Blog do Alone

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