Blog do Eduardo Costa Meu blog pessoal

23Ago/113

Raciocínio de um físico

Enviada pelo meu amigo Nelson, papo real via Skype:

[14:47:23] Fisico 1: quanto tempo para 380 mls de agua atingirem 90ºC partindo de 22 no meu microondas da eletrolux?
[14:47:28] Fisico 1: vc que é físico
[14:47:42] Fisico 1: kkkkk
[14:47:43] Fisico 2: depende se é um copo alto ou uma tigela
[14:48:07] Fisico 1: caneca do poderoso chefao
[14:48:10] Fisico 2: e depende também do material do recipiente
[14:48:19] Fisico 1: com o dom corleone desenhado
[14:48:28] Fisico 1: ahhhh
[14:48:35] Fisico 1: tem um rosa vermelha na lapela
[14:50:23] Fisico 2: mas é o marlon brando ou o de niro?

21Ago/110

Computação em Nuvem by Google

No início do ano, consegui fazer com que todos os meus serviços pessoais ficassem "na nuvem". Ainda estão, e com muito orgulho. Só que a "fidelidade" aos serviços da Amazon diminuiu. Ainda gosto muito dos serviços deles, mas duas coisas estavam consumindo muito tempo meu: configuração de e-mail e o bendito servidor de aplicações Java. A loja virtual de pronta-entrega Avon que eu fiz requer os dois, e os e-mails de potenciais clientes consomem tempo para responder da forma que um cliente de loja espera.

Além disso, o servidor Java vivia com problemas. No início, pensei que era algo com o Glassfish nas máquinas "micro" da Amazon. Todo dia era necessário reiniciar o servidor, que estourava a memória da máquina no segundo ou terceiro dia de uptime. Tentei trocar por um Tomcat, usando Wicket no lugar de JSF. A memória ficava no mínimo. A produtividade melhorou, graças aos testes unitários. O tempo para restart também melhorou, mas ainda existia. Agora que estou também on-line no BuscaPé, não posso me dar ao luxo de fazer "heartbeat manual" no servidor toda hora. Muito menos parar minhas atividades de funcionário BuscaPé para descobrir que algum bot mal-feito está consumindo 100% dos recursos do sistema.

Bolando um projeto para uma comunidade de divulgação de código, só tive duas escolhas: fazer em outra linguagem (ex: PHP) e consumir um tempo que eu não tinha, ou continuar em Java e achar uma solução para meus problemas. Meu amigo Nelson, que tem seu próprio projeto no Google App Engine, acabou me convencendo da praticidade - principalmente por causa do quesito "custo" (zero, para o tipo de aplicações Java que eu tenho).

Decidi, então, dar uma chance ao App Engine junto com seu tal "BigTables". Tentei inicialmente migrar a loja. O Wicket requer um ou outro truque para funcionar no GAE, mas a parte complicada foi a persistência de dados. JDO, JPA, low-level - tanto faz. O problema real são as limitações impostas pelo Google.

Do ponto de vista de um programador Java clássico (ouso dizer "de mercado"), é um lixo. Muitos recursos sine qua non de nossa vida diária (como o relacionamento MxN de uma "Venda"x"Produto", ou filtros de busca complexos) são bem mais difíceis de implementar.

Entretanto, é perfeitamente compreensível do ponto de vista de alguém que trabalhou até em Mainframes e que passou por uma excelente turma de banco de dados (tópicos avançados) na faculdade. Quando o sistema gerenciador de banco de dados te obriga a pensar um pouco mais, melhores soluções sempre surgem. Meu MxN não é carregado de forma "mágica" pelo JPA e os filtros são melhor pensados. O custo de processamento divide-se entre o banco e a aplicação, ficando mais claro o tamanho do problema que você impõe ao SGBD (ou você acha que "JOINs" e "subqueries" rodam de alguma forma mágica no banco?).

