Archive for December, 2009
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!
Usando o SabreAMF com o CakePHP
O AMF é um formato aberto de comunicação do Flash. É o formato preferido para tais aplicações por possuir diversas vantagens, sendo que a principal delas é a velocidade, já que o AMF não precisa ser deserializado como o XML e o JSON.
Por ser um formato aberto, ele pode ser implementado em qualquer linguagem. Há várias implementações para o PHP, sendo que as mais notáveis são o AMFPHP, Zend_AMF e o SabreAMF.
Neste tutorial, eu mostrarei como desenvolver aplicações em PHP com o framework CakePHP que se comunicam com o Flash (usando a plataforma Flex 3) através da biblioteca SabreAMF.
1- Baixando e instalando os componentes
1 – Baixe os CakePHP 1.2.5 no site do CakePHP e o SabreAMF no Google Code.
2- Instale o CakePHP de forma que ele fique disponível em http://localhost/cakeflex.
3 – Descompacte o SabreAmf em app/vendors/SabreAMF
2 – Colocando os dois para trabalhar
Para fazer com que o CakePHP trabalhe de forma transparente com o SabreAMF, é necessário criar um componente para o CakePHP.
Para tal, vamos criar o nosso componente: (salve-o em app/controllers/components/sabre_amf.php)
set_include_path(APP.'vendors' . PATH_SEPARATOR . get_include_path());
App::import('Vendor', 'SabreAMF_CallbackServer', array('file'=>'SabreAMF/CallbackServer.php'));
class SabreAmfComponent extends Object {
function startup(&$controller) {
if ($controller->action == 'gateway') {
global $_cakeController;
$_cakeController = $controller;
Configure::write('debug', 0);
$controller->autoRender = false;
$server = new SabreAMF_CallbackServer();
$server->onInvokeService = array($this,'amfCallBack');
$server->exec();
exit;
}
else if(empty($controller->amfExclude) ||
!in_array($controller->action,$controller->amfExclude))
exit();
}
function amfCallBack($service, $method, $data) {
global $_cakeController;
$res = null;
if ($_cakeController) {
if (strpos($method, "_") !== 0) {
if (method_exists($_cakeController, $method) and
!in_array($_cakeController->action,$_cakeController->amfExclude))
$res = call_user_func_array( array( $_cakeController, $method ), $data );
else
$res = "Action nao encontrada.";
} else
$res = "Nome de metodo invalido.";
}
else
$res = "Controller nao encontrado.";
return $res;
}
}
?>
O que nós fizemos acima foi redirecionar todas as chamadas à action ‘gateway’ do controller para nosso gateway do SabreAMF.
Agora, um exemplo de como utilizar isso em um controller:
Nosso server side não estaria completo sem o nosso model. No meu caso, como é só uma demonstração, eu não quero criar uma tabela no banco de dados. Portanto, eu crio o meu model dessa forma:
// app/models/teste_amf.php
class TesteAmf extends AppModel
{
var $useTable = false;
}
?>
Para demonstrar nosso código funcionado, nada melhor que uma aplicação Flex. Segue abaixo, um exemplo de como a configuração criada acima pode ser usada no Flex:
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:RemoteObject
endpoint="http://localhost/cakeflex/teste_amf/gateway"
id="rmoTeste"
source=""
destination="minhaApp"
result="rmoTesteResult(event)"
fault="rmoTesteFail(event)"
showBusyCursor="true"
/>
<mx:Button label="Hello!" click="rmoTeste.hello('Herberth')" />
<mx:Script>
< ![CDATA[
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.controls.Alert;
public function rmoTesteResult(e:ResultEvent):void
{
Alert.show(e.result.toString());
}
public function rmoTesteFail(e:FaultEvent):void
{
Alert.show("Fail!");
}
]]>
</mx:Script>
</mx:Application>
4 – Conclusão
O resultado final deve ficar parecido com isso:
É possível retornar tipos mais complexos para serem usados em tipos mais complexos (tipo AdvancedDataGrid), mas irei abordar tal aplicação mais futuramente.
5 – Referências
É isso aí pessoal. Até a próxima!
“A gente nao quer so codigo… a gente quer codigo, controle de versao e bug track”
Tá certo. A paródia da música dos Titãs não ficou boa. Mas acho que já deu pra sacar do que este post trata.
Enfrentar as matérias de programação na faculdade para quem já trabalha com desenvolvimento deve ser um saco para muita gente. Os professores geralmente não trabalham na área, não sacam nada além da linguagem e ainda tem coragem de nos fazer de trouxa, explicando como é a sintaxe da linguagem, como fazer algumas coisas básicas (leia-se CRUD) e acham que está tudo ok. Não está. Óbvio que não. Então, eu tenho algumas coisas a dizer para tais professores (e para os alunos também).
1 – Ensinar algumas coisas sobre a sintaxe e mostrar um CRUD não é o suficiente.
Precisamos mais além disso para desenvolver um trabalho final decente. Nós, alunos, precisamos aprender a nos virar, mas precisamos saber com o que devemos nos virar. Coisas básicas como indentação de código deveria ser cobrada. Separation of Concerns deveria ser incentivado e cobrado desde o início, por exemplo.
Não serei injusto. Algumas coisas como “comente seu código para documenta-lo” nos é ensinada. Isso é importante para quem está começando, pois saber se orientar dentro do próprio código é uma boa. Mas é algo insuficiente. Eles não ensinam como código pode ser autodocumentado, como bons nomes de variáveis podem ajudar nisso, como codificar “de cima para baixo” e outras coisas relacionadas a codificação.
2 – Nos passar trabalhos em grupo não necessariamente nos ensina a trabalhar como uma equipe.
Há vários trabalhos finais para fazermos e a forma mais fácil de fazer isso é deixar um para cada um. Dá pra eliminar vários problemas de comunicação e sincronização de código assim. Acho que já deu pra perceber que não aprendemos muito sobre ferramentas para desenvolvimento em equipe…
Quem for tentar desenvolver em equipe, provavelmente o fará enviando código por email, trocando pen-drives ou enviando via compartilhamento de arquivos, se tiver na mesma rede (impressionante, mas já vi “profissionais” trabalhando assim) e notarão o trabalho que isso dá. Obviamente, dá pra notar que não tivemos uma aula sobre controles de versão…
3 – O trabalho não acaba com a entrega…
Quem trabalha com desenvolvimento de software há um tempo sabe do que eu estou falando. De acordo com esse paper, mais de 90% dos custos de um software estão na sua manutenção. Vendo por esse lado, não estamos fazendo nem 10% do trabalho que deveríamos fazer.
Várias práticas de programação importantes são feitas durante a manutenção. Uma delas é a adição/mudança de recursos. Se fizéssemos isso, perceberíamos que coisas como refatoração e testes unitários são importantes.
4 – Metodologias são sempre bem vindas
Uma das dúvidas de quem começa a desenvolver é: como devo proceder, qual metodologia adotar. Um professor tem que ser um guia para um aluno escolher um método de trabalho. Praxis? XP? Scrum? PDCA? Sair fazendo na doida não é das melhores escolhas
Na matéria de Engenharia de Software, nós temos uma visão teórica de cada uma dessas metodologias. Uma matéria de programação com um projeto pra entregar poderia ser um cenário perfeito para coloca-las em prática.
5 – Conclusão
Matérias como essa são muito desperdiçadas na nossa universidade. E eu imagino que seja em outras também. Se você é professor, comece a pensar nisso e pense em como você pode ajudar a mudar o quadro aqui exposto. Se você é aluno, cobre isso do seu professor. Ou pelo menos tenha a boa vontade de estudar sozinho
