Blog do Alone

Recentemente adquiri um modem 3G da marca HUAWEY da VIVO com pacote de internet ilimitado para suprir minhas necessidades de internet, já que, onde estou morando ainda não há cabeamento de voz nem de dados. Verifiquei os valores das soluções via Radio, mas, aqui em Manaus ainda é um absurdo. A única solução foi adquirir o modem para ter acesso a rede 3G.

Instalei o discador que veio no modem e a conexão foi feita normalmente com velocidade média de 50 a 60 KBps, uma velocidade excepcional pra quem mora em Manaus, já que a internet por aqui é precária. Naveguei cerca de dez minutos e uma surpresa, minha máquina travou. Reiniciei, conectei novamente e depois de dois minutos torna a travar. Fiquei frustrado com isso, tentei várias vezes e aconteceu a mesma coisa.

Anotei o modelo do modem e fui ao Google pra tentar resolver o problema. Em um dos fóruns que pesquisei tinha um post que recomendava atualizar o firmware do modem e o discador, lá tinha o link para o site do fabricante onde tinha os pacotes para tal, baixei imediatamente e instalei em seguida tudo conforme tava no manual. Reinstalei o software discador e tornei a discar.

Na primeira tentativa veio a frustração, travou novamente. Muito decepcionado, cogitei  em voltar para o Ubuntu, mesmo ignorando os softwares que uso no Windows, o que importava era solucionar esse problema e voltar a trabalhar o mais rápido possível. Hoje, utilizo o Windows 7, sistema operacional onde o problema ocorria constantemente, e para minha surpresa, o problema acontecia também no Linux. Cogitei em ir para a operadora para trocar o modem, porém, tinha que fazer uma ultima tentativa, tinha que fazer a conexão com o discador nativo do Windows.

Quando o modem é utilizado pela primeira vez no PC é instalado os drivers de conexão para Windows automaticamente. Portanto, ao configurar no discador nativo, para Windows, o modem 3G aparece para ser lincado ao discador. Copiei as configurações do software discador que vem com o modem a adicionei no discador e efetuei a discagem. Funcionou perfeitamente e não travou mais.

Conclusão, o problema todo era software discador que veio com o modem. Quando havia uma quantidade muito grande de dados em transmissão, o travamento ocorria e não era registrado nos logs do sistema operacional.

Detalhes da solução:

Sistema Operacional: Windows 7

Modem: Huawey E1756 MODEM USB 3G

Discador: VIVO Internet 11.302.06.20.149, plugins 1.01

Operadora: VIVO

Open Source 3g, huawei, moden

Desenvolver aplicações para Web que requer bom desempenho, clareza no conteúdo e flexibilidade não é tarefa fácil até para os desenvolvedores experientes. O principal item que deve ser levado em conta é o bom desempenho pelo fato de influenciar na maioria dos valores que podem ser agregados em um produto voltado para Web. Nesse ponto, existem diversas dicas que podem ser seguidas através da iniciativa da Google, o Let’s make the web faster , que apresenta uma série de dicas para compactar o conteúdo ao máximo para tornar a transferência da páginas mais rápida.

Existem recursos que viabilizam o desempenho em aplicações Web de forma aceitável para o usuário final. Entre elas, na minha opinião, o mais adequado é o Ajax. Existem outras alternativas como o Flex, porém, dependendo da aplicação desenvolvido pode haver demora no carregamento e processamento das requisições, mesmo sendo carregada uma única vez. Com base nisso, a utilização do Flex sobre uma intranet é uma excelente opção. Como o contexto é a internet, soluções Ajax levam vantagem pelo fato do conteúdo ser apresentado em HTML/XHTML e pelo fato de não utilizar nenhum plugin para os navegadores. Porém, quando se trata de JavaScript, muitos desenvolvedores tentam evitar por ser mais uma linguagem necessária para o aprendizado para desenvolver uma aplicação. Ironicamente, um desenvolvedor web necessita saber no mínimo três linguagens para desenvolver uma aplicação utilizável.

Em alguns casos, a utilização do javascript em alguns projetos torna-se complicada devido a dificuldade, principalmente quando projetos são feitos utilizado AJAX. Isso encorajou a criação de inúmeros frameworks e componentes que tentam tornar o desenvolvimento de aplicações que utilizam AJAX mais simples e fáceis de manter.

JQuery é um framework que tenta facilitar ao máximo a utilização de JavaScript nas páginas, sendo que, é a ferramenta mais utilizada quando se trata de recursos para a linguagem. O que chama mais atenção são os efeitos e a facilidade para desenvolver com essa ferramenta.

