Programming with Ease
$73.50
Suggested Price
$42.50
Bundle Price

Programming with Ease

About the Bundle

Alle drei Bände der Serie Programming with Ease in einem Paket. Darin findest du alles, was ich dir zu den wichtigsten Phasen der Softwareentwicklung im Hinblick auf Clean Code Development für langfristig hohe Produktivität sagen kann.

  1. Im Band Slicing findest du die Anforderungsanalyse im Rahmen eines iterativ-inkrementellen Vorgehensmodells aus deiner Perspektive als Entwickler ausführlich dargestellt. Sie sichert dir die Klarheit, die du für sauberen Code brauchst.
  2. Mit Flow-Design lernst du eine Methode kennen, um aus klaren Anforderungen Lösungen mit sauberer Struktur zu entwickeln. Ein pragmatischer, leichtgewichtiger Entwurf ist unabdingbar für sauberen Code.
  3. Und mit Test-first Codierung sorgst du am Ende dafür, dass sich dein Entwurf auch sauber im Code manifestiert.

Evolvierbare Software ist testbar, verständlich, ordentlich, flexibel. Dazu braucht es ein passendes Mindset, Prinzipien und Praktiken. All das vermittle ich dir mit Programming with Ease.

Du kannst die Bücher in der obigen Reihenfolge lesen oder in umgekehrter (so wie ich den Stoff meistens in meinen Trainings vermittle) oder auch einzeln. Aber lies sie überhaupt. Und arbeite die Übungsaufgaben durch. Reflektiere dann mit den Musterlösungen.

Viel Erfolg und Spaß wünsche ich dir auf deiner Reise zu langfristig hoher Produktivität für dich und dein Team!

  • Share this bundle

About the Books

Test-first Codierung

Programming with Ease - Teil 1
  • 491

    Pages

  • 98,217

    Words

  • 100%

    Complete

  • PDF

  • EPUB

  • MOBI

  • WEB

Clean Code bedeutet wandlungsfähiger Code. Wandlungsfähigkeit setzt voraus, dass du keine Angst hast, Code zu verändern. Du willst ihn ja nicht unwissentlich verschlimmbessern und das nicht bemerken. Stabilen Code liefern und sofort wissen, wann er reif zur Lieferung ist, sind Grundpfeiler, auf denen deine langfristig hohe Produktivität ruht.

Automatisierte Tests sind seit langem unverzichtbar, wenn es um nachweisbare und nachvollziehbare Korrektheit von Software geht. Leider haben sich automatisierte Tests trotz hervorragender Werkzeugunterstützung und methodischer Empfehlungen wie Test-Driven Development (TDD) und Behavior-Driven Development (BDD) noch nicht als Selbstverständlichkeit durchgesetzt. Die Testabdeckung ist daher in vielen Codebasen, auch frischen, nicht ausreichend, um regressionsfreiheit sicherzustellen. Das Sicherheitsnetz, das automatisierte Tests spannen sollen, damit du darüber angstfrei Codieren kannst, ist weit und/oder löchrig. Woran mag das liegen?

Die Gründe sind sicher vielfältig für dünne Testabdeckung. Einer sticht für mich jedoch heraus: mangelnde Systematik. Es fehlt eine Guideline, wie du als Entwickler, der du mit einem Programmierproblem konfrontiert bist, geradlinig zu testabgedecktem und auch noch ordentlichem Code kommst.

Der red-green-refactor Prozess in TDD ist eine gute Idee - die allerdings in der Praxis von vielen Entwicklern als zu wenig unterstützend erlebt wird. Sie versuchen sich daran zu halten, fühlen sich jedoch schnell entweder allein gelassen oder überfordert bei ihrem Praxisproblem. Aus Frustrations wird dann das Kind mit dem Bade ausgeschüttet und ganz auf automatisierte Tests verzichtet. Oder es wird in der Community nach Hilfe gesucht, die Literatur gewälzt - doch als Antwort wird vor allem "Du musst es eben nochmal und genauer nach den Regeln probieren!" gegeben. Beides ist nicht hilfreich.

Automatisierte Tests sind heute nicht mehr nice to have, sondern gehören zu fachgerechter Arbeitsweise, wenn du professioneller Softwareentwickler sein willst. Sie nicht zu schreiben, sich nicht darum zu bemühen, ist keine Option.

Und mit TDD einfach nochmal und nochmal gegen die Problemwand zu rennen, bringt auch nicht unbedingt die Lösung, sondern erzeugt Frust und Kopfschmerzen. Denn wenn es mit TDD nicht recht klappen will, dann liegt das nicht unbedingt daran, dass du als Entwickler TDD nicht begreifst. Es kann auch daran liegen, dass der TDD Prozess einfach nicht zu deinem Problem passt.

