Lorem Ipsum Ges.m.b.H. » Daniel Leeb

Softphone GreenJ mit neuer Heimat auf GitHub

Daniel Leeb — Wed, 11 Jan 2012 08:14:18 +0000

Letzten Monat haben wir unser Open-Source Softphone GreenJ bereits auf unserer Seite zum Download freigegeben und ihm auch eine eigene Domain – greenj.org – spendiert. GreenJ ist eine plattformunabhängige Voice-over-IP Applikation, welche es einem Webentwickler ermöglicht, mittels einer einfachen Schnittstelle, eine Webseite als Telefonsystem zu erstellen. Unser Programm bietet die nötigen Telefonfunktionen und kann eine beliebige Oberfläche durch den integrierten Browser darstellen. Mehr Informationen sowie Downloads des Programms, Quellcodes und der Dokumentation können in der Einführung zu GreenJ gefunden werden.

GreenJ auf GitHub

Um die Verfügbarkeit noch zu verbessern, befindet sich GreenJ ab sofort als Repository auf GitHub.com und kann auch von dort heruntergeladen werden.

Etwa indem man das GreenJ Repository klont:

1	$ git clone git://github.com/danleeb/GreenJ.git

In der mitgelieferten Readme, siehe auf GitHub unterhalb der Dateiliste, findet man auch eine kurze Schritt für Schritt Anleitung, um GreenJ unter Ubuntu 11.10 (32-bit Linux) zu kompilieren. Natürlich lässt sich GreenJ auch unter einer anderen Linux Distribution oder unter Windows kompilieren und verwenden. Bei Interesse einfach unsere GreenJ Produktseite besuchen.

Doctrine 2 SQL Profiler in Debugleiste

Daniel Leeb — Wed, 21 Dec 2011 15:12:17 +0000

Auch wenn es sich um ein sehr spezielles Thema handelt, möchte ich hier kurz zusammenfassen, wie man einen Doctrine 2 SQL Logger/Profiler in einer Zend Framework Umgebung umsetzen kann. Da die Kombination aus ZF und Doctrine 2 durchaus beliebt zu sein scheint, zumindest wenn man von Blogeinträgen und Tutorials im Internet ausgeht, könnte dieser Beitrag für manch einen hilfreich sein. Vorweg möchte ich auch noch auf eine praktische Lösung hinweisen, um Doctrine 2.x mit dem Zend Framework 1.x zu verbinden: Und zwar Bisna von Guilherme Blanco, zu finden in seinem GitHub Repository. Danach lässt sich Doctrine mittels Zend_Config (ini, xml, etc.) konfigurieren.

SQL Queries in der ZFDebug-Leiste

Nach der Integration von Doctrine in unsere neue Webapplikation basierend auf dem Zend Framework fehlte uns noch eine einfache Möglichkeit SQL Queries anzuzeigen. Da wir bereits ZFDebug verwenden, lag ein zusätzliches Plugin für die Ausgabe in der Debugleiste für uns nahe. ZFDebug wurde leider seit Mitte 2009 nicht mehr aktualisiert, funktioniert jedoch immer noch sehr gut, liefert hilfreiche Informationen rund um die Webapplikation und lässt sich sehr einfach erweitern. Daher werde ich hier zeigen, wie man den Doctrine 2 Profiler in einem ZFDebug Plugin verwenden kann.

Profiler

Doctrine bietet mit Doctrine\DBAL\Logging\SQLLogger bereits ein Interface um einen Logger mit einer Datenbank-Verbindung zu verknüpfen. Wir implementieren dieses Interface mit den beiden Methoden startQuery() und stopQuery() und speichern einfach alle Queries in ein Array das wir später in der Debugleiste ausgeben werden.

DoctrineExtensions/Profiler/ZFDebugProfiler.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

namespace DoctrineExtensions\Profiler;

class ZFDebugProfiler implements \Doctrine\DBAL\Logging\SQLLogger
{
public $totalTime = 0.0;
public $queries = array();

protected $_curQuery = null;

public function startQuery($sql, array $params = null, array $types = null)
{
$this->_curQuery = new \stdClass();
$this->_curQuery->sql = $sql;
$this->_curQuery->params = $params;
$this->_curQuery->time = \microtime(true);
}

public function stopQuery()
{
$executionTime = \microtime(true) - $this->_curQuery->time;
$this->totalTime += $executionTime;
$this->queries[] = array(
'time' => $executionTime,
'sql' => $this->_curQuery->sql,
'params' => $this->_curQuery->params
);
}
}

Nun müssen wir Doctrine noch mitteilen, dass unser Profiler verwendet werden soll. Wird Bisna eingesetzt, kann dies ganz einfach in der Konfiguration (hier beispielsweise in einer ini-Datei) erledigt werden:

1	resources.doctrine.dbal.connections.default.sqlLoggerClass = "DoctrineExtensions\Profiler\ZFDebugProfiler"

Im Hintergrund wird der Konfiguration der DBAL-Verbindung eine neue Instanz unseres SQL Loggers übergeben:

1
2
3

$configuration = new Doctrine\DBAL\Configuration();
$configuration->setSQLLogger(new DoctrineExtensions\Profiler\ZFDebugProfiler());
$connection = Doctrine\DBAL\DriverManager::getConnection($connectionParams, $configuration);

Natürlich lässt sich statt des ZFDebugProfilers auch einfach ein LogProfiler oder FirebugProfiler implementieren, welche die Queries direkt in eine Datei schreiben bzw. im Firebug ausgeben. Wir verwenden unseren Profiler hingegen, um die SQL Queries in einem ZFDebug Plugin aufzulisten.

ZFDebug Plugin

Nachdem der SQL Logger an Doctrine übergeben wurde, werden alle SQL Queries, deren Parameter und die Dauer der einzelnen Queries gespeichert. Ausgeben wollen wir das Ganze in unserer ZFDebug Leiste, wir erstellen also zunächst ein Plugin, indem wir das Interface ZFDebug_Controller_Plugin_Debug_Plugin_Interface implementieren:

ZFDebug/Controller/Plugin/Debug/Plugin/Doctrine.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

class ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine implements ZFDebug_Controller_Plugin_Debug_Plugin_Interface
{
protected $_identifier = 'doctrine';
protected $_profilers = array();

public function __construct(array $options = array())
{
if (isset($options['profiler'])) {
$this->_profilers = $options['profiler'];
}
if (!is_array($this->_profilers)) {
$this->_profilers = array($this->_profilers);
}
}

public function getIdentifier()
{
return $this->_identifier;
}

public function getTab()
{
if (!count($this->_profilers)) {
return 'No Profiler';
}
foreach ($this->_profilers as $profiler) {
$profilerInfo[] = count($profiler->queries) . ' in ' . round($profiler->totalTime * 1000, 2) . ' ms';
}
return implode(' / ', $profilerInfo);
}

public function getPanel()
{
$html = '';
if (!count($this->_profilers)) {
return $html . 'No Profiler';
}
foreach ($this->_profilers as $index => $profiler) {
$html .= '

Profiler ['.$index.']

;

foreach

(

$profiler

queries

$query

)

{

$html

[' . round($query['time'] * 1000, 2) . ' ms] ';
$html .= $this->highlightSql(htmlspecialchars($query['sql']));

if (!empty($query['params'])) {
$html .= '
bindings:' . $this->listBindings($query['params']);
}
$html .= '

;

}

$html

';
}
return $html;
}

private function listBindings($bindings)
{
$html = '

;

foreach

(

$bindings

$binding

)

{

$html

';
if (is_array($binding)) {
$html .= $this->listBindings($binding);
} else {
$html .= $binding;
}
$html .= '

;

}

return

$html

';
}

private function highlightSql($sql)
{
$statements = array('SELECT', 'UPDATE', 'INSERT', 'FROM', 'WHERE',
'LEFT JOIN', 'JOIN', 'ORDER BY', 'GROUP BY',
'OFFSET', 'LIMIT', 'SET', 'VALUES');
return preg_replace('/('.implode('|', $statements).')/', '\1', $sql);
}
}

Da wir auch ein wenig Wert auf die Formatierung legen, ist der Code des Plugins etwas umfangreicher ausgefallen. Wichtig sind die getTab() und getPanel() Methoden, welche die HTML Ausgabe für den Titel des Plugins in der Debugleiste und für detaillierte Informationen im Panel beim Ausklappen des Plugins zurückgeben.

Nun muss das Plugin noch in den Optionen von ZFDebug eingetragen werden. Beim Bootstrapping der Applikation erstellen wir das ZFDebug_Controller_Plugin_Debug und registrieren es beim Frontcontroller. Zunächst gehen wir jedoch sicher, dass die Doctrine Ressource bereits existiert und erstellen eine Liste der Profiler aller DBAL-Verbindungen, die wir anschließend unserem Plugin übergeben. In den ZFDebug Optionen tragen wir unter Plugins unsere Klasse ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine mit dessen Konfiguration ein:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$this->bootstrap('doctrine');
$container = $this->getResource('doctrine');
$profilers = array();
foreach ($container->getConnectionNames() as $connName) {
$profiler = $container->getConnection($connName)->getConfiguration()->getSQLLogger();
if ($profiler instanceof DoctrineExtensions\Profiler\ZFDebugProfiler) {
$profilers[$connName] = $profiler;
}
}
$options = array(
'plugins' => array(
'ZFDebug_Controller_Plugin_Debug_Plugin_Doctrine' => array(
'profiler' => $profilers
)
)
);
$debug = new ZFDebug_Controller_Plugin_Debug($options);
$this->bootstrap('frontController');
$this->getResource('frontController')->registerPlugin($debug);

Nun lassen sich alle Queries von Doctrine und deren Performance übersichtlich in ZFDebug anzeigen. Zu beachten ist vielleicht, falls man Bisna verwendet, dass durch den Aufruf von $container->getConnection($name)… die DBAL-Verbindungen tatsächlich gestartet werden. Ansonsten würden sie nicht unbedingt bereits beim Bootstrapping, sondern erst bei der ersten Verwendung gestartet. Da ZFDebug aber sowieso nur im Debug-Modus laufen sollte, muss diesbezüglich nur auf den Unterschied zwischen Debug- und Production-Modus geachtet werden.

Verwendete Versionen:
- Zend Framework 1.11.11
- Doctrine 2.1.5
- ZFDebug 1.5

Zend Framework 2

Da ZF2 wohl noch einige Monate auf sich warten lässt, kann man im Moment leider noch keine vollwertige Webapplikation darauf aufbauen. Spätestens zum Release wird aber eine Umstellung fällig werden, sollte die zweite Version das einhalten was sie momentan verspricht. Es wäre daher interessant zu wissen, ob ZFDebug auch für ZF2 erscheint, was wenn man sich die Projektaktivität ansieht eher zu bezweifeln ist – oder es vielversprechende Alternativen dazu gibt?

Der eigene Javascript Event Handler

Daniel Leeb — Mon, 17 Jan 2011 09:09:15 +0000

Besonders bei umfangreicheren Javascript-Umsetzungen zahlt es sich aus, eine kleine Bibliothek aus Hilfs-Funktionen und -Objekten zu entwickeln. Vorausgesetzt man möchte auf die Integration größerer Bibliotheken verzichten, muss man sich selbst um gewisse Grundfunktionen kümmern. Zu diesen zähle ich auch einen Event Handler.
Im folgenden möchte ich eine einfache Möglichkeit zeigen, einen solchen vielseitig einsetzbaren Event Handler umzusetzen.

Vorab einige Anforderungen an einen Event Handler:
- Jedes Objekt soll als Event Handler agieren können: Erweiterung (bzw. “Vererbung”) um Event Handler Funktionalität.
- Beliebige Events.
- Mehrere Listener bzw. Callbacks sollen an ein Event gebunden werden können.
- Benutzerdefinierte Daten beim Auslösen eines Events an die Listener übergeben.
- Übergabe von Rückgabewerten der Listener an das Event.

