I think it’s good practice to list up all the things you achieved in a year. It’s not really about telling others and brag about it. No, it’s more about telling yourself and calm down (impostor syndrome anyone?).
So let’s talk about 2014. We (my wife, our five boys and me) were living in Hamburg, Germany they whole year and I was working as a freelancing software developer most of the time. Besides that
- While working for XING AG I helped building the new Communities product, a replacement for the old Groups. It finally took us one and a half years to get there. What sounds like a simple forum or blackboard application is actually much more, especially implementing access control and integration into the rest of the XING universe.
- I took a look into programming with Elixir and Go, and both are very promising alternatives to my current favorite Ruby
- I tried using the Atom editor. It’s a very good text editor, with lots of nifty feature for programmers and already with a big community. Nonetheless, I finally stayed with Sublime Text
- We decided to return to New Zealand. It’s where currently our heart is. We didn’t finish this chapter of our life last time (in 2012/13), so we had to go back (I’m currently writing this post in Wellington, New Zealand)
- I played around with Docker. It’s more than just a new kid on the block, it’s the near future. It’s already mature, ready to use even in production and comes with a very big community (I somehow got the feeling this is important).
- I went to two conferences this year. The first one is Scottish Ruby Conf in Edinburgh and Crieff, Scotland, a typical Ruby conference with lots of enthusiastic and caring people and topics about, well, Ruby. The second one is Beyond Tellerrand, a conference about working with and living in the Internet, not only about development or design. It’s an amazing event, highly recommended!
- I released version 4 of AASM, one of the open source projects I’m maintaining. It actually took more than a year to finish this up, so I’m glad it’s out of the door.
- I gave a talk about AASM at the Hamburg Ruby User Group meetup. General topic was Open Source made in Hamburg.
- I had to learn that communication is hard. It all started with me creating an issue for paranoia, asking for a new release, and ended with a dispute on twitter. I finally met this guy on the RubyConf Australia in Melbourne, Australia, and talked to him about that issue. Still, communication is hard.
- I participated in the Rails Rumble, together with Jan Krutisch, Florian Munz and Denise Tham. We built Awesome Recipes, which you can use to visually create kitchen recipes and share them with others. We finally made it to the 9th place, and we are overall very happy with the result.
- We travelled to Sweden for the fourth time, and I can only say that we enjoyed it pretty much, again, and we will definitely come back for a fifth time (once we return to Europe).
- I migrated our previous Rails Rumble project, the Awesome Fontstacks, from Rails version 3 to 4.
- I implemented JSON views, which are simple Ruby files evaluated as Rails views and delivering JSON strings.
- We visited Stralsund and Rügen. If you find the time, go there and have a look yourself. Both are really beautiful.
- I read a couple of fictional books, one of which of which I can highly recommend (sorry, German only): Blackout written by Marc Elsberg.
- I finally read Candid written by Voltaire (again, sorry, German only).
- Together with my eldest son I visited the Thalia theatre in Hamburg, Germany, where they played Moby Dick without any (!) stage setting. Very, very good acting!
- I set up my wife as the beneficiary for all of my insurances.
- I started to use #pants, a light-weight blogging engine coming with a fully decentralized social network built-in (I couldn’t have said that any better than Hendrik himself.
- I switched from Quicksilver to Alfred, and I haven’t regretted it until today.
- I was part of the Hacktable team organising a couple of Superkids events, allowing kids to take a look into programming and working with computers.
- I merged two Instapaper accounts into one. Yes, I manually copied over links from one account to the other. If there’s a better way to do this, I don’t want to know.
- Benny and I abandoned blanksand, our shared office space in the centre of Hamburg, Germany. It was finally too much effort to keep things up and we didn’t use it enough. Sad, but true.
- We bought a SUP for Standup paddleboarding. Not cheap, but hell lot of fun. You should try it!
- I reviewed a book about Redis Applied Design Patterns. Check it out if you are interested in working with Redis.
We write idiomatic code
We follow Rails conventions
Ruby on Rails comes with its own set of assumptions and conventions (which is why it is called opinionated). We are not only aware of these, but we follow them in our everyday work. Recommended reading The Rails 3 Way, Obie Fernandez.
We follow common styleguides
There are a couple of good styleguides around on GitHub and others. We know them, we use them and we highly recommend them. Even to the point to force ourselves by setting up these guides in our editors. For example Styleguide for Ruby.
We use best practices
We visit conferences and read books to know how the good guys write code. We listen to people telling us about not the better ways, but the best ways to achieve our goals. Every day.
We read all the commits
It’s our codebase. We love it and we don’t want anyone destroying it. This is why we read any commit coming in. I mean literally, every commit.
We do pair programming
If the issue to tackle is complicated, or we just want to talk to someone while writing code, we simple ask anyone to join us in doing the work. Call it 4-eye-principle, Wackeldackel or Rubberduck, it’s on our toolbelt, ready to be used when needed.
We have a refactoring board, from which we pick regularly
Technical debt is everywhere. Our means to tackle this pile of guilt is our refactoring board, which grows and shrinks, visible for each and everyone. No process needed. There is always time to change existing and running code. No broken windows allowed.
We use pull-requests to review code
We have a number of ways to push our code to the repository. Sending pull requests is one of them. We ask others to take a look (or even ask ourselves one day later), before we let it go into the wild. Simple and effective, if needed.
We talk about our code
There’s a plethora of chances to talk about our codebase. Stand-ups, coffee-times, ad-hoc discussions, lunchtime, and so on. Non-coders disrespectfully shake their heads on us talking so much about our work. We always talk about major code changes long before we implement them.
We know what everybody is working on
In order to avoid conflicts we tell others what we are working on. No surprises, and no major merge conflicts. And even if we are working in the same code area, we are able to handle any conflict showing up.
We know our co-workers
By working together every day, we know each others leanings, our strengths and weaknesses. So we know when we have to support each other on tackling complex problems and writing code. Even when someone tries something new and experiments around, we trust what they are doing, because we know they are doing right.
We seek code smells
Whenever we write code, we take a look around, identifying and marking code smells. We utilize TODO, FIXME and QUESTION a lot, and find the time to decover these spots and remove them.
We modularize our code
Even with all conventions, the codebase grows to a point where it is no longer maintainable. We sport modules, mixins, concerns, gems, plugins, packages. We know when to use inheritance and STI or composition. We do this to remain focused on our given business case.
A lot. All kinds of tests. Sometimes first and sometimes after we write the actual code. No bug without adding a test. No refactoring without a test. To write a test it to write code. We utilize test coverage, but 100% is not our goal. That’d be insane. There’s a kind of test for each usecase. We use the one most appropriate.
We struggle for fast tests
While writing tests is important, having a fast test suite is equally important. Slow tests won’t be run, it’s simple as that. That’s why we observe the trend on Jenkins (or Travis CI).
We check the performance
Every code change might have an impact. This is why we do log-jammin’. We do it regularly and a lot. Logjam is a great tool for that.
We not only keep our tools up-to-date, we keep the tiny bits of libraries and packages up-to-date as well. We not only update gems mentioned in the check-gem-versions build, we check for rarely used or development-only gems as well.
We give back
Monkey-patching is easy. And dangerous. This is why we have a natural tendency to return our code changes back to the original developers, in order to improve their code and let ours grow smoothly and independently. We pullup a lot.
We organize our codebase
Rails provides good means to organize the code. But that’s not sufficient. There are authorizers, utilities, external APIs, decorators and so on. And there’s a neat little place for all of them.
Back in Brighton, England for the dConstruct conference, after 2008 and 2010. If it wouldn’t be for the conference, visiting Brighton is worth all the time. Easy to get there (choose Gatwick Airport as your destination, and take the First Capital Connect train for 30 minutes), grab a bed in any hotel close to the beach and make your way around. It’s marvelous!
But the dConstruct conference is worth attending, too, and your time and money couldn’t be spent any more unrepentantly. I got repeatedly asked what the conference is all about, and to be honest, it’s not easy to answer. From what Clearleft and others state on its website itself, it is a collection (a smörgåsbord) “of clever clogs gathered together to twist our perceptions of technology and culture”. Yeah, that fits. It’s about technology for sure (lots of web developers and designers around), and it’s about culture as well, regarding all the Internet, but even more than that. It’s about how we see the world, what drives our motivation and inspiration. And anytime I get back home, I’m more focused and inspired than before. It’s about that, finding your place in the world around you.
It’s good to be back.
All I've got is a red guitar,
“All along the watchtower”
by Bob Dylan
three chords, and the truth.
All I've got is a red guitar,
the rest is up to you.
Validate your fixtures.
As mentioned in our
Ploppcasts session about Testing
(German only, sorry) I'm using both fixtures and
factories when testing my Rails applications. One of the drawbacks from
using fixtures is that these don't have to be valid in terms of
In order to make sure my fixtures are in fact valid I introduced a fixtures test, which is simply
a unit test to automatically verify the fixtures' validity:
So, taken these fixtures:
the test will indicate one failure, because the fixture
is invalid. The fixture
won't be marked as failure, because its name is starting with
telling the test that it should expect an invalid fixture, and
return a failure otherwise. By this, we can keep having even invalid fixtures
without failing tests.
Roughly a year ago a very good friend of mine,
was organising an event for
from all over the world. He invited them to come over to our shared
office space and have a couple of drinks. I can't remember who came up
with the idea, but we finally bought a bunch of paint tubes and asked
the painters to try and somehow return to real painting, with real paint
and a real canvas. And since all of them should do it together, the canvas
simply had to be one of our office walls.
Over the next couple of hours, these guys really went into something, and
so the painting on our wall grew and grew.
And it grew even further.
We really had good fun watching the work in progress. Everybody, even guests without prior
painting experience, was giving it a try. Everybody was invited to fill the wall up and
paint what they were feeling like.
Everybody was in a flow. Even when waiting outside, it was a nice and warm night, the
people couldn't stop painting, this time using crayons, and they went on painting little
pictures on the street.
After having painted for almost 5 hours, everybody was happy with the result and
proud of being part of this happening. The final picture is about 5 meters wide and
almost 3 meters high, and it does not fit in full size on the following image.
But feel invited to come over and take a look yourself! The painting is still there
and will be around until we leave the office to the next residents. When coming
back to the office the next morning, we were glad it haven't rained yet and the chalk
paintings outside were still visible.
When taking a closer look at the big painting inside, I noticed a number of
It was just a wonderful evening. Thanks to everyone who was taking part in this, and even
more thanks to the guy who created this living and one-of-a-kind experience, Benjamin Rabe!
Adding a to_s method to a Ruby class helps with debugging.
I more and more tend to add to a Ruby class I want to test is a to_s method returning
some sort of information about the underlying object.
So whenever I have to dig a little deeper and have to debug code that uses an instance of
that class or I simply want to write some details to the logfile, I can use the returned
string and thereby make sure all relevant information is printed.
Returning only a hard-coded string or name doesn't make any sense at all though. So, let's
assume we have some sort of business object, for example a job doing some kind of work in
the background. It has a certain state which we want to know about:
If you put this into an application which keeps the waiting user up-to-date with the current
state of processing (as simulated below with a Ruby irb console), the user knows exactly
what's going on.
There are more methods a Ruby class should have. Make sure to take a look at Robert Klemme's
"The Complete Class" article.
I don't think a class should contain all of the methods described there, but it's a good starting
This picture represents the Wellington style pretty much. Old and new in once place, with lots
of very steep hills and roads.
Last weekend we stayed in Castlepoint on east coast of the north island of New Zealand. Words
cannot describe how beautiful this spot is. If you haven't been there yet, do so as soon as
possible! No excuses accepted!
This is the Karori tunnel which connects the suburb Karori with the Wellington city centre.
Most people take their car to drive through it. But that day we decided to do the walk of
about 4 kilometers.
Older Posts are to be found in the archives...