Picoides nuttalli foraging

9387950555 8e362cb33c Picoides nuttalli foraging
Nuttall’s woodpecker, originally uploaded by schahn.

While retrieving a few items from the car I parked out front, I heard the burst of a woodpecker tapping, and grabbed my camera (with an 80 – 320 mm lens for soccer) to see if I could get a good enough picture for identification. The camera rig was much more suitable than the camcorder I used to snap a merlin in 2005.

Ben looked at the photo and worked through his options in the AMNH Birds of North America. Based on the range, the barred back, and red crown, he thinks it’s an example of Nuttall’s Woodpecker (but it could be a Ladder-backed or a hybrid of the two).

This serene moment of observation ended when the squirrel in that same tree, directly above me, dropped a walnut on my head.

Instrumented soccer, 6/30

I managed to get back out on the soccer field, after the two field sessions of the Class E clinic and a weekend in Reno shuttling the boys around. Even though I had worked in some accelerations into my runs, I tweaked my right hamstring at the clinic and so I knew today wasn’t going to be great for sprints. (The hardest part about the clinic was participating in all of the other students’ demonstration drills—about 13 hours of drills.) So, today was about playing smart.

The summary was

p micoach 20130630 workout Instrumented soccer, 6/30
miCoach summary, 2013-06-30

The duration suggests a combination of a brief warmup, at least compared to 9 June, and 40 minute halves instead of full 45s. (It’s a 90F weekend.) Since I couldn’t go all out in the sprints, I made sure to cruise a bit more to get into good position, which is reflected in the high intensity distance being about the same as the previous game.

Another useful graph from the miCoach soccer report is the timeline:

p micoach timeline 20130630 Instrumented soccer, 6/30
miCoach timeline, 2013-06-30

Looks like I sat out for a long substitution in the first half; I’ll have to call for a sub sooner. This week’s goal: further hamstring recovery.

Instrumented soccer

After talking with one of the dads on Nathaniel’s team, I decided to start playing soccer again, this time in the PAASL Men’s B division. (I played a single season of AYSO Adult League in fall of 2011, but work got a bit too busy. Before that there’s an 18 year hiatus.) For running and lifting, various Android apps—CardioTrainer and Strong Log—have given me enough feedback data to adjust training plans, but for soccer, it’s a bit awkward to carry a phone on your shirt sleeve. Since I didn’t want to play without some form of instrumentation, I began to research.

The only single player system for soccer I’ve found is Adidas miCoach, which consists of a pod that slips into a recess under the insole of your left boot, a receiver, a synchronization program, and a web application which provides the reporting. I chose the Mac/PC package, where the receiver is a USB device, to use with my laptop. Since I hadn’t played in a while, I was curious to see what the summary was. When I got home, I ran the sync app, and logged into the miCoach site. The summary panel from my first game, which includes the warmup, is below:

p micoach workout 20130609 Instrumented soccer
miCoach summary, 2013-06-09

Even these five numbers were illuminating: distance travelled, at just under 4 miles, was comfortable, given my regular runs. But I don’t do a lot of speed work, and the demonstrations and touches I perform with Ben’s team are low intensity, and the second half—except for one or two runs—was much more of a challenge in terms of summoning speed. (It feels like a brief incantation is required at my age. Twenty years ago speed was always available…) I’ll make sure to add more accelerations when I’m out on the roads, or just suck it up and run some wind sprints.

miCoach gives more detailed results than that summary; I’ll show a few of these in future posts. No measurements this weekend, as I’m attending the Class E coaching clinic.

Bookmarks from Tue Aug 21 2012 to Thu Dec 27 2012

These are recent links Stephen has saved on http://pinboard.in.

Building node.js on OpenIndiana

More specifically, these instructions should let you build node 0.8.16, the current stable version, on oi_151a5:

$ uname -a
SunOS cooler 5.11 oi_151a5 i86pc i386 i86pc Solaris

(cooler is in its seventh year of service, having run many builds of Solaris, OpenSolaris, and, now, OpenIndiana.) First, you’ll need a GCC 4.x compiler. If you attempt to use the 3.4.3 gcc compiler, you’ll get

