Being a big fan of the Greek language, I’ve always got a kick out of the fact that alot of software teams like to use Greek letters to designate how ready their product is for prime time. For those not familiar with it, let me give you a quick run down on what each of the stages of product development looks like..in a somewhat unofficial manner:

In Development (pre-Alpha) - This is the first stage of a project’s life cycle and can range anywhere from, “I had an idea for this thing and I’ll work on it some day” to “we’ve started to hack out some code and test the waters with this concept.” You’ll often hear of something being, “in development” which may or may not mean it will ever see the light of day. For instance, The City has been “in development” up until now. Not all of the features have been written; it’s really wet cement.

Alpha - A wonderful Greek letter (the beginning of the alphabet naturally), that indicates the first “real” release of a project (generally to testers, which in web app parlance means your friends). In this stage, new features and bugs are found as often as the system crashes, (ie. daily). It’s a stage where the etch-a-sketch can be shaken up and the screen reset anytime as the project is definitely in flux. Generally an “Alpha” is released in a very controlled fashion, as system stability, performance, and other factors can jeopardize public opinion if it’s too open.

Beta - The second letter in the alphabet and the next step for a project, it generally designates a more stable environment and a much more open invitation policy. This is when the press releases go out and the buzz starts to build, as more and more people are experiencing the project and can comment positively or negatively about what they see. Being “in Beta” is actually quite nice from a software perspective because you aren’t actually done, so it’s ok to be rough around the edges. Some companies like to stick the “Beta” label on their products indefinitely, kind of like a warm security blanket for the project manager.

General Release - The golden copy is ready to ship and the project is done. This doesn’t happen with web applications in the same way as, say, Office 2008, but there’s still a point where pretty much everything is good to go and the Beta sticker can be taken off.

Last night, The City went Alpha.

After a few weeks of silence, it’s time for an update on all the activity going on behind the scenes in The City Labs. In short, we have been very busy, which only makes sense as we are launching to the first Community Groups on February 18th! We still have quite a few things to do before we’ll be ready, but the Lord has blessed us with alacrity and features are getting implemented pretty handily.

What are some things we’ve recently worked on? Well, at the top of my list, even though it was trivial to build thanks to the hard working crew over at Crossway, is a little feature that allows anyone in The City to reference Scripture in a very easy fashion. Here’s my announcement from The City:

We also implemented some customization tools, so those of you that are coming from a Facebook background will feel right at home as you can drag and drop things on the screen and hide certain portions, if you want. All of this The City remembers for you, so the next time you come back, you see just the things you want to see.

In the events portion of the site, it now supports an easy to use date entry (no crazy click on the calendar and spin the wheel sort of thing), just type in human-speak and the system turns it into computer-speak. You can also see the potluck system in the screenshot below (allows you to identify items for an event, and attendees to sign up to bring them).

We have also extended the neighborhood concept so a new person in The City can see the groups and people around their home or work address and reach out to join those communities. Pretty simple addition with all the nifty mapping capabilities out there but one that reinforces the locality of each person.

I have alot of help pages to write before the 18th, so I’m going to keep this somewhat brief. If you’re in the Greenlake area, I look forward to seeing you in the first wave!

One of the things that I hear pretty frequently from people who first walk through the doors of Mars Hill is that they’re not really sure how they’re supposed to get connected. They might have a desire to serve on a particular team or join a community group, but they’re not sure who to talk to. And with how quickly ministries grow and change, it’s tough to keep track of that information in any sort of centrally managed repository (we’re long past the days where a spreadsheet, even online, could be accurate).

Of course, the ideal scenario would be to give the various info desks and community group desks all the information they need to be able to connect those dots for the newcomer standing in front of them at the desk. So why not build an environment where that can take place?

As I mentioned in the design principle discussion, Administration at the Edge and Content Finds its Target are key principles for The City. In this scenario then, The City would be home to all the Service Groups at Mars Hill; it would be a place for ministry team leads to surface their needs (”we need two more greeter leads”, “we need one more for the beverage ministry”, that’s the Administration at the Edge piece) and for the helpful people that serve on Sundays to connect the interested volunteer to the right ministry (Content Finds its Target, ie. no dropped communications).

The experience for the Info Desk volunteer would change to have a prioritized list of serving needs that they could use in their dialog with the potential volunteer to help match them to the right area of service. Likewise, the experience for the potential volunteer changes to a personal interaction aimed at connecting them into their area of gifting, and then allowing The City to carry the administrative overhead of making sure that they get a timely response from the service lead. No email lists, out of date spreadsheets, or massive central effort to keep up to date with all the happenings…rather, every info desk would be a portal to the needs of every campus.

