Blog do Alone

Gosto muito dos editores web, como TINYMCE, YOU e FCKEditor pois conseguem incluir formatação de texto com HTML. Facilitam muito o trabalho dos desenvolvedores para incluir soluções complexas de edição de texto. Essas ferramentas são simples de integrar e fáceis de usar, já que é só incluir os arquivos no diretório do projeto e fazer uma chamada simples na página que queira incrementar um textbox. Porém, nem tudo são flores. O problema começa quando existe uma necessidade de exibir o texto, em HTML, salvo por esses editores em PDF.

Normalmente, para os desenvolvedores JAVA, a primeira opção está na utilização do IReport para desenhar relatórios. Portanto, normalmente é feita o desenho, adaptação do relatório com a engine (itext e ireport) na aplicação e pós isso passando a string (ou consultado diretamente) para ser “montada” com o PDF. Consequentemente, o texto será exibido com as tags de formatação HTML. Bom, como podemos fazer com que o texto, fruto dos editores que utilizam formatação HTML, possa ser exibido de forma adequada e com sua devida formatação?

Existem duas alternativas:

• Caso você utilize uma versão 2.5, ou superior, do IReport, pode marcar a opção Marckup, conforme a figura abaixo. Com isso, todo texto passado será feito um parse para ser exibido apenas o texto com o mínimo de formatação. O problema é que o processador HTML é fraco e não aceita todas as tgs documentadas no W3C.

• Outra solução seria a solução mais trabalhosa; fazer o parse manual com o JTidy.

JTidy é uma biblioteca utilitária para manipulação de arquivos HTML que permite checar sintaxe e a manipulação completa do conteúdo HTML. Com esse utilitário é possível fazer o parse do texto e extraindo o conteúdo passado para o relatório. Porém, caso for necessário utilizar formatação complexa será necessária outra abordagem, já que o conjunto de ferramentas IReport não suporta a formatação completa de documentos HTML. Tomara que os desenvolvedores aprimorem o processador HTML da ferramenta para que possa suportar formatação completa, inclusive o suporte a CSS.

T+

xLDen>pt GoogleC

COM

Java html, ireport, itext, jasperreport, Java, tinymce

Olá pessoal,

Dando continuidade na série MMOGs Sobre P2P, apresentarei aqui mais um protocolo para redes P2P que, seguindo algumas premissas que, pode ser utilizado como protocolo de comunicação de peers participantes de games.

Os Games atuais estão exigindo cada vez mais recursos de hardware para apresentar gráficos com maiores detalhes, velocidade e melhor som. Em conjunto com essas características chave está também a conectividade para ter maior interação do game com outros personagens.

Hoje em dia, a camada de conectividade dos MMOGs é desenvolvida utilizando protocolos de baixo nível, devido ao grande úmero de informação que necessita ser transmitida entre os participantes do game. Esses protocolos são desenvolvidos para funcionar apenas na arquitetura Cliente-Servidor, dessa forma, a latência não vai depender apenas da rede, também dependerá do servidor.

Protocolos de alto nível resolvem muito dos problemas de conectividade, porém possuem limitações de latência na transmissão dos dados para o receptor. A explicação para isso é simples. Muitos desses protocolos utilizam XML como mensagens de comunicação. O JXTA é um desses protocolos.

Devido a essa característica existir também no JXTA o desempenho do protocolo perde desempenho, porém ganha em conectividade e flexibilidade. Isso não apenas por ser um protocolo que troca mensagens baseadas em XML mas, por ter uma estrutura completa, repleta de sub-divisões, interfaces e arquitetura bem definida, tudo isso faz do JXTA, não apenas um protocolo, mas um conjunto de protocolos que pode ser utilizado para solucionar problemas de conectividade entre diversos peers em um ambiente P2P.

O que é JXTA.

JXTA não é apenas um protocolo, e sim um conjunto de protocolos encapsulados e organizados com base em suas atividades de empacotamento de forma independente. Esses protocolos garantem a confiabilidade e o roteamento das mensagens que são direcionadas aos peers e grupos.

Protocolos

O JXTA disponibiliza seis protocolos que podem trabalhar em conjunto para prover descoberta, organização, monitoramento e comunicação entre os peers. Esses protocolos são:

• Peers Resouver Protocol: Consiste de um mecanismo onde os peers podem enviar consultas a rede através de mensagens para obter o conhecimento de alguns recursos existentes na rede. Consistas são direcionadas a todos os grupos ou a um grupo espefífico.
• Peer Discovery Protocol: Consiste de um recurso de publicação e descoberta de recurso utilizando Advertise. Cada recurso disponibilizado por um peer são enviadas advertise para toda a rede com o objetivo de disponibilizar o serviço. Os advertise são documentos XML que contem informações do peer e dos recursos disponibilizados por eles.
• Peer Information Protocol: Mecanismo que os peers obtém status de outros peers.
• Pipe Binding Protocol: Consiste no estabelecimento de um canal virtual de comunicação entre um ou mais peers.
• Endpoint Routing Protocol: É um mecanismo que permite descobrir rotas para enviar mensagens para um determinado peer. É utilizado especificamente para a descoberta de rotas entre peers.
• Rendezvous Protocol: Mecanismo na qual os peers podem (ou não) propagar serviços. Este protocolo permite o envio de informações dos peers ou serviço que estão sendo monitorados pelo peer em questão. É utilizado em conjunto com o Peer Resolver Protocol e o Pipe Binding Protocol para propagar mengagens.

