Esta área apresenta alguns obstáculos, principalmente a nível dos algoritmos necessários para sincronizar as vistas, mas também a nível do UI pois as pessoas necessitam de habituar a informação visual adicional: múltiplos cursores, código a mudar simultâneamente e, quando editam a mesma linha, o código que estamos a editar a mover-se enquanto escrevemos (podem ver isso no screencast).

O melhor é mesmo ver os vídeos. O primeiro é um screencast a demonstrar o uso e consigo imaginar-me a fazer aquilo: ligar com o colega pelo skype para voz, convidar os intervenientes a partir do código no eclipse (utiliza um servidor de XMPP) e começar a editar. Aconselho a abrirem o video em HD no site e colocarem em fullscreen para verem bem o código.

O segundo é vídeo é uma Google Tech Talk apresentada pelo Mustafa Isik, criador do Cola, membro do ECF e ele próprio um googler.

O screencast:

A talk no Google:

No entanto, para o código javascript que nós próprios desenvolvemos ou que as frameworks que usamos usam ou geram raramente minimizamos os ficheiros javascript. Isto apenas seria feito para cenários de produção, mas rapidamente se tornaria demasiado trabalhoso.
Se queremos minimizar apenas para determinados cenários e de forma totalmente automática, tem lógica incluir este processo nos nossos processos de build.

E é aqui que entra o plugin do YUICompressor para o Maven.
Este plugin permite processar os ficheiros javascript, minimizando-os. Também corre o JSLint, para verificar a correcção do código. Este último é uma forma de análise estática de código que ajudo muito a reduzir a probabilidade de erros não detectados.

Falo do YUICompressor como podia falar de outras ferramentas de compressão e obfuscação de javascript, como seja o JSMin, ShrinkSafe, Packer ou outro. Não sei é sobre a existência de plugins para todos, embora não deve ser muito complexo de os desenvolver.

Desta forma conseguimos comprimir o nosso código para melhorar a performance e verificar estaticamente por erros no javascript (um erro javascript pode quebrar o build: bom!). Podemos ainda usar o plugin para gerar documentação javascript (JsTools) ou mesmo para efectuar testes unitários em javascript (JsUnit).

Poderíamos ainda melhor mais a performance, gzipando os nossos ficheiros a nível do servidor. Para esta e outras optimizações, é muito útil o YSlow, também da Yahoo que é um plugin para o Firebug que verifica determinados parâmetros de performance na página.

Meta-"Qualquer coisa" é ("Qualquer coisa")2

Ou seja,

Meta-"Qualquer coisa" é "Qualquer coisa sobre "Qualquer coisa""

Assim, podemos ter coisas como Meta-dados (Dados sobre dados), Meta-Teoremas, Meta-Matemática e Meta-Frameworks.

Temos, portanto, uma Framework sobre Framework(s). Mais precisamente, o sentido dado é de uma framework agregadora de outras frameworks, ao invés de um framework que descreve outras frameworks, algo que o prefixo meta poderia sugerir.

Epistemologia à parte, de que raio é que estou aqui a falar?

Estou a falar de agregadores de frameworks, neste caso em java, que conjugam um conjunto de frameworks base, ligando as diversas peças, e facilitando o uso por parte do utilizador. Desta forma os diversos componentes estão agregados de uma forma minimamente provada ou testada e o tempo de configuração do projecto é incrivelmente reduzido. Podem inclusivé servir como objecto de estudo para observar boas práticas.
Embora seja contra tudo o que seja ideia de criar frameworks base internas a empresas e usar sempre produtos open-source, meta-frameworks são uteis e não são mais que uma definição formal da pilha tecnológica do projecto ou, se a empresa trabalhar dessa forma, da pilha tecnológica da empresa.

Arrancar com um projecto deverá ser tão simples como gerar uma estrutura base do projecto, já com todos os componentes wired up e pronta a compilar. Também deve ser possível importar o projecto do IDE de eleição da pessoa. Repito, da pessoa. Ao contrário do que acontece em muitas empresas, na minha opinião o IDE deve ser uma , sendo que a maioria das frameworks disponibilizam pelo menos para Eclipse e Netbeans.

No paradigma web, poderiamos pois ter uma framework que junta uma tecnologia de mapeamento OR, uma de caching, uma de Dependency Injection/Inversion of Control, uma de apresentação, uma de templating e mais quantas sejam necessárias; mas podemos aplicar isto a qualquer paradigma que queiramos.

