miradlo bloggt

Barcamp Bodensee - Web-Konferenz im Mai 2008 in Friedrichshafen

24. April 2008 ute

Beim Barcamp Bodensee gibt es vor allem für Studierende und Teilnehmer aus anderen Ländern als Deutschland noch Plätze. Anmelden kann man sich im Wiki des Barcamps. Das Barcamp findet vom 31. Mai bis 1. Juni 2008 in Friedrichshafen statt. Für Studenten insbesondere aus der Region bietet das Barcamp eine tolle Möglichkeit sich in lockerer Atmosphäre weiterzubilden.

Aus unserer Sicht kann es kaum ein näher gelegenes Barcamp geben, daher freuen wir, Roland und ich uns darauf erstmals teilzunehmen. Aus den Anregungen, welche Themen interessant wären, hat Roland sich entschlossen die Anregung “Softwarentwicklung in verteilten Teams - Tools, Vorgehensweisen” aufzugreifen und dieses Thema anzubieten. Wenn es so interessant wird, wie es klingt, dann wird es sicherlich nicht das letzte Barcamp, an dem jemand von miradlo teilnimmt.

Ausschnitt aus der offiziellen Ankündigung

Wie sehen Konferenzen von Leuten aus, für die Weblogs und Wikis - wie Wikipedia - Alltag sind? Sie heißen „Barcamps“, und ihr Programm wird von den Teilnehmern komplett selbst bestimmt und getragen. Ein solches Barcamp wird von 31. Mai bis 1. Juni 2008 in Friedrichshafen stattfinden. Gastgeber ist die Zeppelin Universität (ZU). Gerechnet wird mit bis zu zweihundert Teilnehmenden.

„Friedrichshafen ist ein idealer Standort für ein Barcamp”, betont der ehrenamtliche Organisator Oliver Gassner, der im Hauptberuf Kommunikationsberater ist, „ein Universitätsstandort mit Flughafen, kurzen Wegen zum deutschsprachigen Ausland und mitten in einer Technologieregion”. Die Veranstalter hoffen vor allem auf internationales Publikum und auf Zustrom aus den Schulen und Hochschulen des Umlandes und der Anrainerstaaten. (…) Ein Eintritt übrigens fällt bei Barcamps nicht an. (…)

Die Barcamp-Idee entstand vor zweieinhalb Jahren in den USA. Weitere Informationen zum Barcamp Bodensee unter http://barcampbodensee.mixxt.eu

Episode 6: Grenzen des Refactorings ::: Softwareprojekte

22. April 2008 roland

Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. …wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend.
Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

Orlando war mal wieder auf einer Schulung

Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben.
Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren.

Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben.
Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden…
Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

Keine Architektur?

Karl schaute sich die bisherigen Architekturkonzepte an.
„Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“
Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen.
„Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando.
Hans nickte zustimmend.
„Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“
Orlando überlegte:
„Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“

Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften.
Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen!
Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt…

Wörter und Zeichen eines Beitrags zählen : TinyMCE in Wordpress anpassen

17. April 2008 ute

Mal möchte man Beiträge nur veröffentlichen, wenn sie eine Mindestanzahl an Wörtern haben, z.B. bei trigami-Rezensionen, oder man will einen Beitrag in mehrere aufteilen, sobald eine bestimmte Anzahl an Wörtern überschritten wird. Wer daher ab und zu mal Wörter oder Zeichen eines Beitrags zählen möchte, kann sich natürlich einfach den Text in ein Textverarbeitungsprogramm oder einen Editor auf dem Rechner kopieren, die diese Funktion haben. Sei es der OpenOffice.org Writer oder ein Editor wie KWrite, alternativ Microsoft Word oder ähnliches, dort gibt es diese Funktion bereits. Will man diesen Umweg vermeiden, dann lässt TinyMCE, der in Wordpress integrierte WYSIWYG-Editor ebenfalls anpassen.

Anleitung Wörter zählen im Wordpress-Editor

Um innerhalb von Wordpress Wörter zählen zu lassen, gibt es ein Plugin. Für den genutzten Editor TinyMCE gibt es das Plugin “charcount“. Damit lassen sich die Wörter eines Artikels zählen. Angezeigt werden: die Anzahl an Wörtern und die Anzahl an Zeichen, sowohl mit, als auch ohne Whitespaces (Whitespaces sind alle Leerzeichen, Absätze usw.) Das Ganze klappte bei mir wie folgt:

Das Plugin charcount runterladen
entpacken
ins Verzeichnis /wp-includes/js/tinymce/plugins/ kopieren
die Datei /wp-includes/js/tinymce/tiny_mce_config.php an zwei Stellen anpassen:
- dem Array plugins charcount hinzufügen: $plugins = array(’charcount’);
- dem Array mce_buttons charcount hinzufügen: $mce_buttons = apply_filters(’mce_buttons’, array(’bold’, ‘italic’, ‘charcount’,));
alles hochladen
den Editor eventuell mit STRG und neu laden, aktualisieren
der neue Button “123 ABC” wird angezeigt.
Dieser Beitrag hat dann:
- Wörter: 224
- Zeichen ohne Leerzeichen: 1570
- Zeichen mit Leerzeichen: 1803

Getestet in Wordpress 2.3, viel Spaß und Erfolg damit.

Softwareprojekte Episode 5 ::: Coderefacturing und Lavacode Beseitigung

15. April 2008 roland

Begonnen habe ich mit der Vorgeschichte und den Episode 1, 2, 3 und 4 in diesem Teil geht es um Coderefacturing

In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folgende Dateien:

TestDummyModel Eine Unit-Testklasse mit der das DummyModel auf Funktion überprüft wurde.
BaseUIElement Der Observer mit dem das Subjekt überwacht werden soll.
TestBaseUIElement Ratet mal Ist wohl eine Testklasse.
BaseModel Beinhaltet die Basis-Modell Information und schlussendlich die echte Subjekt-Methode.

Um das BaseModel testen zu können, wurde ein TestBaseModel eingeführt. Das DummyModell wurde nur dazu benötigt um die protected-Methoden der BaseModelklasse testen zu können.

Der Aufwand, um DummyModel und TestDummyModel entwickeln zu können, betrug in etwa einen Arbeitstag. Jetzt kommt aber der Hammer: Die Wartung von DummyModel und TestDummyModel kostete zwei Stunden. Im zweiten Jahr wuchsen die Wartungsaufwände auf zwei Tage an. Das bedeutet, dass die Wartung mehr kostete als die ursprüngliche Herstellung.

Wie konnte das passieren? DummyModel wurde nicht nur für den Test von BaseModel verwendet, sondern wurde in vielen anderen Testszenarien als einfache Lösung angesehen, die protected-Methoden von BaseModel zu verwenden.

Eine Änderung am DummyModel verursachte nun enorme Kosten bei den Testklassen.

Was kann man da besser machen?

Ok, zuerst kann man mal über ein sauberes Konzept und „wir programmieren nur gegen Schnittstellen“ und all die schönen Regeln beherzigen. Manchmal sieht man aber den Klassenwald vor lauter Methoden nicht mehr. Lavacode entsteht, niemand kann ihn 100% verhindern. Wenn aber so ein Problem erkannt wurde, muss man handeln.

Orlando griff in die Tasten und entfernte das DummyModel. Das Testen der protected-Methoden löste er durch eine Wrapperklasse im TestBaseUIModel und die Testklassen wurden so umgebaut, dass sie sich wieder an Schnittstellen halten und keine Wartungsexplosion zu erwarten ist.

Karl hatte an einem nebligen Freitag ein Problem beim Review. „Jungs schaut mal her: Diese Methode hier verursacht das Problem, dass wir an zwanzig Stellen im Programm Abhängigkeiten schaffen. Das ganze ist nicht modular sondern vernetzt. Wenn ich das jetzt aber ändern soll werde ich nicht fertig und außerdem müssen wir das extrem gut testen. Was sollen wir machen?“

Termine drücken im Familiengeschäft immer. Wenn die drei den nächsten Release vergeigen ist mindestens einer der Drei bei Fred. Dementsprechend sind Klaus, Orlando und Hans etwas vorsichtig beim kompletten Umstellen der Systemkomponenten. Hans schaute sich das Problem an: „Also gut, wir schaffen das jetzt nicht. Geh doch durch alle dir bisher bekannten Komponenten durch und schreibe ein TODO hinein. Wir analysieren das Thema über die nächsten Wochen und falls wir dann glauben, dass wir es schaffen können, putzen wir den Code.“ Diese Idee beruhigte die Nerven der drei gestressten Entwickler doch sehr. Vier Review-Zyklen später war das Problem vollständig analysiert und sie konnten ohne Familienteich die Abhängigkeiten auflösen.

