Kategorien
Fundstücke Musikalien

Bohemian Rhapsody

Respekt…!

Kategorien
Aktuelles

Biometrie im Bad Orber Freibad: Provinzposse oder zukunftsweisendes Verfahren?

Im Laufe dieser Woche erfuhr ich via Buschfunk von der Nachricht, dass das Zuganssystem des Freischwimmbades im altehrwürdigen Kurort Bad Orb mit einem Fingerabdruck-Verfahren ausgestattet wurde.

Nicht nur der Buschfunk funktioniert, natürlich wurde das System überparteilich behandelt und erhielt mediale Aufmerksamkeit (Hessischer Rundfunk, Frankfurter Rundschau, Frankfurter Neue Presse, auch Sat1 meldete sich).

Die Stadt will vorrangig vermeiden, dass die personengebundenen Dauerkarten missbraucht werden und durch den Zaun an andere Schwimmbadbesucher durchgereicht werden. Außerdem sollen Personalkosten an Kassen reduziert werden. Eigentlich eine gute Idee, oder?

Der Einsatz des Fingerabdrucks jedoch weckte den Datenschutz-Drachen. Politiker, Juristen, Datenschützer melden sich zu Wort und kritisieren das Verfahren.

Die Diskussion amüsiert mich ein wenig, denn sie verläuft öffentlich derzeit sehr oberflächlich. Bei all dem Gerede vermisse ich eine klare Beschreibung, wie es technisch denn nun genau funktioniert. Ein Indiz fand ich in einem Artikel, darin hieß es, dass die Daten schließlich nicht zentral gespeichert, sondern nur auf dem Chip vorliegen würden. Das sagt nicht viel.

Wie wäre es garantiert nicht sauber?
Auf dem Chip sind (womöglich im Klartext) die Merkmale vom Fingerabdruck des Trägers gespeichert. Bei der Prüfung am Fingerabdruck-Scanner fragt dieser die gescannten Merkmale bei einen Server an, auf welchem die Merkmale auch gespeichert sind.

So bitte nicht. Wenn die Technik so funktioniert, schlage ich mich sofort auf die Seite der Datenschützer. Provinzposse.

Wie wäre es sauber?
Auf dem Chip ist ein Hashwert für die Merkmale des Trägers gespeichert. Bei der Prüfung am Fingerabdruck-Scanner bildet das Gerät ebenso einen Hashwert der Merkmale und vergleicht das Ergebnis mit dem Chip. Die Merkmale selbst werden gar nicht gespeichert, sondern nur zur Ermittlung des Hashwerts verwendet.

Falls dies hinter dem Verfahren steht, gut gemacht! So gehts, so ist es in Ordnung.

Ein Hashwert kann natürlich geknackt werden, damit hätte man das System gehackt, aber dennoch nicht die dem Hash zugrunde liegenden Daten des Fingerabdrucks. Was hätte der Angreifer davon? Er hätte Zugang ins Freibad! Dafür lohnen sich hochkomplexe Hashwert-Attacken…

Zuletzt im Hackerclub:
Hacker-Azubi zum Chef:
„Nun versuchen wir uns an Biometrie. Was hacken wir jetzt? Den Personalausweis? Bankensysteme? Zugriffe zu High-Security-Gebäuden? Atomkraftwerke? Rüstungskonzerne?“

Chef:
„Nein…viel besser… wir hacken das Bad Orber Freibad!“

Wem das zuviel Sarkasmus ist… sorry! 😉

Ich würde mich freuen, wenn das Verfahren etwas genauer beschrieben wird. Dann könnte man sich ein gesundes Bild davon machen, ob es sich hierbei um eine Provinzposse oder um ein zukunftsweisendes Verfahren handelt.

Kategorien
Computer PHP Tutorials

[:de]Modultests mit PHPUnit[:en]Unittests with PHPUnit

