NPM: windows-build-tools

node-gyp is really useful and annoying. npm install fails if Python 2.7 and a C# Compiler is missing.
You could use choco to get and install the missing packages or simply install another npm package:

npm -g windows-build-tools

will install Phyton 2.7 and the Visual Studio Build tools that are required by node-gyp.

Posted by happyneal in NodeJS, Programming, 0 comments

The Joel Test – 12 Steps to better Code

The Joel Test

In essence, the test is a quick 12 yes/no Questions that allows you to quickly determine how good your development workflow really is.
anything below 10 and you are usually in big trouble in the long term.

Now let’s go a little deeper into the questions and what you would need to do to fix these issues. At the end, I put a list of my revised questions.

1. Do you use source control?

Now in reality, if this question is answered with “No” you are royally screwed. If this is answered with no, then stop right now and take a look at git.
Even when you are working on your own project that does not be synced with a remote repository you should use git.
It is easy to set up and there are a lot of providers like Github, Gitlab, Atlassian Bitbucket if you need to sync it over multiple computers.

The bigger question that relates to this is: “Does every team member understand the Source Control workflow?”
The most popular workflow is the GitFlow it is easy to understand and new team members can understand immediately what is going on.

Does your Source Control integrate directly into your build system?

2. Can you make a build in one step?

In most modern development projects this is not enough. If you are doing a Web Development Project, you can use tools like nodemon (Auto reload for NodeJS) or Hot Deployment (Auto reload for Java / Tomcat) to ensure that you constantly build your server. Similarly, you would use something like the webpack-dev server for the frontend.

What I am saying is, you are anyway constantly doing builds of your software. The bigger question is can you also deploy your build without effort? It does not have to be onto a production system, but it could be a testing-server or some other staging system. So when you have to deploy to production you can ensure that it is as hassle-free as possible?

3. Do you make daily builds?

The question should be “Do you deploy daily?” – Whatever you are creating needs to be seen by as many eyeballs as possible. So that the Feedback can get back and influence the development as early as possible. Also, the client should profit from improvements as fast as possible.

This, in turn, does not mean that you should skip testing or quality assurance. It only means that stuff that is production ready should be shipped as soon as possible.

4. Do you have a bug database?

Now bugs are bad, and you need to know about them as well as which features you want to create for your product. So the more pressing issue is how are you tracking all of the development efforts you are putting into the project.

Instead of a bug database, you should have an issue tracker like JIRA or the integrated bug tracker from Gitlab.

The other thing to consider is a dedicated website for “Help us improve our product..” or a publicly accessible “bug database” so everyone that is using your product can easily report issues they are having with it.

5. Do you fix bugs before writing new code?

Well nothing to add here, fix your product before shipping new features. This is more an issue of business intent vs development.
Usually, Sales will pressure you to ship faster and will try to cut corners. However, this practice is very expensive in the long run, as customers expect high-quality software. By Apple advertising their products as “magic” the expectation of high-quality software is now the norm. Cutting corners and not fixing bugs is no longer an option. Customers that have the feeling the software is buggy will look for another piece of software that has a higher quality.

On top, of course, is that the longer the bug exists the more money it will cost to fix the bug. So there are enough incentives to first fix bugs and then move on to the new features.

6. Do you have an up-to-date schedule?

Programmers hate schedules. It does not matter if you are ‘agile’ you need to estimate the work you are doing and match it with reality. Only then you can ship things with confidence. Developers need to learn to make a schedule for themselves and not work 14 hours a day just because they did not finish.

But what about extra features? well yes that is called scope creep and yes that needs to be regularly discussed and the schedule adjusted accordingly.

7. Do you have a spec?

You need a spec to start any work. If it is not specified it is unclear what you should build.

That is not an excuse for not specifying exactly what you need at this moment.

8. Do programmers have quiet working conditions?

Now this one is critical for every developer. However ‘quiet’ refers more to that the developers are not constantly interrupted.
Have rules like: google it for 5 min before asking a fellow developer. Interruptions of a programmer can cause delays of up to 30min per distraction.
To have efficient developers do not interrupt them and let them listen to whatever music they want.

9. Do you use the best tools money can buy?

Every developer has his own personal preferences, allow them to use the tools that they want.
Some of the most awesome tools available VSCode is a free tool. Other things like JIRA, and IntelliJ are well beloved and cost a monthly fee. This money is well spent if the developer is happy and gets support from an industry leading tool.

I have seen Java Developers that switch to IntelliJ that were then up to 20% more efficient as before. The program drastically improves code quality and speed in which you develop code. In addition, it has the feature “Inspect Code” that analyses the code for potential quality improvements etc.

10. Do you have testers?

testers should take a look at the software. This includes automated tests, Unit Tests etc. You need to have a Test suite set up to be sure that changes do not affect other parts of the software.

Human Testers should also take a look to ensure that even really unexpected situations do not make the program crash.

11. Do new candidates write code during their interview?

This is a very important thing. HR People have no clue about coding, they cannot evaluate if the developer is suitable and can be integrated into the current team.
By enforcing that you need to code in the interview somebody from the dev team needs to be present. That means he also can evaluate the potential hire, plus the potential hire can show off that he has some skills.

This, however, is widely misinterpreted by companies. Some companies have an exam that is more like “find the missing ‘;'”, or other similar trivial mistakes that are found instantly by a compiler.
Or in another case a company wanted me to complete a task that would require 2days of development effort.

The programming task should be something that is simple and relates to the position the developer is applying for and that can be done during the interview, so it must be short.

12. Do you do hallway usability testing?

