.NET Einstellungsfragen, Bullshit Bingo vs. Skills

by admin 6. September 2007 03:17

Miguel de Icaza steuert ein interessantes Post zur "Einstellungstaktiken und Fragen" Debatte bei. Der übliche Prozess ist wohl die Bewerbung durch Vorstellungsgespräche. Miguel de Icaza beschreibt, dass aus seiner Erfahrung Beispiele von bisheriger Arbeit, also Quellcode, zu besseren Ergebnissen führen, als das persönliche Gespräch. Er favorisiert das Email Interview, in dem es eine nicht triviale Aufgabe, innerhalb von zwei Wochen zu lösen gilt. Die Aufgaben sind so gestrickt, das eine Implementierung in ein bis zwei Tagen möglich sein sollte. Der großzügige Zeitrahmen macht es möglich, parallel zu Job oder Studium zu implementieren. Das klingt für mich wie ein großartiger Ansatz. Alles andere scheint das Potential zu haben, sich Leute ins Team zu holen, die zwar Bullshit Bingo beherrschen (von Design Pattern über Agile bis hin zu Best Practice bei der Speicherverwaltung) aber nicht wirklich Implementieren können. Warum auch immer. Nun ließe sich vielleicht bei einem Bewerbungsgespräch ein einfacher Programmiertest durchführen, aber Software-Entwicklung ist nur zu einem geringen Teil etwas, was man in drei Funktionen sehen kann. Viel spannender ist Struktur, Organisation und die Anwendung von Objekt Orientierten Prinzipien. Ich habe zurzeit nur einen kleinen Eindruck vom Job Markt für .NET Entwickler (speziell ASP.NET) wobei ich die vage Vermutung habe, dass mein Lieblingsszenario „sehr viele großartige Entwickler, wenig offene Positionen" nicht wirklich zutreffen dürfte. Einstellungsfragen für .NET Scott Hanselmann ".NET Interview Questions" und hier einige Antworten Einige Interview Fragen von Ayende hier, hier und hier Ein paar (sehr spezifische) ASP.NET Fragen von Mark Wagner Ressourcen für Die Jobsuche (neben google) http://www.dotnetjob.de/ http://entwickler.com/jobs/ http://gulp.de/ http://www.heise.de/jobs http://www.xing.com/ (?) aspnetzone (forum)

Group By + alle Felder

by admin 5. September 2007 03:40

Meist wollen ja immer die selben Probleme gelöst werden. Mein Standard für ein SELECT auf alle Felder einer Tabelle, abhängig von einer Aggregatfunktionen (min, max, avg. etc.) einer zweiten sieht so aus: Ich möchte gerne für alle Requests, das jeweils höchste Gebot (Bid) haben. Das ganze funktioniert, aber ich Suche nach einem einfacheren Weg. Das gleiche nochmal als subselect, wobei wenn ich mich recht erinnere kann z.B mysql keine subselects. Und ich möchte möglichst Datenbankhersteller agnostisch bleiben. Hier nochmal der Execution Plan für beide Abfragen, wobei die Indizies noch nicht optimiert sind. Auf den ersten Blick verwirrend, ist das umschliessende select für die erste Abfrage. Bleibt die Ergebnismenge aber klein, ist das zu vernachlässigen. Und "premature optimization" ist eh der Feind aller Entwickler :-)

Model Driven Architecture (MDA) - contra

by admin 3. September 2007 07:34

