dicas

Bom, recentemente a FreeNode.org adicionou suporte a conexões SSL. Não que eu faça questão, porém meu irssi perdia a conexão com o server. Fui para o google e decidi postar a dica de como resolvi o problema e habilitei a conexão SSL.

Depois de muito tempo sem postar, me lembrei de algo bem interessante! Vocês podem mandar mensagens na página de contato dando sugestões de temas sobre Vim, Expressões regulares ou outra coisa que vocês gostariam de ver no blog ;p.

Expressões Regulares

Expressão regular é uma ferramenta muito forte para o tratamento de texto. É muito utilizado para substituições ou para verificar integridade dos dados, pois, através da expressão regular, vulga regex ou re, pode-se casar padrões de texto. Por exemplo:

/^[a-zA-Z0-9]+$/
Para somente caracteres alfanuméricos.

/^(\d{3}\.){2}\d{3}-\d{2}$/
Validando formato de CPF.

Esse tipo de regex é simples, valida praticamente só os caracteres que compõe uma dada string. Porém, as Perl Compatible Regular Expressions (Expressões Regulares Compatíveis com Perl), também conhecidas como pcre, permitem muito mais, inclusive utilizar condicionados (a.k.a. if's)! O que vamos falar agora é de Lookahead e Lookbehind.

Depois de muito tempo sem postar, me lembrei de algo bem interessante! Vocês podem mandar mensagens na página de contato dando sugestões de temas sobre Vim, Expressões regulares ou outra coisa que vocês gostariam de ver no blog ;p.

Expressões Regulares

Expressão regular é uma ferramenta muito forte para o tratamento de texto. É muito utilizado para substituições ou para verificar integridade dos dados, pois, através da expressão regular, vulga regex ou re, pode-se casar padrões de texto. Por exemplo:

/^[a-zA-Z0-9]+$/
Para somente caracteres alfanuméricos.

/^(\d{3}\.){2}\d{3}-\d{2}$/
Validando formato de CPF.

Esse tipo de regex é simples, valida praticamente só os caracteres que compõe uma dada string. Porém, as Perl Compatible Regular Expressions (Expressões Regulares Compatíveis com Perl), também conhecidas como pcre, permitem muito mais, inclusive utilizar condicionados (if's), porém isso é para outro post! O que vamos falar agora é de Lookahead e Lookbehind.

As hotkeys, ou teclas de atalho, sempre são úteis para quando você está escutando uma música e alguém lhe pergunta algo, ou precisa ir no banheiro ou precisa passar a música porque a atual é ruim. O exaile sempre foi meu player preferido. Simpatizo muito com ele. Para as teclas de atalho sempre utilizei o plugin Xkeys.

Depois de atualizado o pacote exaile do ArchLinux, o plugin XKeys parou de funcionar e não aceitava mais minhas teclas de atalho do teclado para manipular áudio, como forward, backward, stop, play, etc.

Esse problema era antigo, ele acusava que era necessário a lib mmkeys.so e que não estava presente. Nunca tinha tempo pra verificar o problema, até que eu decidi ir atrás.

Para quem é do Sul, estarei em Porto Alegre no dia 14/11/2009 ministrando duas palestras no evento Tchelinux. A programação tem mais de 60 palestras sobre diversos temas e a entrada é apenas 2kg de alimentos não perecíveis. Aqueles que participarem recebem um atestado de 10h para usar como atividade complementar.

Para mais informações http://www.tchelinux.org/2009. As palestras serão:

A busca efetiva pode ajudar muito, caso bem usada, tanto no ganho de tempo como na efeciência de substituições ou refactories. Seguem alguns outros exemplos de finalidades para a busca utilizando o Vim:

• Certeza de encontrar todas as incidências
• Ficam visualmente destacadas (com :set hlsearch)
• Testar substituições
• Verificar a ortografia atrás de erros de digitação
• Encontrar variáveis ou funções não utilizadas, só declaradas
• Encontrar rapidamente algum termo
• Verificar a existência de algum termo

Além da conhecida / (barra) para buscar, existe o :vimgrep. É dele que quero falar.

Bem, é notável o crescimento das metodologias ágeis de desenvolvimento de software. Uma das práticas que me agrada muito, é a programação em pares (pair programming). É bem perceptível, a um longo prazo, a diferença que faz essa prática. Navegando pela internet, como um marujo sem rumo, encontrei um post falando sobre Remote Pair Programming. Parece meio estranho, porque o XP (eXtreme Programming) faz alusão a uma dupla programar em um único computador, com um único teclado e um único mouse.

Faz um tempo que venho observando códigos que considero estranhos. Apesar de entendê-los, são necessários um esforço e um tempinho disponível. Alguns ainda exigem uns debugs ou até mesmo perguntar ao autor qual foi a intenção daquele trecho.

Baseado nisso e no comentário que recebi recentemente e inspirado pelo post de um amigo, vou fazer uma lista de coisas que proponho. São coisas simples, mas que facilitam na manutenção.

Umas das coisas que aprendi com Uncle Bob (Robert C. Martin), no seu livro Clean Code foi: escrevemos o código apenas uma vez, porém o mesmo é lido várias vezes. Então, não custa usarmos 5min a mais documentando alguma coisa ou escrevendo variáveis legíveis, que nos pouparão tempo mais tarde!

Essa semana eu precisei de uma apresentação Power Point. Abri o Impress, o editor de apresentações do OpenOffice. Comecei meu raciocínio sobre a apresentação. Quando me dei conta, estava colocando negrito e identando um parágrafo. Ao reler o parágrafo, havia 3 erros de gramática. Foi a gota d'água: Não consigo criar apresentações, pensei.

Quando eu vou escrever em algum programa de qualquer suíte de escritório - openoffice, koffice, etc -, eu geralmente me preocupo mais com o negrito da palavra, com identação do parágrafo do que com o conteúdo em si. Isso é um pecado.

Meu primeiro instinto foi: vou escrever tudo no Vim, depois colo no Impress. Boa! Ok, mas e quanto às páginas?
Vou ter que por página por página? Ainda sim eu teria mais trabalho. Eu teria que refazer as listas para que ficassem com as "bolinhas" à esquerda. E teria que modificar todos os títulos para negrito?

No post anterior Vimperator, comportamente do Vim no Firefox eu tinha mensionado que:

Parece radical, mas a produtividade aumenta, de certo modo. Não só na hora de programar e testar, sempre que edito arquivos no Vim, tento não usar o mouse. Claro que sempre vai ter alguma aplicação que vai te obrigar a usar o mouse, mas se pudermos evitar, melhor!

Eu continuo com esta idéia. Coisinha bonita é para cliente final. Desenvolvedores devem trabalhar com ferramentas que proporcionam o melhor uso do tempo possível, pois o bom profissional é aquele que esbanja do ócio, eis o fluxo:

• Concluir as atividades rapidamente com eficácia e eficiência está diretamente ligado ao ócio, pois se ele tivesse feito algo mal feito, estaria corrigindo os bugs e não vendo vídeos no youtube.
• Com tempo livre, o cérebro humano fica mais descansado e mais propício a receber insights/intuições para resolver problemas difíceis, que - e estes merecem - precisam de mais tempo e necessitam ser bem planejados.
• Resolvendo problemas de forma criativa - talvez até inovadora -, faz com que se evite problemas futuros. Logo, se poupa tempo. Se poupando tempo, voltamos a cláusula anterior.

Parece utópico, mas eu acredito nisso. Eu acho que é possível. Basta saber onde conseguir ganhar tempo em atividades, automatizando com scripts, programas e etc, o tempo é consequência.

Quantas vezes você faz um arquivo que é exatamente igual à um outro arquivo por dia? Quantas vezes você abre um arquivo só para copiar um trecho de código que é utilizado em vários arquivos? Quantas vezes você se vê fazendo a mesma coisa que fez em outro lugar?

E aquela palavra que você sempre escreve errada? Aquela função que você sempre esquece o nome?

Conheça algumas dicas para aumentar a produtividade e diminuir o trabalho dessas coisas rotineiras.