On 17th of May, we had a Code Retreat at HERE in Berlin. I was helping Martin Klose with the organisation and facilitation of the event. It was enriching experience and I highly recommend you to do something similar.
As I was trying to parallelize some bash script today, quite unexpectedly, I had more fun1 than I was hoping for. It was a bumpy ride, so please follow the story from the safety of a comfy chair, basking in the glow of your favorite terminal emulator.
So I was sitting there, facing off a small snippet of bash code that screamed to be optimized. Truthfully, what was actually screaming at me was the fact that the last stage in a Go pipeline was taking some 27 minutes.
To better understand Go and to enable you to test it freely, I’ve decided to set up a small Vagrant cluster. The project is available on github.
Go (Continuous Delivery)
If you need to set up continuous delivery pipelines, Go is the way to go1. It has easy-to-use and intuitive graphical web interface. The configuration is stored in XML file enabling simple backups (you can automated them with Go itself if you want). You can sanely divide pipelines in groups and manage resources. Documentation is quite nice as well. It’s now free. Most importantly – it gets the job done without evoking killer urges in the users.
A few hours ago I’ve had intensive and respectful disagreement with a fellow team member. We just couldn’t agree on how the testing should be done. While eye-opening, the discussion was quite frustrating and so I’d like to explore this topic a bit more.
Disclaimer: I do not feel comfortable writing about this topic – I’m only starting to vaguely comprehend what the testing is all about. That said, all the more reason to write about it.
This is going to be an opinionated post, but I’d really like to hear your thoughts to improve/correct my, quite possibly, erroneous ways.
In the blog post “Vagrant: Intro”, I’ve given a short introduction to Vagrant and shown an example how it could be used. (If you haven’t read that one, you should check it out.) In this post I’ll show you how I’ve set up my personal, on-demand, Linux development environment.
By the end of this guide, you’ll have Ubuntu VM with Git, Python with Pip, and Ruby with RVM.
Setting up personal development environment involves the following elements:
- Vagrant – spawns and prepares Linux virtual machine
- Chef – handles most of VM provisioning
- Personal dotfiles – repository with desired custom settings
So let’s get started.
I’ve recently stumbled upon Vagrant and I am really happy about this discovery. In this post I’m going to name some of the reasons why Vagrant is useful. At the end, I’m going to implement a small real-world example.
So let’s get started.
What is Vagrant
Vagrant is “a tool for building complete development environments”. It is used to create virtual machines in a consistent and repeatable way. Virtual machines are provisioned on top of chosen virtualization software, typically VirtualBox. When the virtual machine has started, it can be provisioned with tools like Chef or shell scripts. With automated provisioning you can spawn a new virtual machine in a matter of minutes, fully configured to your specific needs.
Don’t worry if this all sounds a bit fuzzy. Just continue reading and you’ll get it by the end of the post.
While working with some analytics data, I stumbled upon puzzling MongoDB behaviour. I was trying to aggregate the data and suddenly a light bulb popped just above my head. Notwithstanding the quality of produced light, the idea was brilliant: I can just use map-reduce.
I have to admit, I love the idea of map-reduce, both the programming model for processing large datasets and the functions sharing those names in the functional programming paradigm. So I was already getting into a good mood, after all I get to play with it for the first time in MongoDB.
What could go wrong?
Today I’m writing about my recent side project: tmux-connector, tcon for short. It is designed to help you manage multiple servers by employing SSH and tmux.
If you are managing more than a handful of servers, tcon could become an indispensable tool in your arsenal. It enables you to simultaneously connect to the servers and manipulate them as desired. You can issue the commands to a custom subset, or to all of the servers at once. All while tracking the progress through customisable layout, from the safety of your terminal.
For a few years now I’ve thought that blogging is something every developer should do. Unfortunately I’ve never gotten to it. Up until now.
It’s only appropriate to start with a guide describing how to set up a blog.