South Africa - first impressions

It's now been 4 weeks since I set off from a not so impressive summer evening in Hamburg to arrive in a slightly warmer Johannesburg the next day. It's high time I capture some of the first impressions if they're to be first impressions.

But just to quickly give a status update for the people that care: I'm fine, the project I'm working on is fine, the TWers here are cool and it's exciting to see the office grow. The nature of how things are here does limit my socializing though and thus makes me feel a little isolated.

On now for my highly subjective observations:

• South Africans are even crazier about their BBQing (or Braai-ing) than Germans. The main difference being the amount and the sheer size of the meat. 
• Food... lots of Avocados and lots of meat in general. I'm loving it.
• I was told that only red meat is meat and chicken counts as a vegetable
• 100% of sampled offices (2) use fingerprint scanners instead of keys. Not sure if this could ever fly in privacy-conscious Germany, but it is convenient.
• Oh how I miss my reliable, fast and cheap internet. 
• Our office is really nice and next door it has proper hipster coffee. 
• Let's not talk about beer though. Instead, stick to wine.
• Traffic lights are called robots
• Driving involves a change of habits owing to the security problems. Bags go in the trunk, phones stay in the pocket, windows stay up
• In general people are excessively friendly though. The common "How are you" is actually answered and not just mirrored back. After taking a while to get used to the latter being the norm in the UK it's weird to have to unlearn that. 
• Live seems to center around cars and malls. This is a bit annoying, as I can't stand malls
• The exception to this being Melville, which has lots of small shops and cafes on actual streets that you can walk on. I found this nice song there.
• Basic satellite TV (which seems fairly common) has about 10 sport channels. It doesn't seem uncommon to have those running on TVs around the office. 
• I do not understand Cricket. 
• Everything happens two hours earlier. I get up two hours earlier, I start work two hours earlier, I'm home two hours earlier, shops close two hours earlier, I go to bed two hours earlier. I'm still not sure if that's also a security side-effect.
• Giraffes are awesome.

Three tales of browser-based test suites [Part 1]

The topic of browser-based testing seems to come up again and again and on many occasions I meet people who have expectations that don't match my experience. So I guess it only makes sense to write down these experiences and some of the conclusions I came to.

I'm not even going to try and go into distinctions between acceptance, functional, integration or whatever testing. Whatever you're calling those tests, if they are instrumenting a web browser, that's what I'm talking about. (If you care about the distinctions, or about testing in general, I recommend reading Gojko Adzic's excellent book Specification By Example.)

I want to look at three concrete examples that I have worked on over the past years.

In the first case, nobody on our team had prior experience, except for a short but traumatic brush with IBM's Rational Functional Tester (remember kids: friends don't let friends use IBM products). To get rid of that, we decided to go ahead and try Selenium.

We initially recorded tests with the Firefox plugin but quickly realized that this wasn't maintainable and didn't really offer us good control for selecting elements. Our Tester Benjamin then took it upon him to write tests in Java and started to integrate them into our CI environment. Over time he created a solid set of Page Objects that allowed us to write new tests fairly quickly.

It took the rest of the team quite a while to take some ownership of these tests but eventually we came to a point where we'd sometimes even drive new features from these Selenium Tests.

