5minutenpause

full-stack web and mobile developer from Berlin

A slider gallery that works with photos and inline videos

| Comments

Suppose you want to display a slider gallery on your website. After all it’s one of the most requested features clients have these days. Now suppose further, that you chose a third-party library for this, as you don’t want to code it by hand. It might be a nice exercise to do it all by yourself but please show me a client that actually pays for the time it takes you to do that. Then I’ll code you three different sliders. Promised.

Anyway. Your slider is all nice and works really well. Fast-forward three months. You get a call from your client. Everything fine. Except: She wants you to modify the slider so she can include videos in between the pictures. You begin to quietly laugh hysterically but she throws you a bone: It will just be Vimeo or YouTube videos. No custom video player necessary. (At least for now… You know how it goes… If you need a heads-up on html5 video that plays in every browser, I wrote a little about that)

But fear not brave frontend developer. Your brothers and sisters have a solution to fight the dark hordes of feature requests: Fotorama.io slider. I have to admit, I always want to write futurama.io. That would read even better, I’d say. ;-)

So let me give you a little intro to this slider. There will be two examples, one HTML only example and one where I include the slider in a Rails 4.2 project. Yeah we are that bleeding edge over here. ;-)

Listen to the (bug) people

| Comments

The Bug

The other day I had a weird bug happening: We had a responsive website with a dropdown menu on phones. Usually everything worked alright. Sometimes the menu wouldn’t show, though. This happened mostly on Android phones, the testers said. Of course we had to fix this as a menu just has to work no matter the device.

The debugging

So how do you track something like this? You start by reliably reproducing the bug. You want to have a set of steps that always lead to this bug happening. This means it’s a deterministic problem and you have a valid chance of fixing it.
When you try to reproduce it take notes on what is happening. Make sure to write your notes without making assumptions. At this point in the debugging process it’s not your job to find a solution or reason for the bug. At this point it is your job to note the behaviour and trying to describe the bug in detail and all the side effects you are noticing.

This is what we found:

Please ignore everything

| Comments

The other week I went on vacation with my family. We flew to Switzerland and had a really great time. I took the big camera to make gorgeous shots of my wife, my baby daughter and the Alps. The iPhone camera is great but pales in comparison to a professional camera. As I am no great photographer you can see this in every shot. But still, the pictures I made with the DSLR are just better. When using a big camera I always try to take more time for the composition of the shot. I use the lens, different focus spots and depth of field way more than when shooting with my phone.

Because my photography skills still lack, I try to read articles from professional photographers to get ideas and tips on how to improve. An article that made me think was about a photo-marathon in Munich (in German). A photo-marathon is a one day event. You get multiple themes and have limited time to find a suitable picture for each. One thing I noticed was the photographer who wrote the article made sure to have a distinct visual language present in every photo he took: He cared for a hard horizontal line in the lower third of the image and wanted to only take pictures of architecture. His skills are on a very different level than mine but we both took the time and tried to think about what we want to show in our photographs and how to frame it. You could call it a style or a handwriting that your images show.

That made me wonder: When was the last time I really thought about my coding style and handwriting?

A Gruntfile for frontend developers

| Comments

If I do any frontend development I want to make sure I can concentrate on the important things. Things like writing Sass, HTML or Javascript. I don’t want to spend time on basic stuff like copying files or making sure my Javascript files have a semicolon on every line. This is were task runners or build tools come into play. There are quite a few too choose from. My current frontend workflow is based on Grunt tasks. If you are still getting started with Grunt, or just never took the time to set it up, here are my tasks. Use them if you like and please let me know if there are things I could do better or if there are any questions.

Comprehensive guide to deploying Rails applications with Mina

| Comments

I have this small SaaS web application. It has no homepage and it has no signup form or signup site. It has no marketing campaign and people only hear about it from current users. I manually onboard new users and show them around, personally. From face to face. To put it short: “I do things that don’t scale”.
The people using my software depend on it for its purpose, though. They earn real money using it and they are serious about it. They have feature requests and get annoyed when something doesn’t work — for good reason. That’s why whenever I develop a new feature or roll out a security update or fix a bug, it is really important that I don’t mess things up. It is okay to have a few minutes of downtime when the app restarts, there is no need for deployments with zero downtime. But other than that, the software and all things the users got comfortable using should work as intended.

To achieve this there are a few things in place that make this easier for me. Let me tell you about them.

Enter: comments

| Comments

After having people ask me for it and considering the benefits, I will enable comments on my blog. Right now I’ll use disqus.com for this purpose. I am in the middle of creating my own comment system — based on Github issues — but that’s still a work-in-progress and I don’t know when I’ll be able to finish that. So please try commenting if that’s your thing.

Thank you.

Start hacking

| Comments

Some people learn programming because they want to fulfill a wish. Perhaps the wish is to get a (new) job. Or they want to take on a career where you can be creative and get paid well. Some learn programming because they have an idea for a piece of software, an app or a service.
Once they’ve completed the introductory course, you often see them stumble and wait. They aren’t sure what to do next, afraid to not know enough to get started with their idea. They go hunting for even more lessons on programming. Hoping the next course will teach them the things they don’t know yet.
Well here’s the secret:

I am just like you.

| Comments

I have a list in my simplenote app that contains ideas, headline and snippets for possible future blog posts. Right now there are about ten entries. It’s hard to tell how many exactly, because some are just a headline for a kind of mini series about something. Some of these possible posts are about ruby/rails technologies. Some are about workflows (e.g. deployment). One or two are about things I did earlier in my career, so they are something about funny or interesting anecdotes, or just for reliving and remembering things. Some ideas are even about me.
But all these posts have one thing in common: They are for me. Every single post would eventually be written by me for me. What I mean is, that these topics are things I have a personal interest in. Let me make an example:

So, he doesn’t know this, huh?

| Comments

You and I, we develop software. The things we create run inside browsers and on smartphones. They run on computers and on servers. They serve the need of some, and sometimes the needs of hundreds. Or thousands. Or, if we are lucky or have the right setting, millions use our software or parts of it. The systems we develop and write have many moving parts. They consist of a lot of different technologies. Depending on what you develop, you have to be a generalist, more than a specialist. But it depends.