måndag 11 januari 2021

Simple (within parentheses)

  • - Hey, what's ClojureScript?
  • - It's a thing that compiles Clojure to JavaScript.
  • - I get it. What's Clojure?
  • - It's a Lisp.
  • - ???
  • - You know, a functional programming language that uses a lot of parentheses.
  • - I … get it? 🤯

Don't worry. In this post, I will share some of the basics that I have learned about Clojure and ClojureScript.

Clojure?

With Clojure, you can write simple, functional and minimalistic code. Some of the cool things with Clojure are:

  • data is immutable
  • the REPL is a powerful tool
  • few keystrokes to make things happen

Clojure runs on top of Java, suitable for all kinds of "backend" things. It also runs on top of JavaScript. Yes, JavaScript - making it possible to develop all kinds of apps, tools, products and websites. There's even an option to run in a .NET runtime, but I haven’t tried out that one yet.

What does it look like?

Even though the syntax may look unfamiliar, you can already see in this silly example the less amount of keystrokes needed using Clojure, compared to JavaScript.

Parenthesis?

Everything you write in Clojure is a list, wrapped in parentheses. That may sound weird. I agree, it is weird. But your eyes will get used to it. In short, the format of writing something in Clojure is:

(operator operands) or even (function arguments)

Here is an example:

... and how it would be written in JavaScript:

If all this is new to you, you might have this expression in your face right now: 😬

That is perfectly normal. I have looked like that a lot during 2020. When digging deeper, you may need to go through The 12 Stages of Learning Clojure.

ClojureScript?

With ClojureScript, you develop web apps and write simple React components. You write code in Clojure, compile it to native JavaScript and run it in your favorite browser. The compilation happens all the time and automagically as you type.

Just like with Java or .NET in the backend, ClojureScript has native access to JavaScript. You can use and interact with your favorite npm packages and React components just as you would with JavaScript.

Reagent and React

I'm going to fast-forward a bit by adding a ClojureScript library called Reagent. With Reagent, you write React components but with Hiccup instead of JSX. Wait, what?

View components are built up using Clojure data structures. The example above creates html elements with Clojure vectors and keywords. This style is called Hiccup. It will save you a lot of keystrokes and you'll have a lot less of scrolling in your code editor.

What about state?

I'll fast-forward again by adding a very nice library called re-frame.

From the re-frame docs:
“... It has reactivity, unidirectional data flow, pristinely pure functions, interceptors, coeffects, conveyor belts, algebraic effects, statechart-friendliness and claims an immaculate hammock conception. All while being both simple and easy. ...” 💥🤯💥

With re-frame, data is stored in one place called the "app db". Your components will fire events and subscribe to changes in the app db. The cool thing is that you write code in a sequential way, making it very readable and easy to understand. However, the syntax of the actual events and subscriptions might take a while to understand, at least if you are new to Clojure in general.

Here, we have a Reagent component that adds a button component, only when the app is disconnected. It is subscribing to changes of disconnected in the app db. React will re-render the components when the app state has changed.

Cool, but can I use my favorite editor?

Yes, most likely. I know there are Clojure plugins for VS Code, Atom, Sublime Text and intelliJ. I use Emacs, because ... I just like it.

There is something important and special going on with developers and their text editors. I think you will be able to find your favorite dev setup. I also think that you will learn a lot of new programming concepts and styles when reading more about this cool language and its libraries.

Photo by Marcos Paulo Prado on Unsplash

tisdag 29 december 2020

The 12 stages of learning Clojure

In 2020, I've been on quite a learning journey. I joined a team where we write code in Clojure, a very different language from what I’m used to. It turns out writing Clojure is a very nice developer experience, but it could take a while to get it.

You might have to go through some (or all) of the 12 stages of learning Clojure.

😮
1. "I have no idea what I'm looking at."

😬
2. "Where does that code end? Where does it begin? Why are there so many parentheses?"

🤪
3. "I'm totally lost."

😳
4. "Will I ever learn? Am I smart enough?"

😭
5. "I will never learn. I'm not smart enough. I want ice cream!"

🤔
6. "Hmmm, wait a minute ... map, reduce, filter. This is something I recognize."

🙂
7. "Yes. Clojure, yes, yes."

🤯
8. "OMG, this language is so powerful. OMG, I even understand some of it."

🙃
9. "defn, keywords, multi-methods, macros, juxt, slurp, ha ha ha ha ..."

😀
10. "Pretty clean. Yeah, I've learned the keyboard shortcut to nicely format the code. And threading macros are nice!"

😍
11. "I ❤️ Clojure. Everything about it makes sense. It's is the language I've been searching for all my life."

🧘
12. "Empty your mind, be formless, shapeless - like water. Now you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Water can flow, or it can crash. Be water, my friend." *



You might wonder what stage I'm currently in. Well, probably somewhere between 🙂 and 😀.

Here's some of the sources that I have learned a lot from:

I'm sure I will keep trying, failing, learning and mostly smiling in 2021 ✨



* Yes, Bruce Lee said that.

måndag 28 december 2020

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! 🎉

söndag 3 maj 2020

Developers and their text editors

Developers and their text editors

The text editor, or IDE, is probably the developers' best friend. Is the editor almost like a ... family member? You spend a lot of time with your text editor: writing, navigating and reading code. Just like a family member, a text editor can be a source of inspiration, annoying, joyful, difficult to figure out and probably something you will need a break from at times.

For a couple of months, I've been on quite a learning journey. I have joined a team where we write code in Clojure, a radically different language from what I’m used to. I also decided to try out a new editor: Emacs, radically different from tools that I am used to.

I still struggle with the context switch of copying some text from a browser (using the well known key combinations ⌘+c and ⌘+v) - to copy-paste in Emacs, using the Kill-ring-save (M-w) and Yank commands (C-y).

So why did I choose Emacs?
It is in fact a very good Clojure editor. There's a lot of really nice plugins and features for writing Clojure and ClojureScript. Also, compared to programming languages like Python or JavaScript, it seems there aren’t that many tools out there designed for Clojure development. Once you have the features and key combinations in place, Emacs is a very nice developer experience.

Clojure is a very nice developer experience. 💫

It turns out that Emacs also is really good for writing Python and JavaScript. I guess you could use Emacs for anything text based, but I'm not there yet.



Here's my current Clojure, Python and JavaScript friendly Emacs configuration that will probably be updated continuously as I learn more, and how to replace annoying text editor defaults.

fredag 10 januari 2020

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.

 

https://commons.wikimedia.org/wiki/File:Unofficial_JavaScript_logo_2.svg
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.