Mein eigenes kleines Entwicklungs-Wertesystem

Ich mache das mit dieser Softwareentwicklung ja schon ein paar Jährchen (irgendwas um die 12 Jahre +/-), und habe dabei wirklich stetig versucht mich zu verbessern. Habe Abends und am Wochenende Blogeinträge und Bücher gelesen, bin zu Konferenzen und Usergroups gegangen oder letztere organisiert, und mich auch ständig mit den neusten Technologien, Praktiken, Methodiken auseinandergesetzt. Dabei baut man sich natürlich so sein eigenes System an Werten und Praktiken, die einen durch den Alltag bringen.

Wenn ich also zusammenfassen müsste, warum ich bestimmte Dinge so tue wie ich sie tue, dann weil ich mir die Strukturierungsmechanismen meiner Software so aussuche, dass diese möglichst auch in mittelgroßen Projekten noch gut skalieren können sollten (was auch immer so genau mittelgroß sein mag). Und was heisst denn skalieren nun schon wieder? Pff! Ok, ich formuliere es anders: Bei der Auswahl dieser Strukturierungsprinzipien gehe ich nach einem denkbar einfachen Modus vor. Ich bewerte Sie nach Ihrem Einfluss auf drei Eigenschaften von Software bzw. Quellcode, denen ich möglichst alles andere unterordne. Diese Eigenschaften sind Lesbarkeit, Testbarkeit und Einfachheit. Aus diesen kann man je nach Argumentation andere Eigenschaften wie Wartbarkeit, Änderbarkeit etc. ableiten. Denn es geht ja vor allem darum, möglichst schnell Produktivität oder andere Werte für ein Geschäft zu schaffen, und flexibel (agil blabla) auf sich ändernde Rahmenbedingungen reagieren zu können. Dabei hilft es mir, diese Eigenschaften in den Vordergrund zu stellen.

OK, bis hierhin soweit klar? Vermutlich nicht, oder? Denn: Hier haben wir nämlich schon wieder sofort das Problem, dass diese drei Eigenschaften sich nur begrenzt messen und in feste Regelwerke pressen lassen. Dazu könnte man eine größere Diskussion zu Messbarkeit von Software und dem Mangel an empirischer Forschung dazu lostreten. Lasse ich in diesem Fall aber lieber. Da mir die Grenzen des Wissens in unserer jungen Branche bewusst sind, habe ich für mich ein paar Daumenregeln entwickelt, um zumindest Testbarkeit und Einfachheit einzuschätzen.

Einfachheit

Beginnen wir mit letzterer, der Einfachheit: Ich sage öfter halb scherzhaft, halb ernst gemeint, dass mein Gehirn zu klein wäre, um große Codestücke wie lange Klassen oder Methoden zu erfassen und zu durchdringen, und ich in Ermangelung von genug geistiger Kapazität meine Code-Elemente daher klein strukturieren muss. Klein heißt für mich: Eine Klasse passt im besten Fall auf maximal 2-3 Bildschirme, was bei aktuellen Bildschirm- und Schriftgrößen auf ca. 100-150 Zeilen Code hinausläuft. Das ist meine Definition von Einfachheit oder Übersichtlichkeit. Dadurch sind diese Klassen und ihre Methoden auch meist auf genau einen bestimmten Zweck zugeschnitten, was schönen Dingen wie dem Single Responsibility Principle Rechnung trägt und häufig auch der Lesbarkeit zuträglich ist.

Lesbarkeit

Lesbarkeit kann ich persönlich selbst mit Daumenregeln nicht mal im Ansatz messen. Ich bin ein großer Freund von Clean Code Methodiken und SOLID Prinzipien etc., aber eine Messbarkeit sehe ich da bis heute nicht. Also falle ich auf Einfachheit als grob überschlagbar messbares Kriterium zurück, und versuche dennoch Clean Code Praktiken und andere Dinge anzuwenden, um der restlichen Unsicherheit noch weiter entgegen zu treten.

Testbarkeit