This same pairing system would be used to help people find a community group to participate in. The community group desk would have The City at their disposal to look for a group that matches the physical locale of the interested attender and, with a click of the proverbial button, forge a digital bond between the community group leader and the potential attender (emailing confirmation as appropriate). With the approval of the group leader, directions could be sent, along with their own “welcome to our group” message, without having to surface phone numbers or addresses in any way.

What’s the goal? At the end of the day we want to enable everyone to know what is the next step in their walk with Jesus. If it’s getting connected as a Member, then it should be trivial to find out how the Membership process works and to kick it off without having to spend time researching. If it’s getting involved in a Community Group, then they should be likewise drawn into the community through the “neighborhood” from my last posting, as well as a highly equipped community group desk system that plugs them into community without barriers getting in the way.

So in this way, The City is designed to be developmental.

A few weeks ago Anthony setup http://vintagejesus.net. I was going to setup yet another deployment bash script on the server, but not all of our applications are deployed with a bash script. I stepped back and decided it was time to bring some order to the chaos of our current deployment strategy. Currently I use a lot of ‘organic’ bash scripts that deploy off of trunk, something I’ve never been a fan of. Mark enlightened me to use tagging to deploy apps. We use Capistrano to deploy some rails apps, so I figured I would set it up to deploy using tags. I was surprised I couldn’t find a plugin that I liked so I set off on building my own recipe.

The basic idea was that I wanted to run something like this:

cap deploy

The script should prompt for a tag, and if none is given prompt for a
tag name to apply to trunk and then deploy from the new tag.

As a bonus it makes rolling back a revision pretty easy. You can just select the previous tag, or use the built in:

cap deploy:rollback

To do this in Capistrano I created a set_tag recipe that lists the
recent tags and prompts to use one of them or create a new tag from
trunk. This updates the base_repository variable. I also had to
overwrite the default update_code action to call set_tag. (You may want to copy and paste it out since the formating gets a little hairy)

require 'rexml/document' #gem install rexml
set :application, "yourappname"
set :base_repository, "http://your.repository/#{application}"
set :repository, "#{base_repository}/trunk" # default, but is overwritten by set_tag

role :app, "some.prod.server", :primary => true
set :deploy_to, "/some/server/path"
set :use_sudo, false
namespace :deploy do
  task :set_tag do
    # get the release path
    depend :local,:command,"svn"

    show_recent_tags("#{base_repository}/tags")
    tag = ::Capistrano::CLI.ui.ask("which tag (blank for trunk): ")
    if tag == ""
      new_tag = ::Capistrano::CLI.ui.ask("deploy from trunk, but you have to give it a tag: ")
      raise Capistrano::Error, "have to tag a new release" if new_tag == ""
      #raise error if there are invalid characters

      raise Capistrano::Error, "invalid characters in tag" if new_tag =~ /[|]|\?|:|\/|\*|\"|\'||\||(\s)/
      cmd = "svn copy quiet message \"cap tagged release\" #{base_repository}/trunk #{base_repository}/tags/#{new_tag}"
      puts  "  * locally executing \"#{cmd}\""
      system cmd
      tag = new_tag
    end

    set :repository, "#{base_repository}/tags/#{tag}"
    puts "repository: #{repository}"
  end
  # Overwrite update_code task to add call to set_tag
  task :update_code, :except => { :no_release => true } do

    set_tag
    on_rollback { run "rm -rf #{release_path}; true" }
    strategy.deploy!
    finalize_update
  end

  def show_recent_tags(repo)

    hsh = Hash.new
    cmd = "svn ls --xml #{repo}"
    puts " >> Listing tags: "
    pipe = IO.popen cmd
    result = pipe.read

    pipe.close
    entries = REXML::Document.new(result).root.elements['list']
    entries.elements.each do |e|
      # set hash key to release id and value to: name by: commit.author
      hsh[e.elements['commit'].attribute('revision').to_s] = e.elements['name'].text + " \tby: " + e.elements['commit'].elements['author'].text
    end

    sorted_arr = hsh.sort {|a,b| a[0].to_i <=> b[0].to_i}
    if sorted_arr.size > 5
      sorted_arr.to_a[-5, 5].each {|t| puts "#{t[1]} \trev: #{t[0]} "}
    else
      sorted_arr.to_a.each {|t| puts "#{t[1]} \trev: #{t[0]} "}

    end
  end