An TDD ist deshalb nichts falsch. Es greift nur schlicht in der Praxis zu kurz. Die Welt der Programmierprobleme ist größer und bunter als das, was in TDD Coding Dojos an kleinen Problemen behandelt wird.

In mehr als 10 Jahren Beschäftigung mit Clean Code Development habe ich mich daher bemüht, ein Vorgehen zu entwickeln, das umfassender und systematischer unterstützt, Probleme in der Codierung zu lösen. Das Motto ist sozusagen: "Keine Angst vor dem blinkenden Cursor in deiner IDE!"

Test-first Codierung als Teil meines Programming with Ease Konzeptes für Clean Code Development nimmt dich an die Hand bei der Bewältigung von Programmierproblemen, die es in fünf Kategorien einteilt:

  • trivial
  • einfach
  • kompliziert
  • komplex
  • chaotisch

Diese Kategorisierung ist an das Cynefin Framework von IBM angelehnt, das Führungskräfte situationsgerecht bei Entscheidungen unterstützen soll.

In der test-first Codierung wird diesen Kategorien aber jeweils ein anderer Problemlösungsansatz zugeordnet. Triviale Probleme gehst du anders an als komplizierte oder komplexe. Klingt logisch, oder? TDD - genauer: classical TDD - hat darin auch seinen Anwendungsfall; doch der ist begrenzt auf nur einen der Problemschwierigkeitsgrade. Und komplexe Probleme sind das nicht.

Gemeinsam ist den Ansätzen für alle Schwierigkeitsgrade, dass du die Codierung mit mindestens einem Test beginnst: dem Akzeptanztest. Deshalb test-first im Titel. Die Begründung ist zwiefach: 1. Wenn du nicht zuerst einen Test schreibst, ist die Wahrscheinlichkeit groß, dass du keinen schreibst. 2. Wenn du dein Denken zuerst auf einen Test richtest, also auf die Außenansicht deiner Lösung, nimmst du die Perspektive eines Benutzers an. Das führt tendenziell zu einer besseren Schnittstelle für deinen Code und zu höherer Testbarkeit.

Test-first Codierung ist aber nicht alles. Es ist nur die letzte Phase eines mehrschrittigen Prozesses, in dem du Anforderungen in hochqualitativen Code umsetzt. Diesen Prozess fasse ich unter dem Titel Programming with Ease zusammen, weil die Programmierung "von Anfang bis Ende" durch mehr Systematik einfacher werden soll.

Allerdings ist Test-first Codierung der erste Band in meiner Programming with Ease Buchreihe. Codierung ist schlicht das, was dir als Softwareentwickler am nächsten liegt und jeden Tag im wahrsten Sinne des Wortes unter den Nägeln brennt. Deshalb will ich dich dabei abholen und unterstützen. Deine Motivation wird bei der Codierung am höchsten sein, etwas Neues zu lernen und deine Gewohnheiten zu verändern. Zumindest hoffe ich das.

Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einem test-first Vorgehen in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Codebeispielen und Abbildungen aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das meine ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Stabilität und Ordnung in deiner Software.

Ich wünsche dir viel Freude bei der Programmierung!

-Ralf Westphal, info@ralfw.de

PS: Wenn du Lust hast, findest du auch einen Überblick darüber, was ich mit Test-first Codierung meine, in einem Youtube-Interview, das David Tielke mit mir geführt hat. In knapp 30 Minuten reiße ich darin die wesentlichen Aspekte des Ansatzes an.

Ver. 1.2.4.20201129

Softwareentwurf mit Flow-Design

Programming with Ease - Teil 2
  • 80%

    Complete

  • PDF

  • EPUB

  • MOBI

  • WEB

Voraussichtlicher Erscheinungstermin: September 2020

Die Softwareentwicklung braucht mehr Planung, wenn sie nachhaltig arbeiten will.

Davon bin ich überzeugt, auch wenn es sich anachronistisch und kontraproduktiv anhört. Dass der Wasserfall überwunden wurde, ist zweifellos gut. BDUF ist natürlich keine gute Sache - aber nicht wegen des D für Design, sondern wegen des B für Big. Leider scheint diese Feinheit aber unter die Räder des guten Willens von Agilität und Software Craftsmanship gekommen zu sein.

