Orestes Carracedo

Scrum Master, PHP Ninja, cat owner

5 posts tagged as 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: --
09 June 2013

Besides my writing skills, my problem with blogging was the software I was using, Wordpress. I found it slow, heavy and often insecure. I didn’t want my server exploding whenever I got a traffic spike, I didn’t want upgrading my WP modules and being worried about security issues. It was kind of hard to get it to look the way I wanted it. I wrote a custom theme but I wasn’t really satisfied with it, so I bought a one which looked cool, but I still wasn’t happy with my blog because it wasn’t “mine”.

I wanted a static blog website that I could code and style the way I wanted, without restrictions. I wouldn’t have to worry about security since it would be static and would have no user input, search or comment features. I didn’t want to give up comments so I checked Disqus, whichs a really good commenting platform that you can embed anywhere without having to worry about security or performance issues. Disqus is a seamless iframe whith a lot of clever programming inside. Ben Vinegar, gave a great talk about it in 2012: Seamless iframes: The future, today!.

Regarding the traffic spikes and server resources, I decided I’d move the blog out of my lab hosting (which is a tiny virtual machine) into somewhere that could serve static sites and I only had to worry about bandwith costs,

I started researching about scaffolding tools and generators for static websites. I had used stuff like yeoman that worked reat for getting something started quickly, but it was more aimed at apps than static websites and I’d still have to do a lot of the work.

Then I found about GitHub Pages and Jekyll, and they turned out to be the perfect solution for me. Jekyll is a blog-aware static website generator written in Ruby by Tom Preston-Werner. It’s easy to get started with and powerful enough to let you add your own plugins and teach it new tricks. GitHub Pages allows you to serve static content from your GitHub repositories without any setup

The pros Jekyll on GitHub Pages

  • It’s already blog-aware, so it has a notion of posts, categories, tags and a timeline.
  • I can version my posts and contents using a CVS I love (git)
  • I can easily share the source code for my blog
  • I don’t have to worry about hosting
  • I can still use any domain name I own
  • It provides higher geek factor than having a WP blog

The cons

  • GitHub crashes every once in a while and maybe GH Pages comes down with it
Working with GitHub Pages

GitHub Pages are divided into user pages and project pages. The only thing you have to do is create a gh-pages branch on your repository. Whatever you push to the branch will be served on your project page at http://username.github.com/repository-name. If you push a Jekyll site, GitHub Pages will actually build the site for you and serve that instead of the Jekyll source.

Working with Jekyll

You create a new site running jekyll new PATH which creates a bare minimum site config and layouts.

To create the extra tag and category index, as well as the archived month pages, I had to extend the same classes: Jekyll::Page and Jekyll:Generator. The method is pretty straightforward:

  1. Create a class that inherits from Jekyll:Page
  2. In the page class, implement the initialise method
  3. In the initialise method, call self.process(@name) and self.read_yaml to get the contents of the layout
  4. Add to the site.data Hash any data you want to expose to the page
  5. Create a class that inherits from Jekyll:Generator
  6. Implement the generate(site) method which adds instances of the custom page to the site.pages Array

I generated the monthly archive by iterating over the site.posts Array and analysing the dates. To generate the sidebar menu that displays the year/month list I needed to have an index to iterate over, so I coded my plugin archive_helper. What I did was:

  1. Inherit from Jekyll::Site,
  2. Made an alias of the original site_payload
  3. In my site_payload method, called the original site_payload and get the returned data.
  4. Added to site.data Hash the indexes created from the posts’ dates.

The plugins to generate the tag and a category pages were already provided in the Jekyll plugin docs so I didn’t need to do any extra work.

You can get the source code for my plugins and all of this blog here

Deploying the site

The problem I had with my plugins is that GitHub pages builds the Jekyll sites using the --safe switch, which disables them. The alternative is to push your source code to the master branch and your generated site files to the gh-pages branch. I didn’t want to do it manually every time I updated the source, so I wrote a little post-commit hook that generates the site, wipes the gh-pages branch and pushes the freshly generated site to the gh-pages branch.

Using a custom domain name

Everything gets served from http://username.github.com/repository-name. Having a good grasp of the HTTP protocol is crucial for a web developer, and I think we should also know at least a little about the DNS protocol. I wanted to host my blog under blog.orestes.io, so I got to my DNS panel on my domain registrar and added a new CNAME DNS entry for orestes.io with the name was blog and the value orestes.github.com. A CNAME is a Canonical Name entry, which tells DNS clients asking where blog.orestes.io is, to ask instead for orestes.github.io.

Let’s check what’s going on with my domain name using nslookup.

$ nslookup blog.orestes.io
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
blog.orestes.io	canonical name = orestes.github.io.
orestes.github.io	canonical name = github.map.fastly.net.
Name:	github.map.fastly.net
Address: 103.245.223.196

On the output above you can see how everything is being redirected to github.map.fastly.net

When you finally get to the HTTP server behind github.map.fastly.net, it checks the HTTP 1.1 “Host” header, which is sent by the browser and will contain the value blog.orestes.io. Then the GH Pages takes a look under the user’s projects and their /CNAME files to check if any of this projects is assigned to this domain. If there is, you get the static site, if there isn’t, a 404 error.

Links:

Categories: technologies code
Comments: --
17 November 2012

Programmer Swizec Teller and author of the (now) famous blog post "Why programmers work at night" has started a project on Leanpub to publish a book about programmers.

[...] In December 2011 I wrote down a bunch of assumptions about Why programmers work at night (link) in a blogpost. I wrote it because I got tired of being called a lazy slob for waking up at 11am every day. After 4000 tweets, 10000 likes and many emails I didn't feel alone anymore. The most surprising feedback were emails along the lines of "Oh man! I finally understand my husband, thanks so much for writing this!". And it is because of those that I have finally decided to write a short ebook. In the book I'm going to:
  • Show fellow night-time programmers (and others!) that they are not alone
  • Give practical tips on living with your friendly neighborhood programmer
  • Support my original hypotheses by interviewing cool programmers
  • Explore the modern trend of super early wakeruppers who approach the night time from the other end

So if you're a programmer that feels missunderstood on your late nights of happy coding, maybe this book will be an ideal gift for your roomies, girlfriend, boyfriend, parents or even for your boss.

Link: Why programmers work at night: the book
Categories: books
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: --