everflux

Der Google Admanager ( http://www.google.com/admanager/ ) ist ein kostenloses Google Produkt, um Werbebuchungen zu verwalten.

Der Google Admanger arbeitet dabei mit JavaScript um Werbemittel in die Webseite zu integrieren - z.B. auch Google Adsene. Viele Surfer benutzen inzwischen einen Werbeblocker, wie z.B. den Firefox Adblock plus - hier kommt es nun zu JavaScript Fehlermeldungen, die man vielleicht als Webmaster vermeiden möchte.

In CSI:Miami tauchte eine Waffe auf, die als DX4 "Vaporizer" bezeichnet wurde. Dabei wurde - ähnlich wie in dem ersten Youtube Live Event mit Paintballs - eine große Menge von Projektilen gleichzeitig abgeschossen um die Opfer zu vaporisieren.

Während bei Youtube die Nvidia-Maschine Farbkugeln abgeschossen hat, und dazu das Volumen eines kleinen Bullis eingenommen wurde, war die DX-4 "Vaporizer" eher handlich. Bei der Waffe werden die Treibladungen der Projektile nicht mechanisch, sondern elektrisch gezündet, was die Waffe leise und präzise macht: Keine beweglichen Teile.

Dieses "Gewehr" gibt es auch in der Realität - es kommt von der Firma Metalstorm und besticht durch extrem hohe Feuergeschwindigkeit und Durchschlagskraft. In Counter Strike ist sie übrigens nicht verfügbar.

Der IE 6 ist sicherlich schon betagt, was aber noch lange nicht bedeutet, dass er nicht noch reichlich Verwendung finden würde. Besonders wenn für eine Kundensoftware Internet Explorer 6 zwingend unterstützt werden muss, kann man sich auf viele Überraschungen gefaßt machen.

Eine davon ist der Umgang mit CSS (background) Bildern und dem Cache des Internet Explorer. Normalerweise sollte ein Webbrowser Elemente (wie z.B. Grafiken) nur einmal laden, und dann im internen Cache bereithalten, um ggf. wiederverwendet zu werden. Da häufig Elemente auf Webseiten - besonders Hintergrundgrafiken und Style Elemente - wiederkehrend sind, kann man damit Bandbreite und natürlich auch Zeit sparen.

Nichts hilft weniger als synthetische Benchmarks, wenn es darum geht, Produkte zu vergleichen. Das fängt bei Akkulaufzeit von Handys an, und hört noch lange nicht beim Spritverbrauch von Autos auf.

In der letzten Zeit sind Browser-Benchmarks total angesagt, vor allem JavaScript Benchmarks die mehr oder minder zeigen sollen, wer den längeren schnelleren Browser hat. Doch wie aussagekräftig ist das nun wirklich? Bei der Entwicklung einer browser basierten Anwendung, die stark auf Ajax (JQuery, DWR) zurückgreift, während auf dem Server eine JEE Anwendung mit Drools werkelt.

Hier hatte ich nun die Chance, ein paar "echte" Daten zu sammeln - und mir Gedanken zu machen.

Wenn man dem Gridgain JIRA Issuetracker glauben darf, dann gibts einen Tag nach Nikolaus das Gridgain 2.1 release. In den Release notes finden sich dabei die gefixten Bugs, neuen Features - und auch Einblicke ins Marketing. So gibt es Tasks wie "Google ad Gridify Websphere", die wohl über Google Adwords neue Kunden auf GridGain aufmerksam machen sollen.

Was ist interessant am neuen Release? Für mich bedeutet vor allem die Verfügbarkeit von GridGain über ein Maven Repository, dass es leichter wird, mit GridGain Projekte umzusetzen, die für ein breites Publikum leicht verfügbar und baubar sind.

Sicherlich ist auch die verbesserte Spring Integration von GridGain aufregend: Neben Annotation zum injekten von Spring Beans kann nun auch das gesamte GridGain von Spring konfiguriert und instantiiert werden.

Am meisten fasziniert mich die neue Classloader-Philosophie: Schon von Anfang an war ich von der GridGain Art begeistert: Einfach starten, und ein Programm kann im Grid laufen. Direkt aus Eclipse, Netbeans oder auch als Anwendung von der Kommandozeile, GridGain hat sich um alles transparent im Hintergrund gekümmert.  Der einzige - mehr oder minder - Haken war, dass es einen Classloader pro "Task" gab. Damit ist es schwer bis unmöglich, bestimmte Ressourcen zu teilen. Gerade "teure" Ressourcen, oder umfangreichere Datenstrukturen können so einige Programmierkniffe erforderlich machen.
Mit GridGain 2.1 soll es zukünftig möglich sein, alles, was lokal als geteilte Ressourcen verfügbar ist, auch zwischen GridGain Tasks zu teilen - wohlgemerkt auch ohne zusätzliche Deployment-Schritte.

Wer neugierig geworden ist, sollte sich einfach einmal ein Stündchen mit GridGain beschäftigen. Auch auf Javalobby/Dzone findet sich ein Artikel zum GridGain 2.1 Preview. Zur Homepage von Gridgain gehts hier: http://www.gridgain.com/

Update: GridGain 2.1 ist jetzt verfügbar.

OpenSolaris wurde von Sun in der Version 2008.11 (Codename "Jericho") released. Damit ist OpenSolaris nun zum zweiten Mal als Distribution veröffentlicht worden, und wartet direkt auch mit interessanten neuen Features auf:

• ZFS als Dateisystem und Timeslider, mit dem sich ältere Versionen von Inhalten wiederherstellen lassen (ähnlich wie Apples Time-Machine, allerdings in einer schöneren Umsetzung)
• Raid und Volumemanagement Funktionen sind ebenfalls über ZFS gelöst - womit sich ZFS auch als Fundament für Suns neue Storage Stragtegie qualifiziert
• Suspend to Ram

Mit dabei sind auch Überraschungen wie Songbird 0.5, aber auch Aktualisierungen bei altbekanntem: Gnome, Firefox, Netbeans und OpenOffice. Eine Liste aller Neuerungen gibts hier. Gerade zur Entwicklung und Betrieb von kritischen Anwendungen wird sich der Sun Stack - nicht zuletzt wegen dtrace - als sehr produktiv erweisen.

Das nächste OpenSolaris Release wird 2009.04 für das schon interessante Projekte wie crossbow zur Netzwerkvirtualisierung angekündigt wurde.

Chromium ist die Basis für Google Chrome, dem Google Browser. Während nicht weniger glauben, dass der umwerfende Erfolg von Mozilla Firefox nicht zuletzt besonders durch die zur Verfügung stehenden Plugins beinflußt wurde, hat sich Google mit Chrome über die Faktoren "Geschwindigkeit" und "Stabilität" definiert. (Und auch eine so einfache Bedienung, dass keine Mutter sich überfordert fühlt.)

Nun soll Chromium - und damit Google Chrome - auch (endlich) Erweiterungen unterstützen, Aaron in seinem Blog bekanntgab. Ein erstes Design Dokument findet sich dazu hier. Aaron als Greasemonkey Entwickler hatte bereits in seiner "Google 20% Zeit" daran gearbeitet, Greasemonkey in Chrome zu integrieren und reichlich Erfahrung, was Browser Erweiterungen angeht.

Bei dem Design der Extensions wird vor allem auf Sicherheit wert gelegt: Keine Extension soll den Browser abstürzen lassen können, Passwortfelder umbiegen oder zu einer Werbeschleuder werden können. Dazu laufen die Chrome Extensions in einer Sandbox und erhalten lediglich die Privilegien, die sie wirklich benötigen. Auch das Update soll zentral geregelt werden - über des Chrome Update, und nicht für jede Extension einzeln. Ob sich das bewährt, bleibt abzuwarten.

Gerade wenn es um sogenannten user generated content geht, ist es immer schön, wenn man eine Vorschaufunktion anbieten kann. Ein Knopf "Vorschau" ist ziemlich 1990 - es lebe das Web 2.0 mit Ajax, jQuery und vielen Hacks.

Ich hatte bereits darüber gebloggt wie man mittels jQuery und etwas Tricksen einen "Ajax Fileupload" realisert. Noch schöner ist es natürlich, wenn der User sofort Feedback bekommt, wie sein ausgewähltes Bild wohl aussehen würde. Dazu lädt man das Bild schon direkt nachdem der User eine Datei ausgewählt hat, und zeigt diese an. An Browser-Caches muss man vielleicht noch denken, aber auch hier kann JavaScript bzw. jQuery helfen.

Das Vorgehen:

1. Man hängt einen Listener an die Change Methode des Input Felds
2. Wie in meinem letzten Beitrag beschrieben wird der Upload über ein Iframe realisiert
3. Nun biegt man noch die Bild URL um und zeigt somit das Resultat an

Hier der Quellcode: (das Formular heißt "logoUploadForm", das input Feld für das Image File "logo".
Ajax Fileupload handling - und Bild URL umbiegen nach dem Upload. //handle file upload with hidden iframe
jQuery("#logoUploadForm").submit( function(data)
{
var submittingForm = jQuery( this );
var frameName = ("upload"+(new Date()).getTime());
var uploadFrame = jQuery("<iframe name=\""+frameName+"\" />");
uploadFrame.css("display", "none");
uploadFrame.load(function(data){
//submit is complete here
setTimeout(function(){
//update image
var imageDiv = jQuery("#print_logoImage");
var logoUrl = imageDiv.attr("src").split("?")[0];
imageDiv.attr("src", logoUrl+"?"+ (new Date()).getTime());
//remove hidden upload frame
uploadFrame.remove();},1000);
});
jQuery("body:first").append(uploadFrame);
//setup complete
submittingForm.attr("target", frameName);
}); Hier noch der Code zum "sofort upload": jQuery("input[name=logo]").change(function (){
jQuery("#logoUploadForm").submit();
}); Das wars - ausprobieren!

Ich hatte die Gelegenheit gleich zweimal den Google Support zu testen. Und ich kann nur sagen: Exzellent! Hört man doch immer wieder in einigen Foren und Diskussiongruppen dass es Probleme mit dem Support gibt, so kann ich lediglich berichten:

1. Keine reinen Textbausteine, wirklich passend zum Inhalt eine Antwort erhalten
2. Sehr kurze Reaktionszeiten
3. Sehr bemühte Mitarbeiter, die die jeweillige Sachlage nachvollzogen haben
4. Schnelle, Fallabschließende Klärung

Einzig eins mindert die durchweg gute Erfahrung: Für das Problem mit dem Google Admanager konnte ich nirgends eine Kontakt Adresse finden. Zwar gibt es FAQs und Google Groups, doch da es sich in meinen Augen um einen Bug handelt (oder zumindest ein Problem mit der Useability) wollte ich Google dies melden. (Ich freu mich ja auch stets, wenn mich jemand darauf hinweist, wenn etwas nicht korrekt funktioniert oder Verbesserungspotential besitzt, dass ich entwickel.)

Da half dann einfach "raten": adsense-suppport@google, adwords-support@google - wie könnte dann der admanager support at google erreichbar sein... und es tat. So schnell kann man Kunden glücklich machen, danke Google!

Vergleicht man dies mit dem Support anderer Unternehmen - wie z.B. dem Cokefridge Support - kann ich Google in der Tat nur gratulieren. So bindet man Kunden langfristig und stellt sie zufrieden!

Für die Software-Telefonanlage Asterisk wurde nun ein Skype Channel angekündigt. Channel sind bei Asterisk sozusagen die verschiedenen Anbindungswege von "Telefonleitungen" an die Asterisk Software. Dabei gibt es bisher z.B. SIP und IAX als Anbindungen an Voice-Over-IP (VoIP) Protokolle, oder CAPI um mittels ISDN Karten Asterisk an das digitale Telefonnetz zu koppeln.

Die Firma hinter Asterisk, Digium, hat nun in Kooperation mit Skype eine Anbindung für das proprietäre Skype Protokoll angekündigt, wie hier zu lesen ist. Der "Treiber" wird dabei jedoch nicht viel viele andere Asterisk Channel als OpenSource, sondern lediglich als proprietäres binär Modul angeboten. Der Hintergrund dabei ist, dass für Skype spezielle Codecs und Verschlüsselungen zum Einsatz kommen, die Skype nicht offenlegen möchte - die Lizensierung erfolgt dabei pro Kanal, das Preismodell für das Skype Asterisk Channel Modul steht jedoch noch nicht fest, bisher existiert lediglich ein Beta Programm zur Teilnahme an der Testphase.

Nicht nur ich scheine derzeit neue Formen von unerwünschtem Verhalten auf verschiedenen Seiten zu beobachten, auch Johann Burkard schreib in seinem Blog über merkwürdige Aktivitäten in seinem Forum. Er hat dabei das "Glück" lediglich mit einigen 50 Requests zu kämpfen, in meinem Fall handelte es sich um eine halbe Million. Das Ärgerliche daran ist, dass bis zu 10 Requests pro IP gleichzeitig abgeschickt wurden - das ist nicht weit von einer DoS-Attacke entfernt. Im Traffik-Wochenverlauf des betroffenen Hosts kann man gut erkennen dass es sich keinesfalls um regulären Traffik handelte. Da der UA und die IP ständig wechselte, ist es auch schwer hier entsprechende Gegenmaßnahmen zu treffen.

Was das ganze soll ist mir dabei recht unklar - die abgefragten URLs waren offensichtlich generiert, und nicht durch crawling erhalten. Entweder eine "made for Adsene" Pseudo Suchmaschine, oder jemand ist auf der Suche nach neuen E-Mail Adressen für Viagra-Spam o.ä. - das Weihnachtsgeschäft steht schließlich an.

Vielleicht wurde durch das Abschalten eines großen Spam-Hosters ja auch der Datenbestand der Bestandskunden vernichtet, und nun muss nachgeladen werden. Am Ende ist die Wirtschaftskrise womöglich noch durch Spammer, die ihre Ersparnisse verflüssigen müssen verursacht - denkbar ist ja vieles.

Die integrierte Entwicklungsumgebung Netbeans ist in Version 6.5 erschienen, einen kompletten Überblick über die Netbeans Features findet sich hier. Neben IntelliJ IDEA und Eclipse hat sich Netbeans zu einem sehr attraktiven, offenen und schnellen Produkt entwickelt, das nicht nur Java Entwicklern zu empfehlen ist.

Gerade die Unterstützung verschiedener Programmiersprachen, von JavaScript über PHP zu Python, Ruby und natürlich Java ist teilweise besser in Netbeans als in Eclipse gelöst. Zusätzliche Features lassen sich als Plugins nachinstallieren, und auch mit "der" (kommerziellen) IDE IntelliJ muss Netbeans den Vergleich keineswegs scheuen. In meinen Augen für Java Desktop Entwickler ist weiterhin der GUI Builder Matisse und als freies UML Tool zum Designen und Reverseengineering das UML Tool von Netbeans wirklich herausragend.

Eine IP hats in den letzten Tagen auf sich: 209.85.238.11 - kein reverse DNS Eintrag, deswegen kann er in den Statistiken auch nicht mit irgendwas assoziiert oder zusammengefaßt werden.

Doch wer mag dahinter stecken? Ein Crawler? Ein Blick in die Zugriffslogs gibt natürlich etwas Aufschluß:

209.85.238.11 - - [17/Nov/2008:12:45:49 +0100] "GET /feed/ HTTP/1.1" 200 4856 "-" "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html;

Auch eine Google Suche nach der entsprechenden IP erweckt den Anschein, dass darüber Google sucht ("your ip: 209.85.238.11" in den Suchergebnissen ist recht eindeutig). Letzte Sicherheit schafft dann eine Abfrage wem das zugehörige Subnetz zugeteilt ist:

NetRange:   209.85.128.0 - 209.85.255.255
CIDR:       209.85.128.0/17
NetName:    GOOGLE

Schade, dass Google hier nicht entsprechend der eigenen Hinweise handelt, die zum Verifizieren des Google Bots dienen. Und allem Anschein nach, ist es zum einen nicht nur der Feedfetcher - zum anderen, warum sollte das einen Unterschied machen?

Ach ich glaub ich mail da mal hin.

Ajax ist eine tolle Erfindung - bis auf ein paar "Kleinigkeiten". Z.B. ist nicht vorgesehen einen Dateiupload mittels Ajax zu realisieren. Da muss schon ein echtes Formular her.

Doch wenn dennoch eine Datei im Hintergrund hochgeladen werden soll - also ein "echter" Ajax File upload realisiert werden soll - greift man in die kreative Trickkiste. Die üblichen Verdächtigen für solche Aufgaben sind DWR, jQuery, Dojo. DWR bringt in der Inkarnation 3.0 dann auch Support für Ajax Fileupload, inclusive einem Mapper. Also zurück zu den Basics - was tun, wenn ein XmlHttpRequest nicht da ist? Richtig! Unsichtbares iframe nehmen.