Estamos felizes em anunciar que Belo Horizonte irá sediar a sexto edição do Rails Girls no Brasil! É um curso gratuito de dois dias, que irá lhe abrir as portas para o excitante mundo da programação web, com Ruby on Rails. Não necessário nenhum conhecimento prévio em T.I.

Qual é o publico alvo? Mulheres de qualquer idade que tenham um conhecimentobásico em lidar com computadores. Já tivemos participantes de todas as idades. Por favor traga seu notebook.
Homens podem participar? Sim, mas devem vir acompanhados de uma mulher que esteja interessada. Será dada prioridade as mulheres.

Dia 1: 14 de Dezembro
TBD

Dia 2: 15 de Dezembro
Durante a manhã vamos instalar o Ruby on Rails no seu computador, se você teve algum problema antes. Faça a sua primeira aplicação web. Faremos exercícios e vamos por a mão na massa no código.

Anote em sua agenda: Evento! Rails Girls Natal (inscrições aqui)
Quando: 14 e 15 de Dezembro
Onde : TBD - Belo Horizonte, Brasil

View Larger Map
Receba mais novidades acessando nossa página no facebook.

Programar é uma tarefa extremamente complexa. neste talk vou apresentar sobre desenvolvimento web sem sofrimento com ruby on rails. vamos ver um pouco sobre ruby, filosofia do rails, casos de sucesso, mercado de trabalho e como você pode ser mais produtivo e feliz.

Quer aprender mais sobre ruby, ruby on rails e outras tecnologias?
Venha participar do 8º Encontro do GURU Sorocaba!

UPDATE: Haverá sorteio de livros de Rails para quem estiver presente!

Confira a programação:

1.Minha aplicação está pronta, e agora? /Ricardo Valeriano
Desenvolvedor e Professor na Caelum.

Tópicos da palestra:
- Quero testar meus scripts de deploy em minha máquina, o que fazer?
- Que ferramentas podem ajudar a encontrar problemas de performance?
- Conheça melhor aquela rake task que você nem lembrava que existia.
- Como reaproveitar lógica entre diversas aplicações Rails?
- Unicorn ou Thin? Nginx ou Apache?

2.Arquitetura de Front-end em aplicações de larga escala /Eduardo Shiota Yasuda
Front-end Engineer formado em Design Gráfico.

Para desenvolver um site institucional simples ou um hotsite pequeno, não é preciso muito mais que um pouco de HTML, um ou dois arquivos de CSS, alguns arquivos de JavaScript, e um sistema de CMS. No entanto, à medida que a complexidade de um site aumenta, o código passa a se tornar cada vez mais extenso, complexo, difícil de ser organizado, o projeto acaba virando um grande “spaghetti code”.

3.Rails fora dos trilhos /Rafael França
Desenvolvedor de softwares e colaborador dos projetos Elixir, Ruby on Rails e SimpleForm.

Ruby on Rails é conhecido por dar aos desenvolvedores ferramentas para terem maior produtividade. Mas, como qualquer ferramenta, o seu mau uso pode trazer problemas no futuro, diminuindo a produtividade prometida, causando complicações no desenvolvimento do projeto e prejudicando a evolução do código. Nesta palestra vou mostrar alguns erros e más práticas, como monkey-patches desnecessários, views bagunçadas e classes complexas demais, e como podemos evitar que nosso código se torne algo complicado e desprazeroso de se trabalhar.

Anote em sua agenda: Evento! 8° Guru Sorocaba (inscreva-se gratuitamente aqui)
Quando: 17 de Novembro
Onde : CEUNSP Auditório Brasital – Campus V, Praça Antônio Vieira Tavares, 73  - Salto/SP

Exibir mapa ampliado

Receba mais novidades acessando nossa página no facebook.

Focado no desenvolvimento de software, o DevDay é o maior evento de desenvolvimento de Belo Horizonte, onde todos falam a mesma língua.

Confira as palestras aprovadas:

Keynotes:
- Star Wars: Como o maior filme de ficção de todos tempos nos inspira a fazer projetos vencedores! / Alcebíades Araújo
- O Programador Lean / Rodrigo Yoshima

Lightning Talks:
- Influência da qualidade do código no ROI / Glauber Assunção
- Meteorjs / Paulo Roberto Macedo Chaves
- MongoDB no mundo real / Jean Carlo Nascimento
- Os 10 mandamentos do fracasso! / Giulia Sousa
- Programação funcional com C# / Elemar Júnior
- Regras flexíveis e agilidade para o negócio com a implantação de BRMS / Alessandro Kieras
- CanJS – Como desenvolver aplicações Web ricas de forma rápida e fácil / Pablo Aguiar
- Como funciona o projeto WebKit? / Gustavo Noronha (kov)

Palestras:
- Coffeescript no mundo real / Daniel Lopes
- Desenvolvimento x Diversidade de dispositivos Android: Boas Práticas / Matthaus M. Schall L. Vizuete
- Enterprise Integration Patterns / Elemar Júnior
- Introdução ao Scala / Juliano Alves
- Java Kinect / Breno Santos Araújo
- Motivação, você está fazendo isso certo? / Giulia Sousa
- O elo perdido: Sincronizando webapps HTML5 com o servidor / Jean Carlo Nascimento
- Python: iteradores, geradores, etc. / Luciano Ramalho
- Quando utilizar o crowdsourcing para testar meu software? / Robert Pereira Pinto
- Por que é importante para um programador .NET saber Java muito bem? / Juan Lopes
- Saindo do brownfield com refactoring / Emmanuel Brandão
- Teste seu javascript se não quiser uma macarronada para o jantar / Dyego Costa
- Universos paralelos / Vinicius Quaiato
- Visão comparativa de frameworks Web: Java, Ruby e C# / Roberto Vasconcelos Novaes

Anote em sua agenda: DevDay 2012
Quando: 20 de Outubro
Onde : UNA Campus Aimorés - Rua Aimorés 1451, Bairro Lourdes – Belo Horizonte / MG

