Bernhard Häussner
Tags: Artikel mit dem Tag «Webdev» durchstöbern

Greasemonkey Quick Search

21.04.2009, 20:10
Greasemonkey Quick Search

Greasemonkey Quick Search

Man muss ja nicht immer gleich eine Firefox-Erweiterung basteln, wenn man Firefox nur ein bisschen erweitern will. Wesentlich einfacher und schneller geht das (natürlich nur bei bestimmten Dingen) mit Bookmarklets, wie meinem Twitter Bookmarklet. Oder mit Greasemonkey, einer Firefox-Erweierung, die bestimmte Javascripts auf bestimmten Seiten ausführen kann. Ich habe mir ein kleines „Userscript“ gebastelt, dass, wann immer ich Text auf einer Webseite markiere, eine Reihe von Suchoptionen anzeigt.

Das Script registriert einen mouseup-Event-Handler und wenn Text auf der Webseite selektiert ist, öffnet dieser ein kleines Menü mit dem man dann den Text z.B. Googeln kann. Es unterstützt auch noch Google Maps, Wikipedia, und das Leo-Wörterbuch. (Ich hasse es nämlich ganze Texte mit Google zu übersetzen, wenn ich nur ein Wort nicht kenne, weil sich Englisch doch besser liest als Googles Deutsch.)

Um das Script zu benutzen muss man die Greasemonkey-Erweiterung installiert haben. Dann kann man das Script hier installieren:

Wer sich etwas mit HTML auskennt kann auch eigene Funktionen leicht nachrüsten.

Es gibt übrigens ein Verzeichnis vieler Greasemonkey-Scripte auf http://userscripts.org/

Changelog

  • 23.04.2009 - Updated to support twitter search too.
  • 09.07.2009 - Updates: tweet selected quotes and use selected text as URL.

If you're really missing something else and you think others do so too, let me know in the comments.

Kommentare: keine

Howto: Alleinstehende Unds für XHTML umwandeln

16.04.2009, 13:22
$text=preg_replace ('/&(?!amp;|quot;|nbsp;|gt;|lt;|laquo;|raquo;|copy;|reg;|#[0-9]{1,5};|#x[0-9A-F]{1,4};)/','&', $text);

In meinem Markup-Parser für diesen Blog hatte ich das Problem, dass ich zwar einzelne & in &amp; umwandeln konnte, damit ich Et-Zeichen im ganz normalen Text schreiben kann, auf der anderen Seite aber auch HTML <tags> erlauben will. Wenn ich jetzt aber über HTML schrieben will, muss ich ja auch irgendwie die größer und kleiner-Zeichen encodieren, damit nicht alles einfach vom Browser gerendert wird. Wenn ich aber ein &lt; eingebe, würde das Kaufmanns-Und sofort zu &amp; umgewandelt und so würde dann im Quelltext &amp;lt; stehen und im Text nicht < sondern &lt;. Also brauchte ich eine Methode um nur einzelne kaufmännische Unds zu finden. Das lief dann auf obigen Regulären Ausdruck hinaus.

Er ersetzt & mit &amp; nur dann, wenn dahinter keines der HTML-Entities folgt. Da es eine sehr lange Liste von benannten HTML-Entities gibt, habe ich nur die aufgenommen, die man in HTML Umwandeln muss („htmlspecialchars“), damit ihre Bedeutung erhalten bleibt und ein paar Sonderzeichen, die ich sonst nie finde. Alles andere (z.B. &eacute; für é, 文字, ...) wird ja von UTF-8 abgedeckt. Für ASCII kann man auch noch die dezimale oder hexadecimale Unicode-Notierung verwenden.

Der regexp verwendet eine Erweiterung, die Negative Vorausschau (?!x). Das ist so etwas wie ein Unter-Ausdruck, der zwischendurch überprüft wird am Text nach der aktuellen Position. Die Buchstaben, die auf den überprüften Ausdrück passen, werden nicht mit "gefressen", sie werden also nicht übersprungen, sondern nur kurz getestet. Nur wenn der Ausdruck nicht zutrifft wird von der Ursprungsposition weiter getestet. Es gibt natürlich auch noch positive Vorausschau (?=x) (die weiter laufen lässt, wenn der Ausdruck passt), sowie positive (?<=x) und negative (?<!x) Zurückschau (die jeweils den Text vor der aktuellen Position prüfen).

