1. Sistema Operacional: Linux. Utilizo tal plataforma pela simplicidade no gerenciamento e performance. Dentre as distribuições, opto sempre por Arch, Slackware ou Gentoo, nesta ordem.

2. Controle de versão: Git. Já tem uns meses que uso em novos projetos, recentemente porém, adotei também nos projetos SVN lá na empresa com o git-svn enquanto a migração pra Git por lá não acontece.

3. IDE: Há quem fale que uma IDE não agrega em nada, pois eu vejo o contrário. Ter praticidade ao programar é muito bom. Eu costumo utilizar muitos atalhos de teclado para evitar utilizar o mouse ao codificar, elevando o desempenho. Já utilizei várias IDEs para um trial até que há mais de um ano venho utilizando Zend Studio (Eclipse based) para PHP e Eclipse JEE/Ruby para Java e Ruby. Assim os atalhos de uma funcionam na outra

Home Office v1

4. Ambiente: o ambiente em volta é deveras importante para mim ! Recinto calmo, com iluminação adequada e recursos a mão fazem toda diferença ao trabalhar. Até a cor do ambiente influência. Neste caso, porque não seguir as dicas, não é ?

5. Remoto: servidores e apps remotas auxiliam o compartilhamento, armazenamento e controle dos softwares/programas/malwares desenvolvidos. Utilizo um server shared na Dreamhost com dois domínios apontando nele e estou cogitando a ideia de utilizar uma VPS. Lá ficam salvos além das versões comitadas dos softwares, um ambiente de deploy e meu servidor Git remoto para onde comito meus projetos particulares. No Github ficam somente os open

6.  Controle de atividades: Utilizava até um tempinho atrás o renomado Basecamp. Porém, na Rubyconf deste ano, fui apresentado ao seu concorrente mais em conta, Go Plan. Fiz um teste e gostei da ferramenta. Atualmente estou migrando os dados do Basecamp para lá. Issue tracker eu não uso, afinal, não produzo bugs eu também coloco no Basecamp/Go Plan.

7.  Monitores: sou viciado em monitor. Comecei comprando um de 19′ que virou um de 22′ e depois um de 24′. Espaço na área de trabalho virtual agrega muito quando trabalha-se com desenvolvimento. Não é ter visão de uma linha com trocentas colunas, mas sim, utilizar as abas da IDE com suas funções – unit test, shell, filesystem, outline, type… – o que ocupa um bom espaço na tela.

Para continuar, convido:

@tmadeira
@lfamorim
@gchapiewski
@loiane
@chesterbr

Salvador Dali, 1931 - The Persistence of Memory

Já conversei com pessoas que batem o martelo facilmente dizendo:

- É por tempo.  Eu programo em brainfuck há seis anos, logo sou sênior.

Será mesmo ?

Em tempos modernos, fica ainda mais complexo fazer uma avaliação deste tipo para programadores, arquitetos ou engenheiros de software, pois, não é somente uma linguagem de programação que está em análise. É todo um contexto que abrange desde a escolha do ambiente de desenvolvimento até relacionamento com stakeholders e domínio em metodologias e paradigmas de desenvolvimento.

Se temos a análise temporal como inválida, então o que espera-se de um dito sênior ?

Para tal, conversei com três pessoas que estão diretamente envolvidas com estes aspectos.

Creio que sim. Existem os profissionais seniores, porém muitas pessoas, e empresas, acabam confundindo o nível do profissional com o seu tempo de experiência.

Em minha visão, o tempo de experiência é importante, porém, não determinante para rotular um profissional, ou seja, é perfeitamente possível existirem seniores com 3 anos de experiência e juniores com 15 anos.

O profissional Júnior, é aquele que já desempenha as tarefas com certa autonômia, porém, necessita de um maior tempo de pesquisa e em alguns casos de orientação.

Por sua vez, o pleno já demora um tempo menor para realizar as mesmas tarefas além de não necessitar de orientações referente aquela tarefa. O que difere o pleno de um sênior é a visão holistica, ou seja, para ser um profissional sênior é preciso possuir habilidades complementares as necessárias para o desenvolvimento daquela tarefa, isso ajuda acima de tudo no desenho de uma melhor solução além de maior facilidade no tratamento de problemas.

Outro ponto que vale ser observado, é que muitas vezes o sênior é destacado para tarefas simples, que não exige um conhecimento avançado, como seguir um procedimento de criação de usuário. Esse fato, além de desmotivar o profissional, gasta recursos de forma imprudente, já que são os seniores que deveriam criar os procedimentos a serem seguidos, além de desenhar soluções para problemas e corrigir falhas críticas ou em serviços críticos.

Vinícius Bufoni, coordenador de engenharia web na Vex