O projeto da comunidade foi, na visão de arquiteto e líder de projetos, um sucesso. Levou pouco tempo para implementar e com pouca chance de falhas, graças a quase 300 casos de teste, que rodam em 30s e cobrem até boa parte da interface (sem usar o Selenium). Mais uma vez, como tudo na solução é deveras simples, fica trivial testar - mesmo com uma arquitetura mais "densa" e com menos camadas.

Com os conhecimentos que obtive nesse projeto, consegui hoje terminar a migração da loja também para o App Engine. Não pude fazer um sistema muito "belo" internamente, por ter sido uma migração delicada (somente tenho uns 90 casos de teste), mas a infra é bem mais estável, e o sistema já ficou mais "mantenível".

De brinde, ao tentar configurar o redirecionamento dos domínios WWW, consegui também migrar o e-mail para o GMail. Não falo de "download POP" que nem o GMail padrão tem. Consegui configurar a conta do "fale conosco" para virar um grupo do domínio, criar uma conta para minha esposa e adicionar nós dois ao grupo. Assim, divide-se o tempo para responder aos potenciais clientes, tudo usando "contas Google Apps", que diferem das contas "Google pessoais", além da interface amigável do GMail (seja pela web - algo que senti falta - ou via IMAP).

Em resumo, tudo muito bem em duas núvens (Google para Java e e-mails, e Amazon para o resto), mas a pergunta: por que não usar o Beanstalk junto com o SDB? Simples: a arquitetura mínima deles requer uma máquina e um "load balancer" - o que significa duplicar meus custos. No Google, com menos de 2000 requisições por dia, fica gratuito. Quando eu superar a faixa de acessos gratuita, posso considerar uma reavaliação.

Categorias: cloud Sem Comentários
18Ago/112

Serviços, SOA e BPM

Agora que meu amigo Flávio vai para uma empresa que trabalha com BPM, dei uma introdução sobre o assunto que acho que outras pessoas podem se beneficiar. Vamos contar uma historinha.

Tudo começou com o desenvolvimento "clássico" de aplicações. O desenvolvedor ouve o que o cliente/usuário quer e transforma isso em programas. Esse modelo funcionou muito bem até que a quantidade de código tornou-se tão grande que inviabiliza continuar com um único sistema monolítico. Surgiram os "módulos" (cadastro de funcionários, clientes, contas a receber, etc).

Com um sistema modular, fica mais fácil a expansão e manutenção de cada módulo individualmente. O time de desenvolvimento continua recebendo as requisições do cliente/usuário, mas, dessa vez, cada parte interessada só precisa afetar seu próprio módulo. Tudo maravilhoso, até que as necessidades dos módulos começam a se interseccionar. "Contas a receber" depende do cadastro de clientes, "pagamento" depende dos funcionaŕios, etc. Surge o conceito de "serviço".

Ao invés do cadastro de cliente só existir no módulo de "clientes", ele pode existir como um "serviço de clientes", e os demais módulos usam esse serviço: o módulo de "clientes" alimenta esse serviço com novos clientes, enquanto "contas a receber" usa o mesmo serviço para alimentar sua própria base de contas com dados dos clientes devedores. "Serviço", segundo a Wikipedia, é um conjunto agregado de funcionalidades somado com uma política de acesso. Repare que um serviço não precisa ser um Web Service SOAP ou REST! O importante é agregar uma funcionalidade autocontida e controlar o acesso à informação (ou seja, nada de "SELECT"s direto na base). Até um "JAR" devidamente configurado ou um Servlet serviria.

Se você consegue encapsular as funcionalidades em serviços, por que não encapsular TODAS? Tudo poderia ser serviços ("Confirmação de Cliente", "Inclusão de Conta", "Aprovação de Acesso de Funcionário", etc), bastando uma interface bem fina, só para orquestrar e receber dados do usuário. Isso podemos chamar de uma arquitetura orientada a serviços. Ou seja, SOA. Com SOA, assumindo que todo o negócio do sistema está modularizado em serviços, toda nova funcionalidade fica simples de implementar: basicamente basta fazer uma nova orquestração para os diversos serviços já existentes. Novos serviços surgem com bem menos freqüencia - basicamente, surgem com as funcionalidades mais "inovadoras" (integração com o setor financeiro, uma nova empresa comprada, etc).

