agilitic

New app: BlopBlop

Tue, 08 Feb 2011 11:06:14 +0100

During the RailsRumble 2010 in October 2010, we have built BlopBlop, a doodle-like for places, videos, pictures and pieces of source code. It’s been a long time this small service is online but we wanted to post a little bit about it here.

BlopBlop lets you create polls to compare stuff : images, files, links, youtube videos, places on maps, dates, source code, texts, …

No signup required. You can share your poll with Facebook, Twitter or by email.

Following the RailsRumble principle, the app was written and deployed in 48 hours !

Interns : final update

Wed, 29 Dec 2010 06:00:00 +0100

The iPhone version of the CRM client is now functional.

Last week we worked on the synchronization function. It is now complete and allows offline additions, changes and deletions of objects. Here are the steps that it follows :

Get the timestamp from the server and save it. It will be used the next time sync() will be called.
Test if there’s a connection (actually if we got the timestamp). If not, just don’t do anything and return false.
Check for updated objects in the main DB and upload changes only if the local version is the newest.
Check for offline objects, upload them and purge offlineDB. These objects are the ones added when there were no internet connection.
Idem for deletions.
Perform a sync request to the server (every objects modified since last timestamp are pulled including removed ones, see step 8).
Update local contents with new or updated objects from the server.
Since even the deleted objects were pulled (which is good) we now have to delete them from local main DB.
Finally, update the local timestamp with the one pulled from the server at step 1.
This prevent from loosing eventual modifications performed somewhere else during the sync() function is running.
The 3 databases mentioned actually are core data stores. Additions are done in the “offline store”, deletions in the “deleted store” and changes in the main store. Each time one of these action is performed, the sync function is called to maintain consistency between the server and the client. If there’s no internet connection, the sync function just don’t do anything and every local modifications are kept in the differents stores until internet is available again.

There’s now a nice login view. A picture is worth a thousand words :

We brought some improvements to the contacts list, like contacts grouped and sorted alphabetically and a kind of bar to slide directly to a letter.

The task list has also been changed to allow display either all tasks or tasks assigned to the users. In addition, the tasks are sorted from newest to oldest and the tasks “done” are placed at the bottom of the list and are marked by a green circle. The tasks “to do” are placed first in the list and are marked by a red circle.

The edition has been redesigned for better viewing.

Interns : 6th and 7h weeks

Thu, 21 Oct 2010 07:00:00 +0200

Hi folks!

We have been busy again the past weeks. Anyways, find here is the progress of Maxime, Alexis and Joël.

SproutCore web client

Joel requested a few changes to the Rails back-end to have the sync to behave correctly with the SproutCore front-end. Aurélien was very busy on other projects, so he decided to give him access to the source code so he could make the changes himself.

That done, all that was left was the login dialog and a few enhancements and UI tweeks here and there. All in all, the SproutCore version can be considered complete, although Joel will still spend a little time making things prettier.

Next week, he’ll probably be joining Alexis and Maxime to work on the mobile versions, as they are turning out to be more tricky than expected.

iPhone client

These two weeks were entirely devoted to the advancement of our CRM on the iPhone.

We continued the models “edition” part, and we have completely finished the editing of tasks. We can now edit the tasks; it means that we can now change the name, the status of the task (to do or done), the contact to whom the task relates, the details and the user for whom the task is assigned. After the modifications, we just have to touch the button “save” and the program deals with saving it to Core Data and with sending a request “PUT” to change the task on the server.

The editing of contacts is almost over, it remains only the photography part. We recover the pictures, or the business cards for the contacts and we develop in the editing the possibility to choose between the picture library or to take a photo directly. The problem is that the iPhone virtual machine doesn’t allow us to take pictures, so we have to test it on a real iPhone. But we can edit everything for a contact and we can already save it and send the changes to the server.

For the “editing” part, we still have to finish the activity and opportunity models, as well as the multipart part. This one allows us to post pictures and attachments (attachment attribute in activity and opportunity).