Implementierung

Zunächst ist es sinnvoll, aber natürlich nicht notwendig, ein Objekt zu erzeugen, welches als eine Art Namespace agiert, zum Beispiel:

1	window.li = window.li \|\| {};

Ein leeres Objekt namens EventListener dient zum Identifizieren der Listener. Siehe dazu addListener() und deleteListener() weiter unten.

1	li.EventListener = function() {}

Nun kommt das eigentliche Basis-Objekt, welches später von Objekten “geerbt” wird.

1	li.BaseObject = function() {}

Wir verwenden das Javascript “prototype” Objekt, wodurch Instanzen von BaseObject um Methoden von dessen prototype erweitert werden.
Die erste Methode, defaults(), ist eine kleine Hilfsfunktion, um etwas komfortabler Default-Werte von Funktionsparametern setzen zu können.

1
2
3
4
5
6

li.BaseObject.prototype = {
defaults: function(parameter, defaultValue, type) {
if (typeof type === 'undefined')
return (typeof parameter !== 'undefined') ? parameter : defaultValue;
return (typeof parameter === type) ? parameter : defaultValue;
},

Nun kommen die eigentlichen Methoden des Event Handlers:
Mit der Methode addListener() kann einem Event mittels Name eine Callback-Funktion zugewiesen werden:

1
2
3
4
5
6
7
8
9
10

addListener: function(eventName, listenerCallback) {
this.__listeners = this.defaults(this.__listeners, {});
var listenerObj = new li.EventListener();
this.__listeners[eventName] = this.defaults(this.__listeners[eventName], []);
this.__listeners[eventName].push({
listener: listenerObj,
callback: listenerCallback
});
return listenerObj;
},

Um Events auszulösen und somit alle Listeners aufzurufen muss einfach die Methode trigger() mit dem entsprechenden Eventnamen aufgerufen werden. Optional können hier beliebige Daten an die Listener übergeben werden. Die Rückgabewerte der Callback-Funktionen der Listener werden als Array zurückgegeben.

1
2
3
4
5
6
7
8
9
10

trigger: function(eventName, data) {
this.__listeners = this.defaults(this.__listeners, {});
data = this.defaults(data, {});
if (typeof this.__listeners[eventName] === 'undefined') return;
var eventListeners = this.__listeners[eventName], retArr = [];
for (var index in eventListeners) {
retArr.push(eventListeners[index].callback.call(this, data));
}
return retArr;
},

Die folgenden Methoden dienen nun noch zum Entfernen von Listener: entweder alle Listener, alle Listener eines Events oder ein bestimmter Listener (addListener() gibt ein EventListener Objekt zurück, welches zum Identifizieren von Listeners dient und der deleteListener() Methode übergeben werden kann).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

deleteAllListeners: function() {
this.__listeners = {};
},
deleteListeners: function(eventName) {
this.__listeners = this.defaults(this.__listeners, {});
if (typeof this.__listeners[eventName] === 'undefined') return;
delete this.__listeners[eventName];
},
deleteListener: function(listenerObj) {
this.__listeners = this.defaults(this.__listeners, {});
for (var index in this.__listeners) {
for (var i in this.__listeners[index]) {
if (this.__listeners[index][i].listener === listenerObj) {
this.__listeners[index].splice(i, 1);
return true;
}
}
}
return false;
}
}

Um ein Objekt, im folgenden li.MyObject, um diesen Event Handler zu erweitern kann etwa die extend()-Methode von jQuery verwendet werden:

1	jQuery.extend(li.MyObject.prototype, li.BaseObject.prototype);

Beispiel

Mit diesen wenigen Zeilen Code erhält man einen simplen aber vielseitig einsetzbaren Event Handler. Zum Abschluss ein kurzer Beispielcode bei dem das Objekt li.MyObject wie oben beschrieben um li.BaseObject erweitert wurde und somit als Event Handler agieren kann:

1
2
3
4
5
6
7
8

Event Handler – Sourcecode

Integration von Doctrine in eine modulbasierte Zend Anwendung

Daniel Leeb — Fri, 22 Oct 2010 10:49:47 +0000

Eines der erste Dinge, die mir als Einsteiger in das Zend Framework auffielen, war die Vernachlässigung des M in Zends MVC Implementation. Views und Controller, wenngleich sie erst nach einer kleinen Einarbeitungszeit wirklich verständlich werden, bieten genau das, was eine komplexe Webanwendung benötigt. Jedoch fehlt eine wirklich umfangreiche Implementation von Models in Zend. Auch wenn diese im Moment in Arbeit ist, haben wir uns deshalb für Doctrine entschieden, welches genau diese Lücke für uns füllen soll. Es ist jedoch eine Herausforderung für sich, Doctrine in seine Zend Anwendung zu integrieren, zumal wir eine modulbasierte Struktur zugrunde liegen haben.

Doctrine und Module

Die folgende Anleitung soll eine Möglichkeit zeigen, wie sich Doctrine und eine modulbasierte Zend Applikation verbinden lassen. Da Tutorials meist nur die simple Integration von Doctrine und Zend in einer “einfachen” Anwendung ohne Module zeigen, möchte ich hier besonders auf Module eingehen. Natürlich könnte man auch, unabhängig von Modulen, die Models einfach in einen gemeinsamen Ordner unterbringen. Dadurch geht jedoch ein zentraler Aspekt des modularen Aufbaus verloren und wir haben uns deshalb um eine andere Lösung bemüht. Des Weiteren muss angemerkt werden, dass in unserem Fall die Models eines Modules auch Beziehungen zu Models anderer Module haben können. Eine unabhängige Behandlung ist daher nicht möglich. Wäre dies nicht der Fall, könnte man auch einfach jedes Modul als eigenständige Anwendung betrachten und die oben erwähnten Tutorials zu Rate ziehen.
Im Zuge der Anleitung werde ich auch gleich auf einige Vorzüge von Doctrine eingehen, empfehle jedoch die Doctrine-Einführung durchzuarbeiten.

Doctrine’s YAML Schema