Destaco as seguintes frameworks (que são as que conheço):

• Keel

O projecto Keel está morto (não há actividade aparente desde 2004). Apenas é interessante por ter sido a primeira framework deste género com que tive contacto.

• Appfuse

O Appfuse é provavelmente o projecto deste género com maior sucesso e maior disseminação. Liderado pelo Matt Raible, reconhecido especialista em tecnologias web, o Appfuse é na realidade uma colectânea de meta-frameworks.
Basea-se no Maven, usando archetypes, para rapidamente criar esqueletos de projectos. Depois é possível gerar o projecto para o IntelliJ IDEA, Eclipse ou Netbeans e usar qualquer uma das bibliotecas disponíveis no Reference Guide – é possível rapidamente montar um sistema com muito pouco trabalho.
O Appfuse, como usa POJOs e Spring, possibilita criar CRUDs rapidamente com uma simples acção Maven.

• IWebMvc

O IWebMvc é a mais recente meta-framework de que tomei conhecimento. É criada por um senhor chamado Jose Noheda, que é o responsável pela integração com Spring no projecto DWR. É com naturalidade então que ele criou uma meta-framework que agrega DWR + Dojo + Spring + Hibernate/JPA.
Ainda está na sua primeira versão, mas dada a qualidade do DWR isto promete. Certamente uma meta-framework a analisar.

• Parancoe

Parancoe é uma meta-framework criada pelo Lucio Benfante, líder do JUG Padova.
A pilha tecnológica de Parancoe é DWR + Spring MVC + Spring + Hibernate/JPA que é uma solução que considero ser muito prática e uma excelente conjugação de tecnologias.
A característica técnica mais destacada são os DAOs genéricos que não requerem implementação. Para quem gosta de DAOs, pode ser bastante útil.
Para verem um site feito em Parancoe, podem consultar o JUGEvents que usámos para os registos no PTJUG.

Penso que qualquer uma destas últimas vale a pena uma voltinha

Developers Java: O que as empresas dizem que precisam mesmo mesmo

Por Fernando Fernandez

| View

Lightweight Grids with Terracotta

Por Cesario Ramos

| View

Web 2.0 em Java com Google Web Toolkit

Por Hugo Pinto

| View

Enjoy!

Esta conversa já me surgiu em diversas ocasiões e voltou a despontar numa thread na mailing list do PTJUG, e confesso que tenho alguma dificuldade em compreender a enorme resistência que imensos programadores apresentam em aprender e utilizar javascript. Isto é, baterem código mesmo em javascript sem usar frameworks que gerem o código todo – e.g. GWT, ou helpers de php, ruby, etc. -, mas usando obviamente bibliotecas como o prototype, jquery, etc.

Javascript é uma linguagem dinâmica, weakly typed e prototipada. Logo aqui, há diferenças para as linguagens que a maioria usa: C#, Java (statically e strongly typed) e python (dynamically mas strongly typed). O modelo de prototipagem é um pouco diferente do modelo de classes para definição de objectos, por isso percebo que possa introduzir confusão ou pelo menos dar origem a um novo processo de aprendizagem.

Mas não é assim tão complicado como isso…

Razões para usar javascript directamente, não ter medo e assumi-lo com orgulho

1. Desenvolvimento web = (X)HTML + CSS + Javascript + linguagem_server_side

Quer sejamos programadores java ou de uma outra tecnologia web, a probabilidade de termos de usar ou gerar html, css e javascript é muito elevada. Podemos inclusivamente usar geradores mas como facilitadores e não por sermos incapazes de produzir código de qualidade numa linguagem dinâmica ou, pelo menos, compreender o código que estamos a gerar. Devemos poder mudar de linguagem e continuar a dominar a parte de interface web, apenas tendo de aprender conceitos da outra linguagem/plataforma.

2. jsFUD

Durante muito tempo, javascript foi muito pouco estudado e visto como uma linguagem de scripting básica que permitia escrever umas linhas de código. Não havia propriamente estruturação de código e muita gente entende que programar javascript é isso. É um pouco como aquelas aplicações java de alunos de primeiro ano que metem 2000 linhas de código num só ficheiro ao monte.
Hoje em dia javascript não é isso, é uma linguagem madura, os problemas de interoperabilidade entre browsers são mitigados com as novas bibliotecas, estão a ser preparadas virtual machines (compilação JIT incluída) que melhorarão imenso a performance de código no browser, há uma proposta de uma nova versão da linguagem (resumo da nova especificação) com possibilidades de verificação de tipos estática e outras features que fazem dela uma linguagem muito mais parecida com algo tipo java (ActionScript é a coisa mais parecida actualmente).

