Verdammt, jetzt will ich auch eine Schriftart basierend auf einem Vault Alarm designen. 😡
Warum sind alle so gemein zueinander? Habt euch einfach lieb und programmiert ein Videospiel! Pew pew!
Das Buch ist wirklich eindrucksvoll, ich verstehe den Hype jetzt. Ich fand den Mittelteil trotzdem etwas cringe, aber der Schluss hat die Kurve noch gekriegt.
Interessant und unterhaltsam geschrieben, habe ich gerne gelesen. Es ist gar nicht so technisch wie ich vermutet hätte, sondern vielmehr eine gut aufbereitete Reise durch schlaue, einfallsreiche, innovative Frauen, die mit Computern zu tun hatten. Kann ich empfehlen!
Fand ich eine gute, lesbar geschriebene Sammlung von Anekdoten, Anleitungen, Tipps, Tricks und Fun Facts. Nicht super konkret, aber das werte ich positiv. Es scheint Marianne Bellotti vor allem darum zu gehen, die Leser ins richtige Mindset zu bringen, so dass man einen eigenen Weg finden kann.
Ein weiteres Buch von Dave Copeland, diesmal ein Framework für Senior Softwareentwickler. Ich fand es wieder sehr gut und realistisch. Copeland ist nicht so hand-wavey, wie andere Leute schnell werden, sondern sagt auch mal „Und wenn du deine Vorgesetzten mit diesem Argument auch nicht überzeugen kannst, dann stell dich auf eine lange Diskussion ein, oder poliere schon mal deinen Lebenslauf.“
Viele im Buch angesprochenen Sachen habe ich mir in meiner Laufbahn bereits angeeignet, aber einige auch noch nicht. Es war in jedem Fall gut, alles so gesammelt zu lesen.
Ein kurzes, lustiges Buch über die sogenannten „SOLID Principles“ und Softwareentwicklung. Viele gute Stellen, hier ein paar Beispiele:
I also promise that if this book sells well, the follow up, “XP: The Way to Motivate Little Children To Close JIRA Tickets At A Big Horrible Technology Company Run By People Who Do Not Understand Technology”, will be dedicated to Kent Beck.
Und:
Maybe we could call this a “responsibility”, but I like to use words in the right way, since words have, you know, meaning and stuff.
Und:
If Uncle Bob had used the canonical domain of professional wrestling, he would’ve seen that such a leap of abstraction would be difficult without more than one use case.
In diesem Buch geht Avdi Grimm sehr detailliert darauf ein, wie man selbstsicheren Code schreibt. Im Buch geht es (wie der Name andeutet) vor allem um Ruby, aber auch allgemein sind sehr viele gute Refactoring-Tipps enthalten, die Code cooler machen. Ich fand es lesenswert und schaue bestimmt ab und zu noch mal rein!
Manche Stellen waren ein bisschen zu lang, manche ein bisschen zu kurz, aber insgesamt habe ich mir einiges angestrichen für später. Besonders gut fand ich es, wenn es um weichere, menschliche Themen ging oder um pragmatisches Abwiegen von Alternativen. Man merkt, dass Copeland viel Erfahrung mitbringt, die er hier auch gut transportiert.
Ich hatte noch nie von David Farley gehört, bis er neulich in irgendeinem Podcast zu Gast war, den ich gehört habe. Dort hat er erwähnt, dass er dieses Buch veröffentlicht hat, und ich habe es direkt bestellt.
Insgesamt fand ich es ziemlich gut und überzeugend! Besonders die erste Hälfte hat mich sehr zu nachdenken angeregt. Die zweite Hälfte wiederholt viele der Themen noch mal und beleuchtet sie aus einer etwas anderen Richtung – das war dann etwas weniger spannend zu lesen.
Trotzdem würde ich sagen, dass es sich hier um eine gute Zusammenfassung von Farleys Philosophie handelt, und dass ich hoffentlich noch lange über einige der hier besprochenen Aspekte nachdenken werde.
Richtig gut! Seit letztem Sommer bin ich ja endlich Rubyentwickler, darum ist jedes Buch, in dem es um Object-Oriented Design geht, direkt eine gute Investition. (Dieses Buch hier gibt es praktischerweise auch in JavaScript- und PHP-Editionen, darum ist vielleicht für jeden was dabei! Ich habe aber lediglich die Ruby/Milch-Variante gelesen.)
Im ganzen Buch geht es um das gleiche Codebeispiel: Das Lied „99 Bottles of Beer/Milk“. Anfangs ist der Code noch extrem simpel gehalten (das Buch nennt es „Shameless Green“, das werde ich mir auf jeden Fall merken), aber durch „Neue Anforderungen“ müssen immer mehr Features hinzugefügt werden. Damit die Komplexität nicht explodiert, wird man darum auf eine Reise durch Refactorings genommen, die den Code immer modularer werden lassen. Jeder Schritt ist ausführlich und nachvollziehbar erklärt, auf jedes Detail wird eingegangen und Alternativen werden abgewogen.
Da juckt es einen direkt in den Fingern – Ich kann es kaum erwarten, meine nächste Klasse zu schreiben!
Dieses Buch hätte ich lieber schon vor ein paar Jahren lesen sollen. Ich fand richtig gut, wie Sandi Metz sehr feine Unterschiede zwischen verschiedenen Designs herausgearbeitet hat. Sie hat nicht einfach „richtige“ Designs vorgesetzt, sondern ein Beispiel vorgestellt, die Probleme erklärt und dann Schritt für Schritt verbessert, um die Aspekte von Object Oriented Design zu erklären.
Immer wieder gingen mir kleine Lichter auf, durch die ich mich an vergangene Projekte erinnert habe, bei denen genau das besprochene Designproblem aufgetreten war. Ich wünschte, ich hätte damals schon dieses Buch in meinem Werkzeugkoffer gehabt, das hätte bestimmt geholfen!
Eines schönen Tages dachte ich mir: „Moment mal! Ich muss manchmal mit Legacy Systemen arbeiten! Vielleicht sollte ich mich mal etwas fortbilden, wie ich das möglichst effektiv tun kann!“ Darum bestellte ich dieses Buch. Leider kann ich es nicht empfehlen. Direkt auf einer der ersten Seiten definiert Feathers „Legacy Code“ als „Code, der keine Tests hat,“ und im ganzen Rest des Buches geht es nur darum, wie man Klassen so auftrennen kann, dass man Teile von ihnen Testen kann. Ich finde, das ist eine zu starke Vereinfachung und überhaupt nicht, was ich mir erwartet hatte. Die Codebeispiele sind alle in Java und C++ (das könnte ich vielleicht noch verzeihen), aber sie sind auch viel zu ausführlich und zu langweilig – eigentlich geht es immer um Accounting oder Reservierungen oder Payrolls. Die verschiedenen beschriebenen Methoden sind einander zu ähnlich, als dass ich jetzt (Minuten, nachdem ich das Buch beendet habe) noch mehr als drei nennen könnte. Insgesamt habe ich nicht das Gefühl, besonders viel aus diesem Buch in meinen Alltag mitnehmen zu können. Sehr schade!
Abgesehen von dem Inhalt, den Feathers absichtlich geschrieben hatte, war meine (relativ neue, definitiv nicht erste) Ausgabe dieses Buchs voller Rechtschreibfehler im Prosa und im Code, mitten im Satz aufhörender und anfangender Seiten und teilweise haarsträubenden Layoutfehlern. Für ein so teures Buch finde ich das fast schon unverschämt.
Das Buch war einigermaßen interessant, aber auch sehr frustrierend. Es geht meistens darum, wie Manager von großen Computerspielherstellern (mehrere dutzend bis wenige hundert Mitarbeiter) fragwürdige Entscheidungen treffen und dann alle normalen Angestellten hundert Stunden pro Woche arbeiten müssen. Aber ohne das so richtig zu thematisieren. Das Kritischste, was gegen das allgegenwärtige „Crunchen“ gesagt wird, ist ungefähr „Ist es wirklich nötig, den Geburtstag seines Kindes zu verpassen? Alle sagen ‚Ja!‘“. Da hätte ich mir schon eine kritischere Auseinandersetzung mit dem Thema gewünscht.
Eine kurze Tour durch Gedanken, die man sich machen sollte, wenn man Sidekiq benutzt. Tolle Urlaubslektüre!