A comunidade Java é privilegiada com inúmeros frameworks e APIs que facilitam o desenvolvimento resolvendo problemas de vários segmentos, principalmente WEB. Acredito que, devido a dificuldade de desenvolver aplicações WEB apenas com JSP, Servlets, Filters, TagLibs, etc., os desenvolvedores tentaram diminuir essa dificuldade com frameworks, tai então a explicação da grande quantidade de frameworks WEB para Java.

Em Java, atualmente, o frameworks WEB mais utilizado, depois do Struts (legado) , é o JSF. Talvez devido ao fato de ser um produto da Sun e estar coberto por uma especificação. Não cheguei a ver detalhes da especificação 2.0, mas nas versões anteriores o desenvolvimento ainda é maçante e chato, onde existem situações que necessitam cada vez da habilidade do desenvolvedor. Porém, muito foi feito para tentar corrigir os problemas e ao mesmo tempo agregar valor ao framework com as extensões repletas de componentes para ser utilizados nos projetos, uma dessas extensões é o RichFaces. Atualmente encontra-se na versão 3.3 e vem uma série de componentes que podem funcionar sobre uma camada AJAX. A facilidade é tanta que a forma de desenvolver é a quase a mesma que desenvolver com JSF puro. Com isso, está a disposição do desenvolvedor recursos de Drag’nDrop, calendários bem elaborados, efeitos, e uma série de componentes bem desenvolvidos que funcionam sobre AJAX.  A configuração do RichFaces também é simples, basta adicionar alguns filtros, escolher o template, ou desenvolver um, configurar um ou dois XMLs e adicionar algumas taglibs no projeto e pronto, seu projeto já está configurado.

O objetivo desse artigo não é de escrever um tutorial e nem comparar as ferramentas, é de alertar sobre a má utilização dos recursos AJAX na aplicação com o RichFaces. O framework utiliza JQuery para fazer os efeitos e manipular do DOM HTML/XHTML, com isso, o conteúdo do framework vai junto com o projeto. A infra-instrutora de um projeto AJAX é repleta de JavaScript e quando projetos se tornam  complexos, conseqüentemente, a complexidades de manter os script se eleva. Com isso, existe uma estrutura de arquivos javascript pronta para suportar a arvore JSF gerada a cada requisição tornando a estrutura pesada ao ponto de ser desvantagem desenvolver a aplicação baseada em requests sobre toda a página.

Destrinchando o conteúdo carregado pelo browser, existe um tipo de arquivo que representa a chamada de sua URL que é respondida a cada requisição, é configurada no web.xml na definição da chamada para a execução do servlet. Nesses arquivos contem o emaranhado do Javascript que o servidor envia a cada requisição. No meu caso, esses arquivos ficaram em torno de 933Kb, é um tamanho considerável quando se trata de requisições. Isso pode deixar sua aplicação uma carroça quando sua aplicação for pro ar.

Nessa situação, a solução para esse problema é aplicar ao máximo os recursos AJAX na aplicação, fazendo com que apenas um trecho da página possa ser renderizada e não todo a cada requisição. Isso diminui bastante o tráfego na rede tornando a aplicação um pouco mais leve. Nas primeiras solicitações a aplicação fica muito lenta, mas quando o conteúdo está no cache o desempenho fica razoável.

Para comprovar, fiz um teste desenvolvendo uma página simples com um CSS pequeno e sem nenhum arquivo JavaScript amais. Fiz as configurações dos pacotes JSF e do RichFaces descritas em seus devidos manuais respectivamente. Fiz com que a primeira página utilizasse um apenas um <a4j:region > contendo alguns componentes, como; <a4j:form> e  um <a4j:commandLink>. Isso é suficiente para habilitar o suporte AJAX do framework, ou seja, carregando todos os JavaScript responsáveis por essa funcionalidade.

Na documentação do framework não existem tópicos que auxiliem a diminuir o tamanho do conteúdo, isso encoraja a utilização massiva dos recursos em todas as páginas e evitando request desnecessários. Não quero dizer que o framework seja ruim, pelo contrário, é uma ótima ferramenta, porém, deve ser utilizada com cuidado. A utilização de AJAX puro é uma excelente opção.

[]s.

Design, Frameworks, Java ajax, Frameworks, javascript, web

Trabalho em uma empresa de tecnologia, especificamente desenvolvendo software, e também trabalho como freelancer nas horas vagas (que no momento são cada vez mais raras). Ganhei conhecimento e experiência participando como desenvolvolvedor,  a vezes como quadjunvante, nos projetos que apareciam, sendo que, a sua maioria eram de projetos WEB e alguns poucos eram de frameworks e desktops. Suas finalidades também eram variadas, desde serviços até websites para vender produtos, porém, uma coisa me deixava muito frustrado, a dificuldade de não saber elaborar uma interface intuitiva e ao mesmo tempo simples, resumindo, tinha inveja (e tenho até hoje) dos designs.

