Indicação screencast Fabio Akita

Post rapido apenas para recomendar fortemente o screencast do Fabio Akita, Entenda software da maneira correta.

Pra quem não sabe o Fabio Akita é um grande agitador da comunidade Ruby no Brasil. Mas nesse screencast específicamente ele não fala de nenhuma linguagem em específico. Apenas de conceitos gerais que devem ser levado em conta no desenvolvimento de software. Cita também muitos erros comuns de alguns projetos.

Além de falar sobre os conceitos de reuso. Que achei muito interessante, também achei muito boa a abordagem das diferenças, que nem sempre acontecem é claro, do desevolvimento de um software proprietário para o software livre. E principalmente o modelo de organização do SL, que numa primeira vista parece ser absolutamente caótico. Mas que olhando melhor, na verdade propicia o desenvolvimento de software bom, com foco em reuso, manutenção e etc.

Enfim, não vou me alongar demais, mas vale muito a pena. O preço é super em conta R$4,99. Segue o link novamente http://www.akitaonrails.com.br/2010/07/01/screencast-entenda-software-da-maneira-correta

Indicação de videocasts do UncleBob

Claro que o Uncle Bob Martin não precisa de nenhuma recomendação minha para nada que ele venha a fazer.

Vou indicar primeiro que se você não o segue no twitter. Siga já, @unclebobmartin. Ele é daqueles que os programadores tem que deixar ali na lista de leitura obrigatória.

Mas enfim, o que estou indicando aqui são os videocasts, na verdade code-casts, que ele chama de Clean Code.

Sai baratinho, $12,00 no segundo e terceiro episódio. E apenas $1,00 no primeiro.

Ou seja, se você ta meio desconfiado se vale a pena ou não. Pegue o primeiro episódio que é super barato.

O mais interessante, que ele apenas falando, sem mostrar uma linha de código, consegue realmente te convencer que você deve manter seu código limpo.

Além disso também, com poucas descrições de falhas comuns, você já consegue perceber certas fraquezas no seu modo de programar e talvez pensar em uma abordagem melhor.

Enfim, fica minha recomendação, seguir o @unclebobmartin e comprar e assistir os code-casts cleancode.

Ah! uma ultima coisa. O filme é editado num esquema chapolin colorado. Que dá um ar meio antigo, vintage, final de 70′ começo de 80′. Usa um fundo verde em algumas cenas, daquele bem tosco, cortando pedaço do objeto na mão. Mas isso dá um toque especial. Pelo menos de engraçado.

Como aliar BDD/TDD a técnicas como GTD e pomodoro

Depois de ler o livro The RSpec book, principalmente sua base de conceitos de como fazer ciclos pequenos de programação e tentar na prática aplicar alguns métodos que são explicados no livro. Enxerguei a possibilidade de aliar esses métodos a técnicas de gestão de tempo e tarefas, como GTD (Getting Things Done) e pomodoro.

Meu objetivo não é fazer nenhum guia definitivo. Mas sim, explicar como eu consegui colocar esses dois métodos em prática, pra assim reduzir incrivelmente minha procrastinação nos períodos de sujar a mão no código.

Primeira coisa, para programar seguindo TDD, você vai quebrar sua programação em pequenos ciclos, o que já facilita a identificação das tarefas a serem seguidas. Ao quebrar em por exemplo um ciclo semanal de uma feature nova do seu sistema, você em seguida vai começar a identificar esses passos a serem tomados para conseguir finalmente implementar essa nova aplicação.

Nesse ponto entra um bom software GTD, no meu caso o Things da Cultured Code, nesse posts apps GTD para mac, eu explico um pouco o porquê da minha preferência pelo Things.

