Olá, é com grande satisfação que gostaríamos de compartilhar com você nosso novo curso curso online, o Imersão ExtJS 4 que será ministrado pelo Christiano Milfont que irá tratar sobre as melhores práticas para desenvolver WebApps com riqueza de usabilidade usando ExtJS 4.

O Framework Javascript de propósito geral ExtJS possui Widgets [componentes] que fascinam e agilizam o desenvolvimento principalmente de aplicações comerciais que são migradas do Desktop.

Existem bons livros já publicados, como o da brasileira Loiane Groner, que também está publicando um curso gratuito no formato de Screencasts cobrindo o básico do ExtJS e aprofundando com muitos exemplos. O próprio Framework contém uma excelente documentação, uma gama enorme de exemplos, abrangendo inúmeras situações.

Bootstrapping

Uma grande dificuldade para desenvolver WebApps, principalmente para desenvolvedores especializados no Backend, é a aridez de desenhar a interface com CSS e trabalhar o comportamento da visão com Javascript.

Enquanto os sistemas operacionais fornecem um conjunto de componentes de Interface por meio de API e Look’n'Feel padronizado para você simplesmente construir a aplicação, na Web o trabalho é bastante artesanal, inclusive com a necessidade de trabalhar com ferramentas especializadas de design como GIMP ou Photoshop.

Não é à toa que o Toolkit Bootstrap disponibilizado pelo Twitter faz tanto sucesso, inclusive com o mesmo nome da técnica de construir um modelo de layout com componentes padronizados para facilitar a construção de aplicações web.

O ExtJS já fornece embutido no seu Framework todo um conjunto de templates e elementos gráficos para utilizar com seus componentes, além da abertura para customização caso seja necessário. Além disso existem diversos templates distribuídos por terceiros.

Diferencial do Curso

Como já mencionado, existe uma infinidade de materiais disponíveis na Web onde você pode aprender por conta própria.

O diferencial do nosso curso não é simplesmente aprender sobre os Widgets e montar telas ricas, é a experiência de quem desenvolve com o Framework desde que ele era uma extensão do YUI [Framework do Yahoo].

Iremos demonstrar as melhores práticas de como construir aplicações verdadeiramente ricas que são proibitivas de serem construídas num processo artesanal por meio de JS e CSS por dar muito trabalho.

Vamos tratar sobre assuntos espinhosos, como extender componentes, modificar o comportamento natural de elementos do próprio HTML, como navegação por meio de eventos que não existem e ainda vamos dar uma palhinha de como construir uma aplicação que se adapte a dispositivos móveis usando o SenchaTouch com o mínimo de esforço dentro do possível.

Matricule-se já e garanta sua vaga.

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.

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

Amanhã, 11/04/2011, palestrarei no evento “8.ª Jornada CETI – Cursos de Extensão em Tecnologia da Informação” na FA7, sede do BrazilJS.

Titulo: Test Driven Development com Javascript
Resumo Original:  Entenderemos que só TDD é o caminho e a luz da escrita de um bom software, será demonstrado como até em plataformas difíceis se pode praticar essa metodologia, admitir que testes em TDD é apenas um benefício e não a causa, além de códigos e mais códigos.

Ah, será duas vezes:

Manhã

Data: 11/04/2010, segunda-feira
Horário: 07h30
Local: Auditório do Curso de Direito

Noite

Data: 11/04/2010, segunda-feira
Horário: 19h
Local: Auditório do Curso de Direito

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.