Hola pueblo! Ustedes estan bien?
Hoje es un dia muy gratificante para mi persona e mi pueblo, lo dia internacional de hablarse portuñol! Es una data muy querida, muchas fiestas en diversas naciones ocorren neste gracioso dia.

Para los mas desavisados, portuñol es un idioma famoso, tiene artigo en Wikipedia! E non és solamiente esto, és un idioma estudiado por una grande universidad.

És una pena que en Brasil las comeraciones se limitem a lo mundo virtual. En grande part de los países latino americanos las comeraciones son regadas a mucha fiesta. Mariachis, tequila, castanholas e tudo mas que relembra nuestra richa cultura! Las muheres e chicas enton, ficam muy belas.

Estoy mui empolgado e esqueci-me que este blog es sobre progamacion. Nuestra cultura tiene grandes programadueres, grandes tecnicas de la programacion. Uno grande exiemplo desto és lo comando goto, recientemente adicionado en la linguagen PHP.
Solamente una cosa me deja triste en PHP, el Paamayim Nekudotayim. No seria bein mehor lamado de dos puentos? Mas jo acredito que esta discussion lo ira lebar a nada!

Enton, dejo una contribuicion de uno grand programador que habla nuestra lingua! Es un programa que convierte lo idioma del Brasil para las bielas palabras de lo idioma Portuñol! E non dejem de acessar las paginas oficialies de las comemoraciones!

Acredito que Web vem tomando um caminho interessante com decisões tomadas nos últimos meses, como a adoção do HTML 5 e o engavetamento do XHTML 2. Isso com apenas um padrão, a confusão será bem menor e a adoção poderá ser realizada de modo mais harmonioso. Mas, como a maioria das pessoas que trabalham com Web sabem, não basta que o padrão exista, ele deve ser suportado pelo mercado, senão acaba ficando somente “no papel”.
Até algum tempo atrás, acreditava que isso aconteceria com o RDFa, uma recomendação do W3C que é conjunto de extensões do (X)HTML que permite aumentar a semântica de documentos (X)HTML. Atualmente, o padrão é suportado pelo Yahoo!, o pioneiro, e pelo Google.

E agora você me pergunta:

Em que isso vai me ajudar?

O RDFa basicamente adiciona semântica a seus documentos, fazendo com que eles sejam compreendidos mais facilmente por dispositivos, o que aumenta a capacidade de busca.
Agora é só pensar um pouco, se o Yahoo e Google puderem compreender melhor seus documentos, eles serão mais facilmente encontrados e você ganha uma vantagem sobre quem não dá a mínima para semântica.
Pra você que ainda não ficou convencido, aqui vou usar dois exemplos, que talvez você já tenha visto, mas não sabia o porque das informações adicionais. Primeiro a do Yahoo.

Agora a do Google.

Em ambos os casos, as informações adicionais que estão associadas aos resultados fazem grande diferença nos resultados, pois adicionam muito mais ao que o usuário deseja saber, do que simplesmete o resultado da busca tradicional. Essa pequena diferença já é suficiente para deixar seu resultado a frente dos demais e possivelmente preferido pelo usuário.

Gostou, não é?
E agora você me pergunta:

Mas como eu faço isso?!

Não faltam recursos na Web sobre RDFa, e como o objetivo desse post é alertar sobre as possibilidades dele, deixo alguns links para vocês aprenderem um pouco.

1. Ótimo para quem não sabe nada, leitura obrigatória.
2. Também é ótimo para quem está começando, dividido em duas partes.
3. Continuação do artigo anterior.
4. Esse é um pouco mais avançado, leia depois de ler os anteriores

Lembrando que o W3C Semantic Web Activity possui vários recursos para quem quer aprender, além de alguns casos de uso.
E não tem desculpa para não utilizar, ele é compatível tanto com HTML quanto XHTML.

Desde muito tempo atraz, ficamos intrigados em ter que rebootar o apache a cada nova configuração de vhost. O Bodão inclusive descobriu um tal de mod_myvhost, mas que para nossa infelicidade funcionava somente no Apache 1.3.x. E assim como nós, os caras do slack-users, também acharam que compilar esse módulo para a versao 2.xx do Apache não era possível.

