A primeira coisa a ser feita é colocar a lib do flex-tasks no classpath do ant, para podermos executar as tasks flex no build do nosso projeto. A forma mais fácil de fazer isso é copiando a lib {FLEX_HOME}/ant/lib/flexTasks.jar para diretório de libs da instalação do ant {ANT_HOME}/lib.
Então, para você poder utilizar as tasks flex, basta incluir as linhas abaixo no seu arquivo de build:

<taskdef resource="flexTasks.tasks" classpath="${ant.home}/lib/flexTasks.jar" />
<property name="FLEX_HOME" value="${flex.home}" />

Feito isso você já pode compilar os seus componentes, módulos e quase toda parafernália de um projeto flex tradicional. Para compilar os seus módulos flex, você pode utilizar o <mxmlc>,  indicando o seu .mxml de entrada e o .swf de saída. No meu caso ficou mais ou menos assim:

<!-- compila o modulo flex modules/WhiteboardEditModule.mxml  -->
 <target name="compile-flex-whiteboard-module" depends="compile-java">
 <echo message="${ant.project.name}: Compilando WhiteboardEditModule.mxml ..."/>
 <mxmlc  file="${project.path}/wedoWeb/flex_src/modules/WhiteboardEditModule.mxml"
 output="${project.path}/wedoWeb/output/modules/WhiteboardEditModule.swf"
 keep-generated-actionscript="false"
 incremental="true"
 debug="true"
 allow-source-path-overlap="true"
 show-actionscript-warnings="false"
 show-binding-warnings="false"
 services="${project.path}/wedoWeb/WebContent/WEB-INF/flex/services-config.xml">

 <target-player>10.0.0</target-player>
 <actionscript-file-encoding>"UTF-8"</actionscript-file-encoding>
 <load-config filename="${flex.home}/frameworks/flex-config.xml"/>

 <library-path dir="${flex.home}/frameworks/libs" append="true">
 <include name="*.swc" />
 </library-path>
 <library-path dir="${project.name}/flex_libs" append="true">
 <include name="*.swc" />
 </library-path>

 <locale>pt_BR</locale>
 <locale>en_US</locale>
 <locale>es_ES</locale>
 <source-path path-element="${project.path}/wedoWeb/flex_src" />
 <source-path path-element="${project.path}/Whiteboard/src"/>
 <source-path path-element="${project.path}/wedoWeb/locale/{locale}"/>

 <include-resource-bundles>nous</include-resource-bundles>
 <include-resource-bundles>SharedResources</include-resource-bundles>
 <include-resource-bundles>formatters</include-resource-bundles>
 </mxmlc>
 </target>

É importante indicar o arquivo services-config.xml, ele define algumas diretrizes de compilação do projeto, também relacionadas a utilização da aplicação sobre https. ( é isso né John, vc não vai me fazer passar por mentiroso aqui ?!)

services="${project.path}/wedoWeb/WebContent/WEB-INF/flex/services-config.xml">

Além de indicar o arquivo de configuração do flex, é importante configurar a versão do flashplayer sendo utilizada e o file encoding dos actions scripts. Se você não configurar essas opções… bem, nesse caso coisas estranhas vão acontecer.

<target-player>10.0.0</target-player>
 <actionscript-file-encoding>"UTF-8"</actionscript-file-encoding>
 <load-config filename="${flex.home}/frameworks/flex-config.xml"/>

Por incrível que pareça, a parametrização de intercionalização do projeto, foi mais fácil do que eu esperava. No nosso caso, o sistema está disponível em 3 idiomas.  Bastaram mais umas linhas, e tudo certo.

<locale>pt_BR</locale>
 <locale>en_US</locale>
 <locale>es_ES</locale>
 <source-path path-element="${project.path}/wedoWeb/flex_src" />
 <source-path path-element="${project.path}/Whiteboard/src"/>
 <source-path path-element="${project.path}/wedoWeb/locale/{locale}"/>

<include-resource-bundles>nous</include-resource-bundles>
 <include-resource-bundles>SharedResources</include-resource-bundles>
 <include-resource-bundles>formatters</include-resource-bundles>

