Hi, I am Victor Castell, Ruby on Rails Consultant & DevOps Engineer.

Expert professional with +13 years of experience in software development and systems architecture. I help companies, applying technology to business problems. Co-Founded Alkiloo, former CTO and Partner at Season.

Recent Posts

Dkron - Distributed job scheduler

Over the last few months, I’ve been writing an open source program to run scheduled jobs that could work as a replacement for cron. There’s some literature on why the venerable and battle tested cron system service is not appropriate for many use cases read for more info. Me and my co-workers at my current job at Jobandtalent, realized that we were suffering of this weaknesses ourselves. We’ve tried some strategies over the time, like having the cron jobs centralized in a single server only dedicated to this role and some other approaches, but we never came to a solution that allowed us to get rid of the single point of failure problem.

Ansible tip 1

As a general rule always tag your roles. Tagging individual role tasks, allows you to selectively apply just one part of the configuration when you need it. While the advantatges of this may not seem clear at the beginning, you have to take into account that ansible is not the fastest kid on the block. Doing this always, allows great flexibility and high level of granularity when running your playbooks. This is an example of a mongodb setup role: - apt_key: url= state=present tags: mongodb - apt_repository: repo='deb dist 10gen' state=present tags: mongodb - apt: pkg={{ item }}={{ mongodb_version }} update-cache=yes with_items: - mongodb-org - mongodb-org-server - mongodb-org-shell - mongodb-org-mongos - mongodb-org-tools tags: mongodb - service: name=mongod state=started tags: mongodb - template: src=etc/mongod.conf dest=/etc/mongod.conf owner=root group=root mode=0644 notify: restart mongod tags: mongodb As a best practice I always tag the role with the role name.

Ansible tip 2

When developing a role to do a task, you often need to declare some variables to parametrize aspects of the role. It’s not a good idea to name a role variable like: http_port host_name path As a general rule, namespace those variables based on the role name. People can find collisions with their own defined group/host variables in their infrastructure. Using the same mongodb role example of my previous post #file roles/mongodb/defaults/main.yml mongodb_version: '2.6.1' mongodb_data_path: '/var/lib/mongodb' mongodb_rs_hosts: ['mongo1', 'mongo2'] Naming this way it’s less probably that you will find any unintended interaction with variables defined by the user using your role, not impossible though.

heka-redis plugin

I’ve written a simple Redis PubSub heka plugin capable of listening to a queue/s by name or by pattern Decode it if necessary and forward it to the heka pipeline.

Why Go?

This is the talk I gave at the GoMAD group

Lists of values

If you are into building applications of any kind, probably you sometime had the need of a list of countries for a dropdown box or a select list with states. This is why we created LOVs a repository to store this kind of datasets, in a plain, machine readable format that can be used to create DB tables or other kind of automated datastore. With firsts commits I tried to contribute some common use datasets.