Orestes Carracedo

Scrum Master, PHP Ninja, cat owner

3 posts archived under programming.

14 January 2015

I've been entering Facebook's Hacker Cup for a few years now. Some years I've gotten past a couple of rounds, others I haven't done so well. Anyways, I really like participating and I decided to share my setup.

I use the same structure for every problem so I can be more efficient. Every problem:

  • Is in a directory named using the point value and the problem name, like 30 Balanced smileys.
  • Contains a readme file with the full description of the problem.
  • Contains an example directory with the input and output files provided in the problem description.
  • The data directory contains the generated input provided for the submission.
  • The generated directory contains the output generated for the submission.

The tight loop

I'm using the simplest quickest feedback loop I could come up with:

  1. Run the program piping in the input from the example file and piping out the output to an output file.
  2. Diff the generated output file against the expected output file.
  3. Repeat

An example using php:

watch -n 1 "php solve.php < example/input.txt > output.txt && diff example/output.txt output.txt"

Using python:

watch -n 1 "python solve.py < example/input.txt > output.txt && diff example/output.txt output.txt"

I usually have this running in a session, and code in a different one. I like running the code very second and not relying on file watchers

What I often do wrong

This time I entered the qualifying round the last day. I ignored my calendar events for the day when I shouldn't. As a result, I entered the round feeling in a hurry and didn't concentrate as much as I should've.

In past editions I've overlooked the constraints and tested the code using simple scenarios. The problem comes when the generated input hits the constraint limits and my code is not optimized at all, taking a lot of time to perform the calculations and making me fail the problem.

Another mistake I made was preparing only one problem. Chances are I'm going to be fail to think about every scenario and fail the problem. Solving (or at least trying to) all the round's problems should always be the way to participate.

Links:

Categories: programming
Comments: --
21 July 2013

It was 2010 when we got some projects at Focus On Emotions from Ikea. Among the challenging stuff we did for them there was a project for automating the process of the users registering for a credit card. The final product was a digital user stall/kiosk with an interactive touch screen a physical keyboard and mouse. This project needed a couple of tricky features: ID verification and bank authorization.

This was not our first rodeo and we had another public kiosk/stall project for the city hall, Ajuntament de Barcelona which allow citizens to do paperwork. They were challenging because we had to integrate lots of different providers, but we didn't manage any banking data so this was new to us. These projects had been running smoothly for years and we've got some recognition from them.

A couple of weeks after the project's launch we had gotten many reports of users being disoriented when following the process. One of the steps required the users to physically place their ID form on a small flatbed scanner for validation. Even though the physical space was an obvious empty box the users didn't realise that was where they were supposed to place their ID.

The client asked us to modify the kiosk structure, add a LED stripe around the empty box and have it blink when the users got to the ID validation step. We had to give it a little thought before coming up with a solution because we had a tricky problem: hardware access was impossible. The whole application was written in Java, HTML and JavaScript,and it ran as a served web app inside a secured environment using SiteKiosk. This was great for pushing software changes to the multiple kiosks installed for the project as well as for interacting with the bank's backoffice services in a secured environment (server-side). The manufacturer for the ID scanner had provided the dev team with an API that used ActiveX and JavaScript to control their hardware, so we followed that idea: we had to develop our own ActiveX control to activate the LED stripe whenever we needed to.

We bought a simple relay board with an USB interface and started working on it. This relay board was great because it had two different relays that you could control independently. Each relay had a tiny onboard LED indicating its state. You can find it on RobotShop, here.

I got a hold of the controller's specification [mirror] and wrote a simple program to control it over USB by sending the byte-encoded messages for each action (open/close relay 1/2). It consisted of a minimal Windows Forms interface with a few buttons to open/close the USB port and switching on/off the relays. When I was sure I could make it work, I wrote a small function library and compiled it as an ActiveX:
csc /t:library USBLEDControllerLib.cs
To make it available for Internet Explorer, the DLL had to be registered:
regasm /tlb /codebase USBLEDControllerLib.dll
Both regasm and csc are provided by .NET Framework 2. in my case, It was already installed on %WINDIR%\Microsoft.NET\Framework

To invoke the ActiveX control we use the full classname, including namespace.

var controller = new ActiveXObject("FOE.USBLEDControllerLib");
var version = controller.getFirmwareVersion();
console.log('Running FOE USB LED Controller version ' + version);

The simple ActiveX control would trigger a security warning on IE. We suppressed this warning by implementing a few visible COM methods flagged as [Serializable, ComVisible(true)] which come from the IObjectSafety interface. This told IE it could trust our library.

The controller for the board had a limited set of functions so we had to extend them for our project. I added a couple of threaded functions to start/stop blinking the LEDs synchronously, stopping/starting only one of them and have the other synchronize on start, etc... Even though we had very little time and a lot of pressure I think it was a fun project. You can see the PoC in the video below. You click a button on a webpage and a LED lights up. Neat! I love the clicking sound from the relays, so mechanical :D

Links:

Categories: programming project videos
Comments: --
18 December 2011

I just read an excelent article by Swizec Teller about the reasons some programmers do their best work late at night.

I couldn't agree more with the author. The past year I stayed late at the office a lot of times doing a lot of good work. This year not so much because my girlfriend moved in with me, so I've gotten some rest from that but I kind of miss it too. When we were working on Aura, we would work until very late and wake up for lunch almost every day.

Link: Why programmers work at night

Categories: programming
Comments: --