Cada protocolo citado é independente dos demais. Um peer não requer a implementação de todos os protocolos da arquitetura JXTA, apenas implementa os protocolos que são necessários para o seu uso. Para prover um funcionamento padrão de um peer em uma rede JXTA deve apenas implementar dois protocolos; o Peer Resolver Protocol e o Endpoint Routing Protocol. Esses dois protocolos contem as principais funcionalidades que um peer deve ter na rede, já que é exigida na documentação devido a interoperabilidade com o core do JXTA.

Utilização da Arquitetura nos Games

A arquitetura, juntamente com o modelo de implementação dos protocolos, são bem completos. Com isso, o JXTA é o conjunto de protocolos mais completo quando se trata de arquitetura P2P. Porém, para muitos ele é tido como um elefante branco do P2P.

O conjunto de protocolos disponibilizado pela arquitetura é realmente completo, possibilitando um conjunto de ferramentas para o desenvolvimento de soluções que funcionem sobre uma arquitetura de rede P2P. Porém, o conjunto de protocolos utilizado em larga escala com inúmeros peers demonstra algumas falhas imperceptíveis para algumas aplicações porém, cruciais para os games.

Através de alguns testes de performance com vários grupos, inclusive grupos fora de uma intranet, deixaram a desejar em performance a interoperabilidade. Em alguns casos os grupos que se encontravam fora da rede não conseguiam estabilizar a conexão. Em alguns casos, não era possível encontrar recursos em NATs distintas.

Essa afirmação é válida quando utilizamos alguns dos recursos da arquitetura. A implementação de alguns dos recursos são complexos, principalmente o fato de se estar em atrás de um Firewall com uma NAT. Dentro dessa situação, a comunicação nem sempre é boa, sendo necessário horas a mais para solucionar problemas desse cotidiano.

A descoberta de recursos (grupos, peers e serviços) é lenta, principalmente quando testado em uma rede grande como a Internert. Falo isso pensando nos MMOGs que implementarem sua camada de rede P2P utilizando essa arquitetura. De certa forma ficaria inviável a busca por jogadores na rede, podendo chegar ao ponto de ter grupos de jogadores espalhados e não interconectados.

Acredito que a flexibilidade e a grande quantidade de recursos disponibilizados pela ferramenta ainda não dão suporte completo a imensa troca de pacotes nos games. Não quero afirma com isso a total deficiência da arquitetura, pelo contrário, já que o conjunto de protocolos JXTA está na base do mecanismo de cluster do Glassfish. Por sinal, muito bem implementado e funcionando perfeitamente. Talvez um fork da arquitetura visando apenas na otimização da arquitetura para os Games solucionaria o problema.

A arquitetura JXTA encontra-se nesse momento na versão 2.5 e possui um completo conjunto de soluções voltadas para P2P, inclusive pacotes para c++, .Net e uma adaptação para Mobile JME. Com esse leque de opções tão variado, o JXTA é a melhor opção para desenvolver aplicações P2P escaláveis porem, o desenvolvimento de games como camada de comunicação ainda não é uma boa opção devido latência na transmissão de pacotes e pelo, ainda lento, mecanismo de descoberta de recursos.

Fontes: Especificação JXTA e Documentação

JXTA, Java, P2P - Peer to Peer Java, jxta, p2p

Os protocolos de roteamento nas redes P2P são os principais elementos para manter a conectividade entre os nodos. Assim como nas redse TCP/IP, a tarefa dos protocolos consiste principalmente no recebimento e encaminhamento de pacotes e busca de nodos. Porém os protocolos P2P são mais complexos, pois são inúmeras vezes mais abstratos e dinâmicos. Como as redes P2P consistem, na maioria das vezes, de protocolos localizados na camada de aplicação, segundo o modelo de referência OSI, muito de suas características são no momento desconhecidas da maioria dos profissionais da área.

Nesse post, estarei falando sobre o básico do básico de alguns protocolos, que considero os mais interessantes, para que possam ser implementados nas redes P2P.

Chord

O protocolo Chord é baseado no mecanismo de DHT - Distributed Hash Table. Esse protocolo consiste na utilização de chaves para mapear, localizar e remover nodos em uma rede P2P.

