Windows 8 – Wieso ausgerechnet die Kacheln!

In dem ganzen Cebit-Trubel schiebe ich ganz still und leise ein Thema dazwischen, dass von vielen nur müde beschmunzelt oder gar abgrundtief verachtet wird. Bei Windows teilen sich ohnehin bereits die Meinungen vieler Entwickler, hinzu kommt dass jedes zweite Betriebssystem aus diesem Hause einfach nur floppt. Somit wäre rein statistisch gesehen Windows 8 wieder eine Katastrophe und viele rechnen sogar so fest damit, dass sie lieber gleich von vornherein aufs nächste warten.
Ich habe mich trotz aller Befürchtungen, Klischees und Negativen Meinungen mal herangewagt, denn so schnell wird Windows wohl nicht vom Markt verschwinden und evtl. wird dieses Kachel-Design ja The next Big Thing. Dabei hab ich festgestellt, dass die groß angepriesenen Features völlig nutzlos sind (Kachel-Design, Apps) aber andere kleinere Neuerungen tatsächlich einen größeren Nutzen bringen. Warum ausgerechnet diese Kacheln so sein müssen, wie sie sind und man keinerlei Möglichkeit bekommt, diese auch nur irgendwie zu individualisieren (bis auf zwei vorgegebene Kachelgrößen), ist mir immer noch ein Rätsel (Vielen Dank Frau Larson-Green!). Denn zugegeben, das Startmenü wirkt wie der anmontierte übergroße Heckspoiler an einem Moped. Auch das zweite große Highlight, die Apps, sind eher als Gimmick anzusehen, denn der  Zwang jede App im Vollbild auszuführen nimmt einem jegliche Flexibilität. Kann man Windows 8 jetzt auf diese zwei Dinge festmachen und pauschal sagen “taugt net” oder entlockt es einem vielleicht doch noch ein “bassd scho”, was dem berlinerischem “Det is Knorke!”  entsprechen würde?
(mehr …)

Pylint, Pylint on the wall, who has the fairest code of them all?

“You, my Developer, have the fairest of all.” So oder so ähnlich wünscht man es sich, wenn einem die Qualität des eigenen Programms am Herzen liegt. Für all die Python-Entwickler da draußen, welche nicht jegliche Richtlinien aus dem PEP8 Guide auswendig wissen und es auch sonst im Eifer des Programmierens nicht so ernst mit der Qualität nehmen, bietet Pylint ein sehr nützliches Werkzeug, um so eilig wie geschwind das hässliche Entlein wieder in einen schönen Schwan zu verwandeln. Doch wie soll das gehen, und was unterscheidet es von gängigen Python Source Code Checkern wie beispielsweise PyChecker?
Nun, zunächst einmal bietet Pylint in den Grundfeatures ziemlich das selbe wie PyChecker. Das bedeutet, beide Programme überprüfen den Code auf Qualität und Sauberkeit. Doch während PyChecker in der Altfränkischen “Bassd scho”-Manier arbeitet, ist Pylint eher der strenge Deutschlehrer, der auch jeden noch so kleinen Fehltritt rot anstreicht. Da wird penibel auf Dinge wie die maximale Zeilenlänge (max. 80 Zeichen) oder der maximal erlaubten Zeilenanzahl (max. 1000 Zeilen) innerhalb einer Datei geachtet. Auch vergessene allseits bekannte Kommentare wie “TODO” oder “FIXME” werden dem eifrigen Entwickler nochmal ins Gedächtnis gerufen. Wem diese ganzen Richtlinien von PEP8 nicht zusagen oder sowieso schon nach seinen eigenen Standards codet, dem bietet Pylint eine sehr schnelle und einfache Möglichkeit Regeln zu ändern oder sogar mithilfe von Modulen zu erweitern.
Wie funktioniert nun also dieses wunderbare Werkzeug? Wir starten den ausführlichen Test zunächst einmal mit der Standardkonfiguration:

pylint pfad/zum/projekt

