A imaturidade profissional comanda sua equipe. Comanda?

Há algum tempo tive um bate papo com o @rreimberg (iniciado via gtalk e não concluído após uma bela caminhada até o ponto de ônibus) sobre como vejo cada vez mais desenvolvedores - e às vezes, equipes inteiras - serem tão imaturos com relação ao ambiente ao qual estão inseridos; e isso é pior quando acontece também com quem deveria evitar isso: quem lidera, coordena, gerencia…. Fazia um bom tempo que vinha tentando não escrever sobre isso, pois este mesmo amigo de caminhadas vive dizendo que minhas opiniões são, em sua maioria “ofensivas”. Bem, o que posso fazer se (para começar) não consigo deixar de acreditar que existe uma separação entre Programadores e Programadores de Brinquedo - sim, vocês, que têm medo de linha de comando!

Não generalizo, reconheço que tive oportunidades  de trabalhar ao lado de pessoas incríveis; e sempre que tenho a oportunidade digo diretamente a elas o quanto representam no meu crescimento profissional. Acontece que - quase - sempre me deparo com situações de completa inexperiência técnica e de perfil de liderança nas áreas de gestão. Pode ser que eu seja duro demais, porém vejo que além do requisito óbvio de se possuir um perfil de liderança, nas áreas que envolvem desenvolvimento de software, são imprescindíveis conhecimentos reais de pontos que fazem sim a diferença entre sucesso e fracasso de um projeto; infelizmente estão sempre para “pontos negativos”. Estes pontos envolvem o não conhecimento das ferramentas de gestão de código, como SVN e GIT; acesso remoto via SSH, e no momento - não posso dizer pelo futuro, certo? =P; a falha mais terrível é a de uma pessoa com responsabilidades de estar a frente de uma equipe não conhecer, não estabelecer e não cobrar que um processo formal de deploy seja adotado. E olha que neste caso não chego a ser radical, basta um processo claro (mesmo que desenvolvido internamente pela equipe).

Infelizmente este não é um cenário fácil de mudar, depende muito de cultura organizacional e cabeça aberta de quem está nessa posição de se auto avaliar e começar a correr atrás. Tenho certeza  de que é muito mais comum do que se pensa e é bem provável que a imaturidade comanda sua equipe. Comanda?

Apache: seu servidor web é o Microsoft Word

UPDATE: alguns dados sobre market share de servidores, mostrando que nginx possui pouco mais de 12% de participação em todos os domínios ativos (até Janeiro de 2012): http://goo.gl/KztKo

Vivemos a era do Big Data; a cada dia precisamos de mais espaço para guardar nossas informações e - ao contrário de quando comecei a trabalhar nesta área - espaço em disco é barato, qualquer um consegue alguns terabytes na Santa Efigênia por um preço irrisório. Antes, espaço era o problema, hoje nossos desafios caminham na direção de como gerenciar tantas informações. 

Os velhos métodos, os velhos modelos nunca deixarão de existir, mas é evidente que para novos desafios, precisamos de novas ferramentas. Até pouco tempo atrás, bastava a um desenvolvedor conhecer SQL e alguns poucos sistemas de banco de dados relacionais para que ele tivesse, em suas mãos, ferramentas necessárias para tornar seu dia a dia mais fácil, no que diz respeito ao trato com dados. Hoje, somente SQL não é mais suficiente. Empresas querem resultados - rápidos - e para que um desenvolvedor seja produtivo ele precisa estar atento às mudanças que ocorrem em seu meio. NoSQL não é um conceito novo, mas tem tomado cada vez mais a atenção de grandes empresas, fazendo com que seja uma alternativa viável na entrega de produtos que correspondem à espectativas de clientes, desenvolvedores e usuários.

Se por um lado, bancos de dados caminham para um estado de graça em que veremos, com muito mais frequência, conceitos como o de persistência poliglota, do outro lado os servidores web continuam parados no tempo. Dentre os mais usados hoje está o Apache; construído em uma época em que os problemas da gestão de dados eram diferentes e apesar de sua evolução, não tem sido suficiente para resolvê-los. O problema dessa nossa “era”  relacionado aos servidores web está relacionado a suportar grandes volumes de acesso, com baixo custo - da implantação à manutenção e com baixa dependência de novo hardware.

