Bei Amazon hat mal as Kindle Kunde automatisch einen 5GB großen Cloud Speicher für persönliche Dokumente. Ich lasse mir hier zum beispiel über die Kindle-Mail-Adresse jeden Morgen die taz sowie diverse RSS-Feeds aus dem Google Reader auf meinen Kindle schicken.

Das ist soweit alles ganz toll, müllt einem aber auch schnell den Speicherplatz zu. Dann heißt es regelmäßig bei Amazon einloggen und die Dokumente löschen. Das Problem hier ist aber: aufgrund der dafür von Amazon verwendeten Ajax-Funktion und der fehlenden Möglichkeit mehrere Dokumente für das Löschen zu markieren, schafft man, wenn man richtig schnell ist, gerade 3 Dokumente am Stück zu löschen, dann lädt sich die Seite automatisch wieder neu. Dann muss man wieder die entsprechenden Dokumente über die Suchfunktion aufrufen usw…

Eher nervtötend diese Arbeit. Ich war schon drauf und dran selber nachzudenken, wie man das besser hinbekommt.
Kompletten Beitrag lesen …

Ein Webbrowser von Google? Ich war ja von Anfang an sehr skeptisch, Google weiß auch so schon genug
über jeden von uns, als dass man noch mehr Informationen freiwillig von sich preisgeben sollte. Und mit einem solchen Browser öffnet man dem Suchmaschinenbetreiber ja wirklich alle Tore.

Nach der anfänglichen Euphorie kamen auch schnell Meldungen über Sicherheits- und Stabilitätsprobleme des Chrome Browsers von Google auf.

Ganz oben auf der Bedenklichkeistskala steht dabei, dass Google jedem ausgelieferten Browser eine eindeutige Identifikationsnummer mitgibt, die dieser dann an Google zurückübermittelt. Würde so etwas von Microsoft bekannt, gäbe es einen Aufstand in der Web-Welt.

Die Übermittlung dieser Nummer lässt sich zwar ausschalten, jedoch ist dies nicht gerade trivial und vor allem für den Durschnittsuser gar nicht so leicht nachzuvollziehen.

Der Browser legt die sogenannte Chrome-ID in der Datei “Local State” ab. Auf Windows-XP-Rechnern ist sie unter

C:\Dokumente und Einstellungen\NUTZER\Lokale Einstellungen\
   Anwendungsdaten\Google\Chrome\User Data

zu finden, auf Windows-Vista-PCs unter

C:\Users\NUTZER\AppData\Local\Google\Chrome\User Data

