16 de dezembro de 2011

Veja os seus marks no vim

Há algum tempo uma coisa me incomodava no vim: não saber visualmente quais linhas eu tenho marks (ou bookmarks).

Eu sei que o comando :marks mostra isso, mas eu gostaria de ver os marks enquanto estou editando meus programas.

Foi quando procurei e encontrei o plugin ShowMarks. Ele mostra visualmente se suas linhas têm algum mark. Eu instalei meio desconfiado de que não fosse funcionar porque o último upload é de agosto/2004. Para minha feliz surpresa eu estava errado. Idade não é documento, certo?

Apesar de ele funcionar perfeitamente, eu resolvi fazer 2 ajustes:

Visual
Bem, na verdade eu não mexi no plugin. Mexi no que ele me permite configurar. Não gostei da forma como ele mostra os marks. Mas a documentação explica direitinho como ajustar umas variáveis de ambiente para isso. Ajustei as cores para o meu esquema de cores e a forma de mostrar os marks. Ficou bonito.

Deletar um mar
Na verdade, o atalho <leader>mh não apaga um mark. Ele deixa o mark invisível e ajusta-o para a linha 1 do seu arquivo. Por isso ele significa "mark hide". Não gostei disso e mexi no fonte do plugin para emitir o comando delmarks.

Open Source é muito bom (desde que você saiba como mexer). E o ShowMarks também.

15 de dezembro de 2011

Nós nunca nos renderemos!

"Nós não desistiremos nem fracassaremos. Nós iremos até o fim. Nós lutaremos na França, lutaremos nos mares e oceanos, nós lutaremos com confiança crescente e uma força também crescente ao nosso redor. Nós defenderemos nossa ilha, qualquer que seja o preço. Nós lutaremos nas praias, lutaremos em terra firme, lutaremos nos campos e nas ruas, lutaremos nas montanhas. Nós nunca nos renderemos!"
— Winston Churchill, Câmara dos Comuns, em 4 de junho de 1940.

14 de dezembro de 2011

O que Newton deixou para nós

Todo mundo já ouviu falar de Sir Isaac Newton.
É, aquele da história da maçã, que descobriu a Lei da Gravidade, lembra?

Muita gente não sabe que Newton escreveu mais sobre teologia do que sobre ciência. Por estranho que possa parecer, Newton e uma multidão de cientistas eram cristãos e não estudavam ciências descartando a existência de Deus. Ao contrário, eles estudavam para tentar entender Deus.

Abaixo estão links para duas obras importantes de Newton, que não falam de ciências. Ambas estão hospedadas no site do Project Gutenberg:
Conforme podemos conferir no site The Newton Project, Isaac Newton escreveu tanto sobre religião quanto sobre ciência. E, não só isso, ele acreditava que Jesus Cristo viria segunda vez à Terra.

Atualmente ouvimos muito que ciência e religião não podem se harmonizar. Se for assim mesmo, por coerência devemos descartar tudo o que Newto e as pessoas mostradas no vídeo abaixo disseram. Afinal, se eram lunáticos ao falarem sobre Deus, poderíamos considerá-los dignos de confiança ao falarem sobre ciência?

Ou será que deveríamos mesmo entender que religião e ciência podem conviver pacificamente, e que uma não deve descartar a outra?


"A maravilhosa disposição e harmonia do universo só pode ter tido origem segundo o plano de um Ser que tudo sabe e tudo pode. Isto fica sendo a minha última e mais elevada descoberta."
(Sir Isaac Newton -  Principia Mathematica, Book III)

O clipboard do Linux e o shell

O programa xsel permite ter acesso ao clipboard do Linux.

Isso pode te dar liberdade de implementar alguns scripts interessantes e colocar resultados no clipboard para serem colados em uma planilha eletrônica, por exemplo.

Para copiar qualquer conteúdo para o clipboard, a partir do shell, basta fazer um pipe. Por exemplo:
$ ls | xsel -i -b

Agora você pode digitar o famoso CTRL+V em qualquer aplicativo GUI e a relação de arquivos do diretório será inserida lá.

Para mostrar o conteúdo do clipboard no shell, digite:
$ xsel -b

13 de dezembro de 2011

Mais espaço na tela do Ubuntu 10.04

Sendo um programador, eu gosto de ver na tela o máximo de código possível.

Eu uso o editor Vim, que me permite esconder a barra de ferramentas e o menu, mas ainda fica a barra de título da janela, que o Gnome mantém.

No Firefox, eu uso uma extensão chamada Pentadactyl. Nome estranho, mas poderoso. Ela transforma totalmente a forma de navegar na web. Traz os comandos e a interface modal do vim para o Firefox. Para quem gosta do Vim, é um prato cheio e também me permite ocultar o que eu quiser: barra de navegação, abas, menus, tudo. Mas ainda fica a tal barra de título da janela.

Uma coisa que eu gostei no Unity é justamente esse ganho de espaço vertical e decidi encontrar uma solução para isso.

Então, encontrei o NameBar. Ele é um applet que você adiciona ao painel superior do Gnome, que mostra o título da janela ativa. Já dei o primeiro passo.

Depois, entrei no CompizConfig (que precisei instalar pelo Ubuntu Software Center) e configurei a decoração de janelas. Na categoria "Effects", existe uma opção chamada "Window Decoration". Dentro dessa opção, coloque o conteúdo "none" (sem as aspas) no campo "Decoration windows".

Além disso, configurei o painel inferior para Auto Hide. Portanto, ele só ocupa espaço na tela quando o mouse está sobre ele.

Pronto, agora meu Ubuntu 10.04 tem mais espaço na vertical, como você pode ver abaixo.

Firefox com Pentadactyl


Gvim

12 de dezembro de 2011

Uma Mensagem a Garcia

O texto "Mensagem a Garcia" foi escrito em 1899, como veremos abaixo, no relato do próprio autor, o filósofo e escritor norte-americano Elbert Hubbard.


APOLOGIA

SENSO COMUM

Se você trabalha para um homem, pelo amor de Deus, trabalhe para ele. Se ele paga a você um salário que compra seu pão e sua manteiga, trabalhe para ele, fale bem dele, tenha bom conceito sobre ele, fique do lado dele, e do lado da instituição que ele representa. Eu acho que se eu trabalhasse para um homem, eu realmente trabalharia para ele. Não seria somente uma parte do tempo, mas todo o tempo. Eu daria a ele um serviço integral, ou nada. Posto na balança, um grama de lealdade vale um quilo de inteligência. Se você tiver que desmerecer, condenar, e menosprezar, demita-se. E quando você estiver fora, lide com seus sentimentos. Mas, eu rogo a você, enquanto fizer parte de uma instituição, não a condene. Não que você iria machucá-la -- não é isso -- mas quando você deprecia algo do qual você faz parte, você está depreciando a si mesmo. E não se esqueça -- "Eu me equivoquei" não funciona no mundo dos negócios.


Esta insignificância literária, "Uma Mensagem a Garcia", escrevi-a numa noite depois do jantar, em uma hora. Foi a 22 de fevereiro de 1899, aniversário natalício de George Washington, e o número de março da nossa revista "Philistine" estava prestes a entrar no prelo.

Encontrava-me com disposição para escrever, e o artigo brotou espontâneo do meu coração, redigido, como foi, depois de um dia afanoso, durante o qual tinha procurado convencer alguns moradores, um tanto renitentes no lugar, que deviam sair do estado comatoso em que se compraziam, esforçando-me por incutir-lhes radioatividade.

A idéia original, entretanto, veio-me de um pequeno argumento ventilado pelo meu filho Bert, ao tomarmos café, quando ele procurou sustentar ser Rowan o verdadeiro herói da Guerra de Cuba. Rowan pôs-se a caminho só e deu conta do recado - levou a mensagem a Garcia. Tal qual uma centelha luminosa, a idéia assenhorou-se de minha mente. É verdade - disse comigo mesmo - o rapaz tem toda a razão, o herói é aquele que dá conta do recado: que leva a mensagem a Garcia!

Levantei-me da mesa e escrevi "Uma Mensagem a Garcia" de uma assentada. Entretanto, liguei tão pouca importância a este artigo que até foi publicado na revista sem qualquer título. Pouco depois de a edição ter saído do prelo, começaram a afluir pedidos para exemplares adicionais do número de março da "Philistine": uma dúzia, cinqüenta, cem; e quando a American News Company encomendou mais de mil exemplares, perguntei a um dos meus empregados qual o artigo que havia levantado o pó cósmico.
- Esse de Garcia -, retrucou-me ele.

No dia seguinte chegou um telegrama de George H. Daniels, da Estrada de Ferro Central de Nova York, dizendo: "Indique preço para cem mil exemplares, o artigo Rowan, sob forma folheto, com anúncios estrada de ferro verso. Diga também quando pode fazer entrega".

Respondi indicando o preço, e acrescentando que podia entregar os folhetos dali a dois anos. Dispúnhamos de facilidades restritas e cem mil folhetos afiguravam-se um empreendimento de monta.

O resultado foi que autorizei o Sr. Daniels a reproduzir o artigo conforme lhe aprouvesse. Fê-lo em forma de folhetos e distribui-os em tal profusão que, duas ou três edições de meio milhão se esgotaram rapidamente. Além disso, foi o artigo reproduzido em mais de duzentas revistas e jornais. Tem sido traduzido, por assim dizer, em todas as línguas faladas.

Aconteceu que, justamente quando o Sr. Daniels estava fazendo a distribuição de "Uma Mensagem a Garcia", o príncipe Hilakoff, diretor das estradas de ferro russas, se encontrava neste país. Era hóspede da Estrada de Ferro Central de Nova York, percorrendo o país em companhia do Sr. Daniels. O príncipe viu o folheto e por ele se interessou, mais pelo fato de ser o próprio Sr. Daniels que o estava distribuindo em tão grande quantidade, que propriamente por qualquer outro motivo.