Seu funcionamento consiste em mapear os peers conectados a rede através de um código hash que identifica cada elemento. Com esse código, cada peer pode localizar e identificar seus vizinhos através de um emaranhado de peers conectados. A maneira como isso é feita consiste de uma única operação (lookup) que mapeio o endereço IP com o hash gerado.

Os DHTs diferenciam das tabelas tradicionais tabelas hash nos seguintes aspectos;

• Devem suportar a inserção e remoção de nós, pois será necessário atualizar o novo mapeamento dos nós.
• Outra questão é a necessidade de um protocolo de roteamento para que o mapeamento possa ser feito constantemente.

No caso do Chord, o protocolo de roteamento seria descartado para dar lugar ao consistent hashing.

Esse mecanismo mantem o mapeamento das chaves e nodos responsáveis por essas chaves. Com isso, torna-se desnecessário o conhecimento de todos os nós da rede por cada peer. Com isso, a escalabilidade da rede aumenta consideravelmente.

Pastry

O protocolo pastry atribui um identificador de 128 bits, também gerado através de uma função hash, baseada no endereço IP ou em uma chave publica do peer. Esse identificador é utilizado para localizar um nodeIp no universo P2P que consiste no universo de chaves. Com isso, podemos rotear uma mensagem, em uma rede de N nós, em O(log2bN).

O protocolo tem uma característica interessante. Ele roteia mensagens de um nó cujo nodeId esteja mais próximo da chave autorizada. Isto é feito da seguinte forma: a cada etapa do roteamento, um nó normalmente encaminha as mensagens para outro nó cujo nodeId compartilhe com a chave pelo menos um digito (ou b bits) a mais do que é  compartilhado com o nó atual. Se nenhum nó é conhecido, a mensagem é encaminhada para um nó cujo nodeId compartilha um prefixo com a chave e está numericamente mais próximo da chave do que o presente nó. Para suportar este procedimento deroteamento, cada nó mantém uma tabela de roteamento, um conjunto de vizinhanças e um conjunto de folhas.

Tapestry

O tapestry tem uma certa semelhança com o pastry. Entre essas semelhanças estão a utilização do sufixo/prefixo no roteamento. Com isso, quando a tabela de roteamento de um nó não possui não possui uma referência para um nó que não compartilhe o sufixo com a chave a mensagem é encaminhada para um nó numericamente mais próximo da chave do nó em questão.

CAN (Content Addressable Network)

O CAN possui uma abstração maior, podendo ser melhor compreendida, pois é baseada em um plano cartesiano de N dimensões. Esse plano é dinamicamente dividido entre todos os nós de maneira que cada nó possua sua própria zona, como abaixo:

O espaço virtual é usado para armazenar todos os pares (chave, valor) entre os nós participantes da rede. As chaves são mapeadas para um determinado ponto no espaço utilizando a nossa função hash. O par(chave,valor) é então armazenado no nó responsável pela zona onde o ponto se encontra. Quando um nó deseja encontrar o valor correspondente de uma chave, ele deve aplicar a mesma função hash para encontrar o valor correspondente a chave e então encontrar o nó que está procurando. Caso a pesquisa não tenha êxito, a busca é passada a seus vizinhos para que seja feita a busca até encontrar o nó na zona da rede.

Em minha opinião, esse é um protocolo mais adequado para os MMOGs, já que existe a possibilidade de dividir o espaço em zonas, talvez possa ser aplicada a mesma idéia do conceito de mundos e campos de visão. Mas isso ainda é pesquisa.

Referências

Utilizei algumas referências na elaboração desse texto, pois esses protocolos fazem parte de pesquisas na área de redes e muita coisa está sendo desenvolvida no momento, principalmente sobre a adaptação dos protocolos nos MMOGs.

Utilizei o texto de Carlos Kamienski, Eduardo Souto, João Rocha, Marco Domingues, Arthur Callado, Djamel Sadok, cujo título é; Colaboração na Internet e a Tecnologia Peer-to-Peer, publicado no XXV Congresso da sociedade Brasileira da Computação, e o texto de Guan-Yu Huang1, Shun-Yun Hu2, Jehn-Ruey Jiang3 com o título; Scalable Reputation Management for P2P MMOGs de Department of Computer Science and Information Engineering National Central University, Taiwan.

Nos próximos post s estarei disponibilizando uma visão geral sobre o “elefante branco”, porém o mais completo, do P2P, o JXTA.

Open Source, P2P - Peer to Peer can, chord, jxta, p2p, pastry, tapestry

Fiquei curioso ao ler uma reportagem de uma revista informando sobre a iniciativa do MIT de disponibilizar o conteúdo de seus cursos na Web. O nome do projeto é entitulado de OpenCourses que consiste também da publicação de vídeos e exames sem a necessidade registro ou autenticação.

