Archive for 'Desenvolvimento'
Webkit no maemo
Posted on June 14, 2008, under Desenvolvimento, N800, Uncategorized.
No projeto que começamos no fisl, o odfmobile, optamos por utilizar a engine Gecko do projeto Mozilla, para trabalhar a exibição dos documentos. O uso desta se deu através da biblioteca gtkmozembed para python.
A opção de usar o gtkmozembed foi mais por questão de tempo, e por consequência, disponibilidade da api, já integrada ao python. Mas depois de um tempo pesquisando sobre o desenvolvimento para plataforma maemo acabei esbarrando neste post. Lendo isso e tirando como base o navegador do N800 e do iPhone, fiquei me perguntando se o Webkit não seria uma opção melhor ao Gecko.
Para ter uma ideia do que seria melhor, resolvi baixar e compilar o Webkit para o maemo e ver no que dava. Então vamos aos passos para testar o Webkit no maemo, vou considerar que você já saiba com ter SDK do maemo em sua máquina e que esteja familiarizado com o mesmo.
Instale o m4:
> apt-get install m4
Depois baixe e instale os seguintes pacotes no seu scratchbox:
- http://www.atoker.com/webkit-maemo/flex_2.5.33-12_armel.deb
- http://www.atoker.com/webkit-maemo/gperf_3.0.3-1_armel.deb
- http://www.atoker.com/webkit-maemo/libicu36_3.6-2_armel.deb
- http://www.atoker.com/webkit-maemo/libicu36-dev_3.6-2_armel.deb
Existe duas maneiras de obter o Webkit, e elas estão descritas neste link.
Uma vez que tenha obtido o WebKit, rode o comandos:
> CPPFLAGS="-DMOBILE=1" ./autogen.sh --prefix=/opt/webkit --enable-video --disable-xslt --with-hildon
> make && make install
Ele deve criar uma pasta em /opt/webkit, para testar se deu certo a nossa instalação, vamos compilar um simples navegador feito em C.
> wget http://www.atoker.com/webkit-maemo/hildon-browser.c
> PKG_CONFIG_PATH=/opt/webkit/lib/pkgconfig:$PKG_CONFIG_PATH gcc -o hbrowser hildon-browser.c `pkg-config gtk+-2.0 hildon-1 webkit-1.0 --cflags --libs` -Wall
Uma vez feito isso podemos transferir os arquivos para o dispositivo e testar, copie a pasta /opt/webkit para o /opt do seu dispositivo, depois copie o hbrowser para onde desejar. Antes de testar instale a biblioteca: libicu36_3.6-2_armel.deb, que já foi citada acima, no seu dispositivo.
Para rodar o hbrowser faça:
> LD_LIBRARY_PATH=/opt/webkit/lib:$LD_LIBRARY_PATH run-standalone.sh ./hbrowser
Nenhuma das tarefas a cima são triviais, mas isso são apenas os primeiros testes, partindo do principio de que funciona, posso fazer mais testes sobre a performance e estabilidade de Webkit no maemo.
Aguardem em breve mais novidades!!
Passenger versos Thin
Posted on June 9, 2008, under Desenvolvimento, Passenger, Ruby/Rails.
Depois ler sobre o Passenger varias vezes no site do Akita, e utilizar ele na minha maquina para o desenvolvimento da aplicação de e-commerce, resolvi fazer alguns benchmarks e vê como ele se saia comparado ao thin.
Os testes a seguir foram executados com a aplicação em environment production, eles caem consideravelmente quando em development:
No / do site:
Thin (MRI) - Produção: 3.68 [#/sec] (mean)
Thin (Ruby Enterprise): 6.72 [#/sec] (mean)
Passenger (Ruby Enterprise): 2.64 [#/sec] (mean)
Em uma página secundaria de produto:
Thin (MRI): 19.11 [#/sec] (mean)
Thin (Ruby Enterprise): 36.49 [#/sec] (mean)
Passenger (Ruby Enterprise) : 5.53 [#/sec] (mean)
Com esses testes descobri algumas coisas:
- Que minha aplicação esta incrivelmente lenta, 6.77 (o melhor resultado) é inaceitável, preciso melhorar muita coisa para chegar onde preciso.
- O Passenger, pelo menos por hora, só compensa no ambiente de desenvolvimento, pois evita ter que ficar levantando processo para testar as aplicações. obs: isto é para a minha aplicação, para sua pode ser completamente diferente.
- Vou trocar o ruby do servidor de produção pela versão “Enterprise”, os resultados são sem duvida motivadores, a diferença no caso da página de produtos foi gritante.
O resultado não quer dizer absolutamente nada sobre o Passenger, se é ou não mais rápido para todos os casos, isto pode, e vai variar muito de aplicação para aplicação, principalmente no meu caso onde a aplicação ainda não passou por nenhum refatoramento nem um analise profunda de performance.
Além dos testes com a página inicial e com a página de produto, fiz um teste com arquivo estático, uma imagem para ser mais preciso, e deixo um aviso os mais eufóricos, o Passenger, sem a correta configuração pode ser um problema com os arquivos estáticos. A questão esta no fato de que apenas a configuração básica da aplicação no apache faz com que o arquivos estáticos sejam servidos através do ruby o que da um perda de desempenho em responder a esse tipo de arquivo violenta, o certo e fazer como é descrito na tópico 5.3.3 do manual do Passenger.
Pelo menos no meu caso a melhor maneira de servir arquivos estáticos tem sido a configuração do Apache para não passar a requisição das pastas estáticas para os cluster thin. Usando a opção “ProxyPass /images !” o Apache não envia a requisição dos arquivos no caminho /images para o cluster, o que evita processamento dos arquivos pelo ruby.
Meu grande problema agora vai ser refatorar aplicação, fiquei decepcionado em saber que do jeito que esta, estou com uma média de 3.68 [#/sec], isso é muito baixo, e depois do lançamento oficial dos sites pode ser um grande problema 
Asset Packger e o problema com pontos
Posted on June 9, 2008, under Desenvolvimento, Ruby/Rails.
Como disse no post anterior estamos trabalhando o jQuery e Asset Packger. So que existe um pequena incompatibilidade entre esses dois.
O Asset Packer tem um pequeno bug que dificulta na hora de trabalhar com arquivos javascript ou css que tenham ponto no nome, como em Jquery-1.2.3.js. O que acontece e que ele usa a função File.extname, que busca pela extensão de um arquivo dado seu nome completo. Então quando você insere no arquivo de configuração do Asset como: jquery-1.2.3, ele interpreta que a extensão desse arquivo já foi digita, e que ela é .3, inserido o arquivo com o nome errado no cabeçalho da página.
Um solução é adicionar o nome completo do arquivo: jquery-1.2.3.js, isso funciona, mas apenas em modo desenvolvimento. O Asset Packger compila todos os arquivos de um grupo em um único arquivo, mas a função que processa os arquivos no helper e no compile são diferentes, sendo que o compile não verifica se já existe um extensão no nome do arquivo, ela apenas julga que é necessário adicionar o .js na hora de incluir os arquivos na compilação.
Para resolver esse problema eu fiz um fork do projeto no Github e corrigi com um pequena modificação.
jQuery e Asset Packager
Posted on June 9, 2008, under Desenvolvimento, Ruby/Rails.
No projeto de e-commerce que estou trabalhando, estávamos com um problema de sobre peso nas páginas, chegando inclusive a 1.4 MB em algumas partes do site.
O principal motivo desse peso todo eram as imagens e banners, como em quase todo site, uma vez resolvido este problema também tivemos problemas com a biblioteca de Javascript: o Prototype. Que o Prototype é gordinho, quase todo mundo já sabe, a questão era como resolver isso. A resposta veio com o jQuery, uma biblioteca Javascript infinitamente superior tanto em recursos como no fato de oferecer versões compactas das bibliotecas que a constitui.
Antes de tentar o jQuery, experimentei usar algumas ferramentas de “compactação” para Javascript, a mais conhecida foi o YUI Compressor, a ferramenta padrão de compressão do projeto Mootools, mas não obtive sucesso, a compactação não funciona com a Prototype, o código final gerado é invalido, e não há muito o que fazer, o problema esta na maneira com que a Prototype foi feita.
Então depois de alguns dias de pesquisa e substituição, consegui achar todos as funcionalidades e bibliotecas equivalentes para o jQuery, uma vez feita a substituição lembrei de plugin que já tinha visto para Rails que podia deixa a coisa ainda melhor.
O Asset Packer é um plugin para auxiliar na utilização de Javascript e Css, com base em um arquivo de configuração pode-se definir pacotes de css ou javascript, da-lhes um nome, e depois incluir esse pacote com apenas um chamada, além disso ele conta com um tarefa rake que permite gerar uma versão compacta dos pacotes.
O grande atrativo do Asset Packer, e que ele inclui o javascript ou css em sua forma descompactada ou compactada de acordo com environment, permitindo ao desenvolvedor trabalhar com os códigos sem compactação durante a fase de desenvolvimento e inserindo as versões compactadas quando em fase de produção. Além destes recursos o Asset Packer ainda trabalha junto ao controle de versão (infelizmente por enquanto apenas com Subversion) e pode ser configurado para gerar as versões compactadas diretamente no servidor, através de configurações junto ao Capistrano.
Arena de programação
Posted on May 21, 2008, under Desenvolvimento, N800, Uncategorized, fisl.
Depois de um mês do fim do fisl 9.0, finalmente sobrou um tempo para falar sobre a Arena de Programação, acompanhado do fato de que o N95, um dos prémios da arena, chegou hoje pela manha 
Para quem não sabe a arena é um evento que acontece dentro do fisl, sendo este o segundo ano de arena, e esperamos que muitos outros ainda venham. O objetivo geral da arena é promover a integração entre os programadores do mundo livre e gerar algum tipo de contribuição com essa integração. No ano passado tivemos uma arena voltada ao projeto Debian, e esse ano ao projeto Gobo Linux e a plataforma de desenvolvimento móvel da Nokia.
Na primeira fase tivemos um processo de seleção com base em patch que deveriam ser feitos para o projeto Gobo Linux, mais informações aqui. Graças ao fato de que o número de inscrições nesse processo foi aquém do esperado, eu pude participar, meus patch foram enviados com 1 semana apenas de antecedência.
Já no primeiro dia de arena a coisa pegou fogo, fomos divididos em grupos de 4 programadores, e cada equipe recebeu um N95, onde constavam uma lista de tarefas a serem executadas com o aparelho usando python. Terminei este dia frustado, tínhamos feito muita coisa, mas nada tinha ficado realmente pronto e funcional, ficamos com um tarefa pronta, e todas as outras semi acabadas. Fui pro hotel cabisbaixo e pronto pra receber a notícia de que não havíamos nos classificado.
Passei uma noite de cão, pois decidi que não ia deixar aqueles códigos besta me vencer, como tinha instalado o emulador da plataforma S60 um domingo antes de ir para o fisl, resolvi que faria o que não consegui fazer durante o dia, obs: isso não contava em nada, fiz porque era um desafio que deveria ser vencido, mas não iria mudar a decisão do dia seguinte.
Na manha de sexta estava lá as 9:00, cansando pra caramba da noite anterior, mas ainda sim tive um tempo pra fazer mais alguns testes e refinar as tarefas que eu tinha feito durante a noite. No fim consegui terminar uma das tarefas e desenrolar uma outra, de um joguinho, mas como o emulador não tem suporte ao acelerómetro, o joguinho ficou só na teoria de que funcionaria.
Qual foi a surpresa de saber que nossa equipe tinha classificado, os códigos que entregamos mesmo na sua maioria incompletos, estavam dentro do esperado, de fato tínhamos feito um bom trabalho. Foi uma grade satisfação saber que todo o trabalho que tinha feito a noite anterior, não tinha sido em vão, ninguém da organização ficou sabendo sobre isso, mas pessoalmente teve um imenso valor.
Eu não sou de forma algum experiente em programação em Python. Eu trabalho com programação a uns 10 anos, mas Python nunca foi o meu forte, mesmo com várias semelhanças com Ruby, que tem sido minha linguagem principal nos últimos meses, o Python era de certa forma um obstáculo.
Mas as 24 horas que passei programado, 12 da quinta feira, e mais 12 da noite que virei programando, com certeza me preparou pra o trabalho que veria em seguida. Então, logo após o anuncio de quais as equipes que tinha se classificado ficamos sabendo que as equipes deveriam se re-arranjar em grupos de três.
Minha equipe mudou e passei a trabalhar com dois programadores de Joeville, nem sabia eu que essa seria a equipe vencedora. Recebemos um N800 e a árdua tarefa de criar um leitor de ODF para o aparelho, usando pymaemo.
A tarefa em si não seria complexa, não fosse o tempo pra programar. Levando em conta que os aparelhos só ficaram disponíveis lá pelas 12h da sexta feira e que teríamos que entregar de volta ás 21h, e que no sábado teríamos mais umas 4 horas para termina o trabalho, ficamos com umas 13 horas de aparelho disponível para trabalhar.
Novamente mais um dia puxado de trabalho, pegando um pouco mais leve, afinal eu estava a mais de 24h sem dormir e com um agravante que quase ninguém sabia, eu passei por um cirurgia de apendicite no final do mês de março, e ainda não estava completamente recuperando, inclusive tendo que trocar curativos.
Mais um dia se foi e muito trabalho ainda tinha que ser feito, uma vez definido o caminho que queríamos seguir o trabalho estava nos trilhos, mas ainda longe de ser concluído. Novamente fui para casa e para mais algumas horas de trabalho noturno, cheguei no hotel tomei um banho e dei um tempo comendo uma parmejiana com amigos no Copão. De volta ao hotel passei mais uma noite em claro estudando pra o dia seguinte, como não tinha o aparelho, e dessa vez nem o emulador, passei a noite estudando sobre xslt (que estávamos usando na solução) e mais um pouco sobre Python e as bibliotecas que estávamos usando.
No dia seguinte a coisa foi um susto, em menos de 4 horas conseguimos juntar o trabalho que os três estavam fazendo e fazer um programa funcional a tempo de entregar, nossa estratégia se mostrou eficiente, pois mesmo trabalhando separados, estávamos sempre trocando ideia sobre o todo. Cada um pegou seu pedaço e trabalhou firme nele.
As horas seguintes ao fim da arena foram as mais duras que já passei, tínhamos que esperar das 12h até as 20h, quando aconteceria o encerramento do fisl, e teríamos o anuncio do resultado. Eu estava tremendamente cansado, com mais de 48 horas de olhos abertos, mas nem tentei deitar em um cato e descansar, estava ansioso d+ para isso.
As 19h rolou uma apresentação das equipes finalistas, falamos sobre nossas soluções, e fizemos um pequeno momento de reflexo sobre a possibilidade de continuar o projeto que tínhamos começado ali. Passado isso fomos andando para o teatro principal para o encerramento do evento, as borboletas no estômago já estavam do tamanho de elefantes, e a ansiedade de saber o resultado era visível no rosto de cada participante que tinha chegado ate ali.
Como sempre o anuncio dos vencedores começou pela ordem inversa e os ganhadores do terceiro e segundo lugar foram anunciados por primeiro. Neste 2 minutos que dura entre o anuncio do segundo lugar e o primeiro existe um vazio na cabeça de quem espera o resultado que é indiscritível, afinal, ou foi tudo ou foi nada, e as chances em números são as mesmas para os dois lados. Então o anuncio do vencedor e algo que não se pode dizer em palavras, ficamos tão feliz que pulamos os três abraçados por um longo e feliz minuto.
Depois disso a coisa só fica melhor, você leva horas para perceber o que aconteceu, e que você realmente ganhou. Receber o prémio e algo fantástico, mas saber que você deu conta é ainda melhor, e a loucura e algo que domina facilmente a gente nesse momento.
Logo depois de mostrar com toda felicidade o N800 que tinha ganhando ao público, escutei um sonoro “joga, joga, joga!!!”, era uma plateia maravilhada com os prémios, e que clamava de alguma forma pra participar daquilo, não pensei duas vezes, virei para uma mesa, deixei minha sacola, e comecei a desmontar meu W300 na busca pelo chip GSM, que não queria sair de forma alguma, quando consegui arranca-lo do aparelho foi apenas um grito: “PEGUE O CARREGADOR COMIGO DEPOIS”, estava feito, tinha jogado meu celular para plateia que o recebeu com toda a felicidade.
Depois disso veio a entrevista para a impressa, e maravilhosos momentos de comemoração e orgulho da conquista. O N800 foi explorado de todas as formas, e tenho grandes planos de participar do seu desenvolvimento, seja com projetos Open Source ou pessoais. O N95 demorou um pouco para ser entregue, mas finalmente chegou e é outro brinquedo sem igual.
Quanto ao projeto que desenvolvemos para o N800 a coisa esta andando, ainda não temos nenhum release, mas em breve devemos postar alguma novidade por aqui, quem quiser acompanhar o andamento do projeto pode acessar o site do projeto: http://code.google.com/p/odfmobile/ ou ainda o repositório do mesmo: http://github.com/nuxlli/odfmobile
Classificado para Arena
Posted on April 12, 2008, under Desenvolvimento, fisl.
Com muito esforço e algumas horas de estudo consegui passar na fase Registration da Arena de Programação do fisl 9.0. Depois de horas relembrando o que eu já sabia e aprendendo várias coisas novas consegui resolver o terceiro problema em C.
Pelas notícias, acredito que a maior parte dos desafios vão ser em Python e alguma coisa em Symbian C++, eu sou fã do desenvolvimento em C++ e Python, mas nunca peguei firme em aprender nenhuma das duas, sei a syntax, aprendi o duro conceito de ponteiros, mas nunca coloquei em pratica nada que possa me orgulhar em ter feito. Agora as vésperas do evento (faltam apenas 5 dias), vou ter que puxar no final semana, e juntamente com o projeto em Rails vou ter que tirar tempo pra estudar Python e C++, pelo menos relembrar o que já conhecia e perder algumas horas com o Forum da Nokia.
Já as espectativas, são boas, pelo que eu já vi no wiki em português, o desenvolvimento em Symbiam C++ chega a ser mais interessante que o de Python, mas já esbarrei no primeiro empecilho: o ambiente disponível oficialmente é para Windows, vou ter que correr atrás de uma alternativa para o Linux. Outra questão que promete é possibilidade de rodar Ruby no Symbian.
Pelo visto o céu é o limite em se tratando de Symbian, já arrisco em dizer que um porte de Lua (minha linguagem predileta) poderia ser arranjado com uma certa facilidade, afinal ninguém merece trabalhar com Java não é mesmo.
Desenvolvendo Rails em Windows
Posted on April 10, 2008, under Desenvolvimento, Ruby/Rails, ubuntu.
Tenho visto em vários lugares as pessoas falando sobre os problemas de desenvolver Rails em Windows, agora que o Rails passou para repositório em Git nem se fala. Um dos principais lugares onde escutei isso foi no Rails Podcast Brasil, mais especificamente no episódio 12.
Os principais problemas apontados pelo pessoal no desenvolvimento são:
- Instalação de gems: Principalmente as gems que dependem de compilação;
- Limitações do shell: É de longa data que desenvolvedores tem problema com Windows por conta do “DOS” embutido nele, nunca foi um shell muito versátil, e se comparado com bash, a coisa ficar ainda pior;
- O git é muito limitado: Ao que parece o git realmente dominou as mentes dos desenvolvedores Rails, o que é bom, mas para quem trabalha com Windows a história parece ser outra, é possível ter ele rodando através de duas opções Cygwin ou Mysgit, eu pessoalmente não gosto de nenhuma das duas soluções, o Cygwin é bom mais é limitado e confuso, o Mysgit sofre do problema anterior.
Minha solução predileta é o uso de uma máquina virtual, pessoalmente eu utilizo VMware Player com Ubuntu Server, é possível utilizar qualquer outra VirtualBox ou Qemu são exemplos, ao meu ver o VMware é o mais fácil de configurar, inclusive já tento várias máquinas virtuais prontas pra baixar. O VirtualBox tem algums problemas de configuração da placa de rede, e o Qemu, mesmo usando kqemu nunca obtive uma qualidade que pudesse se comparar rodando no VMware.
Sei que a solução de virtualização não é para todos, existe muito problemas de performance, principalmente com máquinas com pouco ram. No meu caso tenho um notebook com 1GB de Ram é um processador de 1.83 core 2, a máquina virtual roda sem atrapalhar outras aplicações, claro que não é possível jogar ao mesmo tempo que estou com Firefox aberto e a máquina virtual, inclusive o grande vilão em se tratando de memória tem sido o Firefox. Mas já detectei momentos em que não estava utilizando a máquina virtual e uso de memória do VMware desceu a 29MB, sendo a máquina configurada com 256MB.
Existe diversas formas de se configurar a máquina virtual para trabalhar com Rails, segue os passos de uma configuração simples:
- Baixe o VMware Player;
- Baixe a máquina virtual com o Ubuntu Server já instalado;
- Baixe o putty;
- Baixe o TrayTask que vai esconder sua máquina virtual na barra do relógio [opcional];
- Rode a máquina virtual, log com o usuário notroot e a senha thoughtpolice;
- Verifique o ip da máquina virtual com um ifconfig;
- Agora já é possível acessar a máquina usando o putty;
- De uma olhada neste Howto é veja como configurar o samba no Ubuntu para facilitar o acesso aos arquivos da máquina virtual;
Existem n opções para o roteiro, desde de variação no acesso os arquivos usando servidor de ftp ou o winscp, e mesmo a opção de utilizar o Xming que permite abrir janelas dos programas rodando na máquina virtual como se fosse aplicativos nativos do Windows. E no caso do Putty pode se configurar chaves que permitam logar sem a senha na sua máquina virtual.
A instalação do Rails é fácil quando se esta no Ubuntu, podemos instalar todos os pacotes através do apt ou instalar o Ruby por apt, o gem atrás de tar.gz e depois instalar os gems como se faz normalmente. Existe diversas formulas na internet de como fazer a instalação do Rails no Linux.
Eu pessoalmente acho a solução razoável, visto que a melhor solução é de fato migrar pra Linux. Mas para quem não tem esta opção por um motivo ou outro, fica a dica. Se bem configurado e usando as ferramentas certas é possível trabalhar com total conforto de um ambiente POSIX sem perder as “vantagens” do Windows.
Qual o mais legal?
Posted on March 22, 2008, under Desenvolvimento, Ruby/Rails, Symfony.
Hoje li sobre o nova versão do Zendo Framework, uma das coisas que me chamou atenção foi a nova cara do site, eu conheci as outras versões do site e sempre gostei do trabalho que eles fazem por lá.
Ai me veio uma pergunta: qual dos sites de framework é mais legal? Não que isso faça a menor diferença na qualidade dos frameworks (sem flamers pessoal), mas mesmo assim a pergunta pairava. Eu listo a baixo os frameworks que já utilizei ou utilizo, existem muitos outros, deixe nos comentários qual o seu site preferido:
Por mais que eu goste de trabalhar com o Ruby on Rails, e de por um tempo ter considerado o site do Rails um dos mais legais que conhecia, hoje o site do Zend me salta aos olhos, verdadeira obra prima.
Aonde está a inovação?
Posted on February 23, 2008, under Desenvolvimento.
Outro dia via severa criticas aos filmes e a produção de seriados, a critica era bem especifica, e falava sobre erros e exageros tecnológicos encontrado nos filmes de hoje.
É impossível não concorda sobre a questão dos erros, mas espere um minuto! Desde de quanto eles não produzem filmes com erros de gravação? Hoje os blogueiros e sites relacionados a informática, observam isso porque esta relacionado a área deles, ver um computador com sinais de desligado, sendo utilizado com um computador ligado é um erro grotesco, mais ainda sim é um erro como outro qualquer, e que para maioria passa despercebido.
Mas o que me incomoda e ver gente falando mau dos exageros, e desde de quanto a gente não quer ver isso em filmes? Um super computador em uma caneta, um sistema de imersão virtual controlado pelo celular, mundo fictícios controlados por computadores que nos usam como pilhas. Isto não são erros, e a pura imaginação, é esta imaginação que nos trouxe tanta tecnologia, esta imaginação que faz o homens terem sonhos e vontades.
Pensando assim, me vem um pergunta: aonde esta a inovação da web de hoje? Uma vez li uma entrevista na revista Veja, que falava sobre o avanço do mundo sobre a interação do usuário com o computador, não vou conseguir lembrar quem foi o entrevistado, mas se alguém souber, indique e eu modifico o texto. Ele falava entre outras coisas que dificilmente vamos conseguir sair dos ícones, pois nos acostumamos a enxergar o computador assim, e ainda pior, que dificilmente vamos conseguir sair da ideia de disco ou espaços de armazenamento e arquivos, porque foi assim que o primeiro inventou, depois disso nos acomodamos sobre o fato e não conseguimos nos livrar disso para criar novas tecnologias.
Outro exemplo que ele citou foi o motor a combustão, a quantos anos criamos esse tipo de motor? Até hoje não conseguimos inovar nesse âmbito, não digo nem pela questão do combustível, falo pela questão do tipo do motor, todos usam o principio da manivela, do pistão dentre outras características, mesmo os motores a combustível alternativo são motores que tem por função girar e depois movimentar as rodas, cade a real inovação? Não desmereço quem inventou diversos tipos de tecnologia nesse meio, estão certos e de parabéns pelo que fizeram, mas me desculpe, não tem inovação nisso.
O mesmo tem acontecido a web, não existe inovação, o que vemos são aglomerados de tecnologias se junto umas as outras, as vezes de forma mais organizada, as vezes de forma gambiarrada, mas ao meu ver não ha nada de inovação nisso. Temos mais de uma década de html, e queremos dizer que AJAX e tantas outras letrinhas são inovações?
Desde da epoca em que eu comecei a trabalhar com computadores eu penso que precisamos de alguma coisa que substitua o html, que substitua o browser e sua maneira arcaica de juntar tecnologias. Eu ainda não tenhoa solução para essa questão, mas não tem um dia sequer que eu não pense em quanto ainda podemos inovar no ramo de informática e principalmente no ramo de internet.
VirtualHost não é host
Posted on February 20, 2008, under Configuração, Desenvolvimento.
A muito estou trabalhando com desenvolvimento web, e sempre encontrei pelo caminho quem confundisse a configuração dos web servers, commumente chamada de VirtualHost com a configuração do host.
Para quem trabalha com redes ou servidores a definição de hosts, domínio, zonas e tantas outras coisas ligadas ao serviço de DNS são bem simples, mas nem todo desenvolver almeja entender ou querem entender como isso funciona, ao meu ver um erro, pois é muito importante entender pelo menos o básico de redes, para si tornar um bom programador.
Mas essa questão a parte, muitos confundem essa pequena diferença e acaba por não conseguirem configurar seus ambientes de testes corretamente. Para estes ai vai uma pequena explicação:
Como muitos já devem ter percebido ate aqui, VirtualHost não é o mesmo que host. Tente imaginar o seguinte o VirtualHost que você configurou dentro do seu web server é como um if ou um case, que testa por qual host o cliente chegou ao seu serviço. Ou seja ele esta lá analisado o cabeçalho das requisições http, e vê lá a informação de qual host o usuário digitou no browser para que ele conseguisse chegar ate seu servidor.
Já o host é como uma entrada em uma agenda de endereços que diz qual ip está associado a este nome. Existe duas formas de configurar um host, a primeira é através de um servidor de DNS, no caso do Linux commumente se utiliza o bind para tal tarefa, no caso do Windows existe uma implementação desse tipo de serviço em versões server, que por sinal utiliza muito do código do bind, para usuário domésticos ou mesmo programadores há uma serie de software comerciais que desempenham este papel.
Apesar da configuração do servidor de DNS ser a opção com mais características e com mais flexibilidade, se trata de uma configuração complexa, e muitas das vezes inviável ao programador, que quer apenas configurar um ambiente de teste. Em seu lugar podemos utilizar o apelido de ip, que é algo mais simples de ser configurado, com o empecilho de que só funciona na maquina onde for configurado.
Para esta configuração deve se editar o arquivo /etc/hosts no caso de ambientes Posix, como Mac os X, Linux, BSD’s, entre outros, e o arquivo C:/[windows|winnt]/System32/drivers/etc/hosts para máquinas Windows. Para ambos os casos a configuração é a mesma, adicione uma nova linha no arquivo e coloque primeiro o ip, depois o host, ficando assim:
... 127.0.0.1 apolo apolo.nasa.org 127.0.0.1 jupter ...
Observe quê se pode configurar mais de um apelido em uma mesma linha, basta apenas separar eles por um espaços. Algo muito importante que deve se deve entender é que essa configuração não é uma configuração de domínios, o fato de adicionar apolo.nasa.org não faz diferença algum para o domínio nasa.org, a não ser na minha própria maquina, o que estamos fazendo é apelidado o ip com o endereço inteiro: apolo.nasa.org para o ip 127.0.0.1.
Como isso funciona: quando um serviço ou um programa qualquer, como um browser, pede ao kernel do seu sistema para resolver o endereço chamado, o kernel antes de consultar o servidor de dns, verifica se para aquele endereço não existe uma entrada no arquivo hosts, uma vez encontrado um apelido ali, ele nem procura resolver o endereço no servidor, apenas responde com o ip.
Uma vez com o ip na mão o programa ou serviço, monta um cabeçalho http e envia-o ao ip na porta também especificada, o padrão é 80 para serviço de http. Dentre as informações que estão neste cabeçalho esta o nome do host que ser quer ter acesso, o web server recebe esse cabeçalho, e checa em seu “case” qual a configuração para este host.
Espero que isso possa ajudar aos programadores iniciantes que querem montar seus ambientes de teste para o desenvolvimento de aplicações web. Em um próximo post vou falar como é fácil configurar um VirtualHost no apache sobre Ubuntu, até lá!
