Daniel Brüßler
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
 | | Inhaltsverzeichnis dieser Seite | | Kontakt |
| Meine "Linksammlung" zum DseWiki |
| Content Management Systeme |
| TYPO3 |
| und andere Informations-Systeme |
| Groupware |
| Verknüpfung von Wissen |
| Software-Entwicklung für große, komplexe Projekte |
| Projekt-Management, Vergleichbarkeit, Team, Meetings |
| "normal" contra agil -- Teams, Qualität, Maturity, Kunde, Chaos-Theorie |
| Design Pattern |
| Mit Risiken umgehen |
| Stabilität, Qualität |
| Kosten |
| Requirements, Kundenfeedback, Spezifikationen |
| Aspekt-orientierte Programmierung |
| Deklarative Programmierung |
| Philosophie dahinter |
| Zitat von Martin Fowler |
|
|
|
Kontakt  |  |
Hi!
Ich bin auch Software-Entwickler und seit einiger Zeit hier im Wiki vertreten. Hier interessieren mich hauptsächlich Patterns, Software-Test und Java. Manchmal bin ich typischer Vertreter der Nerds.
Kurze Info
- Bis 2004 studierte ich Wirtschafts-Informatik in Nürnberg
- seit Juli 2004 bin ich Freelancer für Content Management Systeme.
- seit Anfang 2008 bin ich Leiter des TYPO3 Doc-Teams, kümmere mich also nicht nur um das TYPO3-Wiki (
http://wiki.typo3.org) sondern nun auch um das Team an manual-Autoren und manual-Übersetzern. Es macht sehr viel Freude :-)
Kontakt: http://www.danielbruessler.de TYPO3 und Java - Freelancer
das DseWiki ist so riesig, man braucht sowas einfach
| Content Management Systeme | |
Siehe auch InformationArchitecture
| TYPO3 | |
Ich kümmere mich seit 2002 darum, dass Typo3 in der Wiki-Welt vertreten ist. Da es sehr gute Ressourcen gibt - also Diskussionsforen, Newsgroups, Extension-Sammlung - braucht es lediglich Links zu den entsprechenden Stellen zu geben. Es wird also doch kein eigenständiges Wiki, wie zuerst vermutet ;-)
| und andere Informations-Systeme | |
Mit dem ContentManagementSystem TYPO3 wird ContentManagement betrieben. Durch Extensions ist dessen Funktionalität stark (und leicht!) erweiterbar. Spätestens durch den Einsatz der geeigneten Extension ist damit auch WissensManagement beziehungsweise beziehungsweise KnowledgeManagement möglich. Interessant ist dabei auch die Information Architecture. There is are some english speaking Wiki-Pages about Sharing Knowledge: 
MeatBall:InformationArchitecture, Wiki:InformationArchitect, PyWiki:PersonalKnowledge
Da es sich absolut anbietet WikiAlsDokumentationsTool einzusetzen, müssen die noch existierenden Probleme gelöst werden. Aber vielleicht ist es erst soweit, wenn XML die Basis von Webseiten geworden ist. Denn dann können Diagramme - zum Beispiel UML - und Vektor-Grafiken wirklich mittels SVG leicht per Browser editiert werden. Bis dahin sind lokal-installierte Tools aber effizienter. Es geht aber schon los: Denn im MoinMoin wird in einer der nächsten Version SVG-Icons zur Navigation benutzt. Und ein SVG-Wiki (siehe DasRichtigeWiki) gibt es auch schon. Bin gespannt, wann es Wikis gibt, die mitten durch einen Wiki-Text SVG-Grafiken erzeugen ;-)
Standards wie XML und RDF helfen dabei Wissen zu strukturieren.
| Groupware | |
Ein WikiWiki gehört zu dieser Kategorie. Allerdings läuft es nur gut, wenn es mindestens 80..100 Seiten, und ein genügend großes, lebendiges Team gibt. Da es eine ganze Menge an Wikis gibt, ist es eine Teil-Aufgabe des MeatBall-Wikis eine aktuelle InterWiki-Liste zu veröffentlichen. Das MoinMoin-Master-Wiki zum Beispiel nutzt diese Liste. Wenn man ein neues Themengebiet beginnen möchte, bietet es sich an DasRichtigeWiki zu wählen.
Eine persönliche Unterhaltung ist schöner, wenn man sie im selben Raum führt, aber Wissen kann man wohl am besten schriftlich teilen.
| Verknüpfung von Wissen | |
Da ich inzwischen festgestellt habe, dass die Verknüpfung von Wikis per InterWiki-Link so seine Problemchen hat, interessieren mich MeatBall, DasRichtigeWiki und die Idee der TourBusHaltestelle als Teil einer Bus-Route. Die Fahrpläne stehen hier: MeatBall:TourBusMap (Oktober 2002: 6 Busse)
InterWiki-Links werden leider sehr selten gesetzt. Warum nur? Es gibt wohl zwei Haupt-Gründe: Zum einen kennt man die Seiten anderer Wikis kaum. Und dann kann es passieren, dass die Seite des anderen Wikis umbenannt wird. Und dann geht der Link leider ins Leere. Sehr wichtige Seite: DasRichtigeWiki
| Software-Entwicklung für große, komplexe Projekte | |
Siehe auch CVS.
| Projekt-Management, Vergleichbarkeit, Team, Meetings | |
Ohne gutes ProjektManagement geht ein Projekt in die Hose. Heutzutage werden an SoftwareEntwicklung und Software-Test hohe Ansprüche gestellt. Deswegen müssen Standard-Komponenten genutzt, und die Entwicklungs-Prozesse gut sein. Durch das CapabilityMaturityModel ist eine Vergleichbarkeit von Prozessen möglich geworden. Allerdings muss man hierbei aufpassen, dass die Arbeitsabläufe nun nicht starr und statisch werden. Ein Team kann zielgerichtet arbeiten, wenn es einen ProjektPlan gibt und regelmäßig StandUpMeetings gemacht werden um sich auszutauschen.
| "normal" contra agil -- Teams, Qualität, Maturity, Kunde, Chaos-Theorie | |
Teams, die gut aufeinander abgestimmt sind ("eingeschworene Teams"), können ihre Systeme nach statischen oder nach dynamischen Prozessen erstellen. Ein statischer Standard-Prozess ist RationalUnifiedProcess?, seine Qualität ist durch ein CapabilityMaturityModel messbar. Bietet sich an, wenn ein FestpreisVertrag gefordert wird und wenn die SoftwareRequirements? (RequirementManagement) von Projekt zu Projekt wenig voneinander abweichen. -- Oder sie verwenden einen dynamischen Prozess, also AgileSoftwareEntwicklung. Bekanntester Vertreter ist das ExtremeProgramming. Nachteil ist, dass kein FestpreisVertrag möglich ist. Aber der große Vorteil ist die hervorragende Einbindung des Kunden-Feedbacks in die Entwicklung des Systems. Und das wird immer mehr entscheidend sein, um den Bedürfnissen des Kunden gerecht werden zu können. Seit Mitte der 90 Jahre (die "Chaos Studie" der Standish Group http://www.standishgroup.com/sample_research/chaos_1994_1.php) rechnet man einer Änderung (ChangeManagement?) der Requirements (RequirementManagement) von 4% pro Jahr. Dabei ist dieser Wert für Internet/ Intranet-Projekte wesentlich höher. Die Schlüsselfaktoren "The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements" (Standish Group) erfolgreicher Projekte werden durch die Agile-Methoden zum großen Teil erreicht. -- (Siehe auch FürWelcheProjekteIstXpNichtGeeignet/Projektgröße).
| Design Pattern | |
SoftwarePatterns
| Mit Risiken umgehen | |
Risiken müssen gemanaged werden. Sehr interessant dazu ist MeineSchätzungWirdStimmen.
Schön finde ich dazu das Konzept vom Ex-Aldi-Manager (="Mut zum Verzicht") und die Gedanken von Dürrenmatt. Im Anhang zu "Physiker" heißt es: "Planmäßig vorgehende Menschen wollen ein bestimmtes Ziel erreichen. Der Zufall trifft sie am schlimmsten, wenn sie durch ihn das Gegenteil ihres Ziels erreichen: Das, was sie befürchten, was sie zu vermeiden suchen."
Da im Projekt natürlich Krisen entstehen, weil Risiken nicht oder nicht passend im Griff sind, braucht man ProblemLösungsTechniken. Interessanterweise helfen manche Erkenntnisse aus der Chaos-Theorie.
| Stabilität, Qualität | |
Um eine höhere Stabilität der Software zu ermöglichen, können Entwickler unter anderem Assertions (=Zusicherungen) einsetzen. Siehe IstAssertSinnvoll/UndWieWeitSollEsGetriebenWerden.
| Kosten | |
Um das Total-cost-of-ownership minimieren zu können kann man unter anderem GemeinsameVerantwortlichkeit fördern. Denn dann hängen Wissen und Zuständigkeit nicht an einem einzigen Mitarbeiter.
| Requirements, Kundenfeedback, Spezifikationen | |
Wenn ein Kunde AnforderungsGeschichten schreibt, dann ist man schon mitten drin im XP.
| Aspekt-orientierte Programmierung | |
AspektOrientierteProgrammierung ist eine relativ neue Herangehensweise an komplexe Software. Hauptziel ist es die Wartbarkeit des Codes zu erleichtern.
| Deklarative Programmierung | |
DeklarativeProgrammierung setzt Compiler voraus, die kleine Teilprobleme selbst "lösen" können. Der Programmierer beschreibt das Problem nun "nur" noch in einer "Extensible Application Markup Language". Hauptziel ist eine effizientere Programmierung.
| Philosophie dahinter | |
Eher für SoftwareArchitekt?en interessant: 3-Weltentheorie von KarlPopper
| Zitat von Martin Fowler | |
(übersetzt) "... Ich bin nun aber ein ziemlich fauler Mensch und immer bereit, hart zu arbeiten, um Arbeit zu vermeiden. ..."
KategorieHomePage
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 26. Oktober 2008 18:38 (diff))