~rcmachado

Na versão 1.3.2 do jQuery o método .trigger() gera o seguinte erro no Internet Explorer 7 e 8 com custom events:

No meu caso isso aconteceu porque o nome do evento possuía ‘:’ (dois pontos) no nome. Ao remover e trocar por ‘_’, tudo funcionou normalmente. Na versão mais recente o problema foi corrigido.

Se você enfrenta problemas com a data e hora no seu linux rodando como guest no Virtualbox 3.0.x, mais especificamente em algumas versões do kernel 2.6 (como a 2.6.18), adicione o parâmetro nolapic_timer no boot do seu guest.

Se você quiser testar no próximo boot, sem alterar as configurações permanentemente, faça o seguinte no boot do guest (assumindo que você está utilizando o Grub como gerenciador de boot):

1. Pressione ‘e’ para editar a linha selecionada
2. Selecione a linha que possui root=… e pressione ‘e’
3. Ao final da linha, adicione a opção nolapic_timer
4. Pressione ‘Enter’ para salvar a modificação
5. Pressione ‘b’ para iniciar o sistema

Se funcionar, você pode alterar as configurações permanentemente no arquivo /boot/grub/menu.lst. Procure a seção que se refere ao boot e altere a linha que possui root=… adicionando o parâmetro nolapic_timer no final.

Aparentemente o problema não acontece com a versão 2.6.22 do kernel.

No SVN, para reverter um arquivo que foi modificado para a versão corrente do checkout, basta executar:

Uma desvantagem é que o comando não restaura diretórios apagados, já que não acessa o repositório.

Já no Git você pode utilizar o comando reset. Segundo o manual do git-reset, para descartar as modificações no arquivo basta passar para a opção –hard o commit para o qual você quer reverter. Supondo que você tenha um checkout do HEAD e queira descartar todas as modificações que fez nos arquivos, basta executar:

(Utilize dois traços para a opção hard)

Isso no entanto não vai descartar os arquivos que foram criados mas não foram adicionados ao branch. Para isso, utilize o comando clean:

Cada vez mais escutamos falar do HTML5. A atualização do HTML 4.01 traz diversos novos elementos que prometem deixar as páginas mais semânticas (header, article, section) e facilitar o desenvolvimento (video, canvas).

Para quem ainda não se informou sobre, uma busca no Google é um bom começo. Em seguida, você pode verificar como anda o progresso no Working Draft (ele ainda está em desenvolvimento, então algumas coisas podem mudar) ou pela lista de diferenças entre o HTML 4 e o HTML 5.

O Vim (Vi IMproved) é um editor de textos para linha de comando estremamente poderoso, com syntax highlight para diversas linguagens de programação (e até arquivos de configuração) e extensível com o uso de plugins, o que o torna melhor do que muitas IDEs do mercado (segundo os usuários do vim ).

Quem edita seus arquivos HTML no Vim e já quer utilizar as novas tags e atributos do HTML 5 pode fazer o download do html.vim direto do gist.github. Para instalá-lo, salve-o na pasta ~/.vim/after/syntax (ou a crie, se não existir) com o nome de html.vim.

Esse arquivo é uma modificação não-oficial do arquivo que acompanha o Ubuntu 9.04. Foram incluídos os novos elementos e atributos e retirados os que não devem ser utilizados pelos desenvovedores, de acordo com a página do W3C.

Referências:

• HTML 5 Working Draft: http://dev.w3.org/html5/spec/Overview.html
• Diferenças entre HTML 4.01 e HTML 5: http://dev.w3.org/html5/html4-differences/
• Site oficial do Vim: http://www.vim.org/

Muitos editores e IDEs tem a opção de remover os espaços em branco no fim de cada linha ao salvar o arquivo. Com o Vim não é diferente: basta um comando.

