Herberth Amaral Software development adventures

11Mar/100

O que fazer quando seu codigo JavaScript se torna um monstro

Quando eu não conhecia jQuery e seus plugins, JavaScript era um tédio pra mim. É fato que uma biblioteca de alto nível (não só o jQuery, mas o mootools e o prototype, por exemplo) facilitam e deixam o desenvolvimento em JavaScript rápido e divertido, pois você não terá que se preocupar (muito) com detalhes de implementação de browsers.

Mas o que acontece quando, mesmo usando com alguma lib fodástica, seu código começa a ficar grande demais, complexo demais, fragmentado demais ou desorganizado demais? Isso é a minha definição de código monstro. Eis algumas dicas que podem te ajudar se você estiver passando por isso:

1 - Evite o Callback Hell

O jQuery mostra muitos exemplos usando funções anônimas como callback. De certo modo, isso é uma boa prática para situações simples, como o  tratamento do evento clique de um botão:

$("#meuBotao").click(function(){
  alert('Fui clicado!');
});

Mas nem sempre isso é legal: muitas vezes você quer reaproveitar essa função para outros callbacks, como por exemplo:

$('#meuBotao').click(getClientes);
$('#meuInput').blur(getClientes);

getClientes = function()
{
   $.get('/clientes/get','',
   function(data){
      //trata os dados recebidos aqui
   },'json')
}

Nesse caso, eu estou aproveitando minha função de callback getClientes para dois event listeners. Isso é bem legal, mas quando nosso código começa a crescer, nos esbarramos em outro problema: as funções globais.

2 - Evite funções globais

Isso quer dizer, ao invés disso:

$('#meuBotao').click(getClientes);
$('#meuInput').blur(getClientes);

getClientes = function()
{
   $.get('/clientes/get','',
   function(data){
      //trata os dados recebidos aqui
   },'json');
};

Faça algo assim:

$('#meuBotao').click(getClientes);

$('#meuInput').blur(Clientes.getClientes);

var Clientes = {
    getClientes:function()
    {
       $.get('/clientes/get','',
       function(data){
          //trata os dados recebidos aqui
       },'json');
    }
};

Isto é, coloque suas funções dentro de objetos. Assim você evita funções globais e evita fazer código "estruturado", passando a usar os recursos da orientação à objetos do JavaScript e deixando o mínimo de globals possível. Essa é a forma mais fácil que eu conheço de se evitar funções globais e organizar melhor seu código, mas há outras formas como o Module Pattern.

3 - O "this" aponta para diferentes lugares em diferentes contextos. Saiba como lidar com isso.

Você não está deixando mais todas as suas funções como globais, está encapsulando tudo dentro de objetos, reaproveitando código e feliz da vida quando percebe que o this não é mais this. Calma que eu explico.

Você já deve ter visto algo assim no jQuery:

$('a').click(function(){
   $(this).html('fui clicado') ;
});

Isso faz com que, quando um link é clicado, o mesmo fique com o texto "fui clicado". Deu pra notar que nesse caso, o this aponta para o elemento que disparou o evento. Mas olhe o seguinte exemplo:

var Cliente =
{
    texto:'Fui clicado',
    init:function()
    {
        $('a').click(this.aClickHandler); //this aponta para o objeto Cliente
    },
    aClickHandler:function()
    {
        $(this).html(Cliente.texto); //this aponta para o elemento "a" que disparou o evento
    }
};

Viu como "this" pode mudar de contexto? No exemplo acima, o problema de não ter o this apontando para o objeto Cliente foi facilmente contornado, mas você poderá precisar acessar o objeto pai de uma forma parecida com a this. Nesse caso, você pode passar um parâmetro para o evento usando o método bind() do jQuery, informando o contexto que ele foi chamado:

var Cliente =
{
    texto:'Fui clicado',
    init:function()
    {
        $('a').bind('click',{'self':this},this.aClickHandler); //this aponta para o objeto Cliente
    },
    aClickHandler:function(event)
    {
        var self = event.data.self;
        $(this).html(self.texto); //o self aponta para Cliente e o this aponta para o elemento "a" que disparou o evento
    }
};

