“Falsy” vs “Falsey” – I’m Making the Call

This is probably the most asinine blog post I’ll write, but for my sanity, it must be done.

It is spelled falsy.

Without the “e” between the “s” and the “y” – priod, th nd.

Okay. So what is Falsy anyway?

In loose-typed languages like PHP or JavaScript values can be considered Boolean false if they are '' (empty strings), the number 0 (zero), NULL, and most obviously Boolean false itself, just to name a few (in PHP an empty array is considered false, while in JavaScript it is not). It is important to note that this is only in the context of non-strict comparison, i.e. == and not  ===, and when type casting to Boolean (see PHP’s type juggling reference).

When describing a false-like value it is easier/faster to type “falsy” (or the now incorrect way of “falsey”) since it has less keystrokes, and it is easier to read due to the lack of character bloat; incidentally it also fits nicely as a variable because there is no hyphen (devil’s advocate: camelCase) and it is not a reserved word. It is important that the developer does not simply describe the value as “false” since this implies a variable of type Boolean, however using “falsy” implies a false-like value of any data type which, albeit more ambiguous in its definition, is more descriptive in its context.

Supporting Data

Let’s let the data speak for a moment. After analyzing a Google Trends chart of “falsy” vs “falsey,” the results are initially a bit misleading. “Falsey” is the clear winner at first glance, only to find that there is a name and published articles with the name “Falsey.” Considering that “falsy” is not trailing by many datapoints provides the confidence that it is in use and very applicable. Most importantly in regards to the related searches, “falsy” prevails over “falsey” which does “not [have] enough search volume to show results”: “javascript falsy” and “falsy values.”

Addition: Douglas Crockford even uses “falsy” in his writing, “The Elements of JavaScript Style.” Perhaps I didn’t need to write this post after all, but I sure hope it solidifies the answer indefinitely and provides a resource for any other concerned developers out there.

Spelling Review

I am by no means an English major, or anywhere near one, but I do have a knack for research and comprehension.

With regard to the suffixation of the letter “y” (vowel) when transforming a word, the “e” is dropped per the rules:

In the word “false,” the word ends with the vowel “e,” is preceded by the consonant “s,” and none of the exceptions are applicable.

F – A – L – S – Y

JavaScript Inheritance and Method Overriding

I’m always finding myself wanting to use JavaScript like a classical OOP language with class-based inheritance, even though I know it is prototypical. Anyways, I’m jotting down how to do this and also allow for overriding (not overloading) methods. Note, that if you’re using Node.js, then you don’t need to define the inherits function, it is already available in require('util').inherits.

Check the console:


Node.js: Split/Count Number of Lines (Unicode Compatible)

The task was to read n number of a lines from a file in Node.js. The assumption is that the read buffer is UTF-8. The caveat is that there is more to just new lines in Unicode than “New Line (ASCII 10 or \n)” and “Carriage Return (ASCII 13 or \r)”.  This SO comment put me in the right direction.

Unicode Technical Standard #18 § 1.6 describes the following rule regarding line boundaries, (PS and LS are defined in Unicode 6.1 § 16.2 Layout Controls):

RL1.6 Line Boundaries
To meet this requirement, if an implementation provides for line-boundary testing, it shall recognize not only CRLF, LF, CR, but also NEL (U+0085), PS (U+2029) and LS (U+2028).

To put it into practice, the number of lines can be tallied while the ReadStream has incoming data:

The key is the regular expression, derived straight from RL1.6,  /\r\n|[\n\r\u0085\u2028\u2029]/ , which looks for any of the possible new line characters with precedence to CRLF (greedy). Don’t forget to listen for the “end” event and also remove the “data” listener on “end” or “error!”

In the context of splitting incoming data by line, simply calling  chunk.toString('utf8').split(/\r\n|[\n\r\u0085\u2028\u2029]/g) will do the trick. Note that if working with CSV files, parsing will require a bit more effort if escaped new-lines will need to be taken into consideration, and PS, LS and NEL are probably not characters that should act as line delimiters in that context anyway.

Node.js: Handling File Uploads without Express

I was working on a little project which does not utilize express. Part of the program needed to handle file uploads. In PHP this is easy with the $_FILES superglobal, and with express this is also just as easy with req.files. In pure node.js the developer doesn’t have this luxury because they’re just dealing with raw http requests and responses (I’m surprised node.js even parses the headers, it is a miracle!). Before I begin, this whole process should be optimally streamed to a file so large file uploads do not consume more RAM than their response chunk size, but I didn’t do this, shame on me.

First, capture the response body. Here I am assuming you have a HTTP server that is listening and responding to requests:

Here, I’ll give you the entire source to my MultipartParser Node.js module. It requires nodeproxy.

And the implementation is as follows:

LittleDiddy does not have any path routing (e.g. it won’t actually show a form that uses enctype="multipart/form-data"), it simply accepts and parses a POST with “file” inputs. This “little diddy” (implementation example) is untested by the way, so good luck.

This article’s source is released under the MIT license; I don’t care what you do with it.

ECMA-262: Breaking Out of Nested Loop Control Structures

PHP: Optional Numeric Argument for break

My first dynamic language was PHP and with that came the break statement which ends the execution of a control structure (e.g. for, while or case). It also “accepts an optional numeric argument which tells it how many nested enclosing structures are to be broken out of.” This optional argument is beneficial when there are nested loops that need to be terminated prematurely without adding extra logic and without halting the entire script execution (e.g. exit).

In the following example the second/nested for loop will be terminated during the first iteration, but the outer-most loop will execute tens times.

…but in the next example it will break out of both for loops resulting in $i never incrementing from 0 to 1.

JS/AS: LabelledStatement (TL;DR)

What about ECMAScript Languages (ECMA-262)? I struggled with the absence of this feature for languages based on the ECMA-262 standard like JavaScript and ActionScript. These languages (as far as I knew) have the break statement which works just like it does in PHP, but without the optional numeric argument. This made stopping nested control structures a PITA.

Well, maybe if I RTFM I would’ve been acquainted with the LabelledStatement Statement and saved myself the heartache. This can be observed in section 12 of the ECMA-262 Langauge Specification, Edition 5.1. Basically the syntax goes something like this:

Note “theLabelName” on lines 1 and 3. This is the bread’n’butter. All that needs to happen is to label the control structure using the standard variable naming convention and post-fix it with a semicolon (:). This becomes the “calling card” of that specific construct. Lastly, the break statement has an optional argument where the previously established label can be applied.

Further Reading

See ECMA-262 5.1 Edition ECMAScript Language Specification, §12, p86.

JSMin, Important Comments, PHP Port

I’ll make this quick.

JSMIN is a minification engine for JavaScript. It condenses the script by removing unecessary white space and comments. Well therein lies the problem: it strips out comments. Comments are important for licensing and when they’re removed, this is illegal.

After doing a split second of research I found the article “JSMin, Important Comments, and Copyright Violations” by Zoompf which talked about this issue and how to resolve it. Turns out there are “important comments” that have an added exclamation point at the beginning, e.g.:

Notice the “/*!” – that “!” is what makes it important. So the solution is to write an exception in the JSMIN lib to include the comment into the standard output. The previously mentioned article had source code showing the  change, but it wasn’t in PHP (I use the JSMIN port to PHP called “jsmin-php”). So I took a few minutes and wrote the replacement for the protected “next” function.

OK, so here’s the code. Lines of interest are 17 through 35, and don’t forget line 50. Lines 37 through 49 include the original code.