Kommen wir zur Testbarkeit, die vermutlich einzige wirklich messbare dieser drei Eigenschaften von Software. Messbar warum? Nunja, indirekt. Man kann Testbarkeit natürlich nicht auf einer Skala von 1-10 abtragen. Was man allerdings messen kann, ist die Testabdeckung (Code Coverage) der eigenen Software. Hier peile ich in allen Projekten 90-100% an. Nicht immer 100%, da bestimmte Teile von UI Code oder durch Tools erzeugtem Code entweder nicht, oder nur durch hohen Aufwand zu testen sind. Natürlich kann man die 100% dann trotzdem erreichen, indem man diese Code-Teile von der Coverage-Analyse ausschließt. Hier muss man aber mit Augenmaß vorgehen, um nicht zu viel auszuschließen oder grob zu betrügen. Im Zweifel also lieber nicht tun. Beim Testen ist mir grundsätzlich auch egal, ob das nun durch Unit Tests oder Integration Tests stattfindet. Mir ist wichtiger, dass die Tests eine hohe Aussagekraft über die Funktionsweise der Software haben. D.h. oft nehme ich die Datenbank explizit mit in die Tests, um Fehler in Treiber, Query Engine, Constraints, oder ähnliches auch schon in meinen automatisierten Tests zu bemerken. Geil, oder? OK, nächster Bonuspunkt: Software sollte gewissen Strukturierungsprinzipen folgen, um möglichst einfach testbar zu sein. Lose Kopplung, Abstraktion (Interfaces usw.), kleine Klassen mit genau definierten Aufgaben, etc. So unterstützt die Eigenschaft Testbarkeit auch sofort die Verbesserung der inneren Struktur einer Software. Nun mögen die Klugscheißer unter uns natürlich anmerken, dass man mit hohem Aufwand auch eine schlecht strukturierte Software durchaus testen kann. Das stimmt, selbst solche Software lässt sich von aussen mit UI- oder End-to-End-Test Tools testen, und teilweise sogar eine messbare Testabdeckung erzeugen. Aber meist steht der Aufwand in keinem guten Verhältnis. D.h. man sollte bei der Bewertung der Testbarkeit die Relation dazu nehmen, wieviel Zeit man für das Schreiben von Tests aufwendet, im Vergleich zu der Zeit die man mit dem Schreiben des zu testenden Codes verbringt. Meiner Erfahrung nach, ist ein gutes Verhältnis 2:1, d.h. ich verbringe zwei Drittel der Zeit mit dem Schreiben von Tests, und ein Drittel der Zeit mit dem Code der getestet wird. Das ist ein einigermaßen gesundes Verhältnis, wie ich finde. Und meine Erfahrung lehrt mich, dass das Schreiben von UI oder End-to-End Tests für schlecht strukturiere Software in den allermeisten Fällen massiv mehr Zeit verschlingt, als der Bau der zu testenden Funktion.

Fazit

