random($foo)

New Pads for the Cans #

May 21st, 2013 12:46

While I’m not a full-blown audiophile (I’ve been to way too many concerts, shows, raves, and parties to have any illusions on the state of my hearing), I do enjoy good set of headphones/IEMs. These days I mostly use Audeo PFE 232 IEMs with a Fiio E17 in the office, and an old iBasso D2 Boa and a going-on-five year old pair of Denon AH-D2000s at home.

These Denons actually managed to replace my mighty Sennheiser HD-580s as my go-to – mostly because they were both punchier and more comfy for extended wear. However, recently, the pads had started … disintegrating (grody). I started looking for replacement pads and ended up finding the Lawton Audio Angle Pads. After a couple weeks delay, I finally got them in the mail…

Holy cow, these are fantastic. Really comfy, but most surprising is that the the audio, particularly the soundstage is noticeably better. I’m a happy clam right now, and looking forward to the next 5 years w/ these suckers.

Of course I’m wearing these while I type. Here’s one of the tracks I’ve been grooving to right now… (Buy on Amazon)

Benign Dystopia #

May 17th, 2013 11:09

From a comment on Nick’s report from Google I/O:

The scene of strangers winking at each other along a row of urinals, wearing photo-taking, internet-enabled glasses, is probably the most benign dystopian future I have ever heard of.

Definitely less asinine than Larry’s thinking on medical privacy.

Basis Watch Report #

May 12th, 2013 12:07

Next in my gadget backlog series…

Basis B1 WatchI had preordered a Basis B1 Watch a long while ago and promptly forgotten about it, so it was a bit of a surprise to find one sitting on my desk after SXSW (which has turned into this amazing construct of pure marketing – good for business though, I guess).

Since then, I’ve worn it almost every day (about a month-and-a-half). I figured I’d give a report after living with it for a while since Basis is now apparently starting to sell them for real (after being back-ordered for a while).

While I have had reservations on the watch form-factor after getting a MetaWatch and realizing in the intervening decade since I regularly wore one that I now couldn’t stand wearing watches, I’ve mostly re-adjusted, and the data the Basis collects has been worth overcoming the annoyance factor.

There have been a couple reviews (the Verge one isn’t a bad summary), but here’s the basic rundown of what you need to know:

  • Price is $199. It comes exquisitely packaged in a die/laser-cut box and overall all the industrial and product design is quite nice (package, device, site/app). The watch is less bulky than the typical smart watch and is pretty inconspicuous. The capacitive touch buttons work well and the display is simple but more than adequate.
  • Unlike almost all devices currently on the market (besides the BodyMedia devices), the Basis is a multi-modal sensor device that’s more than just a glorified pedometer. Sensors include:
    • Heart-rate via green-laser optical flow-based sensor (I assume using something similar to the TI AFE44xx but sadly, there’s no current support for SpO2 or glucose measurements); An important note is unlike the similarly kitted MIO Alpha, Basis specifically notes that heart rate measurements are not suitable for exercise monitoring
    • Skin Temperature (accurate to the tenth of a degree) – mine seems to be about 92-94 degrees fahrenheit when I’m up and a few degrees lower when I’m asleep
    • Perspiration specified by μS/cm, so it looks like it’s using galvanic response to calculate? The Basis itself seems to be fairly well waterproofed, and I’ve used it in the shower w/o issues (although usually not, because that’s weird, right?)
    • Pedometer and sleep tracking via a 3-axis accelerometer
    • Calories burned are derived from BMR via Oxford equations multiplied against a “physical activity level value” that’s presumably derived from the sensor data collected. Note, if you have a better BMR value (ie, I have an RMR estimate from my lean body mass from my Bod Pod measurements, you can presumably use Table 5.2 to reverse calculate what weight to enter to get more accurate estimates)
  • Battery life is good for a few days (3-5?) and you need to use a custom charger to recharge. This is a bit of a pain actually, especially if you’re traveling – the charger is a plastic band that hasn’t broken yet, but is just begging to be and will soon enough, I’m sure.
  • This charger also syncs data from your device. This is a really important point. While the Basis has Bluetooth (2.1 eww) built-in, it doesn’t work yet and the USB sync is the only way to get your data. Also, there are mobile apps (Android first, then iOS?) on the way, but again, these aren’t available yet. Personally, I wouldn’t recommend this to most end-users until this gets sorted out.

The web interface and the graphs that it gives you is actually quite nice. For me, the actual (almost) dealbreaker wasn’t the lack of wireless/mobile syncing (wireless power and data sync is definitely very high on my list for want-to-haves, personally), but rather that while there’s been the promise of an API/export for quite a while, there’s actually nothing (and no roadmap!) yet.

