Many people use the standard Python debugger (pdb or ipdb) because it works well and can be used as a standalone tool or with your favorite editor. I’ve used it for years, but today I’m more productive using the PyCharm debugger. It can debug Python, JavaScript, and Django and Jinja Templates (making the debugging process seamless in web applications). Also, I don’t have to worry about leaving pdb.set_trace calls around anymore.

The whole Editors versus IDEs debate is getting old and boring, especially because it is not a zero sum game. I’ve been using Emacs for 15+ years and at one point I used it to read my email, browse the web, and make coffee (haven’t we all?). But today I find that I’m more productive by using the right tool for the right job.

I often need to convert a bunch of MIDI files to MP3 for teaching and lecturing. There are a few commercial graphical apps for the Mac and you can even use Garageband, but I always wanted to be able to convert MIDI files using the command line since it’s easier and I can automate the whole process. On the Mac we can use Timidity++ or Fluidsynth, both available using homebrew.

How many hours have you worked on your Minimum Viable Product (MVP) in the past month? How many hours have you worked on your lifestyle business this week? How long does it take to write a book? I’m able to give reasonable answers to these questions because I track my time.

Hackers turned founders rightfully track many things about their products (downloads, page visits, conversions, etc) but, surprisingly, many of them don’t track where they spend their time.

As I mentioned in a previous blog post, I used Sphinx to write my book, Music for Geeks and Nerds. With Sphinx I could generate HTML, Epub, Mobi (for the Kindle), and two PDF versions (black-and-white and color). Sphinx works quite nicely out-of-the-box for documenting computer programs, but I had to bend it a little to generate output more suitable for a book.

I’m happy to announce that I’m launching my ebook, Music for Geeks and Nerds. It uses programming and mathematics to teach same aspects of music and it answers long-standing questions such as why Eb and D# are different, and which sequence _sounds _better, Pascal’s triangle or Fibonacci (place your bets). I wrote it because I have friends who are programmers, computer scientists, or engineers and they are always asking me for book recommendations to learn more about music. There are good books out there, but I always feel they present things in a prescriptive, “magical”, or worse, artsy way.

I was advising some students the other day about harmonizing non-traditional scales and someone mentioned how it would be useful to have a list of harmonizations for every possible scale. I bragged that I could write a program in half-hour to accomplish it. Of course it took longer than that, but I quickly wrote a small python program to generate harmonizations for every possible scale and used LilyPond to typeset them.

I’m writing a series of posts about SICP in Python. You can read more about the reasoning in the introductory post.

The first chapter is about building abstractions with functions. I think it’s remarkable that a book for beginners (pretty smart beginners, but still) introduces assignment only in the third chapter (on page 220). I really think this is the way to start a programming course. Probably all students know about mathematical functions and with functions we can talk about things like bound variables, scope, abstraction, composition, and recursion.

Structure and Interpretation of Computer Programs (a.k.a SICP, or “The Wizard Book”) is considered one of the great computer science books. Some people claim it will make you a better programmer. It was the entry-level computer science subject at MIT and it’s still used in universities like Berkeley. One of the great things about SICP is that it focus on computational processes and ideas, instead of just teaching syntax.

Call me old fashioned but I like to review my code by printing it. Yes, on paper.

The advantage of reviewing code on paper instead of the monitor is that I can give my eyes a break and I can annotate more freely, connect things with arrows, draw boxes, etc. I don’t print my code everyday, after all this is not the 80’s, but I like to print the code when I feel it could benefit from some refactoring and re-structuring and my brain could benefit from same change in the medium and even location (I can grab the printouts and go to a park or cafe).