Archives
-
Of edges and vertices - another stab at reaching a more systematic view of software
I keep hearing, services (as in SOA) are about edges. If that´s the case, what are these edges connecting? There are no edges without vertices.
-
Building an associative (data)base - or: The Pile thinking applied
Ok, finally - after another digression on Pile fundamentals (and I guess, more needs to be said, but not right now) - I´ll quickly describe my prototype implementation of a Pile engine as well as a Pile agent/client to use it for searching in plain text files.
-
Folding the informational space - or: How Pile lets you transcend hierarchies of data
After some philosophical digressions now on to "More matter, less art" as Hamlet´s mother says. Lets step up the ladder of abstraction and look at how to put the elementary particle, those associations, to some tangible use. How about implementing a little full text search application? That´s what I did to check my understanding of Pile. Although there exists such an application at pileworks.org, I thought it would help me more to try to build it myself instead of just studying existing code.
-
Data is just an abstraction of associations - or: A philosophical interlude
In my previouse posting I´ve described the Pile view of the "world of data": focus on associations, not data. Todays I wanted to put meat on this theoretical skelleton and show you code I wrote. But first let me insert a little philosophical deviation. It might help to distinguish Pile from other (more or less novel) approaches to "data management" - and either draw more fire from the RDBMS camp or drive them off altogether :-) We´ll see...
-
Beyond WinFS - Let associations rule! - or: An introduction to Pile for mere mortals
Yesterday I wrote about why I think WinFS is a step forward - but in the end will not really solve the problem of the penned up data. WinFS´ data units (the objects, e.g. contacts, appointments and what not) simply are still too coarse grained. And even though WinFS puts relations between data units (or entities) more into the center of the stage, it is still bound by the general world view of "data is most important". However, as long as data is in the focus, associations between data are second. And as long as associations are second, we´ll have a hard time to map the multi contextuality of real world entities to software.
-
Musings on relations - or: WinFS is not enough
Have you had a look at WinFS? No, you should. It´s cool. Or maybe I should say: It could be even more cool, if it didn´t stop too early.
-
Gute Laune durch 'Computerbücher ins Altpapier'
Es ist so angenehm und doch so selten, dass ich auf einen Text im Web stoße, der mir einfach so spontan gute Laune macht. Aber jetzt ist es doch wieder passiert. Peter Braun hat seinem Unmut über den Zustand der Computer-Fachliteratur in einem Kolumnenbeitrag mit dem Titel 'Computerbücher ins Altpapier' im Dr. Web Magazin Luft gemacht. Und das ebenso direkt wie herzerfrischend.
-
Drei Herren mit guter Laune
Warum haben diese drei Herren so gute Laune? Hm... Sie stoßen auf etwas an, aber was...?
-
Storing Relations revisted - The hanging trees of Pile
-
Storing Relations Instead of Data - Just a cool idea or a revolutionary new data storage paradigm?
Well, this idea of storing relations instead of data sounded very interesting - even though I did not fully understand it. And I guess, I still do not fully understand it - but Peter Krieg got me hooked. I´m always open for unusual cool new ideas, and this seems to be one. Later that day he did a keynote titled "When Powerpoint meets Doom" where he tried to explain the idea to a larger audience. Reactions where mixed, but I immediately ran out to get his book "Die paranoide Maschine - Computer zwischen Wahn und Sinn". (Sorry, this book is only available in German; but nevertheless I can recommend it for his quite refreshing view on what computers are and how they need to change, if we want them to become more "intelligent".)
-
Defining Components - A pragmatic look at software building blocks
Yesterday I argued, we´re really living in the decade of the component - and not in the good old objects or service hype days. Also I sketched out what I think is necessary to arrive at true software building blocks as the next higher level of abstraction above objects/classes: Contract First Design (CFD) and Microkernel based architecture.
-
The Decade of the Component - Service orientation is just the beginning
I guess, before I start my day, I need to get this out of my system: You know what´s happening right now? It´s the decade of the component! The 1970/80ies were the decade of structured programming, the 1990ies were the decade of object orientation - and now we´re right in the middle of the decade of component orientation.
-
The discourses go on: Ingo Rammer and I talk about designing interfaces between services
Listening to a discussion often offers a new view on a subject, because hearing contrasting thoughts next to each other sparks your own thoughts in a different way than reading a just an article explaining some subject. That´s why thinktecture now publishes its second email discourse on an software architectural topic.
-
On the right number of methods, classes or DLLs in a project - or: Just cut a few and it will be perfect
Udi Dahan did a posting on a question he received from a developer the other day: The developer asked him, why Udi was so much in favor of so many DLLs in a project? Wouldn´t the large number of DLLs make the project unnecessarily complicated?
-
Meeting a "hero" of my youth: Prof. Niklaus Wirth
Today was a surprising and very happy day for me: Scheduled to talk at the iX Conference - Better Software - in Colone, Germany, I was invited to participate in the panel discussion on "Software development - art or engineering dicipline" for Tom DeMarco, who had to leave the conference early. The topic was fun, although in the end we were mostly discussing whether there still was a software crisis or not and what its characteristics might be.
-
A new slant on Desktop Search: search engine and disk drive united
For those who demanded an English posting when I wrote my last blog entry here´s a link you can follow to explore Suchwerk - an interessting tool which somewhat combines Google´s desktop search and Windows Explorer´s file search. Suchwerk (German, could be translated to something like "search factory") is a virtual drive which allows you to organize file in a virtual hierarchy of folders. The folders contents are dynamic and you don´t need to explicitly put files into them. It´s done automatically by Suchwerk according to a query you implicitly specify by creating the folder hierarchy.
-
Desktop Search einmal anders: Suchmaschine und Laufwerk in einem
Bin gerade auf www.suchwerk.net gestoßen. Eine interessante Technologie!
-
Die BASTA! kommt... Neue Entwickler-Roadshow - Thema diesmal: Softwarearchitektur
Für alle Freunde der BASTA!-Entwicklerkonferenz und natürlich auch Entwickler, die die BASTA! noch nicht kennen, gibt es eine gute Nachricht: Die BASTA! kommt zu Ihnen nach Hause - oder zumindest in Ihre Nähe.
-
Das war echt cool - Der 1. Lehmanns Programmier Contest ist gelaufen
Das war Community pur, würde ich sagen: Der 1. Lehmanns Programmier Contest hat 16 Teams mit mehr als 25 Softwareentwickler über 6 Stunden gefesselt. Wer hätte das gedacht? Bei allem Optimismus, den ich als Mitinitiator und Mitglied der Jury hatte, habe ich mir doch nicht träumen lassen, dass so eine tolle Atmosphäre enstehen würde.
-
Publikation im OBJEKTspektrum Nr. 5 9-10/2005: Softwarezellen - Ein Architekturmodell für Software in Netzwerken
Softwarezellen – Ein Architekturmodell für Software in Netzwerken
-
Live Programmierwettbewerb - .NET meets Java
Am Samstag 17.9. um 18h richtet die Fachbuchhandlungskette Lehmanns (www.lob.de) einen Programmierwettbewerb anlässlich der Jubiläen von .NET und Java in diesem Jahr aus.
-
Locker vom Hocker - thinktecture veröffentlicht Email-Plaudereien zu technologischen Themen
Einen "üblichen" technischen Artikel zu schreiben und zu lesen, ist eine Sache.
Eine andere ist es, technologische Themen in einem Gespräch zu behandeln und einem Hin und Her von Argumenten und Meinungen zu folgen. -
Publikationen in der dotnetpro 9/2005
"Spicken nicht erlaubt - Contract First Design und Microkernel-Frameworks", S. 124: Beschreibung eines IoC/Microkernel-Frameworks zur Realisierung einer dynamischen Bindung von Komponenten zur Laufzeit.
-
Warum ist Wikipedia ein Erfolg? - Gedanken zur "Funktionsweise" von Kollaborationsprojekten im Internet
Angeregt durch eine Diskussion in einer dotnetpro-Newsgroup hier ein Versuch der Erklärung, warum Open Source und Wikipedia und einige andere Projekte funktionieren. Denn nur wenn man eine Idee davon hat, warum eine Sache funktioniert, kann man abschätzen, ob eine andere, vermeintlich ähnliche Sache auch funktionieren könnte.Ich schmeiße mal Folgendes in einen Topf:-Wikipedia - Ein online Lexikon, bei dem jeder Beitrag von jedem Interessierten eingestellt und modifiziert werden kann.-Open Source im Web - Softwareprojekte, bei denen im Grunde auch jeder Kundige einen Beitrag leisten kann, indem er die frei verfügbaren Sourcen ergänzt und modifiziert. (Dass das nur eine Untermenge aller OS Projekte ist, ist mir klar.)-Napster, Gnutella & Co - Musiktauschbörsen, bei denen jeder Musikdateien anbieten und runterladen kann.-Newsgroups - Diskussionsforen, bei denen jeder Fragen einstellen und beantworten kann.-Projekt Gutenberg - Sammlung copyright freier TexteAlle diese Projekte wurden durch das Internet ermöglicht. Denn nur das Internet erlaubt die dafür nötige einfache Publikation (Erzeugung von Inhalt, Veröffentlichung, einfache Aktualisierung und einfachen Zugang). Die Produktions und Verteilungshürde traditioneller Medien ist mit dem Internet aus dem Weg geräumt. Damit haben Verlage (und Druckereien) einen Teil ihrer Existenzgrundlage verloren.Aber nicht nur ist die Produktion und Verteilung an sich mit dem Internet plötzlich einfach, darüber hinaus können die Publikationen ständig im Fluss bleiben. Dieselbe Publikation kann dauernder Revision unterliegen. Wenn dagegen ein Buch erstmal gedruckt ist, ist es unveränderlich.Diese grundsätzliche Modifizierbarkeit und die beliebige Granularität (von Softwareprojekte mit tausenden Dateienü über eBooks oder Musikstücke mit einer Datei bis zu einzelnen Sätzen innerhalb einer HTML-Seite) der Änderungen machen Kollaborationsprojekte wie die obigen möglich. Es können überhaupt jetzt erst viele zusammen kommen, um an einem großen Ganzen zu arbeiten.Das ist wie mit den kleinen Steinpyramiden, die man beim Wandern in den Bergen immer mal wieder sieht: jeder, der vorbeikommt, kann einen Stein dazu legen, wenn er will. Über die Zeit wächst dann ein Haufen, der anderen anzeigt, dass sie noch auf dem richtigen Weg sind. Viele kleine Beiträge formen also zusammen etwas Größeres und zudem nützliches. (Schon hierbei ist ein Charakteristikum zu sehen, dass für alle solche Projekte gilt: nur wenige tragen dazu bei, aber viele, viele nutzen es. Die Zahl derjenigen, die ein Musikstück über Napster herunterladen oder eine OS Software nutzen oder einen Wikipedia-Beitrag lesen ist immer um 10erpotenzen größer als die derjenigen, die ein Musikstück bereitstellen, eine Änderung an OS Software machen oder einen Beitrag schreiben. Dieses "free riding" kann ein Problem werden, wenn die Zahl der Produzenten unter einen kritischen Prozentsatz fällt. Dann "lebt" das Gesamtprodukt nicht genügend und bleibt/wird unattraktiv.)Zwischenstand:-Wikipedia, Napster, viele OS Projekte im Web (aber nicht alle) und Newsgroups sind Produkte (weil sie produziert werden, nicht weil sie Geld kosten), die nur durch das Internet möglich sind.-Alle diese Produkte sind Kollaborationsprojekte, zu denen immer viel weniger Produzenten gehören im Verhältnis zu den Nutzern.-Alle diese Produkte sind kostenlos für die Nutzer.Warum haben manche dieser Produkte so großen Erfolg und manche nicht? Das hängt wohl von einer kritischen Menge an Nutzen ab. Und die wiederum hängt von einer kritischen Masse an Nutzern (und Aufmerksamkeit) ab. Wikipedia war ja nicht immer erfolgreich, sondern hat klein angefangen. Aber aus irgendwelchen Gründen bot Wikipedia irgendwann soviel Nutzen, dass immer mehr Leute es wertvoll und empfehlenswert fanden. Damit stieg dann auch ganz natürlich die Zahl der Kontributoren, die mit ihrer Arbeit den Nutzen erhöht haben usw. usf. Eine positive Spirale.Nicht jedes OS Projekt kommt an diesen Punkt, wo das Interesse einen Sprung macht und eine positive Spirale aus "mehr Beiträge - mehr Interesse - noch mehr Beiträge - noch mehr Interesse" in Gang gesetzt wird.Die Newsgroups der dotnetpro sind dafür ein Beispiel. Sie haben keine kritische Masse an Beiträgen, also interessieren sich die Leser nicht sehr dafür, also steigt die Menge der Beiträge auch nicht stark. Um das zu ändern, müsste wahrscheinlich großer Aufwand getrieben werden. Aber es könnte auch zufällig einfach passieren. Warum die kritische Masse sich nach Erscheinen der dotnetpro nicht in den ersten Monaten eingestellt hat...? Keine Ahnung. Die Lebendigkeit der NGs der BasicPro konnte jedenfalls nicht einfach übernommen werden.Aber zurück zu Wikipedia & Co:Die Masterfrage lautet, warum überhaupt für diese kostenlosen Produkte Beiträge kostenlos produziert werden?Warum stellt jmd ein Musikstück bei Napster zur Verfügung? Warum schreibt jmd eine Antwort auf eine Frage in einer NG? Warum korrigiert jmd. einen Beitrag in Wikipedia?a. Der erste Teil der Antwort muss lauten: weil diese Produzenten den Wert des Produktes erhalten wollen. Produzenten sind also zunächst einmal Nutzer. So wie ein Bauer sein Feld bestellt, so "beackern" Produzenten ihre Kollaborationsprojekte. Sie wissen, nur wenn gesät wird, kann man am Ende auch ernten. Insofern handeln sie eigennützig und nicht altruistisch.b. Über die Erhaltung des Wertes eines Produktes hinaus treibt Produzenten aber sicher auch oft an, dass sie sich mit einem Beitrag ein gutes Gefühl verschaffen können. Sie freuen sich, wenn sie merken, dass ihr Beitrag wertgeschätzt wird. Insofern handeln sie eigennützig und auch nicht altruistisch.c. Und nicht zuletzt empfinden Produzenten bestimmt auch oft eine intrinsische Freude beim beitragen. Es macht ihnen unabhängig vom Gesamtnutzen und eventueller Ehre einfach Spaß, etwas zu produzieren. Sie tüfteln gern oder schreiben gern oder beschäftigen sich gern mit einem Thema. Auch in dieser Hinsicht handeln Produzenten eigennützig und nicht altruistisch.d. Für einige Projekte mag dann noch eine ideologische Komponente hinzukommen. Die Produzenten wollen mit ihren Beiträge eine Idee unterstützen. Der Wert des Produktes liegt dann nicht nur in seinem konkreten Nutzen, sondern in seiner puren Existenz als Ausdruck der Idee. Solche Ideen sind "Nur mit Open Source kann sichere Software produziert werden" oder "Nieder mit dem Kartell der Musikindustrie" oder "Informationen muss für alle immer kostenlos zugänglich sein, damit die Welt ein besserer Ort wird". Ob Beiträge, wenn man sie auf dieser Ebene betrachtet, altruistisch sind oder auch letztlich nur eigennützig, mag ich an dieser Stelle nicht entscheiden. Darüber lässt sich trefflich philosophieren.Alles in allem sind das plausible Gründe, würde ich sagen, warum Menschen an solchen Kollaborationsprojekten teilnehmen. Wikipedia & Co wohnt also keine Magie inne. Vielmehr sind Wikipedia & Co nur neue Betätigungsfelder - möglich gemacht durch das Internet - für Verhalten, dass schon immer da war:zu a.: Peter ist Mitglied bei der Freiwilligen Feuerwehr, weil er versteht, dass der Nutzen (gelöschte Brände) für ihn (und alle anderen) nur erhalten bleibt, wenn er sich an seiner Produktion beteiligt. Das Gleiche gilt für Bärbel, wenn Sie alljährlich mitmacht beim Frühjahrsputz des Tennisgeländes; denn nur so bleibt der Verein attraktiv und es macht Spaß, im Sommer auf einem schönen Platz zu spielen.zu b.: Monika geht wöchentlich einmal auf die Kinderstation im Krankenhaus und liest dort vor. Es erfüllt sie mit Freude, die fröhlichen Kindergesichter bei ihren Lesungen zu sehen. Fred ist Vorsitzender des lokalen Kunstvereins. Er organisiert Ausstellungen und ist stolz, wenn anschließend die Mitglieder zu ihm kommen und ihm für seine gute Arbeit danken.zu c.: Monika und Fred und auch Peter macht ihre Arbeit einfach auch Spaß. Peter liebt den Umgang mit dem Feuerwehrgerät und den Adrenalinstoß, wenn es zum Einsatz geht (es sei denn, der Einsatz ist nachts um 3h). Nur Bärbel putzt den Tennisplatz nicht wirklich gerne.zu d.: Monika ist natürlich auch der Ansicht, dass die Welt ein besserer Ort ist, wenn Kinder lachen und weniger einsam im Krankenhaus sind. Und Rolf engagiert sich für Greenpeace und steht bei Regen am Infotisch in der Fußgängerzone. Er ist fest davon überzeugt, dass die Welt verändert werden muss, damit sie eine Zukunft hat. Er hat keinen unmittelbaren Nutzen von seiner Arbeit, die unmittelbare Anerkennung fehlt meist auch (denn die meisten Passanten ignorieren ihn), Spaß macht es keinen, im Regen zu stehen und immer wieder mit Betonköpfen zu diskutieren, die nicht verstehen, dass Atomkraft nie wieder kommen darf. Aber er weiß, er arbeitet für ein wichtiges Großes Ganzes.Also: Wikipedia & Co sind zwar neue Betätigungsfelder - aber die Motivationen sind uralt.Für eine Beurteilung der Erfolgsaussichten neuer Kollaborationsprojekte stellt sich nun die Frage, was all diese Produkte gemeinsam haben?Sie haben alle einen Nutzen, sie erfüllen alle ein sachliches Bedürfnis und bieten darüber hinaus ein Betätigungsfeld für Menschen, die sich durch a., b., c. oder d. motiviert fühlen.Aber das reicht noch nicht. Das erklärt nämlich noch nicht, warum Menschen sich dort ohne monetäre Vergütung einbringen.Warum tun Menschen das? War verschenken sie ihre Leistung?Die Antwort ist einfach: Weil niemand ihre Leistung bezahlen würde. Niemand kann oder will ihre Leistung kaufen. Dafür gibt es viele Gründe, z.B.-Es ist kein Geld vorhanden. (Die Gemeinde kann sich eine Berufsfeuerwehr nicht leisten. Das Krankenhaus kann sich eine Vorleserin nicht leisten.)-Unklarheit bzgl. der Kompetenz des Produzenten. (Ist Stefan kompetent, etwas über das Thema xyz zu sagen? Selbst wenn er es objektiv nicht ist, sondern nur meint es zu sein, kann er einen Beitrag zu Wikipedia leisten - obwohl ihn die Brockhaus-Redaktion abgelehnt hätte.)-Unklarheit über das Potenzial eines Produktes. (Ist Musik im Internet erfolgsversprechend? Wie groß ist das Potenzial im Vergleich zu CDs? Wenn das unsicher ist, lassen Musikverlage die Finger davon - aber Enthusiasten können durch Investition von Zeit trotzdem dieses Potenzial ausloten.)-Der Wert eines Beitrags ist klein und es existiert kein Bezahlungsmodell dafür. (Wie sollte die dotnetpro einen Newsgroupsbeitrag vergüten? Ist er das auch wirklich wert?)Den Erfolg der kostenlosen Kollaborationsprodukte im Internet macht also aus, dass es keine Alternative zu ihnen gibt. Ich kann mein Wissen zum Thema xyz niemandem verkaufen - und antworte daher in der NG oder schreibe einen Wikipedia-Beitrag (denn ich bin ja durch a., b. oder c. oder gar d. motiviert). Ich arbeite tagsüber mit Clipper an Geschäftsanwendungen, weil das lukrativ ist - aber abends kann ich meine Kompetenz als C++ Programmierer in einem Open Source Projekt einbringen. Ich stelle gerippte Musik ins Web, weil ich es der Musikindustrie zeigen will - eine Alternative habe ich nicht, denn für ungesetzliche Handlungen gibt es eigentlich kein Honorar.Kostenlose Beiträge sind kostenlos, weil ihre Produzenten - aus welchen Gründen auch immer, subjektiv oder objektiv - keine Alternative haben. Sie sind stark motiviert, kennen aber keinen Abnehmer für ihre Motivation, der ihre Arbeit auch noch vergüten würde. Denn selbstverständlich wäre es jedem Produzenten lieber, er würde für seinen Aufwand Geld bekommen. Denn diese Form der Anerkennung kann er an anderer Stelle gegen etwa anderes eintauschen, z.B. eine Stereoanlage oder einen Urlaub oder ein Buch.(Eine besondere Gruppe stellen jedoch Produzenten dar, die durch d. motiviert sind. Bei ihnen mag es "gegen die Ehre" verstoßen, Geld für ihre Leistung zu empfangen. Oder echte Bezahlung verstieße sogar gegen die Ideologie, die hinter dem Produkt steht.)Was bedeutet das für zukünftige Kollaborationsprojekte?Ich denke, es haben nur kostenlose Kollaborationsprojekte eine Chance, die entweder...-vor allem von Menschen getrieben werden, die ideologisch motiviert sind (und deren Ideologie am besten auch noch anti-monetär ist)-und/oder deren Beiträge nur schwer oder gar nicht an anderer Stelle gegen Bezahlung geleistet werden können. -
Die Macht des Biergartens - Microsoft ohne Berührungsängste
Es ist schon beeindruckend, was ein bayerischer Biergarten so alles bewirken kann:
-
Publikation: Contract First Design für jedermann
Contract First Design für Jedermann – Klare Abmachungen als Grundlage komponentenorientierter Programmierung, Computerworld, Schweiz
-
Moving to SOA is like switching from Newtonian physics to relativistic physics
I just read an article ("Dealing with the 'Melted Cheese Effect'" by Maarten Mullender in collaboration with my fellow thinktect Christian Weyer) on how to prepare for change in SOA architectures. Although the article itself does not contain many new insights - however it´s the start of an interesting looking series - of course it tackles an important problem: How can you replace the moving parts in a machine running 24x7? We´ll see, what Maarten has to say about that in his future postings.
-
Bücherflohmarkt - ADO.NET, Extreme Programming und mehr
Meine Fachbücherregale haben es einfach nicht mehr gepackt. Als es auch mit zweireihiger Anordnung und Übereinanderlegen nicht mehr ging, musste ich jetzt schweren Herzens aussortieren. Hier eine erste Auswahl der aussortierten Bücher. Angegeben ist der Preis und die Rubrik, wo sie bei Amazon als second hand Titel zu finden sind:
-
Software Cells #F: Adding Culture to the Software Universe - Making the Platform Visible in the Holarchy
In the meantime I had the chance to apply the Software Universe as well as Software Cells to customer problems and wrote an article on Software Cells. Also a friend working at BEA used it to simplify his message for their ESB Quicksilver product.
-
Kennen Sie VauBekien? Wenn Sie VB-Entwickler sind, dann ist das Land eine Reise wert...
Endlich ist es soweit: Uwe Baumann von Microsoft und ich haben unsere langersehnte Bildungsreise in das ferne und bald so nahe Vaubekien angetreten.
Wir wollen für Sie erkunden, was Visual Basic .NET als Programmiersprache zu bieten hat. Was ist anders im Vergleich zu VB6?
Und vor allem: Wie wird VB2005 mit dem .NET Framework 2.0 in Visual Studio 2005 aussehen? -
Publikationen in dotnetpro 7-8/05
dotnetpro.tv Interview zum Thema "O/R Mapping" mit Mirko Matytschak, der sein Tool NDO vorstellt.
-
Software Cells #E: Splitting the General Software Architecture Framework from the Prescriptive Model and Coming to Terms with UML
After I did my previous posting on the "Big Picture", I felt qualms as to whether my vision was a little bit too grant. Does the world really need my view on software? Isn´t there already UML covering almost everything you need to know in terms of modelling software? After having slept bad for a couple of nights ;-) the following answer came to me: Yes, trying to stuff everything into just one model is too much. And I´m not trying to replace UML; in fact UML can be used to express my Software Cells´ concepts.
-
Neuer dotnetpro.tv Tipp #3 online - Autogrammkarten zu gewinnen
Ich hatte ganz vergessen es zu erwähnen: Seit einiger Zeit ist auch wieder ein neuer dotnetpro.tv Tipp online:
-
Software Cells #D: A Big Picture of Software Architecture and: The Network is the Computer
With my previous postings on the holarchy of the Software Cells model, on how software layers fit in, and what to do with infrastructural concerns in place, I guess it´s time for a little wrap-up.
-
Software Cells #C: Connections refined
Ok, with software layers finally embraced and infrastructure integrated, I can no longer avoid the tricky topic of connections in the Software Cells model. I´d say they are the hardest and maybe the most important part of the picture.
-
Software Cells #B: Keeping the Essence of Software Layers
After I had written my previous posting about the Software Cell dimensions I kinda felt a little bit ashamed for my software layer bashing ;-) So what I now want to try is get back on board all those who left in dismay. Here´s my message for you:
-
Software Cells #A: Embracing Infrastructure
At the beginning of my journey into Software Cells was an uneasyness about the term "application". It seemed, developers were not all too clear about it. Now, as it turns out, I feel the same about "infrastructure". My impression is, in software projects distinguish not enough between problem domain and infrastructure. By that I don´t mean, nobody takes into account a HTTP like IIS is needed to host the code of an intranet application. And of course all developers are aware they have to rely on an OS or even some other runtime.
-
Publikation: "Trends: Industrialisierung der Softwareentwicklung" in OBJEKTspektrum 3/05
"Softwareentwicklung geschieht zunehmend in einem Spannungsfeld zwischen Zeitdruck und Technologieflut. Um unter diesen Umständen verlässlich höhere Qualität zu produzieren, müssen sich Menschen und Prozesse verändern."
-
Software Cells #9: Applications as Holons - Becoming a little more systematic
Software Cells started out in the concrete and tried to make small to medium scale software architecture more tangible. Software Cells thus were a bottom-up approach.
-
Publikationen in dotnetpro 6/05
"Am Anfang war der Vertrag: Contract First Design und Microkernel-Frameworks", dotnetpro 6/05
-
Publikation: "Spezialiserung tut Not" in IT-Freelancer Magazin Mai/2005
"Spezialisierung tut Not", S. 34 in IT-Freelancer Mai 2005: Zur Notwendigkeit der Spezialisierung der Kenntnisse und Fertigkeiten für Softwareentwickler. Ein Artikel in der Linie meiner Argumentation von "On the Future of Software Development".
-
Previous Publications / Bisherige Publikationen
A (yet incomplete) list of my publications until April/May 2005. All other publications will be listet as individual posting.
Contract First and Microkernel applied - Report from a recent workshop
Finally I find time to blog about a recent workshop I did with 12 developers in Austria and where I applied Microkernels in a training.
Software Cells #8: Of Customer Problem Domain and Infrastructure - Mind the Dimension
After I put Software Cells into perspective with other architectural models, several people approached me with the question "Now, then, what are Software Cells for?" followed with some problem scenario. And I can tell you, those scenarios made me sweat for a while ;-) But I want to spare you the details and focus on my findings while trying to put Software Cells to good use on those problems.
Software Cells #7: Putting Software Layers et al. into Perspective
In my previous posting I added the missing pieces to the Software Cell puzzle: communication technologies like .NET Remoting, MSMQ, but also ADO.NET. Now you know all the basic structures of any software:
Software Cells #6: Connecting Applications
In my last posting I tried to put Software Cells into perspective. And as it turned out, they prefectly fill a gap that existed between COP/OOP and SOA. With Software Cells we can seamlessly stack levels of abstraction onto each other from single statement to groups of Solutions which I call Software Societies.
First Impression: Meeting Google´s Craig Silverstein
Lately there has been some discussion on if and how Google might be a threat to Microsoft. Bill Gates even said "[they] kicked our butts". Right now I´m not interested in the details of where exactly Microsoft feels hurt and if Google can do substantial damage to Microsoft´s position. Rather, what now surprises me is the surprise everybody felt when Google came out with desktop search functionality and Google maps etc. I´m surprised about this, because I just met with Craig Silverstein, Google´s director of technology and first employee of Google - or Google´s man behind the curtain (as some call him).
Software Cells #5: A journey through the software universe from single statement to Software Societies
So, where are we with Software Cells? In my last posting I talked about Contract First design, and I guess, we now need to tie together the various bits and pieces.
We need to talk about how to connect Software Cells. For that it´s beneficial, to put Software Cells into perspective. So let´s first vary the scale of our software map. Let´s get on a journey thru the "software universe"! What can we see, if we look thru a microsope? What can we see, if you look thru a telescope?Software Cells #4: Contracts everywhere
In my last posting I drilled down into the details of a Software Cells. We looked at the substructures of the Core, the Adapters and the Portals. But altough I think, those substructures make much sense and should be taken as a guidance when designing an Application, I´m very open for deviations and different ideas. Should a User Portal always implement the MVC pattern? I´d say, yes, try to map your problem to MVC, start out with MVC - but if it does not match your specific problem, then do the User Portal some other way. Most important is to see the User Portal as a separate entity from Core, Adapters and Application Portal. The same goes for other structures of a Software Cell.
Software Cells #3: Drilling down into the cell structures
Now that I have explained the basic structure of Software Cells I need to drill down into the details of its structures. What´s the design of a Core, of Adapters and Portals?
Software Cells #2: Basic structures
In my last posting I introduced the term Software Cell to describe a software application. The minimally necessary ingrediences - a Host and my code to solve a problem (logic) - just looked like an organic cell once I drew some pictures of applications consisting of a Host EXE that contains some assemblies.
Why I´m in love with applications as host-code-combinations: Software Cells #1
If you´re still sceptical and don´t believe the proposed definition of software applications as a combination of a host plus my problem solving code has any merit over the so far diffuse usage of the term "application", maybe I can convince you to rethink your position with a couple of pictures?
Aristole and the definition of software applications
Somehow I cannot publish two comments I received for my proposal for a stricted definition of the term "application", so I´m publishing them this way with my comments:
Proposal for a more precise definition of the term "application"
I´ve given the question I posed "What is an application?" some more thought. Martin Lercher made a good point, when he wrote "deployed set of executable code, infrastructure and data such that this set is minimal" for a given purpose. And Ingo Rammer surely explains it like I would have some time ago by saying, an application is "whatever is contained in one single Visual Studio SLN file." Microsoft surely likes him for that, too :-) But still... there remains a feeling of uneasyness in me with those explanations. For one, I strongly believe, non-trivial applications (or software based solutions) should not be developed within a single VS solution. And then, Ingo says: "A certain solution - or system - however might easily consist of several applications." That means, when I set out to solve a problem and tell the customer "Hey, I´m gonna develop a nice application for you." I might be wrong? I might end up producing several applications? If that´s the case - and I believe it is - then we should define the term "application" much stricter.
Simple question: What is an Application? But is the answer equally simple?
Maybe I´m naive or dumb, but the more I think about it, the less I know what an "application" - an application in software development - is. Can you help me? Who can give me a simple answer?
.NET lacks support for Microkernel architectures
In yesterdays post I bemoaned VS.NET constraining how we develop software. Now, that I´ve thought about this a little bit more, I came to the conclusion, what I´m looking for is support for Microkernel architectures.
Microkernels (although primarily known from the OS world) are a general architecture pattern. They allow a software to be extended without recompilation/relinking.
However, the CLR primarily supports static binding with dynamic loading. Assemblies get dynamically loaded when needed, but you need to statically reference them from your project.
Of course, the CLR also allows dynamic binding by loading assemblies by hand and using Activator.CreateInstance(). But these features are not tight together into a dedicated infrastructure to set up Microkernel architectures. For example there is no concept of a "registry" for implementations of interfaces by which you could instanciate implementations indirectly thus decoupling client and service.
To reach new levels in parallel/independent development and decoupling of components, though, we must move to "Contract First" design for intra-application "boundaries". (The SOA world has recognized this already for inter-application boundaries. See Christian Weyer´s postings on his tool for Web Service Contract First programming as an example.) Currently, the services of a component are (mostly) implicitly described/determined by its implementation, the actual assembly we are referencing.
But what we need, is an independet explicit description (a formal interface definition) against which we programm. And which only at runtime is dynamically linked to an implementation.
This of course entails changes in how we test/integrate our applications. But it also allows for many improvements in the process of application development from design to maintenance.
VS.NET constrains the application development process
Have you ever pondered the current practice of referencing assemblies from within a VS.NET project? I haven´t much until recently. I just took this way of linking to code for granted. It´s how we do dynamic linking today. Great!
Or isn´t it?
No, I don´t think it´s that great. I think it limits our thinking on how we develop software. It is just one way to link components together at runtime.
What´s limiting in referencing assemblies is that it binds the component under development to a certain implementation of other components. Isn´t that, what we want, you might ask? Yes, sure, that´s what we need and want for components that already exist (lets call them libraries) while we develop our own component.
When I work on my component, I need the services of libraries like the .NET Fx DLLs or the assembly of my favorite DataGrid. Those libraries exist prior to my project, their interfaces are set, their implementation is complete. So, sure, I should be able to include their services into my component by setting a reference to them, thereby importing not only their meta data, but also later on during runtim loading concrete assemblies.
But when I want to do real component based development (CBD), then I consequentially want to divide my own application up into several modules/components. These components will be developed by several programmers in parallel. This will often lead to situations where a developer working on component A needs component B - which is still under development. But this scenario is not well supported by VS.NET or the .NET Fx.
I cannot reference an assembly that does not exist yet. So what should I do in my project? There are several ways out of this dilemma. The one chosen most often is not to develop components at all. Next comes building huge solutions with many, many projects in them. Both ways sooner or later lead to tight coupling between components and thus thwart the vision of CBD.
But there is a third way: I could define interfaces for components first and put them in a separate assembly. This assembly I could readly reference in my component A project. I´d then know how to use component B thru its interface IB. Great!
Or isn´t it?
Yes, a very good idea - but no well supported by VS.NET and the .NET Fx. Because this way entails you need to discover the implementation of the interfaces you bind to during runtime. Currently there is no way to accomplish that. You can´t pass an interface type to Activator.CreateInstance() and ask it to instanciate an unknown class implementing that interface.
But that´s what´s necessary if you truely want to decouple a client component A from the implementation of some interface IB. Because during development of A you might use mock-up component BMockup which implements IB. But later on a client´s system BMockup has to be replaced by BFinal. Or maybe you want to try different implementations of IB, e.g. BStrategy1 and BStrategy2. How do you bind to those different implementations during development? Not at all, because they don´t exist.
That´s what I mean, when I state, VS.NET contrains the development process. VS.NET and the .NET Fx are targeted towards developing applications where all implementations are well known during development time. It supports well bottom-up development. But it does not support well parallel, independet development. We still need to come up with additional infrastructure to overcome these limitations. We need to build our own Contract First tools for intra application interfaces between components.
Microsoft´s CSCop: Unfortunately not reality
I have to admit, yesterday´s posting on Microsoft´s olfactoric tool Code Smell Cop (CSCop) was an April Fools Day joke. But still... I´d like to see tool support for more than our eye and ear senses. What about tactile feedback while programming, e.g. depending on amount of code in a method or class or assembly?
Microsoft unveils new refactoring tool: CSCop
According to the German .NET developer magazine dotnetpro, Microsoft has shown a prototype of its new CSCop refactoring tool at CeBit 2005 (read full article here (in German)).
CSCop stands for Code Smell Cop and is developed by Microsoft Research. CSCop analyses .NET code (C#, VB.NET, and also IL) and - based on modern AI technologies like Bayesian networks - assesses if it needs refactoring.
This alone is already revolutionary since Kent Beck and Martin Fowler in Fowler`s book "Refactoring" stated, they could not give any hard criteria to determine the "unstructuredness" of code.
But Microsoft has not only solved this problem through merciless analysis of its own code base. In addition to this, Microsoft developed a completely new olfactoric user interface! CSCop flags code which needs refactoring by producing smells.
Kent Beck coined the term "code smell" and Microsoft took this to heart to develop a user interface orthogonal to the common visual GUI. When viewing "bad code" in VS.NET 2005 with the CSCop stick attached to the USB port, the developer will soon smell a unique stench characterizing the kind of "misstructure" he´s looking at.
According to Microsoft´s Steve Eson (lead developer of CSCop) it was quite difficult to find a set of "base smells" to mix all the necessary nuances of code smell from. Another challenge was to find a way to make the smells not too "sticky" but nonetheless be able to provide a characteristic smell for a whole application. CSCop currently is in beta 1.
We´ll see, if developers will embrace a tool which makes code structure quality so obvious to anybody entering their cubicles.
On the Future of Software Development #4 – The need for specialization
In my previous postings I talked about two perceptions: 1. I don´t see any real signs that make our trade of software development singular and hard to compare to other industries. 2. The rate of change in our industry has increased very much in the past 10 to 20 years and makes it impossible to keep up our attitude of allround programmers.
On the Future of Software Development #3 – Feel the heat!
Ok, so now that any “attitude” is out of our way (see my previous posting for details), we can start to look at what is the real challenge for programmers today.
On the Future of Software Development #2 – We are not so special
Let me start my reasoning about how the people-side of the future of software development might look like with two perceptions that form the basis of my argumentation.
On the Future of Software Development #1
Motivated by I a conversation with Steve Cook, one of the fathers of the Software Factory concept ([1], [2]), I´d like to share some thoughts with you about the future of software development. However, contrary to what you might be thinking now, I don´t want to speculate much about the next versions of the .NET Framework or how virtual shared memory could help to solve interop problems or the benefits of Intentional Programming.
An introduction to using O/R Mapping in .NET programs: Adventures in VOA Land #1
Are you looking for information on how it feels like, when you use an O/R Mapping tool in your .NET applications in general? How - if at all? - does the programming model change? What is it like to live without DataAdapters and DataSets?
Termine der INETA Vortragstour zum Thema O/R Mapping
Halbzeit! Mit meinem Vortrag vor der .NET User Group in München am gestrigen Abend habe ich die Hälfte meiner Vorträge gehalten.
INETA UG Tour Vortrag zum Thema O/R Mapping
Die Powerpoint-Slides und den Beispielcode zum Vortrag über O/R Mapping mit Versant Open Access können Interessen hier herunterladen.
Neuer dotnetpro.tv Programmiertipp online: Textimport mit RegEx leicht gemacht
Wer noch ein wenig am Wiedereinstieg in die Arbeit zum Jahresanfang zu knabbern hat, für den gibt es jetzt ein jahreszeitlich stimmungsvolles Video aus der Serie dotnetpro.tv Tipp.
Dieses Mal löst die Sekretärin des Projektleiters das Problem eines Datenimports aus Textdateien.
Wo ihr Schatzi sich mit String-Funktionen die Zähne ausbeißt, kann sie durch den Einsatz von Regulären Ausdrücken kein Problem entdecken.
Wie das sein kann? Sehen Sie selbst bei der dotnetpro - und den Quellcode des Beispiels können Sie auch herunterladen.
Ich wünsche allen Freunden des .NET Framework ein frohes, neues Jahr!
Lassen Sie mich gern wieder wissen, wie Ihnen dotnetpro.tv gefallen hat.
Demnächst kommt auch das nächste Interview auf der dotnetpro Heft-CD heraus.