Month: January 2010

400 Duboce #113, Now from “Greg Apartments”

| Nathan Yergler

So things are continuing to get a little weird at my current building. First, management was “transferred“ to FirstApts. I put transferred in quotes because, really, it’s the more of the same: same phone numbers, same people, same lackluster management. Apparently an exercise in branding, trying to excise the CitiApartments name from people’s memory (for some reason). You could write a case study about how not to rebrand yourself in the 21st century based on this. Their old email addresses start bouncing, their old domain doesn’t even redirect. Hell, even some of the email addresses they put on the letter to residents bounce as non-existent. (When calling to let them know, the receptionist is hardly interested, telling me, “someone ought to update that sign.” Yes, someone indeed.)

So it’s a little strange, given all this effort to present a new, uniform brand, to see the following on Craigslist (thanks, Richard!) (cached copy):

|image0|

Huh, that looks like 400 Duboce. But “Greg Apartments”?

|image1|

Yup, that’s unit 113, the first one I looked at when I was looking at the building (it was leased to someone else before I got my application in two and a half years ago).

Greg Apartments website also has contact information; that’s a different phone number than Citi, er, FirstApts uses, but 2099 Market sounds awful familiar. Oh, right — that’s the same address at Citi and FirstApts. Digging a little (but not much) deeper, we find that gregapartments.com is registered to none other than FirstApts, with Greg listed as the technical and administrative contacts.

All these shells, and they’re still trying to raise the rent.

Updated 2012-10-24: Removed Greg’s contact information.

date:2010-01-05 22:01:31
wordpress_id:1290
layout:post
slug:400-duboce-113-now-from-greg-apartments
comments:
category:my life
tags:400 duboce, citiapartments, firstapts, gregapartments

AcaWiki: On Building Emerging Applications

| Nathan Yergler

I’m woefully late in noting the launch of AcaWiki. Mike does a good job exploring the sweet spot AcaWiki may fill between research blogging and open access journals, and where AcaWiki fits into the wiki landscape. AcaWiki is interesting to me for two reasons; first, I was the technical lead on the project†, and second, it’s another recent example of building a site using MediaWiki as a platform. More specifically, we used MediaWiki along with Semantic MediaWiki, Semantic Forms, and several other related extensions as the platform for the site.

The idea of using a wiki for a community oriented site is far from new. The difference here is that Neeru came to us talking about specific ways people could interact with the site — specific structured data she wanted to organize and capture about academic articles. For anyone familiar with MediaWiki and Wikipedia, the obvious answer istemplates; Wikipedia uses them extensively to provide a consistent presentation for parts of an articles (messages about the article, citations, etc). The catch is that for someone coming to a site for the first time, who perhaps has not edited a wiki previously, templates are a bit of inside baseball — you need to know which one to use, and you need to know how to format them in your article. Of course these are trainable skills, but I suspect for many users they’re non-obvious. Semantic Forms lets us provide a form for entering these fields, which is then translated to a template.

The question that comes up when discussing this approach with non-wiki-philes is, “why use a wiki at all? if all you need are CRUD forms, why not just whip it up in Rails, Django, etc?” The question is a good one — a specialized tool almost always has the potential to look fantastic compared to an off the shelf one. And who wants to learn that weird markup syntax, anyway? The thing is, at the end of the day, AcaWiki isn’t a software project, it’s a community project. There isn’t a team of engineers available to help move the toolset forward. There isn’t staff available to fix bugs and write migration scripts. So using off the shelf tools with active communities is essential to achieving any amount of scalability.

As Mike points out, there are some niches AcaWiki seems primed to fill. While working on the site, however, it was clear there are lots of unanswered questions about how that will actually happen. AcaWiki, like many sites that seek to serve a community of interest in a given area, is an emerging application. The data schema isn’t well defined, and we don’t necessarily know how users are going to interact with the site. The goal is to get something that users can use in place; something that provides just enough structure to encourage newcomers, while retaining the plasticity and flexibility needed to grow and evolve.

As I mentioned before, this is not the first “application” we’ve built using this tool chain; we use MediaWiki and Semantic MediaWiki at Creative Commons in many places. We use it to track Events our community puts together, and we use it to track things we’d like developers to work on (NB: the latter is woefully out of date and stagnated; perhaps a negative use case for this sort of tool). We even built a system for tracking grants and projects using it.

Using MediaWiki and Semantic MediaWiki as an application platform isn’t appropriate for every project and it isn’t a cure all; there are real limitations, like any off the shelf system. In some cases these issues are magnified due to the fact that it’s not explicitly designed as a platform. For applications that rely on community involvement and that are only partially defined, it usually either gets the job done, or brings us far enough along with minimal effort that we can see what the real problem we’re trying to solve is.

AcaWiki is an exciting experiment in building community around academic research and knowledge. It’s also another in a line of interesting experiments with building applications in a different, organic manner. There’s some interesting work in the pipeline for AcaWiki, including data dumps, a shiny Vector-based skin, and improvements to the forms and templates used. The most interesting work, however, will be the work done by the community.

† AcaWiki’s founder, Neeru Paharia, was one of CC’s earliest employees, and she turned to the CC technology team for help with this project.

date:2010-01-04 22:44:17
wordpress_id:1209
layout:post
slug:acawiki-on-building-emerging-applications
comments:
category:development
tags:acawiki, cc, mediawiki, platforms, semantic mediawiki, smw, wiki

Read: The Cactus Eaters, by Dan White

| Nathan Yergler

