CAT | The real job
Only a couple of years ago my company decided to build a website platform. A toolbox of features that are used on our many websites in order to reuse rather than to reinvent.
What sounds like a good idea is no longer actively used though..
Actually I started this blog a long time ago only to teach myself test driven development – hence the name. I know all the good reasons why I should’ve written unit tests first.
However I soon discovered that unit testing simply didn’t work out for me.
Impulse a german magazine just did a management buy-out (mbo). The editor in chief bought the whole brand and continues it as his own business. With the brand he acquired the paper magazine, the contents, the website and an app for both Android and iOS.
Changing ownership however is something Apple doesn’t expect to happen.
I was talking to a friend the other day who told me about a scrum team he recently met. He said he was irritated by the amount of rules and rituals they employed. Everything was done by the book.
And it felt wrong.
Fat controllers, you know them: Those bloated controllers which grew up in size drastically during a project lifetime. It is so easy to create them but difficult to get rid of them after a project went live once. Controllers should be kept to a minimum as they should be exchangeable and without any business logic.
In this article I provide 4 simple tips to avoid fat controllers and which are easy to follow.
by Frank Stelzer*
At the Symfony Live Berlin 2012 last week I joined a discussion about handling dependencies in services. One person mentioned that he used to inject the whole dependecy injection container (DIC) to a service in some cases. The service itself requests one or more services from the injected container and use it then for internal stuff.
The service pulls his dependencies here. However dependencies should always be pushed and injected directly in the constructor or with a setter if possible.
by Frank Stelzer*
In one of the projects I’m involved in we have daily status meetings where we update each other on our progress. Every now and then a technical detail is mentioned that can only be described as a workaround. A typical quote on this would be:
Of course this wasn’t originally supposed to be used like this.
I just witnessed this again. A simple response without thinking about really. The idea was out and it came the question of how to realize it and the first response was “we’ll do it like this!”.
Not always what I want to hear..
So why was prototype chosen back then?