end

Lets take a look at it in action:

cap deploy
>> Listing tags:
cap_test_0.0    by: sfaxon      rev:163

cap_test_0.1    by: sfaxon      rev: 167
which tag (blank for trunk): [type a tag listed above or hit return]

by just pressing return it asks:

deploying from trunk, but you have to give it a tag: [cap_test_0.2]

Next time I’ll show how we took this and applied it to other applications.

Update: direct link to the code above.

Over the last couple of days, Anthony and I have been kicking around the idea of ‘neighborhoods’. Social networks are replete with friendship based networks, and while I love the wonderful friends that I’ve been blessed with, they mostly know Jesus…so who’s my mission field? Stated another way, how can I meet new people that I can share the love of Christ with and invite into community?

This is where ‘neighborhoods’ come in.

Simply, your neighborhood is everyone that lives near you. Pretty basic eh? So why is this a cool concept? Let’s look at a concrete yet fictional example.

John is a community group leader in Ballard; he hosts his group just a little down the road from the public library off Market. He’s got a relatively new group with just five folks in regular attendance. He invites people to his group regularly, but they live all over the place! Ballard draws people from all over Seattle (and beyond), and finding the right people has been tough.

Jim is new to Mars Hill. He attended his first service, stopped by The City kiosk afterwards, and signed up to be “connected”, whatever that means. The volunteer that helped him was nice enough, but Jim doesn’t know what he’s supposed to do next. He lives near the old firehouse on Market, in fact, he works as a Brazilian Jiu-Jitsu coach at the studio there. If only John knew Jim was in his backyard…

This is where the ‘neighborhood’ thing I checked into the code this morning comes into play. John would see in The City that a new guy showed up in his neighborhood (without having to dig for it), maybe The City would even say, “hey, you’re the closest community group!” and John could reach out to Jim with a couple of clicks.

A similar scenario could be played out with a business network downtown…ever wonder who works in your building that goes to Mars Hill? Could be cool to have a lunch group once a week, talk about your life in Christ as you work at the Columbia Tower.

That’s the idea.

From time to time here at Mars Hill Church we receive emails with questions about the work that we do, who does it, what we use to do it and how the magic happens. For the second installment lets look at the website that kicked off the current sermon series, askanything.marshillchurch.org

Q. I’d love to get some background on how you developed the Ask Anything app - a very nice app, by the way. Was it all custom?

A. The short answer is “yes it was custom, thanks”.

The big idea was taken from the letter to the Corinthians, wherein Paul uses his letter to answer some popular questions from the church body in Corinth. We wanted to take a few months to collect questions and then take a one Sunday each to preach and answer the top 9 questions.

Development and design was an all done in-house here where we knew generally what we wanted out of it, though we also let the needs evolve as we developed it, and we could get things going quickly and adapt as need, so it ended up being coding in Ruby on Rails.

We looked into some more off the self type solutions, such as ShouldDoThis from the great Robot Co-op guys here in Seattle, but they often did not offer us enough control over the presentation nor the content posted by users, and any kind of phased approach. Though we wanted it to remain as open and as organic as possible, knowing we were opening this up to the world, we planned to need some level of control over things such as vulgarity, personal attacks and completely off topic questions. We did want our admin involvement to be as minimal as possible though.

Going into it there were a few key things we knew we wanted:

1. We only wanted positive feedback, so we did not go with voting things up and down, we only wanted people to be able to vote FOR something, not against it.
2. We wanted it to have a very low barrier of entry for people to ask questions. So we decided to not have a login. Which we knew meant we could not control gaming the system very easily, but we kind of liked that.
3. Although we wanted it to be easy to add questions, we still wanted good questions. So we decided to limit the amount of characters that could be used to 200. It was a somewhat arbitrary number, but the point was to make people think about the heart of the question and not ramble.
4. We wanted a broad audience, so it should be easy to share the question you asked with your friends. So we made sure each question had a landing page with a URL that could be blogged or given to friends and encourage them to go vote.
5. We wanted it to be sticky, interesting and as fair as possible. So we opted for 10 votes a day and a basic comment section for each question. Then later added a small blogging section and RSS features.
6. We wanted some self moderation by users. So we allowed flagging of questions and comments by anyone. These went to a queue and were reviewed by an admin . If a flagged item was approved then it could no longer be flagged. We later also added the ability for users to suggest a similar questions that should be merged.

