Back to the Future

"Back to the Future" is what I'm feeling now regarding software development after moving to San Francisco.   It is not (only) because of the environment or the people but because I'm back to develop low level components in C++ after some years developing high level services on fancy languages.

I think the main reason behind the good feelings apart from the change itself is the challenging it is to develop in such environment.

Working on low level components makes you worried about a lot of technical issues that I didn't remember paying to much attention to.   I've been testing multiple FIFO queues implementations to improve the performance, profiling the application to detect contention on different synchronization strategies, testing different thread allocation and tasks assignment to those tasks, changing memory allocation...  You feel that the way you implement the software has a big impact in the way it performs and in addition you are continuously being surprised by the results of some of the tests and continuously willing to explore new things that you had never been done before.

Working with lower level programming languages like C++ makes you feel that you are under full control, everything that happens is your fault or is thanks to you.   If the application takes a long time to start is because of you and not because of the JVM, if there is a lot of contention is because of you and not because of the GIL, if the application takes a lot of memory is because of you and not because garbage collector....  Of course great power brings great responsibility, but that responsibility makes everything much more funny.

The only thing I'm still hating about the "new" development environment is having to compile.   If I could get rid of that I would be more than happy.... at least for some months/years :-)

Love to Code?

Just saw a facebook advertisemet with the title "Love to Code?" and couldn't resist the temptation to click on it.   It ended up being a door to facebook recruitement process and I decided to spend some minutes to try to get more information on how their process is.

After clicking the ad you are redirected to a very interesting tool from an external company called InterviewStreet who asked me to solve a simple programming problem in less than an hour in any programming language.

The problem was a slightly modified version of the game of life problem where the pieces at the boundaries never change and I decided to solve it in python. I was slightly disappointed because I was really expecting something more difficult (Tuenti contest problems are more difficult for example).

I was able to finish it in the 1h timeframe but didn't pay too much attention to write a great code so they won't probably call me :-)    Find my code below in case somebody wants to improve it.

#Enter your code here. Read input from STDIN. Print output to STDOUT

#For more details, please check http://www.interviewstreet.com/recruit/challenges/faq/view#stdio

def solve(board, size):

  result = [list(row) for row in board]

  pos = [(-1, -1),(-1, 0),(-1, 1),(0, -1),(0, 0),(0, 1),(1, -1),(1, 0),(1, 1)]

  for y in range(1, size-1):

    for x in range(1, size-1):

      blacks = whites = 0

      for dx,dy in pos:

        if 0 <= y+dy < size and 0 <= x+dx < size:

          if board[y+dy][x+dx] == 'b':

            blacks += 1

          else:

            whites += 1

      result[y][x] = ('b' if blacks > whites else 'w')

  return [''.join(row) for row in result]

tests = raw_input()

for test in range(int(tests)):

  #read input

  size, iters = raw_input().split(' ')

  board = [''] * int(size)

  for i in range(int(size)):

    board[i] = raw_input()

  #calculate

  for i in range(int(iters)):

    board = solve(board, int(size))

  #write result

  print "Board %d" % (test+1)

  for row in board:

    print row

Comparing YUI vs jQuery for simple tasks

Most of the people agree on the fact that using jQuery is not enough to build complex web apps.   When building one of those apps with jQuery you will probably end up including additional libraries and tools for logging, widgets, graphs, MVC infrastructure, history tracking, unit testing, minification... or moving to a different framework like dojo, YUI or ExtJS.

So, we can not create complex apps just with jQuery, but on the other side... Should we create simple apps with those bigger frameworks?  Are they really imposing a performance overhead and making much more complex to implement simple tasks?

To answer that question I tried to implement three typical use cases of simple apps with jQuery and YUI to compare the code produced.  Those typical use cases are 1) Attaching event handlers, 2) Modifying the DOM and 3) Making async HTTP requests.

1) Attaching event handlers (f.e. to catch a click event)

jQuery: $(selector).click(function() { });
YUI: Y.one(selector).on('click', function() { });

Conclusion: YUI slightly more verbose (but Y.one could be aliased as $ and the syntax is the same with both libraries in case of using event delegation). Result: tie

2) Modifying DOM (f.e. to show a div)

jQuery: $(selector).show();
YUI: Y.one(selector).show();

Conclusion: Identical (at least for this example).  Result: tie

3) Making async HTTP requests