Wenn beim Codereview festgestellt wird, dass ein größerer Aufwand vorhanden ist, muß dies vermerkt werden. Der Projektleiter muss eine Issue-Liste führen und neue Anforderungen und Probleme dort hinterlegen. Es werden immer Problemstellungen vorhanden sein, die nicht sofort gelöst werden können. Die schlechteste Alternative ist diese einfach zu verdrängen. Wenn im Sourcecode dokumentiert ist, dass noch Nacharbeiten notwendig sind und Zeit und Aufwand für diese Nacharbeiten im Projekt budgetiert worden sind, stellen diese notwendigen Korrekturen kein Problem dar.

Abendwolken : geändertes Design auf miradlo bloggt

13. April 2008 ute

Am 12. April war bei uns unser Tag der Ofentür dafür gab es einige Tage das dazu passende Design. Inzwischen ist dieser Aktionstag abgeschlossen, mehr dazu in einem eigenen Beitrag in den nächsten Tagen.

miradlo Tag der Ofentür

Wie gewohnt also wieder einmal ein Designwechsel, dieses Mal halt ein bisschen schneller als gewohnt. Da das Ofentür-Design sehr ablenkend ist, wollte ich es nicht zu lange online lassen.

Informatiküberraschung gewinnen am Samstag bei miradlo in Konstanz

11. April 2008 ute

Unser Tag der Ofentür findet von 9 bis 17 Uhr statt. Mehr zum Programm auf www.miradlo.com.

Unser Gewinnspiel ist bereits online, teilnehmen kann man jedoch ausschließlich:

morgen, Samstag von 9 bis 16³⁰ Uhr

Mitmachen kann man beim persönlichen Besuch unseres Aktionstags, aber auch online, können alle Interessenten mitspielen.

Gewinnspielteilnahme

Die Teilnahme am Gewinnspiel auf www.miradlo.de ist online und persönlich möglich am Samstag, den 12. April von 9 bis 16³⁰ Uhr. Zu gewinnen gibts eine Informatiküberraschung… Genaueres wird nicht verraten, außer:

Es lohnt sich und viel Glück!

Diskussionen zu Microsoft und dem IE8 : III.

10. April 2008 ute

Diese Serie startete mit I. den guten Nachrichten von Microsoft, dem folgte das II. der Webtrend: standardkonformere Seiten, dieses ist das III. der letzte Teil der Serie über die Diskusssionen unter Webentwicklern und die Bedenken zur Standardkonformität des IE8.

Ich finde es schade, dass es Diskussionen gibt, die sich an diejenigen richten, die an den Gesprächen mit Microsoft beteiligt waren. Jens Grochtdreis schreibt z.B. in Microsoft hört zu unter anderem:“Gustafson, Eric Meyer, Zeldman und die anderen sollten in sich gehen und fragen, ob sie noch wirklich unabhängig denkende Geister sind oder ob sie sich zu sehr haben vereinnahmen lassen.”

Klar gerade Jeffrey Zeldman hatte gesagt, dass auch die Lösung, in der der IE8 sich eher wie IE7 verhält, akzeptabel wäre. Auch ich hielt das für den falschen Ansatz und glücklicherweise hat sich Microsoft dagegen entschieden. Allerdings schrieb Zeldman auch folgendes in seinem Kommentar (eigene sinngemäße Übersetzung des englischen Kommentars):

“Wenn genügend Webentwickler glauben, dass der Standard sein sollte ‘aktuelle Version’ statt ‘IE7′ - und falls sie schlüssig und sachlich argumentieren - dann könnte es sein, dass Chris Wilson und seine Kollegen ihnen zustimmen und den Standardwert so setzen, wie ihr es wollt und nicht wie zuerst vorgeschlagen. ”

