Subscribe: Coders for Christ
Added By: Feedage Forager Feedage Grade B rated
Language: English
arena  check  chms  church  developer  jason  module  month  network  new  refreshcache  rock  server  system  time  year 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Coders for Christ

Coders for Christ

coding for His Kingdom on earth


Github's Diff Sorta Stinks

Wed, 27 Sep 2017 15:31:00 GMT

Ever make a commit to Git and then look at the commit's diff in Github you say to yourself --"I didn't do that!"  It's probably just diff confusion caused by whitespace.  Here's my change where I just wrapped code with a try catch block:


Here's that same change as seen in my favorite editor's UltraEdit simple diff tool:


This Github secret (?w=1) would have been nice -- if it was working.


Rock, The First Year

Tue, 27 Oct 2015 17:18:00 GMT


What a year. We just wrapped up RefreshCache v7 at the 2015 National Church IT Network Round-table (CITRT) where I was asked to present a 10 minute update on the Rock RMS project. Luckily the hard-working team at Harvest recorded the 10Talks so you can watch it on this YouTube channel if you'd like to get an update on what has happened over the last year.

One thing I forgot to mention during the update was this: "yes, even that beautiful booth we had at the event was donated -- and it was donated by the people who made it, the amazing people at Group Imaging." (If you ever have the need for printed displays, apparel, or promotional items, you won't go wrong giving your business to them.)


At the event, there was tons of excitement about finally having access (it's free) to an enterprise level CMS/ChMS Relationship Management System like Rock. Although we're planning the Rock eXperience 2015 event on Oct 26-27 in AZ, many expressed a desire for Rock specific workshops at this year's CITRT. We'll see what we can do at next year's 10th anniversary event being hosted by our close friends and Rock development partners at NewSpring Church.

Rock McKinley 4.0 News

Some news we leaked was the eminent release of Rock McKinley 4.0. If you looked at the earlier versions of Rock, you might have noticed it lacked some important features. We knew this. It's why the Rock core team's churches couldn't move to Rock. With this next release, it's enabled Christ's Church of the Valley (as of this writing, they're on the 4.0 pre-release) to move to Rock and will enable my church to move off our current Church Management System over the next few months. (Side note: Although there are more organizations using Rock in production we don't know them all. On the site we only publish those who self-report their organization's implementation status and I'm looking forward to finally making our half circle a full circle.)

Rock Support

Another piece of huge news is the Spark Development Network (the 501c3 that manages Rock) is going to take away another reason why some were saying they couldn't move to Rock: support.

If your organization needs to pay someone to help with implementation or help with problem solving, the Spark Development Network is partnering with Kingdom First Solutions who will start offering this as a for-fee service option. We are super excited about this partnership because, not only is the team at KFS is a remarkable group of guys who really understand ministry, they are like minded and like-hearted as the Spark team. Again, Rock is free and you don't have to pay for support, but if you must, now you can. :)

I've got more to say, but that's enough for now.


Rock RMS is Released

Mon, 03 Nov 2014 17:44:00 GMT


It recently came to my attention that someone thought the Rock project was dead because the team members were not blogging about it on our personal blogs. How far from the truth! In all fairness, we probably should have told everyone months ago to go read the Rock blog for the latest details about it. So please go do that now...

Let me just say that Rock McKinley 1.0 was released a few weeks ago and we launched it at the RefreshCache and Church IT RoundTable (CITRT).  We held a pre-event called "Rock Day" and then shared nearly 20 sessions at the main three day event. You can watch most of the recorded videos on the Rock Learn pages.

I could not be more excited about what the future will now bring as we re-grow a new community of developers to contribute solutions for this new free and open source platform.


Simply SQL Loops

Tue, 27 May 2014 20:37:00 GMT

(I'm mostly writing this for myself... to remind myself how easy this can be.)

I recently needed to record some metrics for our prayer ministry using data we've been collecting over the past 5 years.  We had the data in various other tables, so I just needed a quick way to pull them out and insert them into our metric table.

No complex CTEs, recursion, cursors, etc. are necessary when you just need to crank through N sets of date ranges.

Here's an example using monthly date ranges.  All that's needed is a start date, an end date, and the query you need to run for each month (for something BETWEEN 1st of previous month and 1st of current month):

-- Set your start date and end date
Declare @StartDt DATE = '05/01/2009'
Declare @EndDt DATE = GetDate()
WHILE @StartDt < @EndDt
		-- First day of previous month
		--SELECT DATEADD(month, DATEDIFF(MONTH, 0, @StartDt) - 1, 0)
		-- First day of current month
		-- First day of next month
		--SELECT DATEADD(month, DATEDIFF(MONTH, 0, @StartDt) + 1, 0)
		-- Our range will be 1st of previous month and 1st of current month.
		SET @DateA = (SELECT DATEADD(month, DATEDIFF(MONTH, 0, @StartDt) - 1, 0))
		-- Your query goes here... take this abbreviated example
		--INSERT INTO mtrc_metric_item
		--	[metric_id], 
		--	[metric_value], 
		--	[collection_date])
		--	65,
		--	COUNT(1),
		--	@DateA
		-- FROM pryr_request WHERE date_created BETWEEN @DateA AND @DateB
	-- Increment to the next month
	SET @StartDt = (SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, @StartDt) + 1, 0))