Como quer que seja, quando o príncipe regressou à sua pátria mandou traduzir o folheto para o russo e entregar um exemplar a cada empregado da estrada de ferro da Rússia. Em pouco tempo foi imitada por outros países: da Rússia o artigo passou para a Alemanha, França, Turquia, Indostão e China. Durante a guerra entre a Rússia e o Japão, foi entregue um exemplar de "Mensagem a Garcia" a cada soldado russo que se destinava ao "front".

Os japoneses, ao encontrarem os livrinhos em poder dos prisioneiros russos, chegaram à conclusão que havia de ser uma informação valiosa e não tardaram em vertê-lo para o japonês. Por ordem do Micado foi distribuído um exemplar a cada empregado civil ou militar, do governo japonês.

Para cima de cem milhões de exemplares foram impressos, o que é sem dúvida a maior circulação jamais atingida por qualquer trabalho literário durante a vida do autor, graças a uma série de circunstâncias felizes.

Elbert Hubbard




UMA MENSAGEM A GARCIA

"Como o frescor de neve no tempo da ceifa, assim é o mensageiro fiel para com os que o enviam, porque refrigera a alma dos seus senhores." (Provérbios 25:13)

Em todo este caso cubano um homem se destaca no horizonte de minha memória.

Quando irrompeu a guerra entre a Espanha e os Estados Unidos, o que importava a estes era comunicar-se com o chefe dos insurretos, Garcia, que sabiam encontrar-se em alguma fortaleza no interior do sertão cubano, mas sem que se pudesse dizer exatamente onde. Era impossível um entendimento com ele pelo correio ou pelo telégrafo. No entanto, o Presidente precisava de sua colaboração o mais rapidamente possível.

O que fazer?

Alguém disse ao presidente: "Há um homem chamado Rowan; e se alguma pessoa é capaz de encontrar Garcia, há de ser Rowan".

Rowan foi trazido à presença do Presidente, que lhe confiou uma carta com a incumbência de entregá-la a Garcia. De como este homem, Rowan, tomou a carta, meteu-a num invólucro impermeável, amarrou-a ao peito, e após quatro dias, saltou de um barco sem sequer uma cobertura, alta noite, nas costas de Cuba, de como se embrenhou no sertão para depois de três semanas surgir do outro lado da ilha, tendo atravessado a pé um país hostil, e entregue a carta a Garcia, são coisas que não vem ao caso narrar aqui pormenorizadamente.

O ponto que desejo frisar é este: McKinley, o presidente, deu a Rowan uma carta para ser entregue a Garcia; Rowan tomou a carta e nem sequer perguntou: "onde é que ele está?" Pelo Eterno! Eis aí um homem cujo busto merecia ser fundido em bronze e sua estátua colocada em cada escola do país. Não é somente de sabedoria livresca que a juventude precisa, nem somente de instrução sobre isto ou aquilo. Precisa sim de um endurecimento das vértebras que os farão ser fiéis a uma crença; para agir imediatamente, concentrar as energias: dar conta do recado -- "Levar uma mensagem a Garcia".

O general Garcia está morto agora, mas há outros Garcias.

A nenhum homem que se tenha empenhado em levar avante uma grande empresa, em que a ajuda de muitos se torna necessária, têm sido poupados momentos de verdadeiro desespero ante a imbecilidade de um grande número de homens, ante a inabilidade ou falta de disposição de concentrar a mente numa determinada coisa e fazê-la.

A regra geral tem sido: assistência irregular, desatenção tola, indiferença irritante e trabalho mal feito.

Ninguém pode ser verdadeiramente bem sucedido, salvo se lançar mão de todos os meios ao seu alcance para fazer com que outros homens o auxiliem, a não ser que Deus Onipotente, na sua grande misericórdia faça um milagre, enviando-lhe como auxiliar um anjo de luz.

Leitor amigo, tu mesmo podes tirar a prova.

Estás sentado no teu escritório, rodeado de empregados. Pois bem, chama um deles e pede-lhe:
- Queira ter a bondade de consultar a enciclopédia e fazer uma descrição resumida de corrégio.

Dar-se-á o caso de o empregado dizer calmamente: "sim senhor", e executar o que lhe pediste?

Nada disso! Olhar-te-á admirado para fazer uma ou algumas das seguintes perguntas:
Quem é ele?
Que enciclopédia?
Onde é que está a enciclopédia?
Fui eu acaso contratado para fazer isso?
E se Carlos o fizesse?
Já morreu?
Precisa disso com urgência?
Não quer que traga o livro para que o senhor mesmo procure?
Para que quer saber disso?

E aposto dez contra um que, depois de teres respondido tais perguntas, explicando a maneira de procura dos dados pedidos e a razão por que deles precisas, teu empregado irá pedir a um companheiro que o ajude a encontrar Corrégio e depois voltará para te dizer que tal homem não existe.

Evidentemente pode ser que eu perca a aposta, mas segundo a regra e a conduta geral, aposto na alternativa certa.

Ora, se fores prudente, não te darás ao trabalho de explicar ao teu "ajudante" que Corrégio se escreve com C e não com K, mas limitar-se-á a dizer calmamente, esboçando o melhor sorriso:

- "Não faz mal; não te incomodes".

E, dito isso, levantar-te-ás e procurarás tu mesmo.

E esta dificuldade de atuar independente, esta incapacidade moral, esta fraqueza de vontade, esta falta de disposição de solicitamente se pôr em campo e agir, são as causas que impedem o advento do socialismo puro. Se os homens não tomam iniciativa de agir em seu próprio proveito, que farão se o resultado de seu esforço redundar em benefício de todos? Por enquanto parece que os homens ainda precisam ser dirigidos.

O que mantém muito empregado no seu posto e o faz trabalhar é o medo de, se não o fizer, ser despedido no fim do mês.

Anuncia precisar de um taquígrafo, e nove entre dez candidatos à vaga não saberão ortografar nem pontuar - e, o que é mais grave, pensam não ser necessário sabê-lo.

Poderá uma pessoa destas entregar uma carta para Garcia?

- "Vê aquele guarda-livros?", dizia-me o chefe de uma grande fábrica.

- "Sim, que tem?"

- "É um excelente guarda-livros. Contudo, se o mandasse dar um recado, talvez se desobrigasse da incumbência a contento, mas também podia ser que no caminho entrasse em duas ou três casas de bebidas e que, quando chegasse ao seu destino já não se recordasse sequer da tarefa que lhe fora dada".

Será possível confiar-se a tal homem uma carta para ser entregue a Garcia?

Ultimamente temos ouvido expressões sentimentais, demonstrando simpatia para com os pobres entes que lutam de sol a sol, para com os infelizes desempregados à cata do trabalho honesto, e tudo isso, quase sempre, entremeado de muita palavra dura para com os homens que estão no poder.

Nada se diz do patrão que envelhece antes do tempo, num esforço inútil para induzir eternos desgostosos e descontentes a trabalhar conscienciosamente. Nada se diz de sua longa e paciente procura de pessoal, que, no entanto, muitas vezes nada mais faz do que "matar o tempo", logo que ele volta as costas.

Não há empresa que não esteja despedindo pessoal que se mostre incapaz de zelar pelos seus próprios interesses, a fim de substituí-lo por outro mais apto. Este processo de seleção por eliminação está se operando incessantemente com a única diferença que, quando os tempos são maus e o trabalho escasseia, a seleção se faz mais escrupulosamente, pondo-se fora, para sempre, os incompetentes e os inaproveitáveis. É a sobrevivência do mais capacitado. Cada patrão, no interesse comum, trata somente de guardar os melhores, aqueles que podem levar a mensagem a Garcia.

Conheço um homem de aptidões realmente brilhantes, mas sem a fibra necessária para dirigir um negócio próprio, e que ainda se torna completamente nulo para qualquer outra pessoa devido à suspeita que constantemente abriga, de que seu patrão o esteja oprimindo ou tencione oprimi-lo. Sem poder mandar, não tolera que alguém o mande. Se lhe fosse confiada uma mensagem a Garcia, retrucaria, provavelmente: "Leve-a você mesmo".

Hoje esse homem perambula errante pelas ruas em busca de trabalho, em estado quase de miséria. No entanto ninguém que o conhece se aventura a dar-lhe trabalho, porque é a personificação do descontentamento e do espírito de discórdia. Não aceitando qualquer conselho ou advertência, a única coisa capaz de nele produzir efeito seria um bom pontapé dado com a ponta de uma bota de número 44, sola grossa e bico largo.

Sei, não resta dúvida, que o indivíduo moralmente aleijado como este, não é menos digno de compaixão. Vertamos também uma lágrima pelos homens que se esforçam por levar avante uma grande empresa, cujas horas de trabalho não estão limitadas pelo som do apito e cujos cabelos ficam muito cedo envelhecidos na incessante luta em que estão empenhados contra a indiferença desdenhosa, contra a imbecilidade crassa e a ingratidão atroz, justamente daqueles que sem seu espírito empreendedor, poderiam andar famintos e sem lar.

Dar-se-á o caso de eu ter pintado a situação em cores demasiado carregadas?

Pode ser que sim; mas quando todo mundo se prende a divagações, quero lançar uma palavra de simpatia ao homem que dá êxito a um empreendimento, ao homem que, a despeito de uma porção de empecilhos, sabe dirigir e coordenar os esforços de outros e que, após o triunfo, talvez verifique que nada ganhou. Nada, salvo a sua simples subsistência.

Também eu carreguei marmitas e trabalhei como jardineiro, como também já fui patrão. Sei, portanto, que alguma coisa se pode dizer de ambos os lados.