Para compilar os demais módulos flex do seu projeto, a história se repte, é só mandar um <mxmlc> da mesma forma como fizemos aí em cima.

Depois disso,  ainda é preciso gerar o arquivo html principal da aplicação, sim.. aquele objeto que traz consigo o .swf dentro dele: o html-wrapper. O elemento <html-wrapper> gera pra você o index.html e AC_OETags.js, que serão necessários no deploy da aplicação. Além disso ele pode gerar o resto da parafernália (adoro a pronúncia dessa palavra: pa-ra-fer-ná-li-a …), como os arquivos historyFrame.html, history.css e history.js

<!-- Gera html-wrapper  -->
 <target name="wrapper-flex-html" depends="compile-flex-wedoWeb-module">
 <echo message="${ant.project.name}: Gerando html-wrapper ..."/>
 <html-wrapper
 title=""
 file="wedoWeb.html"
 height=""
 width=""
 bgcolor=""
 application=""
 swf=""
 version-major=""
 version-minor=""
 version-revision=""
 history="true"
 template="express-installation"
 output="${project.name}/output"/>

 <html-wrapper
 title=""
 file="wedoTest.html"
 height=""
 width=""
 bgcolor=""
 application=""
 swf=""
 version-major=""
 version-minor=""
 version-revision=""
 history="true"
 template="express-installation"
 output="${project.name}/output"/>

 </target>

O problema é que no nosso caso, já temos um index.template.html, que é utilizado na geração do html principal da aplicação. Por isso eu utilizei o <html-wrapper> apenas para geração da parafernália (novamente…) de arquivos AC_OETags.js, historyFrame.html, history.css, history.js e o index.html padrão. Depois bastaram alguns ctrl-c, ctrl-v para os passar os parãmetros do template para o meu recém criado wedoWeb.html.

<target name="copy-html-template" depends="wrapper-flex-html">
 <echo message="${ant.project.name}: Gerando wedoWeb.html ..."/>
 <delete file="wedoWeb/output/wedoWeb.html"/>
 <copy file="${project.name}/html-template/index.template.html"    tofile="${project.name}/output/wedoWeb.html" />
 <replace file="${project.name}/output/wedoWeb.html" token="$${title}" value=""/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${swf}" value="wedoWeb"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${width}" value="100%"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${height}" value="100%"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${bgcolor}" value="#869ca7"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${application}" value="wedoWeb"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${version_major}" value="10"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${version_minor}" value="0"/>
 <replace file="${project.name}/output/wedoWeb.html" token="$${version_revision}" value="0"/>

Claro, antes disso ainda precisei manipular alguns arquivos… uns pra lá outros pra cá…  pra poder gerar o .war do jeito que eu queria. Mas isso também vai depender muito da estrutura do seu projeto.

Bem, acho que é isso. Depois é compilar todos os componentes e módulos flex, juntar tudo com o seu código fonte java,  empacotar o .war e “voilà”, temos o um projeto flex compilável.

Logo após as primeiras tentivas e alguns java.lang.OutOfMemoryError: Java heap space , precisei configurar a quantidade de memória para utlização do ANT. No script de inicialização, ant.bat, adicionei a linha abaixo e o problema foi resolvido.

   ANT_OPTS=-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m

Mas depois foi só correr pro abraço…

De qualquer forma, eu conheço de flex o quanto jogo de futebol, então se quiserem uma referência mais segura em desenvolvimento flex, é melhor darem uma olhada no blog do John.

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 …

Mas sinceramente, algumas coisas não tenho mais paciência pra escutar. Não sei se estou ficando velho. Não sei se estou ficando muito rabujento. Talvez sejam ambas as coisas. Quando se está a algum tempo “fazendo programas”, você acaba apreedendo muita coisa boa, mas principalmente, acaba identificando tudo aquilo que NÃO SE DEVE FAZER em desenvolvimento de software.
Vou descrever abaixo algumas frases clássicas que provavelmente você já ouviu em alguma reunião, tech-talk ou de algum gerente “espertão”.

