Context is important. I think we know that. Context refers to the conditions in which something exists or occurs.

It’s important when we read scripture to have an understanding of the context of the verse, not just pull it out and base our world view on the Christian life from one verse.

It’s important when we talk to people to see facial features and gestures, its actually often more important than what the person is saying. Just start using IM for every conversation you have (something I practically did for 8 years) to see this theory in practice.

Its important in relationships when we praise or rebuke someone, that there is an understanding of the context from which that comes.

I believe it is also important to at least think about the context of the content we produce. What are the contributing factors that effect how that particular content in perceived, reacted to, and used. I think some of those questions can help understand the context in which we place our content and better understand what the best avenues are for the content we have to distribute.

Below is a table I have worked up and referenced at times to put my own ideas in context and help me understand what to expect from them.

Some useful links:

• Context in User interface design : “Putting Context into Context“
• The Nature and Purpose of Online Conversations
• Art and Context: Rules and Context
• The Resurgences’ upcoming conference “Text and Context”

RSS Feeds.
Feeds, Feeds, Feeds.

We love our feeds at this church. There is an RSS feed for pretty much every piece of content we put out online, and we put out a lot of content. I have to admit, it is quite a convenient way get the information you want in this over bloated information age that we live in, the only way to avoid information overload, which in some cases can lead to insanity.

They are very convenient, until one of your feeds has an issue and you’re the tech guy charged with fixing it, then it can just be a giant frustrating mystery.

So what is this all about, well, we have many feeds that come out of our Voxpop network site. Voxpop is a site of many blogs and many feeds, but one in-particular has been troublesome, the Voxpop Master Feed. The Voxpop Master feed essentially contains all the latest blog entries from ALL the blogs on our site. The problem stems from the application we use to manage all these blogs, that application is called Wordpress MU. Now for you non blog geeks out there, Wordpress is a very popular open source application that lets you publish a blog and a feed to the blog very easily, and works very well. Wordpress MU is a version of Wordpress that lets you publish multiple blogs, and multiple feeds in one system. The one lacking feature of Wordpress MU, is it doesn’t have an RSS feed aggregator that would produce one feed from all the various blog entries. It does great publishing individual feeds for individual blogs, but nada on the one master feed idea.

So, we did what every self respecting open source user does when they meet a limitation of the software, we wrote our own master feed aggregator. Actually, a very faithful volunteer wrote one, and it worked great, put out a master feed that just about every RSS feed validation tool said was perfect. So, what’s the problem? The problem was feedburner. We use feed burner to give us statistics on RSS feeds (ie, how many people subscribe to our feeds, what is the feed traffic, etc). Feedburner takes our feed, then returns our feed to us, while keeping track of statistics so we don’t have too. Sounds simple enough, but for some reason, feedburner was having an issue with the master feed. It wasn’t automatically getting new content from the master feed. When the master feed got updated with new content, feedburner wouldn’t see it, so the feedburner feed didn’t have the new content. The only way to get feedburner to see new content, was to manually ping the feed using a tool that feedburner provides, but this is very tedious to try and do every day, so we had to find a solution.

One of the frustrations that we faced with this issue is that feedburner doesn’t really provide any information on their side as to why a feed hasn’t been updated. I mean, when we manually pinged the feed, it updated just fine, it said the feed was perfect, no problem. It just wouldn’t tell us why it hasn’t been updating the feed automatically as it was the other feeds. If there was something wrong with the feed, we would have gladly fixed it, but you need to tell us what the problem with the feed is, otherwise, we spend a lot of time just guessing and tweaking, which is where we found ourselves.

So, what now? Well, I began looking around the intertron, and found a feed aggregator plugin that someone else wrote called WPMU Sitewide Feed . Sounded interesting, and exactly what we were doing. So, we tried it out, and it worked great. It did everything we wanted, and feedburner was much happier.

So, we just wanted to say a public thank you to itdamager.com, and recommend this plugin to anybody else who may be struggling with this issue.

Thanks

By Mark Blair