Não há excelência na pobreza em si mesma; farrapos não servem de recomendação. Nem todos o patrões são gananciosos e tiranos da mesma forma que nem todos os pobres são virtuosos.

Todas as minhas simpatias pertencem ao homem que trabalha conscientemente, quer o patrão esteja, quer não, e ao homem que, ao lhe ser confiada uma carta para Garcia, tranqüilamente toma a missiva, sem fazer perguntas idiotas, sem a intenção oculta de jogá-la na primeira sarjeta que encontrar, ou praticar qualquer outro gesto que não seja entregá-la ao destinatário.

Este homem nunca fica "encostado", nem tem que se declarar em greve para forçar um aumento de ordenado.

A civilização busca ansiosa, insistentemente, homens nestas condições. Tudo que tal homem pedir, conceder-se-á. Esse tipo de homem é tão raro, que nenhum patrão pode pagar o preço de deixá-lo ir embora. Precisa-se dele em cada cidade, em cada vila, em cada lugarejo, em cada escritório, em cada oficina, em cada loja, fábrica ou venda.

O mundo clama por isso: precisamos dele, e precisamos com urgência -- do homem que possa levar UMA MENSAGEM A GARCIA.



Texto original: Message to Garcia at The Project Gutenberg

Nota: eu resolvi transcrever o texto aqui porque havia um link em outro post para um site com esse conteúdo, mas que saiu do ar. Portanto, agora está postado aqui.

9 de dezembro de 2011

Está nas maiúsculas ou nas minúsculas?

Meu notebook é o segundo que tenho, que não indica se o CapsLock está ligado ou não. Parece que essa moda pegou e são poucos os netbooks que têm essas luzinhas.

Com isso, muitas vezes não sei se vou digitar em maiúsculas ou minúsculas. Para programar isso incomoda bastante.

Como no Ubuntu 10.04 não há uma forma nativa de saber esse status do teclado, procurei e encontrei o Indicator-Keylock.

Ele mostra, na barra superior do Ubuntu, se estou com o keylock ligado:



Bem que o Indicator-Keylock poderia já vir na distro, né?

Fonte: www.omgubuntu.co.uk/2010/09/indicator-keylock-ubuntu

Use sempre git merge --no-ff

No artigo Mexi no branch errado. E agora? eu encerro recomendando usar sempre o comando git merge --no-ff, mas por que?

Quando você faz um merge, o git junta dois branches em um só. A título de curiosidade, a palavra merge significa "combinar, unir, misturar".

Em alguns casos o git apenas inclui as suas modificações, sem deixar nenhum rastro do merge. A opção --no-ff diz ao git que ele tem sempre que criar um commit, indicando que foi feito um merge.

Isso vai fazer com que seu histórico tenha mais commits, mas vai te salvar quando você descobrir que fez um merge no branch errado, porque você vai poder fazer o reset.

Então, use sempre git merge --no-ff

Aí fica a pergunta: se essa opção é tão importante, por que esse não é o comportamento padrão do git? Bem, só perguntando pro Linus Torvalds, né?

Mexi no branch errado. E agora?

Trabalhar com git é bom, mas enquanto você está se acostumando aos branches, é normal se pegar fazendo o seguinte:
  • Descobrir que está dando manutenção em programas no branch errado
  • Se desesperar
  • Depois de uma respirada, tirar um backup do diretório que você está trabalhando, para não perder nada do que fez
  • Fazer um novo clone do origin em um novo diretório
  • Nessa nova cópia do repositório, criar ou entrar no branch correto
  • Rodar um git diff --stat no diretório que você tirou o backup para ver o que foi modificado
  • Copiar os arquivos que foram modificados para a nova cópia do repositório
  • Continuar trabalhando aliviado, mas ainda desconfiado de que salvou tudo certinho
  • Guardar a cópia errada do seu diretório (zipado de preferência) até se certificar que não há problemas.

Isso tudo pode ser agilizado usando o comando git stash, que significa "guardar em local seguro". Vejamos um exemplo.

Suponha que temos os branches master e nova-consulta. Por algum vacilo, eu começo a mexer no master, quando eu deveria mexer no nova-consulta.

Se eu ainda não fiz commit, o que alterei está apenas no meu diretório. Ainda não foi para o git, certo? Então eu descubro que estou no branch errado.

Eis os comandos que vão organizar meu trabalho, estando eu no branch errado:
$ git stash
$ git stash branch temporario
$ git checkout nova-consulta
$ git merge --no-ff temporario
$ git branch -d temporario
O que eu fiz, exatamente?
  1. Com o git stash eu peguei minhas mexidas e guardei em lugar seguro. Nisso, o master voltou a ficar com o conteúdo correto. Ufa!
  2. Com o git stash branch temporario eu criei um branch com elas, de nome temporario.
  3. Com o git checkout eu entrei no branch correto, nova-consulta
  4. Com o git merge eu peguei a minha mexida, que agora está no branch temporario, e incorporei ao branch correto (nova-consulta) :-)
  5. Com o último comando eu apaguei o branch temporario
Pronto, agora estou no branch correto, salvei o branch master de uma manutenção indesejada e posso continuar trabalhando normalmente.

Nota: use sempre a opção --no-ff em seus merges! Para mais detalhes, leia um artigo resumido sobre isso.

7 de dezembro de 2011

Qualquer letra serve pra mim

Que detalhes fazem você sentir-se confortável ao escrever seus programas?

Uma boa cadeira, um teclado macio, mouse que não falha, monitor bem colocado, mesa na altura certa, boa iluminação... tudo isso é importante, mas faltou uma coisa: o tipo de letra (fonte) que você usa.

Já vi muitas pessoas que não se preocupam com isso, e codificam usando a fonte System ou Courier, no Windows. Eu, particularmente prefiro fontes que com boa nitidez e que diferenciem os caracteres.

Abaixo, alguns exemplos de boas fontes para programar:

Anonymous Pro


DejaVu Sans Mono


Mensch


Monaco


Ubuntu Mono
Eu já testei várias fontes e acabei escolhendo essas acima, que acho serem indicadas para nossa atividade de codificação. Usei todas por um tempo para experimentá-las, exceto a Ubuntu Mono, que conheci hoje e ainda estou experimentando, mas estou gostando.

Dessas fontes que apresentei, quero comentar sobre duas delas:
  • Monaco: eu me apaixonei por essa fonte desde que a vi pela primeira vez, numa apresentação feita num Mac e que mostrava o trecho de um  programa. Um dia eu descobri que era a fonte Monaco. Baixei e comecei a usá-la. Eu acho essa fonte muito bonita e com boa diferenciação entre os caracteres.
  • DejaVu Sans Mono: quando usei o Ubuntu 10.04 pela primeira vez, notei que a fonte padrão do terminal era muito boa. Entrei no Gedit e vi que era agradável também para editar programas. Fiquei realmente admirado por ela ser de tão boa qualidade e já vir ajustada como default. Se você não é tão fissurado em fontes como eu, use-a sem medo de errar. A DejaVu Sans Mono pode ser identificada como Monospace no Ubuntu 10.04, já que é a fonte mono-espaçada (mesma largura para todos os caracteres) padrão.
Quero destacar que a Canonical está de parabéns. Hoje conheci a família de fontes Ubuntu e dá para perceber que existe investimento numa área até então ignorada pelas distros Linux: design de fontes. A Ubuntu Mono ficou muito boa.

Quando você for escolher uma fonte, é importante analisar alguns itens bem objetivos:
  1. Veja se é fácil diferenciar esses caracteres: O, Q e 0
  2. Esses também: l, I e 1
  3. Note se esses caracteres são agradáveis à vista: &, <, >, ?, {, }, [ e ]
  4. A fonte é muito alta ou muito larga?
  5. Como é a aparência dela se eu aumentar o tamanho para outra pessoa ver de mais longe?
  6. E se eu precisar ver mais código de uma vez, e precisar diminuir o tamanho? Ainda fica legível?
Entretanto, existe um ponto subjetivo, que é o gosto pessoal. No final das contas é ele quem vai definir a fonte que você vai usar.

Abaixo, a lista das fontes mostradas nesse artigo:
Sugiro que você não use a fonte padrão que seu editor ou sistema operacional traz, sem analisar outras opções. Experimente algumas, com tamanhos diferentes. Isso pode tornar você mais produtivo.

E você, qual fonte prefere usar para programar?

Temas no Vim

Nem todos gostamos das mesmas cores, por isso os editores de programas que se prezam permitem personalizarmos temas, também conhecidos como esquema de cores ou color schemes.

O Vim, claro, não poderia ser diferente.

O Color Sampler Pack é um pacotão com mais de 100 temas para personalizar o visual do seu Vim. Se você instalar todos, vai juntar lixo no diretório ~/.vim/colors sem necessidade. Portanto, recomendo ver todos eles antes de instalar definitivamente o seu preferido.

O editor Textmate faz muito sucesso no mundo Mac por algumas características. Os conjuntos de cores do Textmate é uma delas. A boa notícia é que você pode ter os temas do Textmate no Vim. O site Coloration faz a conversão deles sem nenhum esforço.

O tema Solarized é bastante discreto e agradável. Gostei bastante dele, quando o vi por uma indicação do @gilsonfilho.

Ultimamente eu tenho usado o tema Moria, que também é agradável, com algumas pequenas modificações.

Se você tem um tema preferido ou um site com temas para Vim ou Textmate, compartilhe.

Atualização em 16/01/2012: @rochacbruno indicou o Villustrator, que permite montar seu tema visualmente no navegador. Gostei muito.

6 de dezembro de 2011

Apagando branches locais que não existem mais no origin

