On a previous post I wrote about how to write tests for polymer components. Now, I want to hook those tests into my automated test suite that runs for all commits in a repo. The problem is that we are kind of in a low budget so we don’t have a selenium grid we can connect to. What we do have is a machine where we have Jenkins installed. Because we run many different jobs in this machine, we usually use docker to keep our environment isolated.

The problem now is that we can’t run polymer tests in a headless browser like phantomjs, because it is not supported. We have to run our tests in a real browser like Chrome or Firefox. These browsers need a GUI to work which docker doesn’t provide, so we have to do a few things to work around this issue.

xvfb

Xvfb stands for X virtual framebuffer. It is a display server that implements the X11 protocol, but does everything in memory, so it doesn’t really need a screen to work. This is exactly what we need. To use it we just need to create a Dockerfile that uses xvfb to run the tests:

I have started writing some real life polymer components, and I feel really bad that I haven’t been writing tests for them. In this post I’m going to teach myself how to write and run tests for polymer components so I can stop being a slacker and do some proper TDD.

Lets start by creating a little project. You can leave the defaults for the questions asked by npm init:

1
2
3
mkdir ~/test
cd ~/test
npm init

Now, lets setup bower. You can again, leave the defaults:

1
2
npm install --save-dev bower
./node_modules/bower/bin/bower init

A few weeks ago I published a post with an introduction to Gerrit. The configuration I explain there is not very scalable, so now I want to explain how to connect it to an external MySQL database so the data is more secure. As in my previous post, I’m going to do everything inside a docker image so it is easy to reuse and share.

Lets start with the Dockerfile from my previous post:

1
2
3
4
5
6
7
FROM gerritforge/gerrit-centos7:2.11.4

# Expose gerrit ports
EXPOSE 29418 8080

# Start Gerrit
CMD /var/gerrit/bin/gerrit.sh start && tail -f /var/gerrit/logs/error_log

Sometimes when I’m running a process in the foreground (most commonly, vim). I unintentionally press Ctrl + z and I get a message like this:

1
[1]+  Stopped                 vim

There might be reasons why you want to do this if you are running in a system that gives you a single terminal, but when running a UI where you can have multiple terminal tabs open, this usually happens by mistake. But no reason to panic, if you want to go back you just have to type this command:

1
fg

As a matter of fact, you can have different jobs running on the background:

1
2
3
4
jobs
[1]   Stopped                 vim
[2]-  Stopped                 vim
[3]+  Stopped                 less Makefile

And reopen them using fg %n. For example:

1
fg %2

Nerdtree is one of my VIM essentials, but I was always annoyed that it took so much space in the screen. Since I use a vertical monitor, I barely get 80 characters to work on. I recently found that this is easily fixed by adding a configuration to .vimrc:

1
let g:NERDTreeWinSize = 20

Sometimes, when I was browsing through the folders I actually wanted to be able to make it larger so I could see the complete file names. This is also easy to achieve. Move your cursor to Nerdtree and toggle it using:

1
shift + a

I’m trying to host a static site in S3 using AWS. The problem is that for it to work with a custom domain, the bucket needs to be named like the domain. Domain names contains dots and for some reason they are not supported out of the box in the SDK. I was trying to something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
var fs = require('fs');
var aws = require('aws-sdk');
var bucket = 'my.domain.com';

var bucketParams = {
  params: {
    Bucket: bucket
  }
}
var bucket = new aws.S3(bucketParams);

var uploadData = {
  ACL: 'public-read',
  CacheControl: 'max-age=31556926',
  Key: 'somefile.txt',
  ContentType: 'text/plain'
};
uploadData.Body = fs.createReadStream('somefile.txt');
bucket.upload(uploadData).send();

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: