About Daniel Kyak

Trockene technische Themen mit Leben zu füllen und die Ideen von Konzeption und Design Wirklichkeit werden zu lassen, ist mein täglich Brot als Senior Systems Engineer bei der New Identity AG. Als gebürtiger Hallenser habe ich nach Abschluss meines Wirtschaftsinformatikstudiums eine zweite Heimat in Mainz gefunden.

Kannst du mir davon mal einen Screenshot machen?

This entry is part 1 of 1 in the series Firefox Add-ons

Mein persönlicher Lieblingsbrowser ist nach wie vor der Firefox. Doch ohne die vielen guten Add-ons wäre er nur halb so gut. Allerdings verliert man auch in der Vielzahl leicht den Überblick, daher möchte ich hier in einer kleinen Serie die Add-ons die ich gerne nutze kurz beschreiben.

Beginnen will ich mit Screengrab, da ich es erst vor ein paar Wochen installiert habe. Mit Screengrab kann man auf eine wirklich unkomplizierte Weise Screenshots von Webseiten erstellen. Dabei kann man auswählen, was man haben will (Gesamte Seite, sichtbaren Bereich, auswählbaren Bereich oder gesamtes Fenster), wie man es haben will (Datei oder Zwischenablage) und mehr nicht. Und, um ehrlich zu sein, mehr braucht es auch nicht. Damit deckt die Erweiterung alle Funktionen ab, die ich an ein solches Tool stelle. Leuten, die Pfeile, Rahmen und Anmerkungen auf Screenshots machen, wird das sicherlich nicht ausreichen. Aber dafür gibt es ja noch genug andere Tools…
Ich jedenfalls habe Screengrab wirklich zu schätzen gelernt und lege es jedem ans Herz.

Weiter so, nur vielleicht etwas besser…

Sascha kam gestern mit dem Vorschlag zu mir, dass wir das Blog doch stilllegen sollten. Der Grund liegt nahe, wir schaffen es bisher nicht so richtig viel zu schreiben. Als wir das Blog angefangen haben, wollten eigentlich zwei Artikel pro Woche veröffentlichen. Zugegeben, so richtig haben wir es nie geschafft diese Taktrate einzuhalten. Über einen Beitrag pro Woche wäre ich schon glücklich.
Aber einige Artikel finde ich gut und möchte sie nicht missen. Auch macht es mir Spaß zu schreiben. Daher musste ich ihm versprechen, dann jetzt doch mal etwas mehr zu bloggen. Ist ja nicht so, dass ich noch ein paar Entwürfe schon gespeichert hätte…

Also los, neuer Vorsatz fürs neue Jahr: mehr bloggen! :-)

Ach so, heute um 19Uhr werden die Tickets für das BarCampRuhr4 am 26./27. März in Essen freigeschaltet. Da ich noch nie in Essen war und inzwischen leicht barcampsüchtig bin, werde ich versuchen ein Ticket zu bekommen.
Wünscht mir Glück!

Ich bin süchtig und das ist auch gut so!

Alles hat vor ungefähr einem Jahr angefangen. Ich hatte mich zu der Zeit schon etwas mit der Barcamp-Idee beschäftigt, war aber bis dahin noch zu keinem gegangen. War alles immer so weit weg, wie ich fand. Dann kam das erste Barcamp nach Mainz und ich konnte nicht anders: Ich musste hingehen, auch direkt einen Tag nach der Weihnachtfeier. Ergebnis der zwei Tage: sehr müde, aber nun süchtig und voller Erwartung auf das nächste Barcamp.

Inzwischen ist ein Jahr vergangen und am letztes Wochenende war ich dann schon bei meiner fünften Unkonferenz. Da lernt man schon die unterschiedlichen Orgastile kennen und merkt auch, dass eigentlich auch ein Stück Malerkreppband für das Namesschild ausreicht. Das Wichtigste sind sowieso die Teilnehmer!

