Dabei werden auch einige Highlights von Groovy angesprochen wir Groovy-Beans, Categories, Swing-Builder etc. Besonders schön finde ich, dass durch das Beispiel sehr deutlich wird, wo in Praxis der Nutzen dieser Features liegt.
Post bewerten
Freitag, Februar 23, 2007
Groovy: Wie aus Skripten Programme werden
Mein Kollege Bernd Schiffer hat in seinem Blog einen sehr schönen Eintrag zu Groovy geschrieben. Anhand eines einfachen Problems zeigt Bernd, wie man sich Groovy zuerst eine Skripting-Lösung baut und die dann schrittweise zu einer echten Anwendung wird.
Dabei werden auch einige Highlights von Groovy angesprochen wir Groovy-Beans, Categories, Swing-Builder etc. Besonders schön finde ich, dass durch das Beispiel sehr deutlich wird, wo in Praxis der Nutzen dieser Features liegt.
Dabei werden auch einige Highlights von Groovy angesprochen wir Groovy-Beans, Categories, Swing-Builder etc. Besonders schön finde ich, dass durch das Beispiel sehr deutlich wird, wo in Praxis der Nutzen dieser Features liegt.
Mittwoch, Februar 21, 2007
Lieber bewährt als Leading-Edge
Stanford-Professors Robert Sutton sagt: „In dem ganzen Jubel um neue Produkte und neu gegründete Unternehmen vergisst man leicht, dass die meisten neuen Ideen schlecht sind und die meisten alten Ideen gut."
Diesen Ausspruch finde ich wirklich super. Insbesondere in der IT sind wir allzu schnell dabei, jedem Hype und jeder neuen Technologie hinterher zu rennen. Meine persönliche Schlüsselerfahrung dazu ist: Das uralte Cobol-System, an dem ich als Student gearbeitet habe, war deutlich besser strukturiert als die meisten C++- und Java-Systeme, die mir in den 12 Jahren danach über den Weg gelaufen sind.
Diesen Ausspruch finde ich wirklich super. Insbesondere in der IT sind wir allzu schnell dabei, jedem Hype und jeder neuen Technologie hinterher zu rennen. Meine persönliche Schlüsselerfahrung dazu ist: Das uralte Cobol-System, an dem ich als Student gearbeitet habe, war deutlich besser strukturiert als die meisten C++- und Java-Systeme, die mir in den 12 Jahren danach über den Weg gelaufen sind.
Post bewerten
Sonntag, Februar 18, 2007
Quasar: gute Sache
Quasar ist ein Architekturkonzept für die Strukturierung von Softwaresystemen in Komponenten. Das Ding gibt es schon sehr lange. Da es von sd&m kommt, hatte ich mich aber lange Zeit um das Thema herumgedrückt. Dann habe ich mich doch rangewagt und inzwischen haben wir auch erste Projekterfahrungen, die ganz klar sagen: Quasar ist eine sehr nützliche Geschichte. Es ist einfach zu vermitteln und zu erlernen und befördert das Nachdenken über eine saubere Strukturierung des Systems in Komponenten. Die Projektbeteiligten waren bei der Retrospektive zum Thema "Quasar" einhellig der Meinung, dass es sehr positive Effekte gehabt hätte.
Quasar funktioniert damit auch, wenn man agil vorgeht und inkrementellen Entwurf praktiziert - was eher nicht im Sinne der Quasar-Macher war :-)
Ein gutes Buch zum Thema ist "Moderne Software-Architektur. Umsichtig planen, robust bauen mit Quasar." von Johannes Siedersleben.
Quasar funktioniert damit auch, wenn man agil vorgeht und inkrementellen Entwurf praktiziert - was eher nicht im Sinne der Quasar-Macher war :-)
Ein gutes Buch zum Thema ist "Moderne Software-Architektur. Umsichtig planen, robust bauen mit Quasar." von Johannes Siedersleben.
Post bewerten
REST für Geschäftsanwendungen
Der REST-Architekturstil funktioniert offensichtlich sehr gut für das Internet. Eine Einführung in REST findet sich z.B. hier.
Eine interessante Frage ist jetzt natürlich, ob REST genausogut für nichttriviale Geschäftsanwendungen funktioniert. Dazu ist im Internet bisher nicht allzu viel zu finden.
Hier gibt es immerhin ein Gedankenexperiment mit klarem Ausgang dazu.
Wenn irgendjemand selbst Erfahrungen mit REST für Geschäftsanwendungen hat oder Referenzen kennt, würde ich mich über Rückmeldungen dazu freuen.
Eine interessante Frage ist jetzt natürlich, ob REST genausogut für nichttriviale Geschäftsanwendungen funktioniert. Dazu ist im Internet bisher nicht allzu viel zu finden.
Hier gibt es immerhin ein Gedankenexperiment mit klarem Ausgang dazu.
Wenn irgendjemand selbst Erfahrungen mit REST für Geschäftsanwendungen hat oder Referenzen kennt, würde ich mich über Rückmeldungen dazu freuen.
Post bewerten
Samstag, Februar 17, 2007
Die Wahrheit über SOA...
...findet sich hier: http://www.soafacts.com/
Am schönsten finde ich: "SOA is not complex. You are just dumb."
Und außerdem ist die Aussage so schön universell. Die funktioniert auch für EJB, verteilte Transaktionen, Web-Services (WS-*) etc.
Am schönsten finde ich: "SOA is not complex. You are just dumb."
Und außerdem ist die Aussage so schön universell. Die funktioniert auch für EJB, verteilte Transaktionen, Web-Services (WS-*) etc.
Post bewerten
Mittwoch, Februar 14, 2007
Die agile Chance
Wir veranstalten am 20.02.07 um 14 Uhr einen Vortragsblock in Hamburg mit dem Thema "Die agile Chance". Dort geht es um die Frage, welche Vorteile die agile Softwareentwicklung für den Auftraggeber hat.
Neben drei Vorträgen zum Thema gibt es Raum für Diskussionen zum Thema. Mehr Informationen gibt es hier.
Neben drei Vorträgen zum Thema gibt es Raum für Diskussionen zum Thema. Mehr Informationen gibt es hier.
Post bewerten
Freitag, Februar 09, 2007
Behindern Unittests inkrementellen Entwurf?
Vor kurzem bekam ich per E-Mail eine Anfrage zum Thema testen. Die lautete inhaltlich sinngemäß:
"Wenn ich mich bei Unittests sehr stark am Softwaredesign orientiere, was nach meinem Verständnis die klassischen xUnit-Tests machen, dann habe ich das Problem bei Strukturänderungen den Test nachziehen zu müssen.
Wenn ich mich im Unittest an der übergeordneten Funktion orientiere, bekomme ich Schwierigkeiten mit der geforderten Testüberdeckung.
Die XP-Welt propagiert gleichzeitig den Einsatz von Unit-Tests und einer laufenden Weiterentwicklung im Design. Wie passt das zusammen?"
Diese Frage fand ich so interessant, dass ich meine Gedanken dazu mal in einem Whitepaper zusammengeschrieben habe.
"Wenn ich mich bei Unittests sehr stark am Softwaredesign orientiere, was nach meinem Verständnis die klassischen xUnit-Tests machen, dann habe ich das Problem bei Strukturänderungen den Test nachziehen zu müssen.
Wenn ich mich im Unittest an der übergeordneten Funktion orientiere, bekomme ich Schwierigkeiten mit der geforderten Testüberdeckung.
Die XP-Welt propagiert gleichzeitig den Einsatz von Unit-Tests und einer laufenden Weiterentwicklung im Design. Wie passt das zusammen?"
Diese Frage fand ich so interessant, dass ich meine Gedanken dazu mal in einem Whitepaper zusammengeschrieben habe.
Post bewerten
Dienstag, Februar 06, 2007
Training zu Feature-Driven-Development in Hamburg
Die akquinet veranstaltet über ihre Beratungsmarke it-agile im Mai ein FDD-Training mit Jeff DeLuca. Das finde ich sehr interessant, weil
- Feature-Driven-Development eine ganz andere Perspektive einnimmt als die anderen agilen Methoden wie XP oder Scrum.
- Trainings zu FDD in Deutschland eine echte Rarität sind.
- Jeff FDD (mit)erfunden hat.
Post bewerten
Samstag, Februar 03, 2007
Lean Fast Food
Ich bin viel auf Reisen unterwegs und gehe abends zum Essen der Einfachheit halber häufig in Fast-Food-Läden. Dabei trifft man auf zwei prinzipiell unterschiedliche Bedienungskonzepte:
Seit einigen Jahren gibt es eine Verbesserung bei Kategorie 2: Man muss nicht mehr lange warten. Ein typischer Vertreter ist Subway. Während McDonalds und Konsorten mehrere Kassen nebeneinander am Tresen haben, schleust Subway die Kunden in einer Schlange am Tresen vorbei. Das Subway-Prinzip läuft darauf hinaus, dass man sein Sandwich während des ganzen Entstehungsprozesses begleitet und mit ihm der Kasse immer näher kommt. Dieses Vorgehen hat zwei positive Effekte:
Die Produktionsweise bei McDonalds könnte man als klassisch bezeichnen, die von Subway als Lean. Und man kann eine wichtige Konsequenz für die Kunden agiler (lean) Softwareentwicklung ableiten: Man muss sich den ganzen Entwicklungsprozess über engagieren. Dadurch hat man mehr Einflussmöglichkeiten, muss sich aber eben auch einbringen.
- Produktion des Essens auf Vorrat (Push-Prinzip).
- Produktion des Essens bei Bedarf (Pull-Prinzip).
Seit einigen Jahren gibt es eine Verbesserung bei Kategorie 2: Man muss nicht mehr lange warten. Ein typischer Vertreter ist Subway. Während McDonalds und Konsorten mehrere Kassen nebeneinander am Tresen haben, schleust Subway die Kunden in einer Schlange am Tresen vorbei. Das Subway-Prinzip läuft darauf hinaus, dass man sein Sandwich während des ganzen Entstehungsprozesses begleitet und mit ihm der Kasse immer näher kommt. Dieses Vorgehen hat zwei positive Effekte:
- Man kann mehrfach zwischendurch noch Einfluss nehmen auf sein Sandwich (z.B. welches Brot, welche Salatanteile, welche Soße).
- Man kommt sehr schnell dran und ist dann beschäftigt. Möglicherweise wartet man länger auf sein Essen als bei McDonalds. Es fühlt sich aber kürzer an.
Die Produktionsweise bei McDonalds könnte man als klassisch bezeichnen, die von Subway als Lean. Und man kann eine wichtige Konsequenz für die Kunden agiler (lean) Softwareentwicklung ableiten: Man muss sich den ganzen Entwicklungsprozess über engagieren. Dadurch hat man mehr Einflussmöglichkeiten, muss sich aber eben auch einbringen.
Post bewerten
Abonnieren
Posts (Atom)
Atom.xml