quinta-feira, 3 de dezembro de 2009

Aprendendo com quem já fez

Já que o dia é de referências, o sr David Lojudice Sobrinho postou hoje uma apresentação de sua autoria, como trabalho de conlusão da pós graduação, sobre escalabilidade de sites web. Neste trabalho ele analisou a arquitetura de grandes sites em busca de características e técnicas comuns a eles no que se refere a escalabilidade, também vale a visita

Web em Tempo real

Há algum tempo atrás, anos na verdade, eu estava trabalhando em um projeto VOIP e, entre outros, um dos desafios era mostrar na página web do usuário do serviço de telefonia um indicador de chamadas, algo que o avisasse que o telefone ia tocar, quem estava ligando, algo que permitisse ao usuário acompanhar os status das ligações correntes, entre outras coisas.
Apesar de parecer simples a princípio, o desafio se mostrou bastante interessante graças a uma restrição não muito comum (naquela época) quando se pensava em aplicações web, a informação tinha que acontecer praticamente em tempo real, ao mesmo tempo que mandávamos um pacote SIP para um device (um telefone IP ou um softphone) tínhamos que fazer push desta informação para uma página web! Como fazer?
Após algum tempo de pesquisa acabamos por optar por uma técnica hoje bastante difundida, o long polling e foram escritas algumas dezenas de linhas de código para fazer com que tudo funcionasse.
Os problemas começaram quando começamos a nos deparar com inesperados problemas de performance no servidor http, quando o código não funcionava em diferentes browsers, quando qualquer manutenção se tornava um tormento.
Depois de um bom tempo fora do projeto, hoje já nem sei se isto tudo ainda existe, se está em uso e muito menos como está sua arquitetura e seu código, mas por um destes acasos do destino o Sr Luis Cipriani, um dos malucos do núcleo de pesquisa e desenvolvimento da empresa onde trabalho atualmente, fez uma apresentação no DevInSampa tendo como tema "Web em tempo real", além de ser uma ótima apresentação, foi inevitável pensar: "era isso!".
A arquitetura, os requisitos, mesmo as decisões de design e implementação são simplesmente a melhor resposta ao problema do "status de chamada" que vi até agora. Vale a pena investir um tempo assistindo a apresentação e codando um exemplos das tecnologias citadas.

quinta-feira, 26 de novembro de 2009

arquitetos, tradeoffs , consensos e afins

Segundo a wikipedia: "Trade-off ou tradeoff é uma expressão que define uma situação em que há conflito de escolha. Ele se caracteriza em uma ação econômica que visa à resolução de problema mas acarreta outro, obrigando uma escolha".

O dia a dia das pessoas que trabalham com desenvolvimento de software é recheado de escolhas, é comum ter que decidir entre este ou aquele estilo, TDD ou BDD, este ou aquele framework, etc.
Cada uma dessas decisões trazem em si uma boa carga de stress e ansiedade já que elas acarretam, conforme explicado acima, algum nível de perda.

Quando se trata de decisões de longo prazo, aquelas que uma vez tomadas é complicado (e caro) voltar atrás, a decisão em geral não pode ser tomada por uma única pessoa, entra em cena a busca pelo consenso.

Cada um dos stakeholders tem seus argumentos a favor e contra, e é bastante comum que haja grande conflito de interesses. No meio deste novelo de interesses em geral está o arquiteto, atuando numa das suas mais importantes tarefas: buscar o consenso de forma a sair com uma solução que contemple ao mesmo tempo as necessidades de negócio do projeto, as necessidades técnicas de desenvolvimento e também as "garantias" que todo sistema precisa para funcionar em produção.

Em uma recente palestra Stefan Tilkov aborda o tema "trade-off" de forma bastante interessante, partindo da premissa que sempre que alguém se deparar com um trade-off a resposta padrão é depende, ele aborda os trade-offs existentes entre soluções genéricas e específicas e apresenta algumas características que devem ser levadas em consideração por alguém com a missão de decidir.

Fazer escolhas, decidir entre a menor perda e o maior risco, a capacidade de criar uma lista de caracteríscticas ou argumentos a favor e contra cada lado do conflito e por fim, através de argumentação e negociação, chegar a uma decisão que represente um cenário aceitável para todos os envolvidos é algo bastante comum, dia a dia mesmo, para alguém de negócios.

O que nos leva a uma conclusão interessante: um arquiteto (neste contexto) é um desenvolvedor com experiência e conhecimentos técnicos avançados mas com um viés de negócios na bagagem, com habilidades normalmente encontradas em pessoas não técnicas.

O que é por si só um trade-off, uma vez que desenvolve capacidades de negócio, se distancia do dia a dia técnico, das especificidades que fazem um bom técnico especialista.

Portanto, para quem está pensando se é melhor ser um arquiteto de software ou investir na carreira de especialista a resposta é: DEPENDE. :)

quinta-feira, 17 de setembro de 2009

Débitos técnicos e o Grameen?

