RubyConf Brasil 2012

Get Started. It's Free
or sign up with your email address
Rocket clouds
RubyConf Brasil 2012 by Mind Map: RubyConf Brasil 2012

1. StartupDEV

1.1. startupdev.com.br

1.1.1. Foco: Startups que desejam um protótipo

1.1.2. Sistema inicial em 48h

1.2. Visão Lean

1.2.1. Menos linhas de código

1.2.2. Escopo limitado pela pontuação de features (timebox)

1.2.3. Não criar barreiras

1.2.4. Comunicação clara

1.3. Técnicas

1.3.1. Requisitos: mockup em papel

1.3.2. Delivery => Done (o que está entregue não precisa ser revisto)

1.3.3. TDD

1.3.3.1. 100% de cobertura

1.3.3.2. test/code ratio ~ 3,5

1.3.4. Integração contínua

1.3.5. Deploy contínuo

1.3.5.1. Heroku

1.3.6. Rails Template

1.3.7. Refactory

1.3.8. Gem integration

1.4. Ferramentas

1.4.1. Typus / ActiveAdmin*

1.4.2. Postgresql / MongoDB

1.4.3. DelayedJob / Sidekiq*

1.4.4. Devise / Omniauth*

2. Como Não Escrever o 
 Projeto Lixo do Futuro

2.1. Conheça os pontos negativos

2.2. Domine a API

2.3. Use a melhor ferramenta para o problema

3. Micro Cloud Foundry (PaaS)

3.1. @pmenglund, [email protected]

3.2. Promotion code: RubyConfBrazil

3.3. Also works in VirtualBox

3.4. Bosh

3.4.1. More than chef or puppet

4. Infiltrating Telecoms using Ruby

4.1. Speakers

4.1.1. Ben Klang @bklang

4.1.2. Ben Langfeld @benlangfeld

4.1.3. MojoLingo

4.2. Examples

4.2.1. Integration between text and voice

4.2.2. Verbalizeit (online translation)

4.3. Sample app: 3958 8592

4.4. Adhearsion

4.4.1. Check it!

5. Poderosas Interfaces Rails

5.1. Os três filtros das interfaces

5.1.1. #1 Os métodos devem implementar o que seus nomes dizem fazer

5.1.2. #2 Deve ser eficiente (unix like)

5.1.3. #3 Avisar o cliente caso haja algum erro

5.2. Idéia: não utilizar models AR nos controllers

5.2.1. Models AR devem se preocupar somente em se persistir.

5.2.2. Deveriam ser chamados por outros models não AR.

5.3. Design by Contract

5.4. Presenters

6. Uma Restrospectiva sobre 
Projetos Problemáticos

6.1. rails best practices gem

6.2. Dreyfus Model

6.3. Testar o necessário

6.4. Práticas sem contexto são dogmas

6.5. Presenters

6.6. @danielvlopes, @jeffrydegrande

7. Travis CI

8. Vamos falar sobre concorrência

8.1. @josevalim

8.2. Haskell

8.3. ruby: #curry

8.4. Técnicas de gerenciamento de estado

8.4.1. Locks

8.4.1.1. Ruby

8.4.2. Transactional memory

8.4.2.1. Clojure

8.4.3. Message passing

8.4.3.1. Go

8.4.3.2. Erlang

8.5. Referências

8.5.1. Celluloid

8.5.2. Elixir

8.5.3. Book: Seven languages in seven weeks

9. Por que nosso código cheira mal

9.1. @bkeepers, github.com/bkeepers

9.2. Referências

9.2.1. Book: Refactoring

9.2.2. Book: Grow OO Software, Using Tests

9.2.3. Video: Fast Test, Slow Test

9.2.4. Video: Fast Rails Test

9.3. #1 Unit Tests are Complex

9.3.1. When objects are tighly copled

9.3.2. When objects are doing too much

9.3.3. Too much setup needed

9.4. #2 Unit Tests are Slow

9.4.1. When interact with slow components

9.4.2. When don't test object by isolation

9.4.3. When bootstrap heavy frameworks

9.5. #3 Tests tightly coupled to a framework

10. Aplicações mais simples

10.1. Watch

11. Conheçendo as entranhas do Rails

11.1. @rafaelfranca, github.com/rafaelfranca

11.2. rails-api

11.3. Mailer assíncrono

11.4. Notificações

12. Escalabilidade com JRuby e TorqueBox

12.1. TorqueBox

12.1.1. Rack

12.1.2. Schecule Jobs

