Code-Inside Blog

Durch eine Problemstellung bei Kollegen bin ich auf ein interessantes Thema gestoßen: HTTP Push/Reverse Ajax. Bei einem normalen Einsatz von AJAX schickt der Client (Browser) einen Request zum Server und dieser Antwortet – asynchron natürlich. Doch gibt es eine Möglichkeit dass auch der Server den Client informiert – ohne Polling? Hat jemand bereits in diesem Gebiet (mit .NET “Integration” ) Erfahrung gesammelt?

Weiterlesen »

Es ist sehr wichtig zu wissen, was nach dem Deployment einer Anwendung “im innern” passiert – besonders im Fehlerfall kommt man bei einer Black-Box nicht sehr weit. Dieser Blogpost soll als eine Art Toolsammlung sein, die sich bei uns bewährt haben.

Weiterlesen »

Aufmerksame Leser des Blogs werden gemerkt haben, dass meine Postanzahl im Blog doch etwas nachgelassen hat. Den Grund dafür findet ihr auf http://www.diesachsen.de. In diesem Blogpost möchte ich kurz von der Idee und natürlich auch von der Technik erzählen.

Weiterlesen »

Im letzten Post ging es um SVN als Versionskontrolle und Trac als Projektmanagement & Bugtracking Tool, nun gehen wir einen Schritt weiter und die ganze Sache noch um einen Buildserver erweitern. Dies ermöglicht einige nette Sachen wie z.B. Nightly Builds, mehr Kontrolle & Sicherheit über den eingechecken Source Code bis hin zu automatischen Deployments – willkommen “Continuous Integration“.

Weiterlesen »

Vor einer ganze Weile habe ich über eine Idee geschrieben, die wir eine ganze Weile auch in einem Projekt so verfolgt haben. Ein anderes geniales Konzept, wo ich mir nicht ganz sicher war, war das Exception Handling. Nachdem ich beide Ideen in einem Projekt umgesetzt hatte, kommt jetzt mein Fazit: Keep it simple!

Weiterlesen »

Jede Anwendung basiert auf ein oder mehrere Aktionen, welche zum Teil von verschiedensten Dingen abhängen: Dem User, anderen Systemen, eingegebene Werte etc.

Meist spricht man von einem "Workflow", der in Software umgesetzt werden muss, doch wie bildet man diesen am "effektivsten" ab? If-Else Konstrukte oder "Workflow Engines" wie die Windows Workflow Foundation? Wie steht es mit der Testbarkeit? In diesem Post will ich ein paar Varianten vorstellen, bitte aber wieder ausdrücklich um Feedback, wie ihr dies handhabt.

Weiterlesen »

Usereingaben validieren, durch die Businesslogik schicken, dem Nutzer evtl. Fehler wieder anzeigen – fast jedes System macht sowas, doch wie macht man es "richtig"? Definiert man Errorcodes? Was ist mit Mehrsprachigkeit? In dem Post zeige ich meine Variante und bitte auch um Feedback

Weiterlesen »

Mein letzter direkter “ReadYou” Post ist schon etwas länger her – meine Membership-Idee habe ich in einem HowTo mal verwirklicht, allerdings hatte ich bisher keine Gelegenheit mehr zu coden.

Authentication, Authorization & Personalization
Für mich persönlich war der Kommentar von Andre Loker ein Anstoß darüber nachzudenken, das Membership System komplett zu entfernen bzw. einfach meinen eigenen Provider zu schreiben. Die verschiedenen Tabellen vom Membership-System find ich recht “groß” und unübersichtlich.
Insbesondere passt aber das Membership-System nicht ganz in meine Architektur rein.

Gut, dass nicht nur ich so denke, sondern inzwischen auch Rob Conery zu diesem Ergebnis gekommen ist. Den Anstoß gab Ayende Rahien in dem 15 Teil vom MVC Storefront Screencast.
Inzwischen hat Rob den 16 Teil fertig gestellt – in diesem verwirft er das Membership-System und implementiert prototypisch OpenID.

