Post-blood-donation mini fudge stripes.
Monthly Archives: January 2015
YESSSSSSS
What car?
Courtesy of my dad.
Spinning Off a Git Repo
I’ve been hacking away at this one project for the last three-plus years. It started out with a limited scope, and it made sense to keep it buried in an existing git repo - it was closely related to the rest of the code base. Quickly the scope grew, and for the last two years I’ve known I should pull it out into its own repo. That’s a daunting project, so I kept putting it off.
Until today. This codebase is going to get some wider circulation, so it was finally time to take the plunge. Greg Bayer put together a fantastic guide for how to get this done: Moving Files from one Git Repository to Another, Preserving History. I’m capturing the commands here, just in case I ever need to do this again.
First, make a local clone of the starting repository, and filter out everything except the subdirectory of interest:
git clone <git repository A url>
cd <git repository A directory>
git remote rm origin
git filter-branch --subdirectory-filter <directory 1> -- --all
Then, clone the destination repository, and pull in the master branch of your stripped local clone of the starting repository:
git clone <git repository B url>
cd <git repository B directory>
git remote add repo-A-branch <git repository A directory>
git pull repo-A-branch master
git remote rm repo-A-branch
I probably would have tried to pull this off in my working copies of the two repositories, so Greg’s comments to start with new clones and then disconnect them from the remote were solid.
Oh shit.
Omnifocus Forecast Discrepancies
I’ve been a dedicated Omnifocus user for about three years, and I’m a big fan of the 2.0 releases on all three platforms (Mac, iPhone, iPad). With the recent 2.0 update on iPad, we saw a move towards the styling of the iPhone Forecast Perspective. There’s one quirk about it that’s making me crazy, though. Pay attention to Due count on each day, and which days are highlighted.
On the Mac, we can see a whole month. Today (Monday the 19th) and Thursday (the 22nd) are highlighted because there are available tasks that are due on those days:
On the iPhone, the same days are highlighted:
But on the iPad, all of the days are highlighted, whether or not the tasks are available (in this case, they’re blocked by their Start Dates):
This affordance on the Mac and iPhone has become a key part of how I use Omnifocus - days that aren’t highlighted mean I don’t need to look at them urgently. Days that are highlighted require attention.
In Ken Case’s plan for 2015, he wrote:
It’s time to make OmniFocus for iPhone just as capable as OmniFocus for iPad is, bringing over all those features like Review mode and the ability to build custom perspectives.
I do hope that before they port the iPad implementation over to the iPhone they’re able to incorporate this design detail back into the iPad.
Update January 20, 2015:
Ken Case responded:
@jeffvautin We agree! The universal update will adopt the Mac/iPhone handling of unavailable due soon tasks in Forecast.
— Ken Case (@kcase) January 20, 2015
#backtoschool
#powerpun
Listening To Storage
This is why audiophiles get a bad name. Right out of the gates:
Anecdotal murmurings and some limited first-hand experience suggested that digital music files can sound different when played from different computer media sources. […] We readily confirmed that the final sound quality is influenced not only by the choice of network player, DAC, digital cables, or indeed many other long-recognized factors, but additionally — and quite markedly — by the manner in which we now store large quantities of our music at home.
It’s so hard to even know where to begin with this, but let’s just assume the author’s assertion that all of those other factors affect sound quality1. The entire design of the experiment, in addition to being poorly documented2, is just dumb.
This initial trial was not intended to be an exhaustive study into all the factors that can affect the sound quality of network and computer audio, only to confirm or deny the suspicion that digital bitstream coming from hard disks are not all equal. Which has to be somewhat surprising, to say the least.
Thoughts:
- The author readily acknowledges they didn’t control for a number of factors…
- …but still concludes that the digital bitstream coming from the hard disks are not equal.
This assertion can be directly3 tested, for instance, with MD5. If you directly test the accuracy of the data coming from the drives, you can eliminate all of the factors that are uncontrolled, the most troublesome being the subjective comparison: the listening.
Either the disks are accurately reproducing the data or they’re not. And if they’re not, it seems much more likely that you’d wind up with completely corrupted files than a ‘more tuneful’ rendering of the music:
QNAP2 rendered the same song more tunefully. It was more organic and made more sense, the lines of melody and rhythm cooperating better. As well as showing better individual instrument distinction, the whole piece sounded tidier, tonally less messy without the roughened HF, and perhaps better integrated in musical intent.
Next, someone will probably claim vinyl sounds better.
-
DACs, yes. Digital cables? If the PLL of the receiver can reconstruct the clock with low jitter, then the cable doesn’t matter. ↩
-
How were the listening tests done? If the switching times between playback systems were at all substantial, it would swamp our echoic memory capacity. Was ABX testing employed? Can they reliably determine which NAS is which, with statistical significance? ↩
-
Sorry for all the italics. This just makes me so angry. ↩