Last episode, I started attending Mars Hill Church and around 2001 it was suggested to me that I check out serving in the Mars Hill Tech Ministry.

Writing code for Jesus, what a beautiful thing, in fact, I had never even heard of such a thing. It wasn’t something they stressed at the public University I attended.

So, what did I do? I contacted the deacon in charge of that area at the time, to protect his identity, let’s just call him Jason (some people actually call him Hugh), and asked what I could do.

He wanted me to work on this thing called the Members Site which was a site for members only that at the time was a bunch of static HTML pages that somebody had put together with a little bit of information on them. The design was nice but not particularly convenient. In retrospect, I wish I had saved a copy of it for historical reminiscing, but I didn’t know any better at the time.

The church wanted a members directory, I guess because they were tired of having members call the office looking for other members contact information. Sounded interesting, especially for a guy who had a little bit of dynamic web site experience, so I said sure and started working on it.

The first thing I noticed was that the members site was hosted on a FreeBSD unix sever. This presented a problem to me because the little experience I had in this area of technology was in Microsoft’s ASP (I had some classes in college that used this). So, I promptly asked to switch our site to a Windows NT server, so I could do what I knew (and honestly, at the time I was kind of a Microsoft fan boy anyway). Jason responded that we couldn’t do that because the hosting of a Windows NT server was like 10 or 20 dollars more expensive a month, that’s why we had the FreeBSD Server, and we didn’t have money to spare.

Seems silly NOW in a church with a budget in the millions of dollars, but at the time the budget was slightly less (or, like, really less). So, thus began my venture into the open source software world, and I think that crucial moment has influenced us in that direction ever since, at least with our back end systems. Sorry Microsofties, if you weren’t such money grubbers, it might have gone the other way (DISCLAIMERS NOTE: This last comment is the sole opinion of the author, and in no way reflects the official views or opinions of Mars Hill Church. In other words, Jesus loves Microsofties too.)

So, I had to learn a new language called PHP, and a new database server called MySQL, which is what that server had available to me. I got a book called “PHP 4″, and learned how to write really bad PHP code. I mean, it was bad. To be honest, that is probably the main weakness of PHP, it lets you write really bad code really quickly, and there is a lot of it around, including mine. To be fair though, at the time, ASP was about the same in this respect, as was most server side web scripting languages.

So, I wrote the first version of the members directory, and it served the basic need. So now we had a Members site that was part static pages, and part dynamic pages (Directory), and I actually kind of thought I was done with it.

Not by a long shot.

Next time…..more work.

A few years back, I (Zack) was working as a Sr. Website Administrator for Amazon.com. It was one of those exciting yet disruptive jobs, where as a group of elite Unix gurus we handled the troubleshooting and resolution of large scale outages of the primary website. The team was very solid and I was happy to be in such good company, but the job came with quite a downside…pager duty.

Not just any pager duty, but $20,000/minute pager duty. That was how much money Amazon was losing per minute of outage back then, so the conference calls were particularly emotionally charged. Good times.

I can remember one evening rather vividly. It was 3am and I had just fallen asleep after resolving a few other pages, when off goes the pager again. Buzzzzz…if you’ve ever been responsible for a pager before, you know what I mean. Even for several months after I transitioned off that job, I still had phantom pager buzzes waking me up in the middle of the night. But, this was a real page, 3am, and I got out of bed without destroying the pager, so I was off to a good start.

I called in to the number on the pager and joined the conference call already in progress. Guess what? The whole site was down, the main database was about to wander off into the weeds, and the ringing of the cash register had come completely to a halt. Amazon.com was down.

Believe it or not, this happened alot back in those days, so my blood pressure and adrenaline were at normal levels and with the excellent co-workers on the line, we managed to track down the root cause of the crash. Complex multi-threading issue in the database server? Nope. Super high-tech part get interference from cosmic rays? Nope.

In fact, it was all because of a typo in a Excel document.

You see, the Technology supporting the setting of a price was so difficult to use that no one bothered with it anymore and had instead built a workaround where they would create a list of prices in Excel and then just upload it into the annoying Pricing program. Excel munged the price, it went to the site incorrectly, and hordes of people tried to buy the drastically reduced but very popular item at it’s pennies on the dollar price. Everything crashed under the load.