Continuando a falar sobre Branches remotos no git,  vamos dar um passo adiante, já que resolvemos adotar o modelo de branching do pessoal da Nvie porque o nosso estava meio confuso e com algumas falhas.

Esse artigo da Nvie é a explicação mais clara que vi sobre o assunto. Normalmente lemos sobre os comandos do git e das possibilidades, mas raramente encontramos material sobre workflow eficiente.

Esse post vai te contar como apagar branches locais que já existiram no origin, mas que foram apagados de lá. Se não existem mais lá, também não precisam existir na sua cópia local.

O git não administra automaticamente a sincronização desses branches e isso é bom. Se eu quiser manter algum branch comigo por algum motivo, posso deixá-lo sem problema. Mas no dia-a-dia, acaba ficando sujeira no seu repositório local. Os branches de novas features ou releases e hotfixes criados e apagados por seus colegas ficam ali escondidos.

Para enxergá-los, use o comando git branch -a.
$ git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master
  remotes/origin/novo-cliente
  remotes/origin/painel-de-controle

No meu caso, os branches "novo-cliente" e "painel-de-controle" já foram apagados do repositório remoto (o origin), mas continuam aqui no meu repositório local.

Para livrar-me deles, usei o comando git remote prune origin.
Se você quiser saber o que será eliminado antes de apagá-los do seu repositório local, use a opção --dry-run: git remote prune --dry-run origin.

Depois de rodar o git remote prune origin, meu repositório local ficou equiparado ao origin, em termos de branches:
$ git remote prune origin
Pruning origin
URL: https://xxxxxxx@yyyyyyy.com/xxxxx/teste.git
 * [pruned] origin/novo-cliente
 * [pruned] origin/painel-de-controle
$ git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master

Em breve falaremos mais sobre o funcionamento desse workflow e os comandos que podem te ajudar a trabalhar com ele.

5 de dezembro de 2011

Backup do diretório atual

Aqui na X4 usamos git e eu confesso que muitas vezes tenho medo de me perder nos merges e branches. Os recursos são ótimos, mas ainda estou me acostumando com eles.

Então, fiz um script para tirar um backup e administrar versões anteriores do diretório corrente, para simplificar minha vida.

O backup não é automático. Rodo sempre que preciso, quando preciso.

Olha aí:
#!/bin/bash

# @brief Backs up current dir plus 3 older versions (.bak, .v-1.bak, .v-2.bak, .v-3.bak).
# @author viniciusban@gmail.com


echo "Let's back $PWD up"
from="./"
from_display="."

for i in 3 2 1 0
do
    to=$from
    to_display=$from_display
    if [ $i -gt 0 ]; then
        from="${PWD}.v-${i}.bak"
    else
        from="${PWD}.bak" # there's no v-0.bak
    fi

    from_display=`basename $from`

    if [ "$to" = "./" ]; then # 1st time
        if [ -d "$from" ]; then
            echo -n "Erasing the old fashioned ${from_display}... "
            rm -rf $from
            echo "OK"
        fi
    else
        if [ -d "$from" ]; then
            echo -n "Renaming ${from_display} to ${to_display}... "
            mv $from $to
            echo "OK"
        fi
    fi
done

echo -n "Creating a brand new ${from_display} from ${PWD}... " # I'm sure it's $from_display
cp -r  $PWD $from # I'm sure it's $from
echo "OK"

Eu dei um nome bem sugestivo a esse script(bakdir) e coloquei-o no ~/bin, que está no meu path.

Copie e use, se lhe for útil.

2 de dezembro de 2011

Um relato evolucionista

Meu tataravô tinha um punhado de pó de ferro guardado.

Meu bisavô não jogou fora, continuou guardando, sem mexer naquilo. Era uma relíquia do pai dele.

Quando meu avô cresceu, contou que nunca mexeu, mas dentro daquele saquinho não tinha nenhum pó de ferro. Havia ali peças de um relógio, todas soltas, independentes.

Meu pai conta que, quando cresceu e foi arrumar as coisas no sótão, lembrou dessa história e foi verificar. E, mesmo sem nunca ter aberto aquele saquinho, encontrou um relógio de bolso funcionando. Mostrador branco, ponteiros pretos, algarismos romanos, correntinha pra pendurar.

Ontem, eu resolvi dar uma olhada naquele misterioso saquinho. Nunca mexi nele porque sempre achei que havia algo de mágico naquilo. Para minha surpresa, estava lá um relógio Aqualang com ponteiros fluorescentes, marcador de profundidade e cronômetro. Resolvi pegar pra usar.

Tem gente que acha isso absurdo, mas para mim, não. Afinal, eu acredito na evolução.


Nota de esclarecimento
Esse artigo é uma ilustração.
Eu sou cristão e, como tal, acredito que o Universo foi criado por Deus. Acredito no relato bíblico do livro de Gênesis.

Portanto, sou criacionista. Entre outros motivos, por não ter fé suficiente para acreditar nas hipóteses (não são teorias porque não podem passar pelo crivo do método científico) evolucionistas.

18 de novembro de 2011

Notebook Microboard Iron i5 - Minha experiência

Antes de você ler esse post, quero registrar meus parabéns à Microboard pela dedicação e solução do defeito da dobradiça do meu notebook.

Caso você precise resolver alguma coisa com a Microboard, leia o relato e como as coisas foram se desenrolando. Você vai perceber que a empresa não fica dando respostas padrão quando percebem que o problema não é o padrão. Gosto de empresas com essa atitude.

Eis aqui o log de interações até a solução do problema da dobradiça do meu notebook:
  • [18/11/2011] A Microboard entrou em contato pelo Twitter, pedindo meu telefone. Informei. Vamos ver o que (e quando) vai acontecer.
  • [21/11/2011] A Microboard entrou em contato por telefone. Como não há assistência técnica credenciada no Rio de Janeiro, combinamos que vou enviar o notebook para a fábrica. Vai e volta por Sedex, sem custo para mim. Agora vou tentar arranjar outro computador, tirar backup dos dados e enviar para eles. Gostei do atendimento da Elaine. Muito atenciosa.
  • [22/11/2011] A Microboard designou uma assistência técnica aqui no Rio de Janeiro e abriu uma ordem de serviço pra mim. A Elaine me ligou novamente informando a respeito do andamento do processo. Não precisarei enviar o computador pelos correios. Agora, vou bater novas fotos para o problema ficar mais visível e para que eles possam enviar as peças necessárias para a assistência técnica.
  • [23/11/2011] Bati novas fotos do notebook (abaixo), e enviei à Microboard. Agora, os técnicos de lá vão olhar o problema e mandar as peças necessárias para o reparo.
  • [25/11/2011] A Microboard me informou por DM no Twitter que as peças para consertar meu notebook serão enviadas na 2a feira, 28/11/2011.
  • [28/11/2011] A microboard me informou por DM no Twitter que as peças foram enviadas por transportadora. Perguntei qual a previsão de chegada aqui no Rio. Estou aguardando a resposta deles.
  • [29/11/2011] A Microboard me informou por DM no Twitter que as peças devem chegar amanhã (30/11/2011) na assistência técnica aqui no Rio. Vamos continuar aguardando.
  • [01/12/2011] A Microboard me informou por email que as peças chegaram ontem à assistência técnica, aqui no Rio, e me passou os dados para localização delas. Liguei na assistência técnica 2 vezes, mas a atendente me disse que não poderia abrir a caixa com as peças que chegaram porque o sistema da Microboard estava fora do ar. Enquanto isso, a Elaine continua acompanhando o processo. Me mandou um email perguntando se consegui agendar o conserto. Ainda não, mas amanhã cedo ligo na assistência técnica novamente e vamos ver o que a atendente me diz.
  • [02/12/2011] Minhas peças chegaram mesmo na assistência técnica. 2a feira levarei meu notebook p/ consertar.
  • [05/12/2011] Acabei de voltar da assistência técnica com o notebook consertado. Quero parabenizar a Elaine e aos profissionais da Microboard que de alguma forma se envolveram para a solução do meu problema. Registro também a eficiência da Rede Fácil, assistência credenciada aqui no Rio de Janeiro. Com a ajuda da Fernanda, pude conversar diretamente com o técnico e explicar o histórico do problema. Em menos de 1 hora meu computador estava consertado e eu posso novamente voltar a trabalhar normalmente, usando o notebook na finalidade para a qual ele foi adquirido.

Em abril/2011 eu comprei um notebook Microboard Iron i5, com 4GB de memória. Já estava na hora de fazer um upgrade no meu antigo CCE, Core 2 Duo, com 2GB de memória e 4 anos ininterruptos e felizes de estrada, sem nunca me deixar na mão.

A configuração é boa, veio com Linux Debian, Webcam, Drive de DVD, saída HDMI, 3 USB, Bluetooth, o teclado é uma maravilha, a tela também muito boa. Pra mim foi perfeito, tudo funcionando no Linux. O notebook é leve, bonito e com bom desempenho.

Mas em junho/2011 uma das dobradiças da tampa soltou. Como era um detalhe, fiquei usando o computador assim mesmo, mas com cuidado.

Em setembro/2011, veio o pesadelo: o note parou de reconhecer a fonte de energia. Levei na assistência técnica e deixei-o lá. Foram 27 dias sem o computador!

Quando voltou, a fonte já era reconhecida novamente e a dobradiça estava consertada. Fiquei feliz. Tudo novo de novo. Apesar da demora, a Microboard me atendeu dentro do prazo da lei: 30 dias.

Hoje pela manhã, 18/11/2011, ao abrir a tampa do notebook, a mesma dobradiça quebra novamente! Desta vez, de um modo estranho. Parece que os parafusos que prendem a carcaça soltaram-se dela.

