O gestor de projecto irá usufruir do conforto do Airgile para gerir e acompanhar a evolução dos projectos, delegando tarefas aos consultores e programadores. Estes receberão as tarefas directamente no Eclipse, a sua ferramenta de trabalho de eleição. À medida que completam as tarefas, os consultores podem fechá-las directamente no Eclipse, que irá sincronizar com o Airgile (automaticamente), actualizando os indicadores e notificando o gestor de projecto.

Este é o workflow de gestão que usamos na Webfuel, ligando o Eclipse antigamente ao Trac e actualmente com o Airgile – que é mais rápido e confortável. É relativamente fácil configurar a ligação, estando as instruções disponíveis aqui.

No vídeo abaixo, a partir dos 5:45 é possível ver o conector em acção.

O Airgile sincroniza automaticamente as alterações às tarefas entre todos os elementos da equipa automaticamente, o que permite que as equipas trabalhem a todo o gás e que os gestores de projecto acompanhem as evoluções ao projecto em tempo real através de um dashboard intuitivo. Pesquisas e filtragens a milhares de tarefas demoram menos de meio segundo, tal como adicionar ou editar tarefas – através do Quick-Add e Quick-edit.

Feito a pensar em equipas espalhadas em redor do mundo, suporta multi-linguagem (por agora em Português e Inglês) e lida automaticamente com o fuso horário. Isto é,  uma tarefa introduzida a uma determinada hora em Portugal, aparece com a hora correcta para os elementos da equipa localizados no Brasil sem qualquer configuração necessária.

Além da informação detalhada que é possível colocar numa tarefa – como o tipo, estado, importância, data de início, fim, orçamento, entre outras -, é ainda possível anexar múltiplos ficheiros de uma só vez sem que tenha que esperar que o envio termine para continuar a trabalhar. Isto é, a aplicação não bloqueia em tarefas assíncronas, tudo com o objectivo de aumentar a produtividade! O sistema de preview inline permite visualizar imagens e ficheiros de texto dentro da aplicação, sem ter que os descarregar para o seu computador.

O sistema de comentários associado a cada tarefa reforça a comunicação entre os elementos da equipa – ou mesmo com o cliente -, incentivando a troca de ideias ou pedidos de esclarecimento.

O Airgile encarrega-se de enviar automaticamente emails a todos os utilizadores ligados a um projecto sempre que há alterações  (nova tarefa, tarefa editada, novo comentário, etc), podendo o gestor de conta activar a opção de subscrição por tarefa, permitindo que cada pessoa opte individualmente por receber mails só nas alterações das tarefas que escolher.

O sistema de permissões permite ligar utilizadores a projectos, sendo definido projecto a projecto se determinado utilizador pode somente consultar, inserir tarefas, e deixar comentários; se pode aceder às tarefas confidenciais; ou ainda se terá permissões de gestor de projectos que lhe permitem manipular todas as tarefas.

Como cada projecto e negócio é diferente, o Airgile permite-lhe configurar projecto a projecto os tipos, estados e níveis de importância das tarefas. Isto é, é fácil adaptar os projectos a áreas completamente distintas, como a consultoria em IT, ou a advocacia.

Os pormenores de usabilidade do Airgile são deliciosos, com vista não só a aumentar largamente a produtividade da equipa e assegurar o cumprimento de prazos, como também a permitir a utilização por diferentes pessoas com níveis de conhecimentos informáticos completamente díspares: a sua simplicidade tornam o Airgile na ferramenta de gestão de projectos ideal tanto para utilizadores experientes, como para utilizadores inexperientes.

Estando alojado numa Cloud, a plataforma está acessível a partir de qualquer computador em qualquer local do mundo com ligação à Internet, sendo compatível com todos os sistemas operativos e web-browsers usando o Flash Player 10.2. Não existem incompatibilidades entre web-browsers e sistemas operativos, sendo o desempenho e robustez da aplicação sempre ao mais alto nível.

O Airgile está disponível no modelo Software-as-a-service, isto é, mediante o pagamento de uma mensalidade muito baixa (a começar nos 6€/mês!), mas possui também uma conta gratuíta limitada a um projecto. Ao longo do tempo, o Airgile continuará a crescer com novas funcionalidades sempre com vista a aumentar a produtividade dos utilizadores.