4 - Procure pelos patterns corretos.

Quem disse que padrões de projeto criam um vocabulário em comum na equipe não poderia ter dito algo mais pertinente:  o uso de padrões faz com que o desenvolvedor foque nas funcionalidades da aplicação sem se preocupar com alguns detalhes de implementação.

O AjaxPatterns contém uma coleção bem legal e bem documentadas de patterns para Ajax e JavaScript em geral. Mas não espere ter problemas pra consultar os patterns: quanto mais se conhece sobre padrões, mais fácil é pensar em soluções de problemas e planejamento em geral.

5 - Deixe apenas um $(document).ready em todo o seu código

Eu diria isso para todos os event listeners que você possa vir a colocar, mas o $(document).ready é o mais crítico na minha opinião. No JavaScript não há sobreposição de eventos: se você colocar dos event listeners para um mesmo evento, os dois serão executados. Isso pode dar problemas, pois você pode deixar o $(docuement).ready em dois arquivos diferentes e você pode desejar que um evento execute antes de outro.

6 - Valide seu JavaScript

Browsers interpretam JavaScript de forma diferente, então é sempre bom ter uma padronização de código para que não tenhamos problemas com sintaxe em diferentes browsers. Uma ferramenta de validação bem legal é o jslint.

  • Share/Bookmark
28Jan/100

Testes unitarios no Flex usando o FlexUnit 4

O FlexUnit 4 é a mais nova versão (não tem a oficial, só a RC, por enquanto) e apresenta uma série de vantagens sobre o seu antecessor, o FlexUnit 0.9, como os metadados de teste ([Test], [After] e [Before], para citar as mais populares), Theories, DataPoints e Assumptions que são úteis para testar grandes quantidades (talvez até infinita) de dados e ver como a aplicação se comporta e a possibilidade de executar os testes com diferentes Runners.

Este tutorial tem como objetivo mostrar o básico de testes unitários no Flex, sem se aprofundar muito nos recursos avançados do framework de testes.  Eu pretendo ir postando mais tutoriais à medida que eu for me aprofundando na tecnologia.

O setup

Para usar o FlexUnit4, você precisa baixa-lo aqui. Após isso, crie um projeto no Flex Builder e adicione todas as libs que vieram no pacote no seu diretório libs:

Verifique se todas as libs estão lá

Como o bom e velho TDD manda, vamos primeiro escrever a classe de teste de exemplo antes de escrever nosso código de produção.

A classe de teste

Uma classe de testes é uma classe comum que usa a classe Assert para fazer asserções. No exemplo que irei mostrar, usarei dois tipos básicos de asserção, mas se você observar, o FlexUnit possui vários tipos diferentes de asserções:

package tests
{
	import org.flexunit.Assert;
	import org.flexunit.runner.manipulation.filters.IncludeAllFilter;

	import production.BasicClass;

	public class BasicTests
	{
		public function BasicTests(){}
		private var basicClass:BasicClass;

		[Before]
		public function before():void
		{
			basicClass = new BasicClass();
		}

		[Test]
		public function Verifica_Se_As_Duas_Strings_Sao_Iguais():void
		{
			var str:String = "MinhaString";
			Assert.assertTrue(basicClass.areStringsEqual(str,"MinhaString"));
		}

		[Test]
		public function Verifica_Se_A_Soma_Retorna_Resultado_Correto():void
		{
			var soma:int = 10;
			Assert.assertEquals(soma,basicClass.somar(2,8));
		}

		[After]
		public function after():void
		{
			//codigo de after
		}

	}
}

A suíte de teste

A suíte de testes inclui nosso caso de teste descrito acima e será útil para o Flex executar nossos testes. Sendo assim, nossa suíte de testes ficaria mais ou menos desse jeito:

package tests
{
	[Suite]
	[RunWith("org.flexunit.runners.Suite")]
	public class MyTestSuite
	{
		public var baseTest:BasicTests;
		public function MyTestSuite(){}

	}
}

UITestRunner e o FlexUnitCore

