Archiv der Kategorie Empfehlungen

Kleines FritzBox/Netcologne Wächterscript – Uptime, Reconnect per Script

Aufgabe: Das automatisierte Auslesen der aktuellen Uptime (Verbindungszeit) der eigenen Internetverbindung und idealerweise auch das “reconnecten” per Scriptaufruf.

Das NetCologne Router-Modem-Gespann — welches eine spezielle gebrandete FritzBox ist — mangelt es etwas an Scripting-Möglichkeiten. Der einzige Zugriff ist eine Weboberfläche, die a) nur dürftig ist und b) darüber hinaus auch noch (wieso eigentlich?!) mit einem Sessioncookie “gesichert ist”.

Das hat Folgen. Nachdem man dann per Firebug o.ä. Tools herausgefunden hat, hinter welcher URL sich bspw. die Uptime versteckt, muss man feststellen, dass das Ergebnis des entsprechenden wgets dennoch nur die blöde Übersichtsseite enthält. Warum? Weil der web.cgi-Controller jedes Mal, wenn keine Session oder ein falscher Referrer  geschickt wird, immer jene Seite ausgibt.  Hilfreich war da ein kleines Snippet.

Herausgekommen ist ein kleines Shell-Script, welches folgende Basics kann:

  • uptime – Ermittlung der aktuellen Zeit
  • ipaddr – Ermittlung der aktuellen IP-Adresse (extern)
  • connect, disconnect, reconnect – Steuern des PPPoE-Devices.

Ob noch mehr hinzukommt, werden wir mal sehen. Aktuellen/Letzter Telefonanruf mit Namensauflösung wäre so ‘ne Idee…

Das Script kann man hier laden: netconnect.sh

Entwickelt und getestet wurde es unter einem OS X 10.6 (+ wget), aber sollte eigentlich unter jedem Unix laufen. Naja, und was Windows angeht: Mädels, besorgt Euch ein ordentliches Betriebssystem ;) Wahlweise geht sicher auch Cygwin – wer es braucht.

Hudson-Konfiguration im SVN

Keeping your configuration and data in Subversion

Auch die Konfiguration des Build-Servers selber sollte man sichern.

Howto: Ein firmeneigenes Java-Maven-Repository aufsetzen

Für diesen Artikel setze ich jetzt einfach mal voraus, dass die Begriffe und Technologien hinter Java, Maven, Repository, Eclipse und Tomcat bekannt und geläufig sind. Und nein, jeweiliger Profi muss man zum Verständnis nicht sein.

Was wollen wir?

An ein firmeneigenes Repository — oder auch: corporate repository — gelten besondere Anforderungen. Diese können bei einem “einfach privat-eigenen” verändert werden, aber man kommt meistens auf folgende Punkte:

  1. Ein Repository soll den Entwicklern zum Deployen der eigenen Artifakte und Module zur Verfügung gestellt werden. Wahlweise übernimmt dies auch ein automatischer Build-Agent wie Hudson, TeamCity und haste-nicht-gesehen.
  2. Ein Repositorymanager soll als proxy fungieren. In einer Firma spart dies nicht nur einfache Bandbreite. Da ein solcher Manager in der Regel im lokalen Netz steht, sind die Interaktionszeiten um ein Vielfaches besser.
  3. Ein so genanntes third party pepository für die Abhängigkeiten, die unbedingt notwendig sind und wovon es keine Maven-Abhängigkeiten gibt.

Für Punkt zwei spricht auch eine wesentlich einfachere Konfiguration der Clients (Entwicklerprofile), da nur noch ein Repository eingetragen werden muss. Alle “bekannten” Repositories werden zentral gebündelt, damit schwindet natürlich gleichzeitig die “Freiheit” des einzelnen Entwicklers, andere “unbekannte” Repositories zu verwenden. Dies ist jedoch vernachlässigbar, weil: Diese “Freiheit” schränkt im Endeffekt den Buildprozess und auch die Wiederverwendbarkeit ein. Das Hinzufügen von weiteren Repositories in die POM ist aus Gründen der Versionisierung und Nachhaltigkeit auch keine optimale Lösung. Dennoch, alles nur eine Sache der Konfigurations der Clients.

Was brauchen wir?

Es gibt eine Reihe von Repository-Managern, die allesamt viel können. Die Wahl auf Nexus fällt hier aus folgenden Gründen:

  • der Footprint ist mit 30 Megabyte wesentlich kleiner als bspw. Artifactory
  • die interne Verzeichnisstruktur entspricht mehr oder weniger 1:1 der realen Organisationsstruktur eines Maven-Repositorys (im Vergleich: Artifactory speichert ein eigenes Datenbankstruktur ähnliches Layout)
  • Nexus und das Eclipse-Plugin m2eclipse sind vom gleichen Hersteller Sonatype und ergänzen sich; nach dem Umstellen bemerkt der Entwickler keinen Unterschied in der Suche, Auto-Discovery, o.ä.