This leads us to the second corollary of Principle 1: Ministry will be more effective when there are fewer problems to work around.

Anytime the weird and obscure ways of Technology force ministry to travel the side streets to get to their intended destination, the less ministry will get done. Just like the coffers at Amazon slammed shut with a website malfunction, so too can the reach of the Gospel be cut short when our systems go offline.

Reliability, redundancy, fault-tolerance, three-nines (a reference to the 99.9% of the time we want our websites to be up)…these are all words in the Christian Technologist’s repertoire. If the light in the lighthouse is off, ships will wreck on the shores.

By Mark Blair

I work for a church writing software.

Wow, didn’t see that one coming.

At least, that is what I would have said five years ago, alright, two years ago even. In fact, sometimes it is still hard to believe, but I’m here. It certainly took a while (in my puny human perspective that is), and I can’t always say I’ve been the most willing participant in God’s plan for my life, but God has a way of overriding what I think and I end up doing what he wants anyway.

My story begins in the year 2000. I was a year or so into my technology career when I moved to Seattle. I was young, eager, had an engineering background, and ready to tackle the exciting world of cutting edge technology that Seattle was so known for at the time. I also arrived just in time for the dot crash. Oops, now what.

Well, by the grace of God, I didn’t actually lose my job at that time, although many of my co-workers did, but it certainly limited my opportunity to do the cool things I had hoped to do with technology when I moved here. I really wanted to do something worthwhile with my skills, I now it sounds cheesy but it’s true. Although the company that sustained me through those lean dot crash years was doing some interesting things, it all seemed kind of hollow when I thought about how everything I did just made some investors a little richer, hardly world changing.

Then came the opportunity that was unexpected. I had started going to this little church that met in the evenings at First Presbyterian Church downtown, you guessed it, Mars Hill. I started in the summer of 2000, and around the end of that year or the beginning of the next (can’t remember exactly), I was talking to one of the staff who suggested that I get involved with the tech ministry at Mars Hill.

What? Tech Ministry? Write code for Jesus?

Sounds interesting, sure, i can help out, why not.

The journey starts…..and the story continues next time.

Note - From time to time, the Codex blog will have topics which are not likely generally interesting, but more of a Geeky nature. If it’s tagged ‘Tech Talk’, be prepared for pocket-protector pensees (in this case, skip ahead to Spider-Webs below if you just want the punchline without all the tech talk).

Last night while working on our top secret project, I ran into the following, rather interesting problem.

Background
Just like many applications, there is a place where interesting stuff is created and many places that you want that interesting stuff to go. Theoretically this is just a one to many relationship that Ruby on Rails (for instance) would describe like:


class Content < ActiveRecord::Base
has_many :consumers
end
class Consumer < ActiveRecord::Base
belongs_to :content
end


This is a pretty straightforward but unrealistic model (when does a Consumer only care about one piece of content?) but it allows you to make the following calls:

# first from the perspective of this singleminded consumer
>>zack = Consumer.find_by_name('Zack')
>>zack.content
=> returns whatever was in the source content
# or from the perspective of the content
>>code_is_fun = Content.find(:first)
>>code_is_fun.consumers
=> returns Zack and all his buddies that are interested in the same content


Polymorphism
But what is a good model if you want multiple types of content, that the consumer can indifferently consume? This is where polymorphism comes in nicely. It should be noted that the other name for Polymorphic Associations is Promiscuous Associations, but we don’t like promiscuity around here so we’ll stick with Polymorphic. We will also make it a little more realistic by allowing the consumer to be subscribed to many different channels of content.

Here’s what the model looks like (a bit more complex):

