Resolvi falar sobre CoffeeScript porque algumas pessoas com poder de influência em diversas comunidades estão evangelizando essa aberração.

História

Vou começar pelo começo, aproximadamente entre os anos de 99 e 2009 a comunidade Javascript passou se degladiando sobre o futuro da linguagem, uma parte defendia algo próximo ao ActionScript [exemplo fácil só para um termo de comparação], com classes e outras características que não existem na linguagem que é prototype-based. Venceu a turma conservadora, que defendia js se manter como estava.

Para terem uma idéia da confusão, hoje existe a especificação ECMA 262 versão 3 e versão 5, justamente porque a 4 ficou no meio dessa briga e nunca chegou a existir.

Desculpas

De 2006 pra cá algumas linguagens antigas como ruby e python influenciaram todas as comunidades de desenvolvedores com argumentos – dos quais concordo em parte – como expressividade, facilidade na leitura por humanos com menos ruído sintático em vez de apenas performance ou outra característica técnica que poderia muito bem ser trabalhada em um nível inferior (Como por exemplo, para cada linha que voce evita de escrever em Python, existem centenas em C que fazem o trabalho).

Primeiro argumento do uso de Coffeescript é justamente sobre ruído sintático do Javascript, mas inventaram uma SINTAXE NOVA que não é igual a Ruby e nem Python, mas há métodos e características de ambas para justificar seu uso. Ora bolas, porque não terem implementado um subset direto do Ruby?

Incluíram o Pattern Klass como funcionalidade dessa linguagem sendo que Frameworks antigos como Prototype já implementavam isso.

Em Javascript você consegue Closure, Currying e outras construções funcionais porque function é um cidadão de primeira classe na linguagem, consegue ter Mixin até mais fácil do que em Ruby porque além de dinâmico é de tipos fracos.

A justificativa de se usar Coffeescript por causa de sintaxe é a mesma de muitos que usam Groovy porque a “curva” de Java seria menor. Falácia grave. O problema de um desenvolvedor não aprender uma sintaxe porque é assim ou assado já demonstra em muito que ele não quer aprender as características da linguagem e vai continuar “programando em Java” usando Groovy.

Isso é muito comum, já passei por muito programador PHP programando em Ruby como PHP ou programador Java programando em javascript como Java.

Alguns entusiastas de Ruby defendem o uso porque lembraria a sintaxe que se sentem familiar e por ironia citam List Comprehensions, funcionalidade que existe no Python e não no Ruby. Como voce contorna isso no Ruby? Vamos parar com a covardia e sair da zona de conforto?

Problemas

Eu tenho um problema com linguagens intermediárias com Enhanced, mas vá lá, podemos viver com isso.

javascript tem muitos problemas, mas não é apenas sintaxe, precisamos normalizar todas as versões e especificações e atacar as fraquezas conhecidas, não sair criando pseudo-linguagem.

List Comprehensions que já citamos, tem na versão 1.7 que o SpiderMonkey implementa (usado pelo Firefox) , mas o V8 (usado no Chrome, Safari e no node.js) não implementa, Rhino implementa e assim vai, uma confusão só. Os navegadores basicamente implementam a versão 1.5 que é equivalente a ECMA 262 – versão 3 que chamamos de ES3 (ECMA Standard 3), o V8 implementa a ES5 e mantém compatibilidade com 1.5. SpiderMonkey implementa a 1.5, mas não tem compatibilidade entre ES5 e 1.5, se quiser usar funcionalidades definidas na ES5 tem que usar versão 1.8. Confuso? É assim mesmo.

Se Javascript não se encaixa no seu projeto, não a use, é porque não serve mesmo, agora tentar mudar as características (como assincronismo, só para aproveitar o momento e bater em ferramentas como Step) para se encaixar é querer usar a furadeira para pregar um prego.

Se você é obrigado, já que não existe outra alternativa na camada de apresentação em Webapps (RIP ActionScript ), use os frameworks modernos que já implementam o Crossbrowser aceitável (nunca vai ser decente) e se beneficiam de sua idiossincrasia. Coffeescript só está em evidência por causa do node.js, já que há várias bibliotecas e até Frameworks implementados com isso, se a discussão aqui for navegador, nem invente.

Eu por exemplo sinto mais falta de incluírem o “method_missing” na especificação do que interpolação de strings.

