It’s a fun group, and I always enjoy going, even when I’m the speaker.

Raspberry Pi, $50ish, with case, etc.

That has sound already.  If it’s crappy, plug in a $100 Total Bithead.  If you want to go whole hog, get a $500 Headroom Micro DAC and Headroom Micro Amp.  You’ll even get a big knob and all the nice ports on the front.

Way less than a Transporter, but no shiny displays.

If I could get “good enough” sound for $50, with a DIY software set from the Internet, that’d rock.  It’d rock especially hard if I could make it do the software sync, too, but that might require changes to the Logitech Media Center.

EDIT: After thirty seconds of searching the Internet, yes, it can do this.  Someone else has done the hard part, even.  Neat.

The nice people at Logitech have dropped the Squeezebox line to make a new cloud-based product.  Not my cup of tea.

Problem: The Logitech Media Server software is old and balky, and installing it is a pain on new systems, because it includes binary versions of Perl modules.

Solution: Install perlbrew for the squeezebox user, install a supported Perl version there, and tweak the #! lines to use that squeezebox user’s perl install.

The right perl works fine, and since it’s in ~squeezebox, it won’t get screwed up when SuSE upgrades.

WAY easier than trying to fix the idiosyncratic Logitech Media Server software!

So. Shopping for cartridges. This leads easily down the audiophile rabbit hole, and I don’t want to go too far.

This was, in it’s day, a moderate-to-nice turntable, not the pinnacle. It’s plugged into a vintage moderate-to-nice receiver. They match! :) Keep in mind that in the mid-1970′s, vinyl was more important than now, so even moderate-to-nice was pretty good gear.

I’ve had two solid recommendations for the Sure M97xE. It’s well regarded.

There’s also a Grado – the Gold -I’d consider.

In the end, I went with an Audio-Technica AT440MLa.  Well regarded and affordable.  My local shop was impressed with the sound, and said it went on easily.  I’m pleased with the sound too.

I also got a new stylus on the turntable I inherited from my Grandfather.  There’s a 78 stylus available for that cartridge, too, which is tempting.  It would play 78′s properly, with way less fuss.  We shall see.

The plastic bases commonly used hold 1/16″ chipboard, perfectly. It’s also numbered 0.06″ or just 0.06. It can sometimes be called Binder’s Board and is used for making book covers. Check the scrapbooking places.

I got a big box of it on eBay – possibly a lifetime supply – for $16, including shipping.

It fits the stands perfectly. I’ll print the art, glue them to the cardboard, and cut them out on the laser cutter at TechShop.

I ordered my brush from, of all places, the DAK catalog.  It was gone for a while, but he’s back.  Lots smaller, but many of the same ideas – reasonable products at cheap import prices.  Several of the “audiophile” sources had what appears to be the same brush for twice the price.  And Drew has pictures of dust to look at.  What more can you ask?

I’ve been really impressed at the difference this makes right away.  Whenever you put a record in a paper liner or a cardboard sleeve – who’s brilliant idea was that, anyway? – the grooves get filled with linty fluff.  As the record spins – at about 1.1mph at the outside edge – all that fluff impacts with the stylus and makes a torrent of little white noisy sounds.

The carbon fiber brush is really simple – it sweeps all the linty fluff out of the grooves without packing them full of crud.  That whole layer of noise goes away.  I bet most people just think that is how records sound – nope!

I’m confident that this is something that almost anyone can hear the difference between, and at $30 or so it’s well within the bounds of most people.

It’s Invisible

The first reason is that I feel it changes the language a lot, and in ways that make it really hard for a new reader to follow. If you’re reading code that has no error checking in it, as a new or even mid-level Perl author, you’ll perhaps not realize that’s bad, or that it does have error checking. That checking being hidden in “use autodie” can be somewhat difficult to see.

As part of that difficulty, using autodie makes changes to all the Perl builtins.  When I need to use one, I look it up in perldoc.  perldoc tells me it returns false or undef or whatever in case of an error.  Except… that’s not true with autodie.  While I’m a good enough programmer to remember this about my own programs, it makes it a lot harder to tell what a particular piece of Perl code will do.

I’m really unhappy with the changes to the second edition of the Modern Perl book, because it’s assuming autodie everywhere.  I don’t want to give it to new Perl programmers any more because they’ll be confused, and the differences are subtle and almost entirely undocumented.  I can’t recommend the new version of this otherwise useful book to anyone who isn’t an expert Perl programmer and that’s a shame.

