ColdFusion 8 mais rápido com Java 5/1.5

Aparentemente a versão 6 do Java VM (a JVM configurada por padrão no CF8) apresenta problemas para carregar grandes quantidades de .class na memória. Um número grande de .class é típico de aplicações ColdFusion grandes ou em provedores de hospedagem, que armazenam muitos sites em ColdFusion. A sugestão é trocar a VM do CF8 para a 5/1.5 (não há diferença em termos de suporte à linguagem nem mudanças significativas em termos de estabilidade) até que a Sun resolva o problema.

[1] Java 6 and ColdFusion 8
[2] Huge Performance Gain in Moving ColdFusion 8 to Java 1.5

Dreamweaver lento com muitos CFINCLUDES

Dica boba, mas que demorei a descobrir. Se o Dreamweaver demora alguns segundos a mais do que o normal para abrir um .cfm que contenha muitos cfincludes (típico em aplicações fusebox 2), desabilite a opção “Show contents of included file” em “Server-side includes” da categoria “Invisible Elements” nas preferências do programa. A melhora na velocidade é perceptível.

Por que o ColdFusion não é gratuíto?

Aqui no Brasil/Portugal ninguém comentou sobre este post no blog CFInsider (blog de Jason Delmore, gerente para ColdFusion da Adobe). Até porque, sejamos francos, por mais que o autor diga o contrário, os argumentos que ele apresentou são válidos apenas na esfera do marketing. Tecnicamente, a lista de produtos que ele listou – que segungo ele, compõem o “ColdFusion como solução” e não como linguagem – pode ser contraposta de forma relativamente simples, utilizando alternativas abertas/gratuítas (que existem aos montes) para suplantá-las e substituí-las (aliás, a Adobe vêm fazendo exatamente isso ao adotar padrões abertos como o Yahoo! User Interface Library (YUI) e FCKEditor, só para ficar em alguns exemplos). Eu até já caí nessa conversa no passado. Defendia com unhas e dentes que o CF custava barato perto de outras soluções existentes (ASP por exemplo). Mas isso mudou, especialmente porque nos últimos anos temos visto surgir iniciativas excelentes e abertas na área de desenvolvimento web. Estas (não preciso citar exemplos) estão fazendo com que o CF não tenha um valor tão apelativo como tinha antes (lá pelos idos de 2002/2003, quando saiu a versão MX). È minha opinião, compre-a se quiser. Em suma: para mim a Adobe precisa parar com essa história de tentar convencer seus desenvolvedores de que o CF é uma solução barata pelo que oferece. Confesso, é um senhor pacote, mas acho que não justifica os preços e a modalidade de licenciamento atual. Se os argumentos da Adobe a favor do alto valor da licença do CF fossem coerentes, o que dizer então do Flex e as mudanças que a Adobe implementou em termos de licença neste produto? Vai entender…

Entretanto os comentários que se seguiram ao post valem a pena a leitura. Valem para saber o que pensa a comunidade internacional sobre essa história de o ColdFusion ser gratuíto, aberto, whatever.

Agora, não pense que eu sou a favor de uma versão livre e gratuíta do CF. Eu não sou, que fique bem claro. Eu prefiro o CF sob as asas da Adobe ou de alguma outra grande empresa (ok, menos a Microsoft), por enquanto. Explico: sim, sim… eu ia adorar o CF “na faixa”, mas como comentei na minha apresentação de abertura na última vinda do Forta, acho que estaríamos em maus lençóis se dependêssemos apenas da comunidade de usuários desta tecnologia.

Quem daqui se considera capaz de contribuir de forma efetiva (eu estou falando: codificar, botar a mão na massa e fazer a coisa acontecer) para modificar e incrementar um produto como o CF? Eu, por exemplo, não tenho, nem de longe, o conhecimento em desenvolvimento de software (seja colaborativo ou não), Java, J2EE, protocolos, etc, etc, para ousar abrir e alterar um fonte de um módulo qualquer (por exemplo, o que converte CFML em Java e depois para Java bytecode – ok, esse último fica à cargo do compilador) de um software como o ColdFusion. O que falar do tempo?? Falta conhecimento, falta experiência, falta tudo. São poucos os que seriam capazes de fazer isso com o CF. Inevitavelmente ficaríamos na dependência de engenheiros de software que ganham para isso: leia-se, dependeríamos da Adobe ou uma outra empresa. Temos um exemplo na nossa comunidade: o CFEclipse. É um puta produto, mas só existe por conta de apenas alguns gatos pingados (mais notadamente Mark Drew). E CFEclipse é um cisco em termos de software perto do ColdFusion. Não é a toa que a comunidade fica implorando para a Adobe assumir o produto e colocá-lo como “a” IDE para ColdFusion. Tornando-se aberto e gratuito o CF poderia estagnar e morrer. Por isso, na hora em que você for comprar uma licença de CF, lembre-se que software pago é isso aí mesmo: pagar por algo que você não é capaz de fazer igual ou não tem tempo para tal. Até rimou…

Agora… se a Adobe abrisse o CF e adotasse um outro modelo de negócios/lucro em cima do produto (eu ouvi Flex?…), a história poderia ser diferente… Poderia? Não sei… só sei que essa é uma longa discussão… 😉

Gambiarra: CFGRID + multiplos selects no formato html

(for english see here)

Uma das novidades do CF8 é o format HTML para a tag CFGRID. Assim como outros recursos de AJAX do CF8, o HTML CFGRID utiliza um framework “terceirizado” (por assim dizer) para montar estruturas bem interessantes. Mas como nem tudo são rosas, a implementação em CFML destes recursos é quase sempre muito básica, não permitindo muita customização nem a utilização de todos os recursos e características destes componentes/frameworks (no caso do CFGRID em html, o CF8 faz uso da poderosa biblioteca/framework Ext JS).