Abaixo, as fotos da dobradiça quebrada.
Carcaça da tampa separada do corpo do notebook.

Novamente a dobradiça quebrada.
A peça metálica que é parafusada na carcaça, soltou. Note como a dobradiça está completamente solta.

A mesma peça, vista de trás. Os parafusos estão nela.

Novamente a peça que soltou. Agora, num ângulo mais separado da carcaça da tampa.



Imediatamente entrei em contato com o SAC da Microboard, que me disse que a dobradiça não tem garantia. Mas que eu poderia enviar o notebook à fábrica deles, que a mão-de-obra seria gratuita. Essa dobradiça tem 1 mês de uso, pois foi trocada, lembra?

Quem me conhece sabe que meus notebooks parecem novos depois de anos de uso. Tenho um HP com 9 anos de idade. Usei um CCE por 4 anos e ele está inteiro até hoje.

Se existe uma coisa que tenho cuidado é com computadores. Até porque eu uso o notebook para trabalhar. Vivo dele!

Então, quero deixar registrado que os notebooks da Microboard são bonitos e com ótima configuração, mas precisam melhorar na robustez da dobradiça.

Esse é um item que merece atenção. Principalmente em configurações que notoriamente são adquiridas por profissionais, não por quem usa o notebook para ficar brincando, ou por mero capricho.

Seria muito bom se a Microboard pudesse consertar meu computador sem eu ter que deixá-lo na assistência técnica por mais dias. Afinal, o problema é simples de identificar e de solucionar. Como essa dobradiça tem 1 mês, nada mais justo que ser trocada sem custo, concorda?

Peço que quem ler esse post divulgue-o no twitter, email, sinal de fumaça... sei lá. Só assim é possível que as empresas dêem maior atenção aos projetos desenvolvidos no Brasil e aos clientes também.

17 de outubro de 2011

Branches remotos no git

Aqui no trabalho estamos desenvolvendo um produto e precisamos lidar com branches no git.

Tínhamos muitas dúvidas, pesquisamos, conversei com o @gilsonfilho e @rr_martins (eles manjam) e tracei nosso modelo de trabalho. Recomendo estudar o Git Community Book.

Se você trabalha ou precisa trabalhar em grupo com o git, mas não usa os branches ainda, seguem algumas dicas de comandos.

Você criou um branch local, fez seu commit e agora quer criá-lo no seu repositório remoto. Simples:
$ git push meu_repo_remoto meu_branch

Agora, por algum motivo, você precisa salvar seu branch local com um nome diferente lá no repositório remoto:
$ git push meu_repo_remoto meu_branch_local:meu_branch_remoto

Você já terminou seu trabalho nesse branch, fez o merge com o master e agora quer apagá-lo do repositório remoto? Simples:
$ git push meu_repo_remoto :meu_branch_remoto_que_nao_quero_mais


Existe também a situação de você fazer clone de um repositório com alguns branches já existentes e querer continuar o desenvolvimento naquele branch específico. Suponhamos que nesse repositório remoto exista o branch painel-de-controle e você quer mexer em algum programa nele. Para isso, depois do git clone use:
$ git checkout -b painel-de-controle origin/painel-de-controle

Isso faz com que seu branch painel-de-controle fique ligado ao branch painel-de-controle existente no repositório que você acabou de clonar, o origin. Depois disso, é só fazer commit e push normalmente.

Use branches (vou escrever mais sobre isso em breve). Branches, são ótimos!

Se você tem alguma dica pra ajudar, comenta aí.

(Leia a parte 2 desse mesmo assunto)

23 de setembro de 2011

Quando o que temos são as incertezas

Bem, estou novamente trabalhando como desenvolvedor web. Na verdade, sou uma mistura de Scrum Master, desenvolvedor e líder técnico. Se é pra ser multidisciplinar, que sejamos nós mesmos! Aqui na X4IDS isso é normal e incentivado.

Nesse projeto, somos uma equipe de quatro pessoas e uma delas trabalha remotamente, em outro Estado. No primeiro dia do projeto delineamos um objetivo pequeno, claro e palpável. Era nossa primeira user story.

Na prática, tínhamos apenas uma ideia e várias incertezas. Bem típico de um projeto de software, não é? Mas nem sempre a realidade mostra-se tão clara. Dessa vez, demos sorte.

Dividimos nossa user story em tarefas e escolhemos os respectivos responsáveis. Não conseguimos estimar o tamanho de nenhuma delas, pois era uma tecnologia até então desconhecida de todos nós. Se usássemos o Planning Poker, teríamos uma coleção de aliens (ou de interrogações) na mesa! Se partíssemos para o T-Shirt Sizing, teríamos uma prateleira inteira de roupas XXL.

Trabalhamos cinco dias. Fizemos nossas reuniões diárias religiosamente. Conversamos. Criamos novas tarefas em função dos sucessos e fracassos das tarefas originais. Sugerimos. Pesquisamos. Experimentamos. Modificamos. Aprendemos.

Ontem, no início da tarde, concluímos nossa user story. Estamos praticando o Lean Software e um pouco de Scrum. Estamos validando ideias e entregando valor cedo. Já temos algumas certezas. Estamos felizes.

Quando o que temos são as incertezas, resta-nos dar um passo de cada vez. "Baby steps, baby. Baby steps."

Até já pensamos o que vamos aprontar na Campus Party 2012 com esse projeto.

Em breve iniciaremos tech talks aqui na empresa e estamos ansiosos.

E você, como tem tocado seus projetos e compartilhado o conhecimento nas equipes?

Atitudes necessárias para sucesso nos projetos

Hoje eu assisti ao filme "Planeta dos Macacos: A Origem". Não sou evolucionista, portanto, não me ative a esse aspecto do filme. Considerei-o como um filme sobre liderança, como podemos ver no trailer a seguir:


Cesar, o chimpanzé que é o personagem central, usa racionalmente a psicologia para se estabelecer como líder dos macacos. Não há medo de lidar com outros mais fortes, nem de estabelecer uma relação de interdependência com eles, onde a inteligência une-se à força e, juntas, alcançam seu ideal.

Ele cria esperança aonde não havia. Permite que os macacos pratiquem suas capacidades. Estabelece acordos, não flexibiliza princípios. Também observa o ambiente e tira proveito das limitações, transformando-as em trampolins para a genialidade. Vemos claramente o papel daqueles que não são os líderes, que conhecem o seu potencial, mas que decidem fazer parte do grupo.

Sob essa ótica, recomendo o filme. Para gerentes de projeto, coordenadores de equipe ou empreendedores, considero uma boa oportunidade de aprendizado. Não só com os símios, mas também com os humanos.

Pegando carona, listo abaixo alguns vídeos que mostram alguns aspectos importantes para desenvolvedores de software em geral.

Ter informação faz toda a diferença:


Conhecer as regras do jogo e adaptar-se durante a partida, podem tornar você um vencedor:

E lembre-se: apenas boas intenções não bastam!


15 de setembro de 2011

Boas práticas de programação

@R4bugento twitou 40 dicas sobre boas práticas de programação e resolvi colaborar um pouco:
  1. Escreva código pra outras pessoas entenderem.
  2. Tente escrever código que não precise de comentários para ser entendido.
  3. Escreva pouco código. Quanto mais código, maiores as chances de problemas.
  4. Escreva no mesmo padrão que sua equipe já codifica, se você entrar depois da turma.
  5. Sempre que possível, escolha uma linguagem produtiva.
  6. Leia código dos outros.
  7. Aprenda a dar manutenção em programas que outra pessoa fez.
  8. Nunca altere o conteúdo do contador do for. E se precisar fazer isso, documente.
  9. Aprenda TDD.
  10. Pratique.
Alguma outra dica importante que esqueci?

12 de setembro de 2011

As estimativas são amigas

"Não conhecer a velocidade da equipe é a causa raiz de 100% dos planejamentos fracassados das releases [de produtos]." (Jeff Sutherland, criador do Scrum).

Uma pergunta natural que qualquer cliente faz é: "quanto tempo isso vai demorar?" Nós, de T.I, não gostamos dessa pergunta porque somos ruins para estimar prazo. Afinal, quase 70% dos projetos de T.I fracassam.

Duvida? Veja a Pesquisa que o Standish Group divulgou em 2009 sobre isso.

Fazer estimativas próximas do real é um passo importante que a T.I dá em direção ao tão falado "alinhamento com o negócio", mas que ainda parece distante. Quase nos ofendemos quando alguém pergunta em quanto tempo vamos entregar o que estamos fazendo.

Não gostamos de sermos fiscalizados, porque não temos coisa boa pra mostrar. Lembra daquele ditado que diz "quem não deve, não teme"?

As metodologias ágeis vieram para nos ajudar com isso, tornando as estimativas aliadas da equipe de desenvolvimento. Alguns pontos e dicas básicas:

  1. Não demore muito fazendo as estimativas. O importante mesmo é entregar software funcionando e não adivinhar em quanto tempo as tarefas serão entregues.
  2. Estimar não significa assinar um contrato de morte, em caso de erro.  É errando que se aprende.
  3. As estimativas vão melhorando à medida que a equipe vai conhecendo o projeto, desbravando os meandro técnicos específicos dele e dominando as regras de negócio.
  4. Não tente estimar em horas. Estime em Story Points ou T-Shirt Sizing.
  5. A mesma história certamente terá estimativas diferentes, se feitas por pessoas diferentes. As experiências de cada uma delas é determinante para a estimativa.
  6. Inclua as estimativas na retrospectiva do Sprint, para que o grupo tenha oportunidade de dizer o que aprendeu com elas.
  7. Não use as estimativas contra sua equipe. Se você fizer isso, a equipe vai começar a colocar "gordurinha" nas estimativas. Aí, meu caro, começou o joguinho do "me engana que eu gosto".