I don’t like making large-scale, undocumented changes to the language libraries any more.  At what point is it no longer Perl, but something new and different?

As an aside, I think a lot of expert Perl programmers forget that many people using Perl don’t know it has exceptions at all.  I often find people who are shocked to discover it does.  Some of them have even been using die for errors, and didn’t know how the whole thing works together.  Professional programmers, not script kiddies.  Happens all the time.

This concern of mine with autodie is actually a solvable problem.  The Perl core needs to incorporate autodie, and update al the perldocs to explain it.  If the perldoc for “unlink” said, “returns the number of files deleted. With autodie enabled, will die on error deleting files.” it would mean that a new author would have a chance to see what’s happening.  I don’t expect this to happen, but until it does, I consider autodie too sweeping a set of changes for a module to be making.

I probably wouldn’t use it anyway, because of this second reason:

I Don’t Like Exceptions

I’ve worked in a ton of languages that use exceptions.  I understand them, and I can use them.  I don’t like them.  I find it hard to write robust, resilient code with them.  Many people like them because you can put off or ignore error handling and capture it all in one place.  Your code is free of that distracting noise of error handling.

However, this means your code notices the errors in the wrong place to do anything about them, and has to pretty much fall over dead and crash.  It can’t try and fix things very well.  Or you can handle the exceptions very close to the place they might occur, littering your code with even more distracting and hard to read exception handling stanzas.

The most reliable and robust code I’ve ever written was about 70% error handling code.  In many cases it could recover from errors or try an alternative to keep running.  I find this much harder to do with exceptions, and exceptions in general much more difficult to manage.

If programmers were clamoring for a giant “ON ERROR GOTO” statement, while telling me that gotos were evil, I’d be really confused.  Yet, that’s what exceptions are.  Exceptions that many programmers never handle, and simply want the program to crash the first time something goes wrong.  I don’t want my program to crash every time something goes wrong; I want it to log the error and keep going, or ask again or try an alternative.

If “Go To Considered Harmful” is still valid – and it seems to me to be – why is ON ERROR GOTO allowed?  Isn’t that all an exception is?

I don’t know a way to change this preference of mine, and how to convince myself that it’s okay to just let things crash or to write horribly tangled code to pander to the needs of the exception handlers.  So, I don’t.

I replied to my friend, discussing that article on Lifehacker, and he suggested I publish it as there was a ton of additional information in it.  So, here it is, a reply to Lifehacker’s article:

Here’s pseudo code of what I found at work today:

$ok = link("$src/$file", "$dst/$file");

unless($ok) {

    my $log = $!;

    log_error_in_database($log);

    send_error_in_email($!);

}

See the error?  The coder saved the error from $! in $log, and then passed it to the DB to store it.  The DB (which no one knew existed) had all the right errors.  Writing to the DB changed $! to a harmless non-error.  It wound up being “Resource temporarily unavailable” or whatever numeric value that is.  It’s meaningless, though, because it was set by calling some other stuff in the DB handling function.

Then, the code tries to e-mail it.  Clearly the DB was added later, as it didn’t use the copy they saved there, and used $!, sending the useless value to us in e-mail where we all looked at it.

(Edit: A sharp commenter suggested I actually show the fix, which is an excellent idea!)  Instead of storing your error, then forgetting to use it, use the stored error message in both places:

$ok = link("$src/$file", "$dst/$file");

unless($ok) {

    my $log = $!;

    log_error_in_database($log);

    send_error_in_email($log);

}

Another alternative would be to use local on $!, but that’s not as sound, because every function you call also has to do the same, and it is hard to tell what module or library you use might get it wrong.  Saving a copy of $! for your code to use later will be safer.

The good news is that I eventually found, and realized the values were in the DB and looked there so I know what was going on and can try and make progress.

This is actually cleaner and simpler than the real code.  The real code actually did check the results of link(), which is good!  It doesn’t check mkdir() or chdir() anywhere, though…  It’s not the worst Perl I’ve ever seen, but it’s on the list of contenders.

I really, really want to replace this code with something that is less painful.  I have a nice, new Modern Perl version well underway.  We’ll see if management lets me finish and deploy it!