Die Kunst des Softwareentwurfs wird nicht gelehrt, ist mein Eindruck. Systematisch, greifbar, für andere nachvollziehbar über Software nachzudenken, steht nicht hoch im Kurs. Auf dem Zettel des Agilität ist das Gespräch über inkrementelle Anforderungen im Rahmen eines iterativen Vorgehens. Super! Auf dem Zettel der Software Craftsmen sind TDD und Prinzipien der Codegestaltung. Auch super! Nicht weniger braucht es für korrekten und sauberen Code. Bei aller Notwendigkeit halte ich das aber nicht für hinreichend.

Wer sich auch mit der besten Definition of Done sofort an TDD macht, wird über kurz oder lang den Code in die Ecke der Unwartbarkeit pinseln. Verständlichkeit und Wandelbarkeit kann man nicht (oder nur begrenzt) in Code "hineincodieren". Damit ist es wie mit der Korrektheit: die lässt sich auch nicht in Code "hineintesten".

Korrektheit hat Voraussetzungen schon in der Anforderungsanalyse und braucht eine konsequente test-first Disziplin beim Codieren. Verständlichkeit und Wandelbarkeit haben ihre Voraussetzungen gleichermaßen vor der Codierung und zwar in einem expliziten Entwurf. Think before Coding muss das Motto lauten. Ansonsten startet die Codierung mit einem zu unklaren Bild und geht durch zu viele Veränderungen, die den Code unsauber zurücklassen. Denn Refaktorisierungen werden gewöhnlich als zu aufwändig angesehen; es muss ja weitergehen mit dem nächsten Issue, wenn eines erfolgreich codiert wurde. Und wohin auch refaktorisieren? Wie sieht eine saubere Struktur eigentlich aus?

Ordnung als Grundlage für langfristig hohe Produktivität musst du also planen. Du musst ein Modell deines Codes entwerfen, das du in der Codierung fast schon mechanisch umsetzt. Ja, das meine ich so: Codierung ist nach einem guten Entwurf fast langweilig. Die Lösung kennst du ja schon. Die Spannung ist dann raus aus der Softwareentwicklung, zumindest eine gewisse kreative Spannung.

Das Modell ist noch nicht der Code. Seine Beschreibung musst du also in einer anderen formalen Weise vornehmen als mit einer Programmiersprache.

Und das Modell ist schon mehr als der Lösungsansatz. Der geht dem Modell voraus und umreißt, wie du dir "ganz informell" eine Lösung ausmalst.

Denn um ein Ausmalen geht es, um Visualisierung. Für mich bedeutet Softwareentwurf visuelle Softwareentwicklung. Mit UML ist dieser Gedanke auch schon einmal verbreitet worden - nur hat UML keine Akzeptanz in der Praxis gefunden. 90% der Entwickler nutzen UML nicht. Visuellen Entwurf deshalb als gescheitert anzusehen, hieße jedoch, das Kind mit dem Bade auszuschütten. Für mich liegt der pragmatische Weg in der Mitte: Wir brauchen einen leichtgewichtigen, visuellen Entwurf. Wir brauchen eine alltagstaugliche Entwurfsmethode. Genau die möchte ich dir in diesem Buch vermitteln.

Der Softwareentwurf ist für mich die mittlere von drei Phasen, in denen du Anforderungen in hochqualitativen Code transformierst. Sie ist für mich sogar die wichtigste, weil im Entwurf das anliegende Problem grundsätzlich gelöst wird. Hier ist deine ganze Kreativität und Erfahrung gefragt. Du musst die Domäne verstehen und dein Codierungshandwerkszeug beherrschen. Beim Entwurf schreibst du zwar keinen Code, doch er kann deshalb nicht unabhängig von den Einschränkungen stattfinden, die dir Code auferlegt. Entwurf muss durch technische Kompetenz informiert werden.

Deshalb ist es mir auch sehr wichtig, dass eine Entwurfsmethode leichtgewichtig ist. Nur dann hast du genug Motivation, sie zusätzlich zu deiner Codierkompetenz zu lernen.

Und mir ist wichtig, dass du als jemand mit Codierkompetenz entwerfen lernst, weil dann sichergestellt ist, dass der so wichtige Entwurf nicht im luftleeren Raum entsteht. Entwürfe von "Astronautenarchitekten" sind nicht praxistauglich und haben der Disziplin Entwurf einige Imageschaden zugefügt.

Entwurf ist natürlich etwas anderes als Codierung. Das muss er sein, sonst würde er nichts bringen. Er ist zum Beispiel deklarativ und nicht imperativ. Dennoch glaube ich daran, dass es nicht zu schwer ist, dass du dir diese Kunst aneignest. Oder noch besser: Dein ganzes Team sollte das visuelle Entwerfen lernen. Denn mit einem visuellen Entwurf kann man im Team viel unaufwändiger und schneller Lösungsalternativen durchspielen oder überhaupt Lösungen kommunizieren.