Exibir mapa ampliado
Inscrições via: DevDay

Receba mais novidades acessando nossa página no facebook.

A Semana da Computação da USP São Carlos é um evento anual cujo principal objetivo é complementar a formação profissional e acadêmica dos alunos da USP e também de outras Universidades da região e conta com a participação direta de pelo menos 600 alunos.

O evento tem o objetivo de passar informações e visões aos participantes das áreas que não temos chance de ver na graduação. Os minicursos e palestras são escolhidos após uma vasta pesquisa, baseada em critérios como futuro da tecnologia, aceitação por parte de desenvolvedores e mercado, assim como expectativas dos participantes. Desta forma, após análise, as atividades do evento são escolhidas garantindo que o objetivo será alcançado.

Confira a programação:

24 de Setembro
08h00 – Credenciamento
09h15 – Café da Manhã e Abertura
10h30 – Identificando Oportunidades
12h30 – Futebol de Robôs
13h30 – Avanços e Aplicações da Inteligência Artificial no Mercado de Trabalho
15h00 – Coffee-Break
15h30 – AMD: APU Trinity
16h30 – SEBRAE: Como divulgar sua empresa
17h15 – Direito Digital
20h30 – Tecnologias LCD e Touchscreen

25 de Setembro
Minicursos:
- Unity 3D
- J2ME e WebApps
- Kinect: Aplicações Práticas
- OpenGL + GLSL
- Kernel Linux
- Bancos de Dados Geográficos
- .NET
- Testes de Performance em Ambientes de Alta Complexidade
- TDD: Uma Visão Prática
- Psicologia nos Jogos – O jogo da vida
- SEBRAE: Desenvolvendo Talentos Empreendedores

Coffe-Breaks (às 10h00 e 16h00)
Sarau (às 12h00)
Aprenda a comparar antes de investir (às 19h30)

26 de Setembro
Feira de Profissões (às 12h00)

08h30 – Redes Sociais e Profissionais na Promoção da Carreira
10h00 – Axoon
10h40 – Neolog
11h20 – VoxAge
13h00 – Advus
13h40 – PrimeUP
14h20 – CPqD
15h00 – Ci&T
16h00 – Everis
16h40 – Ícaro
17h20 – UOL
18h00 – Daitan Group

Concurso: Clickstream (às 19h30)

27 de Setembro
Minicursos:
- Introdução ao Game Design
- nVidia CUDA
- Ruby on Rails
- Objective-C
- Mobile Sites
- Python
- Redes e Segurança
- Responsive Web Design
- Redes Complexas

Coffe-Breaks (às 10h00 e 16h00)
Computação Forense (às 20h00)

28 de Setembro
08h30 – As 10 falhas fatais de um empregado
10h00 – Coffe-Break
10h30 – Preparing for the TOEFL IBT (The Four)
11h00 – Workshop de Iniciação Científica: Como ser um inovador
13h00 – Android, Aplicativos Móveis
13h30 – Ágil na Real
14h30 – Blue Pill x Red Pill
15h00 – Application Compatibility
16h00 – Coffe-Break
16h30 – Painel de ex-alunos
20h00 – Encerramento

Anote em sua agenda: 15° Semcomp
Onde: R. Dr. Carlos de Camargo Salles, São Carlos – Instituto de Física de São Carlos

View Larger Map

Quando: 24 à 28 de Setembro
Receba mais novidades acessando nossa página no facebook.

Qual é o publico alvo? Mulheres de qualquer idade que tenham um conhecimentobásico em lidar com computadores. Já tivemos participantes de todas as idades. Por favor traga seu notebook.
Homens podem participar? Sim, mas devem vir acompanhados de uma mulher que esteja interessada. Será dada prioridade as mulheres.

Day 1: 07th September
19h00: Installation party
20h00: Who run the world? – Luisa Bernardes

Day 2: 08th September
09h00: Registration, coffee & workshop includes learning the first steps into software craftmanship in small teams.
10h00: Welcome – Outline of the day and word from organizers
10h20: Introduction to Machine Learning – Guilherme Silveira
10h40: Introduction to Programming – Klaus Wuestefeld
11h00: Workshop
13h00: Lunch
14h00: Workshop, extend your application.
17h30: A tecnologia também pode ser bonita – Alda Cristina Rocha
17h50: Working in IT – Andrea Pinto
21h00: Afterparty! All friends and who wants to join can meet us after the workshop.

Anote em sua agenda: Rails Girls São Paulo
Onde: Locaweb – R. Itapaiúna, 2434 – Vila Andrade, São Paulo
Afterparty: Bar do Benedito - Dr. Fonseca Brasil, 289 – Morumbi, São Paulo
Incrições em:
Quando: 5, 6 e 7 de Setembro

Receba mais novidades acessando nossa página no facebook.

Programação:

1.0 – Prólogo – Instalação e configuração do ambiente
1.1 – O que é Ruby
1.2 – O que é MVC
1.3 – Começando com Rails
2.0 – “Welcome Aboard”
2.1 – Controllers
2.2 – Views
3.0 – Primeiro CRUD
3.1 – Customizando o CRUD
3.2 – Associações
3.3 – Menu de Navegação
4.0 – Testando…
4.1 – Deploy
4.2 – RubyGems
5.0 – Q&A

Pré-requisitos:

Saber lidar (ou querer aprender) com a linha de comando;
Notebook para poder acompanhar o exercício;
Já ter utilizado alguma linguagem de programação;
Entendimento do conceito de Orientação a Objetos;

Importante:

O exercício será executado em uma maquina virtual disponibilizada pelo instrutor no inicio do curso. É recomendado que o computador do aluno tenha pelo menos 1GB de memória sobressalente para execução do VirtualBox.

É recomendado que alunos com sistema operacional Linux façam a instalação do VirtualBox antes do curso, pois no caso de haver uma falta de internet, o aluno pode ficar sem poder acompanhar o exercício (o Linux pode precisar da internet para baixar pacotes de dependências).

Os instaladores para Windows e Mac OSX serão fornecidos na início da aula.