Ok, é possível escalar aplicações web apenas com Apache? Sim, claro, mas isso traz um ônus para a implantação de novo hardware sempre que o número de acessos aumentar - já vi isso várias vezes e estou vivendo isso em meus projetos atuais. E por conta destes projetos de alta demanda, venho me interessando por novas alternativas ao uso do Apache para entregar aplicações web. Uma das quais vejo um grande potencial é o nginx (engine x). Uma frase de Chris Lea descreve bem a situação em que o Apache se encontra hoje:

Apache is like Microsoft Word; it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache.

Veja bem, deixo claro que não sou fanboy, não gosto de flames, tampouco estou sugerindo a extinção do Apache, mas a situação para a maioria dos projetos que entreguei no último ano não precisavam sequer tocar no Apache. O projeto ao qual estou me dedicando atualmente realmente necessita de uma solução “poliglota” em que seria muito útil ter Nginx e Apache trabalhando juntos - portanto a idéia que defendo é exatamente a de utilizar as ferramentas certas, baseado no tipo de problema a ser enfrentado.

Mas Apache é robusto, consolidado no mercado, mimimi, mimimi

Certa vez, ouvi de um professor, quando falava sobre Node.js, de que ele somente confia em soluções que estejam muito bem conceituadas no mercado, apoiada por empresas de renome e bla, bla bla - nem preciso dizer nada a página inicial do node.js diz tudo. E porque falei nisso? Talvez, você também tenha pavor de versões beta, alpha e software on the edge e apesar de recente, nginx tem um share no mercado de quase 10% e apostaria minhas fichas que até o fim de 2012, estará mais próximo de abocanhar uma fatia maior, alcançando a solução da Microsoft - IIS - com aproximadamente 14% do mercado.  Se o problema é respaldo da indústria, nginx tem de sobra.

Não sou eu quem decide isso…(?)

Não existe panacea na vida e com tecnologia não é diferente, convencer seu chefe/cliente a usar nginx é um passo que exige mostrar os benefícios que ele pode trazer em seus projetos, mas talvez o mais óbvio seja o fato de economizar muito em hardware. Um VPS pode suportar um grande volume de acessos sem problemas e até hoje não conheci nenhum cliente que queira gastar - se puder economizar ele o fará - portanto, dentre todos os fatores este pode ser decisivo. Acredito que as transformações na sociedade só acontecem quando decidimos “mexer nossas bundas” e como profissional, é sua responsabilidade fazer com que avanços sejam percebidos, utilizados e novas técnicas sejam desenvolvidas - questionar também faz parte do aprendizado, aquilo que aprendemos nos livros é válido, mas não é “palavra escrita numa pedra”.

A linha de código mais elegante, que possui o mínimo de bugs, é mais fácil de escrever e fácil para alguém, lendo seu código, entender é aquela que você não escreve. Menos linhas de código é melhor

Tradução livre do que escutei hoje, num vídeo do Paul Hegarty (professor da Stanford). 

Não é a primeira vez que escuto (ou leio) algo parecido, mas me fez pensar sobre muitos projetos ruins que por vezes me aparecem; e penso no amadorismo que se forma por ai. Não sei se a culpa é das instituições (Faculdade, Cursinho S.O.S Bytepog) ou das pessoas, que se acomodam com melhorias de Hardware, das runtimes e seus garbage collectors ultra eficientes e deixam de pensar que mais de 50% da solução não está na máquina e sim no humano.

Por estes (e outros) motivos, talvez desenvolvedores de software devessem estudar como estudam os designers. Propor soluções que não são apenas funcionais, mais que simplesmente bonitas e que nos aproxime do que somos - humanos - e mesmo não sendo um fanboy, reconheço que Steve Jobs sabia disso, há tempos atrás. 

Multi Device Design

ou

Design à prova de futuro 

ou

O que você está esperando para desenvolver para web  sem ser preguiçoso

ou (ainda)

Seja designer uma vez na vida seu programador de merda