Hinweis: Meine Anwendung wird stark an die Architektur von Rob angelehnt sein – ich hab dies bereits produktiv in einem Projekt eingesetzt und bin positiv überrascht wie gut dies geklappt hat
Die gesamte MVC Storefront Serie ist sehr sehenswert!

Robs Screencast endet bei dem Login mit OpenID – er erwähnt noch, dass er sich nun auch Gedanken macht, wie er die OpenID tatsächlich an einen User knüpfen kann. Selbe Gedanken beschäftigen mich ebenfalls schon eine Weile (und insbesondere habe ich ja noch den mutigen Vorschlag gehabt Windows Live ID mit zu unterstützen ).

Was es nicht heute alles gibt
Ich muss zugeben, dass ich früher mir nicht so einen großen Kopf um das Usersystem an sich gemacht hatte – da wird das Passwort und ein Loginname vergeben und gut ist.
Allerdings bin ich der Meinung, dass hier einige große Veränderungen kommen – warum sich bei X-Diensten registrieren, wenn man doch z.B. eine OpenID hat.
Auch CardSpace ist eine Sache – Produktiv hab ich das (bis auf den Blog Kim Cameron) nicht gesehen.

Jetzt eine Frage an meine werte Leserschaft: Wer von euch weiß was OAuth ist und was man damit machen kann? So richtig schlau werde ich aus der Seite nicht.

Wo stehen wir momentan?
Momentan beschäftigt mich das Grundkonzept von diesen verschiedenen Diensten etwas – da mir leider da auch TDD nicht weiterhelfen kann, versuche ich mich erstmal zu informieren.
Ein paar interessante Links (neben den MVC Storefront) :

• Add OpenID login support to your ASP.NET MVC site
• Enhancing the ASP.NET MVC OpenID login experience
• MVC Membership – Preview 3
• Identity Toolkit
• DevDefined.OAuth´
• OAuth for Beginners

Das wäre es (leider) für heute erst mal.
Ein Hinweis noch: Mir ist bewusst, dass ich mich doch recht lange an einem doch trivial klingenden Thema aufhalte – allerdings genau wegen solchen Sachen mach ich das ja auch. Wer würde das denn sonst auch bezahlen?

Fast jede Anwendung die heute irgendwie läuft, benötigt ein Login oder man kann bestimmte Profildaten anhäufen etc. Daher ist das Usersystem die erste große Hürde, die es zu überwinden gilt.

Solch ein Usersystem ist prinzipell recht schnell gemacht, allerdings muss das Usersystem laut den Anforderungen auch andere Provider (wie OpenID, Windows Live ID etc.) unterstützen.

Im Mittelpunkt steht der “User” – in dem Fall ein ganz normaler Nutzer unser Applikation. Ein “User” kann mehrere “Identitäten” haben, z.B. eine Windows Live ID, eine OpenID oder auf ein eigenes Login-System setzen. Ob ich das später tatsächlich einbaue ist eine andere Sache, allerdings sollte das System möglichst “offen” sein.

Dann hat natürlich unser “User” “Accountdaten” (also Profildaten etc.) die wir in unserer Applikation brauchen – die könnte man später z.B. über bestimmte Connectoren befüllen – das ist aber nur eine fixe Idee.

Diese Accountdaten werden momentan durch diese recht einfache Userklasse repräsentiert:

Das “Problem” der Zuordnung

Mein selbst festgelegtes Ziel hat natürlich ein Haken: Ein User hat mehrere Identitäten – eine eindeutigen Namen brauch ich also, um genau zu sagen, dass Nutzer A der sich gerade mit seiner Windows Live ID anmeldet auch wirklich Nutzer A ist.
Dafür ist in der User-Klasse der “AccountName” vorgesehen – ein eindeutiger Name der zu beginn vom Nutzer festgelegt wird.
Die “ID” (eine GUID) wird in dem Falle vielleicht nicht mehr benötigt, allerdings könnte ja noch die Anforderunge rein kommen, dass jemand seinen Nutzernamen ändern möchte – daher die “ID“.
Der “IdentificationName” ist der Name, mit dem der User sich gerade angemeldet hat, also wenn er z.B. seine OpenID angegeben hat, steht da “http://user.myopenid.com” da.