Os downloads para Linux estão no seguinte endereço: https://www.virtualbox.org/wiki/Linux_Downloads

Anote em sua agenda: Workshop de Ruby on Rails
Quando: 31 de Julho (dàs 18h30 às 22h30)
Onde : SmartMob Coworking – Rua Nunes Machado, 93, 1° Andar, Centro, Florianópolis
Inscrições: faça aqui

Receba mais novidades acessando nossa página no facebook.

Anote em sua agenda: RubyConf 2012
Quando: 30 e 31 de Agosto
Onde: Centro de Convenções Frei Caneca – São Paulo
Inscrições: R$150 (com 20% de desconto aqui - até 31 de Julho)

Receba mais novidades acessando nossa página no facebook.

Pela 3° vez em São Paulo, entre os dias 4 a 8 de Julho de 2012, acontecerá o TDC (The Developers Conference), evento que se destaca pela diversidade de assuntos, com mais de 240 palestras em 30 trilhas, e organizadas por diferentes comunidades de usuários atuantes em tecnologia e desenvolvimento de software.

Confira as trilhas:

Anote em sua agenda:
The Developer’s Conference 2012
Data: de 04 (quarta) à 08 (domingo) de Julho
Inscrições Aqui (com descontos para universitários)
Local: Universidade Anhembi Morumbi – Rua Casa do Ator, 275 – São Paulo

Receba mais novidades acessando nossa página no facebook.

Rafael França apresentou o Devise e o Simpleform

Deu tão certo que hoje é o 8º repositório com maior número de watches no Github e 12º com mais forks na rede social. E não é pra menos: “ele foi criado para ser altamente customizável, você pode customizar as views e até o HTML gerado pelo Devise”, completa Rafael. Pela popularidade, tudo indica que vem cumprindo bem esse papel.

Já o SimpleForm, como o nome sugere, foi criado também em 2009 para atender uma necessidade quase obrigatória de criação de formulários para aplicações, com o diferencial de serem forms que respeitassem as “boas práticas” exigidas para essas interfaces. Rafael inclusive frisa que um dos fatores mais importantes para a empresa é a qualidade do código gerado nos projetos, e conta que o SimpleForm foi inspirado no Wufoo, nome da empresa de Palo Alto que vive exclusivamente de customizações de formulários online. “Criamos essa solução pensando em customizar e adicionar mais flexibilidade aos formulários de Rails”, resume ele. O plano futuro para este projeto é a integração com o Twitter Bootstrap para agregar estilo ao form, entre outras funcionalidades mais específicas.

Ambos os projetos são open source, mas há também outros projetos abertos para contribuição, basta acessar: http://github.com/plataformatec

SCREENCASTS:

Devise
http://railscasts.com/episodes/209-introducing-devise
http://railscasts.com/episodes/210-customizing-devise

SimpleForm
http://railscasts.com/episodes/234-simple-form

Para ver cases e demos do código dos dois projetos, assista ao vídeo com a íntegra da palestra de Rafael França no Guru Sorocaba:

Antes de detalhar a arquitetura do sistema, Ricardo frisou a importância de se desenvolver de forma incremental, ou seja, lançar uma parte do projeto no Github (social coding) para que possa receber contribuições de outros desenvolvedores da comunidade interessados em fazer evoluir a ideia pensada originalmente.

Estão na “ToDo” list do projeto:

- Automate git clone process
- Automate project name generation
- CLI for run tests
- Pusher to notify clients
- Sample templates

Assista ao vídeo com a íntegra da palestra de Ricardo Almeida no Guru Sorocaba para ver uma demo do projeto “Canaries” e aproveitar as dicas dele para a criação do seu próprio projeto open source no Github – ou quem sabe ainda, contribuir com este mesmo:

Veja também os slides da apresentação:

Referências:

Canaries

Ruby/Git

Redis
https://github.com/ezmobius/redis-rb
https://github.com/mloughran/em-hiredis

RabbitMQ

Browsah

Veja a grade da programação do Guru Sorocaba:

09h  - Ricardo Almeida (Gonow) – “Canaries in the air”

09h30 – Rafael França (Plataformatec) – “The Plataforma Way”

10h – Coffee Break

10h30 - Nando Vieira (Codeplane e HowTo)

11h10 – Fábio Akita (Codeminer 42)

Mora em Sorocaba ou região e gostaria de participar? Ainda há vagas disponíveis, confirme sua presença pelo e-mail: gurusorocaba@gmail.com
E acompanhe as atualizações do blog Gonow para saber o que rolou durante o evento!

Acesse o formulário, inscreva-se e participe: http://goo.gl/dL9vf

Acesse os slides da apresentação:

E veja também o vídeo da palestra, diretamente da página do blog pessoal de Rinaldi Fonseca:
http://rinaldifonseca.com/criando-um-framework-com-rack-em-10-minutos/

Lucas Húngaro é desenvolvedor Ruby na Gonow Tecnologia, e se auto-define como apaixonado pelo minimalismo aplicado ao código na criação de arquiteturas bonitas e flexíveis, sendo “uncle” Bob Martin uma das suas referências favoritas.
Lucas inaugurou a trilha de palestras no Dev in Sampa que rolou no último sábado no auditório Abril, com patrocínio da Abril Mídia e da Concrete Solutions, para abordar o tema “SOLID através de BDD: um guia prático para rubistas”.

“SOLID é um conjunto de princípios que foram definidos pelo ‘uncle Bob’ que devem ser aplicados ao código orientado a objetos, no intuito de atingir um código mais desacoplado, mais coeso, e no final das contas você faz isso para que o custo de manutenção seja reduzido”, define. E se ateve a dois princípios que, para ele, são os mais importantes e que causam mais impacto no código: Single Responsibility Principle (SRP) e Dependency Inversion Principle (DIP).

Coesão e acoplamento

