Diferentemente dos outros anos, em 2011 eu estarei na PHPConference como palestrante. Meu maior impasse era quanto ao tema, por fim, decidi submeter algo polêmico que foi aceito! Acredito conseguir abrir a mente de alguns possíveis espectadores com o tema:

Definir classe não é programar com orientação a objetos.

Do que não falarei:

• Como definir uma classe com PHP;
• Classe e Objeto no âmbito técnico do PHP;
• Parâmetros, métodos e objetos;
• Padrões de projeto (design patterns).

Do que falarei:

• Design (projeto) orientado a objetos;
• Princípios de orientação a objetos;
• Como não definir uma classe (code smell);
• Composição, agregação, value object e entidades;
• Ubiquitous Language (ourindo do Domain-Driven Design)
• Getters, setters burros;
• Ciclo de vida de um objeto.

O objetivo é abrir a mente dos presentes para uma orientação a objetos pura, legível e realmente manutenível. Minha palestra será na sexta-feira, 2 de dezembro às 11hs (de acordo com a grade atual). Interessou? Aparece por lá!

O problema

Documentar para a eternidade.

1. pseudossolução: texto e mais textos

No ano de 2009, eu entrei  no time de web da Vex e como tal fiz minha primeira tentativa a fim de resolver o problema da documentação do que eu fazia. Tentei documentos de especificação técnica.

Escrevia em um arquivo .odt tudo o que eu havia entendido sobre o projeto e com aquilo, começava as atividades de design e codificação. Era engraçado, pois essa atividade assemelha-se ao renomado processo cascata e increvelmente, era simples e parecia solucionar o problema. Não satisfeito em escrever o .odt eu o salvei no servidor de versão e ainda por cima mandei por email para toda equipe Web.

Após algum tempo, novos requisitos apareceram e eu até mudei o .odt, mas não enviei novamente à Web, pois, na primeira vez, percebi que ninguém leu o arquivo, afinal, não era do interesse deles aquele montante de informação escrita e até, confusa.

Mais modificações vieram e eu modifiquei direto o sistema sem passar pelo documento.

Resultados: após algumas semanas, o documento já não servia para mais nada.

2. pseudossolução: report email

Como documentos extensos não deram resultados para a equipe – incluindo-me nisto – resolvi em outro projeto, enviar um pequeno email report relatando como estava o processo e o que estava adotando para seguir. Ficou parecendo um diário de bordo resumido do projeto, enviado apenas umas duas vezes. Não fui buscar resultados, mas alguma coisa me diz que ninguém leu ou lembra-se disto.

Resultados: fail.

3. pseudossolução: diagramas

Durante os projetos comecei a pensar: porque não disponibilizar os esboços de diagramas de classe que faço de meus designs ? Assim, ajudaria os demais a visualizar por um nível macro o que relaciona com quem. Esta ideia ficou somente na ideia, pois eu me deparei com a situação: como disponibilizar isto e manter atualizado ?

E foi daí que venho minha quarta ideia…

4. pseudossolução: wiki !

Ferramenta utilizada na Vex antes de 2009 sem sucesso, o Wiki foi uma forma que eu vi para documentar os projetos. Cheguei a comentar com o @esampaio sobre isto, mas ele disse que na primeira tentativa (antes de 2009) somente dois ou três desenvolvedores preocupavam-se em atualizar a ferramenta e por fim, acabou morrendo por desatualização.

Após idas e vindas do trabalho pra aula e para casa pensando sobre isto, percebi que o ponto de interseção entre todas as pseudossoluções era: fazer algo além do sistema funcionar.

Eu como programador sei bem o quão relutante eu era para escrever documentos e realizar processos burocráticos de software. Incrivelmente, com estas ditas soluções eu acabaria adicionando (mais) um processo burocrátivo na minha vida, desfocando daquilo que realmente importa: software funcionando. Percebi também que ao longo do tempo eu escrevia testes e aquilo sim agregava valor ao “software funcionando” e mais do que isto, me auxiliava à ver codificadamente as soluções de design tomadas no processo. Possibilitou que eu mudasse a funcionabilidade sem medo de side-effects pois os testes diziam exatamente o que era esperado daquele software.

