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.

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. :)

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.

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!

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

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

O ciclo virtuoso do ensinamento/aprendizado

Vou insistir no assunto conhecimento e aprendizado porque realmente acredito que vale a pena, já que cada vez mais isso se torna um diferencial no mercado de trabalho.
Quando eu estava na faculdade tinha um professor de matemática financeira que vivia usando a frase "voces deveriam experimentar a estranha sensação do raciocínio" quando se referia à nossa preguiça mental. Hoje em dia entendi (eu acho) o que ele queria dizer e a aprecio tanto que acrescentaria "experiemente, dá barato!".
E o que isso tem a ver com arquitetura de software ou com tecnologia? Tudo! Escrevi no post anterior que uma das características que considero essenciais para um bom arquiteto - ou um bom profissional da área de TI em geral - é saber aprender, neste vou além: um bom arquiteto deve usar sua experiência e conhecimento para ensinar a aprender.

O arquiteto até pode ser líder mas nunca chefe
A diferença entre o líder e o chefe é que basicamente o primeiro é um cara que fica no plano de fundo, sem aparecer muito e cujo principal objetivo é levar os liderados ao sucesso, no contexto aqui proposto o sucesso seria o aprendizado, a aquisição do conhecimento. O chefe todo mundo tem e sabe como é.
Dentre as várias estratégias possíveis que poderiam ser usadas para atingir tal objetivo, uma que gosto muito de aplicar consiste em fazer com que o aprendiz chegue a uma conclusão (aprenda) através de perguntas e mais perguntas, sempre dando direcionamento, gerando conflito, mas nunca relelando a resposta em si, até que num dado momento o próprio aprendiz tem o "estalo" que resolve a questão. Neste instante o cérebro faz sua parte liberando substâncias químicas que dão um certo tipo de prazer (mais ou menos como a adrenalina) e a tal sensação do raciocínio se faz presente, como disse antes, dá barato!
Logicamente existem outros métodos, desde ensinar através de exemplos até as tais "comunities of practice" onde se aprende estudando e observando os mestres (ou membros do core), ou então incentivando a leitura (e porque não escrita) de artigos técnicos e/ou científicos, etc.
O importante é que o aprendiz consiga criar em sua mente a inferência que leva à solução, e não a solução em si, pois a primeira pode ser combinada com outras para solucionar outros tipos de problemas criando assim a base de um cérebro criativo.

Mas porque não dizer logo o que e como fazer ?
"Afinal é só dar a ordem, depois cobrar o resultado e pronto. Além do mais, fazer isso (ensinar a aprender) leva tempo, às vezes dá muito trabalho e nem sempre é bem recebido pela equipe".
Entre tantos motivos que consigo pensar, aquele que me parece o mais importante é: porque essa é uma via é de mão dupla, ensinar é a forma mais eficiente de aprendizado.
Pergunte aos seus professores, todos são unânimes em dizer que aprendem coisas novas diariamente com seus alunos, sendo assim o barato do aprendiz também é o barato do mestre: a aquisição de conhecimento.
Aí está a mágica, o conhecimento gera bem estar, que gera a predisposição a aprender, que realimenta a fonte inicial do ciclo, o mestre, que por sua vez se ve mais disposto ainda a ensinar. É este ciclo virtuoso que devíamos almejar ao escolher o difícil e trabalhoso caminho do ensinamento em detrimento da aparente agilidade de uma ordem.

bons estudos, bons ensinamentos
t+