Acabei de ler esse texto do Luke Wroblewski, e digo que é uma das coisas mais inspiradoras que li neste mês, principalmente se levar em conta meu interesse recente em mobile.

Comprei e ainda não comecei a ler os livros Responsive Web Design e Mobile First - trabalho, fim de semestre na faculdade e nada é uma desculpa para não ler - e tenho certeza que vou devorá-los antes do Natal.

É uma pena que para muitos programadores a preocupação com design é quase nula. Entender que design está além da existência do profissional especialista, que cuida deste setor na empresa e/ou equipe, torna você - programador - mais que programador; o torna um ser humano, com visão, criatividade e, acima de tudo, paixão pelo que faz. É isso que busco todo dia.

Conheça seu inimigo

Pra quem desenvolve para web um pesadelo constante está ligado à inconsistência entre navegadores. Se eu for comparar a época em que comecei a desenvolver com o cenário atual, vivemos em uma era bem mais convidativa para o desenvolvimento de forma consistente; à época de guerra entre Netscape e Internet Explorer a coisa era bem mais difícil.

Essa guerra fez com que muita gente tomasse a decisão mais simples, de suportar apenas um navegador, originando a famigerada expressão: “Melhor visualizado em Internet Explorer 6.0 e resolução 800x600”. Eu mesmo já fui obrigado a adotar essa expressão em projetos passados (arrrghh!).

Mas as coisas mudam, a web evolui a uma velocidade impressionante e hoje a guerra está ligada à entregar navegadores cada vez mais aderentes aos padrões e com alto desempenho. Ótimo para quem precisava fazer malabarismos para dar ao usuário uma experiência consistente entre navegadores, mas isso não elimina a necessidade de empregar algum esforço para atingir este objetivo.

Uma das coisas que aprendi ao longo dos anos e que ajudava muito quando o IE6 ainda era um big player, foi “conhecer meu inimigo”.

Conhecer o seu inimigo está relacionado a estudar as limitações do ambiente para o qual se está desenvolvendo, de modo que você não ocupe seu tempo tentando reinventar a roda ou “nadar contra a corrente”. Quando se entende os pontos fracos e fortes de cada navegador, muita coisa pode ser simplificada. Com o Internet Explorer, a idéia era de não usar hacks CSS em hipótese alguma; e há quem duvide que isso seja possível.

Mesmo com um bom suporte de padrões pela maioria dos navegadores modernos, essa idéia de conhecer seu inimigo não é desperdiçada. Ainda existem inconsistências, principalmente se usarmos uma ótica de desenvolvimento para web móvel;  há uma infinidade de aparelhos, navegadores e especificações de suporte a CSS, HTML e JavaScript - e isso não quer dizer que você precisa de um CSS para cada navegador, como também era comum aplicar ao IE6.

Hoje, aplico esse conceito não somente voltado aos navegadores, mas em todo o ambiente em que trabalho. Entendendo as limitações que a HTML, CSS, JavaScript ou qualquer outra tecnologia impõe e abraçá-las como parte do dia a dia, sem tentar subverter seus conceitos para contornar tais limitações. Um exemplo é a maneira como vejo o sistema de herança do JavaScript em relação à alguns anos atrás. Quando se entende o sistema de cadeia de protótipos, é possível usá-lo a seu favor, ao invés de tentar refazer um sistema de herança para que fique mais próximo de linguagens orientadas a classes, tal como Java. Prototype faz isso, e logo que conheci a biblioteca achei interessante poder construir “classes” em JavaScript, mas hoje não tenho o mesmo entusiasmo com este tópico - protótipos funcionam, closures e módulos são padrões bem estabelecidos na comunidade JavaScript e programação funcional é parte da natureza da linguagem. Desta forma, fica a questão: será que é preciso escrever camadas e camadas sobre a linguagem, ou aprender a usar seus recursos e limitações de maneira correta?

Conhecendo seus inimigos!

Algumas referências para ajudar a identificar problemas que podem ser evitados, diminuindo a quantidade de tempo que você passa fazendo hacks ou reinventando a roda.

JavaScript Garden - http://bonsaiden.github.com/JavaScript-Garden/ 
Alguns pontos problemáticos do JavaScript, bugs e explicações dos motivos de cada tópico. Também tem muitas dicas sobre o qeu não fazer em JS.