Eine umfangreiche Online-Dokumentation ist auf der Nexus-Seite zu finden.

Installation

Nexus wird unter anderem als WAR ausgeliefert, insofern die Installation in einen Tomcat ein leichtes ist. Beachtenswert ist dabei nur, dass Nexus ein Verzeichnis ~/sonatype-work erstellt. Da sich dort unter Umständen viele Nutzdaten ansammeln, kann ein Verschieben (symbolischer Link?) nicht verkehrt sein. Da sich mit der Laufe der Zeit einiges an Daten ansammeln kann, sollte der Platz nicht zu sparsam vermessen sein.

Umfang

Nachdem Tomcat bzw. Nexus gestartet ist, kann man sich mit dem Default-Daten admin/admin123 anmelden (analog  mit den Daten der anderen beiden Benutzern!).

Nexus kommt bereits mit einer Reihen von vorkonfigurierten, eigenen hosted repositories einher.

  • releases sammelt alle Release-Artifakte der Firma
  • snapshots sammelt alle Snapshot-Artifakte der Firma
  • third-party sammelt alle Release-Artifakte externer Quellen, wofür es keine Maven-Repositories gibt (oder wo man jenes Repository nicht generell zur Verfügung stellen will), gutes Beispiel ist ein (aktueller) Oracle-JDBC-Treiber

Daneben gibt es so genannte proxy repositories, die praktisch gesehen nur aus einem Index bestehen. Wie ein Proxy hängen sie sich zwischen dem Client und dem tatsächlichen Repository und cachen alle Artifakte lokal. Selbst der Index ist mehrere Megabytes groß, das sollte man nicht vernachlässigen. Voreingetragene proxy repositories sind Apache Snapshots, Codehaus Snapshots, Central Maven Repository (Maven1/Maven2-Repository-Konverter sind in Nexus vorhanden a.k.a. virtual repositories).

Die grouped repositories sind auch rein virtuelle Gruppierungen von verschiedenen Repositories. Das Standard Repository “Public” ist in der einfachsten Konfiguration eine Sammlung aller (aktivierten) Repositories auf dem Manager — also sowohl der externen Spiegel, der Third-Parties als auch den eigenen Artifakten.

Konfiguration

Die Aktivierung und Verwaltung von (neuen) Repositories ist abhängig der eigenen Bedürfnisse. Meistens sinnvoll ist es jedoch, bei den drei großen Spiegeln (proxy repositories) in dem Konfigurationstab das Indizieren (Download Remote Indexes) zu aktivieren. Je nach Belieben kann man in der Gruppe Administration auch das Aktualisierungsverhalten steuern.

Konfiguration: Deployment

Um ein Deployment zu gewährleisten, muss man nebst Kenntnis der Repository-URL (eben die URL) nur wissen, ob der anonyme Zugriff erlaubt sein soll, oder ob man einen Deployment-Benutzer einrichten und nutzen willst. Falls eine Richtlinie vorschreiben sollte, dass dies nur ein Build-Agent machen darf, ist ein (geheimes) Passwort oder Schlüssel unabdingbar.

Konfiguration: Client

Nehmen wir an, der Nexus-Manager ist auf dem Host 192.168.0.10:8080/nexus installiert. In der einfachen Installation und Konfiguration sammeln sich im public repository praktisch alle relevanten Artifakte (sowohl Releases als auch Snapshots).

<settings>
<mirrors>
<mirror>
<id>corporate</id>
<name>Corporate Repository</name>
<url>http://192.168.0.10:8080/nexus/content/groups/public</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>

Der Deployment-User benötigt ggf. Zugangsdaten für das entsprechende Repository.

Ein Client wie m2eclipse sollte danach einen kompletten Rebuild des Index machen.

Tipp: Douglas Crockford – The JSON Saga

Link

Der Chuck Norris im JavaScript. ;)

Beispiel?

I give permission for IBM, its customers, partners, and minions, to use JSLint for evil.

MacOS X Security

Boah, was für ein Artikel. Geht zusammengefasst um das Sicherheitskonzept von MacOS X, teilweise im direkten Vergleich zu Windows. Unter anderem auch mit der These: Der geringe Marktanteil von Mac OS X ist nicht Schuld an kaum Malware.

Nicht überaus technisch überladen, also sehr verständlich (auf deutsch) erklärt.