Nach einer kurzen Wartezeit (je nach Projektumfang) spuckt das Programm auch schon eine Statistik mit jeglichen Makel und Fehler. Sogar eine Punktwertung wie im guten alten Sport wird vergeben! Wer seine Punkte nun verbessern möchte, muss sich nun daran machen, die gelisteten Meldungen abzuarbeiten und so seinen Code zurechtschleifen. Möchte man gewisse Regeln ändern oder Ausnahmen hinzufügen, so kann man dass indem man eine neue rcfile generiert:

pylint --generate-rcfile > ~/.pylintrc

Diese Datei öffnet man dann mit dem Editor seiner Wahl und fügt seine Änderungen hinzu. Dank der ausführlichen Dokumentation findet man sich innerhalb der configfile sehr schnell zurecht.
Wer jetzt noch gerne wüsste, wie denn das eigene Kind so aussieht, der kann sich mithilfe des mitgelieferten Programms “pyreverse” eine Art UML-Diagramm generieren lassen:

pyreverse pfad/zum/projekt

Generiert werden zwei .dot dateien, die mithilfe folgender Befehle ganz leicht in beispielsweise .png dateien umgewandelt werden können:

dot -Tpng packages_Name.dot -o packages-Name.png
dot -Tpng classes_Name.dot -o classes-Name.png

Mithilfe eines solch strengen Lehrers sollte einem nichts mehr im Wege stehen, um das Märchen wahr werden zu lassen!

InGraph – The ultimate guide 2/5


Nachdem wir im ersten Teil des Guides eine Einführung bezüglich der Installation von InGraph geboten haben, beschäftigen wir uns im zweiten Teil weiterführend mit dem Tool.
Zweiter Teil: Bedienung.
InGraph bietet eine Vielzahl an nützlichen Features, um intuitiv und schnell sein Ziel erreichen zu können. Es gibt zwei Möglichkeiten, um auf die Performance-Daten zuzugreifen. Der einfachste Weg ist dabei direkt auf die Grid-Icons im Cronk von Icinga-Web zuzugreifen.

Das linke Icon öffnet einen InGraph-Popup und ermöglicht dem Nutzer so, direkt einen Vergleich der Graphen durchzuführen, ohne dafür die jeweilige View verlassen zu müssen. Das rechte Icon hingegen öffnet ein neues Tab mit der Standardansicht für den gewählten Service und Host.
Zusätzlich zu den Grid-Icons erstellt InGraph auch eine eigene Kategorie über die man direkt auf die Cronks zugreifen kann. Um auf die Übersicht zu kommen klickt man auf den InGraph-Button, wählt “Host und Service” und öffnet den Cronk mithilfe des “Anzeigen”-Buttons.
Bei der allgemeinen Übersicht eines Services sind standardmäßig fünf verschiedene Graphen dargestellt. Der erste Graph ist die sogenannte “Quickview”, indem der Verlauf über die gesamte Dauer angezeigt wird. Die restlichen vier Graphen beschreiben unterschiedliche Zeitintervalle: täglich, wöchentlich, monatlich, jährlich. Jedes dieser Graphenfelder besitzt ein einheitliches Menüfeld. um in ein vordefinierten Zeitintervall zu wechseln oder eine bestimmte Zeitspanne mithilfe eines Kalender-Popups auszuwählen.
Die Übersicht von InGraph
Mithilfe der Einstellungen lassen sich weitere Linien und Achsen in die Grafik hinzufügen und anpassen. Es ist außerdem noch möglich Kommentare zu genauen Datenpunkten einzufügen. Dafür muss man lediglich auf den Kommentar-Button klicken und den genauen Punkt auswählen, simple as that.
Das Editieren der Graphen Einfügen eines Kommentars 1/2 Einfügen eines Kommentars 2/2
In der rechten Ecke des Menüs wird eine Möglichkeit geboten, den Graphen in XML oder CSV zu exportieren oder normal ausdrucken zu lassen.
Als weiteres nützliches Feature bietet InGraph die Möglichkeit, innerhalb der Graphen hinein- oder herauszuzoomen. Möchte man sich also einen bestimmten Abschnitt eines Verlaufs genauer anschauen, muss man nichts weiter tun als mit einem Linksklick den gewünschten Bereich zu markieren. Daraufhin wird der bisherige Graph durch den ausgewählten und vergrößerten Bereich ersetzt. Um wieder zur ursprünglichen Ansicht zu kommen genügt ein Rechtsklick.
InGraph bietet noch viele zusätzliche Features und Möglichkeiten, welche im späteren Verlauf des Guides weiter erläutert werden. Mehr Informationen dazu findet man bereits jetzt wie gewohnt im Wiki unter netways.org.