Eu precisava montar um CFGRID com paginação (o Ext JS é realmente fantástico), porém que permitisse a seleção de múltiplas linhas/records e enviar o valor da chave para uma página de ação qualquer. Nativamente isso não é possível com a tag CFGRID. Fuçando um pouco no código gerado (com o Firebug) pelo CF, e buscando paralelos na documentação da API do Ext JS eu consegui chegar a uma gambiarra que permite fazer exatamente o que estava precisando: montar um grid que permite selecionar múltiplas linhas e submeter os valores-chave para uma página de ação qualquer. A idéia é bastante simples: mostrar a listagem de dados dentro de um grid (que tem paginação elegante e rápida) e poder selecionar os valores para fazer qualquer coisa depois (update/delete/whatever).

Você pode ver a gambiarra aqui e baixar o fonte também (para rodar na sua máquina basta ter a datasource “cfdocexamples” instalada). Certamente há margem para melhorar (e muito) esta minha gambiarra, incluindo a saída totalmente “POG” de esperar os dados serem carregados no grid para habilitar a seleção múltipla (tentei fazer isso quando o CF invoca/cria o grid, mas não consegui/descobri como). Mas isso eu deixo para quem tiver saco (e conhecimento). Por enquanto estou satisfeito com o resultado. 😉

ColdFusion como plataforma de integração

Nota que saiu no InfoQ: ColdFusion as an Integration Platform. Obrigado ao Luiz (amigo de infância e de adolescência nerd) pela dica!

ColdFusion não é Java: excelente discussão

Alguns já sabem, mas eu pedi demissão e deixei o meu confortável cargo de Gerente de TI na Amigos da Terra. No meu novo trabalho (no momento prefiro não contar por questões pessoais) estou tendo que voltar a programar, a botar a mão na massa, espanar a poeira de programador (e eu nunca fui um programador bom). Além disso, estou tendo que reavaliar práticas de programação, assunto que naturalmente passa por frameworks e design patterns.

Hoje me deparei com uma excelente – e recente – discussão (na forma de dois posts) sobre a necessidade (ou não) de se usar frameworks avançados ou complexos para desenvolver uma aplicação web (inclusive as mais complexas e extensas) com o ColdFusion. Eu confesso que alguns padrões básicos de MVC, encapsulamento, etc devem ser usados em nome da facilidade de manutenção e compreensão da estrutura da aplicação. Entretanto, usar MVC, três camadas (dados, lógica – que engloba controle e modelo – e apresentação) – dê o nome que quiser, separe em quantas camadas quiser, não significa que você precisa usar CFCs, ou um framework modernoso como Mach-II, ModelGlue, etc. Dá para fazer – e bem feito – com os bons e velhos arquivos .cfm e cfinclude, tornando sua aplicação compatível, inclusive, com versões mais antigas do CF.

Muitos dizem por aí e eu concordo: a linguagem CFML é um “framework” por si só. Um framework para desenvolver aplicações web em cima de um servidor J2EE ou .NET (no caso do BlueDragon.NET). Por essa razão não se sinta compelido para usar um framework só porque os feras dizem que você deve usar.

Sobre esse assunto, vale MUITO a pena ler os seguintes posts (e comentários que se seguiram):

• ColdFusion Isn’t Dead, Its Never Lived; Dynamic Languages Reign Supreme 13/09/2007
• ColdFusion is not Java 14/09/2007

OBS: não se deixe levar pelo título dos posts. Ambos defendem a continuidade da simplicidade (e inerente beleza) da linguagem CFML e do ColdFusion em detrimento da fissura por “Javardarizar” excessivamente aplicações web.

CFDJ acabou

É, tudo mundo está comentando. A SYS-COM realmente não vai mais produzir o ColdFusion Developers Journal. É uma pena, mas quer saber? Não fará tanta diferença assim. Mais detalhes (incluindo links) aqui.

Em tempo: há três anos atrás um artigo meu era capa da edição de Setembro.

Novo hosting de CF no país

Os planos parecem ser bons: www.zsolutions.com.br.

ColdFusion 8: memorando interno

Vale a pena ler um memorando interno da Adobe sobre o lançamento do ColdFusion 8. Não é nada demais, mas serve para ver como o produto é encarado internamente, pelo menos nas aparências. Alguns pontos que eu anotei enquanto lia são:

– Aproximadamente 350.000 desenvolvedores no mundo;
– ColdFusion agora é parte da chamada Plataform Business Unit da Adobe, liderada por Kevin Lynch;
– Haverá uma campanha “agressiva” de marketing para o lançamento (cadê?);
– Anúncios de busca pagos (onde?);

Adobe ColdFusion 8: Lightning in a Bottle

Os comentários que se seguem são bons também.

ColdFusion 8 Final disponível

O escorpião saiu da toca! http://www.adobe.com/products/coldfusion/. Eu só fiquei chocado com a insensatez dos preços. Continuam os mesmos, apesar dos boatos de revisão. A versão Enterprise por exemplo continua custando 7.500 dolares. Ridículo!

E para saber como ficaram as versões (Standard e Enterprise), uma tabela comparativa pode ser vista aqui. Para não perder seu tempo: não houveram mudanças significativas. Alguns recursos exclusivos da versão Enterprise podem ser usados na Standard, porém com limitações (ex: apenas um thread/execução por vez). Sandbox Security continua sendo uma exclusividade da versão Enterprise.