O site do Airgile está disponível em http://airgile.com e possui não só vários vídeos de demonstração, como lhe permite testar uma conta de demonstração com dados fictícios antes de poder criar a sua conta.

A aplicação foi desenvolvida pela Webfuel, sendo completamente nacional. Assenta na Cloud, e corre em qualquer browser, tendo sido implementada em Flex usando o Adobe Flash Builder 4.5.  Planeamos lançar uma versão instalável com suporte a OCC (trabalhar offline) e uma versão para Android e iOS através de Air 2.6.

Experimentem o Airgile, forneçam-nos feedback usando o fórum e ajudem-nos a divulgar este produto de origem nacional!

Comecei recentemente a dar os primeiros passos na aprendizagem de Maven, e apesar de ainda ser um novato achei por bem partilhar as razões pelas quais esta tecnologia é tão interessante.

Apesar de utilizarmos Maven há já algum tempo nos nossos projectos na Webfuel e de conhecer os seus benefícios, nunca tinha investido tempo na sua aprendizagem visto que a configuração dos projectos com Maven estava a cargo de uma empresa nossa parceira (Web-Responsive). Sou, portanto, tenrinho no assunto, mas sinto-me compelido a partilhar as razões pelas quais vale a pena aprender Maven.

Este post não é um tutorial a explicar como se usa, mas sim uma descrição de alguns dos problemas (use cases) que o Maven resolve em projectos complexos. De notar ainda que o Maven não é específico ao desenvolvimento de RIAs, mas sim aplicável ao desenvolvimento em qualquer tecnologia que tenha um plugin para Maven. Para Flex existe o flex-mojos que cobre grande parte dos tópicos referidos neste post, mas não todos (ainda). Diria que no mundo J2EE, aí sim, o Maven se porta brilhantemente – por exemplo, na configuração de um JAVA + Spring + Hibernate + BlazeDS + Springflex + montes.de.outras.libs.

O que é o Maven?

O Maven é uma ferramenta poderosa para gestão de projectos, gestão de dependências, gestão de versões, automatização do processo de build (compilação, unit tests, reporting, etc), configuração de ambientes de desenvolvimento, entre outras. É uma ferramenta com cerca de 3 megas que se utiliza através da linha de comandos (ou através de alguns plugins para Eclipse, como o m2eclipse), para executar diversas tarefas sobre um (ou vários) projecto(s), regra geral associadas à sua compilação, mas sobretudo manutenção. Bem, o ideal é mesmo ver os exemplos mais abaixo…

(Mais prólogo) Esqueçamos o modelo de projectos gigantes…

É importante compreender que existe uma maneira “à-la-Maven” para a estruturação de um projecto. Um “projecto físico” deve ser separado em vários sub-projectos/componentes/bibliotecas (artefactos), com dependências entre eles. A noção de um projecto, com Maven, pode resultar em 10 ou mesmo 100 “projectos Eclipse”.  Por outras palavras, o projecto “my-huge-crm-application” quando criado “à-la-Maven” deve ser dividido em “my-crm-users”, “my-crm-reports”, “my-crm-costumers”, “my-crm-commons”, “my-crm-config”, “my-company-lib”, “my-3rdparty-lib”, etc – podendo-se atingir com facilidade 10 ou 20 projectos diferentes, com dependências uns dos outros (isto é, o my-crm-commons.jar é usado pelo my-crm-costumers, etc).

À primeira vista, pode parecer mais confuso, mas na realidade resulta numa maior simplicidade – graças à elegância do Maven, como veremos adiante.

O Maven lida com uma simplicidade extrema com as dependências entre projectos e com o processo de build – por exemplo, ao compilar um projecto que depende de outro, o Maven irá descarregar o outro projecto de um repositório onde possa estar instalado, ou se não o encontrar, mas tiver “acesso” ao código fonte, compilar o outro projecto -, e graças a esta arquitectura de gestão de dependências, torna-se relativamente fácil acoplar, desacoplar e substituir projectos/módulos/dependências num projecto.

(Ainda mais prólogo) Algumas notas prévias