“Eat your own dogfood”, people in your company should be able to use the product without any explanation of it.
If your own employees cannot use the product or understand what is going on, how should they sell it to a customer?
It builds confidence in the dev team that you are doing the right thing and that other people (non-developers) understand what is going on.

Only other Developers are interested in what awesome code you have written. Normal People only care about if they can use the program.
Usability is key to any successful piece of software.

The Joel Test V2

  1. Do you use source control? (Does every team member understand the associated workflow?)
  2. Can you build and deploy in a single step?
  3. Do you deploy daily?
  4. Do you have a ticket system for features, bugs, maintenance?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule and devs schedule/estimate their work?
  7. Do you have a spec?
  8. Do programmers have a quiet / interruption-free working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have Quality Control (Automated Testing, Human Testing)?
  11. Do new candidates write code during their interview?
  12. Do you do usability testing?

Source: The Joel Test: 12 Steps to Better Code

Posted by happyneal in Programming, 0 comments

Puppeteer.JS – Using Headless Chrome for Site Crawling

PuppeteerJS essentially allows you to automate Chrome.
Headless Chrome allows you to run Chrome without actually rendering the webpage. Sounds silly, but has a lot of useful applications, you could for example simply write a test script that ensures that your website is still working correctly.


npm i puppeteer
# or
yarn add puppeteer


We are going to look at a quick example of how to log In to a site and then do some operation.

Inititalize Puppeteer

You need to run it in an async function, simply because you do not know how long it will take until chrome has started.
so with

We start our browser. The flag headless is set to ‘true’ as default, however for debugging purposes, you should set it to ‘false’;


To Login into the site we need three things:
* The URL for the Login Page
* CSS Selector for the Username Field
* CSS Selector for the Password Field

To obtain the the Selectors you can use the Chrome DevTools (F12). Simply select the HTML Field and with Rightclick select Copy Selector.

Fetch all Links

Now since you are logged in to the site, you can navigate to any site and fetch all the links.

Final Code

Posted by happyneal in Blog, Web Technologies, 0 comments

WebDev – Articles – 02


The engineer’s guide to not making your app look awful

4 Surprising Reasons to invest in UX


The licencing of React will change with Version 16 it will be a MIT licence.
Release of ReactJS 16


IBM J9 joins Eclipse Foundation as OpenJ9
In essence OpenJ9 is an Alternative to the OpenJDK you can use for enterprise Applications.

Oracle Java EE joins Eclipse Foundation
While the exact date when Java EE will join the Eclipse foundation is not known. The move will happen some time after the completion of Java EE 8.


Material Palette

A website to test out various color shemas for your Material UI based Design
Similar to Adobe Kuler

Atom IDE

To play around with this new Package you need Version 1.21 (Currently Beta):


Posted by happyneal in Web Technologies, 0 comments

WebDev – Articles – 01

A short summary of some of the interesting articles I came across in the last couple of weeks.


Most Important Color in UI Design
A very interesting article on the Color Blue and why it is used so much.


Canary 62 Dev Tools

One of the highlights of the new Dev tools is that you can capture screenshots of a specific node.

  1. Select the Node
  2. Open the Command Menu (CTRL-SHIFT-P)
  3. Type ‘capture node’

VSCode 1.16

  • HTML now finally gets autoclose tag. However it is not enabled for JSX, so you still need to install the Auto-Close-Plugin
  • Support of Typescript 2.5
  • Faster Refactorings for Typescript, by selecting a Code Segment you can rightclick and say “Extract Function”


A useful tool to detect which technologies are used by a specific website.


Edge Insecure by Design: Bypass Content Security Policy (CSP)
A reported Security Issue that effects Safari, Chrome and Edge, got fixed in Safari and Chrome. Microsoft responds: Works as Designed.

Random Articles

Trending Developer Skills based on Job Descriptions
An interesting way to take a look at the vacant Job Positions and concluding which technologies are currently being used for the Production Stack.

(tl;dr: Rapid Rise of React, NodeJS and Postgres)

Why Coding Style Matters
A short article about the benefits of a clear and consistent coding style.ama
“Programs are meant to be read by humans and only incidentally for computers to execute.”
— H. Abelson and G. Sussman (in “Structure and Interpretation of Computer Programs”)

Posted by happyneal in Blog, News, Programming, 0 comments
VSCode: Launch create-react-app and Chrome with launch.json

VSCode: Launch create-react-app and Chrome with launch.json

Developing React (with create-react-app) and Visual Studio Code you usually press ESC-` and then npm start.
The script from create-react-app then automatically starts a Browser. That you then close.
hen reopen by pressing F5 to start Chrome in debug mode.

Let’s make these steps a little quicker.

Create a Task for npm start

Press Ctrl-Shift- and Select “Tasks: Configure Default Test Task”
This will create a tasks.json file.

In the tasks.json file you need to add a couple of values:
* isBackground: true – launch.json will not wait untill the task completes
* problemMatcher Needs to be defined to figure out when the task has completet its initialisation phase and it is safe to continue with the next task

Configure create-react-app

To prevent launching the browser you need to add in your .env-file following line:


More Info:
* .env-file

Configure the Launch.json file

Press F5 and select Chrome and a launch.json file will be created.
* Change the port to 3000 (create-react-app default)
* Add a preLaunchTask to start the task we defined earlier

Start Working

Tadaa, now you press F5 and can start debugging directly in vscode. The background task will continue running even when you stop debugging.

Stop Working

You need to terminate the task via ctrl-shift-p > terminate Task. (Or you just close vscode)

Posted by happyneal in Blog, Web Technologies, 0 comments