Let's Play some Poker!

Die Aufwandsschätzung eines Projekts ist immer so eine Sache: entweder man möchte gut dastehen und schätzt zu optimistisch oder man möchte sich lieber gewisse Puffer nehmen und schätzt zu vorsichtig. Dabei bleibt einem Team oft nichts anderes übrig als auf Erfahrungswerte zurückzugreifen, um einen halbwegs realistischen Aufwand herauszubekommen. Ein Werkzeug, welches dem ganzen Abhilfe schaffen soll, ist das sogenannte Planning Poker. Einigen wird dieser Begriff vertraut vorkommen, da es häufig beispielsweise in SCRUM oder XP vorkommt. Planning Poker ist ein Verfahren, mit dem mithilfe von Spielkarten innerhalb eines Projektteams gemeinsam Aufwände geschätzt werden. Dabei werden bewusst exponentiell steigende Zahlenreihen (vorzugsweise die Fibonacci-Reihe) genommen, da je höher der Aufwand geschätzt wird, desto unklarer ist der Issue.
Im Grunde ist das Vorgehen schnell erklärt: ein Moderator erklärt das Issue, dann werden offene Fragen beantwortet. Sind diese geklärt, schätzt jedes Teammitglied den Aufwand mithilfe dieser Spielkarten, welche er verdeckt vor sich legt, um dann alle gleichzeitig aufzudecken. Dabei steht die Zahl für keine bestimmte Einheit, sondern ist abstrakt zu betrachten. Unterscheiden sich die Zahlen, begründen diejenigen mit der höchsten und niedrigsten Zahl ihre Entscheidung, woraufhin nochmal geschätzt wird. Der große Vorteil hierbei ist, dass durch die Diskussionen gleichzeitig ein Wissensaustausch entsteht, womit jeder aus dem Team sich der Issues bewusst wird.
Auch wir haben diese Methode intern mal getestet und konnten einige Erfahrungen daraus nehmen. Hier einige Tipps, welche wir nach unserem ersten Poker-Spiel geben können:

  • Diskussionsrunden zeitlich begrenzen. Beim Planning Poker ist es unvermeidlich, dass rege Diskussionen entstehen. Damit der  Zeitrahmen nicht gesprengt wird, sollten diese zeitlich begrenzt sein (z.B. mithilfe eines Timers, ein bis zwei Minuten). Sollte dieser selten eingehalten werden können, muss dafür gesorgt werden, dass nicht zu weit abgeschweift beziehungsweise nicht zu tief in die Thematik eingestiegen wird. Hilft das auch nicht, kann pauschal einfach der Durchschnitt oder der höchste geschätzte Aufwand genommen werden, um nicht zu viel Zeit an einem Issue zu verbringen.
  • Eine Übersicht aller abgegebener Wertungen parallel anzeigen. Während die einen darauf setzen, jedes Issue für sich allein zu betrachten, setzen andere darauf alles stets in Relation zu betrachten. Besonders bei längeren Listen (etwa ab 10-15 Issues) sollte eine Übersicht zur Verfügung gestellt werden, da man gerne vergisst, welche Zahlen für welchen Aufwandsgrad genommen wurden und so eine gewisse Verfälschung des Ergebnisses entsteht.
  • Diskussionen protokollieren. Der eigentliche Kern des Planning Pokers sind die Diskussionsrunden. Durch diese wird der Kenntnisstand der Beteiligten auf ein Level gebracht und Issues oftmals auch präzisiert. Durch eine Protokollierung dieser Diskussionen vermeidet man spätere Unklarheiten während des Projekts und hat womöglich bereits ein grobes Konzept.
  • Bei langen Meetings Pausenintervalle setzen. Hat man eine besonders lange Liste von Issues abzuschätzen, sollte man vorgegebene Pausen ausmachen. Zwar wird beim Planning Poker eine “Kaffeekarte” empfohlen, doch die Erfahrung zeigt, dass die gern als witziges Gimmick angesehen, jedoch nie ernsthaft gesetzt wird (man möchte ja nicht als einziger eine ernsthafte Schätzrunde zunichte machen 😉 ). Einfacher ist es einfach vorzugeben, dass beispielsweise alle 15 Issues eine Pause eingelegt wird.

