Flex For Kids foi 10!
Depois de um dia inteiro de correria, muita palestra e principalmente comida, estou aqui para contar um pouco do Flex For Kids para vocês.
Infelizmente, perdemos uma palestra que parecia ser bem legal: Desenvolvimento Multi-touch com AIR 2.0. Tivemos problemas com a conexão e iniciamos meio atrasados. Bem que a porta de saída poderia ser a 80 mesmo... evitaria muitos problemas.
Conseguimos pegar a palestra do Igor Musardo (Construa painéis administrativos em Flex integrados com ASP.NET MVC) bem no início, quando ele começou a falar sobre ASP.NET MVC e Flex. Ele mostrou um pequeno sistema para gerenciamento de conteúdo usando o Flex 3 e o ASP.NET MVC como backend e usou o JSON como formato de comunicação. A maioria dos presentes não tinha familiaridade com .NET, mas serviu pra mostrar um pouco da tecnologia. Bem interessante a palestra, mas eu fiquei curioso com o fato dele não usar AMF para isso. Devido à alguns problemas técnicos com a transmissão, a palestra do Musardo acabou atrasando um pouco, mas nada grave.
A palestra a seguir foi a do Mário Junior: Swiz Framework: MVC Simples e Poderoso para projetos Flex/AIR. Como o Mario mesmo disse, o Swiz é extremamente simples e leve, no entanto a palestra dele serviu para mostrar como eu subutilizo os recursos que o Swiz oferece. Ele é muito mais poderoso que eu pensava. Valeu muito pra mim e pra galera da Infobits. Muito boa a palestra dele.
Como eu estava na organização e nós tínhamos que trazer o almoço para a Unimontes, eu acabei perdendo a palestra do Eberton Consolim: Flex e VOIP: Adicione essa tecnologia em suas aplicações. Segundo a galera que assistiu, a palestra foi excelente, mas infelizmente terei que aguardar o acesso às gravações para ter certeza 
A próxima palestra logo após o almoço foi a do Daniel Lopes: Desktop com HTML, Javascript e Adobe AIR. A palestra foi muito bem ministrada: muito conceito, muita idéia e pouca explicação de código e ele incrivelmente conseguiu fazer um hands-on sem muitas delongas. Incrível. Excelente palestra.
A palestra da Gabriela teria sido mais interessante se eu entendesse um pouco mais de User eXperience. No entanto, foi bom ter uma palestra no-code no meio de tantas. Aliás, foi bom ter visto uma mulher no meio de tanto marmanjo . Mesmo assim, foi proveitosa.
O Eric Calvancanti assumiu a missão de desmistificar o Cairngorm. E posso dizer que ele o fez com muito sucesso! Segundo o Vedovelli, até a avó dele entenderia o que o Eric quis passar. Foi a apresentação mais didática que tivemos, apesar do Cairngorm ser o framework mais complexo apresentado hoje.
A palestra do Vedovelli foi uma das mais esperadas. Muito conhecido pelos seus screencasts e sua irreverência, o Ved, como costuma ser chamado, se tornou um dos ícones dos Flexers nacionais. Ele explicou como funciona a arquitetura de uma aplicação usando o framework Mate. O framework é interessante e comparável em muitos pontos com o Swiz. Muito boa apresentação.
O "vírus da bactéria" que o cachorro do Igor Costa não consegue ver deixou a sua apresentação muito divertida, além de informativa! O Igor é uma das maiores referencias em Flex e Java no Brasil e sua palestra foi memorável. Eu não saco muita coisa de JEE, mas a palestra dele foi bem inteligível.
E por último e com a melhor palestra do dia, a do Beck Novaes. Ele deu uma geral sobre a plataforma Adobe de desenvolvimento de RIAs: Flash, Flex, Flash Builder e Flash Catalyst. A palestra foi incrível. Ele tem um mix de explicação extremamente fácil de entender com informação útil. Deveria ter sido a primeira palestra do dia, com toda certeza.
Nossa reunião na Unimontes teve uma audiência de 15 pessoas e contou com a organização e apoio da Infobits e da Gerência de Tecnologia da Informação da Unimontes. Queria agradecer a todos que vieram e prestigiaram o evento. Também gostaria de dar os parabéns a todos que tiraram o escorpião do bolso e doaram para o Cotolengo. Muito bacana! A seguir, as fotos do evento:
Eu vou participar do Flex For Kids. E voce?
Como eu bloguei em outro blog anteriormente, eu vou participar do Flex For Kids!
Basicamente, o evento é praticamente uma maratona de palestras: nove palestras de uma hora cada em exatamente nove horas de duração, de 8:00 às 17:00, e contará com palestrantes da comunidade Flexer Brasiliera.
Todo dinheiro arrecadado com as inscrições será destinado à Cotolengo, uma instituição do Mato Grosso do Sul que acolhe pessoas com necessidades especiais.
Nós, da Infobits, conseguimos reservar o auditório do Centro de Ciências Exatas e Tecnológicas para acomodar os participantes do evento, estamos organizando algumas outras coisas (como o almoço, a alimentação no resto do dia e a inscrição no evento) e temos 8 pessoas já confirmadas (o número vai subir até amanhã).
Só lembrando: se você quer participar do Flex For Kids conosco, ainda tem tempo! Nos procure na Infobits*, mande email, sinal de fumaça ou comente esse post
*Sala 10A do Centro de Ciências Exatas e Tecnológicas. Perdido? Veja no Google Maps.
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!
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:
- Diego Caxito
- Elvis (não, ele não morreu
- Diego Guimarães
- 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 
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!
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
DojoMoc #4 – Se voce não foi, voce perdeu!
Hoje tivemos na Unimontes a quarta edição do nosso Coding Dojo. Geralmente postamos o resultado do dojo no nosso blog, mas esse foi tão bom que merece um espacinho aqui também (despistem se notaram a falta de post nos últimos dias).
Foi o primeiro dojo que conseguimos resolver o problema e foi o primeiro que terminamos no bar:
Cerveja "Python Powered"!
A multidão indo ao delírio vendo os testes passarem.
Yes, we Créu!
E onde o público feminino também programa e bebe com os outros 66% do público
cd pub && more beer
As fotos do dojo podem ser baixadas aqui. [mais tarde eu posto o código =]
Espero ver vocês no proximo Dojo. Até mais, pessoal!
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:
- Há três estados do ser: não saber, ação e realização.
- Aceite que tudo é um rascunho. Isso ajuda a terminar.
- Não há estágio de edição.
- 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.
- Banir a procrastinação: se você demorar mais de uma semana para ao menos iniciar algo, descarte-o.
- O ponto de estar pronto não é pra terminar, mas para fazer outras coisas.
- Uma vez que você terminou uma tarefa, você pode descarta-la (e partir para próxima).
- Ria da perfeição. Ela é entediante e lhe impede de terminar as coisas.
- Pessoas sem as mãos sujas estão erradas. Fazer algo te torna certo.
- Falhas contam como pronto. Então cometa erros.
- Destruição é uma variação de pronto.
- Se você tem uma idéia e a publica na Internet, isso conta como um fantasma do pronto.
- 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.
Boas Festas!
Galera, aí vai meu voto de boas festas:
lol
Brincadeiras a parte, espero que todos nós tenhamos um 2010 melhor que o 2009. Boas festas
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
Ano novo, coisas novas pra aprender.
Esse ano foi o melhor da minha vida em questões profissionais e de conhecimento. Desses 6 anos que eu me interesso por TI, esse foi o que eu mais aprendi e o que mais me agregou experiência. Vou começar com uma retrospectiva antes de passar para o planejamento:
1 - Retrospectiva
A Infobits, juntamente com seu Grupo de Web, me deu experiência mais gerencial, mesmo coordenando poucas pessoas. Eu era e ainda sou um cara muito técnico e participar de um projeto como esse, em que eu tinha que coordenar e orientar pessoas, me ajudou a ver o outro lado da moeda. Sair do nível técnico para o gerencial é complicado. Ainda bem que eu tenho uma equipe pequena agora: menos gente, menos preocupação, mais comunicação, mais ágil.
Ter sido demitido foi uma das experiências mais marcantes que tive. Mexeu com meu ego (que por sinal não é pequeno) e eu me focei a ver o que eu tinha feito de tão errado pra ter merecido isso, já que boa parte da justificativa do meu ex-chefe não fazia sentido pra mim. A retrospectiva de um ano de empresa foi uma coisa tão foderosa, que eu atribuo mais de 80% do meu conhecimento adquirido neste ano às coisas que eu aprendi nesse processo. Até brinquei com um amigo esses dias, dizendo que se eu soubesse o quanto isso te faz evoluir, eu procuraria ser demitido mais vezes. Por exemplo, eu não teria tido o interesse ou a iniciativa de ter ajudado a iniciar o nosso Coding Dojo se não tivesse sido demitido.
Vendo pelo lado acadêmico, esse ano também foi o mais produtivo: eu apresentei e publiquei 6 trabalhos e pretendo seguir o ritmo no ano que vem, mas mais voltado pra minha linha de pesquisa (Recuperação de Informação).
Quase ia me esquecendo do Coding Dojo: apesar de termos somente duas reuniões até agora, eu tou colocando muita fé nele.
2 - Para o próximo ano
Enfim, foi um ano cheio e eu estou prevendo que o próximo ano não será muito diferente, pois será o ano que eu irei me graduar. Daí vocês já tiram: monografia "comendo solta" o ano inteiro
Seguindo o conselho dos Pragmatic Programmers de aprender ao menos uma linguagem por ano, eu vou escolher as minhas aqui agora:
Lua é uma linguagem de programação brasileira que tem atraído muita gente no exterior, mas é pouco conhecida/valorizada aqui no Brasil. Pelo que eu pude ver, Lua é uma linguagem de altíssimo nível, bonita, elegante e que pode me ensinar alguma coisa valiosa. Outro motivo por escolher Lua é minha vontade de aprender mais sobre programação funcional. Isso me passa para a próxima linguagem:
Pra mim, Scala começou a ganhar atenção quando o Twitter começou a substituir Ruby por Scala no seu backend. Mas não é somente por isso que eu escolhi Scala em detrimento de Haskell, Erlang, Scheme ou Lisp. Eu realmente queria aprender todas elas, mas acho que Scala pode ser um bom começo. O objetivo é aprender programação funcional, certo? 
Esse ano eu comecei a aprender Ruby para apresentar um trabalho. A linguagem é legal, mas eu ainda estou longe de ser um cara competente em Ruby. Por isso, Ruby vai ser uma das linguagens que irei aprender no próximo ano. Ruby é bastante usada em alguns Coding Dojos do mundo todo e por isso vai ser legal usar Ruby no DojoMoc.
3 - Além de programação
Eu ainda pretendo continuar com meus estudos sobre desenvolvimento ágil, voltado principalmente para técnicas de desenvolvimento (pair programming e TDD, principalmente), automatização de tarefas de produção de software, produtividade e arquitetura de software.
No meio acadêmico, eu pretendo procurar aplicar tudo isso aí em cima no processo de desenvolvimento do produto que será minha monografia (fazer um crawler de pequena/média escala não é tarefa fácil...). Pretendo também continuar publicando pra ver se em 2011 eu já entre em algum programa de mestrado, mesmo como aluno especial.
Ultimamente eu tenho pensado muito em desenvolvimento OpenSource. Ontem mesmo eu fiz um hack para a lib de autocomplete do jQuery para substituir a YUI numa página que eu estou mexendo no trabalho e pretendo tirar as gambiarras melhora-lo para disponibilizar pra galera. É coisa pequena, mas é um começo
Agora é esperar 2011 chegar e ver se eu consigo cumprir pelo menos a metade disso aí 
4 - Livros
Ganhei alguns livros no meu aniversário e tenho outros encostados. São eles:
- O Silmarillion - J.R.R Tolkien
- O Caçador de Andróides - Philip Dick
- As Crônicas de Nárnia - C.S Lewis
- Eragon - Christopher Paolini
Há alguns outros que eu não tenho que eu quero ler:
- Blue Ocean Strategy, uma sugestão do Fábio Akita.
- The art of Unit Testing - Osherove Roy
- Clean Code: A Handbook of Agile Software Craftsmanship - Uncle Bob.
- The Art of Agile Development - James Shore
- Agile Estimating and Planning - Mike Cohn
Esses são os maiores títulos. Não sei se consigo dar conta de ler todos eles com uma monografia a fazer, mas não custa tentar
Até mais!
Páginas
Categorias
- agile (6)
- coding dojo (2)
- Flex & Actionscript (4)
- JavaScript (2)
- Misc (4)
- News (3)
- palestras (1)
- PHP (1)
- Python (2)
- tdd (4)
Últimos Posts
- Flex For Kids foi 10!
- Eu vou participar do Flex For Kids. E voce?
- Testes unitarios no Flex usando o FlexUnit 4
- DojoMoc #5 – O mais emocionante de todos
- Como voce testa seu JavaScript?
- Steve Jobs vai se lascar com o #iPad!? http://migre.me/jlqL
- Productivity in lines of code per day increased 10%.Defect levels decreased by 26%.Use multiple monitors for coding! http://migre.me/jl4x
- Version 1 sucks, but ship it anyway! http://www.codinghorror.com/blog/archives/001313.html
- "Be lazy: nothing is faster than doing nothig" http://migre.me/jc6R
- Scalable JavaScript Application Architecture http://migre.me/jbRF //interessante, mas eu ainda prefiro AS3
- Powered byWordPress Twitter Widget Pro
Comentários
- Joicy on Flex For Kids foi 10!
- edgarddavidson on Flex For Kids foi 10!
- Beck Novaes on Flex For Kids foi 10!
- herberthamaral on Flex For Kids foi 10!
- uberVU - social comments on Flex For Kids foi 10!
Arquivo
- February 2010 (2)
- January 2010 (4)
- December 2009 (7)
- November 2009 (3)
Tag Cloud
agile ano novo cakephp coding dojo computação científica controle de versão dojomoc flex flex builder flex for kids flexunit 4 hello world infobits integração contínua integração contíunua JavaScript lua nerdson new opengl opensource palestras pdca PHP pomodoro produtividade Python ruby sabreamf scala scrum tdd tutorial unimontes xp
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.