Category Archives: Heroku

Sencha Touch: More than a trendy mobile JS framework

Mobile appsA few weeks ago, I started to think about my next project, a mobile dashboard app for Salesforce. As I’m a Ruby/Javascript dev, not an IOS dev, I spent some time investigating which framework would best meet my requirements:

  • The ability to generate IOS/Android apps, to remain device agnostic
  • Using a language I know, improving my skills rather than diluting them
  • Not requiring a heavy env install (it’s never as simple as they say)
  • Well documented, to avoid banging my head against the wall from looking into a raw source code of thousands of lines
  • A promising future – I don’t want to waste my time learning already obsolete technologies

Some of the candidates were RubyMotion, PhoneGap – Cordova, JqueryMobile, Titanium, and RhoMobile. My final conclusions are not based on intensive trials but more on web investigations and personal intuitions. Here are the pros and cons of these different solutions:

  • RubyMotion: promising and really trendy. RubyMotion’s creator was one of the invited speakers at the last Ruby Lugdunum conference. The product is still too young, expensive (not free) and only generates IOS apps
  • PhoneGap – Cordova: a complete framework, now part of the Apache foundation. Able to generate apps for all devices, but looks complicated (too much recent evolution, with Adobe then Apache, heavy IDE with XCode, Eclipse, plugins …).
  • JqueryMobile: everyone loves this framework but it’s a little bit old now. Furthermore, JqueryMobile apps are known to be slow and are obviously not even fake native apps but pure web apps designed for mobile.
  • Titanium: I have no real explanation for why I didn’t choose this option. Maybe because they’ve changed their business model, presentation, name, and documentation too many times in recent years. Maybe because when I have tried it years ago I was really disappointed.
  • RhoMobile: another player using Ruby – and well-established. Positive points, but then it was bought by a big company (Motorola), and furthermore, performance is known to be less than average.

SenchaIn the end, one candidate kept my attention: Sencha. If you work in the Salesforce ecosystem you might have heard about it. Sencha has been blogged about a lot and its presence at Dreamforce 2012 was impressive.

My first experience with Sencha had me hesitate. As with Phonegap – Cordova, there is a lot of documentation available. Furthermore, Sencha’s offering is split into multiple components (ExtJS 4, Sencha Touch 1, Sencha Touch 2, Sencha Architect…). It’s hard to figure out initially which one to use: are they working together, or do they have different destinations?

Even if I am not a huge fan of an integrated environment I thought that maybe, in 2012, Sencha might have achieved something phenomenal with their architecture. Using the 30-day free trial, I started to create my first mobile app to display points of interest on Yelp!. It was cool, the tutorial was easy to follow, but at the end, even if my app worked, I didn’t understood any of the JS code that was generated: it was a bunch of hashes with a lot of obscure configuration options.

A few days later, I started a new app with Sencha Touch 2. Sencha Touch 2 is the latest version of Sencha Touch, and is the component to use if you want to build mobile apps. It’s Open Source and free to use even for commercial purpose. Sencha Touch 2 has the ability to compile your code into fast native Android, Blackberry and iOS apps. Obscure configuration options generated by the architecture became much easier to understand, as Sencha Touch 2 is in fact a classic MVC framework. I recommend watching the following videos to discover what Sencha Touch has to offer, and how to create your first applications cleverly:

  • Discover Sencha Class System. Understand how structurally different Sencha Touch 1 and 2 are, and why the new version is so pleasant to use, with a much more robust and compact syntax.
  • The Sencha MVC framework architecture part 1 and part 2

A lot of people complain about the Sencha Touch documentation. I agree that the main documentation site is a rudimentary API description, and that tutorials are usually not detailed enough. However, Sencha released a learning platform for Touch with access to great content. You can also find interesting blog posts on their website.

In my next blog post, I will explain how I created a simple app that displays records from Salesforce, using Heroku, Sinatra and

Tagged , , ,

Heroku Pro Tips 1 – Running your app in various environments

Awesome Heroku platform is Awesome. We are starting a new series of blog posts today about Ruby and Heroku Pro tips. Discover tips from Tquila Labs Team to leverage the power of Ruby and Heroku. is a SaaS application to build marketing micro-sites and Salesforce-connected forms. Last week we launched the private beta and you’re invited to take part! FormStorm is hosted on Heroku and generates consumer-facing Heroku apps on the fly. During the development process Heroku has been used to host the TEST ENV then, when ready, both STAGING and PRODUCTION ENV. Here are some tips we’ve discovered along the way.

Running your app on various ENV:

A classical approach to maintaining any app is to have 3 or 4 different environments. Each environment is backed up by a specific Git Branch and you usually end up with something like :

  • development env and branch, for local use and local work
  • staging env and branch, for Production-like test
  • Production env and branch, for the live app

This approach is common but it is not immediately obvious how to implement this on Heroku. By default you are in Production mode and only the master branch can be deployed. Here is how to recreate your various ENV on Heroku.

  • First create your apps for staging and production ENV:
heroku create --remote staging
heroku create --remote production
  • Run your app with the correct ENV

Ruby Heroku apps respect the RACK_ENV variable value. Rails apps use the RAILS_ENV variable. To change them, run this in you terminal:

heroku config:add RACK_ENV=staging --remote staging
heroku config:add RAILS_ENV=staging --remote staging
  • Deploy your branches

After that, to push your staging or production branches to Heroku do (respectively):

git push staging staging:master
git push production production:master

That command will push and merge either your staging/production branches on the corresponding remote master.

Next Pro tips on Ruby and Heroku:

  • Ruby – Testing with databasedotcoom gem
  • Heroku – Useful commands
  • Ruby – Extending your SF objects
  • Heroku – Use Thor to handle your VARS
  • Ruby – Performance boost
  • Heroku – Adding a SSL Certificate
Tagged , , , , , ,