Approach towards reading aosa

[Greg Wilson]

On 2013-07-31 10:51 AM, Matt Brubeck wrote:
> On 7/31/2013 3:57 AM, Anubhav Yadav wrote:
>> However, I am confused as to how I should start reading the book for
>> the month, "The Architecture of Open Source Applications?". Should I
>> first get a fair Idea of the application described throughout the
>> chapter (for eg, Chapter 1Asterisk), download its source code, try to
>> understand it, and then read the corresponding chapter.
>> Or should I just read the whole book chapter after chapter?
> I find the chapters quite readable on their own.  In fact, I wish more 
> of my own projects had architecture overviews like this so I could 
> direct newcomers to read them *before* diving into the source code!
Hi everyone,

Hope you don't mind me sticking my nose in, but a couple of universities 
have used these books in grad courses and reading groups, and based on 
their feedback, I think that reading all the chapters in order will 
probably be mind-numbing :-)  Instead, you might get more out of just 
these ones:

If you want to stick to Volume 1:
* http://www.aosabook.org/en/asterisk.html
* http://www.aosabook.org/en/audacity.html
* http://www.aosabook.org/en/bdb.html
* http://www.aosabook.org/en/eclipse.html
* http://www.aosabook.org/en/llvm.html
* http://www.aosabook.org/en/mercurial.html
* http://www.aosabook.org/en/packaging.html
* http://www.aosabook.org/en/sendmail.html

If you want to include Volume 2:
* http://www.aosabook.org/en/distsys.html
* http://www.aosabook.org/en/freertos.html
* http://www.aosabook.org/en/gdb.html
* http://www.aosabook.org/en/git.html
* http://www.aosabook.org/en/ironlang.html
* http://www.aosabook.org/en/mailman.html
* http://www.aosabook.org/en/openmpi.html
* http://www.aosabook.org/en/puppet.html
* http://www.aosabook.org/en/twisted.html
* http://www.aosabook.org/en/zeromq.html

What those groups (particularly the one at Waterloo) seemed to find 
helpful as they read was paying attention to the level of description: 
when were the authors talking at a very high level (design principles, 
major components, historical forces shaping the software, etc.), and 
when did they dive down into nitty-gritty detail because one of those 
larger issues hinged on a particular low-level implementation decision 
or obstacle?  One reader told me that he felt it was like watching a 
yoyo: authors seemed to go from high to low and back to high over and 
over again because the big picture simply didn't make sense without an 
understanding of some key details, while the low-level details didn't 
make sense without knowing how they fit into the bigger picture.  I'd be 
really curious to hear if you get the same sense, and whether you think 
you'd have to do the same thing to explain what you're working on to a 
new hire joining your team.

Cheers,
Greg