Voltando, ao quebrar seu desenvolvimento em pequenos ciclos, o que eu tenho feito é o seguinte: criar um projeto que seria por exemplo meu ciclo semanal, para aquela determinada aplicação. Dentro desse projeto, literalmente destrinchar o processo de criação do código, em todos os ciclos que eu imagino que serão necessários para completar o projeto. É claro que nunca da exatamente certo, sempre vai faltar ou sobrar algum ciclo que esqueceu. Mas isso já da uma boa base, para pensar no todo do projeto e até perceber bem inicialmente se existe alguma falha na sua trilha.

Depois disso que entra o pomodoro technique. Que é básicamente, dividir todo o seu trabalho em pomodoros, que são, pequenos ciclos de 25 minutos de trabalho e 5 minutos de descanso. Com intervalos  maiores de 30 minutos a cada 4 pomodoros. Já da pra sentir uma semelhança com o conceito de BDD/TDD por aí.

A partir do momento em que eu já tenho um plano a seguir do desenvolvimento da minha aplicação. Eu atribuo estimativa de pomodoros no meu plano GTD, de quanto cada um daqueles ciclos de cucumber examples, RSpec Red/Green/Refactor vão levar. Por exemplo eu tenho 2 ciclos, bastante simples, que provavelmente vão levar 25 minutos para serem concluídos, junto esses 2 em 1 tarefa no GTD. Depois vem um ciclo médio, que vai levar mais ou menos 2 horas de programação dedicada, então atribuo a ele 4 pomodoros. Depois tenho um ciclo realmente penoso, que levará 12 pomodoros para ser concluído. Então eu já vejo um pequeno problema por aí. Que provavelmente eu posso dividir isso em 2 ou 3 tarefas. Que deixará mais documentado em termos de tdd, mais organizado no gtd e mais efetivo com o pomodoro.

Depois de algumas semanas aliando essas técnicas, percebi uma melhora muito grande na minha procrastinação. Se eu quero ver o twitter, ou meus feeds, vou fazê-lo nos meus intervalos, e não enquanto programo. Isso parece banal, mas ter pequenos objetivos durante seu dia de trabalho, ajuda e muito na produtividade.

Também consegui perceber que usando essas técnicas, tenho uma noção melhor de quanto tempo leva cada passo de programação o que leva a uma ótima consequencia, que é a maior facilidade de precificar e analizar se um produto ou uma feature vale a pena. Usando os examples de cucumber, e colocando realmente o valor que aquele código trará pra minha aplicação. Em embate com o tempo que ele levará a ser completado.

Enfim, acho que vale a pena para quem não conhece, dar uma olhada nesses modelos de trabalho. Mesmo que não sejam os ideais para você.

The RSpec Book uma excelente leitura sobre BDD e TDD

A duas semanas atrás participei do Ruby Masters Conf. E um dos palestrantes foi o David Chelimsky que é o principal desenvolvedor e mantenedor do RSpec desde 2006.

Até a sua palestra eu não tinha certeza quanto as reais vantagens de programar usando BDD e TDD, pra ser sincero, muitas vezes, achava uma grande perda de tempo, já que você acaba programando o triplo de código do normal, quebra sua programação em diversos micro processos. Além disso, eu também nunca tinha entendido o motivo de tanta febre de refactoring.

Depois da excelente palestra ministrada por ele. Tive uma luz conceitual. Mais ou menos assim. Opa, espera um pouco, não é o método que é ruim, muito pelo contrário, sou eu que nunca peguei o espírito da programação orientada a comportamento e testes.

Mas enfim, depois de sua palestra, ele indicou o seu próprio livro, The RSpec Book. Que é escrito por David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp e Dan North.

Resolvi comprar o livro pra pelo menos conhecer um pouco mais a fundo essa metodologia de programação e desenvolvimento de software.

E além do livro tratar de aspectos teóricos, de um novo tipo de abordagem em que todas as partes interessadas no software devem se comunicar de uma forma diferente. Até aspectos bem técnicos de Cucumber e RSpec.

