However, I often have a hard time to convince other developers about those advantages. I guess testing is the easiest one, because no developer would dare to argue against testing, even though many developers don’t do it or don’t do it right. Questions and discussions about testing seem to be very rare. Developers just discuss it with their non-technical managers, if they want to get around that “effort”.

But it already starts with OpenAjax. I rarely find a developer that knows what it is and what it is good for and why you might need an event hub in JS at all. Zend, W3C, IBM and Google are some of the more well-known members of the OpenAjax Alliance. If you hear about it the first time now, take the time to have a look.

Just yesterday I was talking to an obviously experienced JS dev (who was working for a well known mobile phone company), that was browsing through the JavaScriptMVC documentation and stopped in the chapter about EJS templates: “Yeah, I saw something similar in our own project and removed it. It is confusing, if the JS code and the HTML are in separate files, because you don’t see the code together in one file. HTML should only be edited by developers who know the JS code very well”. Not sure what to say about that. Why not give up separation of concerns at all and put everything in one big file? Then you see the big picture on your hopefully big screen. Also you always need to check the full version control system diff after each change because the file name alone doesn’t tell you what was changed and you probably have more of those exciting conflicts to resolve. And: You REALLY need to be an expert to understand what is going on. The company can never fire you, because no one else would ever understand that kind of code. Sorry for being sarcastic, but that kind of attitude can seriously damage the health of innocent other people who need to clean up the mess in 20h work days afterwards, to meet the deadline of the project. Or the project is so small that it doesn’t matter. Or the company you work for can afford to pay a lot of developers who have the time to maintain a JS app without templates.

Convincing people about the usefulness of controllers is not easy too. Either you start showing an OpenAjax subscribe action – then the developer most likely won’t understand what that is good for (see above). Or you talk about event delegation, then the developer will point to jQuery’s live() method, which does event delegation too. In fact, JavaScriptMVC’s event delegation used to be one of the strong points and I admit that I am not totally up to date with the whole discussion right now, because I was busy with a PHP project during the last 6 months. I know Justin Meyer is/was working on the controller code so that it makes more use of jQuery, he contributes code to jQuery and he is in contact with John Resig. Anyways, the whole point about controllers again is separation of concerns and not so much the technical details behind the scenes. The JavaScript world is moving very fast and implementation details change a lot, but separation of concerns is not really something that you can look at as something you probably don’t need. The JS world sometimes feels like the PHP world about 10 years ago.

Ok, after getting rid of those thoughts, I will return to work now. The next 2 weeks will be quite relaxed with very little work. So maybe, I can read through the new JavaScriptMVC code and update my knowledge. It really feels uncomfortable not the be able to answer questions in detail. Also I start confusing PHP and JS syntax *lol*

See also: http://jupiterjs.com/news/talkin-javascriptmvc-is-hard

Nett fand ich mal wieder Sebastian Bergmanns Vorstellungen zu testbarer Software zu hören. Im Wesentlichen basierte seine Argumentation in letzter Konsequenz auch auf „man will ja dieses und darum muss man jenes so und so machen“. Finde ich nicht falsch und für mich gut verständlich. Nur: Wenn man das so einem normalen Entwickler erzählt, schaut dieser nur befremdlich und sagt dann, dass es anders doch auch geht und viel einfacher ist.

In der Praxis ist es so, dass man schon vor einer großen Herausforderung steht, wenn man Entwickler nur dazu bringen muss, nicht allen Code in eine Klasse zu schreiben. Von „Separation of Concerns“ haben gefühlte 30% der Entwickler schon was gehört. In Büchern wie „PHP Quick and Dirty“ wird es als tolle Idee angesehen, einen PHP-Interpreter herauszubringen der deutsche Keywords versteht, weil man Entwicklern nicht zumuten kann, Englisch zu lernen oder ein Wörterbuch zu verwenden. Alles Zeitverschwendung. In einem anderen Buch zu objektorientiertem PHP wird auf endlosen Seiten auf die Implementierung des Countable-Interfaces aus der SPL eingegangen um dann zum Fazit zu kommen: „Ohne Countable geht es nicht“. Damn, ich habe das in den letzten 10 Jahren nicht gebraucht.

Wenn man auf so ein BarCamp geht, entsteht der Eindruck, alle Anwesenden würden fast immer das richtige Design Pattern verwenden und streng nach Test-Driven-Development (TDD) und Extreme-Programming (XP) Grundsätzen arbeiten. Dass das nicht so ist, ist anzunehmen, zumindest hinterlässt meine berufliche Praxis ein schmerzhaft anderes Bild. Insbesondere problematisch finde ich solche in den Raum gestellten Statements, wenn der Source-Code (wie bei fast allen Web Anwendungen) nicht einsehbar ist. Lieber wird an Open-Source Projekten wie Zend Framework und Magento kleinteilig herumkritisiert. Bei Magento gibt es keine Tests, im Source sind dumme Fehler zu finden, langsam ist es eh und die meisten Zend Framework Klassen seien auch nur schnell zusammengehackt worden. Leider sind die meisten Closed-Source Anwendungen noch sehr viel schlimmer!

Um diesem Problem zu begegnen wird von verschiedener Seite „Scrum“ als Lösung propagiert. Insbesondere wird in dem Zusammenhang die niedrige Fehlerrate und der hohe Grad an Selbstorganisation, die durch Vertrauen und Eitelkeit ermöglicht wird, hochgehalten. Im Nebensatz werden dann noch schnell XP und TDD erwähnt, und schnell ist klar, dass es sich hier um ein Rezept für erfolgreiche Projekte handelt.