Paul Miller wrote a great piece on this earlier in the year about this, which I vigorously agree with and I won’t buy or support any self-instrumentation device that doesn’t give me full access to my own fucking biometric data.

Now, if you’ve read the last two paragraphs and are scratching your head on how/why I still have my Basis watch, well, that’s simple: there is an API, it’s just not publicly documented. If you’re an end-user looking for export, yes you are SOL and should send your Basis back and demand a refund if it’s important to you (and it should be!).

If you are a developer, simply pop up your Javascript console and look at the XHR calls to /api/v1 for nicely formatted JSON. Note: these calls are actually totally unauthenticated. That’s bad. However, since the tradeoff is easy access to my data w/ low likelihood of accidental leakage (data URLs have hashed unique identifiers), I’m ok with that for now.

Overall I like my Basis although I have an Amiigo on the way that, if it functions as promised, should be better than the Basis in pretty much every single way (sans telling time/wrist display – but that’s not so necessary anyway w/ a proper mobile app). It’s also half the price. For developers and data geeks, the Amiigo also promises to have a full SDK and actual developer support (although I hope they have their data as nicely formatted as the Basis data – it’s totally sweet).

However, the Basis is well designed, and if you’re absolutely buying something today, the Basis is by far and away the best device for those looking for serious self-instrumentation (ie not Fuel Points). The habit system is also on the right track, as well, in terms of general usefulness. However, as outlined, the B1 is also a seriously unfinished product at the moment and anyone expecting basic fitness-tracking functionality (like a mobile app/wireless syncing) will be disappointed. Early adopter caveats definitely apply.

It’s a pretty interesting time for fitness/activity trackers – I think we’ll soon be reaching a point where the sensor-suite will be more than good enough (as mentioned earlier, photometric glucose measurements and SpO2 should be possible w/ the existing sensor packages, and having wireless charging would be the last really nice bit), and the real value will be integrating with other data to create an integrated picture and assisting in behavioral modification/self-improvement. It’s also interesting seing some of the vertical applications as well. The LIT for example looks pretty neat.

UPDATE: Looks like a QS guy also reviewed the Basis and also spotted the JSON feed, and better yet, published some instructions and some code on Github for people.

Hacking the Ouya #

May 10th, 2013 1:50

I’ve made a public Hackpad (I like it and have been using it more and more, although not without reservations) to gather some notes/docs on getting Linux to run on Ouya.

I’m a fan and hope they succeed as an additional channel for indie gaming, but the short of it is that despite some previous claims/hopes, the Ouya is completely hacker unfriendly (bootloader locked, GPL-violating lack of Linux kernel sources, no one at the company answering their emails).

If you’re looking for anything besides playing Android games, you should look elsewhere (there are many alternatives).

So it’s off to the land of misfit gadgets for mine (aka the pile on my workbench) or to gather dust w/ my XBox, but was fun to d/l Gordon’s Beast Boxing Turbo demo and play it on the 70″ screen in the office.


View Ouya Hacking on Hackpad.

Dirty Hack of the Day: Python DNS Edition #

May 7th, 2013 10:11

In Python, you can set most request timeouts w/ socket.setdefaulttimeout(). In recent versions, urllib2 has also added a timeout field to urllib2.urlopen(). So far so good, right?

Unfortunately, while these work fine when looking up IPs or domains in /etc/hosts, this fails miserable when querying a FQDN as you’re at the mercy of socket.gethostbyname() and your DNS resolver which does not let you adjust the timeout. On my Mac this defaults to 30 seconds. It’ll ruin your day, really. (A good recent thread, old summary)

This is a somewhat common problem and you can see a lot of various workarounds (using signals didn’t work for me). The proper modern way is to probably using multiprocessing with a join(timeout) (sample) but that seemed awfully wordy, so here’s my simple one-line hack that I ended up with instead:

subprocess.check_call(['/sbin/ping','-t','1','FQDN'])

Just set 1 to the timeout you want. It’s hacky, but it works and it’s much easier and shorter – a one liner in a try block without any other libraries. Another advantage this has is that it works as it should both with DNS and mDNS (zeroconf) without any additional lookups. I’m using this for finding local machines so this is quite useful.

Some extra references:

Late Night Reading #

April 19th, 2013 12:47

Transcript of secret meeting between Julian Assange and Google CEO Eric Schmidt

