Es gibt eine neue Rubrik auf der Homepage von IT-Consulting Hempel – Empfehlungen von Artikeln und Beiträgen. Diese Empfehlungen werden wie die Twitter Timeline auf der rechten Seite in einer Box ausgegeben.

Über die Manifest-Datei site.pp bzw. nodes.pp oder eine ENC (external nodes configuration) werden in Puppet Module und damit Anwendungen einem Knoten / Rechner zugeordnet. Welche Module zugeordnet werden, hängt von der Rolle / dem Einsatzzweck des Rechners ab. Je mehr Module zugeordnet werden umso länger wird auch ein Puppet-Lauf. Möchte man einen manuellen Puppet-Lauf durchführen, ist dabei aber nur an den Ergebnissen eines Moduls interessiert, kann man die Funktionalität der Tags in Puppet nutzen.

Am 19. April 2013 fand das zweite Puppet Camp in Nürnberg statt. Veranstalter war wie schon beim ersten Puppet Camp 2012 Netways aus Nürnberg. Auch in diesem Jahr war der Raum bis zum letzten Platz besetzt.

Das Camp begann mit der Keynote von Nigel Kersten (CTO von Puppet Labs) mit seinem Bericht über den aktuellen Stand der Entwicklung von Puppet. Bereits verfügbar ist die neue Version 1.7 von facter. Neu in dieser Version ist die Möglichkeit den Inhalt von yaml, json und txt Dateien als Facts zu importieren. Der nächste Schritt der Entwicklung ist hier die Unterstützung von typisierten und strukturierten Facts. Als Beispiel sei die Auflistung aller Netzwerkschnittstellen mit deren MAC und IP-Adressen genannt.

Ich habe das Brutal Refactoring Game bereits bei der Java User Group Erlangen Nürnberg kennen gelernt. Zuletzt wurde eine Runde dieses Spiels bei der Softwerkskammer Nürnberg durchgeführt. Was diese spezielle Form eines Code Retreat auszeichnet, habe ich bereits beschrieben.

Auch bei der Softwerkskammer haben wir das Retreat mit dem bekannten Tic Tac Toe Kata durchgeführt. Von den 17 Regeln des Brutal Refactoring Games hat uns besonders die Regel „Primitive Obsession“ behindert oder besser gesagt gefordert.

Bereits vor längerer Zeit habe ich in einem Beitrag über die Verwaltung von PPAs (personal package archive) mit Puppet geschrieben. Nachdem ich seit Anfang 2013 einen Account bei Github habe, habe ich in einem Repository ein Modul zur Verwaltung von PPAs veröffentlicht.

Das Schreiben von Unit-Tests ist nichts besonderes. Gerade bei der testgetriebenen Entwicklung (TDD) gehört das Schreiben von Unit-Tests zur normalen Tätigkeit von Entwicklern. Egal ob man die Tests vor oder nach dem produktiven Code schreibt ist es aber immer lästig und fehleranfällig, wenn vor dem eigentlichen Test ein umfangreiches Setup durchgeführt werden muss. Auch die Auslagerung des immer gleichen Codes in eine @Before Methode hilft dabei nicht unbedingt weiter. Sehr schnell wird die setUp() Methode dann immer größer unübersichtlicher und trägt zur langen Ausführungszeit von Tests bei. Ein weiteres Problem sind Setups, die immer wieder in mehreren Testklassen vorgenommen werden. Diese Redundanz macht den Testcode sehr schwer wartbar.

Ich bin dabei ein eigenes, kleines Projekt im Bereich der Software-Entwicklung zu starten. Das Ergebnis bzw. das Projekt selbst sollen unter einer OpenSource Lizenz veröffentlicht werden. Recht naiv bin ich an die Auswahl der zu verwendenden OpenSource Lizenz gegangen. Schaut man sich die einzelnen Lizenz genauer an, gibt es kleine aber nicht unerhebliche Unterschiede, die bei der Wahl der Lizenz zu berücksichtigen sind.

Es ist ein grundlegender Unterschied, ob man sich als Anwender an die Regeln einer Lizenz halten muss, oder ob man als Entwickler selbst eine Lizenz auswählt. Im ersten Fall beschäftigt man sich mit den Einschränkungen / Freiheiten der Lizenz. Je nach Einsatzgebiet muss man mit Einschränkungen leben oder kann die Software überhaupt nicht einsetzen. Im zweiten Fall geht es eher um die Freiheiten, die man Anwendern / anderen Entwicklern an der Software geben möchte. Ein wichtiger Aspekt ist dabei für mich, ob Änderungen an der Software wieder zurückgegeben werden müssen.

Fast täglich liest man Meldungen über gehackte Datenbanken mit Benutzerdaten und Kennwörtern. Erst kürzlich wurde Twitter Opfer eines solchen Angriffes. Bei den Accounts der betroffenen Benutzer wurde das Kennwort zur Sicherheit zurück gesetzt.

Ich hoffe, dass die betroffenen Benutzer das Kennwort bei Twitter nicht auch für andere Accounts verwendet haben. Unüblich wäre die mehrfache Verwendung des Kennworts nicht. Was bequem ist, ist nicht sicher. Die Kennwörter werden bei anderen Accounts der Benutzer ausprobiert werden. Sehr schnell sind dann neben dem Twitter Account viele andere Accounts „erbeutet“.

Es ist mühsam sich für jeden Account im Internet ein neues / anderes Kennwort auszudenken und sich dieses zu merken. Durch die Verwendung eines Password Safes kann man sich das Leben in dieser Hinsicht wesentlich leichter machen.

Ich war diese Woche auf einem Treffen der Java User Group Erlangen Nürnberg. David Tanzer informierte uns kurz über das Brutal Refactoring Game und leitete uns dann durch ein Spiel mit 3 Iterationen. (Bild: Angry Girl From May, CC-BY stevendepolo)