Um seine Models von Doctrine generieren zu lassen, bietet sich das Erstellen einer YAML-Schema-Datei an. Diese kann entweder per Hand geschrieben oder aus einer existierenden Datenbank generiert werden:

1 2	Doctrine_Manager::connection("mysql://user:pw@localhost/dbname"); Doctrine::generateYamlFromDb('schema.yml');

Anschließend sollte das Schema jedoch nochmals überarbeitet werden, um eventuelle Anpassungen wie Klassennamen, Beziehungen, etc. durchzuführen. Es empfiehlt sich das Erstellen eines PHP Scripts für alle Doctrine Operationen. Auf die Erstellung eines solchen Skripts möchte ich jedoch hier nicht weiter eingehen, da dies bereits in der Doctrine Einführung und in diversen Tutorials ausführlich behandelt wird.

Ist das YAML-Schema erst einmal ausgearbeitet, lässt sich später auch die Datenbank daraus generieren. Änderungen im Datenbankdesign können also fortan direkt im YAML-Schema erfolgen, unabhängig von dem verwendeten Datenbanksystem.
Aus der YAML-Datei lässt sich jedoch auch das Doctrine Model generieren, welches wir in unserer Webanwendung verwenden wollen. Hierfür müssen wir einige Einstellungen vornehmen, die Doctrine bei der Generierung berücksichtigen soll:

1
2
3
4
5
6
7
8

$options = array(
'suffix' => '.php',
'baseClassPrefix' => 'Orm_',
'pearStyle' => true,
'baseClassesDirectory' => '',
'generateTableClasses' => true
);
Doctrine::generateModelsFromYaml('schema.yml', 'models', $options);

Der Eintrag 'baseClassPrefix' => 'Orm_' erweitert den Klassennamen unserer Model-Basisklassen und erzeugt durch 'pearStyle' => true die Model-Datei im Ordner ‘Orm’ ohne jedoch Orm_ im Dateinamen – eben im PEAR-Namensstil. Durch 'baseClassesDirectory' => '' verzichten wir auf das ‘generated’ Verzeichnis und mittels 'generateTableClasses' werden zusätzlich Klassen, abgeleitet von Doctrine_Table, erzeugt.
Nehmen wir an, in unserer Datenbank bzw. im YAML-Schema befinden sich die Tabellen “user” und “appointment”. Der obige Code würde dann folgendes Erzeugen:

models\Orm\Appointment.php class Orm_Appointment extends Doctrine_Record
models\Orm\User.php class Orm_User extends Doctrine_Record
models\Appointment.php class Appointment extends Orm_Appointment
models\AppointmentTable.php class AppointmentTable extends Doctrine_Table
models\User.php class User extends Orm_User
models\UserTable.php class UserTable extends Doctrine_Table

Unsere Webanwendung ist in folgender (etwas vereinfachter) Verzeichnisstruktur aufgebaut, wobei die eben aufgelisteten Dateien im Ordner /doctrine generiert werden:

Nun kommt ein etwas unschöner Vorgang, denn wir müssen die eben generierten Dateien in die Model-Ordner unserer Module verschieben. Um beim obigen Beispiel zu bleiben, verschieben wir User.php und UserTable.php in das ‘Core’ Modul, also etwa modules/core/models/. Appointment.php und AppointmentTable.php verschieben wir nach modules/calendar/models/. Und den Orm Ordner können wir als Ganzes in unserem Application-Verzeichnis platzieren (wichtig ist nur, dass der Zend Autoloader die Dateien findet, mehr dazu gleich).

Autoloader

Da wir nun erfolgreich unsere Models generiert haben, können wir unserer Webapplikation mitteilen, wo diese zu finden sind. Folgende Methode kann zur Initialisierung von Doctrine in der Bootstrap Klasse (application/bootstrap.php) platziert werden:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public function _initDoctrine()
{
$this->getApplication()->getAutoloader()
->registerNamespace('Doctrine')
->registerNamespace('Orm')
->pushAutoloader(array('Doctrine', 'autoload'))
->pushAutoloader(array('Doctrine', 'modelsAutoload'));

$manager = Doctrine_Manager::getInstance();
$manager->setAttribute(Doctrine::ATTR_MODEL_LOADING, Doctrine::MODEL_LOADING_CONSERVATIVE)
$manager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true)
$manager->connection("mysql://user:pw@localhost/dbname", "conn");

Doctrine::loadModels(array( APPLICATION_PATH . '/modules/core/models',
APPLICATION_PATH . '/modules/calendar/models'));
}

registerNamespace('Doctrine') sorgt dafür, dass die Doctrine-Klasse in Doctrine.php geladen werden kann, vorausgesetzt der Pfad zur Doctrine-Library wurde als Include-Pfad, zum Beispiel in der index.php, gesetzt. Sollte Doctrine.php direkt inkludiert worden sein, kann man auf diese Zeile auch verzichten. registerNamespace('Orm') ermöglicht das Autoloading der zuvor generierten Basisklassen Orm_User und Orm_Appointment. Der Ordner Orm muss dabei in einem inkludierten Pfad liegen, sodass er dem Zend Autoloader bekannt ist. Mittels den beiden pushAutoloader() Aufrufen registrieren wir die autoload() und modelsAutoload() Callbacks von Doctrine. Erstere ist für die Doctrine-Klassen zuständig, zweitere für unsere Models. Nun konfigurieren wir den Doctrine_Manager, sodass dieser unsere Models bei Bedarf (Conservative) und unsere Tables (UserTable, AppointmentTable) lädt. Mittels Doctrine::loadModels() teilen wir Doctrine die Pfade mit, in denen sich die Model-Dateien befinden. In der Praxis kann der Aufruf natürlich auch entweder in den speziellen Modul-Bootstrap-Klassen erfolgen, oder eine Methode verwendet werden, welche alle Model-Pfade der Module zurückgibt.
Nun können wir die erstellten Model Klassen beliebig um eigene Methoden erweitern und in unseren Controller_Actions und Views verwenden:

1
2
3
4
5
6
7
8
9

