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

Zusammengefasst lässt sich sagen: Die Provider haben bereits begonnen, “exklusive Zusatzleistungen” in Form von unlöschbaren Apps zu bringen. Und dabei handelt es sich nicht um Basics wie Mail oder Kalender, sondern PC-Bloatware-typischer Softwaremist halt.

Es scheint langsam so, als würde ein beachtlicher Teil von Androids “Open” von den Providern genutzt — und gleichzeitig zugemacht. Schade um den Grundgedanken an Android, aber es sind die Provider.. was soll man schon erwarten.

PS: Ja, das iOS hat auch einige Basics, die nicht zu löschen sind. Neben internen Apps wie den “Einstellungen” oder auch Essentials wie Mail und Browser sind dabei auch Wetter, Stocks, YouTube & Co. Streitbar, ob letzte nun wirklich jeder braucht.

So true – Have you ever noticed that, 95% of the time: People who hate Macs have never owned one, People who hate PCs have owned one.

by @gracesmith

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.

Super Beitrag eines Vertreters der Zeitungsverlegers. Die Unkenntnis von robots.txt/Disallow ist ist schon zu banal.

Es ist ja sicherlich bei keinem vorbeigegangen, dass Google WLAN-Daten aufgezeichnet hat. Dass die Daten unweigerlich aufgezeichnet werden müssen, um die eigentlichen Netzdaten (Kennung und Verschlüsselungsart) interessiert dabei nur die wenigen. Auch den Umstand, dass natürlich nur offene, d.h. unverschlüsselte Netze mitgeschnitten wurden und konnten.

Schön passt da jetzt die neuste Story. Und dann kommt diese auch noch auf Golem.de, die scheinbar teilweise ihre komplette IT-Kompetenz in Frage stellen wollen. Entweder die kopieren jetzt die News nur noch (dann aber bitte immer), oder man sollte solche News bitte auch im Kontext von IT-Wissens schreiben.

Worum geht’s eigentlich? Alleine der Titel “Google hat auch Passwörter aufgezeichnet” lässt uns doch schon lächeln. Wo ist da jetzt die Neuigkeit, hat Google doch bereits das Mitschneiden zugegeben. Weiter im Text, haben “französische Datenschützer […] entdeckt, dass Google […] auch persönliche Passwörter” aufgezeichnet hat. Jungs, das konnte euch vor Wochen schon jeder Informatik-Student im ersten Semester erzählen.

Soll ich mal sagen, wie man diese News richtig verpacken sollte? So: Immer noch senden viele Menschen ihre Passwörter in Klartext über offene Netze.

Klingt wohl nur holzig oder man kann dagegen nicht politisch agieren. Und so.

Vorschlag: Wenn man schon gegen Google vorgehen möchte, dann bitte mit gleichem Eifer auch dafür sorgen, dass die Datensensibilität der Menschheit verstärkt wird. Sonst ist das reiner Aktionismus, dem keiner hilft.

1. Per Buttonklick die aktuelle Seite bookmarken (taggen). Diese Funktion kann derzeit tatsächlich noch nicht mehr als auch die einfache “Lesezeichen mit Javascript”-Variante.
2. Per Buttonklick zur eigenen Inbox springen. Zudem werden neue Inbox mit einem Badge-Counter im Button angezeigt.
3. Ein Button zeigt an, ob die aktuelle Seite bereits gebookmarked wurde.

Eventuell werden noch weitere Plugins oder Updates veröffentlicht.

Der nette Nebeneffekt (neben der Tatsache, kein Flash haben zu müssen):

• das Video ist komplett werbefrei

Kein nerviger Visual Studio Werbekasten drumherum, keine “Werbe-Intro”. Nix.

Update: Hey, noch eins. Für Spiegel.de