ZEIT ONLINE has been relaunched

Allgemein / journalism

ZEIT ONLINE (ZON) has been relaunched a week ago. Over at zeit.de you will find a beautiful news site – no matter if you are browsing on your phone, tablet or desktop. A responsive news site relying on ad revenue is technically interesting. But there are journalistic innovations as well, that I have been longing for for years. During my internship in ZON’s Research&Development team, I have had the opportunity to help relaunching the page. Here are my favorite features:

Live Dossiers:


This is how a teaser looks like that links to the refugee live dossier on ZEIT ONLINE’s new page.

From a digital journalist’s perspective, the most exciting feature of the new page is the so called „Live Dossier“. At some point of an ongoing news event, like the refugee crisis, many people loose track of what is happening. ZON’s live dossiers recap the most important stories, provide context and link to the original reporting for further reading. The tool will evolve, but I think the basic version, ZON is starting with, is very promising. Check out the live dossier about the refugee crisis.


ZEIT ONLINE has also relaunched it’s quiz section. Readers can write their own quizzes now. The new tool has been designed mobile first and can be embedded into other websites. Check it out, build your own quiz and share it with your peers.

Card Stacks:

ZEIT ONlINE's new card stacks.

ZON’s new card stacks. This one is about refugee-prejudices.

Card stacks will give ZON’s editors a tool to deliver (fun-)facts in an interactive way. One of the first card stacks is fighting prejudices against refugees. Yes, card stacks are similar to slideshows. But they are not the same thing at all. Editors can combine text and multimedia content in card stacks and there are interactive elements like choice cards, offering content based on the user’s decision.

From a web developer’s perspective there are many more features and problems that have been solved by ZON’s developers.

  • They have implemented a single sign on server unifying the way users log into different services of „Die ZEIT“. No matter if the user wants to comment on an article or read the print edition’s epaper version – he can log in with the same credentials now.
  • Editors have new content management tools. They can for example decide if sub pages should be filled based on content queries or manually.
  • zeit.de consists of way more than just one CMS, data layer and front end: There is a whole blog ecosystem based on WordPress, comments and community powered by Drupal that have been integrated seamlessly and relaunched at the same time. The Android and iOS Apps will follow suit.

Personally it has been an exciting project for me and it will be for the next month. I started with testing tasks, dived into the quirks of the CMS implementing new views and content queries. I went on demoing the new features to the editorial staff and got in touch with managing this huge agile project by helping my colleagues Michael Schultheiß, head of R&D, Johannes Neukamm (CMS) and Holger Wiebe (Blogs) writing user story based tickets.

Build passed: Graduated from Makers Academy


Some photos I have taken over the past six weeks at the Academy and around the corner…

I have had a soundtrack as well.

Time to have Dinnr


I’m in my last of 12 weeks Makers Academy. It’s hard to believe and at the same time I’m okay with it. Maybe I’m spoiled by our smooth and rewarding final project but I feel ready for the market. I want to build apps that are actually used.

But before I tell you about my plans (in another post) I will tell you about „Dinnr„. The idea was pitched to us by my friend Patrick Abele.


Dinnr is fully responsive and works great on smartphones and tablets.

Dinnr is fully responsive and works great on smartphones and tablets.

Let’s say tonight I want to cook Pasta. I have recently moved to London, I work until late every day and besides my colleagues I barely know anyone in the city. But cooking for myself is depressing. That’s why I post my plan on Dinnr. I tell the community what, where and when I’m going to cook and they can apply for my event.

Thanks to the web development framework Ruby on Rails, this basic functionality, our „minimal viable product“, was done after day three of our nine day project. And thanks to Materialize, Google’s shiny front end framework it looked alright, too. Users could log in (also via Facebook), they could publish their event and join other events.

Every night we „pushed“ our latest stable version to Heroku. Heroku is a service that makes websites instantly available on the internet – if you follow the rules and best practices. If you don’t, it can easily take hours until you know what is going wrong and days until it is actually working online. That happend to us in the very beginning. We had to figure out how to integrate the design and user experience bits and pieces we had installed using Bower. Locally it was working fine. But when Heroku tried to compile everything, it lost track of our bower-components. Thanks to our coach Ben we found out how to get it working. He has written a blog post about the Bower with Rails issue. With this setup in place later on we could install JavaScript-Plugins in minutes. Masonry for example, that makes the cards on our front page use every bit of space in the browser window (Try resizing it – I love that effect).


87 tests, 98 percent test coverage.

87 tests, 98 percent test coverage.

Before the project I wasn’t sure how we could work with four people on the same app without stepping on our feet all the time. But it was actually quite easy using GitHub:

  1. Each feature was developed on a so called branch. A branch is based on the main code repository. But if something goes wrong you can leave it without affecting the code base.
  2. When a feature is ready, we merge the newest version of the project, containing changes the colleagues have recently made, into the branch.
  3. We run our tests and if everything fits together, we include the feature branch into our master branch.

Without our tests we would have had to try all our features before merging different code versions by hand. Instead, a virtual capybara ran to our site, clicked links, filled out signup and event creation forms and looked for certain content.

Writing those tests can sometimes be quite tricky. It takes some experience to know what to expect and sometimes it’s really hard to teach Capybara what you are looking for.

Testing Google Maps

One example for difficult tests is the map you find on Dinnr.herokuapp.com. The map on the front page is expected to show all events that have been saved in the database. But unlike us, Capybara doesn’t see the map by default. Mainly to save time, the test tool opens the page without running javascripts and without the scripts the map doesn’t get loaded.

It took me a whole day to find a way to test the map. Since I wasn’t the only one looking for a way to test maps, I have outsourced this information to Stack-Overflow.

One more word about the map. I used the Rails-extensions (gems) geocoder and JBuilder and the Google Maps API. When an address gets saved into the database, geocoder uses a Google service to translate the human readable address into latitude- and longitude geo coordinates and saves them into the database. With JBuilder I created our own API that serves all geocoded events or a single event in a machine-readable format called geoJSON. If Dinnr became very popular some day other developers could use the same API as well to display Dinnr’s events on their sites linking back to Dinnr. If it doesn’t, we just have a clean way to feed database content into our map.

Factory Girl, besides Paperclip the second gem in our stack that has been created by the awesome thoughtbot team helped us to populate the database with test content.

All those efforts ended up in 87 green tests and a test coverage of more than 98 percent.

Agile Project Management and Development

Trello board for Dinnr

Trello board for Dinnr

I guess, this project would never have been such a pleasure to work on if we had not used tools out of the agile project management toolbox. We used a Trello board with columns called Backlog, To Do, In Progress and Done. We enjoyed our stand up meetings twice a day and an additional „merge party“ towards the end of each day.

Personally I’m really happy with what we have managed to build in nine days. Rails is a great framework if you want to build a database-heavy application. After Yelp clone this was my second Rails app and I am sure that next time many things will go even faster.

If I go on working on the project, the next features will be a workflow for event hosts to accept and deny guests and a search function to filter events by location, dietary, time and host.

You can checkout the code on GitHub. And a live version of Dinnr on Heroku.

Ready for the finals


Today I’m going to start my final project at Makers Academy. Kate Beavis, Chris Ward and Sean Haughton and I will build a social network for people who like to cook together. My friend Patrick Abele came up with the idea some time ago and responded to my call for pitches two weeks ago.

There have been several great ideas pitched to me. Kersten Riechers and Tobias Reitz remembered me of their idea „Corrigo“ – a browser plugin that let’s users correct news articles.

Rebecca Sandbichler proposed a Tinder-like tool to match volunteers with people who need help. Matthias Bastian suggested building an user-engagement tool for news sites. Dennis Hoenig-Ohnsorg asked us to build a tool for the Ashoka volunteers network. And Jannik Finkbohner shared his thoughts about a sports club management system.

Thank you very much for sharing your ideas!

I am very happy that at least one of the ideas, that have been pitched to me, will be built within the next two weeks. I will keep you informed about the project.

Pitch uns dein Projekt und gewinne 450 Webentwickler-Stunden gratis


Ich werde mit vier weiteren Makers-Academy-Studenten zwei Wochen lang alles geben, um ein überzeugendes Abschlussprojekt zu programmieren.

  • Aktuelle Technik: Ob Angular, Node, Backbone oder Rails – wir wählen das beste Tool für den Job.
  • Test driven: Wir liefern keinen Code aus, der nicht durch und durch getestet ist.
  • Wir legen Wert auf sauberen, objektorientierten und gut lesbaren Code.

Weil wir uns auf die Technik konzentrieren wollen, können wir keine inhaltliche Recherche leisten. Wir können auch keine Garantie dafür abgeben, dass das Produkt am Ende alle Wünsche erfüllt. Aber die Abschlussprojekte meiner Vorgänger beweisen meiner Meinung nach, dass sich die Zusammenarbeit trotzdem lohnen kann.

Ob Datenvisualisierung, Webapp, API, Prototyp oder Produktivitäts-Tool für die Redaktion – wir sind gespannt auf Deinen Pitch!

Per Mail an thomas[at]codereporter.de.

Clandestine chat, personal calendar and spotify-magic


I am a senior now. I guess the next six weeks will be the only time within the upcoming years in which I will be considered to be a senior web developer. But it’s true. The „old“ seniors have finished their course, a funny bunch of new juniors has just finished the Marshmallow-Spaghetti-Challenge and my February-cohort has moved over to the project desks.

In order to give you an idea what I will be programming during the second half of the course, I want to present my predecessors‘ final projects:

1. Meshee: A clandestine meshnet chat

Meshee logoMeshee is a chat app providing encrypted chat rooms. But encryption isn’t the only layer of protection for Meshee users‘ communication: The tool doesn’t use the internet. Users connect via their computers‘ WLAN connections. A tool called CJDNS establishes the encrypted ad hoc network. Meshee runs on a node.js server and provides key-protected chat rooms to connected users.

I sadly cannot show you the tool since it’s running in local networks only. But if you know how to speak code, checkout the repo on GitHub.

Stack: CJDNS, Node.js, Frontend (HTML, CSS, JS)

Team: Kieran Goodacre, Jin Dai, Clint Pijuan, Jacob Mitchinson

2. SMS sending website for „The Horsell Snow Angels“

The Horsell Snow Angels from Surrey (UK) help elderly people with their daily tasks when weather is too bad for them to go outside. They help them to shovel snow or to walk the dog. Until some weeks ago organizing the volunteers was quite a time consuming business. But a team of five Makers students have built an app that helps the project managers.  They can send SMS to potential volunteers to check their availability. It helps the manager choosing the volunteer closest to the task by displaying all available volunteers and tasks on a map.

Stack: Ruby on Rails, PostgreSQL, Unix, APIs (Twilio for messaging and google maps), Frontend (Javascript, HTML, CSS).

Team: Bibiana CristofolJake AlvarezJosh BebbingtonRichard IghodaroSteph Oldcorn

Link: The Horsell Snow Angels, the app’s repo on GitHub 

3. Turn up tune in: Never miss your song again

Turn Up Tune InHave you ever asked the DJ to play a song for you? Have you ever submitted a wish to a party’s playlist? If so, there is a high likeliness you were not in the room when your song was actually played. „Turn up tune in“ tackles this issue with Beacons, an Android app and the Spotify API. People who have been invited to the party can go to the party’s playlist management page and choose their favourite songs from the spotify database. If a song has already been added to the list, the user is informed about that.

Once the user turns up at the party and turns on his smartphone’s bluetooth transmitter, a Beacon will recognize him and the app adds his songs to the playlist. If he goes out for a cigarette, his songs vanish from the list. When he enters again his songs get enqueued. And so on.

Team: Hannah CarneyMatteo ManzoAndy NewmanJack RubioMarcin Walendzik

Stack: Front end (JS, jQuery, HTML & CSS), Server (NodeJS, Express), Database (MongoDB, Monk wrapper)

Link: Turn up tune in webapp, Code on GitHub.

4. „I am me“: a personalized event calendar

iamMEFor Londoners it is a serious problem: There are so many events happening every weekend, that people find it hard to choose where to go. The „I am Me“-Team developed the page for a real client who had come to Makers Academy to pitch his idea during the final project jamboree.

