Posts Tagged ‘Arquitetura’

Mais 10 livros recomendados para desenvolvedores

Monday, March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

[Encontro de TI] Eu fui!

Sunday, March 29th, 2009

Ontem tive o prazer de fazer mais uma apresentação no 2o. Encontro de TI organizado pela Arteccom.

Dessa vez eu falei sobre desenvolvimento para web com agilidade. Nos dias de hoje nós desenvolvedores temos ao nosso alcance uma infinidade de ferramentas para desenvolver software com mais qualidade e agilidade, e o meu objetivo foi apresentar rapidamente algumas das opções mais usadas no mercado falando de suas vantages e desvantagens. Falei também um pouco sobre arquitetura de software usando o velho mito do “Rails não escala” como cenário. No final ainda deu tempo de falar sobre alguns dos princípios e mentalidades que eu acredito que qualquer desenvolvedor precisa ter para ser mais produtivo. O tempo foi pouco pra tanto assunto mas no final acabei conseguindo. Espero que quem assistiu tenha gostado! :)

O mais legal foi que a palestra do Fabio Akita – que foi logo depois da minha – encaixou perfeitamente no assunto e deu um belo arremate nessa mesma linha, falando sobre desenvolvimento com agilidade usando Ruby on Rails. Se nós tivessemos combinado não teria sido tão acertado! Outras figurinhas carimbadas também estavam presentes no evento como o Paulo SIlveira da Caelum e o Paulino Michelazzo da Fábrica Livre.

No fim do dia rolou um painel de discussões bem legal com alguns dos palestrantes e quem não teve tempo de fazer perguntas nas apresentações teve chance de participar. Poderia ter sido só um pouquinho mais longo mas mesmo assim valeu.

ETI2: Painel de discussões
* Painel de discussões no encerramento do evento. Foto de Patricia Haddad.

Mesmo já tendo palestrado em eventos anteriores organizados pela Arteccom ainda fico intrigado pelo empenho e organização de todos da equipe. O evento estava muito legal! Mesmo sendo “novatos” neste segmento de TI já estão batendo um bolão. Só falta agora eles aprenderem a escrever o meu nome direito! :)

Sei que algumas pessoas já pediram mas por enquanto não vou disponibilizar os slides para não fazer spoiler, afinal, o Rio de Janeiro foi apenas a primeira etapa do evento. Nos próximos meses estaremos em São Paulo, Florianópolis, Curitiba, Porto Alegre, Brasília, Belo Horizonte, Salvador e Recife.

Nos vemos lá!

Falando em Java 2008, aí vou eu!

Monday, May 12th, 2008

Falando em Java 2008Na próxima semana estarei em São Paulo para o Falando em Java 2008, um ótimo evento realizado anualmente pelos amigos da Caelum, a melhor empresa de treinamentos em desenvolvimento de software do Brasil na atualidade.

Esse ano haverá a ilustre presença do Emmanuel Bernard (um dos líderes do projeto Hibernate na JBoss) que fará duas apresentações, uma sobre JPA 2.0 e outra sobre Hibernate Search. Por uma grande ironia do destino, a palestra de Hibernate Search foi uma das que eu não consegui assistir na JBoss World 2008 e agora vou ter minha segunda chance! Além disso esse ano não se falará só em Java mas também em arquitetura de software, Domain-Driven Design, JRuby on Rails, Scrum e AJAX.

Nos vemos por lá! :)

10 livros recomendados para desenvolvedores

Thursday, March 27th, 2008

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos :)

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!

A falácia da otimização prematura

Tuesday, January 8th, 2008

“A otimização prematura é a raiz de todo o mal”. Quantas vezes você já ouviu essa frase? Eu mesmo já disse isso aqui nesse mesmo blog e já falei essa frase para várias outras pessoas. O problema, como já apontavam os sábios budistas, é que as pessoas acabam levando as coisas ao extremo… Para alguns desenvolvedores, como a otimização é a raiz de todo o mal ela deve ser evitada a qualquer custo e ao longo dos anos o sentido da frase acabou virando simplesmente “nunca otimize seu código”.

