Property-based testing is probably the thing I missed the most from my time working with Haskel. It is such an elegant way of testing functionalities that it is hard to not use it. As you can imagine, I look for a Property-based testing framework in any language I have under my hands. Usually, unsuccessfully. However, in recent years I am working a lot with Typescript and, luckily, Typescript has a good property-based testing library: fast-check.

My last week project involves PureScript and Halogen and the Dwarf Fortress calendar. I wanted to give a first-hand experience with some pure functional language for web front-end and, after discarding Elm, I ended with PureScript. I will not go on a comparison between PureScript and the rest of the world. If you want a comparison among the other candidates, you can look at this very detailed article. (There is ClojureScript too, if Clojure will ever came back from the graveyard).

As usual, trying to nicely separate into different files the various application parts in JavaScript is a titanic challenge. This time, I wanted to separate the “.frag” and “.vert” shader programs into different files that I can load at runtime (instead of putting them into the HTML like a savage).

For some reason, there is no easy out-of-the-box way to do that. On the internet, there is a small library, but it depends on JQuery and I think it is insane to load JQuery on top of THREE.js just to load a couple of files. Therefore, I wrote a function to do that using the THREE.js integrated generic loader function.

Yesterday I converted a Binary Heap data structure in TypeScript. The original code is here, in the Eloquent JavaScript online book by Marijn Haverbeke.

In short, a Binary Heap is a common data structure for a priority queue. We want to put inside the queue many values (or an object) and you want to extract the smallest value (or the object with the smallest score) in the most efficient way.

This JS implementation the Eloquent Javascript book is pretty common, so I decided “to typify it”.  The result is in the following Gist:

As you may know, I am in the middle of developing a demo for some Smart Pathfinding, and I’m using Phaser and TypeScript for it. Unfortunately, as soon as I started coding a couple of days ago, I quickly found a problem. How can I do pixel-perfect scaling of the game?

The tileset I’m using is very small (16x16 pixels tiles) and I needed to scale them at least 3 times to make them visible on a big screen. However, searching for “phaser.io” and “scaling” returns a lot of not useful results.

I have to admit it. I was a big Javascript hater. I used to criticize the language on every possible aspect: syntax, maintainability, error prevention and management, and so on. Let me be clear, I still have a lot of concerns on all this things. I wasn’t wrong. Javascript’s syntax can be a nightmare (and this is why there are so many languages that transpile to Javascript), maintainability is a state-of-the-mind more than a language feature and a lot of Javascript design issues are an infinite-bug-spawner. But, after all, it is not so bad and it is going to improve significantly in the future.

In the last months, I get used a lot to the Javascript ecosystem and community and it becomes a language in which I feel quite happy to work with. Let’s see why (and why still is not a perfect language).

Yesterday, while my working machine was crunching tons of numbers, graphs and maps to produce some (hopefully) meaningful data for a research work, I was looking for a simple guide to build a simple web page with ClojureScript. Unfortunately, I was not able to find something that was at the same time straightforward, simple, minimal and explained! So, I decided to write something by myself to avoid my pain to some future young clojurist. The main problem with the guides I’ve found online were:

1. They didn’t use Leiningen or any other build system. Now, this can also be good, but Leiningen is, in practice, a standard for Clojure developer, so I’d like to learn how to setup a project as soon as possible.
2. They are outdated.
3. They are not well explained. For sake of simplicity, they assume a lot of things. But I want to know what I’m writing!
4. They are not simple. I don’t want to write a full featured web application with a lot of dependencies and plugins! I want an hello world!

So, I hope to cover all this points. Let’s start!