The ZooKeeper's New Year's Resolution

(... will probably not be lose weight. Because it has already been fulfilled)

What happened during 2020?

The Node.js ZooKeeper Client - simply called zookeeper - have been released 5 times and the current version is now 4.7.1.

🎉 Packaging

The source code is packaged differently, making the footprint a lot smaller and the install process simplified. To summarize: the ZooKeeper lost weight.

🎉 Prebuilds make the install process really, really fast

The install process is faster than ever. If you are a Mac OS X or Windows user, there is no longer any need to build an AddOn during the install process. Everything is already included in the package, thanks to a cool tool called prebuildify. Linux user? Don't worry, the installer will quickly build a Native Node.js AddOn for the Linux flavor you are running. During 2021 we will probably include prebuilds for the most common Linux flavors.

🎉 TypeScript

TypeScript declarations makes the Developer Experience very nice. With type hints, function parameter docs and autocomplete.

🎉 async zookeeper

Promise based functions are the default.
await client.create(path, data, constants.ZOO_EPHEMERAL);

🎉 Same client for all platforms

The same version of the C Client source code is now used in Linux, Mac OS X and Windows 10 to build a Node.js native AddOn. Before that, there was an issue with Windows clients connecting to a ZooKeeper server v3.4.8 that made us add a workaround - reverting to a really old client version for Windows users. But that is now solved and all platforms share the same set of modern features. Yay!

🚀 What's next?

Adding support for the new node types introduced in Apache ZooKeeper server v3.5.5:
Container and TTL. The features will probably be released during January 2021.

🎉 Happy New Year! 🎉

Documentation: The Good Parts

Writing documentation is probably the most boring part of software development. As developers, many of us avoid it. We write docs only when someone else force us, twist our arms or assign us JIRA tickets.

- Was it the project manager, or maybe that senior tech lead guy with the massive beard that made you write the docs?

What I want to describe in this post isn't complex Word documents explaining some software. It isn't a guide on how to write something clever about a public FirstName property of a Person class.

It's about JavaScript and data types. Keeping it simple, and fun.

 

JavaScript is dynamic
JavaScript won't stop you from passing in whatever you want to a function, even when the code is expecting data of a specific type. It will crash during runtime instead, yes. When parsing or iterating something that cannot be parsed or iterated.

- No type checks for you!

This is also what makes the language very flexible. Simplistic syntax, functions as first class citizens and with a little less noise. There is no need for explicit data type declarations, generics or interfaces, making it easy to write code in less than 100 characters width. In fact, you will find yourself writing code in less than 80 chars quite often. In addition, having only one thread to worry about is a good thing (for most of us). And I believe the V8 engine is fast enough too.

- It would be nice if there was something that could let us have a little bit of both.

Did you say TypeScript?
TypeScript is cool. But I'm not sure it is the way to go for back-end code written for Node.js. Node.js itself is probably a bad choice if you are in great need of strongly typed language features on the server. Why not go for C# instead? 

If your code lives in the browser, well, that is something different. You are basically stuck with JavaScript for web development - whether you like it or not. TypeScript, or WASM, can probably help you - after some initial setup, headache & build scripts.

 
Have you tried JSDoc?
During my work on the Open Source project node-zookeeper, I have learned how JSDoc can help us make the JavaScript Developer Experience a lot better - without the headache. Your editor will give you hints and warnings about parameters and data types.

Here's an example:

/** @returns {number} */
function getRandom () {
    ...
}

With parameters:

/**
 * @param {number} minValue
 * @param {number} maxValue
 * @returns {number}
 */
function getRandom (minValue, maxValue) {
    ...
}
 
In the example, documentation is used only for describing the data types of input parameters and the return type. Nothing else. I would recommend you to try hard and refactor the actual code, making additional comments not needed. Is the function name getRandom good enough?

- Maybe I should add some comments to the code here?

(don't do it)

Your editor is smart
Your IDE or editor will figure out the JSDoc syntax, even for custom type definitions. Custom type definitions are for objects - custom data types - that cannot be described as built in strings, booleans, numbers, objects or arrays.

Another example, this one is from the typedefs.js of the node-zookeeper project, describing a ZooKeeper node changed callback:

/**
 * Watch callback
 * @typedef {callback} watchCb
 * @param {number} type
 * @param {number} state
 * @param {string} path
 */ 

The type definition for the watcher can be referenced in the code like this:
/** @param {watchCb} callback */

The node-zookeeper project has a typedefs.js file in the root folder. A smart IDE, like WebStorm, will parse it and use the type definitions to give you and your coder friends a nice developer experience.

When dynamic isn't good enough, use JSDoc. But be careful, use it only when needed. Or else, you will be stuck in the Documentation Swamp.

Coding in the dark: ES2015 and TypeScript on an iPad

Coding in the dark
Summertime, and the Swedish weather is ... not great, but good enough! I have spent some of the vacation days here at the countryside of beautiful Värmland, Sweden, without writing any code at all. But ideas have popped up and I want to try them out. So, now I code when everybody is sleeping. The "Dark Theme" of the editor dim the bright screen light - and hopefully won't wake up the family in the middle of the night.

Direct link: Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.

Offline coding
I really want to write code on my iPad mini, instead of using the laptop (that I also have with me, of course). With low bandwidth - sometimes no connection at all - remoting to & write code on a Cloud based VM is not an option here in the wilderness. Local and offline is better. The Coda for iOS app supports local offline files and the latest version has some really nice features. But why code on an iPad? Well ... why not! And it's convenient too, experimenting with code snippets is just a smart device away from being realized. The solutions I present here are of course useful for countryside coding on a laptop too.

ES2015 on the iPad
I decided to give ES2015 coding a try. Does it work, using an iPad and the app only? Yes, the built in web browser and file system of Coda for iOS makes it possible. When I figured out how to transpile and run the scripts in the web browser (by using Babel and the es6-module-loader library), I got carried away and thought it would be cool to also write TypeScript on the iPad. It turns out to be just as easy as the ES2015 setup.

TypeScript on the iPad
I found a nice library on GitHub by Basarat Ali Syed, that makes it possible to transpile TypeScript files to JavaScript in a web browser: basarat/typescript-script 

Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.

Command line experimenting with the JavaScript Playground
One of the new features of the Coda app is a command line based JavaScript playground. Scripts can easily be loaded into it and the transpiler functions can be executed from the command line. I think it is a useful alternative to the web browser, and very helpful when I want to see the actual output from a transpilation.

Happy iPad coding!