WTFJS  - http://wtfjs.com
Mostra de maneira humorada as coisas bizarras que existem no JavaScript, porém com toda a explicação sobre os problemas e como evitá-los. Você pode ainda contribuir, caso encontre alguma coisa bizarra ainda não relatada.

Explorer Exposed -  http://www.positioniseverything.net/explorer.html
Lista inúmeros bugs (a maioria sobre CSS) do Internet Explorer, explica os motivos e mostra como resolvê-los. Também há neste site uma seção (bem menor) voltada a bugs de outros navegadores.

E claro, uma das melhores (senão a melhor) referência sobre JavaScript está na MDN. Porém muita coisa boa pode ser extraída da MSDN - principalmente para identificar problemas e soluções para Internet Explorer. 

Update:

Se você é adepto de árvores mortas - eu ainda sou - boas fontes para entender como se livrar de alguns problemas em JavaScript são os livros: High Performance JavaScript do Nicholas C. Zakas e Test Driver JavaScript Development, de Christian Johansen 

Lições sobre desenvolvimento web móvel

Sempre pesquisei e me mantive por perto do desenvolvimento web móvel mas nunca havia aplicado com intenção de trabalho os conhecimentos teóricos que adquiri ao longo dos anos. Durante as últimas semanas tive de reavaliar aquilo que já sabia e descobri que o que está nos livros, especificações e até mesmo em blogs é muito mais bonito do que quando enfrentamos a realidade.

Se no livro Sistemas Operacionais Modernos, Tanenbaum chama o mundo dos sistemas operacionais de “zoológico”, eu chamaria a quantidade de dispositivos móveis, seus sistemas operacionais e navegadores de “parque das aberrações”, pois mesmo utilizando padrões web é preciso ter conhecimentos das limitações de cada plataforma ou mesmo de cada aparelho que seja parte de seu público alvo. Isto me leva umas das tantas lições que não se aprende em livros: conhecer quem acessará o site/aplicação é crucial para guiar o desenvolvimento.

Para um dos projetos que estou envolvido, a maior base de acessos passada pelo cliente foi de aparelhos celulares que suportam no máximo WAP2 e tive alguns contratempos durante a produção do XHTML. Um exemplo foi a surpresa que tive ao descobrir que alguns aparelhos Sony Ericsson aplicam uma visualização bem estranha a campos select (<select />), mostrando-os como uma lista de campos radio (<input type=”radio” />). Essa característica acaba com o sonho dourado de qualquer designer ou desenvolvedor que achou que a experiência de navegação seria a mesma para todos os celulares.

Conhecer as limitações do desenvolvimento móvel por todos os envolvidos no projeto é muito importante. Esta é outra lição que tiro sobre a produção de soluções móveis. Digo isto pois pode ser muito desconfortável, tanto para o cliente quanto para o desenvolvedor, descobrir que o projeto vendido inclui funcionalidades não realizáveis em um contexto móvel. Acredito que o pecado mais comum que encontramos neste aspecto foi a constante utilização de padrões Ajax para atualizar a interface. Infelizmente o suporte a JavaScript não é confiável em um grande número de aparelhos, principalmente os celulares que citei anteriormente. Mesmo havendo interesse na evolução da especificação XHTML MP em suportar ECMAScript Mobile Profile não encontrei muitas maneiras de aplicá-lo de maneira consistente para a maioria dos aparelhos.

Outro ponto crítico está relacionado aos testes daquilo que já foi produzido. Para um site ou aplicativo web desktop, há um grande número de ferramentas muito bem estabelecidas no mercado que ajudam no processo de testes. Bem ou mal, todos os navegadores se comportam de maneiras similares e contam com inspetores de código HTML, JavaScript e CSS. Utilizar emuladores para testar ajuda muito e no caso da inspeção de código, utilizei as ferramentas para desenvolvedor do Google Chrome e Opera DragonFly com certo sucesso. Além disso, a validação do W3C e mobiReady ajudam a identificar pontos que precisam ser melhorados ou refeitos.

