https://github.com/darius/chispa
Indexed text search in <500lines
https://github.com/darius/chispa
Last synced: 5 months ago
JSON representation
Indexed text search in <500lines
- Host: GitHub
- URL: https://github.com/darius/chispa
- Owner: darius
- License: other
- Created: 2015-02-24T15:57:15.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2015-03-15T04:04:34.000Z (over 11 years ago)
- Last Synced: 2024-04-18T14:39:11.574Z (about 2 years ago)
- Language: Python
- Size: 8.4 MB
- Stars: 2
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.md
Awesome Lists containing this project
README
*500 Lines or Less*
===================
This is the source for the book *500 Lines or Less*, the fourth in the
[Architecture of Open Source Applications](http://aosabook.org) 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](LICENSE.md) for details. In addition, all
royalties from paid-for versions will all go to Amnesty International.
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
MichaelDiBernardo
mikedebo@gmail.com
Dustin Mitchell
Mozilla
cluster
djmitche
dustin@mozila.com
Audrey Tang
g0v.tw, Socialtext, Apple
spreadsheet
audreyt
audreyt@audreyt.org
Greg Wilson
Mozilla
web-server
gvwilson
gvwilson@third-bit.com
Kresten Krab Thorup
Trifork
torrent client
krestenkrab
krab@trifork.com
Taavi Burns
Points.com
data-store
taavi
taavi.burns@points.com
Kragen Javier Sitaker
Canonical Hackers
search-engine
@kragen
@kragen
kragen@canonical.org
Guido van Rossum
Dropbox
crawler
gvanrossum
guido@python.org
Erick Dransch
Upverter
Modeller
EkkiD
erick.dransch@upverter.com
Sarah Mei
Ministry of Velocity
testing framework
sarahmei
Leah Hanson
static analysis
astrieanna
leah.a.hanson@gmail.com
Christian Muise
University of Melbourne
flow-shop
haz
christian.muise@gmail.com
Carlos Scheidegger
AT&T Research
rasterizer
cscheid
carlos.scheidegger@gmail.com
Marina Samuel
Mozilla
ocr
emtwo
msamuel@mozilla.com
Cate Huston
Image Filter app
catehstn
catehuston@gmail.com
Yoav Rubin
Microsoft
In-memory functional database
yoavrubin