(Laufwerksbuchstaben und “NUTZER” müssen angepasst werden.

Sobald der Chrome-Browser geschlossen ist, kann die Datei “Local State” editiert werden. Unter dem Abschnitt “user_experience_metrics” speichert Google Chrome die Kennnummern des Browsers – in den Zeilen “client_id” und “client_id_timestamp”.
Nun einfach die Zahlen in den Anführungszeichen löschen. Der obere Eintrag sieht dann wie folgt aus: “client_id”: “”,
Nach dem Speichern der Datei muss diese schreibgeschützt werden, sonst schreibt Chrome die Browser-ID nämlich wieder neu in die Datei. Jedoch legt der Google Browser auch noch eine Kopie dieser Datei an, wenn er mal keinen Zugriff auf  selbige hat. Deshalb sollte man die Datei einfach selbst nochmal als “Local State.tmp” in das selbe Verzeichnis kopieren und auch diese gegen Schreiben sichern.

Laut Golem, von wo diese Anleitung auch stammt zeigten Stichproben, dass der Browser auch nach Entfernen der Chrome-ID wie gewohnt funktionierte und es keine Einschränkungen gab.

Nicht verhindert wird mit diesem Eingriff jedoch, dass der Browser aufgerufene URLs an Google übermittelt. Dies kann aber in den Browsereinstellungen deaktiviert werden. Dazu einfach in den Suchmaschinenoptionen den Haken “Automatische Vorschläge zur Vervollständigung der in die Adressleiste eingegebenen Suchanfragen und URLs” entfernen.

Warum man bei Golem das Übermitteln von Suchanfragen an Google verhindern möchte ist mir zwar nich ganz klar aber gut.

Fazit ist: Finger weg vom Google Browser, wenn man nicht in dessen Eingeweiden herumpfuschen will. Und auch sonst bleibt ein ungutes Gefühl, weiß man doch nicht, welche Tricks sich Google noch hat einfallen lassen.

weitere Berichte:

hier hier hier hier

Weil ich kürzlich darüber gestolpert bin, dass ein XML-Dokument einen CDATA-Abschnitt enthielt, der weiterverarbeitet werden sollte und dieser aber von SimpleXML nicht zurückgeliefert wurde:

simplexml_load_string($xmlraw, 'SimpleXMLElement', LIBXML_NOCDATA);

Dies funktioniert seit der PHP Version 5.1.0. Alle früheren Versionen ignorieren < ![CDATA[...]]> Abschnitte im XML-File.

Mehr Informationen zu den LibXML-Funktionen gibt es hier.

Für alle AJAX – Anhänger gibt es heute im Weihnachtskalender von Entwickler-Press das Buch “Das Dojo Toolkit” aus der Reihe “schnell+kompakt” als PDF zum kostenlosen Download.

Die gedruckte Ausgabe des 124 seitigen Büchleins kostet normal 7,90€.

Das Buch liefer, wie der Name schon sagt, einen kompakten und schnellen Überblick über das komplett in JavaScript geschriebene AJAX-Toolkit.

Auf Entwickler-Press gibt es bis Weihnachten jeden Tag ein kostenloses Buch im PDF-Format zum Download.

Hierbei muss nur beim Besuch der Seite dafür gesorgt sein, dass Java-Script und Pop-Ups erlaubt sind. In einem Layer öffnet sich ein Adventskalender, und jeden Tag bis zum 24.12. verbirgt sich hinter der entsprechenden Tür ein PDF mit einem kostenlosen Buch des Verlags.

Bei den Büchern handelt es sich um aktuelle Ausgaben und nicht um veraltete Versionen, tägliches Reinschauen lohnt also!

Hierbei nimmt der Zeitgewinn mit wachsender Größe des Ergebnis-Sets zu.

Der Grund ist, dass ein

SELECT UNION

tatsächlich einem

SELECT UNION DISTINCT

entspricht. Dies bedeutet, dass MySQL sicherstellt, dass jede Ergebniszeile nur einmal in der Ergebnismenge vorhanden ist. Für diese Überprüfung wird in einer temporären Ergebnistabelle ein Key erstellt, der den Hash-Wert der jweiligen Ergebniszeile darstellt. Es wird dann dafür gesorgt, dass diese Hash-Werte unique sind. Die Berechnung der Hash-Werte kostet natürlich entsprechend Rechenzeit.

Demnach ist es performanter explizit ein

UNION ALL

auszuführen, wenn man nicht auf die Einzigartigkeit der Datensätze im Ergebnis angewiesen ist, oder auf Grund der Datenstruktur so oder so keine Ergebniszeilen doppelt vorkommen können.

SELECT column FROM table WHER a=1 OR b=2

Schneller:

SELECT column FROM table WHERE a=1

UNION

SELECT column FROM table WHERE b=2

Hintergrund: Bei Oder-Bedingungen im WHERE -Teil des Statements nutzt MySQL keine Keys, sondern führt einen Full-Table-Scan aus. Hingegen können die Keys beim UNION SELECT benutzt werden und MySQL muss im günstigsten Fall nicht in die eigentlichen Daten schauen, um die zutreffenden Datenätze zurückzuliefern.

Ein Grund, warum ich bisher InnoDB skeptisch gegenüberstand, war neben der drei bis fünfach höheren Datenmenge von InnoDB-Tabellen gegenüber myIsam-Tabellen, das “Problem”, dass bei InnoDB alle Tabellen einer Datenbank in einer einzigen Datei abgelegt werden.

Dies macht es sehr schwer, mal eben eine einzelne Tabelle zu Backuppen oder im laufenden Betrieb wieder herzustellen. Muss man ein Backup einspielen, so müssen entsprechend alle Zugriffe auf die Tabellen der Datenbank unterbrochen werden und die entsprechenden Anwendungen heruntergefahren werden, was unter Umständen nich praktikabel ist.

Wie ich aber dem Dem offiziellen MySQL 5-Handbuch entnehmen konnte, gibt es durchaus die Möglichkeit unter InnoDB, ähnlich, wie bei myIsam tabellenbasierte Dateien zu benutzen. Das ganze wird dann Multi-Tablespaces genannt und ist recht einfach zu konfigurieren.

Man muss lediglich in der

my.cnf

im Abschnitt

[mysqld]

folgende Zeile einfügen:

bbinnodb_file_per_table

Nach dem Neustart des MySQL-Servers wird für jede neu angelegte Tabelle eine Datei nach dem Schema

tbl_name.ibd

angelegt.

Dies ähnelt dem Verhalten von MyIsam, mit dem Unterschied, dass bei InnoDB sowohl die eigentlichen Daten, als auch die Indizes in diese eine Datei geschrieben werden, wohingegen MyIsam hierfür jeweils eine eigene Datei anlegt.

Die

tbl_name.frm

wird analog bei beiden Storage Engines angelegt.

Bereits bestehende Tabellen verbleiben jedoch nach dem Neustart in der bisherigen Struktur, sprich in einer Datei für die jeweilige Datenbank, nur neu angelegte Tabellen werden in separate Dateien geschrieben. Umgekehrt bleiben diese Tabellen auch in einzelnen Dateien, wenn man die die Verwendung von Multi-Tablespaces wieder deaktiviert.
Auch hiernach werden nur die neu angelegten Tabellen wieder in die “globale” Shared-Space-Datei geschrieben.
Auf diese Weise kann man natürlich auch nur bestimmte Tabellen in einzelne Dateien schreiben und den “Rest” wie gewohnt in einer Datei vorhalten.

Da ich zur Zeit oft vor dem Problem stehe, dass ich aufgrund von vielen Einzeltabellen, die unter einer Merge-Table liegen, zu viele geöffnete Dateien habe, überlege ich, ob es in diesem Falle nicht sinnvoll wäre diese Tabellen in InnoDB in einen Shared-Tablespace zu legen…

[UPDATE]

Gute Idee, doch leider funktioniert die MERGE-Storage-Engine nicht mit InnoDB. Tja, schade.