Ptolemy has reflected on the project himself.

Team: Danielle Demkiw, Gus Powell, Charlie Walsh, India Dearlove, Ptolemy Barnes

Stack: Server (Ruby Rails, Heroku, AWS S3 Buckets), Front end (HTML, CSS, JQuery, JS).

Link: Calendar web app on heroku, Code on GitHub

5. One day in the life of an engineer… pilot… president…

This project was developed for the Barcelona based project One Day. The idea is to show young people how it would be to work as an engineer, pilot, or whatever they might be interested in. The website the Makers‘ students developed will feature curated information about professionals across different industries. Young people can contact and finally spend a day with them to get a better idea of the job.

Team: Emily SasSanda GolceaLuke ClelowJohnathan LakinHuy Le

Stack: Rails, Ruby, Devise, Front end (JS, JQuery, HTML, CSS), Google Maps API & Gmaps.js

Link: One Day prototype on heroku, Code on GitHub

6. Makerbot: A slack bot

Makerbot was not a final project but a Makerthon product – developed during the eighth week of the seniors. Makerbot lives in our highly frequented chat app Slack and can answer questions about upcoming talks, nearby restaurants and more. The code can be examined on GitHub.

Week5: JavaScript and APIs


A bit more than five weeks ago I tried to read a programming book. It was recommended as one of the best books to learn Ruby with. I had a feeling that „The Well Grounded Rubyist“ was a really good book. But I didn’t understand it. The author David A. Black writes about hashes, arrays, variables and things called methods that are called on objects. It wasn’t a very pleasant read.

This week I have started to learn JavaScript. My second programming language after Ruby and I am impressed how much easier it is. Not because JS is somehow easier (it actually looks a bit intimidating in the beginning). It’s easier because I can focus on vocabulary, syntax and differences between the two languages now. The basics are the same. I am far from being completely fluent in either of those languages. But with the documentation at hand I can get things done. I was very happy to find that I could write Fizzbuzz and the airport-challenge in JavaScript as well.

The language of the web

So far I like JavaScript. I got used to the brackets and curly braces within days. What I like the most? It’s deep connection to the web. There is no modern browser it doesn’t run in and it’s hard to find a website that doesn’t include any Java Script. After a ten-year-long intense relationship with the web, I am finally learning the language web services communicate in.

Today I wrote a little script that pulls a list of 38 cities onto a simple website. When the user chooses, let’s say Athens, from the menu, my script connects to the API (Application Programming Interface) of openweathermap.org and returns Athen’s current temperature. I was quite excited about this useful little tool. So excited that I stayed at the academy until I had found a way to get the cities‘ geo coordinates and query Instagram photos taken around Greece’s capital as well. Once the layout is somehow presentable I will show you my first handmade mashup.

Welcome to Chitter


True. It’s not the most user-friendly web app ever made. And it’s not particularly beautiful either, but I am very happy to present you… the new Twitter: „Chitter“.

Chitter was last weekend’s challenge. You can read messages in a public stream, you can sign up to write messages yourself. That’s what we call the Skateboard at Makers. The „Minimal Viable Product“ (MVP). A Twitter-clone should at least offer those features. Right now I am very tempted to keep working on Chitter. Maybe find a better name and then bring it from status skateboard to car (going through bike, scooter and maybe some other states). But I think there are more rewarding tasks than copying Twitter.

In case you wonder, why I am so excited about this silly website:

  1. I have written every single line of the code
  2. The messages are stored in a PostgreSQL-database via the Object Relation Mapper „Datamapper“
  3. The logic (models written in Ruby) is separated from the views (HTML/CSS) and connected by the controller using the minimalistic Web framework „Sinatra“.
  4. The passwords get encrypted before being saved to the database

Even though this was a two-day-beginner’s-project, I have developed it the way modern websites are built. I am now familiar with the basic concepts of modern web development which I can build on.

An entrepreneur enabling startup: The story of Makers Academy


