Running Flask in Cloud9 with Virtualenv

I’ve been playing with Cloud9 lately and wanted to get a Flask application up and running. In case you don’t know about it, Cloud9 offers virtualized Ubuntu instances where you can develop applications and install libraries without paying anything.

Even though Cloud9 offers a ready to go Django environment, I wanted to see how I could get a Flask application up and running. I ran into some issues, specifically with the Python “runner”. Runners are basically servers that allow you to see your application in a browser.

Here’s what I did step by step.

First create a new hosted workspace with a custom type selected:

Cloud9 Workspace Select

Open a terminal window and in your workspace directory, create the virtualenv and activate it:

virtualenv venv
source venv/bin/activate

Install flask:

pip install flask

Now create a folder for your project (I’ll make it “project”) and inside create an

import os
from flask import Flask
app = Flask(__name__)

def hello():
    return "Hello c9 World!"

if __name__ == "__main__":'IP', ''),port=int(os.getenv('PORT', 8080)))

Then right click it and run it, it will throw an error:

Your code is running at
Important: use os.getenv(PORT, 8080) as the port and os.getenv(IP, as the host in your scripts!

Traceback (most recent call last):
  File "/home/ubuntu/workspace/project/", line 2, in <module>
    from flask import Flask
ImportError: No module named flask

What’s happening here is that Cloud9 is running the file with the standard Python binary which is not the same one on our virtualenv. We need to explicitly pass the python in our virtualenv so that it runs correctly.

So, click on the runner and select edit:

Cloud9 Runner Editor

And edit the file so that it references the right python:

// This file overrides the built-in Python 2.7 runner
// For more information see!/api/run-method-run
  "cmd": [
  "selector ...
more ...

Is There a Future for Hybrid Apps?

Hybrid Apps

There’s been a long standing debate in the past few months on the feasability of developing mobile applications using HTML5, JavaScript and CSS.

Facebook’s founder went as far as partly blaming their initial hybrid approach as the reason they had failed in their mobile strategy.

“I think the biggest mistake we made as a company is betting too much on HTML5 as opposed to native,” he admitted, acknowledging his company’s difficulties in piecing together a coherent mobile strategy.

Today Basecamp announced on their blog the release of their new iPad app, which follows a hybrid approach just like their other apps (iPhone, Android and Kindle).

Jason Zimdars, an UI designer, explains on the post in detail how they lay out the different components for the app and how their approach would be if they had to start from scratch today.

But it’s these words that makes it clear that they’re very optimistic on the whole future of hybrid apps:

Today’s devices are larger (phones) smaller (tablets), and most importantly more powerful. HTML, CSS and Javascript performance are better than ever, the future looks especially bright for hybrid web apps on the latest versions of iOS and Android. Practical compromises in 2012 might be irrelevant today or in the very near future.

In the post, there’s a link to two very interesting articles — both describing how upcoming versions of both Android and iOS platforms will be more friendly to hybrid applications.

The 9to5mac article mentions:

When iOS 7 launched, developers discovered that their apps with built-in web browsers were unable to achieve the same level of JavaScript performance as the stock Safari app. This was because Apple restricted use of its improved Nitro JavaScript engine to its own app, leaving third-parties with a slower version. As of iOS 8, however, it seems that decision has been reversed. All apps will now be able to use the same improved JavaScript engine that powers Safari. That means Google’s Chrome browser on iOS will now be just as quick as Safari, as will the pop-up browsers ...

more ...

Why Use a Static Site Generator Instead of a Blogging Platform

Static Screen

When I started using Wordpress, I thought it was an awesome solution for blogging. It was easy to install and seemed like by just using plugins, you could augment your blog with a lot of features easily.

That was until I got hacked not only once, but twice. Wordpress and any other database-backed Content Management System suffers from the same security vulnerability: you store the content behind an authorization scheme. There are ways to prevent this (and I even wrote a blog post about it in the previous incarnation of my blog), but the complexity of keeping up to date with all the patches, monitoring bad plugins and other security considerations quickly become pretty overwhelming. The feeling of seeing Viagra ads all over your site is something you don’t easily shake.

There’s also the scalability factor: if your site has a mention on Mashable or Hacker News, you can pretty much kiss your website goodbye, as your infrastructure is not designed to withstand hundreds of visits per second, and unless you have some sort of caching layer enabled (which most small blogs don’t), every page needs to request its content from the database — and that becomes a bottleneck for the serving of your content.

When I decided to launch my blog again, I knew I wanted to do it using the new wave of content serving systems: static site generators.

What is a static site generator?

The idea seems a little bit stange at first. What if instead of generating each post every time the user requests it, we pre-generate all the posts, write them on the filesystem as static HTML/CSS/JavaScript files and folders and then transmit that content to the remote server?

But wait, you must be saying, doesn’t that take a long time? The truth is for most blogs it doesn’t, and unless you have thousands of posts, regenerating a blog with 1,000 posts takes a few seconds for most generators. But the beautiful thing is that once that content is generated, there are no databases to access, your whole ...

more ...

My Blog Reboot

Ctrl Alt Del

For the third time in its history I’ve decided to relaunch my blog. This time around, I have a new approach that I think will allow me to work on it on a consistent basis.

After all this time, I still firmly believe it’s important that we have independent voices and not let the major blog portals own all the conversation.

Blogging is important for me

I’ve felt the need to blog for a long time. There are many excuses to not blog — dozens of more urgent things, work, family obligations. And yet, it’s an important acitivity that allows me to look back and reflect on things that are happening. It also allows me to connect to people who might learn something from what I write or allow me to learn something from the comments that people leave on the posts or through social media.

At the end of 2009 my life was thrown into unexpected waters and I was forced to look for a new job. I eventually joined a startup that required 100% of my waking hours and was heads down for almost 4 years while I worked there. My blog was so unattended that I decided to pull the plug and just point it to an page. I also decided to try one of the new publishing platforms, Medium, to see if it had the same feeling of blogging.

Every time I saw my homepage, my heart would sink. That page was completely not representative of what I wanted to be seen as.

This year I left that startup, and I feel like my life is back in balance. Even though there’s the same amount of work, it does allow me to disconnect when I go home.

Sharing my knowledge

One of the upsides of going through the startup bootcamp that I experienced for the past 4 years was the amount of new things I learned in both the engineering side and the business side. I intend to share that knowledge on this blog in the coming months. I will ...

more ...