Learn How to Hack an App Video Series

Our friends at Arxan,  a company that specializes in mobile payment security and application protection, have shared a list of videos on how applications are hacked.

The first step in defending against mobile application attacks is to see just how easy it is for a hacker to tamper with an application’s code. The “How to Hack an App” video series includes a handful of short clips (1-2 minutes long), each demonstrating how to perform an attack with the use of readily available tools.

  • iTunes Code Encryption Bypass

      • See how easy it is for hackers to bypass iOS encryption to progress a mobile app attack. (Watch Video)
  • Android APK Reverse Engineering

    • Watch how hackers can easily reverse engineer binary code (the executable) back to source code — which is primed for code tampering.  (Watch Video)
  • Algorithm Decompilation and Analysis

    • See how “Hopper” is leveraged to initiate a static, springboard attack for counterfeiting and stealing information.  (Watch Video)
  • Baksmali Code Modification

    • Learn how hackers can easily crack open and disassemble (Baksmali) mobile code.  (Watch Video)
  • Reverse Engineering String Analysis

    • Watch how hackers use strings analysis as a core element for reverse engineering.  (Watch Video)
  • Swizzle with Code Substitution

    • Learn how hackers leverage infected code to attack critical class methods of an application to intercept API calls and execute unauthorized code, leaving no trace with the code reverting back to original form. (Watch Video)
  • Understanding application internal structures and methods via Class Dumps

    • Learn how hackers use this widely available tool to analyze the behavior of an app as a form of reverse engineering and as a springboard to method swizzling.  (Watch Video)

JSApps 101: AngularJS In A Nutshell


Moving on with the topic, in the previous part of this series, we discussed about that interesting new tendency to let the browser do all the user interface heavy-lifting on the client-side, since it is such a good guy. Of course, this involves a LOT of JavaScript going on, since it is the only language the browser understands besides HTML.

We all know how complex and crazy things can get when you involve JavaScript in the picture. The language is usually seen as over-complicated, it used to be hard to debug, learning curve is steep as hell and it can get confusing quickly; also, there used to be a lack of tools and IDEs with strong support for its development just sums up for bad reputation.

However, fear not! After this article, you will have a solid base on how you can turn the fiendish JavaScript you have known for years from a simple DOM traversal helper to a whole reliable application development framework with the aid of AngularJS; man, now THAT’S a catchy name.

What In The World Is AngularJS?

AngularJS is a JavaScript library that allows you to implement the Model-view-controller pattern (in some sort of way) at a client-side level (dude, the browser). Why is this? Because you have two options in life:

  • Option A    You implement a +1000 lines JavaScript source file with a bunch of code that not only is in charge of handling manipulation of the HTML structure and creation of UI components, but also handles all of the data validation and display logic of it, all of this while your fellow teammates start hating the guts out of you.
  • Option B    You be a good developer, who cares about separation of concerns, and split all those tasks in several components where each is in charge of a single thing; those written in separate files for your code maintainability’s sake, while making a lot of friends in the process.

In the good old days, option A was “kind” of affordable (heavy quotations), since JavaScript was used for simple things like adding and removing elements from the HTML structure, changing colors and such. But when we talk about implementing a client application only using JavaScript, option A starts struggling. Mainly because we are not only moving HTML elements around, animating stuff and other user interface tasks; but also performing data validation, error handling and server communications in the client-side.

Of course, option B is the way to go. Since there is a ton of things going on in the browser, we need a way to create components that handle each task separately. This is known as the Separation of Concerns principle, or SOC; which states that your code has to be split in several parts, handling a single task each, orchestrated in order to achieve a common good. And this is where AngularJS shines. It allows you to:

  • Organize your client-side code in a Model-view-controller fashion, so you have separate components where each handles a different task in the logic stack: from user input to server data posting (Don’t worry, we’ll get on this later on.)
  • Live template processing and data-binding; more specifically: munch a template, bind it to specific data coming from the server or anywhere else and then produce a valid HTML piece that can be displayed in the browser.
  • Creation of re-usable user interface components.
  • Implementation of advanced patterns, like dependency injection; which is tied to…
  • Ability to implement unit tests for the JavaScript code.

Client-side Model-View-Whatever

We all know Model-View-Controller (MVC from now on) was conceived for a good reason: Roles and responsibilities matters. It was designed as a practical way to separate all of the front-end logic into three interconnected parts, so code having to do with how data is displayed is clearly separated from the code that validates, stores and retrieves that data. Also, it was thought with unit testing in mind. MVC Flow Now, MVC is commonly used server-side; think of ASP.NET MVC or Spring MVC, where you have a class representing the “controller”, which fetches data into “models” and then binds them to a template producing a “view” in the form of an HTML document, which is returned to the browser for display on the user screen. Remember, each time we talk about MVC, we are generally referring to the Presentation Layer of an application.

Now, why go crazy and MVC-fy my JavaScript code? Well, because what’s trendy right now are dynamic web interfaces where pretty much everything is asynchronous, little post-backs are done to the server unless really necessary and you have complex UI components like pop-ups, multi-level grids and others living on the screen (think of Facebook, for example). The only way to do this is delegate the browser (through JavaScript) with the user-interface composition, interaction between all of the components and lastly fetching and posting data back and forth from the server. You really, really NEED a way to achieve law and order so the client-side code does not become an uncontrollable mess.

OK, enough talk already. Let’s dive into how to implement a simple application using AngularJS.

Hello, Angular

Consider the classic “To-do List” example. We want a screen that displays a list of items to be completed; also we need to show a mini-form that allows us to enter and add new items to the list. Here is how it should look: To-do List UI So, in order to get this done, we need to complete some steps:

  • Create the HTML document which will be representing our view.
  • Include the AngularJS library in the HTML document so we can start creating controllers that will handle behavior of the user interface.
  • Create and include a JavaScript file where we are going to create our application object (wait for it) and define some controllers.
  • Add scope (almost there…) variables and functions that will be bound to the view through special AngularJS HTML attributes.

Basic View Markup

Let’s start this in a natural way: let’s create the user interface first. We will create a file called todolist.html and we will add the following HTML to it:
Now, nothing fancy right there; we just included the AngularJS library at line 8 and another file at line 9, which we will create in a moment. However, just notice the structure of the document: We have an UL element which will represent our list of to-do items and then a couple input controls so we can add new items to the list. It does not have any information on it for now, but eventually it will… And it will be awesome.

Let’s leave this code as it is for now, let’s move to the app.js file which has all the fun going on.

Adding Logic: The Controller

Just by looking at the previous HTML document, you will realize that there are two things we need regarding to view state data:

  • An array to store the to-do items to be displayed in the UL element at line 13.
  • A function to add new items when I click the Add button at line 15.

Simple, right? Well, let’s create a new file called app.js and add the following code; I’ll explain it later:


First things first: let’s take a look at line 1. Before we start building controllers that handle UI logic, we need to create what is known as an AngularJS application module; this is done by calling the angular.module() function and passing it the module name, which returns the created module. This object will later be used as a container where you will store all of the controllers belonging to this particular JS App.

The variable angular is available after we included the AngularJS library in our HTML document at line 8.

After we create the application object, we can start creating controllers; being done in line 3 through the controller() function, which is now callable from the application module we created in line 1. This function takes two arguments: the name of the controller and a callback function that will be responsible of initializing the controller and which will be called each time a controller is instantiated by AngularJS. AngularJS also passes a special variable to that function called $scope; everything that is added to the $scope variable during controller initialization, will be accessible to the view for data binding; better said: it represents what the view can see.

The rest of the lines are quite self-explanatory:

  • Lines 7 to 11 adds a pre-initialized array of to-do items to the scope, that will be used as storage for new items. It represents the items that will be displayed in the empty UL element we have right now.
  • Line 13 declares a variable that will hold the description of new items to be added after the Add button is clicked.
  • Lines 17 to 21 define a function that will add new items to the to-do items array; this should be called each time the Add button is clicked.

Binding The View

Now that we have AngularJS, the application module and the to-do list controller, we are ready to start binding HTML elements in the view to the scope. But before that, we need to change our <html> tag a little and add some special AngularJS attributes:


Notice the ng-app attribute we added to the <html> tag; this is your first contact with one of the several directives that are part of the AngularJS data binding framework.

Directives are simply HTML element markers that are to be processed by the data binding engine. What does ng-app do? Well, it tells AngularJS which application module it should use for this HTML document; you might notice we specified ToDoListApp, which is the one we created in out app.js file at line 1.

After we associate our HTML document with the ToDoListApp, second step is to specify a controller for our view; this is done through the ng-controller directive. The ng-controller directive assigns a controller to a section of the HTML document; in other words, this is how we tell Angular where a view starts and when it ends.

Anyways, modify the <body> tag so it looks like this:


Same with the ng-app directive, the previous code tells AngularJS that everything inside the <body> tag will be governed by the ToDoListController, which we created in our app.js file at line 3.

Now we are ready to start binding elements to members added to the $scope variable during the ToDoListController controller initialization.

The ng-repeat Directive

Let’s start with the empty UL list element. In this case we want to create a new child LI element per item that is contained in the to-do items array. Let’s use the ng-repeat directive for this matter; add the following code inside the UL tags:


OK, hold on tight. The ng-repeat directive will repeat an element per item in an array used as data source; the quoted value represents the iterator expression, which defines the array to be iterated and an alias used to refer the current item being iterated.

In this case, we specified that it should repeat the LI element for all of the items in the items array defined in the $scope variable from line 7 through 11 in the app.js file.

Lastly, inside the LI tags we define an Angular template, which is an expression enclosed in double curly braces that will be compiled dynamically during run-time. In this case, the template is extracting a member named desc from each item and is going to display its value inside the LI tags being repeated.

Go ahead, save your files and open todolist.html in your preferred browser; you will see how the list gets filled. Awesome stuff, huh?

The ng-model Directive

Next in our list is the ng-model directive, which is used to bind the value of an input element, a text box, text area, option list, etc.; to a variable of the $scope. But before I give you more talk, change the input element at line 15:


Binding the value of an element means that each time the value of the input element changes, the variable specified in the ng-model directive will change with that value.

AngularJS enables two-way binding by default, meaning that if the value of the variable the input element is bound to changes, the change will be reflected in the input element on screen. This is the true magic of AngularJS: You can change the value of elements displayed on screen just by modifying values of the $scope variable; no need of selectors, no need to access the DOM from JavaScript, no need of extra code.

In this case, the input element has been bound to the newItemDescription variable of the $scope, defined at line 13 of the app.js file. Each time the value of the input element changes, the variable at the scope will be updated and viceversa.

The ng-click Directive

What if I want to do something when I click that? For that, AngularJS provides a bunch of event handler directives. These directives can be used to invoke functions defined on the $scope each time the user performs an action over an element.

The only one we are going to use for this example is the ng-click, which handles the user click on a button or input element; the expression it takes is basically the code to be executed on each click. In our case, we will modify the button element at line 15 and add the following directive:


If you look closely, we are telling AngularJS to call the addItem function defined in the $scope. If you see the code of that function from line 17 to 21, you will see that it adds a new item to the to-do list array, based on the value of the newItemDescription variable.

If you save your files and open todolist.html, you will see how the list is automatically updated each time you enter a new description in the text box and click on Add.

Your HTML document is dynamic and alive. How cool is that?

What Kind Of Sorcery Is This!?

OK, I must tell you that all of this does not happen through magic. AngularJS is what’s called an unobtrusive library; which means that everything happens automatically as soon as the library finishes loading.

At the very beginning, when the HTML document finished loading, AngularJS crawls through HTML document structure looking for ng-app directives which tells it that something has to be done there. After all of the directives have been found, the marked elements are processed separately: elements are bound to controllers and templates are compiled.

The $scope variable lifetime is automatically handled by AngularJS, each time something happens on-screen, it is notified and performs anything that has to be done to ensure the controller and view are synced; from updating values in the $scope bound to a particular element to refreshing an element or template. This is done through the implementation of some sort of the observable pattern that allows AngularJS to react to changes on elements and the $scope itself.


Woah! That was a bunch of stuff to digest. Hopefully, you will make sense out of it with some practice. Of course those three directives are not everything that there is on AngularJS; for a complete list on all of the possible directives you can use out-of-the-box, take a look here.

Have in mind that you can also extend the library with custom directives, but that is an advanced topic we might cover in a future article.

AngularJS is not everything there is about JS Apps, this was a very basic introduction and I want you to have knowledge you can use in real life, so we will be learning how to build more complex JS Apps in my next article. Topics to be covered will be:

  • Creating custom Angular directives.
  • Complex user interfaces (windows, redirection and data validation.)
  • RequireJS for on-demand asynchronous JavaScript files loading.

Hope that sounds exciting enough for you. Stay tuned! 😀

Source Code

Further Reading

JSApps 101: Introduction To JavaScript Applications


So, JavaScript… Again! After some months away from this blog, I am back with a new series of articles related to the incredible, magical and mysterious world of JavaScript. More specifically, JavaScript applications. Have you ever heard of AngularJS, Backbone, Knockout JS, LESS and such things? Read on, this might interest you.

