Monday, September 8, 2008

Here comes another bubble!

Não muito novo, mas muito bom!



Baseado na música We didn't start the fire do Billy Joel.

Escalabilidade e Consumo de Energia

Hoje mesmo o Software Engineering Radio, disponibilizou mais um episódio. O assunto do dia foi eBay's Architecture Principles com Randy Shoup, arquiteto do eBay. Logo no começo do episódio, Randy mencionou os principais desafios enfrentados pelos arquitetos do eBay. Um deles foi o seguinte:

Power consumption - everybody who runs large data center knows this - but simply power and cooling the hardware is actually the biggest limiting factor for the growth of our hardware. So it's not physical space, it's not being able to buy the machines. It's simply beign able to power the machines and to cool the machines. And what we are finding - we, but also google, yahoo, amazon, etc - is that the size of an individual data center is now exceding what a residential power grid in most of the USA can power. So, now you have to start thinking about more and more and more smaller data centers and architecting around that, so that's actually one of the main challenges (Randy Shoup, transcrito por mim)

Ironicamente quando se pensa em escalabilidade, muitos não levam a energia consumida em consideração - eu mesmo não imaginava que esse era um dos grandes problemas. Mas, veja o Google por exemplo. Dinheiro não é problema. Recentemente lançaram o seu primeiro satélite para capturar imagens, gastam bilhões e bilhões na compara de serviços na internet. Mas imagina processar todo dia milhões e milhões de buscas no google search, percorrer e indexar milhões e milhões de páginas, fornecer milhões de vídeos, fotos, rss, alertas, notícias, anúncios, e-mails, blogs, recados, mapas, etc. É um número de processamento inimaginável! E isso tudo gasta energia para processar e manter os servidores frios - ou eles simplesmente iriam derreter!



Mas como sempre o Google tinha que surpreender e inovar! Ontem li uma notícia que o Google entrou com um pedido de patente, para construír data-centers na água. Isso! O Google argumenta que data-centers localizados em navios podem utilizar a energia natural do movimento da água para gerar energia de processamento e/ou canalizar o calor gerado pelo processamento! Como é o Google, eu espero ver isso em funcionamento em um futuro não muito distante. Isso sim que é computação verde.

Friday, September 5, 2008

Killer Filesystem

Estava fazendo a minha leitura diária dos meus feeds hoje me deparei com um tópico no Slashdot:

Best Shrinkable ReiserFS Replacement?


Para os não-nerds, Slashdot é o melhor site de notícias e discussão sobre ciência e tecnologia da internet. Cada notícia possui uma seção de comentários dos usuários que muitas vezes supera a própria notícia, com tiradas engraçadas, informações úteis e discussões interessantes. Algumas "celebridades" do mundo geek são conhecidos por frequentar e interagir no site.

Para os nerds desatualizados, ReiserFS (o mesmo da notícia acima) é um sistema de arquivos bastante conhecido dos usuários Linux. Recentemente, seu criador - Hans Reiser - foi condenado pelo assassinato de sua esposa.

O video do momento de sua condenação já está no Youtube. No video o Hans parece bem abalado e pede desculpas pelo crime (a pedido do advogado).

Voltando para o tópico no Slashdot. Para falar a verdade, esse sistema de arquivo nem é um assunto que me interessa, mas eu tive que ir ver os comentários dos usuários, pois tinha certeza que ia ter muita coisa "boa". Basicamente o criador do tópico queria saber qual seria um bom substituto para o sistema de arquivos ReiserFS. Abri, e está lá a primeira resposta da notícia:

The O. J. Simpson filesystem!


HAHAHA! Funny-5.. seguindo pro segundo:

It'll be hard to find a new killer filesystem, you insensitive clod!


E continuaram assim... só foram ajudar o usuário com problema no quinto comentário! Mas depois as piadinhas continuaram. Não vou colocar todas aqui, apenas a campeã:

No, no, no.

Login: reiser
Password:

$ touch wife
touch: access denied
$ sudo touch wife
password:
touch: access denied
$ echo "wtf?"
wtf?
$ ps -aux | grep wife
wife 14589
$ sudo kill -9 14589
mv body /dev/hills/body

Some time later:
Login: cops
Password:

$ locate body
body not found
$ sudo usermod -g felon reiser
$ sudo updatedb
$ locate body /dev/hills/body


FODA! A criatividade desses nerds me surpreende!

P.S.: O próprio Hans era usuário do Slashdot! Quem quiser ver seus posts no site, vai nesse link.

Saturday, August 30, 2008

Mozilla Ubiquity e a Web Semântica

Um projeto muito interessante que ainda está em versão alfa é o Ubiquity do Mozilla Labs. Ele permite que você utilize/manipule informações disponíveis no site que está sendo exibido no seu Browser de forma rápida e fácil, através de uma linguagem simples - similar à um shell - e extensível. Explicando assim não da para entender muito bem do que se trata. Melhor ver o video oficial abaixo:


Ubiquity for Firefox from Aza Raskin on Vimeo.

O que mais me chamou a atenção no video de demonstração é a necessidade de uma web mais semântica. Em pelo menos dois exemplos do video, fica claro que a ferramenta fez uso de alguma API específica (Google Maps) ou de Web Scraping para encontrar a informação necessária. O próprio autor fala: "Atualmente essa funcionalidade só está disponível para o Craiglist...". É preciso chegar à uma padrnização do formato de dados de certos domínios e da forma como esses dados são entregues. Mais fácil será a vida do desenvolvedor e do proprio usuário.

Assim, o usuário que acessa o IMDB poderá solicitar ao Ubiquity: "verifique os horários desse filme na minha cidade e adicione no meu Google Calendar". Mas da mesma forma ele poderá acessar o Rotten Tomatoes e adicionar a sessão de cinema no RememberTheMilk.

Outros serviços como o FriendFeed - excelente por sinal - também expoem esse problema. O FriendFeed centraliza os dados de diversos serviços que você utiliza na web, mas o número de serviços ainda é restrito porque é preciso uma implementação diferente para se comunicar com cada um deles.

Apesar da aparente necessidade de uma web semântica, a idéia já foi alvo de algumas críticas e muitos acham que ela nunca vai vingar.
The Semantic Web will never work because it depends on businesses working together, on them cooperating. (Stephen Downes em Why the Semantic Web Will Fail)

Então agora eu te digo Why Stephen Downes Failed! Quando a tecnologia vem a favor das grandes coorporações, é claro que elas irão trabalhar juntos. Veja, por exemplo, o projeto DataPortability. Olha só quem está apoiando o projeto: Google, Facebook, Plaxo, Drupal, Netvibes, Mystrands, LinkedIn, Flickr, Six Apart, Twitter, Digg e Microsoft. Tá bom ou quer mais? Veja o sucesso do OpenSocial, o apoio do Yahoo, Adobe, etc etc. A propria específicação HTML 5 está incluindo mais semântica na sua linguagem com marcações como section, article, dialog, audio, time...

Um dia será como disse Tim Berners-Lee:
"Por favor agente, marque uma consulta com um oftalmologista, o mais perto da minha casa e que se adeque à minha agenda! Obrigado!"
Feito!

Friday, August 29, 2008

Fenômeno Youtube

A compra do YouTube pela Google parece estar dando o retorno esperado por eles. Olha os dados fornecidos pela Forbes:

  • Atualmente o Youtube possui metade do tráfego do Google, mas cresce muito mais rápido.
  • Um anuncio na página inicial do Youtube custa $175,000 por dia, mais o comprometimento de gastar mais $50,000 em anúncios;
  • Canais customizados vendidos para anunciantes como Nestlè, 3M, Hewlett-Packard, entre outros custa $200,000 cada.
  • Sem contar os outros anúncios que aparecem antes dos videos principais, banners embaixo de certos videos, e o AdSense.
Via Forbes e Google Blogoscoped

Monday, August 25, 2008

Pressão sobre o desenvolvedor


E a pressão é toda no desenvolvedor...

Fonte: Stumbleupon

Sunday, August 24, 2008

Manutenção e Documentação

Manter código de um sistema de grande/médio porte é uma arte complexa. Principalmente se você está trabalhando com um sistema desconhecido ou legado. Vários estudos já indicaram que o custo da manutenção é o maior em todo ciclo de vida do desenvolvimento de software. E na maior parte do tempo de uma atividade de manutenção estamos tentando entender o sistema.

Se olharmos para a história da engenharia de software podemos ver que grande parte de sua evolução tem como objetivo reduzir o esforço da compreensão de um sistema:
  • Criação de novos paradigmas de desenvolvimento - o surgimento da Orientação à Objetos, fornecendo ferramentas para encapsular melhor os conceitos do sistema. O AOP que busca isolar aspectos secundários, mas necessários no desenvolvimento do software. Desenvolvimento visual (embora bastante criticados pelos hardcoders), uso de DSL, engines de regras...

  • Ferramentas fornecidas pela IDE - as grandes IDEs fornecem ferramentas interessantes que são usadas comumente na compreensão de sistemas: busca utlilizando expressão regular, o outline de classes, recuperar dependências de classes e métodos, highlight de uso de váriaveis (atualmente com distinção entre leitura e escrita), visualização de hierarquia, etc e etc.

  • Documentação - linguagens de modelagem como UML, documentação de código (como o JavaDoc), utilização de wikis, etc.

  • Ferramentas de análise estática e dinâmica - apesar de ainda não se observar um uso comum desse tipo de ferramenta - sem contar com o debugging e ferramentas como FireBug e o PMD - a academia investe pesado nessa área, que vem evoluindo bastante. A aplicação é diversificada: análise de impacto, análise de dependência, recuperação de arquitetura, visualização de software, mineração de repositórios de software, detecção de clones, detecção de padrões de projeto, slicing, dentre muitas outras. A ferramenta Rational Software Architect da IBM disponibiliza uma opção de identificação de arquitura bastante interessante.

  • Outros - técnicas de teste, rastreabilidade, utilização de APIs, boas práticas, etc.
