I’ve been writing a series of posts here over the last few months discussing the JUCE C++ application framework and how useful it’s been in creating the ‘Scumbler’ looping audio performance application that’s my current nights & weekends project. One of the important requirements that I had for the project was that it be able to use existing VST or AU audio effects plug-ins to process the audio during performance.
Over the years since I graduated with a degree in electronic and computer music, I’ve accumulated a fairly large shelf of books on digital signal processing theory and applications. Earlier this year, Focal Press released what’s the most usable book on writing audio effects plug-ins. It’s very easy to find books for theorists, or for people who already have very heavy math backgrounds explaining the concepts behind DSP; it’s rarer to find resources targeted at interested and motivated practitioners. Anyone coming to this book with a relatively solid background in C++ programming and high-school math (trig and at least pre-calculus) should be able to work through it and come out the other end with an understanding of much of the DSP that’s needed out in the wild.
I realized something about my life right around the time that I was getting ready to ask my girlfriend to marry me: if I wanted to eat well at home, I was going to have to learn to cook, because she lacked the interest and patience required to cook well (or at all, in her case…)
I gradually transitioned from basic subsistence cooking into being a really good and enthusiastic home cook with an ever-growing bookshelf of cookbooks and hours logged in front of the better shows on Food Network. The real thing that unlocked cooking for me was finding resources created by people who weren’t interested in demonstrating how to make a particular thing; these teachers were more interested in showing you a different way of thinking about food. On one end this is people like Michael Ruhlman and Alton Brown, focusing on the underlying principles behind how and why we cook (if you wanted to learn to cook well, I’d buy you a copy of Ruhlman’s books “Ratio” and “Twenty” and you’d have a solid foundation right there.)
On the other end of that shelf you have chefs like Grant Achatz, whose ‘Alinea‘ restaurant in Chicago is built around taking his deep, deep knowledge of the basic materials and techniques of cuisine and blowing them up, reassembling them with ultra-modern technique and presentation to create things that have never been done before, yet always make sense as food.
image from http://designforhackers.com/book/
David Kadavy’s book ‘Design for Hackers: reverse-engineering beauty’ is built around the idea of presenting the underlying principles of visual design to hackers eager to learn the secrets of the field. (more…)
This past week I finished reading the very interesting book, How Google Tests Software. I first heard about this book from an IT-Conversations interview with one of its co-authors, James Whittaker. The interview provides a good overview of many of the key points made in the book, but I still found it worthwhile to read the book.
The book itself is not a how-to book, providing concrete steps on how to test software. Instead the focus is at a higher level with much of the book devoted to describing the different testing roles within the company. There were three particular themes that jumped out at me from both the interview and the book itself.
I’d like to expand on Brett’s post a bit with some more recent books that I’ve enjoyed. And another which is perhaps a few clicks off the maintained trail.
The Algorithm Design Manual (Steven Skiena)
I’ll kick this discussion off with the fact that I don’t have a Computer Science degree. There, I said it. No degree. Ask me and I’ll give you the info: There’s no Computer Science degree here. Anyway. As a pure practitioner, I love books that usher out-of-reach concepts into the realm of real-world applicability, and this one does exactly that. This book is one part catalog of algorithms, the other part a series of “war stories” — real problems the author has tackled during his career using variations of the algorithms presented.
The Little Schemer (Matthias Felleisen, Daniel P. Friedman)
This book taught me a conscious way to write recursive routines. Prior to reading, I’d hammer the keyboard with a gloved hand and hope for the best. The preface mentions that this book is itself derived from a course taught by the authors on Scheme programming — to non-technical public affairs students. Yes, so you might imagine that the presentation inside is not your typical c0d3rz manual. I’ve dispatched this book to a couple of my non-technical friends, and the consensus is that this book is a gem.
Hacker’s Delight (Henry S. Warren, Jr.)
Count 1-bits in a word. Reverse bits in a byte. Transpose a 32×32 bit matrix. This book is a catalog of interesting passages of low level bit-twiddling code. Thanks to modern day tools, I haven’t needed to reach for many of the tactics described in this book, but it is an enjoyable and mind-contorting swim through the ether of machine words and switch flippery. Looks like I need to pick up the recently released second edition.
Image via http://www.flickr.com/photos/library_of_congress/2162719777/sizes/z/in/photostream/
Going through my RSS feeds this morning after a week away, I see this post from DHH at 37 Signals:
There are so many programming books out there, but most focus on specific technologies and their half-life is incredibly short. Others focus on process or culture. Very few focus on the timeless principles of writing good code, period. The following five books had the biggest influence on my programming style and development:
A very interesting list, and especially interesting to me that it has no overlap with mine. I do appreciate that his list concentrates on higher-level issues instead of more ephemeral matters (I angled the above photo so you can’t see my office’s Siberia shelf where I’ve exiled books like Brockschmidt’s “Inside OLE”). The five software development books that I’d grab if I had to evacuate in a hurry:
The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt & Dave Thomas)
I re-read this book once a year or so. I love that it’s a set of small concrete steps that you can take every day to make your work better. Two specific changes I made as a result of reading this book were:
- I switched to using vim as my primary editor, even when relying on an IDE to maintain build environments (Tip 22: Use a Single Editor Well)
- When I read this book, C++ was really the only language that I had use for on a daily basis. Their Tip 28: Learn a Text Manipulation Language convinced me to pick up Python, which is now where I spend most of my time coding (and using it far beyond what their description of a text manipulation language would imply).
Code Complete (Steve McConnell)
I vastly prefer the first edition of this book, but there’s still a lot of great material in the second book. The great thing about this book is that he looks at software as a construction activity, and considers the effects on your code of elements from the lowest level inside a single line of code up to broader architectural considerations have on the final product. Most usefully for me, he’s done the work of scouring the literature and providing citations that back up his recommendations. In an argument with someone about issues of indentation, using white space, or other code layout issues? McConnell can point you to the relevant human factors/readability studies that will help you make your case (or change your mind).
Literate Programming (Donald Knuth)
Sure, most folks would have gone for Knuth’s multi-volume ‘The Art of Computer Programming’ if they were going to include anything by him. For me, though, Literate Programming is the really interesting read — his basic concept here is that the true purpose of source code is to explain to another human what you’d like a computer to do, and more incidentally to include the actual instructions that make up the program. It completely upends the traditional thinking, where a source file is mostly code with some comments/documentation strewn about (rarely enough, or at least enough of it being useful). This book is a collection of essays, mostly discussing the WEB (not world-wide — the essays in this book are all from the mid 80s or earlier) system for authoring programs that he developed while creating TeX. A program written using Knuth’s Literate Programming tools reads as a publication that happens to have source embedded in it; post-processing tools named ‘Weave’ and ‘Tangle’ convert from the human-focused layout into compilable source.
On the one hand, I think that Knuth’s vision as presented in this book is a pipe dream (and is largely obviated by more modern tools and methods for thinking about source), but I find the idea of programming as a branch of literature compelling enough that it remains at the front of my mind when I’m coding.
The Design of Everyday Things (Donald A. Norman)
Technically, not a programming book, but instead a book about making things that are intended to be used by humans. Originally written in the late 80s, as software development was slowly making the move from being presented to users via character-mode terminals to modern GUI environments, and many developers needed to be dragged into the era where it was no longer acceptable to deliver clunky, unusable systems. I’ve got a whole section of my shelves filled with Don Norman books — this early one was probably the most eye-opening for me.
Thinking In C++ (Bruce Eckel)
This is another book where the first edition is the important one for me, even though it would probably be less so for anyone reading it today. When this was released, I had been working as a C programmer, mostly, and had been having a difficult time making the switch to using C++ as anything more than ‘a better C’. What Eckel did in this book was to go feature-by-language-feature in C++ and first implement each one in C to provide a thorough understanding of what’s going on beneath the covers before writing the same example program again using the much clearer C++ syntax. Reading this book was one of those cases where a subject I had been struggling to grasp suddenly and thoroughly clicked into place for me.
Those are my five (and I could keep listing books — Design Patterns seemed too obvious, Alexandrescu’s Modern C++ Design perhaps too mind-blowing).
Tag — you’re it.