Além do livro, tratar muito de comunicação. Comunicação de código. Ou algo do tipo: como todos os envolvidos nesse projeto, desde de quem pague a conta, até quem faz os algoritmos mais malucos, podem falar entre si nesses testes, pra que todo mundo se entenda. E o resultado final, seja o melhor possível.

Por fim, o livro deixa bem claro que não é um livro sobre ruby, apesar de tanto o Cucumber, quanto o RSpec, serem nativos do Ruby, eles poderiam rodar em outras plataformas também. Mas é um livro sobre habilidade de programação. E realmente, ele tem aspectos técnicos e bastante específicos e informativos para o RSpec e Cucumber que por serem nativos para a linguagem Ruby, naturalmente são mais facilmente absorvidos e colocados em prática pelos rubystas. Porém a maior riqueza do livro está nos conceitos propostos e apresentados sobre essa nova forma de pensar um software. E quebrar paradigmas tradicionais muitas vezes enraizados e que nem sempre são a melhor abordagem para você ou sua empresa.

Enfim, o livro é muito bom, altamente recomendado. A versão de papel vendida no Brasil está muito cara, se for comprar em papel vale mais a pena comprar pela Amazon.

Mas eu recomendo mesmo comprar via Pragmatic Bookshelf a versão em PDF, MOBI e EPUB, sem DRM como já é de costume da PraProg. E caso você seja um apreciador do livro de papel. Compre a versão impressa no bundle, que sai o mesmo preço da versão apenas impressa aqui no Brasil.

Descobri que não sou só eu que xingo nos commits

Eu sempre soube que eu não era o único que xingava o código nos commits.

Mas eu também achava que eu fazia parte de uma minoria pequena, que fica com raiva dos tapas na cara que a programação te dá. E na hora de fazer o commit soltava o verbo.

Mas agora descobri, que não sou tão esquisito assim, segundo esse post do tecnoblog. Um desocupado, montou um código para contabilizar os xingamentos em commits no GitHub.

E a linguagem que mais gera palavrões é o C++, a segunda é Ruby e a terceira Javascript. :P Mais uma inutilidade que a internet nos proporciona.

 

Dica de livro pra iniciantes em python

Normalmente eu sou bastante crítico com as publicações técnicas traduzidas. Mesmo com alguns bom trabalhos, a Novatec por exemplo, tem muitos escorregões e vacilos, muitas vezes numa obrigação desnecessária de traduzir tudo e mais um pouco para o português, muitas vezes sem necessidade.

Mesmo assim, eu gosto muito das publicações feitas em português, por nativos do portugues.

E nesse caso, um livro completamente voltado para iniciantes. Não apenas iniciantes em Python, mas iniciantes em qualquer linguagem.

O nome do livro é, Introdução à programação com Python – Algoritmos e lógica de programação para iniciantes. O autor: Nilo Ney Coutinho Menezes. Editora: novatec.

Eu sou um completo 0 a esquerda com python. Mas já tinha experiência com outras linguagem. Pelo que o próprio autor descreve, logo no primeiro capítulo, talvez não fosse o livro ideal para mim. Mas mesmo assim, eu gostei muito principalmente do método que o autor aborda suas explicações.

Se não me engano no segundo capítulo ele passa em 2 páginas. Uma aula sobre sistema numérico decimal e binário. Muito melhor do que já tive com N professores.

Enfim, vale a pena o livro, além de prestigiar os autores nacionais, o livro é super recente, de novembro de 2010. Isso é uma grande vantagem, porque livro nacional técnico, tem uma tendência de tudo que está na prateleira, ser do século passado.

 

Iniciando no Ruby On Rails

A algum tempo eu tenho vontade de aprender uma nova linguagem de programação, mais especificamente Ruby On Rails.

Antes das pedras, eu sei que RoR não é linguagem, é framework.

Mas depois de conhecer o cakephp, que é bastante similar ao Rails, no modo de desenvolver, eu fiquei mais interessado ainda. Não para abandonar o PHP e partir pro Ruby, mas para conhecer novas “coisas”.

