Go ahead. Disqus.
Tuesday, April 28, 2009
Alas, poor Blogspot. I knew him well. That's right - it's time for bigger and better things, this time in the form of a shiny new (hand-crafted!) blogging platform.
More details are in the inaugural post. This final post here is mainly to say that if you are one of the brave souls reading this via RSS, please update your feed - and thanks for reading!
Saturday, April 04, 2009
Editor's Note: I am continually amazed by and grateful for the thousands of internet denizens who write about their problems and the solutions they have found. This post is one feeble attempt at contributing to that collective knowledge; hopefully many more will follow.
I decided to rework my home page as a simple Rails application, mainly to take advantage of the way Rails handles views/templates. Is this overkill? Probably. Are there a ton of other tools I could have used? Definitely. It's a classic case of holding a hammer and taking a look around for nails. But I digress. I also decided to set up Enterprise Ruby/Rails, Passenger, and Git, all of which are totally overkill at the moment but will hopefully lay a groundwork for things to come. Again, I digress.
The first thing we'll need to do, assuming we're working with a fresh install of Debian (5.0 - Lenny), is install libraries for Ruby, Apache, and mySQL.
(I have no idea what a couple of those items are: I was prompted to install them later on in the process, so if you install them up front it will go more smoothly)
Get the most recent version of Ruby Enterprise Edition.
For me it was:
Note the Enterprise Ruby version in red, we'll need it later.
The Ruby Enterprise installer looks in /usr/bin/ruby for Ruby, which doesn't currently exist; link up your install in ruby1.8 by doing
Now, using your own version of Enterprise Ruby from above in place of the ###...:
Run the installer:
Follow the prompts. Should be self-explanatory.
Next, remove the old link to ruby1.8:
and link up to the enterprise ruby goodness:
ln -s /opt/ruby-enterprise-1.8.6-########/bin/gem /usr/bin/gem
ln -s /opt/ruby-enterprise-1.8.6-########/bin/rails /usr/bin/rails
ln -s /opt/ruby-enterprise-1.8.6-########/bin/ruby /usr/bin/ruby
Now install Passenger:
As you may have noticed, the Enterprise Ruby install directs you to add some lines to Apache's config file. If you're using Apache2, open that up with
and add the following, replacing the gem version in red (2.1.2 at this time) with your own gem version.
That's it for Enterprise Ruby and Passenger! Next up, Git:
Get Git - right now it's:
Unarchive; configure; make; install!
You'll likely want to set up Virtual Hosts on Apache as well; this gets a little bit specific for the purposes of this how-to so I'll leave it at RTFM :-)
Thursday, April 02, 2009
1. Create "Maximo Park Radio" on Pandora
2. Happen upon the song "We Don't Think, We Know," by Maritime
3. Catch the allusion in the lyrics: "All the days are just packed / And we’re asleep in the trees"
4. See if anyone else caught it -- nope! (Well, they didn't write about it anyway)
5. Write about it
6. Smile :-)
Saturday, March 14, 2009
Tim Berners-Lee, inventor of the internet, recently spoke at the 2009 TED conference. His talk was an inspirational glimpse into the life of someone who has clearly never stopped exploring and always done what was intriguing to him -- it just so happens that his road wound up providing a tremendous benefit to society.
Some highlights of the talk were Tim's *sheer joy* at the notion that he had made an addition to a collaboratively edited map; a new Three. Word. Mantra (Raw Data Now); and a shoutout to a previous outstanding TED talk on the power of making data useful and universally accessible (sounds familiar).
Tim also put up a cartoon that made fun of the fact that all of these different social sites (Facebook, LinkedIn, Flickr, etc.) exist in silos, incapable of fully interacting with one another.
This is certainly a problem that the major sites are aware of and are working to fix; Facebook, for example, allows me to import a feed of my activity on Picasa (Google's photo storage/sharing service).
But it doesn't quite cut it. Photos are a perfect example of my point. Let's say I have an album, and I want to keep it on Picasa (or Flickr, or wherever) instead of Facebook because I don't want the picture size reduced (or any other reason). However, I still want to tag my friends in that album, and if people make comments, I want those to appear below the pictures.
The current solution is broken -- when's the last time you clicked through on something like "John has uploaded new photos to Flickr" and left a comment on his picture, after finding it tagged with all of John's Facebook friends?
The workaround hints at the solution. I have several photo albums that have "_facebook" appended to their names. These albums are duplicates or near-duplicates of albums that are stored elsewhere but that I wanted to share and tag using my Facebook network.
Such duplication of data should leave anyone who works with databases (myself included) banging your head against your keyboard right about now. ao;idsgja;sodijadosifj. That's better.
We need to "normalize," in database-speak (read: stop duplicating), the content that we put on the web. After all, it's our content! Right now we're jumping through all sorts of hoops because Facebook has our network but Flickr has more storage and better picture quality. Why should that matter? Why should we have to make this compromise?
Instead of duplicating and distributing content, it needs to be in one single place, accessible to those applications and sites that you give permission to. You provide the information; Facebook provides the social network, the display formatting, and the ability to easily allow others to make additions (e.g. comments) to that information. Your. Raw. Data.
It's REST meets the social web.
Tim talked about how data is all about relationships (bing!). The most challenging part of all this is making it simple to manage these relationships. Let's move away from photos for a second and talk about another piece of data that we would ideally keep in one place rather than duplicating it across multiple sites: basic profile information.
Things like name and email address are straightforward. Any site that is interacting with Your Raw Data probably requires one of these as their primary way of distinguishing an account. But what about something like "favorite books"? Or "professional experience"? I want the first to be on Facebook but not LinkedIn, and vice versa for the second. Or what if I want to have "homebrewing" on my list of interests on Facebook but replace it with "golf" on that same list on LinkedIn?
Connections are perhaps an even better example, and one that's gotten more attention - I want to be friends with my co-worker on LinkedIn, but not so much on Facebook. How to manage those different relationships?
And to cite a far more useful example -- Tim talked about databases for pharmaceutical companies and researchers, trying to find all the proteins with certain characteristics. One lab might do an experiment and determine that a protein does have the ability to do XY and Z - does that mean the connection should be made? What if another lab produces a conflicting result? Who decides whether it's a valid connection?
While there are a ton of people working on the problem right now, none of the results I've used take the approach that I've outlined here. Many aggregate from the current smorgasbord, which is certainly the easiest thing to do, but not, in the long run, the most useful. If anyone is jumping out of their chair right now and interested in a little side project, let me know :-)
I'm going to cut this off here but hopefully will have more to write about on the topic soon. In the ultimate irony, these thoughts will be posted to my blog and then imported as a "note" to Facebook. Any comments written in either location will not be displayed in the other one.