[:de]Eine kleine private Exkursion in die Tiefen einer OpenSource-Gemeinde hat mir mal wieder vor Augen gehalten, wie man sich das Coder-Dasein durch die Verwendung von Modultests („UnitTests“) vereinfachen kann. Nicht jeder benutzt sie, jeder sollte. In der PHP-Programmierung ist die ideale Software hierfür PHPUnit.

Die Software wird im GitHub verteilt, ist gut dokumentiert, weit verbreitet (guckt mal in viele größere Klassen rein, man stolpert oft über den einen oder anderen Testordner) und genießt hohes Ansehen bei Entwicklern. Die Software ist auch im PEAR und kann darüber installiert werden (ein paar Dependencies gibt es für zusätzliche Funktionen).

An einem einfachen Beispiel möchte ich die grundsätzliche Verfahrensweise demonstrieren. Angenommen, in einem PHP-Projekt gibt es irgendwo eine Funktion, welche den Ostersonntag eines Jahres bestimmt. Der Einfachheit halber nennen wir sie easter($jahr). So eine Funktion könnte beispielsweise eingebunden sein, wenn es um die Errechnung von verschiedenen Feiertage geht – somit könnte sie eine gewisse Kritikalität im Projekt innehaben. Wie testet man nun so eine Funktion mit PHPUnit?

Ich steige hier mal mitten in PHPUnit ein:

[php]
require_once ‚includes/functions.php‘;

class EasterTest extends PHPUnit_Framework_TestCase {
public function testEasterOk() {
$easter2011 = easter(2011);
$this->assertEquals($easter2011, gmmktime(0,0,0,4,24,2011));
}

public function testEasterFalse() {
$easter2011 = easter(2011);
$this->assertNotEquals($easter2011, gmmktime(0,0,0,12,24,2011));
}
}
[/php]

Zuerst habe einen Verweis auf das PHP-Script (hier: functions.php), in welcher die Funktion easter($Jahr) enthalten ist. Dann generiere ich eine Klasse („EasterTest“), welche PHPUnit erweitert. In dieser Klasse sind zwei Tests abgelegt:

  • Ein Gutfall (ist der 24.4.2011 Ostern?)
  • Ein Schlechtfall (ist der 24.12.2011 Ostern?)

Jetzt kommt der trockene theoretische Teil…
Hier geht es nicht etwa darum, das Ergebnis zu finden – das hat man ohnehin schneller mit einem Blick auf dem Kalender. Vielmehr ist es Ziel, das Ergebnis der Funktion mit einem definierten „Wunschergebnis“ zu vergleichen. Ich weiß, dass der 24.04. dieses Jahr der Ostersonntag ist… und ich weiß, dass es der 24.12. definitiv nicht ist.

PHPUnit – wie auch fast alle andere Software in diesem Umfeld – arbeitet mit „Assertions“ (Behauptungen). Es gibt eine Sammlung von einfachen Funktionen, welche solche Assertions in verschiedenen Konstrukten ermöglichen – angefangen von Vergleichsoperationen wie die im Beispiel verwendeten assertEquals und assertNotEquals über False/True-Varianten, Array-Prüfern und einigem anderen.

Ist dies viel Arbeit?
Bitte urteilt selbst.. ein einfacher Test ist fix geschrieben. Nicht schwer, oder?

Zurück zur Praxis.
Wie kann man nun die Tests auswerten? Am einfachsten über die Shell. Und hier ist es nun wirklich egal, ob man sich in einer Dosbox, Bash oder wo auch immer aufhält.

[shell]
D:\htdocs\>phpunit EasterTest.php
PHPUnit 3.5.11 by Sebastian Bergmann.

..

Time: 0 seconds, Memory: 3.75Mb

OK (2 tests, 2 assertions)
[/shell]

PHPUnit kann auch andere Output-Formate, beispielsweise das TAP-Format („Test Anything Protocol“), JSON, XML und andere.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
ok 1 – EasterTest::testEasterOk
ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Wenn ich nun in einem Test einen Fehler habe, sieht das so aus (ich habe hierfür den Test 1 so verändert, dass die Behauptung lautet, der 23.04.2011 wäre Ostersonntag – ist aber in Wirklichkeit der Samstag davor):

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
not ok 1 – Failure: EasterTest::testEasterOk

