December 30, 2013

Tutorial: How to get started with Apache Cordova and Firefox OS on Nitrous.IO

It's time to go mobile. And it is time to go cloud. Why not go mobile in the cloud? In this tutorial we'll learn how get started building mobile web apps using Apache Cordova (formelly PhoneGap) and testing your app using the Firefox OS Simulator. To avoid some setup complexity and to allow for coding entirelly in the cloud, let's build the app using a Node.js Nitrous.IO box.

1 - Signup for Nitrous.IO and spawn a Node.js box

Nitrous.IO is cloud development environment, that allows you to quick and easy setup a linux box in the cloud with zero-install: just using your browser. If you don't have a Nitrous account yet, you can signup for one on, using Google, Github, or by using a username and password.

Once logged into Nitrous, start a new box, and choose the Node.js box template:

The IDE will open after your box is ready, with the following image:
The black screen in the bottom is the Console window, where you will type the commands.

2 - Install Apache Cordova CLI using npm

Apache Cordova is a mobile application container, that allows you to build Web Apps that can be installed on mobile devices, and benefit from the device features, such as Camera or GPS. I recomend reading the documentation to get a grasp on it: at least Overview and Command Line Interface (or the Web Project Dev).

To install cordova on your box, run the command below in the console window:

$ npm -g install cordova

NPM is the Node Package Manager, and the Cordova CLI is distributed as a node module. The above command will download and install the Cordova CLI tools and install them on your Nitrous box, under the ~/.nvm folder. This may take some minutes, and when it the instalation is complete, you can test it with the command

$ cordova info

This command will display some details about how to use cordova, and about your cordova instalation.

3 - Start a new cordova project

With Cordova installed, we are ready to start the project itself. In your console window, run the commands:

$ cd ~/workspace
$ cordova create hello

This will create a project under ~/workspace/hello, and you will be able to see some folders:

$ ls hello/
merges  platforms  plugins  www

The folders merges, platforms and plugins will be empty, but we will fill some of them soon. The merges folder hosts platform specific content overrides. The platforms folder will host the cordova.js JavaScript bindings, plus some configurations and other media. The plugins folder will host additional plugins, as you add them.

The www folder is your application root. Cordova will create a small sample app that responds to the 'deviceready' event in that folder. The index.html file references the app script, style sheet and image assets.

4 - Add the Firefox OS platform

To make your app deployable, Cordova needs some platform specific JavaScript bindings, plus the target platform SDK to build the final app. You can add as many platforms as you wish, with the command cordova platrorm add <platform shortcut>. Some platforms, like ios (from Apple) or wp8 (from Microsoft), require a particular operating system to build and run your app on emulators (see details here). In this tutorial, we'll be using the firefoxos (from Mozilla) platform, since it can be tested entirelly using the web.

To add the Firefox OS platform, run the command, from the hello folder

$ cd ~/workspace/hello
$ cordova platform add firefoxos

After that command finishes, the platforms folder will have a new sub-folder, with the cordova bindings and some sample configurations. We are ready to test our app now!

5 - Test in the Nitrous.IO browser

Cordova can serve your app from a built-in web server, so you can test your preview the app on your browser.

Once we have added a platform, we can run:

