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:

<code>ffmpeg -i demo.ogv -f mp4 demo.mp4</code>

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.

2n edition of HU course – with blog and material

23 Oct

Hi everyone,

today was a great day! Today was the first day of the second edition of the course about the basics of web development I’m teaching at Humboldt University Berlin. I had a great deal of fun and am already looking forward to next week.

Anyhow, the course now has its own blog where I share presentations, homework etc. The course is held in German only, so the material is only German as well. The course is aimed at total beginners (e.g. minimum requirement: “You should know how to use a computer.”).  When looking through the material please keep in mind that it is not made for self-study – it is made to be presented. Also it is for real beginners and therefore sometimes makes abstractions/simplifications for the sake of productivity.

So without further ado, enjoy the blog:



Hire motivated talented Ruby/Rails engineers from an educational program today!

7 Oct

So if you are here, you are probably looking for some Ruby/Rails engineers. Many companies (and therefore recruiters) are but they are hard to find. Luckily we have programs in place to get more people, especially woman, into coding, such as Rails Girls (and our local Berlin group) and Open Tech School. With the current shortage of programmers I want to urge you to give alumni of these programs a chance. The programs go far in their support, it ranges from workshops, to weekly meetups and even a full 3 month hands on learning program with good coaching/mentoring like Rails Girls Summer of Code (I wrote about ways to continue to learn here). But the last step of success is mostly out of the hands of those programs. It’s in the hands of companies to give the alumni a chance and hire them as an intern, trainee or junior developer (yes I believe some are ready to be a junior developer).

Why should I hire alumni?

I believe there is one thing you need to especially consider when thinking about alumni from such a program: those people made a deliberate choice to quit whatever their former career was and get into programming. You know it can be hard and rough – especially when you are starting and you are mostly on your own. It takes a lot of determination to go through with it. Determination to sit at home and figure out that one bug in your sample application instead of watching TV or whatever. And a lot of passion.

Also they bring in all their rich experiences from their former careers which can help in a number of ways that none of us can predict. They’ve got ideas that I couldn’t even dream off.

Moreover programming and technology is full of self-taught individuals, so it should be second nature for us to give them a chance. At a recent Berlin JavaScript user group I asked how many attendees had undergone formal computer science education – just ~60% of them raised their hands. Which means ~40% didn’t – quite impressive!

These are not your common graduate students

When you assess these programmers for a position please keep in mind that they haven’t undergone any formal education. They know about Ruby and Rails but they might not know about Java or the lambda calculus or the inner architecture of a CPU or whatever they teach you at a university… (note: I’m studying and am at the end of my Master studies).

The question is: is all that knowledge really important? In my opinion: No it mostly is not! I believe that a lot of this knowledge is not necessary for a specific job and that you can pick up what you need when you face a problem. Example: UTF-8. It’s really great to know how UTF-8, Unicode etc. work but what are the practical implications? For me it mostly boils down to: “Oh look some character is not displaying correctly. Okay let’s change the encoding to UTF-8. Works.”

There also are a lot of things that you rarely ever touch again like Turing machine, formal grammar, details of how the Windows Kernel works, higher math, TCP/IP stack… I could go on. Of course this all depends on your field of work: If you do 3D computation you probably need higher math. If you do network security or some optimizations you need good TCP knowledge (which is totally interesting by the way). But most of the time you don’t and then when you get to it you will have to refresh your knowledge again either way.

Also alumni sometimes might not know what a specific term means (e.g. polymorphism) but chances are they already use the concept – they just don’t know the name.

Meet some Rails Girls Summer of Code alumni

As you might know I’m from Berlin and so I know some of the local teams. A lot of them are looking for jobs right now and I asked them if I could include them in this blog post and here are the people that I know, asked and said yes. I want to highlight that I know all of them as extremely motivated and capable learners and programmers. All of them were coached during the summer by coaches I know and highly respect :-)

I might not be up to date with their current job status, so some of them might already have a position. In that case, keep them in mind for the future ;-)

So without further ado, let me introduce:

Susanne and Tam from Team Highway to Rails

I’ve known Susanne and Tam for some time – they are among the founding members of the rubycorns, a weekly study group that Til and I coach. The two of them have always shown a great interest, motivation and effort (especially when working on homework) in the study group. So it was no surprise to me when they applied for Rails Girls Summer of Code. Unfortunately they were rejected. But here comes the real surprise and what really impressed me: they didn’t even think of giving up. Nor for a second. They buckled up, put in the extra effort and looked for an opportunity how they could make it happen for them either way. That’s some real motivation right there. And they found Absolventa where they did their voluntary Summer of Code as Team Highway to Rails. They worked on event_girl an “open event-logging system with triggers/hooks to run arbitrary tasks when an event is matched or not matched.”.

Want to get in touch with them? Great!

Carla Drago from Team Inchworms

Carla has been one the first students we ever had at Rails Girls Berlin and went on to be one of the founding members our famous first study group the Ruby Monsters. After finishing their initial project the group went on to their next project: the speakerinnen liste. The “monsters”, as we call them, now help on multiple workshops as coaches teaching new attendees Ruby on Rails, which is awesome. As a little fun memory from myself: I once went to their project group meetup several months ago eager to help them with problems. Many didn’t need any help at all and when they did it was a hard problem, that took me quite some time to figure out. During this summer of code Carla worked as a member of team inchworms on sinatra and farmsubsidy. Here is Carla’s LinkedIn.

Laura Wadden from Team Railsgrrls

I met Laura for the first time when she was in my group at our Rails Girls Berlin anniversary workshop. Right from the start I noticed that she had an extraordinary fascination for programming. Laura has a strong background in working with nonprofit organizations, fundraising and event organization as this is what she mainly did before her journey into coding. During this summer she worked on the learners directory and a new programming language on top of Rubinius called lani. I’ve been the mentor for the learners directory, but her deep interest into how programming languages work really impresses me. During the summer of code this team had their own table at the Soundcloud offices – giving them one of the best learning environments one can think of with lots of awesome people around to help. Oh and here is her LinkedIn profile.

Nina Breznik of Team Spree Girls

Nina also had the luck of being able to work from the SoundCloud offices, that’s where I met her. Her team is working on the spree commerce project an online web shop written in Rails. It’s quite the challenge to understand a system as complex as spree, even more so as a beginner. As far as I can tell they are doing well and making progress – also thanks to the supporting environment. You can find her on LinkedIn.

A few words of thank you

Last but not least I want to thank everyone who was ever involved in a free educational program. Be it sponsor, organizer, coach or mentor. You are awesome! Without you all of this would not have been possible. I especially want to highlight Sven Fuchs and TravisCI without whom Rails Girls Summer of Code would not have happened. Period. Also github for their gracious donation (and for being super supportive and awesome in general). And to SoundCloud once again not only for their donation, but for offering work spaces and coaches  to 5 students (did I forget anyone?) and the possibility of an internship for two students afterwards.

I’d really like to thank each individual but this blog post is too long already. So this heart will have to do: But really, thank you so much!

And as for the purpose of this blog post: If you want to hire or just talk to any of the programmers listed here please do so. This of course not only goes for them (those are just the ones that I happen to know pretty well and got permission to “advertise” them). This goes for everyone. There are lots of people out there who want to make a career change and lots of companies in need of good, passionate developers. Get together, together you can reach your goals. Help them make the next step and I’m sure you won’t regret it.


Get every new post delivered to your Inbox.

Join 700 other followers