Estou lendo a biografia do Yunus, o banqueiro dos pobres, nela é contada a história da criação do banco Grameen, um banco especializado em microcrédito que concede empréstimos à parcela mais miserável da população de Bangladesh há mais de 20 anos.
Quase ao mesmo tempo me deparei com um post no blog do mergulhão onde ele compara débitos técnicos de projetos de software com dívidas, concluindo que se alguém coleciona débitos técnicos sobre débitos técnicos o efeito é o mesmo do devedor que pega um empréstimo para pagar outro, ou seja, uma hora vai quebrar, é só questão de tempo.
Tá, mas o que uma coisa tem a ver com a outra? Na minha opinião as coisas se cruzam na parte do livro onde o autor descreve a forma como o banco lida com os pagamentos: ao invés de um grande pagamento ao final do período, eles recebem pagamentos semanais. Isto foi feito para que o valor da parcela fosse pequena o bastante para ser paga sem que o devedor "sinta". Segundo Yunus, valores pequenos evitam que os devedores sintam-se tentados a arranjar desculpas para não efetuar os pagamentos.
Fazendo analogia com o cotidiano vivido por desenvolvedores ágeis, seria até aceitável terminar uma sprint com alguns débitos técnicos a fim de manter o prazo de entrega, desde que esta dívida fosse imediatamente transformada em uma história (empréstimo) que teria como objetivo refatorar o código (pequenos pagamentos) até que os débitos técnicos fossem eliminados (empréstimo quitado).
Neste cenário, comprometer-se com um sprint backlog cheio de novas funcionalidades sem corrigir os débitos passados seria o mesmo que pagar juros sobre juros, até pode funcionar por um tempo, mas...
Outra solução normalmente empregada é a sprint técnica, recheada de correções, ajustes e melhorias. Esta saída seria o equivalente ao tal "grande pagamento no final" e o seu grande incoveniente é o mesmo citado por Yunus, todos vão certamente procurar todos os tipos de argumentos para evitá-lo ou postergá-lo, já que o "montante" (uma sprint inteira) é muito alto e vultoso.
É óbvio que o ideal é que simplesmente não existam débitos técnicos ao final de uma sprint, ou mesmo ao terminar uma história, assim como o ideal é que não precisássemos recorrer a empréstimos, cartões de crédito, etc. Mas a realidade não liga muito para o ideal, e as vezes simplesmente não dá para evitar. Nestas situações o melhor é reconhecer logo a "dívida", antes que os juros tornem-a insolúvel.

quinta-feira, 13 de agosto de 2009

Tem fórum novo na área

Um grande amigo deu mais um passo importante na carreira! O sr Fernando Campos se preparou bastante e está bastante animado com mais esse desafio, está dando aulas na Unip. Não deixa de ser interessante ver quanto um cara muda ao longo de 10 anos... sair de aluno desatento (pra pegar leve) a professor dedicado foi realmente algo surpreendente.
Uma das ferramentas que ele preparou para dar suporte a suas aulas é um fórum, do qual passo a ser eventual contribuinte.
Comecei falando de bancos de dados, uma questão antiga e genérica, com uma resposta ainda mais antiga e genérica :)
Para os mais "antigos" que estiverem afim de ajudar, dá uma passada lá e deixem suas respostas/opiniões, para os novatos, perguntem!

quinta-feira, 30 de julho de 2009

To de volta, sipservlets e RTPclients

Depois de muitos e muitos meses resolvi voltar a ativa, agora com mais força, espero eu....

Durante tres anos, de 2005 a 2008 trabalhei para a Voice Technology construindo uma plataforma VOIP para a Brastel, lembro-me que durante as primeiras conversas ainda no começo do projeto sempre nos deparávamos com o problema de como inserir o sip no contexto javaEE. Existiam drafts indicando que o caminho era construir um Resource Adapter, outros falavame em Servlets (sipservlets) e por fim, acabamos por fazer um serviço que se integrou ao JBoss através do protocolo JMX.

Apesar de ser uma decisão acertada naquele momento, a equipe sempre questionou em que momento alguma dessas alternativas se tornaria padrão de fato no mercado, talvez este padrão ainda não exista mas hoje a galera que defende o sipservlet recebeu um ótimo reforço nos seus argumentos. Foi lançada a versão 1.0 da implementação da Mobicents para a versão 1.1 do sipservlet, compatível com tomcat e jboss e licenciado sob LGPL.

Sem dúvida é um grande avanço em termos de estabilidade, padronização e principalmente integração entre as plataformas web e voip, agora é meter a mão na massa para constatar na prática as vantagens teóricas citadas aqui.

Em tempo, a voice labs está desenvolvento uma api java para interfacear como rtpproxy, resolvendo assim problemas de nat, escalabilidade, distribuição de carga, entre outros, vale dar uma olhada.

[]s
Dino

sexta-feira, 12 de dezembro de 2008

O ciclo de morte dos sistemas

No começo tudo são flores, a equipe é montada, a arquitetura definida, os requisitos mal e porcamente levantados e todos trabalham com afinco até que o sistema entra em prodção, então alguns membros chave do grupo saem, outros perdem o interesse, o sistema começa a sofrer manutenções até que um dia alguém diz: "Não posso fazer a alteração que o sr está pedindo porque não sei se a alteração não vai quebrar outra funcionalidade"

Quem com alguns anos de experiência na área de desenvolvimento de sistemas nunca se deparou com um frase como essa? Ela demarca o princípio do fim, a partir daí o sistema começa a ficar engessado, estático, para de se desenvolver e entra na fase do "só arruma o que está dando problema", daí para o "joga fora e faz de novo" é um pulinho.

Mas como evitar que isto aconteça? Simples:
  • Adote métodos de desenvolvimento que fomentem a comunicação e consequente compartilhamento do conhecimento (SCRUM por exemplo)
  • Invista em testes de regressão automatizando o máximo possível
  • Tenha a coragem de mudar quando necessário, mude as pessoas, a plataforma, a funcionalidade, etc
  • Integre continuamente
  • Invista nas pessoas, na formação e no bem estar delas
Mas (sempre existe o mas) é complicado justificar aos investidores do projeto o tempo (e dinheiro) gasto na implantação de práticas de engenharia , então talvez esta seja a justificativa: proteja seu investimento atual através do uso das boas práticas de engenharia, ou então dentro de algum tempo voce terá que dispor de tempo, pessoas e dinheiro para fazer tudo de novo.

por hoje é só
[]s
Dino