Daí, com vários serviços já prontos, o trabalho principal da equipe de desenvolvimento é receber as necessidades do cliente/usuário, modelar o negócio e orquestrar em SOA. Nesse nível, normalmente, a empresa já tem uma equipe de negócio especializada. O trabalho dessa equipe, então, fica meio estranho pensando de forma "clássica": a equipe de negócios recebe a requisição do cliente/usuário e repassa aos desenvolvedores. Qual a utilidade deles? Temos pauta para muita discussão, mas esse não é o foco. Em minha opinião pessoal, quando o trabalho deles é bem feito, tem muita utilidade.

O que aconteceria se a equipe de negócio, ao invés de rabiscar no "Word", rabiscasse a orquestração em um "meta-sistema"? Se fosse possível, nesse sistema, dizer que existe um formulário que deve enviar ao serviço de cadastro de clientes, obter a resposta, enviar ao serviço de "abrir ordem de serviço", aguardar confirmação do gestor por e-mail, etc, etc? Muito mais fácil que implementar a tela que chama dois serviços, envia e-mail, etc. Com isso, seria possível modelar o processo que rege um negócio. Oras, isso é o tal BPM (Business Process Management)! Com BPM, os desenvolvedores fazem os vários serviços, enquanto a equipe de negócio orquestra tudo.

Se é tão maravilhoso, por que parece não funcionar? Simples. Quem leu o que escrevi sobre "mercado versus inovação", pode ter imaginado: ainda não houve inovadores suficientes para que o mercado possa seguir. Logo, alguns erros básicos geralmente são cometidos:

  • Programadores não entendem BPM - é triste, mas muitos programadores "clássicos" acham errado que a equipe de negócio faça a modelagem com ferramentas visuais. Acham que é mais fácil fazer uma tela em Java com toda a lógica e pronto. Eu, particularmente, acho que seria muito mais fácil fazer vários serviços SOAP ou REST e testar ao máximo com testes unitários - sem precisar de enormes armengues para testar a interface (isso quando é possivel testar). Como o serviço só contém lógica e uma política de acesso (nesse caso, a interface SOAP/REST), basta testar a lógica que o "bind" com o Jersey ou similar é o menor dos problemas;
  • Ninguém entende SOA - todo mundo acha que basta fazer tudo com webservices que você tem SOA. Falácia gravemente obtusa. SOA pressupõe serviços, e não webservices. WS só é padrão de facto em SOA pelos seus benefícios de passar firewall, usar "protocolos normais" (HTTP, XML), etc. Nada impediria que um JAR fosse um serviço, ou qualquer outra tecnologia mais obscura (CORBA, CICS, etc). O truque do SOA não é o "S", mas sim o "A". A arquitetura dos serviços é o fundamental. Se você nem sabe o que colocar no serviço, já era - desista de usar SOA por enquanto;
  • Querer começar criando novos serviços. Ou seja: fazer as novas funcionalidades em "SOA" e esquecer o legado. Mais uma falácia. Detesto esse erro clássico de tentar fazer algo reaproveitável começando do zero. Como reaproveitar se nem aproveitou ainda? Que tal olhar aquele sistema legado monstruoso e ver o que ele faz ao negócio? "Puxa, preciso fazer a funcionalidade de prospecção de clientes igual ao legado". Opa! Traduza para "preciso reaproveitar a prospecção de clientes do legado". Olha o tal "reaproveitar" aí. Transforma em um serviço! Legado usa uma outra tecnologia? Integração também é uma palavra bonita! Provavelmente você já tem um jeito de acessar o legado usando sua tecnologia nova (já vi até Java conversar com CICS!), então, faz o Java virar o tal WebService, somente traduzindo os dados e solicitando ao módulo legado. Pronto! Um serviço totalmente reusável surgiu! Mais inteligente que tentar recriar do zero, copiando o que tem no legado - e bem mais rápido de fazer, também.