Mit diesem Barcamp-Virus infiziert, konnte ich auch nicht anders und musste letztes Wochenende zum Barcamp Darmstadt. Also bin ich dann Samstag los Richtung Darmstadt. Natürlich mit einem kleinen Abstecher über die NIDAG, um Blöcke, Kugelschreiber und Stellenanzeigen mitzunehmen. Finde es gut, dass meine Firma auch dieses Jahr wieder das Barcamp Rhein-Main sponsorte!

Da stand ich nun in der Sessionplanung und stand auch wieder vor dem positiven Problem, mich nicht zwischen Sessions entscheiden zu können. Besonders schön fand ich, dass es alles im allem auch etwas IT lastiger war. Wenn ich allerdings zugeben muss, dass ich ganz gern mal die andere Sessions gegangen bin. IT hab ich so schon jeden Tag, aber das Leben hat ja mehr zu bieten. So bin ich dann Samstag Abend wieder in Mainz mit dem Vorsatz, noch meine Session für den Sonntag vorzubereiten. Also Slides erstellen und so, aber irgendwie habe ich festegestellt, dass ich eigentlich nur Whiteboard mit Klebezetteln hätte drauf darstellen wollen. Das hat mich dann zu der Erkenntnis gebracht, dass ich das dann doch lieber sein lasse und direkt mit Whiteboard und Klebezetteln arbeite. Also nächsten Tag wieder zum Barcamp und in der Sessionplanung, meine Session vorstellen. Ich hatte ja gehofft, dass am Sonntag weniger spannende Themen aufkommen und ich so nichts verpasse. Dem war leider nicht so. Ich fand die Sessions am Sonntag allgemein sogar interessanter. Was mich überraschte, da es meist anders ist.

Frisch gestärkt vom Mittagessen in der T-Online Kantine stand ich da nun vor überraschend vielen erwartungsvollen Gesichtern. Einige kannte ich, andere nicht. Hinter mir das Whiteboard, vor mir ein paar Klebezettel und ein paar Stifte und ich mit der groben Idee, was ich gleich machen will. Mein Thema: “Einsatz von KANBAN im Maintenance”. Also los, reinspringen und zeigen warum ich es nützlich finde und wie wir es in einem unserer Supportteams einsetzen. Die anschließende Diskussion war sehr cool und genau dafür liebe ich Barcamps. Es sind halt nicht nur Vorträge, sondern auch der Meinungsaustausch und die Diskussion stehen weit oben auf der Agenda.

Und was soll ich sagen, ich habe es nicht bereut. Weder zum Barcamp zu gehen, noch auch mal eine eigene Session zu halten. Alles in allem ein gelungenes rundes Wochenende. Es hat sich einfach wieder gezeigt, ein Barcamp ist so gut, wie es jeder einzelne Teilnehmer macht. Das unter dem Vorbehalt, dass das Orga-Team wieder eine großartige Arbeit geleistet hat. Da hat einfach alles gepaßt! Wirklich schade war eigentlich nur, dass wohl die Quote der NoShows recht hoch war. Naja, irgendwie muss man damit wohl leben. Leider. Gut finden muss man es trotzdem nicht.

Commit Monitor für SVN

Der Commit Monitor ist ein kleines Tool, was ich doch inzwischen sehr mag. Warum ich es mag, ist eigentlich ganz einfach: Man wird schnell und übersichtlich über Änderungen im SVN informiert. Gerade bei langsamen oder großen SVN’s spart man sich ja ganz gern mal die Zeit für ein SVN-Update. Auch kann man damit das gesamte SVN im Blick behalten und bekommt so einen Eindruck, in welchem Branch beispielsweise gerade entwickelt wird. Nicht zuletzt lassen sich Scripte ausführen, wenn es Veränderungen im SVN oder einem Teilzweig gibt. Schön ist auch die Möglichkeit bestimmte Nutzer (z.B. man selbst) auszuschließen, so bekommt man wirklich nur die Hinweise, die man auch benötigt.

FrOSCon 2010