There is more to a startup than a brick-walled office space, bean bags and a ping pong table. A startup needs a product and a story.  Last week Evgeny Shadchev, CEO and co-founder of Makers Academy, told us how much pain it was, to find the beautiful office in which I’ve been learning how to code for three weeks now.

Little more than two years ago, on February 18th in 2013 the first cohort started . Evgeny’s story starts a couple of years earlier though. He had been working as a software developer for different companies. As tech co-founder he had built a price comparison browser plugin called „InvisibleHand“ (which was later sold to Skimlinks by the remaining founder). And he had co-founded „Forward Labs“ in 2012, an incubator that was merged with Forward Venture Partners and branded Forward Partners. This is where he eventually met his co-founder Rob Johnson.

Two founders share a need

The following conversation between Rob and Evgeny was going to give birth to Makers Academy one year later. „I complained about how difficult it is to find talented developers“, tells Evgeny. „Seniors are like unicorns. They basically don’t exist. And juniors usually don’t have the skills to hit the ground on day one. And once they have experience they tend to go somewhere else.“

Rob Johnson on the other side shared his experience of how difficult it had been to teach himself how to code. „He had started with „Objective C“ (bloody difficult, bad idea). Than shifted over to „C“ reasoning that if Obj-C is based on C, he should learn that first (worse since C is even more difficult than Obj-C)“, Evgeny tells. Even though Rob finally managed to finish Apps that were sold in Apple’s app store, it was a perfect match: „Maybe we should start teaching people how to code.“

Learning how to code - with coaches, in good company and in a pleasant environment.

Learning how to code is hard – but it get’s way easier in good company, with coaches and a tested curriculum.

The first coding schools in the United States had started. It was the beginning of the entire „learning-how-to-code-movement“ and it seemed like an interesting business, Evgeny says.

Around Christmas in 2012 they decided to do it and Evgeny quit the incubator. They had a product: They knew how to code and wanted to teach people how to do it. But „we had no Curriculum, no team, no nothing. We didn’t even know if there would be a demand“, Evgeny looks back. They put up a simple landing page: „Hey, we will teach you how to code. It will cost you 3000 GBP. We have no idea what we are doing, because we have never done it before. But if you are interested – please apply.“ And much to the founders‘ surprise, around 15 people applied of which they finally accepted nine students.

Far away from breaking even

They started looking for an office space four weeks before the course was meant to start and luckily got the keys one week before.  „We got furniture delivered on Friday. On Saturday, two days before the start, Rob and I went to Ikea and bought a few sofas, plants, coffee mugs and cutlery. We assembled everything over the weekend…

and on Monday the course started. We began with building Rails Applications in week one. Probably the worst idea ever.“ Nowadays the „Ruby on Rails“ framework is postponed to weeks eight and nine of the 12-weeks-course.

Evgeny treports on a constant struggle in the first seven month figuring out, what to teach, how to teach and at the same time hiring teachers, raising money and promoting the course in order to receive applications. They planned to extract their business out of the incubator that had financed the startup. And in the middle of all that trouble Evgeny wanted to prepare his wedding scheduled for summer („A very good idea to marry. But on the other hand, leaving the office was absolutely out of the question. I was probably half of the coaching team and half of the everything-else-team. Additionally, in the first year of your startup, whatever money you have, has to go into the company.“) They cancelled the wedding and instead of getting married in the end of June they married the day the May-cohort started. „I was getting married on Monday. I had my honeymoon on Tuesday. But I was back teaching on Wednesday“, Evgeny says.

„Excel is cruel“

In July and August of 2013 Makers-story was close to it’s end. Evgeny and Rob had seen no way around raising the tuition fee to 5000 GBP. The demand went down and on top of that they didn’t have enough staff to run the July course, which had to be cancelled. An office in central London and a full-time team is too expensive to maintain when the cash flow goes down. „But for some reason the demand went up again. We didn’t know why. But it did; and in August we had a group of 19 students – the biggest cohort so far. We had finally a better idea of what and how to teach and it was an amazing cohort.“