Passeando pelo tópico de Electrical Engineering and Computer Science, vi uma disciplina um tanto quanto curiosa: 6.370 Robocraft Programming Competition, é um curso de extensão que tem o objetivo de ensinar programação, de forma divertida, através de uma engine de simulação de uma batalha de robôs que são programados pelos alunos. Esse é um dos brinquedos que o pessoal do MIT utiliza nos momentos de lazer.

Software bem parecido com o projeto Robocode, antes patrocinado pela IBM, que oferece um ambiente de desenvolvimento completo para desenvolver o seu tanque e incluir a lógica de batalha. Um projeto interessante tido como auxílio ao ensino de programação. É válido ressaltar que tudo isso é feito com Java.

Simples dica de diversão geek.

Java, Open Source Java, MIT, Programação, Robocode, Robocraft

No post anterior explanei um pouco sobre o mundo dos MMOGs e sobre a visão universal desse tipo de entretenimento  utilizando um  protocolo totalmente descentralizado. Não passei os detalhes, mas apenas analisando o título é perceptível que essa é uma tarefa que requer muita dedicação.

Atualmente os MMOGs, utilizando a arquitetura cliente-servidor, tornou-se um paradigma para a indústria (consumidores assíduos, desenvolvedores, empresas, etc). Praticamente todos os títulos que vão para as lojas tem como base a arquitetura cliente-servidor como mecanismo padrão de interação dos clientes. Como tinha afirmado, essa arquitetura é dispendiosa para as empresas que disponibilizam os acessos aos datacenters para jogadores.

Vendo por esse lado, não seria viável apenas distribuir o game? Bom, verificando o lado da empresa seria viável porém, a empresa perderia receita. Devido a isso, criar a infra-estrutura  de serviço é um passo fundamental, principalmente pelo pouco gasto que teria com infraestrutura.

A utilização do arquitetura P2P veio como um forma de amenizar os gastos com essa com datacenters. Porém, existe alguns obstáculos para a viabilidade dessa afirmação. Esses obstáculos variam de culturais e tecnológicos.

Obstáculos culturais

O elaboração de uma arquitetura descentralizada para a comunicação de hosts diretamente tem início nos primórdios da computação. Porém, houve uma evolução nesse conceito, fazendo que o termo “host” tornasse um elemento abstrato, flexível e virtual chamado peer.

Peer é a definição de um elemento dentro do contexto de uma rede P2P. Um peer pode ser qualquer coisa que se comunique com a rede como;  um pc, notebook, celular, ou seja qualquer dispositivo que tenha conectividade com a rede seja lá o que for. Dentro desse conceito, um pc, por exemplo, pode ter um ou diversos pares na rede P2P. Esse exemplo foi necessário para termos uma idéia de como é a conectividade entre os pares.

Agora, quais são os impactos culturais da sua utilização? A elaboração da arquitetura teve finalidade oposta a fama que teve com a s redes de compartilhamento de arquivos. O problema é que a arquitetura P2P caiu como uma luva para o desenvolvimento dos softwares de compartilhamento de arquivos existente. Gnutell, Kazzaa, Emule, Napster, entre outras, todas utilizam uma implementação (com particularidades) para a sua rede.

Essa, talvez seja a origem, dos problemas de violação dos direitos autorais que as gravadoras, editoras e produtoras de filmes tanto reclamam. As redes de compartilhamento tornaram fontes de troca de arquivos e com isso surgiu a forma mais eficaz da prática da pirataria.

Obstáculos tecnológicos.

A utilização da arquitetura P2P nos protocolos de compartilhamento de arquivos aumentou consideravelmente o tráfego na internet sendo que, hoje em dia, 40% do tráfego da inter vem das redes de compartilhamento de arquivos. Mas foram os poucos que viram as qualidades da arquitetura para os games. A conclusão foi simples; se existem uma enxurrada de bytes trafegando sobre essa arquitetura e cada vez mais tendo usuários adeptos, logo a arquitetura pode ser robusta.

Acredito que seja essa a iniciativa para modificar a camada cliente-servidor dos MMOGs para P2P. Mas para isso, existem atividades de adaptação da tecnologia e em alguns casos a adaptação do motor do game para a nova arquitetura.

Estudos e soluções

O MMOGs considerados mais divertidos são os que possuem mapas imensos e a possibilidade de personalizar o seu jogador. Fazer com que um peer consiga gerenciar elementos como esses, seria necessário possuir praticamente a mesma estrutura, inclusive datacenters, dos servidores para que ocorra a interação dos pares conectados na rede.

Esse é um problema clássico do que pode ocorrer em situações com grande quantidade de jogadores conectados, ou seja, um caos. Para resolver esse problema, ou pelomenos minimiza-lo, seria necessário desenvolver uma estrutura de mundos e submundos tornando o ambiente utilizável e com desempenho desejado. Para isso, seria necessário a construção de um mundo virtual 2D, ou mapa, dividido em células. As células existentes no game seria um peer da rede eleito seguindo critérios.

