It Matterth Not ...

In August 1830, a heavenly messenger appeared to Joseph Smith and
instructed him¹ that, "it mattereth not what ye shall eat or
what ye shall drink when ye partake of the sacrament" and said further that the
real importance was "remembering unto the Father [Jesus's] body which was
laid down for you, and [His] blood which was shed for the remission of your
sins."² As such, most sacrament meetings in The Church
of Jesus Christ of Latter-day Saints use water instead of wine or grape
juice.

While I was reading this passage the other night, I wondered how much money the
Church saves annually by using water instead of juice. There are almost 13
million members on the records of the Church. From my experience it
seems that about 50% of a ward's members attend sacrament meetings on a regular
basis. Nearly all of those attending partake of the sacrament which includes
drinking one small cup of water. Each cup contains about 1/4 ounce of liquid.
Sacrament meetings are held every week of the year except 4 (General and Stake
conferences). Using those assumptions, members of the Church consume about
609,000 gallons of liquid each year while partaking of the
sacrament.

For this calculation, we'll assume that water is essentially free. Buying
grape juice from Sam's Club costs around $5.50 per gallon (in
Cheyenne, at least). Assuming that the Church could get some kind of volume
discount, maybe it would be as cheap as $5 per gallon. That comes out to
around $3 million annually.

This doesn't include the cost of cleaning up spilled grape juice. It also assumes that there is no wasted juice. The savings might be twice as high if we accounted for the extra cups that are poured to make sure surprise visitors are able to partake of the sacrament.

Of course, the economic cost is probably the least important reason for using
water as part of the sacrament, it's nevertheless interesting to see the
unintentional savings the Church enjoys from this practice.

WD-40 Makes a Decent Hammer

I'm not quite a member of the WD-40 fan club, but the stuff is pretty amazing. A couple days ago, I discovered that one of our drain pipes was leaking. I tore off the wood paneling to find the leak and noted several rotten 2x4s that I had to remove before I could access the leaking pipe.

With my trusty hammer, it was easy to remove most of the nails and wood. However, one beam just wouldn't come loose. Two nails held it fast. The first nail I cut through with a hacksaw. The second nail was too far back for the blade to reach. I pried and pried but could only get it loose about 1/4". While I was staring at my toolbox, suddenly es fällt mir ein: use the WD-40. I stood there for a minute dumbfounded. How do I use WD-40 to pry out a nail?

Eventually my brain caught on. I sprayed the WD-40 onto the 1/4" of nail that I had exposed. Then I hammered the nail back into its hole. After a few seconds, I pried with the hammer again. Now it came out about 1/2". After a few more rounds of spray, hammer, pry, the nail came out and the timber was free.

If I had been better versed in WD-40 canon, I would have known that on page 4 of 2000 Uses of WD-40 is this great proverb: Lubricates nails to ease disassembly of pallets.

Speaking of Love

Maggots on a Rock
Originally uploaded by mndrix

While I was writing the previous entry, my wife walked in the room with a little snack for me. That's exactly the kind of thing a business should do for its customers: "I know this isn't much, but I thought you'd enjoy it."

