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ê 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.

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:

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/

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?

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.

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.

Resolver esse problema é mais simples do que parece, mas requer mudanças na forma como as URLs personalizadas são definidas. Na maioria dos frameworks, a configuração é feita dessa forma (ou alguma variação):

<?php
$routes = array(
    '^/([a-zA-Z0-9\-]+)\.html$' => '/carros/ver/$1'
);
?>

Essa abordagem facilita a visualização de quais URLs apontam para onde, mas não permite que façamos o inverso. Ou seja, não conseguiríamos descobrir qual é a URL personalizada para um determinado controller/action. Para isso, vamos tentar decompor melhor essa configuração:

<?php
$routes = array(
    '^/([a-zA-Z0-9\-]+)\.html$' => array(
        'controller' => 'carros',
        'action' => 'ver',
        'params' => array( '$1' )
    );
);
?>

Decompondo a URL de destino nas suas partes básicas (controller, action e parâmetros) podemos escrever um helper que percorre as configurações de URLs procurando pelo controller e action especificados:

<?php
function url_helper($c, $a, array $p) {
    global $routes;

    foreach ($routes as $rota => $info) {
        if ($info['controller'] == $c && $info['action'] == $a) {
            // achamos a rota que queríamos
            // agora executamos o código para montar a URL - isso fica como exercício 
            break;
        }
    }
}
?>

Podemos ainda expandir esse helper para escolher a URL customizada de acordo com o número de parâmetros envolvidos. A idéia desse post é somente mostrar o caminho para desenvolver essa solução e não fornecer uma implementação completa. Uma outra solução seria rodar um script que modificasse os links nos templates a cada vez que a configuração de rotas fosse modificada.

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.

O Ubuntu já tem pacotes para as ferramentas que precisamos. Então basta um…

…para que possamos compilar a documentação.

Como nem tudo nessa vida é perfeito, existe um bug que impede que a documentação seja compilada utilizando o Sphinx 0.6 (que é a versão do pacote

do ubuntu). A boa botícia é que o problema já foi corrigido para a versão 1.1. Caso você esteja utilizando a combinação Sphinx 0.6 e Django 1.0.2 precisará de um patch específico para a versão 1.0.2 ^[1].

Primeiro, faça o download do arquivo de patch, disponível em http://files.getdropbox.com/u/1447299/patch-django-1.0.2.diff. Salve-o na raiz do seu diretório de usuário com o nome

. Na pasta onde você extraiu o conteúdo do .tar.gz do Django, faça:

Depois, basta seguir o procedimento normal, executando um make html no diretório docs/. A documentação será gerada no diretório

.

^[1] Retirado de http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg645050.html

Mas o que foi que aconteceu?

Pesquisando um pouco não foi difícil descobrir o problema: a lib MySQL API para o Ruby ainda não é compatível com a versão 1.9. Voltando a pesquisar mais um pouco, encontrei esse post com a solução. No meu caso, ficou assim:

[code lang=bash]
$ sudo gem19 install mysql --source http://gems.rubyinstaller.org
[/code]

É isso! Comentários abertos para dúvidas e sugestões

Depois dos avisos, vamos ao que interessa.

O Ubuntu, como era de se esperar, já tem pacotes tanto para Ruby como para Rails. O único problema é que, ao menos nos meus testes, não funcionou direito. A instalação de gems (os “pacotes” do ruby, que utilizam um sistema similiar ao das distros Linux, como apt-get, yum, emerge, etc.) simplesmente não funcionava, retornando o erro “marshal data too short”. Como uma rápida pesquisa no Google não retornou nenhuma resposta satisfatória, e eu também queria a última versão, resolvi partir para a instalação do zero.

O primeiro passo, obviamente, é instalar o interpretador da linguagem Ruby. Não é do escopo desse post explicar como instalar o compilador e as ferramentas necessárias. Continuando, faça o download do código fonte em http://www.ruby-lang.org/en/downloads/ (a página em português está com links desatualizados). Assumindo que você salvou o código fonte na pasta ~/rubydev e o release baixado foi o 1.9.1-p129, faça o procedimento padrão:

Uma breve explicação:

• Na 4ª linha, configuramos os parâmetros da compilção. Nesse caso, queremos que os arquivos do ruby sejam instalados no diretório /usr/local (–prefix) e que os executáveis tenham o sufixo 19 (–program-sufix), o que premite múltiplas versões do ruby instaladas lado a lado.
• Na 6ª linha rodamos os testes para verificar se a compilação ocorreu conforme planejado. Caso o teste aponte erros significa que aconteceu algum problema na compilação ou você está com o código-fonte de uma versão desatualizada. Faça um
  make clean

  e repita o procedimento a partir da 4ª linha. Se ainda sim não resolver, tente com outra versão (preferencialmente a mais recente).

• Na 7ª linha instalamos os arquivos compilados no diretório /usr/local (lembra da opção –prefix?), por isso precisamos das permissões de root. Se o local de instalação fosse no seu diretório de usuário (o que só é recomendado caso você saiba o que está fazendo), não precisaríamos do sudo.
• Na 8ª linha criamos um link simbólico de ruby19 para ruby, para facilitar nossa vida

Após todo o processo (que pode demorar um pouco, dependendo do processador) você já poderá utilizar o ruby, atráves do executável ruby19 (lembra da opção –program-sufix?).

Instalando RubyGems

Após instalar o ruby propriamente dito, chegou a hora de instalar o RubyGems. O RubyGems é o gerenciador padrão para publicação e manutenção de libraries Ruby de terceiros – uma espécie de gerenciador de pacotes do Ruby. Mais uma vez, faça o procedimento padrão:

Agora já temos o RubyGems instalado e com a lista de gems atualizada. Chegou a hora do Rails.

Instalando o framework Rails

ou se você preferir instalar no diretório de sistema (o que é o meu caso):

Simples não? Já temos tudo o que precisamos para iniciar o desenvolvimento utilizando Ruby + Ruby On Rails – e tudo isso em alguns minutos