Damit schrieb er meines Erachtens keineswegs, dass er die von Microsoft ursprünglich vorgeschlagene Lösung für optimal hielt. In demselben Artikel schrieb er später ergänzend in einem weiterem Kommentar (eigene sinngemäße Übersetzung der Frage und des Kommentars aus dem englischen Original):
Brian Warshaw: “Wenn die Versionsangabe im Metatag bedeutet, dass ein heute erstelltes Design auch noch in zehn Jahren gut aussieht, ist das nicht diese eine Zeile Code wert? “
Jeffrey Zeldman: “Ja, für mich ist es so, auch wenn es das glatte Gegenteil an Browserverhalten ist, für das ich seit 1998 kämpfe. Meine Motivation war niemals religiös sondern praktisch. Ich möchte, dass die Seiten, die ich entwerfe funktionieren. Wenn diese Lösung hilft dieses Ziel zu erreichen, dann ist sie eine gute Sache. “

Noch deutlicher äußerte sich Eric Meyer in einem Kommentar zu dem Thema auf der Webseite von Jeremy Keith (eigene sinngemäße Übersetzung des englischen Kommentars):

“Wie schon gesagt, ich hoffe sehr dass du mit deiner Meinung diese Diskussion gewinnst; denn mir geht es genauso, ich möchte dieses Vorgabeverhalten. Ich habe genau das vergeblich anzubringen versucht, nun hoffe ich, dass andere ebenso argumentieren und weiterhin versuchen Microsoft zu überzeugen. ”

Insofern bin ich, anders als Jens Grochtdreis, nicht der Meinung, dass sich die beiden von Microsoft haben vereinnahmen lassen. Klar, gerade von diesen Gurus der Webstandards, erhofft sich mancher, dass sie immer bis zum letzten Moment kämpfen. Andererseits zeigt das jetzige Ergebnis, dass das nicht der einzige Weg ist. Ich hoffe, dass die Entscheidung fiel, weil sich viele andere Webentwickler dafür eingesetzt haben. Manche Unkenrufe vermuten allerdings, dass es rechtliche Gründe gegeben haben könnte, die Microsoft zu diesem Schritt bewogen haben.

…doch nicht standardkonformer IE8

Andere, die den IE8 in seiner ersten Beta-Version getestet haben, befürchten, dass es trotz bestandenem Acid2-Test wieder viele Fehler geben könnte, die schon IE7 hatte. IE8 soll im Herbst veröffentlicht werden, ich halte es für verfrüht bei jedem Fehler in der Beta I anzunehmen, dass dieser auch noch in der endgültigen Version vorhanden sein wird.

Insgesamt meine ich, es ist ein sehr gutes Zeichen für die Webstandards, wenn der Riese aus Redmond nicht nur einen Browser entwickelt, der den Acid2-Test besteht; sondern darüber hinaus zulässt, dass nun eher die Webentwickler, die für IE6 oder IE7 optimiert haben, gefragt sind und an ihren Seiten etwas ändern müssen, statt derjenigen, die standardkonform entwickeln.

Das Webstandards Projekt schreibt dazu (eigene sinngemäße Übersetzung):

Was bedeutet diese Entscheidung? Nun, einiges, z.B:

Webautoren, die standardkonforme Seiten erstellen müssen keine Änderungen an ihrem Markup vornehmen, um ihre Webseiten vom IE8 in seinem neuesten bestmöglichen Modus darstellen zu lassen.
Alle Webautoren, die nicht standardkonforme Seiten entwickeln, müssen entweder lernen das zu tun oder aber sie müssen ihrem Markup einen Hinweis hinzufügen, dass ihre Seiten entsprechend einer älteren Version des IE angezeigt werden sollen.
Jeder, der JavaScript nutzt, um je nach Browser einen anderen Code auszugeben, muss das ändern, da viele Annahmen über die Rendering Engine des IE auf die Version des IE8 nicht mehr zutreffen.

Mir gefallen diese Konsequenzen, weil damit der Trend hin zu standardkonformeren Webseiten zwangsläufig verstärkt wird. Ein weiterer informativer Artikel zum Thema Microsoft und Webstandards wurde von Mathias Schäfer (molily) auf dem SELFHTML-Blog veröffentlicht.

Zu den genutzten, nicht erklärten Begriffen siehe Glossar zu Web, Webdesign und Webapplikationen.

Barcamp Bodensee - Web-Konferenz im Mai 2008 in Friedrichshafen

Ausschnitt aus der offiziellen Ankündigung

Ähnliche Beiträge

Episode 6: Grenzen des Refactorings ::: Softwareprojekte