O criador dessa frase famosa foi Tony Hoare e Donald Knuth foi o responsável por torná-la popular. O que as pessoas não param para pensar é que quando essa frase foi dita, em 1975, o contexto era completamente diferente. O que Hoare e Knuth estavam realmente falando é que os engenheiros de software da época deveriam se preocupar com outras coisas mais importantes (como um bom design de algorítmos e boas implementações desses algorítmos) antes de se preocupar com micro-otimizações como a quantidade de ciclos de CPU que um determinado comando consome. A história toda é bem interessante e recomendo a leitura completa.

Hoje em dia os tipos de software que desenvolvemos são completamente diferentes. A capacidade computacional das máquinas é diferente, as arquiteturas dos sistemas, a quantidade de usuários… Temos bancos inteiros totalmente computadorizados com milhões de transações simultâneas acontecendo e essas trasações não podem falhar ou alguém perde dinheiro em algum lugar. Temos sistemas na internet que suportam milhões de usuários trocando mensagens o tempo todo. Enfim, precisamos considerar aspectos bem diferentes.

Eoin Woods, membro da IASA, publicou um artigo sobre o que ele acredita que sejam os 10 maiores erros de arquitetura cometidos em projetos. O item número 7 é “Assumir requisitos de performance e escalabilidade”. Ele acredita que você deve começar a considerar aspectos de performance e escalabilidade desde cedo porque isso ajudará a aumentar a sua confiança de que não há nenhum bicho de sete cabeças que na última hora vai arruinar qualquer possibilidade da sua aplicação ir para produção. Os requisitos de performance de uma aplicação devem ser conhecidos, estudados e levados em consideração desde o início do desenvolvimento.

Robert Annet do Coding The Architecture cita um outro exemplo do que pode acontecer quando você assume certas informações erradas no desenvolvimento. Ele também conclui que todos os desenvolvedores devem sempre estar cientes da arquitetura de um sistema e como isso afeta o que está sendo desenvolvido. Faz muita diferença, por exempo, se uma aplicação rodará em cluster ou não.

Resumindo, eu discordo de quem diga que um software não deve ser otimizado antes mesmo de ser desenvolvido. Há casos e casos. Veja a minha situação: quando eu desenvolvo sistemas na Globo.com, como é que eu posso ignorar o fato de que o sistema será acessado por milhões de usuários? No nosso último projeto, por exemplo, uma das premissas era que o player de vídeos fosse ultra-compacto (menor quantidade de bytes possível) já que ele seria baixado por qualquer usuário que fosse ver o vídeo e não poderia afetar o carregamento da página. Se não fosse isso poderíamos acabar tendo um daqueles arquivos Flash de 2 MB que quando você acessa a página tem que esperar 2 minutos para carregar – a experiência do usuário fica um lixo.

Porém também acho que temos que tomar cuidado para não exagerar na dose. Otimizações são boas quando elas são realmente necessárias.

Já cansei de ver desenvolvedores sacrificarem o design de uma aplicação por causa de performance ou otimizações que eram completamente desnecessárias. Quando você tem requisitos de performance claros como os que eu citei acima é óbvio que você tem que levá-los em consideração. Mas a grande maioria das aplicações certamente não atende milhões de usuários nem se você somar 10 anos de acesso! Então o que acaba acontecendo é que ao invés de se preocupar com desenvolver software de qualidade, bem testado, modular e com design decente muita gente acaba desenvolvendo software desnecessariamente otimizado e difícil de entender e modificar. A não ser que você tenha requisitos não-funcionais bem claros e definidos a prioridade sempre deve ser por um bom design, código legível, extensível e esse tipo de coisa.