É aí que entra a escrita de bons testes. Simples, coesos e desacoplados. Para atingir tal estágio não é fácil, requer muitas tentativas e erros (eXtreme Go Horse), mas que no final recompensam cada hora focada na melhoria da técnica de escrever testes.

Meu próximo passo é tentar as retrospectivas. Por isto, realizo hoje uma palestra interna na Vex com o título: Retrospectiva. Nela, apresento a timeline idêntica a este post – com muito mais detalhes, claro – com o objetivo de mostrar para o resto da equipe de TI o que a Web passou durante 2 anos. Pedi que levassem também, um “problema” que cada um vê em seu trabalho atualmente, visando assim encontrar soluções em grupo para tais problemas – que podem até serem recorrentes.

Até o momento não vi motivos para as retrospectivas não funcionarem, mas isto só poderei afirmar daqui algumas semanas.

Cenário:

Uma timeline com os últimos 10 commits apenas locais contendo uns testes malucos seu. Destes 10, você precisa tirar um para um push no servidor remoto, porém ele está lá no meio, entre o quinto e sétimo commit. E agora ?

Solução:

git reset + git  diff + git apply

Primeiro, peguei o hash do commit que me interessa da lista. Com ele em mãos, fiz um reset para ele:

$ git reset d3fb9

Fiz um diff entre o commit HEAD (ele próprio) e o penúltimo commit da timeline gerando um .patch da diferença:

$ git diff -u 691ac > meu_commit_importante.patch

Após ter meu patch a salvo, fiz o reset apontando para o último commit que tenho sincronizado com meu servidor remoto:

$ git reset 12345

Após, eu utilizei o git apply –check para verificar se meu patch não ocasionaria problemas e por fim o apliquei:

$ git apply meu_commit_importante.patch

Como eu não preciso logar no histórico que fiz isso (eram commits locais, lembra ?) não utilizei o git am conforme o pessoal costuma utilizar. Após isto, git commit -a -m “Modificação XPTO” e done.

Como me é interessante manter o que estou fazendo vivo, obviamente o coloquei em um branch separado após isto.

Ele abordou rapidamente o que é ALM (Application Lifecycle Management); dedicou uma boa parte do tempo explicando o que realmente é o framework Scrum e da junção de ambos no desenvolvimento de software. O interessante da palestra foi ele propor duas atividades de 5 minutos para que os participantes pensassem sobre a situação-problema por ele anunciada e após abriu para debate.

Após a palestra dele, José Papo assumiu o palco para abordar o tema ALM com governança e qualidade. Ele defendeu que é possível agradar gregos e troianos equipes que gostam da utilização do Scrum no ciclo de vida do software sem esquecer daquele gestor ou diretor que vive de planilhas e gráficos de Gantt daquela empresa que você sabe o nome.

Aliás, uma coisa – ao meu ver – quebrou o brilho do evento: o marketing invasivo da Microsoft. Ridículo, imaturo e desnecessário são as palavras que cabem para o que fora lá praticado.

O José papo por ser da área técnica do Visual Studio no Brasil, precisou ao longo de sua palestra, puxar sardinha pro lado da empresa que paga parte de seu salário de tal forma que ficou nítido que ele era forçado a fazer aquilo.

Utilizar gráficos para exibir uma autoafirmativa liderança no mercado de ferramentas para developers no meio da palestra – inclusive foi citado isso – foi feio; “Utilizem o ‘Bing’ caso não saibam o que é tal coisa” – e não era uma brincadeira quando falava isto. Para não ser injusto, a única descontração que houve foi o diretor de produto Visual Studio citar: “A Microsoft faz coisas boas, com exceção ao [Windows] Vista !”

Apesar do marketing burro da Microsoft, a palestra do Papo agregou muito e desmistificou outras tantas também.

Após o almoço, voltamos com um convite para uma espécie de “Mão na Massa” com a plataforma Team Foundation Server e Visual Studio. Não sei se todas as vagas foram preenchidas, o que posso afirmar é que a palestra que concorria com esse laboratório estava cheia.

