Duck in computer jargon

I've been struck by how often we, developers, use the word duck in our jargon. Here is a little list of the usages that came from the top of my mind.

Duck Typing

This might be the more common usage. It comes from the saying that, if it quacks like a duck, it is probably a duck. I've mostly encountered it in the Ruby ecosystem, where you don't really care about which class an object belongs to, as long as it answers your calls to a specific method.

class Duck
  def quack
    puts "Quaaaaack!"
  end
end

class NotReallyADuckButIDontCare
  def quack
    puts "Coin-Coin!"
  end
end

Duck.new().quack # Quaaaaack
NotReallyADuckButIDontCare.new().quack # Coin-Coin!

This is quite useful when iterating over collections of similar-but-yet-different objects and wanting to call a specific method on each of them, when every object implements it slightly differently.

Duck Feature

That's the name we use for a feature in a project who adds absolutely no value, and we know it will never make it to the final product. But we keep it because we know that at some point, either the marketing departement or the management departement will feel the urge to ask us to change something to our product. And when that moment arise, we just remove the duck feature to please them.

This one, allegedly, come from the good old days of Interplay, when they were developing Battle Chess. The animation artist did a very great job at animating one of the pieces and was very proud of his job. But he knew that someone will have something to say about it and ask him to change something (just because they could). So he added a little duck, walking side-by-side with the Queen. As expected, he was asked to remove the duck, which he did, without altering the real Queen animation.

Rubber Duck Debugging

How many times have we been stuck on a problem for minutes or hours, and finally asking a colleague for help, or posting a question on StackOverflow ? And when writing our question, or exposing our problem to our colleague, the solution came right at us, clear as day.

That's because we were so focused on the issue, that we did not take the time to reassess why we needed to do it, and most of the time, we just discovered that we actually had no issue to fix at all.

So next time, instead of disturbing a colleage, try talking to yourself, or even better, to a rubber duck, explaining your issue, and you might find the answer simply by explaining the problem.

Canary Release

You might have heard of Chrome Canary. This is the next Chrome official release, but available sooner, for front-end developers. This allow developers to test new features and API earlier, and report bugs, so the official release will be more polished. This can also be applied to full architecture deployment, when you're running the old and new versions in parallel, but only a selected few are using the new platform at first.

But why is it named Canary ? Well, it comes from the old coal mines, where miners where carriying crates of small canaries to test for poisonous gases. The analogy is the same, we first test on a small subset of users, and if everything is working fine, we'll deploy to everybody.

Any others ?

The duck jargon seems to be used a lot in programming and I'm sure there are other instances that I'm not aware of. I'll update this post whenever I'll encounter a new one.

This blog now has an API

An API, really ?

Well, sort of.

All posts can now be accessed in a json format (just replace the final / with a .json). This is obviously a read-only API.

For example, my previous post is accessible in json format here.

{
  "id": "/2014/12/27/past-and-future-objectives",
  "title": "2014 learnings and 2015 objectives",
  "url": "http://blog.pixelastic.com/2014/12/27/past-and-future-objectives/",
  "tags": [],
  "date": "2014-12-27 00:00:00 +0100",
  "html": "<p>This is the end of the year, and I do realize now that [...]",
  "markdown": "This is the end of the year, and I do realize now that [...]"
}

It currently exposes the initial text in markdown as well as the formatted HTML text, along with some metadata (id, url, date and tags).

I had a need to have my post in json format for processing them through Grunt, so I thought I might as well expose them publicly. I'm not sure people will ever use it, but at least it does exist !

How was it done ?

Jekyll lets you plug custom made scripts to be called in the generation process in an aptly named _plugins directory. I just had to create a json.rb file that will take every post and create a new json page from them, using a very minimalistic post.json layout.

All I had to do was build the custom object I wanted to return, which was a mix of generated content, and metadata.

2014 learnings and 2015 objectives

This is the end of the year, and I do realize now that I learned and did a lot this year. I would like to write it down today, as well as what I would like to achieve next year, and see in one year how it went.