Mesmo sendo um mundo completamente bizarro, cheio de “Frank-N-Steins”, é fascinante; esta creio ser a melhor de todas as lições.

Zend Framework e a caça aos bugs de Julho

Uma das melhores maneiras de aprender mais sobre PHP, melhorar suas habilidades com técnicas de TDD e manter o código do framework que você utliliza mais robusto e estável. Não há necessidade de ser expert em PHP, alguns problemas listados no Issue Tracker precisam apenas de um filtro para determinar se realmente há um bug ou melhoria a ser feita na solicitação. Muitos deles podem ser eliminados por uma olhada rápida e discussão com o pessoal do #zftalk.

Se você se esforçar, pode até ganhar uma camiseta oficial. Bora tentar?

Um parágrafo por dia

Depois de algum tempo trabalhando com Zend Framework, notei que a maioria das pessoas que nunca trabalharam com ele (ou que experimentaram pouco) tinham - e ainda têm - dificuldades para encontrar informações acertadas dentro da documentação oficial. Esse não é um fenômeno isolado, pois acompanhando as listas de discussão e a wiki oficial do projeto, percebo uma preocupação muito grande com o fato de existir uma curva de aprendizado mais elevada, somada pela documentação muitas vezes ruim, ou mesmo inexistente. Mas nem tudo é ruim; o guia de referência é o principal ponto para que se tenha um entendimento básico de como os componentes operam e a partir dali pode-se explorar a documentação da API, ou mesmo o próprio código fonte (sim, código-fonte é documentação, se você não o inspeciona, passe a fazê-lo imediatamente).

Foi pensando nessa dificuldade que comecei a me perguntar como minimizá-la e acabei enxergando que muita coisa não é absorvida (no caso, pelas pessoas que passaram e ainda estão na equipe com a qual trabalho) pelo simples fato de não haver documentação exposta em nosso idioma. Por isso decidi me informar sobre o status da tradução do framework para o Português Brasileiro e sinceramente me decepcionei: de acordo com a informação na página do projeto, apenas 13% do manual oficial está traduzido. Para que uma tradução seja aceita e mantida na página da documentação oficial ela necessita de pelo menos 50% de seu total traduzido e vi que estamos longe dessa situação, ainda mais com a iminência de um release não muito distante da versão 2 do framework. O  principal motivo para este número baixíssimo é a falta de colaboradores para tocar as traduções. Após entrar em contato com a equipe oficial de tradução, vi que muitos que começaram o projeto estão inativos e não há grande procura de novos membros para que a produção de documentos seja acelerada.

De acordo com a página de instruções para colaboração ao framework voltada a tradutores, há um trecho que diz não ser necessário fluência em inglês para produzir os documentos em inglês. A razão para isso é justamente o aspecto colaborativo do processo, se seu inglês não está lá muito bem, outra pessoa com fluência poderá ajustar eventuais erros, quando necessário. Ora, se para produzir a documentação original não há necessidade de fluência em inglês, imagino que também possamos tocar a tradução dos documentos para nosso idioma e ajustá-los ao longo do tempo. Por conta disso decidi me informar sobre como a equipe oficial estava trabalhando e colaborar. A idéia inicial era a de traduzir “um parágrafo por dia” e vi que o fato de estar comprometido com um trecho tão pequeno de texto me fez concluir meu primeiro documento em um tempo muito menor do que o “previsto”.

Pretendo continuar a ajudar a equipe de tradução e digo que a sensação que se tem de poder construir algo de modo colaborativo é muito boa. Se você acha que não pode contribuir para um projeto só porque acha que não tem tempo suficiente, pense novamente e colabore com “um parágrafo por dia”. Tenho certeza que por menor que seja a contribuição ela será de grande valor.

Se você estiver a fim de escrever um parágrafo por dia e praticar seu inglês. Nos ajude:

Assine a CLA (Contributors License Agreement) e envie para cla@zend.com. Minha resposta chegou em 2 dias quando fiz, não é um tempo exagerado.
http://framework.zend.com/wiki/display/ZFPROP/Contributor+License+Agreement 