Am Samstag war ich in Sankt Augustin zur FrOSCon. Mein erstes Mal und ich muss sagen, es wird nicht mein letztes Mal gewesen sein. Eigentlich hatte ja naturgemäß der PHP-Track mein Interesse geweckt, aber als ich dann vor Ort war, war ich doch fast mehr in anderen Sessions. Gerade die nicht so technischen Sessions sind doch immer wieder am Spannendsten.

Begonnen habe ich dann mit einem Vortrag von Lorna Jane Mitchell. Er war wirklich kurzweilig und hat wieder mal bewiesen, dass man auch mit nur 3 Folien (“Titel”, “zur Person”, “Thanks”) viel erzählen kann. Großartig! Zugegeben, bei dem Thema waren sowieso eher die Softfacts entscheidend.

Dann habe ich mir natürlich auch die Keynote nicht entgehen lassen. Der Hörsaal war dabei sogar so voll, dass einige Zuhörer auf den Treppen Platz nehmen mussten. Und ich glaube niemand hat bereut sich diese Stunde Zeit zu nehmen. Ich zumindest habe es nicht. Es ist schon beeindruckend, wenn man durch so einen Vortrag mal einen Blick über den Tellerrand bzw. von der anderen Seite der Welt bekommt. Das erweitert doch immer wieder den eigenen Horizont.

Damit meine kleinen Open-Source-Projekte noch etwas besser laufen, habe ich mir dann noch “Gute Open-Source-Projekte bestehen aus mehr als nur Code” angesehen. Zunächst mit etwas Skepsis, hat sich das dann doch schnell gelegt. Zum Einen war den Vortrag in sich rund und hat einem schöne Tipps gegeben, zum Anderen war er aber auch gut aufbereitet und super vorgetragen. Gut zugegeben, ich mag Vorträge mit guten Bildern, welche den Inhalt unterstützen.

Ein wenig Neues habe ich dann auch noch über Softwaremetriken in PHP und Arbit gelernt. Die beiden Vorträge waren ok, hatten aber unterschweilig immer den Touch einer Werbeverantstaltung von qafoo, der Firma der Vortagenden. Aber mit irgendwas verdienen wir ja alle unser Geld. Mal lebt ja nicht nur von Luft und Liebe. :-)

Inzwischen kann man sich zahlreiche Videomitschnitte de4 Session auch von froscon.tv herunterladen.

“Junior”-Level für den Coding Standard?

Wir haben bei uns zur Zeit eine Diskussion zur Umstellung der Coding Standards. Ich hatte vor einer Weile angeregt, ob wir sie nicht an bewährten Regeln von größeren Frameworks anlehnen sollten. Mir gefallen dabei die Coding Standards von Zend recht gut, obwohl es auch für mich eine Umstellung wäre.

Die Vorteile liegen dabei wohl auf der Hand:

  • Es gibt schon Sniffs für den PHP_Codesniffer um die Regeln zu überprüfen.
  • Neue Kollegen kennen diese Regeln aus den Frameworks und nutzen sie idealerweise bereits für ihre Entwicklungen.
  • Codeschnipsel von externen Quellen können eher direkt verwendet werden, ohne sie an die eigenen Codeing Guides anzupassen.

Die Überlegung zur Umstellung der Coding Guides hat natürlich auch Widerstand hervorgerufen. Das größte Bedenken ist dabei, dass es nicht einfach wird, den gesamten vorhandenen Quellcode von mehreren Jahren Entwicklung umzustellen. Ein Bedenken, was nicht so einfach von der Hand zu weisen ist.

Wir haben natürlich auch Überschneidungen zwischen unserem aktuellen Coding Standard und den möglicherweise zukünftigen Coding Standards. Diese Schnittmenge sollte somit bereits in den aktuellen Sourcen abgedeckt sein.

Daher ist mir folgende Idee gekommen. Wie wäre es, wenn man unterschiedliche Level einführt. Also zunächst ein “Junior”-Level für die Schnittmengen in den Styleguides und dann mehrere Stufen bis zum “Chief”-Level. Das “Chief”-Level würde denn den perfekten Codingstyle darstellen. Man könnte dann für jedes Projekt bestimmen, welches Level dieses Projekt erfüllen soll. Natürlich immer das Ziel im Hinterkopf in absehbarerer Zeit das “Chief”-Level zu erreichen.

