Earlier this year I took over that project at my new company. A project, that existed for many years and has been continuously growing. My first impression, it was missing some love recently. The repository was cluttered by many files, that could assumed to be dead code. Unfortunately, you never know. Although I felt the urgent need of removing stuff, I was able to keep myself from blindly deleting files and breaking everything ;). The mission was clear: Cleaning up the project, without breaking things.

Today I wanted to have buttons for some Git features in my PHPStorm toolbar. Unfortunatley it doesn’t have icons for all the essential Git features, which results in empty buttons. Doesn’t look very nice. So I created some icons on my own. Use them if you like.

It was the 13th of November, when I made the descision to leave my current company. I can remember that date, because according to my browser history, it was the day when I’ve choosen the song for my farewell mail (we had the tradition, that everyone who’s leaving links to a song in their last email). Some days passed until I’ve finally realized, that this was the moment, when I’ve switched my mindset from “keep going” to “I’m leaving”. After three tremendous years, I will quit my job as a lead developer and reach out for something new. Propably one of the hardest decisions I had to make.

Since then, I was often thinking about what happened in those years and what I’ve personally lerned from it. So I’m doing this post mostly for myself to recap, but maybe a former colleague or someone else will find it useful. Maybe you’ve made similar experience. So, this is about my lessons learned, as a member of a startup, as a developer, as a team lead. Let’s start with number one.

1. Know Your Limits

Let me tell you a story, a “war story”, that took place in the first months of the company, when everyone had that pioneer spirit. For me it was the most intense time at that company. The time when some individuals, who haven’t worked together before, became a team.

It was early 2012, when we just had licensed our first game and announced it to the press. The date for the closed beta release had already been choosen (for the non-gamers: closed beta is when a game is released to the public, but only for a limited amount of users). The plan was though, but it was possible. Unfortuately we got more and more into trouble, when some of our partners struggled with delays. The game developer needed more time to deliver the server software and we had similar problems with other service providers. We had to wait, until we received something to work with. It was only four weeks to prepare everything for launch – and nothing was ready. No game servers with the game running, no website, no account management. Everything needed to be built within those four weeks.

At that time we’ve been only two people in the tech department. Me, responsible for development, and my colleague, responsible for IT. So we did, what everyone working in tech is doing in such a situation: crunch time. It wasn’t a problem for us. We’ve been full of power, everyone was euphoric about our first release. Usually we started working at 10 a.m. like everyone else. All the other colleagues left at around 7 p.m. and the best part of the day began. No one randomly popping in and asking for stuff, we were able to concentrate on our tasks, at last. It was us two and the CTO sitting together and pushing forward. The atmosphere was nicely startup-ish, we ordered food, had a few beers and when everyone needed a break, we played a session of Minecraft and continued after an hour or so.

Our valley on the Minecraft Server

We’ve usually been exhausted late at night when everyone went home. For the next weeks we continued like this, almost seven days a week. Going to work, working, food, working, food, working, going home, sleeping, going to work… Looking back, I have to admit to myself that it was totally insane. I litterally had no life. Laundry piled up at home, the fridge was empty, but at least I’ve learned a lot about Berlin’s night bus lines.

Picture shot on the way home, 16th of Febrary 2012 at 2:30 a.m.

So why am I telling this? Because at that time I’ve permanently exceeded my personal limit. I was so fueled by the challenge of making it happen, that I didn’t care about myself. And as usual, if you drive above the limit too long, something will go wrong. In my case it was the result of me being totally wasted by the previous weeks, suddenly all that pressure fell off on the launch day and I made a decision I’d have better thought twice.

Although it was kind of harmless, many month later it made me realize, that exceeding your personal limit is a real problem. It may be ok from time to time, but you should make sure not to exceed it for too long. Otherwise you will most certainly harm yourself. A former colleague of mine did not get off that lightly – he got a burnout and needed to start a therapy. That’s certainly an experience nobody want’s to live through.

Today’s working environments make it easy to reach your limit and going further. Therefore it is even more important than ever to be aware of your personal limit and – that’s equally important – you have to be able to realize when you’re exceeding it. I’m not saying you have to avoid it under any circumstances. Sometimes it is necessary to give 120%. But if you see yourself permanently running at 120%, something is wrong and you must not hesitate to change it. I can’t tell you what to do, because it strongly depends on your indiviual situation. For me the solution simply was to keep an eye on myself and to force myself into some spare time away from the workplace, instead of doing extra hours just for fun, when I had no plans for the evening.