For the “creation” part, we can add and delete tasks. Therefore, we need to select the edit mode when we are in the task list, then buttons appear in each cell of our list. These buttons allow us to delete a task as well as to add a new task.

To realize this mode, we firstly have to add an item in our tableView:

We have to implement a method that returns an editing style. For all the elements smaller than the size of our tasksArray, we return the style UITableViewCellEditingStyleDelete “. This style allows us to get the delete button. For the last element, we send the style UITableViewCellEditingStyleInsert. This one allow us to add a new element.

The last method to implement will allow us to do something when the user touches our editing buttons.

The creation of Contact is implemented but not completed, it remains to finalize the picture addition and the business card. We also have to implement the creation for the models activity and opportunity.

In summary for the iPhone, we have to finalize the activities and opportunities editing. We have to look after the “multipart” part for the sending of pictures and files. For the creation part, we have to finish Contact and we need to finish the implementation of edit activity and opportunity. These ones have to be finalized, fortunately we already have the code to implement task and contact, it is obvious that the finalization of these models will be done very quickly. Other parts have to be started and finalized; including two important points such as synchronization and the connection to the application.

Last week we reached an important step in the iPhone development. The GUI that enables the user to create modify and delete contacts tasks activities and opportunities is now completed. So we started to implement synchronization and login (login and password were hardcoded upto last week and the application was pulling every items at startup). The login view is now functional, not the synchronization. Therefore we’re going to finish it this week.

The synchronization principle is pretty simple :

pull modified elements since the timestamp;
add them to a new core data context;
merge it with the main context with an overwrite policy;
finally it’s necessary to filter all the elements that have their “destroyed_at” field filled in.

Many of these functions have already been coded but the whole synchronization is not finished yet. Another important thing we’ll have to do is to remember the last connected user on the terminal. Indeed if a new user connects himself on the terminal of someone else, he shouldn’t see the contacts tasks etc of the previous user. That’s one of the goal of the persistent object “Settings” which was added to the core data model. It will allow us to know if the present user is different of the previous one and if so, to wipe the core data context.

After that we’re probably going to add last features like search, dashboard, …

Interns : 5th week

Thu, 21 Oct 2010 06:00:00 +0200

Finally, the update about our interns! We have been quite busy this week and the publication of their work progress has been delayed a little bit. An internet connection breakdown also slowed us down. Nevermind, here is where they are now.

We spent the last weekend coding for the RaisRumble contest. We’ll talk about our project here soon.

SproutCore web client

The SproutCore application is getting closer and closer to the finish line and is now completely usable.

The past week was first spent linking the tasks and contacts. Joel wasn’t very happy with SproutCore relationships, because linking to models is basically useless: you have to return both ends of the relationship in your backend (so a task has a contact_id, but a contact also has task_ids), and SproutCore won’t update it for you later on (so creating a task for a contact doesn’t add it to the contacts tasks). In the end, the application only uses relationships to access data in an easier and cleaner way, which is nice but a little disapointing comming from Rails.

The rest of the week wasn’t very exciting for Joel, as he mostly had to copy-paste and adapt what he did for the tasks to handle the opportunities and activities.

This week will be spent enhancing the UI, and making some improvements to try and speed everything up. Hopefully we’ll be done by friday, and maybe Joel will be able to write a Cappuccino version to compare the two frameworks on a complete, identical project.

iPhone client

This week has been devoted to the development of views for information about models and to the edition of models. Therefore, several ListViewControllers have been implemented, for one model we have two ListViewControllers: the first one is for the information and the second one for the edition. A third one will be added soon to create items of each model.

Now when we touch a task, for example, we switch to a new ListView with different information about this task. An “Edit” button has been placed on the bar of NavigatorController to open the ListView that allow edition of this task. The class, UINavigationController, is very practical, it allows us to create a navigator on a set of views. In our case, we have four navigator controllers for our four models and we add them directly to our UITabBarController.

We encountered a problem while rebuilding our JSON for each model. We structure the JSON correctly in a NSString. The problem was that when we wanted to display an attribute that is set to nil, we had instead in our string: “(null)”. To avoid having problems later with these brackets, we have added the right conditions to not display the attributes that are nil.