12.1.3. Background Processing

12.1.4. Long-running daemons

12.1.5. Caching

12.1.6. Messaging

12.1.7. Websockets

12.1.8. Clustering

12.2. Many services in one (easy to config and maintain)

12.3. Applications

12.3.1. immutant.org

12.3.2. dyn.js

12.3.3. escalante.io

13. Quem precisa de WebSockets?

14. Reunindo Ruby, Java e uma Arquitetura Orientada a Serviços

14.1. Case: projeto grande em Rails 2 com uma equipe inchada

14.1.1. Testes lentos

14.1.2. Usava o banco como fila

14.1.3. Longos períodos de QA

14.2. Separação em aplicações diferentes

14.2.1. Compartilhamento de código via gems

14.2.2. Podem utilizar tecnologias diferentes

14.2.3. Integração através do resque

14.2.4. API REST com json para comunicação

14.2.5. Não existe banco compartilhado

14.3. As duas aplicações passaram e evoluir independentemente

14.4. Falhas

14.4.1. Problemas de comunicação entre equipes

14.4.2. Documentação

14.4.3. API pública e API privada deve estar separadas

14.5. foreman gem

14.6. Conclusões

14.6.1. Construa aplicações pequenas e focadas em algum trabalho

14.6.2. Só compartilhe dados pela API, não pelo banco de dados

14.6.3. API privada deve ser mínima

14.6.4. Não misture a representação de saída com seus models

14.6.5. Separe fontes/bancos de dados

14.6.6. Rails Engines não é solução para isso

15. Boas e Más Práticas de App Rails em Ambiente Corporativo

15.1. Explosão de código

15.1.1. Abuso de monkey-patch

15.1.2. Forks pessoais

15.1.3. Deixar upgrades para depois

15.1.4. Forçar o Rails além do seu limite

15.1.5. The Rails Way is the only way

15.2. Como evitar

15.2.1. Teste seus monkey-patches

15.2.2. Extraia gemas para facilitar a manutenção

15.2.3. Pense além do model/view/controller/helper

15.2.4. Limite o número de pontos de integração

15.2.5. Bom design OO

15.3. Estratégias de teste

15.3.1. Gerenciar testes funcionais por estória

15.3.2. Abuso no uso de mocks

15.3.2.1. Re-testar o framework

15.3.2.2. Mockar o objeto sendo testado

15.3.3. Ter um time separado cuidando dos testes

15.3.4. Investir em automação de teste de UI

15.3.5. Testes só rodam em determinado ambiente

15.4. Desejável

15.4.1. Testes funcionais de user journeys e não por estória

15.4.2. Muito mais testes unitários que testes funcionais

15.4.3. Todo mundo é dono dos testes

15.4.4. Código de testes também é código

15.4.5. Evite acoplar testes com determinado ambiente

15.5. Deployment e Problemas em ambiente de produção

15.6. O que não fazer ao lidar com dados

15.6.1. ActiveRecord num schema que vc não controla

15.6.2. Usar vários BDs na mesma aplicação

15.6.3. SqlServer

15.6.4. Usar NoSQL como RDBMS

15.7. Desejável

15.7.1. Divida em aplicação/serviços menores

15.7.2. Defina quem tem posse dos dados

15.7.3. Representantes do negócio em decisões arquiteturais

15.7.4. Considerre usar processos ETL

15.7.5. Teste!

15.8. Problemas com capistrano

15.8.1. Encoraja deployments fora da integração contínua e direto do controle de versão

15.8.2. Branches para ajustes de produção

15.8.3. Ciclo de vida complicado

15.8.4. Processos dif[iceis de auditar

15.9. Desejável

15.9.1. Não usar o ciclo de vida padrão

15.9.2. Empacotar aplicação usando rpm, deb, etc.

15.9.3. Use capistrano para instalar os pacotes nos ambientes

16. Testes de interface com JRuby e Sikuli UI

16.1. Book: The Rails View

16.2. Bot baseado em reconhecimento de imagens e entradas através de emulação de teclado e mouse

16.3. Aplicação: Testes de aceitação em emuladores

17. Addicted to Stable

17.1. Automated tests

17.2. Automate backup and restore

17.2.1. Test it regularly

17.3. Redudant servers

17.4. Archive data

17.5. Automate deployment

17.6. Collect and fix exceptions

17.7. Collect and graph metrics

17.8. Email, push and sms alerts

17.9. Automate failover

17.10. Stable your team

17.11. Few words: automate, fail, empower, celebrate