(Yes, that's a Disney Princess stress ball in the background. Content for another entry.)

Showing customers your love

First, let me say that I'm all for charging as much as the market will bear. If customers don't like the pricing structure they're free not to use the product. However, sometimes charging for a product or service is poor business. For example, let's compare the Google and eBay SMS offerings.

Google SMS allows you to submit searches to Google via text message. You text 466453 and Google responds with a brief, helpful result. Very cool, very handy and all for free.

eBay SMS is a similar service. It notifies you when you've been outbid on an auction or when an auction you're watching is about to end. You can then reply to the message to bid on the auction. Very cool, quite handy and all for $0.25 per auction!? As I read the service description, my internal eBay satisfaction meter climbed higher and higher. Fantasies of useful text messages zoomed through my mind. When I saw the pricing my meter sank below where it started: Are you kidding me? That must cost you next to nothing.

Now of course, I'd rather that eBay offer the service for a charge than not offer it at all. There are probably some people out there willing to pay for eBay text message alerts, but I'm not one of them. By providing SMS messages as a complimentary service to bidders, eBay could make their platform more appealing. They would have kept my customer satisfaction meter nicely stoked.

In business, it's important to ask, How can I show the customer my love? Often the answer is the same as with romance: small, inexpensive trinkets that say I'm thinking about you.

Phonetic coding algorithms

/Adri[ae]nn?e?/

Unfortunately, English spelling can be hard. And when it comes to spelling
names, it's even more difficult. For instance, in English, the name /ˈeɪdriən/
could be spelled in at least the following ways:

• adrienne


• adriene


• adrien


• adrianne


• adriane


• adrian

In human circumstances, this isn't a problem since people recognize all the
spellings and translate the written text into a phonetic representation in
their mind.

Now imagine that you want a computer user to enter a name into a search box and
have the computer convert that entry into an identifier in a database. If the
database has "adrienne" and the user types "adrian", there's no match. It's
too time-consuming to enter every possible name variant into the database.
Phonetic coding algorithms address this problem. For the list of names above,
the Soundex algorithm generates the code A365. By storing a single
phonetic code in the database and converting the user's entry into A365 one
can find the person the user intended.

Caron or Hendricks vs Hendrick

There are many phonetic algorithms. Soundex is one of the
first and most widely used, but it doesn't always perform well. For example,
my sister-in-law is named Caron. People inevitably spell her name as "Karen."
Soundex doesn't help because the codes C650 and K650 are different. In
this case, we could switch to the NYSIIS (CARAN), Metaphone (KRN),
Double Metaphone (KRN) or Phonix (K6500000) algorithms.

I sometimes encounter the misspelling "Hendricks" vs "Hendrick." By ommitting
the final "s", one confuses the Metaphone and Phonix algorithms. NYSIIS
(HANDRAC) and Double Metaphone (HNTR) still work in this case though.

Kinsey vs. McKinsey

For my particular application, I settled on NYSIIS because it
can be implemented in about 30 lines of Perl code and works quite well for
the names I'm interested in. However, it doesn't entirely solve the
use case I described above. There's one person in the database whose proper
name is Elizabeth but she goes by the name Betsy and another whose name is Amy
but she goes by the name Teddy.

In both cases, the problem lies with nicknames and not phonetics. It would be
interesting to develop a phonetic code which accounted for nicknames.
Perhaps by converting names into canonical names (Betsy -> Elizabeth) before
applying the phonetic code. Or maybe using the edit distance between two
phonetic codes to determine similarity. With a phonetic code like NYSIIS, this
hybrid approach could be fruitful. Some research by Zobel and Dart
indicate success with similar hybrid techniques.

RDF impressions at YAPC

While attending YAPC 2006 in Chicago, I've been once again impressed with the need to get a set of RDF tools working in Perl. There are so many interesting tools that could be implemented if only there were some basic RDF modules. We need something to do for RDF what DBI does for database access, but with flexibility that matches RDF's. I've heard that RDF::Helper may be a start in that direction, but it doesn't look nearly visionary enough. One of my highest priorities is to get this basic RDF toolchain working. I could use Redland, but I really want my RDF-related modules to work regardless of the implementation that a user chooses. For instance, at work, I developed an application that stores it's data as RDF in a Sesame repository. I should be able to switch from Redland to Sesame by changing very little code and have everything Just Work.

Here's a short list of some of the RDF modules that I want — and the inspiring/reminding talks where appropriate.

• RDFI — Generic RDF interface like DBI for RDF



I attended Joe McMahon's talk about Designing for Pluggability which reminded me of the importance of interchangeable parts and modifiable parts in modern software design. RDF is a great match for this pluggable design approach because it allows plugins to extend the data model as well as the code. I've been working on a timecard application for a while and I keep coming back to RDF as the perfect, extensible data model for that application. I don't want to write all the functionality into the core application. If someone wants to record the color of their hair at the time they clocked in, they should be free to extend the data model to accomodate that desire. That data should then become a first class citizen available for querying (SPARQL) and modification like any other data.





• RDF::Sync — synchronize the RDF in two repositories



During the lightning talks, Jesse Vincent presented a brief segment (during Adam Kennedy's talk) where he described the ideal situation where one's data lives on his laptop and out on the net. He wants to get off the airplane and have his laptop data automatically sync with the data that's stored out on the net.




I've wanted this same thing since I often switch between: connected desktop, connected laptop, disconnected laptop. I'm sick of trying flawed approaches to synchronize my bookmarks. When I'm off in the wilderness and want to find an email that I saw three months ago, I don't want to wait until I can get a net connection again. My data should be where I want it, when I want it.




Because RDF can be used as a universal data storage format, and it's easy to synchronize that data between different repositories, I think that RDF is a great solution to this problem.




• RDF::MSG — calculate the minimum self-contained graphs for an arbitrary RDF graph.



RDF synchronization and RDF signing both require a technique for splitting an RDF graph into atomic chunks. The technique is easy to implement, I just have to bundle it into a handy Perl module and toss it on the CPAN

Ingy döt Net gave a mostly incoherent lightning talk (by design, I'm sure), but amidst the swearing and random auditory noise, there were some good pieces about an idea that he called CogBase. I didn't get a chance to talk with him about it afterwards, but his notion seems to coincide with an idea I've had for a while: a single, versioned repository for all my data like contacts, email, bookmarks, websites visited, …. I think that RDF is the solution to this universal database. Look at the Description section of the CogBase module and compare that with what the RDF data model provides. 8 of the 15 requirements are already met by RDF. Solutions for versioning and access control issues are still an open question within the RDF community, but I don't think they're insurmountable. With those two pieces solved only the item about object-orientedness of schemas is still missing.

There are just too many cool apps that can be built once the tools are in place. I just need the time and resources to work on it. Let's see if I can implement it in less than the 3 years these ideas have been rolling in my head. Maybe next year I'll submit a collection of talks about RDF

• Introduction to RDF


• Using RDF as a Data Model


• Extensible Applications with RDF

or some such.

Review: Rackmounted.com

I've been using Rackmounted as my
provider for dedicated hosting for about a year now. During that time, the
service has been excellent. They provide one of the most
inexpensive dedicated server
packages that I've found anywhere. We've had no problems with the server and
responses to service tickets have always been prompt.

The event that prompted this review is that a little past midnight, our
server went down. I noticed it this morning and was unable to access the
server via SSH (even though I could ping it). I submitted a ticket to
Rackmounted and waited for an automated email response indicating that the
ticket request had been received. After a few minutes, one didn't arrive, so
I submitted another ticket. Within a minute or two, a
representative from Rackmounted called me on the phone. He said that he
noticed I had sent a second ticket and assumed that his email responses
weren't getting through, so he wanted to make sure I knew what was going on.
He was going to restart my server. Within a couple more minutes, everything
was back up and running.

Great service. One more reason to get dedicated server hosting from
Rackmounted.com

Thanks Rackmounted