Entwurf ist dabei zu unterscheiden von Dokumentation! Entwurf findet vor der Codierung statt. Ein visueller Entwurf nimmt Codestrukturen vorweg. Dokumentation hingegen findet nach der Codierung statt. Dafür wird UML durchaus gern benutzt - nur ist das etwas ganz anderes, als worum es in diesem Buch geht.

Du wirst hier deshalb auch keine sauberen Zeichnungen sehen. UML-Tools oder auch nur Visio benutze ich nicht und rate dir nicht, danach zu schielen. Pragmatischer Entwurf findet mit Handzeichnungen statt. Das ist ein Aspekt seiner Leichtgewichtigkeit. Sobald du mit dem "Reinzeichnen" anfängst, geht Spontaneität verloren und bekommt ein Entwurf zu viel Gewicht.

Selbstverständlich ist ein Entwurf ein Plan. Doch den darfst du nicht missverstehen als "in Stein gemeißelt". Der Plan soll dich schneller machen bei der Codierung, weil einfach so eine Menge Entscheidungen getroffen wurden, als du noch nicht unter Codierungsstress gestanden hast. Doch letztlich kannst du auch vom Plan abweichen, wenn du während der folgenden Phase neue Erkenntnisse gewinnst.

Aus der "Handschriftlichkeit" des Entwurfs folgt auch, dass er für sich genommen nur schwer zu verstehen ist. Ein Entwurf wie ich ihn meine, lebt vom Diskurs. Du kannst einen Entwurf allein anfertigen und bist damit dann vertraut. Besser allerdings, wenn du einen Entwurf im Pair oder Team gemeinsam erarbeitest. Er ist dann für alle in gleicher Weise verständlich.

Dass ein solcher Entwurf anschließend einem Dritten aber "über den Zaun geworfen" werden kann, damit er dort umgesetzt wird, halte ich für ein Missverständnis. Ein Entwurf braucht mindestens die lebendige Erklärung. Der Betrachter muss ihn sich aktiv aneignen - am besten im Dialog.

Und wie wird Software nun entworfen? Was visualisiert der ominöse Entwurf? An dieser Stelle nur kurz: vor allem Datenflüsse. Datenflüsse und Module sind für mich die default Bestandteile eines pragmatisch-praktischen, leichtgewichtigen Entwurfs. Meine Gründe dafür lege ich dir ausführlich im Buch dar. Auch wenn dir das gerade noch nicht plausibel sein mag, steht das überhaupt nicht im Widerspruch zu Objektorientierung. Im Gegenteil! Ich nehme die Objektorientierung sehr ernst, genauso wie die Funktionale Programmierung. An die wird dich auch einiges im Buch gemahnen. Deshalb ist es aber noch lange kein Buch, mit dem ich dich zur Funktionalen Programmierung bringen will. Mein Ansatz ist eklektisch: Ich benutze das mir sinnvoll Erscheinende aus beiden Welten.

Wesentliches Merkmal solchen Entwurfs ist, dass er sich leicht, geradezu mechanisch in Code transformieren lässt. Das ist mir sehr wichtig. Die visuellen Beispiele im Buch unterlege ich deshalb auch immer mit Code. Sonst glaubst du mir nicht, dass ein solcher Entwurf praktikabel ist. Bubbles don't crash ist mir auch bekannt. Deshalb muss ich dir glaubhaft machen, dass dennoch bubbles ihren Sinn haben.

Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einem visuellen Entwurf in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Abbildungen und Code aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das meine ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen - auch wenn ich dich hier ein wenig vom reinen Codieren abbringen will. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Verständlichkeit und Wandelbarkeit in deiner Software.

Ich wünsche dir viel Freude bei der Programmierung!

-Ralf Westphal, info@ralfw.de

Ver. 0.6.0.20201031

Software Anforderungsanalyse mit Slicing

