Posts FromJanuary, 2008

25
Jan 08

Hyperlocal Discussion Boards Launch on outside.in

Posted by john in Development & Features / General — Comments Off

Yesterday outside.in launched a preview of our new discussion boards, where visitors can talk with people around them, ask questions, give answers, rant, weigh in, and so forth.

Now, everyone knows that online discussion boards have been around since almost the beginning of time. So why is this a noteworthy event?

Because outside.in takes the ancient notion of the online discussion board and makes it local. Not just local like some bulletin boards that have a few different boards for a few large cities – LOCAL local. Local in several different ways.

To start with, every city, town, village and hamlet* has a discussion board of their very own. So you can address a question to the people who live around you, and know that it’s going to be viewed by the people around you.

To give you an example, here’s the discussion board for Brooklyn, the city I live in now. Here’s the discussion board for San Francisco, where I lived previously to Brooklyn. And here’s San Anselmo, the little town north of San Francisco where I grew up. Every town in the entire U.S. has a discussion board of its own, just like these, and when you post to the discussion boards at outside.in, you are addressing the people in these towns.

Then, beyond cities and towns, each neighborhood within our featured cities have their own discussion board as well. So you can start a discussion or make a comment to just the people in your neighborhood, too. Here’s the discussion board for the Haight in San Francisco, for example.

Then, beyond THAT, discussion threads get associated with each individual place they reference. So, say you’re talking about the evictions that just took place at 475 Kent Avenue in Brooklyn. If that place has been referenced before in our system, the discussion boards will detect it and associate your post with the outside page for that place. If it’s not in our system, we invite you to give it a place manually (which takes about ten seconds), and thereafter it IS in our system as a place, with your Discussion post attached.

All of these different levels of locality then stack up vertically – place, neighborhood and city all nested together. So if you post a question about a restaurant in Hayes Valley, SF, it not only shows up on the Hayes Valley discussion board, it shows up on the San Francisco discussion board, as well as on the page of the restaurant itself – where other people interested in that restaurant can find it and learn from it, or post their own response to it. In other words, the conversation gets indexed at all of the different levels of zoom that are relevant to it.

What does all of this mean?

Specifically, it means that you can now have conversations online with the people around you – whether that means people in your neighborhood or your city or your town of 5,000.

In the broader picture, it means online conversations can now be indexed and referenced by location. That means that all of the conversations over time about a place become associated with that place, and become part of the record about that place. Locations everywhere become annotated with the conversations you have about those places. Your conversations add value to the places around you, and the places and things around you come more into focus by the conversations associated with them.

That’s online discussion boards, outside style. Please check ‘em out and say hi to your neighbors.

________

*in the U.S. only right now. More countries coming soon, we promise!

24
Jan 08

Outside.in and The Washington Post

Posted by steven in General / News — View Comments

This morning we announced our new partnership with the Washington Post: our buzzmaps for the DC area are now live on the Post site. As you’ll see, these maps are variations of the buzzmaps we’ve created for all the bloggers in our system: they’re tracking all the places that local bloggers are discussing in the DC area, and mapping the top ten places based on overall volume over the past week. But of course it’s not just about the map; there are links to all stories from the blogosphere about each place, along with links to the place pages themselves at outside.in.

One thing that’s important to note: we’re also tracking Washington Post content as well. (If the Post has an article about a place in the top ten, you’ll see an orange slice in that placemarker on the map.) So in this relatively simple page, a number of cool and interrelated things are happening:

First, we’re strengthening the ties between the local bloggers and the Washington Post. (Our investor Fred Wilson talks about this a little today on his blog.) The Post gets a easy way of integrating blog content onto its pages, and the blogs get traffic from — and the fun of appearing on — the Washington Post’s pages.

Secondly, we’re not just geographically organizing the blogger content — we’re organizing the Post’s content. That’s because our system is designed to track geographically pretty much anything that outputs a feed. So building a map like this for another newspaper, in another city, takes us about five minutes. (You can see where we are heading with this.)

Thirdly, it’s an extremely distributed system. We’re not just creating a page that shows you information about a neighborhood (though of course we do that at outside.in.) We’re connecting stories from dozens of bloggers, from a newspaper site, from our own database of places in the DC area, and from Google’s map API — and we’re putting it up on someone else’s site, not our own.

The other thing that’s exciting about this deal — and I hope it’s just the beginning — is that we’re working with the Washington Post, which is not only one of the top newspapers in the country, but also a true leader in their local coverage online. (Their local explorer maps, for instance, are very cool.) So congrats to the team at outside.in and at The Post for making it happen!

22
Jan 08

outside.in switches to Rails

Posted by Cory in General / News — View Comments

In the Fall, outside.in took the plunge and committed to an aggressive overhaul of the back-end of our system. We rewrote the codebase, which was PHP, from scratch in Ruby, using the ever-popular Rails framework. In addition to the change in code, we also decided to switch our back-end database from MySQL to Postgres. And we gave ourselves just 10 weeks to do it. I should also mention that, at the time, only a third of our dev team had practical experience with Ruby on Rails. (I should also mention here that we are currently hiring great Rails developers.)