cc1: error: unrecognized command line option "-fno-tree-vrp"
cc1: error: unrecognized command line option "-fno-tree-sink"

in the output from your failed build. So, use the Illumos GCC 4.4.4 build, which you can install via

$ sudo pkg install developer/illumos-gcc developer/gnu-binutils

which led to the installation on my system, of 3 packages, and a total of 56.9MiB of content downloaded. Include these new tools in your path for the build:

$ export PATH=/opt/gcc/4.4.4/bin:/usr/gnu/bin:$PATH

To help the node build find the appropriate Standard C++ library for linking, we set the linker run path, via the environment. (By having a correct run path, our node binary won’t need LD_LIBRARY_PATH to be set to pick up libstdc++.so.6.) We can then configure, and issue the (GNU) make to start a build:

$ export LD_RUN_PATH=/opt/gcc/4.4.4/lib
$ CC=gcc ./configure --prefix=$HOME
$ CC=gcc gmake

You can test the resulting binary

$ ./node
> process.version;
> ^D

and install the node platform to the configured location.

$ CC=gcc gmake install

And now you have a working node.js for your OpenIndiana system. npm is installed as well, so you can begin downloading the modules needed for your development. (If you’re running OmniOS, it looks like the “managed services” repository includes a pkg(5)-installable node.js package, so you can install that interpreter directly. Maybe that’s what cooler should run next.)

post-review returns HTTP 500 with cribbed repository configuration

We run ReviewBoard at work; we set up each hosted Git repository as new projects are started. I made a silly error a few weeks ago: when I created a new repository, I filled in the Mirror Path setting with that of a previous repository. This mistake leads to client output like

$ post-review 7fdd345e22783b289be128205cc0c47935057e20
Error creating review request: HTTP 500

Your administrator mail address should receive a message with a body like

Traceback (most recent call last):

File "/usr/lib/python2.7/site-packages/Django-1.3.3-py2.7.egg/django/core/handlers/base.py", line 111, in get_response
  response = callback(request, *callback_args, **callback_kwargs)

File "/usr/lib/python2.7/site-packages/Django-1.3.3-py2.7.egg/django/views/decorators/cache.py", line 79, in _wrapped_view_func
  response = view_func(request, *args, **kwargs)

File "/usr/lib/python2.7/site-packages/Django-1.3.3-py2.7.egg/django/views/decorators/vary.py", line 22, in inner_func
  response = func(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/Djblets-0.6.22-py2.7.egg/djblets/webapi/resources.py", line 397, in __call__
  result = view(request, api_format=api_format, *args, **kwargs)

File "/usr/lib/python2.7/site-packages/Djblets-0.6.22-py2.7.egg/djblets/webapi/resources.py", line 581, in post
  return self.create(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/ReviewBoard-1.6.11-py2.7.egg/reviewboard/webapi/decorators.py", line 127, in _check
  return view_func(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/Djblets-0.6.22-py2.7.egg/djblets/webapi/decorators.py", line 88, in _checklogin
  return view_func(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/Djblets-0.6.22-py2.7.egg/djblets/webapi/decorators.py", line 62, in _call
  return view_func(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/Djblets-0.6.22-py2.7.egg/djblets/webapi/decorators.py", line 231, in _validate
  return view_func(*args, **new_kwargs)

File "/usr/lib/python2.7/site-packages/ReviewBoard-1.6.11-py2.7.egg/reviewboard/webapi/resources.py", line 5984, in create

File "/usr/lib/python2.7/site-packages/Django-1.3.3-py2.7.egg/django/db/models/manager.py", line 132, in get
  return self.get_query_set().get(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/Django-1.3.3-py2.7.egg/django/db/models/query.py", line 351, in get
  % (self.model._meta.object_name, num, kwargs))

MultipleObjectsReturned: get() returned more than one Repository -- it returned 2! Lookup parameters were {}

each time a review is submitted against one of these repositories.

You can fix this condition by correcting the Mirror Path of the new repository; it’s not a ReviewBoard issue.