Sicherlich ist "Model Driven Architecture" einer der verheißungsvollsten Trends der letzten Jahre. Keinen schmerzhaften CRUD Code schreiben, die Abstraktionsebene auf das eigentliche Problem heben und gelegentlich den „Erstellen“ Button drücken um einen Prototypen zu erzeugen. Das Frontend benötigt dann, zur Projektabgabe nur noch den letzten Feinschliff. So schön die Theorie. Ich muss natürlich gestehen, das alle meine versuche zum Thema bisher rudimentär waren. Ich habe und das ist wirklich schon ein wenig länger her, mit Rational XDE  und „Enterprise Architect“  Klassen generiert. XDE konnte damals (2003) schon „roundtrip engineering“ und hat das Klassen Model in beide Richtungen aktualisiert, also vom Designer Richtung Code und zurück. Gierig habe ich mir auch Microsofts „Domain Specific Language Tools“ angeschaut (die nicht wie der Name vermuten läst DSLs im klassischen Sinne bearbeiten u. erstellen lässt sondern eher in die MDA Tool Kategorie gehört). Alles natürlich keine reinen MDA Tools aber sie decken eine Schnittmenge ab, von dem was ich von einem derartigen Tool erwarten würde. Leider waren alle diese Versuche nur einziges Zeitgrab. Eine Klassendiagram ist nur ein Ausschnitt eines Problems und repräsentiert die Implementierung nur eben ungefähr. Alles andere führt zu einer Informationsexplosion, die das eigentliche Ziel von Uml-Diagrammen, Modellierung und Kommunikation, obsolet werden lässt. Meine zweite Erfahrung war, dass das eigentlich Implementieren in händischer Manier, inkrementell, von Problemfeld zu Problemfeld von Klasse für Klasse zu sauberem Code führte. Das Ergebnis lebt davon, dass Zeit in das Modellieren von Ausschnitten investiert wurde, was zu vielen kleinen, auf die Anforderung angepassten Detail-Lösungen führt. In allen Schichten der Anwendung. Drittens: Für mich die schnellste Form eine Anforderung zu verstehen, ist eine Skizze auf Papier und eine schnelle Implementierung, die auch gern ein Mock-up sein kann. Das führt zu vielen kleinen Iterationen, die Stück zu Stück zu einem runden Ganzen führen. Es gibt die schöne Analogie, die so entstandene, organisch gewachsene Software mit Orten zu vergleichen, die sich um eine Kirche herum scharen, mit vielen kleinen Geschäften. Hingegen MDA generierter Code so ist, wie eine am Reisbrett entworfene Vorstadt, mit eine großen Supermarkt, nebst großem Parkplatz in der Nähe. Ich weiß für meinen Teil wo ich lieber arbeiten und wohnen möchten ;-) Ein oft gehörtes pro MDA Argument ist, das man teuren Architekten das Designen überlassen kann, während billige Standard Coder für das Grobe zuständig sind. Für mich hat dieser Grundansatz schon eine Reihe von Fehlern. Architekten die nicht Coden verlieren an Fähigkeit. Sie programmieren nicht aktiv. Sie können kein Beispiel geben für guten Code. Und viele B-Klasse Coder, das klingt auch nicht wie ein erfolgreiches Dream-Team? Zu all dem muß hinzugefügt werden, das ich ein großer Freund von Code-Generierung bin :-) Was aber erstmal nichts mit MDA gemein hat.

"The Cool Cam" - "European Air War"

by admin 30. August 2007 07:01

Ich habe lange nicht mehr so gelacht; worse than failure (früher "what the fuck") berichtet über eine abstruse Entwicklung, in einem (eigentlich) zum Scheitern verurteilten Software Projekt: "The cool cam". Unglaublich aber anscheinend wahr :-)

DSL (Domain Specific Language) und Fluent-Interface

by admin 18. August 2007 02:44

Ich arbeite gerade an Testmethoden und habe mich über folgenden Code gefreut, weil er ein relativ komplexes Thema ziemlich lesbar gestaltet. Der Test ist natürlich grün :-)    (Clicken für Originalgrösse) Das Setup für die Tests ist mir immer noch einen Tick zu lang und ich werde wohl noch refaktorisieren. Auch werde ich gleich noch ein paar mehr Asserts hinzufügen. Erzeugt werden 8 Angebote mit jeweils 4 und 3 Eigenschaften. Sticker haben hier keinen Preis, sind also kein echtes Angebot aber für den Test reicht das komplett. Die Angebote lassen sich mit einem Einzeiler persistieren. Die Flyer und Sticker Klassen Definition und Helper Klassen werden via XML Configurationsfiles generiert, was auch den Sprach-Mix erklärt. Ursprünglich war das nur gedacht um schnell und einfach Tests schreiben zu können, nun ergeben sich aber noch ein paar andere Vorteile. Das Endprodukt läst sich so relativ flexibel befüllen. Für ein paar 10 000 Produkte braucht es nur wenige Zeilen... Komisch, in den letzten 4 1/2 Wochen habe ich 7100 Zeilen Code (oben sieht man 30 Zeilen ;) fürs das Backend unserers Produktes geschrieben. Nach dem ich die letzten Tage ein wenig panisch geworden bin, vor allen Dingen wegen vager Anforderungen und  Unwissenheit über Zielgruppen und Märkte, scheint sich doch noch alles zusammen zu fügen. Trotzdem steht jetzt erstmal Crunch-Time an. Lets Rock'n Roll :-)