// class User extends Doctrine_Record
$user = new User();
$user->username = "Admin";
$user->myMethod(); // eigene Methode in User Klasse
$user->save();

// UserTable
$usertable = Doctrine::getTable("User");
$usertable->myTableMethod(); // eigene Methode in UserTable Klasse

Falls sich das Schema ändert, sollte in den meisten Fällen ein Updaten des Orm Ordners ausreichen, dessen Dateien wir ohnehin nicht verändern wollen.

Schlusswort

Ob diese Variante, Doctrine in die eigene Zend Anwendung zu integrieren geeignet ist, hängt stark von den Anforderungen ab. Wir haben uns für diese Methode entschlossen, da wir zwar Abhängigkeiten zwischen den Models der Module haben, jedoch trotzdem eine prinzipielle Trennung vornehmen wollten. Jeder Teilbereich unseres Datenbankschemas wird in einer eigenen YAML-Schema-Datei definiert (also etwa core.yml und calendar.yml). Man könnte auch auf Packages (siehe Doctrine’s YAML Beschreibung) zurückgreifen, jedoch ändert sich dadurch die Namensgebung und eine weitere abstrakte Klasse wird für die Models erstellt. Der Aufwand die generierten Model-Dateien in die entsprechenden Ordner zu verschieben hält sich jedoch in Grenzen, weswegen wir uns für diese Variante entschieden haben.

Verwendete Versionen:
Zend Framework 1.10.8
Doctrine 1.2

IP-Telefonie und der G.711-Codec

Daniel Leeb — Tue, 28 Sep 2010 09:33:47 +0000

In der Internet-Telefonie werden Codecs (Coder und Decoder) verwendet um analoge Audiosignale für die Übertragung über das Internet zu digitalisieren. Der ITU-Standard (Internationale Fernmeldeunion) G.711 ist ein Sprachcodec, welcher in der klassischen Festnetz-Telefonie und IP-Telefonie eingesetzt wird.
Die Sprachqualität des G.711 Codec entspricht derjenigen von ISDN. Hierbei erfolgt eine sogenannte PCM-Kodierung (Pulse Code Modulation) ohne Komprimierung mit einer Netto-Bitrate von 64 kbps. Durch die sehr gute Sprachqualität gilt er auch als Maßstab für Voice over IP.

Der Codec im Test

Um die benötigte Bandbreite zu ermitteln, haben wir ein simples Softphone basierend auf der pjsip-Bibliothek entwickelt. In unseren Tests, bei denen ein Gespräch mit offenen Kanälen in beide Richtungen aufgebaut wurde, ergab sich eine Datenübertragung von 89 kbps sowohl ausgehend (Upload) als auch eingehend (Download). Die erhöhte Bitrate ergibt sich durch die bei VoIP verwendeten Protokolle RTP (Real-Time Transport Protocol) und UDP (User Datagram Protocol) zur Übertragung der IP-Pakete. Es empfiehlt sich jedoch im Praxiseinsatz einen Puffer von 10% (etwa für das optionale RTCP-Protokoll) einzurechnen, also etwa 100 kbps für ein laufendes Gespräch zu kalkulieren. Sinkt die Leistung unter 89 kbps zeigt der Test, dass sofort eine spürbare Verzögerung eintritt, da die angestauten Pakete in diesem Fall in einer Warteschlange abgearbeitet werden.
Vorteil von G.711: Sehr gute Sprachqualität.
Nachteil: Benötigt durch die fehlende Komprimierung eine höhere Datenübertragungsrate im Vergleich zu anderen Codecs.

Alternativen

GSM: Für Mobiltelefonie – es stehen verschiedene GSM-Sprachcodecs zur Verfügung, welche sich alle im Bereich von 20 kbps bewegen.
G.726: Von der ITU beschriebener Codec zur Komprimierung von Sprache in digitale Signale. Verwendet Bitraten von 16 bis 40 kbps.
Speex: Freier Audiocodec, optimiert auf Komprimierung von Audiodaten, die menschliche Sprache enthalten.

Die Wahl des richtigen Codec

Benötigt man eine gute Sprachqualität, die sich nicht vom Festnetz unterscheidet, oder steht eine ausreichende Bandbreite zur Verfügung empfiehlt sich der Einsatz des G.711 Codecs für die IP-Telefonie. Eine Übersicht der Sprachqualität von Codecs bietet der Mean Opinion Score (MOS) – von 1 (mangelhaft) bis 5 (ausgezeichnet):

Codec (Datenrate)	MOS-Wert
G.711 (64 kbps)	4,1
G.722 (64 kbps)	4,5
G.726 (32 kbps)	3,85
G.723.1 (5,3 kbps)	3,65
G.723.1 (6,3 kbps)	3,9
G.729 (8 kbps)	3,92
G.729a (8 kbps)	3,7

Quelle: Wikipedia

Rechteverwaltung – Alle Benutzer sind gleich, manche sind gleicher

Daniel Leeb — Mon, 06 Sep 2010 10:32:17 +0000

Jede Seite mit mehreren Benutzern benötigt eine mehr oder weniger umfangreiche Rechteverwaltung. Ein simples Blog unterscheidet bereits zwischen Autoren, registrierten Benutzern und einfachen Gästen. ACL – Access Control List – ist eine Technik mit der sich ein flexibles Rechtesystem aufbauen lässt, indem festgelegt wird, welcher Benutzer welche Aktionen ausführen darf. Die hier vorgestellte Variante ist nur eine von vielen Möglichkeiten ein ACL-System aufzubauen.

ACL Aufbau

Das System besteht aus Benutzern, Rollen, Regeln sowie speziellen Bedingungen (Assertions). Einem Benutzer sollen mehrere Rollen aber auch einzelne Regeln zugewiesen werden können. Rollen bestehen aus einer Sammlung von Regeln. Eine Regel bestimmt, welche Aktion erlaubt oder nicht erlaubt ist oder ob eine bestimmte Bedingung erfüllt werden muss. Eine Bedingung kann in diesem Zusammenhang etwa die Einschränkung auf eine bestimmte IP oder ein eingeschränkter Zeitraum sein.