A tradução desses dois princípios, aplicada ao código, diz respeito a duas características: coesão e acomplamento. “O princípio da única responsabilidade propõe que uma forma fácil de você ver se está aplicando ele ou não é saber se o objeto, a classe ou a entidade tem apenas uma razão para mudar. Se ela tiver mais de uma razão para mudar, quer dizer que você já violou o princípio. E outro problema que tentamos evitar é o alto acoplamento, que é quando um pedaço de código está preso a um caso de uso e suas dependências”, explica Lucas Húngaro.

Ele defende a criação de aplicações centradas em comportamentos de negócios e não em dados. “Sem perceber, já começamos a pensar em atributo de tabela, e na orientação de objeto primeiro devemos pensar no comportamento e os dados são consequência, eles ficam escondidos”, diz. Segundo ele, a maioria das aplicações Rails acabam sendo um modelo user gigantesco, tornando-se o núcleo da aplicação e puxando tudo para si, criando assim um “domínio anêmico”, ou seja, uma classe que é muito forte e o resto é basicamente uma estrutura de dados que só fica carregando atributos de um lado para outro.
(E mostra trechos de código que embasam e exemplificam sua colocação).

Dica do “Uncle” Bob seguida como guideline por Lucas: ActiveRecord deve conter apenas validação, associações e finders, nada mais que issodeve ser tratado como uma estrutura de dados. Uma forma de aplicar isso é restringir models ActiveRecord apenas à validação, associações e finders, nada mais que isso.

Testes quebradiços = Design Ruim

Lucas Húngaro também comenta que costumava ser da turma dos que defendiam que “mocks e stubs são apenas para isolamento de sistemas externos (como gateways) pois geram testes quebradiços quando usados internamente”. Mas resolveu estudar a melhor essa questão depois de ouvir referências respeitáveis na comunidade. E chegou então à conclusão de que, na verdade, já que estava tendo problemas de teste quebradiço, o design é que estava ruim.
E descobriu que ao unir object doubles com dependency injection é possível conseguir testes muitos rápidos – que não precisa nem subir o Rails – algo na casa dos milisegundos. Além de objetos desacoplados, coesos e com custo de manutenção reduzido.
(E mostra no código como fica a implementação depois de usar a injeção de dependência, que é uma forma de atingir a inversão de dependência, ao fazer os objetos dependerem em abstrações e não em implementações).

Quanto de abstração vale a pena?

“Minha dica é: se eu sei que alguma coisa tem chance de mudar, já faço a abstração direto. Eu só não crio um adapter se eu tenho certeza que aquilo não vai mudar, o que é bem difícil. Agora, se eu tenho dúvida, preciso também preservar meu direito de mudar depois. Então, nesse caso, eu prefiro fazer um adapter, abstrair uma vez mais, para depois, se houver uma mudança, eu ter como fazer”, sugere Húngaro.
(E mostra trechos de código que embasam e exemplificam sua colocação).

“BDD é uma ótima forma de apontar problemas com o design do código – os sintomascostumam ser claros”

Dicas para verificar se seu código está “sólido”

- Pequenas peças de comportamento facilmente acessíveis: isso garante que não precisemos de setups muito elaborados e nos “força” a abstrair conceitos de negócio em forma de código.

- app console .buy (user, product, cart): abra o console da sua aplicação e veja se os processos de negócio podem serexecutados facilmente na linha de comando.

- Modele processos, não se prenda apenas a entidades. Exemplo: User assume o papel Customer para o processo de pagamento.

- Evite ao máximo colocar dublês em tipos externos. Se necessário, crie um wrapper/adapter (que esteja sob o seu controle).

- Crie o hábito de passar dependências como parâmetros (Uncle Bob)

- “Não escreva ‘fat models’” — OOP

Assista ao vídeo com a íntegra da apresentação de Lucas Húngaro no Dev in Sampa 2011:

Veja também os slides da apresentação dele:

Referências:

Uncle Bob @unclebobmartin
Michael Feathers @mfeathers
Corey Haines @coreyhaines
Gary Bernhardt @garybernhardt
Pat Maddox @patmaddox
Avdi Grimm @avdi

*Laura Loenert participou do Dev In Sampa 2011 a convite da Abril Mídia e da Concrete Solutions, patrocinadoras do evento.

Entre outros assuntos, Akita comentou sobre o futuro da tecnologia e as novas perspectivas para o mercado de TI:
http://madeinjapan.uol.com.br/2011/08/16/programador-nikkei-fala-sobre-tecnologia-e-novas-perspectivas/

Publicamos também há algumas semanas o vídeo da palestra dele no evento.
Para assistir a apresentação na íntegra, acesse:
http://www.gonow.com.br/blog/2011/07/20/veja-como-foi-a-palestra-de-fabio-akita-no-japao/

Gosto de algumas gems como o wirble, que adicionam algumas funcionalidades ao irb (e, por consequência, ao console do Rails). O problema é que, em projetos que utilizam o Bundler, fica complicado adicionar esse tipo de gem ao Gemfile, pois elas não são realmente dependências do projeto e nem todos gostariam de utilizá-las.

Como programadores costumam ser bem radicais (ainda mais com essa mania de ser “opinionado”), isso sempre gera discussões e atritos. Eu já penso que é mais fácil simplesmente buscar uma solução, e eis aqui uma: https://gist.github.com/1096494.

Colocando esse snippet no seu arquivo .irbrc, ao abrir o irb (ou console do Rails), todas as gems do gemset global do RVM serão colocadas no load path, podendo assim serem requeridas na sequência. Eu não costumo usar gemsets por projeto (uso apenas o Bundler, da maneira explicada nesse post), mas deixo o gemset global com algumas gems para esse fim. Meu arquivo .irbrc está disponível no GitHub.

Essa solução não é lá muito elegante, mas funciona muito bem para gems utilizadas no irb. Há algum tempo propus uma solução na lista do Bundler e recebi algumas sugestões, porém nenhuma me agradou (como, por exemplo, obrigar todo mundo que não quer as gems a usar a flag –without a cada bundle install). A discussão pode ser vista aqui. Até cheguei a fazer um fork do Bundler para implementar algum tipo de metadado para controlar isso, mas o código é bem complicado e acoplado, então deixei pra lá.