Caso 1: Configurar um projecto do zero é demorado e aborrecido

O Maven resolve essa tarefa em dois segundos com um único comando, recorrendo a algo conhecido por “archetypes”. Como? Escrevendo:

mvn archetype:generate

O Maven irá fazer algumas perguntas (tipo de projecto, package, etc) e irá então criar uma estrutura de directorias base com alguns ficheiros necessários (ou dummy) tipicamente necessários nesse tipo de projectos, utilizando uma estrutura de pacotes pré-definida, e criará um ficheiro pom.xml de base. A estrutura de directorias usada pelo Maven obedece a uma *convenção*, normalmente muito bem definida, que torna permite que developers que estejam a analisar um projecto  pela primeira vez entendam rapidamente a sua estrutura, e onde encontrar todos os recursos. Além disso, a convenção usada pelo Maven reduz em *muito* a complexidade dos arquivos pom.xml do Maven (especialmente quando comparando ao Ant), pois não é necessário adicionar configurações extra ao pom.xml – O Maven irá “automaticamente” encontrar os recursos necessários nos locais correctos, se as convenções forem seguidas – mas, claro, os developers podem fazer override às convenções, embora não seja recomendável.

Outro dos desconfortos na criação de um projecto a partir do zero, é a configuração do projecto no Eclipse. Descarregar as dependências, adicioná-las à classpath no Eclipse, etc…, e depois fazer isto novamente em cada um dos postos de trabalho de uma equipa. Porém, graças ao maven-eclipse-plugin, basta um comando para gerar estas configurações. Fazendo:

maven eclipse:clean eclipse:eclipse

serão criados automaticamente os ficheiros de configuração do Eclipse (.project, e restantes), de acordo com as dependências e tipo de projecto definidos no pom.xml. A partir daí, basta que em cada posto de trabalho se faça um “Import Eclipse Project” no Eclipse, onde regra geral fica tudo maravilhosamente configurado. Graças ao pom.xml o Maven saberá o suficiente para criar correctamente os ficheiros de configuração do Eclipse. Claro que existem centenas de diferentes tipos de projectos no eclipse com configurações diferentes, e o maven-eclipse-plugin não conhece todas. Mas para JAVA, tem-se portado suficientemente bem para 90% dos meus casos. Os outros 10% são resolvidos facilmente adicionando algumas configurações adicionais no pom.xml.

Em resumo, a utilização de archetypes permite criar a estrutura e configuração de projectos a partir do zero, e o maven-eclipse-plugin permite criar e *actualizar* os ficheiros de configuração do Eclipse, sem ser necessário configurar projecto a projecto cada um dos projectos em cada um dos postos de trabalho à mão (isto, para JAVA, regra geral).

Caso 2: O meu projecto tem 20 dependências, e cada dependência também tem 10 outras dependências… Além de ser confuso, perco imenso tempo à procura das bibliotecas, a descarregá-las e configurá-las

Com o maven, é bastante simples. No pom.xml basta adicionar o seguinte XML para especificar que o projecto tem uma dependência do spring-flex, por exemplo:

         <dependency>
             <groupId> org.springframework.flex </groupId>
             <artifactId> spring-flex-core </artifactId>
             <version> 1.5.0.BUILD-SNAPSHOT </version>
         </dependency>

E aí basta correr:

mvn install

O Maven irá automaticamente encontrar a dependência (chamada de “artifact”) – pesquisando num conjunto de repositórios de dependências -, fazendo o download da mesma e “instalando-a” no seu repositório local. Irá fazer o mesmo para todas as dependências de cada dependência recursivamente, pelo que não temos que perder tempo com isso. E a partir daí, sempre que compilar com Maven, este irá adicionar cada uma das dependências ao classpath do compilador automaticamente.

A integração com o Eclipse também é incrível – ao executar:

mvn eclipse:clean eclipse:eclipse

o maven irá actualizar (na verdade, irá recriar) os ficheiros de configuração do Eclipse e adicionar as dependências correctamente ao classpath do projecto. Por outras palavras, algo que regra geral pode ser um autêntico pesadelo (definir as dezenas de dependências de um projecto, descarregá-las da internet, configurá-las, e por sua vez fazer o mesmo para as dependências de cada dependência…), é resolvido elegantemente em poucos segundos!

