This End Up

Github's Diff Sorta Stinks

nairdo — 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

nairdo — 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 rockrms.com 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

nairdo — 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

nairdo — 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()
DECLARE @DateA DATE
DECLARE @DateB DATE
WHILE @StartDt < @EndDt
	BEGIN
		-- First day of previous month
		--SELECT DATEADD(month, DATEDIFF(MONTH, 0, @StartDt) - 1, 0)
		
		-- First day of current month
		--SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, @StartDt), 0)
		
		-- 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))
		SET @DateB = (SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, @StartDt), 0))
		
		-- Your query goes here... take this abbreviated example
		--INSERT INTO mtrc_metric_item
		--( 
		--	[metric_id], 
		--	[metric_value], 
		--	[collection_date])
		--SELECT
		--	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))
	
	END

For yearly ranges just make the necessary adjustments.

Rock Beta Status

nairdo — 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

nairdo — 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

nairdo — 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

nairdo — 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...

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".
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/
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: HOST/CHMS HOST/chms.centralaz.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.centralaz.com 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/chms.centralaz.com 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

nairdo — Thu, 05 Jul 2012 21:42:00 GMT

Last year I told you about our problem of trying to check-in 1750+ kids (http://codersforchrist.com/cs/blogs/nick/archive/2011/07/25/VBS-Check_2D00_in-Process-Improvement.aspx) 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

nairdo — 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 mentioning are: cell phone auto dimming, screen locking, and mysterious time lost as a result of certain mobile phone browser interruptions - such as screen lock and wake up. (On my Android phone, a screen lock and re-open would cause a simple JavaScript clock to become out of sync with correct time. It smells like a timing bug with the OS - but what do I know.)

Forward to November when it was decided that our system should also power the worship center's IMAG side screens with something cool, show an event count down timer, and the drive the band's click track. That ended up being a real blessing because we got to work on some really fun stuff. After more experimentation for the "something cool" part, and more ramping-it-up ™ with statements like "what if we could ...", we ended up programmatically building a Christmas Tree as colored circles on the HTML5 canvas to match our church's Luminous graphic.

We somewhat randomly plot circles in the shape of a Christmas tree using a little Math.sin() trick to get the curve we wanted. (Remember that stuff you learned in high school -- it really does come in handy!) The same JSON encoded light track data would be used to control the four sets of lights on the tree. We kept the same code base and ended up with some configuration settings to control whether the simple HTML/CSS (cell phones) or HTML5 canvas w/tree was being used (side screens).

Ultimately, the midi file click track turned into a full blown amazing score and arrangement of Carol of the Bells by Adrian Darsee in mp3 format. There was more fun getting the audio track to play which perhaps Jason will cover in his blog.

We also created a small admin panel as an Arena module so that the A/V tech guys at each campus could store the event start time for that service once they knew exactly when they wanted it to start.

Time Shifting Gotchas

Late in the game we discovered something unfortunate when we put it all together with all the other equipment (QLab, the worship center's A/V systems and side screens, a full 30 minute pre-service countdown, etc.). Not all seconds are created equal. I should have realized this, but somehow it failed to register. Due to NTP being used on the various systems, the QLab mac, the mac running Chrome for the IMAG, and our server would slowly drift by a 1 to .5 seconds during the 40 minute countdown. That's a big problem if you're trying to achieve millisecond synchronization. We turned off NTP as a work-around but realize it's something we want to address in future versions of CrowdSync. We're also going to implement all the server side stuff in Node.js.

Conclusion

The goal was for each person to "be the light" and "let your light shine" as a literal and symbolic expression during the worship to our King. Overall it was a success for the whole opening worship experience but when the congregation erupted into loud applause at the end I knew they enjoyed the experience too. I hope we have some of it captured on video.

We'll post the latest alpha CrowdSync source up on Github shortly.

5th Generation Arena ChMS Website

nairdo — 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.js, Backbone.js, 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 added an alias to our internal DNS and set up IIS to serve the test site up as http://testweb/ for general staff User Acceptance Testing.

Now that this website is behind us, next up will be creating a personal, personalized space on the site and the modules needed for people to access all of "their" stuff (profile, prayer requests, small groups, contribution statements, event registrations, customized news/promotions, etc.).

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

nairdo — Mon, 10 Oct 2011 20:11:00 GMT

I've joined forces with an initially small team of developers and artists to form the Spark Development Network (www.sparkdevelopmentnetwork.com) 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 (www.refreshcache.com) 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: https://github.com/SparkDevNetwork/Rock-ChMS. 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

nairdo — 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

nairdo — 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

nairdo — 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?