Acesse o post original no blog pessoal dele.

–

*Lucas Húngaro é desenvolvedor de software há 10 anos e escreve código em Ruby desde o início de 2007. Seu foco é o minimalismo aplicado ao código e como os princípios da orientação a objetos podem ajudar a criar arquiteturas bonitas e flexíveis.
Lucas palestrou no último TDC (Developers Conference) em São Paulo, acesse o post e assista ao vídeo da palestra dele.

Nessa parte do áudio sobre iOS, que continua na quinta-feira desta semana, Fernando conta da sua paixão por Objective-C, que começou há mais de 10 anos. Fala também sobre a relação do Objetive-c com o C e da sua experiência com iPhone e iPad, que já soma 2 anos no portfolio.

Para ouvir o podcast, episódio 42, acesse:
http://itunes.apple.com/us/podcast/grok-podcast/id393122038

Para acessar a página do Grok Podcast:
http://grokpodcast.com/

OO = Data + Behavior

Lucas lembra que orientação a objeto nada mais é do que misturar dados com “comportamento” (atributos e métodos). E a armadilha que tendemos a começar a cair é separar os dois: “a partir do momento que você começa a separar tudo, começa a voltar ao código procedural. Eles têm que estar juntos e interagindo no seu código”, diz. E comenta que observa pessoas influentes na comunidade afirmarem que o Rails trouxe muita coisa boa mas trouxe também um vício de fazer com que os programadores esqueçam os preceitos básicos da orientação a objetos. “E como fazemos para aprender isso? Temos que praticar muito. Eu sempre fui crítico em relação ao meu código, comecei a ler bastante e só comecei a fazer direito depois de praticar muito”, completa.

Uma das dicas de Lucas é prestar atenção no que dizem os “tiozões” do software, como Kent Beck e Uncle Bob, pois são “veteranos” que já fizeram e continuam fazendo muito software, e que estão também sempre aprendendo, ensinando e compartilhando conhecimento. E a outra dica é ignorar as “prima donnas”, ou evitar aqueles que acham que já sabem tudo.

“Acredito é necessário aprender conceitos antes de sair aprendendo um monte de diferentes linguagens de programação. É bom aprender um pouquinho dos princípios primeiro para depois expandir as linguagens. Aí sim você vai aprender”, diz Lucas, e cita uma frase de Ralph Waldo Emerson para embasar seu comentário, adaptando-o ao contexto da programação: “você pode ter milhões de métodos (linguagens/ferramentas) mas quando você entende o princípio, você pode mudar a linguagem, do contrário, você terá problemas”. Do original: “As to methods there may be a millionand then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble“.

E quando há um problema no projeto, é normalmente o gerente quem leva a culpa. “Eu me considero 100% responsável pelo código que escrevo”, afirma Lucas. “Se deu bug, problema meu, devia ter me manifestado na hora ao invés de esperar que as coisas piorem lá na frente”. Resumindo: faça seu código bem feito e nao jogue a culpa nos outros, para não ter que trabalhar mais depois.

E esclarece o título da palestra: “Acredito que os testes falam. Só que às vezes mesmo com 100% de cobertura, os testes estão ruins. O MVC deixou o desenvolvedor viciado: é muito legal mas também muito perigoso, pois parece que só existe isso. Estamos tão acostumado com o Rails que abrimos o diretório e já vamos direto para o Model. Depois acabamos pensando que deveríamos ter feito outra coisa”, afirma. “Geralmente a estrutura do meu diretório app tem vários diretórios a mais: tem uma pasta para extensões, services, para modelos que não são do banco de dados. O que está lá é o padrão, mas não significa que você deva necessariamente seguir aquilo” conclui.

Dois princípios importantes do SOLID

Como aplicar o Single Responsability (ou “Princípio da Única Responsabilidade”) e o Dependency Inversion (ou “Inversão de Independência”) e identificar quando não estiver seguindo-os.

O Single Responsability afeta o que chamamos de coesão. Componentes com baixa coesão executam parte de uma responsabilidade ou mais de uma. Quando o objeto executa mais de uma responsabilidade, você terá um código extenso como resultado. E quando ele executa apenas uma parte de uma responsabilidade, você começará a ver uma fragmentação na mesma camada de software. Haverão várias partes menores que você terá que coordenar para juntar tudo. Isso é baixa coesão, e é isso que buscamos evitar através do princípio da única responsabilidade.

Já o Dependency Inversion, trata do acoplamento. E, neste caso, estamos falando em alto acoplamento, ou seja, um código preso a um caso de uso específico. Ele ficou preso a um caso de uso e você não consegue desacoplá-lo para usar em outros casos. Utilizamos a inversão de depenência para evitar esse problema.

As 3 características que desejamos para nos livrarmos disso são:

- Interface mais concisa possível: não defina nada que você não irá usar
- Narrativa consistente: pegue sua classe e comece a ler o que ela faz. Ela precisa ser capaz de executar a responsabilidade completa
- Componentes bem independentes entre eles

“A melhor forma que vejo de atingir o “Princípio da Única Responsabilidade” é pela leitura fácil do componente. Analise suas classes: se notar que há mais de uma razão pela qual uma determinada classe precisa mudar é porque você precisa quebrá-la. E, juntando isso com teste, percebi que frameworks que possuem contextos ajudam a ver isso, como é o caso do RSpec e do Riot“, diz Lucas Húngaro, que mostra no código (veja o vídeo) como fazer isso.

E uma outra observação importante, segundo a visão dele, é a necessidade de se aprender a modelar processos de NEGÓCIO ao invés de refletir entidades do mundo real. Orientação a Objetos é erroneamente associada ao mapeamento um-para-um de entidades reais mas, na verdade, devemos buscar o mapeamento de processos e interações.

Inversão de Dependência através de Injeção de Dependência (DI x DI)

