Mein bisheriges Fazit:

Google+ ist, als wären Twitter und Facebook miteinander im Bett gewesen und das daraus resultierende Kind kam gleich smart, adrett und erwachsen auf die Welt. Gut kleine Macken hat es noch. Für mich definitiv ein gefällt mir +1.

Link + Download: http://derwebarchitekt.de/werdegang-eines-tausendsassa-ebook/

Zur Auswahl steht an einem Donnerstag Abend im Januar ein Lokal aufzusuchen, oder am Wochenende ein gemütliches Brunchen. Die Lokalität steht noch nicht fest. Vorschläge, am Besten mit kostenlosen WLAN, einfach an mich senden.  Ebenso eure Anmeldungen.

Ich würde mich sehr freuen mich regelmäßig mit Euch über Themen rund um PHP und wesentlich mehr auszutauschen.

Kontakt Jabber: nico.hofmann@jabber.org
Kontakt Email: siehe Impressum.

Ein häufiges Szenario ist, dass man lokal eine Versionsverwaltung in der Entwicklungsumgebung einsetzt, während man im Produktivsystem die Sourcen aber nicht aus dem Versionierungssystems holt, sondern ein komplettes Release hoch lädt. Wenn man jetzt nur einen kleinen Teil der Applikation ändert, geht der Entwickler dazu über die geänderten Files hoch zuladen. Dabei kann es zu diversen Fehlern führen:

• Vergessen einzelner Files
• Produktivsystem wurde dummerweise bereits geändert -> Änderungen gehen verloren
• erzeugt Fehler während der Uploads
• Dateien werden versehentlich an die falsche Stelle geladen und verwaisen
• u.s.w.

Eine Möglichkeit dies zu umgehen ist der Patch. Jeder kennt Ihn, aber nur die Wenigsten wenden dies auch auf Quellcodes an. Wir werden jetzt mit Git, zwei Branches und patch einen Patch erzeugen und einspielen. Im Grunde ist das eine genial einfache Geschichte.


laptop:Manuals nico$ mkdir Patch #Verzeichnis anlegen
laptop:Manuals nico$ cd Patch/ #in dieses Verzeichnis wechseln
laptop:Patch nico$ git init #Git Repository initialisieren
Initialized empty Git repository in /Users/nico/Workspaces/Manuals/Patch/.git/
laptop:Patch nico$ vim index.php #Datein anlegen und Bearbeiten


In die index.php schreiben wir nun folgenden Quellcode:

<?php

echo "Hallo Welt";


Speichern. Datei für Commit hinzufügen und commiten.


laptop:Patch nico$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# index.php
nothing added to commit but untracked files present (use "git add" to track)
laptop:Patch nico$ git add index.php
laptop:Patch nico$ git commit
[master (root-commit) 1b5b9e7] asdf
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 index.php
laptop:Patch nico$ git status
# On branch master
nothing to commit (working directory clean)


Der Einfachheit halber legen wir einen neuen Branch an, diesen brauchen wir später um den Patch einzuspielen.

laptop:Patch nico$ git branch version1


Wir gehen davon aus, dass der Branch version1 irgendwo produktiv läuft.

Nun wollen wir den Quellcode ändern.


laptop:Patch nico$ vim index.php

<?php

echo halloWelt();

function halloWelt()
{
return "Hallo Welt";
}


Nun noch committen:


laptop:Patch nico$ git add index.php
laptop:Patch nico$ git commit
[master f58e5d6] implement function
1 files changed, 6 insertions(+), 1 deletions(-)


Jetzt geht es daran einen Patch zu erstellen, damit wir dies tun können müssen wir die Revisionsnummern wissen, von welcher Revision auf welche der Patch erstellt werden soll. Zum Glück haben wir nur zwei und können so gesehen hier nicht viel falsch machen ;o)


laptop:Patch nico$ git log --oneline
f58e5d6 implement function
1b5b9e7 init


Der Befehl sagt uns, dass wir den Patch von der Revision 1b5b9e7 auf f58e5d6 erzeugen wollen. Dies tun wir mit folgenden Befehl.


laptop:Patch nico$ git format-patch 1b5b9e7..f58e5d6
0001-implement-function.patch


Schauen wir uns den Inhalt des Patches an:

laptop:Patch nico$ cat 0001-implement-function.patch
From f58e5d66c18c59e0e11e394dbfec0b97c1661783 Mon Sep 17 00:00:00 2001
From: Nico Hofmann mail@nico-hofmann.de
Date: Sat, 25 Sep 2010 19:57:32 +0200
Subject: [PATCH] implement function

---
index.php | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/index.php b/index.php
index f203f7f..742c38f 100644
--- a/index.php
+++ b/index.php
@@ -1,3 +1,8 @@

-echo "Hallo Welt";
+echo halloWelt();
+
+function halloWelt()
+{
+ return "Hallo Welt";
+}
--
1.7.0.2

Kann man verstehen, muss man aber nicht. Wir simulieren jetzt das entfernte System, in dem wir zurück auf den Branch version1 wechseln.


laptop:Patch nico$ git checkout version1
Switched to branch 'version1'
laptop:Patch nico$ git branch
master
* version1
laptop:Patch nico$ cat index.php