Ablauf der Anmeldung / Registrierung

1. User registriert sich mit einer beliebigen Identifikation (”IdentificationName”) und einem Nickname (”AccountName”)
2. User wird im System angelegt und in einer Zuordnungstabelle wird festgehalten, das User A mit der Identifikation A sich anmelden darf.
3. User meldet sich ab.
4. User meldet sich wieder mit seinem “IdentificationName” und dem dazugehörigen Passwort an (seinem OpenID-Passwort z.B.)
5. In der Zuordnungstabelle wird überprüft, ob User X sich mit der ID überhaupt anmelden darf, wenn ja, dann ist er eingeloggt.
6. Wenn er eingeloggt ist, darf er seine Accountdaten weiter pflegen.

Identification-Interface

Momentan ist das Interface noch recht “klein”:

Ein Fall fürs Prototyping

Da ich momentan doch noch recht unsicher über das Design bin, werde ich erstmal ein paar Provider “prototypen”, sodass ich sehen kann, ob es überhaupt so machbar wäre.

Fazit & Feedback

Code gibt es heute leider nicht zu sehen, zwar läuft bereits ein UnitTest erfolgreich durch, allerdings muss mal ein, zwei “richtige” Loginsysteme integrieren um eine schlüssige Aussage machen zu können.

Wie immer gilt: Feedback ist gern gesehen – wenn ihr sagt, dass ich mich hier total irre oder etwas wichtige übersehe, dann nur zu
Ich bemüh mich in dieser Woche ein Login-System auf die Beine zu stellen. Wenn dies erstmal steht schauen wir weiter

Gestern habe ich bei Codeplex ein “ReadYou” Projekt angelegt.
Info am Rande: Die “HowTos” sind allgemeiner gehalten – in der Kategorie “HowToCode” dreht es sich um zusammengesetze spezielle Sachen, wobei ich hier “HowTos” etc. verlinke – so ist jedenfalls momentan meine Vorstellung von diesen beiden Kategorien

Um einen Ãœberblick über die verschiedenen Tätigkeiten bei “ReadYou” zu behalten muss unbedingt eine ToDo Liste her.
Info am Rande: Ich dokumentiere dies Schritt für Schritt – sodass ich dies evtl. später auch mal unseren Azubis vermachen kann, daher auch der “low-level” Einstieg

Ob das Feature auf Codeplex genau so genutzt wird, weiß ich natürlich nicht – da am Ende allerdings ein Team Foundation Server steckt und dort solche ToDos sich (mehr oder weniger komfortabel) als WorkItem wiedergeben lassen, werde ich dies hier auch machen

Codeplex: “Issue Tracker”

Mit dem Tracker kann man sehr leicht WorkItems/Issues/Features anlegen.

Man kann dazu viele Details mit hinzufügen:

Komponenten – Grobstruktur

Codeplex bietet nettes kleines Feld namens “Component”:

Hier können wir unsere Applikation erst mal grob strukturieren:

Genau diese Komponenten legen wir an:

Visual Studio 2008: Team Explorer Integration

Da ich natürlich nicht immer auf die Codeplex Seite die neuen ToDos anlegen möchte, geht dies auch mit dem Team Explorer. Hier sehen wir die selben Input-Felder wie auf der Website (diese Eingabemaske ist vom TFS Projekt Template abhängig) :

Visual Studio 2008: ToDos erstellen

Im ersten Schritt habe ich erstmal meine nächsten Schritte als WorkItem beschrieben:

Wie zu sehen ist, soll erstmal eine Ordnerstruktur her und wir widmen uns gleich zu beginn einem Kernelement: Das User System.

Was haben wir hier gelernt?

