Apresentei no QCON São Paulo 2011 um Lightning Talk: “Engine de template em Javascript com HTML Sprites”. A estratégia consiste em montar um template com suas Partials no mesmo arquivo html para facilitar o trabalho de renderização usando DIVs como “sprites”, assim como fazemos com CSS.

Para a estratégia eu construí uma Engine de Templates minimalista quase Logic-less baseada na EL do JSP. Quase Logic-less porque a única lógica permitida são sentenças como IF Ternário, comparações e o conceito de Helpers (como no Rails), que não passam de funções javascript simples que retornam alguma formatação para a VIEW.

No meu curso Javascript Fundamental, um dos exercícios é construir essa engine que chamei de ELJS.

A grande diferença entre o ELJS e o Mustache (Engine Logic-less famosa) são os Helpers e o conceito de compilação separado da própria renderização. A grande vantagem da compilação é fazer um parser das marcações e deixar o template preparado para interpolação sem precisar tratar sentenças a cada chamada de “render”.

Assim como o Mustache, o tratamento dos Partials é feito fora da Engine, no meu caso eu tratei no plugin para jQuery (TODO: terminar plugins para outras bibliotecas/frameworks).

Atualizei o plugin para jQuery apresentado no evento com a última versão que usamos nos nossos projetos e tornamos Open Source. Criei uma página de exemplo como funciona a estratégia, mas os testes facilitam a compreensão, principalmente o teste do plugin.

Dá uma olhada nos slides novamente para entender a evolução dessa estratégia.

Diferente do ano passado, eu não consegui assistir muitas palestras e ignorei todos os keynotes após o carinha do Twitter.

O Evento

Começamos o sábado com a abertura do Paulo Silveira, Leonardo Galvão e Floyd Marinescu [os 3 não precisam de apresentação].

Logo em seguida veio a palestra morna do Jim Webber que tentou ser “engraçaralho”, mas … sou cearense, entendo um pouco de humor. Nada de novo e sinceramente, falar de Rest, WebServices, SOA, etc é que nem falar de Agile hoje em dia, precisa muita criatividade para não ficar enfadonho.

