// der php hacker

// archiv

Den PHP Hacker zu Gast …

Geschrieben am 24. Mrz 2011 von Cem Derin

… ist selten schön. Ich bin gefräßig, schmutzig, undordentlich, mache die ganze Zeit anzügliche Witze und vergraule alle Frauen von jeder Party. Deswegen hat derSchepp mich auch nur in seinen (und dem Peter und dem Markus seinen) Podcast eingeladen. Da hats dann nicht so gestunken. Thematisch geht es da übrigens so gut wie immer um Webentwicklung. Reinhören lohnt – und es hat mir einen riesen Spaß gemacht.

Wenn Entwickler hassen: Was nervt euch?

Geschrieben am 18. Feb 2011 von Cem Derin

Der Mensch ist ein Gewohnheitstier. Auch wir als Entwickler sind davor nicht gefeit. Ich habe mehr als einmal die Erfahrung machen müssen, dass Entwickler sogar sehr viel häufiger ein Problem damit haben, aus festgefahrenen Strukturen auszubrechen oder sich mit “neuen” Herangehensweisen zu beschäftigen. Ob es nun die IDE, das verwendete Framework oder bestimmte Architektur-Ansätze sind.

An manchen Stellen jedoch stößt man an Punkte, die stoßen einem einfach sauer auf. Und das hat dann überhaupt nicht da mit zu tun, dass man “festgefahren” wäre, sondern ist ein ganz subjektives aber deswegen nicht weniger störendes empfinden. Kleines Beispiel (was ich neulich auch getwittert habe): Ich hasse es, wenn SQL-Aliase ohne “AS” angelegt werden. Das sieht ungefähr so aus:

SELECT
	myTable.row myRow
FROM
	table myTable
JOIN
	anotherTable yourTable
ON
	myTable.myRow = yourTable.id
WHERE
	myTable.anotherRow = 'value';

Da könnte ich mich wirklich auskotzen. Was mich auch auf die Palme bringt (und oft bei “Anfängern” zu sehen ist): wenn Parameter ohne Leerzeichen direkt hintereinander geschrieben werden. Beispiel:

	function($param1,$param2,$param3)

Ganz übel wird es, wenn dann auch noch geschachtelt wird:

	function($param1,$param2,foo($bar,function($batz)))

Grauenhaft. Es tut mir schon weh, dass hier nur exemplarisch zu schreiben. Ich weiß zum Beispiel, dass ein namentlich nicht genannter Kollege jedes mal in einer Halb-Zwangshandlung an den Leerzeichen rumfummelt, bevor er sich den Code überhaupt angucken kann.

Und deswegen: Was nervt euch tierisch an?

Wusstest du schon …

Geschrieben am 30. Dez 2010 von Cem Derin

… dass kaum ein Entwickler die „ungarische Notation“ wirklich kapiert hat? Falls ihr euch jetzt denkt „was zum Geier ist eine ungarische Notation“: Schnell zusammengefasst bezeichnet die ungarische Notation ein Typ-Prefix vor einem Variablen-Namen. Wenn es jetzt klingelt, dann gut – wenn nicht, erspare ich euch ein falsches Beispiel (zur Not schaut mal in der Wikipedia). Da denkt man sich zunächst, was es daran eigentlich nicht zu kapieren gibt. Nun, das ist allerdings der Knackpunkt: Mit „Typ“ ist nicht dediziert der primitive Datentyp gemeint, sondern der Typ der Variable, wie zum Beispiel ein Zähler, ein Zeiger, eine Differenz. Einen sehr schönen – wenn auch nicht mehr ganz neuen – Artikel dazu hat Joel Spolsky vor einigen Jahren verfasst (und ich hab den sogar mal in einem alten Blog von mir verlinkt): Making Wrong Code Look Wrong!

Wie auch schon im letzten Jahr werden die Feier- und Brückentage mit kleinen aber wie ich finde feinen Tipps aus der Trickkiste der Web-Developer angereichert. Wer die “Wusstest du schon …”-Tipps vom letzten Jahr sehen möchte, schaue im Archiv!

Wusstest du schon …

Geschrieben am 22. Dez 2010 von Cem Derin

… dass auch das letzte Element eines Arrays mit einem abschließenden Komma notiert werden kann? Das beugt einem nervigen Fehler vor, den man auch als erfahrener Entwickler immer wieder macht: Ein neues Element hinzufügen und vergessen, beim vorherigen ein Komma mit einzufügen!

