ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

Thema Release-Management

22.10.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Grundsätzlich gehe ich davon aus, dass mein Weblog hauptsächlich von Software-Entwicklern gelesen wird. Daher werden sich die einen oder anderen sicherlich mit dem Thema Release-Management beschäftigen.

Jetzt gibt es natürlich unterschiedlichste Varianten bis die Software beim Kunden fertig installiert bzw. überhaupt erst beim Kunden ist. Angefangen von vollautomatischen Abläufen bis hin zur manuellen Release-Erstellung und Doployment via Zip and Go.

Wie wird das bei meinen Lesern gehandhabt? Welche Tools kommen zum Einsatz? Wie sieht es mit Fehlerhäufigkeiten bei einem vollautomatischen Prozess aus?

Auch ich habe in diesem Bereich bereits meine Erfahrungen gemacht, bevor ich diese jedoch grundsätzlich hier breit trete, würden mich die Erfahrungen meiner Leser interessieren.

1 Kommentar - 727 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Continuous Integration - kenn ich nich ..

21.10.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Nein? Dann dürfte ein Artikel von Martin Fowler [1] zu diesem Thema [2] wirklich weiterhelfen.

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

[1] Martin Fowler
[2] Continuous Integration

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Das Übel Software-Testing

20.10.06 - Entwicklung, Software Testing
Beitrag von Norbert Eder

Gestern hatte ich ein längeres Gespräch mit einem befreundeten Entwickler. Basis der Diskussion war das Thema Software-Testing in allen Formen, Varianten und warum die Akzeptanz so gering ausfällt.

Fakt ist (zumindest laut meiner persönlichen Erfahrung), dass nur sehr wenige Firmen Software wirklich testen. Damit meine ich nun weniger, das rein zufällige Finden von offensichtlichen Bugs durch unkontrolliertes - an Zuckungen erinnerndes - Herumklicken auf der GUI, sondern vielmehr der Einsatz von einschlägigen Hilfsmitteln á Unit-Tests und Co.

Wenn ich nun kommuniziere, dass es am zusätzlichen Aufwand liegt, dann wiederhole ich mich, denn dieser dürfte es anscheinend nicht sein. Vielmehr daran, dass viele Entwickler nur dann Spass am Programmieren haben, wenn Neues geschaffen werden kann. Beim Schreiben von Tests muss jedoch bereits entwickeltes geprüft werden (in vielen Fällen), was einer Wiederholung gleich kommt. Um es auf den Punkt zu bringen: es ist einfach fad. Daher wird dieser wichtige Schritt einfach nicht durchgeführt.

Das Resultat? Nun, wer würde sich ein Auto kaufen, welches jedes Mal auf der Autobahn abstirbt, weil der Motor aufgrund der andauernden Belastung überhitzt, also quasi einen Überlauf verursacht. Oder man stelle sich vor, dass das Aufblendlicht nicht funktioniert, weil der Kontakt zur Birne fehlt, was vergleichbar mit einer Null-Reference-Exception wäre. Viele viele Beispiele gäbe es an dieser Stelle. Grundsätzlich möchte jeder ein voll funktionstüchtiges Auto. Genauso verhält es sich mit Software. Wenn andere Branchen so fehlerbestückte Produkte ausliefern würden, wie es Software-Branche tut, könnten wir vermutlich mit keinem Gerät bzw. keinem Produkt tatsächlich etwas anfangen. Das stimmt sehr nachdenklich.

In diesem Sinne wünsche ich einen guten Start ins Wochenende und auf dass es in Zukunft nicht auch notwendig ist, die Software zum Service zu bringen oder gar jährlich ein Pickerl (TÜV) machen zu lassen ...

5 Kommentare - 1118 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

S/MIME, PGP - Ein Hype der nie einer war?

17.10.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Lange hat man schon nichts mehr über S/MIME, PGP und Co. gehört. Doch gab es hier doch den vermeintlichen Hype. In Österreich die Einführung der Bürgercard, Zertifikate auf den Bankomat-Karten usw. Und was ist daraus geworden?

Genau das, was ich mir anfangs schon gedacht habe: Nichts. Kaum einer hat es, kaum einer verwendet es. Im geschäftlichen Alltag mag es sich nicht so recht durchsetzen, auch wenn einige Unternehmen auf eine elektronische Rechnungslegung setzen, aber so wirklich zieht es dann auch wieder nicht.