O UITestRunner é um componente do FlexUnit que mostra os testes numa interface gráfica. Ele ficará na nossa aplicação e mostrará os resultados dos testes.

O FlexUnitCore será o responsável por carregar as suítes de teste e por passar os dados de saída de testes para o UITestRunner. No nosso caso, nossa aplicação principal ficaria assim:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="run()" layout="absolute" xmlns:flexUnitUIRunner="http://www.adobe.com/2009/flexUnitUIRunner">
    <mx:Script>
    <![CDATA[
       import tests.MyTestSuite;
       import org.flexunit.listeners.UIListener;
       import org.flexunit.runner.FlexUnitCore;

       public var core:FlexUnitCore;
       public function run():void
       {
           core = new FlexUnitCore();
           core.addListener(new UIListener(uiRunner));
           core.run(MyTestSuite);
      }
    ]]>
   </mx:Script>
   <flexUnitUIRunner:TestRunnerBase id="uiRunner"  width="100%" height="100%"/>
</mx:Application>

O código de produção

Ufa! Depois de escrever a classe de teste, a suíte de teste e o runner, podemos nos focar em fazer nosso código de produção :) . Dêem uma olhada em como ficaria o dito:

package production
{
	public class BasicClass
	{
		public function BasicClass(){}

		public function areStringsEqual(string1:String,string2:String):Boolean
		{
			return (string1==string2);
		}

		public function somar(valor1:int,valor2:int):int
		{
			return valor1+valor2;
		}

	}
}

E Voilà!

Depois de tudo pronto, a cara da criança ficaria mais ou menos assim:

Legal, não? E ainda dá pra fazer com que o FlexUnit4 exporte o resultado dos testes para um arquivo XML, permitindo que seus testes no Flex sejam importados pelo seu sistema de Integração Contínua, mas isso é assunto para outro post :)

Você pode baixar o código fonte aqui e ver os exemplos rodando online aqui.

Good testing!

  • Share/Bookmark
27Jan/104

DojoMoc #5 – O mais emocionante de todos

Hoje nos reunimos na Unimontes para realização de mais um Coding Dojo. No total foram quatro pessoas:

  1. Diego Caxito
  2. Elvis (não, ele não morreu :)
  3. Diego Guimarães
  4. eu

A linguagem escolhida foi o JavaScript (\o/) e usamos o QUnit como suíte de testes. Apesar de todo o esforço do setup inicial do nosso caso de teste, o pessoal gostou bastante de fazer testes usando o QUnit.

O problema

Resolvemos escolher o problema na hora (inclusive, esse foi um dos motivos pelos quais nos atrasamos). O problema escolhido foi o A Diversion, um problema simples aparentemente, mas que nos deu um pouco de trabalho, principalmente na hora de explicar.

Os testes rodaram bem no Chrome 4 e no Internet Explorer 8. Como rodou no IE8, dá até pra considerar o código à prova de balas :)

Os testes possuem uma versão online disponível aqui. Pra quem quiser baixar, o link é esse.

A emoção

Tivemos que quebrar o problema principal em 3 problemas de menor tamanho para conseguirmos resolver. A última parte consistia em fazer um conversor decimal-binário na mão! Eu até tentei sugerir pra que pegássemos um pronto na net e focássemos mais na resolução do problema, mas a galera quis ser matuta. E foi bom assim, pois deixou o problema muito mais divertido.

Além do mais, é a primeira vez que trabalhamos com uma linguagem dinâmica no DojoMoc. Espero que se torne preferência da galera trabalhar com linguagens dinâmicas, pois, na minha opinião, facilita o trabalho.

Uma coisa que deu mais emoção ainda foi ter feito tudo usando o Notepad++ sem o langs.xml estar funcionando direito. Foi a primeira vez que não usamos uma IDE :D

E pra completar: dos 5 Dojos que fizemos até hoje, nós só conseguimos resolver o problema em duas vezes. O de hoje foi uma dessas vezes. Parabéns pra galera!

Não vai dar pra postar a nossa retrospectiva aqui agora porque os post-its ficaram com o Diego Caxito, mas em breve estaremos disponibilizando mais informações sobre o nosso Dojo de hoje no blog oficial.

