Video: Shoes talk at JRubyConf 2013

28 Jul

Finally the video of my talk at JRubyConf 2013 in Berlin is online. It was my first full length talk at a conference, I gave it almost a year ago – some difficulties with the video material and getting it online caused this delay. Nonetheless it is finally here! The talk was titled “Shoes – the Ruby Way to GUI applications” and now  you can go ahead and watch it or you can watch all the other amazing talks.

While that is a bit old, some of the information isn’t up to date anymore. Most importantly about what still needs to be implemented as we made tremendous progress so far. We have a preview release and are happily looking into the future :)

Shoes4 preview – the more personal release notes

26 May

As you might have noticed a big project I’ve been working on for almost 2 years got its first release on the 10th of May a bit more than 2 weeks ago. You can go read the official release announcement. This one is a bit more personal ;)


It’s been a long road from the 24th of May 2012 when the shoes community got together to concentrate efforts on the complete rewrite we call shoes4 now. That is a long time. It’s a time in which we made more than 2000 commits and closed nearly 600 issues.

Why did it take us so long? Well rewrites are difficult… there is an older piece of software in place which kind of does what you want but not really. Still if you release your new version has to be somewhat good enough. With this preview release we feel that all the major building blocks of the Shoes DSL itself are in place. Finally.

This release is really important to me. You know, it’s super hard to work on a project for so long without any release. Without any users. Other than your co-contributors there really aren’t many playing with what you build. Not many people to report bugs. Not many people to build something awesome. Not many people telling you that what you do actually matters. Sometimes this makes it a bit hard to motivate yourself. Therefore I want to thank everyone who during that time encouraged anyone of us, wrote an email saying that shoes is awesome or even grabbed a release straight from github and tried it out. Every time that happened it put a big smile on my face and motivated me to put in a couple of hours of extra work. I <3 you!

Hackers gonna hack

Of course a release doesn’t mean that people are really using what you build. I tried to make a little effort writing the announcement blog post and sending out some announcement emails. So far we have a bit over 260 gem downloads, which is good I guess :) There will hopefully be a wider coverage if we get a release out.

Of course, this is just  preview release. Nothing stable. We’re hard at work and already got some nice new bug fixes and improvements lined up. Stay tuned for the preview2 release and subsequent releases until we hit a release candidate!


Last but not least I want to thank everyone who ever contributed to shoes4 – not only code but reporting issues, just trying stuff out. Thank you really, your support means a lot! Also to whoever funds me or funded me on gittip – thank you!

More personalized thanks go out to Eric Watson and Jason R. Clark! Eric has probably been the most steady contributor to shoes4. He’s been there from the start, still is, still going strong. And hopefully will for a long time :) Recently he’s been hard at work converting our specs to the rspec3 syntax. Jason on the other hand is a more recent addition to the team – his first commits date back to around September 2013. Nevertheless he’s been pretty hard at work solving vital issues and hard to crack bugs. Lately he’s been hunting down operating system handles we didn’t free up!

What impresses me most about the two of them is that they both have a family and a job but still find the time to work on open source. I hope I’ll be the same once I’m at that point in my life! I mean Eric even has 5 children! FIVE! I can’t even imagine what that’s like :) . But that’s super fun too. I’ll never forget remote pair programming with him with one of his kids running around in the background and waiving. Or Jason attributing the first open source contribution of his daughter on shoes. All super fun memories.

So everybody, shoes is coming. Try the preview release. Or wait for the next one. Or the release candidate. No matter what. Shoes is coming!

Shoes on!


HTML5 <video> and <audio> – supported formats and browser compatibility

16 Apr

With HTML5 video and audio tags are here and ready for use to easily enhance your websites with audio and video. The tags are available in all major browsers now, except for Opera Mini (audio video). You even got popcorn.js to interact with the media, make you web pages react to the progress of a video and build cool new media enriched websites.

The major problem with HTML5 media though so far has been browser support for the different media formats/codecs. Support has gotten a lot better – not great, but better. At the time of this writing it seems like you only have to offer 2 different formats for audio and video to support a wide range of browsers.

Disclaimer: I didn’t try this all out manually. I trust the data for Browser compatibility I found on the Internet: Mozilla Developer Network media format support, Wikipedia(HTML5 audio, HTML5 video)


Support mp3 and Ogg Vorbis – you can use other formats in place of ogg as well (and AAC in place of mp3).


Support H.264 (.mp4) + Theora (.ogv) or VP8 (WebM) should do the trick.

On a last not, if you want to convert video files you can use ffmpeg, e.g. for instance theora/.ogv to H.264/WebM:

ffmpeg -i demo.ogv -f mp4 demo.mp4

Hope that this helped :-)



Slides: Code is read many more times than written – short version from RailsGirls Hackday

24 Feb

With a bit too much of delay, here are the slides from the 15 minute “Code is read many more times than written” talk I gave at the Rails Girls Berlin workshop on the 15th of February:

Have fun coding, keep your code readable and clean!

after_do 0.3.0 released

19 Jan