Wer signiert denn wirklich seine Emails? Sehr wenige. Warum? Weil es noch immer zu kompliziert ist. Viele Zertifikate werden nicht erkannt, ohne diese extra zu installieren (welcher Otto-Normal-Verbraucher kann das schon?), externe Geräte im Kleinwagen-Format die man mitschleppen muss und ständige Probleme mit unterschiedlichen MIME-Types, Content-Types und Co.

So toll digitale Signaturen auch sind, das grundlegende Problem liegt an einer anderen Stelle. Dieses verhunzte Mailsystem. Ein Jahrzehnte altes System in welches versucht wird, neue Anforderungen hineinzupfriemeln, anstatt das gesamte System zu revolutionieren. Die zugrundeliegenden Protokolle müssten überarbeitet und mit Sicherheitsmerkmalen versehen werden, aber das würde auf der einen Seite viel Hirnarbeit erfordern und auf der anderen Seite einen großen Umstellungsaufwand auf Seiten der Serverlandschaft als auch bei den Clients bedeuten. Dennoch sollte dies erledigt werden. So könnte man Spammern Einhalt gebieten, eine sichere Übertragung gewährleisten und digitale Signaturen könnten für den Endbenutzer wesentlich einfacher integriert werden.

Diese Maßnahme würde jedoch auch Nachteile für den Staat, diverse Geheimdienste und natürlich den ganzen Anti-Terror-Einheiten bedeuten. Immerhin kann man sich dadurch nicht mehr so einfach an die Fersen von potentiellen Terroristen heften. Resultat: keine Veränderung. Lieber der lieben Hausfrau 100 neue Probleme aufhalsen, damit ihr Sohn auf Hawaii sich sicher sein kann, dass die gerade empfangene Mail tatsächlich von seiner Mutter stammt.

Dabei wäre die Lösung so einfach ...

2 Kommentare - 687 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Wird es Zeit für einen Paradigmenwechsel in der Softwareentwicklung?

06.08.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Die Softwareentwicklung - wie sie Heute ist - hat sich im Grunde schon lange nicht mehr verändert. Nach wie vor wird ein Texteditor (oder eben eine bunte IDE) benutzt, um stundenlang Code hinein zu hacken. Von der prozeduralen Art und Weise gab es den Sprung zur objektorientierten Programmierung, den jedoch immer noch viele Entwickler nicht mitgegangen sind. Immer noch werden zahlreiche Anwendungen in Sprachen á la Visual Basic 6 und Co. verfasst. Aber auch die objektorientierte Programmierung ist nicht das Gelbe vom Ei. Ursprünglich davon ausgegangen, dass man mit OOP alle realen "Objekte" abbilden kann, stellt man fest, dass dies in manchen Fällen dann doch nicht so einfach (wenn überhaupt) möglich ist. Probleme aus der Steinzeit der Entwicklung kehren immer wieder zurück und Entwickler müssen sich die selben Gedanken machen wie vor 20 Jahren.

Zahlreiche neue Frameworks tummeln sich und versprechen Leistungsvorteile, schnelleres Entwickeln. Altes wird neu verpackt (Beispiel AJAX) und auf den Markt gebracht. Die Entwicklungszeiten werden dadurch meist nicht verkürzt. Patterns hier, Application Blocks dort, einfache oder komplizierte Template-Techniken (siehe Visual Studio 2005) und weitere lustige Spielerein. Kaum jemand kann sich wirklich ausschließlich auf seine Businesslogik konzentrieren. Immer noch muss der meiste Code per Hand eingegeben werden. Für alltägliche Funktionalitäten - was eigentlich nicht sein müsste.

Techniken wie aspektorientierte Programmierung, agile Softwareentwicklung, Extreme Programming versprechen Leistungssteigerungen und Qualitätsverbesserungen. Fakt ist, dass die Softwareentwicklung immer noch zu lange dauert, zu teuer ist und jeder sein Auto sofort verschrotten lassen würde, würde die Qualität der der Softwareentwicklung entsprechen.

Aber woran liegt das? Zum einen liegt es mitunter am Softwareentwickler selbst. In kaum einen Unternehmen wird qualitativ hochwertige Software entwickelt. Dabei gibt es zahlreiche Hilfsmittel, die hier eine eindeutige Verbesserung verschaffen: Unit Testing, Code Coverage usw. Vielfach wird der Grund hierfür in der zusätzlich notwendigen Zeit gesehen. Dass die für beispielsweise Unit Testing aufgewendete Zeit, jedoch vielfach wieder eingespart wird (die Amortisationszeit im Fehlerfalle ist sehr gering), wird von der Hand gewiesen. Weiters sehe ich Gründe darin, dass viele Entwickler lieber die Techniken verwenden, die sie bereits jahrelang anwenden und somit absolut den neuen Techniken hinterher programmieren. Anstatt sich komplette Bestandteile der Software durch entsprechende Tools automatisch generieren zu lassen, wird weiterhin jede einzelne Zeile Code per Hand erfasst.