Visite a Página Oficial da equipe de tradução, nela estão listados os membros e quais arquivos estão atualmente em processo de tradução.
http://framework.zend.com/wiki/pages/viewpage.action?pageId=3091

Como somente coordenadores e outros perfis de maior grau de influência nas decisões do framework são commiters no repositório oficial, a equipe organizou um projeto, hospedado no Google Code para que todos possam contribuir e acelerar a produção de documentos. Aqui também há uma versão do manual em português (não oficial) contendo todo o esforço realizado até o momento pela equipe de tradução.
http://code.google.com/p/zfdoc-ptbr/ 

“profissional” ou Profissonal: o que você quer ser?

Durante minha experiência com o desenvolvimento de projetos web encontrei as mais diversas metodologias e políticas relacionadas à gestão de modificações de software. É claro que aprendi muito com todas estas experiências e tenho que dizer que aprendi mais sobre o que não fazer do que o contrário. Conheci pessoas que sabiam exatamente o que estavam fazendo bem como aquelas que na base da tentativa e erro, cedo ou tarde, conseguiam atender um prazo, mas imagino que essa seja uma situação recorrente, não limitada a este mercado.
 
A velocidade em que tudo pode mudar em um projeto, em muitas vezes, é tão grande que não há sequer um processo formal no qual toda a equipe está de acordo para a entrega de versões de um produto com qualidade. Encarar processos que possam ser chatos ou demorados são imediatamente tirados do campo de visão dos desenvolvedores tão logo que entram em uma empresa no início de suas carreiras, os quais se criam em um ambiente de total desorganização e levam para suas vidas uma cultura de bagunça, falta de normas e total desapego à disciplina. Sou desenvolvedor PHP há mais de 7 anos e durante vários deles ouvi muitas anedotas a respeito do “tipo de programador” que a linguagem forma e infelizmente conheci poucos caras que levavam a sério o seu trabalho e se preocupavam com aspectos de arquitetura, desempenho, segurança e aperfeiçoamento constante; a maioria fazia muita porcaria. Porém seria um grande engano, daqueles que adoram flames e defendem a ferro e fogo suas “linguagens altamente tipadas-totalmente orientadas a objetos-e-ultra performáticas”, de que somente em PHP existem programadores que fazem “suinagem” em seus códigos. Recentemente, analisando um projeto .NET com um amigo vimos que tem muita coisa pior do que já vimos em PHP (e olha que a má fama tem alguma origem), provando mais uma vez de que não há linguagem ou plataforma melhor que outra; são os “profissionais” que precisam se colocar como Profissionais.
 
Quando se está em começo de carreira, é comum abrir qualquer editor e sair programando, eu mesmo já fiz isso e é uma das maneiras que se tem para experimentar e ganhar confiança naquilo que se trabalha, mas à medida que se ganha experiência é necessário ter cautela e pensar em muitos fatores que podem ou não levar um projeto ao sucesso ou fracasso. Conhecer o conjunto de ferramentas que cercam um desenvolvedor é uma obrigação - e das mais básicas - e que não se limita apenas à sua IDE favorita ou ou banco de dados com o qual trabalha com maior frequência. Em “Engenharia de Software”, no capítulo sobre SCM há uma frase, aplicada à métodos ágeis que não me sai da memória:
 

“[…]. Preferivelmente processos ágeis usam ferramentas simples de CM como as ferramentas de gerenciamento de versão e de construção de sistemas que exigem algum controle. Todos os membros da equipe devem aprender o uso destas ferramentas e ajustar-se às  disciplinas que elas impõem.”

Engenharia de Software, 8ª ed, cap 29, p.457, I. Sommerville - Pearson Addison Wesley, 2007

Ênfase minha, pois foram as palavras que ficaram na cabeça e é justamente aquilo que menos vi em equipes e projetos. Apenas uma pequna parcela de profissionais conhecia ou tinha o interesse em conhecer sobre as ferramentas à disposição durante o desenvolvimento, de maneira muitas vezes não muito aprofundada. Bons exemplos incluem o uso consciente de expressões regulares ou entendimento de branches, merges e outras operações com SVN; são simplesmente um pesadelo para alguns caras. Deixo claro que não saber não é o problema, mas como estes (e outros) assuntos são levados em consideração para muitos desenvolvedores, que se acomodam, pois sempre há alguém ao lado (ou em algum fórum) para fazer o trabalho em seu lugar. Acredito que se os Profissionais de desenvolvimento de software não se ligarem, em pouco tempo teremos muito mais “profissionais”, deixando portas abertas para a mão de obra estrangeira abocanhar fatias importantes da nossa economia.