Chaos report - desaster and failure

by admin 2. August 2007 01:47

Die "Standish Group" untersuchte über 40 000 Software-Projekte innerhalb von 10 Jahren. Hier der (gekürzte ;-) "Standish Chaos Report": Software projects: 1995: 16% succeed 31% fail 53% are challenged 2004 29% succeed 18% fail 53% are challenged via "Scott Rosenberg @ google talks" - wenig technisch und immer nett zu hören wenn proklamiert wird, das Software Entwicklung ein hartes Geschäft ist. (Leider) nichts für Mädchen :-) Für den liquiden Interessierten sind die "Standish Group" Reports hier zu kaufen.

Microsoft ist keine Gefahr

by admin 27. July 2007 05:06

Mark Shuttleworth stellt in seinem Post ein paar interessante Dinge fest: durch Microsoft ist Sofware so billig wie nie zuvor Microsoft ist durch Patente genauso angreifbar wie OSS (Open Source Software) Linux ist im Desktopmarkt zu klein um ein lohnenswertes Ziel zu sein Die Feststellungen sind aus dem Kontext gezerrt. In dem Post dreht es sich um Patentrecht um dessen Akteure, sowie mögliche Bedroher für Linux (GNU/Linux;-).

Projektplanung und Schwangerschaft

by admin 8. July 2007 00:20

"9 Frauen und 1 Monat machen kein Baby" :-) Das ist die köstlich, ironische Zusammenfassung der Erfahrung, dass das Hinzufügen von Ressourcen nicht zwangsläufig zu einem schnelleren Projektende führt. Wobei wenn Projektplaner so genau wären wie Geburtstermin-Ermittler, wäre die Software-Industrie verändert. Das Terminermittlungsproblem ist jedoch nicht Software spezifisch. Regelmäßig höre ich von Bauvorhaben, die ihr ursprüngliches Kostenvolumen um ein vielfaches überschreiten. Zum Beispiel wurde der Berliner Hauptbahnhof für 700 Mio projektiert und kostete dann 1 Mrd Euro. Wobei noch 200 Mio Euro gespart wurden, in dem Teile weggelassen wurden. Genau genommen erscheint es mir so, als ob das nicht halten können von Zeitplänen und Terminen Alltag in fast allen Bereichen der Gesellschaft ist. Es hilft wohl nur sich damit zu arrangieren und immer wenn das Thema Zeitplanung Relevant wird, auch für Ungenauigkeit zu planen - durch bessere Verträge und finanzielle Reserven.Und hey, ist Risiko nicht Teil eines jeden Geschäfts und wenn alles detailiert planbar wäre, würde sich dann nicht langweile breit machen? Doch auch hier hilft viel nicht viel, das ist bei Risiken nicht anders und so ist gute, gekonnte Planung wesentlich für Risikovermeidung. 9 Risiken machen kein erfolgreiches Geschäft.

Michael Arrington von Techcrunch.com über Start-Ups

by admin 4. July 2007 21:42

