I’m working with a small team that is divided in two geographical locations. This separation has made collaboration a little challenging which has compromised the quality of the code base. I’m exploring tools that can help us collaborate better, particularly making it easy to review each others code.

Gerrit promises a platform that makes it possible to create ACLs on top of git repositories, so that code can’t be committed until an official approver checks and approves the code. Ideally, the workflow will look something like this:

• Carlos makes changes and commits them to his local repository
• Carlos pushes his changes to Gerrit and creates a code review
• Luis, as an owner of the project reviews the code and suggests changes
• Carlos makes the changes, commits them and updates the code review
• Luis looks at the changes and approves them
• Carlos can now push the changes to upstream

Docker came with the promise of ending the “works on my machine” syndrome. I have to admit that when I first read about Docker and thought about it, it sounded like they were just bragging. With the little knowledge I had, I thought that the only way to have all developers work in a consistent environment was to start a container and somehow work inside the container. Now that I know a little more, I realize that it is not the answer, and the answer is actually really easy.

Volumes

Docker comes with something called data volumes. These basically allow you to mount a folder from the host system into the docker container. This effectively allows you to have your project folder available in the container. This means that you can keep developing the way you have always done it, and have the code run inside the container.

Docker containers are created based on images. If you want to create a new container based on a fedora image and run a terminal on it you can do:

1
docker run -i -t fedora bash

Every time you execute this command a new container will be created based on the fedora image.

Most of the time we run docker containers with servers in a daemonized mode. Here is a very simple example:

1
docker run -i -d fedora bash

In this scenario, we know the container is running, but we can’t really interact with it anymore. If something is not working correctly and we want to debug why, we need to create a new container with a shell and try to reproduce all the steps that led to the error. Well, at least that was the way I used to do it.

This weekend I decided to resume work on an Android project I had left behind. Once I had my environment set up I kept getting this error:

1
W GLSActivity: gms.StatusHelper Status from wire: INVALID_AUDIENCE status: null

After some googling I found the problem was that I was trying to call a google service from an app using a signature not registered in my project. I fixed it by going to the developer console for my project:

ss is a replacement for netstat; a program that allows you to analyze the sockets running on a Linux system. In practice, it is useful to investigate if a port is being used and by whom or to investigate which services are running.

In its simplest form, the ss command will list all non-listening sockets:

1
2
3
4
5
6
7
8
[adrian@localhost ~]$ ss
Netid  State   Recv-Q Send-Q       Local Address:Port                          Peer Address:Port
u_str  ESTAB   0      0            /run/systemd/journal/stdout 8313                    * 29127
u_str  ESTAB   0      0            /run/systemd/journal/stdout 9946                    * 30837
u_str  ESTAB   0      0            /var/run/dbus/system_bus_socket 7415                * 25359
u_str  ESTAB   0      0            /var/run/dbus/system_bus_socket  8795               * 18724
u_str  ESTAB   0      0                * 30484                                         * 28442
...

I’m looking for the best way to create a UI components library. A few weeks ago I explored React with Radium and I have also considered Polymer. This time I want to explore React with Webpack. I already wrote a guide to using Webpack with React. In this article I’m going to focus on creating a component that bundles not only it’s JS and markup, but also it’s styles.

CSS loader

To be able to declare CSS dependencies for our components, we need to use css-loader and style-loader. Installing them is easy:

1
npm install css-loader style-loader

Webpack is a module bundler similar to Browserify but with a different philosophy. Browserify was born with the goal of making it possible for developers to write CommonJS(node code) in the browser. Webpack allows you to write CommonJS but it also allows you to use other formats that might not be supported by node. One thing that makes it interesting is that since it doesn’t try to comply with CommonJS, it allows developers to declare dependencies on files that are not necessarily JS, which can be helpful to create self contained components.

Getting started with Webpack

Lets create a simple React app using Webpack. We can start by creating our HTML entry point:

1
2
3
mkdir ~/webpack
cd ~/webpack
touch index.html

Every now and then I have to dig into other people’s code that doesn’t comply to my coding standards. When I make a change on these files, Syntastic lights up like a Christmas tree. Since this is not my code and I can’t really fix it, I prefer to temporarily disable Syntastic:

1
:set SyntasticToggleMode

Once again I changed computers and had to install and configure Vim so it works the way I like it. This time I was a little smarter and created a script that I can use in the future to install it and configure it with one command.

It will install the latest version of vim(from github), download and install the most useful plugins and create a .vimrc file. Just clone the get-vim github project and run:

1
./do.sh

And you are set. Hope it is useful.

Reworkcss is an easy to extend CSS processor that has some cool features I want to explore. Lets start by installing it:

1
2
3
mkdir ~/rework
cd ~/rework
npm install rework

Rework has a very simple API. It receives a string of CSS code and it outputs a rework object. You can then run plugins on this instance and finally output the result:

1
2
3
4
5
6
var rework = require('rework');
var plugin = require('plugin');

rework({source: 'style.css'})
  .use(plugin)
  .toString();

The interesting part happens on the plugins so lets look at some of the most interesting ones.