Nessa expressão regular estamos dizendo para substituir (s/) todos os espaços e tabulações (\s\+) por vazio (//), aplicando em todo o buffer (g). Como não é muito prático ficar digitando isso toda hora, vamos mapear para o comando “Trim”:

Para facilitar ainda mais, podemos mandar o Vim executar esse comando sempre antes de salvar o buffer (evento BufWriteCmd):

O ‘*’ diz a quais arquivos essa regra deve ser aplicada. Para aplicar somente a arquivos PHP, basta escrever:

Coloque esses comandos no arquivo ~/.vimrc (retirnado o ‘:’ no início da linha) e pronto. Simples, não?

Os frameworks MVC e diversos sistemas (como o próprio WordPress) utilizam URLs amigáveis – algo como http://example.org/configurando-sites.html ao invés de http://example.org/post.php?id=99. Isso requer que o servidor web seja configurado corretamente. No Apache isso pode ser conseguido com o auxílio do mod_rewrite, que permite mapear URLs utilizando expressões regulares para diferentes arquivos. A maioria provê o seguinte exemplo (ou uma variação dele):

Esse código especifica que se o arquivo requisitado (%{REQUEST_FILENAME}) não for um diretório (!-d) e não for um arquivo (!-f), a regra seguinte deve ser aplicada (que no caso diz para passar a execução para o script index.php).

Podemos colocar esse código .htaccess, o que traz uma desvantagem: é preciso que o apache seja configurado para procurar arquivos .htaccess em cada diretório da aplicação, o que reduz o desempenho. O ideal seria colocá-lo diretamente na definição do VirtualHost. Para isso, precisamos fazer um pequeno ajuste. Onde está:

Substitua por:

Isso é necessário porque o apache – por algum motivo que desconheço – não mapeia a caminho completo para a variável REQUEST_FILENAME (embora a documentação informe o contrário). Colocando o %{DOCUMENT_ROOT} antes, a condição se torna válida.

Todo framework MVC sério possui um mecanismo de customização de URLs (as vezes chamado de routing). Esse mecanismo permite que tenhamos URLs amigáveis – transformando /carros/ver/35 em /maserati-3200gt.html. Normalmente, isso é implementado utilizando expressões regulares que são mapeadas diretamente para a URL no formato controller/action/parâmetros, o que torna muito simples de ser implementado e configurado. Com as URLs do projeto configuradas, ao desenvolver as páginas temos de optar por colocar os links na forma controller/action/parâmetros (o que não é uma boa idéia, já que estaríamos ignorando a customização de URLs) ou na sua forma customizada (o que claramente é melhor).

Só existe um problema com essa abordagem: vamos imaginar que fosse necessário fazer um ajuste nas URLs no decorrer do desenvolvimento – ou até mesmo imediatamente antes de publicar o projeto. Por menor que seja o ajuste, teríamos de alterar todos os links do projeto (com sorte poderíamos utilizar um script em sed para convertê-las automaticamente, mas ainda sim seria preciso verificar depois se tudo está OK). Foi exatamente esse o problema que enfrentei em um dos projetos que trabalhei recentemente.

Read more…

Comecei a brincar com o Django, “o” framework Python quando se trata de web. E como nem sempre estou com conexão disponível, resolvi ter também uma cópia local da documentação, para que eu possa consultá-la sempre que for preciso.

Pois bem, na página sobre a documentação do Django, vejo que os arquivos que preciso estão no diretório docs dentro da pasta criada ao descompactar o .tar.gz do mesmo. Para criar a documentação no formato HTML, basta instalar as ferramentas certas e fazer um

no diretório.

Read more…

No post anterior eu expliquei como instalar o Ruby On Rails no Ubuntu, sem utilizar os pacotes oficiais. Pois bem, ao tentar instalar o driver para MySQL do Ruby, me deparei com o seguinte problema:

Mas o que foi que aconteceu?
Read more…

Juntamente com a linguagem Ruby, o framework Rails tem ganhado grande destaque ultimamente, principalmente pela rapidez e facilidade que proporciona para desenvolver um site ou uma webapp. Mesmo com a popularidade da dupla Ruby + Rails, muita gente ainda repete a frase “Rails não escala” (normalmente desenvolvedores “velhos” – não por causa da idade, mas por causa das ideias – também conhecidos como dinossauros). O foco desse post não é debater se Ruby on Rails escala ou não, e sim mostrar como em poucos minutos você pode configurar o seu ambiente Ruby + Rails.

Depois dos avisos, vamos ao que interessa.

Read more…