Leia mais em "Scrum: Why Story Points Are Better Than Hours"
Sobre T-Shirt Sizing estimation, leia "T-Shirt Estimates", um artigo bem prático sobre o assunto.

Livre-se do que não presta

Mark Parker (CEO da Nike) -- Você tem algum conselho pra mim?
Steve Jobs (CEO da Apple) -- Só uma coisa. A Nike faz alguns dos melhores produtos do mundo. São coisas que as pessoas cobiçam. Mas vocês também fazem muita porcaria. Livre-se do que não presta e foque no que é bom.

"As pessoas pensam que foco significa dizer sim para o que você está focando. Mas não é, de jeito nenhum, o que essa palavra significa. Ela significa dizer não para centenas de outras boas ideias que aparecem. Você precisa pinçar com cuidado. Na verdade, eu sou tão orgulhoso das coisas que não fizemos, como das que fizemos. Inovação é dizer 'não' para 1000 coisas." (Steve Jobs)

11 de setembro de 2011

Ética

Ética é fazer a coisa certa, mesmo quando ninguém está vendo.

1 de setembro de 2011

Dicas para melhorar apresentações de slides

Muita gente se pega com a tarefa de preparar slides para uma apresentação. E agora?

Calma. Veja algumas dicas úteis

Tecnologia da Comunicação

(Gerente) - Bom dia, pessoal.
(José) - Bom dia.
(Maria) - Bom dia.
(Gerente) - Como estão as coisas? Os processamentos da noite já acabaram?
(João) - Bom dia.
(José) - A minha parte já. ;-)
(Carlos) - A minha não. Deu erro e tive que submeter novamente.
(Érica) - Bom dia.
(Gerente) - E o que vamos fazer p/ terminarmos a tempo?
(Maria) - É... não confere o serviço... isso que dá! rsrsrs
(Carlos) - Estou acompanhando. Acho que termina em 30 min.
(Gabriel) - Bom dia.
(Gerente) - Fique de olho e me avise sobre qq novidade, ok?
(Denise) - Bom dia. Minha parte tb tá ok.

Você já se pegou conversando em um instant messenger (skype, msn messenger) com o colega da mesa ao lado?

Eu já. E o pior: nem era para me esconder do gerente. Ele próprio incentivava esse comportamento da equipe.

Essa conversa acima não é brincadeira, não. Acontecia mesmo. Claro que eu não coloquei tudo o que rolava. E os nomes também são fictícios. Se você está achando estranho, saiba que eu achei esquisitíssimo, quando cheguei nesse ambiente. Caótico até.

Informações sérias para o projeto eram trocadas via instant messenger. A alegação era que a mensagem era instantânea. Sim, para quem estivesse online naquele momento, né?

A situação fica mais esquisita ainda quando você pára e percebe que todos os participantes do chat estavam na mesma sala. E que tínhamos uma sala de reunião à disposição praticamente o dia todo.

Comunicados importantes? Vai por instant messenger.
Mudanças de planos? Dá-lhe instant messenger.
Cobrança de serviços? Lá vem instant messenger.

Uma conversa com todo mundo de 2 min? Prá quê?! Basta escrever no instant messenger que todo mundo lê.

Tirando o inconveniente daquelas incontáveis mensagens de: "rsrs", ":-)", ";-)", "eu tb", "eu não" e etc., talvez as piores partes sejam a falta de formalidade e a falta de comunicação olho no olho, que gera compromisso e comprometimento.

Você já tentou procurar por um texto importante em uma conferência no Skype? E o pior, a empresa dizia que esses softwares não deveriam ser usados. Mas o gerente estava lá, mandando instant messenger.

Portanto, a melhor tecnologia da comunicação, na minha opinião é o olho-no-olho, o téte-a-téte, onde não precisamos colocar emoticons para dar entonação à fala.

Líder que lidera tem que juntar as pessoas e fazer com que elas se comuniquem (dizer, falar com a boca mesmo) e olhem no olho.

A tecnologia evolui. A comunicação também. Mas precisamos saber aonde vamos dispensar a conversa pessoal.

Existe mais real-time e sincero do que o cara-a-cara?

18 de agosto de 2011

BDUF is evil

O que é BDUF, afinal?
BDUF = Big Design Up Front (Projeto Grande Logo de Cara)

BDUF é o (mau) hábito de já prever um monte de coisa que "eu sei que vai precisar lá na frente", logo no início do projeto. Ou de adivinhar o que o cliente vai pedir.

É comum vermos isso, principalmente no projeto de tabelas. À medida que o sistema vai ficando velho e pessoas que não participaram do desenvolvimenteo entram na manutenção, vamos cada vez mais ouvindo: "ah, esse campo nunca foi usado. Nem sei pra quê taí, mas não vamos apagá-lo. Vai que dá problema...".

Mas o BDUF também pode ser visto em funcionalidades básicas, "necessárias". Eu mesmo vivi isso há alguns dias ao fazer uma página que mostra uma lista com os últimos artigos postados no site. Aprontei a lista e logo pensei: "Bom, agora preciso fazer a paginação".

Depois que comecei a lógica de paginação, lembrei que esse site receberá apenas um artigo por semana. Já que seriam mostrados os últimos 25 artigos nessa página, me dei conta de que a paginação só será usada daqui a 6 meses! Como ainda estamos na fase de validação da ideia, resolvi largar a paginação por enquanto. Daqui a 5 meses eu pego nela.

BDUF is evil, mas nem sempre é fácil identificá-lo.

O risco que corremos quando temos uma abordagem assim mais "on demand", é diminuir a qualidade técnica de nossas escolhas. Para proteger-nos disso, nos princípios por trás do Manifesto Ágil constam dois itens importantíssimos:
  1. Software funcionando é a medida primária de progresso. -- Se o que você desenvolveu não será visto logo pelos usuários, você perdeu tempo. No meu exemplo acima, eles só iriam ver a paginação funcionando daqui a 6 meses!
  2. Contínua atenção à excelência técnica e bom design aumenta a agilidade. -- Essa é a vacina contra o relaxamento. Se fizermos alguma escolha técnica medíocre, vamos comer desse fruto ruim.
Já o princípio que condena o BDUF é: Simplicidade -- a arte de maximizar a quantidade de trabalho não realizado -- é essencial.

Repita comigo: "BDUF is evil! Simple working software is great!"

1 de maio de 2011

Quanto cobrar

Recebi essa mensagem em uma lista que participo e resolvi colocar aqui, pois retrata de forma descontraída a realidade do mercado de TI que vivemos no Brasil.

Nota: isso é uma brincadeira.

Quanto cobrar por:


Serviço
Valor (R$)
Logo marca, logomarca 6.000,00
Logotipozinho, logomarcazinha, marquinha e marquinhazinha (preço também válido para logotipo bem pequenininho, símbolo, desenho pra colocar no cartão e elipse e degradê) 2.250,00
Nome do logotipo 5.500,00
Impresso 855,00
Folheto de divulgação 255,00
Convitezinho 345,00
Panfleto 452,00
Um folder rapidinho 1.250,00
Prospecto 355,00
Jeitinho aqui 150,00
Folhinha / Filipeta 355,00
Folhinha pra tirar xérox mesmo (xérox não inclusas) 456,00
Uma faixa aí 2.230,00
Cartaz “que você ja pega pronto no Print Artist” 564,00
“Botar um design” no meu site 5.300,00
Desenho animado pra colocar no site 50.000,00
Uma letra girando, assim ó 250,00
Cartãozinho mixuruca 150,00
Só pra não passar em branco (Folder de aniversário de 50 anos da empresa) 6.000,00
Um site (Não interessa a quantidade de páginas, nem o que tem dentro, site é site, ué) 15.000,00
Um portal (Sem diferença para o material acima, apenas na nomenclatura) 30.000,00
“Igualzinho a esse aqui, só vai colocar o meu timbre ao invés do dele aqui em cima, entendeu? Pra não dar trabalho mesmo…” 1.000,00
Sem muitos detalhes 350,00
Quando começar a frase com:
Acrescentar mais (R$)
“Isso aí, você coloca no computador e ele faz” 1.250,00
“Eu tenho um sobrinho que faz assim…” 350,00
“Ei, você que mexe com computador…” 500,00
“Ah foi bom te ver aqui, você não é o cara da informática?” 8.000,00
“O chefe do departamento já escolheu até a letra e a cor, agora ficou fácil” 250,00
“Não, não.. você não vai ter trabalho nenhum, mesmo. É só colocar no computador mesmo” 350,00
“Na verdade o serviço JÁ ESTÁ PRONTO! É só colocar um pouco de design” 750,00
“É só uma firula mesmo né?” 450,00
“Pra enfeitar o pavão…” 360,00
“Na verdade é porque eu não tenho tempo pra fazer.” 2.500,00
“Eu confio em você, vê aí alguma coisa.” (não sabe nem o nome da empresa) 5.500,00
“Depois a gente vê uma maneira de te compensar.” 240.000,00
“Vê aí o que você faz pra mim?” 890,00
“Nossa, mas é só um site! Isso tudo?” 5.000,00
“POR PÁGINA??????” (cada vez que a pessoa repetir essa frase) 345,00
“Aproveita pra ver o que aconteceu com o antivirus daqui da loja?” 350,00
“Ah.. tá.. mas nisso já estão incluídas as fotos e as modelos né?” 150,00
“É só esticar aqui, ó” 60,00
“E você usa o computador pra isso?” 75,00
“Coisa simples” 2.500,00
“Não você não entendeu. É simples mesmo” 3.500,00
“É, você não entendeu mesmo” 4.500,00
“Só uma galeria de fotos. Quantas fotos? Ah umas 100, mas é so colocar ali no canto” 890,00
“Ué, mas é só digitar como tá aqui no jornal.” 980,00
“Escaneia daqui da revista mesmo” 200,00
“Eu quero um site” (Mecânico free-lancer) 2.800,00
“DUZENTOS E CINQUENTA REAIS???” (somar a cada grito de desespero) 50,00
“Fotolito? Não, não, não vamos contratar fotógrafo” 35,00
“Ah!! Pode pegar o logo do nosso site, não tem problema nenhum, eu autorizo. É so clicar com o botão direito do mouse em cima e ir em ‘salvar como’…” 890,00
“COMO ASSIM, SEM A IMPRESSÃO???” (afinal o cara ainda vai pagar a impressão!!) 200,00
“E quanto você cobra assim? Pra um site, é. Completo! Sim eu sei, mas mais ou menos? Tira uma média, site completo! Hum.. e outro mais simplezinho?” 450,00
“Ah mas eu achei a mesma coisa por R$ 30,00 cada página. E é serviço de confiança. O que a gente pode fazer pra chegar nisso?” (esses eu tenho vontade de xingar) 200,00
“Pois é mas eu estou vendo com outras pessoas…” 100,00
“Tá, tudo bem... e fica pronto quando? Pode me mandar uma previa por email hoje à noite? 5.000,00
(numa sexta feira às 17:55) “ok, me entrega na segunda até umas 10h, tá bom?” 8.000,00
“É que meu prazo já está estourado. Sabe como é né?” 4.580,00
Serviços extras – depois do trabalho pronto:
“Aumenta essa letra?” 50,00
“Coloca esse amarelo mais vivo?” 90,00
“Troca esse vermelho, por amarelo?” Sob consulta. Em casos como trocar o tom da pele de uma foto fica mais caro.
“Vira o rosto dela no computador, pra ficar de lado, acho q vai ficar melhor” (foto 3×4) 150,00 (e não realiza o serviço, lógico)
“E se a gente mudasse o menu pra cá? To achando isso meio parado…” (site pronto) Valor do site x 5
(Depois de pedir incessantemente pelo estetoscópio na capa do manual médico) “É mesmo, né? Não ficou muito legal….. e agora?” 6.000,00
“Puxa mais pra cá.. Isso agora mais pra cá, isso, troca essa cor.. agora inclui essa foto… podia mudar aqui né? hum… pô parace que piorou; não estou entendendo…” 8.500,00

