Artikel von Ralf Westphal
Als Abonnent haben Sie vollen Zugriff auf alle Artikel im Archiv.
Zum Download eines Artikels und/oder der zugehörigen Quelltexte, klicken Sie
den gewünschten Artikel einfach an.
(
dotnetpro 08/2007,
Seite 81)
Vor Kurzem habe ich einige Vorträge auf der Software Architect
2007 Konferenz in London gehalten, aber auch
Zeit gefunden, ein paar Sessions anzuhören. Seit meinem
Studium interessiert mich das Thema Programmiersprachen.
Somit lag es nahe, eine Session über Domain Specific
Languages (DSL) zu besuchen.
(
dotnetpro 05/2007,
Seite 138)
Natürlich soll Code funktional korrekt sein. Aber darüber hinaus soll er auch nicht manipulierbar
sein, beim Kunden nachvollziehbar laufen, wenig Mühe beim Deployment machen, historisiert
sein und automatisch produziert werden. Also geht es im letzten Teil der kleinen Serie zum
Thema Komponentenorientierung um solche Dinge wie Strong Names, Instrumentierung und
Tracing, Versionsverwaltung und Build-Prozesse.
(
dotnetpro 04/2007,
Seite 47)
Wieder so ein Vortrag, bei dem Ihre ganze Aufmerksamkeit auf den Kampf mit dem Schlaf gerichtet ist.
So unterfordert Sie der Referent. Oder andersherum: Sie sind frustriert, weil der Referent ein Überflieger ist
und Sie schon lange abgehängt hat.
(
dotnetpro 04/2007,
Seite 96)
Die Aufgabe war, die Beispielanwendung dnpMelodie [1] nach Mono zu portieren. Das Ziel war, zu zeigen, dass eine Portierung dann besonders einfach ist, wenn man schon beim Entwurf der Anwendung systematisch komponentenorientiert gedacht hat. Doch dann kam alles anders.
(
dotnetpro 03/2007,
Seite 71)
Was sind „ausgezeichnete Kenntnisse in ASP.NET“?
Oder was bedeuten „fundierte Kenntnisse in der .NET-basierten Entwicklung mit C#“? Oder was macht den Besitz von „überdurchschnittliche[r] Kommunikationsfähigkeit” aus?
(
dotnetpro 01/2007,
Seite 61)
Niemand kann mehr alle softwaretechnischen Werkzeuge und Materialien beherrschen, die für die Programmierung
in einer Problemdomäne relevant sein könnten. Die Zahl der Optionen steigt, das Feld wird immer unübersichtlicher.
(
dotnetpro 01/2007,
Seite 40)
Als Windows-Nutzer entwickeln und testen wir wie selbstverständlich mit dem meistverbreiteten Betriebssystem.
Auch bei unseren Kunden finden sich zum allergrößten Teil homogene Windows-Umgebungen – auf unsere Empfehlung
natürlich. Selbst mobile Geräte werden von uns mit Windows-Programmen bestückt. Also alles in Ordnung?
(
dotnetpro 07/2006,
Seite 46)
Im Laufe eines Arbeitstages alle Aufgaben sofort und ohne die Hilfe anderer zu erledigen ist heute für viele nicht mehr möglich. Stattdessen tauschen sie Informationen zwischen Anwendungen aus, senden Teilergebnisse per E-Mail an den nächsten Sachbearbeiter und verlassen sich auf E-Mail-Programme und Organizer wie Outlook, um bei Verzug entsprechend zu reagieren.
(
dotnetpro 06/2006,
Seite 124)
Software komponentenorientiert entwerfen ohne Angst vor Komplexität – wer würde das nicht gerne? Softwarezellen, Contract First Design und Microkernel-Architektur bilden hierfür eine gute Grundlage. dotnetpro zeigt ihre Umsetzung in der Praxis.
(
dotnetpro 06/2006,
Seite 50)
Jeder quasselt, aber keiner versteht ein Wort. So stellt sich die Situation momentan dar, wenn Softwarekomponenten miteinander reden sollen. Eine Vielzahl an möglichen Protokollen und Technologien macht Kommunikation möglich, aber schwierig.
(
dotnetpro 05/2006,
Seite 112)
Wünsche werden wahr
Am Anfang steht eine Liste der Features, die sich der Kunde für seine Software wünscht. Dann gilt es, diese Features in Code zu transformieren und die Implementierung einzelner Features zu testen. dotnetpro zeigt, wie Sie schrittweise zum fertigen Softwareprodukt gelangen.
(
dotnetpro 03/2006,
Seite 126)
Der Weg von der Idee zum Softwarecode ist von Unsicherheit geprägt. Die Struktur von Soft ware scheint immer wieder neu und unvorhersehbar – und somit problematisch. Das altgediente Schichtmodell, das hier Ordnung schaffen will, kann das Bedürfnis der Entwickler nach Klarheit nicht mehr befriedigen. Softwarezellen lösen das Problem.
(
dotnetpro 03/2006,
Seite 65)
In letzter Zeit befasse ich mich verstärkt mit dem Thema Softwarearchitektur, wie Sie vielleicht an der Ausrichtung meiner Artikel in der dotnetpro bemerkt haben. Immer wichtiger wird dabei für mich der Begriff der Komponente. Wenn Softwareprojekte planbarer, flexibler und wartbarer werden sollen, dann müssen sie viel mehr aus „Bauteilen“ zusammengesetzt werden, so wie es in anderen Industrien schon lange Usus ist. Das geschieht aber nicht wirklich. Warum?
(
dotnetpro 02/2006,
Seite 77)
In meiner ersten Sandbox vor zirka einem Jahr mit dem Titel „Weniger Kunst“ habe ich dafür plädiert, das Programmieren aus der Ecke der Künstler und Handwerker herauszuholen und zu industrialisieren. Mehr Systematik muss einkehren,
Entwurf und Produktion arbeitsteiliger werden. Nur damit kann die Branche ihren Ruf als „Bananenlieferant“, dessen Produkte erst beim Kunden reifen, nicht abschütteln.
(
dotnetpro 02/2006,
Seite 60)
Es war das Jahr 1968, als der Begriff der „Softwarekrise“ geprägt wurde: Die meisten Entwickler waren damals damit beschäftigt, bestehende Software zu warten, und neue Projekte wurden – wenn überhaupt – meist viel zu spät und zu teuer fertig gestellt.
(
dotnetpro 12/2005,
Seite 141)
Haben Sie schon einmal den „Pepsi-Test“ gemacht? Sie erinnern sich: Pepsi hatte in den 1980ern Coca-Cola den Kampf mit einem Geschmackstest angesagt. Unbescholtenen Bürgern wurden zwei ungekennzeichnete Cola- Getränke angeboten, um deren „Qualität“ quasi „wissenschaftlich korrekt“ bestimmen zu lassen. Tatsächlich waren die Blindtests gestellt und Pepsi ging als Sieger daraus hervor. Hat sich Pepsi Cola am Markt klar gegen Coca-Cola durchsetzen
können? Nein. Aber warum nicht, wenn doch der Qualitätsbeweis in tausenden „Studien“ so klar erbracht wurde? Die Ursache liegt in der Fragestellung: Pepsi hatte den falschen Test gemacht: „Welches Cola-Getränk schmeckt besser, wenn man nur einen Schluck nimmt?“ Die Fehlannahme war,
dass Konsumente ein Cola-Getränk nach der Ein-Schluck- Qualität aussuchen. Zum Verkaufserfolg von Cola-Getränken gehören jedoch mehr Faktoren.
(
dotnetpro 11/2005,
Seite 124)
Aufbau eines Spam-Filter-Frameworks
Ein effektives Spam-Erkennungsverfahrens ist das Herzstück eines Spam-Filters. In dotnetpro 10/2005 wurde ein Körper entworfen, der dieses Zentrum aufnimmt. Der Spam-gequälte Ralf Westphal beleuchtet in dieser Ausgabe Implementationsentscheidungen als Beispiele für Best Practices, Trade-Offs und Missverständnisse, wie sie in allen Softwareprojekten vorkommen.
(
dotnetpro 10/2005,
Seite 134)
Ein Framework für einen Anti-Spam-Filter.
Spam ist eine Plage, da gibt es keine zwei Meinungen. Aber wie der Spam-Flut Herr werden? Das Angebot an Filtern ist groß. Nur ihre Effektivität ist unterschiedlich. Warum also nicht gleich selbst Hand anlegen und einen maßgeschneiderten Spam-Filter bauen? Dabei lässt sich einiges über Softwarearchitektur lernen – und am Ende sogar etwas gewinnen!