All posts by sole

Hashing passwords with Bcrypt and node.js

I have a little pet project that I’m using to learn Hapi.js.

Today I wanted to add authentication and since this is, as I said, a tiny little mini project, I want to only allow specific users (actually, just me) to log in, and not everyone+dog using bell or something of that sort. So I thought I’d go for hapi-auth-basic.

This module performs, not surprisingly, an HTTP basic authentication, and also wants a password hash generated with Bcrypt. I didn’t really find a command line thing that would generate the hash for me on this mac computer in a convenient fuss free way, and I also didn’t really spend hours looking because it’s Saturday, so in my most pragmatic move of today I decided I would just write a little snippet of code that would hash and verify the password using JavaScript.

So here it is, roughly based off this post of using Bcrypt with mongoose.
Continue reading

Danger Dashboard: for the adventurous `dom.webcomponents.enabled` enablers

You know the drill, you go to about:config, look for dom.webcomponents.enabled and turn it on because you want to try some new feature in Firefox. And then you visit some other website which relies on said support to be fully complete and all hell breaks loose… or it just breaks in variously spectacular degrees of fail.

Wait, no more–now you can install this fantabulous add-on called Danger Dashboard which will overlay a little dashboard on the bottom right corner of each website you visit, so you can

  • spot if the site is loading a polyfill
  • or spot if the site is using web components natively
  • and also toggle web components support without going to about:config, because it gets tiring after doing that many times on the same day

Toggling dom.webcomponents.enabled in one of Mozilla Brick’s demo components, brick-deck

Continue reading

Assorted bits and pieces

As we wrap the year and my brain is kind of hazy with the extra food, and the total shock to the system caused by staying in Spain these days, I thought it would be a splendid moment to collect a few things that I haven’t blogged about yet. So there we go:


In Hacks

We were brainstorming what to close the year with at the Mozilla Hacks blog, and we said: let’s make a best of 2014 post!

For some reason I ended up building a giant list of videos from talks that had an impact on me, whether technical or emotional, or both, and I that thought would be great to share with fellow developers. And then the planets aligned and there was a call to action to help test video playing in Firefox, so we ended up with You can’t go wrong watching JavaScript talks, inviting you to watch these videos AND help test video playing. Two birds with one stone! (but figuratively, we do not want to harm birds, okay? okay!).

Since it is a list I curated, it is full of cool things such as realtime graphics, emoji, Animated GIFs, Web Components, accessibility, healthy community building, web audio and other new and upcoming Web APIs, Firefox OS hardware hacking, and of course, some satire. Go watch them!


And then the videos for some talks I’ve given recently have been published also.

Here’s the one from CMD+R conf, a new conference in London for Mac/iOS developers which was really nice even though I don’t work on that field. The organiser watched my CascadiaJS 2014 talk and liked it, and asked me to repeat it.

I’m quite happy with how it turned out, and I’m even a tad sad that they cut out a bit of the silly chatter from when I jumped on the stage and was sort of adjusting my laptop. I think it was funny. Or maybe it wasn’t and that’s why they cut it out :-P

Then I also spoke at Full Frontal in Brighton, which is not a new conference but has a bit of a legendary aura already, so I was really proud to have been invited to speak there. I gave an introduction to Web Audio which was sort of similar to the Web Audio Hack Day introduction, but better. Everything gets better when you practice and repeat ;-)


Potch and me were guests in the episode 20 from The Web Platform, hosted by Erik Isaksen. We discussed Web Components, solving out problems for other developers with Brick, the quests you have to go through when you want to use them today, proper component/code design, and some more topics such as accessibility or using components for fun with Audio Tags.

And finally… meet ups and upcoming talks!

I’m going to be hosting the first Ladies Who Code meetup at London of the year. The date is the 6th of January, and here’s the event/sign up page. Come join us at Mozilla London and hack on stuff with fellow ladies who code! :-)

And then on the 13th of January I’ll be also giving an overview talk about Web Components at the first ever London Web Components meetup. Exciting! Here’s the event page, although I think there is a waiting list already.

Finally for-reals I’ll be speaking at the Mozilla room at FOSDEM about Firefox OS app development with node-firefox, a project that Nicola started when he interned at Mozilla last summer, and which I took over once he left because it was too awesome to let it rust.

