Esse ano estamos tentando fazer algumas mundanças na Informant. Percebemos que usar quadros magnéticos, pregar post-it’s por toda empresa e fazer reuniões diárias não estavam nos fazendo mais “ágeis”, e na prática… pouca coisa era aplicada. Agora estamos buscando realmente implementar algo ágil nos nossos projetos. Estamos dandos os primeiros passos, mas muita coisa boa está sendo planejada para este ano.

Uma das coisas que precisamos melhorar é a forma como trabalhamos com nosso repositório de fontes. Estamos modificando nossos procedimentos e nosso trabalho diário para manter nosso respositório mais confiável: A Integração Contínua é uma prática essencial do XP, que não se resume apenas a utilização de uma ferramenta, mas a automatização de build’s e deploy’s pode economizar muito tempo de desenvolvimento. Deixando o programador disponível para realizar o seu trabalho mais importante: programar.

Estamos começando a utilizar o CruiseControl, ferramenta que ainda não conhecia de perto. Apesar de já ter trabalhado com algumas ferramentas do gênero (ex.: Bamboo), o CC me impressionou bastante com relação a flexibilidade de configuração e implementação de planos de build. Para quem está perdendo muito tempo com liberação de versões, builds, deploys de aplicativos, e está pensando em utilizar o CC, vou repassar aqui os meus passos iniciais de configuração da ferramenta em ambiente Windows:

1. Faça o download da última release do CC, que atualmente é a 2.8.3 e descompacte vvocê achar melhor, por exemplo em C:\java\cruisecontrol-bin-2.8.3
2. O ideal é criar um diretório de trabalho configuração de seus projetos. (ex.: C:\java\work\cruise). Achei mais fácil iniciar o CC desta mesma workspace, por isso também copiei os arquivos cruisecontrol.bat, config.xml e dashboard-config.xml para o diretório /cruise. Bastando apenas fazer alguns acertos no cruisecontrol.bat, apontando o launcher do CC para o caminho correto (C:/java/cruisecontrol-bin-2.8.3/lib/cruisecontrol-launcher.jar). Nesse momento, você já poderá iniciar o CC. Apontando o seu navegador para http://localhost:8080/dashboard/tab/dashboard já será possível acessar a ferramenta. Se tudo der certo, você deverá ver o Dashboard Server, que por enquanto, não terá nenhum projeto disponível.Você deverá ter a variável JAVA_HOME também já configurada no seu Path.
3. Agora precisamos configurar um projeto. No CC, todos os projetos são configurados a partir do arquivo config.xml. Quando trabalhamos com múltiplos projetos, é interessante manter a configuração de cada um deles em arquivos separados, para isso podemos alterar o config.xml para que fique da seguinte forma:

   <!-- config.xml -->
   <!DOCTYPE cruisecontrol [
      <!ENTITY build-informantUtils SYSTEM "projects/informantUtils-config.xml">
      <!ENTITY build-informantEJB SYSTEM "projects/informantEJB-config.xml">
   ]>
   <cruisecontrol>
       <property file="config.properties"/>
       <plugin name="svn" classname="net.sourceforge.cruisecontrol.sourcecontrols.SVN"/>
       <plugin name="svnbootstrapper" classname="net.sourceforge.cruisecontrol.bootstrappers.SVNBootstrapper"/>
       <system>
          <configuration>
              <threads count="2"/>
          </configuration>
       </system>
       &build-informantLibs;
       &build-informantEJB;
   </cruisecontrol>
   

