It is interesting that the maintaining of a commonplace book was encouraged as part of your academic study. Lab notebooks have certainly retained their place in the more sciencey parts of academia but I'm not sure commonplace books have.
The wiki entry did suggest that blogs have common thread with commonplace books -- I like that line of thinking. You could look at a blog like Brett Terpstra's as a "commonplace" blog for his discovery of code snippets and their repurposing for his own endeavors. You could also look at the resurgence of personal journaling (Day One is my personal tool of choice here) enabling the same behavior.
If they Firefox engineers can pull off the same-as-image PDF quality printing people are used to then they'll have shipped something crucial in web history. Regardless the writing is on the wall for browser plugins. If not the Firefox team, someone else will ship a full-featured JavaScript PDF engine. If you've got a product reliant on Java, Flash, Reader, Silverlight or anything else requiring a native browser plug-in, you'd best be well on your way to removing those dependencies. Presumably Apple's Safari on OS X (10.9?) will be the first browser to remove browser plug-in support altogether. The rest of the dominos will fall shortly after.
While we have a native vs. web debate going on in the mobile space the activity within browsers is all about getting rid of their native shackles.
Using the Python Dropbox SDK, a bit more python glue and a Drafts.app Dropbox Action I can now quickly send a new text entry to this blog. Probably the easiest posting workflow I've ever had. No excuses for not routinely posting at this point.
This domain has been a languishing experiment with Tumblr for several years. It safe to say the Tumbr experiment was a failure because, as is usual with me, I care far more about data preservation than ease-of-use. Probably when Tumblr fully morphed into a social-network first and a blogging tool second is when I checked out of their platform.
After deciding to end the experiment my thoughts turned to what to do with the portfolio of domain names I lord over, but primarily: db79.com, medero.net, & soypunk.com. medero.net remains our family blog and there's no point in changing that. shawn.medero.net is more of a personal vanity page that I believe is useful in professional contexts. Neither db79.com and soypunk.com were active but db79.com has a fairly rich history of blogging dating back to 2001. The problem is the name is virtually meaningless except for whatever meaning I've painted over it as the years went on. soypunk on the other hand is my usual handle on social services and other internet communities and so I'm inclined to centralize all of my blogging adventures under this domain going forward. Exciting news for many of you I'm sure.
As we approach the new year, I'm thinking about resolutions for 2012. One of
my primary tech-themed resolutions is getting a better handle on my "cloud"
data. Robert Nyman, a Technical Evangelist at Mozilla, shares some reasons for
why you might want to concern yourself with "Who Owns Your Online Life, And
Data?"
Do you have all your mail on Gmail, appointments in Google calendar,
pictures on Picasa and videos on YouTube? Do you use Facebook to sign into
every service you use and article you comment on, on the web? All your
pictures you’ve ever taken on Flickr?
A number of these companies offer these services for free. Free is a
relative term, of course, since a majority of them go through your data and
recorded behavior to present you with ads and similar information; at the same
time, it makes it a much more compelling platform for advertisers with
targeted ads. This data could, at least potentially, also be shared with third
party companies, so in essence you can never be entirely sure what and how
much a company knows about you.
Many people say they are fine with sharing all the data about them, but I’m
unsure they realize just how much companies know about them. You can make a
conscious decision what to share, all the time, but always be ready that
anyone out there can access anything you ever share.
Robert points out that these companies do provide great services and there be
nothing wrong with your centering your digital life around them. Still it is
worth considering an inventory of what you use online and what your backup and
exit strategies are.
An example might be "What would it take to have a mirror copy of everything
I've put into Flickr?" It is a harder question once you dig into it. You might
say "I have a copy of every photo I've hosted on Flickr in iPhoto." That
tackles the archival of the photo material but it may not capture the
taxonomy, geo-tagging, or even URI system-of-record
services that Flickr is
providing. I'm not trying to pick on Flickr btw, I think they do an impressive
job of opening up their service. Aaron Straup Cope's "parallel-flickr" project is a great example of what you can do.
Can I download all of my Path data?
Yes! We're happy to help you get a copy of your Path data anytime. Please send
a request to service at path dot com and we'll take care of your request.
I'm sure that'll scale awesomely when Path is bought out by some company you
aren't comfortable with. (And it is a shame because the smart journal user
experience Path is providing really is quite nice.)
Lately I've grown tired of reading about how a platform is closed or open
based on a single facet of its operation. I expect lazy coverage from pundits
but much less so from technology journalists.
Open Source
In the age of competing mobile computing platforms we've seen a lot of
discussion of "openness." Often these debates focus on the open source angle
from the last great technology platform war: Microsoft vs. Linux. Nothing
illustrates this more than a single tweet from Google's Senior Vice President
of Mobile, Andy
Rubin:
the definition of open: "mkdir android ; cd android ; repo init -u
git://android.git.kernel.org/platform/manifest.git ; repo sync ; make"
Andy's tweet implies that mere access to the source code for your platform
along with the ability to build the code in some form is the endgame of
openness. Andy's openness script glosses over the complications an independent
developer might have in building the various Android flavors created by HTC,
Samsung, or Motorola. If a developer cannot build the various platforms they
wish to deploy their application on, is the platform still open?
If source code isn't a sufficient measure for openness, what other checkpoints
might there be for a mobile computing platform?
well documented public APIs
standard document interchange formats
programmatic access to device components
a "free market" for distributing applications
unfiltered network access?
ability to freely switch out the platform on the device itself
There's only one mobile computing platform I can think of that would receive a
passing grade on most of these marks (with several marks of unsatisfactory at
that): The Web.
Platforms come in all shapes and sizes with various levels of "openness".
Source-code alone won't prevent a developer's business model from being
invalidated overnight. Source-code alone won't allow consumers to switch
platforms if their device, platform, handset maker, or carrier denies them the
privilege. Source-code alone won't prevent locking a developer into a
licensing strategy (such as the GPL) which will hamper future efforts to
transfer, license or expand the intellectual property they've developed.
Source code that is missing a critical component (application or other forms
intellectual property) doesn't help a developer hunting down a potential
compatibility bug or an end-user trying to enhance an application's workflow
to their own liking.
Device Fragmentation
Device fragmentation doesn't rule out a platform as being open. There's a lot
of device and implementation fragmentation on the Web. We each have our own
prism of the Web defined by our browser, network provider, operating system,
and user preferences. Any of these players might make a particular shard of
the web more or less open.
If the platform and an "application store" help normalize the differences
across devices (for both consumers and developers) does that make platform
more or less open? Was Mac OS X more or less open before the Mac App Store?
Before you answer, factor in the cost to market, sell, and support an
application before the App Store. Consider the same experiment for a developer
targeting Slackware Linux. If you only provide a limited set of device choices
but in doing so you've enabled a consistent, fluid, and engaging user
interface have you made your platform more or less open?
Openness
There aren't black and white answers to most of these questions. It is a
battle of tradeoffs that enable and hamper platform providers, developers, and
consumer in contradictory ways. The Web is seemingly an open platform but has
a high barrier to entry for certain types of implementors and business while
being extremely open to other uses. iOS is not a "closed platform" because
Apple & the carriers dictate the rules of how you may use the hardware &
network they've essentially leased to you. Android is not an "open platform"
because they provide a significant portion of the operating system code.
Platforms are too complex for narrow definitions and it would serve everyone's
best interest if technology journalism would help us unravel the tradeoffs.
Users (be they developers, end-users, or business-folk) are ready for
sophisticated discourse of mobile technology because we've invested our future
in making the smartphone a core part of our daily experience.