jQuery: $.post(url, function() {} );
YUI: Y.io(url, { method: 'POST', { on: { success: function() { }} } )

Conclusion: YUI slightly more verbose.  I'm also missing deferreds support in YUI.  Result: jQuery wins

* Selectors are pretty similar and didn't find relevant differences in the support included in jQuery and YUI

Regarding the size of the library, some quick information without too much investigation (minified but without considering compression):

jQuery 1.7.1: 90KB
YUI min (limited but allows deferred loading of rest of yui components): 70KB
YUI min + dom + events + animations + io (equivalent to jquery?): 150KB

Disclaimer: I'm not an expert on YUI, comments and corrections are more welcomed

C++ MACRO Nightmare

This afternoon I was implementing a typical circular buffer including some lines like this to make the pointers go from the end of the buffer to the beginning again when needed.

_bufferReadPos = (_bufferReadPos + len) % BUFFER_SIZE;

When testing the code I started to see very weird values of the read and write pointers, in fact much bigger than expected.

After at least 10 minutes trying to debug the problem I realized that it was because of the expansion of the BUFFER_SIZE macro that was:

#define BUFFER_SIZE 32*1024

% Has precedence over * and my code was been interpreted as:

_bufferReadPos = ((_bufferReadPos + len) % 32) * 1024;

Very sad and not easy to catch.  My solution has been using parenthesis in the BUFFER_SIZE definition to avoid it being split again when being part of the previous line:

#define BUFFER_SIZE (32*1024)

Do you have similar nightmare stories with macros?!

Creating "REST" APIs with django

I've been trying to implement an API for our service with some django based frameworks for the last week and to be honest the experience hasn't been as placent as I expected.

These are the frameworks that I evaluated and the reasons that made me get away or make use of them:

• piston: the project looks abandoned and it is not compatible with latest django version (because of automatic csrf checks).  It seems to be very used with hundreds of forks but none of them convinced me.   Its strongest points are OAuth support and being used for the bitbucket API.

• tastypie: the project is actively maintained and looks very nice but I had some problems as soon as I tried to implement things a bit different than usual.  I didn't like the concept of hydrating/dehydrating objects. In addition it has some external dependencies and I didn't like very much the way it is coded when I looked at the source code.

• djangorestframework: it looks less featured but simpler and actively maintained.   It also took me some time to implement things that were a bit different from the usual use case, but it was finally my choice.  It source code is clean and easy to understand.

During this evaluation process I also found this table with info about different  implementations that could be useful.   There are also a lot of stackoverflow questions about this issue.

Android target sdk vs min sdk versions

An android project has two important properties in its manifest: target sdk version and min sdk version.  If you use eclipse to develop those properties are requested by the new android project wizard during the setup of the project.  I've never been completely sure of the meaning of both properties and I would try to clarify it in this post for all the people that could face the same doubt in the future.

• min sdk version is the minimun version required for the application to run.  If the device hasn't an android version equals or bigger than min-sdk version the application can not be installed in the device.
• target sdk is the version used to build the application binary during development.  This property has two different purpouses or implications:
• Android APIs that can be used.   If target version is bigger than min-sdk version you can use new APIs supported in versions until target version (always taking care of checking if that feature is supported in the android version where the application is running because it could be running in a min-sdk device not supporting that feature).
• Android optimizations that will be applied to your application during execution.   You inform android that you have tested your application with target-sdk versions and it hasn't to make under the hoode any optimization intended for old applications.

There is also a max-sdk version property but its use is discouraged in android documentation.

[1] Android Reference: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

Playing with Backbone.js Views inheritance

One common requirement for big javascript applications is being able to create reusable and extensible visual components (Views in backbone).  The most natural way to achieve this extensibility goal in an OOP environment is to take advantage of inheritance capabilities available in javascript [1]. 

For example in my projects I usually create a PopupView class implementing the funcionality shared by all the popups (close button, resizing, modelness...) and then I create a XXXXPopupView class for each type of popup in my application.

I didn't find any documentation on how to implement this pattern with Backbone.js, and I've been playing with two different approaches to get it.

Proposal 1. Extending events property (doesn't require any change in backbone)

    var ViewClass = Backbone.View.extend({
      el: $("body"),
      events: {
        "click": "click"
      },
      click: function() {
      }
    });
    var SubviewClass = ViewClass.extend({
      events: _.extend({
        "dblclick": "dblclick"
      }, ViewClass.prototype.events),
      dblclick: function() {
      }
    });

    var view = new SubviewClass;

We have to admit that the resulting code could be nicer.

Proposal 2. Changing Backbone events declaration
Making some little changes in backbone.js you can get a simpler solution, although it also has some potential drawbacks.  I forked it in github to publish these changes [2].

    var ViewClass = Backbone.View.extend({
      el: $("body"),
      "click": function() {
      }
    });
    var SubviewClass = ViewClass.extend({
      "dblclick": function() {
      }
    });

    var view = new SubviewClass;

In this case the resulting code is much cleaner, although it requires the implementation in backbone.js of some heuristics in the views to differentiate the event declarations from other properties in the object.

I included some unit testing and also confirmed that all the existing backbone tests weren't broken, but I would be glad to receive any comments proposing better solutions to implement View inherintance.

[1] http://jupiterjs.com/news/writing-the-perfect-jquery-plugin
[2] https://github.com/ggarber/backbone