Esse conceito é bem parecido com o campo de visão de um jogador, ou sejam, se o jogador entrou no meu campo de visão então só a partir daí que o tráfego entre esses dois jogadores poderá surgir.

Bom, uma pergunta vem a tona: Como é feita a sincronização das informações que também não estão na minha área de visão? A necessidade de manter informações de outros jogadores que não estão dentro do “contexto” do jogador é necessário para manter o conjunto de informações do game como um todo. Records, ranck, mercados, guildas, etc. dependem desse tipo de informação. A pergunta em questão está sem resposta no momento mas, existem diversas soluções.

A solução que, a meu ver, mais se adéqua a necessidade seria a utilização de um servidor central para prover esse tipo de informação. Bom, nesse caso a estrutura de game não é mais 100% P2P? É isso aí. Em situações do cotidiano, no caso sem soluções, seria necessário manter a arquitetura cliente-servidor através de um servidor central para realizar a “contabilidade” do game, diminuindo a existência de shits.

O que acompanha as dúvidas da arquitetura nos games é principalmente a suposta facilidade de inclusão dos cheats no game, já que os arquivos de configuração seriam gravados no disco do cliente. Com isso, um desenvolvedor mais experiente poderia fazer engenharia reversa nos executáveis, verificar os arquivos que o game carrega e modifica-los conforme desejar. Porém, para que isso não aconteça, o game deve implementar inúmeras políticas de segurança como : criptografia, certificados digitais e principalmente implementar uma forma mais adequada a realidade atual, caso a empresa deseje faturar com o serviço do game.

O desafio para desenvolver a arquitetura nos MMOGs é grande. Tão grande também são as dúvidas referente ao aceite dos jogadores dessa tecnologia nos games, já que a arquitetura cliente-servidor é o padrão para esse tipo de game. Acredito que o principal desafio será encontrar a derivação do protocolo mais adequado para suportar o montante de informação referente a interação dos jogadores no game. Portanto, no próximo post detalharei alguns protocolos P2P e frameworks que mais se adequam a  essa finalidade.

T+ []s

games mmog, p2p

O entretenimento eletrônico tornou-se um segmento econômico forte onde empresas de renome também querem se alojar nessa fatia de mercado que cada vez mais cresce. Empresas como Microsoft e Sony disputam a liderança do mercado através de seus consoles de ultima geração e com títulos cada vez mais empolgantes que enchem os olhos dos games maníacos que ficam vidrados com gráficos cada vez mais realistas e com som de primeira qualidade. Sem falar do banho da interatividade que a Nintendo disponibilizou no seu novo console que faz com que o “entretenimento familiar” fosse o ponto principal da estratégia de marketing da gigante dos games.

A iteratividade nos jogos eletrônicos pode ser considerada como elemento fundamental para o sucesso de um game, principalmente quando essa iteratividade também envolva inúmeros jogadores, coisa que torna possível com o a utilização da internet para essa finalidade. Títulos que utilizam a rede como alternativa para a interatividade de jogadores são considerados completos e divertidos pelos consumidores. Dês de 1998 temos os sucessos da ID Software como Quake (I,II,III,IV) em conjunto com a Epic Games com a séria Unreal e a modificação mais famosa do mundo, o Counter Strike, levou esse gênero a inúmeros PCs no mundo.

O enredo adventure, strategy e RPG não podia ter ficado de fora. Levando pelas características do estilo como a existência de mundos, raças, povos, mapas imensos e colaboração, houve a necessidade de criar um ambiente que também suportasse as características do estilo através da rede, uma coisa semelhante a um RPG Online. Tudo isso, de forma com que o universo que precede o jogo fosse livre para exploração, interação, organização, ou seja, o mais parecido com o mundo real. Acredito que dessa forma surgiu o termo “massivo” (o primeiro M de MMOG).

Pra quem não sabe, MMOG significa Massively Multiplayer Online Game, o termo não tem uma tradução, mas por alto significa Jogos Online para Múltiplos Jogadores.  A demanda pelo gênero cresceu de forma absurda, consequentemente foi necessário uma grande infraestrutura para suportar inúmeros jogadores online, o acesso aos servidores dos jogos começou a ser cobrado para cobrir as despesas, patchs e mais patchs de atualização foram necessários para evitar os hacks nos jogos (trapaças). Foi dessa forma que grandes investidores descobriram um modelo de negócio sustentável e que desse lucro rápido.

Grandes empresas investiram pesado nesse novo modelo para tentar vender não apenas títulos, mas também uma forma de mensalidade para acessar os servidores da fabricante. Coisa que aconteceu com World of Warcraft. Muitos conseguiram criar servidores de forma ilegal, mas os melhores serviços são sempre os disponibilizados pela fabricante ou autorizados, pois não tem muitos bugs e são mais seguros (livres de trapaças).