3. Javascript não é só web

Nos últimos meses tenho desenvolvido aplicações com a suite de BPM Teamworks da Lombardi que utiliza javascript como linguagem de programação para as actividades dos BPMs. A utilização de javascript nestes moldes ou, melhor ainda, como linguagem para desenvolver plugins ou algo semelhante para aplicações, tirando partido das suas propriedades dinâmicas é altamente refrescante. Basta usar os jars que a Mozilla fornece com a implementação do projecto Rhino.

4. JSON

Poder estar a programar e definir as minhas estruturas de dados em formato JSON é magnífico. É menos verboso, simples e escrevo muito menos new’s.

5. Abrir horizontes

Last but not least, não devemos ter receio de linguagens dinâmicas. Um programador java tem um trabalho confortável e laborioso: estamos protegidos com verificações estáticas em tempo de compilação, checked exceptions e outras demais coisas o que nos dá segurança e permite apanhar erros cedo; por outro lado, tudo isto nos dá mais trabalho sem muitas vezes nos garantir qualidade do software (para isso preferiria ter contratos estritos definidos entre os componentes com verificações em tempo de compilação e runtime, o que seria demais para a maioria nos sistemas).
Trata-se pois, de uma questão de encontrar a chave de fendas que funcione melhor com o parafuso. Sejam linguagens dinâmicas ou não, o que interessa é a que produza melhor resultado final e isso pode nem sequer depender da linguagem mas de outros factores externos como a equipa, o tipo de requisitos, etc.

Em termos de resumo, coisas como o GWT são excelentes paradigmas mas não se deve perder de vista o que se passa debaixo do capô. Experimentem desenvolver uma aplicação em javascript para testar o poder da linguagem. Repito, uma aplicação, não um bloco de script.

Não tendo testado nada disto, continuo a achar uma parvoíce tudo isto, senão vejamos. Nenhuma destas tecnologias de interfaces ricas é acessível, tal como aplicações Ajax também não o são (screenreaders têm dificuldades em detectar alteração de valores e partes de páginas). Ajax ficou na moda porque o caminho é que todos queremos ter interfaces mais usáveis, que possam ter múltiplas acções assíncronas, no fundo, que dêem um feeling mais desktop. No entanto, os únicos standards que temos na web para poder fazer algo assim, são xhtml, css e javascript (e mesmo assim, implicam muito trabalho porque as especificações não são implementadas da mesma forma em todos os browsers). Embora flash e o jre tenham uma taxa de penetração muito elevada, são tecnologias proprietárias, daí ser difícil um screenreader ler uma aplicação em flash, por exemplo.
Na minha opinião, o caminho das RIAs devia ser o de utilizar ou criar um standard não proprietário como o flash/javafx/silverlight, tal como foi tentado com os XForms e que parece ter morrido. Este standard permitiria que browsers o implementassem, screenreaders o lessem, etc.
Para um browser ser compatível, teria de passar um conjunto de testes de aceitação que seriam efectuados por uma aplicação da W3C, e só se passassem poderiam dizer serem compatíveis. Ajudaria se a nível da união europeia, se definisse uma meta para a implementação dessa tecnologia.
Sinceramente, XForms seria mesmo um óptimo candidato para isto. É já um standard W3C, permita implementar dinamismo destas outras tecnologias e não é vendor specific.

Resumidamente, o DWR permite, de uma maneira muito simples, usar Javascript no cliente para interagir directamente com os objectos Java no servidor e tem vindo a tornar-se  um standard neste tipo de tecnologia.

Para aqueles que usam o Netbeans como IDE, a vida fica agora (ainda) mais facilitada com o lançamento (não oficial) da primeira release de um plugin para DWR, disponível aqui.

Esta primeira release permite já editar visualmente o ficheiro de configuração do DWR  (embora só para operações de create e new) e o drag & drop dos objectos exportados directamente para as JSPs!

Estão previstas para as próximas releases funcionalidades como a exposição de form beans de Struts e managed beans de JSF e de um editor para Signatures.

promete!