We have used, at some point of our Internet life, some awesome websites, such as Facebook, Github, Spotify, and others; where everything is asynchronous, the user interface is super-responsive and couldn’t be closer to a desktop application in matters of functionality, all of this right in our browser. Less that some people imagine is that these sites owe their slickness mainly to our good old friend in battle: JavaScript; oh so many developers underestimate JavaScript. This article series will dive you into the basis of how these kind of powerful JavaScript applications are built and over what technologies and frameworks, so let’s move forward into some basic concepts.

Server-side v.s. Client-side

So, what in the world is a JavaScript application anyways? Well, as you might know, the traditional way a web application works is that you have a set of specialized frameworks and tools (name it ASP.NET, PHP, Spring Framework) running server-side; when someone requests a page from the server, it responds with an HTML document, usually resulting of the parsing of a server-side template (a PHP, ASPX or the alike) and then bound to data coming from the database. Those templates being processed by the server usually contain special syntax and directives that instructs the server’s templating engine how to bind data to it and produce a valid HTML document; some might recall these as the dreaded “server tags.”

Standard Server Request/Response


Some server-side technologies like ASP.NET use “controls” or helpers that assist in the rendering of complex user interface components into HTML like grids, forms and charts bound to dynamic data coming from the database. Each time these components need to be refreshed, they do it through asynchronous AJAX requests or a full-page refresh (known as a server post-back, which all users love, or not). While these are handy for speed-building of web solutions, is not as efficient as pure-JavaScript graphical components.

ASP.NET WebControls

Often, JavaScript is used to manipulate the structure of the resulting HTML document, get the value of a field, and other simple tasks dynamically on the browser (better known as “the client side”) without the need of refreshing the page. But as popularity of JavaScript arise (let’s thank jQuery for that), it is being delegated with more and more complex stuff like rendering templates into HTML, so it is done client-side and not server-side; binding of server data, validation of user input and controlling page flow. This being said, a JavaScript application is basically a “client” that runs on the browser, thanks to the leverage of technologies such as JavaScript, HTML5 and CSS3. All of the UI logic is controlled client-side, right there in the browser.

Structure of a JavaScript App

Before moving on, it is true that this requires a paradigm shift if you have been working on traditional web applications for a while, specially if you have never used a Model-View-Controller approach. If you have never heard of, or used Model-View-Controller, I’m afraid there is some reading to be done before continuing. But hey! You can start here, or else you can continue reading this incredibly sexy article.

As mentioned before, a JavaScript application, or JS App (patent pending), usually follows an MVC approach. It is composed of several “views”, which are usually HTML documents or templates; “controllers” that handles validation, logic flow and communications with the server; and “models” that contains the data to be displayed and bind on the views. As you might notice, is a pretty similar model to server-side technologies like ASP.NET MVC and Spring MVC, just that the entire presentation layer is being moved to the browser, specifically into JavaScript components. We’ll analyze advantages of this later on.

With all the presentation logic being handled by the browser, where does the data we see on the UI coming from? It comes from the server; that is the real use we have for it. The controller at the browser is the one responsible for this channel of communication; it retrieves data from the server each time the user pages through a data grid and sends data to it whenever the user needs to create or edit information. JS Apps work in a similar way to smartphone apps, in which a client runs on the phone locally and it uses data coming from a remote server. In fact, there are specialized build tools, like PhoneGap, that creates applications to be installed on a smartphone from HTML/JS/CSS3 sources.

JS App Structure

Pros & Cons

While JS Apps goes far off any conventional use of a browser, it offers several advantages:

  • Rendering of pages and templates is done by the browser in the client computer, taking advantage of the client computer’s processing power and leaving less workload on the server.
  • Better user interface responsiveness, since all calls to the server are asynchronously and JavaScript UI components are usually lightweight.
  • Completely decoupled from the server logic.
  • Less calls to the server, since it is only accessed to get data and not pages in every possible display state it might have.
  • High separation of concerns, since the server ONLY handles business logic and not UI-related validation and such.
  • Easy unit testing of the user interface and UI logic.

Also, it might represent some disadvantages:

  • Lots, lots and LOTS of JavaScript to be written; we all know it can be a pain to maintain if not properly done.
  • The learning curve is quite step, since most people is used to jQuery and DOM manipulation but not to JavaScript controllers, models and pseudo-classes; let alone advanced concepts like JavaScript dependency injection.
  • Data incoming to the server needs to be double-checked in order to prevent bad information sent by tampered JavaScript components.