So, das ist es. Mein eigenes Mini-Wertesystem, welches mich mit einigermaßem gesundem Verstand durch viele Projekte gebracht hat. Diskutiert gerne auf Twitter (https://twitter.com/schmagahimself) oder sonstwo mit mir darüber, bin gespannt.

Meine persönliche Protractor Odyssee, oder: „Tests mit Protractor im Konzern“

Jeder, der Software entwickelt, kennt das Problem: Die Arbeit läuft, es geht voran, aber für die letzten 20% der Arbeit braucht man dann 80% der Zeit. Irgendein Randfall oder eine Lücke in den Features einer Library, eine merkwürdige Kundenanforderung, komische modellierte Daten. Tada, der frühe Feierabend oder der pünktliche Sprint-Abschluss ist dahin. Ständig verbraten wir Arbeits- und Lebenszeit auf den Abwegen vom Happy-Path.

Meine folgende Story hat damit nichts zu tun… Sie handelt davon, wie man auch schon auf dem Happy-Path so oft stolpern kann, dass man am liebsten lachend in eine Kreissäge rennen möchte. Sie handelt auch davon, wie man manchmal einen regelrechten Hass auf zentral gesteuerte Konzern-IT bekommen kann, und wie wenig die hippe Welt der Web-Entwicklung auf solche Umstände Rücksicht zu nehmen scheint. Ich sollte an dieser Stelle dazu sagen, dass ich als Freelancer oft in Kundenprojekten von Konzernen oder Mittelständlern unterwegs bin. Dort ist die IT in der Regel zentral gesteuert und sehr restriktiv. Oft haben nicht einmal die Leute in den Entwicklungsabteilungen auf ihren Rechnern Admin-Rechte.

Aber kommen wir zum Kern: So ergab es sich, dass ich bei einem meiner Kunden eine neue Angular Anwendung aufsetzen sollte. Wie es sich für einen guten Entwickler gehört, wollte ich auch für die neuen Features direkt einen kleinen Satz an End-to-End Tests bauen. Damit nahm das Unheil seinen Lauf.

Teil 1:
Der erste Versuch, und schon legt sich Protractor aka Webdriver aka Selenium etc. auf die Fresse.

Mushroom Cloud
That’s what you get for trying to test your software

Grund: Es war keine Java Runtime installiert. Bis diese installiert war, ging eine Woche ins Land (keine Admin-Rechte, Genehmigungsverfahren, Remote-Installation per Helpdesk). Eine Woche war sogar verhältnismäßig schnell…

Teil 2:
Freudig versucht Protractor laufen zu lassen, und schon legt es sich wieder auf die Fresse. Grund: Das automatische Updaten der webdriver-manager Abhängigkeiten läuft auf einen Timeout, konkret: Error: connect ETIMEDOUT …
Schuld diesmal: Der Proxy-Server. Das kannte ich schon, da ich Proxy-Server schon aus vielen Projekten gewöhnt war. Die Lösung für den webdriver-manager:
set HTTP_PROXY=http://somecompany-proxy:1234
set HTTPS_PROXY=http://somecompany-proxy:1234

Teil 3:
Und weiter geht es, ich habe es doch jetzt geschafft, oder? Weit gefehlt! Wieder legt sich das Teil auf die Fresse, denn: Die Automatik vom webdriver-manager zieht natürlich die neuste Version des ChromeDrivers, also des Teils, über den der Chrome Browser ferngesteuert wird. Wenn man nicht den neusten Chrome installiert hat resultiert das aber leider in folgender Meldung:
E/launcher – session not created exception: Chrome version must be >= 64.0.3282.0
Na super, was macht man als Entwickler, wenn man schon tagelang kämpfen musste, um überhaupt einen Chrome installiert zu bekommen, und ihn nicht einfach updaten kann? Für die friedlichen unter uns:
webdriver-manager update --chrome --versions.chrome=2.36

Teil 4:
Womit wir direkt zum nächsten Punkt kommen. Das hilft natürlich nicht, denn der Automatismus, der über ng e2e aufgerufen wird, nutzt irgendeine fest in einer .config Datei verdrahtete Version von ChromeDriver. Diese .config Datei wird mit npm ausgeliefert und ist daher kein guter Ort um sie zu ändern, da andere Entwickler sonst von der eigenen Vorarbeit nicht profitieren. Auch etwas was ich leidvoll erfahren musste und erst nach einiger Recherche beheben konnte.
Die Lösung hier ist ein Verweis auf die ChromeDriver Version in der protractor.conf.js:
chromeDriver: 'C:/ChromeDriver/chromedriver_xx.exe', ...

Warum der absolute Pfad? Bei global installiertem Protractor würde die Version sonst in den AppData Ordner des Benutzers installiert (ich befinde mich auf einem Windows System), den man mit Umgebungsvariablen oder ähnlichem Kram auflösen müsste. Es muss also auch das Updaten des webdriver-managers in diesen Ordner gesteuert werden:
webdriver-manager update --chrome --versions.chrome=2.36 --out_dir C:\ChromeDriver

Teil 5:
ng e2e
Und es läuft!!! Scheiß‘ die Wand an…

Fazit
Ich hoffe dieser Artikel hilft möglicherweise einigen, die auf ähnliche Probleme wie ich gestoßen sind. Dann hätte ich zumindest etwas positives damit erreicht, mal abgesehen von Frustverarbeitung 🙂 Aber so hatte ich wenigstens ein wenig Spaß beim Dampf ablassen.

Und die Moral von der Geschichte? Ich hasse Konzern-IT! Sie hindert ständig Menschen daran, ihre Arbeit richtig zu machen. Jaja, in manchen Fällen mögen restriktive Vorgaben durch die zentrale IT durchaus sinnvoll sein. Ich habe sogar aus eigener persönlicher Erfahrung sehr viel Verständnis dafür, da ich viele Monate selbst in der Administration und im Helpdesk diverser Unternehmen unterwegs war. Aber für Rechner von Softwareentwicklern ist das in etwa so, als würde man einem Künstler sagen, er solle doch ein schönes kreatives buntes Bild malen, aber bitte nur mit den freigegebenen Konzern-Bleistiften. Ralf Westfal hat dazu in der dotnetpro einen wundervollen Artikel geschrieben, der es sehr gut zusammenfasst: https://www.dotnetpro.de/diverses/lesenswert/strategien-talentkrieg-1459619.html. Leider ist der Artikel nicht öffentlich verfügbar. Für Links zu anderen Artikeln dieser Art bin ich immer dankbar! Diese Produktivitäts- und Motivationsvernichtung in deutschen Unternehmen kann man nicht oft genug anprangern 🙂

Schmaga beim nationalen Imagine Cup Finale und dem Community Open Day

Diese Woche ist es wieder soweit. Es findet das nationale Finale des Microsoft Imagine Cup statt, einem Technologiewettbewerb für Studenten. In unterschiedlichen Kategorien (dieses mal Games, Innovation und World Citizenship) treten dort die jeweils besten drei Teams der Kategorien aus Deutschland gegeneinander an. Eine Vorauswahl passierte bereits in diversen regionalen Finalen. Den erstplatzierten der Kategorien winkt neben Sachpreisen eine Teilnahme beim internationalen Finale in Seattle. Und dadurch vielleicht noch viel mehr Ruhm und Ehre; Denn durch die hohe Sichtbarkeit dort könnten durchaus Investoren, Unterstützer und andere Interessierte auf die Teams aufmerksam werden. Ich bin mit dem Imagine Cup auch durchaus emotional verbunden, da wir in 2009 mit einem Team aus Freunden beim nationalen Finale den zweiten Platz gemacht haben. Inklusive Handshake der damaligen Bundesentwicklungsministerin 😉

Dieses mal gibt es aber insofern eine Besonderheit, als dass ich in der Jury sitzen werde 🙂 Und zwar in der Kategorie Games. Ich muss ehrlich zugeben: Ein Platz in einer solchen Jury ist ein Novum für mich, und ich bin ein klein wenig nervös. Wer mich kennt weiß dass ich ein leidenschaftlicher Gamer bin, der schon hunderte Spiele in seinem Leben verschlungen hat. Daher werde ich natürlich versuchen mein bestes zu geben, um ein objektiver und fairer Juror zu sein. Nach einem ersten Blick auf die drei Finalisten-Teams kann ich nur sagen: Es wird absolut spannend.

Die Siegerehrung geschieht dann kommenden Freitag bei der Eröffnung des Microsoft Community Open Day (COD), an dem ich in meiner Rolle als Leiter der .NET Usergroup Essen auch teilnehmen werde. Beim COD werden diverse Usergroup Leiter, Most valuable Professionals und andere Personen aus der Microsoft Community zusammenkommen, um zu diskutieren, spannende Vorträge zu schauen, und zu netzwerken. Ich bin schon sehr gespannt und freue mich auf viele bekannte und neue Gesichter.

(0)

Über gute Entwickler…

Im November habe ich auf den Clean Code Days in München einen Vortrag darüber gehalten, wie unzufrieden ich mit vielen Entwicklern in Deutschland bin, mit denen ich während meiner bisherigen Laufbahn Kontakt hatte oder zusammengearbeitet habe. Das war allerdings ein ziemlich pessimistischer Blick auf die Welt. Daher drehe ich den Blickwinkel heute mal um und möchte beschreiben was es bedeutet ein guter Entwickler zu sein bzw. was man meiner Ansicht nach benötigt um einer werden zu können.

Durch befreundete Entwickler, mein wachsendes Netzwerk, und vor allem meine Arbeit in der Microsoft Community bin ich in letzter Zeit mit vielen Entwicklern zusammengetroffen, die ich als überdurchschnittlich engagiert und talentiert wahrnehme. Natürlich stellt man sich dann an dieser Stelle oft die Frage, wie man sich selbst zwischen all diesen Entwicklern einzuordnen hat.
Um genau diese Einordnung für mich vornehmen zu können, habe habe ich in letzter Zeit sehr viel darüber nachgedacht, was die ordentlichen Entwickler von den Guten, und die Guten von den absoluten Ausnahmetalenten unterscheidet.

Es gibt einige Fähigkeiten/Eigenschaften, die ich in diesem Kontext als essentiell wahrnehme, und die bei diesen drei Entwicklertypen besonders ausgeprägt sind. Das wären z.B.:

  • Eine schnelle Auffassungsgabe. Je besser ein Entwickler ist, desto schneller kann er sich meiner Meinung nach in neue Themen und Technologien einarbeiten. Das trifft genauso auf fachliche Inhalte zu.
  • Die Fähigkeit zur Abstraktion von Details, als auch die Konzentration auf Details. Und vor allem dazwischen gut umschalten können.
  • Ein breites technisches Grundwissen. Gute Entwickler schauen über den Horizont. Lernen gerne neue Technologien, beherrschen möglicherweise mehrere Plattformen und Sprachen. Sie kennen sich mit Netzwerken und Protokollen aus, beschäftigen sich vielleicht sogar mit hardwarenahen Dingen.
  • Gute Allgemeinbildung und Interessen, die über ihr eigenes Fach hinausgehen. Viele der guten Entwickler die ich kennenlernen durfte haben breit gefächerte Interessen. Manche sind aktive und engagierte Musiker, wiederum andere arbeiten an gemeinnützigen Projekten mit, sind sportlich sehr aktiv, etc. Sie beschäftigen sich mit dem aktuellen Weltgeschehen, sind politisch informiert, und man kann sie durchaus als aktive Bürger des Landes ansehen.
  • Sie brennen für Ihren Job, sind dort überdurchschnittlich engagiert und arbeiten viel. Vor allem unter den Freelance-Entwicklern in meinem Bekanntenkreis macht keiner eine 40-Stunden Woche… fast alle arbeiten weitaus mehr, nehmen Ihre Arbeit aber nicht als Belastung wahr, sondern lieben sie. Mit Genuss werden hier Blog-Posts, Videos und sonstige Inhalte zu Softwareentwicklung und darüber hinaus verschlungen, ausprobiert, kommentiert und vielleicht sogar in eigenen Posts weiterverarbeitet. Spontane Coding-Sessions mitten in der Nacht nach einem coolen Einfall sind in dieser Gruppe keine Besonderheit. Genauso wie durchgehackte Wochenenden.

Mein Eindruck dieser ganzen Eigenschaften ist, dass sie sich vermutlich gegenseitig bedingen. Wer Spaß an seinem Job hat und auch noch entsprechend mit Anerkennung versehen wird (was bei den meisten Softwareentwicklern der Fall sein könnte, mindestens finanziell) wird vermutlich generell mehr Zeit und Leidenschaft in seinen Job stecken. Vermutlich wird eine solchermaßen engagierte Persönlichkeit egal in welchem Fach herausstechen (sei es nun Softwareentwicklung oder beispielsweise Jura). Zumindest macht dieser Gedankengang für mich Sinn. Aber darüber hinaus kommt bei vielen Entwicklern noch diese beschriebene tiefere intrinsische Motivation hinzu. Dies ist ein Antrieb den ich bei vielen anderen Personen aus meinem Bekanntenkreis nicht finde, die in anderen Berufen und Branchen unterwegs sind. Aber das mag daran liegen, dass ich natürlich in Beruf und Alltag zwangsweise primär mit Softwareentwicklern zu tun habe und dadurch einen gewissen Tunnelblick erleide.

Möchte man alles was ich hier so erzählt habe kurz zusammenfassen, läuft es eigentlich auf drei Dinge hinaus: Einen wachen und offenen Geist, der Interesse an neuem hat. Ein regelmäßiger Blick über den Tellerrand und zuletzt eine starke Identifikation mit der eigenen Tätigkeit die weit über den eher verbreiteten Lohn-und-Brot Ansatz hinaus geht. Lässt man das mal kurz sacken bemerkt man: Fast nix davon hat primär mit hartem technischen Wissen zu tun. Alles mehr oder weniger Soft Skills… Verwundert das wen? Mich ehrlich gesagt nicht.

Sollte diese Erkenntnis fernab meiner persönlichen Meinung auch tatsächlich etwas Wahrheit enthalten, so müsste man daraus vielleicht ableiten, sowohl in der Ausbildung als auch später bei der Einstellung von Mitarbeitern und im Alltag viel mehr darauf zu achten, diese weichen Kriterien zu prüfen und zu vermitteln. Vielleicht sollte es auch schon vor dem Studium eine weitaus bessere Eignungsfeststellung geben. Das würde vermutlich auch die in Informatikstudiengängen immer noch drastische Abbrecher- und Durchfallquote verringern. Ich kann nur allen angehenden und schon berufstätigen Entwicklern empfehlen, sich viel stärker mit solchen Themen auseinanderzusetzen. Es gab auch bei mir einen Punkt während meines Studiums ab dem ist mir dieser Aspekt erst klar geworden. Danach war es ein langsamer und mühsamer Prozess stetigen Lernens. Aber es lohnt sich!

Die Clean Code Initiative ist da ein sehr guter Startpunkt, über die man an die entsprechenden Bücher, Quellen und auch Übungen verwiesen wird. Zumindest das „Clean Code“ Buch von Robert C. Martin und der Nachfolger „The Clean Coder“ sind ein guter Einstieg zur Selbstreflektion. Hoffentlich führen Sie Euch in die richtige Richtung. Viel Spaß beim Lernen!

(15)

Schmaga im Wunderland – Rezertifizierung des MCSD für Web mit der 70-494 Prüfung

Seit einiger Zeit wird von Microsoft ja verlangt, dass man bestimmte Zertifizierungen alle 2 Jahre erneuern muss. Der Microsoft Solution Developer für Web Application ist einer dieser Kandidaten. Ich habe die drei Einzelprüfungen vor einiger Zeit gemacht, und nun stand meine Rezertifizierung an.

Nun gut, Microsoft hatte gerade ein Second Shot Angebot, weswegen ich mich anmeldete und ohne Vorbereitung in die Prüfung ging. Was hatte ich schließlich zu verlieren, und der zweite Versuche wäre ja umsonst? Immerhin setze ich viele der abgefragten Technologien in meinen Projekten fast täglich ein oder habe sie früher oft eingesetzt. Das Wissen muss ja für irgendwas gut sein…

Letztendlich hat es leider nicht gereicht. Ich lag sehr knapp (vermutlich eine Frage, den Punkten nach zu urteilen) daneben, und es erschien am Ende das böse „FAIL“ am Bildschirm.

„OK“ sagte ich mir. „Du hast ja auch überhaupt nicht für die Prüfung gelernt“. Dafür ist so ein knappes Ergebnis ja wirklich akzeptabel. Ich muss dazu sagen, dass mir trotzdem einige der Fragen wirklich wirklich komisch vorkamen.

Gestern habe ich meinen zweiten Versuch gewagt. Ich habe in der Zeit dazwischen wirklich die beiden Prüfungsbücher gründlich durchgearbeitet und weitere Themenrecherche betrieben. Es war eine recht intensive Vorbereitung. Es reichte für *Trommelwirbel*………………… eine absolute Punktlandung. Ich habe genau die Punktzahl erreicht die zum Bestehen nötig war. Was zur Hölle? D.h. vermutlich eine Frage mehr richtig gehabt. Und nachdem mir nun die Fragen teilweise vertraut waren und einige neu, fühle ich mich etwas verarscht. In der Retrospektive hätte ich einiger dieser Fragen nichtmal richtig beantworten können, wenn ich die beiden Bücher dabei gehabt hätte. Leider darf ich Aufgrund der Prüfungs-NDA nicht auf Details eingehen, aber teilweise waren die Teile (selbst die vermeintlich richtigen Antworten) gespickt mit Fehlern. Ich habe selten soviele Kommentare geschrieben. Und wenn es darum geht Konfigurationsdatei-Syntax auswendig zu lernen oder Konfigurationsschritte in Reihenfolge zu sortieren… Da muss ich zugeben weigert sich mein Kopf irgendwie dafür Zeit und Energie aufzuwenden. Macht so etwas einen guten Solution Developer aus? Wenn ja, dann will ich keiner sein.

Mein Fazit: Die Bücher durchzuarbeiten ist nur bedingt sinnvoll und hilft nur bei Teilthemen. Entweder man hat die genutzten Komponenten in den Fragen schon öfter eingesetzt, oder halt Pech. Ich habe noch nie so eine schlecht designte Microsoft Prüfung gemacht. Und es ist bestimmt schon meine zehnte die ich bisher machen durfte/musste, je nachdem wie man es sieht. Evtl. sollte Microsoft einen „I am feeling lucky“ Button in die Prüfungen einbauen lassen…

Ein Jahr Selbstständigkeit – Endlich online

Hallo Welt,

ursprünglich hatte ich geplant diese Website spätestens zum 1.5. zu starten. Sozusagen zum einjährigen Geburtstag meiner Selbstständigkeit. Das hat natürlich nicht geklappt (Warum habe ich das überhaupt geplant?), da ich in Projekten eingebunden war. Aber jetzt ist es endlich soweit und diese Seite ist online.

Ich werde versuchen in der nächsten Zeit auch einige technische Blog Einträge zu schreiben, in der Hoffnung dass die Problemlösungen die ich in meinem Entwickleralltag erzeuge auch für andere interessant sein könnten.

Ich freue mich natürlich auch immer über Feedback zur Seite.

Viele Grüße,
Euer Schmaga