Off The Lip

“They’ve included several bundles of code libraries for databases and more importantly interfacing with the Facebook API.”

Over thirty years of software engineering dismissed in two seconds. As a developer, my heart bleeds. Or maybe not. Anyway I feel this could definitely sum up 2007.

I wrote an article for O’Reilly’s OnJava about Raven, it’s very entry-level but you still could fine some stuff interesting. I also briefly mention Buildr in it (future article for Assaf?). Thanks a lot to Alexis, Antonio and Seb for reviewing it (and Nicoche for trying) before it went live.

By the way I found the O’Reilly OnJava editor, David Brock, to be a very nice guy.

Nice services are flourishing all over the web to let you listen to music in intelligent ways (meaning in a way music majors don’t like). To name a few: Pandora, Last.fm, Deezer or Seeqpod. There are much more but these are my favorites at the moment.

Now there’s a notorious problem with playing music through the Flash plugin of your browser: it’s a tightly closed black box. There’s an attempt at creating open source versions of the Flash player but it’s not quite there yet (although it works well for YouTube and I dearly hope it will improve). For me this closed environment is a problem: first I don’t like closed software, second I can’t listen to that music later or offline and third I can’t send it to my airport express, which deeply annoys me.

But this time, my friend, is over. Come PulseAudio. It’s an open source sound server allowing for pluggable music producers and consumers. So you can read music on your computer and have it played on another machine on the network. Or control the volume for each source individually. Or do all kind of other smart tricks. And it runs either on Windows or Linux (sorry Mac users, you can’t have both reflection in Dock and good open source software).

Turns out that you can have the Firefox flash plugin send what it’s playing to PulseAudio. And configure PulseAudio to have this stream written to a sink file on your filesystem. And read the stream from that special file to write it to a regular file. Or send it over to your Airport Express. Or do whatever you want with it. Freedom, finally.

So here is a short How To to get this working on Linux (sorry Windows users, you won’t get past step 2 even if you don’t have Dock reflection):

• Install PulseAudio. I hear it’s already in Fedora 8. For (K)Ubuntu users, there’s a decent tutorial from the Debian guys.
• Compile and install the Flash player library for PulseAudio. There’s a nice little guide. Although on Ubuntu the latest available version of libpulse is 0.9.6 and the one required to compile is 0.9.7. So I just changed the version in configure.ac and it did the trick.
• Edit /etc/pulse/default.pa and uncomment the line: load-module module-pipe-sink
• Restart Firefox if it was already started and start playing music. You can open pavucontrol to see what is playing and redirect it to the file sink (right click on the source).
• To verify that something get played just cat /tmp/music.output and try to read the matrix.
  

From there you can do a lot of things. Write the sink to a classic file that you can keep around with a cat /tmp/music.output > myfile for example. Note that this is raw music but you can probably send it to lame to encode to mp3. Personally, I pipe the file sink to an Airport Express using raop-ruby.

Music sounds so sweet to my ears.

Picture from tonifrancois.

I’ve always been a strong believer in the benefits of reading others’ code. This belief has been recently reinforced during a discussion with Alexis. The argument is that there’s no better way to learn new idioms, programming patterns (in the generic sense, not the GoF sense) and applied algorithms than when reading code. And that’s one more benefit of open source. By having so much code out there you can read, there’s far more opportunity to learn than, say, 10 years ago. I’d even go as far as saying that the open source movement is making us all, developers, better, by giving us very valuable sources of knowledge. Don’t get me wrong, there’s always been some opportunity to learn before from others’, like the code of your team’s guru, but we now have far more choices and also much better quality code to choose from. And probably also much worse but you can learn from that too and before you’re good enough to learn from bad code, you’ll have to make good choices.

I’ve learned Javascript a lot by reading Prototype. Same thing for Ruby, starting from Rake with its nicely structured code and more recently with RSpec, which is full of clever meta-programming techniques. Java is a bit different, when I started the net was less ubiquitous, there was less good quality open source libraries available. But the API sources were distributed with the JDK and there was quite a bit to see in there too (both good and bad). The Oswego Concurrent library, now part of the JDK, is also a priceless mine of best practices when you need to write thread-safe code.

More generally, the same thing can be achieved at the design and the architectural level. Just check how things work and what the implications are. For example, from using and checking the guts of different big Java persistence frameworks, I can tell you there are basically 3 ways to make some class persistent in Java, which requires knowing when an object attribute value has changed: code generation (either compile time or runtime), byte-code enhancement or reflection. Each approach has its strengths and shortcomings. Hibernate uses the first technique by generating classes at runtime that subclass your persistent classes. It’s almost completely transparent until you start caring about class identity: the classes you’re dealing with have changed. Which can lead to some nasty bugs with inheritance trees and the usage of instanceof. Which doesn’t mean Hibernate is a bad tool, others also have the problems that can come with their respective design decisions. It’s just good to know them, to know why they exist and see if some similar designs you’re working on could be facing the same tradeoffs.

As for architectures, there’s also a lot to learn from past failures, the disillusions and the incremental improvements over the years. J2EE, SOAP-based Web Services, RESTful Web Services, JBI, SCA, what do they all offer? Which benefits? Which compromises? But when you go from code to design to architectures, the number of details to grasp grows significantly, making objective judgment also significantly harder.

Reading the code of interesting libraries and checking how some pieces of software work is a way to reach our collective knowledge, as developers. All this code out there is both our toolbox and our Wikipedia. So read more. And also, don’t forget to write and offer your best looking code, it’s as good a way to teach as any.