And I wanted there to be more just acts, and fewer unjust acts. And one can sort of say, well what are your philosophical axioms for this? And I say I do not need to consider them. This is simply my temperament. And it is an axiom because it is that way. And so that avoids, then, getting into further unhelpful discussions about why you want to do something. It is enough that I do. So in considering how unjust acts are caused and what tends to promote them and what promotes just acts I saw that human beings are basically invariant. That is that their inclinations and biological temperament haven’t changed much over thousands of years and so therefore the only playing field left is: what do they have? And what do they know? And “have” is something that is fairly hard to influence, so that is what resources do they have at their disposal? And how much energy they can harness, and what are the supplies and so on. But what they know can be affected in a nonlnear way because when one person conveys information to another they can convey on to another and another and so on in a way that nonlinear and so you can affect a lot of people with a small amount of information. And therefore you can change the behaviour of many people with a small amount of information. So the question then arises as to what kinds of information will produce behaviour which is just? And disincentivise behaviour which is unjust?

Thinking about this in context of the events unfolding in Boston, and the crowdsourced attention happening among other things.

Some Notes on Labor, Technology and Economics #

March 26th, 2013 12:50

I think that we are all aware that advanced capitalism is leading us down a road that as a society, we may not want to travel – constant crisis due to increasingly advanced, complex, and unstable financialization, an increasingly vicious trend toward plutocracy and plutonomy that has obliterated socioeconomic mobility via massively increasing inequality, and of course, as an engine of unsustainability, where environmental, health, and social costs are externalized and reality is subsumed via a twisted economic logic.

All these things really should be teased out into much larger discussions, but a few recently related links/discussions I want to make note of (I’m slowly moving some things back out of Evernote into a way that can be narratized):

  • HN: Confessions of a Job Destroyer – a good essay that highlights what technological “disruption” really means; relevant to software, robotics and all sorts of enabling technologies
  • HN: Unfit for work (npr.org) – NPR is doing a weeklong series on how the disability program is hiding massive collapses in the workforce

Also, this image popped up in my Twitter stream recently…

A quick Google search shows that it’s been floating around for at least a year, and the bottom text references an organization that ceased to exist in 1982 so it is probably quite old, but still resonates as much (if not more) today. Here’s the text transcribed (via)

If you’re unemployed it’s not because there isn’t any work

Just look around: A housing shortage, crime, pollution; we need better schools and parks. Whatever our needs, they all require work. And as long as we have unsatisfied needs, there’s work to be done.

So ask yourself, what kind of world has work but no jobs. It’s a world where work is not related to satisfying our needs, a world where work is only related to satisfying the profit needs of business.

This country was not built by the huge corporations or government bureaucracies. It was built by people who work. And, it is working people who should control the work to be done. Yet, as long as employment is tied to somebody else’s profits, the work won’t get done.

- The New American Movement (NAM)

Searching for this led to this interesting article:

Summary Mode #

March 21st, 2013 8:11

While there are public tools like Storify that do an OK job for tweets, and I personally end up using Evernote or for most of my (private) tracking of topics, it’d be useful if there was a good tool for collecting/collating and snapshotting primary sources and making notes/comments on any particular topic (and groups of topics). Useful things would include seen-on and publish dates (a la Zotero etc). And being able to contextualize/parse interesting pieces (Evernote and Clipmarks do a pretty good job with this)

For example, for the controversy of the past few days on the whole PyCon fiasco:

* Summary: How “dongle” jokes got two people fired—and led to DDoS attacks

A series of discussions on Hacker News related to the topic:
* 2013-03-17 Inappropriate comments at pycon 2013 called out
* 2013-03-20 The PyCon Incident
* 2013-03-21 PyCon Code of Conduct changed to avoid public shaming
* 2013-03-21 SendGrid Fires Company Evangelist After Twitter Fracas
* 2013-03-21 Adria Richards, PyCon, and How We All Lost
* 2013-03-21 A Difficult Situation

Performance Comparison of Image Libraries Revisited #

February 24th, 2013 4:09

A few years ago, I wrote up a brief comparison of various image libraries running a series of operations (image compositing and resizing) that we use for Lensley on an OS X + Python setup.

Just recently, I started doing work with Ruby + RMagick, however I ran into some issues doing basic operations (PNG resizing on a set of images) that was just incredibly slow.

ruby 1.9.3p385 (rvm) + RMagick 2.13.2 (ImageMagick 6.8.0-7 2013-02-19 Q16)
real	9m37.735s
user	4m11.995s
sys	3m16.644s

What’s going on here? Looking more closely, Ruby started out maxing out the CPU but this actually declined as the script ran, and memory steadily climbed, reaching 6GB by the end (which took about 30s after processing just to release). Obviously a GC issue, and sure enough, there was a thread about it. Adding a couple destroy! calls at the end seemed to fix things nicely:

real	3m49.132s
user	3m44.673s
sys	0m3.150s

Now, how did that compare with running convert via Python, I wondered?

Python 2.7.3 + envoy + convert (ImageMagick 6.8.0-7 2013-02-19 Q16)
real	4m58.882s
user	4m40.536s
sys	0m15.840s

Seems about right (one interesting thing to note is that the processing was actually shorter than Activity Monitor’s refresh so it never showed maxed CPU usage). Now how about running ImageMagick directly?

time mogrify -path test-seq3 -scale 800x450  test-in/*.png
real	3m17.050s
user	3m14.937s
sys	0m1.879s

OK, and since we’re just doing simple manipulation, lets see how it does against sips.

real	0m56.272s
user	0m51.000s
sys	0m5.150s

Well now, that’s a bit embarrassing isn’t it? Still, one thing with all of these so far was that only a single processor was being maxed out.

I decided to try multiprocessing (this was easier for me in Python) to see how fast I could really process these images. I used multiprocessing + Queue w/ 8 processes for my cores (similar to this example).

Python MP + envoy + convert (ImageMagick 6.8.0-7 2013-02-19 Q16)
real	0m51.472s
user	4m44.998s
sys	0m19.737s

Python MP + PIL 1.1.7
real	0m18.123s
user	2m5.540s
sys	0m2.721s

Python MP + Wand (ImageMagick 6.8.0-7 2013-02-19 Q16)
real	0m39.012s
user	4m39.162s
sys	0m4.145s

Python MP + pgmagick (GraphicsMagick 1.3.17 2012-10-13 Q8)
real	0m17.148s
user	1m47.560s
sys	0m1.593s

Python MP + envoy + sips
real	0m52.984s
user	0m58.504s
sys	0m13.715s

The biggest surprise was that sips had virtually no gain and no effect on the actual processing. I wonder if there’s some pipelining going on or what the loss in subprocesses was… PIL and GraphicsMagick beat the pants of ImageMagick, both being over twice as fast in processor and wall time.

I would have liked to have tried comparing to freeimage, but alas couldn’t get wrappers to work. smc.freeimage and FreeImagePy had problems talking to the dylib, and I was able to get mhotas‘ freeimage wrapper mostly working but it was giving me fits on resizing. Maybe next time.

Python and ImageMagick #

February 21st, 2013 10:50

I’m a big Python fan and it’s my preferred language these days, but sometimes you just have to shake your head and give up. One area where Python falls down is in its ImageMagick bindings. You can read more about the history of some of the libs here.

Here’s my experiences on OS X (10.6, 10.8) and MacPorts that hopefully will save some people time:

  • PythonMagick (BROKEN) – the official bindings, and somewhat up-to-date (last update 2012-09-19), I could get it to compile, but it threw TypeErrors when trying to run. You can compile it like so:

    ./configure --prefix=/opt/local CPPFLAGS="-I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7" LDFLAGS=-L/opt/local/lib

  • pythonmagickwand (BROKEN) – this shows up in searches, but it hasn’t been updated in 5 years. It’s as you can imagine, broken.
  • python-magickwand (BROKEN) – last updated 2012-01-22, it includes a nice README (w/ the aforementioned history) and examples and I wanted it to work, alas, I couldn’t get it to.
  • Wand (WORKS!) – Wand is under active development (last commit 2013-01-31), is Pythonic, has community contributions, and works! Sounds perfect, right? Alas, it doesn’t support many features currently (layers, effects, animation etc) although it’s on the roadmap.
  • pgmagick (WORKS!) – This lib was the closest to doing what I needed. It’s very active (last commit 2013-02-10) and is much more comprehensive than Wand.. however, while supposedly working for ImageMagick, I could only get it working w/ GraphicsMagick, which in my case, was missing features that I needed. There are decent docs but very little real code out there. Here btw, is how I got it running (it has some boost issues; also, pip doesn’t work):

    sudo port install boost
    cd /opt/local/lib
    sudo ln -s libboost_python-mt.a libboost_python.a
    sudo ln -s libboost_python-mt.dylib libboost_python.dylib
    sudo easy_install pgmagick

    After wrestling for quite a while, I threw in the towel and rewrote my code in Ruby w/ RMagick, which is well maintained and up-to-date, has comprehensive documentation, and lots of example code floating around the web.

    If you’re tied to Python, using PIL or subprocess/envoy to call convert/mogrify directly is probably your best bet, but if you are doing anything substantially complex, calling out to an RMagick script will probably save yourself a lot of pain.