Blog de arquitetura de software do Dino

Aprendendo com quem já fez

2009-12-03T12:40:00.000-08:00

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

2009-12-03T12:10:00.000-08:00

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

2009-11-26T12:12:00.000-08:00

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?

2009-09-17T18:28:00.000-07:00

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

2009-08-13T14:47:00.001-07:00

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

2009-07-30T10:20:00.000-07:00

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

2008-12-12T05:53:00.001-08:00

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

2008-11-13T16:50:00.000-08:00

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+

Arquiteto??? Você constrói casas, prédios?

2008-10-31T12:46:00.000-07:00

Outro dia tive que tentar explicar pela milionésima vez porque fui contratado como arquiteto de soluções. A pergunta mais normal é:

- mas você não era programador?

Sim, eu sou e me orgulho muito disso.

Então:

Qual é a diferença?
O que faz de alguém um arquiteto?
Quais os papéis que ele desempenha?

Bom, vamos por partes, de traz para frente.

Quais os papéis que um arquiteto de software/soluções exerce?

O The Architecture Journal dedica sua edição de #15 inteiramente a este assunto, nem vou tentar resumir aqui, recomendo fortemente a leitura. Ou se preferir tem este ótimo post que resume bem o assunto.

O que faz de alguém um arquiteto?

Existem algumas abordagens para definir um arquiteto, algumas analisam o lado técnico, outras a capacidade de síntese, outras ainda defendem que é um cara que consegue entender as necessidades de negócio e ao mesmo tempo tem o conhecimento técnico necessário para desenhar a melhor solução possível. Este último para mim chamou-se um dia Analista de Sistemas e já faz um tempo que não ouço falar dele.
Eu prefiro uma abordagem, digamos, mais humanista. Para mim o que faz um programador se diferenciar dos outros (sair dos 80%???) e se tornar arquiteto é o espírito inquieto, a persistencia, o equilíbrio e principalmente o estudo.

O espírito inquieto
Sabe aquele moleque que desmonta as coisas pra depois passar dias tentando entender onde deveriam estar as peças que sobraram? Conhece aquela criança que de cada 10 palavras ditas 11 são "por que"? Sabe aquele nerd do colégio que não para de encher a paciência dos professores enquanto não entende a matéria? Sabe aquele curioso que mexe em tudo, que tenta saber um pouco de tudo?
Então, esses são alguns fatores (entre milhares de outros) que indicam uma pessoa com a predisposição a ir além, a sair da caixa e ver o quadro geral, a distrinchar um problema até chegar à sua causa raiz e só então propor uma solução. Este tipo de pessoa tem mais chances de se diferenciar como programador e se tornar arquiteto, não que alguém sem essas características não o possa, é só que para alguém assim o caminho é mais suave.

A Persistência
Muito já se falou sobre isso mas é sempre bom lembrar, não basta ser genial nas idéias é preciso persistir até conseguir provar com algo material que suas idéias são viáveis. Um ex-colega de trabalho (e bom amigo) costuma usar um termo para este assunto, ele diz que iniciativa é bom, mas é imprescindível ter "acabativa", ou seja, de nada adianta começar n coisas e terminar nenhuma delas.

O Equilíbrio
Se alguém é extremamente radical, esta pessoa pode ter problemas em se tornar arquiteto de software pelo simples motivo de que a radicalidade acaba tirando da pessoa a capacidade de ver o quadro geral, tira a imparcialidade necessária para enxergar corretamente o problema e limita o número de ferramentas disponíveis para solucioná-lo.
Um exemplo disso é a pessoa que é radicalmente a favor de uma linguagem de programação a ponto de não enxergar pontos positivos em qualquer outra. Isto ocorre com sistemas operacionais , IDEs, navegadores, plataformas de desenvolvimento, times de futebol, religião, poítica, marca de cerveja, música, etc.
O ponto aqui não é exatamente o equilíbrio em relação a questões tecnológicas, mas, num sentido mais amplo, avaliar a pessoa pelo modo como ela se posiciona em relação a questões polêmicas, se sua posição é geralmente ponderada, o caminho para esta também tende a ser suave.

O Estudo
Os arquitetos que conheço são absolutamente malucos por informação, os caras estudam o tempo todo, sobre várias coisas, ao mesmo tempo. Neste ponto tenho que concordar, a pessoa tem que ter uma capacidade de síntese muito boa para conseguir rapidamente ler (ou ver, ouvir, etc), entender, filtrar e classificar a informação.
Neste ponto as características citadas anteriormente agem juntas fazendo com que a pessoa estude a fundo um assunto (persistente) mas não a ponto de se viciar nele (equilibrado), faz com que ela mude o foco constantemente (inquieto, curioso) mas ao mesmo tempo mantenha o foco tempo o bastante para digerir e compreender o assunto (de novo persistente).
Mais que ser estudioso, a capacidade de aprender a aprender talvez seja a mais marcante caracteríscta do arquiteto. Numa área onde tudo muda a todo momento, não basta saber, tem que saber aprender e se munir disso para o bem de si próprio e da empresa. Aquele que consegue aprender a aprender também caminha mais tranquilamente no sentido de se diferenciar.

Então qual é a diferença?

De verdade? A diferença está nas escolhas que a pessoa faz ao longo da carreira, talvez antes mesmo de ingressar no mercado de trabalho.
Os que escolheram tentar, fuçar, mexer, quebrar, arrumar, perisistir, aprender coisas novas, ouvir músícas diferentes, conhecer pessoas, estudar filosofia, etc. criaram ao longo da vida uma " "poupança" que lhes permite ser diferente, ao invés de se tornar diferente. Aos que ainda não são, sempre é tempo, basta começar.

Finalizando, se eu sou um programador? De novo, sou sim. Adoro código, adoro falar de software e hardware, adoro SQL, índices, tabelas, EJBs e C#s. E sim, sou arquiteto, pelo menos é como me chamam aqui no trabalho, e também me orgulho disso.

por hoje é só.
T+