De acordo com Andy e Dave, toda programação é manutenção. Apenas nos 10 primeiros minutos trabalhamos criando código original.

Mantendo o sistema dos outros

Se manter o seu prórpio sistema pode te deixar maluco com aqueles bugs escondidos, imagina manter software "dos outros". Isso pode acontecer com troca de equipe, contratação de novos desenvolvedores, compra de software e fusão de empresas, entre outras situações que não consegui pensar agora. Uma empresa grande como a Microsoft investe em pesquisa para acomodar melhor os recém-contratados.

Eu participei de uma experiência nesse contexto recentemente. Uma grande empresa brasileira, que possui sua própria TI, terceriza grande parte do desenvolvimento de seus sistemas. São muitos sistemas que geralmente implementam regras de négocio bastante complexas. Um certo dia de sol, a TI da empresa percebeu que deveria ter um controle maior sobre esses sistemas, e queria conhecer de perto a arquitetura e implementação deles. E agora? O que fazer?

A decisão dessa empresa foi a seguinte: olhou a vasta gama de documentação que a UML especifica e exigiu que fosse entregue grande parte dela. Ou seja: casos de uso, diagramas de classe, sequência, componentes, arquitetura, implantação, e por aí vai. Acredito que não tenham nem parado para pensar o que seria interessante ou útil para eles. Mas quem iria gerar essa documentação? Os desenvolvedores não podem parar de dar manutenção no sistema. Logo, foi contratado uma outra equipe especialmente para essa tarefa. Mas essa equipe nova tampouco conhecia o sistema, muito menos as regras de negócio envolvidas. Imaginem quanto dinheiro e tempo não foi investido para gerar essa documentação. Será que essa documentação tem o valor esperado? Em quanto tempo essa documentação ficara defasada?

Posso dizer que a qualidade do código desenvolvido era excelente. Será que não era mais fácil e mais barato olhar diretamente para o código? Pode ser que sim e pode ser que não. Com certeza olhar um diagrama pode ser melhor do que ter que navegar - redundantemente - através de 30 classes diferentes (ou mais, bem mais). Mas também é inviável manter diagramas e especificações de cada aspecto implementado no sistema. E esse foi o erro dessa empresa, querer tudo, sem pensar no valor agregado. Por outro lado, muita gente acha que não precisa de nada. Documentação zero. Muitos acham que ser ágil é isso - "Não preciso de documentação porque sou o melhor programador". Creio que seja uma boa prática manter uma documentação mínima de algumas facetas do sistema. Um meio termo entre tudo e nada:

1) Visão geral do sistema

A visão geral do sistema consiste de um documento de arquitetura. Devem ser especificadas as tecnologias utilizadas, protocolos, comunicação entre nós, distribuição dos componentes na rede, camadas lógicas e políticas de segurança.

2) Visão lógica do negócio

Identificar pacotes lógicos do sistema, agrupando as entidades chaves do negócio. Deve-se apresentar a relação existente entre essas entidades e as responsabilidades à elas atribuidas. Não precisa ser uma foto detalhada de como está implementado o sistema. Essa visão pode ajudar o desenvolvedor à localizar os conceitos no sistema na hora de reparar problemas.

3) Visão estrutural e boas práticas

Frequentemente os desenvolvedores criam uma estrutura comum no sistema que é replicada ao se implementar novas funcionalidades. Por exemplo:
  • estruturas da GUI que devem ser respeitadas, como incluir as janelas abertas em um contexto de execução, tipos de diálogos, lançamento de eventos, e etc;
  • estrutura de serviços do sistema. Implementação de uma superclasse comum de serviços, criação de proxies e inclusão em um esquema de service locator;
  • classes utilitárias. Ex.: classes responsáveis por encapsular tarefas demoradas ou que se comunicam com uma rede interna;
  • esquema de segurança, validação, etc.
Todas essas estruturas devem ser identificadas e muito bem documentadas. Esse tipo de documentação pode ser muito útil quando é preciso incluir novas funcionalidades no sistema.

4) Outros

Outros documentos podem ser necessários, como manual do usuário, guia de implantação, uma visão de processo e concorrência, e por aí vai.

Notem que esses documentos representam visões de alto nível que não tendem a mudar com frequência. Apesar disso podem ser mais bem aproveitadas do que toda a documentação RUP para cada caso de uso de seu sistema. Acredito ser essencial esse tipo de documentação mínima para todo sistema. Para o desenvolvedor expert e já acostumado com o sistema, um Eclipse da vida pode bastar, mas pense sempre que você irá programar para os outros, afinal, as coisas podem mudar e outra pessoa terá que manter aquilo que só você entendia. Recentemente testemunhei algo semelhante e foi uma GRANDE dor de cabeça. Nos próximos posts eu falo disso.