Tem também esse video interessante sobre o relacionamento entre clientes e fornecedores: http://bit.ly/112PAJ

10 de abril de 2011

Mudar senha do keyring do Gnome

Meu sistema Linux veio com o usuário padrão do sistema operacional, mas eu resolvi criar o meu próprio.

Então, quando eu usava o Empathy, aparecia uma tela dizendo que minha senha atual (do novo usuário) não conferia com a senha utilizada para criar o keyring (do usuário que já veio instalado).

Pelo que pude perceber, não há um modo de mudar essa senha, no Debian. Mas há um jeito de colocar uma nova senha. Siga os passos abaixo:
  1. killall gnome-keyring-daemon - mata o daemon do keyring
  2. rm ~/.gnome2/keyrings - apaga o arquivo de keyrings.
Feito isso, você precisa entrar no empathy e criar novas senhas.

 Pronto, agora informe sua nova senha e... voilá.

Ativar virtualização do Intel Core i5

É possível que você tenha comprado um computador com processador Intel Core i5 e ao tentar instalar uma máquina virtual, não consiga designar mais de um processador para seu sistema virtualizado.

Isso é causado porque algumas BIOS trazem o recurso de virtualização desabilitado, por default. O motivo de ser desligado por padrão, ninguém sabe.

Para corrigir isso, no caso dos notebooks modelo Iron, da Microboard, siga os passos abaixo:
  1. Vá em www.microboard.come.br/downloads/Notebooks/Iron%20IXXX
  2. Baixe os arquivos Atualização BIOS.zip e Procedimento Atualização BIOS Iron.pdf
  3. Siga as instruções para fazer o upgrade da BIOS e tudo funcionar como deveria desde o início.
Pronto, você acabou de habilitar a virtualização e pode designar até 4 processadores para suas máquinas virtuais.

17 de março de 2011

Qual é a melhor forma de avaliar um desenvolvedor?

Os desenvolvedores de software enfrentam uma questão importante: seu valor no mercado. É certo que existe uma média salarial, mas como diferenciar-se da multidão? O que você tem, que seus colegas de sala podem não ter?

Essa mesma dúvida seu chefe provavelmente também tem a seu respeito: “A quem eu devo promover?”. Muitas vezes seu diferencial é tão particular que ninguém vê. Nem você mesmo!

Para evitarmos a mesmice, procuramos nos diversificar. Até aí corremos o risco de cair na mesmice, afinal sempre encaramos as coisas com o olhar tecnológico. Afinal, quanto mais sabemos, mais temos a oportunidade de contribuir, certo? Só se você diversificar dentro do leque de opções que interesse seu cliente ou seu empregador, caso você queira continuar trabalhando com eles.

Muitos procuram as tecnologias que estão na crista da onda. Esses nunca serão realmente especialistas em nada. São generalistas e há espaço para eles.

Outros, procuram entregar tudo no prazo, cumprir horário, seguir o script como manda o figurino, mas não ligam o computador em casa. Eles realmente não gostam da profissão e nunca vão se destacar, nunca deixarão um legado. Também há espaço para esses.

Talvez se soubéssemos como somos avaliados, poderíamos focar nossos esforços para “ficarmos bem na foto”.

Já fui avaliado por linhas de código produzidas. Isso mesmo! “Fulano fez só Y linhas de código. Esse é enrolado!”

Já vi avaliação por Pontos de Função entregues! Gente, os Pontos de Função são uma métrica de tamanho de sistema (apesar das controvérsias), não de produtividade. Até hoje muitas empresas insistem em estabelecer uma produtividade média em Pontos de Função, conforme a linguagem. [Não sei se é melhor do que as tais linhas de código.]

Também conheço desenvolvedores que eram premiados ou punidos porque entregaram certo volume de programas por semana ou por mês. Bem viajado, isso, né? E se os 15 programas fossem pequenos e simples, contra 1 grandão e complexo? [E as linhas de código ainda ficam na lembrança.]

Eu já tive que avaliar membros da minha equipe, para promovê-los (!!!), com base na pontualidade. E sem eles saberem disso! :-o (Hoje vejo que não tínhamos relógio de ponto, mas eu era o porteiro que fazia “cara x crachá”). [Agora to achando que as linhas de código já fazem algum sentido.]

Existem também os “desenvolvedores” que são avaliados pela quantidade de especificações feitas. É... como se o cliente pudesse executar uma especificação. E, pior, aonde vi isso em prática, normalmente os desenvolvedores seniores eram os escolhidos para escreverem as tais especificações. Pergunta se a turma gostava de trocar o editor de programas, pelo Word! [Que saudade da avaliação por linhas de código!]

Sem falar naquele método de avaliação chamado “gente-boísmo”. Esse eu tenho certeza que você também já viu. Sabe aquele cara gente boa, que todo mundo gosta? É o promovido. O resto, que não tem muito tempo pra fazer “as honras da casa”, continua ralando sem promoção. [Pô, as linhas de código até parecem justas agora. Pelo menos o cara trabalhava.]

E o codificador programador que leva uma baita ensaboada porque seguiu a tal especificação do tal sênior que ganhou a promoção? Ele fez o que o papel mandava, mas pagou o preço porque o programa não funcionou. [Salve as linhas de código!]

Olha, essas situações acima não são folclore. Eu já presenciei todas essas formas de avaliação.

Mas, nunca vi um desenvolvedor ser avaliado pelo retorno financeiro que ele deu ao negócio. Já vir se dispensado, mas nunca promovido. Outro dia eu conversava com um amigo que ajudou a empresa a reduzir os gastos com telefone celular, de R$ 34.000 (trinta e quatro mil) por mês, para R$ 2.500 (dois mil e quinhentos). Não sei exatamente como, mas fez.

Já pensou se a empresa estendesse por mais um mês o gasto antigo, e bonificasse meu amigo em R$ 31.500 uma única vez? Acho que ele não ficaria chateado, nem pensaria em sair dessa empresa.

Quando as empresas resolverem premiar seus desenvolvedores pelo retorno que eles dão ao negócio, teremos mais criatividade posta em prática, sistemas mais simples e enxutos, e desenvolvidos em tempo menor.

Então, saberíamos que a melhor forma de melhorar na vida seria preocupar-nos com o negócio da empresa, ao invés de encarar a tecnologia como um fim em si mesmo.

Para quem se interessa por Agile, esse seria o mundo perfeito. Mas, fico pensando, para quem gosta de se esconder atrás de especificações, qual seria a alternativa?

Na sua opinião, qual é a melhor forma de avaliar um desenvolvedor?

8 de março de 2011

Rails for Zombies

Anota aí: http://railsforzombies.org É... Rails para Zumbis!

A princípio pode parecer brincadeira, mas não é. O curso é bem prático, com exercícios interativos e muito objetivo.

Aliás, fico impressionado como os rubystas têm a capacidade de inovar e fazer coisas sérias com um aspecto bem legal.

Esse curso gratuito e introdutório de Ruby on Rails é muito gostoso de fazer. Em apenas 5 lições tem-se uma visão ampla de como o Rails funciona, abordando Models, Views, Controllers e Routes de uma forma muito natural.

Recomendadíssimo!

Obs.: peguei essa dica no blog do Leo Hackin http://www.leohackin.com.br/2011/03/ruby-on-rails-referencias-de-leitura

28 de fevereiro de 2011

Ruby em 15 minutos

