During the last few weeks I rewrote an existing PHP application with rails 4. Since basically everything changed (including DB schema and even DB type) a new hosting provider was also interesting.

After some research Heroku and Amazon EC2 seemed to be the best fit. During development the app was hosted on Heroku using it’s free tier for one dyno. As always, setup was very easy and all external services, like the database, memcached, Blitz.io and Papertrail were connected in no time.

But there are two “problems” with heroku:

1. I don’t have complete control over the server(s). This is a questionable point since Heroku provides a platform rather than just an infrastructure, so one might argue that not caring about the server(s) is actually a good thing. But I rather have full control over everything.

2. The price. Heroku’s free dyno is awesome, especially for development to get the app up and running very quickly. But once you actually need to scale, it becomes really expensive really fast.

While migrating an existing a Magento shop to Shopify, my client faced me with a task: Implement a list of all vendors, grouped by their first character.

Since Shopify doesn’t give you as much flexibility as Magento or other non-hosted systems do, I had to try around a bit to come up with some working code. It contains several things that Liquid provides, so it might be a good starting point for other problems as well. Here’s what I came up with in a compressed and simplified version:

We all want to tackle our goals. Regardless if it’s a new year’s resolution or just the summer sixpack. But most of our goals aren’t met. There are several reasons for that, but more often than not, it’s because we don’t define our goals. Tracking goals and their progress has also a huge impact.

One way to do this is Trello. Trello is mostly a project management tool, which I use in a number of client projects. But since it’s so easy to set up a new board with an individual layout, it can be used for all sorts of things. Tracking goals is one of them. Here’s a standard layout I use to define my goals and keep track of my progress:

Quick tip: Lately I worked with a bunch of developers who didn’t know about the ?= syntax in Makefiles. Let’s say you have a make deploy target which, by default, deploys to staging. In order to deploy to production you could add another target like make deploy-production or you use the mentioned syntax:

1
2
3
4
5
6

# Makefile

ENV ?= staging

deploy:
    my_deploy_script $(ENV)

So the deployment can be done like this:

1
2

$ make deploy # Deploys to staging since it's the default value
$ ENV=production make deploy # Deploys to production

This is useful in a variety of cases, like tests, generating docs and so on. Maybe you can find a use case for it in your workflow. It’s not a big deal, but can be nifty quite often.

I’m trying to keep this one short but I had to write it down, cause it’s bugging me since a long time:

Meetings are usually the worst thing you can do with your time! And I don’t mean 3 developers sitting around one screen to debug something. I mean those kinds of meetings which are scheduled by project managers and CEOs.

Employees getting pissed and sitting around a table for x hours doesn’t help anyone. The only definitive result is a headache. Meetings can be productive and useful but almost every time there are too many people invited, there’s no clear agenda (or there is and nobody cares), no clear time frame and so on. Watch Jason Fried’s talk on TED and you’ll know what I mean. He’s completely right. But especially project managers and CEOs either don’t know they’re wasting time and money or they don’t care because they think the meeting is “important”. Usually it’s not.

The other day a client of mine faced me with an interesting request: A widget with a WYSIWYG editor. Since we all know those tinyMCE editors from the Magento backend (for instance when changing cms pages) it sounded pretty easy to accomplish. As it turns out, it wasn’t. But here’s how to do it.

Lately I heard “I just don’t have the time” quite often. And it pisses me off. Why? Because most of those people actually have the time but use “no time” as an excuse for not getting things done. You see, if you have the time to watch 2 hours TV every evening, you have the time. If you’re sitting in a bar three times a week, you have the time. If you listening to music while checking Facebook for 30 minutes a day, you have the time. You got the idea.

Take 30 minutes of Facebook from Monday to Friday. That’s 2,5 hours a week or 10 hours a month. 10 hours. More than a whole work day one could spent on Open Source, own projects, family time, learning a language, teaching something, working out and a thousand other things that actually have a value. The value of checking your Facebook timeline 5 times a day: Right…

So I started my own company during the last two months and I wanted to share my experience with you. Besides that I want to compare the founding process in Germany with the one in the US (at least a bit).

If you think about starting a business in Germany, here are the steps for an UG (GmbH is basically the same) to get it done:

During the last two years I came across quite a lot of Magento extensions. I saw good ones, bad ones and ones I don’t want to talk about anymore. Don’t get me wrong - this is not a post about bad developers or something like that. No. I just want to list a few things you should double check the next time you release Magento extensions or create extensions within a shop.

Do not, I repeat, do not introduce core hacks

This might seem like a clear matter, but in fact there are still too many core hacks out there (usually in whole shop projects, not extensions). Even though include hacks are not the same as core hacks, I kinda hate them both. Magento gives you a huge interface to override and extend classes, methods, layouts and templates. Use it.

Consistent style

Again, a completely obvious point, right? Yet, I saw extensions from well known Magento agencies which looked like 5 people who never spoke to each other and don’t like each other worked on it. Of course, sometimes you have to add a quick fix and you might not double check the style. But having camelCase and snake_case methods in the same class just doesn’t look good. Especially since Magento uses the Zend standard, which you should do too. Also commented methods, sometimes more than 100 lines long are a no go. Speaking of 100 lines of code. Try to shrink your methods down to 50 lines tops, rather less than 25. I know, this is pretty hard in PHP and Magento sometimes, but try.

Today I want to introduce you to an effect I call “the HTML whitespace/exclamation mark principle”. A lot of people tend to use two or more exclamation marks in their sentences. So let me explain the mentioned principle:

Assume you write HTML code. If you enter a single whitespace what will your browser render? Right, a single whitespace. Now write a second whitespace, right behind the first one and reload. Aha! Still one. Even if you could write two exclamation marks and the browser would render two, the bottom line is the same: It doesn’t make a difference.

You got the point write? So stop writing two, three or even more exclamation marks in a row. Whoever will read your text will not tread it more serious just because you feel like you need to add more than one to express yourself. Actually sometimes it’s the opposite. In my experience nearly 50% of the people receiving orders from their bosses via text react rather pissed when the order comes with multiple exclamation marks. By the way: I’m one of them ;)

PS: Same goes for question marks and three dots in every sentence.