Es sind zu viele Informationen auf einmal gewesen, aber beim ersten Durchlesen sind mir keine Fehler aufgefallen. Einzig allein den Passus, dass “Mac OS X” in großen Teilen offen läge, finde ich unglücklich formuliert. Der Autor meinte sicher, dass viele Komponenten (wie das in dem Kontext genannte Samba) offen sind und von Apple dort auch genutzt werden.

Java Reflection API – mit Cache, ey!

Einführung in Reflection

Die Java Reflection API ist Bestandteil des JDK und ermöglicht den Zugriff auf Methoden, Felder und Annotationen von Klassen und Objekte, also den Instanzen von Klassen. Mit Ausnahme von Annotationen geschieht der Zugriff immer auf einer Meta-Ebene.

Mit einem einfachen Beispiel ist diese Meta-Ebene erklärt.

class Foo {
private String bar = "private value";
}

Stellen wir uns vor, wir wollen ganz exemplarisch von dem Objekt foo (foo = new Foo())den Inhalt von dem Feld bar erhalten. Auf dem üblichen Weg ist das nicht möglich, da das Feld ein privates ist.

Über den zugehörigen Klassentyp (via getClass()) stellt Java eine Reihe von Methoden aus dem Reflection-Paket zur Verfügung, u.a. auch Field getDeclaredField(String). Ein declared field ist ein Instanzattribut eines Objektes, während ein field (Field getField(String)) statische Felder finden.

Field field = foo.getClass().getDeclaredField('bar');

Die Variable field enthält aber – wie man dem Typ entnehmen kann – aber nicht den Inhalt von bar, sondern ein Field-Objekt. Um an den Inhalt zu kommen, verwendet man die Methode get(Object). Der Parameter bezeichnet den entsprechenden Kontext, also das Objekt foo von weiter oben.

Object value = field.get(foo);

Das bedeutet im Klartext: Auch für eine weitere Instanz der Klasse Foo (etwa foo2) kann dieses Field für dieses Feld verwendet werden. Es beinhaltet nur die Metainformationen, nicht die eigentlichen Inhalte.

Dabei ist jedoch zu beachten, dass der SecurityManager aktiv werden kann; in diesem Falle wird eine Exception bei get(Object) geschmissen, weil das Feld nicht sichtbar ist.

field.setAccessible(true);

schafft dabei Abhilfe.

Und Methoden?

Im Prinzip funktioniert das Schema bei Methoden genauso – aber bevor ich jetzt einen Radio Eriwan-Witz loslasse…

Im Gegensatz zu den vorherigen Feldern werden Methoden nicht nur über den Namen, sondern auch über die Parametertypen identifiziert (daher können Methoden sich vom Namen her in Java auch “überladen”).

class Bar {
private String name;
String getName() {
return name;
}
String getName(String defaultName) {
return (name == null) ? defaultName : name;
}
}

Die Metainformationen werden entsprechenderweise geladen:

Method method1 = bar.getClass().getDeclaredMethod("getName");
Method method2 = bar.getClass().getDeclaredMethod("getName", String.class);

Selbstverständlich ist bei Kenntnisnahme der Klasse auch folgende Zeile gleichwertend:

Method method1 = Bar.class.getDeclaredMethod("getName");

Methoden haben im Gegensatz zu Feldern keinen “Inhalt”, sondern sind eine Aktivität oder Operation — und zwar auf einem Objekt. Dementsprechend funktioniert das Ausführen mittels der Method Object invoke(Object, Object…args):

Object result1 = method1.invoke(bar); // getName()
Object result2 = method2.invoke(bar, "default name"); // getName("defaultName")

Und Annotationen?

Annotationen sind “Anmerkungen” im Quellcode, und seit Java 5 fester Bestandteil des JDKs. Technisch gesehen sind Annotationen besondere Klassen mit eingeschränkten (Java-) Möglichkeiten, deren Instanz auf einem Meta-Attribut wie Klasse, Feld, Methode oder Methodenparameter “hängen”. Mit anderen Worten bedeutet dass, dass man mittels Reflection tatsächlich eine Instanz einer Annotation erhält — allerdings mittels einem Proxy (aus der Java API).

@Entity
class Account {
@Column(name="id_x")
private Long id;
}

Die Methode getAnnotation(Class) existiert in allen Typen: Class, Field und Method.

Account account = new Account();
Entity annotation1 = Account.class.getAnnotation(Entity.class).annotationType();
Column annotation2 = Account.class.getDeclaredField("id").getAnnotation(Column.class).annotationType();
Assert.assertEquals("id_x", annotation2.name());