Resumindo, reparem na história que contei. SOA e BPM encaixaram como uma luva por causa do legado de aplicações. Eles deram a base para transformar o sistema monolítico em módulos, depois em serviços, depois orquestrar com SOA, por fim modelar com BPM. Se tentar começar com BPM ou SOA sem ter profundos conhecimentos do negócio, nem de prática real em SOA/BPM, é evidente que algo errado vai acontecer.

12Ago/111

Inovação e mercado

Na minha opinião, inovação e mercado são conceitos opostos. Não tem como ser inovador seguindo o mercado. O mercado não inova. Veja Steve Jobs e sua maior criação: a Apple. Ele não briga tentando inovar em mercados competitivos. A Apple cria novos mercados. Até hoje ainda não acredito que ele reinventou o mercado de MP3 Players com o iPod ou que ele tenha criado o mercado de tablets com o iPad (cá entre nós, adoro meu iPad 2, mas ele é somente um iPhone gigante).

Filosofando com meus amigos Nelson e Flávio sobre mercado, encontrei a metáfora perfeita para comprovar. Nos Simpsons, acho que na 14ª temporada, episódio 5 ("Helter Shelter"), tem uma reunião dos executivos de uma emissora de TV, na qual um deles falou: "precisamos inovar! Vamos ver o que está passando nos outros canais!" E todos sacam suas TVs portáteis e começam a ver a concorrência. Hilário pensar que dá para uma Globo inovar copiando o SBT ou vice-versa.

Agora, compare essa cena com uma reunião entre gerente, líderes, peões e consultores, no qual o gerente começa a reunião dizendo: "precisamos inovar! O que o mercado usa para resolver meu problema?". Reparou a contradição?

Não dá para dizer que o SBT inova quando quase todos os programas são comprados de outras emissoras. A menos, claro, considerando que o mercado de TV no Brasil tem uma redoma na qual ninguém sabe o que acontece no resto do mundo (algo parecido com a tecnologia anos atrás).

Se você trabalha com informática, não dá para inovar usando Eclipse do jeito que todo mundo usa, programando Java como todo mundo. Tem que ver o que o NetBeans ou o JDeveloper tem a oferecer, usando Ruby, GWT, Scala, Vaadin, Wicket ou JDO, experimentando com misturas exóticas (ex: Rails de interface, Scala na camada de negócios, BigTables na base).

A moral da história? O mercado segue os inovadores. Se você precisa usar o que o mercado usa, significa que está na lanterna.

4Ago/111

Entrega em domicílio? Esquece!

Vou acabar criando um blog só sobre coisas boas que foram perdidas pela burrice humana. Acabei de descobrir que, no condomínio onde moro, os porteiros foram proibidos de receber encomendas. Absurdo! Algum imbecil compra uma TV de Plasma e deixa ela mofando na portaria por uma semana e eu que me lasco? Fala sério! Pior que estou com uma encomenda minúscula dos EUA, sem rastreamento (maldita CafePress que só avisa depois do envio), e é rezar para eles entregarem quando tiver alguém em casa.

O que me leva a perguntar: o que diferencia uma encomenda de uma carta, por exemplo? Digamos um talão de cheques do banco contra uma fatura bem gorda do cartão de crédito? E um CD/DVD/Bluray? TV de plasma na portaria é coisa de gente sem noção, mas uma camisa "Don't Panic" é minúscula - acho que daria na caixa de cartas.

Não encontrei legislação para o fato, mas já vi outros condôminos (e até alguns síndicos) falando que isso "é normal". Normal é receber encomenda na era da Internet. Anormal é querer que o porteiro receba uma encomenda delicada, cara e frágil (TV de plasma - really???).

Cada vez mais meu lema está virando: "perdi a fé no ser humano"...

Categorias: shoutbox 1 Comentário