An Obsession with Everything Else

http://www.derrickschneider.com/atom.xml

Friday, November 11, 2005

ThinkFun's Gordian Knot Puzzle

Like puzzles? Like 'em hard? You probably won't find a puzzle with more difficulty per piece than the Gordian Knot puzzle from ThinkFun. (Thanks to Ed Pegg for letting folks know about it).

I ordered the puzzle to bring to work, but I have an earlier edition as well, when it was known as Extreme Torture. I've never solved mine. To get the first piece out of the assembly, you need to make 28 moves. To get the second piece out, you have to make an additional 21 moves. After that, the other pieces come out somewhat more easily. As for assembling one of these bad boys, well, I hope ThinkFun's including instructions.

There is a saying among puzzle designers: "It's easy to make a hard puzzle, hard to make a good one." Part of the problem is that it's tough to define what makes a good puzzle. I probably wouldn't call Extreme Torture a "good" puzzle, simply because any sane person would give up before figuring it out. It doesn't entice you to find the solution. But there's still something intriguing about super-difficult puzzles with just a few pieces (just 6 in Extreme Torture's case). It's less a design than a discovery made via a computer search done by Frans Vreugd and Dic Sonneveld, two talented designers (see issue 58 of Cubism For Fun ).

I applaud ThinkFun for publishing the unusual design, but I feel like this is a "puzzle designer's puzzle," one that's interesting for reasons that the average consumer won't know. Still, perhaps people will be intrigued to find how much difficulty you can cram into a small space.

Wednesday, November 09, 2005

Making a Social Networking App, Part 4 - Two steps back, one step forward

There is a moment in every software project when you see the light at the end of the tunnel. Something works that didn't before, and you feel like you've passed a milestone of sorts. Or maybe a millstone, depending on the task.

In my farmer's market application, one can now create markets, join them, and remove oneself from them. One can not drill down into them, arrange meetups, or do any of the other things one might like to do. One can not attach images or set start and stop dates or any of that.

But it's a start.

So now some time to step back and undo all my work. Well, not really. The code has grown organically, and now I need to be serious about it. The app needs a usable interface. It needs error-checking. It needs security. It needs some refactoring, where I smush all the code around and consolidate common functionality so that I have something a little less haphazard. I'll probably start a blog on it so that users can keep track of what's going on. So keep an eye on it, though be warned that I'll probably wipe out the database from time to time. Hopefully it will start looking like a real application soon.

Sunday, November 06, 2005

Making a Social Networking Application, Part 3 - Making Objects

Before I dove into the code for my Farmers Market Outings application (see Part 1 for an intro), I jotted down some ideas about the system. There are all sorts of tools and paradigms for this kind of work, but my favorite tool is still a sketchpad (or whiteboard). You can draw quickly and add freeform annotations.

I define objects and relationships simultaneously. If you're not a computer person, an object is just a representation of a complex concept, and a relationship defines how the objects interact. This thing contains that thing. That thing is like this other thing but slightly different. If you are a computer person, I'm of course defining classes, not objects, but that's somewhat more abstract for my non-computer readers.

One of the interesting things about Ning is that you don't have to predefine your objects. Usually, you have to make some assertion about the structure of an object. Here are the attributes, here are the instructions you can give to the object, and so forth. Not with Ning. Aside from certain attributes Ning creates for every object, you can define whatever you want on the fly. And, for the computer folks, here's the neat part: Different instances of a class can have different fields. So City A could have a zip code while City B doesn't. It's a bad idea to actually do this, since then you can't predict what will be in an object, but it still seems like a neat feature.

When you're done stuffing your object, you just push it into the Content Store, a freeform soup that reminds me of the data storage commands on Apple's Newton. You reload it with a system-wide ID or via a query to return a set of objects.

The most obvious object in my application is a Market. Any given market has some attributes. There's a geographical component (the Berkeley Farmer's Market is on Center Street at Martin Luther King in Berkeley, California). There's a time component (the market is open year-round on Saturdays from 10:00am to 2:00pm). Maybe the market has a website. Maybe there's a picture of it somewhere.

But a Market also has relationships to other objects. There are people who shop at the market. There are the vendors who sell at the market. There are announcements ("Market closed this weekend because of Easter"). And in my application, there are "meet-ups" associated with the market.