Of course “app development with node-firefox” is too bland, so the title of the talk is actually Superturbocharging Firefox OS app development with node-firefox. In my defense I came up with that title while I was jetlagged and incubating a severe cold, so I feel zero guilt about this superhyperbolic title :P

Merry belated whatevers!

Why I check for length === 0

A few weeks ago (or was it a few days ago? ahhh, holidays) I had my code reviewed by a colleague, who suggested I replaced all appearances of

if(whatever.length === 0) {


if(!whatever.length) {

I said I preferred to just leave it as it was, as I found it easier to scan visually. I find the strict comparison with zero highly stands out when you’re reading code, which is what we most often do as programmers.

What I didn’t also express is that there is a certain cognitive dissonance when I see the if(!whatever.length) part. It sounds like “if whatever has not length, then…” which is not what I want to express, and is also distracting: “what do you mean if it has length, can it not have length, and why should I be worried about that?”

Or also, if you’re not familiar with precedence rules, you might wonder if it’s applying the NOT operator to whatever itself. Why would we do that? What would that mean? It’s confusing.

I don’t want people unfamiliar with coding to agonise over my intentions. I want them to look at the code and immediately go: “oh, so we want to know if there is something in this array. We want to know if it’s empty, therefore we want to know if it has zero elements, so we’ll look at its length property”.

That’s it.

There’s another reason why I don’t like to use this style and it’s the lack of consistency it engenders. Suppose you want to look for whether the array is empty, whether it has exactly one element, or whether it has more than one, at different points in the code. So you might end up with something like this:

if(!array.length) {
  // if it's zero

// ...

if(array.length === 1) {

// ...

if(array.length > 1) {

We are enquiring about the same thing all the time: the amount of items in the array. But we are doing it in slightly different ways. This is, again, very confusing, both when you’re new to programming and when you’re tired, because you have to make an argument of why using one versus the other, and those are mental resources you’d better spend solving your actual problem. Better be consistent and use the same style everywhere. You’ll be just “wasting” a few characters, but gaining a lot of time. And code uglifiers can take care of compressing your code to the very minimum, anyway.

Moreover: using truthy values such as in this case feels like the ghost of C code past*, where boolean didn’t exist as a data type until very recently, so all boolean-like values were held in integer-typed variables, and anything with a value of zero evaluated to “false” and anything not zero was “true”. That gives way to code like this:

file = open("todo.txt", O_WRONLY);

if(file) {
  /* we could open the file */

where if the todo.txt file can be opened, the file variable will hold a bigger than zero value representing the file descriptor, and hence it will be “true”.

But not everyone that comes to JavaScript has a C background, so I fear that each time I am “clever” and use one of these I am making it harder for new people to use or learn from my code.

Since I am sufficiently convinced that I am clever, I don’t need to demonstrate it by writing pseudo-obscure code constructs. So I’d rather use my cleverness to write code that is crystal clear and expressive :-D

* will you excuse the BAD PUN?


I had occasionally biked around London using their famous Boris Bikes (which should actually be called “Ken Bikes” since he’s the Mayor that developed the idea, but hey), so I thought I knew the drill: lots of buses you’d want to avoid, drivers were mostly OK, it should be fun.

I kept saying to myself that I should get my own bike, but it took me almost two years of procrastination to finally make the move and do it.

And I got a foldable one–a Brompton. It took six weeks to be delivered because I wanted an specific colour AND three gears, and that wasn’t any of the configurations they had in stock so… custom order it was.

When I took it home for the first time, I thought I’d be unable to walk the next day. Ahhh the pain! It’s funny how little attention we pay to some things when we’re pedestrians–that street that you walk without really caring too much about it has actually a bit of a slope. So try biking along that sustained slope when you’re not trained, and your legs will notice.

If taking the bike home the first day had been exhausting, I was totally sure that I wasn’t ready to bike to work, which was a longer way. So what I did was “training” around my neighbourhood on week-ends and some days that I’d work from home (so I’d get some fresh air!). It was also a great chance to practice lifting the folded bike downstairs, unfolding it, and after the ride, folding and lifting it up. I can do that quite fast now, but the first days it was a complete disaster! (Specially the first day–picture me googling “how to unfold a brompton bike” on the street).

Finally one day I thought: that’s it, I’ll bike to work tomorrow!

And I did it.
Continue reading