Das würde zum Beispiel alle Minuskeln ausgeben, die nach einem „o“ stehen: [a-z](?<=o.). Man beachte den Punkt nach dem „o“. Er steht für das gerade überlaufene Zeichen für das jetzt geprüft wird was (von der aktuellen Position hinter dem Zeichen aus gesehen) davor steht. Das bedeutet in der Rücksicht sieht sich das Zeichen nochmal selbst. Noch ein Beispiel: .(?<=o(?#comment).{5}) findet alle Zeichen 5 Positionen vor „o“.

Diese Features stehen in Ruby übrigens nur teilweise zur Verfügung.

Kommentare: keine

Schneller abbr- und acronym-Tags im Editor

01.02.2009, 21:42

Die beiden Abkürzungs-Tags abbr und acronym werden kaum verwendet, vielleicht weil man nicht ständig Definitionen schreiben will, denn wozu gibt es Abkürzungen? Glücklicherweise kann ich die Definitionen auch fast automatisch schreiben, dank einer netten (und neuen) Funktion im CMS, die ich hier vorstellen werde.

Da eine Abk. meist mehrere Bedeutungen hat und man auch nicht immer wissen kann, was sich hinter den wenigen Buchstaben verbirgt, wäre man manchmal froh um eine Erklärung. Weil aber meistens sowieso klar ist, worum es sich handelt, darf die Erklärung auch nicht im Weg stehen. Eine Lösung dafür bieten die abbr- und acronym-Tags welche im title-Attribut eine Definition enthalten können, die dann vom Browser als Tooltip angezeigt wird.

Um jetzt diese Definitionen einfach einzufügen markiert man die Abkürzung im Editor und klickt auf den Abkürzungsbutton. Mit Javascript und AJAX wird eine Liste der Abkürzungen mit den markierten Buchstaben geladen, die die verschiedenen Definitionen enthält. Aus dieser wählt man dann die passende Definition und die Tags werden in den Text eingefügt. Sollte die passende Definition nicht gefunden werden, kann man einfach einen leeren abbr- oder acronym-Block einfügen.

Ein PHP-Skript generiert im Hintergrund die Abkürzungsdatenbank. Es sammelt in den vorhandenen Blogposts die verwendeten Abkürzungen mit ihren Definitionen heraus. Damit bei einer großen Abkürzungsdatenbank nicht so viel übertragen werden muss, filtert das PHP-Skript die Abkürzungen auch gleich noch. Da der Filter optional ist und ich ein CSS-Stylesheet für die Abkürzungsliste gebastelt habe, kann man sich die XML-Datei mit den Abkürzungen auch im Browser anschauen.

Auf diese weise ist das Hinzufügen von Abkürzungen kein Problem und es erscheinen auch immer nur die Abkürzungen, die man auch wirklich verwendet.

(andere neue Features des Blogs)

  • Print-Stylesheet
  • Suchfeld-Tipp
  • jQuery 1.3 und dessen
  • Live Events bei Feed-Tag-Wahl
  • Noscript-Warnung bei Feed-Tag-Wahl
  • und ein paar interne Sachen

War wohl ein produktives Wochenende. Ich bin auch bei ein paar anderen Projekten erheblich weiter gekommen.

Kommentare: keine

Weniger Traffic durch JS, PNG und CSS optimierung

01.02.2009, 18:46
Web Compression

Web Compression

Wie erreiche ich schnellere Ladezeiten für meine Webseiten ohne ein riesiges Rechenzentrum anzumieten? Man kann mit einigen Details schon unglaublich viel sparen, denn schon kleine Veränderungen an häufig angeforderten Dateien machen viel aus. Das Aktivieren von gzip, das Komprimieren von HTML, CSS und Javascript, die Optimierung von PNG-Bildern und das Verwenden von CSS-Sprites und CDNs.

CSS-Sprites

Anstatt jedes Icon und jedes Hintergrundbildchen in einer eigenen Datei zu laden, werden alle in ein Bild gepackt. Da die meisten Besucher ohnehin einen Breitbandanschluss haben, machen für sie wenige KB Dateigrößen-Unterschied kaum etwas aus. Doch viele Requests brauchen bei jeder Verbindung viel Zeit. Für jedes Bild, dass man mit einem anderen Kombinieren kann, spart man ein Request.

Damit man nicht viele Container-Elemente ins HTML einbauen muss, lohnt es sich die Bilder geschickt zu kombinieren. Ich habe so auf meiner Homepage das Markup kein bisschen verändert, als ich vor kurzem CSS-Sprites implementiert habe. Um die Bilder zu packen, setzt man z.B. solche Muster und Verläufe, die horizontal wiederholt werden, zusammen untereinander in ein Bild und solche, die vertikal wiederholt werden, nebeneinander in ein anderes. Buttons und Ähnliches, was ohne Wiederholung gerendert wird, kann man entweder in ein einzelnes Bild geben oder sie in eines der beiden anderen einbauen.

Auf dieser Seite habe ich z.B. die kleinen Icons ganz rechts in die Kombinierte Graphik gestellt, damit links davon noch ein Bild mit fester Größe Platz findet. Außerdem sind unter dem Sprechblasen-Icon für Kommentare nur transparente Pixel, sodass in längeren Kommentaren keine anderen Hintergrundbilder auftauchen. Der Webseitenhintergrund ist gesondert als JPEG abgespeichert, da er keine Transparenz benötigt und so viel kleiner ist.

Komprimieren von Javascript, CSS und HTML

Das Komprimieren der eigentlichen Webseite ist auch nicht schwer. Da die Webseite sowieso dynamisch erstellt wird, lasse ich einfach sämtlichen zusätzlichen Whitespace im HTML weg. In den Templates bleibt alles schön übersichtlich, aber was gesendet wird, ist rund 10% kleiner.

Deutlich interessanter wird das ganze bei Javascript: Da Javascripts meistens statisch sind, habe ich mit ein einfaches Shell-Script geschrieben, welches alle Javascript-Dateien in eine Datei zusammenhängt um Reqests zu sparen und mit JSMin den Whitespace und Kommentare entfernt. So wird bei mir aus 19 kommentierten und nach Zweck getrennten Dateien mit rund 90 KB eine einzige mit 56 KB, also mit 30% Einsparung eine effektive Methode. Am einfachsten lässt es sich natürlich sparen, wenn man auf einiges an Javascript verzichtet.

#!/bin/sh
# Sammle alle js
for file in js/*; do
 cat "$file" >> javascript.js
 echo >> javascript.js # Leerzeile zwischen Scripts
done
./jsmin <javascript.js >>javascript.min.nocp.js # komprimieren
cat jslicences.txt javascript.min.nocp.js > javascript.min.js # Lizenzen hinzufügen
rm javascript.min.nocp.js

Beim CSS gilt ähnliches: Man kann alles in eine Datei packen und Whitespaces entfernen, jedoch habe ich keine automatische Komprimierung gefunden. Was man auf diversen Webseiten findet, spart normalerweise 10-20%.

PNG-Optimierung

Mit verlustfreier Komprimierung und trotzdem großer Farbpalette hat das PNG-Format Vorteile, wenn es um Icons und Graphiken geht. Doch aus der verlustfreien Komprimierung lässt sich noch mehr heraus kitzeln, indem man brute-force-mäßig die besten Kompressionsparameter verwendet. Das macht z.B. das einfach zu bedienende optipng und spart damit auch nochmal bis zu 15%.

CDN

Ein Content Delivery Network wird eher für besondere Seiten rentabel: Für Seiten mit viel statischem Content, also Bildern oder Videos. So entlastet man nicht nur den eigenen Server mit dem dynamischen Inhalt, sondern verteilt den Content über den ganzen Globus, sodass er dann nicht mehr so weit verschickt werden muss.

Für alle Seiten, die jQuery verwenden, ist es möglich sich dieses von Googles CDN hosten zu lassen. Dazu verwendet man einfach statt der URL der Javascript-Datei auf dem eigenen Server folgende: http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js und schon spart man sich wieder einige KB pro Seitenaufruf. Und auch die User sparen sich diese meistens. Da nämlich inzwischen sehr viele Seiten jQuery bei Google hosten, haben die meisten Surfer diese Datei schon im Cache des Browsers, müssen sie also nicht mehr herunterladen.

Kommentare: 3 Einträge

Umstellung auf PHP Data Objects mit Prepared Statements

10.01.2009, 09:52
PDO and Prepared Statements

PDO and Prepared Statements

Da ich die letzte Zeit offline war (und bald eine rund 15x schnellere Internet-Verbindung habe) konnte ich am Computer recht wenig machen. Deshalb habe ich ein bisschen an dieser Webseite gebastelt und die Datenbank-Verbindung auf PHP Data Objects (PDO) umgestellt. Diese unterstützen Prepared Statements, wo eine SQL-Abfrage schon geparsed werden kann, bevor konkrete Werte eingesetzt wurden, was sowohl der Sicherheit (keine SQL-Injections möglich) als auch dem Reccourcen-Verbrauch (Unveränderliches wird geparsed und gespeichert) zugute kommt.

Ich konnte mit der Umstellung auch gleich meine interne Datenverbindung zu den Views von einem Gemisch aus MySQL-Resultsets und Arrays auf nur Arrays umstellen, sodass die Views jetzt nicht mehr Umgeschrieben werden müssen, falls der PHP-Controller auch die Daten ändern will, wie zum Beispiel bei der Suche, wo die Reihenfolge der Ergebnisse von PHP berechnet wird. Da die MySQL-Abfragen dennoch optimiert sind, werden diese Arrays auch nicht zu groß.

Die Umsetzung der PDOs war nicht ganz einfach, zumal die (unvollständige) Datenbankabstraktion mehr oder weniger abwärtskompatibel sein sollte aber zusätzlich einiges an Automatik beinhalten sollte. So cacht sie jetzt nur SELECT-Abfragen, und gibt je nach Abfrage-Art (SELECT, INSERT, UPDATE) das Resultset, die Insert-ID oder die Anzahl der upgedateten Datensätze zurück. Sie verwaltet selbst die Prepared Statements, sodass nichts doppelt präpariert wird, überlässt mir damit also die Fütterung mit beliebigem SQL und kümmert sich um den Rest.

Da die PDOs auch eine relativ einfache Umsetzung von Transactions mitliefern, überlege ich mir, ob ich auch noch diese automatisch laufen lasse, jedoch habe ich noch kaum Erfahrung mit Transactions, weshalb ich damit erst nicht etwas beschäftigen muss (Rollbacks, SELECTs etc.).

Kommentare: keine
 
Χρόνογραφ
© 2008-2017 by Bernhard Häussner - Impressum - Login
Kurz-Link zur Homepage: http://1.co.de/