Como já tinha dito, esse tipo de entretenimento tem mercado e o retorno é de médio a pequeno e médio prazo, porém, o investimento em infraestrutura de servidores é imensa. Um exemplo disso foi a empresa brasileira, desenvolvedora de jogos,  Hoplon, cujo principal título é o Taikodom. O game está sendo distribuído de graça, até o momento, e devido essa estratégia foi necessário criar uma grande infraestrutura de servidores que suportasse a massa de jogadores interagindo ao mesmo instante. Essa necessidade resultou da parceria com a gigante IBM trazendo mainframes para que, até o momento, suportasse os primeiros jogadores do título.

A necessidade de imensas estruturas para manter jogadores interagindo é extremamente cara, ainda por cima, não é novidade as grandes empresas desenvolvedoras dessa modalidade de game cobrar mensalidades para usufruírem do acesso ao ambiente. Muitos concordam e outros discordam, mas seria bom se a banda larga brasileira fosse de qualidade e o mesmo fosse com o serviço, sendo assim poderíamos apenas opinar. Conheço pessoas que são adeptas ao World of Warcraft, jogam horas e horas, que reclamam um absurdo da qualidade do serviço prestada no acesso aos servidores da Blizzard.

Vendo o grande gasto com infraestrutura para manter MMOGS em funcionamento, pesquisadores e empresas do ramo viram uma alternativa nos protocolos P2P como uma forma de tentar minimizar, ou até mesmo tirar, o gasto em serviços, passando toda a responsabilidade para o cliente seguindo uma série de regras que envolvem desempenho como objetivo de minimizar ao máximo os recursos computacionais utilizados pelo cliente.

Vendo por outro lado, o protocolo P2P seria uma alternativa viável para tal. Podemos ver aplicações que rodam com sucesso sobre esse protocolo, não só sistemas de compartilhamento (na qual é mais conhecido devido as redes de compartilhamento) mas também software mensageiros como MSN e SKYPE. Aplicações como essas necessitam apenas da autenticação com um servidor do mesmo segmento e o resto é tudo feito pela aplicação cliente, ou seja, a transmissão de mensagens, compartilhamento de arquivos e até mesmo a transmissão de voz (se o software suportar) é feita apenas pelos atores que estão participando da troca de informações no momento.

Idéia como essa manteve acesa a necessidade das empresas do ramo investir em pesquisa na arquitetura P2P para que possa tornar vantajosa sendo segura, simples, robusta e que atenda ao máximo os usuários adeptos dos títulos. Com isso, toda a responsabilidade de interação, transmissão e desempenho ficaria sobre os recursos do cliente na qual o titulo está sendo jogado.

Bom, mas que vantagem o cliente teria se toda essa carga estaria sobre o cliente?Essa deve ser a pergunta que você deve estar fazendo. Até o momento a vantagem está praticamente TODA para a empresa desenvolvedora do título que não terá que investir em uma infraestrutura de servidores. A carga fica toda como cliente sim. Para isso, existem pesquisas feitas sobre o conjunto de protocolo que envolve a sigla P2P para que essa carga se torne a mínima possível e que seja irrelevante  para o cliente. Ao mesmo tempo, existem pesquisas feitas na utilização do esquema de mundos virtuais, onde cada usuário tem o seu mundo e o tráfego do serviço fica ativo apenas aos jogadores que participarem do seu mundo. Mas isso é assunto para o próximo post, onde darei mais detalhes sobre esse mundo empolgante dos MMOGs.

Isso é apenas uma pequena introdução sobre o que pode acontecer no mundo dos MMOGs, especificamente na camada de comunicação, e o que pode vir daqui pra frente nos games. Pesquisas financiadas por softwarehouse e renome para desenvolverem uma plataforma utilizável que funcione com alguma implementação P2P para que alguns títulos possam ser desenvolvidos para testar a plataforma. No próximo post falarei um pouco sobre os tipos de protocolos P2P.

P2P - Peer to Peer, games games, mmog, p2p, r&d

Olá pessoal..

Vi que muitas pessoas postaram em seus blogs resenhas e opiniões (muitas positivas) em seus blogs sobre o livro. Mas o que falarei aqui será sobre minha surpresa em observar a ligação entre conhecimento em outras áreas e a geração de idéias com bases em conceitos distintos obtidos em mundos recém conhecidos.

Uma vez passeando próximo a uma livraria, vi um livro que eu estava procurando a bastante tempo, na mesma hora entrei na livraria e comprei. Sempre tive simpatia pelos belos produtos desenvolvidos pela Apple, coisa que me levou a admirar e a respeitar as pessoas que estão por trás dessa grande empresa e principalmente o CEO. Steve Jobs.  Não é todo dia que um cara que foi praticamente chutado da empresa que fundou e volta das cinzas para com NEXiT, Pixar e por esculhambação entra pela porta da frente na Apple.

