Trying out a new technology can be a bit tricky. Whether it is a new programming language or a new framework, the only way to really properly try it out is to have a project or a goal — something you want to accomplish with it. Otherwise it really isn’t possible.

Since I like playing around with new technologies, I came up with a spec sheet for a test application that I always try to write when I feel the urge to try something new. It contains a list of standard features that I have built over the years for multiple other projects using languages and frameworks I am familiar with. I know how they should work and therefore have a better basis with which to judge the technology’s capabilities, ease of use, etc.

The Specs

First off, let’s take a look at the specs. The test program is usually a basic, headless web application that includes the following basic features:

• A server
• Controllers with the following endpoints:
  • GET (JSON response)
  • POST
  • PUT
  • DELETE
• Configurable redirects
• Database read and write
  • The API controllers will interact with the database

Optional Specs

If I am really enjoying the technology or framework, I will often want to dive a bit deeper into it. These are some of the features I will explore in this case:

• Controllers that return rendered templates
  • Support for multiple languages in rendered templates
  • Markdown rendering including support for code syntax highlighting
• Authentication
  • User registration
  • User login
  • User logout
• Automatic SASS compilation (similar to https://github.com/eiskalteschatten/compile-sass)

What I Test

When I set off to test something new, I am looking to see what it is capable of and how easy it is to use as a developer. Does it perform well? Is it unnecessarily complicated to set up? Or is it complicated because it is feature-rich? How mature is it? How much support does it have online? Is it regularly updated? And so on.

Sometimes the result is that the technology is not really ideal for my test scenario. Since I am primarily a web developer, that is my primary focus. Going into a test, I sometimes know that the technology usually isn’t used for web applications (C++, for example), but that doesn’t mean it can’t be fun to try.

Conclusion

One question I haven’t addressed here yet is why I test new technologies. I do it because I like trying out new things. By nature, I am a curious person who is never able to just settle on just one, single technology stack. I like experimenting and I enjoy comparing what I know to new things I don’t know yet. I feel that it makes me a much more well-rounded developer.

As mentioned above, I chose these specs primarily because they are common features in web applications and because I have already built them in other projects. That means I have a basis which with to judge a new technology. I know how they should work and I know that any web application will need to have this standard set of features to be of much use.

This article originally appeared on Alex’s Notebook.

I don’t like clutter. In fact, I am very picky about what I install on my computer which is one reason I love virtual machines (VMs). They enable me to install all sorts of things to try them out and then, when I feel like the machine has become cluttered, I can just delete it and start anew without any risk of data loss.

The reason I mention that is because I like to try out new programming languages and frameworks which always involves installing new runtimes, compilers, libraries, IDEs (and/or plugins), etc. I like to experiment. Most of the time when I try one out, I end up leaving it installed for a while, but rarely use it again. That means I forget about it and eventually the unused installations fossilize and turn into layers of sediment that build up over time.

Not really, but you get the picture.

To prevent this, I use a virtual machine. Any new programming language, tools, etc I want to try first get installed in a virtual machine. The majority of the time, I use it for a short while and then stop. At some point, I will delete the VM with its fossilized runtimes and compilers and start again.

There are, of course, exceptions. If I notice I really enjoy a specific language or a particular editor, I will install it on the host machine. This is exactly the process I went through when transitioning most of my personal development from PHP, to Java, then to Node.js, then to TypeScript. These subsequently made their way from the VM onto my host machine since I use them all of the time.

The Operating Systems I Use

Needless to say, I use Linux in my virtual machines. It is free, there are several different flavors and it just simply works. Not to mention, other than maybe a few Microsoft technologies, most development tools, languages, etc are made to run on Linux. You can install them without a hassle and they just simply work. I’ve found this is especially important if you just want to try it out since a miserable experience getting everything to work would negatively impact your first impression.

My host machine is a late 2013 model 15″ MacBook Pro. And yes, it is that old, but I bought the top-of-the-line model at the time and still don’t feel the need to upgrade yet. It runs the latest version of macOS (as of this writing 10.15 Catalina) and has been a very robust machine that has served me extremely well over the past seven years. I will probably use it until it dies.

But back to Linux.

Not only do I like to try out new programming languages, I also like to try out new flavors of Linux. That means almost every time I install a new VM, it is not what I had before. Sometimes it is a Debian-derivative such as Ubuntu or Debian itself, other times it is a RHEL-based flavor like Fedora or CentOS, but sometimes I also feel like OpenSUSE or even Arch Linux. And even if I keep the same flavor, I almost always choose a different GUI. Sometimes Gnome, sometimes Xfce, sometimes KDE, and so on.

VMs are, of course, absolutely ideal for this. It would be a nightmare to constantly try to install new versions of Linux on bare metal — especially if you require wireless internet like I do.

Since I am constantly starting a new project, I got tired of always having to set up each web app from scratch. Therefore, I decided to create a couple of boilerplate apps in Node.js and TypeScript.

If someone had asked me five years ago if I would ever become a full-time JavaScript developer, I would have looked at them and laughed. At the time, I was deeply entrenched in the PHP and Java worlds and for me, JavaScript was something that was only done in the frontend.

A little less than five years ago, however, I began a new job and was introduced to the world of server-side JavaScript via Node.js. Shortly thereafter, I started with TypeScript which over the years has become my language of choice for web projects.

But this isn’t an article about my transition to JavaScript. I mentioned those things simply as a preamble for why I felt the need to create Node.js and Typescript boilerplate web apps.

So Many Projects

At any given time, I have at least 3-5 personal development projects going on at once. It’s hard for me to stick to a single project because I always have new ideas that excite me and that I want to try out. I have been doing this continuously for the past two decades.

My first projects were in ASP, then ASP.NET when .NET was first released. I then transitioned to PHP and eventually to Java. Now my language of choice in TypeScript.

Since I am constantly starting a new project, I got tired of always having to set up each web application from scratch with the basic functionality I needed. Therefore, I decided to create a couple of boilerplate applications that I can just copy and already have the basis for the new project without any additional effort.

The Applications

The first boilerplate app I created was written in plain Node.js. That was before I discovered TypeScript though. I then copied it and created a TypeScript version.

Both are based on Express.js and contain the following frameworks:

• TypeScript (for the TypeScript version)
• Express.js
• Express Enrouten
• Nunjucks
• Bootstrap
• jQuery
• compile-sass (based on node-sass)
• Moment
• Marked (for Markdown)
• Highlight.js (for code highlighting)
• Matomo (for tracking with Matomo)

Since then I have maintained both on GitHub updating the packages and making sure they always run with the latest versions of Node.js and TypeScript.

Features

An important part of the boilerplate apps for me is the features. Most of my projects need a certain set of features to get started which is why I made sure these boilerplate apps have them.

Here are the features I have included in them:

• Automatically configured controllers based on Express Enrouten
• SASS files compiled on page load when NODE_ENV=development
  • For all other environments, SASS files are automatically compiled and saved into CSS files in the public folder on the hard drive on application start.
• Support for websites in multiple languages
• Markdown rendering in Nunjucks templates or controllers
  • Including support for code syntax highlighting
• Server-side page tracking with Matomo
• Configurable redirects
• Ability to create proxy routes (i.e. for frameworks like jQuery which appear in the node_modules folder) so that they have an URL accessible from the browser such as /js/libs/jquery.min.js)
• Automatic TypeScript compilation and server restart when developing
• Pre-made Dockerfile

