Perfektes Softwareprojekt

Projektidee
Das Projekt trägt den Namen „Moosic“. Dabei handelt es sich um eine Wortschöpfung, die aus den Wörtern „Music“ und „Mood“ entstanden ist. Es handelt sich dabei um ein Programm, welches Musik aus der Umgebung oder einer dedizierten Quelle (Soundkarte) analysiert und dazu passende Farben generiert und/oder Bilder anzeigt.

Code License
Moosic wird unter der GPL entwickelt (GNU General Public License)

Code Headers
Moosic – Displays the mood to your tunes

Copyright © 2009 Stefan Matyba

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, see http://www.gnu.org/licenses/.


Requirements-Engineering
Für das RE wird ein eigenes Tool verwendet/entwickelt, welches allerdings nicht in Java/Eclipse, sondern in C#/Visual Studio 2008 entwickelt wird. Auch dieses wird SE-Techniken und Tools unterworfen.


Analyse

Unternehmensziele
Zielgruppe ist das musikbasierte Entertainment-Business. Ziel des Projekts ist es, Künstler dieser Sparte mit visuellen Effekten bei ihrer Arbeit zu unterstützen.

Marktanalyse
Bisher ist kein entsprechendes (freies) Programm bekannt. Ein potentieller Abnehmer ist vorhanden.

Qualitätskonzept
Da Moosic vor allem bei Live-Auftritten von Musikern zum Einsatz kommen soll, muss es eine sehr hohe Ausfallsicherheit bieten. Nichtkritische Fehlermeldungen dürfen den Programmablauf nicht stören bzw. müssen gänzlich unsichtbar sein.

Versionskontrolle
Zur Versionskontrolle wird auf SVN gesetzt.

Build-Management
Als BM-System kommt Ant zum Einsatz.

Continuous Integration
CruiseControl, JUnit

Code Coverage
Noch unentschlossen

Bug Tracking
BugZilla

Code Quality
Unentschlossen, maybe Sonar, XRadar, SonarJ

Ubuntu 9.04 - Firefox 3.0.10 - Security Exceptions

Ich habe oft das Problem, dass sich Firefox bei mir unter Ubuntu schlichtweg weigert, eine Security Exception hinzuzufügen, wenn eine Seite nicht in der Lage ist, sich richtig zu identifizieren (Zertifikate und so). Ich klicke auf den Button, um eine Ausnahme hinzuzufügen, der entsprechende Dialog kommt, alles sieht gut aus. Doch der Button zum Bestätigen der Ausnahme hat schlichtweg keine Funktion - das ist sehr ärgerlich...
Die temporäre Lösung ist es, die bisher gespeicherten Ausnahmen zu löschen und Firefox neu zu starten. Schon kann eine (und nur eine) Ausnahme hinzugefügt werden.

Um die aktuellen Ausnahmen zu entfernen:

cd /home/[username]/.mozilla/firefox/[profile]/
rm cert8.db
rm cert_override.txt

Nun einfach Firefox neu starten und fertig.

Das ist natürlich nur ein Workaround...

Ubuntu 8.10 auf Benq Joybook S72 installieren

Die Installation von Ubuntu 8.10 (oder anderen Versionen, aber ungetestet) auf einem Benq Joybook S72 stellt sich als komplizierter als notwendig heraus, wie ich leider feststellen musste...

Eigentlich bin ich eingefleischter Windows-Nutzer, wollte aber für die Uni Linux auf meinem Laptop installieren. Tja, eigentlich sollte das ja so schwer nicht sein, dachte ich mir und legte die frisch gebrannte Ubuntu 8.4 (damals) ein.
Das Setup verlief einwandfrei, ich startete den Rechner neu und alles war fein.

Doch dann kamen die Probleme: Ich kam nicht ins Internet, egal wie ich es versuchte. Meine Netzwerkkarte hatte einfach keine Lust...
Im Netz las ich, dass man die Verbindung über

sudo pppoeconf

einrichten könne...das funktionierte aber auch nicht.

Ein Kommilitone erzählte mir, dass in einigen Tagen die neue Version von Ubuntu (8.10) herauskommen würde und ich es damit versuchen solle. Also installierte ich wieder Windows, da ich den Laptop in der Zwischenzeit noch brauchte.