É isso aí pessoal, até a próxima!

  • Share/Bookmark
24Jan/100

Como voce testa seu JavaScript?

Testes unitários é um assunto muito comum hoje em dia entre desenvolvedores. Mas somente assunto, pois apenas 2% dos desenvolvedores escrevem testes. Depois de ler o post do Giovanni Bassi, eu queria saber: quanto desses 2% que escrevem testes para suas aplicações desenvolvem E escrevem testes em JavaScript?

É, acho que entrei num ponto crítico aqui. Nas minhas pesquisas sobre TDD , eu vi muita documentação para Java, .NET, Python, Ruby, PHP, Flex e Silverlight, mas é raro ver alguem falar de JavaScript. Será se são os devs que acham que JavaScript é coisa de menino ou é realmente difícil de testar apps em JS?

A dificuldade

Não há um único ambiente de testes para JavaScript. Há divergência entre os interpretadores que estão presentes em cada browser, o que nos obriga a testar em todos eles (ou pelo menos nos mais populares). IE, Firefox, Safari e Google Chrome são os mais comuns. Isso sem contar os browsers para Smartphones.

Imagine um desenvolvedor que esteja acostumado com o JUnit, NUnit, PHPUnit ou outros xUnit da vida, onde é necessário o mínimo de esforço para fazer testes. Agora imagine esse mesmo desenvolvedor abrindo 3 browsers diferentes e apertando F5 a cada vez que ele escreve um teste. Não tiro a razão de não testar JavaScript.... é simplesmente chato...

Há bibliotecas de teste que ajudam no desenvolvimento dos testes, como é o caso do js-test-driver, JSPec e JSUnit, por exemplo. Essas ferramentas têm recursos para fazer os testes rodarem em vários browsers através da linha de comando, mas todas elas possuem inconvenientes graves. O js-test-driver não suporta HTML fixtures, ou seja, se você quer testar alguma função em JavaScript que envolva manipulação do DOM, você terá que escrever o código HTML dentro do código JS. O JSUnit exige que você carregue cada caso de teste em JS dentro de um HTML. Além de ter de ficar escrevendo HTML toda hora na mão, ele não possui uma boa ferramenta de testes pela linha de comando. O JSPec parece funcionar muito bem. É o meu sonho de consumo atualmente: suporta fixtures, boa separação HTML/JS, Ajax Mocking, suporte à ferramentas de integração contínua e tem um conjunto de Shell Scripts que funcionam muito bem em um Unix. Somente em Unix.

A coisa é tão crítica que essa semana eu estava reparando isso na página do QUnit:

Quantos plugins que o jQuery tem? Vários, correto? Alguem pode explicar o porquê de somente o plugin de validação do jQuery ter testes decentes? Acho que isso ajuda a mostrar o quanto é difícil de testar JavaScript.

A solução e o futuro

Bem, no atual estado da arte das ferramentas de testes unitários de JavaScript, nós temos que nos sujeitar à uns procedimentos um tanto quanto chatos se quisermos testar nossas aplicações. Felizmente, há projetos muito ativos e muito bons que eu pude ver (js-test-driver e JSPec, principalmente) que estão avançando. Eu espero que o js-test-driver dê suporte a loading de HTML fixtures assim como o JSPec suporte plataformas Microsoft (sim, eu ainda desenvolvo em Windows) em um futuro próximo (assim como eu espero que eu cumpra a promessa de ajudar nesses projetos).

Você que está lendo esse texto já teve o mesmo tipo de experiência? O que achou? Conseguiu solucionar alguns dos problemas que eu citei aqui? Então saia do modo read-only e comente :D

  • Share/Bookmark
31Dec/095

Banindo a procrastinacao: O Manifesto do Culto ao Pronto.

Procrastinação é a arte de enrolar. É o que te faz assistir aquele episódio da sua série favorita quando você tem um trabalho chato pra fazer. Infelizmente, não há como ser imune à procrastinação.  Todos nós procrastinamos, em um nível ou outro. Esse post trata sobre O manifesto do culto ao pronto, uma série de dicas e regras simples que visam diminuir o nosso nível de procrastinação.