Overall the site worked great, and was a success. We ended up with doing 4 phases.

Phase 1- Open voting, where anyone could post any question onto the site and vote 10 times a day on any question.

Phase 2- Site closed to new questions. We stopped taking questions about 2 months into it with almost 900 questions asked. Then allowed a month of continued voting on all questions.

Phase 3- We reduced the available questions to the top 50 and let voting continue. During this phase we also merged similar questions, based on user suggestions. To do this we combined votes from similar questions and if needed we reworded the question to include any content from merged question as well, we tried to minimize those changes though and leave the questions as intact as possible.

Phase 4- Initially we had not planned on it but it became apparent that we needed to limit the 50 questions and focus attention on the most popular so with about 20 days to the end we removed all but the top 20 questions. Many of the lower number questions at that point need too many votes to be viable for th top 9.

What did we learn:

1. Where people can cheat they will. We spent a good amount of time watching and deleting votes from people who voted thousands of times a day. Also there is really no fool-proof way to watch IP addresses and sessions and cookies to be 100% accurate without a login.
2. People have a lot of time to debate theology and talk trash to other Christians on anonymous forums. I often thought we needed to offer an apology to some peoples employers.
3. We love Ruby on Rails. It was confirmed that we like developing in this and is now where we are investing our development efforts for most new projects.

Let us know if you have any more questions and we will try and answer them in the comments.

I’ve written just briefly about The City, but as we get closer to launching the pilot version, I’m going to write much more. So let’s kick this off with a high level review of what The City is all about.

What is it?

The City is an online meeting place for Mars Hill that ties together existing community groups, service groups, and interest/strategically-based affiliations into a social network. This social fabric undergirds many forms of ministry and greatly enables the Ground War. It also enables linking the Ground War of many large communities (ie. networks of churches).

What are key themes in The City?

• Attractional - The City invites those not yet connected to form deeper relationships, get more involved, and become on mission with Mars Hill
• Developmental - The City is designed to show you the next step according to serving in your area of gifting
• Content Finds its Target - The City shows you information that you need/want to see (which you can fine tune). It does not deluge you with so much unimportant information that managing your involvement at Mars Hill through The City becomes a part time job. It also doesn’t show you information you shouldn’t be able to see.
• Administration at the Edge - The City is not centrally managed; every group leader is given the tools and ongoing training they need to effectively lead those they’ve been entrusted. For those business book readers, it’s more like a Starfish than a Spider.
• Real, not Virtual, Community - The City is all about real relationships, real ministry, real life and community change.

How is The City built?

The City is a Ruby on Rails 2.0.1 custom application developed and designed internally at Mars Hill. If you’re a developer or designer and a member of Mars Hill, come hang out with us and get involved.

Why not use another white label social network? (like Ning, etc.)

Stated simply, Mars Hill changes frequently and we need to have the agility to keep up with a rapidly changing organization. I also didn’t want to be tied into a vendor’s release schedule for new features…if we want to make something happen, we can do it.

When will it be available for Mars Hill?

Pastor Brad and I are working through the deployment schedule, but the bottom line is that it will be with Community Groups first, so get plugged into your group, go to the Syncs, and you’ll hear more in the next two months. A lot more.

Over the next several installments, I’ll describe each of the design principles in more detail, giving examples of what those principles mean in the life of The City. My last post, “Location, Location, Location” gave a preview of what favoring Real Community over Virtual Community, but I’ll outline this more fully.

I’m personally very excited about what will be happening through this avenue in the coming year, and I’d ask for your prayers for the team and the faithful volunteers that make all this happen.

One of the design principles of The City, which has guided virtually every decision we’ve made, is that the physical is more important than the virtual. This subtle but significant difference provides the foundation for understanding how this new thing is going to work.

A natural question would be why we emphasize the physical so much, I mean, isn’t this the internet, isn’t the medium inherently “virtual”? The power of the internet (that it is a globally prevalent platform for Technology) can also become it’s weakness if we eliminate the possibility of _local_ community. Let me explain this with an example.

On my Facebook page, I’ve got dozens of friends. Of those friends, I would imagine that about one third are actually in the Seattle area. The other two thirds are people literally all over the world. While there is a certain cool factor in having a virtual Rolodex of everyone I’ve ever known, is there anything more to it than that? Sure, if I’m planning a trip out to one of the areas where they will be, it’s rather convenient, and I get to find out that my college friend is eating a ham sandwich (a la Twitter), but that doesn’t change my life or their life for that matter. When you’re trying to build an intentional community, Facebook just doesn’t cut it. There are too many off topic, off mission sorts of diversions that the game aspect of the site dominates any mission it could try to carry.