For yearly ranges just make the necessary adjustments.   



Rock Beta Status

Wed, 23 Apr 2014 22:58:00 GMT

From a blogging perspective, I've been in a cave for the past 6-12 months helping to get Rock into it's beta phase.  If you are hungry for Rock news, hopefully you're plugged into our podcasts, our Getting Started docs, our Q & A system, or Jon's Rock blog posts.  Those sources will help you know what's going on from an admin/user perspective.  Now that Rock is in beta and the dust has settled a bit, I plan on posting about what's coming down the road -- from a Rock community developer's perspective. That's a perspective that you won't hear too much about on those other channels.

Here's a summary of what will be happening over the next few months:

  • We'll have a developer site with developer documentation similar to the Rock Getting Started guides.
  • We'll have our own Developer Q & A separate from the General Use admin-users.
  • We'll have a Rock Store where we can share (for free or for fee) any packages you develop for Rock.
  • We'll have some tools to help you kick-start creating Rock Blocks.
  • And besides all that, we're planning our own community meet-up at least once per year at the RefreshCache developer event.   At RC we'll have basic and advanced Rock developer workshops, collaborate on Rock packages and projects, and generally do what we've been doing with other ChMS communities at RefreshCache.

So, besides watching this blog for Rock developer news, make sure you plan to attend the Church IT Network Roundtable and RefreshCache event this year at Northwoods Community Church in Peoria, IL on October 22-24.  We're planning our first meet-up the day before the event on Oct 21 -- so be sure you fly in a day early from the normal CITRT/RC event.  Mark your calendars because registration opens on May 1st this year.


RefreshCache is Four Weeks Away

Fri, 27 Sep 2013 03:17:00 GMT

RefreshCache (RC) is four weeks away, so if you've been slacking it's not too late to register. If you do so before Sept 30th, you'll be eligible to win the Surface RT we're giving away.

This year we're experimenting by joining forces with the great guys and gals that run the National Church IT RoundTable (aka CITRT or Church IT Network). Although us web and developer types will have our own sessions, workshops, and round-tables, we will all gather with our IT-network-pro brothers for the general sessions and food gatherings. There should be some good synergy this year.

RefreshCache will make you a better developer. Really! As recently mentioned by Jon Skeet, you should find opportunities to speak at conferences and present to your peers. This is one of those great things that RefreshCache gives you. What other national developer conferences will let us (you and I) speak and teach? Ha!

All kidding aside, I believe in RefreshCache will all my heart. Regardless of which Church Management System (ChMS), Content Management System (CMS) platform, or device you're developing or building on top of, if you're doing any development for the Kingdom RefreshCache is the conference you should plan on attending each year. Add it into your budget. And definitely don't miss next year. If you do, you'll regret it when you find out who we've got lined up to speak and present.

Although it's better to give than to receive, we know for certain that "he who refreshes others will himself be refreshed." (Prov 11:25b)


Rock ChMS Update

Wed, 13 Mar 2013 00:03:00 GMT