$array = array(
	'foo',
	'bar',
	'batz',
);

Wie auch schon im letzten Jahr werden die Feier- und Brückentage mit kleinen aber wie ich finde feinen Tipps aus der Trickkiste der Web-Developer angereichert. Wer die “Wusstest du schon …”-Tipps vom letzten Jahr sehen möchte, schaue im Archiv!

Menschenlesbare Zeitangabe leicht gemacht

Geschrieben am 09. Dez 2010 von Cem Derin

Wer meinen Twitter-Account verfolgt, der wird wahrscheinlich mitbekommen haben, dass ich derzeit an einem Twitter-Service arbeite: Ein Tool, mit dem man unter anderem sehen kann, wie lange ich einem Benutzer folge (oder eben nicht mehr) bzw. wie lange mit ein anderer Nutzer folgt (oder – richtig geraten – eben nicht mehr). Natürlich könnte man einfach schreiben „seit dem 10.11.2010, 19:20“. Das ist zwar auch menschenlesbar, aber wesentlich schwerer zu erfassen als „seit einem Monat“.

Ich wollte also Zeitangaben, wie zum Beispiel Facebook sie auch nutzt, so „natürlich“ wie möglich. Mehr oder weniger im Schlaf kam mir dann die Idee, wie man das sehr leicht umsetzen kann. Im Grunde besteht das Konstrukt aus drei oder mehr Klassen. Auf die gehe ich nun ein!
// mehr lesen

Geschrieben in Entwicklung, PHP 4 Kommentare

Re: Crap Code – Warum gibt es so viel schlechte Software?

Geschrieben am 02. Dez 2010 von Cem Derin

Ralph hat sich vom letzten Artikel von Nils inspirieren lassen, und seine Antwort als eigenen Post verfasst. Find ich gut und hab ich auch schon gemacht.

Aber, es geht um was anderes: schlechten Code. Oder: wie kann man ihn vermeiden. Nils gibt dazu ein paar Tipps zur Hand. Grundsätzlich stimmen die auch alle, trotzdem gibt es dahingehend von mir noch zu kommentieren: die besten Vorgänge, die ausgefuchsten Prozesse, hochwertigsten Tipps und die knackigsten Checklisten schützen nicht vor Blödheit. Doofes Wort, ist aber so. Das allerwichtigste ist zu begreifen, wofür das alles gut sein soll. Und wenn man das auf die Einnahmen der Firma und somit auf das Gehalt runterbricht, wird das den allermeisten auch schlagartig bewusst ;)

Zu Ralphs Meinung hab ich dann etwas mehr zu erzählen. In erster Linie stört mich, dass er seine Meinung als “das ist so” hinstellt. Das mach ich auch dann und wann, versuche aber auch zu erläutern, warum das so ist. Aber das ist nur eine Formalität. Ich unterstelle ihm einfach mal, dass er es doch mehr als “Thesen” verstanden wissen will. Dann gehe ich mal auf die einzelnen Punkte ein.
// mehr lesen

Zwei Dinge, die mich immer schon an Webapplikationen genervt haben

Geschrieben am 16. Nov 2010 von Cem Derin

Es gab eine Zeit, da war eine Webapplikation nichts weiter als die etwas hübscher aufbereitete Darstellung von Daten die an gewissen wenigen Punkten sogar dynamisch war. Ich erinnere mich da an meine ersten Tage im Internet zurück. Damals war GMX so ein Dienst, wo man kostenlos eine Email-Adresse bekommen hat. Wow. Eine Email-Adresse. Sowas hatte nicht jeder – lag vielleicht auch daran, dass kaum einer (oder zumindest keiner den ich kannte) wusste, was das eigentlich ist. Über eine Weboberfläche konnte man Emails schreiben und lesen. Unglaublich unkomfortabel und hässlich – jedenfalls aus heutigen Gesichtspunkten.
// mehr lesen

Haben Design Pattern versagt?

Geschrieben am 10. Nov 2010 von Cem Derin

Beim morgentlichen stöbern durch die Entwickler-Blog-Welt bin ich auf einen Artikel aus Australien gestoßen, in dem die gewagte These aufgestellt wird: Design Patterns haben versagt. Es wird mit der Einleitung begonnen, dass man selbst so viele Design Pattern wie möglich benennen und erklären soll. Und zwar, bevor man weiterliest. Ein wenig Brimborium, Design Pattern sind ganz nett, aber schlussendlich gibt es ein Problem:

“Design patterns have flopped because most programmers don’t know design patterns well enough to recognise the recurring problems that they solve.”

zu Deutsch: Design Patterns haben versagt, weil die meisten Programmierer sie nicht gut genug kennen um zu verstehen, welche Probleme sie lösen.”

Vor allem in Verbindung mit dem ersten Absatz impliziert diese Aussage, dass man alle Design Pattern auswendig kennen muss, um sie richtig verwenden zu können. Das wird auch noch einmal damit unterstrichen, dass der Autor ganz offensichtlich aus dem Recruiting-Umfeld stammt, und Bewerber regelmäßig Pattern aufsagen oder erklären lässt. Zumindest ersteres wäre auch für mich ein Problem: Ich merke mir Sachen, die ich mir merken muss. Ich muss mir Sachen merken, wenn ich sie täglich Anwende. Ein Pattern wende ich aber nicht an, sondern ich setze das Resultat ein – es sei denn, ich entwickle etwas auf Grundlage von Pattern. Die allermeisten könnte ich aber aus dem Stehgreif erklären.

Ich sehe hier also keine Ambivalenz zwischen der mangelnden Fähigkeit rund 30 Pattern auswendig aufsagen zu können und der Tatsache, dass ich das Konzept dahinter nicht verstehe. Um zur Frage im Titel zurückzukommen: Nein! :)

Geschrieben in Entwicklung, Theorie 8 Kommentare

5 Motivationstipps (nicht nur) für Entwickler

Geschrieben am 09. Nov 2010 von Cem Derin

Wir alle lieben unseren Job. Wir machen ihn gerne, leidenschaftlich und können uns nicht vorstellen etwas anderes zu machen. Trotzdem: Manchmal hat man auch einfach keine Lust, ist frustriert von immer den gleichen Standardaufgaben oder es beschäftigen einen andere Dinge. Manchmal hat man dann die Möglichkeit sein Pensum herunterzuschrauben um sich nicht komplett zu frustrieren – aber oft verhindern Abgabetermine, Parallelprojekte und nicht zuletzt man selbst das. Da auch ich diese Probleme kenne möchte ich ein paar Tipps geben, wie man dem entgegenwirken kann – und vor allem dann, wenn das Kind schon in den Brunnen gefallen ist.
// mehr lesen

Über die Crux mit dem Kommentieren

Geschrieben am 04. Nov 2010 von Cem Derin

Ausnahmslos jeder Entwickler kennt das Problem: Schlecht kommentierter Code, der leider alles andere als selbstbeschreibend ist. Und Ausnahmslos jeder Entwickler hat selbst schon einmal solchen Code produziert. Sei es aus Faulheit oder aus vielleicht doch aus Unwissenheit – irgendwann mussten wir uns den Schuh mal anziehen. Ich möchte mal ein bisschen aus dem Nähkästchen plaudern, auch wenn ich mich damit heute mal nicht mit Ruhm bekleckere. Aber man muss ja auch mal in den sauren Apfel beissen können. Genug mit dem Phrasengedresche.

Früher, da war ja alles ganz anders, mein Kind!

Als ich meine ersten Zeilen Code geschrieben habe, da sah ja alles ganz anders aus. Kommentiert habe ich nur sehr wenig. Ich hab hier sogar noch ganz alten Code von mir gefunden, den ich euch nicht vorenthalten möchte!

	function user_overview($link) {
		include('../src/inc/config.php');
		if(!is_numeric($_GET['page'])) {
			$_GET['page'] = 1;
		}
		if($_GET['page'] <= 0) {
			$_GET['page'] = 1;
		}
		$curpage = $_GET['page'] - 1;
		$offset = $curpage * $G_MAX_USER_OVERVIEW;
		$query = "SELECT id, username FROM userdata_core LIMIT ". $offset.", ". $G_MAX_USER_OVERVIEW;
		$result = mysql_query($query, $link);
		while($data = mysql_fetch_array($result)) {
			$add = array_simple($add, "{USERNAME}", $data['username']);
			$add = array_simple($add, "{ID}", $data['id']);

			// In Loop-Array
			$user = array_loop($user, $add);
			unset($add);
		}

		// Navigation erstellen
		$query = "SELECT COUNT(id) FROM userdata_core";
		$result = mysql_query($query, $link);
		$data = mysql_fetch_array($result);
		$pages = ceil($data['COUNT(id)'] / $G_MAX_USER_OVERVIEW) - 1;
		$nav = create_navigation($curpage, $pages);

		// Template
		$source = file_get_contents('src/templates/user/overview.html');
		$source = parse_loop($source, $user, "{USER}");
		$source = parse_simple($source, $nav);
		return $source;
	}