Esta simplicidade na gestão das dependências não só facilita a configuração das bibliotecas externas necessárias aos nossos projectos, como fomenta a separação dos nossos projectos em dezenas de módulos e bibliotecas, visto que com Maven se torna relativamente simples organizar todas as relações entre projectos.

Caso 3: Build através da linha de comandos

Com Maven, iremos utilizá-lo inevitavelmente para compilar.  A compilação é feita através de plagins, que invocam os compiladores com as directrizes de compilação apropriadas, de acordo com o pom.xml. Isto é, não definimos os argumentos dos compiladores; definimos sim a configuração do projecto, e o maven trata de definir os argumentos, regra geral automaticamente! Além da compilação, o Maven irá utilizar o resultado desta para executar tarefas adicionais, como a execução de unit-testing, geração de relatórios, envio de emails quando ocorrem erros de compilação, etc.

Algo extremamente elegante no Maven, é a forma como ele compila vários projectos em “simultâneo”, recursivamente de acordo com a ordem das dependências. Algo que iremos ver posteriormente

Caso 4: É difícil gerir diferentes versões dos meus projectos/bibliotecas e das suas dependências

Artefactos (módulos, bibliotecas, etc) possuem sempre um número de versão que lhes é inerente. Isto é, a biblioteca log4j poderá existir na versão 1.1, 1.2, etc. Isto significa que se o nosso projecto precisar do log4j 1.3, basta abrir o pom.xml, localizar a zona onde a dependência é definida (ver o caso 2), e mudar a versão para 1.3. O Maven irá descarregar automaticamente a versão 1.3 e actualizar as definições do projecto. Posteriormente, ao correr mvn eclipse:clean eclipse:eclipse, o Maven vai ainda reconfigurar o Eclipse com a nova versão da dependência. Agora imagine-se que por alguma razão é preciso voltar à versão 1.1 do log4j. Simples. Basta mudar no pom.xml a versão da dependência para 1.1, e o Maven trata do resto.

Mas o que acontece com suas próprias bibliotecas (aliás artefactos) – como são geridas as versões? Sempre que é executado o “mvn install”, o maven faz o build ao projecto, vai criar o package correspondente (i.e. Jar, War) e vai usar o número da versão definido no pom.xml para instalar o artefacto compilado no repositório local (ou online). Um repositório não é mais que um género de “base de dados” de bibliotecas gerida automaticamente pelo Maven.

Imagine-se que estamos a implementar o projecto A v1.0, que depende do projecto B v0.5. Temos ainda o projecto C v0.2 que também depende do Projecto B v0.5. Quando se faz o build install do projecto A v1.0, como este depende de B v0.5, o Maven vai primeiro fazer build, (package), e instalar o projecto B v0.5 e só depois o mesmo ao projecto A. Por sua vez, ao fazer build install ao projecto C v0.2, como o artefacto B v0.5 já existe e está instalado, o Maven não recompila o projecto B (excepto se houverem mudanças no código), usando a versão do projecto B v0.5 instalada no repositório.

Agora imaginemos que evoluimos o projecto B, actualizamos a versão para v0.6 no pom.xml. Estas alterações são necessárias ao projecto A, pelo que mudamos também o versão na dependência definida no pom.xml do projecto A. Porém, o projecto C ainda depende da versão v0.5 do projecto B, e não quer as novas alterações. O maven gere isto confortavelmente, pois irá simplesmente usar a versão do artefacto necessária, já previamente instalada no repositório.

Ou seja, elegantemente conseguimos ir evoluindo as versões das nossas bibliotecas “sem termos que nos preocupar” com quebrar a compatibilidade com projectos que dependem das mesmas, visto que o número de versão toma aqui um papel muito importante, facilmente gerido pelo Maven. Na realidade, é tão fácil, que quase nos esquecemos de porque é que era tão complicado lidar com diferentes versões das bibliotecas…!

Caso 5: O meu projecto consiste em 20 projectos de Eclipse, dependendo uns dos outros e é preciso compilá-los na ordem correcta para que tudo funcione