A little over a year ago the Spark Development Network was formed and at RefreshCache v3 we announced our intentions to begin developing a Church Management System called Rock ChMS.  Where are we now? Well, hopefully you've subscribed to the semi-regular newsletters we've been sending out.  If you didn't, go do it right now (bottom right corner of the Spark Dev Network home page) before you continue reading... I'll wait here. Over the past year the guys on the Rock core team (such as David, Jon and Mike Peterson) have been coding like mad.  These are the hardest and smartest working guys I know.  Sometime during 2012 the first phase was completed -- an entire modern application development framework and CMS was created from scratch!  It's got all the bells and whistles you'd want in a modern application development framework: Entity Framework, LINQ, REST api, Bootstrap adherence, integration with a job/task scheduling system (Quartz), etc. And then the team moved on to creating additional features needed to build the ChMS parts of the system including: a Workflow engine, a generic Group and Attribute system, reusable UI Toolkit, etc.... and also began creating the core ChMS functionality. For a few months during the summer of 2012, my church dipped our toes into the development waters and gave Jason and I official time (albeit part-time) to work on Rock during office hours.  (Up to that point, we were only contributing a little during our personal free time.) Now as of Jan 2013, Jason and I have begun working more regularly (I'm still part time due to other baggage responsibilities that I deal with) simply because we're now actively planning for our future -- to use Rock ChMS here at our church when it's ready. Part of my job has been coding up some of the smaller features and building the ever-growing live Rock developer wiki (an ePub snapshot is also available and looks pretty decent on the iPad). Jon gave an update at the recent National Church IT Network Roundtable showing a nice slide with progress bars representing the status of the big ChMS features. [insert slide here].  He also did a demo of his very sweet and simple Rock Installer and David Turner showed the check-in system -- built entirely on top of the Workflow engine. It still blows my mind seeing that in action.Ok, so there you have it. I'll probably be "heads down" for another 6 months until I pop up for RefreshCache in October.  This year we're holding RefreshCache alongside the Fall National Church IT Network Roundtable (CITRT) in Kansas City.  Keep your ears open and look for the registration announcement on the CITRT events page. Don't miss that event! If you do, you're going to regret it later. [...]

Server Swap Leads to SPN Discovery

Wed, 06 Mar 2013 17:01:00 GMT


I thought I understood DNS and naming enough to make a seamless server swap/upgrade, however during our test attempt to 'upgrade' one of our internal servers we ran into problems that ultimately was due to something called the "Service Principal Name".

Here was the scenario...(the server names used below have been changed to protect the identity of the guilty)... also this was done in a test environment first so no actual users were harmed during our discovery...

  1. Our users access this webserver via it's logical name, http://chms/.  That logical name also happens to be the actual Windows server name, "CHMS".
  2. Our new server is called CHMS01 and http://chms01/ works fine, however we wanted our users to continue using the logical service name, http://chms/
  3. Problem - when we updated the "chms" A record in our DNS to point to the IP address of the new CHMS01 server, IE users began receiving an authentication challenge which they don't usually get.  Even worse, if they entered their correct credentials, it would not accept them.  No bueno.

After Derek and I did some theorizing about what must be happening behind the scenes that might be causing this weird behavior, we consulted Google.  After 30 minutes of reading we both came upon something neither of us had ever encountered before, the SPN or Service Principal Name.

Looking at our CHMS server using the command "setspn -l CHMS" we saw that it indeed had a record that was causing the interference:

Registered ServicePrincipalNames for CN=CHMS,OU=Servers,OU=Computers,OU=Resources,DC=centralaz,DC=com:

Without wanting to spend too much more time on understand the SPN, I concluded it's basically a Kerberos authentication safety measure that prevents automatic credential passing to a server other than the 'principal'.  Once we removed those records using the "setspn -d HOST/CHMS CHMS" and "setspn -d HOST/ CHMS" records, IE passed credentials to CHMS01 without any issue.

We'll probably make CHMS01 the principle for those "chms" entries by using the "setspn -s HOST/CHMS CHMS01" and "setspn -s HOST/ CHMS01" commands, but for now it did not make a difference in getting things working again.  Anyhow check out Derek's blog if you want to hear his perspective on this topic.


Mobile Phone Check-in

Thu, 05 Jul 2012 21:42:00 GMT

Last year I told you about our problem of trying to check-in 1750+ kids ( at roughly the same time to avoid the long line that growing as our Vacation Bible School program grows each year.  I hinted that the solution might be to allow people to use their mobile phones to check in... Presenting - Mobile Check-in!  Works on any mobile device (at least the ones that people are actually using ;) that has geo-location services.Over the past several weeks, Jason and I have been adding the missing features, re-skinning, polishing and testing a variant of our custom Checkin Wizard module for Arena ChMS.  (Internally we've been calling it v1.5.0, but I'm still not sure if it will get merged back into the current Arena ChMS code base on our Redmine repo.  But, this is the kind of magic we'll be adding into Rock ChMS for sure.)Although it was a relatively simple set of changes, we still ran into enough 'gotchas' that made the project linger longer than we both wanted.  It's still just a web app, so the person doesn't need to install anything on their phone (because frankly, they don't want to have to install a church app on their phone -- they've already got their Bible app, so what more do they really need?)  Seriously, I've mentioned this topic at previous RefreshCache events -- many others balk at the idea writing separate apps for iPhone, Android, Blackberry, etc., and even though there are frameworks/tools that will let you more easily build a native app wrapper around your HTML "app", I still say "people don't want to install your app."  With the coming HTML5 storm coupled with changes by vendors to allow web apps to have the same access to hardware that native apps enjoy, I feel stronger than ever with my argument.For now, the only thing we really needed was access to the person's location.  Thanks to the team over at Geo-Location-Javascript for their JavaScript library and their use of the MIT License, we only needed to work out the details of mapping the person's geo-location to a particular kiosk at one of our four campuses.  We decided that if you're within .5 miles (configurable, of course) of our campus you're close enough to check-in, otherwise you're still too far.Once you're on campus, if the event's check-in start time has started you can check-in using your phone number.  In the future, it would be nice to automatically access the devices mobile number directly and try to find a matching family first, but for now it's still better than waiting in line to use a public kiosk. Major props go to Jason because he did a sweet job taking our existing module's markup and making it look amazing using his mad CSS styling magic skills.I'll let you know how it all goes sometime after next week's VBS... [...]

CrowdSync - All Your Phones Are Belong To Us

Sat, 24 Dec 2011 16:22:00 GMT

An Idea A few months ago Kim Vehon, from our Worship team came, into our office to share a video showing a bunch of phones hanging from wires flashing on and off. It's pretty cool. She wondered if we could do something like that during our Christmas services at Central. Building a "fat-app" to control a bunch of phones wired together did not seem like a challenge nor interesting enough to be worth pursuing. A Better Idea But then we started thinking. What if we tried to control the congregation's phones and what if we used only their existing 3G network connection?  And, since hardly anyone would want to install an app from the market/store, what if it only used their phone's web browser?  We also thought it should be built in such a way as to reduce the dependency on the network -- in other words the phone should get what it needs from the server and then be able to loose network connection without impact to the performance. Game on. I agree with Jason (tweet), this might be one of the funnest things I've worked on in a long time. Jason and I call our software CrowdSync...  Ultimately we also needed to generate a lights time coded "track" from a Christmas song (midi file) with each note being assigned to 1-4 colors.  A person's phone would receive the track, be randomly assigned one of the four colors, and start playing the track in sync with the band.  Sounded simple enough. Thankfully I found the C# MIDI Toolkit code from Leslie Sanford that reads midi files (thank you Leslie!) which I was able to modify in order to extract and generate our time coded light track as JSON data which looks roughly like this: { startTime: 123578916, endTime: 12345667, ticks: [ { notes: ["a"], time: 27, duration: 900 }, { notes: ["b"], time: 982, duration: 900 }, { notes: ["c"], time: 1940, duration: 900 }, { notes: ["d"], time: 2908, duration: 900 }, ... ]}   The Time Problem Pretty quickly we eliminated web sockets and other client-server signaling technology for a variety of reasons including lack of consistent device support, chattiness, lag, and timing control.  We wanted to constrain ourselves in order to force us to think differently about certain problems -- such as the "how do we get all of these devices/clients to start at exactly the same time?" problem. Initially we were thinking we could rely on the time from the phone's operating system.  You might think two 3G Verizon phones would have the same time, right?  Wrong. Very wrong. We saw phones that were off anywhere from several seconds to a few minutes. (Who knows how or where each phone is getting its time from? It doesn't appear they're using a common Network Time Protocol (NTP) server.) After some medium scale client tests and experimentation, we came up with the following approach:  Each client asks our server for the current time, calculates the delta (from it's local time), and repeats this about 20 times over the course of about 20 seconds.  The error introduced because of network latency is reduced to a minimum because we use only the 'smallest' delta from our samples. Once we've got the correct delta we calculate and shift the entire track's note times to represent the exact localized time each particular note should play (light up) on that device.  Then we basically wait until the note's time occurs and set some CSS to play that particular note's light. Other Stuff Since not all browsers can handle HTML5, we had to keep things simple and used basic HTML, CSS and JavaScript (CoffeeScript).  Other problems worth mention[...]

5th Generation Arena ChMS Website

Fri, 18 Nov 2011 15:57:00 GMT

Today marks the launch of our 5th Arena ChMS powered website.  This time around it was more of a cosmetic face-lift, and as far as the switch-over was concerned, we used all the tricks we learned last time to make the change very smooth (more on that below).  The bulk of the switch took 8 seconds (scripted), about 1 hour of minor manual tweaks by Jason Offutt and I, followed by roughly 4 hours of additional fine tuning by Jason Ake. A few lessons were learned during the 4th generation site (aka Hasselhoff) which were largely based on feedback we received from the congregation and staff.  Gone is the campus selection integration that was initially prevalent after the initial launch in the summer 2010.  Now the only place a person needs to think about which campus they care about is when they're exploring the calendar, giving online (since one of our campuses has a different giving system - ugh), and when they simply want information about our different campuses.  It mostly turns out that people don't like campus separation/segregation.Although the new site is based on the "Elegance" theme, props go to Jason Ake (our new web designer) and our graphic artists, Jeremy Wagner and Mitch Eiler, for their many cool elements and tweaks.  Most of the cool code changes including the newly tweaked event calendar, our Facebook login integration, and Vimeo video wall come from Jason Offutt, who's continually pushing me to learn the latest techniques and libraries.  To that end, this time around we used a little Mustache, Backbone, and as we discussed at RefreshCache 2011, we wrote some of our JavaScript in CoffeeScript.  Our promotion slider (seen here) is still based on our Promotions via XSLT module but this time around our XSLT spits-out Awkward-Showcase jQuery library goodness to handle the transitions and widgety-thumbnaily UI.  The recent blog entries that are pulled into the the home page is using a slightly customized (I added caching) version of Arena's standard XML File Transformation module (which I just posted to the shared repo here).  Lastly, we also used the Promotion via XSLT module on a standalone page to "feed" our Arena based promotions into our "Welcome" Facebook page as seen here: Overall these changes took our code team between 2-4 weeks of execution time while all the rest of the project work took Jason Ake between 2-3 months of planning and execution. Now, about the planning, staging and cut-over...First of all we decided to ease our pain by creating four new Arena templates which would roughly match our previous four (home page, child page, single column page, and wide page). In addition to that, whenever possible, we used identical "area" (placeholder) names inside the templates.  These two steps alone simplify the cut-over tremendously since our cutover SQL script now basically only has to change (for example) pages that use template 65 and update them to use template 77, etc.  I highly recommend you use this same technique when upgrading/updating your website from generation to generation.Once the templates were created/beta we also immediately added them to our production Arena install so that we could get their final templateID (for use later when writing the cut-over script).  At that point in the process it's also a good idea to add any new pages that you're going to want in the new website and just set the "Display in Nav" to false.  On the day of the cut-over your script can surgically flip that bit to make it show up.  At about t-minus 2 weeks we copied our production Arena database and Arena website folders into a new test instance for testing the cut-over scripts. We adde[...]

Rock ChMS, An Open Source Church Management System and CMS Framework

Mon, 10 Oct 2011 20:11:00 GMT

(image) I've joined forces with an initially small team of developers and artists to form the Spark Development Network ( and we are creating a new, open source Church Management System (ChMS) called Rock ChMS. You can read the press release if you wish.

This may come as no surprise to some of you after hearing me last year at RefreshCache ( and previous rants on why open source is the best option.  Last week I reviewed my "State of the Union" presentation from last October.  Reading that now, you might think that Rock ChMS was already underway; however our group had not even had a single discussion about anything remotely related.  Over the years several groups tried to apply pressure to our vendors to release open source versions of their product and I think we waited as long as we could, but in the spirit of RefreshCache, decided to just make it happen on our own.
Although everyone at Spark Development Network will have slightly different reasons, basically we wanted to collaborate on a framework that was free for the Christian Church and para-church community, that's beautiful, easy and simple to use, easy to administrate, open source and easy to develop against for the church developer community.  For those who want to eventually run their church on Rock ChMS, should they ever encounter a mission critical bug, their developer can jump in and fix it without having to wait for an official patch.

Rock ChMS is only a pre-alpha seed at the moment, but the source is now open and publicly available on Github: This was done so that others could collaborate and get involved from the earliest days of the project.  Rock ChMS is going to be a full featured Church Management System built on top of a custom CMS application framework, so you may find it's similar to other CMS frameworks you've used in the past. It's an ASP.NET 4.0 Entity Framework application written in C#, so if you’re serious about wanting to help The Church, then git on over to GitHub and fork the repo. When you're ready, submit a pull request and we'll take a look at your work. If you're interested in knowing more or want to get involved in other ways, sign up on our Stay in Touch page.


Grouping Arena Module Settings

Tue, 27 Sep 2011 23:26:00 GMT

Something I've been meaning to have added to the Arena Custom Module Developer (ACMD) guide is this little known feature that was introduced at some point in the past few years.  It's a way to group your custom module's settings as seen here: The effect is subtle, but when you have 20 or so settings like we have in our check-in module it starts to become really necessary (of course we haven't yet added groupings, but we will in the next release).To create these groupings (aka categories) all you need to do is include the System.ComponentModel in your using section:using System.ComponentModel; ... and then define a Category attribute with a grouping name argument for each module setting as seen in this example:// Styling Group[TextSetting( "Search Button Image Path", "Relative path ...", false ), Category( "Styling" )]public string SearchImagePathSetting { get { return Setting( "SearchImagePath", "", false ); } }[TextSetting( "Search Button CSS Class", "CSS classname...", false ), Category( "Styling" )]public string SearchButtonCSSClassSetting { get { return Setting( "SearchButtonCSSClass", "", false ); } }[TextSetting( "TextBox CSS Class", "CSS classname ...", false ), Category( "Styling" )]public string TextBoxCSSClassSetting { get { return Setting( "TextBoxCSSClass", "", false ); } }// No group defined -- these go into a "General Settings" section automatically[NumericSetting( "Return Results Page Size", "The number of ...", false )]public string ReturnResultsPageSizeSetting { get { return Setting( "ReturnResultsPageSize", "10", false ); } }[...]

VBS Check-in Process Improvement

Tue, 26 Jul 2011 00:15:00 GMT

This year we had a little more than 1750+ kids use the automated check-in system for VBS across three of our campuses.

Looking at this graph which shows the number of check-ins per minute, you can see check-in does not ramp up as sharply as we would want on Monday (red).

(click for larger image)

By Tuesday (blue) after some adjustments were made and parents knew the routine a bit better, check-in ramps up quicker to about 50-60 kids per minute and 28 minutes later the lines were gone and the majority of kids were checked in.

It's OK, but not great. Ideally, you'd like to check in 1500+ kids per minute and have check in last one minute.  Not realistic or necessary since not all parents arrive exactly on time.  Perhaps 150 kids per minute is a goal.  Then check-in only lasts 10 minutes.  What will it take to reach that goal?

With some analysis, we found that it takes about 15-18 seconds per parent to check in their kids.  It turns out, much of the time it takes for someone to check in using our system involves punching in the phone number (see this video).  That's something I already knew, and it's one of the reasons why I wanted to keep barcode scanners at all our campuses. (a battle I lost -- for now).  If a parent uses a barcode they shave 6-12 seconds off that time (depending on how slowly a person normally types in their phone number) and they can check in their kids in about 4-6 seconds.

So if we don't start using barcode scanners again, I think the only thing we'll be able to to is drop in more, cheap, iPad kiosks... unless we start letting people check in using their mobile phone when they arrive on campus...


Eddy Currents Can Trap You

Fri, 24 Jun 2011 13:48:00 GMT


Our current church management system has been falling behind.  The Visual Studio precompiled website solution we get with the SDK still targets the .NET Framework 3.5 and this morning I ran into my biggest issue to date:


I can't use the NuGet.Core library in my new module until our current vendor either updates the solution to target the .40 framework or I figure out a way to get around this hurdle.  I don't think I can safely just change the build target on the solution since it's precompiled...  hmm.

Once I figure that out, I'll move onto the other problem.  The system is still using jQuery 1.3 (circ. 2009).  Yes, jQuery 1.4 was released at the beginning of 2010, 1.5 at the beginning of 2011, and 1.6 was just released last month.  I'm beginning to understand why President Roosevelt uttered the words "the only thing we have to fear is fear itself."

Any suggestions?


Custom IE Error Page (DNSERROR.HTM)

Mon, 20 Jun 2011 22:22:00 GMT

When you use a web based kiosk for your attendant-less check-in system, you should think about what's going to happen if your network fails you -- especially if you're using the 3G network.  This is what you'll see if the kiosk cannot reach the server:


That page is especially problematic if you don't have a keyboard because there is no way to refresh/reload the page if the network starts working again.

Luckily you can customize this content... it's just a pain to do it but I'll show you how.  Here's what our page now looks like:


The button is a nice feature because it's basically just going to load our check-in system page again.  Without that, in the past someone would have to reboot the whole system (pressing F5 on an stashed-away emergency keyboard would have also worked).  It's also worth noting that since you can use javascript in there, you should even be able to do something more sophisticated such as automatically retry every few seconds, etc.

Here's how we did it:

  1. Download a Resource editor such as Resource Hacker. I read that it is possible to edit .mui files using VisualStudio, but after about a half hour of fail, I found Resource Hacker and it did it quite easily.

  2. Grab a copy of your kiosk's ieframe.dll.mui file (found under C:\Windows\system32\en-US\) and stow it away for backup purposes.

  3. Use Resource Hacker and edit the ieframe.dll.mui file.  Navigate down into the "23" folder (aka HTML folder) and select the DNSERROR.HTM item like so:


  4. Make your changes.  It's just HTML, so you know what to do...

  5. Press the "Compile Script" button.

  6. Save the file and quit.

  7. Copy the file over to your kiosk's C:\Windows\system32\en-US\ folder.  If you're unable to, because the file is in use or similar, just rename the live file (oddly Windows let's you do that) and then copy the file down to that folder.

  8. Start IE and kill your network to see the result.
Is this a hack?  Of course, but it works. We're using an old version of IE, so you're mileage may vary. I'd consider switching to Chrome for our kiosks (since you can start chrome in -kiosk mode too) but I can't seem to find any information on how to customize its equivalent error page.  Let me know if you've found another way.

Patchy Philosophy and the Bug Free Software

Thu, 16 Jun 2011 03:17:00 GMT


[note: This is an especially 'angry coder' post -- so I encourage the the faint of heart reader to simply skip this article.] 

Although I hate to admit it, I know there is no such thing as bug free software releases.  With testing and a solid QA process in place, you most definitely can drive software defects in new releases toward zero. However, the more complex the software is, the less likely it will come close to zero.  Some have argued from a business perspective it's not cost effective to even try to reach zero bugs.  Personally, I think it's your obligation to do your best to find and kill bugs before your customers do -- if you want to keep your customers and your business.

What to do?  Shall we developers simply pretend bugs don't exist and keep on creating new releases?  Certainly not.  Patches to the rescue.

When you haven't yet proven that you can release software with little to no defects, you are obligated to follow the patch principle.  Your customers are counting on it.  The idea is simple.  After you release a new version of your software (major or minor release -- any version that introduces new or changed functionality) you promise to quickly and frequently release patches for the bugs that are reported by your customers.  You must not wait until the next release because guess what...there will be more bugs in that release too. (To think that 'the next release will not contain bugs' is to misunderstand developers and software development.) You should not wait and batch them up either and you should not endlessly test the patches for weeks or even days. You create and release them -- quickly -- as your customers are broken until they've applied that patch.  They are at your mercy.  It's up to you to establish a solid, reliable patch process your customers can count on.

So, as we move into the future, I intend on pushing this same philosophy with the two open-source software projects that I'm involved with. Both of these new management systems (Grassroots and ****) will not suffer from the patchy philosophy syndrome.


Remote, Mobile, 3G, Check-in

Wed, 15 Jun 2011 14:11:00 GMT


When we launched our Queen Creek campus at the Queen Creek High School, we decided not to rely on the local network there.  Having learned our network reliability lessons when we ran a test church at Campo Verde High School the year before, we instead decided to put some trust into the 3G cellular network. So far it's been pretty solid.

Built not for looks but for quick setup, tear-down, and storage, this 'kiosk on a cart' solution was somewhat based on Daniel's "network in a box" configuration and our custom check-in Arena module.  The cart includes a self contained network using a used Cisco 800 series router with a 3G card that creates a VPN tunnel to our main campus.  If IT and Networking are your gig, you can read all the details about those parts over on Derek's blog.

If you're wondering if it's fast or even usable... check out this video of me doing check-in of some test children during a live, normal weekend.

frameborder="0" height="277" src="" width="444">

Every time I see the labels print out with this setup, I'm amazed.  The browser on the kiosk is talking over the 3G VPN network, to our web server which is then sending a local print job to a printer called QC1 (or QC2), which in turn is defined to talk to the printer's print-server on a particular static IP back over the 3G VPN network.  Back and fourth over the 3G network without a hitch.

One more important thing to note. Notice how fast we can punch in a phone number? Unless you're using iPads or some other non-mouse/keyboard device, you might need to change your registry's DoubleClickSpeed setting. We've set ours to 50. That setting defines how clicks are interpreted by the OS, so if the number is too high the OS won't interpret two very fast clicks (screen touches) as two single clicks.


Mind Storm

Sat, 11 Jun 2011 14:02:00 GMT

Here are a few of the things swirling around in my head that make it hard to sleep...

  • thinking about new friends I met in North Africa that live in tents (refugees) and have lost everything due to the revolution
  • having so much side work I have to turn customers away
  • emails I haven't responded to
  • still top-secret and not secret side projects such as Grassroots
  • the need to do more RefreshCache 2011 prep work
  • thinking about how to keep up with news, software tech, tweets, feeds, and friends
  • trying to figure out when we can upgrade our Arena to a newer version
  • potential security holes
  • bugs
  • bed bugs (not that I have any -- just knowing that they exist somewhere out there)
  • Quantative Easing 3
  • thinking about and publishing a list of things that are keeping me awake at night
  • recursion
Ok, they say if you just write things down that you'll feel better and can get back to work. We'll see if that works.

I'm Defeated: Community Communications

Wed, 16 Feb 2011 18:20:00 GMT

(image) I admit defeat. I can't keep up with all the community posts in the Arena community forums anymore.  Actually, I would have to say it started at some point during 2010.  I just would not admit it until today.  I guess this might also mean the.Community has become a pretty successful tool for certain things ArenaChMS!

Anyhow as a result, I'm finally changing my forum's subscriptions -- unsubscribing from about 90% of them.  I just need to keep the most essential ones... and I'm lucky I went in there.  I also just discovered several new forums for the community developers, namely the Developer Alerts forum. Perhaps that forum will be used to announce when a Arena deprecates a method from their class library API...



Using Firebug in IE

Tue, 07 Dec 2010 15:39:00 GMT

If you're developing complex modules for your Arena website, you'll probably need a tool such as Firebug (a plugin for Firefox) to test how your CSS changes will effect layout in the browser.  Once you've used Firebug you'll have a hard time trying to manage without it.That's great for Firefox, but what about IE?  With Firebug Lite you can also have much of Firebug's great functionality inside IE too -- you just need to add a script reference into the "head" section of your webpage...If you use our custom Inject Javascript Arena module, you can have that (or any other javascript reference) put directly into the head of the HTML with a few simple module settings:And if you add it to your site's Arena template and only allow admins view permission to that module, it will have absolutely no impact to anyone else.  Enjoy. ** You also need to add this "bookmarklet" (Launch Firebug Lite) to your your Favorites in IE which is used to start Firebug Lite.[...]

Media Files:

Jason Offutt == JSON Data

Thu, 25 Nov 2010 15:40:00 GMT

(image) My good friend and co-worker, Jason Offutt, recently started blogging over at  (Yes, not only is he a developer and an artist, he's also a great writer!)  In our spare time, Jason and I have been working on a couple of open source projects. One of them, his baby, is an MVC web application for allowing organizations to start giving campaigns w/sponsors and the other is still very young and undisclosed. The topic of open source is a frequent discussion among the guys involved in these projects and Jason just wrote a great article about open source development in the .NET world --- which is something many non-MS developers may not realize is happening.

As I mentioned at RefreshCache, it's a shame when can't utilize the tools and experience we've gained during our regular job when we continue the work of our ministry in the off hours; whether we're helping build a website for an orphanage in Nepal or writing software for a parachurch ministry.  We love Arena ChMS as application development framework, but it's not open source and we just can't use it for our other projects.

We can't control the choices of our vendors, but we can control our own actions. This is part of the reason why Jason and I are involved in these other two projects.  I'll be posting more about all this early next year.  Happy Thanksgiving!


Silence: the moral dilemma on hiding a Facebook friend

Thu, 07 Oct 2010 02:31:00 GMT

Yesterday I used the "hide" feature on Facebook and I'm torn over it.For me, the Facebook trend had become something I dreaded because of a particular person I know who doesn't seem to have a day job other than to FB troll every day - all day. You know the type of person I'm talking about. Not the regular person who occasionally drops an agenda-based-topic into their socially acceptable narcissistic stream of consciousness. I'm talking about the super activist whose only job is to dredge up nonsense, pre-spun statistics, so-called facts and bogus "news" which they feel is going to influence the overwhelmingly silent majority of Americans.  In order to see what my other friends were up to, I'd have to wade through 6-12 other daily, inflammatory, repulsing posts from you-know-who, and after a year or so of doing this Facebook simply sickened me.The act of FB hiding is something I've been struggling with internally for months now.  Most the people I've talked with say, 'yeah, it's fine to silence your friend, and you need to do it.'  But I can't help but feel: what's the point in calling someone a friend if you can't stomach what they have to say.  Hiding seems like a cop out - a lie to yourself.Coincidentally, my pastor said today, 'to outright reject every detail of what someone says without measuring its truthfulness is foolish and you'll be seen as an idiot.'  While this applies to to all parties in a debate, what if only one side is being intellectually honest and reasonable?  I suppose it's only reasonable to end that debate and walk away from the unhealthy conversation.I'm going to try it for a while and see how it goes. At least with hiding there is still some ability to participate in each others discussions, but I will definitely be mulling my decision over and may just pull the plug on the 'friendship'.I knew something like this could happen.  It's one of the reasons why I've always been overly thoughtful about who I accept friend requests from. I don't generally think of my FB friends as simply co-workers or acquaintances.  I consider them real friends (someone I could call on for help) and I want to keep it that way.[Note: In yet another coincidence, shortly after writing this post, Facebook announced a new version of "Groups" which could be the answer to the problem I've just described -- provided the trolls take their constant activism to their activist groups.][...]

Simple Deploy Tool

Fri, 10 Sep 2010 17:25:00 GMT

Even before the full release of our newly rebuilt website, it seemed like we were constantly deploying daily/hourly updates from our sprints to several of servers (UAT, Staging, etc.)... so much so that, being a Lazy programmer, I stopped what I was doing one night and wrote quick WinForms app I call Simple Deploy.


Now I can quickly deploy a set of files again-and-again to a set of servers with a simple button click -- not that I endorse having to do this -- but now I can be lazy.  If I need to exclude a server, I just unclick the server's checkbox before pressing Deploy.

I'm not sure yet, but I'm considering adding this into the RefreshCache swag bag if others think it's useful.


The Arena Community Developer Board

Fri, 02 Jul 2010 15:37:00 GMT

In February 2007 the guys at Arena ChMS established what was loosely called the Community Developer Board (or CDB). This little known group was comprised of the Arena team (Jeff M, Steve, Mark, Alfred, etc), Jon and David from CCV, and Phil and myself from Central. Since that time a few more churches were invited to the team (Joel & Daniel: High Desert Church, Jeremy Hoff: Shepherd of the Hills, Tom Powers: Southeast Christian Church) but our charter has been roughly the same as summarized here: The CDB’s role is to foster and grow structured development for the Arena community. To achieve this, the CDB should, among other things, create and maintain documentation that illustrates how to properly design, develop and package Arena modules for use by the community.  Additionally it should ... fulfill other needs that are essential to more efficient module development.A few of the things the board has done:help establish the.Community siteestablish the original wiki which later moved to the official wiki establish the namespace/naming standardscreate the Arena Custom Module Developer guide (ACMD)establish the monthly and yearly Arena Developer Roundtablesestablish the module export/import feature (and applying constant pressure to make it more complete)establish our original shared source repository on CVS Dudeestablish the "My Portal" framework enabling developers to write personalization modulesestablish consistency on various things like using the MS Ajax CDN Although we haven't always agreed on things, we've made good progress in areas where there was consensus. (Establishing the RefreshCache tribe has been instrumental in relieving pressure in areas where we have not agreed -- more below.)With the arrival of Mike Gold at Arena and onto the CDB, he's been reshaping how things are done at Arena and as result the CDB will be undergoing a reboot or reinvention. Regardless of the direction the CDB takes, the RefreshCache team will continue to grow in importance. On that team Arena has no responsibility -- which means they are not on the hook for anything.  This has been a real blessing for everyone. Having that kind of clarity has freed up the community to take responsibility and ownership for things that they feel are critical or important (our Manifesto).For the most part, everyone who attended last year's event is part of the RefreshCache team. Over the past year this team has:established and manage the #ArenaChMS IRC channel (Brian Slezak)established the Arena Sample Server - a place where developers can setup their custom modules and try out other live modules in actionestablished our Redmine project server - the new repository (replacing CSV Dude) for hosting your code, issue tracking, wiki, etc. more... (Daniel Hazelbaker)created an amazing Arena module installer (Jon Edmiston, David Turner) really beta tested each major release of Arena before its available to everyone (Austin Spooner) created the Arena Sandbox - a place where developers can test installing their modules in a clean sandbox environment (Daniel Hazelbaker)taught developers essential tips and tricks for developing Arena modules (David Turner, Jeff Schinella, Jason Offutt) shared vital ideas and concepts about ChMS (Jon Edmiston)We're only about about 3 months away fr[...]