Da es für CentOS keine Packages für node.js gibt, hier eine kleine Anleitung, um sich zu behelfen:

Kurze Anleitung
Einfach das von mir gebaute RPM  für node.js in Version 0.8.18 verwenden(falls die Architektur passt):

wget http://www.basis42.de/wp-content/uploads/2013/01/nodejs-0.8.18-1.el6.x86_64.rpm
sudo yum localinstall --nogpgcheck nodejs-0.8.18-1.el6.x86_64.rpm

Umfassende Anleitung
Vermutlich will man ja nicht auf immer bei der Version 0.8.18 bleiben, deshalb muss man früher oder später (idealerweise) ein eigenes RPM bauen.

So geht’s:

Als Superuser ggf. noch benötigte Packages installieren und Verzeichnisse vorbereiten:

sudo su
yum install rpm-build gcc-c++ redhat-rpm-config openssl-devel zlib-devel
mkdir /root/rpmbuild
mkdir /root/rpmbuild/SOURCES
mkdir /root/rpmbuild/SPECS

Anschließend den node.js Source runterladen(hier am Beispiel von Version 0.8.18) und im Verzeichnis /root/rpmbuild/SOURCES ablegen:

wget http://nodejs.org/dist/v0.8.18/node-v0.8.18.tar.gz -O /root/rpmbuild/SOURCES/node-v0.8.18.tar.gz

Was uns jetzt noch fehlt ist ein SPEC File zum bauen des RPM. Solches finden wir auf github unter https://github.com/kazuhisya/nodejs-rpm (wieder am Beispiel von Version 0.8.18):

wget --no-check-certificate https://raw.github.com/kazuhisya/nodejs-rpm/v0.8.18/nodejs.spec -O /root/rpmbuild/SPECS/nodejs.spec

Jetzt kann’s losgehen:

rpmbuild -ba /root/rpmbuild/SPECS/nodejs.spec

Wenn alles gut gegangen ist, kann node.js installiert werden:

sudo yum localinstall --nogpgcheck /root/rpmbuild/RPMS/x86_64/nodejs-0.8.18-1.el6.x86_64.rpm

Da ich im Rahmen eines Techtalks versucht habe, meinen Kollegen das Javascript-basierte Buildtool grunt.js näher zu bringen, will ich zumindest die Sildes und den Beispielcode hier verlinken, um die Informationen allgemein verfügbar zu machen.

Der Vortrag gibt anhand eines Beispiels eine Einführung wie man grunt.js in (nicht nur) JavaScript-Projekten nutzen und für die eigenen Belange konfigurieren und erweitern kann. zusätzlich spannend für mich war meine erste Mal reveal.js, einem JavaScript Framework für Präsentationen. Wenn ich das so mit PowerPoint vergleiche, dann hat das Bauen der Präsentation damit auf jeden Fall 10x mehr Spaß gemacht, unbedingt ausprobieren :-).

Da ich heute ein Gespräch mit einem Kollegen hinsichtlich der Gefahren von fremd-gehosteten Ads hatte und ich bezüglich dessen nun schon mal den Großteil fein aufgeschieben habe hiermal meine Gedanken dazu:

Im konkreten Fall ging es um Ads die über DFP ge-scheduled werden. Generell sind im Grundsatz 2 Arten denkbar, eine Ad welches über ein Netzwerk, wie z.B. DFP, ausgeliefert wird, eingebunden werden kann:

Zum einen direkt in die Seite eingebettet oder aber in einem speziellen IFrame, welches lediglich einen kleinen html Schnipsel enthält, der für das Einbinden des Ads notwendig ist. Wobei bei ersterer Variante relativ offensichtlich ist, das das im Prinzip recht böse ist, wir laden uns (meist) Javascript in den Scope unseres Dokuments, welches dann auf Cookies, DOM, etc. zugreifen kann.
Auch ein IFrame bringt wenig Besserung, wenn  z.B. ein Ad über die im IFrame geladene Datei http://www.example.com/ads/iframe.html geladen wird, so hat man gegenüber einer direkten Einbindung unter z.B. http://www.example.com/seite.html zumindest hinsichtlich der Cookies nichts gewonnen, das DOM der einbettenden Seite ist allerdings geschützt. Für die Cookies hilft hier das setzen eines Cookies mit vollem Pfad oder aber auf verschiedene Subdomains z.B. www.example.com, während Ads über eine eigene Subdomain ausgeliefert werden, z.B. ads.example.com.

Nehmen wir also an wir sind auf des selben Domain, haben unsere Cookies nicht auf eine speziellen Pfad gebunden und die böse Cookieräuberin ist in unserem Fall Frau Google. Google ihrerseits spannt nun generell ein iframe auf, in etwas so:

1
2

<iframe frameborder="0" scrolling="no" src="http://googleads.g.doubleclick.net/pagead/ads?...">
</iframe>

So das sich jedweder Code den ein Ad mitbringt eben nicht in www.example.com Scope befindet, sondern im googleads.g.doubleclick.net, sprich die Böse Cookieräuberin kann lediglich Google beklauen und in dessen DOM rumfuhrwerken.

Heißt soviel wie: Nur Google kann uns unmittelbar Schaden zufügen, da wir deren Code in unseren Scope laden. Ein böses Ad müsste eine Schwachstelle im Googlecode nutzen um über diese in unseren Scope bzw. in unser DOM zu gelangen. Sollte jemand eben solche Schwachstelle im Google code finden, dann könnte in der Tat ein IFrame den Zugriff auf unser DOM erschweren. Die (www.example.com)Cookies sind dann aber bereits gestohlen, sollten wir nicht obige Hinweise befolgt haben.

Der hauptsächliche Grund warum man Ads in ein IFrame lädt ist Performance, sprich das entkoppeln der Ladevorgänge von Seite und Ads. Löst man dies allerdings anderweitig, bleibt meiner Ansicht nicht mehr viel von der Herrlichkeit der IFrames. Hierfür gibt es Lösungen wie writeCapture, welche ein Lazy Loading von z.B. Ads erlauben, wobei dies ein eigenes, sehr spannendes Thema ist.

Falls mein Gedankenkonstrukt irgendwo löchrig erscheint, freue ich mich selbverständlich über ein Fachgespräch :-).