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.

Mission

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?

Contribution Guidelines

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:

1. 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.

2. After that first commit, feel free to submit pull requests as often or as infrequently as you like.

3. 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.

Contributors

Name	Affiliation	Project	Online	GitHub	Email (if you choose)
Mike DiBernardo	freelance	editorial	@mdibernardo mikedebo.ca	MichaelDiBernardo	[email protected]
Amy Brown	indie	editorial	amyrbrown.ca @amyrbrown	amyrbrown	[email protected]
Dustin Mitchell	Mozilla	cluster		djmitche	[email protected]
Audrey Tang	g0v.tw, Socialtext, Apple	spreadsheet	@audreyt	audreyt	[email protected]
Greg Wilson	Mozilla	web-server	@gvwilson	gvwilson	[email protected]
Kresten Krab Thorup	Trifork	torrent client	@drkrab	krestenkrab	[email protected]
Taavi Burns	PagerDuty	data-store	@jaaaarel	taavi
Guido van Rossum	Dropbox	crawler	@gvanrossum	gvanrossum	[email protected]
Erick Dransch	Upverter	Modeller	@ErickDransch	EkkiD	[email protected]
Sarah Mei	Ministry of Velocity	testing framework	@sarahmei	sarahmei
Ned Batchelder	edX	templating engine	nedbatchelder.com @nedbat	nedbat	[email protected]
Leah Hanson	Google	static analysis	@astrieanna	astrieanna	[email protected]
Christian Muise	University of Melbourne	flow-shop	@cjmuise	haz	[email protected]
Carlos Scheidegger	AT&T Research	rasterizer	@cscheid	cscheid	[email protected]
Marina Samuel	Mozilla	ocr	www.marinasamuel.com @emtwos	emtwo	[email protected]
Cate Huston		Image Filter app	www.accidentallyincode.com/ @catehstn	catehstn	[email protected]
Yoav Rubin	Microsoft	In-memory functional database	@yoavrubin	yoavrubin
Dessy Daskalov	Nudge Rewards	Pedometer	@dess_e	dessy	[email protected]
Carl Friedrich Bolz	King's College London	object model	cfbolz.de @cfbolz	cfbolz	[email protected]
Jessica Hamrick	University of California, Berkeley	sampler	www.jesshamrick.com @jhamrick	jhamrick	[email protected]