Computer Programming / Development

It’s hard not to have a love/hate relationship with my region’s website. I think every person who’s ever managed or designed a new version of it has this same love/hate relationship.

• It lacks a clear audience. Presumably, the website is a resource for people who are already leading or worshipping with Disciples of Christ congregations in our four-state region. But it’s also for people looking for churches (either to move to or work at) from other parts of the country. Or it’s for non-Disciples wanting more collaboration, ecumenical partners. Or it’s for people looking for our great camping and conference center ministry. Or it’s for … (the list goes on).
• Like the church, people think it should remain forever. To their point, I agree that permalinks and navigation shouldn’t break (often). But against their point — why do the registration forms for events three years prior still need to be accessible? And why is the website supposed to serve as a fixed repository, a place for them to dump all of their documents?!?
• Often it’s at least 5 years behind the technology curve. And in many cases that’s not a bad thing. Churches who are “early adopters” with web technologies have to wade through the different compatibility issues their users face. They undoubtedly leave people behind. But five years ago, the big innovations were CSS and multiple device stylesheets. That’s what church websites should be current with now. Churches’ websites don’t need direct integration with mobile devices. (I, for one, don’t want to have to figure out how to program against the Blackberry calendar system …) Nor does our regional page need to be coded in the upcoming HTML5 bells and whistles; with so many of our users still on IE7, we can wait a couple of years to get there.

I built the latest version of the website on the Genesis Theme Framework put out by StudioPress. It’s optimized for search engines, it’s secure, and it has an amazing developer community behind it. It saved me a lot of hassle in migrating previous layouts, and it REALLY will save me time for future layouts.

This version of the website also marks a transition from Wufoo (the online form generator I recommend for churches), to Gravity Forms, a Wufoo-comparable AJAX WordPress plugin that is easier to embed in several places of the website at once. While Wufoo is awesome — I wanted something that was plug-n-play.

I’m not sure how long this version of the website will last. The previous version lasted 9 months, so I’d give this one at least 18 months before it needs another major overhaul.

Fridays — often a minister’s day of rest.

With my hybrid vocation, I often still work on Fridays.  And yet, the days still keep some of their retrospective character.  I can look back at my tasks for the week and give myself a sort of score card.

Publicly, I can share some of my recent work.

So, let me set the situation. In June I promised my wife a new website for her church by the end of the summer. Fast forward to the fourth week of August and I’m presenting a workshop at the School for Congregational Learning about congregational website setup and maintenance using WordPress. I get home from a long weekend and Heidi calls in the promise. The summer was almost over and she was missing a website.

Rather than doing everything custom, I retrofitted a stock theme (http://themeforest.net/item/light-of-peace-wordpress-template/120416) to work for her setting.

• I replaced the logo with an “Episcopal” customized one with the Episcopal Shield.
• I added a custom post type for events (treating events like taxonomies and as collections of posts so that any updates to event pages show up in RSS feeds).
• Customized an RSS widget to automatically track the Revised Common Lectionary readings for the week from the Vanderbilt Divinity School Library’s website (http://lectionary.library.vanderbilt.edu/)
• Some other UI tweaks of features that didn’t fit her congregation.

Thankfully, a team from her congregation transported most of the content from their old website to the new one.  They were also experts of this type of fall cleaning: they mercifully cut out lots of garbage or outdated information from the old website.

The site’s live at http://www.stbenedict.ws/

Windows programmers have it easy. Not only are their compiler tools more robust (and therefore, full of infinitely more options — for better or worse), but Windows programmers have some easy network-able source control tools.

My team used to use Visual Source Safe, which came with Visual Studio. Even though it caused headaches and needed a database rebuild once, it was simple.

My team is now using Microsoft’s Team Foundation Server for some of our newer projects. Robust is just the start of the description. Team Foundation Server was crafted for collaboration.

So those are great for Windows programmers, but what am I to do with my Mac programming?

Here’re the needs:

• Compatible with my Mac software: Coda (http://www.panic.com/coda/)
• In the event of a crash, it’s the backup
• So it has to be “off-site” (and not a local install of Subversion)
• I don’t need the collaborative, syncing of latest versions (yet)
• Free is good

So, even though the local install of Subversion is out, that’s still the best source control protocol for Coda.

The best walk-through I’ve seen for this setup is a video at: http://basementjack.com/uncategorized/video-coda-subversion-beanstalk-how-to/

Do any Mac programmers have a better setup?

I should also mention that I don’t do any compiling on my Mac. So I doubt this would work for XCode. I only use Coda.