Performance

Im Regelfall benötigt man keinen Zugriff auf Reflection und sollte es vermeiden. Nichtsdestotrotz gestalten sich Konfigurationen, welche auf Basis von Annotationen, meist als sehr einfach, simpel und vor allem Code-konzentriert. Das JPA-Mapping (etwa mit Hilfe von Hibernate) gestaltet sich via Annotationen wesentlich einfacher, schneller und schlanker als mit XML.

Jeder Zugriff über die Reflection API kostet Zeit. Für Konfigurationen und Pläne ist das meist nebensächlich; die JPA-Konfiguration wird beim Start der Applikation eingelesen, analysiert und gespeichert. Nebenbei profitiert das natürlich von der anfänglichen “Warmup-Phase”.

Besteht jedoch ein Access on Demand, so sollte man sich Gedanken um eine geeignete Cachestruktur machen. Wichtig ist dabei, die Metadaten von den eigentlichen Inhalten zu trennen.

Cachen & Lösungsansätze

Jeder der oben genannten Reflection-Getter gibt es auch jeweils eine getAll-Variante: Class.getDeclaredFields(),Class.getDeclaredMethods(), Class.getAnnotations(), Field.getAnnotations() und Method.getAnnotations().

Mit einem einfachen Algorithmus kann man die Laufzeit drastisch senken, wenn Objekte des gleichen Typs mittels Reflection untersucht werden.

public class CacheReflectionUtil {
// cache of declared fields of class types
private final Map<Class<?>, Field[]> classDeclaredFields = new HashMap<>();
// Return the declared fields of the given class type.
public Field[] getDeclaredFields(Class<?> type) {
Field[] fields = classDeclaredFields.get(type);
if (fields == null) {
fields = type.getDeclaredFields();
classDeclaredFields.put(type, fields);
ensureAccessibility(fields);
}
return fields;
}
// Ensure that the given fields are accessible.
public void ensureAccessibility(Field[] fields) {
for (Field field : fields) {
// setAccessible will not only set a property but invoke SecurityManager stuff
if (field.isAccessible()) {
field.setAccessible(true);
}
}
}
// Return the declared field of the given class type.
public Field getDeclaredField(Class<?> type, String name) {
for (Field field : getDeclaredFields(type)) {
if (field.getName().equals(name)) {
return field;
}
}
return null;
}
}

Um einen stetigen Speicherverbrauch zu verhindern, empfiehlt sich das Nutzen einer Least-Recently-Used-Struktur. Das Apache-Commons-Paket bietet dies etwa mit der LRUMap an.

Shortcut of the week

Das ursprüngliche Problem: Ich habe eine URL zu einem MP4-Video, welches der Safari sofort abspielen will. Allerdings will ich das Video erst später gucken, also speichern. Hm, dumme Sache. Dem Link folgen von der  ursprünglichen Seite ging aus bestimmten technischen Gründen nicht — und ein Dokument/Seiten speichern scheint zu mindestens nicht zu funktionieren, so lange das Video noch lädt.

Überraschenderweise ist es einfacher, als man denkt: Das Safari-Downloads-Fenster nimmt die Tastenkombination +V für Einfügen an — dementsprechend auch jegliche Drag ‘n’ Drop Aktionen, welche eine URL als Objekt haben.

Kurzer Gegenscheck: Nope, Firefox kann das nicht. ;)

[Fw] Google-Bashing: Zur politischen Ökonomie einer Suchmaschine

Ich kann den Beitrag nur empfehlen, ist von Ende Januar diesen Jahres.

HTML5 & Forms

Als Ergänzung zu meinem XForms-Vortrag in der FH, hier ein paar nette Details zu den Neuerungen von HTML5/Forms. Jaja, was für eine Überaschung. Okay, nach dem Tod von XHTML2 (und demnach die Integration von XForms in XHTML) auch wieder nicht…

Ganz allgemein scheint Dive Into HTML5 aber auch empfehlenswert zu sein, wenn auch noch in Arbeit. Nett gemacht.

Ersatz für Thawte (personal e-mail certificates)

Kleine Randnotiz und Hinweis für diejenigen, die auch eine Alternative für Thawte suchen – zur Erinnerung: Die kostenlosen E-Mail-Zertifikate bzw. der Dienst dafür läuft in wenigen Tagen ab.

Eine Alternative ist TrustCenter mit seinem Angebot TC Internet ID. Auch dies ist ein E-Mail-Adressen basiertes und kostenloses Zertifikat – und dieses PKI-Zertifikat ist auch beim “Rest” installiert und bekannt.

Page optimized by WP Minify WordPress Plugin