Friday, June 8, 2007

Trendlines and Musings

It seems that there have been several general and successive trends online over the last few years, each driving a certain type of success story (and yes, some overlap exists):

  1. Search (Google,, Y!, tagging on Flickr, etc)
  2. Share (, Digg, YouTube, Reddit, etc)
  3. Create ... this one is still in its nascent phase, but is cropping up more and more, often in conjunction with the first two
  4. ???
My lines of inquiry here are: what is the eventual trajectory for the "create" modality, what comes after it, how can these work together, and what technologies/techniques might offer the best fit in pursuing these new projects?

The creation modality of the net is nothing truly new. We've long seen services that allow users to create and customize their own home pages, and blog services that allow people to post and host their own content.

This creation trend has been expanding into other areas more recently, pulling more varied media types and methods into the fray. Delicious:designer, for example, is an intriguing new tool that gives a pretty slick graphic design interface to its users. There have been spin offs of the "picture a day" internet meme that use Flash to pull images directly from connected web cams into the internet application, automating the creation of an image stream. There are similar services available for creating music mashups or playlists to share with friends (both through links and via p2p, but the discussion of technology will come later).

There have also been some pushes to create services that allow people to create dynamic content, like web games and other small apps, all through simple interfaces. I know that HAppS has some interesting potential here, as do things like Flash, Flex and possibly even Laszlo.

Looking at the progression of create-style web apps, we see a trend of offering more and more control in creating more rich content. The examples that seem to be most successful, in my experience, are those that offer the simplest interfaces, and the simplest hooks to allow people to integrate their creations into the search/share spaces.

Uptake of content is the name of the game. Anyone can "publish" these days. Getting content online takes about half a moment, and even less thought. Getting that content into the hands/eyes/minds of others is the trick. Getting that same content to your desired audience is the holy grail of search/share, and it's why companies have been able to pull in hundreds of millions of dollars in that space.

As more dynamic content is created, there is more noise added to the search/share channels for those media types. Let's face it - it's not all good content that's being produced. So how do end users find good content - and the converse - how do content producers get their content into the channels that will get to good audiences? Well, most of that discussion is for another time and place, but from a create-mode product view, there are several emerging strategies that seem to be doing well:
  • the aggregate and vote system (ie, Digg and Reddit) allows a wide pool of users to filter material, giving exposure to a lot of content, but pushing a certain amount to the top
  • the "email to share" system allows people to push interesting content directly to their friends (making this *easy* and non-intrusive is key, though)
  • social network messaging systems allow people to post to a focused group of consumers, who can then propagate the message further through their networks if they find the content appealing
There are more methods, to be certain, and it will be interesting to watch them as they continue to evolve.

Speed. Simplicity. Engaging.

These concepts have really been at the forefront of the current trend cycle. Agile development and rapid application development help get things from concept to reality in short, repeatable cycles, allowing things to grow organically and respond to feedback quickly. Simple focus - doing one thing really well - has made the use cases for products really clear. This lets their utility shine through, promotes ease of use, and keeps things focused on what works and what's needed. Finally, keeping people engaged has been critical. This is no longer a broadcast world. Commentary, dialogue, edits, versions, iterations - these all form the critical feedback that keeps the system evolving.

The tool sets and technologies that really respond to these things have definitely seen a lot of attention in recent years. Agile has taken off like a rocket. Rails has been going gangbusters, maturing by leaps and bounds. Languages with high ability for concurrent execution have been getting more attention. Tool sets that allow for mixed online/offline utility have been popping up like mushrooms.

... to be concluded in next post.

Tuesday, June 5, 2007

Travelling Salesman Problem: Introduction (in Haskell)

Here's the original link.

The task here is a setup for some stochastic methods of solving the Travelling Salesman Problem. I'm doing it in Haskell since my skills here need work.


Set up a coordinate string. These are the cities in our routes.

> coordinates :: [(Float,Float)]
> coordinates = [(0,1),(1,2),(2,3),(2,4),(0,6)]

This is a simple function that takes two 'cities' and returns the floating-point distance between them using the Pythagorean Theorem

> distance :: (Float, Float) -> (Float, Float) -> Float
> distance (x1,y1) (x2,y2) = sqrt ((x1-x2)^2 + (y1-y2)^2)

This allows us to determine the actual length of a list of cities ('tour'). Note that it's not circular, unlike in the linked article.

The 'let' statement looks up the city in question from the list above and inserts it into an equivalent list.

zipWith is like map, except it takes a two-argument function, and two lists of arguments which are 'zipped' together into a result list.

> tourLength :: [(Float, Float)] -> [Int] -> Float
> tourLength pairs tour = let coords = map (pairs !!) tour
> in sum $ zipWith distance coords (tail coords)

A wrapper, if you'd like to have all tours be circular.

> tourLength' :: [(Float, Float)] -> [Int] -> Float
> tourLength' pairs tour = tourLength pairs (tour ++ (head tour))

The main testing function, which prints the specified tour's length

> main :: IO ()
> main = print $ tourLength' coordinates [2,1,0,3,4]

One thing you'll notice here, is that I'm eliding the matrix calculation in the original source. One of the nice things about Haskell is that a later date, should I choose to do some memoization, there's very little work to be done. Only one of these functions would need to change.

Another nice thing is that if a given pair of cities is not ever used, Haskell (due to it's laziness) won't ever bother to actually calculate the value, even if I do go back and add memoization.

There's more to this, especially the shuffling functions (I'll get to introduce Monads!). That'll have to wait for another day soon.

Monday, June 4, 2007


Mime shouldn't be a capital crime. The first time.

Business metrics

A hypothesis for you: it seems that the more time I have to spend killing time via surfing the 'net at work, the shorter the time I can expect to remain employed there.

Maybe someone should build a small aggregate logging system to determine company health this way...