Esse fato realmente é uma tremenda vira-volta na vida de qualquer ser-humano e também aqueles que estão ao seu redor. Isso prova que o cara tem realmente uma estrela que só diminuiu a luz temporariamente. As dificuldades vieram a tona e através de um jeito inusitado e excêntrico, ou resumindo, criativo. O fato de ser multidisciplinar e flexível o levou a criar uma série de produtos premiados, com designs inovadores, simples e ao mesmo tempo funcional.

Bom, mas porque eu estou rasgando ceda pra uma pessoa que nem me conhece, por não trabalhar em sua empresa e por não gostar (apesar de funcionar) de suas técnicas motivacionais? O que me chamou atenção ao ler o livro de Leander Kahney foi simplesmente o fato de uma pessoa conhecer eletrônica, circuitos integrados, sistemas operacionais, caligrafia, arte, marketing, design e etc. Mas porque tantas coisas nada em comum? Isso é simples de responder.

Quando eu estava na graduação tive um professor de calculo que me falou o seguinte: “Se seu currículo está repleto de qualificações técnicas, então isso é excelente. Um mérito seu com certeza. Mas faça um curso de culinária, pintura, degustação de vinhos, dança de salão e coloque no seu currículo como atividades extras”. Logicamente quando escutamos isso achamos isso hilário. Mas ao ler esse livro vi que ao designar nosso tempo para atividades extra uma coisa boa pode acontecer. Pode despertar a criatividade com novas descobertas e ao mesmo tempo evitando ficar bitolado apenas com que você conhece, fazendo também aplicar o resultado dessas atividades no seu trabalho.

Isso aconteceu com muitos dos produtos da Apple. É possível encontrar traços das curvas dos BMW nos IPods, iMacs e MacBooks. Resultado das contínuas aulas de caligrafias e budismo onde surgiu a inspiração para Mac OS, Mac OS X e o Leopard. As inúmeras atividades alternativas que Steve Jobs o proporcionou (ou até ajudou muito) ser um cara extremamente criativo, com inúmeras idéias sobre produtos inovadores que vendem como água.

Quando temos o problema extremamente complicado e temos uma única ferramenta para solucioná-lo, pode até dar certo, mas com toda certeza será uma tarefa extremamente complicada. Ao ler o texto de Kahney percebi algo semelhante nesse sentido. Muitos de nós desenvolvedores de uma só linguagem vemos que todos os problemas do mundo, quando o assunto é software, podem ser resolvidos com aquela linguagem que você mais domina. Pode até ser que sim, mas se o problema for de complexidade extrema ou um problema com uma solução ótima abaixo do aceitável, com toda certeza a linguagem não será sua amiga. O que quero afirmar com isso é que problemas de prego não são solucionados apenas com martelos, sempre há uma solução mais apropriada fora do seu ângulo de visão. Então onde podemos encontrar a solução quando temos problemas dessa categoria? A resposta é simples: fora do seu ângulo de visão e alem do seu conhecimento. Tendo um amplo ângulo de visão é provável que elementos criativos venham a tona de forma natural, como um pensamento. Também problemas sejam resolvidos através de analogias.

A analogia, na minha opinião, é uma coisa banal quando adaptada a um segmento distindo. Na ciência da computação a analogia está entre os dois extremos. Um dos pontos positivos é adaptar conceitos se segmentos de um ambiente distinto, porém compatível, com em uma área paralela, porém distante.  Viajei um pouco nessa frase, mas se observar-mos essa idéia com carinho com certeza fará sentido. Vamos pegar um exemplo do nosso mundo: A engenharia é uma ciência que está presente na sociedade a séculos. A informática é uma ciência recente que alavancou nos anos 70, lógico que teve sempre em sua base a engenharia. Mas, o pior de tudo é emprestar o nome de “engenharia” para a disciplina de desenvolvimento de software. Isso tira toda a particularidade e dinamismo que está nos pilares da construção de software para uma analogia equivocada.

Tirando toda essa falta de criatividade que nos acompanha desde o início da nossa vida profissional, temos que ficar atentos para que o mundo dos paradigmas não nos perturbe, para que possamos expor nossas opiniões e principalmente fazer com que sejam aceitas sem a necessidade de quebrar a grande barreira que domina a mente humana dês do início dos tempos: a hipocrisia. É de se admirar que a maioria das produções inovadoras não venha de universidades e sim de empresas (texto de Vitor Pamplona). Isso pode ser explicado pele excesso de ego, burocracia e ao mesmo tempo a hipocrisia.

O tempo fez com que nossos pensamentos se concentrassem em uma determinada faixa de conhecimento. Abrir portas para outras áreas de conhecimento podem fazer de nós melhores pensadores e solucionadores de problemas utilizando ferramentas inovadoras e eficientes.

Off-Toppic apple, jobs, mac