Ainda pra completar há uma rivalidade entre os defensores de Frameworks como entre o jQuery e Mootools que não sei de onde surgiu, mas nós humanos somos assim mesmo, brigamos por religião e por Framework.

Javascript é de tipos fracos, dinâmicos, sem classes, orientada a protótipos e assíncrono… aprenda a linguagem. Já basta de uma linguagem a mais para cada chilique de desenvolvedor por causa de um “{” ou “;”. Como alguém, que não lembro quem foi, escreveu no twitter dias desses: “Antigamente todo mundo queria seu próprio Framework, hoje todo mundo quer sua própria linguagem”.

Aproveite e vá me assistir no QCONSP 2011 que vou demonstrar algumas coisas bacanas de se fazer com Javascript e como a sintaxe não atrapalha

Post indexador sobre o que escrevi sobre OO em Javascript nesse blog apenas para guardar como referência rápida de consulta, estou revisando todos os posts para verificar o que falta escrever.

Name Binding

Herança no javascript

Overloading e overriding no Javascript

Como prometido ontem, estou doando o curso de javascript para o projeto JavaCE Social, o curso foi formatado para 4 horas, bem focado. O conteúdo para o curso é a seguinte:

1. Javascript: Orientação a Objetos
   • Orientação a objetos Prototyped-Based, objeto literal e JSON
   • Estratégias de construção de objetos (Factory, Constructor, Prototype e escopos de visibilidade)
2. Javascript: Funcional
   • Closure e Currying
   • Array Comprehensions

O curso de Javascript completo é cerca de 16h no mínimo, mas dá para demonstrar bastante coisa em 4h. Esse curso serve principalmente para compreender bem como funciona um framework client-side como o Jquery, principalmente se precisar criar ou modificar plugins. Se der tempo pretendo ainda fazer algumas demonstrações de estratégias de otimizações, técnicas de ajax, entre outras coisas.

Vamos usar o firebug para praticar, não dá tempo de instalar e configurar um Rhino ou Node, então fica para os próximos algo mais avançado.

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

(…)”A dúvida era essa: Linguagens dinâmicas dão maiores possibilidades de inclusão de erro no código com isso aumentando de forma significativa a refatoração.”(…)

Em conversa com um excelente desenvolvedor aqui no Ceará, Delberto Muniz, ele escreveu a seguinte resposta:

Estava relendo um livro sobre os primórdios da programação e houve um debate semelhante: Os programadores Assembly achavam que programar em Fortan dava maiores possibilidades de erros porquê o programador não tinha total controle sobre o código gerado.

Dez anos depois o pessoal do Fortran falou mal do Algol porquê Algol abstraía demais e o programador não tinha total controle sobre a linguagem.

Aí veio o pessoal do C/C++ dizendo que Java abstraía demais, deixando margens a bugs serem introduzidos nos programas pelo compilador e/ou pela vm ou porquê simplesmente ele não estava alocando/desalocando memória manualmente.

Só mudaram as linguagens – o debate é sempre o mesmo: Se eu aumentar a abstração, meus programadores vão fazer besteira?

Se você está com essa dúvida, sinto muito: Você está nivelando por baixo e/ou não conhece seus desenvolvedores.

Ontem começou o Maré de Agilidade com o curso RR11 de Ruby on Rails da Caelum com o Fábio Kung, que não precisa de apresentações [se você não sabe quem é Fábio Kung então mude de profissão].

Como o Kung está indo integrar o time da Locaweb, [apesar de continuar como instrutor na Caelum] essa é a última oportunidade de tê-lo conosco para ministrar esse curso, a turma foi agraciada com a sorte.

Na quinta e na sexta acontecerão os minicursos oficiais do Maré de Agilidade com o Manoel Pimentel da Visão Ágil e a turma da empresa SEA Tecnologia [ Renato Willi, Bruno Pedroso e Alexandre Gomes], ambos organizadores do evento.

No sábado acontecerão as palestras com todos que ministraram/rão cursos além de Clavius Tales, Fabiano Milani da Adaptworks e um tal de Christiano Milfont.

Todos os minicursos estão com vagas esgotadas, se você quiser ainda participar do Maré de Agilidade, corra para a inscrição das palestras enquanto há tempo.

Para finalizar o Maré, a Adaptworks promove o curso “Planejamento e estimativas em projetos ágeis”, através do telefone (11)5585-7738 ou pelo e-mail contato@adaptworks.com.br na sede do CGDT.

Esse pequeno tutorial-guia faz parte do material dos meus cursos de Javascript e Ajax e serve para deixar um histórico acessível aos alunos e fácil para leitores que por ventura precisem.

Preparei um ambiente de execução com todas as dependências no projeto Remendux onde vocês podem fazer checkout e rodar o build ant localmente como um projeto do eclipse – estou usando o plugin para o SVN Subclipse.

Montei um script ant padrão bem simples de ser entendido por iniciantes:

<?xml version="1.0" encoding="UTF-8"?>
<project name="jsmin" default="main" basedir=".">
	<!-- Propriedades para definir nomes de pastas que usaremos -->
	<property name="js" value="js"/>
	<property name="build" value="build"/>
	<property name="lib" value="lib"/>
	<property name="output" value="output"/>
	<!-- Propriedades para definir nomes os arquivos necessários -->
	<property name="yui-compressor.jar"
		location="${lib}/yuicompressor-2.4.2.jar" />
	<property name="yui-compressor-ant-task.jar" 
		location="${lib}/yui-compressor-ant-task-0.3.jar" />
	<!-- Incluir as libs necessárias no classpath -->
	<path id="task.classpath">
		<pathelement location="${yui-compressor.jar}" />
		<pathelement location="${yui-compressor-ant-task.jar}" />
	</path>
	<!-- Definição da task para o Ant reconhecer -->
	<taskdef name="yui-compressor" 
classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">
	<classpath refid="task.classpath"/>
	</taskdef>
 
	<target name="clean">
		<delete dir="build"/>
		<delete dir="output"/>
		<mkdir dir="build"/>
		<mkdir dir="output"/>
	</target>
 
	<target name="main" depends="clean">
		<!-- Tag do Ant para concatenar arquivos 
		[ http://ant.apache.org/manual/CoreTasks/concat.html] 
		os arquivos são unidos na sequência de definição 
		no fileset
		-->
		<concat destfile="${output}/remendux.js" force="no">
			<fileset file="${js}/util.js" />
			<fileset file="${js}/remendux.js" />
		</concat>
		<!-- Task do yui-compressor -->
		 <yui-compressor warn="false"  munge="true"  
				preserveallsemicolons="false" 
				fromdir="${output}" todir="${build}">
		</yui-compressor>
	</target>
 
</project>

Após a importação, para executar o script – que chamei de build-yui.xml – basta apenas executar com o ant pelo eclipse – vide imagem abaixo – ou em linha de comando. Estou usando o Ant 7.1 com java 6u10 e Eclipse 3.4, portanto caso haja um erro atente para a versão das ferramentas usadas.

Após executar, observe a redução de tamanho na versão minificada [../build/remendux-min.js] para a versão concatenada [../output/remendux.js ]. A versão final ficou com 30% do tamanho com documentação e identação.

Buildfile: C:\workspace\remendux\build-yui.xml
     [echo] Building output
clean:
    [mkdir] Created dir: C:\workspace\remendux\build
    [mkdir] Created dir: C:\workspace\remendux\output
main:
[yui-compressor]
 [30%] remendux.js [5775] ---> remendux-min.js [1734]
[yui-compressor]
 [JavaScript] Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
[yui-compressor]
 [CSS] No files to compress, or all files already up to date
[yui-compressor]
 Compressed 1 files to 30% (5KB to 1KB, saving 4KB)
BUILD SUCCESSFUL
Total time: 12 seconds

Como sempre criaram uma nomenclatura totalmente diferente para entidades da API, dificultando o entendimento da comunidade com anos de uso da única implementação que possuía essa API: Hibernate. Comparem a API de Criteria do Hibernate com a API de Criteria da Spec. Ok, podemos aceitar isso, política…

Faltou muita coisa ainda, mas parece que estão trabalhando para melhorar até a versão final, pelo visto DELETE_ORPHAN vai sair de alguma forma:

@Target({METHOD, FIELD}) @Retention(RUNTIME)
public @interface OneToMany {
    Class targetEntity() default void.class;
    CascadeType[] cascade() default {};
    FetchType fetch() default LAZY;
    String mappedBy() default "";   
    boolean orphanRemoval() default false;
}

Nota para os leitores:

Open Issue: We also discussed the alternative of introducing a separate annotation for the orphanRemoval functionality and the alternative of introducing a REMOVE_ORPHAN cascade
option. We would welcome feedback on the form that this metadata should take.

Não encontrei nada sobre como manipular as estratégias de fetching – que é primordial – nos relacionamentos como temos no Hibernate: Select fetching, Subselect fetching, Join fetching e Batch fetching. Nem a API de Criteria possui estratégia com FetchMode, apenas uma “Issue” aberta para a interface FetchJoinObject que deverá trabalhar isso, eu espero.

Ainda assim continuamos indicando o uso do Hibernate direto ao invés da especificação até que a especificação seja estável o suficiente com features decentes para um desenvolvimento sério em Java. A API de Criteria da implementação Hibernate continua ainda muito superior principalmente se você precisar de consultas um pouco mais avançadas.

Confiram o material e decidam.

Existe um tipo de falácia bem comum que está crescendo ultimamente se aproveitando da célebre frase: Não existe bala de prata!

Quando invocamos a necessidade de não considerar todos os problemas como um prego e a única arma um martelo, não estamos fornecendo a chave da irrestrita flexibilidade irresponsável.

Quando assumimos que em tudo depende, não estamos dizendo que não há uma fronteira. O avanço significativo do cálculo só foi possível com o advento do limite matemático.

Fazer ciência é investigar e fazer a pergunta certa ao contrário da resposta certa. Para isso identificamos padrões e formulamos teorias.

Antes de abandonar uma teoria devemos substituí-la por outra mais apropriada. Isso soa conservador mas é preciso para se fazer ciência, propor o abandono de uma determinada teoria sem a substituição por outra mais adequada é leviano.

Para entender como algo funciona não podemos simplesmente achar que qualquer solução é válida e sim descobrir qual a solução adequada.

Entender que existem soluções mais apropriadas – e que sim, existe um jeito certo ou um modo melhor de se fazer algo – não quer dizer que outras abordagens simplesmente estão erradas,  podem ser apenas incompletas e/ou inviáveis.

Em muitas discussões que tenho travado ultimamente sempre quando tento argumentar que uma solução específica é melhor do que determinada outra, ouço:

“Não existem balas de prata”. Bingo!

Essa pessoa não entende ou não quer aceitar por motivo qualquer que a solução dela está errada ou não satisfaz.

Aqui a proposta é pontual, para determinado conjunto de fatores existe uma solução mais adequada, isso é fato.

Existem Balas de prata!

Mas como somos fans de Supernatural, sabemos que o que mata é acertar no coração. O trabalho deve ser direcionado a combater a complexidade no coração do problema e não simplesmente num jogo de escolher a ferramenta certa.

Na área de desenvolvimento de software a maioria dos desenvolvedores se apegam a uma metodologia/ferramenta/arquitetura e tentam encaixá-la para a construção de qualquer sistema. Não entendem que aquela solução não vai resolver todos os problemas.

Até aqui tudo bem, o problema é aproveitar a defesa de que não existe uma ferramenta para todos os propósitos e considerar que “não existe o melhor” ou a “forma apropriada”, quando justamente por não existir ferramenta universal é que devemos usar algo por sua especialidade.

O manifesto ágil tem um trecho que diz:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.”

Observe que ele diz “melhores” e não “diferente” ou “de outra forma“.

No final diz:

“Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Aqui reconhece que os itens à direita não estão errados, apenas que os da esquerda levam a uma melhor forma de tratar o campo específico que é desenvolver software.

Tentar levar o manifesto ágil para gestão de projetos, construção civil ou limpeza da sua casa o faz ser uma bala de prata e que não vai matar nada porque você não está atigindo o coração, apenas tentando criar um martelo genérico para um uso universal.

Todo o “KnowHow” associado ao manifesto ágil se refere única e exclusivamente ao processo de desenvolver software da melhor forma, atinge o pontual.

Agiletards sabem ser chatos também quando seguem metodologias de caixinhas e querem criar um novo dogma de desenvolvimento de software.

Existe o melhor e a forma mais adequada, procurar é nosso dever!