Phperl, minha gambiarra para usar Perl como se fosse PHP
Admiro muito o PHP, mas só isso, porque eu prefiro construir minhas páginas usando CGI/Perl, então eu bolei uma técnica para poder programar em CGI/perl como se fosse PHP, ou seja, usando um construtor WYSIWYG (Dreamweaver,NVU, etc).
[ Hits: 27.087 ]
Por: Arnaldo Luiz Estevao em 22/01/2008
Introduzindo
Phperl
Embora tenha grande admiração pelo PHP, sempre tive dificuldade em migrar meus aplicativos de CGI/Perl para PHP, não sei se por inabilidade minha, mas sempre tenho um consumo elevado de memória quando habilito PHP no meu apache e uma queda significativa na performance das aplicações escritas em PHP comparada a mesma aplicação em CGI/Perl, no entanto sempre me incomodou o fato de não poder utilizar construtores WYSIWYG como o DreamWeaver ou o Komposer para editar a arte das minhas páginas, trabalhei muito nos últimos dois anos com sistema de templates, e acredito que consegui chegar a uma técnica que tem sido tão produtiva que resolvi compartilhar com a comunidade.O pulo do gato
Existem duas coisas que são o pulo do gato desta técnica.1. O fato da maioria dos construtores WYSIWYG e dos navegadores ignorarem o conteúdo dentro de uma tag <?php ?>.
Evidente, pois o php é executado do lado do servidor e não do cliente.
2. O poder da função eval() do perl.
Esta função pode interpretar quase um programa inteiro escrito em perl e até agora a única incompatibilidade que vi são as declarações de cabeçalho, que não podem ser feitas em tempo de execução de um script perl. Fora isto você pode escrever um sistema com milhares de linhas de código, inclusive declaração de subs e uso de módulos do CPAN que ela irá executar tranquilamente.
Páginas do artigo
1. Introduzindo2. O interpretador PHPerl
3. helloworld.cgi e helloworld.perl.php
4. Explicação passo a passo
5. helloworld.perl.php (2º exemplo)
Outros artigos deste autor
Instalando Slackware 11.0 em um pendrive
Autenticação mútua SSL em servidores de NF-e e CT-e
XML de NF-e ou CT-e ou MDF-e - Como validar usando os pacotes de esquemas do Governo
Leitura recomendada
Catalyst Framework Perl - (parte 2)
Catalyst Framework Perl - Parte III
Executando os principais frameworks Perl no cPanel com CGI
Twittando com o Perl (parte 1)
Comentários
[1] Comentário enviado por hugoeustaquio em 22/01/2008 - 13:48h
PATAQUEOPARÉU!!! Procure um sistema de templates para o perl, que você vai ter todas essas vantagens sem fazer tamanha gambiarra medonha!
PATAQUEOPARÉU!!! Procure um sistema de templates para o perl, que você vai ter todas essas vantagens sem fazer tamanha gambiarra medonha!
[2] Comentário enviado por removido em 22/01/2008 - 13:52h
HAUAHAUHAUAHUAHAUHAUAHHAUAHAUHAUAHUAHAUH
O pulo do gato foi ótimo!!!
Cara, perfeito seu artigo, tô rindo até agora!!!
Cada um que vemos na internet!!! Parabéns, excelênte artigo!
=)
HAUAHAUHAUAHUAHAUHAUAHHAUAHAUHAUAHUAHAUH
O pulo do gato foi ótimo!!!
Cara, perfeito seu artigo, tô rindo até agora!!!
Cada um que vemos na internet!!! Parabéns, excelênte artigo!
=)
[3] Comentário enviado por Ragen em 22/01/2008 - 16:07h
Amigão, nem por acaso você procurou pra ver se isso já não existia algo desse tipo?
Existe um módulo para Apache chamado mod_perl que tem a mesma função do mod_php que está disponível na grande maioria das distros atuais ^^
Ao invés de criar um Frankenstein, você poderia ter documentado como se faz a instalação desse tal módulo, um programa teste ou coisa do tipo.
E só pra finalizar... É sério, devem existir pelo menos uma dúzia de engines de template pra Perl - reinventar a roda, você deve ter muito tempo sobrando!
Amigão, nem por acaso você procurou pra ver se isso já não existia algo desse tipo?
Existe um módulo para Apache chamado mod_perl que tem a mesma função do mod_php que está disponível na grande maioria das distros atuais ^^
Ao invés de criar um Frankenstein, você poderia ter documentado como se faz a instalação desse tal módulo, um programa teste ou coisa do tipo.
E só pra finalizar... É sério, devem existir pelo menos uma dúzia de engines de template pra Perl - reinventar a roda, você deve ter muito tempo sobrando!
[4] Comentário enviado por marcosmiras em 22/01/2008 - 16:42h
hehe...
O gato tá mais pra canguru... rs. O que o Ragen falou é muito considerável, ao invés de "reelaborar a roda" o ideal seria verificar um engine de template disponível...
hehe...
O gato tá mais pra canguru... rs. O que o Ragen falou é muito considerável, ao invés de "reelaborar a roda" o ideal seria verificar um engine de template disponível...
[5] Comentário enviado por leandro_hamid em 22/01/2008 - 20:17h
"Pulo do gato"!?, que é isso cara!!!!
"Pulo do gato"!?, que é isso cara!!!!
[6] Comentário enviado por arnaldoestevao em 24/01/2008 - 16:29h
O problema não esta no fato de eu não saber que existem outras soluções alem do php e sim da maioria dos editores WYSIWYG não saberem disso, o próprio Kompozer por exemplo exibe todas as tags que voce tentar colocar como perl embebido usando o módulo Embperl, além disso eu não reinventei nada tudo que fiz foi construir uma técnica de programação utilizando os próprios recursos e o poder que a que a linguagem Perl oferece sem utilizar nenhum módulo adicional para isso, mas quem não gostou que faça do seu próprio jeito , afinal nós usamos software livre.
O problema não esta no fato de eu não saber que existem outras soluções alem do php e sim da maioria dos editores WYSIWYG não saberem disso, o próprio Kompozer por exemplo exibe todas as tags que voce tentar colocar como perl embebido usando o módulo Embperl, além disso eu não reinventei nada tudo que fiz foi construir uma técnica de programação utilizando os próprios recursos e o poder que a que a linguagem Perl oferece sem utilizar nenhum módulo adicional para isso, mas quem não gostou que faça do seu próprio jeito , afinal nós usamos software livre.
[7] Comentário enviado por hugoeustaquio em 24/01/2008 - 17:26h
Calma colega, não estamos tentando denegrir sua imagem, somente colocando sugestões melhores. Com certeza usando um sistema de templates você não passará por esse problema, pois com template você separa a visualização do código, mantendo os html's limpos.
Calma colega, não estamos tentando denegrir sua imagem, somente colocando sugestões melhores. Com certeza usando um sistema de templates você não passará por esse problema, pois com template você separa a visualização do código, mantendo os html's limpos.
[8] Comentário enviado por arnaldoestevao em 24/01/2008 - 17:57h
Blz Eustáquio, mas manter o código totalmente separado também não é solução, a soluçaõ mais próxima que eu encontrei foi o EmbPerl, mas veja quando voce usa as tags [+ +] o kompozer por exemplo não entende que deva ignorar o conteúdo dentro desta tag, veja um exemplo clássico voce precisa construir uma tabela com linhas de cores de fundo diferente, geralmente o Webdesigner não sabe nada de código se ele não estragar o código ja ajuda muito e o programador é igual ao windows 3.0 ou seja só encherga 16 cores , eu preciso integrar o serviço dos dois, no mercado eu so encontro desenhistas que produzem 90% de seus contúdos usando Dreamweaver, e programadores só em PHP quando encontro. vejamos o caso da tabela multicor
<html>
<body>
<table>
<tr><td>cabeçalho</td></tr>
<?php for $i ( 0 .. 10 ) {
if ($i /2 = int ($i/2)) {
?>
<tr><td>Linha par </td></tr>
<? php
}
else {
?>
<tr><td>Linha impar </td></tr>
<?php
}
}
?>
</table>
</body>
</html>
veja usando esta técnica o desenhista consegue um visual +- 90% ao layout do resultado do script ele pode definir o desenho da tabela, styles, etc usando o dreamweaver ou kompozer por exemplo, com a template separada isto não é possivel, alem disso é muito complicado dar manutenção em script e template separados a produtividade cai muito ,
o PHP é excelente mas ou é mais lerdo ou eu não soube configurá-lo corretamente porque a velocidade dos scripts abaixou e o consumo de memória do servidor aumentou muito além disso eu teria que abrir mão de quase 10 anos de programação em CGI/perl, quando o pessoal acenou com a continuação do projetor perl no Perl6 ja orientado a objeto, eu preferi continuar em perl mesmo e utilizar a técnica acima descrita, o Ò do Borogodó seria criar minha própria DTD para permitir os
editores WYSIWYG reconhecerem a tag <?perl ?> talvez eu faça isso.
Blz Eustáquio, mas manter o código totalmente separado também não é solução, a soluçaõ mais próxima que eu encontrei foi o EmbPerl, mas veja quando voce usa as tags [+ +] o kompozer por exemplo não entende que deva ignorar o conteúdo dentro desta tag, veja um exemplo clássico voce precisa construir uma tabela com linhas de cores de fundo diferente, geralmente o Webdesigner não sabe nada de código se ele não estragar o código ja ajuda muito e o programador é igual ao windows 3.0 ou seja só encherga 16 cores , eu preciso integrar o serviço dos dois, no mercado eu so encontro desenhistas que produzem 90% de seus contúdos usando Dreamweaver, e programadores só em PHP quando encontro. vejamos o caso da tabela multicor
<html>
<body>
<table>
<tr><td>cabeçalho</td></tr>
<?php for $i ( 0 .. 10 ) {
if ($i /2 = int ($i/2)) {
?>
<tr><td>Linha par </td></tr>
<? php
}
else {
?>
<tr><td>Linha impar </td></tr>
<?php
}
}
?>
</table>
</body>
</html>
veja usando esta técnica o desenhista consegue um visual +- 90% ao layout do resultado do script ele pode definir o desenho da tabela, styles, etc usando o dreamweaver ou kompozer por exemplo, com a template separada isto não é possivel, alem disso é muito complicado dar manutenção em script e template separados a produtividade cai muito ,
o PHP é excelente mas ou é mais lerdo ou eu não soube configurá-lo corretamente porque a velocidade dos scripts abaixou e o consumo de memória do servidor aumentou muito além disso eu teria que abrir mão de quase 10 anos de programação em CGI/perl, quando o pessoal acenou com a continuação do projetor perl no Perl6 ja orientado a objeto, eu preferi continuar em perl mesmo e utilizar a técnica acima descrita, o Ò do Borogodó seria criar minha própria DTD para permitir os
editores WYSIWYG reconhecerem a tag <?perl ?> talvez eu faça isso.
[9] Comentário enviado por hugoeustaquio em 24/01/2008 - 19:42h
Normalmente os sistemas de template possuem uma sintaxe para estruturas de repetição (normalmente de forma parecida com o JSP), sem que isso polua o html, mantendo compatibilidade com os editores WYSIWYG. Não conheço os sistemas de template para perl, mas uso muito o django, e os templates dele abrem perfeitamente bem em todos os editores que já abri. Talvez esteja faltando algo assim no mercado que seja escrito em perl, mas talvez valha a pena você procurar testar os templates para perl. A sintaxe do Perl Template Toolkit usa as tags "[% %]", teste se elas entram em conflito com o Dreamweaver (dentro dos valores de parâmetro dos imputs, dentro das tabelas, etc...). Qualquer coisa poste o resultado aqui. Ah, a propósito, a produtividade sobe muito quando se usa sistema de template. Talvez você tenha essa sensação devido a curva de aprendizagem, que é um pouco íngreme, mas quando você domina as opções de marcação do sistema, a produtividade sobe muito, e a facilidade de manutenção também.
Normalmente os sistemas de template possuem uma sintaxe para estruturas de repetição (normalmente de forma parecida com o JSP), sem que isso polua o html, mantendo compatibilidade com os editores WYSIWYG. Não conheço os sistemas de template para perl, mas uso muito o django, e os templates dele abrem perfeitamente bem em todos os editores que já abri. Talvez esteja faltando algo assim no mercado que seja escrito em perl, mas talvez valha a pena você procurar testar os templates para perl. A sintaxe do Perl Template Toolkit usa as tags "[% %]", teste se elas entram em conflito com o Dreamweaver (dentro dos valores de parâmetro dos imputs, dentro das tabelas, etc...). Qualquer coisa poste o resultado aqui. Ah, a propósito, a produtividade sobe muito quando se usa sistema de template. Talvez você tenha essa sensação devido a curva de aprendizagem, que é um pouco íngreme, mas quando você domina as opções de marcação do sistema, a produtividade sobe muito, e a facilidade de manutenção também.
[10] Comentário enviado por arnaldoestevao em 25/01/2008 - 10:09h
não, as tags [+ +] e [% %] não são compatíveis com o DreamWeaver e poluem o html .
não, as tags [+ +] e [% %] não são compatíveis com o DreamWeaver e poluem o html .
[11] Comentário enviado por hugoeustaquio em 25/01/2008 - 11:13h
Ahá! Achei a solução definitiva para você! O Perl Template Toolkit pode mudar de tag de configuração. Veja no endereço http://template-toolkit.org/docs/manual/Config.html#section_TAG_STYLE
Assim você pode usar qualquer tag que não entre em conflito com o DreamWeaver, pode até usar a tag <?php ?>, mais eu te aconselho a usar a tag mais comum (creio que seja a mais usada por linguagens de marcação de template) que é <% %> e deve funcionar no Dreamweaver perfeitamente!
Ahá! Achei a solução definitiva para você! O Perl Template Toolkit pode mudar de tag de configuração. Veja no endereço http://template-toolkit.org/docs/manual/Config.html#section_TAG_STYLE
Assim você pode usar qualquer tag que não entre em conflito com o DreamWeaver, pode até usar a tag <?php ?>, mais eu te aconselho a usar a tag mais comum (creio que seja a mais usada por linguagens de marcação de template) que é <% %> e deve funcionar no Dreamweaver perfeitamente!
[12] Comentário enviado por arnaldoestevao em 25/01/2008 - 12:53h
O dreamweaver aceita as tags <% %> o kompozer não, ja a utlização de comentários que foi minha primeira opção da um xabú com o dreamweaver, é que ele usa -> ao invez de --> pra fechar comentários,
então quando voce usa uma expresão $recordset->getvalue(0,0) ele suja o código html. Além disto com esta técnica eu transfiro 99% do código pra dentro da template até agora a única coisa que o perl não aceitou foi anexar módulos externos em tempo de run time, no resto a função eval se comportou de forma identica ao próprio perl e eu tenho scripts rodando com mais de 100 linhas de código inclusive com declaração de subs, utilização de funções em módulos externos e declaração de váriaveis globais , e também quando ocorre um erro de run time durante o desenvolvimento, ao invez de receber a tela 500 do apache eu recebo a mensagem de erro que o script esta gerando , fica bem mais fácil depurar e tratar erros
outra vantagem para mim é poder usar
<a href="$link">
ao invéz de
<a href="[% $link %]">
eu acho o primeiro mais limpo
O dreamweaver aceita as tags <% %> o kompozer não, ja a utlização de comentários que foi minha primeira opção da um xabú com o dreamweaver, é que ele usa -> ao invez de --> pra fechar comentários,
então quando voce usa uma expresão $recordset->getvalue(0,0) ele suja o código html. Além disto com esta técnica eu transfiro 99% do código pra dentro da template até agora a única coisa que o perl não aceitou foi anexar módulos externos em tempo de run time, no resto a função eval se comportou de forma identica ao próprio perl e eu tenho scripts rodando com mais de 100 linhas de código inclusive com declaração de subs, utilização de funções em módulos externos e declaração de váriaveis globais , e também quando ocorre um erro de run time durante o desenvolvimento, ao invez de receber a tela 500 do apache eu recebo a mensagem de erro que o script esta gerando , fica bem mais fácil depurar e tratar erros
outra vantagem para mim é poder usar
<a href="$link">
ao invéz de
<a href="[% $link %]">
eu acho o primeiro mais limpo
[13] Comentário enviado por hugoeustaquio em 25/01/2008 - 14:08h
Não senhor! Não se coloca 99% dos códigos de controle para dentro do template, nunca!
Nunca se usa um código como "$recordset->getvalue(0,0)" num template, seu código tera que passar um valor que será usado no template. Os sistemas de template possuem estruturas de controle porque elas ajudam a construir a visualização, como no seu exemplo de cores (que não possui nada referente ao controle, somente visualização) mas que não devem ser utilizadas para o controle da aplicação. Você continuará a usar seus códigos (inclusive com declaração de subs e mais de 100 linhas de código) só que agora retirará dele tudo o que é referente a visualização, facilitando (e muito) a manutenção do seu sistema.
Para não visualizar a mensagem de erro genérica do apache, bastará colocar um parâmetro que liga a debugação, fazendo com que o mesmo exiba a saída de depuração do script, ao invés do referido erro. O parâmetro é o seguinte: ErrorLog /usr/local/apache/logs/error_log que deve ser colocado no httpd.conf do apache (algumas distros mudam o nome ou a localização desse arquivo, mas creio que a maioria das distros o colocam em /etc/httpd/httpd.conf ou /etc/apache/httpd.conf), assim voltará a ser tão fácil depurar seus script quanto era antes. Caso você utilize mod_perl, será mais fácil ainda, nem precisará ver os logs, ele tem uma diretiva de debugação, mas lembre-se de desligar esses mecanismos quando for configurar um servidor de produção. Quanto a última vantagem que você apontou, o código do template não seria o que você colocou, seria o seguinte:
<a href="<% link %>" />
sendo que o caractere "$" foi eliminado. Com todo o respeito, essa opção é evidentemente superior, só pelo fato de não conter caracteres que podem atrapalhar os editores. Quem se encarregará de setar o valor de "link" será o seu programa que faz uso do template. Por fim, teste todas as opções de mudança de tag do sistema de templates no komposer, com certeza alguma não causará conflito com ele. Provavelmente a sintaxe funcionará, teste o exemplo abaixo e por favor poste aqui se isso deu certo ou não:
<table>
...<tr><td>cabeçalho</td></tr>
...<!-- FOREACH i in lista -->
......<!-- if i%2 == 0 -->
.........<tr><td>Linha par </td></tr>
......<!-- END -->
......<!-- ELSE -->
.........<tr><td>Linha impar </td></tr>
......<!-- END -->
</table>
Eu optei por utilizar os templates no comentário, que deve ser previamente configurada, conforme link que eu já postei.
Por favor, substitua os pontos por espaços, eu os coloquei para que o código ficasse identado. Usei a operação "%" que já calcula o resto da divisão inteira. Creio que qualquer raio de editor possa trabalhar com esse código, afinal de contas os comandos serão reconhecidos como comentários para ele. Dá pra retirar alguns "<!--" e "-->", mas colocando cada comando em um bloco do template eu achei que ficou mais didático.
notas adicionais:
* o desempenho do php é lento, mas um acelerador de cache resolve o problema http://www.ducea.com/2006/10/30/php-accelerators/
* se o comportamento do Dreamweaver não puder ser alterado, você pode alterar a configuração do template da seguinte forma:
my $template = Template->new({
...START_TAG => quotemeta('<!--'),
...END_TAG => quotemeta('->'),
});
obs: Talvez o seu legado de aplicações funcionando com o seu sistema PHPerl seja grande demais para mudar assim, de uma hora para outra, mas quando for iniciar um novo sistema, considere a hipótese de separar o código de controle da visualização, eu te garanto que não se arrependerá. Utilize também um mapeador objeto-relacional e você já estará pronto para fazer um sistema MVC sem nenhuma dor de cabeça!
Não senhor! Não se coloca 99% dos códigos de controle para dentro do template, nunca!
Nunca se usa um código como "$recordset->getvalue(0,0)" num template, seu código tera que passar um valor que será usado no template. Os sistemas de template possuem estruturas de controle porque elas ajudam a construir a visualização, como no seu exemplo de cores (que não possui nada referente ao controle, somente visualização) mas que não devem ser utilizadas para o controle da aplicação. Você continuará a usar seus códigos (inclusive com declaração de subs e mais de 100 linhas de código) só que agora retirará dele tudo o que é referente a visualização, facilitando (e muito) a manutenção do seu sistema.
Para não visualizar a mensagem de erro genérica do apache, bastará colocar um parâmetro que liga a debugação, fazendo com que o mesmo exiba a saída de depuração do script, ao invés do referido erro. O parâmetro é o seguinte: ErrorLog /usr/local/apache/logs/error_log que deve ser colocado no httpd.conf do apache (algumas distros mudam o nome ou a localização desse arquivo, mas creio que a maioria das distros o colocam em /etc/httpd/httpd.conf ou /etc/apache/httpd.conf), assim voltará a ser tão fácil depurar seus script quanto era antes. Caso você utilize mod_perl, será mais fácil ainda, nem precisará ver os logs, ele tem uma diretiva de debugação, mas lembre-se de desligar esses mecanismos quando for configurar um servidor de produção. Quanto a última vantagem que você apontou, o código do template não seria o que você colocou, seria o seguinte:
<a href="<% link %>" />
sendo que o caractere "$" foi eliminado. Com todo o respeito, essa opção é evidentemente superior, só pelo fato de não conter caracteres que podem atrapalhar os editores. Quem se encarregará de setar o valor de "link" será o seu programa que faz uso do template. Por fim, teste todas as opções de mudança de tag do sistema de templates no komposer, com certeza alguma não causará conflito com ele. Provavelmente a sintaxe funcionará, teste o exemplo abaixo e por favor poste aqui se isso deu certo ou não:
<table>
...<tr><td>cabeçalho</td></tr>
...<!-- FOREACH i in lista -->
......<!-- if i%2 == 0 -->
.........<tr><td>Linha par </td></tr>
......<!-- END -->
......<!-- ELSE -->
.........<tr><td>Linha impar </td></tr>
......<!-- END -->
</table>
Eu optei por utilizar os templates no comentário, que deve ser previamente configurada, conforme link que eu já postei.
Por favor, substitua os pontos por espaços, eu os coloquei para que o código ficasse identado. Usei a operação "%" que já calcula o resto da divisão inteira. Creio que qualquer raio de editor possa trabalhar com esse código, afinal de contas os comandos serão reconhecidos como comentários para ele. Dá pra retirar alguns "<!--" e "-->", mas colocando cada comando em um bloco do template eu achei que ficou mais didático.
notas adicionais:
* o desempenho do php é lento, mas um acelerador de cache resolve o problema http://www.ducea.com/2006/10/30/php-accelerators/
* se o comportamento do Dreamweaver não puder ser alterado, você pode alterar a configuração do template da seguinte forma:
my $template = Template->new({
...START_TAG => quotemeta('<!--'),
...END_TAG => quotemeta('->'),
});
obs: Talvez o seu legado de aplicações funcionando com o seu sistema PHPerl seja grande demais para mudar assim, de uma hora para outra, mas quando for iniciar um novo sistema, considere a hipótese de separar o código de controle da visualização, eu te garanto que não se arrependerá. Utilize também um mapeador objeto-relacional e você já estará pronto para fazer um sistema MVC sem nenhuma dor de cabeça!
[14] Comentário enviado por mineirobr em 29/09/2010 - 02:51h
Legal cara, mas prefiro template.
Parabens pela criatividade.
Deus é o limite.
Legal cara, mas prefiro template.
Parabens pela criatividade.
Deus é o limite.
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Enviar mensagem ao usuário trabalhando com as opções do php.ini
Meu Fork do Plugin de Integração do CVS para o KDevelop
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Criando uma VPC na AWS via CLI
Multifuncional HP imprime mas não digitaliza
Dica básica para escrever um Artigo.
Como Exibir Imagens Aleatórias no Neofetch para Personalizar seu Terminal
Tópicos
como coloco para instalar com esse erro. (13)
Alguém sabe de documentos de texto e /ou vídeo aulas de certificações ... (1)
Top 10 do mês
-
Xerxes
1° lugar - 69.193 pts -
Fábio Berbert de Paula
2° lugar - 52.680 pts -
Buckminster
3° lugar - 19.938 pts -
Mauricio Ferrari
4° lugar - 16.331 pts -
Alberto Federman Neto.
5° lugar - 15.094 pts -
Daniel Lara Souza
6° lugar - 14.232 pts -
Diego Mendes Rodrigues
7° lugar - 13.854 pts -
edps
8° lugar - 11.844 pts -
Andre (pinduvoz)
9° lugar - 11.656 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 11.189 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