Aus verschiedenen Aspekten stelle ich es mir ganz spannend vor:

  1. Kein Seniorentwickler will auf die Dauer auf “Junior”-Level programmieren. Zumindest mir würde es gegen den Strich gehen. Zumal es ja auch alle anderen in der Firma sehen würden. ;-)
  2. Man hätte Qualitätslevel als Vergleich zwischen den Projekten und Teams, welche man auch relativ leicht bewerten kann. So ist das super-mega-innovative Projekt dann doch nicht mehr so cool, wenn es nur einen “Junior”-Level erreicht, oder?
  3. Auch hat man durch die Nutzung von Level nicht sofort hunderte/tausende Hinweise. Denn mal ehrlich, bei zu vielen Hinweisen hat man auch keine Lust, da man das Ende und den Fortschritt kaum sehen kann. ;-)

Was haltet ihr von meiner Idee? Könnte das so funktionieren?

PHP Tool Integration (PTI) für Eclipse

This entry is part 8 of 4 in the series Zend Framework Grundlagen

Nachdem Sascha jetzt mit seiner Serie schon recht weit bei der Einrichtung unter Eclipse fortgeschritten ist, will ich ihn da mal unterstützen und ein weiteres Plugin vorstellen, ohne das man unter PHP eigentlich gar nicht entwickeln sollte. Ich selber habe es gerade in den letzten Wochen regelrecht lieben gelernt. :-)


Eclipse PHP Tool Integration oder kurz PTI ist das Plugin, was ich euch hier ans Herz legen will. Mit PTI werden vorhandenen PHP Tools in Eclipse integriert. Zur Zeit sind Integrationen von PHP_Codesniffer, PHPUnit und PHPCPD verfügbar. Drei Tools also, die so schon alleine wirklich praktisch sind. Was ich daran genial finde ist, dass man die Fehler/Warnings durch PTI direkt im Editor sieht und so auch direkt bearbeiten und beheben kann. Ich denke durch diesen direkten Feedback schafft man es recht schnell die Qualität des erstellten Sourcecode zu erhöhen.

Continue reading

PhpCilux – continuous integration monitoring

Es ist soweit, ich bin stolz, die erste Version von “PhpCilux” präsentieren zu dürfen. :-)

Eigentlich wollte ich es ja “Daisy” nennen, da ich bei gleichnamigen Sturm über Deutschland mit der Entwicklung begonnen hatte. Allerdings gibt es schon viel zu viele Projekte mit dem Namen “Daisy”.
PhpCilux soll als Name vielmehr symbolisieren, dass es php-Anwendung mittels CI beleuchten kann. Der Name war eine wirklich schwere Geburt, aber jetzt wieder weiter im Text.

Ich beschäftige mich schon seit einer Weile mit Continuous Integration. Dabei habe ich natürlich auch phpUnderControl installiert und eingesetzt. Ich denke, dass ist der Platzhirsch, wenn man sich mit dem Thema im Rahmen einer PHP Entwicklungsumgebung beschäftigt. Es ist auch durchaus zu recht in aller Munde, da es groß und mächtig ist. Für mich aber irgendwie zu mächtig, zu groß und zu komplex. Neben phpUnderControl gibt es noch diverse andere Tools. Im PHP-Umfeld ist dabei sicherlich noch Xinc interessant. Allerdings sieht es so aus, als ob das aktuell nicht mehr weiterentwickelt wird.

Dann bin ich eher aus Zufall auf Sismo gestoßen. Ich finde diesen Ansatz cool, einfach und intuitiv zu bedienen! Es gibt genau nur die Informationen wieder, die man hier benötigt:

  • Projekt erfolgreich: ja/nein
  • Build erfolgreich: ja/nein
  • Navigieren durch die Projekte und Builds

