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.

Die sieben Gewohnheiten eines äußerst erfolgreichen, freiberuflichen Webdesigners - oder aller Entwickler?

17.01.07 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

In der Übersetzung Übersetzung: Die sieben Gewohnheiten eines äußerst erfolgreichen, freiberuflichen Webdesigners von Stefan Nitzsche des Artikels 7 Habits of a Highly Successful Freelance Web Designer von Andy Budd werden einige interessante Punkte erwähnt, die zum einen nicht nur für Webentwickler gelten, nein, auch für den "Default-Entwickler" sind diese Punkte gültig.

Mit einem erwähnten Punkt habe ich jedoch so meine Probleme: Spezialisiere Dich.

Prinzipiell ist es ja wichtig sich zu spezialisieren, dennoch wird aus meiner persönlichen Erfahrung immer noch Allrounder bevorzugt. Viele Unternehmen können sich einen Spezialisten pro Fachgebiet einfach nicht leisten.

Es ist jedoch wichtig, Dich nicht auf Kosten Deiner anderen Fähigkeiten zu spezialisieren.

Wie soll das funktionieren? Eine Spezialisierung bedeutet jede Menge zeitlichen Aufwand. Zwangsläufig werden dadurch andere Fähigkeiten zurück gestellt und nicht weiter (oder im notwendigen Ausmass) gepflegt. Ergo stellt sich über einen längeren Zeitraum in den nicht spezialisierten Bereichen eine Verschlechterung ein.

Doch wie dem entgegenwirken? Welches ist die beste Strategie? Diese Fragen kann ich auch nicht beantworten. Jeder muss seinen Weg gehen und kann idealerweise die Dinge tun, die gefallen.

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

Es muss nicht immer AJAX sein ...

14.01.07 - Entwicklung, Diskussionen, .NET, Grundlagen, ASP.NET
Beitrag von Norbert Eder

Wer AJAX nicht einsetzt ist doof. Hört man zumindest Vögel zwitschern. Aber es gibt auch andere Möglichkeiten.

Für viele Dinge ist es zudem auch gar nicht nötig, AJAX einzusetzen, da simple JavaScripts durchaus ausreichen. So ist vor dem Einsatz von AJAX darüber nachzudenken, welcher Zweck erfüllt werden soll und ob es nicht andere - einfachere - Lösungen gibt.

Wer zudem fit in C++ ist, hat die Möglichkeit auf binary HTML Components [1] zu setzen. Zugegeben, schon recht alt, aber funktioniert sehr flott - und ein riesiges Framework ist auch nicht notwendig.

Implementing Binary DHTML Behaviours

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

Ist die VB-Community am Sterben?

13.12.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Erst kürzlich hatte ich eine große Diskussion wo sich User beschwert haben, dass zum Thema VB kaum mehr etwas Neues zu lesen ist, die Unterstützung fehlt und viele weitere Vorwürfe.

Woran das wohl liegen mag?

Nun, VB(6) ist anscheinend eben vom Aussterben bedroht. Viele haben auf .NET gewechselt, oder sind zumindest dabei. Kritische Projekte wurden ohnehin nihct in VB umgesetzt. So gesehen sprechen mittlerweile wenig Gründe dafür, VB einzusetzen.

Auf der anderen Seite muss auch erwähnt werden, dass im Internet zu so ziemlich jedem VB-Problem auch eine Lösung zu finden ist. Warum also diese Aufregung? Ist hier eine Google-Schulung notwendig?

Mittlerweile sollte doch jedem Entwickler klar sein, dass VB aktuell fast keine Existenzberechtigung mehr hat. Entweder man steigt auf .NET um, oder man wendet sich anderen Programmiersprachen zu. Für Anwendungen, die mit deinem Framework á la .NET, Java nicht sinnvoll umzusetzen sind, eigenen sich andere Sprachen ohnehin besser. Ich denke hierbei beispielsweise an C++.

Mir stellen sich aber dennoch einige Fragen zu diesem Thema:

1. Kann es in der Tat sein, dass viele Unternehmen noch auf alte (bewährte) Techniken setzen und sich vor neuen Errungenschaften (die mitunter gar nicht mehr so neu sind) verstecken?

2. Fällt es wirklich einigen Entwicklern schwer, sich auf neue Gegebenheiten einzustellen? Selbst wenn die Entwickler altersmäßig < 25 anzusiedeln sind?

3. Liegt es eventuell an der OOP die unter .NET bzw. Java angewendet werden sollte? Ist Software Architektur zu schwer zu verstehen?

Bis zu einem gewissen Grad kann ich Kundgebungen des Unmutes noch verstehen, aber es sollte niemand die Augen vor neuen Techniken verschließen. Eigenes Potential bleibt auf der Strecke und die dahinterstehenden Unternehmen können mit dem Punkt der Zukunftssicherheit nicht wirklich punkten. Und genau das könnte sich fatal auswirken. Vielleicht nicht sofort, aber bald ...