I just released version 0.3.0 of my little aspect oriented programming/adding callbacks to methods library after_do! You can find an introduction here.

So what is in 0.3.0? Basically 2 things:

  • after_do now works properly with modules, meaning you can attach callbacks to the methods of a module and objects of classes including those methods will call them!
  • Fixed bugs around inheritance where it could happen that a block might get called too often or not at all

At the same time this release was able to delete code and remove complexity while improving functionality. How is that possible? Well thanks to block scoping it is!

One problem I always had is to figure out callbacks of which class to execute in combination with inheritance. You know – self is always the current object and callbacks might be defined in super classes. I wanted to have a way to know which class the currently called method is defined in, not what the class of the current object is. Luckily there is one point where I know that – the moment when I add the callbacks (since they are added on that exact class/module). So we just need to save it:

callback_klazz = self
define_method method do |*args|
  callback_klazz.send(:_after_do_execute_callbacks, :before, method, self, *args)
  return_value = send(alias_name, *args)
  callback_klazz.send(:_after_do_execute_callbacks, :after, method, self, *args)

Simple yet powerful.

Enjoy the 0.3 release of after_do :-)

How to get started with contributing to open source

13 Jan

I often see people who really want to contribute to open source projects. And that’s great! But often it’s not easy to get started. “What project should I contribute to?”, “What can I do on that project?” and “How does contributing work?” are common questions. It can be scary. I found myself in the same place around 3 years ago. Since then I contributed to a variety of open source projects and am heavily involved in a few (including my own projects). This post is here to answer these questions, give you some help, guidance and share experience.

Step 1 – Find a project

“Where to start?” “Which project can I contribute to?” These are usual questions. The most important principle here is “Scratch your own itch!” – work on a project that you use and that matters to you. There is no point in investing energy into something you don’t care about. Even better if you have a specific issue with a project: some odd behavior, a bug that you work around, a sub optimal API, lack of documentation… you name it. If you use some projects you’ll find a couple of those. I guarantee it – nothing is perfect.

Also try to see if the project isn’t too far off your comfort zone – e.g. if you are a ruby programmer and don’t know much C then contributing to a gem which is primarily a C-extension is probably not the best idea.

Have a look at how active the project is. You’ll want to contribute to a project that is still actively developed and where the maintainers react to issues and pull requests. For this you can look at a couple of things: When was the latest commit made? Look at the recent pull requests and issues: Did anyone comment on them? Is there a crazy amount of open pull requests, some of them like half a year old without activity?

Another advice: Try not to contribute code to a really big project (think: rails) straight away, especially if you are a beginner. Those projects are… well… big. It’s often hard to find the right place where a fix should occur. Familiarizing yourself with the code base unfortunately takes a lot longer as well. Also due to their nature, they often have a lot more issues and pull requests that the maintainers have to take care of. Often that results in longer feedback cycles, somebody else trying to fix the same problem and it diminishes the chance of making “a real impact”. It’s not the ideal scenario for first time contributors in my opinion. With small to medium-sized projects I often experienced that maintainers are a lot happier to get contributions and faster to respond.

Step 2 – What to work on?

If you’ve got an itch you want to scratch you are already mostly ready to go. But first make sure that the problem persists even in the latest release of the software (even better on master). Then search the issue tracker of the project to check if the fault has already been reported. If not, report an issue (or feature request) to see if this actually is a problem/a wanted feature. In the best case you provide a small sample script demonstrating the error along with an expected behavior from your side. You can already mention that you’d like to work on this.

If you don’t have an itch to scratch but a project you’d love to help out: have a look at the issue tracker. Some projects feature tags/categories for newcomer friendly issues – check those out first. Otherwise look for something that seems appealing to you and not too complex.

I want to stress that contributions aren’t limited to fixing bugs and implementing new features. Helping out with documentation is very valuable, that’s how quite some contributors get started. Also writing tests to increase test coverage or refactoring code (hint: some projects use Code Climate – you can check out code smells there) to remove duplication/make it more readable is often very welcome. I especially recommend the latter two as to do this you have to understand the code and therefore get a good first view of the code base without having to add anything.

Make sure to have a look at the README of the project. It often highlights how to figure out what to work on and which kinds of contribution are welcome.

Step 3 – Get your changes in!

Mostly you should make sure that there is an issue for what you want to work on (exceptions include small refactorings). In that issue comment that you would like to work on the problem, maybe outline a strategy to solve it if you already have one and ask for pointers and advice how to go about that issue.

Also look at the README – a lot of projects mention how they’d like contributions to be handled. Also they might have references to style guides or guidelines such as “provide test cases that fail”. A lot of them will also have instructions like these (at least on the most popular platform these days, github):

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Forking is basically creating your own copy of the repository which you can write to. Creating a Pull Request is like saying: “Hey, I made these changes do you want to have them?” In a Pull Request the changes are discussed, commented  and it’s basically the way to get your changes in. I recommend opening pull requests early – as soon as the basing building blocks are standing. The feature doesn’t need to work yet. This way you can get valuable feedback about whether this is the right approach as well as hints and tips leading to the right solution.

Closing Notes