Altogether, find a healthy balance between work and leisure time. Oh, that sounds so much generation Y 😉

As the title might tell you, it is about techniques and rules to help you to writing high quality code in such a manner, that it becomes easy to understand and and easy to maintain. The book has a chapter for each aspect of software – naming, formatting, structuring, error handling – to name some of them. After defining a set of dos and don’ts, the following two chapters demonstrate how to apply them by refactoring a piece of software step-by-step.

I consider myself having a pretty good “code sense”, which means that I naturally know, how to structure things and write good code. Therefore most the book wasn’t such a surprise for me, but I discoverd some aspects, that I haven’t thought about before. Instead I just did it. The book helped to understand, why it is a good idea to do certain things, instead of just doing it because it feels right.

Why should you read it: You’re creating software, especially together with other people in a team. You care about the quality of your work and you want to improve your sense for good code.

Recently I was working on a project with FOSUserBundle. It was best choice instead of implementing the whole user system from scratch. Unfortunately, after a while it became clear, that the bundle doesn’t fulfil all of my requirements and therefore I had to make some modifications. I’ve found the solutions not to be totally obvious, so I decided to write it together in this blog post. Another post on FOSUserBundle is my tutorial how to change the password constraints in FOSUserBundle.

Note: This post is about the 1.3 version of FOSUserBundle. Version 2.0 is not stable yet, but it has much better extensibility.

The first thing to do, when extending the bundle, is to create a new bundle, which extends the original FOSUserBundle. This will enable you to overwrite controllers and configuration files with your own implementation. I’ll call it Acme\UserBundle in the following examples.

When working regularly with Sonata bundles, you’ve might come accross their MediaBundle, which integrates a media management module. You certainly recognized that there is something different in the list view: A tabbed navigation to filter media items. This is how it looks like in the current 2.3 branch:

I think this is very useful, because you can filter very quickly – literally with one click – instead of wasting three steps on the datagrid (focus widget, select/type value, click filter button). Unfortunately the tab feature is not documented, so I tried to figure out how it works. Here is a tutorial how you can add filter tabs to your own Sonata Admin modules.

Here are some custom made tasks for Capistrano, which might be helpful in the Symfony2 context. First, some cache clearing tasks, that don’t clear the whole cache but only translations or the Twig template cache.

The folder is accually not removed but renamed to not interfere with current processes. The folder is then automatically rebuilt by the framework.

Symfony2 has that great “assets version” feature, which adds a parameter to the URL of all assets. Then by changing the value, you can make sure that everyone has to load the latest version from the server. If you want to update the asset version automatically on every deploy, you might use the following setup:

Add a file app/config/assets_version.yml to your project containing:

YAML

1

2

parameters:

assets_version: AsSeTvErSiOn

Add that file to the import section of your config.yml and use the parameter %assets_version% in the configuration.

Call that Capistrano task in your deployment process. It replaces the assets version with a value generated from the release name. It is the hexadecimal representation of the YYMMDDHHII timestamp.

Unit testing is great! But sometimes there are situations where it can become really tough to write proper tests for your code. One of these situations is when your code doesn’t work totally predictable, when it has some kind of randomness in it, that is intended. Then you usually have one of those functions in your code:

tempnam(), uniqid()

rand(), mt_rand(), shuffle() or any other randomized function

time(), date(), new \DateTime() or anything that has to do with the current time

The list isn’t complete, just wanted to mention the most common ones. Those functions are bad for testing, because tests have to be repeatable and those ones will most likely produce a different result on every call.

So how to get rid of the randomness and create predictable and therefore repeatable unit test?Read more →

Posts navigation

About me

Hello, my name is Christian Scheb, I'm a developer from Berlin, where I do all kinds of web stuff. Primarly I'm programming in PHP, but I'm open to any kind of programming language or web technology as long as it can do the job. When creating PHP applications I prefer using the Symfony2 framework, which is why most of my blog will be related to it and the so-called "Symfony ecosystem". This blog will be about my experience with new technologies and the lessons learned, so people like you can benefit from it.