See you soon for the next episode.

Interns : 4th week

Tue, 12 Oct 2010 06:00:00 +0200

Hi all, it’s time for updates about our CRM development by Alexis, Joël and Maxime.

SproutCore web client

This week was mostly spent completing the UI of the web application, correcting a few imperfections to the controllers along the way. It’s far from finished, but contacts and tasks management is already usable, even if it still needs a little polishing.

However, Joel was disapointed with UI programming in SproutCore compared to Cappuccino, noting that some concepts are counter-intuitive, or outright wrong.

Here are a few examples that drove him crazy this week:

Links: using an advanced JavaScript framework, you would think there is a simple way to create an HTML link, such as a linksTo option to the Label object. Well, no. Links are embedded into SproutCore labels by inserting the A tag into the label value, which in turn means you have to turn off the escapeHTML option, so the only way to add links into your application is by making the label insecure. If you rely on user data for your link, like we do for the contact’s website, e-mail address and even twitter username, this can be pretty bad.
Views are ressources in SproutCore. They are written in JavaScript, using SproutCore objects, but somehow they’re not really part of your application. Now this might be a good idea for views with a static layout, with content bound to your controllers, but if you need your layout to adapt to your content, all this serves if making you confused. What is the point of defining your views as external ressources? If you’re using a JavaScript framework instead of, say, Rails, UI is probably a big deal to you, and HTML, even with JQuery, isn’t enough to suit your needs. So why threat views are something separate, something we need but don’t want to keep too close to the “real” code? Cappuccino has a much more UI-centric approach, which seems to be more in sync with the needs of developers turning to these frameworks.
CSS over-generalization. SproutCore tries to simplify UI styling by using CSS rather that embedding styles into your JavaScript code. This is probably a good idea, but there is one problem: each element in SproutCore has at least 4 classes. If you want to change how your application looks, you better be careful and pay extra attention to inheritance: SC.LabelView extends SC.View, so it has both classes, and modifying the top one could have lots of repercusions. Adding your own classes can be painful as well, because you never know where your style could be overriden.

Overall, we’re making a lot of progress, and should complete the unpolished UI this week.

iPhone client

We spent some time looking for resolving the problem encountered last week. Remember, the application crashed when we scrolled in the TableView. The problem was related to Core Data, our entities (Task, Contact, …) were poorly implemented. Indeed, we changed the “@dynamic” by “@synthesize”. The @synthesize automatically generate accessors, but in some classes (including class NSManagedObject used by Core Data) we need to specify variables in code by @dynamic rather than @synthesize. In this way the accessors are created dynamically at runtime.

Android client

This week was mainly devoted to progress on the Android. We began to make item edition and deletion possible, starting by tasks. Contacts, activities and opportunities edition and deletion will be implemented very soon. Now when selecting a task in the list, a new view showing more information about this task appears. There’s a button aimed to edit the task and another one to delete it. Deleting the task removes it from the local database and then sends a DELETE request to the server with the task id number. Editing the task sends a PUT request to the server with the well-formed JSON code representing the modified task.

On the Android client, we can now add/modify/delete a contact or a task.

So much so good, see you next week !

Interns : 3rd week

Mon, 04 Oct 2010 06:00:00 +0200

Hi there! Here are the news about our multi-client CRM developed by our three rock stars.

No Android this time since Alexis and Maxime focused on iPhone all the week long.

SproutCore web client

Joel spent this week designing the foundations of the SproutCore application. We now have a functionnal data source (the SproutCore concept that connects the internal models to the backend), and we can partly view and edit users. There is obviously a lot of work left, but it will only go faster and faster from now on as he’s getting familiar with the framework.

The major trouble this week was to make scrollbars work correctly and automatically adapt to the content. This seems to be a common problem among SproutCore users, and the only solution he found for now is fixing the content height, which may become a problem if a view requires to dynamically expand. As we don’t need that for now, spending more than an afternoon figuring it out seems like a waste of time, so he’ll get back to that if necessary or if he has some time to kill.

