crafting (and) JavaScript

TypeScript for JavaScript, Part 1 - Setup

You don't need to rename all your ".js" files to ".ts" to go all in on TypeScript, you can go gradually. Adopt TypeScript step by step, become familiar with it in your existing JavaScript project. No need to put development on hold for weeks, while you convert the code base to TypeScript and fix all type errors. Read on to see how I adopt TypeScript for JavaScript for the sourcecode of jskatas.org.

Continue reading β†’

When my build process slows down my work and I think about how to build just parts of a project instead of the entire project, my time is spent wrong. I should speed up the entire project's build process, not optimize for building parts. Read on about how I build, measured, sped up and will repeat for site-stitcher, the project that builds this site.

Uku creator of plausible.io had written a nice article on how to design, even though one is a miserable designer, as I am. A must read if you own the same skill deficiency ;).

I am a big fan of structured data and making the data we have on the web more accessible, easier to use, simply more worth it is a very useful thing. How useful is it investing in outlining your website's today? I found a couple articles and quotes on the web.


There is a uXSS bug in Chrome on iOS, which is actually a WebKit bug. But Chrome fixes it on iOS by crashing the browser, because this was the fastest way to fix it. Alright ...

I have been through a couple projects to build my blog. None survived, so I just build, just what I need, with just enough code to get it done.

It was the second time that we did Tetris as our task for the JSCodeRetreat and I have to say, that the participants' comment made me realize that we are on the right track. Though not all comments were purely in favor of Tetris, I think Tetris is the better task for a (JS) CodeRetreat.

It was Evren who triggered the idea of using Tetris as the task for the next JSCodeRetreat. And I have to say it was a good idea, it was a bit more challenging than the Game of Life and left more room for discussions and also allowed to explore more (software) design challenges.

I just wanted to install a github-flavored markdown plugin for vim. Until today I only used vim as it falls out of the box. So I had to do a couple detours before I got a vim plugin installed. Since I like the simplicity of the Mikado Method I apply it very often (maybe too often). In this case I used a very simple form of it, actually mainly to document all the steps I had to take on this detour. Read more below.

This is newsletter #7 - about crafting (and) JavaScript - April 17rd, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software.

This is newsletter #6 - about crafting (and) JavaScript - April 3rd, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

This is newsletter #5 - about crafting (and) JavaScript - March 27th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

This is newsletter #4 - about crafting (and) JavaScript - March 20th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

While refactoring some badly tested code, a pattern of how I extract dependencies emerged. The actual intention was to improve the testability. In this case dependency injection is the tool that helped me. Read here to find out the steps I found to separate the dependencies.

This is newsletter #3 - about crafting (and) JavaScript - March 13th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

Welcome to the newsletter #2 - about crafting (and) JavaScript - March 6th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

This post is my 2nd write-down inspired by "Purescript by Example", the book by Phil Freeman, the author of purescript. Now about chapter 2, where I install Purescript and touch the tools for the first time. I am gonna use yarn instead of npm, let's see how that goes :).

I am convinced, that stricter types are of help when writing, reading and understanding source code. Why? Ever had the primitive obsession? And if you continue down the (type) rabbit whole, you get to stricter typing. And to Purescript, which attempts *"to keep the semantics of JavaScript, while enjoying the syntax and type system of a language like Haskell"*.

Welcome to the newsletter #1 - about crafting (and) JavaScript - February 28th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

I just stumbled over https://imgix.com which looks like it could speed up a website building process and reduce the time one needs to invest in preparing images.

The annoying port 8080 is already in use message and not knowing which process is occupying this port sucks. I knew it was lsof that can help me. But how exactly? TL;DR: ps -p `lsof -i :8080 -t` -o command= (on Mac OSX)

gitup makes branches easy to understand show perfect overivew