Have fun contributing to open source! There are a lot of nice people out there happy to get contributions of any form. And I can tell you – it’s a great feeling to know you made something better for a lot of people (including yourself!). You might have seen an occasional story about big discussions or fights in pull requests/issues. Please don’t let that scare you. I can tell you that from my experience these are the exception not the rule. Most people in open source are really nice and work together for a common goal. Two and a half years ago I started contributing to the Shoes project. To this day this is the nicest online community I ever met with a lot of really helpful and polite people around! I stayed with the project ever since – gradually increasing my contributions.

I hope this post helps you to get started on your journey into the open source world. If there is something missing or you got more questions please feel free to add a comment.

Introducing after_do: after/before method callbacks in Ruby

19 Dec

I want to introduce you to a little gem I built and use in some of my projects: after_do. What it does is pretty simple: you can attach callback blocks before/after methods are executed. And it looks like this:

MyClass.after :some_method do whatever_you_want end
# or/and
MyClass.before :some_method do pure_magic end

As I don’t fancy monkeypatching you will have to extend classes that you want to use after_do on with the AfterDo module. E.g. for the code above to work:

MyClass.extend AfterDo

after_do has no external runtime dependencies and the code is around 160 lines (blank lines and documentation included) with lots of small methods. So simplecov reports there are a little above 70 relevant lines code (it ignores blank lines, docs etc.).

It works and is tested with current releases of all major ruby interpreters, e.g. MRI (1.9.3 and 2.0), JRuby and rubinius.

The github repo has some more documentation about use cases etc. – I won’t go into all of it here.

Why would I want to do that?

For me this catches the essence of Aspect Oriented Programming – doing something before or after a method is executed to fight cross-cutting concerns. What are these cross-cutting concerns? Glad you asked! They are aspects of your application that you can’t confine to a single class but are rather spread over multiple classes.

One of the most common examples is logging: Logging is done in many classes and many methods. As a result the real purpose of a method is cluttered with logging statements and it’s hard to get an overview of all the logging statements in your application at once.
Another example would be statistics: You might want to keep track of successful purchases, failed logins etc… the code to do so goes in the method that handle these cases but really doesn’t contribute much to its actual purpose. And I’ve seen people use global variables to make statistics gathering available everywhere. Yikes.

With aspect oriented programming you could have all of those in a single file and as a result not clutter the original methods at all.

Access to parameters and the object

For a lot of purposes it’s nice to have access to the parameters of a method call and the object itself – after_do gives you just that:

MyClass.after :two_arg_method do |arg1, arg2, obj|
  something(arg1, arg2, obj)

With this you can log events like a succesful purchase:

# Assuming CheckoutProcess#complete gets user as an argument
CheckoutProcess.after :complete do |user, checkout|
  @logger.log "#{} checked out #{}"

Removing repetition

Another use case is removing repetition from within a class. E.g. if you want to call the save method of an object after several different methods you can do the following:

class CoolClass
  extend AfterDo
  # lots of methods
  after :m1, :m2, :m3 do |*args, object| end

This might remind you a bit of before_action/filter in Rails controllers.

How does it work?

When you attach a callback to a method with after_do what it basically does is it creates a copy of that method and then redefines the method to basically look like this (pseudo code):

return_value = original_method

Why build something like this?

I was working on a side project after reading Objects on Rails and wanted to try to separate the persistence concern from the actual Object domain logic. For the fun of it and remove repetition along the way. My initial research didn’t come up with a good maintained tiny library to serve my purpose. So I wrote one myself, named it after_do et voila there is the solution to my initial problem:

persistor  =
Activity.extend AfterDo
Activity.after :start, :pause, :finish, :resurrect,
               :do_today, :do_another_day do |activity| activity

Nice, isn’t it?

Is this a good idea?

Always depends on what you are doing with it. As many things out there it has its use cases but can easily be misused.


  • Get cross cutting concerns packed together in one file – don’t have them scattered all over your code base obfuscating what the real responsibility of that class is
  • Don’t repeat yourself, define what is happening when in one file
  • I feel like it helps the Single Responsibility principle, as it enables classes to focus on what their main responsibility is and not deal with other stuff


  • You lose clarity. With callbacks after a method it is not immediately visible what happens when a method is called as some behavior might be defined elsewhere.
  • You could use this to modify the behavior of classes everywhere. Don’t. Use it for what it is meant to be used for – a concern that is not the primary concern of the class you are adding the callback to but that class is still involved with.

A use case I feel this is particularly made for is redrawing. That’s what we use it for over at shoes4. E.g. we have multiple objects and different actions on these objects may trigger a redraw (such changing the position of a circle). This concern could be littered and repeated all over the code base. Or nicely packed into one file where you don’t repeat yourself for similar redrawing scenarios and you see all the redraws at one glance. Furthermore it makes it easier to do things like “Just do one redraw every 1/30s” (not yet implemented though).

Ultimately, you be the judge. I’d be happy if you were to go ahead and give after_do a try, say what you think about it, report bugs and feature requests.


Get every new post delivered to your Inbox.

Join 756 other followers