Urban Hafner

Ruby, Ruby on Rails, JavaScript programmer. Dabbling with Rust and agile methodologies on the side.

Why Every Agile Team Should Include a Tester

| Comments

A recent post on Jim Grey’s blog about his job hunt as a QA manager made me think about what my ideal test setup for an agile (SCRUM like) team would be.

The thing is, having QA as a completely separate team that tests everything once the development team has “finished” the features and bug fixes for the next release is very much out of line with every agile methodology. Agile processes are (to me at least) about faster feedback and the possibility to change direction quickly. So for example, if you were doing SCRUM with one week sprints, do a feature freeze every month (you know, management won’t let you release each week), and only then start testing all the features and bug fixes there’s quite a lot of overhead. The QA process may take a while as everything produced in a month needs to be tested, the developers have already moved on to new features and now have to switch back to fixing their old code (which is quite a mental overhead) and once everything has been tested, fixed, and tested again it’s already 2-3 weeks later.

Using Launchd to Manage Long Running Processes on Mac OS X

| Comments

I recently had the need to have a long running, user defined process on my Mac. At first I thought about using Monit or Inspeqtor, but then Jérémy Lecour pointed out to me that I could just use the built in launchd.

Lauchd can automatically start processes on startup and it can monitor them and restart them should they abort. Adding one yourself is rather easy. You create a file in ~/Library/LaunchAgents in a certain format. Here’s one of mine:

Learning Rust: Tasks and Messages Part 2

| Comments

The code examples of this blog post are available in the Git repository tasks-and-messages.

In part 1 of this series we started implementing our Pi calculation using the Monte Carlo method. We ended with code that works, but that still doesn’t return a value after exactly 10 seconds. In this part we’ll finish the implementation.

The problem with the previous implementation was that the worker() function had to wait for montecarlopi() to return, before it could react to the message from main(). The solution to this should now be obvious: Let’s put the montecarlopi() calculation in a separate task. Then worker() can listen to messages from both main() and montecarlopi() at the same time.

Learning Rust: Tasks and Messages Part 1

| Comments

The code examples of this blog post are available in the Git repository tasks-and-messages.

In the previous learning rust blog post I promised to talk about runtime polymorphism next. Instead I’m starting what is probably going to become a multi part series about concurrency. I’m doing this as I just happen to need this stuff for Iomrascálaí, my main Rust project. Iomrascálaí is an AI for the game of Go. Go is a two player game, and like Chess, it is played with a time limit during tournaments. So I need a way to tell the AI to search for the best move for the next N seconds and then return the result immediately.

Learning Rust: Compile Time Polymorphism

| Comments

Coming from Ruby, polymorphism is a big part of the language. After all Ruby is a (mostly) object oriented language. Going to a language like Rust which is compiled and has an emphasis on being fast, run time polymorphism isn’t that nice as it slows down the code. This is because there’s the overhead of selecting the right implementation of a method at runtime and also because there’s no way these calls can be inlined.

This is where compile time polymorphism comes in. Many times it is clear at compile time which concrete type we’re going to use in the program. We could write it down explicitly, but it is nicer (and more flexible) if the compiler can figure it out for us.

My Emacs Configuration

| Comments

As I currently work on a distributed team and we’re trying to do more and more pair programming I decided that it’s time to give Emacs a try again. Using tmate in combination with either Emacs or Vim seems to be the way to go due to the lower latency than a proper screen sharing solution.

Right now my Emacs configuration is rather basic, but I think it could be a good starting point for other people, too. This is why I made it available as a Github project.

If you have any problems with it let me know and more importantly (at least for me personally) if you notice anything that I should do differently I’d love to hear from you.

How to Test Rust on Travis CI

| Comments

Working with Ruby on Rails in my projects I’m used to running continuous integration on Travis CI. As this is free of charge for open source projects projects I wanted to set it up for my Rust project Iomrascálaí, too.

At first I used the setup provided by Rust CI, but as the project page doesn’t seem to be working 100% anymore and because the Debian package they provide of the rust nightly snapshot for some reason strips the Rust version number I decided to use the official nightly snapshots instead.

Introducting Iomrascálaí

| Comments

or “Help me learn Rust by pairing with me”

After years working in interpreted languages (Ruby, JavaScript) I recently discovered Rust. As I sadly don’t have the opportunity to use Rust directly in a client project, I decided to come up with a toy project to help me learn the language.

As Rust is supposedly good for programs that actually need raw speed (unlike the web apps I generally write) I decided to come back to one of my old time favourites: an artificial intelligence for the game of Go.

I had already tried writing a few of those in recent years (including helping Jason House with his bot written in D), but every time I had the problem that working alone wasn’t very motivating so I never managed to produce a working program.

To combat this I’m trying to pair program with people (i.e. you) to keep me going. So if you’re interested in either learning Rust with me or writing an AI for the game of Go, please get in touch!