Sometimes I stumble over commenting out a part in my JSX template. And I am always again looking for how to do that {# or {-- or what do I know.

ADR is a way to document decisions, reminds me of python's PEP.

This topic came up today when we discussed the #crewmeister API, and made me think. Until I remembered that we once in a project used to use the pure POST params, which are basically key-value pairs. And the question also reminded me of my PHP times, there the server-side knew how to handle a key which looks like user[0] and builds and array. But when I ran into that problem back then we used to use python and there we didn't have that.

There are seven kinds of coupling.

This sticks out, so far :) Avdi Grimm's article about the law of demeter, reading it including all commetsn until the end will take a bit of time but is exactly what explains a lot of things that imho we do wrong in lots of software we write, I am working on improving myself around it. For the completeness here is the paper initially laying out the law of demeter.

Actually we are currently discussing and evaluating to use react or alike and this react lifecycle comes in perfectly and somehow also makes the point stronger that a well documented, cared and widely used project is a good thing to be using. Decided!


Till Nowak: Delivery

In Ruby "and and or are control flow operators, not boolean operators".

In the ruby koans I now came across array functions. One is collect and I thought, this is map, and the comment below said

A colleague just pointed me to the article about Six Thinking Hats. What I really like about this is that it removes the personal part from a solution finding, discussion, etc.

At this point in the EmberJS Framework Basics Part 2 video the author explains how you can make (computed) properties out of 'normal' methods by using what the ember.js Ember.Object offers. It starts out with friend.age(), which returns what you expect. The author wants to write this as a property (as one accesses it in ember!) like this friend.get('age'). How is that done? Well, ember extends the native prototype of Function, so you can write this inside an ember object definition age: function (){}.property().

730.975 byte - the size of the main JS file of an empty app that ends up in the dist folder after building the app by ember build --environment=production.

This article about closures in ruby started somewhere by saying "Ruby has four different ways of using closures, each of which is a tad bit different, and sometimes nonsensical".

In the last days I had to learn a lot about how to use, write and understand user stories. This talk by Mike Cohn is a pretty good kick start and summary for the hows and whys.

I just read a post about GraphQL, and because the headline and all the article contains so much excitment and passion for the topic I read it until the end.

I was fighting a little bit with getting Michael Feather's delta-flora to run, but made it finally. My starter level of ruby knowledge made it not much simpler to get it to run :). But in the end I succeeded doing the following steps.

I found this repo, which seems not to be the newest, but one (if not the only one) which provides some ways of refactoring for ruby.

A very good talk by Jim Weirich, where he shows how to pull the meat, the actual business logic out of a rails app to make it testable in a fast manner concludes with a very interesting idea.

I know that the calling of functions can be quite noise-less, no parantheses and commas. But it also leaves me baffled at times. I can't get my head around this one either.

One method three different return types

Don't promisify fs.exists since this does not play by the rules of node style callback params, where the first one should be err and then data. It seems this does return only the data, which promisify understands as an error and does throw right away. Instead do what the node js docs suggest too and use fs.access instead, like so: promisify(fs.access)(aPath, fs.R_OK). See it in action [here in the cosmowiki].

I had been fighting for the last years, always again to make WebStorm run all my tests the way I want. I moved tests into the src folder then back into a tests folder. The latter is painful, since I have to keep the structures of two folders in sync that way, which is just inefficient, especially when I refactor so much, which I think is simply necessary and the right thing to do.

My laziness actually pulls me strongly towards #noEstimates. I guess it's because the "no" means I have less work to do. Which I could kind of back up with the argument Robert Weissgraeber gives at the beginning of his talk, which is that we should remove all unnecessary work, all waste.

Uncle Bob nicely shows the parallels between accountants and TDD. One value gets put on the asset side and the other on the liability side, they add up to be 0. And then he questions why accountants meet their deadlines, even though they do things twice. Accountants do this for five hundred years, its a "law". We still need to get there with TDD, but we are on the best way and I second that and try to do my part with the JSCodeRetreat.

C# has a way better expression for what we write in JavaScript like so obj.method && obj.method() and in C# you can do obj?.method() which is pretty slick I think. See this video (in german) for a short explaination.

In the paper "Design Patterns for Sorting", the internals of how to implement a decoupled version of a sorting algorithm is described. It also shows that the complexity of something like a quicksort is not necessarily high, which should remove the fear of just trying out to implement it.
Maybe that's a good idea for a kata, that might go into the katas repo.