message: ‚Failed asserting that <integer:1303516800> matches expected <integer:1303603200>.‘
severity: fail
data:
got: 1303516800
expected: 1303603200

ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Wenn ich nun – wann und warum auch immer – an der eigentlichen Funktion wieder mal arbeite, dann habe ich weiterhin meine gespeicherten Tests. Wenn diese mir also Mist zurückgeben, ist entweder mein Test falsch (eher unwahrscheinlich), oder meine veränderte Funktion ist nicht ok… und genau darum geht es hier. Modultests wie dieser hier machen den Code deutlich stabiler und nachträgliche Arbeiten, Erweiterungen etc. erheblich einfacher.

Und wenn es mal Bugs gibt… schreibt einen Test und fixt dann den Bug!

[:en]A little private encounter with the community of an open source project opened my eyes, how good and easy life as a coder is if you’re working with unit tests. Not everybody uses them, but everybody should. For php programming the ideal software for this is PHPUnit.

The software can be obtained from GitHub verteilt, is well documented, widely used and very popular. It is also in the PEAR project and can be installed using the PEAR installer (it has some dependencies for additional features).

To demonstrate the basic procedural manner I’ll use a simple example. Imagine… somewhere within a php project there is a function, which returns easter sunday given any year. To make things easy, we’ll name it easter($year). Such a function could be used for determining holidays and therefore could have a certain criticality. How can this be tested with PHPUnit?

Let’s delve into code:

[php]
require_once ‚includes/functions.php‘;

class EasterTest extends PHPUnit_Framework_TestCase {
public function testEasterOk() {
$easter2011 = easter(2011);
$this->assertEquals($easter2011, gmmktime(0,0,0,4,24,2011));
}

public function testEasterFalse() {
$easter2011 = easter(2011);
$this->assertNotEquals($easter2011, gmmktime(0,0,0,12,24,2011));
}
}
[/php]

First there is a link to the script containing the easter-function (here: functions.php). Then I generate a new class („EasterTest“), which extends PHPUnit. In this class there are two basic tests:

  • A positive test (24.4.2011, is this easter sunday?)
  • A negative test (24.12.2011, is this easter sunday?)

Now to the boring theoretical part…
The solution isn’t the aim here – one glance at a calender should help you way better. The goal is, to compare the functions result with a defined result. I know for sure, that this years easter sunday is on 24.04. (as long as my calendar isn’t lying!) … und I know for sure, 24.12. ain’t somewhere near easter.

PHPUnit – like many other software products around unit testing – works with „assertions“. There is a library of simple functions for assertions in different constructs – for comparisms (like the here used assertEquals and assertNotEquals), arrays, bools and so on.

How much work is it?
Please decide for yourself. An easy test should be coded within less than five minutes. Not too difficult, ain’t it?

Back to work.

How can you now run those tests? Easiest way: use your shell (whatever, either Dos, Bash or anything else php runs on).

[shell]
D:\htdocs\>phpunit EasterTest.php
PHPUnit 3.5.11 by Sebastian Bergmann.

..

Time: 0 seconds, Memory: 3.75Mb

OK (2 tests, 2 assertions)
[/shell]

PHPUnit can express itself using different output formats, for example TAP („Test Anything Protocol“), JSON, XML and some more.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
ok 1 – EasterTest::testEasterOk
ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Now… how does it look like if there is an error? To test this I slighly changed my first test and assumed, 23.04.2011 is easter sunday – in reality it is the saturday.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
not ok 1 – Failure: EasterTest::testEasterOk

message: ‚Failed asserting that <integer:1303516800> matches expected <integer:1303603200>.‘
severity: fail
data:
got: 1303516800
expected: 1303603200

ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

