Exigências do trabalho: Competência profissional em condução de veículos leves como carros e pesados como ônibus e caminhões, ônibus articulados, bondes, metrô, tratores, escavadoras e pás carregadoras, e tanques pesados atualmente em uso pelos países da OTAN.

Habilidades em Rali e de condução extremas são obrigatórios!
Experiência na Fórmula-1 é um diferencial.

Conhecimento e experiência em reparação de motores de pistão e rotor, transmissões automáticas e manuais, sistemas de ignição, computador de bordo, ABS, ABD, GPS e sistemas de áudio automotivo dos fabricantes conhecidos mundialmente – obrigatória!

Experiência em tarefas de pintura e funilaria de automóveis é um diferencial.

Os candidatos devem ser certificados pela BMW, General Motors e Bosch, mas não por mais de dois anos.

Compensação: R$ 15 – R$ 20/hora, dependendo do resultado da entrevista.

Exigências da instrução: Bacharel em Engenharia Mecânica.

As seen on leonardofaria.net

Não, não é só ir lá e votar ou comentar, como numa enquete. O buraco no “Participa Brasil” é muito mais embaixo. Lá, o principal objetivo, é encher o saco dos políticos da sua região.

A coisa toda é muito simples. Por exemplo, o assunto em destaque lá no momento da publicação desse texto é sobre a aprovação ou não do novo código florestal. Quando você se posiciona a favor ou contra o código (e sobre todos os outros temas que entrarem depois, imagino), automaticamente você envia um e-mail para todos os deputandos E senadores do seu estado. Assim, sem esforço, o sujeito lá em Brasília vai receber um e-mail com seu nome dizendo que você é a favor ou contra aquilo e que ele deve seguir a sua orientação.

Muito mais fácil que ficar xingando no Orkut ou no Twitter, não é? Então, como um blogueiro interessado em política, eu recomendo: acessa ai www.participabrasil.com e desça a lenha na sua opinião.

A favor ou contra, o importante é encher a caixa de e-mail dos seus representantes para mostrar que você não é somente um voto e sim uma voz!

Deu Flamengo de novo. O time da Gávea voltou a emocionar a torcida e conquistou o Campeonato Carioca 2011 de forma invicta ao bater o Vasco nos pênaltis neste domingo, no Engenhão. Depois de um jogo muito nervoso e que terminou em 0 a 0, os vascaínos demonstraram muito nervosismo nas cobranças de pênaltis. Coube a Thiago Neves fazer o gol do seu 32º título carioca. Assim como no ano passado, o estadual não vai para os dois jogos finais. Sem perder nenhuma partida, os comandados de Vanderlei Luxemburgo conquistaram a Taça Guanabara e a Taça Rio em 2011.

E o destaque desse ano vai para o Ronaldinho Gaúcho, que marcou uma falta matadora nos dando o 1 x 0 em cima do Boa Vista.

E vamos que vamos agora pra levar a Taça Rio e o Campeonato Carioca 2011!!!

Estava querendo usar as pastas compartilhadas do Oracle VirtualBox em guest Ubuntu Server com host Windows e não estava conseguindo de primeira, acabei descobrindo que é necessário seguir os seguintes passos:

Configure uma ou mais pastas a serem compartilhadas entre o host e o guest (vamos usar como exemplo o nome de pasta storage, que está em C:\storage do host, e será montada em /mnt/storage):

Com a máquina virtual rodando, habilite as guest additions (adicionais para convidado) do virtualbox:

Logue na máquina via SSH ou pelo próprio console, e envie os comandos abaixo:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install dkms gcc
sudo apt-get install linux-source
sudo apt-get install linux-headers-$(uname -r)

O comando abaixo vai montar a unidade de cd-rom criada virtualmente pelo Virtualbox quando você instalou os guest additions:

sudo mkdir /cdrom
sudo mount /dev/cdrom /cdrom
sudo /cdrom/VBoxLinuxAdditions-x86.run
sudo mkdir /mnt/storage
sudo vi /etc/fstab

Adicione a linha abaixo:

storage /mnt/storage vboxsf defaults 0 0

Salve, e saia do vi com:

:wq

Em seguida reinicie a máquina virtual:

sudo shutdown -r now

Quando o sistema voltar, você terá o compartilhamento de pastas do host no guest, exatamente no ponto de montagem (/mnt/storage).

Desse jeito estou conseguindo montar máquinas virtuais bastante enxutas com pouco espaço de HD e pouca memória, pouco mesmo, por exemplo, pra uma máquina mediana tenho instalado Ubuntu Server usando HD virtual de apenas 2GB (expansível dinâmicamente) somente para o sistema mesmo e com apenas 128mb ou 256mb de ram.

Nessas máquinas eu configuro o mount point do “storage”, e tudo que for arquivo de trabalho eu posso usar facilmente entre várias máquinas virtuais e o próprio host. Assim é possível rodar muitas máquinas, uma para aplicação, outra pra banco, outra pra tools como Hudson e SVN, com configurações bem enxutas, sem precisar ficar criando network shares e montando cada uma entre todas as máquinas.

Divirta-se!

As regras do meme são:

1ª – escreva sobre 7 itens de seu ambiente de trabalho – fale sobre qualquer ponto que quiser;
2ª – indique de 3 a 5 pessoas para que possivelmente façam um artigo sobre seu ambiente.

Vamos ao meu:

1. SO
   No desktop: Windows 7. No note e nos servers: Linux, qualquer um, desde Ubuntu pra uso diário a CentOS pros servidores.
2. Zend Studio
   Agora na versão 8, é a IDE mais completa na minha opinião. E já que é da Zend, vamos fundo!
3. SVN
   Já tive que usar CVS por um bom tempo em empregos anteriores, depois que conheci o SVN a experiência melhorou. Ainda não conheço o Git ou outros controladores de versão distribuídos, então continuo com o SVN já que me atende 100%, especialmente com seus hooks.
4. Apache + PHP + MySQL
   Sim, isso faz parte do meu ambiente. Afinal, outros desenvolvedores podem usar outras combinações. Mas hoje com a facilidade da virtualização, venho transferindo os ambientes locais para ambientes virtuais. E isso é excelente!
5. Firefox + Firebug + Web Developer toolbar
   O Firefox é meu navegador há anos, e não consigo usar com frequencia qualquer outro (Chrome, Safari, Opera…). O Firebug e a Web Developer são as extensões perfeitas pra quem desenvolve pra web.
6. iTunes/Celular
   Se não tenho silêncio em casa ou no trabalho ligo ele pra ouvir minhas músicas preferidas ou os podcasts atrasados com o fone que me isola do mundo.
7. Coca-cola
   Sempre!

Agora, mesmo que essas pessoas já tenham sido convidadas por alguém por aí, [re]faço o convite pra continuar:

• Renato Carvalho
• Newton Wagner
• Paulinha Winter

Estão abertas as inscrições para o PHP Conference 2010. Esse ano a fórmula vai ser a mesma, um dia para mão na massa (quinta), dois para palestrantes nacionais e internacionais (sexta e sábado), e no domingo vai rolar um encontro no litoral paulista. Pela programação que já foi divulgada, terão algumas palestras bem interessantes!

Todos os detalhes estão disponíveis no Planeta PHP…

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

- Na verdade isso responde muita coisa. Eu sempre tive o pressentimento que algo grande e sinistro acontecia no mundo.
- Não. Isso é chamado de paranóia. Todos no universo sofrem disso.
- Talvez eu esteja velho e cansado, mas as chances de sabermos o que acontece de verdade é tão remota que o melhor a fazer é seguir em frente e se ocupar com algo. Prefiro ficar contente do que ficar me remoendo.
- E você é feliz?
- Ah… não. Esse é o problema.

Mas eles certamente foram felizes para sempre.

E eu aqui sendo egoísta, ocupando 4 IPs de uma vez só no meu único servidor. Na verdade, tô segurando esses 4 pra vender no Mercado Negro apartir de setembro de 2011.