4. O meu objetivo inicial com a utilização do CC, era fazer o build automático das aplicações no nosso ambiente de testes sempre que alterações fosse efetivadas (commit), garantindo que nosso repositório esteja sempre compilando, e que a qualquer momento, tivéssemos uma versão disponível para liberação. Para isso, utilizamos o elemento <modificationset>, que determina como o CC procura por alterações no repositório e quando vai executar o build do projeto.

   <!-- informantEJB-config.xml -->
   <plugin name="svn" classname="net.sourceforge.cruisecontrol.sourcecontrols.SVN"/>;
   <plugin name="svnbootstrapper" classname="net.sourceforge.cruisecontrol.bootstrappers.SVNBootstrapper"/>
       <modificationset quietperiod="10">
           <svn localWorkingCopy="checkout/agil/${project.name}"
                repositoryLocation="${svn.repository}/${svn.trunk}/InformantEJB"
                username="${svn.user}"
                password="${svn.passwd}">
           </svn>
       </modificationset>
   

   Assim monitoramos alterações do projeto no SVN e quando o CC deverá fazer o build do projeto. Veja que é preciso indicar o respositório local do projeto (localWorkingCopy), para onde os fontes do projetos serão copiados e compilados no momento do build. Por isso é necessário criar um diretório de checkout local para os projetos no seu diretório de trabalho (ex.: /work/cruise/checkout)
   Para tudo dar certo, ainda iremos precisar incluir os plugins do svn, conforme acima. Também será necessária instalar e garantir que o SVN esteja no seu Path.

5. Então utlizamos o elemento <schedule> com interval=”300″, para fazer com que o CC verifique o respositório do SVN a cada 5 minutos por novas modificações.  Além disso utilizamos o atributo time=”2300″, forçando com que um build seja executado diariamente as 23:00 horas. Nestes casos, o CC irá executar o script de build do projeto:  build-file=”checkout\agil\build-${project.name.xml}”

   <!-- informantEJB-config.xml -->
   <schedule  interval="500" showProgress="true">
        <ant  antscript="${ant.home}\bin\ant.bat"
              buildfile="checkout\agil\build-${project.name}.xml"
              target="build-informantEJB"
              uselogger="true"
              usedebug="true"
              time="2300"/>
   </schedule>
   

   Será necessário ter o ant instalado. O próprio CC  já vem com a versão 1.7.0 do ant, disponível no diretório de instalação do CC (C:/java/cruisecontrol-bin-2.8.3/apache-ant-1.7.0).

6. Precisamos agora definir o diretório de logs do projeto. Crie um diretório de logs no seu diretório de trabalho (ex.: C:/java/work/cruise/logs). Isso é importante, porque o CC controla todo o histórico de builds e status (buildstatus) dos projetos em execução, através deste diretório de logs. Dentro do diretório de logs serão criados outros vários subdiretórios, um para cada projeto.
   E acrescente a configuração de log ao projeto:

   <!-- informantEJB-config.xml -->
   <log dir="logs/${project.name}"/>
   

7. Após cada build do projeto, geralmente um artefato é gerado. Um arquivo war, ear ou zip por exemplo. Neste caso, um arquivo .jar. Por isso é preciso definir uma diretório onde todos esses artefatos serão armazenados após um build realizado com sucesso. Crie um diretório para os artefatos gerados no seu diretório de trabalho (ex.: C:/java/work/cruise/artifacts).  Dentro do diretório de artefatos serão criados outros vários subdiretórios, um para cada projeto.
   Para dizer ao CC, onde e quais artefatos serão publicados, utilizamos o elemento <artifactpublisher>:

   <!-- informantEJB-config.xml -->
   <publishers>
       <artifactspublisher dir="checkout/agil/${project.name}/output" dest="artifacts/${project.name}"/>
   </publishers>
   