Einige Tage später war die 8.10 dann offiziell da und ich startete einen neuen Versuch. Diesmal kam ich sogar ins Netz! Wer hätte das gedacht! :)
Nur leider wollte Ubuntu auch diesmal nicht so, wie ich. Sobald ich online war (egal ob per LAN oder WLAN) hatte ich noch einige Momente, bis der Rechner sich vollständig aufhängte! Das war mehr als ärgerlich. Eine andere Sache war, dass er manchmal nur "so halb" einfror. Dann war er zwar irgendwie noch "da", nur die Maus (Touchpad und USB) reagierte nur noch extrem (!) träge. Will sagen mit einer Verzögerung von mehreren Sekunden! War also nicht zu benutzen.

Kurze Zeit später fand ich heraus, dass die Treiber für die ATI-Grafikkarte des Joybooks nicht direkt von Ubuntu unterstützt werden, es jedoch proprietäre Treiber gäbe, die man installieren könne.
Da sich das System so verhielt, dass man meinen könnte, die Grafik wäre das Problem, beschloss ich, diese Treiber zu installieren.
Über den entsprechenden Dialog wollte ich sie aktivieren - doch das ging einfach nicht. Ein Fenster öffnete sich, sagte mir, dass die Treiber nun heruntergeladen werden würden und dass ich warten solle. Der Ladebalken zeigte 0% an, das Fenster schloss sich wieder. Ich hatte keine Chance, den Treiber zu aktivieren.

Genervt wandte ich mich kurze Zeit anderen Linux-Distributionen zu. Darunter Mandriva und Fedora 10. Fedora ließ sich nicht installieren (wie bei Ubuntu fror der Rechner ein, diesmal jedoch schon bei der Installation und zu keinem bestimmten Zeitpunkt). Mandriva ließ sich leicht installieren und starten, lief auch fehlerfrei - ließ mich aber wieder nicht ins Netz.

Ich war schon kurz davor, die Verwendung von Linux ein für allemal abzuhaken, beschloss aber, noch ein letztes Mal Ubuntu 8.10 zu installieren.

Nach der Installation startete ich das frische System, wählte mich sofort ins Netz ein und zog alle verfügbaren Software-Updates. Ich war überrascht, dass das System diesmal nicht einfror...ich hatte alles genau so gemacht wie zuvor...

Nachdem die Updates installiert waren, erinnerte ich mich an den Grafikkartentreiber. Ich öffnete erneut den entsprechenden Dialog und klickte auf "Aktivieren". Und siehe da - der Treiber wurde heruntergeladen und installiert!

Ich war aus dem Häuschen, konnte es kaum fassen. Schnell noch einige Programme über den Paketmanager installiert und fertig - Ubuntu 8.10 läuft stabil und flüssig!

Ich kann nur hoffen, dass das auch so bleibt!

Quick'n'Dirty: Custom Dictionaries für StyleCop

Das erste Quick'n'Dirty dieses Blogs soll sich mit der Definition eines eigenen Wörterbuchs für das Addin "StyleCop" befassen.
Das Tool hat nämlich leider das Problem, dass z.B. Fantasienamen wie "Krytpa" als nicht bekannt gelten (klar, woher auch?) und entsprechend als änderungsbedürftig angezeigt werden.

Dem kann allerdings über ein eigenes Wörterbuch für das Tool leicht Abhilfe geschaffen werden.

Wörterbuch anlegen

---

Um ein eigenes Wörterbuch anzulegen, muss lediglich eine XML-Datei zum Projekt hinzugefügt werden, welches mit StyleCop analysiert wird.
Diese kann man beliebig benennen, "CustomDictionary.xml" bietet sich allerdings an.

Füllt man diese Datei nun mit folgendem Inhalt, kennt StyleCop plötzlich alle angegebenen Wörter und meldet diese nicht mehr als fehlerhaft. Hier ist natürlich zu beachten, dass nur Wörter ausgeblendet werden, die wirklich nicht fehlerhaft sind, nicht solche, die von StyleCop aus gutem Grund als unbekannt gemeldet werden (auch auf Buchstabendreher achten!).

<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
  <Words>
    <Recognized>
      <Word>Fantasiewort 1</Word>
      <Word>Fantasiewort 2</Word>
    </Recognized>
  </Words>
</Dictionary>

Hierbei handelt es sich natürlich nicht um den vollständigen Funktionsumfang der eigenen Wörterbücher - deshalb heißt die Rubrik ja auch "Quick'n'Dirty" - sondern nur um einen kleinen (!) Ausschnitt. Im Laufe der Zeit werde ich versuchen, noch mehr solcher nützlichen Methoden aufzuzeigen.

Dictionary einbinden

---

Zunächst stellte sich bei mir Frustration ein, denn das eigene Wörterbuch wurde vollständig ignoriert!


