Over the past month or so I've been learning Odin and I'm enjoying it so much that I'm breaking the silence on the blog.

I haven't written much on the blog on the last few years, I don't know, I didn't felt like I had much to say. There is so much being said on the Web, lots of great stuff, but also tons of crap too, and I didn't feel like adding to the noise. I've learned loads of stuff, but not in the mood for sharing, and anyway the most important stuff wasn't related to tech.

Faz pouco mais de um ano que estou morando na França, e ainda estou descobrindo onde encontrar bom conteúdo francófono na internet.

^{Trying to ship the old blog post drafts}

When I arrived at Cleveland's airport a few weeks ago to attend Pycon, the customs agent didn't know that there was a tech conference happening in town. I'm sure many other people knew something was going on, because I was welcomed by a screen just after she checked my documents and let me in. It was a nice gesture, and it surely put a smile on my tired sleepy face!

I've been wanting to write since a little while but whenever I sit to write a post I end up on an endless yak-shaving of making small adjustments to the blog. I know that if I wanted to optimize my blogging flow for writing I should start using something like Medium, or maybe even go back to good-ol' Wordpress.

Ever since I started using the awesome pudb debugger for Python programs I've been curious about the urwid library, an user interface library for console-based applications that the debugger uses. The examples in the gallery are just gorgeous!

Some days ago I read this nice article talking about co-routines as an alternative to state machines.

I've recently discovered the [BeeWare project, also known as pybee][1], and it's bloody awesome.

I had stumbled upon it before at Pycon US earlier, they had a booth set up and their website said "BeeWare, the IDEs of Python".

I didn't gave much attention at it at first, because I've kinda given up on IDEs some time ago. Every now and then I try Pycharm (which seems to be one of the best UI for Python development out there) and always end up getting back to Vim. An open source replacement for Pycharm definitely sounded cool, but still didn't seem much more than a bunch of developers tools born out of yak-shaving.

However, while there is some fun yak-shaving involved, it's just a teeny tiny part of the picture.

BeeWare is about bringing to people the power of computing.

I remember the first time I submitted a pull request in GitHub and some reviewer asked me to squash the commits. I had no idea what they were talking about. I didn't have any friends who knew Git, I was pretty much a noob on Git and GitHub. It's easy to forget how scary this stuff can be for someone just starting out with their first open source contribution.

First-timer OSS contributor asked to rebase and squash commits

It took me several weeks to figure out the whole thing because I was so afraid of messing up. And in the end the code didn't even get merged.

I never forgot my frustration during this, which is why today I avoid as much as possible to ask for someone to rebase their code in a pull request, unless I can pair with them and show how to do it.

I've shared this text almost as-is internally at @Scrapinghub, the company I work at. As it had a good response, I'm sharing it here after some minor editing. I wrote it mainly to my programmer friends, but many people will probably relate to it.

Here are some things that I want to share with you:

If you’ve ever felt that you’re a mediocre developer at best, even though you show up and do your best everyday, you’re not alone.

If you’ve ever felt bad about not being nearly as productive as you’d want to, you’re not alone.

If you’ve ever thought that you will probably be fired eventually because you’re not as smart and accomplished as your peers and “someday they’ll figure that out”, you’re not alone.

If you’ve ever refrained from introducing an idea out of fear of being ridiculed or laughed at, you’re not alone.

If the thought ever crossed your mind that you’re a fraud waiting to be uncovered, that everyone is smarter and better and faster and more knowledgeable than you, I want to tell you that you’re not alone.

Most of us go through that at least at some point, sometimes every day. And the thing is, there are ways for us to overcome these feelings that, even if we don’t completely eliminate them, it help us to grow both personally and professionally.

Here is a summary of my learning from watching season 3 of Destroy All Software screencasts.

Here is a table helpful for learning regular expression metacharacters differences across several languages and environments.

Almost ten years ago, I was an intern helping to maintain a PHP application and attempting to write a little framework to create the new version of that application. My little framework generated PHP classes from some templates and a description you’d write in a DSL language I came up with.

We programmers often prefer to work in problems that we already know how to solve, and tend to avoid hard ones that don't have a straightforward solution. Sure we like to think that we love a challenge, but given the choice of something easy to solve and another that requires thinking more deeply, one will choose to work in the easy one -- regardless of which one is more important. We're biased to tools and techniques that we already know and are comfortable with, we favor solutions we don’t need to think much.

These are my notes for season 2 of Destroy All Software screencasts.

fields

So, a few weeks ago I purchased and watched the first season of Destroy All Software screencasts (from Gary Bernhard), and it was awesome. I'd say there are different kinds of stuff to learn from it, depending on your personal interests and experience.