Scrum na prática @ ALM Conference Brasil

O pessoal da Programmer’s, apresentou de forma bem didática como eles aplicam Scrum e melhor: a palestra foi instrumentada com Scrum elucidando ainda mais o que era por eles explicado. Destaque para o Kanban 3D com monitor touch screen que estava em exposição no stand deles.

O evento foi proveitoso, grátis e incrivelmente tranquilo. A divulgação deste evento ao meu ver foi fraca, haja vista que sobraram muitas vagas em um evento que eu aposto que seria bem baladado ainda mais por ser gratuito.

Espero que ano que vem ocorra o “II ALM conference Brasil”, mas por favor: eu topo pagar a entrada à ter que ouvir e ver um marketing tão “brutal” praticado por algumas empresas de software.

Annotation @author

Desde que comecei a programar no ínicio do segundo semestre de 2004, eu utilizo desse tal de arroba-aútor. Já vi algumas variantes dela, por exemplo:

Annotation @author Augusta edition

Há ainda aqueles que detalham no cabeçalho sua pog contribuição:

Blablabla no annotation (clique para ampliar - ou não)

Sinceramente eu nunca fui pesquisar se há uma convenção na utilização deste annotation. O fato é que meu uso com isto é descomplicado:

• Insiro meu nome em novos arquivos;
• Adiciono meu nome abaixo do último se eu fiz alguma adição ao arquivo, ou;
• Não adiciono quando faço pequenas modificações sem acrescentar algo de valor ao então domínio/objetivo/proposta do arquivo.

Mas mesmo assim, sempre coloco no formato Nome completo <email@provedor>

Porém, não pela primeira vez vejo um developer defendendo o não uso deste annotation. A última vez foi numa discussão – no bom sentido – entre @sergioprado e @lfamorim. Com isto, fui perguntar a eles – e alguns outros mais – a opinião pessoal em relação ao tal annotation. Confira:

Eduardo Guerra – @emguerra

Obviamente se o uso de @author nas classes for uma prática da equipe irei segui-la sem problemas, mas se a escolha for minha opto por não colocar. Esse tipo de marcação no meu ponto de vista atrapalha a propriedade coletiva do código por determinar explicitamente os autores da classe. No caso de erros na classe, sempre haverão dedos apontando o autor como culpado, mesmo se não foi ele quem introduziu o problema.

Como toda documentação não-executável, pode deixar de ser atualizado com a evolução de um projeto e muitas vezes o autor original não é mais quem mais contribuiu para a classe no seu estado atual. Adicionalmente, sou a favor de manter o código o mais limpo possível e esse tipo de coisa acaba deixando o código de todas as classes mais verboso.

Cainan Costa - @sryche via Jabber

[20:03:08] cainan.costa: não faz sentido, porque o VCS já mostra =P
[20:03:16] cainan.costa: quem é o maluco que fez a parada
[20:03:25] cainan.costa: aí tu usa um git blame
[20:03:33] cainan.costa: e já sabe quem encher de porrada

Lucas Fernando Amorim – @lfamorim

Hoje em dia a tag @author é tão obsoleta quanto respeitar um limite de colunas para seu código, mas ainda assim acho elegante e talvez até relevante.

Fica muito mais fácil para aqueles programadores que não usam a IDE XPTO verem o criador de determinado arquivo, método ou função sem ter que recorrer a um programa. É repetitivo você pode alegar, mas eu posso retrucar que a tarefa pode ser automatizada.

Eu aprecio muita essa tag, pois a partir dela posso usando minha humilde IDE identificar o criador de determinados códigos, antecipando os vícios do autor e me adaptando para a leitura. Tudo isso sem abrir a shell e digitar N^C comandos.

N = Familiaridade com o programa X de controle de versão.
C = Commits anteriores.

Christian Benseler - @chrisbenseler