Ich ärgerte mich bereits, erinnerte mich aber schnell daran, dass solche und ähnliche Probleme oftmals über die Build Action einer Datei (Eigenschaften der Datei aufrufen) gelöst werden können.
Und tatsächlich: Unter Build Action fand sich der Eintrag "Code Analysis Dictionary"! Kaum hatte ich diese Eigenschaft gesetzt, wurden die von mir eingetragenen Wörter als nicht fehlerhaft erkannt und entsprechend auch nicht mehr gemeldet.
Bevor die Eintragungen wirksam werden, ist bei mir ein Rebuild der betroffenen Assembly notwendig!

Spring.NET: Logging einschalten

Da bei der "perfekten Entwicklungsumgebung" natürlich auch Logging-Funktionen nicht fehlen dürfen und bei der Entwicklung von Krypta auch Spring.NET zum Einsatz kommen soll (IOC, etc.), lag es nah, die Spring-Logging-Funktionen zu nutzen.

Leider stellte mich diese Vorgehensweise vor einige Probleme, die ich hier schildern möchte, da ich sicherlich nicht der einzige bin, der damit zu kämpfen hatte.

Zunächst müssen die richtigen Assemblies referenziert werden. Hier zeigte sich das erste Problem, da ich annahm, dass sich diese im Ordner (abhängig von der Version und dem Ort der Installation)

C:\Programme\Spring.Net 1.2.0 RC1\bin\net\2.0\release\

befinden würden.
Entsprechend referenzierte ich die Assemblies Spring.Core, Common.Logging und natürlich log4net.dll aus dem Log4Net-Verzeichnis.

Leider brachte das nicht den gewünschten Erfolg. Visual Studio meldete (im Outputfenster), dass die Konfiguration nicht "richtig" sei und das Logging wollte partout nicht funktionieren.

Letztendlich wurde mir klar, dass die richtigen Assemblies nicht im o.g. Verzeichnis liegen, sondern im Ordner (wieder abhängig von Version und Installationsort natürlich)

C:\Programme\Spring.Net 1.2.0 RC1\lib\Net\2.0\

Aus diesem Verzeichnis müssen die Assemblies wie folgt referenziert werden:

Sind diese Assemblies referenziert, kann die Konfigurationsdatei angelegt werden.

Konfigurationsdatei

---

Um das Logging zu aktivieren, muss nun noch die Konfigurationsdatei angepasst werden. In diesem Beispiel liegt die Konfiguration für da Logging in der Datei App.config, die über Visual Studio einfach hinzugefügt werden kann.
Die hier gezeigte Konfigurationsdatei wurde hauptsächlich aus den Anleitungen auf www.springframework.net aufgebaut und funktioniert bei mir tadellos, auch wenn ich noch einiges an Arbeit vor mir haben werde, da bin ich mir ziemlich sicher...
Leider ist die hier gezeigte Darstellung etwas unübersichtlich - die vollständige Konfigurationsdatei kann aber am Ende des Artikels unter "Links" heruntergeladen werden.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="spring">
 <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
 <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>

<sectionGroup name="common">
 <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>

<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />

</configSections>

<spring>
<context>
 <resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net">
 <description>An  example that demonstrates simple IoC features.</description>
</objects>
</spring>

<common>
<logging>
 <factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
   <arg key="configType" value="INLINE" />
 </factoryAdapter>
</logging>
</common>


<log4net>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
 <layout type="log4net.Layout.PatternLayout">
   <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
 </layout>
</appender>

<!-- Set default logging level to DEBUG -->
<root>
 <level value="FATAL" />
 <appender-ref ref="ConsoleAppender" />
</root>

<!-- Set logging for Spring to INFO.  Logger names in Spring correspond to the namespace -->
<logger name="Spring">
 <level value="INFO" />
</logger>
</log4net>

</configuration>

Mit diesen Einstellungen sollte das Logging funktionieren. Ein Beispiel wird im nächsten Abschnitt gezeigt.
Hierbei handelt es sich um einen Logger, der - bei einer Windows Forms - Anwendung im Debug-Fenster (Outputfenster) - in die Konsole schreibt.

Anyone out there? Erste Logmeldung

---

Ist der obige Teil erst einmal erledigt, wird es Zeit, eine erste Logmeldung auszugeben. Zunächst definieren wir uns einen Logger, den wir - in diesem Beispiel - für die MainForm verwenden wollen:

public partial class Mainform : Form
{
  private static readonly ILog _log = LogManager.GetLogger("Spring");
  //...
}