Update: This tutorial isn't up to date with the latest and greatest of Scrapy. You should follow the official documentation instead, I've worked together with other Scrapy developers to make it better. I'm leaving this article online for archival purposes only.

Those who know me well, know that I'm a bit of a Steve Yegge fanboy. That's true, I love reading Steve's mean jokes and I keep coming back to those long blog posts. That dude's writing has been a great influence to me. I've even started to write long posts myself, in a sort of cargo-cult-steve-yegge-wannabe behavior. I'm such a fanboy. Steve would probably feel embarrassed for me.

I cleaned up my desk this weekend and ended up finding some notes I wrote down some time ago when I attended a course about monitoring JBoss application servers. I haven't been doing much related to Java Web development lately, but I'm going to try to make a quick summary here because: 1) then I can safely throw away the paper with the notes, and 2) I think some of the tips can still be useful in the context of many long running JVM processes.

Soon after graduating, I went to work as a software developer for a big public company in Brazil. This company is responsible for a huge part of the country's IT infrastructure, and they keep trying to build a reputation of being innovative and pro open source, the kind of thing that excited me a lot. I thought: "They promote Linux and free software... Heck, their website is built with Plone. I'll get to do cool stuff in Python all day!" I know it's naive, but that was my thinking back then.

Okay, here is a book I've been trying to read for almost two months already and barely get to the half of it. Python for Data Analysis has left me with mixed feelings. Of all the O'Reilly books I've got until now, this is probably the one in worst shape.

Na virada do ano, uma das minhas resoluções para 2014 foi a de que este ano aprenderia Erlang. Eu queria brincar com alguma linguagem que usasse ideias diferentes das que uso no trabalho e que me ensinasse mais do que simplesmente outro jeito de escrever os programas que já sei.

Trabalho Eficaz com Código Legado é o título em português do famoso livro sobre código legado (título original: Working Effectively with Legacy Code) escrito por Michael Feathers, um consultor muito experiente e reconhecido na comunidade Agile/XP. Acabei de ler a versão traduzida que um amigo emprestou, e a tradução está bem decente -- bem diferente da última vez que li um livro técnico em português.

Se você é programador, você devia aprender shell-script. Ou pelo menos, algo parecido.

Um amigo indicou-me a leitura de The Problems of Philosophy (Os Problemas da Filosofia), uma introdução a Filosofia escrita por Bertrand Russell, filósofo e historiador britânico. O livro é excelente, esclareceu várias dúvidas minhas e me fez pensar melhor sobre muitas coisas.

Practical Vim é um livro sobre o Vim -- o editor de textos xodó dos programadores. Muito bem escrito, recheado de exemplos e referências, kudos para o Drew Neil, autor dessa belezinha. Drew também faz vídeos sobre o Vim, disponíveis gratuitamente em http://vimcasts.org.

Ok, hoje estou tirando a preguiça do traseiro para escrever sobre algo que há tempo queria fazer: uma lista de alguns programas úteis que uso no Ubuntu. A maioria deles eu demorei um pouco para descobri-los, por isso acho uma boa idéia falar deles por aqui -- são aplicações bacanas que merecem uma boa propaganda.

Alguns dias atrás terminei de ler o Programming Grails (Amazon), um livro sobre o framework Grails voltado para desenvolvedores experientes, que explica como funcionam várias coisas do framework e aponta vários caminhos das pedras. O autor é Burt Beckwith, conhecido na comunidade Grails por criar vários plugins úteis do Grails, escrever sobre Grails no seu blog, responder perguntas no StackOverflow, palestrar em conferências e também colaborar no desenvolvimento do próprio Grails.

Ok, se você não é javeiro, talvez nunca tenha ouvido falar em JSF. No worries, você não está perdendo muita coisa.

Estou usando Grails ativamente há alguns meses atrás. Comecei fazendo manutenção numa aplicação legada usando uma versãozinha do Grails já bem gasta. Eventualmente, acabei migrando de vez, usando Grails 2.x para praticamente todas as aplicações novas lá no trampo. O bichinho é muito bom!

O Vim ainda é o meu editor predileto. Tentei substituí-lo várias vezes, e as únicas alternativas que chegaram perto de ameaçá-lo foram Emacs e Sublime Text: o primeiro pela quantidade de recursos, o segundo pela interface joiada. Mas sempre que precisava resolver um problema rapidão, acabava voltando pro good ol' Vim.