There were hurdles along the way. Tests were brittle and the execution time was unacceptable (>30 mins). This improved with newer versions of Selenium, use of Selenium Grid to parallelize tests and by keeping a close eye on the VMs running the browser instances. In the case of IE(<8 gave="gave" just="just" p="p" simply="simply" up.="up." we="we">
Due to some relatively complex processes it was also fairly hard to test later stages of these processes. We only slowly got better at setting up test data for this without making use of the browser. This left us with some unfortunate holes in automated coverage.

There were still manual tests for each release for all of our major supported browsers. But with more of the core functionality being handled by automated tests and with the amount of changes shrinking due to shorter release cycles the effort for this went down considerably.

We also became better at writing unit and integration tests and our confidence in these grew.

What did I take away from it:

• the demand for these tests was driven by Benjamin wanting to automate his tests to make his life easier. And also his desire to learn more about Java. It was a relatively clear goal and the benefits of effort spent on automation were fairly clear. Where automation was hard, it allowed him to balance that effort with the effort of doing the tests manually
• setting up and maintaining browser instances for tests and keeping them stable is hard, unthankful work and I'm glad that these days you can just hand money over to saucelabs to do that for you
• getting the CI builds to be reliably green made shared ownership easier. Collaboration on these tests continued to grow.
• closely related to that, the tests have to run fast. If they run for more than ten minutes they might as well not exist
• we had relatively few Selenium tests compared to our unit-tests but there were the odd cases of bugs that weren't caught by our normal test-suites
• when we rewrote a lot of the front-end JavaScript and test-drove those with jasmine, browser compatibility issues became very rare
• as our understanding of all the different tests grew, it became easier to decide when we could avoid writing an extra Selenium test
• working closely with the rest of the team and writing the tests in Java gave our Tester room to grow and learn and turn into a regular dev on the team. Seeing that happen was probably one of the most fun things during my time there. The rest of the team also took up some of the manual testing work.

(Edit 13.9.15: removed some point about testers that I didn't like anymore)

Continue on to part 2

Timetravelling in JavaScript unit tests

At the February berlinjs meet-up Krzysztof Szafranek had a very nice, short talk about TDD in JavaScript (slides here). Among many other things he was showing busterjs and the way it lets you test asynchronous stuff without having to actually wait for time to pass.

I made a note of it to give it a closer look. When I recently had to write some JavaScript again, I remembered about it and was keen to give it a try. Since we were already using jasmine as our testing framework, my colleague Christoph and I were looking for something equivalent there. To cut the intro short, there is: jasmine.Clock.

Thank you, 2011

It’s December. That means it’s time to write a long, rambling post looking back on the year. It’s been a very exciting and eventful year for me, so I’m actually appreciating having the time to do this.

Last new year's eve I tweeted the following. And I wasn't wrong.

2011 is gonna be amazing, you just watch!

I’ve changed jobs, moved from Düsseldorf to Hamburg, took part in a lot of conferences and events, organised a few things myself and in all of that met a huge amount of amazing people that truly inspired me. Thank you, everyone! It was an amazing year.

xtc Berlin

Late Tuesday evening, the night before the ALE conference started, I sat in the hotel bar of the venue talking to people who had arrived early. Looking around, I thought, "cool, it's like an extreme tuesday club in Berlin". Since then I've been thinking about what it would take to actually create something like this in Germany.

So what is the extreme tuesday club?

A regular London meeting (weekly) for Agile/XP/Kanban/Scrum newbies, practitioners, and experts. (*)

That's not very elaborate but I like that it casts a fairly wide net in terms of target audience.

There are already a lot of different software and agile related user groups in Berlin and I like what I've seen of them so far. But each of these only cater to a specific topic or technolgy.

I'm looking for something less formal. Have a beer, talk to people about what they're working on, share war stories, cross-pollinate new ideas, ask for help or give help, if wanted. I would hope it would be as inclusive as possible. So, newbie or expert, programmers, PM/POs, design people, start-uppers, whatever - as long as you care about what you're doing and want to talk with people about it, it should be fine.

I did a little open space session at ALE on this and there seemed some general interest and I said I would just try and get this rolling and just see what happens.

Someone suggested the Cafe 100 Wasser as a pub to go to. And that's where I'll be, this Tuesday from around 8pm onwards. I'd be happy for you to join me. If you do plan to come, please let people know on Twitter.
[we've since changed pubs around quite a bit. Twitter is probably the safest bet to find out where people are. We're now usually at the Prater Garten in Prenzlauer Berg]

Some closure (ha!) to 7 Languages in 7 Weeks

I'm currently trying to work through a backlog of things I've been meaning to blog about. And at the top is this post. The whole experience deserves being wrapped up properly. But I'll keep it brief.

When last I wrote about it, I was somewhere in the middle of week 6, working with clojure. This is probably my favourite of the languages in terms of learning new things and offering new perspectives while also having enough momentum that I might actually be able to do something with it at some point. I really hope this doesn't fall victim to my inherent lazyness.

The last week dealt with Haskell. At this point I was so busy with moving apartments and starting my new job that I barely managed to read the chapter but didn't get to try the examples. It sounded interesting but maybe a bit too strict. Others in the study group seemed to like it a lot though.

So, what's left to say. I really appreciated the study group and being able to learn from other people's code on github.

I enjoyed the weekly google hangout sessions with the others, when I was able to join them. I particulary liked how aimee facilitated those, keeping track of threads of discussions and making sure everybody got to say something.

The book requires quite a bit of commitment to get the most out of it but where I did that I felt it was well worth it.

I certainly recommend doing this together with other people. And share your experience with the world. 

All in all, I stick to what I said in my first post on this.We live in amazing times!

Learning clojure just in time

It looks like we've moved to clojure at just the right moment.

As mentioned, I started using emacs for the first time again in ages. While I still struggle remembering all the useful key combos I did get a little bit of help in the transition by installing aquamacs. It keeps buffers in tabs and lets you use cmd-c,x,v while you're trying to remember how to work the yank buffer.

I'm really liking clojure so far. I'm finally writing tests again (not sure I actually ever did for any of the other languages) and it's nice to have that inside emacs and also have the REPL to try things out.

So, Day 1 only had two excercises. I'm going to just point to aimee's entry on that, because we both came up with pretty similar code.

But let's look at the second exercise

Write a function called (collection-type col) that returns :list, :map, or :vector based on the type of collection col.

I got the following:

I wasn't quite happy with repeating the col argument for each condition. So I started to play around with using the various test methods (list? vector? map?) as keys in a map and then filtering the keys based on the collection argument given. I eventually gave up on it, because it is a rather silly approach. But it was an interesting opportunity to play around with the language.


Then I noticed multi-methods and became interested. Method dispatch based on the result of a function applied to the arguments of the method. This is pretty powerful and will probably take a while to get comfortable with. I used the rather simplistic approach of dispatching on the class to do the second exercise again.


This is silly, too. And it works pretty sloppily. The empty list creates an instance of PersistentList$EmptyList which doesn't seem to match PersistenList. But whatever, it's good enough and it got me thinking about multi-methods. There is more on those in this blog post.

And now it's on to day 2, where apparently we see the list comprehensions I was so impressed with in Erlang enter clojure, too.