8. Com o arquivo de configuração do projeto concluído (projects/informantEJB-config.xml), precisamos apenas do script de build do projeto, que será chamado pelo CC. No meu caso, ficou mais ou menos assim:

   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <project basedir="." default="build-informantEJB" name="informantEJB">
       <echo message="Project:informantEJB: Executando..."/>
   
       <property file="build.properties"/>
       <property name="svnant.latest.url" value="${agil.svn.repository}/${agil.svn.trunk}/informantEJB"/>
       <property name="local.repository" value="informantEJB"/>
   
       <path id="informant.libs">
           <fileset dir="libs/jars">
     	   <include name="**/*.jar"/>
   	</fileset>
       </path>
   
       <path id="jboss-runtime.libs">
   	<fileset dir="../../dependencies/jboss-runtime/client">
       	    <include name="**/*.jar"/>
   	</fileset>
   	<fileset dir="../../dependencies/jboss-runtime/lib">
    	    <include name="**/*.jar"/>
   	</fileset>
       </path>
   
       <path id="ejb.libs">
           <path refid="informant.libs"/>
           <path refid="jboss-runtime.libs"/>
       </path>
   
       <taskdef  resource="svntask.properties"/>
       <target name="checkout">
   	<echo message="${ant.project.name}: Fazendo checkout do respositorio ${svnant.latest.url}..."/>
   	<svn username="${agil.svn.user}" password="${agil.svn.passwd}">
     	    <checkout url="${svnant.latest.url}" revision="HEAD" destPath="${local.repository}" />
   	</svn>
       </target>
   
       <target name="mkdir">
           <mkdir dir="informantEJB/build/classes"/>
   		<mkdir dir="informantEJB/output"/>
           <copy includeemptydirs="false" todir="informantEJB/build/classes">
               <fileset dir="informantEJB/ejbModule">
                   <exclude name="**/*.launch"/>
                   <exclude name="**/*.java"/>
               </fileset>
           </copy>
       </target>
   
       <target depends="checkout,mkdir" name="compile">
           <echo message="${ant.project.name}: ${ant.file}"/>
           <javac debug="true"
   	       debuglevel="${debug.level}"
   	       destdir="informantEJB/build/classes"
   	       source="${compile.source}"
   	       target="${compile.target}"
   	       classpathref="ejb.libs">
               <src path="informantEJB/ejbModule"/>
           </javac>
       </target>
   
       <target depends="compile" name="build-informantEJB">
   	<echo message="${ant.project.name}: Gerando informantEJB.jar..."/>
   	<jar 	destfile="informantEJB/output/informantEJB.jar"
   		basedir="informantEJB/build/classes"
   		includes="**/*.class,**/*.xml">
   		<manifest>
         		    <attribute name="Created-By" value="Agil ERP"/>
   		    <attribute name="Manifest-Version" value="1.0"/>
   		    <attribute name="Implementation-Vendor" value="Informant"/>
   		    <attribute name="Implementation-Title" value="Informant"/>
   		    <attribute name="Implementation-Version" value="1.0"/>
   		</manifest>
   	</jar>
       </target>
   </project>
   

   O plano de build do projeto agora está OK: configuramos o informantEJB-config.xml para que execute o script de build (build-informantEJB.xml) quando alguma alteração for realizada no repositório. Além disso o CC irá executar também um build diário, as 23:00 horas.