Pra mim, a procrastinação aparece quando falta uma coisa: disciplina. Quando nossos pais ainda mandam no nosso nariz, eles nos fazem "andar na linha". Eles cobram, brigam e castigam para termos disciplina. Depois que crescemos, essa influência paternal impondo disciplina diminui, o que nos dá mais liberdade.

Aí que está o problema: nós não sabemos lidar com a liberdade. É muito bom saber que se pode fazer o que quiser quando quiser, mas será que estaremos realmente fazendo algo? Antes nós tínhamos nossos pais. Agora é quem? Por causa disso, precisamos de algumas regras para conseguirmos aproveitar a liberdade que nos foi dada de um jeito mais produtivo. Algumas dessas regras eu encontrei no The Cult Of Done Manifesto.

Vamos ao manifesto:

  1. Há três estados do ser: não saber, ação e realização.
  2. Aceite que tudo é um rascunho. Isso ajuda a terminar.
  3. Não há estágio de edição.
  4. Fingir que você sabe o que está fazendo é quase a mesma coisa de saber o que você está fazendo. Então aceite que você sabe o que está fazendo, mesmo que não saiba, e faça.
  5. Banir a procrastinação: se você demorar mais de uma semana para ao menos iniciar algo, descarte-o.
  6. O ponto de estar pronto não é pra terminar, mas para fazer outras coisas.
  7. Uma vez que você terminou uma tarefa, você pode descarta-la (e partir para próxima).
  8. Ria da perfeição. Ela é entediante e lhe impede de terminar as coisas.
  9. Pessoas sem as mãos sujas estão erradas. Fazer algo te torna certo.
  10. Falhas contam como pronto. Então cometa erros.
  11. Destruição é uma variação de pronto.
  12. Se você tem uma idéia e a publica na Internet, isso conta como um fantasma do pronto.
  13. Pronto é o motor de mais coisas prontas.

É um manifesto simples, mas que vai direto ao ponto. Ele levou 20 minutos para ser feito, pois os autores não tinham mais tempo para faze-lo.

Espero que todos tenham um 2010 com o mínimo de procrastinação possível :)

See ya.

  • Share/Bookmark
21Dec/096

Foco e produtividade – A tecnica do Pomodoro.

O que?! Vai dizer que você caiu nessa denovo?

Quem nunca passou por uma situação parecida com essa aí de cima que jogue a primeira pedra!

1 - O problema

Esse tipo de situação acontece com muitos profissionais todos os dias. E, no meu ver, o principal problema é a liberdade. Digo, não a liberdade em si, mas o seu mau aproveitamento. Muitos de nós, profissionais de TI, não somos questionados sobre o que estamos acessando e que horas estamos acessando, desde que entreguemos tudo no prazo. Daí você já viu: hora extra, noites sem dormir e finais de semana em casa para cumprir com aquele prazo...

Várias metodologias foram criadas para sanar o problema da procrastinação. Uma delas é o famoso Getting Things Done (GTD) ou no seu título em português: A arte de fazer acontecer. O GTD tem seus pontos fortes e fracos. Dos pontos fortes, o principal é que ele fornece um "framework" para organização de vários níveis de tempo: desde de como vai ser cada hora do seu dia até planos para daqui dez anos. O ponto fraco é quase o mesmo que dá o ponto forte, pois, por ser um "framework", ele é genérico. A maioria das coisas que eu li nele são simplesmente frutos do bom senso comum.

2 - A Técnica do Pomodoro

A técnica do pomodoro é um pouco diferente. Ela é simplesmente prática, vai direto ao ponto e é bem simples: você trabalha 25 minutos, pausa 5, trabalha mais 25 e pausa mais 5 e assim por diante. Cada 25 minutos corresponde a um Pomodoro. Depois de 4 pomodoros, você pode fazer uma pausa maior (25 minutos).