Esta é uma tarefa aborrecida no Eclipse, para a qual normalmente usamos o Ant. Mas que o Maven gere de uma forma muito simples, e confortável. Relembrando, cada projecto tem um ficheiro  pom.xml. Os projectos podem ser organizados em níveis. Por exemplo:

Cada um dos (artefactos) acima possui um pom.xml. Nos pom.xml “parent”, adiciona-se:

 <modules>
      <module>ProjectA-server</module>
      <module>ProjectA-flex-client</module>
  </modules>

Quando o maven é executado no projecto base, irá analisar a configuração dos módulos, e tentar executar primeiro o build em cada um dos módulos definidos, e por sua vez, em cada um dos sub-módulos, recursivamente na ordem correcta de dependência, “instalando-os” no repositório local. Mas claro, é sempre possível indicar ao Maven que queremos compilar só um projecto.

Caso 6: O projecto está a ser implementado numa equipa, mas é penoso configurar todos os projectos no Eclipse um a um em cada um dos postos de trabalho

Os ficheiros de projecto (.project) do Eclipse são específicos da máquina em que estão (i.e. um .project configurado no meu computador provavelmente não funcionará no computador do lado), e portanto não é boa prática colocá-los no SCM para partilhar com a equipa. Isto quer dizer que normalmente todos os elementos da equipa têm que criar à mão um novo projecto no Eclipse, configurar as dependências, definir a build path, etc, etc. Por vezes, estas configurações são até um pouco complicadas e demoradas, e algo corre mal, pelo que alguém tem que andar a saltar de estação em estação a ajudar a configurar o ambiente de desenvolvimento. E o pesadelo repete-se sempre que há uma alteração à configuração (novas dependências, novas versões, etc).

Com o Maven, como já foi referido anteriormente, queremos evitar de mexer com nas configurações de projecto do Eclipse. Por outras palavras, o Maven irá, regra geral, tratar desta tarefa automaticamente por nós. Quando escrevemos:

mvn eclipse:eclipse

O Maven irá ler o pom.xml, e usá-lo para criar os ficheiros de configuração do Eclipse para esse projecto, e para todos os sub-módulos desse projecto (ver Caso 5). Depois basta fazer um “Import > Eclipse project” no Eclipse, e já está, pronto a trabalhar. Naturalmente, já tinha referido isto no caso 1, mas voltei a repeti-lo aqui para reforçar o quão útil é este comportamento no desenvolvimento em equipa, especialmente na configuração inicial do ambiente de desenvolvimento de um novo projecto.

Mais possibilidades

Este post podia alongar-se em muitas mais páginas. Como ainda estou a estudar maven, este é o ponto a que já cheguei:

Mas ainda me falta:

Em resumo…

Resumindo, qualquer pessoa numa equipa pode executar um único comando que irá:

Interessa também realçar que os ficheiros pom.xml acabam por se tornar em manuais/guias valiosos para novos developers entenderem muito rapidamente a organização de um sistema complexo. Outro facto de realce, é que o plugin m2Eclipse possui um interface gráfico para editar e gerir os ficheiros pom.xml, simplificando em muito a vida na fase de configuração do projecto.

João Saleiro (Webfuel)

Marca desde já essa data na agenda e prepara-te para passar uma tarde bem disposta juntamente com pessoas que partilham contigo interesses e paixões pela Internet e não só!

Vamos ter speakers a abordar temas de elevado interesse da actualidade que te vão deixar com água na boca para aprender, explorar e procurar as inovações para o design e desenvolvimento das tuas aplicações!

O universo de desenvolvimento de aplicações web está em perfeita erupção! Não são só as tecnologias cliente, mas toda a “pilha” de desenvolvimento com as suas diversas tecnologias, linguagens e ferramentas está a ser posta em causa e cada um quer encontrar o seu nicho nesta realidade. Não perca esta oportunidade de ouvir alguns experts  portugueses na área do desenvolvimento de Rich Internet Applications.

Como se isto não fosse suficiente ainda vamos ter prémios para distribuir pelo pessoal que estiver a assistir que vão desde licenças de software a vouchers de cursos de formação e outros.