Dediquei meus estudos para conhecer linguagens de programação, frameworks, processos, padrões, boas práticas, ferramentas, etc, mas nunca me dediquei a aprender alguma coisa de design.  Digo que design não significa manipular imagens, HTML, CSS, Photoshop, etc. o termo significa muito mais que isso, significa ter em mente a melhor forma de apresentar um produto, impacto visual, chamar o cliente, ou melhor, possuir o “conhecimento artístico” de como tocar um cliente através da arte.

Vi que isso era de extrema importância depois tentar fazer uma interface, para uma necessidade específica, que iria utilizar em um projeto. Tinha a idéia mais não tinha capacidade para colocar em prática. Frustrado com minhas tentativas em vão, consultei alguns colegas que são web designs e solicitei uma ajuda no que eu estava fazendo. Depois de alguns minutos expondo minhas idéias ele me surpreendeu afirmando que eu não sabia o que eu estava fazendo, ou seja, tinha o problema, mas formulou sua resolução de forma errada.

Quanto mais ele falava mais ficava desapontado, pois realmente, o que eu tinha em mente não tinha bulufas com a solução do problema. Para tentar mostrar melhor, ele desenhou a interface toda na minha frente mostrando o porque de cada elemento contido na tela, achei isso fantástico, além do mais, ganhei a interface de graça e utilizo até hoje no projeto. Analisando isso, me questionei sobre a vantagem de ter designs em empresas que desenvolvem software, seja web ou não.

No ponto em que fui ajudado, todas as regras de negócio já estavam completamente desenvolvidas e testadas para solucionar o problema. Tratando a interface como um item sem importância, vi que estava completamente errado sobre quase tudo que tinha feito. Ou seja, o problema que aconteceu foi que não me preocupei com a apresentação para o cliente. É obvio que, tendo uma interface sem a regra de negócio o sistema não funciona, porém, se tendo a regra de negócio e não tendo uma interface funcional e também intuitiva o fator psicológico entra em cena. Isso é fácil de exemplificar; É só observar o comportamento de uma pessoa que utiliza uma família sistema operacional quase que

a vida toda e força-la  a utilizar um sistema sem sua interface que estava acostumada. Acreditem, já vi isso acontecer e quem se ferra é o setor de suporte.

Bom, voltando ao assunto, é óbvio que a necessidade de ser ter uma equipe de design é importantíssima. A Apple faz disso o seu principal elemento de desenvolvimento de produtos e venda, eles levam a sério o Design Funcional. A Microsoft incorpora o design no seus produtos voltados para usuários comuns e incorpora o design ao produto de forma intuitiva que ajuda o departamento de vendas a fazer o seu papel de forma agressiva.

Descrevi minha experiência frustrante de tentar fazer um trabalho de design sem o conhecimento adequado para isso. Respeito muito o trabalho desses caras porque, sem eles a web (WWW) não era um elemento tão atrativo como é hoje, e o marketing não seria são eficiente como é hoje.

[]s

Design, Off-Toppic Design

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

A obra do GoF foi magnífica para o cenário atual da computação, especificamente a área de desenvolvimento de software, pois, trouxe um conjunto de informações organizado e catalogado por responsabilidades que visam a solução de um problema específico. Os problemas foram descritos brevemente com o objetivo de acoplar um padrão de projeto conforme a necessidade que era descrita, dessa forma, tornando a leitura fácil e clara.

Porém, utilizar padrões sem conhecer a real realidade do problema, ou até mesmo utiliza-lo por modismo, pode fazer com que problemas, que geralmente são simples de serem solucionados, tornem-se extremamente complexos transformando o código em um  prato enorme de espaguete.  Utilizar padrões sem experiência pode levar o projeto ao caos, tanto em longo prazo (o mais provável) quanto em curto prazo.

Concentrar na solução do problema é a primeira coisa que deve ser feita, é a atividade mais importante no momento. Devemos esquecer da existência de patterns para concentrarmos no problema a ser solucionado. Após solucionado, poderá ser refatorado para um padrão de projeto específico do tipo de problema que está sendo resolvido. Essa é uma atividade básica para utilizar o padrões de uma forma simples, pois, aplica-lo direto, principalmente se o desenvolvedor for inesperiente, poderá causar uma série de problemas colaterais.

A simplicidade deve ser mantida. Caso seja impossível, ao menos mantenha leitura dos fontes simples e clara.