Viele scheuen auch davor zurück, sich externe Berater zuzulegen. Eventuell liegt es an den veranschlagten Honoraren, die doch in gewissen Fällen astronomische Höhen annehmen. Dennoch können auf diese Art und Weise gute Ergebnisse erzielt werden. Die eigene Software auf den aktuellsten Stand der Dinge zu bringen würde definitiv nicht zum eigenen Nachteil sein.

Im Vergleich zu dem was durch eine veraltete Technik an Einnahmen auf der Strasse bleibt, kostet ein Experte eigentlich gar nichts ...

Aber zurück zum Thema: VB stirbt vor sich hin und es wundert mich nicht. Entsprechende Entwickler sollten sich lieber mit der aktuellen Technik beschäftigen und sich selbst auf Vordermann bringen, anstatt ihren Unmut in diversen Foren kund zu tun. Sicher ist sicher.

6 Kommentare - 815 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Frauen in der IT

06.11.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Nein, jetzt kommt kein Witz, sondern ein wirklich ernstes Thema.

Ich kenne einige Frauen die in der IT beispielsweise als Softwareentwickler tätig sind und viele klagen über dieselben Probleme. Dies fängt bei Mobbing an und geht hin bis zur unstellten Unfähigkeit, fehlendes Logik-Verständnis usw. Männer werden in dieser Branche immer noch als die besseren Fachkräfte angesehen und genauso behandelt.

Bei genauerem Hinsehen ist dem aber oft nicht so. Schwarze Schafe gibt es überall und pickt man sich diese aus dem Haufen der Entwickler, stehen wir Männer vermutlich ganz schön dumm da.

Was ich aber damit sagen will ist folgendes: Wir sollten uns alle am Riehmen nehmen uns es ausnahmsweise mal so halten, wie es auch der Computer tut: Er macht auch keinen Unterschied, nur weil die Person, die in die Tasten haut, Brüste hat. Sauberer, korrekter Code ist gefragt und das schaffen auch Frauen.

Meiner Erfahrung nach sind Frauen einfach wichtig für ein Team, weil sie uns Männer wieder auf den Boden der Realität holen und für Ausgleich sorgen. Kein Ding, welches abschätzend behandelt werden muss.

Es wäre nur allzu schön, wenn sich die paar wenigen Pseudo-Machos darüber Gedanken machen würden und vor dem nächsten Spruch vielleicht einmal kurz ihr Hirn einschalten.

Es war mir ein Anliegen, das los zu werden!

10 Kommentare - 1212 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Welche Programmiersprache ist denn nun die beste?

01.11.06 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Unter diesem Motto stand heute eine kurze Diskussion mit programmierbegeisterten Personen.

Nun, welche ist denn wirklich die beste? Meine Antwort darauf: Ist es eigentlich nicht nebensächlich?

Eine Programmiersprache ist lediglich ein Werkzeug. Die tatsächliche Arbeit eines Programmierers/Entwicklers findet im Kopf statt. Patterns, Algorithmen, Abläufe, logische Konstrukte ... alles wird im Kopf zu einem Produkt zusammengeschraubt. Wer analytisch/logisch gut ist, kann auch ein guter Programmierer sein.

Mit welchem Werkzeug diese Gedanken/Ideen/geistigen Konstrukte umgesetzt werden ist ansich nebensächlich, da in einigen Fällen vom Kunden vorgeschrieben und in anderen Fällen eben nicht. In letzteren Fällen sollte die Programmiersprache an die Gegebenheiten angepasst werden. Was bedeutet dies genau?

Nicht jede Programmiersprache eignet sich für alle Bereiche. So macht es wenig Sinn, einen Hardware-Treiber mit C# zu entwickeln. Genausowenig sehe ich die Notwendigkeit, C++ für eine Webapplikation einzusetzen, ausser beispielsweise für bestimmte Hintergrund-Aktionen (aufwändige Berechnungen etc.). D.h. es macht durchaus Sinn, mehrere Programmiersprachen miteinander zu kombinieren und die Vorteile tatsächlich auszunützen. Es macht jedoch keinen Sinn, einen Glaubenskrieg auszulösen, wie es allgemein hin gerne gehandhabt wird.

Aber auch weiterhin wird es viele geben, die mehr Wert auf die Programmiersprache legen, als die darüber stehenden Paradigmen. Meiner Ansicht nach ein Fehler. Aber das muss wohl jeder für sich selbst entscheiden.

Anmerkungen, Ergänzungen, andere Sichtweisen sind natürlich gerne gesehen. Flamewars sind nicht erwünscht. In diesem Sinne wünsche ich noch einen wunderschönen Nachmittag.

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

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 - 726 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

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 - 686 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 - 992 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

Zurück Weiter