JavaScript ainda não é “linguagem de verdade”?

Há tempos atrás, eu li um excelente texto no blog Quirks Mode que falava sobre a negligência da maioria dos desenvolvedores web em relação ao uso e principalmente ao aprendizado de JavaScript. O texto é antigo mas ainda se aplica aos dias atuais. Me lembrei disso e resolvi escrever, pois durante esta semana ouvi:

”- Você tem um livro de TDD com JavaScript? Nunca vi, nem imaginei isso!” 

Sim, tenho. Não só um livro sobre TDD em JavaScript mas também alguns outros que falam de tópicos como design patterns aplicados ao contexto da linguagem, entre outras coisas. Investir conhecimento e dinheiro em entender melhor como programar e estruturar aplicações JavaScript me fez sempre parecer um alienígena pois, para os outros, meu dinheiro poderia ter sido melhor investido em livros sobre Java, ASP.NET, Ruby ou quaisquer outras linguagens “de verdade”.

Mas afinal, JavaScript não é linguagem de verdade?

Ao longo dos anos em que tive a oportunidade de trabalhar com as mais diversas equipes e projetos das mais variadas plataformas de desenvolvimento, JavaScript é a única em que ninguém se preocupa poucos se preocupam em dedicar tempo (e dinheiro) em melhorar seus conhecimentos para entregar a seus clientes produtos com maior qualidade. A linguagem não é vista como “linguagem de verdade” e sim como “alguma coisa para fazer gambiarras” e que não vale sequer o esforço de se empenhar em estudá-la, assim como fazem os experts em Java e todos os seus design patterns e filosofias sobre robustez, multiplataforma e etc. Este é um grande erro, pois JavaScript é sim uma linguagem poderosa e me espanta ver que pouca coisa mudou no pensamento dos “programadores de verdade” desde que li o artigo.

Com a grande variedade de bibliotecas, como jQuery, essa impressão que tenho se mostra intensificada de tal maneira que vejo situações em que o programador espera soluções completas e mirabolantes da biblioteca, quando estas são inerentes do conhecimento da linguagem em que a mesma foi escrita (JavaScript). Vejo esse comportamento se repetir também em muitos desenvolvedores que aprendem frameworks de outras linguagens e simplesmente se “esquecem” de entender alguns “porquês” da plataforma em que trabalham. Não sou contra o uso de bibliotecas (JavaScript ou não) no desenvolvimento de aplicações web, mas as vejo apenas como ferramentas que ajudam a eliminar o velho problema de reinventar a roda.

Muita coisa tem sido criada justamente por acreditar no potencial da linguagem, não somente voltadas a programação de aplicações em um navegador web:

  • CommonJS: iniciativa para fomentar o desenvolvimento JavaScript em outras plataformas além do navegador web
  • V8 JavaScript: motor JavaScript de código aberto do Google
  • node.js: biblioteca para manipulação de E/S orientada a eventos, sob o motor V8 JavaScript
  • Cappuccino: framework para aplicações com aspectos desktop, desenvolvido em Objective-J, linguagem que possui compilador e implementação em JavaScript;
  • SproutCore: framework para desenvolvimento de aplicações com aspectos de desktop que usa tecnologias web existentes: JavaScript, HTML e CSS
  • Handlebars: templates ultra leves para JavaScript (integra o projeto SproutCore)
  • JavaScriptMVC: framework MVC para aplicações JavaScript

Desenvolver para web não é simplesmente aprender uma tecnologia server-side ou jQuery. Entender as tecnologias envolvidas em todos os processos é um passo básico para quem se propõe a entregar soluções que realmente tenham qualidade, não somente limitado ao aprendizado de JavaScript, mas também HTML, CSS, XSLT e tecnologias relacionadas.

Top