Auf der "The Future of Web Apps" Konferenz, auf der unter anderem auch Jeffrey Veen von Google, Kevin Rose von digg, Cal Henderson von Flickr und Tom Coates von Yahoo sprachen, hielt auch der Gründer und hauptsächliche Schreiber von techcrunch.com, Michael Arrington, einen Vortrag. Techcrunch.com Heute als Guru für Web Applikationen bekannt, geliebt und gefürchtet, ging Michael Arrington seinem Hobby nach, über Start-Ups von Web Applikationen zu schreiben und startete die Seite techcrunch.com. Heute verfügt sein blog über atemberaubende 430.000 Abonennten und ist maßgeblich an dem Erfolg oder Misserfolg von neuen Web Applikationen beteiligt. Da Arrington sich 15 Stunden am Tag mit Web Applikationen beschäftigt, sollte sich da einiges an Know-How angesammelt haben, was den Erfolg oder Misserfolg von Applikationen anbelangt. Wie macht man es richtig? Das wohl zentralste Kriterium für eine erfolgreiche Web Applikation, so Arrington, sei, ob sie herausrage. Das klingt einfach, was jedoch dahinter steckt ist der Umstand, dass es nicht reicht, eine gute Anwendung zu bauen (oder gar nachzubauen), die unter funktionalen und ästethischen Gesichtspunkt bestehen kann. Der Standard, dass man seinen Beruf lieben muss, fehlt auch bei Arrington nicht, wobei ich denke, dass es für das Web noch viel eher gilt, als für "normale" Geschäfte, da die Konkurenz tatsächlich global ist. Ein tatsächlich guter Tipp für eine Applikation ist, "Reibung im Prozess zu minimieren". Wenn deine Applikation Arbeit verringert, Abläufe vereinfacht, Zeit und Geld spart, wird sie sich sicher durchsetzen. Was sind typische Fehler? Arrington berichtet von überfinanzierten Applikationen, zu großen Versprechungen, die nicht eingehalten werden können, features, die keinen Sinn ergeben (squidoo.com). Er empfiehlt darüber hinaus, möglichst klein anzufangen, nicht überzufinanzieren und zu schauen, wie sich das Unternehmen entwickelt. Auch auf der persönlichen Ebene gibt es genug Bespiele, dass Start-Ups auseinanderbrechen, weil das Team sich zerstritten hat. Die Anforderung, stets ein funktionierende Einkommens-Modell zu haben, hinterfragt Arrington: youtube.com als wohl erfolgreichster Vertreter dieser Gruppe. Fazit "Wenn du glaubst, du kannst flickr schlagen, dann tu es!" ;) "The Future of Web Apps" Neben Michael Arringtons Rede gibt es auf der Seite zu dem Kongress noch andere hörenswerte Beiträge zum Thema Web Applikationen, Start-Ups, Iteration, Software-Entwicklung, Features, etc. Definitiv lohnenswert. andrej.

Web Designer/Developer und Usability Experte?

by admin 25. June 2007 20:06

In seinem heute auf useit.com veröffentlichten Artikel schreibt usability-Guru Jakob Nielson, ob es sinnvoll sei, Web Designer und Developern auch usability-Tasks zu übertragen. Der Begriff "Usability" ist seit einiger Zeit ein Schlagwort der Web-Welot geworden, hat aber leider kein treffendes Äquivalent im Deutschen und bezieht sich im Wesentlichen auf Benutzerfreundllichkeit einer Web-Seite. Pros Als Hauptargumente für die Zusammenlegung der Arbeitsbereiche führt Nielson an, dass zum einen Arbeitskraft eingespart werden könne und andererseits die Glaubwürdigkeit erhöht würde, da derjenige der das Design/die Applikation erstellt auch gleichzeitig sich um deren usability kümmert. Cons Dagegen hält er, dass Spezialisten stets bessere Ergebnisse liefern und auf der anderen Seite die Objektivität im Einschätzen der eigenen Tätigkeit zu wünschen übrig. Da sich die Design/Developer-Vrogaben gegenüber den Usability-Vorgaben durchsetzen können. Fazit Es ist von massivem Vorteil, wenn man sich als Developer und Web Designer mit zumindest den Grundlagen von Usability auseinandersetzt, da man konzeptionell Dinge anders anpackt und durchdenkt. Zwar ist ein finales Überprüfen durch einen Spezialisten sicherlich eine gute Investition, jedoch denke ich gilt auch hier die 80/20-Regel. Der Spezialist wird im Fine-Tuning das ein oder andere Detail anpassen können, wenn jedoch die Applikation oder Web Seite von Grund auf nicht funktioniert, wird er dies nicht mehr richten können. Weiterführendes zu Usability (auf Englisch homepage von Jakob NielsonUsability-Forum hallwaytesting.com Leitfäden zu Usability und Accessebility "Dont' Make me Think" (link zu Amazon.de) - sehr lesenswertes Buch von Steven Krug

About Oliver

shades-of-orange.com code blog logo I build web applications using ASP.NET and have a passion for javascript. Enjoy MVC and Orchard CMS, and I do TDD whenever I can. I like clean code. Love to spend time with my wife and our three children. My profile on Stack Exchange, a network of free, community-driven Q&A sites

About Anton

shades-of-orange.com code blog logo I'm a software developer at teamaton. I code in C# and work with MVC, Orchard, SpecFlow, Coypu and NHibernate. I enjoy beach volleyball, board games and Coke.