Zunächst einmal sollte man TDD, XP und das eigentliche Scrum-Projekt-Management auseinander halten. Das Tests die Qualität erhöhen, hat zunächst nichts mit agilem Projekt-Management zu tun. Häufig wird das in einen Topf geworfen, und dann heißt es pauschal, Scrum würde die Qualität erhöhen. Agiles Projekt-Management soll flexibel auf geänderte Anforderungen reagieren und daher in kurzen Iterationen arbeiten. Dabei sind Tests nicht nur hilfreich, sondern wegen der laufenden Refactorings dringend notwendig – deswegen wird beides zu Recht zusammen genannt. Nur Vertrauen alleine schafft noch lange keine guten Tests, selbst wenn ein Team tatsächlich schafft welche zu schreiben, was IMO auch eine Seltenheit ist. Ich kenne es auch so herum, dass die Entwickler vor lauter Eitelkeit in Panik verfallen und gezielt schlampig arbeiten, um am Iterationsende ein Stück schlechten Code mit schlechten Tests vorweisen zu können. Traut sich dann wirklich immer jemand die Wahrheit auszusprechen, die Arbeit von ein oder zwei Wochen zu verwerfen und neu anzufangen? Eventuell sogar den Mitarbeiter zu kündigen, obwohl seine Familie das Geld dringend benötigt, weil gerade Nachwuchs gekommen ist? Das ist doch so realistisch wie die freie Marktwirtschaft.

Formale Methoden verfolgen das gleiche Ziel der Fehlerfreiheit, werden jedoch oft gar nicht erwähnt oder auch nur in Erwägung gezogen. Weiter sollte es klar sein, dass es Entwickler gibt, die sich selbst organisieren können und andere, die mehr Unterstützung benötigen und nicht die Erfahrung haben um an allem arbeiten zu können. Man hat oft kein Team, das nur aus Senior Entwicklern besteht und selbst diese unterscheiden sich untereinander. Am Ende des Tages kommt es einzig und allein auf die Kompetenz der Projekt-Beteiligten auf allen Ebenen an und nicht so sehr darauf, welche trendige Management-Methode man angewendet hat. Siehe dazu auch Cargo Cult Software Engineering. Statt das anzuerkennen, wird gegenüber Scrum-Kritikern polemisch das Bild vom autoritären Chef gezeichnet, der boshaft Befehle verteilt, so dass dann natürlich nur die offensichtlich bessere Option der magischen Selbst-Organisation bleibt. Von eiserner Disziplin will niemand gerne reden, das wäre am Ende ja noch anstrengend und würde mit alternativen oder hybriden Ansätzen, die nicht der reinen Scrum-Lehre entsprechen, möglicherweise genauso gut funktionieren.

„Most teams purporting to be doing agile software development are not applying the level of technical rigor necessary to succeed at it. Most “agile” teams have actually only adopted Scrum’s project-management practices and have failed to effectively adopt “the hard disciplines” like test-driven development, refactoring, pair programming, simple design, and continuous integration.” Jean-Raymond Abrial, Faultless systems: Yes we can!, IEEE Computer 9/2009

Niemand ist ein Gegner von Vertrauen, Selbstorganisation, Selbstmotivation und Agilität. Soweit ich sehe funktioniert agiles Vorgehen gut in kleinen Teams mit sehr erfahrenen Entwicklern oder wenn die grundsätzliche Architektur zentral vorgegeben ist und nur noch konkrete Details von den einzelnen Entwicklern mit Hilfe eines bereits fertigen Frameworks implementiert werden. Zudem muss man gnadenlos konsequent sein, was je nach Team viel Kraft und Zeit kosten kann bis alles rund läuft. Was nicht geht, ist sich vorne hin zu stellen und zu erzählen, wie toll und einfach alles ist (“klar gibt es hin und wieder Probleme, aber dann redet man halt”). Diejenigen bei denen es wie zu erwarten nicht gut ausgeht, haben es dann einfach falsch gemacht. Solche Totschlag-Argumente erinnern einen an religiöse Gemeinschaften.

Microsoft hat in Unterschleißheim ein “Open Source Interop Technology Center” eröffnet. Microsoft will hier an der besseren Unterstützung verschiedener Open-Source-Software unter Windows arbeiten. Den Anfang macht PHP.

http://www.golem.de/0810/63176.html

• Add something like PHP_CodeSniffer to pre-commit in Subversion to reject code that doesn’t follow standards
• Run tests in a Subversion post-commit script
• Try to switch to git, because you can also do commits when offline

Sadly, there were also less good ideas like

• Prefix private/protected class methods and properties with an underscore (makes refactoring very difficult; instead you should start with all properties being protected anyway and only make properties public, that need to be public)
• Limit line length to 85 chars (120 chars are ok – nobody uses a 80 char text console for coding anymore – wide screens are standard, even for developers)
• Use PHP_CodeSniffer (I like ZendCodeAnalyzer)

Look at this, if you wanna see bad practices:

http://talks.php.net/show/froscon08

Yes, PHP frameworks do suck in terms of performance. CakePHP is the slowest while Zend Framework seems to be the most complex, in terms of include dependencies.

• Yahoo! Inc.
• Ciao.com
• Facebook

The next logical step is, that Microsoft runs PHP applications and employs a lot of PHP developers. I really don’t think, they will port all those apps to their own technologies like .net, C# or Visual Basic. So, be prepared. You will soon be able to start a career at Microsoft as PHP developer.

Reading 3274 messages…

Fatal error: Out of memory (allocated 11534336) (tried to allocate 18446744073709551615 bytes) in /usr/share/php/libzend-framework-php/Zend/Mail/Storage/Mbox.php on line 198

That’s around 17179869183 TB of memory… to read 3274 mails… makes 5247363 TB per message… not bad