Não percam! Dia 6 de Março, no Edifício “Maus Hábitos”, às 14:00, e sim, no Porto!

Inscreve-te em: http://riapt.stagehq.com/events/182/booking/new

Agenda

Além dos patrocinadores, quero deixar também o meu agradecimento a todos os oradores, que se esmeraram na qualidade das apresentações, para aqueles que não estiveram presentes no evento deixo aqui as apresentações , excepto a do João Saleiro que já fez o favor de nos disponibilizar a sua.

Estamos também a contar ter esta semana os vídeos da apresentação assim que tiverem na nossa posse disponibilizaremos aqui no blog.

Apresentação do Luis Martins:

Apresentação Enrique Duvos:

Apresentação Nuno Godinho:

Apresentação Ricardo Castelhano e Ricardo Fiel:

Mais uma vez obrigado pela participação de todos, e quero desde já deixar aqui uma noticia em primeira mão, se gostaram deste evento preparem-se porque vêem ai novidades, como por exemplo a presença do Joshua Davis, num próximo evento nosso, além de muitas outras que estão na manga, acreditem este ano irá ser o ano da nossa RIAPT.

Queria dar os parabéns à organização (exemplares!!), aos patrocinadores e principalmente aos oradores que estiveram fantásticos, com apresentações de elevada qualidade.

Não se esqueçam de deixar o vosso comentário à apresentação, e se houverem questões, não tenham problemas em contactar-me. Espero que tenham gostado e que a apresentação vos tenha sido útil.

[Update] Duas pessoas pediram-me a versão digital do documento da Webfuel, mas como não fiquei com o contacto delas, aqui vai o link [/Update]

No próximo dia 25 de Junho, Quinta-feira, vai ocorrer no ISCTE das 14h30 às 19h30 o Portugal Flash Camp 2009. A agenda é a seguinte:

Andrew Shorten (Adobe Systems) – Flash Catalyst and Flash Builder 4
João Fernandes (Cofina SGPS) – Data Centric Development
João Saleiro (Webfuel) – Enterprise RIAs: This is how we do it
Paulo Moreira (Ayumikata) – Olha mãe, sem rato nem teclado
Rui Silva (Alert) – Testes Unitários em Flex
Rui Vieira(FullSix) – Get out There

A morada do ISCTE é:

Avenida das Forças Armadas
Lisboa, 1649-026
Portugal
(Google Maps link)

As inscrições são gratuítas e limitadas a 350 pessoas. O endereço para se inscrever é http://portugalflashcamp2009.eventbrite.com/.

Mais informações no site oficial do Adobe User Group: http://aug.riapt.org

Entre outras configurações, a mais importante é a estrutura de directorias, que em desenvolvimento é diferente da estrutura em produção.

Regra geral, quando se trata de uma aplicação com backend e um backoffice nós costumamos organizar o nosso ambiente de desenvolvimento desta forma:

\projectos\projecto

\projectos\projecto\backend (backend, por exemplo em php)
\projectos\projecto\mm (imagens, e outros recursos multimédia)

Quando corremos a aplicação localmente, sem os virtual hosts, vamos obter algo como http://localhost/projecto/bin-debug/index.swf .

Para que a aplicação possa comunicar com o backend, o path para o gateway será por exemplo algo como ../../backend/gateway.php .

Para que a aplicação possa aceder aos recursos multimédia (imagens, etc) o caminho será algo como ../../mm/imagem1.jpg .

Estes caminhos não batem certo com os caminhos na versão de produção:

www.projecto.pt (binários da aplicação)
www.projecto.pt/backoffice (binários do backoffice)
www.projecto.pt/backend (backend, por exemplo em php)
www.projecto.pt/mm (imagens e recursos multimédia)

Vemos que na versão de produção a aplicação para aceder ao backend vai fazer o caminho backend/gateway.php – enquanto que na versão de desenvolvimento, fazia o caminho ../../backend/gateway.php . O mesmo se aplica para as restantes directorias.

Há muita gente que trabalha com a estrutura de directorias e caminhos do ambiente de desenvolvimento, e quando chega a altura de alojar o projecto, mudam os caminhos no source code (ou num ficheiro de configuração) e recompilam – má prática.

Solução: criar um virtual host