Ãœberblick über ein Projekt zu behalten ist nicht ganz einfach – ein ToDo Zettel ist ganz nett, allerdings werden wir später noch herausfinden, was bei diesen WorkItems noch schick ist und warum es sich lohnt, so eine Art Kreislauf einzuhalten:

Schritt 1: Anforderung kommt rein
Ein Kunde (in dem Fall ich) möchte ein bestimmtes Features, z.B. sollen sich User anmelden können usw. (siehe hier).

Schritt 2: Bewerten / Aufwand abschätzen
Der Schritt ist etwas “schwammig” bei mir hier – normalerweise sollte der Entwickler an dieser stelle bereits eine ungefähre Ahnung haben, was da eigentlich gewollt ist und auch eine Ahnung haben, wie lange dies oder jenes dauert. Hier kann auch eine Konzeptionsphase sein (oder sogar sollte )

Schritt 3: In entsprechende WorkItem umwandeln
Wenn das soweit ok geht (und vom Projektleiter abgesegnet wurde etc.) müssen wir die schwammigen Featurebeschreibungen in konkrete ToDos umwandeln.
Es kann auch sein, dass hier gar kein WorkItem abfällt, weil es z.B. kein Code zu schreiben gibt und auch sonst eher eine “administrative Aufgabe” ist.

Schritt 4: Implementieren
Da wir hier nach Test-Driven-Development vorgehen, wird während dieser Phase bereits ausgiebig getestet – jedenfalls wird hier alles eingebaut, was nötig ist um das zu erfüllen was gefordert ist.

Schritt 5: Testen
Hier sollte alles nochmal überprüft werden – nach dieser Phase geht es live!

Schritt 6: Ausliefern & WorkItem schließen
Wenn alles funktioniert, dass Feature fertig implementiert wurde und auch beim Kunden läuft, können wir hier das WorkItem schließen und können uns erstmal zurücklehnen

Da man mit den Unit-Tests in Zusammenhang mit WorkItems was schickes machen kann, wollte ich dies nochmal hervorheben.

Im nächsten Blogpost gibt es also das erste mal direkten Code zu sehen – jedenfalls werden wir das Visual Studio nicht nur zum Managen nehmen, sondern auch zu unserer eigentlichen Aufgabe zurückkehren: Coden!