[]s

Patterns DP, GoF, Patterns

Quando joguei Quake I online pela primeira vez fiquei absolutamente fascinado pela possibilidade de jogar, no mesmo mapa, com uma série de jogadores conectados querendo destruir um a outro. A empolgação com essa novidade foi tanta que o excesso de LAG não era problema. Por conseqüência, as desagradáveis paradas no game eram constantes, seu player morria e você não se quer sabia quem matou você, porém, mesmo com esses problemas não deixava de continuar jogando. A verdade é que os desenvolvedores do título se preocuparam apenas com o movimento que era feito de um poto X para um Y e transmitir as coordenada via broadcast para outros players. Diga-se de passagem que esse foi o primeiro títulos (ou um dos primeiros) desenvolvidos com a possibilidade de travar batalhas pela Internet.

O idealizador disso tudo foi nada menos do que John Carmak, fundados da ID Sofware que anteriormente colocou no mercado títulos de sucesso como Wolfenstein e Doom (títulos que alavancaram o estilo de “jogos de primeira pessoa”). Carmak, como desenvolvedor talentoso, evoluiu a modalidade com o desenvolvimento da engine 3D para seus títulos e posteriormente o protocolo multiplayer que começou a vir a partir dos títulos posteriores.

Carmak foi um gênio ao desenvolver e evoluir a engine dos primeiros jogos de primeira pessoa para o cenário que conhecemos hoje. Méritos para também para o desenvolvimento e evolução do protocolo de jogo. Fazendo com que o mesmo ficasse cada vez mais limpo e refinado, tanto que, na maioria das vezes a animação era mantida quando havia muito lag. Os problemas surgiram quando havia muitos jogadores no mesmo mapa, nesse ponto tínhamos a latência da rede e do processador para processar os movimentos de tantos jogadores. Uma curiosidade foi o fato de ter desenvolvido seus primeiros títulos iniciais sobre um NeXT em um NeXTSTEP OS e posteriormente ter migrado para a plataforma Windows.

Os títulos da ID ficaram famosos juntamente com o estilo de jogos muiltiplayer de primeira pessoa. Fabricantes desenvolveram seus títulos que também tinha o mesmo esquema de combate e, diga-se de passagem, utilizavam a mesma engine para seus jogos de primeria pessoa (a engine é um assunto para o próximo blog).

Ao desenvolver o título de maior sucesso, o Quake III, que foi, em minha opinião, o melhor título, engine e protocolo, possibilitou com que os combates fossem cada vez mais divertido e fáceis de jogar.  Essa “leveza” nos jogos muitiplayer tornou famoso, não só a engine, mas também o protocolo de comunicação que era bem mais evoluído. A forma de jogo é simples, mapas são abertos e ao mesmo tempo bem limitados, ou seja, não são tão extensos como os títulos anteriores já que a finalidade era apenas batalhas multiplayer.

Escrevi esse post não apenas por gostar dos títulos da ID (mesmo sem lança nada após o Quake 4 e o Doom 3), mas especificamente pelo protocolo de comunicação muitiplayer da ID. O melhor de tudo é que a ID Software disponibilizou toda engine e protocolo do Quake III na área de download da ID Software como GPL. Portanto, o próximo passo é fazer compilar os fontes e estudar os fontes do protocolo.

A leitura dos fontes não é tão complexa, acredito que me ajude em melhorar meus protocolos desenvolvidos para P2P. No site a engine está configurada para abrir no Visual C++ da Microsoft e abriu perfeitamente no meu Visual Studio 2008 após pedir para remover os arquivos do Source Safe. Pra quem gosta essa é uma excelente oportunidade. Estarei postando futuramente sobre os trabalhos futuros.

P2P - Peer to Peer, games game, quake

Quando uma empresa investe tempo e mão de obra para desenvolver algum framework para seu uso próprio, ou até mesmo minimizar a complexidade da utilização de outros, significa que o nível de maturidade em uma determinada tecnologia se elevou ao ponto tornar o processo de desenvolvimento, com o uso dessa tal tecnologia, mais ágil.

Estratégias utilizadas para obter essa flexibilidade variam dês de desenvolver templates, classes abstratas, soluções que utilizam padrões de projetos que visam a reutilização, desenvolver forks de frameworks open source para se adequarem ao modelo de desenvolvimento da empresa. Essas alternativas visam poupar tempo com situações de um cadastro simples, persistência auditada, autenticação, etc.