A Injeção de Dependência é uma das formas de se atingir a Inversão de Dependência. “As pessoas confundem um pouco por conta do mundo Java e C#, com aqueles containers de injeção de dependência, Spring e outras coisas, onde se configura um .xml e classes abstratas. Mas no Ruby é bem mais simples”, diz. (Assista ao vídeo para ver a demonstração do código).

E uma outra dica importante é: nunca coloque mock ou stub em tipos que não são seus. Sempre for depender de algo externo assim, escreva um wrapper. E para saber mais sobre isso, acesse o paper “Mock roles, not objects“.

E sobre mocks e stubs, Lucas Húngaro mostra como e quando se deve usá-los. E explica: “Desenvolver software orientado a objeto basicamente é gerenciar dependência. É um objeto que depende do outro, que depende do outro, e assim sucessivamente. Você tem que garantir que a supercífie de contato entre eles seja a menor possível. Porque se for muito grande, você terá problemas. Se você tiver que escrever um monte de stub para uma coisa que não tem nada a ver com aquilo que você está querendo testar, pode ter certeza de que quebrou o encapsulamento”. ”Então ao invés de fazer queries, você faz um comando”, e recomenda a leitura do artigo “Tell, Don´t Ask” para entender melhor o que isso significa.

Checklist

- Crie o hábito de passar dependências como parâmetros
- Escreva código declarativo (assertividade)
- Reduza ao máximo o uso de estado compartilhado (nunca faça um objeto usar estado global de outro)
- Ao “terminar” um componente, pergunte:
DRY?
Apenas uma responsabilidade
Tudo muda à mesma taxa (velocidade/quantidade)?
Depende de coisas que mudam menos? (Sempre uma entidade tem que depender de entidades que mudam menos)

Referências:

http://www.cleancoders.com
http://c2.com/cgi/wiki

Livros*:

Clean Code (Uncle Bob)
The Clean Coder
Code Complete 2

*Utilizamos os links da Amazon somente para identificar os livros que mencionamos neste post.

Assista à íntegra da palestra de Lucas Húngaro na trilha Ruby do TDC 2011 em São Paulo:

E veja também os slides da apresentação dele:

Curioso para saber como foi? Assista ao vídeo da palestra dele, abaixo:

[18S06] Personal Dilemma: How to work with Ruby in Brazil? (en) from ogi on Vimeo.

Prólogo: Arquitetura e Design

Design pattern em desenvolvimento de software não se refere a algo “standard”. Cita Christopher Alexander, um arquiteto e matemático – autor de “A Pattern Language” – para fundamentar que patterns são só as formas recorrentes mais vistas na forma de construir um prédio, por exemplo, capazes de diminuir sua complexidade, e de identificar e descrever o que você quer construir. E que leva, por sua vez, a livros software como os famosos “Design Patterns” e “Domain-Driven Design“, de Eric Evans. Diz Akita: “Quando falamos em design e arquiteturas de software, não existem estruturas que são fixas, ou leis que figuram como a única forma de se usar isso ou aquilo“. E completa: “temos que tomar extremo cuidado com aquilo que vemos e tomamos como certo, sem refletir melhor a respeito“.
E cita uma premissa de Alexander, para quem “cada padrão – pattern – representa nosso melhor chute AGORA… os padrões ainda são HIPÓTESES… e portanto todos são tentativas, todos livres para evoluir sob o impacto de novas experiências e observações”.

“Quando falamos em construção de software precisamos ter em mente que não se trata simplesmente de uma questão de gosto ou de opinião. É uma questão de estrutura, de otimização, de custo, de formas mais avançadas de se desenvolver e assim por diante“. afirma Akita. E comenta que, hoje em dia, temos o problema do que ele denomina de “popularidade estatística” no desenvolvimento de software. Mas alerta que a popularidade por si só não pode definir a solução. Na visão dele, seria o mesmo que dizer, por exemplo, que se uma multidão afirmar que ’2+2=5′, portanto a afirmação é verdadeira. Só que na matemática, como sabemos, as coisas não funcionam dessa maneira: basta que uma pessoa diga e consiga provar que ’2+2=4′, que esta será a resposta certa. E aí não importa se há 1 milhão de pessoas dizendo que essa resposta está errada pois, se há alguém que prove, demonstre e afirme que essa é a resposta certa, existe uma linha de raciocício concreta que chega a essa resposta.

Em resumo, não é porque 100 mil pessoas afirmam qual a melhor forma de fazer uma determinada coisa, que é como essa mesma coisa deverá ser feita. “Se assim fosse“, diz Akita, “e eu fosse buscar simplesmente por estatística de uso, ou qualquer tipo de estatística em relação a uso de software, vamos pensar por exemplo, qual é o tipo de sistema de software aonde trafega dados que valem muito dinheiro e que portanto deveria ser a tecnologia de escolha de todo mundo aqui neste momento: eu deveria escolher Cobol. Está em todos os bancos, trafega trilhões de dólares sendo processados em Cobol, mas nem por isso eu uso Cobol“.

“Não é bem assim que a gente tem que definir software. E como é que a gente tenta definir arquiteturas, como é que a gente tenta definir soluções de sistemas, soluções de problemas?“, questiona. E, como resposta, cita duas frases célebres de W. Edward Deming: “A experiência por si só não é nada” e também “Em Deus nós acreditamos, todos os outros devem trazer dados”. Mensuráveis, e que podem levar a conclusões objetivas e não simplesmente a estatístcas de popularidade, completa Akita.

Histórico Ruby x Ruby on Rails

Em projetos open-source, normalmente os desenvolvedores lidam com 3 versões de cada tipo de sistema: a estável mais usada, a estável em transição e a versão em desenvolvimento que vai ser a próxima versão estável. E o mundo Ruby on Rails anda bastante rápido: nos últimos 5 anos, já surgiram 34 versões. Ruby on Rails é um framework para desenvolver aplicações web.

Atualmente, o framework Rails – não confundir com a linguagem Ruby, pois são coisas distintas – está na versão estável 2.3.12, que não é a mais recente mas é a mais usada. Já a linguagem Ruby mais usada é a 1.8.7, as duas estáveis mais recentes são 3.0.9 (framework Rails) e 1.9.2 (linguagem Ruby) e em desenvolvimento temos a 1.9.3-dev (linguagem Ruby, que deve sair em Agosto) e 3.1-RC4 (Rails, que está perto de ser a próxima mais estável).

