PHP – quick & dirty
Nun ist es soweit, um ein wenig Ordnung in das Chaos der Posts zu bekommen, gibt es neue Kategorie: Bücher. Vielleicht denkt der oder die Eine, dass ich jetzt hinüber bin. Zuerst schreibt er einen Post “Wer liest den heute noch offline?” und jetzt eine eigenen Rubrik für analoges lesen?
Einerseits stapeln sich bei mir interessante Druckwerke und andererseits habt ihr ja mitbekommen, dass ich selbst unter die Buchautoren gegangen bin. Natürlich reichen meine Bücher nicht für eine eigene Kategorie, aber die restlichen interessanten Werke schon. Und die werde ich euch nicht vorenthalten. Jetzt wäre es naheliegend, dass ich als erstes meine eigenen Bücher vorstelle. Aber nein, die Ehre des ersten Eintrags wird dem Kollegen
Marcus Straßer mit PHP quick & dirty
zu teil.
PHP - quick & dirty
Dieses Buch um 30,– (ein Schnäppchen für ein Fachbuch) ist genau nach meinem Geschmack. Es ist von einem Praktiker für Praktiker geschrieben. Ich habe mir selber in den letzten Jahrzehnten alles in der Programmierung durch “Try ‘n’ Error” beigebracht und wollte manchmal den ganzen Kram aus den Fenster werfen, wenn es nicht so richtig wollte.
Marcus erstellt in diesem Buch eine Blog-Software, so wie es auch draussen in der freien Wildbahn passiert. Es ist halt nicht so, dass wir uns ewig mit Klassendiagrammen und ähnlichen beschäftigen. Sondern der Kunde kommt, sagt was er will und eigentlich soll es ja schon gestern fertig sein. Wir programmieren also nicht chaotisch, aber schnell und funktional. Oder wie Marcus es bezeichnet quick and dirty.
Das Buch behandelt in 12 Workshops von der Projekt-/Konzeptionsphase, über die ersten Schritte der Programmierung, bis zur Wiederverwendung von Code alle wichtigen Bereiche der Software-Entwicklung. Natürlich werden wichtige Praxisthemen nicht ausgelassen. So gibt es einen eigenen Workshop zur Security von PHP-Applikationen oder auch einen 40-seitigen Teil zum Debugging oder wie kann man einen Awendung einfach erweitern. Gerade die Fehlersuche kostet uns am meisten Zeit und da brauchen wir wirklich jeden noch so kleine Praxistipp. Und die gibt es hier zur genüge. Endgültig überzeugt war ich bei “Tu’s mit Excel: Viele SQL-Strings auf einmal erstellen”. Ich hatte das Gefühl der Autor hat mir über die Schulter geschaut, denn genau diese Vorgehensweise mache ich andauernd um Zeit zu sparen.
Das Buch ist sicher nichts für den kompletten Programmierlaien, aber wer in PHP einsteigen will und schon programmieren kann, hat ein gutes Praxisbuch in der Hand. Und auch dem Profi, welcher nicht rein akademisch programmiert, sondern sein Leben mit dem Erstellen von PHP-Programmen verdient, kann noch das eine oder andere aus dem Buch mitnehmen.
Um es mit Marcus Straßer zu sagen:
Programmiere quick & dirty!
So schnell wie möglich und so schmutzig wie nötig.
Natürlich kriegt ihr das Buch sofort bei Amazon “PHP-Projekte – quick and dirty: 12 Praxis-Workshops für schnelles Programmieren“
Und als Bewertung nicht drei Daumen hoch, sondern 5 von 5 möglichen Gurus:
5 von 5 möglichen Gurus
ähnliche Posts:
- Programmieren mit php und mySQL
- Joomla!-Extensions mit PHP entwickeln
- PHP und WordPress: Themes und Templates selbst enwickeln
- Wer will “Das Blogger-Buch”?
- 8 Tipps für WebDesigner
- am Montag, 22. Februar 2010 um 18:54 erstellt und wurde unter Bücher abgelegt.
- Der Post besitzt diese Tags: Fachbuch, php, Praxis, Programmieren, Tipps, Tricks, Workshops
- Du kannst alle Antworten darauf mit dem RSS 2.0 Feed verfolgen.
- Du kannst eine Antwort schreiben.
- Du kannst einen TrackBack von Deinem eigenen Blog setzen.
drucken
Der Artikel hat Dir geholfen?
Warum spendierst Du mir nicht einen Kaffee?
Kommentare zu diesem Artikel
Hey! Super, danke für den Tipp! Werde mir das Buch mal näher anschauen.
Vor allem die Punkte Tricks und Techniken für schnelles Programmieren, Ein PHP-Framework im Eigenbau und Copy & Paste – aber richtig finde ich interessant!
5 Gurus
Und eine weitere Quelle für Technicken, wo man sich als Helfer in PHP-Foren und IRC-Channels nur noch ne Kugel durch den Kopf jagen möchte. =)
Wer braucht schon qualitative Software für ne Seite die sich in den nächsten 100 Jahren nicht verändern soll.
PS: Ich habe aus einer vertrauenswürdigen Quelle einen Ausschnitt aus dem Buch gezeigt bekommen, wenn dies tatsächlich keine Satire sein soll, dann dient dieses Buch allenfalls als Negativbeispiel. Wer den darin vorhandenen Hinweisen folgt, schadet sich auf Dauer gesehen mehr, als einen das Buch weiter bringt.
So hab ich auch lange Zeit gedacht, aber ganz ehrlich: so wird man nicht glücklich als Programmierer. Schon gar nicht, wenn man sich ein Jahr später mit dem eigenen Müll, den man verzapft hat, nochmal auseinandersetzen und ihn anpassen soll. Da liegt kein Seegen drauf.
Meine Erfahrung hat gezeigt, dass die zwei Stunden die man am Anfang vielleicht in ein (zumindest grobes) UML-Diagramm investiert, sich nach hinten raus fünf bis zehnmal lohnen, weil man eben nicht alle Dateien durchwühlen muss, wie denn nun der komische Funktionsaufruf war, den man sich vor zwei Wochen mal ausgedacht hat und den man seitdem nicht mehr benutzt hat, nun aber dringend braucht.
Natürlich ist es besser, all die Grundregeln zu berücksichtigen. Und auch ein grobes Diagramm ist besser als gar keines. Aber trotzallem: Oft ist es nicht die “Riesen”-Applikation, welche gewünscht wird und auch nicht die Neuerfindung am Softwaremarkt. Meistens sind es kleine Funktionen und Anpassungen an einem bestehenden System, welche überschaubar sind.
Das Buch richtet sich auch nicht an die Anfänger in der Softwareentwicklung, sondern an Profis die wissen, was sie “verbrechen”
lol.. was anderes kann man über dieses Buch nicht sagen…
Sorry, aber dieses Buch ist der letzte Müll.
Ich habe es nicht selbst gelesen, aber wenn das tatsächlich Zitate aus dem Buch sind, dann gute nacht (siehe
http://www.phphatesme.com/blog/buchtipp/buchtipp-php-quick-dirty/ )
Hi Leute!
Eine Frage: Warum bewertet Ihr Dinge, welche ihr nicht selbst kennt? Aber das Buch ist keine Anleitung zum guten Programmieren, sondern wie kann ich schnell (quick & dirty) etwas hacken. Für große Projekte sind die Tipps wirklich nicht gedacht. Es ist eher eine Art etwas schnell zu erledigen.
Natürlich ist eine gute Doku (vor dem Projektstart) wichtig!!
Auch OOP und ein sauberer Stil erleichtern die eine oder andere Arbeit (besonders Monate nach dem Projektende). Aber manchmal ist “quick & dirty” auch ganz gut.
Also es ist eigentlich wie immer: Die Wahrheit wird irgendwo in der Mitte liegen.
Ganz einfach, weil wir die Folgen eines solchen Handelns schon mindestens einmal zu spüren bekommen haben.
Wie ich in meinem vorherigen Kommentar ja schon erwähnte, der einzige Fall, in dem man so arbeiten kann ist, wenn diese Software NIE wieder an ihrem Quellcode angefasst wird.
Sollte man doch nochmal etwas an dem Quellcode ändern müssen, dann steigt die benötigte Arbeitszeit schnell um ein vielfaches an, und damit auch die kosten.
Und um das ganze von der Kundenseite zu sehen, wer lässt sich eine zweite Seite von jemanden machen, wo eine vergleichsweise kleine Änderung nochmal die selben Kosten verursacht, wie vorher die Entwicklung der gesamten Seite. Geschweige davon, wenn er von einem anderen Entwickler erfährt, wie hoch die Qualität in Wahrheit ist.
Ich kann ja verstehen, dass es für weniger erfahrene sinnvoll klingt, aber es rächt sich IMMER.
Also, für klein(st)e Hacks halte ich PHP eher für ungeeignet. Dafür gibt es Perl und Shellscripts. Und wenn man ein bestehendes System anpasst (welches ja hoffnungsvollerweise sauber strukturiert und dokumentiert ist, als größeres System … nicht wahr?), dann sollte man auch bei Änderungen die vorgegebenen Strukturen beibehalten, damit man den vorhandenen Code nicht verschmutzt.
Ich hab gestern zum ersten mal PHPCodesniffer über eine meiner privaten Seiten laufen lassen und bin fast vom Stuhl gefallen, was der alles bemängelt hat, aber wenn man drüber nachdenkt macht es Sinn. Die Leute haben sich bei jedem sniff was gedacht und ihn nicht einfach nur eingebaut “weil der Papa das so sagt”. Was ich zum Anlass nehmen werde meinen kompletten Code nach und nach anzupassen.
Trackbacks zu diesem Artikel