Sismo ist leider noch nicht veröffentlicht. Ich wollte aber unbedingt so ein Tool haben, somit habe ich mich entschlossen so was ähnliches zu entwickeln. Das Ergebnis ist nun da: PhpCilux.

Und was kann es?

Es kann eigentlich gar nicht so viel und das ist auch so gewollt!
Eigentlich kann es nur die Logfiles von PHPUnit und PHP_CodeSniffer anzeigen und mit Informationen aus dem SVN-Log anreichern. Ich brauche hier keine generierten Quellcode-Dokumentationen, Code Coverage oder irgendwelche Softwaremetriken. Nicht, dass dies unwichtig wäre, aber das dient eher zu Verbesserung bzw. Dokumentation des Projektes. Was ich im Rahmen einer einfachen Continuous Integration haben will, ist eigentlich ganz einfach und läßt sich in folgender Aussage auf den Punkt bringen: Könnte man das Projekt jetzt deployen? Dafür reichen meiner Meinung nach zunächst Unit-Tests und eine Auswahl an CodeSniffs. Durch die Beschränkung auf diese zwei Tools erreicht man, dass der Buildprozess recht schnell bleibt und somit auch häufig statt finden kann.

Damit PhpCilux die Builds eines Projektes anzeigen kann, bedarf es eigentlich auch nicht viel. Pro generiertem Projekt gibt es einen Ordner. In diesem Ordner gibt es dann einen Unterordner “reports”, welcher wiederum die eigentlich Build-Ordner enthält. In den einzelnen Ordern können dann die Logfiles von PHPUnit, PHP_CodeSniffer oder SVN liegen: phpcs.txt, phpunit.txt und svnlog.xml.
Als Projektname wird der Name des Ordners verwendet. Gleiches gilt auch für die Namen der einzelnen Builds.

Wie diese Daten dort hin gelangen, ist PhpCilux vollkommen egal. Für meine Entwicklungen habe ich mich für ein phing-Buildscript entschieden. Sie könnten aber auch via Cronjob, manuelles Kopieren oder irgend einen anderen Weg dort landen. Also jedem das seine und für mich kein Aufwand einer Entwicklung. ;-)

So kommen wir jetzt zum Schluß. Es ist früh und ich muss morgen ja wieder arbeiten. Aber eins noch: Ich freue mich auf konstruktives Feedback und mal sehen, vielleicht gibt es auch bald den großen Bruder für PhpCilux… ;-)

Was geht eigentlich so an SQL-Abfragen?

Jetzt schreibe ich schon wieder über Wege zu Optimierungen. Man könnte denken, meine Anwendungen wären langsam. ;-)

Aber mal im Ernst, in größeren gewachsenen Projekten weiß man nicht mehr unbedingt, was ein Seitenaufruf für SQL-Abfragen auslöst. Drei Sachen finde ich dabei interessant:

  1. Die Anzahl von gleichen/ähnlichen Abfragen. –> Vielleicht kann man was zusammenfassen.
  2. Die Abfragezeit der längsten Abfragen. –> Vielleicht kann man was verändern oder noch verbessern.
  3. Anzahl der Abfragen im allgemeinen und die Gesamtausführungszeit. –> Vielleicht kann man was vermeiden.

Im Zend_Framework kann man für die Datenbank das Profiling aktivieren, was ganz gut funktioniert und auch die Voraussetzung für meinen kleinen Codeschnipsel ist. Also zunächst in der Bootstrap das Profiling  aktivieren und dann mache ich eigentlich was ganz einfaches: Ich gehe die einzelnen Einträge aus dem Profiling durch und sortiere/gruppiere die Einträge. Im Anschluß wird das ganze noch in eine Datei weggeloggt. Fertig. Recht einfach, oder? Aber es funktioniert gut um kleinere Schwachstellen zu finden. Wichtig ist noch, dass dies am Ende eingebunden wird, so dass auch alle Abfragen enthalten sind.