Como funciona a pilha padrão do Rails no lado servidor

O ciclo padrão da maioria dos frameworks web segue a seguinte ordem, explicada detalhadamente no vídeo da palestra (ver abaixo):

Recebe:
Request > Web Server >> Rack Middlewares >>> Routes >>>> Controller >>>>> Model >>>>>> View

Retorna:
View > Controller >> Rack Middlewares >>> Web Server >>>> Response

No nível Web Server: NginX / Apache
No nível Application Server Pack: Unicorn / Passanger

A arquitetura em camadas permite que a sua aplicação cresça: em um primeiro momento você pode não precisar, mas em um segundo momento, poderá acrescentar camadas, como balanceador de carga (HAProxy), você pode trocar por Web Services (REST, SOAP) para se comunicar com outros repositórios de dados, posso adicionar caches (Varnish) em nível Web Server ou no extrato do banco de dados (Memcached), ou seja, é uma arquitetura que pode evoluir de diversas formas.

O problema é quando há requisições concorrentes. A recomendação é fazer com que haja uma diminuição do tempo de processamento de cada requisição. Existem várias formas de se fazer isso – acompanhe a explicação detalhada de Fabio Akita no vídeo da palestra – mas uma maneira de se otimizar o processo é utilizar eventos assíncronos.
Dessa forma, as requisições seriam simultâneas, na ordem dos milhares, e seu processamento passaria pelo modelo representado abaixo:

Request > NginX >> Async App >>> RDBMS

Algumas referências citadas por Fabio Akita de servidor-cliente para arquitetura assíncrona são:
The Web Socket API
EventMachine
NodeJS
Servidor assíncrono:
Pusher
Questões cliente-servidor:
The C10K problem

Lado front-end

Assuntos “polêmicos” comentados: Processamento de Assets. Para quem trabalha com desenvolvimento web, assets é composto por seu CSS, JavaScript e imagens. E como juntar tudo isso sem poluir a aplicação? Para organizar isso em uma arquitetura mais prático, criou-se uma biblioteca chamada “Sprockets”, que funciona basicamente como um filtro, onde as requisições são checadas e gerados arquivos em tempo real no caso de desenvolvimento, ou um arquivo estático no caso de produção.

Epílogo

Akita concluiu a apresentação falando da importância de se criar projetos open-source. Na opinião dele, é preciso otimizar processos para geração de software de maior qualidade no mercado. “A ideia aqui é abrir código para melhorar o design desse código. Testar um software em ambientes reais, conseguir dados que de outra forma não se conseguiria normalmente, e criar novas arquiteturas e alternativas de soluções que me permitam ganhar melhores projetos e, com isso, ganhar de fato mais dinheiro”, resumiu ele.
E também anunciou o RubyConf Brasil 2011, que acontece no ínicio de novembro em São Paulo.

Assista à íntegra da palestra de Fabio Akita na trilha Ruby do TDC 2011:

Akita será o primeiro sul-americano convidado a se apresentar no evento – com exceção da Antártica – e está bastante empolgado com o convite, conforme relata em seu blog pessoal.

Veja fotos das duas últimas edições do RubyKaigi em:

http://www.flickr.com/photos/kakutani/3745179235/in/set-72157621775178508
http://www.flickr.com/photos/kakutani/5010963014/in/set-72157624877140969

Visite também a página oficial do evento:
http://rubykaigi.org/2011/en

Apresentamos aqui os slides das palestras de Fabio Akita, para que você possa compatilhar referências interessantes para estudo e também clarear as ideias para novos rumos na área, que é justamente o que ele incentiva e desafia suas equipes a fazer diariamente aqui na Gonow:

Para fechar os cinco princípios do SOLID, vamos falar sobre os dois princípios restantes: Liskov Substitution Principle (LSP) e Interface Segregation Principle (ISP).

Como já foi falado anteriormente, esses princípios foram formulados com linguagens estáticas em mente e, por essa razão, precisam ser “adaptados” para que sejam aplicados em linguagens dinâmicas. Note que, em suas formas originais, esses princípios em geral recorrem a técnicas como herança para contornar as “amarras” do sistema estático de tipos.

No caso do LSP temos mais um exemplo disso. Em sua forma original ele é definido da seguinte forma:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

O que foi “traduzido” para o OOP da seguinte forma:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Em Ruby isso não é muito problemático pois, como sabemos, não estamos presos à tipos. O importante, como já vimos com o OCP, é manter a mesma interface, de forma que se precisarmos modificar alguma entidade, as demais entidades que dela dependem não precisem ser modificadas.

Além da interface, também precisamos prestar atenção ao comportamento. Modificações no comportamento podem fazer com que clientes da entidade sofram consequências inesperadas.

Já o ISP é definido da seguinte forma:

Clients should not be forced to depend upon interfaces that they do not use.

Isso quer dizer que um cliente (entidade que depende de alguma outra) não deve depender de interfaces não utilizadas por ele pois, em caso de modificação nessa interface, mesmo que o cliente em questão não a utilize, também terá que ser modificado.

Em linguagens estáticas há uma série de técnicas e artifícios para atingir isso. Em Ruby, o Duck Typing nos entrega esse princípio “de graça”, já que cada entidade depende apenas da interface que utiliza, independente do restante (e de tipos). Apesar disso, devemos sempre buscar entidades com interfaces coesas e bem delimitadas, evitando que sejam muito extensas e genéricas (o SRP se aplica aqui também). Aplicar o design pattern Adapter é uma boa forma de respeitar isso.

Bem, é fácil perceber que os últimos três princípios discutidos (OCP, LSP e ISP) lidam diretamente com formas de garantir interfaces estáveis para atingirmos o nosso objetivo de evitar que mudanças no código gerem um “efeito dominó” e façam com que tenhamos que alterar várias partes do software.