É, o mundo se move e nós sempre aprendemos linguagens novas.

Eis aqui mais um fast track. Agora, de Ruby.

Como esse fast track é destinado a programadores, muitos exemplos não têm explicação. Preste atenção aos detalhes e use o shell do Ruby (IRB) para testar os códigos abaixo. ;-)

Antes de começarmos, vamos a algumas definições da linguagem:
  1. Ruby é case sensitive. nome é diferente de Nome
  2. Ruby tem tipagem forte, mas dinâmica. Igual ao Python.
  3. Tudo é objeto, inclusive os tipos "primitivos" String, Integer, Float, Array, etc.
  4. Nem sempre os parênteses são necessários ao passar parâmetros para métodos.
  5. Métodos que terminam com um sinal de interrogação, normalmente retornam valor booleano.
  6. Métodos que terminam com um sinal de exclamação, normalmente modificam o objeto sobre o qual ele está agindo.
  7. Para blocos de código, tanto faz usar do...end ou as chaves.
  8. Variáveis de instância começam com @
  9. Variáveis de classe começam com @@
  10. Todos os testes booleanos retornam true, exceto false e nil. Isso significa que zero e string vazia retornam true!
Agora, mão na massa!

puts 'aspas simples ou duplas?'
puts "tanto faz"
nome = 'Maria'
puts "mas as aspas duplas mostram #{nome}"
# tipos e variaveis
nome = 'Maria'
idade = 34
eh_mulher = true
media_em_matematica = 8.5
cores = ['azul', 'preto', 'branco']
dados = {'nome' => 'Jose', 'endereco' => 'Rua 7 de setembro' }

a = 5
b = 10
a,b = b,a
puts 'a=' + a.to_s + ' b=' + b.to_s

a = '10'
puts a.to_i * 2
# if em uma linha só precisa do "then"
nome = 'maria'
if nome == 'maria' then puts 'mulher' end 
# entrada de dados, conversao e if com elsif + else
entrada = gets.chomp
n = entrada.to_i.abs

if n < 0
  puts 'nota invalida'
  exit
end
if n == 0
  puts 'zero?!'
elsif n > 0 and n < 5
  puts 'abaixo da media'
elseif n >= 5 and n < 10
  puts 'dentro da media'
else
  puts 'tirou 10!'
end
# unless é o contrário (else) do if
nome = 'maria'
unless nome == 'joao' then
  puts 'mulher'
end
# String
nome = 'Maria do Socorro'
puts nome.downcase
puts nome.upcase
puts nome.swapcase
puts nome.reverse

largura = 70
puts nome.center(largura)
puts nome.ljust(largura)
puts nome.rjust(largura)

puts nome.start_with?('Ma')
puts nome.end_with?('x')
puts nome.include?('Soco')

puts '-' * 70
puts 'Maria ' 'da ' 'Silva'
puts 'Maria ' + "da " + "Silva"
# Números
puts 5*2
puts 5+2
puts 5-2
puts 5**2
n = 5*2
puts 'o resultado: ' + n.to_s
puts 10.to_s
puts -5.abs
puts rand
puts rand(100)
if rand(100) != n then puts 'gerou diferente' end
if rand(100) > n then puts 'gerou maior' end
# Loops
3.times do |i|
  puts 'passei ' + i.to_s
end

1.upto(3) do |i| # tem também o downto
  puts i
end

for i in (1..3) do
  puts 'passei ' + i.to_s
end

i = 1
while i <= 3
  puts 'estou no ' + i.to_s
  i += 1
end

(1..3).each do |i|
  puts i
end

(1..3).each {
  |i|
  puts i
}

('a'..'z').each do |letra|
  puts letra
end

i = 0
loop {
  i += 1
  puts i
  if i == 3 then
     break
  end
}

# cuidado!
i = 0
begin
  i += 1
  puts i
end while i <= 3
# Arrays
cores = ['preto', 'branco', 'azul']
puts cores.join(', ')
puts cores.first
puts cores[0]
puts cores.last
puts cores[-1]
puts cores.length
puts cores.min
puts cores.max
puts cores.include?('amarelo')
cor1, cor2, cor3 = cores

grandes = cores.collect{ |cor| cor.upcase }
puts grandes

for item in cores
  puts 'a cor atual é ' + item
end

cores.each do |item|
  puts 'a cor atual é ' + item
end

cores.push 'cinza'
puts cores.length
cores.pop
puts cores

cores.sort
puts cores

outras_cores = cores.clone
# Hashes
dados = { 'nome' => 'maria', 'idade'=> 74 }
puts dados['nome']

mesmo = dados
mesmo['nome'] = 'Joana'
puts dados['nome']

outro = dados.clone
outro['nome'] = 'Marcos'
puts dados['nome']
puts outro['nome']

for k,v in dados
  puts "#{k} = #{v}"
end

dados.each_pair do |k, v|
  puts "#{k} = #{v}"
end

dados.each do |k,v|
  puts "#{k} = #{v}"
end

dados.each do |x|
  puts x
end

puts dados.has_key?('nome')
puts dados.has_value?('Fernando')
dados.delete('nome')
# Métodos
def oi pessoa # nao precisa dos parenteses! :-o
  puts 'Oi ' + pessoa
end
oi('vinicius')
oi 'vinicius' # aqui também nao.


def soma (a, b)
  c = a + b # não precisa do return
end
total = soma(1,2)
puts total
# Inspecionando os tipos "primitivos"
puts String.instance_methods.sort
puts Integer.instance_methods.sort
puts Float.instance_methods.sort
puts Array.instance_methods.sort
puts Hash.instance_methods.sort
puts File.instance_methods.sort
# classes e objetos
class Pessoa
  def initialize (nome_parm) # esse é o constructor.
    @nome = nome_parm
  end

  def eh_homem?
    homens = ['joao', 'fernando', 'vinicius', 'carlos']
    return (homens.include? @nome.downcase)
  end
end

pai = Pessoa.new('Joao')
if pai.eh_homem?
  puts 'é o pai'
else
  puts 'humm...'
end


# attr_accessor age como uma property.
class Animal
  attr_accessor :nome # funciona como getter e setter.
  attr_reader :idade # getter.

  def initialize nome
    @nome = nome
  end

  def idade=(idade) # setter personalizado.
    @idade = idade.abs
  end
end

cao = Animal.new('Toto')
puts cao.nome
cao.nome = 'Petunia'
cao.idade = -5
puts cao.nome + ' tem ' + cao.idade.to_s + ' ano(s) de idade.'

9 de fevereiro de 2011

Run the ultra-marathon along with web2py

Runner athletes have big difference in their profiles.

Some of them explode in speed. They arrive super fast, but their bodies can’t support much time. They usually use the cutting edge technology in food, physical exercises and clothes with great aerodynamics. They are often the innovators. They must achieve quick results and stop early.

Their coleagues, long distance runners, need to prepare themselves to a more intense physical and emotional activity. The ultra-marathonists run for days, face cold, warm, sun, darkness, different heights, all in a single run. They need do feed themselves often and stop to stretching. Their shoes need to be extremelly comfortable: absorve impacts and protect from injuries.

Application developers must understand that long term customers want long term commitment. And long term plans. Your appointment doesn’t finish a few seconds away. Your are focused in a future objective. It’s a ultra-marathon, not a 100m running.

Technologies envolved must be safe, with continuation compromise. Very often we need to adjust things, we bring alternatives, but the big picture is already designed. We need to remind the rules, our competitors, renew our strengths. But it’s still the same running.

I want to clear out this way of thinking does not promote you to keep doing things the same way you always did. You need and must innovate in every single opportunity, but safely. Your choices need to be based on real indicators.

Maybe the more important choices, that will dictate if you will keep walking or will need to rewind are programing languages (business rules, automation scripts, templates, data manipulation), data base management systems and the framework will keep you appart from boring and difficult tasks to let you focus on your goal: your apps.

These points are often under attention, even for professional developers. I already faced people choose some language “because everybody I know is using it”, “because it’s the natural transition” ou “because we already know it”. If you do this way, wake up! These are important arguments, but they don’t have a solid background.

I met Java developers that had never heard about Python until they knew me. Visual Objects were “the natural transition” from Clipper to Windows, in early 90’s. I’ve worked in a place with a PHP “culture” because they had some sites written in it, but they didn’t know even why they chose PHP. Here in Brazil we hear often “when your only tool is a hammer, all your problems seem to be a nails”.

As a developer, your business core value is intellectual and the programming language expresses your app rules is too valuable to you. It will determine if that “bit of feature” to be fixed or implemented will be 1 hour or 3 days long.

Nowadays I am developing applications using web2py. Some characteristcs I voted pros are:
  1. It has official commitment with backwards compatibility. None compatibility was broken in 3 years. What I developed, keeps running.
  2. It is written in Python, to develop Python apps. A mature language, increasing its marketshare, used by big players worldwide. I can develop object oriented, or not. I can write administration or automation scripts, if I want.
  3. I can use Python to render my views. Using the same language, lesser is the learning curve.
  4. It’s self-contained. In other words, unzip and use. All dependencies are already there. This accelerates my deploying and configuration process. It comes with jquery, PDF generator, Ajax, etc.
  5. It’s open source.
  6. DAL (Data Abstraction Layer) may be decoupled. It means if I need to develop a module to work out of web I can still use the same data access language. In other words, DRY (Don’t Repeat Yourself).
  7. There’s a lot of free site templates ready to use, made from CSS Zen Garden and Free Templates.
  8. There’s a trully receptive and organized comunity, even in Brazil. (nice!)
If you plan see your applications lasting for years without the need to rewrite, choose your development environment with all this in mind.

Who stands and plans, reaches the ultra-marathon’s finish line.