Bom… A idéia foi abandonada, e a azia de reboot continuava causando com a galera! ¬¬”

Recentemente (mais precisamente na sexta passada), resolvi colocar a idéia do Mano em prática: configurar um ambiente de desenvolvimento padronizado para a empresa!

Tá… legal… As idéias foram surgindo… Mas peraí! Pouts… “A gente podia dar um jeito de não ter que ficar dando restart no Apache neh?” É!

Bom… foi o suficiente pra que eu (teimoso como sempre) fritasse algumas horas e colocasse o mod_myvhost pra rodar!

OK! Chega de historinha e vamos instalar neh…

1 – Execute esse script aqui

Ele baixa o source, corrige o Makefile e compila o módulo:

#!/bin/bash
 
mysql_libs=`mysql_config --libs | sed 's,-rdynamic ,,'`
 
if [ $? -ne 0 ];
then
    echo -e "\n\nVoce precisa da \"libmysqlclient-devel\" para continuar a instalacao"
fi
 
APXS=`apxs`
if [ $? -ne 0 ];
then
        echo -e "\n\nVoce precisa de \"apache2-devel\" para continuar a instalacao"
fi
 
svn checkout https://mod-myvhost.googlecode.com/svn/branches/2.xx mod-myvhost-read-only
cd ./mod-myvhost-read-only
 
sed -i "s,\`mysql_config --libs\`,$mysql_libs," Makefile
 
make -w -i --silent && wait
cp .libs/mod_myvhost.so ./

Depois do módulo compilado…

coloque-o no diretório de módulos do seu Apache

cp ./mod_myvhost.conf /usr/lib/httpd/modules/

2 – Configure o seu httpd.conf

basta inserir as linhas que seguem no fim do arquivo. Lembre-se de comentar o include do arquivo onde estavam os antigos vhosts.

...
#Include /etc/httpd/extra/httpd-vhosts.conf
...
 
LoadModule myvhost_module lib/httpd/modules/mod_myvhost.so 
 
# My Virtual Hosts Configuration
Include /etc/httpd/extra/httpd-myvhosts.conf

3 – Crie seu httpd-myvhosts.conf

pra isso é só colocar as linhas seguintes em /etc/httpd/extra/httpd-myvhosts.conf, e alterar onde for necessário

NameVirtualHost *:80
 
    MyVhostOn           on
    MyVhostDefaultHost  "localhost"
    MyVhostDefaultRoot  "/srv/www/htdocs/"
    MyVhostDbHost       "localhost"
    MyVhostDbSocket     "/var/run/mysql/mysql.sock"
    MyVhostDbUser       "usuario"
    MyVhostDbPass       "senha"
    MyVhostDbName       "hosting"
    MyVhostQuery        "SELECT `rootdir`,`admin`,`extra_php_config` FROM `vhosts`  WHERE (`vhost`='%s' OR `valias`='%s') AND `enabled`='yes'"
 
        # Configuracoes Opcionais
        Options Indexes FollowSymLinks
        RewriteEngine On
        AllowOverride All
        Order allow,deny
        Allow from all

4 – Criando o banco de dados

CREATE DATABASE `hosting`;
USE `hosting`;
 
CREATE TABLE `vhosts` (
    `vhost` varchar(255) NOT NULL DEFAULT '',
    `valias` varchar(255) NOT NULL DEFAULT '',
    `enabled` enum('yes','no') NOT NULL DEFAULT 'no',
    `rootdir` varchar(255) NOT NULL DEFAULT '',
    `admin` varchar(255) DEFAULT '',
    `extra_php_config` text,
    UNIQUE KEY `vhostname` (`vhost`),
    KEY `enabled` (`enabled`)
) TYPE=MyISAM COMMENT='vhosts';

5 – Concluindo

Agora é só restartar o apache (PELA ULTIMA VEZ! haha), popular o banco e começar a utilizar!

Hoje aconteceu mais uma apresentação sobre temas relacionados a programação aqui para a equipe da souÁgil. Falamos sobre um tema que gera bastante polêmica entre uma equipe de programadores, por se tratar muitas vezes de uma preferência pessoal. Mas que tema é esse?
Padrões de escrita de código em PHP.
Especialmente no caso do PHP, a polêmica é ainda maior, uma vez que a linguagem não possui nenhum padrão estabelecido oficialmente.

