…dev, tech problems and solutions.
6 million ways to deploy, choose one
Die Aufgabe ist mit dem yuicompressor alle css files einzeln zu komprimieren.
Concatenation lasse ich weg.
Wir haben zur Auswahl 2 x mal als ant deploy und einmal die gute alte shell.
Das yuicompressor jar ist “installiert” und liegt hier:
/usr/share/ant/lib/yuicompressor.jar
Und es kann losgehen:
HTML5 bietet die Möglichkeit für custom data Attribute in HTML Elementen.
Diese beginnen mit dem Prefix data- und können danach beliebeig benannt werden.
Browser sollten diese Attribute ignorieren aber für interne Datenstrukturen sind sie sehr gut geeignet.
Zum Beispiel kann man sich in Javascript Paramter-Übergaben sparen und sich die Daten holen, die man braucht.
Das hält das Markup schön Javascript frei -im Sinne von unobtrusive.
In meinem Fall brauchte ich einen Event Tracker, der Aktionen auf dynamisch generierten Elementen aufzeichnet.
Continue reading “Event Tracker mit HTML5 custom data Attributen”
Ich bin letzte Woche über Eclipse PTI gestolpert und habe es direkt mal ausprobiert.
Einfach über den Eclipse installer über die Site: http://www.phpsrc.org/eclipse/pti/ geholt und fertig.
Was ist PTI? PTI ist ein Plugin für Eclipse PDT (zumeist), das folgende Tools in Eclipse integriert:
* PHP_CodeSniffer
* PHPUnit
* PHP Depend
* PHP Copy/Paste Detector
Ich weiss nicht ob Ihr es wußtet:
Es gibt ein feines Plugin für Google Analytics für symfony.
Kris Wallsmith sei dank.
Da kann man sich fragen, warum denn ein Plugin dafür?
Die paar Zeilen Code kopier ich doch schnell ins Layout.
Über das Plugin kann man jedoch Analytics “environment aware” einbinden.
Man will ja nicht das die Test- oder gar Entwicklungsumgebung die Messung verfälscht.
Ich habe die Zeit zwischen den Tagen mal für Quatsch genutzt:
Ich habe mal einen alten Laptop mit einem Linux versehen.
Der Laptop war ein Fujitsu Siemens mit einem 400 Mhz Celeron, 64 Mb (!) RAM und einer 4 GB Platte drin.
Da lief noch eine Windows98 drauf, was es auch tat, Winamp & Word taten es auch,
nur USB Sticks hat er nicht erkannt, die Partitionen waren etwas ungünstig und einiges andere war auch nicht optimal.
…und da sowieso alle Menschen mit Linux arbeiten sollten hab ich dann mal ein Linux dafür gesucht.
Mit 64Mb RAM ist die Auswahl da nicht so groß und ich bin sehr schnell bei DamnSmallLinux gelandet.
(-wieder mal, ja damals in der WG, der Wohnzimmerrechner vom Sperrmüll, da lief das auch schonmal, hach giedie-)
Wer kennt das nicht: man entwickelt mit JSON, will die AJAX Rückgabe kontrollieren und macht, wie gewohnt, im Firefox den Firebug auf und checkt unter Console den AJAX Request und sieht folgendes:
Nicht sehr erhellend! Total unübersichtlich! Nicht gut!
Wird JSON mit dem richtigen Header ausgeliefert, unter PHP geht der so:
header('Content-type: application/json');
Da ich ein Kontrollfreak bin ;) wollte ich mal meinen vServer monitoren.
Nach allem was ich so las, scheint wohl Munin das geeignete Tool zu sein.
Also aufgemacht und es installiert:
Munin ist Server-Client mäßig aufgebaut, ich installiere der Einfachkeit halber mal Server und Client (Node) auf der selben Maschine.
Für Debian Lenny geht das ganz einfach über apt-get:
apt-get install munin munin-node
So nun noch das Webinterface umlegen: ich mache dafür eine eigene Subdomain bei einem meiner vHosts über Plesk.
zB munin.nerdpress.org (nein, die url gibts in echt nicht)
jetzt muss noch das www Verzeichnis, welches Munin generiert umkopiert werden in das Subdomain Verzeichnis:
cp -r /var/www/munin/* /var/www/vhosts/nerdpress/subdomains/munin/httpdocs
Man sollte sich tatsächlich angewöhnen beim Entwickeln immer eine Console offen zu haben und die error_log zu beobachten.
tail -f /var/log/apache2/error_log
Bekommt man nämlich so einen Fehler in der error_log:
ALERT - configured POST variable limit exceeded - dropped variable ...
… bleibt die Seite meistens ohne Fehlerausgabe trotz E_ALL und es passieren komische Dinge.
Dann kann man schonmal eine ganze Weile damit verbringen ganz woanders zu suchen.
Mit offenem error_log wäre das nicht passiert ;).
Achtung Falle!
Benutzt man persistente Objekte in PHP, die ungefähr so aufgebaut sind, wie hier beschrieben.
class User
{
public function __construct(){}
// save object to session variable
public function __destruct()
{
$_SESSION['user'] = serialize($this);
}
// factory method
public static function factory()
{
session_start();
if(isset($_SESSION['user']) === TRUE)
{
return unserialize($_SESSION['user']);
}
return new User();
}
}
Will man mit PHP und MongoDB soetwas wie “SQL Aggregate Functions” umsetzen muss man sich etwas verbiegen.
MongoDb hat zwar eine group() function, die in etwa SQLs GROUP BY entspricht, allerdings kann man dies nicht kombinieren mit SORT oder LIMIT bzw den sort() und limit() Funktionen, da diese keinen Cursor zurückgibt sondern direkt ein Array.
Will man also sortieren und limitieren muss man sich des Map / Reduce features von MongoDB bedienen.