Sounds Kind of Interesting, Now What?

OK, now that you might get the picture of what a JS App might look like and its advantages, so the next step would be to analyze the technologies and frameworks you could use, getting your hands dirty along the way so you can start developing this kind of applications.

In the following articles we will move into learning JavaScript libraries like AngularJS, for client-side Model-View-Controller; RequireJS, a library that allows asynchronous loading of JavaScript files on-demand; usage of Twitter Bootstrap, to build nice HTML5-compliant user interfaces; and ultimately how to structure your server application as a solid data provider for your JavaScript application.

So, stay tuned for more articles! 😀


JavaScript For Regular Guys (Part 1)


So, JavaScript. That thing that makes AJAX, dynamic HTML and other fancy stuff possible. We know it exists somewhere deep on the browser. But what is it exactly? How does it work anyways? And even more important: How in the world do you even code for it?

Okay, reader. If you have any of those questions, today is your lucky day. We are going to find out the answers for them.

Some Background

Like every exciting article, we will be starting with some history. So, JavaScript was born with Netscape browsers about 18 years ago. It was first shipped with Netscape version 2 as a feature that would allow web pages to run scripted content on the browser right in the user computer. Its original name was Mocha, then it changed to LiveScript and finally ended up as JavaScript (JS). Wow, that’s what I call name evolution.

How Does It Work?

JavaScript is contained either on individual *.js files that are referenced by the web page or one or more inline HTML <script> blocks coded deep inside the HTML structure. The browser then interprets (that’s right, JavaScript is an interpreted language) all code on referenced files and <script> blocks by using its own JavaScript runtime and executes the code in the web page when load is complete.

To include JS files on a web page we would have to add <src="../file.js" /> tags for each file. The other way is to include JavaScript code inline inside a script block:

<script type="text/javascript" language="text/javascript">
    function doSomething() {
        alert("Something happened!");

It is recommended that these blocks are right after the last HTML tag before the <body> tag on the page to improve loading times. Always remember that JavaScript is a functional scripting language. It executes all code in a file or script block from top to bottom sequentially. For example, the script above won’t do anything since we are never calling the function anywhere. So, we would have to do something like:

<script type="text/javascript" language="text/javascript">
    function doSomething() {
        alert("Something happened!");


The Domain Object Model (DOM)

JavaScript goes tight with the HTML structure of the page it is executed on. JavaScript sees all the HTML document structure as an HTML element tree called the DOM. This allows us to manipulate the document structure on runtime by referencing its DOM elements and change things as needed. For example, to change color of a paragraph 2 seconds after the page has loaded, we can use the following code:

<p id="target">Test paragraph...</p>

<script type="text/javascript" language="text/javascript">
    setTimeout(function() {
        var target = document.getElementById('target');
        target.style.color = '#00FF00';
    }, 2000);

By examining the previous code, we can see the use of the setTimeout function. JavaScript comes with a set of pre-defined global functions that don’t come from any object. They just can be used anywhere. No, literally ANYWHERE. If you come from a formal language like C# or Java, you know that, at some point, you’ll need to include namespaces or packages so your code can use things defined somewhere else. Yeah well, with JavaScript this is not the case. Global functions are auto-magically imported by the browser itself.

In the case of the setTimeout function, it takes two parameters: the first is a function that will execute after a specified amount of milliseconds; specified by the second parameter. The function we specified as the first parameter is what we know as an “anonymous function”. We call it “anonymous” because it has no name. Really? Yes, really. But you can assign a name to it if you want:

<script type="text/javascript" language="text/javascript">
    function colorChanger() {
        var target = document.getElementById('target');
        target.style.color = '#00FF00';

    setTimeout(colorChanger, 2000);

It now has a name. But we can still use it as a variable and pass it as first parameter of the setTimeout function. Dammit, JavaScript!

Anyways, we slipped a little from the whole DOM topic. The important thing you gotta remember is that the global document variable can be used to retrieve HTML elements by ID (you already got the idea of what the DOM is all about). After we have the element on a JavaScript variable, we can change its attributes, move it somewhere else on the tree or even just delete the crap out of it à la Godfather.

JavaScript Has No Class

Even tough JavaScript is one of the most popular and used languages in the world, is not anything close to any other language you might have seen before. It is functional, dynamic weakly-typed and totally random at some points. Is like taking all programming languages known to mankind and mash them together in one single surprise-pack. Seriously, it gets a little crazy sometimes.

For instance, even though it has weakly-typed dynamic variables and other sorts of neat things, it has no formal way of defining classes. However, as the languages evolved from old computers into 21st century, a way to do something like Object-oriented Programming had to be on JavaScript by its first release. So, guys at ECMA had a dialogue, at some point while writing the first language specification, back in year 97′, that goes a little something like this:

  • Dude 1: “Dude, JavaScript is cool so far and everything but everyone is using something called Object-oriented something something.”
  • Dude 2: “Damn, kids these days. Let’s just allow functions to contain variables and other functions. Voilà. We got classes.”
  • Dude 1: “That sounds like is going to confuse lots of people… D:”
  • Dude 2: “Meh. Not really.”
  • Dude 1: “But…”
  • Dude 2: “NOT REALLY, I SAID!”

Okay maybe it was not like that but, since then, we have like four or five different ways to define something like classes. The one I like the most is as follows:

<script type="text/javascript" language="text/javascript">
    function CarFactory() {
        var carsProduced = 0; // Private variable

        this.name = 'Car Factory'; // Public variable

        this.getCarsProduced = new function() { // Public getter
            return carsProduced;

        this.createCar = function() { // Public function

        function showCarProductionMessage() { // Private function
            alert("A car was produced.");

    var carFactory = new CarFactory();

    alert("Factory name: " + carFactory.name);


    alert("Cars produced so far: " + carFactory.getCarsProduced());

How pretty does that looks? So, a function can also be a class definition with private members and all, just like any object-oriented language. This is known as prototyping.

Hopefully, the example is clear enough. I have a couple of things to clarify though. JavaScript, while trying to be object-oriented, is still a scripted language; never forget that. So, if you put the class definition after you use it, you’ll get a nice error complaining about the use of an undefined type since the interpreter has not yet seen the class prototype definition as it is after the code trying to use it. Also, look at the use of the keyword this. Things are just starting to get more and more interesting for sure.

The “this” Keyword

If you have worked with classes before, surely you’ll recognize the this keyword. This magical keyword often refers to the class where the current method using it is defined. Well, in JavaScript (once again screwing up with our brains) the this keyword refers to the function owner and can refer to several things depending on the scope it is used:

This Keyword Scope Conventions

Now you see how tightly coupled JavaScript is with the DOM tree. The default owner for all scripts is the global window DOM element.

Now, you can see the last two usages in the table involve the use of the call() and apply() functions. These functions are useful if we would like to change the value this refers to. That would be your homework: Check the use of call() and apply().


So, we have reviewed how JavaScript was conceived and how it is structured. This is essential in order to understand more complex examples like DOM element events and asynchronous server calls and of course– server-side JavaScript; which we will be examining with more care on future articles.

Stay tuned! 😉

BackCountry Hackathon 2012: Informatech Wins API Category

A little late to be sure but no less significant, given that I wanted to write about this at the same time.

On September 22-23, Adriana Jara, Johan Rodríguez and myself participated in the first-ever BackCountry Hackathon 2012. Here we are at the beginning of the event.

What we did

Adriana had the fantastic idea of using the competition APIs to build a comment and review search engine, and thus Community Mining was born.

The APIs gave us data in JSON, so using a proxy webserver we queried the data and in JavaScript analyzed, graphed, and displayed the results.

Our tech stack included:

  • Tomcat 7
  • jQuery & jQuery UI
  • YUI Grids
  • Raphaël Vector Library
  • Lots of JavaScript code

We completed the main feature set about an hour before the deadline, and our app proudly ran in desktop, smartphone and tablet browsers.

What does it look like? Well here you go:

What was learned

Speaking from a strictly personal perspective, I have to say that after the rush of more than 36 hours of work, and the pride of feeling “I still got it”, wore off. The main takeaway was: you have to choose your team well.

Your teammates must be talented. Sometimes, less people is actually better, as it allows easier coordination (that was the case here). And very importantly you have to trust the people next to you not to blow up when the stress is high. Adriana and Johan certainly fit the bill.

All in all good fun.

– Michael Holst

Ruby on Windows, Now Easier

Update: link fixed

“It’s no secret that the Ruby community has been slow to welcome Windows users into our world. Projects like Instant Rails were a great start, but have long since been abandoned. For the continued momentum of Ruby, Windows users need the ease of setup and use that all the rest of us have long enjoyed.”