O Apache permite que se associe um ambiente com configurações específicas a um determinado domínio. Ou seja, se o Apache receber um pedido de acesso ao dominio www.projecto.dev , e houver um virtual host para esse dominio, podemos configurá-lo para devolver a nossa própria estrutura de directorias (e não só).

O que gostariamos era de escrever no browser www.projecto.dev , e ser-nos exposto o nosso projecto com a estrutura de directorias igual à estrutura que vamos obter no servidor.

Vamos começar por configurar o apache editando o ficheiro httpd.conf na directoria conf do apache. No final do ficheiro, basta adicionar as seguintes linhas:

NameVirtualHost 127.0.0.1
Include conf/vhosts/*.conf

A primeira linha permite que o apache possa associar os nomes dos domínios pedidos aos virtual hosts que vamos configurar (mais info aqui).

A segunda linha indica ao Apache para carregar e executar todos os ficheiros de configuração com a extensão .conf na directoria vhosts. Isto fará com que criar um novo virtual host seja algo como criar um novo ficheiro .conf na directoria vhosts.

Vamos agora à directoria vhosts, e vamos criar um ficheiro chamado projecto.conf .

Nesse ficheiro, vamos colocar o seguinte:

<VirtualHost 127.0.0.1:80>
DocumentRoot "D:\OsMeusProjectos\projecto\frontend\bin-debug"
ServerName www.projecto.dev
<Directory "D:\OsMeusProjectos\projecto\frontend\bin-debug">
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>

Alias /backend "D:\OsMeusProjectos\projecto\backend"
Alias /backoffice "D:\OsMeusProjectos\projecto\backoffice\bin-debug"
Alias /mm "D:\OsMeusProjectos\projecto\mm"
</VirtualHost>

Isto vai indicar ao Apache que os pedidos recebidos na porta 80, máquina 127.0.0.1 relativos ao domínio www.projecto.dev irão ter a directoria bin-debug do frontend como a directoria de raíz do projecto. Os Aliases permitem que o Apache exponha o backend, backoffice e mm em directorias específicas, resultando assim num ambiente igual ao de produção.
Depois de feita a alteração acima, é preciso reiniciar o Apache.

Falta conseguirmos fazer com que pedidos para www.projecto.dev vão parar ao Apache. Para isso, vamos mexer no ficheiro "hosts" do Windows para forçarmos o redireccionamento de pedidos para www.projecto.dev para a nossa máquina local.
Basta para isso editar o ficheiro hosts (mais info no wikipedia), na directoria c:\windows\system32\drivers\etc . Recordo que no Windows Vista, será preciso abrir um editor de texto com permissões de administrador, e depois fazer o File > Open e procurar o ficheiro no disco – caso contrário não será possível editá-lo.

Neste ficheiro, bastará colocar o seguinte:

127.0.0.1 www.projecto.dev

A linha acima vai indicar o sistema operativo que todos os pedidos feitos para o domínio www.projecto.dev vão ser reencaminhados para 127.0.0.1 – a nossa máquina local. Como estamos a fazer os pedidos dentro de um web-browser, a porta por defeito será a 80. O resto é fácil de adivinhar: pedidos para a nossa máquina local na porta 80 vão ser entregues a quem? Ao nosso amigo Apache! Que ao receber um pedido destinado ao domínio www.projecto.dev, vai procurar o Virtual Host respectivo e expô-lo com a estrutura que definimos.

Obviamente, isto abre-nos as portas para fazer configurações mais radicais (i.e. configurar o Apache para que o Virtual Host seja igualzinho ao do servidor final).

O MVC é um padrão quer de desenho quer de arquitectura usando na construção de software. O uso deste padrão é muito vasto, e entende-se como o tratamento separado da lógica de programação e a interface grafica do proprio software que resulta numa enorme versatilidade da aplicação que torna muito mais facil modificar o aspecto visual da aplicação ou o código sem criar dependencias/afectação entre eles lidando facilmente com a comunicação entre utilizador, interface gráfica e o código da nossa aplicação.

Entendendo as siglas;

• Model – Representa a informação / dados da aplicação e as “regras/definições” para manipular / trabalhar com esses mesmos dados da aplicação. No flex, geralmente class pessoais ou classes de serviços para lidar com um backend.
• View – Representa os elementos gráficos da nossa aplicação, como inputText, datagrid, textArea, no flex engloba states, viewstacks, em resumo, todos os componentes gráficos.
• Controller – Representa o tipo de controlo/detalhes que envolvem a comunicação com o Model (Dados e definições) e o View (Interfaces gráficas) estes detalhes resultam da lógica de comunicação entre o Model e o View e normalmente representam também a interacção com o utilizador.

Este padrão MVC foi adaptado por centenas de frameworks, e o Flex não escapou à adaptação sendo que o principal objectivo de uso deste MVC no Flex é a simplicidade e re-utilização do código criando componentes bem definidos que permitem a obtenção de uma enorme versatilidade de todos os eles, bem como uma fácil cominicação entre os mesmo componentes, sem falar numa optimização do desempenho da nossa aplicação.

Ao criarmos um aplicação sem nos preocuparmos com este padrão teremos uma agradavel supresa no final de a termos terminado. O próprio Flex / Framework já está baseada nesta arquitectura e possui mesmo os seu proprio padrão MVC definido, como os componentes que definem a interface do utilizador, os modelos de apresentação de dados e os componentes responsaveis pelo controlo de dados como interacções com linguagens back-end.

Tentar entender este processo no ambito do flex pode ser muito complicado, mas vamos colocar um caso lógico que explica muitas das operações do flex:

Onde estruturamos devidamente os elementos e acções deste modelo:

Model:

• Usando action script, definindo como estrutura de class.
• Geralmente são usadas varias classes para simplificação de objectivos de cada uma que englobam:
• — Classes de dados nativas
• — Serviços de comunicação com back-end
• — No AIR, classes para lidar com chamadas como o SQLite

View :

• Todas as views são componentes gráficos do flex
• Tem como principal objectivo lidar com o layout da aplicação e disparar eventos para o controller
• Não acedem a dados directamente, apenas usam dados de eventos, dataProviders ou propriedades publicas / databinds
• São geralmente componentes escritos em MXML

Controller :

• Pode existir mais que um, embora apenas seja necessário em aplicações muito complexas.
• É usado como ponte entre o View e o Model visto que estes 2 não podem comunicar entre si directamente. Algumas propriedades / funções :
• — Definir dataproviders
• — Chamadas para o Model
• — Lidar com eventos do View
• — Alternar entre views
• Não são necessáriamente Action Script, no flex os arquivos MXML podem ser elementos “Controladores”

O Padrão MVC não se trata de um programa, formula ou função, trata-se sim de uma forma de organização de código permitindo esta “triologia” de funcionamento; criando uma class controlador que recebe/lida com dados de um conjunto de classes (model) e que faz a devida actualização da nossa interface grafica/componentes (view).

Claro que esta explicação pode ser mal entendida e perdoem-me os experts no padrão MVC, mas basicamente é isto que é feito claro que com alguns pontos e detalhes como vimos em cima.

Este tipo de implementações têm varias variantes, podendo nós, devidamente estruturado, criar um padrão MVC para estruturar a nossa aplicação, embora a Adobe disponibilize o Cairngorm que simplifica muito a aprendizagem pincipalmente com exemplos de muitos sites. A sua instalação é muito simples e o seu uso e aprendizagem também. Uma grande referencia em Cairngorm é o blog o David Tucker:

http://www.davidtucker.net/category/cairngorm/

Façam download dos videos e exemplos e facilmente verão do que falo.

Bem, na estrutura do exame Flex 3 este é um dos pontos: “List and describe de differences between model, view and controller in a Flex application”, que nos pede para explicar as diferenças apontadas em cima.

Bem, por agora é tudo… fiquem com alguns pontos de referencia do meu estudo sobre MVC.

http://cristobal.baray.com/indiana/projects/mvc.html (recomendo vivamente)

http://www.wonderhowto.com

http://livedocs.adobe.com/

http://www.iteratif.fr/blog/

Abraço e pelo menos espero ter esclarecido alguém, e já agora, alguém com uma opinião ??

Post originalmente colocado em: http://www.msdevstudio.com