Now, Facebook can be incredibly missional for the 1% that choose to use it as a mission field and network specifically with that in mind, but I’m trying to think along the lines of how you get the 80% to that level. The framework will either make a compelling community, or it will not. I don’t believe Facebook ever will do that for the 80%.

Ok, so why local community? Why build an application that is so “limited” to just the physical communities that people are a part of? Isn’t there a huge benefit to a large network? There certainly is! But I believe we need to be selective in matching the right strengths to the right problem, and not inheriting the weaknesses along the way. So we’re trying to make The City all about small communities, but massively leverage the benefits of being apart of a large network.

For instance, we just made a major change to our Members’ site. This is a site which formerly was an all-church forum (2000+ people participating). While it was very cool that so many people were on it, it also led to a nasty Pareto-like problem…about 5% of the people dominated the platform, and the other 95% didn’t participate. Well, that’s not community! So we made a change so that forums are now organized around the physical campus, so each member participates in a forum designed for just their campus, and participation has gone up quite a bit. I’m seeing many more names that have never posted before, now comfortable to participate in these smaller communities which are still part of a singular larger community.

So the next step with The City is to move even closer to where community happens…in every single small gathering where a member of attendee of a Mars Hill campus is involved. I’ll explain more in the next post.

From time to time here at Mars Hill Church we receive emails with questions about the work that we do, who does it, what we use to do it and how the magic happens. This time we’ll start off with one of our more common ones…

Q. I was wondering if you would mind sharing who designed/engineered marshillchurch.org?

A. The short answer is “some great Jesus loving volunteers”.

Over the years, like any good site, the main Mars Hill website has gone though several iterations, as many hands have been put to work for the gospel. A core value of the work we do around Mars Hill and in technology is that it’s all worship, and that has lead to a great team of volunteers who see the design and development of our web properties to be a time of service and worship. The current marshillchurch.org was lead and organized by a few on staff while the execution and implementation was carried out by some very talented individuals who have given countless hours over the years to provide great looking sites that host and deliver our content worldwide.

So that said, we do not currently use outside vendors for the development and design of the site, we do have some more dedicated staff now, but the site for the most part resides in the hands of the faithful; both volunteers and staff.

Have you ever used the site and thought I could do that better, why don’t they do things like this? Then its time to come help out and get connected. Every Thursday is Tech Night at the Ballard Campus and we are always in need of designers, flash developers and whatever code you know, we have a project that can use your skills. So email zack(at)marshillchurch.org or just stop by on Thursday nights.

A few months ago, I (Zack) was away on a personal retreat for prayer and Scripture reading. It was a surprisingly clear day down by the water, and the quietness of being away from the city was quite cathartic. Just me, my bible, and a laptop for note taking…the day was wide open for anything to happen.

But this wasn’t a retreat for relaxation, rest, or anything like that. I urgently wanted to hear from the Lord about the greater purpose of Technology at Mars Hill. Especially pressing on my heart had been the idea of community at Mars Hill…what does it really look like and how does Technology fit into the picture? Does community need Technology, after all, don’t alot of people believe that the golden years of “real” community was in the era before Modernism? Hasn’t Technology just separated us from one another?

I don’t think so. Anyone that comes to our Thursday night Technology meet-up at Mars Hill knows that I believe that Technology is an agent of change just like Writing, Music, or many other creative activities: it can be redeemed and used in the service of the Gospel, and that God calls those whom He gifts with technical minds to serve in their gifting.

Anyway, I was talking about the retreat, so I’ll have to set that aside for a bit.

Later that day, as I was reading passage after passage on community, the pieces started coming together. The City was founded.

Explaining the idea is always difficult at first, but let me try this progression to get you thinking along the right lines:

1. MySpace - first massively successful social network (I know about the others, but that’s just an aside), but MySpace was focused on the individual. Customization was highly emphasized in the context of the individuals page, with the individual’s tastes, etc.
2. Facebook - this took it the next step by generating social graphs around large physical communities (colleges, at first). This was actually a very productive step in the sense of the Gospel in that the emphasis subtly shifted to the physical and away from the virtual community.
3. The City - Radically physical social network of intentional and missional small communities (think Community Groups and Service Groups) within a large community (the campus, then the church, then a network of churches). There’s alot to unpack in that statement, so I’ll have to spend some time doing so, just not this episode…