I recently completed a writing class focused on creative non-fiction, specifically autobiography, or memoir (the course title used the former label, but “memoir” seems to be the label most often used for the genre). As part of the course we also read about half a dozen different memoirs with different focuses and styles. So it was a both familiar and a little disorienting to receive The Cactus Eaters, by Dan White, for my birthday. Yes, it’s a memoir. And apparently I placed it on my Amazon wishlist at some point. But I do not remember doing so.

|image0|image1*The Cactus Eaters* tells the story of Dan’s efforts to hike The Pacific Crest Trail with his girlfriend, Allison. The Pacific Crest Trail stretches from Mexico to Canada, covering 2,650, and Dan and Allison are not exactly seasoned hikers when they set out.

Reading The Cactus Eaters, I remembered my own experiences in the Boy Scouts, when we would hike 12 to 15 miles in a day. Remembering the pain and exhaustion I felt about two thirds of the way through a day’s hike, and the sheer euphoria at seeing our campsite at the end of the day — nevermind that I was going to shit in a hole that night — gave me a shallow reference point. The obvious difference is that we were only doing this for a single day, not day after day, covering hundreds of miles.

The Cactus Eaters is an engaging and entertaining description of life on the trail — the travails, the excitement, the strange (interesting?) fellow hikers, and of course, how to eat (or not) a cactus. But it seems to me that at its core, it’s about more than hiking. As Dan describes some of his irrational behavior on the trail, he effectively uses the narrative and reflection to start peeling away the onion layers of custom and convention we take for granted in our everyday lives. Dan and Allison’s time on the trail becomes an experience in deconstructing their (his) “real” life, his identity, and the things that make him “Dan”. The story may start as a description of two people in love, sharing an experience of a lifetime, but in the end it’s about Dan, trying to discover who he is and what he wants. I think it’s interesting that this process of discovery is not one Dan seems to have entered consciously or with consent.

*The Cactus Eaters* is not a perfect memoir. There are times I would have liked to read more reflection on the past, and it wasn’t clear to me until the nearly the end when the story took place. It is, however, an enjoyable read that gave me some insight into the experience of long distance hiking, as well as the evolution of one man’s personal identity.

date:2010-01-03 20:42:59
wordpress_id:1251
layout:post
slug:read-the-cactus-eaters-by-dan-white
comments:
category:reading
tags:books, pacific crest trail, reading

Meta

| Nathan Yergler

My friend and colleague Vern used to joke that it was more fun to write code to help you write code than it was to actually write code. Except that it’s not just a joke, it also contains a truism: if you like to create things, it’s really easy to find things to put off the actual act of creating. Especially if that involves creating something else.

Exhibit the first: When I started hacking on gsc, I didn’t do it because I wanted to dig into version control. I did it because I wanted to blog more, but I “really needed a great theme first”. And I knew that doing it from scratch was foolish, so I decided to base it on Carrington. But Carrington uses subversion, and I wanted to track my local changes, like any competent engineer. And none of the DVCS tools I found handled svn:externals, so there I was, writing a tool to help me develop a theme, so I could actually get around the writing (creating) something. Let’s be honest, hacking on gsc didn’t motivate me to write more. It just let me put off something I wanted to do, in the name of perfection. [NB: I’ve since just given in and begun using Carrington Text; I have a few local modifications, but until they grow sufficiently large, I’m not going to worry about them]

Lately I’ve been getting a lot of spam here that gets caught in the moderation queue. This has actually been nice in one respect: I get to go back and revisit some of the things I wrote in 2003-2005. One thing I’ve noticed is how awful a lot of that writing is, but also how frequent. It’s like it just kept coming and I had to let it out. In contrast, I wrote 14 posts in all of 2009.

I should point out that it’s not that I’m not writing these days. I started journaling again back in 2006, writing for an audience of one. I have a shelf in my bedroom with my journals on it.

|image0|

Since moving to San Francisco, my writing on the blog has declined, and my writing in my journal has picked up more than proportionally. On that shelf, June 2007 through 2009 dwarf 2006 (I think 2006 has one or two notebooks on that shelf; the rest are post-move). One of my hypothesis about the reason for this is about the tools: all I get to pick are a notebook and a pen (or pencil, occasionally); once I’ve done that, I stop thinking about it until one or the other runs out.

This hypothesis is supported by my other writing experience of late; during the fall semester I took a writing class at City College of San Francisco — “Creative Writing: Autobiography”. I didn’t take the class because I wanted to write my autobiography, I took it because I wanted to try writing in a more structured way, and it turned out to be a really enjoyable, productive experience. But when I sit down to edit things on the computer, I immediately start mulling over “Emacs or OpenOffice.org? Should I be using DVCS to track my changes? Maybe flashbake? And if I do, is that one repository per piece, or one for the entire class?” This sounds ridiculous as I write it, because it is; those questions are really entirely irrelevant to the work I want to do. They’re just ways to distract myself from what the actual desired output is.

I don’t really believe in New Year’s Resolutions; reading my abortive journal from 2004, I found a “resolutions” entry containing things that never happened, or that only happened years later. I guess my intention for 2010 is to try and focus on the desired outcome, what I actually want to do. I discovered in 2009 that I like to write. And I’ve known for a while that I like to make things. Maybe one day I’ll have the perfect toolkit, framework, theme, or workflow for that; right now, I can do far, far worse than just focusing on the task at hand.

date:2010-01-02 14:13:41
wordpress_id:1239
layout:post
slug:meta
comments:
category:my life, writing
tags:intentions, journal, meta, resolutions, tools, writing