RethinkDB is a topic that I had been investing some time into, because I tried to figure out which DB to use for cosmowiki. What convinced me about: it is a DB which offers the best of both worlds, the NoSQL world (schema "freedom") and SQL DB's relational data. RethinkDB has joins built-in as one of the core features. Besides built-in joins it claims to have a very simple scale out mechanism and almost magic, transparent fail-over since version 2.1.

My pet project ES6 Katas is a playground for learning, if you look in the repo you see lots of things moving around and changes made. Most of it is because I try to apply new learnings and try to get to a structure that really is what I consider good software. Lots of new bits of information I learn I try to apply there or at least play around with it and figure out what's a better way to do things. This often might end up in a forth and back of things and in not being able to decide what is right, and it looks like nothing moves forward, but that's just on the surface.

Unfortunately I missed Franziska's session at SoCraTes 2015 on this topic, but fortunately she wrote about it, make sure to also read through her commits backwards, of course :). Very nice and readable! An article "Kickstart your next project with a Walking Skeleton" she referred to, that explains the process too. While reading more and more of the [c2 wiki] I am asking myself where is the difference to a spike which Kent Beck defined as

In this talk, Uncle Bob starts to set the context for why our industry has a hard time catching up with the speed and also why it is so important that we do spend more time on mindfully constructing software. It's worth spending those 1,5h watching this talk, or less if you 2x the video speed :).

On the famous c2 wiki find "Alan Kay On Messaging". His words are from the year 1998 and still so true. And I am only close to the beginning of really understanding. But I have to, as usual, extract some of the key points for me. Make sure to read the entire message anyways, it's really very short!

The new dojo? I started with dojo about 10 years ago, or so. Now I see reapp which seems to be the same as dojo, lots of widgets, just around react and transferred 10 years ahead and to mobile.
Good stuff? Or not?

With typeslab.com you can write poster like text.

I first heard @bodil talk at the 2014 craftconf in Budapest where I saw her presentation where she was live coding in at least 10 languages on stage.

Any browser project should have a look at DOMPurify at least, if not apply it right away. This might not be what you want to apply right away, but maybe it triggers you to learn more about this field, when security issues hit you it might be too late.

For TDDBin I was just looking for all the icons to use on the website, icons from github, trello and twitter to embed them. And I found out that the collection of those images/graphics are called brand assets. Next time you search for them, don't use the term logo, use "brand assets".

It's not additional synthesis, as I would interpret the headline first, but it's pretty hard core cool what is possible in the browser already.

Not sure if I will ever get bash right, but little helpers like this explaining how "if" works are always helpful (to me).

I wanted to just push my source code to github's master branch and all the deployment after that shall be automatic. Every dev-op reading this will say "yeah sure, wtf?".

As often as I look for this, I need to write it down. For example for my fork of github:dropping-spray, which got inspired by this tweet and the following discussion.

If you want to dive into cookies, here is the RFC6265. I was looking around for some decent cookie libraries. There seem to be some of them.

I asked myself what branch rebase refers to. The one I want to rebase on or the one I want to rebase from?

Links about naming things

I was about to write a "Handler" class. But I remembered that the "er" classes are not so good.

Refactor to functional

I read it first in my personal trending twitter search, then I saw it on hacker news and I pulled the repo and being intrigued by the minimal size, compared to react and polymer I thought I try out the demo, didn't work. So I looked a the code, very opinionated. My conclusion after having spent about just 1h on it I summed up in this tweet.

I have to read this, I just want to parse the data a bit and I fail. I smell that I don't get the concept fully yet, or that I am using it in a different way than it's meant.

In order to keep all your meta data of your project in one place and only create files that actually just copy those data you can use projectz where you maintain data like title, description, author(s), badges, ... in one CSON file and with a special markup you can update fill in the templates files like README, package.json, ...


Lately they don't turn out so good, or is it my blurred vision?


I really appreciate the things I learnt from Erik Meijer, but I am not so sure I can follow all his opinions.

Mocks Aren't Stubs

IDEs are awesome, but sometimes in my way and setting up test runners sometimes defeats the purpose of being fast with tests, which also means having feedback constantly and continuously.