ACL in der Datenbank

Folgende Tabellen werden in der Datenbank benötigt:

user
role
- name: z.B. “Admin”, “Guest”, …
- parent_id: Falls die Rolle die Regeln einer anderen Rolle erben soll.
- order: Werden einem Benutzer mehrere Rollen zugewiesen, bestimmt diese Rangordnung die Reihenfolge und damit Priorität der jeweiligen Rolle.
rule
- resource: Entspricht einem Controller; z.B.: „site“.
- pivilege: Entspricht einer Action eines Controllers; z.B.: „index“.
- assert_id: Falls die Regeln an eine Bedingung gebunden ist.
- permission: Wird die jeweilige Aktion erlaubt oder verweigert; z.B.: „Allow“/“Deny“.
Tabellen zur Zuweisung von Regeln: user_roles, user_rules und role_rules.
assert
- Classname: Der Name der Klasse, in der die Bedingung geprüft wird; z.B.: „IPAssertion“

ACL und das Zend Framework

Das Zend PHP Framework bietet mit der Zend_Acl Klasse bereits eine Implementierung eines ACL-Systems. Im Folgenden möchte ich die wichtigsten Funktionen vorstellen:

// Instanz von Zend_Acl mit welcher die Rechteverwaltung realisiert wird.

$acl = new Zend_Acl();
// Hinzufügen einer Rolle ‚guest‘.

$acl->addRole(new Zend_Acl_Role(‘guest’));
// Der Benutzer (hier repräsentiert als Rolle) ‚myUser‘ erbt die Rolle ‚guest‘.

//  Auf dieselbe Weise können auch Rollen Eigenschaften anderer Rollen erben.

$acl->addRole(new Zend_Acl_Role(‘myUser’), ‘guest’);
// Hinzufügen einer Ressource (Controller)

$acl->add(new Zend_Acl_Resource(‘site’));
// Deny All

$acl->deny(null);

// Setzen der Zugriffsrechte von Rollen auf Ressourcen/Privilegien mit Bedingung:

//  *Assertion sind Klassen, welche Zend_Acl_Assert_Interface implementieren.

$acl->allow(‘guest’, ‘site’, ‘index’);

$acl->deny(‘guest’, ‘site’, null, IPAssertion);

$acl->allow(‘myUser’, ‘site’, ‘index’, TimeAssertion);

$acl->allow(‘myUser’, ‘site’);
// Abfrage eines Zugriffsrechts

$acl->isAllowed(‘myUser’, ‘site’, ‘index’);

ACL im Einsatz

Um das oben beschriebene System zu implementieren muss also zunächst eine Zend_Acl Instanz erstellt werden. Dieser werden alle Rollen aus der Datenbank übergeben. Der Benutzer wird ebenfalls angelegt und mit seinen zugewiesenen Rollen übergeben (als zusätzlicher Parameter von addRole(), sodass deren Eigenschaften dem Benutzer vererbt werden). Anschließend werden die Ressourcen erstellt und übergeben. Mittels deny(null) können alle Zugriffe verhindert werden. Nun folgen die Regel-Zuweisungen via allow() und deny() Aufrufe, wodurch den Rollen die jeweiligen Ressourcen, Privilegien und Bedingungen zugewiesen werden. Beim Aufruf eines Controllers und dessen Action kann nun das Zugriffsrecht mittels der Methode isAllowed() überprüft werden.

Passwörter richtig speichern

Daniel Leeb — Fri, 03 Sep 2010 10:46:15 +0000

Bei der Benutzerverwaltung sollte man von Anfang an Wert auf eine sichere Verwahrung der Passwörter legen. Natürlich ist zu beachten, Passwörter im Klartext weder in die Datenbank oder in ein Log zu speichern noch per Email zu senden. Bevor das Benutzerpasswort gespeichert wird, kann es etwa mit einem Hash-Algorithmus verschlüsselt werden. Im Gegensatz zum Encodieren können aus Hashwerten die originalen Nachrichten bzw. Passwörter nicht wiederhergestellt werden. Bei der Benutzerauthentifizierung muss also zunächst der Hashwert des übergebenen Passworts erzeugt und dann mit dem Hashwert des Passworts aus der Datenbank verglichen werden. Es stehen verschiedene Hash-Algorithmen zur Verfügung, welche sich z.B. in Hinsicht auf Größe und Sicherheit unterscheiden. Die bekannte Funktion MD5 gilt mittlerweile als unsicher, da es zwei verschiedene Nachrichten m1 und m2 geben kann, für die gilt md5(m1)=md5(m2). Auch wenn dies hinsichtlich Passwörter nicht bedeutet, dass die Hashwerte der Passwörter unsicher sind, kann man auf Alternativen zurückgreifen: etwa SHA256 oder SHA512 (256 Bit bzw. 512 Bit großer Hashwert, im Gegensatz zum 128 Bit großen MD5-Hash).

Beispiel einer PHP-Funktion, welche einen SHA256-Hashwert zurückgibt:

1	hash_hmac('sha256', $salt . ':' . $password, $appSalt);

Sicher versalzen

Um die gespeicherten Passwörter noch sicherer zu verwahren, empfiehlt sich das “beimischen” eines zufallsgenerierten Wertes, genannt Salt. Dieser wird dem Passwort angehängt und dann der Hashfunktion übergeben. Für jeden Benutzer sollte ein eigener Salt generiert und neben dem Hashcode des Passworts in der Datenbank gespeichert werden. Das hat den Vorteil, dass vorberechnete Hashtabellen eines Angreifers nutzlos sind, da jedes Passwort mit einem eigenen Salt versehen wurde. Zusätzlich kann noch ein globaler Anwendungs-Schlüssel (Application Salt) beigestreut werden.

Beispielfunktion zum Generieren eines Salts (PHP-Code):

1
2
3
4
5
6
7
8

function genSalt($saltLen) {
$chars64 = "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
$salt = "";
for ($i=0;$i < $saltLen;$i++) {
$salt .= substr($chars64, rand()%64, 1);
}
return $salt;
}