Depois de ler alguns tutoriais de inicio. Eu encontrei esse Rails Tutorial. Que a partir de agora para mim, é o livro de RoR definitivo para quem está começando.

Pra começar a iniciativa do autor Michael Hartl é fantática, ele desenvolveu um tutorial com mais ou menos 500 páginas, está vendendo em pdf, e os screencasts dele desenvolvendo. Porém, ele deixou o livro aberto a todos.

Eu provalvelmente não compraria, por não conhecer o autor e sem grandes recomendações. Mas como ele deixou aberto, eu não só gostei, como estou recomendando, como eu também comprei, não só o livro. Mas todos os screencasts que ele faz.

Enfim, quem estiver interessado, vale a pena pelo menos dar uma conferida no livro aberto do site.

E vale também pelo, autores, músicos, cineastas, aprendam, muitas vezes deixar “aberto” é o melhor, mas isso só vale se você confiar na sua obra. O problema é esse né. :)

Instalar Apache Php e Mysql no Snow Leopard

Tem muita gente que quer inventar moda e até mesmo complicar o que é simples. O Snow Leopard, já vem com boa parte do caminho instalado, quando falamos de php apache e mysql, só precisamos mesmo configurar e instalar o mysql.

Continuar lendo

Algumas considerações sobre Debuggers

Ultimamente venho passando por alguns problemas com relação ao tão popular Xdebug, principalmente em ambiente linux. Simplesmente configuro tudo certo pelo menos ao meu ver.

Então em função disso, acabei “desistindo” de usá-lo pelo menos por enquanto, ou pelo menos até encontrar alguém pra me abrir uma luz no caminho sobre o que eu estou fazendo de errado =P .

Mas desenvolver sem um debugger apropriado. É praticamente impossível, porque como diria o pessoal do www.phpsp.org.br var_dump() não é DEBUG.

Mas nem só de xdebug vive o mundo, a Zend tem o zend debugger, que eu não sou um especialista, então não sei exatamente as features dele, e a diferença com relação ao xdebug. O que sei é que funciona muito bem, mas tem um porém, como sempre. O netbeans, minha IDE favorita não funciona com o zend debugger, pelo menos isso que vi em tudo quanto é fórum por ai. Se alguma alma caridosa puder me dizer o contrário ficarei muito feliz. Quem quiser saber como instalar o Zend Debugger vá neste link aqui.

Ainda sobre os debuggers, o xdebug tem alguns tratamentos de erro na tela, e uma melhora do var_dump(), que aparentemente são melhores que o zend, porém, eu tive que ponderar nesse caso e decidir a favor do zend, pelo bem da IDE, e pelo que vi é incompatível os 2 debuggers estarem instalados ao mesmo tempo, coisa que ainda não me certifiquei com certeza, preciso ir um pouco mais atras.

Mas enfim, com esse problema, tive que migrar de IDE, e lá fui eu para avaliação novamente, entre quais seriam as mais apropriadas, já descartei de cara, Zend Studio, só por uma coisa, preço, tal qual o komodo IDE, que já ouvi falar muito bem, porém nesse momento não estou com disponibilidade financeira para tal.
Próximo passo, eclipse e aptana. Testei primeiro o Aptana. E com isso eu descobri porque não gosto dele. Propaganda na IDE, e o pior não é propaganda para uma IDE premium ou qualquer coisa do gênero, é propaganda do Dreamweaver. Ah! Parou por ai. Até porque Aptana e Eclipse, são praticamente a mesma coisa, pois o aptana também é baseado em eclipse, tal qual o zend studio.

Então fui de eclipse, que sempre tive alguns probleminhas pra adicionar o xdebug com ele, porém como já disse anteriormente, estou dando um tempo com o xdebug e usando o zend. Foi fácilimo de configurar e tudo rodando na mais perfeita ordem. Alguns softwares adicionais como a integração direta com o subversion e tal. E maravilha.