Aqui vai a apresentação:

Acredito que em qualquer projeto essa prática é importante, e o objetivo dessa apresentação é mostrar alternativas existentes em PHP. Quem gostar de algum deles pode adotá-lo ou criar o seu, mas lembre-se que toda a equipe deve ter uma maneira fácil de conhecê-lo.
É isso, espero que ajude a quem precisar.

Em todo blog de desenvolvimento o assunto vem sendo o mesmo nos últimos dias: a morte do IE6. O Digg anunciou que não suporta mais o navegador, depois veio o Youtube, e tenho certeza que muitos outros estão seguindo a mesma estratégia dos gigantes.

Por todos os cantos da Internet se escutam exaltações de alegria: “hacks para PNG não mais”, “seletores CSS3!”, “HTML5″, e etc. E a cada vez que leio algo nesse sentido, sinto uma pontada de pesar por saber que essas pessoas não entendem o que é desenvolver pra web, elas acreditam que dando suporte às funcionalidades conhecidas de um punhado de navegadores que aparecem nas estatísticas é o necessário para dar suporte cross-browser. Então me pergunto: o que adianta bradar aos quatro ventos que desenvolve nos padrões de acessibilidade, sendo que na hora de escrever um script não leva em conta que os navegadores utilizados por deficientes visuais, por exemplo, são praticamente desconhecidos para os desenvolvedores. Eu não sei qual punhado de funcionalidades um navegador desses suporta, mas é meu papel garantir que pelo menos uma experiência minimalista de uso seja viável em qualquer navegador.

Não me vejo no direito de excluir algumas pessoas de utilizarem minha interface porque elas não usam um navegador que eu conheça ou goste, mas parece-me que muita gente não se importa com esses “excluídos”. Ontem, depois de ler o milésimo post falando como o IE6 é(era) a praga da web, resolvi dissertar brevemente sobre o assunto, e como gostei do que escrevi, vou reproduzir o texto do comentário aqui ipsis litteris.

Eu já cansei de falar isso, mas vamos lá.

Todo esse chororô dos desenvolvedores no que concerne ao IE6 é, no mínimo, “overrated”. Eu me sinto na obrigação de escrever código que funcione (mesmo que de maneira básica) em qualquer navegador. E sabem o que é mais interessante? Pra 99,9% dos projetos, não é nem um pouco difícil dar suporte ao IE6, o problema é que as pessoas desistiram de aprender JavaScript para usar cegamente essa aberração chamada jQuery, que até pouco tempo atrás abusou de user-agent sniffing, e que atualmente trocou pelos piores exemplos de feature testing que já vi na vida, se é que posso chamar aquilo de feature testing, tá mais pra object inference. Aí quando o cara testa no IE6 e vê as coisas dando errado, começa a meter a boca no navegador, mas mal sabe ele que o script que ele confia tão cegamente está fazendo tudo errado.
O meu ponto é que não é tão dificil escrever código cross-browser quando os John Resigs da internet pintam a todo momento.

Quanto ao CSS, sim o IE6 tem um suporte bem fraco a CSS2.1, mas existem os comentários condicionais. É simples fazer uma versão ‘lo-fi’ do design para IE6 utilizando um stylesheet alternativo. E pra quem ainda não sabe, esses fixes de PNG introduzem vários crashes totalmente imprevisíveis. O que você prefere, utilizar PNG 8bit ou CRASHAR o navegador de seus usuários?

Por fim, gostaria de dizer que sim, o IE6 está deixando de ser utilizado pela maioria, mas sempre existem pessoas que não podem atualizar, ou pessoas que utilizam um browser que nem entra nas estatísticas, algum dos muitos ‘flavors’ do IE6 que saíram ao longo dos anos. Acho que dá pra entender como é pointless ficar malhando um navegador, certo? Boas práticas de desenvolvimento contornam todos esses problemas.
O que falta na web são pessoas que realmente saibam o que estão fazendo e não navegadores com melhores capacidades.

E você, o que acha?