iPhone client

This week was entirely dedicated to iPhone development. They wanted to be at the same level of progression as Android.

First, about the connection, they abandoned the idea of making asynchronous connections because it complicates the code and as the requests are not long, it’s okay to wait a few seconds for the query to finish. Therefore, they turned to a synchronous connection and for each method (GET, POST, PUT and DELETE) they’ll implement a function to make the connection, the authentication and to send the request.

Example for the GET method :

Subsequently, they focused on their data storage strategy. Therefore they have, as for Android, a class named DataManager. This class is busy with, among others, the initialization of each model (Contact, Task, Activity and Opportunity), i.e., it retrieves, on the server, the sets of models and stores them on the iPhone.

Core Data seemed to be the best solution to store our data on the equipment. It allows data being organized by the relational entity-attribute model to be serialized into XML, binary, or SQLite stores.

They have encountered some difficulties, especially in the list view of the different models. Indeed, they used four UITableViewController’s for, respectively, Contact, Task, Activity and Opportunity. During the loading of TableView, one part of NSMutableArray is loaded, the other part is loaded with the scroll of this view, but the display of characters is totally wrong. They believe that they’re accessing parts of memory not allocated to our data and this causes a random crash of the application.

Conclusion

Everything continues well!

The iPhone and Android clients are now both able to list all the data. The next step for them is to add the creation/edition/deletion of records functionnality.

Joël is now very familiar with SproutCore, his application is evolving : listings of records is almost functionnal and the communication with the webservice is done. This week, he’ll be working on modification/deletion of records too.

See you next monday or thuesday for the next episode !

Interns : second week

Wed, 29 Sep 2010 08:00:00 +0200

It’s wednesday, and so time for an update on our interns work and research. Let’s see where they are now.

Android client

Connection

We spent most of last week to build the Android application (this week will be the turn of the iPhone). We can now make a GET connection to each JSON file, parse them and display items divided in 4 tabs (see screenshot). Although they’re not used in the application yet, the POST, PUT and DELETE methods are implemented. They all use classes that extend HttpRequestBase (HttpPost, HttpGet, HttpPut, HttpDelete) in the org.apache.http.client.methods package in the reference API of Android SDK.

Data storage

We discovered db4o, an object-oriented database. It allows us to directly store objects just as they are. Then we can get them back using a query by example on the database. Example code to get all Task objects :

GUI

We used a tabbed layout to display all the elements (tasks, contacts, etc). To do this, we had to use the “TabHost” container which is composed of a “TabWidget” and a “FrameLayout”. The TabWidget draws tabs buttons above the FrameLayout which contains what we want to display in these tabs. There’s only one TabWidget and one FrameLayout. The number of tabs is determined by the number of widgets we add into the FrameLayout (here we used 4 “ListView”). All these steps are done in the XML layout file. Then we connected these widgets to the controller classes. To use the TabHost object, we have to retreive it by doing this :

“tabhost” is an id specified in XML. Then to add a tab you do :

iPhone client

We started the week by programming the HTTP connection on the iPhone. We used, as it has been requested, REST architecture. Therefore, we implemented the class “Connector”. This class requires a login, a password and an URL. We were able to establish an asynchronous connection with the server and to retrieve information about the tasks.

When an instance of “Connector” exists, we use the method “connectionWithmethod” to make a connection using the HTTP basic authentication.

Then, we thought about how to store our data on the device and we discovered Core Data. Core Data allows us to store and manipulate objects without using any SQL query. Indeed, Core Data uses SQLite but isolates the developer from the SQL database.

We also made our first graphical user interface (in 5 minutes with Interface Builder). However, it’s not connected to “controller classes” yet.

Cappuccino SproutCore

For the web application, we decided to switch from Cappuccino to SproutCore, another JavaScript framework. Here are the differences we noted between the two, and on which we based our choice:

SproutCore has more documentation, although it is still far from being well-documented. Several tutorials are available, and they cover a wider range than the ones on Cappuccino.
SproutCore comes with a set of development tools, not unlike Rails, including generator scripts and a small test server.
SproutCore is pure JavaScript, and doesn’t define a new programming language on top as Cappuccino with Objective-J. Some might like it, but Joel was now used to the Objective-J syntax, and found it easier to understand than a “fake” language. In SproutCore, you extend a class by calling the extend function on it, for example, which is quite different than in traditional languages. Either way, the good thing is that because you work with pure JavaScript, you have actual debugging info in your browser console and you can even interact with your application while you run it, where Cappuccino offers terrible debugging.
Finally, SproutCore offers powerful bindings, where your model is bound to your view and data source (what connects you to your back-end). This means changing one seamlessly changes all the others, without any refresh calls. We’re having a few issues with the data source part of that, but it’s coming along.

We could also point out that Apple chose SproutCore to power iWork.com, the online version of their popular office suite, so there’s probably something there.

Conclusion

The work goes well, Alexis and Maxime are now more familiar with the mobile technologies they are developing with : they are able to access the webservice and to build some piece of GUI, for both Android and iPhone platforms.

Joël has decided to switch to SproutCore, a decision we support as it has been chosen for good reasons. His work has nevertheless continued : he didn’t lose a lot of time on Cappuccinno. He is already up and running on SC !

See you next week with a new step !

Interns : first week

Tue, 21 Sep 2010 07:00:00 +0200

It’s already time for the first post about our interns!

The first week mainly consisted on :

discovering the tools, SDKs and ecosystems;
playing with the APIs;
drawing mockups for the 3 apps.

To play with our REST API, the interns use rest-client which relies on the cURL library to perform the HTTP requests.

Android client

With a Nexus One in their pocket, Alexis and Max had some fun playing with the Android SDK.

One of the first problem they encountered was to choose the lowest Android version they want to support. To make the application compatible with as many Android phones as possible, they chose to use the 4th API level (Android 1.6). Therefore some features and tools are unavailable. By example, we had to use an external Base64 class to authenticate the connection while this class is present in the API level 8 (latest version, Android 2.2).

The GUI editor is not very easy to use so we have to edit directly the XML file to make the GUI. We’re looking for a better editor like “App inventor” (which doesn’t only create GUI) easier to use.

iPhone client

Alexis and Max have no prior experience with Cocoa or Objective-C. Combined with the fact that they do not have an iPhone and that they are not daily MacOS X users make their tasks much more difficult. But, hey, they are here to learn :)

They tried and seemed to like Interface Builder, the tool to create GUIs for iPhone and Mac applications. Compared with the built-in editor of Eclipse, it’s definitely better.

Cappuccino

Joel worked on the Cappuccino version of the client. He does not have any prior experience with Cocoa or Objective-C/J. He has to deal with the relative level of immaturity of Cappuccino and with an unfamiliar programming environment. Here are his first feelings:

Cappuccino is a great tool for writing desktop-like web applications. The framework offers a simple way to create beautiful things, and the result is as smooth as any other application, despite being JavaScript from head to toe (just see the impressive 280slides.com).

Of course, every great tool has its downsides. Here are the few that bothered me in Cappuccino:
Objective-J, the programming language developed alongside the framework, has a peculiar syntax, the most uncommon and recurring element of which being the extensive use of brackets, that enclose every method call as JavaScript cannot handle them natively. If you have used the language’s big brother, Objective-C (mainly used for iPhone development), you won’t have a hard time learning Objective-J, as it uses the same principles and syntax. But if you’re like me and only used regular object-oriented programming languages, you’ll have to get used to surrounding every method call with brackets and replacing the dot with a space.

Lack of development environments: Cappuccino and Objective-J are only supported (via plugins) in a few Mac-only text editors, like TextMate or Xcode. If you’re a Mac user, you probably have TextMate already (and if you don’t, give it a try, it’s worth every penny), so no big deal. But if you enjoy another operating system, as I do with GNU/Linux, the excitement will probably wear off after a few hours of programming without any syntax highlighting. Some are satisfied with Objective-C or JavaScript plugins, but I chose to switch to OS X for the writing of this application. Hopefully, a Linux and Cappuccino fan will write a plugin for Gedit or Eclipse soon (I might if I find the time), and this issue will be resolved.