Mit diesem Logger ("_log") können nun an beliebiger Stelle Log-Meldungen ausgegeben werden, allerdings erst, nachdem Spring.NET mitgeteilt wurde, dass es sich bitte konfigurieren möchte. Im Konstruktor der MainForm fehlt noch die Zeile

ContextRegistry.GetContext();

Diese bringt Spring.NET dazu, die Konfiguration zu übernehmen.

An beliebiger Stelle kann nun eine Log-Meldung ausgegeben werden:

_log.Info("Hello World");

Fazit

---

Nach einigen Problemen, die man hätte verhindern können (wahrscheinlich habe ich es einfach überlesen...), funktioniert das Logging einwandfrei.
Zunächst wird für Entwicklungszwecke nur im Debug-Fenster geloggt, aber sobald die Software ausgegeben wird, kann dieses Verhalten über die Konfigurationsdatei leicht auf zahlreiche andere Verfahren umgestellt werden - und das ist die Mühe allemal wert!

Links

---

• www.springframework.net
• http://logging.apache.org/log4net/index.html
  
• Download: Konfigurationsdatei

Eigene FxCop Regeln

Das kostenlose Tool FxCop von Microsoft bietet die Möglichkeit, eigene Design-Regeln festzulegen und somit beispielsweise in einem Team Unstimmigkeiten zu verhindern bzw. zu beheben.
Leider ist die Implementierung neuer Regeln nicht ganz trivial...

In den nächsten Tagen werde ich versuchen, mir wenigstens die Basis-Techniken anzueignen und meine Ergebnisse hier niederschreiben, vielleicht als eine Art kleines Tutorial.

Bis dahin bitte ich um Geduld.

Perfect Development Environment (Part 1)

Dieser Artikel (und seine Fortsetzungen) beschäftigen sich mit dem Aufsetzen der "perfekten" Entwicklungsumgebung für die Programmierung mit dem Microsoft .NET Framework 3.5 unter Microsoft Windows XP. "Perfekt" bedeutet in diesem Fall, dass sich die Umgebung darum kümmert, dass der Programmierer keine Fehler macht und sich an einen akzeptablen Programmierstil zu halten hat.
Da die Idee von einem meiner Professoren an der TFH Berlin stammt (nämlich Prof. Dr. Stefan Edlich), soll diese Einleitung mit seinen Worten zu diesen Intentionen enden: "Schon bei einem einfachen HelloWorld-Programm soll einem diese Entwicklungsumgebung Fehler um die Ohren hauen!" (sinngemäß).

Grundlage: Die eigentliche Entwicklungsumgebung

---

Als Basis für die perfekte Entwicklungsumgebung kommt für mich nur Microsoft Visual Studio 2008 infrage. Einerseits bietet diese IDE zahlreiche nützliche Features von vornherein an (built-in), andererseits lässt sie sich durch AddIns leicht um andere Funktionen erweitern. Zudem bin ich mit ihrem Einsatz vertraut. Die Wahl fiel also nicht schwer...

Ein kleines Projekt, um die Umgebung zu testen

---

Natürlich braucht man, wenn man eine solche Entwicklungsumgebung aufsetzen möchte, auch irgendein Projekt, welches man damit entwickeln möchte.
Für dieses Vorhaben habe ich mich dazu entschieden, ein kleines Kryptografie-Tool zu programmieren, welches vollständig auf Plugins basiert. Es selbst hat keine wirkliche Funktionalität, sondern stellt lediglich verschiedene Möglichkeiten zur Ein- und Ausgabe bereit, die von den Plugins (natürlich werden entsprechende Schnittstellen nach außen geliefert) genutzt werden können, um verschiedenste Verschlüsselungen und Hashing-Verfahren anzuwenden. Dieses Tool trägt den Codenamen "Krypta".

Microsoft Design Guidelines

---

Wer bereits einmal mit Microsoft Visual Studio gearbeitet hat und in den Eigenschaften einer Assembly unter dem Punkt "Code Analysis" einen Haken bei "Enable Code Analysis on Build" gesetzt hat, der wird sich vielleicht über die zahlreichen Warnungen wundern, die nun bei jeder Ausführung/jedem Build eines Projekts auf ihn einprasseln. Code Analysis bedeutet nichts anderes als die Analyse der Assembly bezüglich der Microsoft Design Guidelines for Class Library Developers. Dabei handelt es sich um zahlreiche (!) Regeln, die Microsoft den .NET-Programmierern auferlegt hat, um eine einheitliche Assembly-Programmierung zu erreichen.
Die folgende Abbildung zeigt die besagte Einstellung, die - falls erst zu einem späteren Zeitpunkt angewendet - einige schlaflose Nächte produzieren kann...