<?php

echo "Hallo Welt";


Wir machen nun den Testlauf für unseren Patch.


laptop:Patch nico$ patch -p 1 --dry-run < 0001-implement-function.patch
patching file index.php


Läuft! Das -p sagt die Verzeichnistiefe vom Patch zum Verzeichnis in dem man sich befindet an.


laptop:Patch nico$ patch -p 1 < 0001-implement-function.patch
patching file index.php
laptop:Patch nico$ cat index.php


<?php

echo halloWelt();

function halloWelt()
{
return "Hallo Welt";
}


Das wars. Der Patch wäre eingespielt! Einen solchen Patch könnte man z.B. auf dem System seines Kunden einspielen, ohne in die oben genannten Fehlerquellen zu tappen.

Die möglichen Themen klingen jedenfalls schon mal sehr spannend und eigentlich kann es nur eine erfolgreiche Veranstaltung werden.

Wir sehen uns auf der:

Die Datei liegt unter „/usr/share/vim“ und heißt „vimrc“. Geöffnet werden muss sie mit root Rechten, oder besser unter der Verwendung von sudo.

sudo vim vimrc

Man sollte jetzt die Konfigurationsdatei sehen, in der bereits einige Einträge standardmäßig beinhaltet sind. Anbei findet Ihr meine Konfigurationsdatei. Die von mir hinzugefügten Zeilen sind entsprechend gekennzeichnet.


" Configuration file for vim
set modelines=0 " CVE-2007-2438



" Normally we use vim-extensions. If you want true vi-compatibility
" remove change the following statements
set nocompatible " Use Vim defaults instead of 100% vi compatibility
set backspace=2 " more powerful backspacing

" When editing a file, always jump to the last cursor position
autocmd BufReadPost *
\ if ! exists("g:leave_my_cursor_position_alone") |
\ if line("'\"") > 0 && line ("'\"") <= line("$") |
\ exe "normal g'\"" |
\ endif |
\ endif
" myConfigEnd



" Don't write backup file if vim is being called by "crontab -e"
au BufWrite /private/tmp/crontab.* set nowritebackup
" Don't write backup file if vim is being called by "chpass"
au BufWrite /private/etc/pw.* set nowritebackup


Jedenfalls kamen die Tage zum ersten mal die Großbuchstaben im URL-Key zum Einsatz. Eigentlich war dieses Szenario getestet, trotzdem arbeitete die Applikation nicht richtig.

Der Großbuchstabe wurde ignoriert und stattdessen der Link der hinter dem Code mit dem Kleinbuchstaben lag aufgerufen.

Die Anfrage mit Key 1A entsprach also dem Datensatz hinter Key 1a

Der URL – Parameter wurde jedoch richtig verarbeitet. Ein Blick ins Model sagte mir, dass an die DB folgende Anfrage gestellt wurde.

SELECT * FROM url WHERE `key` = '1A'

Also keine Case-Insensitive Abfrage. Dennoch bringt genau diese Abfrage zwei Ergebnisse.


+-----+
| key |
+-----+
| 1a |
| 1A |
+-----+
2 rows in set (0.00 sec)


Ich habe nach wie vor keinen Schimmer warum. Sollte dies jemand lesen und wissen, so bitte ich darum mir die Lösung zu verraten. Die Lösung wäre mir auch ein Bier wert.

Zum Glück konnte ich einen kleinen Workaround schaffen. Ändert man die Abfrage minimal ab, so funktioniert es.


SELECT * FROM url WHERE `key` = binary '1A';


Jetzt kommt das erwartete Ergebnis.

Das Tutorial beschreibt die Initialisierung von ZendX_JQuery und zeigt die Verwendung an Hand des TabContainers. Es ist sicher eine gute Basis um auch weitere Komponenten über ZendX_JQuery zu erläutern. Kleiner Screenshot und der Download der Sourcen ist ebenfalls auf der Seite zu finden.

Ich hoffe es gefällt. Feedback und konstruktive Kritik ist gerne willkommen.

“Wann #flattr wohl die AGB-Änderung mit der Abtretung der Rechte am Content bekannt gibt?”

Noqqe kam wohl nicht drum herum diesen Tweet in seinem Blogpost aufzugreifen. (Danke ;o) ) Er interpretierte meinen Tweet als wohl nicht ganz ernst gemeint.

Eigentlich bin ich aber fest davon überzeugt. Vielleicht werden die AGB-Änderungen nicht so überzogen ausfallen, dennoch glaube ich fest daran das es zu Änderungen kommt, mit denen Flattr den User-Content ausschlachten wird. Warum? Wenn mir Flattr gehören würde, würde ich so handeln. Die beste Kennzahl über Content kennt nämlich nur Flattr. Sie setzt sich aus Anzahl der Spenden und natürlich der Höhe der zu erwartenden Beträge zusammen. Mit diesen Werten ist es ein leichtes ein Portal/Webkatalog mit höchst qualitativen Content zu schaffen. Ob dieser Content dann nur noch direkt gegen Bezahlung auf Flattr aufgerufen werden kann, oder in einer anderen Form, werden wir sehen. Es wird jedenfalls spannend, was aus Flattr werden wird.