Poor debugging information: I tried development using Firefox (and the Firebug extension) and Safari, but none are able to provide precise error details. This actually comes from both JavaScript and the Objective-J interpreter, which fail to report the file and line where an error occurred. The only solution I found: testing as often as possible, so you can pinpoint which changes caused the problem.

Communicating with the JSON back-end was surprisingly easy. Cappuccino offers two ways to do so: using a regular HTTP connection and parsing the resulting file with a single JavaScript call, or via a JSONP connection. The first only works if your front and back-ends run on the same domain, for security reasons. The second was developed to circumvent these security restrictions by the use of a
Of course, the gem is ActiveModel-compliant. Any feedback is welcome on the GitHub issues tracker. You can also find a Rails 2.x version which doesn’t implement the VIES webservice connection.

Hope it helps!

Pacman is there

Fri, 09 Jul 2010 06:00:00 +0200

According to dRine, our office walls were way too boring. She turned up yesterday morning with some paint brushes.

and here is the final result:

Many thanks dRine !

Paperclip and delayed_job FTW!

Fri, 11 Jun 2010 07:00:00 +0200

This article is intended to thank two rails plugins that our apps couldn’t live without. The well known Paperclip from Throughtbot and the Delayed Job project (a.k.a. DJ) initiated by Tobias Lütke.

We successfully deployed last week an application for a customer of ours whose purpose is to manage a library of songs. The 33k+ music tracks are organized on disk with Paperclip. For each track on the system, two mp3 versions are generated with lame inside an asynchroneous delayed job.

That’s the biggest queue we’ve ever had here!

Photo credit : http://www.flickr.com/photos/paulrussell/276029831

LiveResto in da cloud

Mon, 03 May 2010 07:00:00 +0200

Since the launch of LiveResto in November 2009, the main app has been hosted on Heroku, which relies on Amazon EC2. We are big fans of Heroku’s git push style deployment here at agilitic and we recommend this service to all of you Ruby guys.

Additionally, I am proud to say that the whole LiveResto website is now fully deployed on cloud-technology platforms: the application and database layer on Heroku, the assets on Amazon S3. All emails are delivered by Sendgrid.

Seminar at UMONS

Fri, 30 Apr 2010 07:00:00 +0200

Last Wednesday the agilitic team was at UMONS to give a seminar in the context of a lecture organized by Chantal Poiret for 3rd year of Bachelor and Masters degree students in Computer Science.

The talk (in french) was split in 3 parts : The future of the Web by Steve, Retours d’expérience d’entrepreneurs en informatique by Aurélien and Javascript, l’assembleur du Web by François.

It was a pleasure for us to be back in our school.

Javascript l’assembleur du web ?

View more presentations from Francois Stephany.

Retours d’expérience d’entrepreneurs en informatique

View more presentations from aurels.

LiveResto at BetaGroup

Wed, 20 Jan 2010 06:00:00 +0100

Today, our first in-house product will be presented at BetaGroup #15 along with WooRank, Knowledgeplaza, whitepapercentral, pic2shop and Tinker Touch.

LiveResto is a hosted CMS for restaurants that aims to provide an easy way for restaurant owners to manage their website themselves.

BetaGroup is a community of belgian entrepreneurs interested in Software, Web and online business. This community hosts free events where 5 start-ups have 5 minutes to show off their product.
This time, the event will take place at ULB in Brussels (Auditorium UD 2.120).

LiveResto had already been presented at the first BetaGroup Mons on Wednesday, December 16, 2009.

See you tonight in Brussels!

New Reference: Terrabio

Wed, 25 Nov 2009 06:00:00 +0100

The agilitic team is proud to show you his latest reference: Terrabio’s website.

Terrabio is a brand that offers a complete range of make-up products, specially intended for spas, beauty salons and perfumeries. Other skincare products, along with specific protocols, will be launched in 2010.

This website was created in collaboration with Destyle graphic.

http://www.terrabio.net