You are currently browsing the category archive for the 'Source Control' category.
Quando me decidi a preparar um ‘build server’ para ter integração contínua no projecto, comecei a procurar na wikipedia pelos possíveis build servers existentes. Apesar de já ter trabalhado com o ‘Cruise Control’ na medialog, dado o pouco tempo (horas!) que tinha para preparar tudo, decidi-me pelo TeamCity da genial empresa JetBrains, também responsáveis pelo resharper.
No final, se tivesse de configurar os scripts nAnt para ter o servidor a compilar, testar e criar as releases dos vários componentes, teria perdido uns bons dias. Com o TeamCity, e inicialmente usando os ficheiros .sol do Visual Studio para criar os builds, foi tudo feito numa tarde*…
Altamente recomendado.
*Claro que assim que quis adicionar umas funcionalidades ‘especiais de corrida’, tive de fazer um build script de raiz. Mas mesmo assim…
Quando saí da faculdade (e até enquanto estava na faculdade) uma má percepção que tinha era que as entrevistas serviam para a empresa me fazer uma série de perguntas, de modo a saberem um pouco mais de mim, do que tinha feito e do que queria fazer e… pronto. Se tivesse conseguido “vender o peixe” eles haveriam de me ligar.
Hoje em dia alterei muito a minha perspectiva… a entrevista tem de servir tanto para eles saberem se eu sou a pessoa indicada para o lugar e para eu saber se eles são a empresa indicada para a minha próxima experiência.
Uma pergunta que geralmente fazem é: “Onde é que se vê daqui a 5 anos?”. Bem, no meu caso.. eu gosto de programar. Daqui a 5 anos… neste momento espero que daqui a 5 anos esteja a programar! E não, não é falta de ambição. Não, não sou uma pessoa que não gosta de subir na carreira. Mas gosto de programar. Claro que quero estar a gerir uma pequena equipa, tenho conhecimento que gostava de passar, tal como me foi passado. Mas a programar. Porquê? Porque, e pondo as tretas de lado, sou bom nisso. E se me derem a escolher entre um lugar como Developer ou Project Manager, podem ter a certeza que sei o que escolher.
E por falar nisso, como é que é feita a gestão dos projectos? Tenho de estar a preencher uma timesheet sempre que mexo numa classe? Por cada tarefa que faça, tenho de preencher um relatório a dizer o que estava a fazer das dez ao meio dia? Mas porquê? O project manager não sabe o que ando a fazer? Se sabe, então ele que faça o trabalho dele e me deixe a mim fazer o meu. Se não sabe, contratem outro. Um que não seja um gajo a tentar não ser programador.
E para os programadores, como é o processo de desenvolvimento? Há controlo de versões do código? Se não houver, desculpem, não é nada contra a empresa mas se não há gestão do código, não se podem chamar uma empresa de software. E é numa empresa dessas que eu quero trabalhar.
Se tiverem integração contínua então… Hmm, já começam a parecer uma empresa de jeito! É que, e de certeza que concordam, com integração contínua temos a certeza que o codigo que está guardado… bem, temos a certeza que compila! É que, e já aconteceu mais do que eu gostava de admitir, receber código que temos de manter ou alterar e o código não compila… É frustrante. E sim, a culpa até pode nem ser de ninguém, eu é que preciso de instalar a ferramenta X ou a dll Y para isto funcionar. Mas se eu preciso de um manual de instruções para poder começar a trabalhar, algo está mal.
Claro que já nem peço que a empresa tenha testes unitários implementados no build diário… mas se há ou se não se importam que eu começe… perfeito! Sim, eu sei que fazer testes faz com que o processo de desenvolvimento demore mais tempo mas acreditem em mim, quando lá para o final do projecto tiveremos com problemas no software, vão querer terem perdido algumas horas todas as semanas para não perder estes dias no final. Ah, e já disse que os testes também podem ser usados para inferir sobre a qualidade do código? E como vocês dizem muito, pouca informação é melhor que nenhuma. Sabem, alguns dos processes ágeis não vos retiram o controle sobre o projecto, mas permitem-nos a nós trabalhar melhor, com mais confiança acerca do que estamos a fazer.
Bem, se chegámos ate aqui, parece que vocês podem ser a empresa indicada para o lugar.
Claro que ainda teríamos de falar sobre a qualidade do local de trabalho mas vou assumir que a empresa já assinou a “Programmer’s Bill Of Rights” portanto podemos passar isso à frente.
Depois disto, parece-me que tudo possa correr bem… mas não esperem que eu pare de chatear por aceitar entrar na empresa. Ainda há coisas que vou poder querer que aconteçam.
Por exemplo, nas empresas por onde passei sempre houve programadores bons e outros menos bons. Sim, é verdade, nem todos eram geniais. E, a não ser que esteja a ser entrevistado para uma empresa excepcional, de certeza que nesta se passa o mesmo. É que a qualidade dos programadores segue mais ou menos a seguinte distribuição:
Há uns bestas e há uns bestiais. E no meio estão os outros. E, fazendo parte da equipa, tendo de manter, alterar e apagar o código de todos eles, quanto melhor for a equipa, melhor para mim e para a equipa.
Assim, já pensaram em dar um dia de 15 em 15 dias para que os programadores possam rever código em conjunto na sala de reuniões, discutindo o que está bem e o que está mal? Ah sim, e vocês, não estão convidados. É que sabem, estas reuniões não são para serem usadas para fazer as vossas reviews sobre os elementos da equipa. Queremos passar o conhecimento do programador bestial para os outros.
Mas estão convidados a trazerem os cafés a meio do dia para a malta aproveitar melhor o tempo, obrigado.
Desde que experimentei a plataforma STDL que tenho andado a falar com o autor e a experimentar umas coisas… No sábado decidi fazer um AddIn para o visual studio para gerar os ficheiros STDL automáticamente da classe que estiver no momento aberta no editor.
Depois de discutir isto com o Neville, decidimos incluir isto no mesmo projecto, com o objectivo de tentar no futuro usar o AddIn como forma principal de usar STDL’s em ambientes .Net.
Apesar de ainda não estar concluido já se pode usar o menu de contexto do editor de texto para gerar o ficheiro STDL:
O ficheiro gerado é um stub e tem de ser depois concluido manualmente para ser realmente util. Para estar finalizado para já temos previsto:
- Gerar dinamicamente o código sempre que se gravar o ficheiro STDL.
- Usar o editor do VS para colocar côr em keywords da linguagem STDL, também mostrando erros sem compilar (como o resharper).
- Usar o editor do VS para deixar fazer folding do código.
Dado que este é o meu primeiro AddIn, se alguém tiver alguma dica sobre como fazer isto… 
Entretando podem ir ao site e fazer download, compatível tanto para o vs2005 como para o vs2008.
Para quem anda à procura de uma forma de integrar SVN com o Visual Studio 2008, talvez seja boa ideia experimentar o AnkhSVN. É uma ferramenta grátis que integra perfeitamente no Visual Studio, com explorador de repositório, indicações visuais do estado do ficheiro no solution explorer no qual podemos, usando o menu de contexto, fazer commit, etc. Obviamente que não é substituto do essencial TortoiseSVN.
Para soluções de hosting grátis para projectos usando SVN, recomendo o Assembla. Não obriga a que os projectos sejam open-source, oferecendo ainda imensas ferramentas para ajudar a organizar a (possivelmente espalhada pelo mundo) equipa de desenvolvimento.
