Participei de projetos onde precisava-mos fazer constantes deploys a cada instante, inclusive no servidor de integração contínua que rodava constantemente. Para isso, utiliza-mos a task contida nas libs do apache que permitia fazer deploys remotos no apache através da interface de administração do servidor. Com isso, criamos targets que utilizava essa task para efetuar. Não é complicado, ao contrário, é muito simples, apenas precisa configurar o ligin, password e o caminho da aplicação. Segue abaixo um exemplo.

<property value="CAMINHO_DO_TOMCAT" />

<fileset id="tomcat.lib" dir="${tomcat.home}/lib">
    <include name="**/*.jar" />
</fileset>

<path id="path.lib">
     <fileset refid="tomcat.lib" />
</path>

<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask" classpathref="path.lib"/>

<target name="deploy-tomcat" depends="war">
      <echo message="Deploying application"/>
<deploy url="http://localhost:8080/manager"
            username="LOGIN_ADMIN"
            password="SENHA_ADMIN"
            path="/APP"
            war="file:${dir.build}/APP.war"
            update="true"/>
</target>

Tudo funcionou perfeitamente mas, o serviço oferecido por essas operadoras (que não vou citar nome porque são todas) é precário para a região norte. A banda que disponibilizam é até razoável pelo preço (500 kbps e 1mb) nas a qualidade é uma porcaria. Para se ter ideia, fiz uma ligação via slype para uma pessoa da mesma cidade e foi um transtorno. A perda de pacotes era tanta que foi impossível ter uma conversa descente.

Em fim, a empresa, na qual era cliente, cobriu a área que moro e imediatamente solicitei troca de endereço. No momento, não estou contente com o serviço mas, apesar do link ser bem baixo, estou menos descontente do que estava quando era cliente dos serviços 3G da operadora.

No momento, o Brasil todo sofre com qualidade de serviços precários quando se trata de internet, principalmente no norte do Brasil onde é uma área isolada e de acesso bem limitado. Estamos torcendo para que a infraestrutura de rede que vem da Venezuela possa suprir a grande demanda por acesso a rede e por um pouco de concorrência no mercado.

Resumindo os fatos.

Após instalar os módulos necessários, usb_modemswitch e o usbserial, o modem aparecia no resultado do comando lsmod mas não aparecia como driver de dispositivo, só funcionava quando iniciava o pc com o modem espetado na USB, uma forma bastante deselegante. Tentei de várias formas de solucionar esse problema, li diversos tutoriais e mesmo assim não conseguia fazer o modem subir aós o pc ligado.

Solução.

Ao executar o comado usb_modemswitsh verifiquei que faltava um arquivo de configuração para executar o comendo com sucesso. Li o manual do programa e encontrei onde esse arquivo de configuração é armazenado. Lá são armazenados inúmeros arquivos contendo configurações para diversos modens de vários fabricantes. Veio a dúvida; como eu vou encontrar o meu nessa lista de arquivos? Lembrei do resultado do comando lsusb. Lá tinha a descrição do modem e um número que que era o mesmo de um arquivo que estava lá.


Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 004: ID 12d1:1446 Huawei Technologies Co., Ltd.

Bus 001 Device 002: ID 04f2:b008 Chicony Electronics Co., Ltd USB 2.0 Camera

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Com isso foi moleza fazer funcionar esse cara. Era só digitar o comando sudo usb_modemswitch -c /etc/usb_modeswitch.d/resultado_do_comando_lsusb, ele vai tentar encontrar o seu modem como descrito no arquivo de configuração e pronto. Após isso ele vai aparecer como um dispositivo de I/O e aós isso é só wxecutar o seu wvdial de acordo com suas configurações. Ex:


sudo usb_modeswitch -c /etc/usb_modeswitch.d/12d1\:1446

Inicia o processo de identificação do modem e montagem automática do modem. E depois:

sudo wvdial vivo


Pronto. Modem montado e conectado na internet via interface 3G. Para ser mais específico, meu modem é um Huawei E1756 e minha operadora é a VIVO.

[]s

Esse link mostra o potencial da tecnologia nos browsers mais atuais que suportam HTML5. Vale a pena conferir e formar sua opinião.

Mais uma vez o link AQUI

[]s.

]]> http://www.nelsonalone.com.br/2010/04/02/html5-demonstracoes-e-exemplos/feed/ 0 http://www.nelsonalone.com.br/2010/04/02/modens-3g-suporte-mediocre-para-linux/ http://www.nelsonalone.com.br/2010/04/02/modens-3g-suporte-mediocre-para-linux/#comments Fri, 02 Apr 2010 02:21:55 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=432 Muito tempo sem postar, é verdade. Mas estou voltando a postas, não com tanta frequência.

Recentemente, comecei a utilizar o Ubuntu 9.10 por necessidade, principalmente para usufruir das facilidades do Shell devido a alguns aplicativos que iria desenvolver. Utilizei Linux durante um bom tempo, especificamente o Slackeare 9.0, e hoje me deparei com um Linux extremamente amigável e fácil de utilizar, foi empolgação de primeira. Copiz melhorado, som funcionando com o chaveador de fones de ouvido, suporte e Wifi, etc, etc e etc. Porém, tive uma decepção, não com o sistema operacional, mas com os desenvolvedores de drives dos modens 3G, simplesmente o suporte a Linux é deprimente.

Para fazer com que o modem funcione nem sempre chega a ser trivial, principalmente quando o software de discagem não te dá alternativas de edição de DNS (já que queria utilizar os DNS do google 8.8.8.8 e 8.8.4.4), a cada nova conexão o endereço mudava. Para navegar na internet era necessário clicar no ícone do navegador que fica no software, só então o software disponibilizava o acesso. Lógico que isso não é conveniente pra ninguém, para ser mais comodo, resolvi baixar e configurar o wvdial como discador para modem adicionando as configurações extras. Um detalhe, o modelo do modem é o Huawei E1756, talves não funcione em outros modens. Após toda essa dor de cabeça, resolvi desinstalar o software discador que veio com o modem e utilizar o wvdial.

Pensando que tinha resolvido tudo, me daparo com mais um problema; a única forma de fazer o modem funcionar era espetando o mesmo na usb anter de carregar o sistmea, só assim que ele era reconhecido. O pior que ainda não resolvi o problema e não consigo nem montar o dispositivo como storage. Fiz de tudo, carreguei os módulos, tentei montar pelos dispositivos /dev (tendo como base o comando lsusb), e não consegui. Em fim, o suporte para sistemas “Não Microsoft” continuam escassos, já que, os usuários Apple também tem diversos problemas.

Dessa vez postei uma solução incompleta, já que, estou meio inferrujado com Linux, por enquanto estou na readaptação. Esse post serviu mais como um pedido de dica do que uma solução, quem tiver podem comentar. Estou cassando diversos tutoriais para solucionar esse problema e caso solucione, estarei postando.

[]s

]]> http://www.nelsonalone.com.br/2010/04/02/modens-3g-suporte-mediocre-para-linux/feed/ 0 http://www.nelsonalone.com.br/2010/01/28/problemas-com-modens-huawey-3g/ http://www.nelsonalone.com.br/2010/01/28/problemas-com-modens-huawey-3g/#comments Thu, 28 Jan 2010 11:00:49 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=424 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

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.

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

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

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