class BlogContent < ActiveRecord::Base
has_many :channels, :as => :pipeline
end
class TextContent < ActiveRecord::Base
has_many :channels, :as => :pipeline
end
class Channel < ActiveRecord::Base
belongs_to :pipeline, :polymorphic => true
has_many :subscriptions
has_many :consumers, :through => :subscriptions
end
class Subscription < ActiveRecord::Base
belongs_to :consumer
belongs_to :channel
end
class Consumer < ActiveRecord::Base
has_many :subscriptions
has_many :channels, :through => :subscriptions
end


So in this, we have a couple of content types that are exposed as a channel which the consumer can then subscribe to. Behind the scenes the Channel model has two columns which make all this happen. They are the channel_id (integer) and the channel_type (string). This allows Rails to remember which original content type to point to and which object id in that model lives in that channel. So whether it’s text or a blog or something else, the consumer can just get to it via the pipeline. What does all of this get us?

Spider-Webs
The killer thing as far as a social network is concerned is the ability to rapidly push content from the edges to the masses through self-organizing channels. When you start to draw what these networks look like, it’s a spider-web of interconnection. Why would a ‘church’ care about this?

Consider this…a small group of people learn about an elderly woman in their neighborhood who has recently taken ill. Her yard is rapidly degenerating through neglect and being Christians filled with love, they want to help her out. What if that group could easily disseminate this information to all other small groups within a 2 mile radius of that house and build an ad hoc service network.


# identify the need
>> need = NeedContent.new(:title => 'Elderly woman needs help')
>> need.save
# create a channel to communicate this need
>> channel = Channel.new(:title => 'Invite neighborhood of groups')
>> need.channels << channel
# invite other groups into this channel via subscriptions if Google says they are within the radius
>> group.subscriptions << Subscription.new(...)
# and so on...


Of course, the channel could have any kind of content…that’s the beauty of Polymorphism! Many interesting possibilities exist once you have the framework for self-organizing channels. Write in with your ideas, we’d love to hear from you.

In Part 1 of the Technology Manifesto, we talked about how Technology Exists to Solve Problems, which seems pretty stunningly obvious right? Well let’s turn our attention to some of the corollaries of this principle and how it directly relates to Mars Hill.

First corollary: You have to solve the right problems, which in turn implies that you know what the right problems are and then work on those first. This is commentary on both discernment and prioritization.

In many ways, Technology is plagued by an over-abundance of possibilities. Every time I sit down to write a line of code or to examine the structure of the organization, there are a multitude of possible outcomes. Do we outsource, or support in-house? Do we buy a vendor’s solution, or let God’s people at Mars Hill worship with their technical skills? What are the problems we have to solve, and what are the problems that would just be cool to solve? I can’t tell you how many emails I get that ask me whether it’s possible to build this neat gadget for ministry X, or a tracking tool for ministry Y. In all cases the answer is that it is possible, but that we can’t pursue that opportunity at this time. It’s obvious then that we have to define the problem, before we can talk about the solution, otherwise the possibilities will dilute the necessary.

At Mars Hill I see that our primary problem, and therefore the first place we have to focus our efforts, is to leverage Technology to extend the reach of the Gospel (that’s the Air War), and secondly to encourage community and the visible demonstration of our Christian love for one another (that’s the Ground War).

Do our websites fit in with these priorities? No, I don’t think they do. That doesn’t mean that our sites aren’t good (in fact, they are very good), but to go the next stage of where God is calling us, we need to take each of them in very different directions. Much more on this topic soon.

Does our infrastructure enable mass dissemination of the Gospel? Again, I don’t think so. What are the primary channels of content distribution online today? Social network shared video content and internet TV, like YouTube, Joost, and so on. Thankfully, there are many folks before me that have been thinking about these things and we’ve got some pretty good ideas on how to move forward, but as you can see, there are many fronts to the Technology war.

Two more corollaries to this first principle and then we’ll be on to the next tenet of the Technology ministry. Mixed in with these posts on the DNA of Technology, we will also begin to pull back the curtain and show you what we are doing at Mars Hill to reinforce these two guiding priorities (Air War and Ground War). In the coming weeks, you will also see screen shots of projects in their early stages and some of our thoughts on how these projects will become integral parts of Mars Hill.

We are very excited to show you what we’ve been working on.