Blog do Alone

Quando se trata de Web, o Google é uma fábrica de inovação. E quando o desempenho é o problemas eles sempre tem uma carta na manga. Com o objetivo de tornar a web mais rápida e eficiente, a gigante das buscas deu início a uma iniciativa chamada “Lets make the web faster”. Essa iniciativa propõe a adoção de um conjunto de boas práticas para tornar o tráfego utilizado via HTTP mais rápido. Essas boas práticas são medidas simples e bem elaboradas para otimizar o tamanho de imagens, redução de espaços em branco de JavaScript, compressão de documentos HTML e etc. Porém, o que mais me chamou a atenção foi a utilização de um novo protocolo para trabalhar em conjunto com o HTTP, o SPDY.

O SPDY, como o Google diz, nada mais é do que um protocolo para transporte de conteúdo através da internet, que foi projetado para gerar o mínimo de latência possível. De acordo com os testes feitos nos laboratórios do Google, o tempo de caga das páginas tiveram o tempo reduzido em torno de 64%. Realmente é um tempo considerável, mas do que se trata esse protocolo, o que ele faz pra ser tão rápido?

O protocolo utilizado na rede mundial de computadores é o TCP/ÍP. Esse protocolo encontra-se, segundo o modelo OSI, na camada de transporte que visa garantir a entrega dos pacotes de uma origem até seu destino. A utilização desse protocolo com o HTTP proporciona que os browsers abram um conexão  a cada request e response. Nesse processo, a latência gerada vem da única requisição por conexão TCP/IP feita pelo browser, cada requisição é feita pelo cliente (browser) tornado o WebServer um robô sem inteligência enviando/recebendo na maioria das vezes um conteúdo que poderia ser comprimido. Ainda por cima, o padrão de envio de documentos não comprimida, coisa que poderia ser feita utilizando algumas boas práticas.

Com a utilização do SPDY em conjunto com o HTML os ganhos de desempenho são obtidos implementado funcionalidades que eliminariam as características citadas acima como:

• Streams multiplexadas: Possibilidade de suportar inúmeras requisições e respostas através de uma conexão TCP.
• Request Priorization:  Essa implementação permite que o cliente possa fazer uma série de requisições do servidor e o mesmo respondendo-as de acordo com a prioridade da mesma.
• HTTP header compression: Implementação da compressão do header resultando em pacotes menores de menos bytes transmitidos.

Esses são os itens básicos que o novo protocolo foi designado para resolver. Existe uma série de melhorias na pagina do protocolo. Lá é possível encontrar maiores detalhes sobre o desenvolvimento do mesmo e a bateria de testes e seus resultados.

A idéia do Google não é substituir o HTTP para processar as requisições WEB, e sim fazer com que ambos os protocolos trabalhe em conjunto. Nesse ponto os engenheiros do Google tiveram bom senso, já que, implementar a troca do HTTP (cliente) contida nos navegadores seria uma tarefa não só tecnológica e sim política decidiram implementar o mesmo nos Web Serves.

Já que o protocolo inda não está disponível, portanto, para tornar a web mais rápida podemos seguir as iniciativas do Lets make the web faster. Com a adoção de medidas simples como essas há uma melhoria considerável da latência em cada página carregada.

Mais detalhes: aqui, aqui e aqui

[]s

Notícias google, HTTP, protocolo, SPDY

Quando entramos em um time de desenvolvimento é indispensável utilizar ferramentas de controle de versão, os CSVs. Existem muitas soluções opensource e outras que oferecem serviços de hospedagem com restrição de segurança gerenciado pelo usuário, serviço que na maioria das vezes é cobrado.

Acostumei a utilizar o Git em projetos pessoais e recentemente em alguns projetos opensource e tenho que afirmar: é o melhor CSV que já utilizei. Porém, recentemente necessitei de compartilhar projetos com um time específico, mas não tinha conhecimento de um serviço que fosse grátis e que solucionasse nossos problemas.  Verificamos os serviços disponíveis no GitHUB, porém, adicionar restrições para acessar requer um custo e, apesar de não ser caro, infelizmente descartamos.

Fuçando na net descobri essa lista no Subversion (SVN) Hosting Comparison. Aqui você encontra uma lista completa contendo vários serviços e seus custos, quantidade de desenvolvedores e serviços agregados disponíveis. Encontramos um que oferecia o repositório com suporte a trinta usuários, 100 MB de projeto, track e blog de graça. Não pensamos duas vezes e ficamos com esse.