Tenho uma visão que o negócio é “mais embaixo”. Antes de tentar assinar um script como seu, o desenvolvedor tem que se preocupar com outros assuntos mais importantes: é um projeto pessoal ou colaborativo? Está prestando serviços a alguém, outra empresa? Qual a política do seu cliente? Qual a versão do script? E qual o tipo de licensa que será adotada?
Só assinar o script não vai fazer a menor diferença se não tiver essas informações. E não vai fazer nenhuma diferença se a comunidade não parar de copiar o script feito por A, retirar os author notes do script e redistribuir o script sem dar esses créditos e/ou sem levar em conta o tipo de licensa adotado.

Carlos Duarte do Nascimento – @chesterbr

Antes de mais nada, você se refere a qual linguagem? Em Java, @author pode significar tanto uma anotação em si (e aí depende do contexto), tal como:

@author(“chester”)
public foo(int bar) {
…

quanto (o que eu imagino que você queira dizer) a anotação feita em um doclet, i.e.:

/**
 * Um elemento coberto por JavaDoc.
 * @author chester
 */
public foo(int bar) {
...

No segundo caso, eu gosto de @author devido à facilidade em lidar com a autoria coletiva: ela permite anotar classes inteiras ou métodos/atributos particulares; você pode colocar múltiplos autores, e
o Eclipse pode ser facilmente configurado para adicioná-la automaticamente. No PHP, se me recordo, é possível usar algo
equivalente (phpdoc) em cabeçalhos de código, mas não sei se é válido colocar em métodos/atributos, ou se é possível ter múltiplas declarações no mesmo escopo.

Em qualquer caso, vale notar que sistemas de controle de versão como svn e git são mais eficientes para descobrir quem efetivamente contribuiu com uma classe/método do que esse tipo de tag. Além disso, elas não são suficientes para notas de copyright (ou seja, teriam que ser replicadas apropriadamente para o correto licenciamento do código, independente da licença utlizada), o que limita de fato sua utilidade prática.

Sérgio Prado – @sergioprado

Há muito tempo atrás, as ferramentas disponíveis aos programadores eram escassas e limitadas.

<oldschool>Já programei em Assembly com um DOS rodando num x86 e monitor CGA de 80 colunas x 25 linhas </oldschool>

Nesta época, ferramentas de controle de versão não eram tão comuns, nem monitores de 21 polegadas. Foi então que surgiram alguns paradigmas. Eram consideradas boas práticas de programação usar no máximo 80 colunas por linha de código (limitação causada pelos monitores da época), e incluir informações no cabeçalho do arquivo como @version, @author, @date, @changes etc.

O problema é que para muitas pessoas estes paradigmas perduram até hoje, por herança, por gosto (ou mazoquismo mesmo). Qualquer ferramenta decente de controle de versão pode te trazer, desde sua criação, todo o histórico de alteração de um arquivo. Além de ser mais seguro e confiável. Se eu usar no código-fonte “@author pica-pau”, grande parte das pessoas não irá perceber, porque ninguem lê o cabeçalho do arquivo. Também não existe garantia de que o nome documentado no código-fonte é realmente o do desenvolvedor. Já com uma ferramenta de controle de versão esta garantia existe.

Eu mesmo usava @author nos cabeçalhos uns tempos atrás, mas parei de usar depois que comecei a criticar alguns paradigmas que tinha. É tudo questão de delegar para ferramentas o que pode ser automatizado e buscar novas soluções para os mesmos problemas.

Fábio Miranda – @fabiolnm

Não uso por pura falta de hábito – nunca trabalhei em um projeto onde essa prática fosse adotada.
Mas acho interessante, não só o autor, como o email / github tb.

Pode ocorrer de ser necessário dar manutenção em determinado código cuja compreensão não seja trivial, e a possibilidade de contactar o autor, mesmo que remota, deve ser considerada e viabilizada.
Não vejo razão para ser contra.

E pra finalizar, os comentários fundamentados de Hanneli Carolina Tavante @hannelita – sobre o uso de @author e muito mais:

Bom, vou dar minha opinião sobre comentários no código antes de qualquer coisa…. Também utilizarei algumas metáforas e exemplos reais.

Eu já trabalhei com códigos de sistemas legados – Mainframes e sistemas bem antigos – , envolvendo C e Assembly. Vou contar uma coisa – quando abríamos um código e víamos infinitas linhas de comentário, já sabíamos que vinha coisa ruim pela frente. Tudo bem para aquele tipo de código sempre achei necessário comentar – Há algumas subrotinas do inferno que precisam de explicação. E o cara que fez isso tem idade pra ser meu pai, já faleceu ou se aposentou. Portanto, códigos assim são “legíveis” graças aos comentários deixados para trás. Já peguei código em Assembly sem comentários. E fiquei quase 10 dias só pra entender por cima o que o programa fazia.

Mas atualmente estamos em uma época onde encontramos linguagens extremamente expressivas, como Ruby e Python. E pra ajudar ainda tem uns framewroks tipo Sinatra, incorporando DSLs. Ou seja, hoje é possível escrever códigos que HUMANOS são capazes de ler. (humanos comuns, quis dizer hehehe). Se você escreve códigos em Ruby que humanos não entendem, então sinto muito, meu amigo, vá ler o Clean Code ou aprender a programar de forma limpa. Aliás, práticas de TDD ou BDD, por exemplo, influenciam e praticamente geram um código limpo e legível dadas as etapas que sugerem na construção da aplicação. Por exemplo, o famoso “Vermelho, verde, refatorar” do TDD – O refatorar ocasiona um cógido extremamente mais compreensivo. Construído tal código sólido e bem estruturado, eu questiono – comentários para que? Eles perdem o sentido. Por exemplo, você se depara com a seguinte expressão em Ruby:

 unless valor == 0
  puts "Valor diferente de zero!"
 end

Bem expressivo, certo? Pra que um comentário então? Uma das coisas que me irrita um pouco é encontrar códigos assim:

public class Pessoa {
  private String nome; //define o nome da pessoa
  private int idade; // define idade da pessoa
}

Ou pior, bem pior que isso:

public class Pessoa {
  private String a; //define o nome da pessoa
}

Ambos os casos eu considero inapropriados. O primeiro por gerer redundância – é ÓBVIO que o atributo “nome” faz menção ao nome da entidade pessoa! O segundo exemplo nos remete a alguém que não fez uso de bom senso de orientaćão a objetos para definir o nome do atributo. O comentário era necessário porque não houve refatoração e uso de um nom esclarecedor ao campo. De qualquer forma, isso é incorreto no meu ponto de vista.

Então quando usar comentários? Costumo usar comentários quando, por exemplo, utilizei algum recurso pouco conhecido da linguagem. Por exemplo, o uso de Fibers no Ruby – poucas pessoas sabem o que são Fibers; coloquei um comentário no meu código extremamente sucinto explicando o que era e onde achar mais informações. Ou se você utilizar alguma magia-negra no código, embebida por metaprogramação, por exemplo, acho que é bom deixar um comentário sucinto do que aquilo quis dizer. Esse tipo de comentário ajuda programadores juniors a adquirir experiência e ajuda até memso os seniors a captar a idéia geral de um método/bloco que possui lógica complexa.
E há alguns casos que comentários podem ajudar a leitura do código fluir e ficar mais agradável. Pra Java, por exemplo, existe uma API – GAG => http://code.google.com/p/gag/ – Google Annotations Gallery, da qual já fui colaboradora. Essas anotações dão emoćão ao código; de vez em quando acho interessante utilziar algumas delas; tornam o coódigo mais expressivo. Novamente, acho que se deve usar sem abusos =)

Sobre o uso do @author – Aí já acho que é uma cosia meio pessoal. Eu não coloco. Saber que sou colaboradora/commiter do projeto já está bom pra mim. A ligaćão entre eu e o código fonte vai muito mais além que um @author. Claro, tem o lado bom de se colocar; todos que tiverem o fonte saberão o responsável por aquela ciração, e poderão parabenizá-lo, encontrá-lo no Twitter ou no Facebook e coisas do gênero. Ou poderão xingar sua mãe com vontade. Mas acredito que há outras formas de se descobrir e pedir ajuda sobre algum fonte que não são através do @author.

Bom, essa é minha visão geral da coisa! =D

E aí, é contra ou a favor do @author ?

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

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 !

Vex - Setores TI e Operações - Maio 2009

A “ideia” de trabalhar fora veio repentinamente, basicamente com um pseudoconvite de meu amigo de longa data @Otata, que já estava trabalhando por lá e disse-me não por uma, nem duas, mas algumas vezes, de que a Vex estava contratando mais developers para fechar o time e que era para eu enviar meu “currículo”.

Após enviar meu currículo para o pessoal, houve os tramites default de conversa por telefone, entrevista pessoal, a renomada provinha tira-teima e no final do dia após enviar meu currículo estava ingressando no time.

Algo que achei peculiar foi a rápida contratação – comigo pelo menos. Tudo bem que houve ele, o QI, mas fiquei surpreso com a confiança que recebi dos coordenadores, afinal eu era até aquele momento um freela de cabelo comprido e que morava há alguns quilômetros de distância da empresa.

Ambiente

Vex - Galere Web - Maio 2009

Obviamente, totalmente diferente do até então escritório-casa que eu trabalhava enquanto freelancer. A adaptação não foi um problema, pois na Vex eu também utilizo notebook para desenvolver plugado à um monitor externo quase nos mesmos moldes que tenho em meu home office.

Por não recebermos visitas de clientes no prédio, podemos ir com roupas menos formais. Isso não quer dizer que eu possa ir de bermudas ou chinelos igual já tentaram fazer por lá

No andar do desenvolvimento, há também o pessoal de sistemas embarcados e redes. O relacionamento com todos sempre foi bem tranquilo, mesmo quando saía uns flamewars do tipo: Python vs PHP; Zimbra não é Yahoo!; e todo mundo contra o @Otata.

Vex - Junho 2009

Durante esse período uma coisa ficou clara: a empresa movimenta-se bastante. Houve pessoas entrando; pessoas mudando de área, pessoas deixando a Vex e até, pessoas que saíram e estão retornando novamente. As saídas, do ponto de vista pessoal, são ruins, pois todos no andar tem um contato diário, uma amizade e que depois de sua saída o contato praticamente se extingue.

Os PHP’ers

Vex - Galere Webdev (@bufoni)

Vex - Galere Web (@Sugamele)

Se os developers geralmente não batem muito bem das ideias, essa turma bate menos ainda ! (haha, vão me matar com esse comentário). O pessoal na Vex é bem tranquilo e são bem espontâneos. O que surpreende nessa turma são as diferenças: cada um possui seu temperamento, opiniões – muitas das vezes bem diferentes – e suas especialidades. Mesmo com tantas diferenças, nós, que trabalhamos geralmente aos pares ou trios e raramente individualmente, temos um envolvimento excelente nos projetos.

Ao que estive olhando nos logs do controle de versão, passaram aproximadamente 12 pessoas (achismo mode on) pelo time Web durante um período de 4 anos.

Inclusive, o @esampaio, aqui conhecido como meu chefe, publicou um vídeo com o histórico do SVN de um de nossos projetos internos.

Vex - Webdev. @Sugamele e eu - Agosto, 2009

Pela quantidade de pessoas que ao longo desse período trabalharam em cima desse projeto em específico é um pouco previsível o que pode-se encontrar nele. Há coisas realmente muito boas – tanto código quanto solução para um problema – a própria engine de i18n é uma delas, porém, há também coisas desenvolvidas no estilo WOP. (Workaround-oriented programming).

O que me chamou a atenção nessa área é a real vontade do pessoal em evoluir e melhorar os pontos que hoje não estão bons. Quality of Code está literalmente em alta e o princípio “Don’t live with broken windows” (para mais leia o livro: The Pragmatic Programmer) tem feito sucesso.

Quando é necessário atualizar alguma coisa ou sempre que possível – mesmo não estando na lista de prioridades, os códigos obscuros do passado são atualizados, melhorando não só a leitura e documentação (leia-se PHPdoc), mas também o relacionamento daquele módulo com todo o resto. Anima muito ver uma equipe – o que inclui os coordenadores da área – interessados em adotar metodologias e princípios que visam melhorar o código e entendem que isto no final, traz benefícios não só para os developers, mas também para os usuários da ferramenta.

Vex - (@lfamorim e @sergioprado ao fundo) @Otata e @acidcode - Maio, 2009

Vex - @bufoni @esampaio e @sergioprado - Fevereiro, 2010

Vex Webdev - @bufoni e @Sugamele - Setembro, 2009

Trabalho em grupo

Por ter o costume de trabalhar sozinho na época dos freelas – claro, havia o designer @jorgeveteran – eu, achei no começo que seria algo complicado. E sim, é complicado ! Não guardar as ideias ou soluções contigo é uma das coisas mais complicadas. Deixar o pessoal que está contigo no projeto atualizado das ações, estabelecer uma linha e manter as coisas alinhadas durante todo o projeto é algo que eu precisei reeducar quando comecei na Vex. Mas até hoje não houve nenhum tipo de problema com o pessoal que já trabalhei em conjunto.

Um dos maiores problemas foi encontrar paciência para explicar as coisas técnicas para o pessoal. Não sou o melhor exemplo de paciência quando a tarefa é explicar coisas – que eu julgo claras e simples de entender – aos outros. Consigo explicar tudo numa boa, porém, dúvidas e erros que eu julgo primários me deixa meio: “Não acredito que você fez/perguntou isso !?”.

Outra particularidade é que dependendo da pergunta – na realidade, quase todas – eu não forneço a resposta pronta. Forneço links, materiais e até títulos de livros para que a pessoa leia, estude e tire suas próprias conclusões a respeito. Antes eu debater com ela aquele assunto à eu “formar robozinhos” que repetem tudo que eu julgo ser verdade até aquele momento. Se eles não entendiam o motivo pelo qual faço isso, agora eles ficaram sabendo !

Vex Webdev - Playground - Fevereiro, 2010

Esse período que é um pouco mais de um ano realmente está valendo muito. Ao que percebo de comentários – críticas, na realidade – dos developers nas empresas em que trabalham, é possível ter uma clara noção de que a Vex é uma exceção. Uma equipe jovem, de jovens líderes e com ideias muito boas. O setor de tecnologia está de parabéns !

Retratos que coleciono desde quando iniciei na Vex podem serem vistos aqui, ó !

A primeira edição da Revista TI Digital saiu no começo de março, porém, aqui na Terra da Maçã, chegou às bancas apenas na semana passada.
As matérias da revista estão focadas no desenvolvimento de software no geral, seja PHP, Java e qualquer outra ferramenta livre ou proprietária.

Uma das matérias da edição foi os prós e contras de ser freelancer ou um contratado normal. A matéria ao meu ver ficou balanceada, havendo quem defendesse totalmente o salário “fixo”; outro que defende o salário fixo, porém, sempre pega uns freelas e outro que vive apenas como freela

Apresentando o lado 100% freelancer da matéria eu procurei  expor minha experiência nessa área, abordando a liberdade que há em trabalhar desta forma; aspectos como liberdade em escolher ferramentas e métodos de trabalho e também o lado gerencial da coisa.

Li o ponto de vista dos demais entrevistados, concordo com certos pontos apontados por eles, mas não acredito em “estabilidade financeira”. Um freelancer pode ficar sem projetos assim como um funcionário regular pode ficar sem emprego. Tudo depende do momento, do seu trabalho e claro, de seus contatos

Não repudio quem trabalha assim, cada qual joga seu jogo, quem sabe até, eu experimente trabalhar em agência para ver como é !

Por fim, quem leu a revista e tenha algo a considerar sobre esta matéria, por favor, fique à vontade para perguntar, criticar ou elogiar

Ser freelancer não é uma tarefa fácil, quem é freelance sabe muito bem como que é o dia-a-dia. A grande diferença é que além de exercer a profissão de forma autônoma, você precisa gerenciar seu negócio, relação com clientes e seu tempo.

A idéia é ir adequando suas tarefas na ordem que melhor combinar no seu dia-a-dia, mas como isso leva um tempo e essas adequações só vêm com o passar do tempo (e experiência) vou listar algumas idéias aqui que podem lhe serem úteis.

1. Separando seus horários.

Obviamente, você como freelance, tem toda a autonomia do mundo para controlar seus horários, logo, é fundamental separá-los para dedicar-se às tarefas com mais empenho. Aqui funciona assim:
Pela manhã, eu leio o meu Scrum e minha agenda (de papel) vendo e separando os compromissos das tarefas. É fundamental ter em mente que Compromisso é diferente de tarefa.

Um compromisso é algo que tem dia e hora para começar e para acabar. Podemos assumir como exemplo a visita a um cliente ou levar seu cachorro para passear, por exemplo

Uma tarefa é algo que tem um dia para começar e acabar, mas não estritamente tem uma hora para começar e finalizar. Como por exemplo, postar no seu blog ou aprontar aquele orçamento bacana do seu futuro cliente (amém).

Depois de ver que não tenho compromisso algum naquele dia, vejo as tarefas que tenho que cumprir para manter-me em dia e dou o start. Sempre atento ao Scrum e a agenda sigo durante o dia, atualizando eles quando finalizo algo.

No fim da tarde, com as tarefas em dia, eu planejo o próximo dia, definindo prioridades e atualizo Scrum e a agenda.
Na parte de noite, como não tenho mais a faculdade, eu dou um tapa no escritório, estudo alguma coisa ou simplesmente não faço nada.

Resumo: vejo minhas tarefas, desenvolvo-as, atualizo scrum e agenda, preparo as novidades, estudo ou descanso.

2. Fazendo as coisas funcionarem

Obviamente no papel (ou na tela) é tudo mágico e simples, porém, eu sei muito bem que no dia-a-dia a porca torce o rabo.

Você até consegue organizar suas prioridades antes das 8hs. Mas depois, é cliente ligando, problemas aparecendo, uma verdadeira loucura !

Para contornar isto, é simples: organize-se ! Sim, é simples. Antes das 8hs esteja de pé e acordado em seu local de trabalho. Até as 8:30hs tenha sua lista de pendências diária pronta e seu “roteiro” definido.

Se já tomou seu café, dê o start nas tarefas, agora caso seje igual a mim, então, tome um café da manhã esperto e comece a fazer as coisas funcionarem.

Se nesse intervalo algum cliente ligar querendo uma visita sua, tente negociar para o dia seguinte (consulte sua agenda antes !) marcando um horário certo e tão rápido quanto desligar o telefone, já anote este evento em sua agenda. É batata ! Não tem erros !

Após finalizar suas tarefas do dia, se ainda houver tempo, planeje seu próximo dia, e tente andar com seus projetos pessoais, afinal ficar na mesmisse sempre pode custar caro no futuro

3. Analisando as evoluções

O Scrum (sim, falo muito dele pois, é bem eficiente !) permite que você controle suas tarefas semanalmente, ou seja, se você tropeçar em alguma coisa durante a semana, você perceberá que isto lhe atrasou – ou não – e se aplicável planeje novamente sua agenda para colocar as coisas em dia.

4. Vendo resultados

A adoção de um “padrão de organização” é meio sofrida às vezes, mas é bem recompensador depois que você consegue usá-la no dia-a-dia. Após uma semana você verá que não irá passar o dia arrancando os cabelos com deadlines chegando, compromissos esquecidos e “sobrecarga” de horários na sua agenda, pois você não irá agendar nada além do que você tem de disponível na semana.

Tudo que citei aqui pode parecer super óbvio, porém, não é o que nós costumamos aplicar no nosso dia-a-dia. Contamos muito com nossa memória, que às vezes pode funcionar muito bem, mas infelizmente ela não implementa uma agenda.

O modelo que mostrei no começo do post, foi baseado no modelo que o Alexandre implementa – ou implementava na época – e foi ele quem me apresentou isto. Gostei, apliquei e depois nunca mais larguei. Recomendadíssimo !