Before creating the boilerplate apps, I had to set all of that up each and every time for every project. It took a lot of time and I often lost interest in the project before I could even actually start with the project idea itself.

Conclusion

The boilerplate apps have formed the basis for business-critical applications at my various jobs as well as for my own personal websites. I continually update them with bug fixes and code changes as I learn new ways of solving old problems or have new feature ideas.

Of course, it was a no-brainer to me that the boilerplate apps should be open source, so they are available on GitHub here:

TypeScript: https://github.com/eiskalteschatten/typescript-webapp
Node.js: https://github.com/eiskalteschatten/nodejs-webapp

This article originally appeared on Alex’s Notebook.

Node.js + Docker + WebStorm is not an unusual setup for Node.js developers, but there is nonetheless surprisingly little information available about how to setup debugging in WebStorm while running a Node.js application locally in a Docker image. Fortunately it is very simple to setup and the benefit of having real debugging is something that will save the developer a lot of headaches and development time.

This tutorial will walk through how to setup general Node.js debugging inside of a Docker container that can be used by any tool that offers debugging. Then we will walk through how to set it up in WebStorm specifically.

Setting Up Docker and Node.js for Debugging

The first thing we need to do is tell Node.js that we want to run our application in debug mode. This is accomplished by simply adding the --inspect flag to the node command as follows:

node --inspect src/index.js

Of course since the application is running in Docker, that will need to be accomplished by adding it to the command in your Dockerfile. We also need to expose the standard debugging port, 9229, so that our debugging tool can access it. The Dockerfile could look something like this:

FROM node:14-alpine
EXPOSE 9229
CMD ["node", "--inspect=0.0.0.0:9229", "src/index.js"]

If you are using Docker Compose, the configuration looks a little different and should take place in your docker-compose.yml file. Here is an example of what it should look like:

version: '3.7'
services:
  app:
    build: .
    command: node --inspect=0.0.0.0:9229 src/index.js
    ports:
      - "9229:9229"

Now that we have prepared Node.js to run in debug mode within the Docker container and exposed the correct port, we can setup WebStorm to take advantage of it. Other editors and IDEs can most likely be setup in a similar fashion, but check the specific documentation for your editor or IDE for details.

In this post, I talk about which productivity tools I use for my work as a developer, my personal development projects and my personal life.

Like so many other people out there, I have a lot to do. There is always some project that is calling, some person needing an answer from me, some book that is begging to be read, some piece of writing that won’t compose itself, etc. Over the years, I have tried a large number of different methods for organizing myself and increasing my productivity. These range from digital solutions that promise to be the ultimate tool to increase one’s productivity to simple analog solutions using pen and paper.

And yet none of the tools I’ve tried have been that promised be-all and end-all solution that magically boosts my productivity. 

I have, though, managed to narrow it down over the years to a specific set I use depending on the type of task at hand. In this post, I am going to talk a bit about which tools I use in which contexts with the intention of hopefully helping someone choose the right one for their needs.

Moving from Analog to Digital

Last year, I switched from a largely analog organization system to a fully digital one. For years, I used paper planners with a weekly format that had the days on the left and a blank page on the right side of the spread which I would use to plan my to-dos for the week. This list of tasks I would transfer from week to week which was tedious, but since I had to do it by hand, it meant I re-evaluated each and every item on the list every week. Through this method, unimportant to-dos would eventually be dropped entirely freeing up both physical and mental space for more important things.

This system worked very well for a long time. Then I started a new job where I got a new iPhone, a new iPad Air with an Apple Pencil and a new MacBook Pro. I’ve had various smartphones and tablets over the years, but with the excitement of the new equipment, I decided to finally make the plunge into an all-digital system.

I am proud to announce the opening of Developer’s Notebook. The intention behind this project is to provide a place where developers can find interesting information about topics relevant to programming.

The primary focus to begin with will be web development with a particular focus on the world of Node.js and TypeScript as well as several of the frameworks and libraries in their ecosystem. As time goes on, however, more languages and topics will be added.

You might be asking why another website for developers is needed when there are so many already. The answer to that is simple. It isn’t.

However, there is such a large number of topics of interest to developers that the list is almost inexhaustible and since I enjoy development as well as reading and writing about technologies, I decided to start my own website. I write in my free time and all costs come out of my own paycheck.

As such, a donation would be much appreciated if you enjoy the website.

I hope you enjoy Developer’s Notebook and any feedback would also be greatly appreciated.

To get started, take a look at our posts, or to find out more about Developer’s Notebook or the technologies powering the website, take a look at the About page.