Bom, o Lucas já me cobrou e eu nem tinha percebido que não postei a apresentação aqui hehe, mas aí vai! Uma breve apresentação sobre referências circulares no DOM e como elas podem vazar muita memória no IE 6 e anteriores.

No começo também falo sobre resolução de identificadores e como funciona o contexto de execução quando uma função é criada. Isso é necessário pro entendimento a fundo do que causa esses memory leaks, mas o mais importante para todos os desenvolvedores está nos últimos slides, onde mostro o que é uma closure, como as referências circulares más são formadas e como fazer para evitá-las.

Qualquer dúvida que tiverem, digam nos comentários e ficarei feliz em responder.

Aproveito também para convidar novamente todos que forem de Londrina a participar dessas apresentações, vamos tentar realizá-las a cada uma ou duas semanas.

Atualmente, o pessoal aqui da souágil está se reunindo para discutir e apresentar alguns temas importantes para o desenvolvimento, o que chamamos de processo de melhoria contínua. São pequenas apresentações de no máximo 30 minutos. O primeiro encontro foi sobre Referências Circulares e Memory Leaks no DOM apresentação feita pelo Gabriel, garanto que vou cobrá-lo a postar algo sobre isso aqui. O segundo encontro foi ontem, dia 14, e o assunto foi o migrations do cakePHP feito por João José e Juan Basso do CakePHP Brasil.

Vou disponibilizar aqui a apresentação porém alerto que esta não explica o que é o migrations e nem o que faz. O intuito era mesmo ensinar a utilizar:

Obs.: Quem for de londrina e quiser participar dos encontros pode comentar este post ou enviar um email para contato [arroba] usosim.com.br

Eai galera!

Nos ultimos dias enfrentamos turbulências na realização da mudança do nosso servidor, cache do WP, e outras azias aleatórias .

O KISS ficou zuadão, mas agora (de acordo com o Bodão) está rodando normalmente:

Hj eu botei um sistema de cache de macho nele… agora eh cache de banco de dados, e nao cache de pagina completa… a separacao de contexto conteudo estatico e conteudo gerado por consultas eh bem mais interessante, gasta menos espaco em disco, menos processamento, e tudo acaba realmente ficando mais rapido…

Bom… sendo assim, gostariamos de deixar aqui nossas sinceras desculpas pelos transtornos =D

[]’ss

Nossa linguagem de programação preferida, o PHP, sempre sofreu diversos ataques com relação a esse aspecto, normalmente comparado a outras linguagens de programação como Java, Python, Ruby e até C++. Não que ele seja uma linguagem imaculada, mas não é limitado ou ruim como muitos dizem por ai.
Se vocês acompanham o desenvolvimento da linguagem, devem saber que a versão 5.3 está quase saindo do forno, e vem com várias promessas bastante promissoras.

Uma delas, que acredito que seja uma das melhores iniciativas desse release, é o PHP Quality Assurance. O PHP QA é uma iniciativa de um grupo de desenvolvedores que deseja ajudar o grupo principal de desenvolvimento do PHP, melhorando a qualidade da linguagem. Entre as estratégias e objetivos, temos diversas iniciativas associadas a testes automatizados, análise e reporting de bugs.

Só que uma das partes mais interessantes ainda não foi mencionada. Se você se preocupa com a qualidade da sua linguagem de programação preferida e gostaria de ajudar ela a melhorar, agora você tem mais uma maneira de fazer isso! Você quer saber como?
Agora você pode escrever testes para o PHP!
E não é só isso! Agora você também pode acompanhar o andamento dos testes existentes e o code coverage para cada versão. Outro modo de ajudar é testanto a compilação dos Release Candidates atuais.

Não conheço nenhuma iniciativa semelhante por parte de outras linguagens de programação, alguém sabe de alguma?
Essa talvez seja uma das grandes vantagens do PHP com relação a outras linguagens de programação, o tamanho da comunidade e a abertura dada para que ela possa contribuir.
Agora ninguém tem desculpa pra não ajudar o PHP a se tornar uma linguagem de programação cada vez melhor. E quando vocês ouvirem que ele é uma linguagem não confiável, já sabem aonde recorrer para provarem o contrário.
Good coding!

Posts relacionados:

1. CakePHP AutoTest – Testes Contínuos Certo dia, lá no canal do IRC fiquei sabendo de...

Tive a idéia de escrever aqui uma releitura do texto utilizando os 3 primeiros grandes objetivos como motivações, benefícios que os testes podem trazer para o projeto. A idéia é plantar uma semente naqueles que ainda não acreditam nos testes, tentar mostrar que, quando bem implantado, os testes são valiosos.

1- Melhoria da qualidade

Antes de falar sobre como o teste pode ajudar na melhoria da qualidade, temos que entender o que significa qualidade de software. O autor foi muito feliz quando dividiu o definição de qualidade em dois tópicos: o software foi desenvolvido corretamente? desenvolvemos o software certo?

Quando desenvolvemos testes, buscamos sempre pensar em qual o comportamento que nosso código deverá ter em diversas situações.  Se conseguirmos escolher corretamente as situações que correspondem o que o cliente precisa e reproduzirmos estas situações nos testes automatizados, teremos certeza que os comportamentos serão atendidos e que estamos no caminho certo. As ferramentas de testes de aceitação são ótimas para atingirmos este objetivo.

Desenvolvendo que é realmente necessário, devemos garantir que o software realize corretamente os comportamentos. Nosso código deve estar livre de qualquer Bug. Testes unitários são ótimos para encontrar Bugs e prevenir que eles retornem. Quando um teste falha, a suíte nos indica precisamente o local que ocorreu o erro, nos dando informações valiosíssimas para concertamos o problema. Isto em questões de segundos.

As vezes, o Bug é descoberto quando o sistema está em produção, nestes casos o estrago provavelmente já deve ter ocorrido. Mas a automação ainda pode ser útil, temos a possibilidade de criar a reprodução do problema com um teste (Regression Test) e, assim prevenir,que o Bug retorne em futuras modificações.

Vale comentar que desenvolver teste é como desenvolver código, da mesma maneira que podemos cometer alguns enganos na programação de uma função, os testes também sofrem este problema. A diferença é que sem testes, o tempo e custo para encontrar estes enganos seriam muito maior.

2- Entendimento do Sistema

Quem estuda metodologia ágil deve conhecer o manifesto que prega, entre outros,  “código funcionando mais que documentação”. É com esta filosofia que digo: Uma suíte de testes é ‘n’ vezes mais valiosa para o entendimento que qualquer documentação.

O primeiro benefício é que os testes não ficam “desatualizados”, eles correspondem fielmente o que o código realiza. A documentação de um sistema é um custo para o projeto que, quando o prazo está curto, o sistema está com bug e o orçamento está no fim, a primeira atitude dos desenvolvedores é cortar esse peso. Uma documentação desatualizada é pior que não ter documentação. Testes e código não mentem, eles são, até certo ponto, exatos.

Temos que lembrar também que testes são códigos, e nós somos autores de códigos. Nós sabemos ler e escrever código, não documentação. Isto leva àquela velha história de comunicação, onde um desenvolvedor, ao escrever a documentação, não consegue expressar o que o código reproduz e escreve algo que não condiz com o sistema, seu colega, como muitos analfabetos funcionais, não interpreta corretamente o que o primeiro escreveu e entende algo totalmente diferente que realmente o código está fazendo. Resumindo, uma grande piada, que para o cliente é de extremo mal gosto.

3- Redução de Riscos

Uma das grandes vantagem dos testes é a criação de uma rede de proteção. Esta rede te dá liberdade para evoluir o sistema sem medo de ser feliz. Já comentei sobre desenvolvimento confiante aqui no blog. Com uma rede de proteção podemos nos prevenir de bugs já conhecidos, mexer em códigos legados e adicionar novas funcionalidades sem medo, pois sabemos que tudo que fazemos, temos os testes para verificar se estragamos algo. É isto que chamamos de Risco Calculado.

Os outros 3 grandes objetivos citado pela fonte diz mais a respeito dos testes em si, algo que deixarei para comentar em uma outra oportunidade. Meu foco foi trazer para vocês os que os testes podem fazer pelo sistema, os benefícios que recebemos quando desenvolvemos testes automatizados de forma correta. Fica o convite a todos para lerem o texto original, tenho certeza que não se arrependerão.