Pode ser apenas especulação porém, acredito que seja uma boa para a SUN já que encontra-se em dificuldade de manter seus principais produtos: Solaris, Java e MySQL. Segue o LINK

[]s

Notícias Java, MySQL, Oracle, Solaris, SUN

Nunca pensei que uma vez na vida iria escutar Screeeeeeam for me Manaus. Sim, isso mesmo a donzela esteve aqui e fez muito barulho. Depois de um tempão sem adicional algum coisa aqui, não podia deixar de registrar uma coisa especial dessa, mesmo sendo um blog de tecnologia.

Abaixo vão algumas fotos do whow Maiden em Manaus, com direito a Ed Force One e tudo. Queria ter visto a cara dos controladores do SIPAM quando viram no radar o voo EDFI666…

[]s

Off-Toppic Iron Maiden, Manaus

Olá pessoal ..

Depois de umas férias merecidas, porque ninguém é de ferro, volto a tona para atualizar esse blog cheio de teias de aranhas.

Em primeiro lugar quero parabenizar o pessoal de Alagoas, especificamente de Maceió, por ter nos recebido de braços abertos e com sorriso estampado na face. Em segundo plano quero comentar a forma com que esse está caminhando.

Eita… que saudades …

Bom, vamos ao que interessa…. Li um post escrito por Vitor Pamplona na qual faz criticas acirrada sobre a forma de escrita de alguns blogs que se destinam a conteúdos da área de desenvolvimento de software (buzzwords, Liguagens, Plataformas, Comunidades, etc) não especificando a finalidade do blog em questão.  De certo modo, existe diversas questões a serem analisadas: Uma delas é o nível de conhecimento  e ao mesmo tempo a experiência do autor. Através desse ponto é possível ter, no mínimo, uma idéia do que sairá daí.

Concordo com o fato da experiência não ser um fator fundamental de aprendizado, mas é um ponto fundamental para um blog de tecnologia que necessita ter audiência. A experiência diz muito sobre o autor, em minha opinião, pesa mais do que uma certificação, títulos e premiações, mesmo sendo uma faca de dois gumes.

A escrita que utilizamos em blogs, na maioria das vezes, é totalmente livre de formalidades, pelo fato de tentar disponibilizar conteúdo para todo e qualquer tipo de pessoa. O fato de reclamar do estilo de escrita vai depender muito da finalidade na qual o blog foi criado. Um blog científico logicamente vai disponibilizar um conteúdo mais específico e com uma linguagem mais formal. Porém, um blog que se destina a fazer auto-propaganda vai disponibilizar um conteúdo mais despojado, voltado para um público mais variado. Não critico o fato de mudar a finalidade ou o estilo de escrita, mas sim a crítica feita de forma desnecessária para tal finalidade.

Tentar achar um meio termo para disponibilizar um conteúdo específico de forma didática, disponibilizando em uma linguagem compreensível para leigos e ocultando o mínimo de detalhes é o estado da arte. São poucos os que conseguem fazer isso, porém, a definição de níveis de escrita é relevante. Isso tudo dependerá do tema e da categoria do POST.

Os blogs deixaram de ser moda e viraram utilidade, tanto para diversão quanto para trabalho. Hoje é possível encontrar inúmeros blogs criados para diversas finalidades, porém, a sua utilização ainda é mal vista entre muitos da comunidade científica. A publicação de artigos através de blogs torna-se um conteúdo duvidoso para referencias de trabalhos científicos. Talvez isso aconteça pela falta de utilização da ferramenta ou até por barreiras de paradigmas, já que a comunidade científica é muito cuidadosa com os trabalhos publicados.

Uma solução para isso foi a criação desse “anel de blogs científicos“. Realmente foi uma idéia muito boa, mas sempre existirá aquele excelente trabalho autônomo publicado que não está no nesse anel de blogs, será que esse trabalho vai ter o devido valor. Categorizar é uma excelente alternativa, mas tentar restringir qualitativamente trabalhos conteúdos de outras pessoas é realmente uma decisão repleta de questionamentos e na minha opinião não é viável.

Existem inúmeros trabalhos científicos sendo publicados através de blogs, não apenas comentários, novidades, buzzwords, e outras coisas, mas sim trabalho científico mesmo. O blog virou uma alternativa, uma forma de dizer para todos a sua opinião, mostrar o que vocês estão fazendo.

No contexto atual, mm blog é uma ferramenta de extrema importância. Segundo Freedman, estamos vivendo um grande momento, a chamada era do Upload. É o momento de disponibilizar conteúdo, protestar, poder fazer com que os outros o leiam, ter a oportunidade de ser lido, ouvido ao assistido e ainda por cima ganhar dinheiro com isso tudo.  Porém, ser formadores de conhecimento através de blogs é uma alternativa um pouco arriscada, já que pode ser comparada como um trabalho científico com referências da WikiPedia, ou seja, referencia não confiável.

Off-Toppic Blog, Ciência, Conhecimento