Ist diese Option erst einmal gesetzt, wird automatisch die gesamte Assembly auf die Einhaltung der Guidelines hin überprüft.

Schon eine leere Windows-Forms-Anwendung produziert (auf meinem System) drei Warnungen:

CA2210
Microsoft.Design : Sign 'WindowsFormsApplication1.exe' with a strong name key.

CA1014
Microsoft.Design : Mark 'WindowsFormsApplication1.exe' with CLSCompliant(true) because it exposes externally visible types.

CA1824
Microsoft.Performance : Because assembly 'WindowsFormsApplication1.exe' contains a ResX-based resource file, mark it with the NeutralResourcesLanguage attribute, specifying the language of the resources within the assembly. This could improve lookup performance the first time a resource is retrieved.

Diese Warnungen lassen sich jedoch leicht entfernen. Um eine Assembly mit einem starken Namen zu versehen (CA2210), muss man lediglich in deren Eigenschaften (Rechtsklick auf die Assembly im Solution Explorer -> Eigenschaften) unter "Signing" einen Haken bei "Sign Assembly" setzen. In der DropDown-Box wählt man "New" aus, um eine neue Schlüsseldatei zu erzeugen (vgl. Abbildung).


Ist dieser Schritt getan (einfach den Anweisungen folgen), ist die Assembly mit einem starken Namen versehen und die Warnung verschwindet.

Um die zweite Warnung (CA1014) zu eliminieren, muss die Assembly als CLS-Compliant markiert werden (oder als explizit nicht CLS-Compliant). Die Warnung entsteht, wenn über diese Eigenschaft einer Assembly keine Angaben gemacht wurden. Um eine Assembly CLS-Compliant zu machen (CLS: Common Language Specification), muss an beliebiger Stelle (AssemblyInfo.cs wäre sinnvoll), das entsprechende Attribut gesetzt werden:

[assembly: CLSCompliant(false)]

In diesem Fall wird die Assembly als explizit nicht CLS-Compliant markiert.

Was bringt es, eine Assembly als CLS-Compliant zu markieren?
CLS-Compliance bedeutet eigentlich "nur", dass die Assembly aus allen .NET-Sprachen heraus angesprochen werden kann, also beispielsweise keine reservierten Wörter einer dieser Sprachen als Methoden-Parameter o.ä. verwendet wurde. Eine Einhaltung der CLS-Compliance ermöglicht es einer größeren Zahl von Entwicklern, die entsprechende Assembly aus ihrer bevorzugten Sprache heraus anzusprechen.


Nun sind bereits zwei der drei Warnungen verschwunden. Die dritte Warnung (CA1824) kann genau so leicht behoben werden. Windows-Forms-Anwendungen besitzen (wie immer auf mein System bezogen) eine Ressourcen-Datei ("Resources.resx"). Diese Ressourcendatei ist nicht mit einer bestimmten Sprache verbunden. Die Design Guidelines empfehlen allerdings, eine Standard-Sprache anzugeben, da somit die Performance beim ersten Suchen der Ressource erhöht werden könne.

Ich bin nicht sicher, ob meine Lösung die richtige ist, aber sie hat die Warnung erfolgreich entfernt und das Programm lässt sich auch weiterhin starten. Ich habe lediglich die folgende Zeile direkt unter die CLS-Compliance-Zeile gesetzt:

[assembly: NeutralResourcesLanguage("de-DE")]

Wenn ich diese Anweisung richtig interpretiere, wird die CLR von nun an versuchen, zunächst nach einer deutschsprachigen Ressource zu suchen und diese im Falle der invarianten Sprache als die Standard-Sprache zu verwenden. Ob das aber richtig/sinnvoll ist, weiß ich leider nicht (sobald ich das weiß, werde ich das Ergebnis hier eintragen!).

Zusammenfassung

---

Ehrlich gesagt gibt es ja noch nicht so viel zum Zusammenfassen. Bisher ist eine Entwicklungsumgebung entstanden, die - falls gewünscht - eine oder mehrere Assemblies automatisch auf die Einhaltung der Microsoft Design Guidelines hin überprüft.
Damit ist die IDE schon einen großen Schritt in die richtige Richtung gegangen.

Abschließend sei noch erwähnt, dass die Microsoft Design Guidelines auch vom kostenfrei erhältlichen Tool "Microsoft FxCop" überprüft werden können (für alle, die kein Visual Studio haben).