In September they had 23 students. Everything seemed to be fine. But „Excel is cruel: we were still loosing money.“ At 5K they figured, they would never break even. It looked like a lose-lose-situation: Either they raised the price again to 8000 GBP, accepting the risk of shrinking demand. Or they kept losing money. They took the risk. Demand went down – but later up again. In November, nine month after founding, Makers Academy broke even. („Short time before our accounts were empty.“)

„If you ever have to choose between fundraising and finding an office space in London…“

After this first roller-coaster-like year 2013, Rob stepped down as CEO in March 2014 and went to Germany. Evgeny had to run the company now, leaving the teaching to his team. In 2014 the sea calmed down a bit. But it didn’t get boring. „We worked a lot on improving our curriculum. And we built a placing team that helps our students to get jobs as junior developers after graduation„, Evgeny says.

His major worry in 2014 was that the office contract was about to end. Evgeny had to find out: „Finding a new media office space in London today is harder than raising money. If you have the choice – try raising money. It will be easier!“ He realized there is less space available than one might think, seeing to-let-signs on the street. But if you narrowed it down on your needs and your desired location there was little left – most probably the most expensive ones only.

Birthday party and exciting final projects

Evgeny doesn’t say how he managed to find those brick walls for his business, nor how much he pays for them. But now that they have moved, he and his colleagues can focus on new projects again: In February they started the online coding course „Ronin“. Eight students mostly from the UK are connected all day long via Google Hangouts, GitHub, Skype, Slack and so on. „I would really like to offer the Makers Academy course ten times cheaper. A great number of people cannot afford 8000 pounds plus living costs“, Evgeny says. „Ronin“ is a major step to a cheaper coding course. But they are also talking to the government and other organizations to find sponsors for the in-presence program.

There will be a birthday party on March 6th. It will be the day my senior fellows of December cohort will graduate. I’m really excited to see them starting their final projects. There is a drone flying around here and what I see on the whiteboards seems promising. In one of my next posts I will tell you what they are up to.

The Kindergarten-state-of-mind

Tom keeps focused.

„Don’t worry about feeling stupid.“ They keep telling you this at Makers Academy. „You will get used to not knowing how things work,“ is another piece of advice I have heard several times.

But I do worry that I’m too stupid to get my head around this. I thought I knew how to make my objects talk to each other. I thought I had understood that a proc wraps a method to have it executed within another. I meant to know which tests I need to write for each class. But I run into the same problems again and again.

Battling the ships

My pairing-partner Chris and I have produced a small stack of models during the last week. We found out that it is better to delete some lines of code than to pass hours fiddling around to get the old lines working (again). The code we wrote could have been written within two hours maybe. But we had to think about how a ship could get onto the board and how it would be hit by one of the player’s shots.

One of the things I really like about Makers: we often start from scratch or at the same basis. This week we will extend our battleships-game with a web-interface (very excited about that!). (After programming a text-message-sending management system for a takeaway-restaurant during the weekend). Our coach Stephen is writing the underlying code-basis for battleships web in front of us. I think that’s perfect. Since I have tackled the problem for so long, I can follow his writing and I see how he is solving the issues.

When he programs one class, he doesn’t include the other classes at all. Let’s say he wants to program how the game ends:

  1. Write the RSpec-tests:
    it “knows a game is not over as long as none of the players has lost” do
    expect(game.over?).to eq false
    it “knows a game is over when one of the players has lost” do
    allow(player_one).to receive(:lost?).and_return(true)
    expect(game).to be_over
  2. Make the failing tests pass:
    The easiest way to make the first test pass is to creat a method called „over“ and make it return false. The second test forces you to change the code: Line one is the human-readable test. Line two makes player_one answer with „true“ to the method „lost?“. With this line we state that player_one has lost no matter what his board may look like.  Line three is the actual test. It expects the game to return „true“ when confronted with the  method „over?“ (RSpec looks vor a method „xyz?“ ending on „?“ when you write „….to be_xyz“).
  3. Code:
    def over?
    player_one.lost? or player_two.lost?

The coaches keep saying that testing (TDD) and class modelling (OOD) are two of the most important things we have to understand if we want to become web developers by May.

I try to stop worrying. I try to adopt the Kindergarten-state-of-mind, as Sam called it during my darkest hours at Makers last Friday.