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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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.
Read more →
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).
Read more →