Mas, já que não temos estruturas como Interfaces e classes abstratas para garantir que estamos respeitando a interface definida, como garantir a aplicação desses princípios? Bom, há algumas formas para fazer isso. Aprenda a “emular” uma interface e pesquisar outros materiais recomendados em:

http://blog.lucashungaro.com/2011/05/18/solid-ruby-liskov-substitution-principle-e-interface-segregation-principle/

Continuando os artigos sobre SOLID, vamos falar um pouco sobre o Dependency Inversion Principle. Em resumo, esse princípio diz que os componentes devem depender de abstrações ao invés de implementações.

Bom, isso faz muito sentido em linguagens estáticas como Java, onde há estruturas como Interfaces, classes abstratas e outras parafernalhas. No final, na minha modesta opinião, o código torna-se um espetáculo bizarro de indireção e pode mais confundir do que ajudar se você não for cuidadoso. Mas e nas linguagens dinâmicas?

É comum ouvir que, quando você utiliza uma linguagem que contém Duck Typing (a característica que mais gosto no Ruby), você obtém os benefícios do DIP “de graça”. Isso não é bem verdade. Você os obtém de graça somente se pedir com jeitinho.

O que quero dizer com isso?

Acesse a post original com as explicações das telas e também uma leitura adicional para clarear ainda mais esta explanação:
http://blog.lucashungaro.com/2011/05/09/solid-ruby-dependency-inversion-principle/

Por Lucas Húngaro*

Muitos dos princípios da programação orientada a objetos foram criados com linguagens estáticas em mente. Esse é o caso do Open-Closed Principle, enunciado da seguinte maneira:

“Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification.”

Originalmente, a ideia é que, uma vez finalizada, uma entidade só poderia ser modificada para correções. Qualquer nova “feature” deveria ser implementada em uma nova entidade, que aproveitaria o código da primeira principalmente através de herança. Isso resulta em reaproveitamento da implementação, mas não garante a consistência da interface.

Um pouco depois, com a introdução e popularização de classes abstratas e recursos de linguagem como Interfaces, o princípio evoluiu e passou a ser aplicado em conjunto com o DIP, fazendo com que o código sempre dependesse de interfaces ao invés de implementações. Com isso, era possível reaproveitar uma interface (closed) e modificar a implementação (open).

Mas e nas linguagens como Ruby, em que abrir uma classe é tão simples como defini-la e pode ser feito a qualquer momento? Será que esse princípio se aplica? Isso sempre é tema de muita discussão e aqui vai minha visão sobre isso.

Bem, com Ruby temos algumas formas de modificar uma classe, como herança, mixins, reabrir a classe ou usar metaprogramação. Perceba que, exceto pela herança, as outras maneiras infringem a ideia original do princípio. Mas, como já vimos, o próprio princípio evoluiu para abraçar mudanças nas linguagens e paradigmas.

O importante, principalmente em linguagens com Duck Typing (que, como já vimos, não dão a mínima para tipos), é que a interface seja fechada. Não importa o modo que você escolher para fazer as modificações, desde que a “superfície de contato” entre as entidades permaneça estável.

No exemplo do post anterior poderíamos modificar as classes que passamos como dependências via parâmetro e utilizá-las sem problemas, desde que a interface permanecesse a mesma. Uma vantagem adicional da tipagem dinâmica é que nesse caso podemos utilizar também herança (modificando o “tipo”) sem precisar modificar o código cliente, que só se importa com a interface.

Dessa forma, podemos modificar um pouco o enunciado do OCP para adaptá-lo à nossa linguagem preferida:

“Software entities (classes, modules, functions, etc) should be open for extension, but closed for interface modification.”

Recomendo esse vídeo-podcast sobre o assunto: Monkeypatching and the Open-Closed Principle.

*Acesse o post anterior sobre Single Responsability Principle no blog pessoal de Lucas Húngaro.

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

O objetivo desses princípios é fazer com que alterações necessárias sejam feitas no menor número possível de locais no código. Em outras palavras, é diminuir o custo dessas mudanças através de um design que reduz os efeitos colaterais das modificações.
Cada um desses conceitos merece uma investigação mais detalhada. Conheça então um pouco mais sobre a aplicação do Single Responsibility Principle em Ruby acessando o post de Lucas em seu blog pessoal e bons estudos! 

E fique despreocupado pois o tutorial de como fazer uma aplicação Rails termina logo na parte 2. Mas para você que é ou não especialista em Ruby on Rails, Serradura fornece uma série de dicas e links úteis onde colher informações para se aprofundar no tema.

Quer aprender a fazer? Então acesse o blog e veja os detalhes!
Lembrando que esse é o post número 2 de uma série, então fique ligado no blog Gonow!

E quem resolveu dar esse pontapé inicial foi Rodrigo Serradura, nosso desenvolvedor Ruby, que tem se debruçado na criação de uma aplicação para Facebook do zero com Rails 3. Será uma série de 7 posts, ensinando passo a passo como matar essa charada. O aplicativo que ele propõe é bastante simples e mostrará quantos amigos do sexo masculino e feminino um usuário possui e com quais dos gêneros ele mais interage.

Quer aprender a fazer? Então acesse o blog e veja os detalhes!
Lembrando que esse é o post número 1 de uma série, portanto em breve divulgaremos a segunda parte, fique ligado no blog Gonow!

O projeto é bem ousado e visa criar uma nova linguagem para aproximar mercado de valores e pessoas físicas sem conhecimentos avançados em finanças. “Será um portal e uma plataforma que permitirá realizar operações na Bolsa com facilidade, numa interface intuitiva e convidativa. E a plataforma Rails será muito importante para garantir produtividade, dinamismo, e integração com vários back-ends tradicionais voltados à Bolsa de Valores”, explica Fabio Akita, coordenador do projeto e um dos principais expoentes da linguagem Ruby no Brasil. Esse é um dos maiores projetos com a plataforma, e em breve divulgaremos como vai ficar a solução – e a satisfação – para o cliente.