Got half an hour to kill? Make it useful to the community!

TranslatewikiRecently I was looking for an open source engine to create a stackoverflow-like website in Italian about mortgages. The best alternative I found is Shapado, which is also rails-based, always a plus for me.

Anyway, on their website I found out that they’re going to release a new version soon, and that it still missed an Italian translation. After a little investigation, I also found out that everybody can contribute to that translation on translatewiki.net

I had never heard of that website, which is part of MediaWiki. I decided to give it a try, and after subscribing and waiting a little for approvation, I started translating the latest version of Shapado into Italian.

I would never have believed it, but it was kind of fun! The web translation interface is really very well-thought, the google and bing suggestions are quite helpful (and sometimes funny), and it only took me a couple of hours to translate all the parts that weren’t already translated from the previous release.

The best part is that this is something that you can do whenever you have some free time and a web connection; you are immediately productive, and seeing the list of missing translations becoming shorter by the minute really gives you a good feeling of accomplishment.

So, if you know one language different from English and have a little time to spare, what are waiting for? There are already 20 open source projects on translatewiki waiting for your help. Give them a hand!

Saved by the magical powers of GIT

Yesterday evening I was very happy: My first mobile app, after a little more than a week, was practically finished. It just needed some little finishing touches.

At that point I decided to take a look at it on my phone, after a few days during which I had only tested it on the Android emulator, which allows much faster debugging cycles. So I connected my phone, started deploying the app, waited, started the app… and… crash! It didn’t even open the first screen.

At 12:10 AM and with a long day at my day job waiting for me the next day, I tried to redeploy the app; then, to restart the development environment and redeploy the app; and, last try, to restart the phone and my pc and then redoploy the app. To no avail: It worked perfectly well on the emulator, but on my phone it just wouldn’t start.

So today, after coming home from work, I prepared myself for a LONG debugging session. My plan was to find the latest version on GIT that worked on the phone, and understand what went wrong after that – hoping that there was only one thing that went wrong.

First, I started going just a couple of commits back – I commit very often – to check that the problem was there. It was. Then I tried to remember when I last tried the app on my phone – it had always worked – and checked a version from around that time. I was a little apprehensive by now… but it worked!

I then started the methodical search for the time when the problem came out, so I tried the commit at the middle of the road between the working version and the not-working one. It worked. Then, I again found the middle of the road, and tested. OK. And again: OK. And again: OK! This was just two commits before the not-working one.

At this point, I went up one commit only. It worked. Another one, the last one before my first test (which failed). It worked. Was it possible that, just by chance, I had tested first exactly the commit where the problem arose? Well, I tested it again, to be sure and… surprise, surprise… it worked!! I’m pretty sure that, however much Dijkstra might have liked them, I didn’t use any non-deterministic programming techniques, so I was a little flabbergasted.

Next try, I checked out the master; deployed it; and it worked!

How can I explain it? I’m sorry, but I just can’t. And, as tomorrow I’m going to leave for a short vacation, I don’t even have the time to find out now. I suppose (and hope) that it was just some weird problem in the Titanium compilator, and not in Android itself. If it isn’t either of the, well, I guess I’ll have to suggest adding “Magic” to the list of GIT features.

App Development: Appcelerator vs (Phonegap + (JQuery Mobile vs Sencha))

Mobile apps are all the rage now, but to create cutting edge solutions on mobile platforms, at least for now, you need to adopt native development. So, as I have an idiosyncrasy  for Java and never developed on (not even used) an Apple platform, and lacking a real motivation to start, until now I kept myself away from this field.

Last week though, after reading once again a couple of inspiring article on Hacker News, I started thinking that trying out one of the various cross platform, javascript based solutions for mobile development on a lightweight app could be a pleasant distraction from my current main (night) projects. I even started fantasizing that, if it was really possible to create a web app using just “html5″ technologies, I could have been able to create a complete app (without too much polish) over just one weekend.

A fairly simple yet useful candidate for a lightweight app was to create a mobile front end for my adjustable rate mortgage calculator. Since all the complicated financial stuff is done on the server, and I already created a simplified web service for the free embeddable version (widget), if I could really use the usual web technologies on the phones my “aggressive” (ie, crazy) deadline seemed feasible.