Was jedoch auch fehlt, sind notwendige Tools um die Entwicklungszeit zu verkürzen. Immer wieder hört man von diversen Projekten, die sich dessen annehmen, wirklich gute Produkte sind mir jedoch bis dato noch nicht vor die Füße gefallen. Langsam aber sicher bewegt sich jedoch die Softwareentwicklung in die einzig richtige Richtung: Paradigmenwechsel.

Was versteht man unter einem Paradigmenwechsel? Ein Paradigma stellt dar, wie eine bestimmte Angelegenheit erledigt wird. Lange Zeit war es beispielsweise ein Paradigma, Consolen-Anwendungen zu schreiben, bis es dann die ersten grafischen Oberflächen gab und man erkannte, dass dies die Anwendung erleichtert und somit einen Mehrwert bietet. Ein Paradigmenwechsel findet dann statt, wenn sich zum aktuellen Paradigma Anomalien ergeben. Dies sind Missstände, die sich nicht lösen lassen und daher eine Erneuerung geschehen muss. Ein Paradigmenwechsel bringt also Neuerung und meist auch Verbesserung.

In der heutigen Softwareentwicklung ergeben sich einige Anomalien. Darunter finden sich - wie bereits oben angesprochen - eine Menge "großer" Punkte (Kosten, Zeit, Qualität). Hier muss angesetzt werden und wird es teilweise auch. Bis entsprechende Produkte auf den Markt kommen wird durchaus noch Zeit vergehen, aber im Kleinen sollte jeder daran arbeiten, sich selbst und vor allem seine Produkte zu verbessern und zu optimieren.

2 Kommentare - 1000 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

Der richtige Weg zu Microsoft Zertifizierungen?

06.07.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Werte Blog-Leser!

Ich weiß, dass einige von euch bereits Microsoft Developer Zertifizierungen gemacht haben bzw. manche gerade am Lernen sind. Daher wende ich mich einmal mit einer Frage an euch, eventuell könnt ihr mir weiterhelfen:

Ich möchte in der nächsten Zeit einige Developer-Zertifizierungen absolvieren und bin noch ein wenig unschlüssig, welche Zertifizierung ich machen soll (immerhin gab es von Microsoft diesbezüglich eine Umstellung auf neue Zertifikate). Dazu nun einige Fragen:

1. Welche Zertifizierung würdet ihr machen bzw. habt ihr gemacht? (Richtung C#, SQL Server)
2. Welche Vorbereitungen habt ihr absolviert? (Unterlagen etc.)
3. Etwaige Tipps und Tricks?
4. Wie lange war eure Vorlaufzeit?

Ich würde mich über den einen oder anderen sachdienlichen Hinweis freuen. Entweder hier per Kommentar oder via mein Kontakt-Formular.

Vielen Dank.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Unit-Tests und Aufwand

16.02.06 - Entwicklung, Software Testing
Beitrag von Norbert Eder

Danke für die vielen Rückmeldungen, die ich vor allem in Form von Emails erhalten habe. Dabei stand fast immer die Frage nach dem Aufwand im Vordergrund.

Zu diesem Thema kann ich folgendes sagen/behaupten:

Natürlich verursacht das Erstellen von Unit-Tests einen entsprechenden Aufwand, da jede Methode in allen erdenklichen Varianten getestet werden soll. Sinnvollerweise wird der Unit-Tests parallel zur zu testenden Klasse entwickelt. Dadurch erhöht sich zwar der Aufwand für die Entwicklung von Klassen, man bedenke aber das große ABER:

Durch die ständigen Test-Durchläufe kristallisieren sich sehr schnell Fehler heraus bzw. wo es nach einer durchgeführten Änderung ein wenig zwickt. Sollte dann doch einmal ein Fehler durchrutschen, kann mit Hilfe der Unit-Tests dieser recht schnell nachvollzogen bzw. überhaupt gefunden werden. Das erspart sehr viel Zeit. Vermutlich mehr, als man sich durch das Nichtschreiben von Unit-Tests sparen würde.

Jeder Leser kann sich nun selbst ein Bild davon machen. Einfach die durchschnittliche Anzahl der Bugs heranziehen und kurz darüber nachdenken, wie schwer so manche davon zu finden sind. Viele davon wären mit Unit-Tests erst gar nicht zustande gekommen.

Ich hoffe dieser Beitrag regt zum Nachdenken und Nachrechnen an und liefert so für jeden von Euch ein Ergebnis bezgl. der Sinnhaftigkeit von Unit-Tests.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Programmierer - Habe ich das Zeug dazu?

13.11.05 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Wie werde ich ein guter Programmierer? Welches Wissen muss ich mir aneignen? Was macht einen guten Programmierer aus? Welche Programmiersprache soll ich verwenden?

Diese und weitere Fragen werden sehr oft gestellt und meist erkenne ich aus der Fragestellung, dass in vielen Fällen wenig Wissen und wenig Erfahrung im Hintergrund schlummert. Grund dafür ist meist das junge Alter. Nichts desto trotz sind einige Punkte zu beachten, will man wirklich professionelle Programme schreiben.

Wissen ist Macht

Nicht nur Wissen ist Macht. Informationen zum richtigen Zeitpunkt zu finden ist ein sehr wichtiger Bestandteil. Im heutigen Zeitalter stellen Google und Co. sehr gute Suchhilfen zur Verfügung um relativ schnell an die gewünschte Information zu gelangen. Hierfür empfiehlt es sich allerdings, die angebotenen Hilfen der jeweiligen Betreiber gut durchzulesen und auch ein wenig zu testen. Damit kann die Trefferquote stark erhöht werden.
Weiters bieten die Hersteller von Programmiersprachen meist umfangreiche Communities bzw. Hilfeseiten an. Diese bieten gute Einführungs-, als auch Hintergrundinformationen.

Konsequent, aufnahmefähig und lösungsorientiert

Diese Eigenschaften sollten von der entsprechenden Person auf jeden Fall mitgebracht werden. Sicherlich macht es Spaß, dass eine oder andere Spielchen zu programmieren. Man muss jedoch ständig darauf achten, am Ball zu bleiben, sich neue Technologien anzusehen und vor allem Erfahrung zu sammeln.

Oft wird einfach nur in den Tag hineinprogrammiert. Es ist ja einfach und man kann sich teilweise den Sourcecode aus dem Internet besorgen und schnell ist damit ein Programm zusammenkopiert. Dies ist allerdings keine Lösung, will man ein guter Programmierer werden. Sourcecode zu kopieren macht dann Sinn, wenn man daraus lernen will. Beim nächsten Mal sollte man das Problem eigenständig lösen können. Natürlich sollte Vorhandenes genutzt werden - jedoch sollte man auch wissen wie es funktioniert.

Und die Programmiersprache?

Die Programmiersprache ist nebensächlich. Viele machen daraus jedoch einen Glaubenskrieg. Vor allem auf die Frage welche Programmiersprache denn verwendet werden soll, entbrennt eine heftige Diskussion zu diesem Thema. Dem Einsteiger hilft das meist recht wenig. Im Grunde kann ich an dieser Stelle sagen, dass sich die unterschiedlichen VB-Dialekte sehr einfach zu erlernen sind. Jedoch sollte in der heutigen Zeit auf jeden Fall von Beginn an die objektorientierte Programmierung (OOP) erlernt werden. Dies ist essentiell. Prinzipiell würde ich an dieser Stelle zu C#, Java oder Delphi raten.

Styleguides und Co.

Styleguides sind Richtlinien, die beschreiben, wie Sourcecode, Namensgebung etc. auszusehen haben. Man sollte sich recht früh einen entsprechenden Styleguide heraussuchen und sich diesen angewöhnen. Die Vorteile liegen darin, dass der Sourcecode strukturierter aufgebaut wird, die Namensgebung konsistent gestaltet und somit die Möglichkeit auch im Team arbeiten zu können gesteigert wird. Der Sourcecode wird lesbarer und leichter zu verwalten.

Conclusio

In der heutigen Zeit werden viele Anforderungen an Programmierer gestellt. Auf vielen Gebieten ist großes Wissen notwendig. Selbständigkeit beim Erlernen einer Programmiersprache bzw. der Grundlagen ist genauso gefragt wie Teamfähigkeit. Der notwendige Aufwand ein guter Programmierer zu werden ist sehr hoch. Wissensdurst vorausgesetzt.

3 Kommentare - 3740 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Zurück