A Meetup is another kind of object (given my slant as a programmer, everything is an object, but these are the main ones). It has a date, a time, and a meeting place. It can be a private Meetup (you want to talk about your boyfriend as you shop with a friend, but you don't want the stress of meeting new people). A Meetup also has a relationship with the people who use the system: They're the ones who will be meeting.

My notes are more complicated than this description. For instance, a market's country is actually an object (Country) which contains some Regions, which in turn contain some Cities. A market's hours (Monday from 4:00pm to 6:00pm) is another kind of object, and a Market might contain several.

Thursday, November 03, 2005

Making a Social Network App, Part 2: Make or Buy

One of Ning's key features is the ability to copy an existing application for your purposes. Clone it, change a few things, and you get the benefit of the original's author's hard work.

Non-developers will no doubt love this feature. I wonder how programmers will feel about it? Like any craftsperson, we tend to be protective of our code, and we're not eager to see someone else slap their name on our extensive work. I'll be curious to see how many career programmers will jump on the Ning bandwagon.

At any rate, why am I starting from scratch when I could leverage one of the applications on the system? I looked at some of the existing apps (Ninglets?), but for each one, it seemed like I'd have to expend as much effort understanding, gutting, and restructuring the code as I would just writing it from scratch at the outset.

This is a classic make or buy decision. Yes, I am technically capable of building the system I need. But then I have to spend the time to build it. I tend to be more of a maker than a buyer, but I've obviously decided to "buy" Ning's core functionality instead of make it. I didn't choose to "buy" an existing Ning application because adapting it to my needs would take too much work. But starting from "scratch" isn't exactly a piece of cake, either. (An aside: an increasing number of people consider cake mixes and their kin to be "from scratch" because you still have to add eggs and milk. It seems wrong, but you're probably not milling your flour or extracting your own sugar, either, so why is your cake "from scratch" while a cake mix cake isn't?)

It's tempting to wonder how Ning users will typically come down on this decision. Even if you find a Ning application that does many of the things you want to do, non-developers are at the whim of the original author. Maybe the code will be poorly commented. Any of the author's bugs will become yours, and you'll need to track it down along with every other person who copies that code.

What's more interesting is to wonder how the Ning community will respond to these issues. Will certain authors be shunned because their applications are typically buggy? Will those who copy an application fix the bugs and send them back to the author? Does every Ninglet developer need a bug-fixing queue? One that all those who copied the application can see as well?

Making a Social Networking Application, Part 1

I was dubious when Ning unveiled itself. It's a neat concept: Give users a web-based tool for constructing social networking applications, systems such as Friendster or Orkut that allow members to associate themselves with other members and self-organize into groups. But I questioned the usefulness of the application. Online social networks, for all the hype they generated two years ago, rarely seem to offer much beyond job searches or online dating. (Web 2.0 zealots could no doubt offer grandiose visions of what they will be, someday).



You can guess what happened next. An idea for a social networking application came to me and now I'm all excited about it. The specific problem I want to solve is to give our friends a chance to join us on our weekly farmer's market forays. We frequent a number of markets, and I want our SF friends to know when we'll be at the Ferry Plaza Market. Or at the Grand Lake market for our Oakland friends. We often run into friends by chance, and it always makes the excursion more fun.



The concept extends in an obvious way: Give any farmer's market attendees a chance to organize "meet-ups" with other local shoppers. Friends could organize shopping excursions, and shoppers could meet new people in their community who share an interest in food or cooking. In other words, give people an electronic way to organize a specific type of real-world event ("farmer's market flash mobs," said my friend Sean). The idealist in me hopes it will get more people to farmer's markets and strengthen local communities. A boy can dream. I envision "farmer's market klatches" that meet regularly for coffee and produce. I see visitors or newcomers to a region using the system to meet local foodies. For instance, Melissa and I could have joined (or organized) a Greenmarket meet-up when we went to New York City.



I decided to give Ning a try. I also decided to blog about it here so other would-be Ningers could see the process. Ning applications are fully exposed—the system makes it easy to copy someone else's code—so there's no propietary information to guard. Keep an eye on this site to see the process. And eventually, keep an eye on the application I'm writing.