$ cordova serve 3000
 Generating config.xml from defaults for platform "firefoxos"
 Preparing firefoxos project
 Static file server running on port 3000 (i.e. http://localhost:3000)
 CTRL + C to shut down

Nitrous allow you to do live testing of servers started from your box. Click on the Preview menu -> Port 3000, and a new browser window will open, displaying the Cordova serve main page:

This page lists some app info, and the platforms and plugins available. Note that the firefoxos platform is a link you can click and, voila! Your app is running!

The same URL can be used to access the app on your mobile phone or tabled, using the device browser, so you can preview how it may look like in the smaller screen.

6 - Install the Firefox OS Simulator

Besides using a tools that allow you to preview the web page on mobile device iframes, you can also use a real device emulator for this task: the Firefox OS Simulator. The device simulator is a Firefox add-on that allows you to test web apps designed to Firefox OS. To install it, launch Firefox (or Iceweasel if you're on Debian), and go to the Firefox OS Simulator add-on page, then click "Add to Firefox" button. The download and setup may take some time, the add-on has more than 60MB.

Once installed, the simulator can be launched from the Firefox (Iceweasel) menu -> Developer Tools -> Firefox OS Simulator.

7 - Run your app in the simulator

The simulator will allow you to add a URL for your app. Copy the link of your app preview and paste it to the Firefox OS Simulator URL bar, then click on the "Add URL" button:

The device simulator will launch, download and install your app for testing. And you will see the app running on the simulator:

The simulator is a pretty nice, and give you an idea on how your app fits on a real device. You can test the device with your mouse, and navigate over the OS and test launching and closing the app.


The web of today is the web accesible from Mobile to 4K TVs. The mobile market is growing fast, and the web is here to help you jump in. Using technologies such as Cordova (PhoneGap) you can reach a broader audience of mobile customers, by using well known web standards. Cloud Computing enables infinite scaling and computational power, helping you build awesome apps that can do amazing things. Nitrous helps you get started on almost everything, by providing a simple and easy to use web interface, with a powerfull GNU/Linux box in the cloud.


/happy hacking

November 16, 2013

Coding in the Cloud - Part II - Google Apps Script and Google Sites Review

Continuing the Coding in the Cloud series, today we'll take a look at the possibilities to quick and easy build web sites and smart web applications using some cool tools from Google: Google Sites and Google Apps Script.

Google Sites is a tool to help you quick and easy build a website. You can think of it as a CMS tool, with some goodies: built-in themes, mobile optimization, site search, customization of theme and layout, and a few other nice integrations with other Google Services. You can, for instance, embedd a Google Drive Form into your site with a few mouse clicks.

Apps Script is a JavaScript rutime that runs in the Cloud, and that allows you to extend and automate the Google Apps suite, improving Google Docs, Forms, Spreadsheets and Sites. It has a lot of builtin support for a Google APIs, allowing you to integrate your script with both Google Apps and Google Cloud services.

Development Envionment

With your standard Google Account or with a Google Apps Account, you have access to the Google Drive and, from there, to the Apps Script Editor. From Google Drive, you can create standalone scripts that you can publish either as libraries or web applications. You can also create scripts from containers, like a Spreadsheet, a Document, a Form or a Site.

The Script editor has some nice features. It runs in your browser, has syntax higlight for HTML, JavaScript and CSS, and also features an integrated debugger. From the editor, you can manage the files within your project, that can be Script files (with .gs extension), and HTML files (with .html extension).

Web Apps, Widgets and Web Services

With Apps Script you can build apps, widgets for Sites or Docs, and even simple web services. Your script can handle the HTTP GET and POST methods with callbacks, and serve content like HTML, XML, JSON and many more using the HtmlService and the ContentService modules. You can also build usefull widgets and embedd them into Sites or other Google Drive apps.

Import and Export features

A recently launched feature that is very usefull is the ability to import and export standalone scripts. You can, for instance, create a github project page for a Apps Script library, and manage your source versions from there. Once you have it done, you can then publish it to Google Drive and create a new deployed version from there.

Taking advatage of this resource, a few weeks ago the Google Plugin for Eclipse received an update allowing you to edit your Apps Script code within Eclipse, and sync back to the Cloud.

Easy integration with other Google APIs

With the seamless integration with other APIs, you can build awesome apps. You can use services like Big Query, Google Prediction, Google Cloud SQL, and many other Cloud APIs, appart from nice integration with Google Drive, Gmail and other Google Apps services. All services expose JavaScript libraries to help you get started and use take advantage of a lot of funcionality from those tools.

A few time ago, I flooded my inbox with unwanted, repeated e-mails from a bad mail alert on one of my systems. It was about 5 milion e-mails, impossible even to let Gmail alone to remove. Thanks to Apps Script, I was able to write a simple, batch removal, capable to cleanup my inbox.


With container-bound and non-container bound triggers, you can schedule your script to run daily, or in response of an event, like a Form submission. A good use case, is to send e-mail alerts every day, on a simple help-desk like Spreadsheet, reminding users from the open tickets.


Initially designed to be a way to users customize and extend funcionality from Google Apps services, Apps Script is upgrading himself to a very nice, and easy to use tool. Using the Google Sites CMS features with the Apps Script programming in the backend, you can quickly build a web app that range from simple corporative tools to full featured e-commerce web sites. Seamless integration with the Cloud and other Google Services allow your app to be built and deployed entirely in the Google Cloud!

Stay tunned to the next post in the series!

September 4, 2013

Mapping multiple domains to Google AppEngine with nginx reverse-proxy on GCE

If you work with Google AppEngine and want to map a custom domain to your application, you must also configure Google Apps for that domain. If you have an app with a white label option, your customers also have to configure Google Apps in order to use your app under their domain. Not only that, they must also manage the Google Apps setup, outside your application.

There are two issues on the public issue tracker that you may be interested to star and watch. One about creating an API to manage the domains: and another about the problem itself: I recommend both to be starred so we tell to Google AppEngine Team that this is important!

But if you simply can't wait for them to be fixed, you can fix it yourself building your own reverse-proxy solution, and make it scale with your app. With a simple nginx proxy setup, running on a GCE instance, a round-robin DNS mapping and a small set of changes into your source code, you may acomplish that with very little effort. As a bonus, those proxies can be usefull for other stuff too, like another level of caching that can save you some instance hits.

Initial setup

First of all, I'm assuming that you already have an AppEngine application with billing enabled, and that you have created a Google Cloud Console project for your application. If you don't have this already, then sign up for AppEngine, setup billing on your app and setup billing on the Google Cloud Console for you application. This will allow you to use all resources required.

If your AppEngine application don't have a Cloud Console Project yet, go to you AppEngine Dashboard -> Application Settings -> Cloud Integration and click in the button "Add Project". After that procedure take place, you will see a box like this one:

After that, login on Google Cloud Console at, select the project with your application and go to Compute Engine -> VM Instances and click on the "New Instance" button. I recomend using the Debian Wheezy 7.0 image as starting point, as it is the current long-term stable release of  Debian, and because Debian is the new default image to use in GCE.

In the new instance screen, give it a name and description. Also, I recomend label it with tags to help you manage more than one instance at once. I've added the tags nginx, proxy and http. Later, we will use some tags to configure routes and firewalls.

It is also recommended that you choose "New static ip address..." in the Networking section, wich may allow you to configure the proxy more easily.

To finish your instance startup, click in the "Create" button and wait until your instance is ready.

Installing and configuring nginx

Once your instance boots, you are ready to configure the software that will allow it to proxy requests to your AppEngine application. I choose nginx as the software, because it is a lightweight and high scalable HTTP server. You can also do this with Apache or even Squid if you wish, but nginx scales easier and the configuration is very simple.

Login into your new instance via SSH, and issue the following commands:

sudo bash
apt-get update && apt-get upgrade
apt-get install nginx unattended-upgrades

The first command starts a new bash session as root, as we will need to configure and install everything as super user. The second line updates package lists and install security upgrades. The last line installs our HTTP server, nginx, with default configuration and the package unattended-upgrades, to automatically install security patches.

Next, let's configure nginx to proxy requests from to our application. AppEngine has some wildcard domains in place for every app. Any requests reaching * will reach the default version of your application. With that in mind, we can easily map on nginx to proxy

To put this into our newly installed nginx, let's create a file named /etc/nginx/conf.d/appspot.conf

Listing 1: /etc/nginx/conf.d/appspot.conf

server {
  listen 80;
  location / {
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://$$request_uri;
    proxy_redirect http://$ /;

Let's check this configuration:

  • First, we create a "nginx server" at port 80
  • In that server, we set a resolver to the Google DNS
  • Then, we configure the proxy to add some headers. I'm setting all of them, to be safe, but they may not all be needed.
  • Finally, the proxy_pass and proxy_redirect directives will make requests be routed to your app, and when you return a 302 redirect it will hide the proxy internal name.

Configure instance firewalls

To make your proxy available to the public, let's setup a firewall rule in the instance network to allow traffic incomming from any host to the port 80.

In the Compute Engine Console, click on the VM Instances section, and then click on your recently launched instance. Under the instance details page, you'll see the Network section, where you can find a link to the newtork your instance is attached to. Click on the link and in the network configuration. under Firewall, and fill the form with the following values. I used the tag http to apply this setting to all instances with that tag. Very handy!

Tip: for better control over your instances, you can create a new network under the Network section of GCE console, and then on instance creation, select the network to keep your proxies with the same setup.


As you may expect, there is aways a trade-off! This setup may cause some side-effects:
  1. UserService.createLoginUrl() aways redirect the user to the proxied address under
  2. To your app, the remote address will aways be the proxy IP and the request hostname will be under
You can solve #1 by replacing the login management to tools like openid4java, or something similar, achieving the same goal. #2 is discussed bellow, and also require some code changes.

Update your code when you need the real hostname

You may already have some sort of code to make the hostname from the request map to your customer data and resources, like customizing the logo or a stylesheet. In this case, you have to tweak your code to handle the request headers we set on nginx instead of using only the values from the current request alone.

If your web framework allows you to add some middlewere classes like Django, or a servlet Filter like Java EE, then you can use this to intercept requests, check for proxy headers, and wrap the request methods that return the hostname or request URL to use the values from the proxy. See bellow for a sample Java Filter that will do the trick (Listing 2):

Listing 2:

import javax.servlet.*;
import javax.servlet.http.*;

public class ProxyFilter implements Filter {

  public static final String HEADER = "x-forwarded-server";

  public class ProxyRequestWrapper extends HttpServletRequestWrapper {

    public ProxyRequestWrapper(HttpServletRequest request) {

    public String getServerName() {
      return getHeader(HEADER);

    public StringBuffer getRequestURL() {
      StringBuffer url = new StringBuffer(getScheme());
      return url;

  public void doFilter(ServletRequest proxyRequest,
             ServletResponse proxyResponse,
             FilterChain chain) throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) proxyRequest;
    String header = request.getHeader(HEADER);
    if (header != null && !header.trim().isEmpty()) {
      request = new ProxyRequestWrapper(request);

    chain.doFilter(request, proxyResponse);

  public void init(FilterConfig config) {}

  public void destroy() {}

You can make similar changes using a Django middleware. Please refer to the django documentation for details.

Scaling your reverse-proxies 

To scale your proxies, you can add more instances with another reserved IPs, and use DNS Round Robin as simple way to achieve load-ballancing.

You just need to add multiple A records for a sudomain like, one for each proxy IP. Then, when mapping the domain to your app, your customers can simply create a CNAME record to The requests will be distributed over your proxies using the Round Robin algorithm. Please refer to your DNS hosting documentation for details, and to check if they provide this DNS algorithm.

Tip: Since this nginx setup is very simple, you can configure a small startup script, host it on the Google Cloud Storage, and then make it easier to start new proxies: just call the command gcutil with the startup script URL as a parameter! After your new instance boots, just add the new reserved IP as a new A record for This is not an automatic scaling, but is very easy to start/stop them, and also to remove nodes from your system.


This procedure can also be used on other cloud providers, like Amazon AWS or Digital Ocean, or any other provider with Deiban Wheezy support. This configuratoin steps can also work on other distributions or nginx versions, altought I didn't tested.

Hope you enjoy this tips, and if you run into problems, drop a comment bellow and we can help you out!

Happy Hacking!

August 7, 2013

Coding in the Cloud - Part I - Nitrous.IO Review

Hello fellows, this is the first post in the new Developer Blog by Ronoaldo. This blog post is also the first of a series of reviews on Cloud IDEs. They give you the power of scaling your development environment as the same way you scale your applications. Also, it is the same workspace on all your devices: no need to setup your workspace over and over again.

Code, test, build and deploy in the Cloud

A cloud development environment allow applications to be entirely coded, tested, built and deployed in the cloud. The concept of a Cloud IDE is gettig more and more attention, and this is the first post of a series of reviews about some of the tools I've tried.

I'll start the series with Nitrous.IO. It has a clean design, extremelly fast responsive UI, comes bundled with all tools to jump in and start coding, allows you to run servers and other tools on your box and test you app live from there. It has all features that are really usefull to replace your local environment, and new features are comming.

It simply works

If you're used to run Eclipse locally, and try Nitrous.IO for Java, you'll probably miss a few of buttons, short cuts, menu entries and so one. I found that the key strengh that Nitrous has is that all things simply work. Period. I've tried other IDEs that has some fancy buttons, but they don't work for real worls projects. This gives you the felling that programming in the cloud will not work at all. Nitrous, on the other hand, has just the small subset of tools that you need to develop online, and all features there simply work.

Fast user experience

I'm a big fan of running stuff on the terminal: it is simple to remember, easy to automate, and it gives you a full power of doing, well, anything! The terminal emulator of the Nitrous IDE is one of the most amazing I've used. It allows you to fire up Vim and have the feelling that you're on your local computer. It responds so fast that you don't even realize that evey character you type goes over the internet. It is even faster than most SSH sessions I've being running over some cloud providers, with not freezing of the UI.

The IDE also has a clean and usefull code editor. The editor is very simple, has syntax highlight but no code completion. It comes with a dark theme, which helps you keep focus on your code. It also handles tabs/soft-tabs very nicely.

The possibility to invite people for your workspace is also cool, and works fine. You can edit the same file, doing a "pair programming session", with a remote co-worker. Wen you finish, you can simply remove access for your workspace. You have full control, unlike other tools where you can't remove someone you've added.


Another key strengh of Nitrous is flexibility. The concept of "build your own plan" is really cool. My opinion is that this is something that all other players on the market didn't realized yet: every developer and project has different needs. There is no plan that will fits all, and bringing the "pay as you go" to IDE was a smart move. This opens a whole new gate of possibilities. It allows you to try out with less cost, and when you feel that the tool is ready to do the job, you just buy more NO2 and the thing runs faster or with more storage. You choose. Having choice to configure your workspace the way you need it is really important, specially if you work with different projects.

But the customization don't stop there: you can download and install on your box other toosl you'll need, making your box the perfect workspace for all your projects.


The whole user experience is fun. Either waiting for your box to startup, or when trying to win more NO2 by completing some goals, there is aways some cool interaction while you're coding. I've shared the join link with a lot of friends, both because they must try out the tool since it is a good one, and because they'll help me boost up my workspace ;)

And more

This is just a small overview, but you can also setup and connect using SSH, direct intor your box, allowing you to use a Local Eclipse when you need or you're tired to use the web IDE. You can also use your favorite DVCS tools, Mercurial and Git comes pre-installed by default. And a lot of more. See this page for a complete list of features:


The Nitrous.IO environment is fun, usefull, clean and solid. All you need to build your apps! Altought the princing is still not finished, and they're still in beta, Nitrous is the tool I'll definitelly keep looking forward, and I invite you to try it out.

Leave your comments bellow, and don't forget to subscribe to keep updated with the new posts of this series.