Otimizar cedo ou não, sempre vai ser um assunto controverso. Normalmente esse tipo de coisa envolve julgar uma série de fatores técnicos e de negócio. Concluindo, é essencial que a equipe de desenvolvimento tenha bom senso ao tomar essas decisões. Nunca otimizar ou sempre otimizar são abordagens completamente equivocadas. Como dizem os budistas, “prefira sempre o caminho do meio”.

[QCon 2007] Randy Shoup: The eBay Architecture

Friday, November 9th, 2007

QCon 2007 - Randy ShoupO Randy Shoup apresentou várias coisas impressionantes sobre o eBay. E quando eu digo impressionantes eu estou falando sério! Eu não fazia idéia do quão grande era o eBay e provavelmente ninguém que está lendo este texto faz. Então, eis alguns números para ajudar a entender melhor do que estamos falando:

  • 248 milhões de usuários registrados.
  • 1 bilhão de fotos.
  • $1812 dólares por segundo em transasções realizadas.
  • 100.000 linhas de código novas a cada duas semanas.
  • 44 bilhões de transações de banco de dados por dia.
  • 2 PetaBytes de dados.
  • 1.5 TeraBytes de logs por dia.

Enfim, é MUITA, muita coisa.

Para dar conta de toda essa infraestrutura monstruosamente grande a estratégia é até bem simples:

  • Particionar. Como você faz para comer um elefante? Simples: em pequenas mordidas de cada vez. As aplicações do eBay são divididas em 16.000 servidores de aplicação que utilizam mais de 1.000 instâncias de banco de dados em mais de 400 hosts.
  • Processamento assíncrono. Faça o máximo de processamento assíncrono possível, isso irá liberar a sua infraestrutura para atender as operações que necessariamente precisam ser resolvidas na hora.
  • Automação. Não perca tempo fazendo coisas que podem ser automáticas. Faça com que as rotinas de gerenciamento da infra sejam executadas automaticamente desde o momento que forem criadas. Automatize tudo que puder!
  • Lembre-se que tudo falha. Faça com que as falhas sejam detectadas automaticamente e quando uma falha for detectada faça alguma coisa sobre isso (automaticamente, claro). Tenha sempre um plano de recuperação de desastre e backup.

[QCon 2007] Ian Flint: Yahoo! Communities Architecture

Friday, November 9th, 2007

A palestra do Ian Flint sobre a arquitetura do Yahoo! foi bem interessante. É bem legal saber como esses caras grandes funcionam e fiquei bem surpreso com algumas coisas.

Qcon 2007 - Ian FlintA principal delas foi saber que eles usam Hibernate para persistência em aplicações Java. O mais impressionante é que essa aplicação tem em torno de 50.000 transações de banco de dados por segundo! Isso pra mim derruba totalmente aqueles mitos de que Hibernate não escala, que não é flexível e não funciona para softwares “grandes” e “sérios”. Se isso não é grande eu não sei mais o que é! Além disso eles usam um set de frameworks bem comum: Spring, C3P0, Log4J, etc.

Outra coisa interessante é que a grande maioria das aplicações deles é em PHP. Ele não disse o percentual ou a quantidade mas enfatizou bastante o fato de ser a maioria das aplicações então deve ser bastante coisa. Em segundo lugar eles usam mais Python e só depois vem o Java. Eles também têm várias aplicações de back-end e componentes em C e C++.

Em relação a banco de dados, eles usam na maioria das aplicações MySQL e em segundo lugar Oracle RAC. Inclusive o Ian disse que foi a primeira vez em toda sua carreira que ele viu esse Oracle RAC funcionar… Pelo visto ele já teve algumas experiências traumáticas…

Para finalizar, tenho percebido que assim como todo o resto das empresas que estão aqui (eBay, LinkedIn, Oracle, etc) eles simplesmente não inventam arquiteturas complexas como às vezes imaginamos. O segredo é uma arquitetura o mais simples possível!

