Obscuratum

Now this is obscure:  the 1904 date system in Excel.

I was working with a spreadsheet in which I was trying to create a
projection of a larger spreadsheet.  I.e., I want to be able to
share just a portion of the larger spreadsheet — so I copied the
relevant cells from the larger workbook and pasted them into the
shareable workbook as links.  Which was fine — except the dates
were all wrong.  Right day/month, wrong year.

After a few judicious Google searches, I stumbled across the fact that
the Mac-created Excel spreadsheet was using the 1904 date system as
a default; unselecting that (in preferences) restored my copied dates
to the right year.  Victory!

But, here’s the larger picture:  I need to share the projected
worksheet with staff located at remote offices.  A communications
network that lets me send data point-to-point is all I need for
that.  However, point-to-point (connection-oriented) is not appropriate to develop the sort
of widespread information network that is the World Wide Web on the
Internet. I would not know who to turn to for resolution to this
annoying glitch. (The link above is to a Microsoft site; the one that I
actually hit at the time was some random user help group). 

To state the hopefully-obvious:  we’re all thoroughly invested in
this global information service supported by the Internet, and anything
that gets in the way of J. Random Helper posting solutions that S.
Frantic User can stumble across is a significant step backwards.

The Power of a Collective

The other day, with some new laceweight yarn in hand, I was browsing
for patterns for shrugs.  (I could make a lace stole, but I think
it would be nice to have a colourful shrug to wear over a sleeveless
dress, as an alternative to having to balance drapey fabric all
evening).   More specifically, I was browsing through the
patterns for shrugs listed on Ravelry.

To make a long story short, I came across the Rowan pattern Carolina, from their issue
39
.  From the available pictures, it really stood out as being
the most lacey, interesting, lightweight shrug.  Currently, 22
people have projects started (or completed) for this pattern, and you
can review the pictures posted in Ravelry.  A couple of them are here
and here
in Flickr.  I thought it was interesting enough that I actually
tracked down and ordered the relevant issue of Rowan.

The thing that amazed me was that, flipping through the magazine, the
official pictures of the pattern are quite dull.  Clearly, the
photographer and/or the magazine layout person was not enamoured of
this project, and simply did not show it up to its full
advantage.  I guess they didn’t “feel the love”!

So — their magazine did not sell itself (or the pattern) to me. 
Rather, Ravelry’s collective database of projects and pattern
information did.  It’s another example that filtering everything
through one small perspective (that of the magazine layout process)
does not have nearly the reach that providing open access to multiple
perspectives and sharing opportunities can. 

I never want to be limited to the perspective of a single provider.

What a Tangled Web We Weave…

I recently installed NoScript as an
add-on to Firefox.  I observed the Firefox application randomly
running my CPU up to 80% usage and holding, and I was pointed at
scripts as a likely culprit.  Indeed — as soon as I started
blocking web page scripts, my Firefox process CPU consumption dropped
below 5%. 

Of course, this also means that I’ve become much more aware of the
scripts that are commonly embedded in any number of my usual website
haunts.   One name that keeps popping up —
“google-analytics.com”.     A lot of sites use the convenient
Google tool
to capture and track information about their
viewers.  Hmmm…

Now, I’m a fan of reviewing web statistics to understand what’s being
done with my site.  As you might note, from the sidebar, I use Firestats to see what’s what with this
blog.  I don’t get (and I don’t want) much information — I see
information about the number of page views and visitors in the past 24
hours;  browser type/computing platform; and, where available,
referring page.    It’s good to know what kinds of
things people are looking for and how they get lead to my pages. 
And, that’s where the information stops.

If I used Google Analytics, I would be shipping all that information to
Google, where I would presumably have a dashboard with much more
complex results (as they analyze the data from my site, compare it
against data from other sites, and draw inferences).

But the difference in the model is kind of interesting:  instead
of you simply leaving a bit of a trace of yourself on my doorstep (with
Firestats), we’d be telling Google more about your browsing habits, and
my site popularity.  Great for Google — but I’m not so sure I’m
comfortable sharing that kind of information with a 3rd party. 

So, for now, I’ll leave NoScripts running and not let my web footprints
at other sites track through the Google databases.

