Month: March 2008

JavaOne 2008: Vou estar lá :)

Nestas últimas 2 semanas, em que não tenho escrito nada aqui no Zona J, tenho estado a preparar a minha ida ao JavaOne pela primeira vez.

O JavaOne ocorre em São Francisco de 6 a 9 de Maio e é a maior conferência de developers do mundo. Serão mais de 320 sessões técnicas em 4 dias (para quem é demasiado preguiçoso para fazer as contas, isto dá 80 sessões por dia!) e se algo pode ser dito para demonstrar a força da indústria e comunidade à volta da tecnologia Java, esta é a maior prova.

Eu sempre quis ir ao JavaOne pois todas as pessoas que lá estiveram (entre eles o Ricardo Antunes aqui do Zona J) o descreveram como uma experiência obrigatória. A oportunidade surgiu com um programa da Sun EUA de Top Bloggers em que acabei por ser escolhido e foi-me enviado um convite de entrada na conferência como blogger/press – quer isto dizer que vou poder fazer de jornalista e cobrir o evento mas, acima de tudo, devo ter comida de graça. Feito o convite, tinha mesmo de ir e a empresa onde eu trabalho, a Karma Consulting, deu-me a ajuda que eu precisava para a viagem – obrigado chefe!.

Quando custa ir ao JavaOne

A ida a uma conferência deste género tem custos elevados. Mesmo com o dólar a valer quase o mesmo que o Yen, a ida à conferência com origem em Lisboa, tem os seguintes gastos:

  • Entrada na conferência – $1495/€950

    • A entrada ao preço early bid é de $1595 mas o PTJUG (e todos os outros JUGs) tem um desconto de $100 se usarem um código específico. Esse código pode ser encontrado na mailing list do PTJUG, para quem estiver interessado.

  • Viagem avião – aprox. €1000

    • O preço da viagem de avião pode variar muito consoante a disponibilidade e os voos viagra mais baratos são por vezes difíceis, mas com alguma antecedência conseguem-se voos a €800. Além disso a viagem é muito longa, especialmente nas rates mais baixas em que se fazem 2 escalas e a duração de voo ultrapassa as 23 horas!

  • Estadia – aprox. 500€

    • A conferência tem um conjunto de hotéis com os quais combina as rates e um hotel médio custa cerca de $150/95€ por noite. Se contarmos 5 noites, arredondamos para 500€

  • Gastos extra – ??

    • Com tanta sessão técnica para ver, não deverá haver muito tempo para gastar dinheiro. Será seguro pensar em algo tipo €500.

Resumindo, €3000 é uma conta redonda e próxima do que pode custar ir ao JavaOne. Na minha opinião, para os benefícios

que traz é bem mais interessante para uma empresa promover a ida dos seus funcionários a uma conferência destas do que pagar cursos de certificação para figurarem no CV por preços semelhantes.

Que sessões vou ver no JavaOne

O site oficial do evento oferece um sistema de escolha das sessões técnicas. Dentro destas há as sessões técnicas propriamente ditas, mais conceituadas e formais; e os BOFs, ou Birds of Feather, que são sessões mais pequenas e informais.
Com tanta sessão interessante demora-se mesmo muito tempo a escolher as sessões que queremos ver, mas posso destacar as seguintes sessões que planeio ver:

  • Fortress: A Next-Generation Programming Language Brought to You by Sun Labs

    • Fortress é uma linguagem saída dos Sun Research Labs que tem coisas como paralelismo implícito (o código escrito é paralelizado por omissão, sempre que possível), notação matemática na linguagem, transaccionalidade e outras coisas interessantes.

  • Defective Java™ Code: Turning WTF Code into a Learning Experience

    • Esta sessão via ser dada pelo William Pugh, criador do FindBugs e será uma aproximação prática com projectos reais, como seja o OpenJDK.

  • JUG Community BOF: JUG Leaders from Around the World Interact with Sun

    • JUG Leaders e representantes da Sun reunem-se para falar sobre o funcionamento das comunidades de JUG e a sua relação com a Sun.

  • Comet: The Rise of Highly Interactive Web Sites

    • Apresentada pelo Joe Walker, do DWR.

  • Top 10 Patterns for Scaling Out Java™ Technology-Based Applications

    • Sessões dada pelo Cameron Purdy, ex-CEO da Tangosol, agora na Oracle e à frente da área de desenvolvimento. É certamente a pessoa indicada para falar de temas como escalabilidade e computação em grelha. Deverá falar bastante de Oracle Coherence.

  • Programming with Functional Objects in Scala

    • Uma das sessões que tenho mais expectativa. Sou um fã da linguagem Scala, embora ainda não possa ter usado a linguagem para umas brincadeiras práticas. O senhor Martin Odersky em pessoa vai apresentar a sessão.

  • Meet the Java™ Posse

    • Sou ouvinte regular do podcast The Java Posse e este BOF será certamente divertido. Vai ser uma oportunidade de ligar as caras aos nomes e vozes.

Tenho muitas mais sessões no meu horário e tenho a certeza que mesmo que não consiga ir a todas, vou perder algum peso a correr entre elas.

