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?!