So jetzt noch der Code-Schipsel:

	// log sql debug
	$dbs = array(
		'db1' => Zend_Registry::get('db1'),
		'db2' => Zend_Registry::get('db2'),
	);

	// order by max unique statements => max
	// order by query length => length
	$orderBy = 'max';

	foreach ($dbs as $dbKey => $db) {
		$data = array();
		$profiler = $db->getProfiler();

		if (!$profiler->getEnabled()) {
			break;
		}

		$file = TOP_DIR.'/logs/db'.$dbKey.md5($_SERVER['REQUEST_URI']).'.log';

		$totalTime    = $profiler->getTotalElapsedSecs();
		$queryCount   = $profiler->getTotalNumQueries();
		$longestTime  = 0;
		$longestQuery = null;

		$queryData = array();
		foreach ($profiler->getQueryProfiles() as $query) {
		    if ($query->getElapsedSecs() > $longestTime) {
		        $longestTime  = $query->getElapsedSecs();
		        $longestQuery = $query->getQuery();
		    }
		    $queryDataKey = serialize($query->getQuery());
		    if (isset($queryData[$queryDataKey]['count'])) {
		    	$queryData[$queryDataKey]['count']++;
		    	$queryData[$queryDataKey]['ElapsedSecs'] += $query->getElapsedSecs();
				$queryData[$queryDataKey]['getQueryParams'] .= "\n".serialize($query->getQueryParams());
		    } else {
		    	$queryData[$queryDataKey]['count'] = 1;
		    	$queryData[$queryDataKey]['ElapsedSecs'] = $query->getElapsedSecs();
		    	$queryData[$queryDataKey]['getQueryParams'] = serialize($query->getQueryParams());
		    }
		    $queryData[$queryDataKey]['query'] = $query->getQuery();

		}

		$queryData2 = array();
		foreach ($queryData as $_query) {
			if ($orderBy == 'max') {
				// order by max unique statements
				$key = str_pad($_query['count'], 5, 0, STR_PAD_LEFT ).'_'.md5($_query['query']);
			} else {
				// order by query length
				$key = str_pad($_query['ElapsedSecs'], 15, 0, STR_PAD_LEFT ).'_'.md5($_query['query']);
			}
			$queryData2[$key] = implode("\n", $_query);
		}

		krsort($queryData2);

		$data[] = 'Request: '.$_SERVER['REQUEST_URI'];
		$data[] = 'Executed ' . $queryCount . ' queries in ' . $totalTime . ' seconds';
		$data[] = 'Diffrent queries ' . count($queryData2);
		$data[] = 'Average query length: ' . $totalTime / $queryCount .' seconds';
		$data[] = 'Queries per second: ' . $queryCount / $totalTime ;
		$data[] = 'Longest query length: ' . $longestTime;
		$data[] = "Longest query: " . $longestQuery;

		$data[] = '';
		$data[] = '';
		$data[] = '';
		$data[] = implode("\n\n", $queryData2);

		file_put_contents($file, implode("\n", $data));
	}

Berlin, Berlin, wir fahren nach Berlin!

Gerade habe ich alles klar gemacht. Ich habe frei, das Hotelzimmer ist gebucht und das Ticket ist gekauft.

Jetzt werde ich also Mitte April zur re:publica 2010 nach Berlin fahren. Ich freue mich schon, auch wenn ich noch nicht genau weiß, was mich genau erwartet. Hauptauslöser für die Entscheidung war sicherlich die Teilnahme am Barcamp Mainz Ende letzten Jahres. Ich fand diese Art von Konferenz großartig.

Wenn man sieht was in Berlin letztes Jahr so abging, ist auch nicht von schlechten Eltern. Neben den ganzen Sessions gab es auch ein Konzert von Fettes Brot. Die haben heute übrigens ihr neues Video released: JEIN 2010, was mir wirklich gut gefällt. Frage mich, wie das noch getoppt werden kann? Wir werden es im April sehen. :-) Wenn jetzt der Wettergott noch ein paar sonnige Tage spendiert, wird alles gut!