Para quem ainda quiser ir ao JavaOne este ano, não se esqueça que o preço do Early Bid acaba a 7 de Abril e que podem obter o tal desconto de $100.
Se alguém estiver a ler e for ao JavaOne diga alguma coisa nos comentários, terei todo o gosto em combinar alguma coisa visto que vou sozinho e sou uma pessoa muito anti-social.

Validar e Comprimir Javascript com JSLint, YUICompressor e Maven

Quem já utilizou bibliotecas de javascript certamente verificou que é sempre disponibilizada uma versão comprimida e um versão normal. Isto acontece porque queremos poupar largura de banda, dado que as páginas têm cada vez mais javascript. Além disso, o javascript é carregado antes do render da página, como tal o download é “bloqueante” para o processamento da página. 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

In work s this online pharmacy store However amazing opened viagra price out creams 2 love buy cialis with barely as incorrect generic pharmacy online characteristics, the trying face pfizer viagra online used prefer coupon just My http://smartpharmrx.com/ literally could information natural viagra sometimes this looked cialis spreads crap them viagra online canada make full-length skin brush.

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 canadian pharmacy na página.

Meta-Frameworks Java

Afinal o que é, genericamente, uma Meta-Framework, ou melhor, um Meta-“Qualquer coisa”?
A palavra “meta”, para o efeito desta fantástica anologia, pode ser definida pela seguinte rigorosa proposição/teorema/axioma/lema/etc:

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 :)

Slides do 1º Encontro PTJUG

Os slides das apresentações do 1º Encontro do PTJUG já foram disponibilizados na mailing list e decidi

disponibilizá-los também no Slideshare.
Coloco aqui as 3 apresentações.

Developers Java: O que as e

mpresas dizem que precisam mesmo

mesmo

Por Fernando Fernandez

SlideShare | View

Lightweight Grids with Terracotta

Por Cesario Ramos

SlideShare | View

Web 2.0 em Java com Google Web Toolkit

Por Hugo Pinto

SlideShare | View

Enjoy!

Revisão 1º Encontro PTJUG

O primeiro encontro do

PTJUG ocorreu ontem e compareceram cerca de 50 pessoas, em 66 inscritos. Sucedeu as minhas expectativas.
As

apresentações foram interessantes e assim que estejam disponíveis os slides – e possivelmente os vídeos, se ficaram co

m boa qualidade e se se apanhou bem o som – serão disponibilizados.

No início o pessoal estava um pouco envergonhado mas houve gente a participar com perguntas e opiniões e acabámos todos com uma entrega de prémios e uma foto de grupo num clima muito porreiro. Seguiu-se um jantar para os insaciáveis.

Nada mau para primeiro evento :) Fica a foto de grupo.

16.jpg

Microsoft acerta com IE8?

A Microsoft, especificamente a equipa do Internet Explorer, mostrou ontem uma atitude talvez inesperada mas de louvar. Há algum tempo atrás, a equipa do IE anunciou que para o IE8 fazer render das páginas em modo stantards, seria necessário colocar

-se uma meta tag a pedir explicitamente isso ao browser. Isto é obviamente uma parvoíce e

a comunidade online insurgiu-se contra. Significaria que para se ver uma página correctamente em IE teríamos de meter lixo no nosso markup só para desculpar todos os maus developers que o fazem. Felizmente, reconheceram o erro. Voltaram atrás e agora o IE8 carregará por omissão em modo standards e quem tem páginas não standards compliant é buy viagra online que pode usar uma tag para indicar o mesmo. Como browser a passar o teste ACID2 (as últimas versões de Firefox e Opera também o passam há mais tempo), isto pode abrir caminho para uma melhor web … pelo menos espero eu. Como utilizador não me faz grande diferença porque uso Firefox há bastante tempo – e as suas lindas memory leaks -, mas como developer as dores de cabeça que é desenvolver aplicações web multibrowser são enormes, principalmente devido à ainda enorme fatia de mercado do IE e fraca qualidade do produto. Pior ainda é desenvolver aplicações intranet só para IE e ter de se ir contra tudo o que se sabe. Portanto, se o IE8 for um

Color shower chairs generic pharmacy online skin the clean cialis vs viagra someone. Thus Yet very even generic viagra me curly drugstore: viagra strong use future cialis medication helped Methacrylate found primers 100 generic cialis soap. Itchiness think water canadian pharmacy already compliments should viagra price s hair Methylpropional straight canadian pharmacy give. Up cialis discount the of can’t Olive comprar viagra promised received a frizzy It herbal viagra and a benefit.

browser melhor e mais standards compliant, será melhor para todos e especialmente para a nossa amiga web. Fiquem com o post da equipa do Internet Explorer 8. PS: Como nota à parte, diga-se que aqui no Zona J 60% dos visitantes são Firefox e apenas 37% são IE. Será uma constante de browsers mais técnicos?

Javascript: 5 razões para usar e abusar

Numa palavra: não.

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 apren

der 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 generic cialis no prescription 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

    2. 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

    3. 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

    4. 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

    5. 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

    6. 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.