Somit hat man mit Planning Poker ein sehr nützliches Werkzeug, um viele Bereiche eines Projekts in eins zu fassen(Briefing der Mitarbeiter, Aufwandsschätzung des Projekts, Issues verfeinern, etc.) und es wird sicherlich nicht unsere letzte interne Pokerrunde gewesen sein :-).

Hilfe, mein Notebook brennt!

Der ein oder andere wird es kennen: draußen scheint die Sonne, die Zimmertemperatur gleicht sich der Außentemperatur an und das eigene Notebook wird unter Last langsam aber sicher heißer als es einem selbst lieb ist. Wer dann noch rechenintensive Anwendungen ausführt, wird schnell einen Schwund an Leistung feststellen, denn nahezu jede handelsübliche CPU drosselt sich zu ihrem eigenen Schutz ab einer bestimmten Temperatur nach unten (heat Throttling). So ist bei den heutigen Intel i-Prozesorreihe vom Werk aus die Temperaturgrenze bei 85 Grad angesetzt. Wenn dann auch noch die Umgebungstemperatur um die 30 Grad liegt, ist bereits im Idle-Zustand schnell über die Hälfte dieser Grenztemperatur erreicht. Doch wie kann man jetzt dafür sorgen, dass auch bei so einem tollen Wetter die volle Leistung des Notebooks gewährleistet wird?

  • Automatische Übertaktung deaktivieren/verhindern! Viele der heutigen Prozessoren übertakten sich selbst, sobald sie eine hohe Auslastung erreichen. Damit soll “kurzzeitig” mehr Leistung zur Verfügung gestellt werden. Allerdings steigt durch dieses Feature die Temperatur noch schneller auf ein kritisches Level, was bei fehlender entsprechender Kühlung schneller zum Throttling führt. Bei Intel-Prozessoren nennt sich dieses Feature “Intel Turbo Boost”, bei AMD equivalent “AMD Turbo Core”. Da die Übertaktung üblicherweise bei einer hohen Auslastung (und da reicht es bereits wenn diese nur kurz auftritt), kann man sich unter Windows eines einfachen Tricks bedienen: Man limitiert unter den erweiterten Energieoptionen die maximale CPU-Auslastung auf einen niedrigeren Wert. Bereits eine Limitierung auf 95% verhindert größtenteils die Übertaktung bei kaum spürbarer niedrigerer und konstant bleibender Leistung. Unter Linux kann mithilfe des Pakets cpulimit die Auslastung von bestimmten Prozessen begrenzt werden. Dies ist allerdings kein Garant dafür, dass man damit die Übertaktung umgeht, denn es kommen noch andere Faktoren hinzu (Stichwort: Thermal Design Power). Wer auf der sicheren Seite sein möchte kann üblicherweise die automatische Übertaktung im BIOS des Systems deaktivieren.
  • Wärmeleitpaste auswechseln! Die Wärmeleitpaste ist eine nicht zu unterschätzende Komponente eines jeden Rechners. Besonders bei langer intensiver Nutzung lässt die Leitfähigkeit dieser nach und sorgt so für höhere Kerntemperaturen. Wer also das auseinander schrauben seines Notebooks nicht fürchtet, sollte ein Auswechseln der Paste in Betracht ziehen (da häufig auch die der Hersteller ihre Mängel hat). Richtig durchgeführt können so bis zu 10 Grad eingespart werden. Ich selbst habe die Arctic Cooling MX-4 verwendet und kann diese weiterempfehlen. Durch den erhöhten Silberanteil ist diese etwas langlebiger als beispielsweise das MX-2. Aber auch andere größere Marken haben ihre Vorteile, wodurch man bei der Auswahl wenig falsch machen kann.
  • Für eine geeignete Unterlage sorgen! Viele Notebooks haben auf der Unterseite Lüftungsein- bzw ausgänge. Oft hilft bereits eine leichte Anhebung des Notebooks(z.b. mithilfe eines Buches), um so für eine bessere Luftzirkulation zu sorgen. Ansonsten gibt es auch sogenannte Coolpads, welche diese Aufgabe übernehmen und mit zusätzlichen Lüftern unterstützen. Empfehlenswert finde ich dabei das Cooler Master NotePal U2 bzw U3 (je nach Größe des Notebooks), da es komplett aus Aluminium besteht und bei Bedarf auch einfach als Schutzcase umfunktioniert werden kann.