9. Tudo certo agora?! NÃO.
   Mesmo que você faça um build manual do projeto através do CC ( http://localhost:8080/dashboard/tab/dashboard), o status do projeto continuará inativo. Isso acontece porque criamos um diretório de trabalho em C:/java/work/cruise, onde serão armazenados os logs e artefatos do projeto. Mas o CC ainda não sabe disso.Crie um arquivo override.properties em C:/java/cruisecontrol-bin-2.8.3/reporting/jsp dessa forma:

   # This should be the full path to your CruiseControl log directory.
   # If you are in multi-project mode, there will be multiple sub-directories
   # inside this log directory, one for each project.
   user.log.dir=C:/java/work/cruise/logs
   
   # This should be the path to your current build status file, # expressed relative to the project's log directory.
   user.build.status.file=C:/java/work/cruise/logs/buildstatus.txt
   
   # This should be the absolute path to the directory where # additional build artifacts are stored.
   cruise.build.artifacts.dir=C:/java/work/cruise/artifacts
   

Essa é uma configuração bem básica. Mas já dá pra ter uma idéia do que pode ser feito. O CC foi implementado para ser extensível e flexível o suficiente para que você possa customizar quase tudo. Além disso, existem vários plugins e outros add-ons que podem ser utilizados pafa aumentar ainda mais as possibilidades de uso do framework.

Tá bom, tá bom. Estava tudo muito parádo por aqui. Parado não, a melhor definição é coma. Isso, o coding4food estava em coma. Mas era um coma induzido. Estive um tempo envolvido com alguns projetos muito importantes (jogando video-game, vendo TV, lendo alguns livros, engordando, … ).

Mas hoje o coding4food saiu do coma graças a um e-mail que perambulou entre os departamentos da empresa onde trabalho. O texto falava sobre a regulamentação da área de TI. E mais uma vez, o famigerado projeto de lei 7109/06 era alvo de novas discussões. O projeto já é antigo, porém vem a tona de tempos em tempos, como um span-highlander que insiste em renascer entre fóruns e afins.

O Sr. Bonifácio Andrada já foi responsável por longas threads no guj e as opniões sobre o assunto são as mais diversas: a SBC sempre foi contra, porém o CCT aprovou o projeto em março de 2008. Tem gente que não pode nem ouvir no assunto, outros acham que um sindicato pode significar um aumento de salário rápido e fácil, quase que milagroso, como sugerido pelo e-mail abaixo:

Pessoal, até que enfim, ao que tudo parece agora sai a lei que regulamenta nossa profissão. Isso significa um sindicato próprio (não esses fantasmas que cobram de nós sem nem sabermos ao menos quem são), piso salarial, garantias e deveres definidos, etc.

O link para a notificação de entrada na pauta de Senado é, acompanhem o andamento do projeto através do cadastro no site:
http://www.senado.gov.br/sf/ atividade/Materia/Detalhes. asp?p_cod_mate=82918

Por favor, perdi alguma coisa ou tem gente achando que vai ganhar um aumento de salário com a simples criação de um conselho ou sindicato ? Provavelmente o Sr. Bonifácio Andrada conhece do mercado de TI o mesmo que o Sr. Expedíto Júnior: ABSOLUTAMENTE NÁDA.

Sério. Por vezes procurei argumentos ou justificativas que me fizessem acreditar que este projeto de lei não fosse mais uma “politicagem” sem pé nem cabeça. Não acredito mais em analistas de sistemas, porque iria acreditar nisso ?! Então vamos lá, como nem a ACM, nem a SBC encontrou motivos para impor alguma regulamentação em nossa área, vamos deixar que os profissionais lá de Brasília o façam.

O que posso dizer sobre isso é apenas repetir o Akita:

Será que um músico diplomado é melhor que um Villa Lobos? Será que um pintor diplomado é melhor do que uma Tarsila do Amaral? Será que um escritor formado será melhor do que Machado de Assis? Será que o Washington Olivetto é um grande publicitário porque é formado? Ah, não, ele nunca concluiu o curso de publicidade da FAAP.

Grandes programadores não são formados. Grandes programadores se formam.

Não entendo porque algumas pessoas tem uma necessidade de proteção de algum órgão, sindicato ou conselho para se sentirem mais seguras. Pra mim, a competência é o que prevalece e não o diploma. Não sou contra o curso superior. Ir a faculdade foi umas das melhores escolhas que já fiz na minha vida. Mas conheço ótimos profissionais hoje, que não foram alunos tão brilhantes assim. Isso porque os bons profissionais não param apenas com o canudo. Estão sempre estudando, se aperfeiçoando, lendo, indo um pouco mais além. Para estes profissionais, o mercado sempre terá espaço. Tenho a impressão de quem é a favor da regulamentação, precisa de uma “garantia legal” para manter o seu emprego. Se este for o caso, acho que o funcionarismo público, seria o mais indicado.

Como daqui pra frente apenas os analistas de sistemas poderão desenvolver software, vamos excluir todos os engenheiros, matemáticos, físicos, administradores, filósofos que estão fazendo programas de computador por esse país a fóra. Afinal, eles não tem competência para fazer isso.
Sendo assim, alguém que é a favor dessa lei poderia me dizer se também está disposto a apenas comprar software desenvolvido por analistas de sistemas “licenciados” ? (… porque aposto que seu computador está infestado de “programinhas” desenvolvidos por adolescentes.)
Aliás, excluir engenheiros da área de TI seria no mínimo, cômico. As ciências da computação por anos vem tentando (sem muito sucesso, diga-se de passagem) aplicar técnicas de engenharia no desenvolvimento de software. Na verdade, a maioria das metodologias utilizadas hoje estão com um pé na engenheria. Mas isso não importa, vamos mandar todo esse pessoal para faculdade, porque eles não conhecem náda de computação.

Como iríamos tratar os projetos open-source? Com certeza não poderíamos mais utilizar muitos desses softwares, porque esses projetos são desenvolvidos por profissionais de todo o mundo, de todas as idades, todas as áreas e formações. Não, não poderíamos utilizar um software desse. Quem iria nos garantir que foi desenvolvido apenas por analistas de sistemas formados ? Com certeza, não poderíamos correr esse risco.

“Mas tem muita gente sem formação, roubando a vaga de profissional com curso superior!!!”

Essa é a maior das falácias. Seria hilário se não fosse triste. Se o profissional não for competente, não são seus diplomas ou certificados que irão lhe salvar. A competencia é o que prevalece. Ninguém rouba vága de ninguém. Apenas alguns profissioanis são mais competentes no que fazem, do que os outros, simples assim.

Alguém já conheceu algum engenheiro que se sentisse mais seguro pelo CREA ?!
Alguém já viu a OAB, CREA, CRA ou algum outro conselho convocar uma greve ? Fico me perguntando por que não ?
O MEC já existe a muito tempo… mas impediu a abertura indiscriminada de pseudo-faculdades e o comércio de diplomas pela internet ? Porque que será ?

A reserva de mercado, como proposto por esse projeto, é andar para trás, e a ACM já vem falando nisso a muito tempo:

ACM is opposed to the licensing of software engineers at this time
because ACM believes it is premature and would not be effective at
addressing the problems of software quality and reliability.
ACM is, however, committed to solving the software quality problem
by promoting research and development, by developing a core body of
knowledge for software engineering, and by identifying standards of
practice.

Is ACM against licensing software engineers?
Yes. For legal reasons, the only way to be a licensed software
engineer is to become a PE. As described in the Safety-Critical
report (see www.acm.org/serving/ se_policy/safety_critical.pdf), several
topics on which all prospective PEs are tested, such as fluid mechanics
and thermodynamics, are beyond the scope of software engineering.
Mastering these topics could detract from the study of more relevant
areas.
In addition, a software engineering license would be interpreted as an
authoritative statement that the licensed engineer is capable of producing
software systems of consistent reliability, dependability, and
usability. The ACM Council concluded that our state of knowledge and
practice is too immature to give such assurances.

Is ACM against software engineering being viewed as a profession?
No. ACM believes it is important to foster the emergence of a true IT profession,
not just software engineering. A field does not need licensing to be a
profession.

A área de TI já não sofre o suficiente com escassez de profissionais no mercado ?!
A CLT já não impõe burocracia e carga tributária suficientes sobre empregadores e empregados nesse país ?!
O mercado de TI no Brasil já não tem problemas o suficiente ?!
Afinal, quem serão os verdadeiros beneficiados com esta regulamentação ?

Alguns dias atrás, me vi numa discussão com alguns colegas, sobre funções, atividades e cargos dentro de uma empresa. Apensar desse assunto ainda ser bem confuso em TI, a maioria soube descrever suas atividades diárias como programadores. Porém, essa descrição não foi obtida tão facilmente quando nos perguntamos: Afinal de contas, o que um “Analista de Sistemas” faz ?

Alguns me falaram que o analista de sistemas é um profissional com mais experiência, com perfil investigativo, que deve fazer a análise dos requisitos e modelar uma solução. Outros disseram que analista de sistema não devem “perder”  tempo com detalhes sobre linguagem ou tecnologia, porque “análise” de sistemas deve ser feita em alto nível, a.k.a UML. Escutei também alguns comentários clássicos: analista de sistemas necessariamente não precisa saber programar, precisa apenas conhecer UML e algum editor de texto. ( “analistas de sitemas não precisam saber programar…”. Com certeza essa merece estar nas próximas falácias da programação, parte ll … hehe )

Sobre esse assunto, tenho que dizer que concordo com Barry Hawkins: a super divisão de trabalho no desenvolvimento de software, foi umas das piores experiências da indústria de software nos últimos anos.

One of the most widespread tragedies in the practice of software development has been the tendency of corporate culture to over-compartmentalize the activities of software development. In the upper echelon of the artificial hierarchy of task separation sits the software architect. Sequestered away from the disturbing din of real life within the company, these persons are liberated from the mundane, in order that they may orchestrate plans that set in motion the work of many, unfettered by such things as domain knowledge and implementation constraints.
Know this; the only people who belong in white towers are the captured princesses of fairy tales, and even then it was not of their volition. Partitioning the activity of design away from implementation destroys the call-and-response cycle between design and implementation. The relevance of your work is directly related to how engaged you are in the domain.
- Barry Hawkins.

Estou convencido, que a separação das atividades de design e programação deveria ser qualificada como um anti-pattern do desenvolvimento de software. O waterfall já vem mostrando por anos, que essa abordagem é um erro.

Porque é necessário criar um cargo especial para atividades, que deveriam ser de responsabilidade do programador ?! Análise, design, programação e arquitetura são atividades e não cargos. Nós, como programadores, precisamos vestir “chapéus” diferentes dentro de um projeto.

Quando questionamos requisitos, buscamos informações de nossos usuários, organizamos e priorizamos tarefas, estamos vestindo nosso chapéu de analista e gerente de projetos. Quando estamos codificando, nos preocupando com manutenabilidade, performance e com a correta aplicação de patterns, estamos vestindo nosso chapéu de programador e projetista. Ao escolhermos por um framework, por uma API, estamos com certeza tomando decisões de arquitetura.
Não quero dizer aqui, que todo programador dever ser um  Macgyver em TI. Mas tenho certeza, que se você é programador, é bem provável que você precise colocar à prova diariamente suas habilidades como programador, analista, arquiteto ou gerente.

A maioria dos programadores passam anos querendo se tornar analista de sistemas, e quando conseguem, descobrem que como programadores, já desempenhavam atividades de análise a muito tempo. Além do mais, achar que um monte de diagramas UML podem modelar um sistema inteiro sem programar uma linha de código, não é algo muito inteligente. Analistas, arquitetos, projetistas, seja lá como for o nome que deram para ele, mas esse cara precisa saber programar -  If you design it, you should be able to code it - Mike Brown:

When designing the architecture for your project, you need to have a feel for what amount of effort is necessary to implement the various elements of your design. The easiest way to have the knowledge of the effort that a specific design element will take is to have developed it before.

Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects. Mike Brown

Muitas empresas de TI estão procurando “achatar” hierarquias, procurando manter profissionais mais qualificados, com conhecimentos multidisciplinares e que possam atuar em diversos papéis diferentes. Que possam programar, tomar decisões de arquitetura ou conversar com usuários se for necessário. Por mais que muita gente ainda pense o contrário: Profissionais competentes e equipes motivadas são fundamentais em qualquer empresa.

E mesmo que os “Analistas de Sistemas” ainda existam para enfeitar alguns crachás corporativos ou anúncios de RH, eu já deixei de acreditar neles já faz algum tempo …