So this is why, on a Friday evening after my day job, I started studying in depth all those solutions that I had just lazily kept an eye on during the last months. I think that what I learned can be interesting to others, so I’ll expose my findings here.

The contenders

My requirements for the ideal development platform were simple: To be as close as possible to usual web development, good enough for the job at hand, able to work on both Android and the iPhone, and possibly free or at least very cheap (as this was just a side show).

After some hours doing a literature review (ie, googling around), I came up with a short list of three candidates:

  1. Phonegap + JQuery Mobile (JQM)
  2. Phonegap + Sencha Touch
  3. [Appcelerator Titanium]

The order of the above list isn’t random. The first combination (Phonegap + JQM) was, on paper, my perfect solution: Based on JQuery, it really is web development for the phone, and it would have allowed me to even reuse part of my current code base.

Sencha Touch is another “html5″ solution (meaning that it creates html GUI objects, not native ones), and from what I read it is quite faster than JQM, but on the downside GUIs have to be created procedurally – something I started hating with the MFC, and never got myself to like.

Last, Appcelerator Titanium is javascript based, but it uses native controls. This should guarantee the best performance of the three, but, in addition to having only procedural GUI programming like Sencha, this also means that things sometimes have to be different on Android and on iOS, so this isn’t cross-platform of the “write once-run anywhere” kind. And, last but not least, I had found an alarming article about some nasty memory leaks that seemed almost a show stopper (that’s why I used the square brackets on the list – at one point Appcelerator was more out of the list than in).

There were also other interesting propositions (like rhomobile – I love Ruby), but they looked less viable for one reason or another and I won’t go over them here.

Testing

What I wrote until now is only based on my “literature review”. With my preferences made up, I decided to try the Phonegap/JQM solution hands on.

Setting everything up was easy enough. The problems came when I tried the “kitchen sink” test app on my Android phone (HTC Wildfire). The performance was terrible, and the rendering often incorrect. The same happened with a showcase app downloaded from the Android Market.

So, that was it for me. As much as I wanted this solution to work, my conclusion is that it is just not production ready yet, at least not for my goals and not for the current generation of not high-end phones. Good bye, reuse of existing code…

I then went on to Sencha. This time, I wanted to check the performance before doing any installation. So I looked for any success story for Sencha on Android, and luckily I found a very recent and very relevant article on techcrunch. When I read that “… it wasn’t easy, performance was a huge issue [and] at times it took days to figure out, and simple things like too much logging and poorly constructed ‘for’ loops actually made our app unusable during our journey.” I didn’t feel very optimistic.

So I installed on my phone the Diary app from the android market. Better than JQM, but still sluggish and with layout problems on my screen size too. And this after a long and painful optimization work, according to the article… not for me, not now. So, Sencha too wouldn’t fit my requirements.

At this point I was pretty disappointed, as I saw my fantasy of being able to complete an app over the weekend slipping away from my grasp. But, not wanting to give up, I decided to look better into Appcelerator: At stake was not only my simple app, but the possibility to develop more interesting ones in the near future!

First of all, I decided to take a look at the existing Titanium-based apps. Among their showcases there are many more iOS apps than Android ones, but I was able to install a couple of good examples on my phone; GetGlue, in particular, looked and felt really good.

But what about the memory leaks? After some more search, I found out that you can avoid them following some guidelines (see the comments in the alarming article) and, if still necessary, using some workarounds that would be perfectly acceptable for my current needs. I’m also pretty confident that in time Appcelerator will fix these problems (if they want to stay in business).

Conclusion

In the end, I downloaded the Titanium Studio and started coding. So far things went pretty smoothly, and, even if I didn’t create my full app over one weekend, I already solved 70% of the technical obstacles – it can already get the needed input from the user, send it to the server, get the response, and show some data in simple pure html bar graphs. What is still missing is a lightweight enough solution to show the payments time series, but I’ll start on that as soon as I have time.

What I learned from this very industrious weekend is that the news about the impending death of native app coding are greatly exaggerated, and that (surprise, surprise!) a LOT of what you read all over the internet about the marvels of html5 development is BS. But I also learned that, even if there are no silver bullets flying around, developing for mobile in a pretty much cross platform way with just one programming language is indeed possible, and that procedural GUI programming, on the simple UIs that you can create on phones, isn’t as painful as I remembered from developing fully fledged desktop applications.