1. Programador não é pago pra pensar, é pago pra programar. Essa já perdeu a graça. Sério. Se seu gerente ainda acha que programação é simplesmente um processo mecânico e repetitivo, diga a ele para contratar um milhão de macacos para fazer o trabalho. Bem mais barato.
   Por favor, não importa qual o nome que as empresas dão a ele: desenvolvedor, programador, analista-programador, mas esse cara deve ser capaz de identificar requisitos e implementar soluções. E muito mais que isso, deve ter noções de arquitetura de software, deve conhecer as tecnologias e ferramentas que utiliza, se preocupar com requisitos não-funcionais, escalabilidade, etc. Não é necessário ser um “super-homem” auto-didata, mas precisa ter flexibilidade suficiente para participar de reuniões com o cliente e ter conhecimento técnico para implementar uma solução. E de qualquer forma, em desenvolvimento de software, code monkeys nunca foram uma opção.

2. Programador deve apenas codificar o que está especificado.
   Se a empresa que você trabalha tem um “analista” que pensa no que precisa ser feito, escreve um monte de diagramas numa linguagem de modelagem (a.k.a UML) e depois passa para um “programador” que apenas codifica em linguagem executável o que foi especificado, acho que seria interessante seu gerente dar uma olhada nisso aqui. E se esta abordagem fosse realmente eficiente/eficaz, os relatorios do Standish Group não estariam desse jeito.
   Programador não baixa a cabeça e sai codificando. Programador deve saber o “porque” está implementando algo. Deve saber o contexto do problema e saber quais as necessidades dos stakeholders. Programador avalia soluções. Sugere melhorias. Critica requisitos de negócio. Ao contrário do que pregam muitas consultorias por aí, BONS PROGRAMADORES SEMPRE SERÃO FUNDAMENTAIS.
   

3. Mas é apenas uma “alteraçãozínha” !!!
   Pelo amor de Deus, não existe uma “alteraçãozinha” em TI. Por melhor que seja o design de suas classes. Por mais bem escrito que sejam seus componentes. Por mais simples que seja o seu ambiente de desenvolvimento, uma “alteraçãozinha” sempre irá envolver esforços de programação, testes e build para produção. Quanto a isso, independente das metodologia, frameworks ou ferramentas empregadas, não se pode fazer mágica.
   Se você trabalha num ambiente um pouco mais ágil (a.k.a SCRUM), é bem provável que você irá conseguir responder mais rapidamente a mudanças de requisitos, e o tratamento de alterações de código fonte serão mais tranquilas. Mas se você trabalha numa empresa que possui milhares de fases de desenvolvimento, artefatos, papelada e burocracia, a alteração de um “label” em produção pode se tornar uma tarefa sofrível.
   

4. Está pronto, só falta testar !!!
   Essa é clássica. Se você tem algum trecho de código que não foi coberto por testes… bem… você tem apenas código fonte.

   - Pronto, terminei !!!
   - Que bom !!! Posso ver como ficou ?!
   - Não.. não…não testei isso ainda..!!!
   - Humm ?!
   
   Qualquer framework, componente ou serviço que se preze, deve ser no mínimo, verificável. E isso não aprendi na faculdade. Foi a tia Perivalda que me ensinou, a muito tempo atrás, nas aulas práticas de ciências: se um experimento não pode ser verificável, então é apenas um modelo teórico.
   Qualquer alteração num sistema, deve ser acompanhado por no mínimo, um caso de testes. É fundamental que este mesmo sistema, tenha um conjunto de testes unitários e teste integrados que me permitam dizer se algo está errado.
   A muito tempo deixei de acreditar naqueles que dizem que os testes são outra “fase” do processo e que programador não se envolve com testes, apenas codifica. Programadores escrevem testes, e ponto final. TDD, por exemplo, é uma ótima abordagem que permite o desenvolvimento de sistemas “testáveis” e vericáveis.

   Por ora, essas são algumas das pérolas da programação que me vêm à memória. E mesmo que esse post tenha ficado com cara de “desabafo”, é bem possível que ainda escreva uma continuação para ele…