One of the many things I really like about doctrine is the data type Array. On the database level it is a serialized string representation of a plain PHP array while on the record level it is PHP array.

You can use it to store more complex data with a changing structure per record. But how do you maintain this in a symfony form?

(more…)

Doctrine · DRY · gjPositionsPlugin · symfony

I keep propagating separation of concerns, modularity and decoupling and from all the discussions I had and all the books and blog posts I’ve read I haven’t discovered but one single reason against this.

The reason is simple and powerful: performance.

Performance they will suffer if you keep your components abstract and independent. The more you couple the more you can optimise the speed of execution.

This is in most cases actually true. On the long scale however..

(more…)

architecture · DRY · perf · Refactoring · Separation of Concerns · symfony

Yesterday I wrote about two approaches on code reusability clearly favouring modularity as a solution.

Today I want to give a brief overview on the possible ways how to achieve this within symfony/doctrine (1.4/1.2) projects.

(more…)

architecture · Behaviours · Doctrine · DRY · Events · Modularity · Open Source · PHP · plugins · Separation of Concerns · symfony · YAGNI

So you’re thinking of reusing your code, huh? This can be quite tricky. Reusing software is considered by many to be one of the great myths of software engineering. Still I am convinced that it is possible.

However there are several approaches to this but not all of them have a good chance to succeed.

(more…)

architecture · DRY · Modularity · Project management · Refactoring · Reusability · Separation of Concerns · YAGNI

Last week I spend in Madrid helping colleagues of mine with their project. One of the things they needed to develop was a means to store information about user logins that stores time and date and also the IP address of the user. Of course this was just a very small feature from the list and surely not business critical. I gave this some thought and with a little help of the symfony community I was able to find a simple yet elegant solution to this.

Then I released this feature as Open Source and I expect this decision to pay off in terms of quality. Now why is that?

(more…)

Code Quality · DRY · KISS · Open Source · Separation of Concerns · YAGNI

Als ich vor ein paar Tagen mich und meine Arbeit auf den roten Clean Code Developer Grad geprüft habe, habe ich auch das erste mal mit dem Copy & Paste Detection Tool phpcpd zu tun gehabt und habe es kurz darauf als Leitmass für ein kleines Refactoring genutzt.

Mittlerweile habe ich dieses Tool auch in meinen Continuous Integration Prozess aufgenommen und kann die Ergebnisse mit jedem Build im Auge behalten. Deswegen möchte ich kurz zeigen, wie ich phpcpd und Hudson in Einklang gebracht habe.

(more…)

CCD · Clean Code Developer · Continuous Integration · DRY · Duplicated Code · Hudson · phpcpd

Gestern habe ich mich mal an den roten CCD Grad gemacht und mich und meinen Code auf die dort angegebenen Prinzipien überprüft.

Eines der Prinzipien des roten Grades ist DRY und ich habe mal mit dem PHP Copy Paste Detector phpcpd nachgeschaut, wie viel Doppelungen ich denn so fabriziert habe.

Ich habe mittlerweile das erste Refactoring bereits hinter mir und bin sehr zufrieden, aber auch die restlichen Todos in diesem Zusammenhang sehen vielversprechend aus.

(more…)

CCD · Clean Code Developer · DRY · Refactoring · sfImageTransformExtraPlugin · Tests · Unit Tests

Wie ich gestern angekündigt habe, werde ich damit beginnen mein sfImageTransformExtraPlugin anhand der Clean Code Developer Grade zu überprüfen angefangen mit dem roten.

Implizit überprüfe ich mich damit natürlich selbst.

Die gute Nachricht ist, dass ich alleine mit dem Interesse bereits den schwarzen Grad erreicht habe. Die eigentlich Arbeit beginnt aber mit dem roten Grad. Dann mal los!

(more…)

CCD · Clean Code Developer · DRY · FCoI · KISS · Pfadfinderregel · phpcpd · Refactoring · Refektion · Root Cause Analysis · Sebastian Bergmann · sfImageTransformExtraPlugin

Code muss KISS, DRY und YAGNI sein, das haben wir alle merh als nur einmal gehört und mehr als einmal versucht zu befolgen.

Das ist auch gut so, denn schliesslich sind diese Programmier Paradigmen nicht aus der Luft gegriffen. Aber reicht das Befolgen dieser Regeln auch schon, um zukunftsfähigen, wartbaren und hoch-qualitativen Code zu produzieren?

(more…)

architecture · DRY · KISS · Paradigmen · Separation of Concerns · YAGNI