Este é um assunto interessante. Na maioria dos lugares as pessoas usam “anos de experiência” como medida para classificar. Esta é, na minha experiência, uma das piores maneiras de se fazer este tipo de classificação. Uma pessoa que desenvolve em, digamos, JSP e Servlets Java por 10 anos não necessariamente tem 10 anos de experiência desenvolvendo software, ele tem experiência desenvolvendo JSP e Servlets! E mesmo assim, tempo gasto em uma tecnologia não está diretamente relacionado com proficiência nesta. Enfim, utilizar tempo para medir experiência é, normalmente, uma besteira.

A forma com que eu tenho lidado com esta relação entre níveis de desenvolvedores, atualmente, é usando algo chamado modelo Dreyfus de aquisição de conhecimento: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition .

Normalmente eu tenho as áreas em que eu considero que meu time deve ser competente (este post: http://fragmental.tw/2009/11/24/i-wish-i-knew-that-before-getting-this-job-–-slides-and-long-notes da uma idéia sobre quais seriam estas áreas) e uso o Dreyfus para tentar entender onde cada um está nestas competências. Tem funcionado relativamente bem para mim mas ainda é, como sempre será, problemático e, por muitas vezes, injusto.

Phillip Calçado, consultor na ThoughtWorks

Do meu ponto de vista um profissional sênior é acima de tudo auto suficiente, é o tipo de profissional em que você não precisa passar o que deve ser feito, ele geralmente entende seu papel em uma equipe e como pode contribuir.

Um profissional Sênior consegue tomar decisões e assumir responsabilidades, ele não depende de alocações e precisa de muito pouca supervisão gerencial e técnica.

Geralmente um profissional Sênior também, está sempre atualizado e esta sempre ligado em tendências do mercado e em como adaptar estas novidades a sua realidade nos projetos em que esta envolvido.

“Tempo” de experiência na verdade não é tão importante, mas a diversidade e intensidade da experiência da pessoa é extremamente importante, se ele esteve envolvido uma grande diversidade de projetos e atuou em papeis dos mais diversos, um profissional sênior geralmente consegue se adaptar pois já trabalhou em diversos papéis e com diversos times.

No caso de grandes empresas de Internet, como o Yahoo!, é vital que o profissional sênior entenda de e tenha tido vivência com projetos de grande escala, e que entenda de Sistemas, arquiteturas e plataformas que funcionem com grandes volumes de acesso e demandam muita performance.

Não gosto muito destes rótulos, mas um profissional Pleno depende de um nível de supervisão/apoio maior. Um Pleno também tende a ser mais inseguro na tomada de decisões e definições mais complexas.

Mas a principal diferença é a experiência, bagagem de conhecimento. Em entrevistas sempre pergunto qual foi o maior desastre da carreira da pessoa, espero que ele me diga quais foram os erros e o que ele aprendeu com isso. Isso mostra maturidade em relação a tentativa/erro, onde não se deve temer cometer erros e que sempre devemos aprender com eles e continuar tentando. Isso é chave para ser inovador.

Antônio Carlos Silveira, diretor de Produto e Engenharia, Yahoo! América Latina

Cada um tem seus métodos de análise, mas ficou evidente que contar os dias no calendário já não é mais tão convincente como parecia

Random Hack of Kindness São Paulo 2010 por danicuki

Eventos como Yahoo! Open Hack day; Google Developer Day; o recente Random Hack of Kindness; Coding Dojo (o de Sampa no IME da USP está meio inativo ao que consta); e vários outros movimentos iniciados até por empresas, como a própria Caelum que já abriu as portas para criar um ambiente onde programdores pudessem se juntar e desenvolver suas coisas, ou mesmo que fechado ao grupo de programadores da mesma como já ouvi relatos de programadores.

O que leva esse bando de programador malhucos das cavernas a participarem com empolgação destes eventos – muitas das vezes apenas com free lunch e Internet 0800 ? São desocupados ? Loucos ?

Yahoo! Open Hack Day Brazil 2010 por Antônio Carlos

Simples: adoram o que fazem ! São essas pessoas que geralmente criam tendências, aplicam ideias e tomam iniciativas nas corporações em que trabalham; São os mesmos developers que passam horas a fio programando com vários livros de nomes nonsense à tira-colo; ou que criam projetos pessoais para suprir uma necessidade própria e acabam chamando a atenção de muita gente – vide tantas startups bem sucessidas criadas e mantidas por programadores.

Geralmente esses mesmos programadores conhecem pelo menos duas linguagens. O motivo ? Curiosidade ! Pouco importa se Ruby on Rails fará sucesso no mercado coorporativo ou se Python não agrada o chefe. É legal para eles, então, investem tempo nisto.

Sempre em busca de novos conhecimentos, fanáticos pela arte em programar e fazer coisas novas; de novas formas e com novas ferramentas. Criam coisas, compartilham o feito e ainda passam a diante o novo conhecimento com artigos, blogs ou seminários. São programadores sempre motivados que buscam fazer uma análise crítica sobre suas próprias formas de programação buscando a evolução das ideias.

Vida social ? Muito bem, obrigado ! Nestas idas e vindas acabam conhecendo pessoas, lugares e oportunidades diferentes. Trocam ideias, conversam, trocam contactos das redes sociais; juntam-se em botecos ou equivalentes tornando o simples ato de programar em grupo em praticamente uma festa completa !

Sabe aquelas vezes em que você precisa realizar tarefas demoradas no browser do cliente e então você lembra do maravilhoso Cron Jobs ? Pois é, uma excelente ferramenta a nossa disposição. Entretanto, às vezes, certas empresas de hosting (Locaweb é uma) define um horário para funcionamento destas "tarefas agendadas". No caso da Locaweb é das 2 às 3 da matina apenas.

Mas, mas e agora ? Como executar a tal sonhada tarefa "em background" quando não há o Cron Jobs como opção ?

Um pouco de história

Sabemos muito bem que o PHP é server-side e isso significa que o PHP roda no servidor e não no cliente como o Javascript, por exemplo. Entretanto, logo quando eu comecei a programar com PHP eu me perguntava o motivo pelo qual o script era interrompido ao clicar no botão Stop do browser ou então quando eu o fechava já que a ação era no cliente e não no servidor. Tempos depois descobri que nestes eventos, era enviada uma informação ao servidor PHP (via TCP, claro) que de o usuário "abortou" a conexão com ele e o PHP bem esperto que é, parava aquela tarefa.

Entretanto...

O PHP nos permite manipular esse comportamento, ou seja, posso dizer ao PHP que eu quero continuar executando o script mesmo se o cliente nos deixar na voz ! Como uma imagem vale mais do que mil palavras, deixo aos senhores um pequeno vídeo que fiz demonstrando o funcionamento:

Perceba que caso queira redirecionar o usuário para outra página e continuar trabalhando naquela tarefa, você precisa manipular o buffer e os headers da página da forma como coloquei no script, caso contrário, ele irá processar todo o conteúdo e depois sim, redirecionar. Isto por quê, como não estamos enviando nada diretamente ao browser, o Apache espera uma quantidade de dados enviados antes de processar quaisquer headers. Com as funções de buffer do PHP nós podemos mudar também esse comportamento, forçando-lhe a obedecer o header (Location).

Deixo abaixo o código dos dois arquivos usados no vídeo:

E também, o vídeo original no formato OGV.

Mais informações:

• http://br.php.net/ignore_user_abort
• http://br.php.net/manual/en/features.connection-handling.php

Nota: o programa usado para gravar foi o qt-RecordMyDesktop para Linux.

Pense numa rotina que desenvolveu. Qualquer uma ! Agora tente se recordar de quantas formas ela poderia ser quebrada pelo usuário, gerando assim algo inexperado na sua aplicação fazendo com que você retornasse um erro para o cliente.

E qual é a forma que você utiliza para retornar estes erros ? Veja, eu posso ajudar a recordar você:

Com isso lá na sua Action você fica fazendo malabarismo para encontrar o erro retornado e gerar a mensagem para o usuário. Não demorará muito para você criar sua tabela de erro:

• -1 para erros de entrada
• -2 para erros de máscara
• -3 para calcúlos errados
• -4 para usuário não logado
• -5 ....
• -7634 ....

Realmente, bem simples assim né ? Só consultar a tabela e mandar bala.

Eu realmente não entendo o motivo de muitos não utilizarem a classe nativa de exceções do PHP. É simples, é funcional e de grátis você não precisa montar sua tabelinha de códigos de erro.

Veja o mesmo código reescrito utilizando a tal classe:

Com isso na sua Action, simplesmente:

Assim, você pode ter 1, 2, 3, n mensagens de erro em n camadas da aplicação sem a necessidade de se preocupar em tratar uma a uma também na Action. Fica ultra-transparente na Action além de economizar seus dedos refazendo coisas que já estavam prontas camadas a dentro.

Nota: Não esqueça disso nunca : jamais lance como exception uma mensagem de erro do PHP. Isso é feio - porque vem em inglês -, você será xingado por 3 gerações futuras de programadores além de permitir que os usuários vejam detalhes sobre sua aplicação.

Como detectar os erros sem lança-los ao usuário ?

Bem simples. Persista-os - eita mania - em arquivos de log. Mas calma, antes de sair criando algo com fopen(), leia isto: o PHP também traz o cara que salva - persiste - erros ! Ah sim, o PHP é excelente eu sei. Voltando ao exemplo...

Sim, ele, o error_log() salva o log para ti. E pior, digo, melhor: caso queira ele pode enviar a notificação no seu e-mail. Certo, em boa parte dos casos isto definitivamente não é uma boa ideia. Mas pode ser útil algum dia, penso.

Resumo do dia: use ao máximo as Exceptions e as funções para tratamento de erros do php .