Category Archives: Code

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

toggling
Continue reading

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) {

with

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?

Native smooth scrolling with JS

There’s a new way of invoking the scroll functions in JavaScript where you can specify how do you want the scroll to behave: smoothly, immediately, or auto (whatever the user agent wants, I guess).

window.scrollBy({ top: 100, behavior: 'smooth' });

(note it’s behavior, not behaviour, argggh).

I read this post yesterday saying that it would be available (via this tweet from @FirefoxNightly) and immediately wanted to try it out!

I made sure I had an updated copy of Firefox Nightly—you’ll need a version from the 28th of October or later. Then I enabled the feature by going to about:config and changing layout.css.scroll-behavior.enabled to true. No restart required!

My test looks like this:

native smooth scrolling

(source code)

You can also use it in CSS code:

#myelement {
  scroll-behavior: smooth;
}

but my example doesn’t. Feel like building one yourself? :)

The reason why I’m so excited about this is that I’ve had to implement this behaviour with plug-ins and what nots that tend to interfere with the rendering pipeline many, many times and it’s amazing that this is going to be native to the browser, as it should be smooth and posh. And also because other native platforms have it too and it makes the web look “not cool”. Well, not anymore!

The other cool aspect is that it degrades great—if the option is not recognised by the engine you will just get… a normal abrupt behaviour, but it will still scroll.

I’m guessing that you can still use your not-so-performant plug-ins if you really want your own scroll algorithm (maybe you want it to bounce in a particular way, etc). Just use instant instead of smooth, and you should be good to go!

SCROLL SCROLL SCROLL SCROLL!

Update: Frontender magazine translated this post to Russian.

Binding to an specific host with express.js

The documentation on the listen method is really vague, but the way you can make your server listen to an specific address only is this:

var server = app.listen(3000, '127.0.0.1', 511, onServerListening);

In this case I want the server to respond only to connections using the 127.0.0.1 host name. Not 0.0.0.0, and not localhost. Only 127.0.0.1.

The reason for this is that I am playing with Twitter’s OAuth and I was stumbling upon this issue because express insisted in binding to 0.0.0.0 by default (i.e. any address), but it wouldn’t work well when Twitter redirected back after authenticating.

For reference, another thing I tried and didn’t work:

var server = app.listen(3000, '127.0.0.1', onServerListening);

Notice that the 511 parameter is missing. So effectively it would take onServerListening as if it was the 511 parameter, which according to the documentation is “the maximum length of the queue of pending connections” and it wouldn’t call the callback. Booo.