Espero que ajude aos que procuram hosting de projetos.

[]s

SVN Git, hosting, projetos, SVN

A maneira como desenvolvemos software tem influência direta no produto final, seja positiva ou negativa. Fases são importantes e principalmente a maneira com que passamos por elas no ciclo de vida do produto que está sendo desenvolvido. Para tal, aprendemos a utilizar os processos e boas práticas com o objetivo de agregar qualidade ao produto e conclui-lo no prazo especificado. Quem é, ou foi, aluno de faculdade deve ter vivenciado resenhas que ditam o mundo perfeito repleto de recursos separados por seus devidos papeis em um modelo cascata linear e com suas atividades e fases. Aprendem que um ambiente repleto de analogias e semelhanças e adaptações de paradigmas resolvem todos os problemas.

A preparação para tal inclui uma carga massiva de conceitos, boas práticas, UML e Java, bastante Java. Normalmente aprendemos que o Windows é uma porcaria e que o Linux é o melhor sistema operacional. Aprendemos utilizar meia dúzia de comandos e palavras reservadas de C e pensamos que somos programadores da linguagem. Ou melhor, recebemos uma carga de informações que, de certa forma, não são úteis para as tarefas profissionais.

Quando deixamos boa parte do jargão acadêmico para trás, ou melhor, quando iniciamos nossa vida profissional nos deparamos com situações completamente diferentes que requer sempre mais do que fazemos e uma carga de informação cada vez mais abrangente e atualizada.  Requer que você se adapte as regras de uma empresa e utilize as ferramentas que ela dispõe para você trabalhar.

A o iniciar um novo projeto de software, normalmente trabalhamos em etapas ou fases. Cada uma dessas fases tem suas particularidades onde a equipe, normalmente especialistas em suas funções, desenvolve seu trabalho para passar o resultado para a fase posterior. A particularidade é tanta que, em alguns casos, é necessário ferramentas específicas para a área. Porém, quando uma equipe consegue maturidade, principalmente trabalhando nas ferramentas que tem, sempre tem alguém afirmando que o desempenho deve ser melhorado e o que está impactado é a ferramenta que utilizamos.

Normalmente utiliza-se UML para desenhar diagramas em algum modelador para visualizar nossas idéias da forma mais genérica e abrangente possível. Normalmente, verifica-se que o modelo que desenhamos está enorme e nos convencem de que precisamos de uma ferramenta CASE para organizar melhor o nosso modelo, auto documentá-lo e ao mesmo tempo integrado ao sistema de controle de versão para disponibilizá-lo para outro participante. Posteriormente descobre-se que a ferramenta não foi projetada para integrar com o sistema de controle de versão utilizado pela empresa e nos convencem de que precisamos de um que se integre com a ferramenta para que possamos continuar nosso trabalho.

Utilizando nosso editor predileto iniciamos uma das fases mais importantes de um projeto de software; a codificação. Nosso editor nos permite trabalhar com diversas linguagens de programação, já que textos abrem em todo editor. Nosso compilador trabalha muito bem e faz tudo o que se propõe a fazer para que possamos trabalhar tranquilamente.

Criamos um buildscript que integra nosso ambiente (na verdade solto) e criamos algumas tasks para automatizar nossas atividades. Isso facilita muito a vida de quem lida com projetos com grande quantidade de fontes e que sempre tem que gerar builds em determinado dia da semana. Alguns, vendo que utilizamos ferramentas não semelhantes (normalmente em um terminal de comando) que eles sempre vão nos questionar se nossa produtividade está aquém do que foi combinado e outros vão indica-lo uma IDE para fazer o trabalho automatizado sem saber que o trabalho atual está automatizado.

Gosto muito de um artigo escrito pelo Akita onde ele fala da faca de dois gumes de utilizar IDEs para desenvolver softwares. Diga-se de passagem, gosto muito de IDEs, mas o problema é que geram um tipo de dependência que influencia em todas as suas atividades. Utilizo várias IDEs e sei do que estou falando. Desenvolvi muitos projetos com IDEs e alguns sem elas e vi que existem formas e maneiras, benefícios e malefícios, porém a dependência gerada é extrema.

Nelson.

Off-Toppic ide, uml