UUID stands for Universally Unique ID. It is a 128-bit value that is usually represented by hexadecimal characters divided by dashes:

1
b54c9b1a-e19c-44e7-ab81-9528c195da02

They are called Universally Unique because in practice it is very hard to have collisions even if two(or more) independent systems generate these IDs independently. It is of course possible to have collisions, but the chances of it are low enough that it can be treated as impossible in most scenarios.

The trunk development flow is an alternative to gitflow or github flow that is used at very big companies(LinkedIn, Google, FaceBook) to allow many developers to work in the same code base with the least amount of friction.

This model existed before git, so it doesn’t really use all its power. If you have done development using another flow, it might even feel wrong at the beginning, because it discourages branching and merging, but it is all for a good reason.

These are the rules I follow when using the trunk model with git:

• Master is always stable – The master branch should always be stable and deployable. For this reason your codebase should be guarded by as many tests and monitoring as possible. Developers should feel comfortable deploying anything that goes to master as soon as it is committed because there may be a system that continuously deploys the master branch.
• No merges allowed – The master branch should remain flat by always rebasing to it. Keeping the master branch flat makes is easier to bisect and revert commits.
• No branches for large tasks – On other flows, branches are created for large tasks that may take days or weeks. This makes development easy, but integration hard. When you are done developing your feature and are ready to add your changes to master, there may be conflicts. Fixing conflicts that are weeks old is hard and error prone. To avoid this problem and still allow for large tasks, use feature toggles instead.

I’m again starting a new project with tools I am not familiar with, and it is exciting. This time I get to play with React. I’ve been wanting to play with React for a while but I got distracted by other technologies. I played a little with Polymer and I liked it so far. I’ve been using Angular for a while and it really annoys me that it is really difficult to componetize. I have heard a lot of good things about react, so I really want to put it to the test.

What is React?

React is more similar to Polymer than to Angular. React Helps create UI components that are easy to reuse. It doesn’t provide a Router, Model or Controller, so you have to take care of those aspects yourself.

I’ve been using JavaScript for a few years, and as of today it is my favorite programming language because it allows you to build things really fast. All the JavaScript I wrote in the past was in a version called EcmaScript 5. I know there is works on EcmaScript 6 and EcmaScript 7, but since I work mostly on the browser, I can’t really use it until the browsers add support.

Babel is a ES6 to ES5 compiler. This means that you can write code in ES6 and it will be transformed to something most browsers understand. This is interesting because it allows us to use new features that are not yet implemented in all browsers, but also because it resembles the way software was developed in the past(write, compile, run). The problem with the old programming model is that it could take some time to compile the code, so there was a delay from when you write the code and you can see it in action. For JavaScript the compilation time can be brought down to something fast enough that the developer doesn’t realize the code was compiled.

When a web project starts getting big, managing dependencies becomes hard if you don’t have the right tools. If you have some experience with web development, you probably use RequireJS to manage your dependencies.

RequireJS does a great job but if you are familiar with node, you probably wish it was as easy in the browser. Dependency management is built into node, so you don’t have to worry about it.

Browserify lets you write node-style code that works in the browser. It is basically a replacement for RequireJS that allows you to create bundles with less configuration.

I just built a little node app that I want to make publicly available. I got a little dedicated server where I am going to host my app. The problem now is getting my app into the server. In the past I had done this task using FTP, but now I know better. There are tools out there that allow us to deploy our app to our server(or list of servers) with a single command, and flightplan makes this task very easy for node apps.

Installation

We need flightplan in our development machine so we can run deploys from there. We can install it from npn:

1
npm install -g flightplan

This globally installs the command line tool that allows us to run the fly command. We also need to install flightplan as a dev dependency of our node project:

1
npm install --save-dev flightplan

Salt is a server orchestration platform that allows you to manage your server infrastructure. It allows you to remotely configure all your servers(minions) from a single place(master). Salt also allows you to execute commands or scripts in a collection of servers at the same time and it will aggregate the output for you.

Installation

You will typically have one master and multiple minions. In your master host you will need to install salt-master

1
sudo yum install salt-master

If you want your salt to start automatically every time your master is started you can use:

1
systemctl enable salt-master.service

You will also need to install something in your minions:

1
yum install salt-minion

And to have it start with the system:

1
systemctl enable salt-minion.service

What is polymer

Polymer is a framework for creating web components. Polymer is different than other web frameworks in that it only exists while browsers catch up on implementing the web components specification(which hasn’t been finalized).

Polymer doesn’t do much in helping you create single page apps. It doesn’t have a router, tools for internationalization or a nice abstraction for XMLHttpRequest. The way you build apps using polymer is by creating components that help you do those things.

Karma is a JS unit test runner originally designed for Angular. Karma can use most popular testing frameworks(mocha, jasmine, etc…), assertion libraries(expect, chai, …) and mocking frameworks(sinon).

The reason this post is titled “Unit testing angular with karma” and not “Unit testing JS apps with karma” is because in my opinion Karma does a lot of things that only make sense for Angular apps. The thing that most caught my attention is that when you use Karma for unit testing you have to load all files in to the browser at once. If you have a JS file that depends on other JS files(loads them using AMD) there is no way to mock the dependencies. This would make unit testing impossible if it wasn’t because of Angular’s dependency injection system. At the end, this means that you can mock all dependencies, but you end up loading stuff you don’t need. In practical terms this is irrelevant because unit tests run very fast anyway.

Git bisect helps you find out the commit that introduced a bug. It has happened a few times that somebody discovers a bug that I knew used to work fine before. When this happens I go back to an arbitrary point in the git history and try to reproduce the bug. If the bug is still present I go back a little more, until I find a point where the bug is not there. Then I try to find the commit that introduced the bug by searching through the commits between the commit I know works and the one I know doesn’t.

Git bisect helps you do this more efficiently by using a binary search. Lets say you are now in the HEAD of your master branch and you know there is a bug in there. You can start a bisect session by running:

1
git bisect start<br /> git bisect bad