Wir sehen: Kaum Kommentare, so wirklich versteht man nicht auf den ersten Blick, was ich da überhaupt mache. Zu meiner Verteidigung: Dieser Code stammt aus einem ziemlich  über das Knie gebrochene Projekt von vor über 6 Jahren. OOP war noch Neuland für mich, es musste schnell gehen, das Budget war klein.

In dem Projekt allerdings nutzte ich eine „Template-Engine“, die ich zuvor geschrieben habe. Komplett unkommentiert. Das habe ich dann im Anschluss nachgeholt, leider mit falsch Verstandenem Eifer. Jetzt war jede Zeile kommentiert, aber verstanden hat die Funktionen immer noch keiner (oder zumindest nicht, warum man nicht die nativen genommen hat). Veröffentlicht hab ich diese im Rahmen des „Developers Shame Day“. Deswegen nicht hier nochmal …

Jedenfalls: In den folgenden Jahren lebte ich also erst einmal nach der Devise: Um so mehr, desto besser. Ich habe alles mit Kommentaren zugepflastert. Dass das ungefähr genau so „nützlich“ ist wie überhaupt nicht zu kommentieren, merkt man erst, wenn jemand anders an den Code muss.

Wie also richtig kommentieren?

Gleichberechtigt mit guter Kommentier-Mentalität steht meiner Meinung nach die selbstbeschreibende Benamung von Klassen, Methoden, Variablen und Funktionen. Nichts ist Schlimmer als „getVarItmByFltr()“ oder „handleThis“ lesen und auseinanderklamüsern zu müssen. Eine gute Benamung kann einen Kommentar ersetzen – jedenfalls fast. Warum nur fast, dazu später mehr. In meiner Pipeline liegt noch ein Artikel, der einige Grundsätze und Faustregeln aufstellt, wie man Methoden, Klassen und Funktionen benennen sollte, damit klar ist, was passiert – und manchmal eben auch, was nicht.

Warum gute Benamung Kommentare (per Definition) nicht komplett unnötig macht, ist die gute alte DocSyntax. Diese sorgt daür, dass automatische Übersichten über eine Klassenstruktur erstellt werden können, und diese mit „menschenlesbarem“ Text versehen wird. Dort können auch Benutzungshinweise und „Zu Erledigen“ Markierungen angelegt werden. Zuguterletzt ist der große Vorteil für PHP auch noch, dass diverse Typ-Informationen von der IDE genutzt werden.

Trotzdem: Wer sich so eine generierte Dokumentation mal angesehen hat, der wird mir zustimmen, dass es nur unwesentlich besser ist, als sich den Code direkt selbst anzuschauen. Es ist halt nach wie vor automatisch generiert. Und eins darf man nicht vergessen: Diese Doc-Dinger werden aus dem Kommentarblock über der Signatur genommen. Was in der Methode (oder Klasse) passiert, bedarf ggf. auch noch einer Erklärung. Dabei sollte man beachten, dass man selbst vielleicht die abgefahrene Notation toll lesen kann, oder selbst die Haversine-Formel im Schlaf aufsagen kann … dass anderen aber evtl. nicht so geht. Deswegen, auch wenn man Methoden klein und kompakt hält: Erklörungsbedarf wird irgendwo immer sein. Erkennt ihn – und dafür gibt es leider keine Faustregel. Sicher ist nur: Wenn ihr es nicht in einem Satz und Allgemein-Verständlicher Sprache sagen könnt, dann muss ein Kommentar her ;)

For the LOLs!

Damit wir nun nicht nur Staubtrocken herumphilosophiert haben, hier noch eine recht lustige Seite mit den lustigsten Fundstücken in Code-Comments (war mir übrigens schon vor dem Developers Shame Day bekannt).

(Auf stackoverflow.com gibt es auch so einen „Thread“).

Geschrieben in Entwicklung 3 Kommentare
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.