How we did the Cobblestone Prayer Plugin

Central to the mission of Cobblestone Community Network is the desire to help small groups gather around activities that are close to their hearts.  This desire will hopefully enrich the lives of group members and raise the quality of time spent together which in turn should produce growth.  It is with this in mind that we developed the Prayer Plugin for Cobblestone:  To help small groups gathered around the belief that God hears our prayers and answers them according to His good pleasure that in so doing, our faith will grow strong.

Since the Cobblestone Framework already exists, all we needed to do was gather around a whiteboard and pour our hearts into a flow chart of what the Prayer Plugin should do.

Step 1: High Level Flow Chart

A quick side note: It would benefit any developer partaking in a flow charting session to allow the dreamers to dream.  All too often we get bogged down by the how’s and this tends to stifle collaboration and the great ideas that might actually surface from the rubble of incoherent suggestions that get flung out onto the whiteboard.  In order to maintain some control, I would highly recommend you grab the marker and arm the position at the whiteboard.  This role is pivotal in converting dreamy digital noise into a sequential stream of logical symphony.

The first challenge was to define what the Prayer Plugin could offer outside a simple post with commenting enabled.  What we came up with is summarized in the following screen shots.

The first challenge is being faced with a blank whiteboard. Often I have found the best way to start being to simply ask “what” it is you are describing. It is remarkable how much information is gleaned from simply listing the attributes.

After this it helps to ask what action will take place on the object described, in this case prayer. Again it is important to simply let the ideas flow. One can worry about how to implement later.

Once the obvious has made it onto the whiteboard, the really interesting ideas start flowing.

To summarize, a prayer in Cobblestone:

• is part of a group (which could be public or private)
• has a title
• has a description
• has an urgency level
• is of type praise or request
• contains people to be prayed for
• contains keywords or tags

Further more, activities on a prayer includes:

• commenting
• praying - a great way to notify the originator that you are praying but also that you’d like to receive updates on this prayer request
• status change
• scripture commenting whereby encouragement can be given in the form of scripture which will be displayed inline
• automatic follow up for archiving, reminders or notifications

Step 2: Specification Document

Once the ideas on the whiteboard have been agreed upon, the often tedious task of making sense of it all follows. It is usually better to have a more analytical perspective when working through the flow charts as this will bring up several questions that have not been raised during the excitement of high five’ing each other at the whiteboard.

A critical component of this document is the User Interface (also known as Wire Framing). This is especially useful when implementing within MVC frameworks in that styling views can be ignored until a later stage without compromising the implementation of the models and controllers.

Here is a screen shot of the Specification document we wrote for the Prayer Plugin:

As a result of writing this specification, a ton of questions came up regarding notification settings, group types and group module management. These have been diverted to other documents but has allowed for us to keep these aspects in mind as we develop the Prayer plugin.

Step 3: Entity Relationship Diagrams

If whiteboards offer lively discussions between the developers and the dreamers, the ERD provides plenty of that amongst developers. And so it should. I have found that just like most guitar players think they’re bass players, which they’re not, most developers think they’re database designers, which they’re not. It takes hard work and multiple refining iterations to produce the most optimized SQL design. Defining primary keys, compound keys and knowing your one to many’s and many’s to ones are essential.

Here is an example of an early round ERD for the Prayer Plugin:

Step 4: Code

Code, code, code!

Step 5: Style

With the coding and debugging completed it is up to the CSS guru to come in and style the views.  In some cases this will raise issues either because it’s been a while since the whiteboarding exercise of step 1, or new ideas rear their ugly heads.  I have found that going back to the whiteboard often provides a level of comfort to everyone in the team as it provides a platform for dreaming up the next version of a particular feature without arguing that it was supposed to be in the current version.

Here is a screenshot of what the Prayer Plugin’s ‘View all Prayers’ page looks like:

An Open Letter to Apple Store, Fashion Valley, CA.

Dear Genius Bar at Apple Store, Fashion Valley, CA

At a time when my love affair with Ubuntu was at an all time high (can you say Jaunty Jackalope?) the most peculiar sequence of events took place, that robbed me from all my intentions to abandon you.  I’ll try keep this short…

Three years ago, when I joined Drew Goodmanson at Monk Development, I bought my Macbook Pro.  I think back fondly of writing the first lines of code in a blank ‘vi‘ session to the product that has become Ekklesia360 - A Church Website Content Management System.  After a long and prosperous relationship with my laptop, the following encounters with you ensued:

1. September 2008 : the super drive had to be replaced as it stopped burning CD’s. You fixed my laptop, no questions asked.
2. January 2009 : the super drive had to be replaced again as it stopped burning CD’s. You fixed my laptop, no questions asked.
3. May 2009 : I was experiencing intermittent failures with burning CD’s as well as having to endure noisy audio output.  Knowing that my AppleCare was to expire, I made sure that I brought my Macbook to you where you took it in for repair, no questions asked.

When I received my laptop a couple days later, delivered via UPS to my home, I was thrilled to see that no less than 7 parts had been replaced, including the Logic board.  Why, I felt like I had been given a new machine right on the cusp of my extended warranty’s expiration!

Hooray, NOT! The noise was still present and a new problem popped up: my machine locked up every now and again at a rate that was totally unpredictable and in many cases could not be reproduced.  By this time I was outside my warranty period and I was dreading trying to explain to you, the genius at the Apple Store, Fashion Valley, CA, how this was a result of the earlier replacement.

Needless to say, everything went wrong when I tried to demonstrate the problem at the Genius bar where my laptop put in a stellar performance of working just right with no mercy being shown to it’s owner and his gripes.  Although “Jack” was less than convinced he agreed to check my laptop in and to run “more hardware diagnostic” tests.

The following day, May 31st 2009, I got a call from you informing me that you were unable to get to the bottom of the problem and with an almost apologetic tone of voice, you asked me if I would be ok with a brand new Macbook Pro?  My jaw dropped.  After sheepishly insisting on a data transfer I could not thank you enough for an astonishing display of customer service.

Highlights include a hard drive with 3 and half times more disk space and, an upgrade in processor and because you treated it like a purchase, you afforded me an opportunity to purchase AppleCare which covers me for the next three years.

Thank you Apple Store, Fashion Valley.  Thank you very much.