Cada Pomodoro é indivisível, ou seja, você não olha seu Twitter, email, chat ou responde à sua mãe quando ela pede uma sugestão pro almoço durante estes 25 minutos. Totalmente focado no trabalho. A mágica da técnica do Pomodoro é que você sabe que você terá seus 5 minutinhos de descanso pra olhar seu Twitter, seu email, zuar o colega do lado e talvez até beber uma água (e esse tempo geralmente dá pra fazer isso tudo! Experiência própria.)

Essa explanação foi bem básica. Você pode conferir mais detalhes no livro disponível gratuitamente em PDF.

3 - Um pouco de história

A técnica foi criada por um sujeito italiano chamado Francesco Cirillo. O Francesco estava passando por maus bocados com os estudos pois ele não conseguia se concentrar nos estudos. Foi aí que ele olhou pra cima de sua geladeira, viu um Pomodoro (aqueles timers em forma de tomate que são usados na cozinha) e pensou consigo mesmo: "Será se eu consigo me concentrar só nisso durante 10 minutos?". Dito e feito. O sujeito pegou o timer, ajustou pra 10 minutos e desceu a lenha no livro. Wow! E ele conseguiu se concentrar por 10 minutos.

Vai um tomatinho aí?

O episódio descrito acima aconteceu em meados da década de 1980. De lá pra cá, ele vem experimentando diferentes timeboxes (diferentes tempos para o Pomodoro), também vem ministrando palestras e organizando workshops e chegou na conclusão que 25 minutos é o tempo que funciona bem para maioria das pessoas. Mas isso é somente um conselho, você pode colocar um timebox mais curto ou mais longo, dependendo da sua necessidade.

4 - Mãos à massa! Já!

Com o GTD você tem N desculpas para procrastinar. Com o Pomodoro não. São apenas 25 minutos, o que é que lhe custa? Teste por uma ou duas horas e veja qual foi o resultado.

Há pessoas que tem dificuldade (ou preguiça) de fazer a lista de tarefas e ainda sim utilizam a técnica do Pomodoro. Elas conseguem sucesso porque conseguem eliminar a ansiedade. Elas sabem que terão os 5 minutinhos pra fazer o que está em segundo plano e sabem que isso irá faze-las render no trabalho.

5 - Minha experiência

No início é cansativo. Os 25 minutos não parecem passar nunca e os 5 minutos são simplesmente muito curtos. Dá vontade de desistir. "Po, isso não é humano", pensei eu. Mas depois de dois dias de trabalho utilizando a técnica eu já consegui me acostumar.

Hoje eu tenho 4 meses de Pomodoro. Cinco minutos é tempo suficiente pra fazer muita coisa. De fato, 5 minutos hoje parecem mais suficiente para muita coisa. Eu tenho um nível de produtividade que eu invejável pelo Herberth de 4 ou 5 meses atrás, não sofro mais da ansiedade do email não lido ou do tweet não respondido, não tenho medo de ignorar o Google Talk (tem uma parte do livro que fala como lidar com interrupções, é bem interessante) e meu serviço rende bem mais.

O mais legal de tudo é quando as pessoas começam a sincronizar pomodoros. Além de divertido, essa forma de fazer as coisas ajuda para que você não desista.

6 - Timers para o Pomodoro

Bem, eu imagino que a maioria das pessoas que estão lendo esse post não tem um timer de cozinha. Então, há alguns programinhas legais para ajudar você a praticar a técnica do Pomodoro. Segue a lista de alguns deles:

(Essa lista pode aumentar. Comente esse post se você achar um que não está listado aqui).

Galera, acho que é isso. Bom Pomodoro pra vocês também!

P.S: Esse post foi escrito com 2 pomodoros e duas interrupções. Nesse meio tempo eu tive 14 tweets não lidos (thank you, ChromedBird), 4 emails a mais na minha caixa de entrada, duas conversas não respondidas no Google Talk e minha mãe realmente pediu uma sugestão para a janta :)

  • Share/Bookmark
7Dec/090

CodingDojo na Unimontes!

É com muito prazer que estou anunciando o nosso primeiro CodingDojo na Unimontes, sendo realizado pelo GWIB.
Mais detalhes no post do evento

Até lá!

  • Share/Bookmark