O Sérgio Lopes apresentou um Keynote que eu já sabia tudo decorado, assunto batidão e… surpreendeu. Sério, apesar do assunto ser algo que eu já dominava e até já escrevi algumas coisas no blog há muito tempo, ele conseguiu pegar um enfoque – que foi analisar os sites de todos os inscritos – e dissecar em estatísticas na apresentação. Ou seja, não foi apenas uma listinha de boas práticas e TODOs para se fazer no seu site ou WebApp, ele encaixou as estatísticas e provou para todos “`a quente” o mal que isso provoca e quais prejuízos podem ocorrer, além disso publicou no blog da Caelum um dos posts mais completos que já li. Melhor do evento.

Aí entrou o cara do Twitter… saí com menos de 5 minutos. Não deu, o cara estava totalmente nem aí e tamanha apatia me deixou sem vontade alguma de assistir aquilo. Depois desse cara eu resolvi não assistir mais nenhum Keynote por puro preconceito mesmo, hoje em dia os Kyenotes em todos os eventos é a parte mais chata, experiência do AgileBrazil também. Provavelmente perdi palestras fantásticas, inclusive ouvi falarem muito bem do cara da NASA.

Minha sugestão é acabar com esse lance de Keynote nos eventos, isso é muito século 20.

Na parte da tarde do sábado e domingo eu assisti algumas palestras escolhidas a dedo, mas esse lance de trilhas me deixa doido, nunca consigo ficar parado.

No sábado eu fiquei pulando de palestra em palestra e assistindo um pedaço de cada. Vi um pouco do Vinicius Quaiato, outro pedaço do  Guilherme Silveira e um pedaço dos guys Alberto Souza e Lucas Cavalcanti, enfim, maluquice. Assisti na íntegra a palestra iOS e sincronização de dados do Mauricio Linhares. Tentei assistir ao mesmo tempo as palestra do Rodrigo Kumpera, Raphael Lacerda e do Renato Willi, aí pirei e desci para conversar com a galera. Tudo que assisti estava muito bom o que me deixa sempre apreensivo de perder alguma coisa, acabo perdendo tudo.

Depois assisti todos os Lightning Talks do Host: Ricardo Valeriano.

Como essa estratégia de tentar assistir parte das palestras tinha sido loucura no sábado, no domingo eu me concentrei e assiti do Vinícius Baggio, Emerson Macedo e quase totalmente a do Cristiano Sanchez e Wladimir Domingues. Todas fantásticas e sempre com alguma coisa que te deixa com aquela curiosidade de googlar depois de assistir. Um pequeno destaque para o Vinícius Baggio que tocou num assunto muito importante na comunidade ruby, essa história de que não faz uma boa prática ou não se preocupa com qualidade do código porque isso é coisa de Java ou whatever.

Primeiro período da tarde eu passei terminando meus slides e apresentando minha palestra

Minhas Palestras

No sábado eu apresentei um Lightning Talk: “Engine de template em Javascript com HTML Sprites”.

No domingo eu apresentei a palestra: “Combinando OO e Funcional em javascript de forma prática”.

Foto engorda a gente, né?

Networking

É muito importante para a comunidade cearense participar de grandes conferências fora do nosso estado, acabar com essa barreira geográfica e colher a sabedoria dessa galerinha lá na origem. Esse ano conseguimos levar em torno de 40 pessoas pela #caravanajavace e foi fantástico.

Não vou citar o nome de nenhum amigo que reencontrei ou conheci “ao vivo” porque não vai caber todo mundo, mas a experiência é sempre indescritível.

Visita a Empresas

Eu me programei para visitar algumas empresas e conhecer o ambiente de vários amigos e pessoas que admiro, mas infelizmente a correria de SP não nos deixa otimizar o tempo, só consegui dar uma passada na sexta de manhã pela Caelum e um pulo na manhã da segunda na Concrete Solutions – SP. Abaixo um vídeo que o Luca Bastos gravou na Concrete.

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

Primeiro curso da Milfont Consulting aberto ao público. Estamos traduzindo nossos cursos “In Company” para um formato que se beneficie do nosso modelo para empresas, mas que seja genérico o suficiente para abordar as principais necessidades que vivenciamos nos últimos 5 ou 6 anos no desenvolvimento de software como consultores.

Nossos cursos seguiam o roteiro:

1. Visita ao Cliente para avaliação de suas necessidades em determinada tecnologia – como Javascript;
2. Preparação da documentação e códigos para os conceitos coletados com base naquelas necessidades;
3. Treinamento com ênfase em “Hands on” demonstrando os conceitos dentro de uma realidade conhecida e exigida.

Esse formato é muito bom e conseguíamos atender nossos clientes com mais profundidade, geralmente esses treinamentos são dentro de um projeto maior de consultoria. O problema é o desgaste de um processo totalmente artesanal por mais que montássemos pacotes com certo grau de estabilidade de conteúdo e reaproveitássemos muitos cursos – como o de Hibernate, que praticamente não havia mudanças.

Agora estamos pegando esse modelo baseado em “mão na massa” com base no “Know How” adquirido após anos de treinamentos e não mais em necessidades de clientes. Só para se ter uma idéia, esse curso de Javascript eu ministro desde 2006/2007 quando criamos a TriadWorks, empresa que fui sócio-fundador e agora parceira/irmã da Milfont Consulting.

Sobre o Curso

Nesse curso Javascript Fundamental eu vou abordar os principais conceitos de programação funcional e orientação a objetos ao estilo Javascript, ou seja, todas as idiossincrasias que você encontrará nas principais ferramentas construídas nessa linguagem. Quero preparar o aluno a ler e entender os fontes de Frameworks famosos como Extjs, bibliotecas dominantes como jQuery e construir suas próprias ferramentas/bibliotecas, seja para o client ou server-side.

Demonstrarei alguns problemas e Cases que desenvolvemos nesses últimos anos e explicarei os fundamentos da linguagem e dos paradigmas por meio desse código.

O livro que adoto como base para esse curso é o fabuloso Professional Javascript for Web Developers do Nicholas Zakas (não incluso no material do curso).

Existem vários bons livros, inclusive já os indiquei em posts passados, veja indicações: recente e antiga.

Existem alguns bons materias gratuitos que recomendo, como: Como criar um Framework javascript, Eloquent Javascript, JavaScript Garden, jQuery Fundamentals (que apesar de ser sobre jQuery, cobre muito sobre javascript em si), Essential Javascript & jQuery Design Patterns for Beginners e o Guia e a documentação de Referência da Mozilla.

Somente com esse material gratuito e com esses livros você aprende Javascript e se torna um bom programador nessa linguagem, o que estamos vendendo é nosso Know How em situações que passamos e como esse material nos ajudou a solucionar e encontrarmos as melhores formas de construir um código limpo, claro e eficiente nessa linguagem. Estamos oferecendo um salto na abstração entre a teoria e a prática, aonde implementar e como usar aqueles conceitos, como por exemplo Closure e Currying, dentro do seu cotidiano.

O formato do curso é curto (16h), focado (direto em cases e necessidades) e baseado em mão na massa. Máximo de 6 alunos por turma para um melhor aproveitamento e acompanhamento individual.

Inscreva-se na primeira turma enquanto há vagas. A quantidade mínima de pessoas para uma turma ser montada é UMA, que no caso para essa turma nasceu garantida, já tínhamos pessoal na fila.

Sede

Av. Desembargador Moreira 2020, sala 209. Edifício Trade Center, Bairro Aldeota, Fortaleza, CE, 60.170-002 Brazil - mapa.

Criamos uma comunidade local com o propósito principal de unir todas as outras comunidades para discutirmos javascript, já que é uma linguagem presente para todos que desenvolvem na WEB, mesmo que seu Framework tente esconder de você.

Realizamos o primeiro encontro com chamada para Lightning Talks e pretendemos manter esse formato, dá mais agilidade e podemos ter mais pessoas apresentando o que estão fazendo.

Tivemos o Coffee Break da TriadWorks e brindes da Opera distribuídos para as pessoas que interagiam e faziam perguntas pertinentes. Os brindes da Opera eram bolinhas de Soccer com o logo.

Abaixo alguns materiais, vou atualizar com o restante conforme os palestrantes subam:

Testo meu jQuery sem navegador!

Aplicações 100% JavaScript com CouchApp e SammyJS

Não gosto de Spaghetti. E você?
https://github.com/hvitorino/CearaJs-Pub-Sub

Fotos

Quem tiver mais fotos, manda pra gente.

Continuando nossa saga de evitar Eval e conhecer melhor o Javascript, vou brincar com a seguinte situação: parsear um template html escrito com Expression Language da spec JSP.

Imagina o seguinte trecho abaixo:

<c:if test="${sessionScope.cart.numberOfItems > 0}">
  ...
</c:if>

É fácil montarmos um mapa com todas as expressões encontradas entre ${ e } e depois chamar eval para processar, mas como quero evitar essa chamada, o que podemos fazer?

Encontramos na documentação de referência da Mozilla a resposta, especificamente no objeto nativo Function, onde podemos criar uma new Function passando seu corpo como uma string que será executada ao fazer a chamada dessa function. Montei abaixo um exemplo como funciona:

Caso não veja no seu Feedreader, link do github.

Fiz um teste nesse momento em 4 navegadores que utilizo no dia-a-dia usando o projeto Sputnik do GoogleLabs para saber a aderencia à especificação ECMA 262. Fiz um teste sem compromisso e sem rigor acadêmico, apenas por curiosidade.

Esse teste é interessante para sabermos que possíveis problemas irão acontecer por diferença de implementação do Javascript por cada engine.

Firefox

Versão 3.6.16

Opera

Versão 11.01 – Build 1190

Chrome

Versão 11.0.696.57

Safari

Versão 5.0.5 (6533.21.1)

Voltei…

O interessante é observar que o Opera é o mais aderente, o Firefox o mais lento [travou], o Chrome o mais rápido. Para não ser injusto com o Firefox, eu ainda matei o processo, abre uma instância novinha e mesmo assim ele travou na execução, abriu aquela janelinha marota pedindo para encerrar o script.

Sequencia no sentido horário: Opera, Firefox, Safari e Chrome.

A velocidade e economia do Chrome é realmente impressionante, observe os processos:

Sequencia no sentido horário: Opera, Firefox, Safari e Chrome.

Dados da minha máquina:

[update]

Como eu sei que alguém vai me acusar de parcial, etc e tal, eu resolvi abrir uma VM aqui com XP e IE8 para não dizerem que não falei de flores … olha só:

Ok, é má vontade… Sério?

Uns 10 minutos depois e sem voltar [continua travado], já basta esses dados para mostrar que o IE8 é uma bo$ta em relação a aderência [imagina o 6]:

Problema que detectei em algumas applicações que estamos desenvolvendo com Extjs+Jquery: Na máquina de entrega o request do tipo DELETE funcionava tranquilamente, na máquina de produção hospedada no Rackspace quebrava. Como a máquina de entrega estava dentro da nossa rede, suspeitei logo da conexão, firewall e essas coisas.

O @rponte me deu a dica desse post que ele encontrou com o mesmo tipo de problema. Nunca tinha percebido que a spec HTTP nem proibe e nem recomenda corpo em DELETE. Não faz muito sentido enviar corpo realmente em DELETE, mas até aí tudo bem.

Para completar, o Extjs já previa esse problema e o JsonWriter possui uma propriedade chamada “encodeDelete” para você explicitamente definir que não quer corpo em DELETE, por default já vem assim.

No console do firebug eu utilizava o $.ajax e o Ext.Ajax diretamente com a mesma url para enviar DELETE e funcionava, mas na aplicação não funcionava. Conversando com o pessoal da rede eles me disseram que trocaram o firewall recentemente e observando o log a chamada sequer passava por lá, ou seja, provavelmente ele já rejeita qualquer conexão DELETE com body.

Fui analizar o código do Extjs e ele enviava um body, a diferença é que era vazio, mas ia. Fiz um hack para destruir qualquer parametro quando a conexão fosse para o DELETE e consertou, como pode ver no código abaixo:

Link caso não consiga ver no seu reader.

Já escrevi sobre “Eval is Evil” há um tempo, mas é sempre bom lembrar. Meu problema com Eval no js é mais de hábito, basta um eval maroto no meio do código para daqui a pouco você travar o Fofox com tanta chamada.

Uma forma simples de evitar Eval é usar o JSON.parse nativo ou com lib, mas em algumas situações isso não é possível. Basta lembrar da spec de js que define:

“An ECMAScript object is an unordered collection of properties each with zero or more attributes…”

Essa coleção funciona como um Array, portanto basta pegar a propriedade pelo index nessa coleção e executar a operação necessária como no exemplo abaixo:

Link caso não consiga ver no seu reader.