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 :)
