André Kwakernaak

C# to JavaScrip cheat sheet

Mon, 02 Apr 2018 00:00:00 +0200

This is an opinionated and incomplete Cheat Sheet for developers familiar with C# who are learning JavaScript.

I have been working with JavaScript for the last year or so, and created this Cheat Sheet in the process.

String.IsNullOrEmpty

C#:

string.isNullOrEmpty(s);

JS:

_.isEmpty(s);

lodash:isEmpty

String.IsNullOrWhitespace

C#:

string.isNullOrWhitespace(s);

JS:

_.isEmpty(_.trim(s);

lodash:isEmpty lodash:trim

LinQ Select

C#:

var l = new List<int>{1,2,3};
l.Select(i => i * 2);
// => 2,4,6

JS:

_.map([1, 2, 3], i => i * 2);
// => 2,4,6

lodash:map

LinQ Where

C#:

var l = new List<int>{1,2,3};
l.Where(i => i % 2 != 0);
// => 1,3

JS:

_.filter([1, 2, 3], i => i % 2 !== 0);
// => 1,3

Lodash:filter

LinQ Any

C#:

var l = new List<int>{1,2,3};
l.Any(i => i % 2 != 0);
// => true

JS:

_.some([1, 2, 3], i => i % 2 !== 0);
// => true

Lodash:some

List Contains

C#:

var l = new List<int>{1,2,3};
l.Contains(2);
// => true

JS:

_.has([1, 2, 3], 2);
// => true

Lodash:has

Thoughts after 6 months of using Docker

Wed, 27 Sep 2017 00:00:00 +0200

For the last half year I have been using Docker to deploy an application based on micro services. I learned a thing or two in this period which I try to share in this post. A lot has been written on using Docker and best practices. I still decided to write this since I encountered a thing or two I did not see coming.

You probably should not use binding mounts in production

Docker allows you to mount files or directories from your host system in your container. This can be used to make configuration available in your container. In my situation I had configuration of a Logstash pipeline in a repository on my host system and mounted the configuration in a Logstash container. This works just fine. However, the moment you want to scale your application to make use of multiple machines to run the Docker stack, you run into issues.

The files that needs to be mounted in a container, have to present on the host that runs that container. This makes your deployment more complex, especially when using multiple host in a swarm.

Another problem with mounting files in a container touches on one of the main principles of Docker and containerization in general. A container should contain an application along with al of its dependencies. This way a container that runs correct in a test environment should also run without problems in production. When an application (or component, micro service, or however you want to call it) needs a configuration file to work, that configuration should be part of image.

Of course, you most likely will have some configuration which differs between test and production environments, like IP addresses or host names. A common approach to configure these is through environment variables. Environment variables are very well supported in the Docker eco-system and offer quite some flexibility.

Alternatively configs from Docker Swarm can be used to create, share and update configuration of your Docker Swarm services. However, consider what configuration you put in these configs and favor configuration that is part of your image.

Take continuous integration to the max!

The process of creating a Dockerfile, putting it under version control, building the actual image, and pushing it to a registry sounds like a lot of of work. However all those tasks can be automated quite easily. With some scripting and a buildserver like Jenkings, you can take this to the point where a commit on a repository, results in a new image being build, the application being deployed on a test environment and automated tests being run.

This approach simplifies the whole process drastically and removes all barriers of using Docker images to deploy your application.

Docker on Windows is not production ready

I started out using Docker on Windows for the application I worked on. This might not be the most obvious decision, after all Docker originates from the Linux eco-system. However part of the server application still had to be deployed as Windows service for the time being. therefor Docker on Windows made sense. After some months the switch to CoreOS was made for a plethora of reasons…

Docker on Windows is buggy. There I said it. I have observed random crashes and a lot of weird things. Settings that get reverted to default for no obvious reason. The GUI indicating 10GB of RAM allocated while in practice the virtual machine only had 2GB. And I don’t know how many times I have re-installed the Filesharing service on my network adapter to fix file sharing.

Updates to Docker on Windows are released quite frequently, so the situation described above can change quickly, but for now I would stronly advise against using Docker on Windows.

Docker is an awesome technology stack!

Docker is truly awesome technology, it is really versatile in ways it can be applied. It is not limited to deploying ‘enterprisy’ applications based on micro services. Docker is great to create development setups that you can share with your, if it builds on one machine it builds everywhere.

Instead of documenting a development setup you can create a docker-compose.yml that setups a database, webserver and whatever you need to run and compile your application. Automate all the things!

A fun use of Docker is to use it to ‘install’ applications for regular desktop use. One example is Cyberchef “a web app for encryption, encoding, compressioni and data analysis”, which you can get up and running locally with: docker run --rm -it -p 8000:8000 mpepping/cyberchef

Looking for more info on Docker?

This is a great place to get started. Awesome Docker is a fantastic collection of resources.

Lessons from a dev

Tue, 13 Jun 2017 00:00:00 +0200

I have been working as a software developer for the last eight years or so. In this time I have worked at a bunch of different companies in different industries and environments. Through success and lots of failures I have learned a lot. In this post I try and share some of those lessons.

1. It is probably your fault…

Developers have the tendency, after investigating a bug, to blame anything or anybody but their code. I have blamed hardware, Operating Systems, drivers, third party libraries, or code from colleagues. Guess what, most of time the bug was in my code. A humbling thought, but once you accept it, it saves you from going on a ghost hunt in that third party library, when you just should be looking at your own code.

2. Naming things is the hardest thing

When writing code we have to come up with names for a lot of things, functions, methods, classes, variables etc. Names are perhaps the most import factor in what makes code readable and easy to understand. Names provide the semantics to your code, and gives it a context. Without proper names, understanding a piece of code is an extremely difficult task. Think about those names, care for proper names and spent time to come up with good names!

3. Git everything!

Every thing you write should be under version control, be it a quick script for this one task, configuration files, or a small test program to try something new. If it is worth writing it is worth to be under version control. It will help you tremendously figuring out how a bug got introduced, what config change caused your program to misbehave, or one year from now figure out why you did made some change. There is really no reason not to use Git.

I mention Git here, any version control system works, but Git is quick and easy to create a new repository. Not familiar with Git? Have a look here.

4. There is a best way

I once gave a pack of stroopwafels to a colleague visiting from abroad. The next day he told me he he had a stroopwafel and really liked it. He also told me that he searched Google on how to eat a stroopwafel. Than he eat it the proper way, place the stroopwafel on a hot beverage, and let the syrup in the stroopwafel heat before eating it. The fact that he went on Google to search for the best way to eat a cookie baffled me, it a cookie after all. But he knew there must be a best way to eat a stroopwafel.

I think this holds true for almost anything, there is a best way to do a certain thing and someone probably found and described the best way. Here is how tie your shoe laces and this is the best way to make your bed. In the field of software engineering this holds true as well. There are best practices identified within the community, idioms for a language or framework that should be followed. Take your time to search for the best to do things, it almost always pays off.

5. Know your tools

As a developer you will use a lot of software on a daily basis. Operating systems, IDE, debugger, browser, Wireshark, Git, Bash, SSH you name it. It is really worth to learn the tools you use. Make use of cheats sheets to learn shortcuts, check out which plug-ins are available, read tutorials and spent some time searching online to get the most out of your tools.

I created a quick list on some of the things I use on a daily basis that are really helpfull to me, yet are not that well known.

Chocolatey Package manager for windows.
ssh config file Do you use ssh? Check it out.
Respeller Spell check plug-in for Resharper.
Git-extras Set of useful commands for Git.

Learn your tools! They help you do your job as efficient and effective as possible. They empower you.

Importance of a decent password strategy

Mon, 13 Feb 2017 00:00:00 +0100

Passwords are the main thing that protect your online valuables, be it your emails, Facebook account, or your PayPal. Do you pay enough attention to the strength of your passwords and do you do everything possible to keep your passwords secure?

In this post I’ll explain why you need to think about your passwords, some of the risks your passwords are exposed to, and describe my password strategy.

Risks

We have passwords everywhere, your e-mail account, social media, web shops, you name it. So what risks are these passwords exposed to?

Weak passwords

The passwords could be weak. Anything found in a dictionary is a weak password, anything under twelve characters is weak. Passwords can be guessed by attackers, often in a automated process.

Password reuse

Since we have entered passwords everywhere, we rely on the security of each and every website to keep our password safe. Unfortunately websites get hacked regulary. Big names like LinkedIn and Adobe are among those hacked websites.

When a website is hacked and the attackers got their hands on the user data, they could gain access to your email and password. The first thing attackers will try is to login on your email, using the password that was leaked. If they succeed the ramifications could be huge. Next they might try to login on PayPal, if they succeed you can probably imagine what will happen next…

In order not having to rely on a third party to keep your password safe, we need to have a unique password everywhere. I know, that might sound like a nightmare, remembering dozens of unique passwords. Don’t worry you end up needing to remember only one password!

Password managers

A password manager stores all your passwords in a safe manner. Password managers come in two forms, an app that you install on your laptop or phone, or in the form of a website offering this service. Using a password manager requires you to remember one strong password, the password manager will remember all your other passwords! And perhaps even better, you never have to think of new passwords again. A password manager can generate strong passwords for you.

Lastpass is a well known password manager website. Yes, when using a service like Lastpass you put a lot of trust in that service. However it is their core business and they will work hard on keeping your passwords safe.

Keepass is an example of an application that you have to install for it to manage your passwords. It stores your passwords in a single file. This file is encrypted using your password (I should say pass phrase, more on this later) so using a strong password is essential. If someone gets their hands on your Keepass file, he or she can not do anything with it, unless they know your password.

Strong master password

When we make use of a password manager we only have to remember one password. Since this password will protect all other passwords it needs to be very strong. What makes a password strong? It should be long and unique dictionary. Note that I do not mention ‘should contain special characters’, password length is way more important than whether or not it contains special characters. A well known method to generate strong passwords that are easy to remember is the Diceware method. With this method you can generate a pass phrase consisting of multiple words which is fairly easy to remember. Instead of using dice you could use this generator. Make sure to read the ‘Is it safe?’ entry in the FAQ.

My password strategy

I use Keepass as password manager and store the password database in my Dropbox so I can easily access it on my phone, my laptop and my system at work. This is safe since the password file is encrypted. My master password is created using the Diceware method and consists of seven words. Whenever I need a new password, Keepass generates and stores it. Besides my master password I know the password to my email account, in case I ever need to reset my Dropbox account to gain access to my Keepass database.

Think about your password strategy

If there is only one thing you take away from this post I hope it is that you think about your password strategy. Do you already use a password manager? Is your master password strong enough? If so, great! If not, make some changes!

Using Vagrant to create Ansible playbooks

Tue, 03 Jan 2017 00:00:00 +0100

Recently I have been using Ansible to provision and manage a couple of servers. Developing playbooks for me involves some trial and error. Having some kind of playground to quickly test and experiment is a real time saver!

This post describes my setup for developing Ansible playbooks.

What is Ansible?

Ansible is a tool to help you manage and provision your Linux installations. It automate installations, script migrations, etc. Basically it allow allows you to script everything that needs to installed or configured on your servers. More info can be found here and here.

What is Vagrant?

Vagrant describes itself as follows:

[…] the command line utility for managing the lifecycle of virtual machines.

source

Vagrant allows one to quickly create virtual machines (VM) in a reproducible manner. See here on how to get started with Vagrant.

Combining Ansible and Vagrant

Combining the ability to quickly create VMs that allow access over ssh, along with utilizing Ansible to provision those VMs makes for an ideal development environment for Ansible playbooks. One can create a VM, run a playbook, and check the result. Make edits to the playbook, rerun the playbook on the VM, re-create the VM and start from scratch.

Vagrant supports Ansible out of the box as a provisioner which is really convenient.

Prerequisites

This post assumes a Linux host system. The following needs to be installed:

Vagrant (1.8.5)
VirtualBox (5.1.6)
Ansible (ansible 2.3.0 devel bec9ebbf30)

The version numbers above are the ones I used when writing this post.

Getting started

First thing we need is a Vagrantfile, this instructs Vagrant on how to setup and configure a VM.

Create a Vagrantfile

Create a file called Vagrantfile in an empty directory with the following content:

Vagrant.require_version ">= 1.7.0"
Vagrant.configure(2) do |config|

  config.vm.box = "ubuntu/xenial64"
  config.vm.provision "shell", inline: "apt-get update && apt-get -qq install python python-pycurl python-apt"

  config.vm.provision "ansible", type: "ansible" do |ansible|
    ansible.verbose = "" # can be set to "vvv" for verbose logging.
    ansible.playbook = "playbook.yml"
    ansible.sudo = true
  end
end

The Vagrantfile above will instruct Vagrant to create a VM based on Ubuntu Xenial 64 bit. It will install the dependencies needed to run Ansible playbooks as well. The important part is:

config.vm.provision "ansible", type: "ansible" do |ansible|
  ansible.verbose = "" # can be set to "vvv" for verbose logging.
  ansible.playbook = "playbook.yml"
  ansible.sudo = true
end

This instructs Vagrant to run the Ansible provisioner with our playbook.yml file as playbook.

Create a playbook

Next, lets create a simple Ansible playbook. The playbook below is the simplest form of a Ansible playbook. When your playbook grows a single file is quickly not maintainable. The Ansible recommended way of organizing your playbooks can still be used.

---
- hosts: all
  tasks:
  - name: apt-get update
    apt: update_cache=yes

  - name: Install deps
    apt: name=nginx  state=present

Now lets create our playbook. Create a file called playbook.yml next to the Vagrantfile and copy the content above into it. This playbook will effectively run apt-get update and then install Nginx.

Lets build and provision the VM

Now that we are all setup we can have Vagrant create the VM and run the playbook. Open a terminal in the directory containing the Vagrantfile. Run vagrant up. This will make Vagrant create the VM and run the playbook. It might take a while since it will download the Ubuntu image if not already present.

The last part of the output should show the Ansible playbook being run:

[..]
==> default: Running provisioner: ansible (ansible)...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [default]

TASK [apt-get update] **********************************************************
ok: [default]

TASK [Install deps] ************************************************************
changed: [default]

PLAY RECAP *********************************************************************
default                    : ok=3    changed=1    unreachable=0    failed=0   

To check the result of your playbook you can run vagrant ssh to login to the VM and verify correct configuration. In this case we could run nginx -v to verify that Nginx has been installed in the VM.

At this point changes or additions to the playbook can be made. Running vagrant provision will rerun the provisioning system and execute the playbook. Running vagrant destroy && vagrant up will destroy and re-create the VM.

Alternatively Ansible can be invoked directly. Vagrant generates a inventory file which can be used like so: ansible-playbook -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory -become playbook.yml.

Skeleton project

I have created a skeleton project containing a Vagrantfile and Ansible playbook (using roles) on my Github.