- 1. Keynote: See you on the trail!, Nick Sutterer, apotonick
- 2. Maintaining a 5yo Ruby project, Simone Carletti
- 3. Cryptography for Rails Developers, Christopher Rigor
- 4. Frontend Choices, Alex Coles
- 5. Writing Your Own DSL Using Ruby, Ricardo Nacif
- 6. POROs to the Rescue, Marcelo De Polli
- 7. Concurrent-Ruby: Ruby in the Concurrent World, Lucas Allan
- 8. Object Oriented Design, Rails and Why You Should Think Twice Before Leaving the Rails Way, Rafael França
- 9. Semantic Web, @yaso
- 10. Keynote: Better Programmers, Caffo
- 11. On Memory, John Crepezzi
- 12. Building a Single Page App, Netto Farah, ifttt
- 13. Clean Architectures, Fabiano Beselga
- 14. Contributing to Open Source: From the Beginning to Lessons Learned, Carlos Antonio
- 15. Property Testing on Rails, Andrew Rosa, andrewhr
- 16. MRuby: Change the Embedded Development Way, Thiago Scalone 4:50PM
- 17. Micro Problems!, Marcos Matos
- 18. Urban Legends: What You Code Makes You Who You Are, PJ Hagerty
- 19. Keynote: The Soul of Software, Avdi Grimm
Resumo das palestras do Tropical Ruby 2015.
Fez muita a apologia ao álcool e colocou a contribuição com opensource como uma forma de preencher a falta de propósito no trabalho do dia-a-dia.
Criticou a arquitetura do rails, sugeriu uma arquitetura mais orientada a domínio (trailblazer).
Reforçou a necessidade de se inspirar, tirar pausas e trabalhar menos. Falou sobre curtir a vida e como trabalhar overtime não é produtivo.
Também deu um exemplo de resiliência, dizendo que as vezes demora para um trabalho dar resultado ou receber feedback positivo.
- self fulfilling
- you work with the stuff you want
- sharing
- what you do is important, people use it
- huge models, views and controllers
- adding a layer makes people call you an astronaut
- before filters (business code)
- callbacks
- helpers on views, logic, conditionals
- dispatch (html/json)
- auth
- validation
- business logic
- persistence
- rendering
-
diagram
-
controller contains no logic, it just dispatches to "operations"
-
no, no, no, callbacks
-
cells for complex views, otherwise, just plain rails views. You'll still have templates
-
the core is operations (domain layer)
-
operations orchestrate
- form object (validation, specify fields), defines a contract
- process
- operations are not limited to a singles model. It orchestrate multiple models `run Comment::Create`
- DDD
http://leanpub.com/trailblazer
Além de passar um vídeo conscientizador sobre a caça predatório de tubarões e trazer chocolates da Itália, compartilhou recomendações para manutenção de projetos legados. Trouxe experiências das trincheiras mantendo projetos com mais de 5 anos. Reforçou a idéia de fazer muitos experimentos, medir os resultados, documentar e comparilhar.
- 1 day
- more gems, and more gems
- 2 years (+ node)
-
go, erlang, lotus, sidekiq, rails, gems, libraries
-
numbers of lines of code (cloc -> 60k ruby loc)
- everybody speaks the same language
- identify patterns
- they may fail
- make then noticeble
- stupid names
- code climate
- new things are added always with an API
- always wrap APIs. It allows you to change the underling code
- AR::Base methods are not allowed outside models
- use objects
- do not raise by design, return objects
- Contact finder
Apresentou um resumo de RSA, deu dicas de segurança para Rails, como usar versão mais recente de ssl. Apresentou um breve histórico dos padrões de criptografia e da transição dos algorítmos simétricos para assimétricos após diversas falhas de seguranças. Fez uma piada engraçada dizendo que o nickname no twitter crigor lembra o nome do cantor Chrigor.
- CLI openssl
- attacks: poodle, freak, beartbleed
- set ssl v23
- do not use AS::MessageEncriptor with always the same key
- generate a key with a random salt
- RbNaCl
Apresentou uma retrospectiva de como o desenvolvimento frontend evoluiu nos últimos 10 anos e como isso influênciou o Rails e consequentemente a forma como estruturamos nossas aplicações. Concluiu com sua opinião pessoal de que devemos separar completamente o front-end e o backend através de APIs. Também comentou sobre a possibilidade de compartilhar código em ambos os lados.
Conversei com ele no coffee-break e ele disse que as duas apps ficam no mesmo repositório (/frontend e /backend) e que os deploys são feitos todos juntos. Versionamento de APIs é um problema pra eles e não resolveram mto bem. Os testes são isolados e no frontend eles tem um mock service invés de subir a app rails.
- 2004: IE6 has 96%, no jquery, first rails commit, gmail pre beta
- Today: single page applications
- "Rails is so 2005"
- rjs (linktoremote)
- prototype
- jquery
- nobackend.com
- meteor.com
- lots of frameworks
- content dependent
- general <-—> personal wikipedia <-—> google docs, gmail
- indexing problems
- how unique is the view to be rendered?
- Ember is like Rails (inherit a single object, routing, vocabulary)
- Rails as an API
A palestra foi muito voltado em como usar e não quando usar. Já tem um livro sobre o assunto como construir uma DSL.
Conversei com o João Brito sobre o assunto e a nossa conclusão foi que DSL é boa quando vc precisa expor uma interface fácil de usar. Fazer uma DSL apenas para vc usar.
Outro insight bacana foi a ponderar a necessidade de usar metaprogramação no journey. Não conseguimos identificar um outro jeito de transformar a string vinda na request em código (por isso usamos send(string)).
Outra conversa com o Carlos ele falou pra sempre implementar o respondtomissing qnd usar o methodmissing.
- Relação entre mineirês e DSL
- Clareza
- Comparação entre capybara e selecium driver puro
Gherkin (externa) Rspec, Factory Girl (internal)
- blocks (closures)
- proc/lambda
- & (converte proc <-> bloco)
- instanceeval
- self (e a relatividade)
- send
- methodmissing
Deu um ótimo exemplo de refactoring usando POROs (plain old ruby objects). Ver os slides para maiores detalhes. Opiniões muito sensatas, entre elas disse que "tudo o que modela o domínio da app é um model" e discutir onde colocar o código não é tão relevante assim. Outra "don't overengineer" (não resolva problemas que vc não tem). Melhor palestra do dia.
Comentário pessoal: esta idéia de que basta usar orientação a objetos para melhorar a estrutura do app não é única ao Rails. Eu também fazia uns apps mto ruins em Objective-C no começo por colocar todo código dentro dos callbacks do SDK. A coisa toda mudou qnd eu comecei a criar mais classes e separar os concerns, usando patterns de OO e classes que não eram do framework.
- "todo código é código legado"
- Usar objetos simples
- Value Object
Para quem vem do mundo Java não vai ver nada de novo neste talk. Ele apresenta diversas abstrações de concorrência disponíveis na biblioteca concurrent-ruby. Tem um livro em Java que mostra tudo isso.
CSP e imutabilidade? STM?
-
MRI tem GIL (impede paralelismo mas não concorrência)
-
concorrência é difícil. Usar concurrent-ruby prove abstrações e uma implementação mais sólida do que fazer algo caseiro.
Object Oriented Design, Rails and Why You Should Think Twice Before Leaving the Rails Way, Rafael França
Com enorme humildade disse que cresceu muito refletindo sobre consequências das decisões de design do Rails way, listou as alternativas e apontou que existem outros problemas como a maturidade do seu time, criando problemas de ramp up de novos membros, a organização dos times, preferências pessoais. Não caia na ditadura do pragmatismo. Não caia na ditadura das boas práticas. Create patterns, not standards. Pondere o custo das indireções e no custo do caos. Não tome decisões automáticas.
Foi o único talk que foi além de software e falou como outros problemas da organização afetam a qualidade dos projetos e influenciam na tomada de decisão da arquitetura.
Um projeto não é só código. Existem problemas humanos e de organização. Não existe bala de prata.
Depois rolou uma discussão sobre como outros elementos afetam o desenvimento, por exemplo as agências com suas demandas com prazos curtos e especificações mudando constantemente.
- trabalhou com código muito legado
- problemas causados por arquitetura mal definida, código mal escrito
- tentativas frustradas de fugir do rails ways
Definição abstrata (subjetiva). Mas ele definiria como sendo MVC, estrutura de diretórios, callbacks, "the exception must carry the weight of".
Esperar pelos slides. Tem tudo. Muitos diagramas.
Listou os problemas do rails way 🤘 e apontou para SOLID como uma solução.
Listou as atuais alternativas arquiteturais: hexagonal, dci, microservices, trailblazer.
Como funciona o W3C e o processo de construção de standards para web.
- RDF
- Turtle
- Json-ld
Típico keynote do Caffo. Engraçadinho e motivacional. Cheio de dicas de como melhorar seu nível de felicidade e produtividade: seja organizado, diga não, valorize seu tempo, anote as coisas, faça listas, crie hábitos, automatize as coisas ou delegue, faça coisas diferentes de programação.
Trabalha na rapgenius.com!!! Listou algumas ferramentas e features do ruby que nos permitem analizar o uso da memória e estatísticas do GC. Deu exemplos de como usar menos memória com lazy enumerables e freezed strings. Boa palestra sobre ruby puro. Também deu uma lição de como fazer uma investigação e analizar dados de forma científica.
Outra palestra com histórico da evolução do frontend e como isso influenciou o Rails. Legal ele dizer que SPA trouxe muitos conceitos do flash/flex. Eu diria que trouxe do smalltalk. Levantou o questionamento da necessidade de se construir uma SPA. Muitas dicas de ferramentas e formas de reaproveitas templates renderizados no backend. Eles usam modulejs, como nós. Reforçou a necessidade de monitorar erros no frontend. Reforçou problemas com memory leaks, bloquear a execução, "Don't just learn a framework, learn Javascript".
Discutiu o que é e qual problema resolve. Web é apenas um mecanismo de entrega e não deveria definir sua arquitetura. A arquitetura deveria revelar a intenção do que aquele projeto faz. Banco de dados é um detalhe. Definição de um fluxo de dados e dependências rigoroso através de boundaries, use cases e entities. Destaque para o uso da gem caze para transações. Definiu heurísticas para escolher usar clean architecture: distância entre lógica e view.
lannister app on github.
Começou contribuindo com projetos aleatórios e não sabia muito bem o que estava fazendo. Com o tempo as contribuições com projetos da ptec e o rails ganharam corpo. Mas a sobrecarga de responsabilidades da vida criaram momentos de burnout, mais de uma vez. Coisas que podem motivar vc a contribuir é começar se ajudando, contribuindo com algo que vc já usa. Olhando sempre como os outros trabalham e tentando entener como fazer isso também. É necessário usar seu tempo livre mas também usar um pouco do tempo de trabalho. Reforçou a idéia de que não basta motivação mas também disciplina. Compartihou diversos links com a trajetório oss de alguns contribuidores. E por último, jogou a reflexão sobre se contribuir faz sentido para o indivíduo.
Excelente talk, falou com muita clareza sobre um jeito diferente de testar onde vc invés de dar os exemplos de entrada vc diz o que é esperado do código e deixa uma engine gerar os dados de entrada. Deu um exemplo de como outras linguagens e comunidades podem trazer idéias para o ruby.
Mostrou um mundo totalmente diferente, embedded devices, onde engenharia de software está muito atrasado em termos de ferramentas e boas práticas. Interessante ver como eles estão migrando tudo, inclusive a linguagem ruby, para este mundo e revolucionando a produtividade.
Este cara lavou a alma. Botou pra fora todos os problemas com microserviços possíveis e imagináveis. Faz vc pensar um milhão de vezes antes de propor tal arquitetura. Argumenta a favor de uma abordagem onde se começa um mini-lito e partir daí vai extraindo alguns serviços e conforme se aprende no processo vc pode gostar e fazer mais disso. Deixa claro os trade-offs, os custos da escolha.
Uma lição de respeito e como contruir uma comunidade melhor onde as pessoas trocam informações e olham umas para as outras com admiração. Destruindo com estereótipos.
Reflexão profunda sobre a forma como construimos software e a forma como a nossa produção influencia a vida de todos. Uma ode a construção de uma comunidade mais acolhedora e humana. Nunca me senti tão em casa em uma conferência. Valeu a pena.
Cara, valeu pelo trabalho! Muito bom! 👍