Programming with Ease - Teil 3
    • PDF

    • EPUB

    • MOBI

    • WEB

    Voraussichtlicher Erscheinungstermin: November 2020

    Um nachhaltig Software zu entwickeln, sind klare Anforderungen die absolute Voraussetzung. Aber wie sehen die für dich als Entwickler aus? Reicht es, wenn du mit einem Product Owner einfach ein paar Mal über User Stories sprichst und ein paar Notizen machst? Meiner Erfahrung nach, ist das nicht genug. Selbst eine Definition of Done greift noch zu kurz (wenn es sie überhaupt gibt).

    Klarheit für dich als Entwickler ist einfach etwas anderes, als Klarheit für einen Product Owner oder Auftraggeber oder Manager. Du musst Anforderungen technisch umsetzen. Deshalb sollte schon eine Anforderungsanalyse auch "auf die Technik schielen". Für die folgenden Phasen im Entwicklungsprozess - Entwurf und Codierung - sind konkrete technische Anhaltspunkte wichtig, ohne die du in Unklarheiten läufst, die dann zu Rückfragen und Konflikten führen, die wiederum Unzuverlässigkeiten in deiner Lieferung Vorschub leisten.

    Der Gedanke der Agilität, Anforderungen iterativ-inkrementell umzusetzen, ist absolut angemessen. Dass du dich mit dem Product Owner in engen Feedbackschleifen drehst, ist nötig - doch es ist meiner Ansicht nach nicht hinreichend. Der Product Owner hat schlicht einen anderen Fokus als du. Seine Verantwortlichkeit ist die Lieferung von Wert an den Auftraggeber. Deine Verantwortlichkeit als Entwickler jedoch ist die Lieferung von Qualität.

    Nachhaltige Softwareentwicklung beginnt für mich mit dieser Erkenntnis: Wertlieferung und Qualitätsproduktion müssen entkoppelt werden. Daraus folgt dann, dass die Definition dessen, was Wert darstellt, nicht gleich der ist, was Qualitätsinkremente sind. Der Softwareentwicklungsprozess wird somit um eine Phase reicher: die Analyse von Wertinkrementen.

    Im agilen Vorgehen involviert der Product Owner dich in die Definition von Wertinkrementen. Danach bist du dann auf dich gestellt. Für den Product Owner ist das optimal, denn er kann sich nun schon etwas anderem zuwenden. Du machst das mit der Umsetzung ja schon. Aus meiner Sicht ist das eine vorzeitige Optimierung. Du beginnst zu früh mit der Lösungsfindung, denn eigentlich ist die Analyse noch unvollständig.

    In diesem Buch möchte ich dir ein verfeinertes Vorgehen vorstellen. In dem dauert die Analyse zusammen mit dem Product Owner etwas länger, weil sie Wertinkremente noch in Qualitätsinkremente zerlegt. Erst die sind für eine Umsetzung konkret genug.

    Den Kern der erweiterten, entwicklerorientierten Analyse bildet eine systematische Zerlegung der Anforderungen in Artefakte von technischer Bedeutung. Die reicht hinunter bis zu Nachrichtendatentypen und Funktionen - aber keine Angst, der Product Owner wird von solchen Details verschont. Wichtig ist, dass dir das Analyseziel klar ist. Du willst eindeutige Ansatzpunkte für dein weitere Arbeit als Programmierer haben.

    Diese Zerlegung braucht allerdings ein passendes Vorgehen als Kontext. In dem ist die Iteration noch wichtiger. Deshalb unterscheide ich zwischen Lieferungen von Wert und Aufforderungen zum Feedback. Sauberer Code braucht sozusagen Hyper-Agilität.

    Und dieses Vorgehen funktioniert wiederum nicht im luftleeren Raum. Es hat als Voraussetzung, dass du die Ruhe bekommst, die du für hohe Qualität brauchst. Das funktioniert nur, wenn sich der Umgang mit dem Schätzen und Deadlines verändert.

    Slicing, Spinning, Forecasting sind die Begriffe, unter denen ich dir eine Sicht auf die Anforderungsanalyse vermitteln will, die dir als Programmierer taugt. Der Pendelschwung hin zur Product-Owner-getriebenen iterativen Softwareentwicklung war nach Jahrzehnten des Wasserfalls nötig. Doch damit solltest du als Programmierer nicht zufrieden sein - und der Product Owner auch nicht. Langfristig hohe Produktivität gibt es nicht, ohne deinen Bedürfnissen als Programmierer wieder Raum zu geben. Du sollst mit besserem Ausgangsmaterial in die Umsetzung starten.

    Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einer "entwicklergerechten" Anforderungsanalyse in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Abbildungen und Code aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das sage ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen - auch wenn ich dich hier ein wenig vom reinen Codieren abbringen will. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

    Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Zuverlässigkeit bei deinen Softwarelieferungen und mehr Wert deiner Software für den Kunden.

    Ich wünsche dir viel Freude bei der Programmierung!

    -Ralf Westphal, info@ralfw.de

    Ver. 0.0.0.0

    The Leanpub 45-day 100% Happiness Guarantee

    Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

    See full terms

    Free Updates. DRM Free.

    If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

    Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.

    Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

    Learn more about Leanpub's ebook formats and where to read them

    Write and Publish on Leanpub

    You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

    Learn more about writing on Leanpub