Teenage Mutant Rails Apps BOF

teenagemutantrailsappsbof.txt

why do it?
1) faster test suite
2) scalability
3) team scalability: how many engineers can you fit on the HEAD of one code base?
4) separation of concerns, maintainability
5) ownership
6) a path to upgrading to newer versions of rails 

Why you might NOT do it?
1) hard
2) extra process needed to organize amongst teams in addition to within teams
3) performance of communication layer between parts
4) fiefdoms / inter-team dispute
5) management may not see the value
6) other?

how do you do it?
1) where do you start?
2) how do you share code? gems
3) sharing javascript, css, etc.
4) how do you make the time when you also have to deliver features?
5) what are the testing implications of this?
6) what happens when parts go down, how to message users so that it makes sense to
them what parts of a site can and can't be used.
7) ?

models for breaking apps up:

1) different apps -same db
2) different apps, service api
3) hybrid model db reads and service writes
4) ?

Very rough notes FROM the BOF -- tips/ideas/thoughts that might be helpful in
breaking up our apps

Domain Driven Design
Letting the product people draw a diagram of the system and splitting it up based
on _their_ understanding of it.
Dividing app based on workflow and state machine ideas: what are the different user
flows? what is the context in which info is being used? 
if something can't be described as a simple state machine it probably shouldn't be
one application?

several recommendations to read Paul Dix's book
http://www.amazon.com/Service-Oriented-Design-Rails-Addison-Wesley-Professional/dp/
0321659368/ref=ntt_at_ep_dpi_1


how can we separate concerns and teams without causing overhead when one team needs
another team to change their api, and the other team has other stuff to do.
Consider github: fork the project, make the changes, make a pull request. The
api-publishing team can then incorporate your changes at its convenience but the
consuming team is not held up.

using a document database to solve the problem ? distributed databases?
caching services info
expose the data as an internal endpoint ? but don't want overhead.

don't feel obligated to upgrade code until it's actually a problem 


What next? 
------------
Most of us attending the BOF did not yet have answers, just lots of questions.
Let's start sharing our answers as we come up with them. 

Join the google group:
http://groups.google.com/group/teenage-mutant-rails-apps-talk?msg=new&lnk=gcis