Javascript is a language that is, by design, difficult to debug. It is dynamically typed, it is based around asynchronous callbacks, almost all data types are mutable, almost no functions of the standard library are pure, and the list goes on. And these are not just flaws in the design; they are what makes the language what it is. It is therefore important to be equipped with the correct tools when setting out to correct your code. I am not talking about fancy debuggers and static code analyzers, just two very simple libraries. So simple in fact they do not even qualify as separate libraries. They are just a couple of hundreds of locs that you can copy right into your project and modify to your needs. My sample implementation for each is provided.

It is well documented how broken the type system of C++/Java style languages is. If you are stuck with one of these languages you can take pride that when it comes to types, you are operating in a context that is a step above Python and a few floors above Javascript. Milking the staircase analogy, at the roof of the building would be Rust and in low orbit you may find languages like Haskell and OCaml. That said, there are a few nice things you can do with C++ templates that are not extremely obvious but not too magical either. In this post I will try to describe some that we have found useful at codebender, since type conversions at the C++ level are required to make FireBreath play well with libraries like serial.

It is often the case that testing a computer program in the environment in which it was meant to be run not only impactical but outright impossible. This is a common issue in embedded development. BlackMirror aspires to solve the problem for javascript by blackboxing the application, recording the interaction of a successful execution with an API, and asserting that a different program has the same interaction with the API as the first one. A big design goal was for the stored interaction to be serializable so BlackMirror is not only able to replay APIs with a different system state but also APIs that are later not available at all.

With so many other candidates, usually the performance bottleneck for javascript is not the responsiveness of setTimeout. Highly asynchronous code is, however, prone to many bugs, a huge pain to test and debug, and may unexpectedly break for no apparent reason. A partial solution to the problem would be to roll your wrapper to the scheduler. In fact, you may want to abstract the concept of time completely from your application.

Recently there has been a big fuss about Chromebooks and how the Chrome OS will be folded into android. That is great news for users and even better news for hackers who can get a Linux laptop for as little as 135$. Well, almost Linux. It turns out that one needs to jump through quite a few hoops to get to the core of the OS where you can actually use your computer like the baws that you are.