Download

[QCon 2007] Eric Evans: Strategic Design

Friday, November 9th, 2007

O Eric Evans, autor do livro Domain-Driven Design, fez mais uma excelente apresentação entitulada “Strategic Design“. Dessa vez a apresentação foi sobre como implementar técnicas de Domain-Driven Design em projetos de software.

Qcon 2007 - Eric EvansSegundo o Eric, por conta do tamanho das equipes de software é impossível ter somente programadores excelentes. Isso faz com que nem todas as partes do um sistema sejam bem desenhadas, isso é fato. No entanto você pode fazer com que algumas partes do sistema sejam bem desenhadas e é essecial que isso seja feito no domínio da aplicação, que é o local onde está a complexidade crítica da maioria dos sistemas.

Uma coisa importante que ele frisou é que não pode existir um domínio corporativo usado por todas as aplicações (tipo “one ring to rule them all”), porque é impossível criar um domínio que atenda a todos os softwares. Cada aplicação deve ter o seu próprio domínio que deverá ser cuidadosamente projetado, dento de um contexto, para resolver os problemas que a alicação se propõe.

Algumas estratégias para implementar um bom domínio são:

  • Desenhe um mapa do contexto e sempre siga-o. Isso vai te ajudar a saber quais conceitos devem ser mapeados no seu domínio ou não e te impedir de perder o foco do sistema.
  • Trabalhe com os líderes do negócio para definir o domínio do sistema. E continue sempre trabalhando em conjunto com eles enquanto o domínio se especializa e evolui.
  • Crie uma plataforma que suporte trabalhar e evoluir o domínio. E mantenha esta plataforma protegendo o domínio.
  • Trabalhe com a gerência para ter liberdade de criação no contexto do domínio.
  • Desenvolva e modele o domínio. O domínio sempre evoluirá e será destilado ao longo da vida do software.

E como em toda a apresentação do Eric têm que acontecer alguma coisa estranha, tivemos um falso alarme de incêncio bem no meio da apresentação! O pessoal tomou um baita susto porque começou a tocar o alarme muito alto e a piscar um monte de luzes e todos tiveram que sair do hotel. No fim das contas era um alarme falso. Nunca mais jogo fumaça naqueles detectores!!! (hahahaha, isso obviamente é sacanagem, eu jamais faria isso… – eu teria acendido um isqueiro no detector de fogo e todos ficariam molhados, que é bem mais legal!)

Download

[QCon 2007] Cameron Purdy: The Top 10 Ways to Botch Enterprise Java Application Scalability and Reliability

Thursday, November 8th, 2007

QCon 2007 - Cameron Purdy: The Top 10 Ways to Botch Enterprise Java Application Scalability and ReliabilityCameron Purdy fez uma apresentação sobre as 10 melhores maneiras de estragar (isso mesmo) a arquitetura das suas aplicações Java! Foi surpreendente porque eu fui pra essa apresentação sem expectativa nenhuma mas ela foi ótima e muito engraçada!

A apresentação foi num estilo meio cômico e a cada slide várias pessoas foram se identificando com várias decisões de arquitetura patéticas que a gente vê por aí (eu inclusive já fiz e ví várias delas!).

Algum dos exemplos que ele deu que podem acabar com a escalabilidade e a confiabilidade de uma aplicação foram:

  • Estuprar o banco de dados: utilizar os recursos de banco para fazer coisas sem tanta importância como logar operações, guardar estado (session) ou guardar imagens.
  • Introduzir gargalos: qualquer coisa que milhares de requests têm que utilizar e que têm latência associada a carga.
  • Usar heaps gigantes na JVM: um FullGC de 10GB pode levar 3 segundos em laboratório mas em produção isso pode levar vários minutos travando completamente a aplicação.

E por aí vai…. Veja a apresentação completa (os slides estão bem legais por sinal).

Download