Estratégias como essas vieram a tona nos tempos do Struts e dos EJBs 2.*, já que era notável a necessidade de eliminar os detalhes de implementação do struts (forms, templates, actions customizadas, autenticação, acesso a recursos de serviços distribuídos, etc). Já os EJBs, mesmo em versões antigas, demonstram robustez, confiabilidade e segurança para as aplicações corporativas. Daí veio os patterns J2EE, XDoclets com a finalidade de integrá-los e diminuir, pelo menos um pouco, o grau de acoplamento entre os serviços.  Com isso, a estratégia de diminuir o tempo de desenvolvimento seria válido devido a complexidade dessas tecnologias e da grande quantidade de arquivos XML necessário para configurá-los.

Essas tecnologias sobreviveram até hoje e ainda recebem manutenção de empresas que as tem como base de seus serviços. É justificável, pois muitos recursos investidos para o aprimoramento dessas ferramentas geralmente são altos e algumas vezes são peças-chave em vários projetos. Na maioria das vezes, principalmente em projetos com particularidades específicas, as soluções desenvolvidas para o mesmo geralmente tornam-se parte do framework da empresa para, caso necessite, ser utilizada em projetos futuros, fazendo o framework “inchar”.

Vendo esses problemas agora vem uma pergunta no ar: Mas porque cargas d’água fizeram essa joça? Porque deixaram isso acontecer? Ninguém previu isso? Eu também queria a resposta para essas perguntas, porém, muitos fatores podem ter ajudado a formar essa bola de neve; falta de experiência da equipe, má vontade, individualismo, falta de visão. Quem já trabalhou ou trabalha em corporações que tem essa mentalidade sabe do que eu estou falando. É nesse ponto que a compreensão dos pilares que a empresa dispõe para o desenvolvimento de seus projetos.

Quando uma empresa estabelece um pilar sua base deve ser rígida. A rigidez significa aceitar a evolução constante do código e ao mesmo tempo das libs, frameworks e JVMs que serão utilizadas futuramente nos projetos da empresa. Caso isso não aconteça, a base do pilar não suportará a evolução do framework podendo até se quebrar. Com isso, os bugs nos projetos que utilizam uma infra-instrutora arcaica vêm a tona. Quem trabalha especificamente com Java deve ter experiência com essa abordagem.

Uma boa equipe, sendo bem gerenciada, desenvolveria um framework que fosse, no mínimo, flexível. De forma que suporta, no mínimo, atualizações de bibliotecas intermediárias assim como atualizações da JVM, já que está sempre em constante evolução e cada momento seu desempenho está sendo sempre incrementado. Acredito que medidas simples tornariam a infra-estrutural de uma empresa evoluindo corretamente e principalmente independente de framework.

Isso é possível de fazer? Sim! Existem provas? Sim e são bem claras. É possível encontrar isso constantemente em projetos open source. M uma simples lida nos changelogs é possível ver a constante atualização de bibliotecas do projeto, substituição de jars e suas adaptações conforme as mudanças. Isso é um pouco trabalhoso porem recompensável, pois a base do pilar fica cada vez mais forte.

A linguagem Java, juntamente com a JVM, está em constante evolução. Desenvolver projetos (ou frameworks) fadados a utilizar uma versão específica da JVM é desperdício de tempo. Projetos como esses dificilmente suportarão a evolução, a longo prazo, de seus elementos fundamentais (JVM e frameworks). As mudanças ficarão restritas apenas a uma versão específica de sua estrutura, portanto caso cresça muito o pilar irá se partir.

[]s

Java Java, jvm

Quem diz isso é o editor chefe da Wired, Chris Anderson, uma das revistas mais prestigiadas de tecnologia. Faz circular idéias controversas sobre novos modelos de negócio online. Em uma breve entrevista com a ISTOÉ sobre seu novo livro, Free o futuro dos preços, afirma que “A internet funciona como força destruidora”.  Analisando a frase não deixa de ser verdade. É só olhar para trás e ver o que o formato MP3 fez com a indústria da música.

Segundo Anderson, a maneira de vender um produto pela web corresponderia a disponibilizar cerca de 90% do produto e cobrar pela utilização dos outros 10%. Seria uma atitude semelhante tomada pelas empresas de software, distribuir um produto e cobrar apenas o suporte. No caso de serviço a visão seria no nível macro, já que é possível mensurar e dividi-lo facilmente em elementos (serviços) free e vendáveis.

É complicado ter em mente esse conceito e olhar para o Second Life e o MySpace como exemplos que não deram certo, ou melhor, não levaram vantagem ao utilizar esse conceito. Não que discorde, mas acredito que as empresas disponibilizam um tipo de serviço e cobram por outro. Um exemplo disso é o Google; o negócio do Google são as buscas e ganham com propaganda.

[]s

Notícias internet, serviços, wired