2014, the year that ends

First of all, I spend the year in an awesome company with very talented and kind people, with immense pools of knowledge and always ready to share it.

They taught me how to test my code, from unit testing to integration testing, and I now can't code without writing the failing test first (TDD FTW!). And this goes without saying all I learned about Agile methodology and conflict resolution.

I also discovered that my areas of expertises were not where I thought they were. I've always considered myself a full stack developer (whatever that means), but I actually don't know that much about back-end code. Never coded anything in Java or .NET (and don't really want to, either). But I actually have a large experience in front-end matters (from CSS to Javascript). I realized that good CSS skills are actually quite rare.

I went to a wide variety of tech conferences and meetups, and wrote extended summaries. At first it was for my colleagues, but I then made them available to everyone. Those meetups were invaluable source of R&D. Seeing 20mn of live performance of someone convinced of what he's talking about is worth hours of blog reading. And the discussions afterwards made me meet some very interesting people and spawn nice discussions.

So I decided to go to the other side and became a speaker. I chose a subject I really enjoyed and tried to make it as accessible as possible, while keeping the message simple. I quite enjoyed it.

Writing summaries of conferences you've attended makes you rethink what you heard and makes you remember it more. But writing your own talk really makes you go deep in what you know and what you don't know and is an invaluable exercise.

On a purely tech-related side, I extensively learned AngularJs and Grunt. I also discovered Jenkins and sharpened my git skills.

I also migrated this website from a cakePHP based application on a shared hosting to a Jekyll generated website on a private server. I now love the clean simplicity of markdown files versionned with git, and am much more at ease administrating my own server.

2015, the year to come

So, what will next year bring ?

I'll continue attending meetups and conferences, and would like to be a speaker more often. There are some subjects I am passionate about and could talk about and share.

I also would like to invest myself more in the open-source world. I actually only submit bug reports, small pull requests and use GitHub mainly as a backup storage for some of my projects. But none get ever used by anybody else than me. In 2015, I would like to be proud enough of one of my projects to release it and have other people use it.

I only scratched the surface of Rails and Node this year, and never actually pushed a full project in production. I would like to go deeper than tutorials and TODO applications.

I would like to stop developing with AngularJS (after 1.5 years using it, I'm still not at all convinced). React seems a very good approach to the view rendering and I would like to test if further. Why not giving Backbone another chance, and trying Ember.

I would like to go back to one of my first loves, CSS. I haven't touched it enough lately and I really want to have a bit of fun with all the new possibilities flexbox can give us.

Grunt is fine, once you know your way around, but I really need to try out Gulp or Brunch also.

I haven't played enough with Vagrant and/or Docker for my taste. Docker is the future and I would really like to have each of the websites hosted on my server encapsulated in their own containers.

Conclusion

Never stop trying, never stop learning.

Testing $q promises with Angular

I've been working on a few Angular projects lately, and had to test some $q promises. And there was one little thing in how Angular implementation of $q and the $digest cycle interact that bit me once or twice.

If you ever fire a promise using $q in one of your tests, know that Angular will not resolve it until you tell it to. It means that your promise will stay in an undefined state (neither resolved nor rejected) and your test will surely fail. This is because Angular promises are tied to the $scope lifecycle and as we do not have one when running our tests, we have to add a bit of plumbing.

To force Angular to finish every promise, just add the following afterEach implementation :

afterEach(inject(function ($injector) {
  $injector.get('$rootScope').$digest();
}));

But this has a side-effet of triggering all your promises, even those you forgot about, like loading the templateUrl for your directives. This will in turn block your tests because some promises will fail. The easiest way to correct this is to mock the responses and always respond an empty object.

beforeEach(inject(function($injector) {
  $injector.get('$httpBackend').whenGET(/.*/).respond({});
}));

Hope this little tricks helped.

pantone2hex

I recently put together a small command-line tool to convert Pantone colors to their hexadecimal value.

$ pantone2hex 122C
#fed141

You can grab the code on GitHub.