Starke Passwörter

Alle hier aufgeführten Maßnahmen betreffen jedoch nur die Speicherung von Passwörtern. Sicher sind Passwörter nur, wenn der Benutzer selbst ein starkes Passwort eingibt. Um dies zu erreichen können bei der Passworteingabe folgende Regeln definiert werden: Eine Kombination aus Buchstaben, Zahlen und Sonderzeichen sowie eine Mindestlänge des Passworts. Eine Anzeige der Passwortstärke während der Eingabe (etwa mittels Auswertung via Javascript) kann dem Benutzer darüber hinaus helfen, ein sicheres Passwort zu wählen.

Links:
Hashfunktionen

Der Projekt-Werkzeugkasten

Daniel Leeb — Fri, 20 Aug 2010 11:19:18 +0000

Möchte man heutzutage ein Projekt realisieren, kann man auf eine Vielzahl von Planungs-, Projekt-, Dokumentations- und Entwicklungstools zurückgreifen. Obwohl Bleistift und Papier nach wie vor ihre Daseinsberechtigung besitzen, erleichtern diverse Werkzeuge die tägliche Projektarbeit ungemein.

Am Anfang war die Planung

Neben Office-Lösungen (MS Office, OpenOffice) empfiehlt sich anfangs der Einsatz einer Mind-Mapping-Software (FreeMind MindMeister.com) um eine erste Projektübersicht zu erstellen und Brain-Stormings festzuhalten.

Verwendet man MySQL und möchte seine Datenbank importieren oder ein erstelltes Design exportieren, bietet sich MySQL Workbench (Nachfolger des DB Designers) an.

Diagramm-/UML-Modeller eignen sich gut um etwa die Struktur einer Anwendung oder Use-Cases grafisch darzustellen. MS Visio ist ein bekannter Vertreter dieser Werkzeuge; mit yEd wartet hingegen ein sehr simples und vor allem freies Tool. Eine kostenpflichtige, dafür sehr umfangreiche Software in diesem Bereich wäre Visual Paradigm.

Projekte managen

Besonders für die Entwicklung von Projekten in einem Team sollte eine Projektmanagement-Software verwendet werden. Hier können Vorgänge zeitlich koordiniert und Ressourcen (Mitarbeiter, Kosten, etc.) zugeteilt werden. MS Project oder OpenWorkbench verwenden die Darstellung mittels Gantt-Diagramm (weitere Ansätze: Netzplan, Projektstrukturplan). Sehr umfangreiche Open-Source-Lösungen im Bereich Projektmanagement sind Endeavour Software Project Management oder Project Open.

Schöner coden

Um effizient im Team arbeiten zu können, besonders wenn Programmierarbeit koordiniert werden muss, hilft der Einsatz einer Versionsverwaltungssoftware. Zwei vielversprechende Kandidaten in diesem Bereich sind GIT und SVN. Wobei es hier eine große Auswahl an robusten Open-Source-Lösungen gibt.

Auch der Einsatz einer Code-Dokumentationssoftware ist empfehlenswert, um auch die technischen Aspekte des Projektes strukturiert festzuhalten. Die freie Software DoxyGen bietet eine Vielzahl an Funktionen und unterstützt die meisten Programmiersprachen.

Bug-Tracking-Tools helfen hingegen, wie der Name es bereits verrät, Fehler zu protokollieren und gezielt auszubessern. Mantis ist ein populäres Web-basiertes System, welches auch als Projektmanagementsoftware eingesetzt werden kann. Ebenfalls empfehlenswert in diesem Bereich: Bugzilla. Beide Bug Tracker sind frei erhältlich.

Ein zentrales Entwicklerwerkzeug, möchte man sich nicht mit Notepad & Co begnügen, ist die integrierte Entwicklungsumgebung (IDE): Mein persönlicher Favorit für C++ Programmierer unter Windows: MS Visual Studio (in der Express Version gratis erhältlich). Weitere freie IDEs für verschiedene Programmiersprachen: Eclipse, NetBeans, Code::Blocks (C/C++).

Einstieg in PHP Frameworks

Daniel Leeb — Mon, 16 Aug 2010 07:40:33 +0000

Will man nicht wertvolle Entwicklungszeit in ein eigenes PHP Framework stecken, hat man eine Reihe von freien Frameworks zur Auswahl. In diesem Artikel möchte ich keinen direkten Vergleich der Frameworks anstellen. Diese gibt es im Überfluss im Web zu finden – einige davon habe ich in den Links am Ende des Artikels aufgelistet. Statt dessen möchte ich den Einstieg in die drei beliebten Frameworks Zend, Yii und CodeIgniter beschreiben, sowie anschließend einen kurzen Blick darauf werfen wie gut sich große Webanwendungen im jeweiligen PHP Framework umsetzen lassen.

Erste Schritte

Zunächst versucht man sich naturgemäß einen ersten Überblick über die verschiedenen freien PHP Frameworks mittels Vergleich-Listen und subjektiven, sich oft auch widersprechenden Artikeln im Netz zu machen. Nachdem man nun festgestellt hat, dass sich die beliebteren PHP Frameworks offensichtlich in ihren Features kaum unterscheiden bzw. die Vergleiche einem bei der Entscheidung nicht viel weiterhelfen, sucht man deren Webseiten auf. Hier bekommt man einen ersten Überblick über Dokumentation, Community sowie Aufbau einer einfachen Webanwendung.

Yii PHP Framework

URL: http://www.yiiframework.com/
Yii bietet meines Erachtens eine umfangreiche und übersichtliche Dokumentation, eine einfache Einführung mittels des beliebten Blog-Tutorials sowie eine Sammlung von User-Tutorials die unterschiedlichste Themengebiete abdeckt. Da es sich um ein junges Framework handelt, steht im Vergleich eine relativ kleine, aber schnell wachsende Community dahinter.

Nach dem Downloaden und Entpacken des Frameworks kann sofort via ‘yiic’ Tool (Konsolenbefehl) ein neues Projekt erstellt werden:

1	yiic webapp path/to/webroot

Im gewählten Verzeichnis wird eine bereits relativ umfangreiche Webanwendung erstellt, auf deren Basis man sofort mit der eigenen Implementierung beginnen kann. Sogar eine einfache Benutzeranmeldung, welche leicht erweiterbar ist, findet sich im eben erstellten Projekt. Aktiviert man das Modul Gii in der Applikations-Konfiguration steht einem ein praktisches Tool zur automatischen Code-Erstellung von Model, Controller, CRUD-Operationen (Create, read, update und delete) und Modulen zur Verfügung.

Zend Framework

URL: http://framework.zend.com/
Das am weitesten verbreitete Framework hat zwar eine sehr umfangreiche Dokumentation, ist aber was den Einstieg betrifft etwas unübersichtlich. Im Gegensatz zum sehr strikt Objekt-orientiert aufgebauten Yii Framework bei dem die Struktur eines Projektes schnell erkannt werden kann. Dafür bietet es eine enorme Flexibilität und hat eine sehr aktive Community.

Auch hier kann ein neues Projekt mittels eines Konsolenbefehls erstellt werden:

1	zf create project path/to/webroot

Das dabei erstellte Projekt kümmert sich jedoch ‘nur’ um die notwendigsten Vorgänge und ist daher um einiges schlanker im Vergleich zur Yii – Webanwendung. Mittels des zf – Befehls können weitere Aktionen im aktuellen Projekt ausgeführt werden: Layouts aktivieren, Datenbank-Adapter einrichten, Model erstellen, usw. Durch den flexiblen Aufbau von Zend muss man mit einer etwas längeren Einarbeitungszeit in das Framework rechnen.

CodeIgniter

URL: http://www.codeigniter.com/
CodeIgniter wird im Gegensatz zu den anderen Projekten einfach in ein Verzeichnis entpackt ohne explizit ein eigenes Projekt zu erstellen. Unter dem Ordner application befinden sich die wichtigsten Elemente (Models, Views, Controllers). Durch den simplen Aufbau des Frameworks lassen sich schnell einfache Webanwendungen auch ohne viel Erfahrung in PHP realisieren. Jedoch ist der Umfang von CodeIgniter etwas bescheidener als bei den anderen Frameworks. Auf der Webseite findet man eine gute Dokumentation sowie einige von der Community erstellte Tutorials.

Large-scale Applications

Alle Frameworks bieten eine HMVC-Architektur, wodurch eine klare und einfache Trennung ermöglicht wird – etwa in Frontend und Backend-Bereich. Die bekannte e-Commerce Software Magento (basiert auf dem Zend Framework) setzt zum Beispiel sehr stark auf einen modul-basierten Aufbau. Was die Performance betrifft haben das Yii Framework sowie CodeIgniter wiederrum die Nase vorne, vertraut man den diversen im Web veröffentlichten Benchmarks. Aufgrund des größeren Funktionsumfangs würde ich mich hier entweder für Yii oder Zend entscheiden.

Fazit

Der Einstieg in das Yii PHP Framework ist mir persönlich leichter gefallen, da die Struktur klarer ist und die Webanwendung durch das überlegte Objekt-orientierte Design sehr leicht erweiterbar ist. Das Zend Framework hat jedoch den Vorteil, dass es flexibler und trotz des enormen Umfangs sehr gut dokumentiert ist. Dafür sorgt allein die weite Verbreitung und große Community des Projektes. CodeIgniter bietet sich für die schnelle Entwicklung von kleineren Webanwendungen an.

http://www.phpframeworks.com/
http://www.bestwebframeworks.com/php/
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP_2

Der eigene VoIP-Server

Daniel Leeb — Fri, 06 Aug 2010 09:45:35 +0000

Beschäftigt man sich mit Voice over IP (VoIP) fällt schnell der Name Asterisk. Die Open-Source-Software ist gerade hinsichtlich Flexibilität und Kosten erste Anlaufstelle für die eigene VoIP Umgebung. Flexibilität bietet Asterisk hinsichtlich Skalierbarkeit sowie Einsatzmöglichkeiten – etwa als eigenständiger PBX (Telefonanlage), als VoIP Gateway oder Anrufbeantworter.

Der Server als Telefonanlage oder Gateway

Die Kostenfrage stellt sich jedoch zunächst bei der Server- und Client-Hardware. Hier können größere Investitionen anstehen, möchte man seine eigene Telefonanlage mit PSTN-Anschluss (Festnetz) realisieren, die über eine Heimlösung hinausgeht. Stattdessen eignet sich eine Anbindung an einen VoIP- bzw. SIP-Provider (oft im Angebot eines ISP). Der eigene Asterisk-Server dient nur mehr als Gateway zwischen diesem und den internen Endgeräten, wodurch auch die Hardwareanforderungen an den Server rapide sinken. Die benötigte Bandbreite richtet sich nach der Anzahl an gleichzeitig geführten Gesprächen (bei guter Gesprächsqualität beginnend bei 100Kbps (up und down); bei 20 parallelen Gesprächen etwa 2Mbps).

Die Wahl der Endgeräte

Bei den Endgeräten muss man Kosten entweder für IP-Telefone, herkömmliche analoge Telefone oder aber PC + Headset einrechnen. Zusätzlich benötigt man für die PC-Lösung ein Softphone, also eine Client-Software, welche als Telefon fungiert. Dafür bietet diese Variante die höchste Flexibilität und lässt sich auch auf die eigenen Bedürfnisse anpassen.

Fazit

Investitionskosten für die VoIP Lösung hängen also stark von den eigenen Anforderungen ab. Und schlussendlich muss man bedenken, dass ein wesentlicher Bestandteil im System, nämlich die VoIP Server Software, mit Asterisk in einer freien Open-Source-Lösung existiert.
Ist das System einmal im Einsatz bietet es je nach VoIP-Provider günstige Tarife ins Festnetz sowie gratis Telefonie über das Internet.

Links:
Asterisk
Bandbreiten-Rechner