RailsSummit Latin America 2008

Get Started. It's Free
or sign up with your email address
RailsSummit Latin America 2008 by Mind Map: RailsSummit Latin America 2008

1. Chad Fowler

1.1. Title: Evolution of a framework

1.1.1. the framework of a developer

1.2. Be Remarkable!

1.2.1. "Purple Cow" by Seth Godin

1.2.1.1. Mainly a business/marketing book

1.2.1.2. But devs can borrow alot of ideas for building their carrers

1.2.2. Chad's Example: Ipod

1.2.2.1. Joined a saturated market

1.2.2.2. Its price was way more expensive than average

1.2.2.3. Turned out to be a world fever!

1.2.3. My Example: Nintendo NES

1.2.3.1. Released in a time where the home console market was considered dead(~1983)

1.2.3.2. Tons of low-quality games that saturated the marked causing a massive loss of public interest in games

1.2.3.3. It bringed the market back to life and turned to be a synonym of electronic entertainment

1.2.4. IT Shops market resembles the initial scenario of both examples

1.2.4.1. Programmers == Lemmings

1.2.5. People with jobs aren't remarkable

1.3. "You are a product"

1.3.1. Do you trespass the investments they put in you?

1.4. Learn2Learn and Learn to share knowdlege

1.4.1. Pragmatic Thinking and Learning by Andy Hunt

1.5. Rails is the bleeding edge tool for building Web Apps

1.5.1. To leverage it well you MUST learn Ruby decently!!!

1.5.2. Closures are responsible for 83% of the cool stuff you can do with Ruby

1.5.3. Fluency is productivity

1.5.3.1. "Experts makes things easy"

1.6. Changes

1.6.1. Keep calm even if the world is falling apart

1.6.1.1. "Doom"

1.6.2. Real experience comes from Changes

1.6.3. Brings Evolution, don't be afraid of it!

1.7. Criticism

1.7.1. Keep your critical sense high

1.7.2. Be critical but keep it to yourself

1.7.2.1. Do something better instead of talking

2. Jay Fields

2.1. General "rules-of-thumb" for writing good tests

2.1.1. 1 object per test-case

2.1.1.1. problematic instantiation = bad smell

2.2. Exposed major Ruby test frameworks

2.2.1. Selenium

2.2.1.1. Good tool but Far from perfect

2.2.1.1.1. 1000 ways to do the same thing. Can turn to a mess.

2.2.1.1.2. Speed issues

2.2.2. Test::Unit

2.2.3. RSpec

2.3. "Remove the pain from testing"

2.3.1. Do every effort for

2.3.1.1. Ex: In a project jay invested lots of time to remove DB access from tests

2.4. 100% Coverage

2.4.1. Foul goal

2.4.1.1. Doesn't mean your app is properly tested

2.4.2. Focus in high quality tests at high business value parts instead

2.5. Smoke Testing

3. Hanrigou

3.1. Acceptance Test Paralellism with Selenium Grid

3.2. Default acceptance test scenario in RoR

3.2.1. Rspec + Selenium

3.2.2. Main issue: Selenium is slow

3.3. Selenium grid

3.3.1. Enforces parallel acceptance tests

3.3.2. Common steps

3.4. Fixtures are bad!

3.4.1. Initializing the domain object in the own test is better

3.4.2. Use ObjectMother pattern instead

3.5. Don't turn your back on acceptance tests

4. Obie

4.1. The Hashrocket Way

4.1.1. A living proof of successful agile+lean driven company

4.1.2. PivotalTracker

5. David Hansson (Q&A)

5.1. Rails 2.2 Multithreaded

5.1.1. Its mainly done, but time is needed to say it's fully ok

5.1.2. No big deal for MRI users due to the lack of native threads

5.1.3. JRuby users actually are the only ones that will really leverage this improvement.

5.1.3.1. JRuby threads == java.lang.Thread

5.2. Rails evolution philosophy

5.2.1. Purely lean

5.2.2. No milestones defined

5.2.3. Rails major design changes tends do be fewer by now

6. Lai & Bui (Phusion)

6.1. Scalability

6.1.1. Ahmdal's Law

6.1.1.1. Load distribution calculations considering sequential/parallel processing

6.1.2. Major Bottleneck is I/O

6.1.3. Application Scaling

6.1.3.1. Spreading app servers over different machines

6.1.3.2. Load balancers

6.1.3.2.1. Can be done via DNS as well

6.1.3.3. Caching

6.1.3.3.1. Page rendering cache (Fragment Cache)

6.1.3.3.2. DB Access cache (Memcached)

6.1.4. Database Scaling

6.1.4.1. Master Slave Replication

6.1.4.2. Multi-Master Replication

6.1.4.3. Sharding

6.1.4.3.1. Absolutely no data normalization

6.2. New collaboration project : Yummius (URL anyone?)

7. Chelimsky

7.1. Acceptance Test Driven Planning

7.1.1. Acceptance criteria defined at planning

7.1.2. helps to estimate

7.2. Stories

7.2.1. User Stories Applied by Mike Cohn

7.2.2. Different stories templates

7.2.3. "Feature Injection" concept by Chris Matts

7.3. RSpec

7.4. Cucumber