If I return coding on the easter-function in the far future, then I still have my unit tests and can run them whenever I like (or whenever I need!). If the tests then return errors, either my tests are wrong or my function is (guess what is more likely). And this is what this is all about. Unit testing makes your code stronger and additions much easier.

And…if you encounter bugs… just write a test first and then fix it!

Kategorien
Computer

qTranslate

[:en]I’m just giving qTranslate a try. Lets find out how it works!
[:de]Ich teste gerade qTranslate. Mal sehen, wie das funktioniert!

Kategorien
PHP Tutorials

[:de]PHP-Commandline-Parameter mit Console_Getopt[:en]PHP-Commandline-Parameter with Console_Getopt

[:de]Aus der Historie heraus verwenden die meisten Entwickler PHP hauptsächlich als serverseitige Skriptsprache zur Erstellung von Webseiten oder Webanwendungen. Mit PHP kann man jedoch noch viel mehr machen: es bietet ein Commandline-Interface, welches ermöglicht, auch unter verschiedenen OS Shell-Scripts zu schreiben und zu verwenden.

Um übergebene Parameter auszuwerten, bedient man sich der dafür reservierten Variable $argv.

[:en]Mainly due to historical reasons my guess is most developers are using php as a language to build web pages and web applications. PHP can do alot more: it has a commandline interface, which enables you to write scripts using several different enviroments.

Parameters are stored in a special variable $argv.

[:de]Beispiel 1: test_argv.php
[php]
<?php
var_dump($argv);
?>
[/php]

[:en]Example 1: test_argv.php
[php]
<?php
var_dump($argv);
?>
[/php]

[:de]Ausgabe von Beispiel 1:
[shell]
d:\php5> php.exe test_argv.php IchBinParam1 UndIch2
array(3) {
[0]=>
string(13) "test_argv.php"
[1]=>
string(12) "IchBinParam1"
[2]=>
string(7) "UndIch2"
}
[/shell]

[:en]Output Example 1:
[shell]
d:\php5> php.exe test_argv.php IchBinParam1 UndIch2
array(3) {
[0]=>
string(13) "test_argv.php"
[1]=>
string(12) "IchBinParam1"
[2]=>
string(7) "UndIch2"
}
[/shell]

[:de]So weit, so gut. Wenn es jetzt darum geht, die Argumente zu parsen und zu prüfen, kann so ein Konstrukt rund um $argv schnell recht aufwändig werden. Um dies zu erleichtern, gibt es im PEAR-Paket eine kleine Klasse namens Console_Getopt.

[:en]Not too bad so far. If you now want to start parsing and checking parameters, such a structure can easily get complicated. To make things easier, there is a little class called Console_Getopt in the PEAR project.

[:de]Installation
Falls man PEAR verwendet, kann man die Klasse sehr einfach darüber installieren.
[shell]
d:\php5> pear install Console_Getopt-1.3.0
[/shell]

Man ist jedoch nicht darauf angewiesen. Es reicht vollkommen aus, die Klasse von der offiziellen PEAR-Seite zu downloaden und in das Projekt einzubinden.

[:en]Installation
If you’re using PEAR, simply use the pear installer.
[shell]
d:\php5> pear install Console_Getopt-1.3.0
[/shell]

But you don’t have to. It is sufficent to download the class here and include it into your project.

[:de]Anwendung
Die Anwendung ist denkbar einfach. Man bindet die Klasse in das eigene Programm ein, initialisiert das Klassenobjekt, definiert erlaubte Optionen und prüft dann die übergebenen Parameter.

Hier ein einfaches Beispiel zur Anwendung.

Beispiel 2: demo_getopt.php
[php]
<?php
// Klasse einbinden
include ("Getopt.php");

// Klasse initialisieren
$cg = new Console_Getopt();

/**
* Erlaubte Optionen:
* -a Abba
* -b Beatles
* -q Queen
*/
$allowedOptions = "abq";

// Kommandozeile lesen
$args = $cg->readPHPArgv();

// Optionen herausfiltern
$ret = $cg->getopt($args, $allowedOptions);