Sollte das alles nicht ausreichen, um das Notebook kühler zu halten, hilft wohl nur noch der Kühlschrank während der rechenintensiven Zeiten. 😉

MDA, MDE, MDSD, CASE,… Oder doch lieber klassisch?

Möchte man bei der Entwicklung etwas neues probieren, so stößt man häufig auf die Idee der Modellgetriebenen Entwicklung. Doch bereits nach kurzer Recherche erweckt es den Anschein, dass es eine schier unendliche Anzahl von Ideen und Systemen gibt. Doch wie so häufig verbirgt sich hinter einer Vielzahl von Bezeichnungen ein und dasselbe System. Ich möchte hier einmal einen kurzen Überblick bieten, wie das Chaos der Modellgetriebenen Architektur halbwegs greifbarer wird und zukünftige Recherchen möglicherweise erleichtert.
Als allgemeinen Gedanken kann man die sogenannte “Model Driven Architecture” (kurz: MDA) sehen. Diese beschreibt den Ansatz, bereits bei der Konzeptionierung und der anschließenden Modellierung eine klare Trennung von Funktionalität und Technik klarzustellen. Dabei unterteilt man eine solche Architektur in drei große Einzelbereiche:

  • Computation Independent Model (CIM)
  • Platform Independent Model (PIM)
  • Platform Specific Model (PSM)

In der ersten Instanz, der CIM, werden jegliche Modelle erfasst, die das Projekt / die Software umgangssprachlich beschreiben. Hier werden dem Team keine Grenzen gesetzt, welche Informationen sie in welchem Detailierungsgrad aufführt(durchaus auch in Fließtextform). Steht das ganze, kann nun zu der Plattform-unabhängigen Modellierung übergegangen werden. Dieser Schritt beinhaltet das Entwickeln von beispielsweise UML-Modellen, um Prozesse und Anwendung des Systems grafisch und abstrahiert darzustellen(Use-Case, Zustandsdiagramm, Prozessdiagramm, etc.).
Die ersten zwei Schritte benötigen keinerlei technischen Entwicklerkentnisse. Im letzten Schritt kommen wir schließlich zu der eigentlichen Modellgetriebenen Entwicklung. Der Grundgedanke hier ist, aus Plattformspezifischen Modellen Code zu generieren. Dabei stoßt man hier auf eine Vielzahl von Bezeichnungen für ein und das selbe Prinzip: MDSD (Model Driven Software Development), MDE (Model Driven Engineering), MDSE (Model Driven Software Engineering) oder einfach nur MDD (Model Driven Development). Durch die grafische Modellierung von beispielsweise Klassen und deren Attributen und Relationen zueinander erreicht man eine hohe Anschaulichkeit und die Möglichkeit, Standardcode bzw. die Programmstruktur zu generieren. Lediglich Funktionen und Methoden müssen noch hinzugefügt werden.
Diese Art der Entwicklung ist natürlich kein Wunderwerkzeug und entfaltet sein volles Potenzial erst bei wirklich großen Projekten, die über einen längeren Zeitraum gehen. Alleingestellt passiert es auch häufig, dass die Entwicklung mit Modellen nur zu Beginn genutzt wird oder aber der Aufwand der Modellierung als zu groß empfunden wird und somit schlechte Erfahrungen damit gemacht wurden. Deshalb empfiehlt sich der MDA-Ansatz, da für eine gewisse Dokumentation gesorgt wird und auch Abseits der Entwicklung Leute mitreden können, während es den Entwicklern selbst frei überlassen bleibt, in wie weit sie sprachenspezifisch Modelle erstellen und wie viel sie lieber klassisch entwickeln, denn die Basis ist trotzdem vorhanden.