Joel Spolsky é um cara batuta e muito inteligente. Ele é uma das figuras por trás do Trello e do StackOverflow (e seus sites irmãos), dois produtos show de bola que têm sido parte da minha vida diária ultimamente. Ele também é bastante conhecido pelos excelentes textos que escreveu no blog sobre vários aspectos de desenvolvimento de software, cobrindo assuntos desde gerenciamento de projetos, arquitetura e design de software, usabilidade e também contratação de funcionários. Resumindo: HERÓI! Se você lê inglês, ou quer aprender (e se você é programador, isso é altamente recomendado), dê uma olhada por lá! Aqui, vou deixar fácil: http://www.JoelOnSoftware.com

Aviso 1: Esta é uma tradução livre de uma das melhores histórias sobre estimativas de software já escritas. O original em inglês é uma resposta no Quora à pergunta do título, e essa tradução foi realizada com o consentimento do autor Michael Wolfe. Caso a língua não seja problema, recomendamos fortemente a leitura do texto original... simplesmente melhor e mais engraçado.

Aviso 2: Este post é resultado duma colaboração minha com o senhor Crineu Tres. Isto é, ele fez tudo e eu só traduzi os palavrões.

O percurso é de aproximadamente 400 milhas; podemos caminhar 4 milhas por hora, 10 horas por dia. Dessa forma chegaremos lá em 10 dias. Ligamos para nossos amigos e marcamos uma janta para o próximo domingo às 18h, quando chegaremos de forma triunfante! Eles mal podem esperar!

Cuidado: o texto a seguir contém níveis perigosos de nerdice, acrônimos e javeiragem em geral.

Acabo de terminar a leitura de um livro simplesmente excelente, Facts and Fallacies of Software Engineering (Fatos e Falácias da Engenharia de Software), do programador/pesquisador/escritor Robert L. Glass. Bob Glass não é um acadêmico que fica falando abobrinha sobre como deve ser feito software mas que nunca quer botar a mão na massa. Ele se descreve como um pesquisador e praticante de engenharia de software (com 45 anos na área), e ele tem mesmo muita coisa interessante pra dizer.

Este é o primeiro post na idéia de escrever sobre os livros que leio, na tentativa de fixar melhor o que tô aprendendo. Rezemos pra que não seja o último! :)

Algoritmos deviam ser ensinados breadth-first, e não depth-first!

Nossas primeiras experiências influenciam as seguintes muito mais do que a gente percebe.

Um amigo meu costumava dizer que tudo no Linux é com malabarismos no teclado, porque certa vez ele conseguiu rebootar um sistema que estava travado, apertando várias teclas aleatórias ao mesmo tempo ("Alt+Shift+Ctrl+Del+K+Enter", narrava). Tempos depois, ele acabou adotando o Linux Ubuntu no desktop, e embora ainda tenha problemas de vez em quando, tenho a impressão que ele já se adaptou bem... Este post é uma homenagem a ele, uma versão em Português duma resposta no AskUbuntu à pergunta do que fazer quando o Ubuntu trava! :)

Alguns dias atrás, tive a chance de fazer duas coisas muito importantes pra mim: apresentar uma performance solo no meu estilo de violão instrumental (acústico fingerstyle in your face :D) e subir no palco com músicos profissionais: o estupendo guitarrista manézinho Luciano Bilu e seu trio!

Uma vez ou outra a gente topa com um cara que acha que ter uma idéia é uma coisa tremendamente importante. Execução, isto é para noviços (subentenda-se, gente que só faz o que mandam)! O jeito de ter sucesso é ter uma idéia brilhante, e a sorte de ter tido essa idéia antes de todo mundo...
De vez em quando, esse cara tem uma idéia empolgante o suficiente pra iludir a si próprio que teria uma chance de criar uma coisa. E em vez de botar a mão na massa e tentar implementar, aporrinha os outros sobre como a sua idéia é super, e não se esforça pra pô-la em execução.

Não tem problema!

Alguns meses atrás descobri o Play it slowly, um programa para tocar arquivos de áudio em velocidades ou alturas diferentes, no Linux. Você pode usá-lo para, por exemplo, ouvir uma música no mesmo tom da original mas com um ritmo bem mais lento (útil para aprender as notas de um solo complicado), ou ainda ouvir um podcast numa velocidade um pouco mais rápida sem transformar a voz do palestrante na de um ratinho. (Tem um equivalente para Windows, Best Practice, grátis e livre assim como o Play it slowly).

Steve Yegge é meu herói!

Dias atrás estava debatendo com alguns amigos, tentando demonstrar como não era muito intuitivo o jeito que acostumamos a pensar sobre consumo de combustível, para efeito de comparação. Perguntei a eles o que fariam se tivessem dois carros, um sedã que fizesse 10km/L e uma camionete que fizesse 5km/L, e tivessem que escolher entre o upgrade da camionete para uma que fizesse 10km/L ou o upgrade do sedã para um que fizesse 35km/L. Todos me disseram que iriam obviamente com a segunda opção.