So why did we make the switch?

Over the first 10 months or so of outside.in’s life, the primary development focus was on proof-of-concept prototyping. Our initial goal was to just build something that worked, and at the time we weren’t sure what parts of it were going to gain traction and really stick around, and what parts weren’t going to be important later on. Making quick changes in direction is of course at the heart of agile development, and we did an excellent job of building a system that allowed us to try new features out very quickly. Still, over time the code hardened somewhat and as we went along we found more and more time was going in to administrative coding. We decided we needed a framework to consolidate the code and simplify further development.

Why Rails?

Christian, the only developer on the team that had prior Rails experience, advocated that we look at using Ruby on Rails for the new and improved outside.in. I had had enough experience messing around with simple programs in Ruby to realize that it’s a beautiful, expressive language, and I knew that Rails was taking the web 2.0 world by storm. Christian started spending about a day a week porting outside.in to Rails to see how feasible a full transition would be.

It’s worth noting at this point that another big motivation for migrating our back-end was that ever since the Where 2.0 conference in May, we had been really excited to use Postgres so we could take advantage of its excellent PostGIS extensions for doing geography-based queries, which are obviously very important to outside.in. The GeoRuby gem and Spatial Adapter rails plugin, which would give us a lot of free GIS-related functionality in Rails gave us another strong reason to look at RoR.

We decided Rails was going to work for us. The benefit of hindsight allowed us to rework parts of the database back-end and code architecture that hadn’t worked very well before when they had been developed ad hoc, and to take advantage of Rails’ Model-View-Controller (aka MVC) separation to consolidate code that had before been spread out and duplicated over many files. The excellent unit and functional testing framework in Rails is one of many useful features that we got for free that would have been time-consuming to build ourselves in PHP.

How’d it go?

Switching programming languages (and training the dev team on a new language), upgrading to a full-fledged framework, and changing database back-ends are all intensive tasks. Any one of them would have been a significant challenge on its own, but trying to do all three at once was especially difficult. Programming languages tend to overlap heavily in the control structures that are used, so the primary hurdles involved in learning Ruby were learning its syntax and the concepts of blocks and iterators. The syntax is pretty easy to learn, since Ruby’s syntax is so minimal it never really gets in your way, but it took a while to get the hang of blocks and yields. IRB is a godsend here because it makes it so easy to drop into the terminal and test something out that there’s no excuse for superstitious programming. Rails is more difficult because it’s so powerful; a lot happens “magically” and it can take a while to understand how all the pieces interact.

Switching hosting providers was a lot less painful than expected, thanks to EngineYard, the Rails-specific, slice-based hosting company that we ultimately chose to go with. EngineYard handles deployment of one’s app, including writing custom deployment recipes, and they were very responsive both on the phone and through their ticket-based support system. I’m very happy to be doing business with them.

All in all, it’s a testament to the flexibility of Ruby on Rails — not to mention the talent of the excellent programmers we have here — that we were able to bring over a feature-complete (and improved!) version of outside.in, with completely overhauled administrative and database back-ends, in under 3 months.

An example of a simple but powerful new feature that we developed after we made the switch to RoR is our customized newsletter. Rails’ ActionMailer makes sending HTML-based emails, something we’d always had difficulty with in PHP, a snap. Just create a template using HTML, the same way you’d create a view for a web page, and Rails handles the headers automatically so that the email is rendered properly as HTML by the recipient’s mail client. ActionMailer also makes it easy to embed the plain-text fallback alternative for mail clients that don’t like HTML. Our geospatial database and PostGIS allow us to use geoblurring to show information relevant to each user’s specific neighborhood in the newsletter when possible, and include popular stories from nearby major metropolitan areas as well. In PHP, we would have had to: wrangle with the PEAR::Mail library for our HTML email, write custom functions for determining adjacent neighborhoods in the system, and we would have had no way to test successful email delivery. In comparison, in Rails we got the email and spatial capabilities for free, and we were able to deploy the fully-featured newsletter functionality, including full unit testing coverage and an administrative interface to preview emails, in just a week!

I compared our old PHP repository to the Ruby one and here’s what I found:

Old PHP version New RoR version
Total commits to svn: 3,702 in 12 months Total commits to svn: 1,515 in 3 months
Total physical lines of source code*: 58,061 Total physical lines of source code*: 11,401

By switching to Rails we were able to shrink our maintained codebase to just 20% of its former size while expanding the overall feature-set of the system. There have been some learning curve-related hiccups over the past few months as we acclimated to a new system, but on the whole we now have a leaner, better codebase, more control over our system, and are developing in a language and framework that are joys to code in. We’re very happy with the switch so far.

* Measured using David A. Wheeler’s SLOCCount. Code not written by us (such as the Rails framework and any plugins we’re using, in addition to the unit tests we’ve written) is not included in these counts. Physical lines of source code is kind of a superficial measure, admittedly, and sloccount doesn’t appear to parse our rhtml or haml views, so there are probably some missing lines of code in the Ruby count, but because we’ve adhered pretty strictly to MVC this time around, most of the code that’s missing in this count is just presentation-level control structures.

Blog WebMastered by All in One Webmaster.