// Errorhinweis
if (PEAR::isError($ret)) {
die ("Fehler in Kommandozeile: " . $ret->getMessage() . "\n");
}

// Ausgabe der Optionen
print_r($ret);
?>
[/php]

Ausgabe zu Beispiel 2:
[shell]
d:\temp\getopt>php.exe demo_getopt.php -ab Who Genesis
Array
(
[0] => Array
(
[0] => Array
(
[0] => a
[1] =>
)

[1] => Array
(
[0] => b
[1] =>
)

)

[1] => Array
(
[0] => Who
[1] => Genesis
)

)

d:\temp\getopt>d:\php5\php.exe demo_getopt.php -c
Error in command line: Console_Getopt: unrecognized option — c
[/shell]

Nach dem Filtern der Optionen kann man nun die über die Kommandozeile eingebenen Parameter auswerten und weiter verarbeiten.

Beispiel 3: demo_getopt_erweitert.php
[php]
.
.
.
// Optionen herausfiltern
$ret = $cg->getopt($args, $allowedOptions);

$optionen = $ret[0];
if (sizeof($optionen) > 0) {
// mindestens eine Option wurde gewählt
foreach ($optionen as $o) {
switch ($o[0]) {
case ‚a‘:
echo "gewählte Band: Abba\n";
break;
case ‚b‘:
echo "gewählte Band: Beatles\n";
break;
case ‚q‘:
echo "gewählte Band: Queen\n";
break;
}
}
}
[/php]

Die Klasse kann noch mehr, unter anderem ist es z.B. möglich, notwendige und optionale Parameter definieren. Auch kann man definieren, ob Parameter Zeichenketten oder Zahlenwerte sein dürfen.

Wer einen tieferen Einblick in die Klasse möchte, die Klasse selbst ist gut dokumentiert. Einen ausführlichen und guten Artikel mit weiteren Anwendungsbeispielen gibt es hier bei Zend.

[:en]Usage
Not only installing this class is easy, so is the usage of it. Just include the class into your programm, initialize the class object, define allowed options and then check the parameters.

Here’s a simple example.

Beispiel 2: demo_getopt.php
[php]
<?php
// include class
include ("Getopt.php");

// initialize class
$cg = new Console_Getopt();

/**
* allowed options:
* -a Abba
* -b Beatles
* -q Queen
*/
$allowedOptions = "abq";

// read commandline
$args = $cg->readPHPArgv();

// filter options
$ret = $cg->getopt($args, $allowedOptions);

// error message
if (PEAR::isError($ret)) {
die ("error in commandline: " . $ret->getMessage() . "\n");
}

// print the options
print_r($ret);
?>
[/php]

Output Example 2:
[shell]
d:\temp\getopt>php.exe demo_getopt.php -ab Who Genesis
Array
(
[0] => Array
(
[0] => Array
(
[0] => a
[1] =>
)

[1] => Array
(
[0] => b
[1] =>
)

)

[1] => Array
(
[0] => Who
[1] => Genesis
)

)

d:\temp\getopt>d:\php5\php.exe demo_getopt.php -c
Error in command line: Console_Getopt: unrecognized option — c
[/shell]

After filtering the options you can now retrieve the command line parameters and work with them.

Example 3: demo_getopt_erweitert.php
[php]
.
.
.
// filter options
$ret = $cg->getopt($args, $allowedOptions);

$optionen = $ret[0];
if (sizeof($optionen) > 0) {
// at least one option has been used
foreach ($optionen as $o) {
switch ($o[0]) {
case ‚a‘:
echo "you choose: Abba\n";
break;
case ‚b‘:
echo "you choose: Beatles\n";
break;
case ‚q‘:
echo "you choose: Queen\n";
break;
}
}
}
[/php]

The class can do a few things more, for example it is possible to check for optional or necessary parameters, check for strings or numeric values and things like this.

If you want to take a closer look into the class, it is well documented. A more detailed article with a few more examples can be found here at Zend.