500 Lines or Less
"What I cannot create, I do not understand."
-- Richard Feynman
This is the source for the book 500 Lines or Less, the fourth in the Architecture of Open Source Applications series. As with other books in the series, all written material will be covered by the Creative Commons - Attribution license, and all code by the MIT License: please see the license description for details. In addition, all royalties from paid-for versions will all go to Amnesty International.
The production of this book has been made possible by the financial support of PagerDuty.
Every architect studies family homes, apartments, schools, and other common types of buildings during her training. Equally, every programmer ought to know how a compiler turns text into instructions, how a spreadsheet updates cells, and how a browser decides what to put where when it renders a page. This book's goal is to give readers that broad-ranging overview, and while doing so, to help them understand how software designers think.
Contributions should not focus on the details of one algorithm or on the features of a particular language. Instead, they should discuss the decisions and tradeoffs software architects make when crafting an application:
- Why divide the application into these particular modules with these particular interfaces?
- Why use inheritance here and composition there?
- Why multi-thread this but not that?
- When should the application allow for or rely on plugins, and how should they be configured and loaded?
Writing for a book like this should be fun, so we're trying to keep process to minimum. Here is our basic set of procedural guidelines:
When you start coding, try to submit one pull request early (e.g. somewhere between 50-100 lines), so that we can catch any early problems that we never thought about.
After that first commit, feel free to submit pull requests as often or as infrequently as you like.
When you are done your "first draft" of your code, do let us know in the commit message, or by emailing us directly (emails below). We'll assign a reviewer or two to your work at that time.
|Name||Affiliation||Project||Online||GitHub||Email (if you choose)|
|Audrey Tang||g0v.tw, Socialtext, Applefirstname.lastname@example.org|
|Kresten Krab Thorup||Trifork||torrent email@example.com|
|Taavi Burns||Previously at Points, now at PagerDutyfirstname.lastname@example.org|
|Guido van Rossum||Dropboxemail@example.com|
|A. Jesse Jiryu Davis||MongoDBfirstname.lastname@example.org|
|Sarah Mei||Ministry of Velocity||testing framework||sarahmei|
|Ned Batchelder||edX||templating email@example.com|
|Leah Hanson||static firstname.lastname@example.org|
|Christian Muise||University of Melbourneemail@example.com|
|Carlos Scheidegger||AT&T Researchfirstname.lastname@example.org|
|Cate Huston||Image Filter email@example.com|
|Yoav Rubin||Microsoft||In-memory functional database||yoavrubin|
|Dessy Daskalov||Nudge Rewards||Pedometerfirstname.lastname@example.org|
|Carl Friedrich Bolz||King's College London||object email@example.com|
|Jessica Hamrick||University of California, Berkeleyfirstname.lastname@example.org|
|Allison Kaptur||Hacker School||byterun||@akaptur||@email@example.com|