Da hat sich wohl der Fehlerteufel eingeschlichen – in den letzten beiden Blogposts war immer von “YouRead” die Rede, dabei heisst es eigentlich (jedenfalls ist diese Domain jetzt dafür gedacht “ReadYou“.

Spricht sich auch deutlich einfacher (und der Titel war auch bereits bei dem UI Prototyp zu sehen)

Der Fehler wurde mir bewusst, als ich voller Stolz meiner Freundin berichtet habe, dass ich nun mit “YouRead” angefangen hab.
Naja, Namen sind am Ende auch Schall und Rauch – freuen wir uns also nun auf viele “ReadYou” Blogposts

Der Posttitel klingt schon mal recht hochgegriffen und es ist für mich auch eine Art Experiment und hoffe, dass es (früher oder später) auch Feedback gibt

Was ist “ReadYou”?

Trotz des “Web 2.0″-Zeitalters mag ich immer noch Bücher – seien es Fachbücher oder andere Romane. Da ich allerdings langsam den Ãœberblick verliere und es meiner Freundin ähnlich geht, muss eine Plattform her, wo man solche “Bücherbestände” möglichst cool und einfach managen kann (und natürlich die ganzen anderen Community-Sachen die üblich sind).
ReadYou ist daher momentan mein Projektarbeitstitel – am Ende soll unter www.readyou.de eine kleine, schicke Web 2.0 Anwendung stehen.
Das Thema ist jetzt nicht unbedingt jedermanns Sache, allerdings sind meist die “Grundzüge” einer solchen Applikation immer gleich – um ReadYou mal mit markanten Web 2.0 Schlagwörtern zu beschreiben:

Ganz guten würden zudem noch Blogs in diesen Kontext reinpassen – aber das ist eine andere Geschichte

Aha… was hat das mit uns zutun?

Ich bin ein großer Fan von Rob Conerys MVC Storefront und hab bei seinen Videos einiges gelernt:

• Was ist Dependency Injection und warum ist es so cool?
• Mocking?
• Was versteht man unter TDD und wie setzt man es in der Praxis ein?
• Interessante Architekturgedanken…
• ASP.NET MVC Routes & Stuff
• …

Da ich zumeist noch das Problem bei privaten Projekten hab, dass ich irgendwann die Lust verliere, mach ich es diesmal von Anfang an “offen” für jeden – damit ich es nicht irgendwann auf meiner Platte verliere. Dabei soll nicht nur der Source-Code “offen” sein, sondern auch warum ich diese und jene Entscheidung treffe oder warum ich das Tool nehmen möchte.
Es soll eine m̦glichst professionelle Applikation rauskommen, welche eine m̦glichst robuste Architektur aufweisst, gut getestet ist und auch (das leidige Thema der Entwickler) sogar dokumentiert ist Рalso ein m̦glichst professioneller Ansatz.

Da ich natürlich kein Experte in TDD, Dokumentieren, Toolauswahl, Architektur etc. bin, ist Feedback besonders wichtig

Was soll das bringen?

Am Ende soll möglichst eine Art “Leitfaden” entstehen (die Applikation ist quasi das Nebenprodukt), den Anfänger ebenfalls beschreiten können – und auch verstehen, warum diese und jene Entscheidungen getroffen wurden und auch (was sicherlich passieren wird), dass manche Entscheidungen vielleicht unklug waren.
Es sollte nicht als pure deutsche Kopie von Robs Videos zu sehen sein (ich glaub nicht, dass ich so gute Screencasts überhaupt machen könnte), sondern ein Lernexperiment für jedermann – vergleichbar mit einem größeren HowTo – diesmal “HowTo code ReadYou”

Themen/ToDo´s die ich mir vornehme:

• Welche Anforderungen hat das System:

Anforderungsmanagement ist ein wichtiger Punkt bei einem Software-Projekt. Da ich hier allerdings selber der Kunde bin, werde ich meine Anforderungen und ungefähren Designvorstellungen selber schreiben – Abschätzungen oder ähnliches werden aber nicht gemacht

• Architekturgedanken:

Anhand dieser Anforderungen muss eine entsprechende Architektur entworfen werden – dabei werde ich mir sicherlich die eine oder andere Idee bei Rob nochmal genauer anschauen.

• Source Control & Build:

Als Source Control ist momentan Codeplex meine erste Wahl (TFS Infrastruktur). Hierbei muss ich mal schauen, wie weit man es da treiben kann РStichwort Continuous Integration). Builds sollten m̦glichst automatisch ablaufen k̦nnen Рdaher werde ich mich an dieser Stelle MSBuild widmen. Hier bin ich mir noch etwas unsicher was Codeplex bietet und wie ich das am cleversten anstelle Рaber an dem Punkt bin ich ja noch nicht

• Implementation & Tests:

Ich versuche möglichst mich nach dem TDD Mantra “Test-First” zu richten – sodass eine möglichst robuste Applikation am Ende rauskommt. Auch Themen wie Dependency Injection, MSTest als Testframework, ASP.NET MVC nehm ich mir vor.

• Dokumentation:

Da Source-Code möglichst dokumentiert sein sollte, soll auch hier mal von Anfang an daran gedacht werden – ich probier es mal mit Sandcastle (hier & hier gibt es einen guten “Ãœberblick” über die neusten Versionen)

Feedback

Wie bereits oben erwähnt ist Feedback natürlich sehr wichtig – wenn ich aus eurer Sicht was vergessen hab, ihr das Konzept blöde findet oder was auch immer – (konstruktive) Krtik ist immer gut

Ich hoffe ich kann in den nächsten Tagen die ersten Themen/ToDo´s angehen