Apple iCal: FAIL

Even before there was an Internet that emphasized the value and
powerful reach of inter-machine resource sharing and interoperability,
there was
a basic concept that any given program ought to be able to use data
files generated by any other instance of the same program, run on
similar hardware. All the user had to do was get the data
from one computer to the other.

Apple’s calendaring “solution” breaks this most basic of understandings.

I am an Apple fan — I heartily enjoy using
my computers to get stuff done, not having to continuously work
on the computers themselves. Apple is a leader in
delivering seamless computing environments. There are so many
things that Apple has gotten
right with the hardware and the user environment. But, sometimes
the apparent drive to “own” the “user experience”, gets in the way of
the actual user. One such area is calendaring: it takes
nothing away from iCal to say that I need it to play with others, and
yet the impediments to doing just that render it virtually
unusable. Message to Apple: making Mobile.me the only
way to sync my iCal across machines is NOT going to get me to subscribe
to Mobile.me, it’s more likely going to get me to stop using iCal.

A common calendar situation

I have a situation that I suspect is not all that unusual in the
world:

I have

  • a personal Apple MacOSX box;
  • an Apple MacOSX box for work; and
  • a personal Apple iPhone.

I need

  • to be able to keep track of, and update, my meetings
    wherever I am (calendar) and
  • to share some versions of my calendar with a shared work calendar
    server

FAIL

Is this an unusual situation? I can’t believe it is. And
yet, I have no solution to doing the above seamlessly, with iCal.
The fact that iCal has no inherent ability to share data with another
machine, or even publish and subscribe to the same calendar on a remote
server, makes it impossible to do the above without the intervention of
a 3rd party service or purchased software.

And even those are not so obvious, if you happen to share a few of the
principles I have:

  • I won’t store quantities of personal data on my work machine, and
    I certainly won’t make my work machine the primary for a personal
    application. The machine belongs to my employer, and they have to
    be able to pull it back at any time. I don’t care to be left high
    and dry.
  • I won’t store any employer data (i.e., work information) on
    my personal machines. (I don’t think I need to explain this)
  • I won’t store quantities of my personal data on some 3rd party
    remote server
  • I won’t store any employer data on some 3rd party remote server
  • I don’t have time to manually enter/update the same data in 2
    different places

So — I’m not reflecting my calendars of Mobile.me or even Google
Calendars. I won’t put all my calendar info on my work notebook
(only) and then have to sync my iPhone there.

Trying to route around damage

I have set up my own webdav server that both machines can access — but
the fact that an iCal cannot both subscribe to a calendar and publish
it somehere means that having my own server doesn’t provide me
with an authoritative server that both Macs can access.

I tried keeping the 2 machines’ calendar files in sync (using rsync),
and that works for the calendar data files. However, apparently
the calendars (particularly, those to which you subscribe) are stored
separately in preferences, so that they are not properly sync’ed, and
you get wierdness. That last point is particularly
irritating: even if Apple doesn’t care to provide the
functionality of sync’ing across Macs, by internalizing the data, they
are making impossible for me to find an alternative solution (rsync)
without getting into Apple-specific software development (digging
through preferences). This is where they turn their backs on that
age-old premise of reasonably open computing: that you can move
data files from
machine to machine, as long as you have reasonably similar instances of
the software to work on them.

I used to get away with using a 3rd device to be the “calendar of
record” — now my iPhone, previously a PalmOS PDA, and prior to that an
Apple Newton (!). That way, I could keep one calendar in sync
with one machine AND have it everywhere wth me, even when away from my
computer. Easy-peasy! But, now I need to have a calendar
that can sync (several times a day) to a shared work calendar, and the
iPhone can’t do that.

Where next?

So, I’m looking at spending $25/machine to achieve something iCal
should just be able to do. Or, I can use another calendar program
(e.g., Sunbird), and lose all ability to integrate calendar items with
other applications. Neither is an appealing prospect.

Really, Apple — I think this is an instance where you need to Lead
(build the best calendaring app for your platform), Follow (make it
easy for other calendaring programs to be integrated applications) or
Get out of the
way (let me route around your damage).