Now I find myself working with people who weren’t even born yet when Star Wars was in the theaters. Heck, they were in diapers when the web was born.

At the ripe old age of 43, I find myself feeling like the grand old man.

Not that I’m not still on top of things, always chasing the latest technology wave. (OK, I admit it, I hate texting. But that’s just because … well, honestly, I’m not sure why it is. Maybe I’m just anti-social.)

So this past week, as I was trying to solve a problem in creating eBooks that would be “cross-platform” — meaning a single ePub (the format used by iBooks) that would convert to a reasonable .mobi, if you’re interested — I was glad to find that for once, my age was an asset.

Turns out that the Mobi format, which is used for Kindles, is based on old — and I mean O-L-D — HTML standards. Like, pre-HTML4 stuff. No CSS (for the most part), no nothing. So while Apple is pushing ePub3, which lets you create all kinds of interactive eBooks, I was dealing with a format that doesn’t even let you use an image as a link.

At this point, I have seen many younger programmers give up. “Sorry, can’t do it,” they say. It’s a phrase I hear all the time, and it’s starting to get on my nerves. Sure, there are times when you can’t do something. Some things are just impossible. (Like getting around full justification in iBooks, if the user has it turned on. Grrrrrrr.)

But I don’t, in general, give up that easy. So here is a technique for displaying a text link in a Mobi file, while the ePub displays an image link.

The situation is this: I’m programmatically generating an ePub, which is then run through Calibre to create a Mobi file. The relevant HTML looks like this:

<a class="indexTopLink" href="index.html#top">
   <img class="indexTop" width="100" height="0" src="backToTop.png"/>
</a>
<a class="textTopLink" href="index.html#top">top</a>

So you’ve got two links in the HTML. The height attribute on the arrow image — yes, Virginia, we used to actually set height and width on the actual image, back when dinosaurs roamed the earth — tells the Mobi reader to render the image with a height of 0, so it’s invisible, but the width attribute makes it wide enough to provide some spacing. Then the Mobi reader displays the text link, which actually works.

Now we deal with the ePub. We add some CSS:

.indexTop {
   height: 24px;
   width: 100px;
}
.textTopLink {
   position: relative;
   left: -9990px;
}

The first rule tells the ePub reader to over-ride the image attributes and display the image at the correct size, so it’s visible. The second tells it to move the text link over to the left so that it’s not.

Because the Mobi reader ignores the class attribute these rules are ignored, so we have an image link for ePub, and a text link for the Mobi.

And all with techniques that fell out of favor long before a lot of today’s web programmers even started college.

It’s good to be the grand old man.

#1 — Really focus on just three content areas I think are important. They are cloud computing and social media, which I believe will be big in 2012, and intelligent search, which I’ve been championing in one way or another for a long, long time. (I’ll get more into exactly how I define each of those topics in future posts.)

#2 — Finally build a project I’ve been kicking around for years: an information aggregator that tames the information overload that gets worse every year. (The project has yet to be named, but I’ll talk about what it actually does — and solicit feedback and priorities — in a future post.) I will build this out in public, with deadlines anybody can see. I probably won’t open-source the code itself, but I will likely write articles and tutorials about the different technologies I use as I go along.

#3 — Implement best practices for using social media, including regular postings to Twitter and either LinkedIn, Facebook, or both. (I’ll do the analysis in a future post.)

I did set some ground rules, though. In doing that, I would also have to keep these things in mind:

First and foremost, client work can’t suffer; I’m a professional and if you’re paying me to do something, you take top priority. (Plus I have a family and they can’t suffer, so this will also have to be ‘the year of living within time management best practices’.)

Second, I’ll be using open-source and publicly available software, preferably cloud-based, unless there’s a good reason not to for a particular task, which will be a discussion in and of itself.

Third, all decisions, from what software development methodology to what search solution to use, will be made “in public”, so to speak, with analysis and conclusions out there for everyone to see.

So the big question is, how did I do?

Well, from the outside, it looks very much like the answer is “not too well”, but it’s actually not as bad as it looks.

#1 — I was right about cloud, social, and search being on the rise, and I did actually focus on those three technologies in 2011. About 2/3 of the work I did involved either search or social media, and just about everything was cloud-related in one way or another (if you’re really generous in your definition of “cloud”.) Unfortunately, most of that was client work that I couldn’t post here.

#2 — I did actually build the project, NoTooMi, and quietly launch a first beta of it. Unfortunately, it was built on a product that has subsequently changed its architecture (I knew that was a risk when I built it) so I need to rebuild a few parts of it before I can relauch. Also, while it does integrate Twitter, I haven’t yet finished Facebook integration, so it looks a little anemic right now. I’m hoping to have a public version up in the next couple of weeks.

#3 — OK, I’ll admit it, I definitely fell down on the job here as far as regular postings to Twitter and Facebook. (I did get my LinkedIn profile filled out enough that I picked up a client from it, however.)It’s my personality; I don’t like to talk unless I have something to say, and I get a little weirded out about whether people want to actually hear it. I promise to try and loosen up in 2012.

And what about the requirements? How did I do there?

#1 — Well, giving client work the priority definitely worked. There was not one instance all year in which client work suffered because of this project. If anything, it’s the opposite; I’ve been so busy with client work this year that I haven’t had time to do what I wanted on NoTooMi. (I even got my corporate website redesigned and rewritten.)

And on the personal front, I’m happy to say that while my last remaining children at home drive me nuts at times (which is, I suppose, their job) my marriage is better than ever, and after all these years, that’s saying something, especially since we spent November opening Sarah’s gift shop to try and beat the Christmas rush. (Website to come shortly; we barely got the doors open in time.) (Oh, and for you Doctor Who fanfic fans, Sarah and I were finally were able to launch a huge and ambitious story I’ve wanted to write for a couple of years. When it’s done we’re going to tackle a novel. Seriously.)

#2 — NoTooMi is based on Apache Solr, so in that respect, yes, it’s based on open source. And the service that I built it on was indeed cloud-based. And it worked pretty well, too, but now it looks like I’m going to bring it back to pure Solr. But I admit that thanks to client requirements on something else I have been seduced by IntelliJ and have been using it instead of Eclipse as my programming environment. Sorry guys.

and #3 … Well, yeah, not so much. Sorry about that. See #1.

So where do we go from here? Well, first, I’m going to try and get out of my head a little bit and not worry so much about whether I’m boring people. If I find it interesting, I’ll post it. I would like to think that there are people out there who are interested by the same things I’m interested by.

And I am also going to try and obsess a little less about what I do write. One piece of advice I got from a book about blogging was to do short tips — and to get good at just banging them out. I learn about a ton of different little things over the course of a year. Not every post about them has to be a tutorial. Just a quick tip will do. Really. (Nick takes a deep breath….)

As far as technologies, “cloud” is still a great buzzword, but I think that it’s pretty well established at this point, as least as far as I’m concerned, so I’m going to start focusing on mobile, which is where I think the bulk of innovation will be in the next couple of years. I spent the last couple of weeks really delving into eBooks as a prelude to app-building (tips, I know, tips!), so I’m hoping to have something to show for mobile in 2012.

OK, so those are my goals for 2012. As for measurable objectives:

1. Post something, somewhere, once a week.
2. Get my new office at the store furnished and ready for receiving clients. (It’s cool, there’s a separate room and a back entrance just for me.)
3. Launch a private beta of NoTooMi before March 1.
4. Go to public beta before July 1.
5. Finish the Doctor Who arc we’ve been working on, and start planning a novel.
6. Publish at least one “pay to download this” item, whether it’s a mobile app or a Kindle Single, even if it’s also available here for free.

So that’s where I am today. How did you do on your goals for 2011, and what are you planning for 2012?

This past Saturday, on the freeway about an hour from home, my transmission quit. After coasting about an mile and a half to an exit, I called AAA, and they made arrangements for me to speak with Enterprise Rent-A-Car about getting transportation while my van was in the shop. Because it was Saturday afternoon, none of the local offices were open, so I wound up making a reservation at the airport.

Two problems there. The first was immediately obvious: Enterprise’s slogan, “We’ll pick you up”, only applies to the local offices, so I had to get someone to drive me to the airport. OK, I understood that. But when I got to the airport, I discovered the second problem: the airport locations won’t rent on a debit card unless you’re flying in and out. The agent was apologetic, but there was nothing he could do.

Fortunately my sister-in-law had waited with us. ‘No problem,’ I thought. ‘We’ll go home, and I’ll call my local office and get a ride on Monday morning.’ I’ve rented with Enterprise dozens of times; because I’m the only driver in the house, “We’ll pick you up” makes them my rental agency of choice.

Unfortunately, when I went to book that car for this morning, I was horrified to see that there were no cars available at the two closest offices. The nearest office with a car was 25 minutes away, and I was definitely out of their territorial range.

And that’s where social media comes in. Frustrated, I tweeted:

The one downside of living in the country is that when your car breaks down, you pray Enterprise has a car. Naturally, they don’t. Sigh.

A few minutes later, I found the following @mention from @enterprisecares:

@NickChase We are listening. Is there anything we can help with? If yes, please tweet/follow us & I’ll DM our contact information (amanda)

Surprised, I did as they asked, and, receiving the customer care email address, explained the situation to them. By this time I’d made a reservation at the distant location (hoping I could find someone to take me down there), and Amanda told me she’d email over there and make sure they did everything they could to help.

And that’s exactly what they did.  This morning I called, and true to her word, Amanda (or someone) had let the office know my situation. “Mister Chase, we are going to do whatever it takes to get you going here today,” Paula said. “What time do you have to have the car by?”

Turns out that cars were in short supply because of hail damage here in North and South Carolina, and that was why my local office was sold out. But not only did they find me a car, they did indeed come and pick me up, and I was able to do everything I needed to do today.

And I’m very glad, because I like Enterprise, and didn’t like feeling badly about using them.

So the moral of the story is this: Pay attention to what’s being said about you. Because Enterprise Rent-A-Car spent the resources to monitor social media, they were able to turn a frustrated (and vocal) customer from a source of negative sentiment to a champion of their brand.

What are you doing to monitor what’s being said about you?

This time it’s three clients, NoTooMi, the Year of Living Socially, and a new cat (whom I love, but to whom I’m seriously allergic) but the results are the same; I’ve been down with pneumonia, but I’m just about back in business, so please forgive me for the break in posting.

I’ve actually accomplished a lot since February 5; more to come as I write things up into postings, and NoTooMi starts showing its head.

The Unified Modeling Language (UML) was designed to create a sort of “common vocabulary” that programmers and engineers could use to document their systems, as well as the business processes behind them. (There are also tools that will go back and forth between the diagrams and working code, but for the moment, at least, we’re going to stick with the diagrams themselves.) The current version, UML 2.1.2, defines thirteen types of diagrams, organized into two main types:

Structure diagrams: These diagrams take a static look at the system, or at pieces of the system. Class and component diagrams fall into this category.
Behavior diagrams: These diagrams look at how pieces of a system operate. For example, use case and activity diagrams fall into this category. This category gets further broken down into interaction diagrams.

For the moment, we’re going to start simply, and look at component diagrams, in order to get an overall look at how NoTooMi is going to work.  This post won’t teach you everything you need to know about UML, but it will give you enough of a head start on component diagrams that if you ever need to read one, you’ll have some decent footing.

What is a component?

There’s a lot of potential for confusion when we start talking about “components”.  Do we mean a COM object?  A particular piece of software?  A piece of hardware?  No, in UML, a “component” is a logical construct that basically means a self-contained bit of functionality that can be pulled out and replaced without rewriting the rest of the software.

For example, I recently wrote a system that, as a small part of what it does, takes a directory in an SVN repository, processes the files, and drops the processed files into another directory to be displayed by another process.  The way I built it, each one of those processes were independent of each other; if we want to go to Git instead of SVN, we can do that without affecting the code that processes the files or displays the results.  Similarly, we can completely change how the files are processed without affecting storage or the display, and so on.

So a UML 2 “component” is a unit of self-contained functionality.

UML 2 Component Notation

The actual component notation is pretty straightforward, even if larger diagrams can get complicated.  For example, the main bit of business to deal with in this first sprint is to index Twitter content in the search engine, then display the results on command.  If we generalize “Twitter” to “some information item source” — after all, we know we’re going to have different types of information — we wind up with a simple diagram like this:

As you can see, we have two boxes, Search Index and Item Source, that represent components.  We know this because they have the component symbol in the upper left-hand corner.  (There are other ways to note this in UML, but we’ll talk about that later, when we do class diagrams.)

Each one of these diagrams has two items coming from it.  The round one, known as a “lolipop”, represents interfaces that are provided by the component.  Note that when I say “interface” here, I mean it in the classic sense of “a way to interact with this component”, as opposed to the object-oriented sense of a template that classes implement.  So the Search Index component provides a way to GetItems that have been indexed.

The second item is called a “socket” and represents interfaces that the component needs, and that need to be provided by other components.  So in this case, we can see that the Search Index component needs the ItemAddition interface of another component.  That interface is provided by the Item Source component, which itself needs the ScheduleRetrieval interface of another component, so it knows when to retrieve items to feed to the Search Index.

Finally, we need to “wire the components together”.  As you can see, we have a dashed arrow that represents a “dependency relationship” in UML, and shows that the Search Index requires the Item Source.

Pretty straightforward.  Now let’s see how it applies to the overall NoTooMi system.

The NoTooMi Component Diagram

Now that we’ve got the basics down, let’s look at the design for NoTooMi.  The diagram works out like this:

Now, that’s a bit more complicated, but the general concepts are the same.  We still have the Search Index, which is still requiring the ItemAddition interface from item sources.  In this diagram, however, we’re seeing the more specific sources, Twitter, Email, and so on.  (For you object oriented programmers out there, ItemSource was the interface, Twitter is the class.  We’ll go into all of that in more detail when we do class diagrams.)  As you can see, we’re also showing the more specific names for the interface provided by each component.  You’ll also notice that our item sources have more than one interface specified as required.

OK, so let’s get to the specifics.

1. We have a Search Index, which in this case will be some variant of Apache Solr.
2. We’ll be indexing Tweets by using the Twitter Streams API, saving tweets to a file, then indexing the file on a regular schedule, which will (if all goes well) be specified by that particular variant of Apache Solr that I think we’ll be using.
3. For emails, same thing; the system will pull emails from the server into POP accounts, then index the POP accounts and delete the messages.
4. Ditto for RSS feeds; we’ll pull them, write them, index them, then delete them.
5. For each of those sources, we’ll take the appropriate information and store it in User Storage using the User Management component.

Now, I want to say a word to all those system engineers out there who are saying, “why are you storing all that on disk instead of indexing it directly?  Solr can do that, you don’t need the extra step and resources.”  In the end, you may very well be right about that, but my philosophy is to decouple these components as much as possible; if the Search Index slows down for some reason, I don’t want tweets backing up, causing us to have to drop the connection, restart, etc.  And again, remember; I should be able to pop one of these components out and pop in a replacement without too much trouble.

As for the overall system, I’ve decided, at least for the moment, to build this on the Grails framework.  As a general rule, I’m really not a fan of frameworks — the reasons are a topic for another time — but it seems, at least on the surface, to offer some benefits, which I’ll detail in another post.

Next Steps

So now we’ve created a UML component diagram that specifies the basic pieces of the NoTooMi system, showing what they provide, and what they need.  We’ve covered the basic notation, including the component icon, the lolipop and socket notations, and the use of the dependency connector.

For more information on UML Component Diagrams, check out the following resources.

UML basics: The component diagram

UML 2 Component Diagrams

It’s lightweight, and still enables me to do the design I need, without having to resort to tons of extra documentation just to keep with an arbitrary methodology. So the question remains, what is Scrum?

I can’t possibly explain it any better than Hamid Shojaee:

Scrum in Under 10 Minutes

So how does a single developer make use of Scrum? One way is to use tools such as AxoSoft OnTime. (There’s a free download, but for reasons that are undoubtedly local to my system, I wasn’t able to install it.) In fact, in accordance with the spirit of this project, I should be using one of the web-based tools for Scrum management, such as:

Scrumie
Kanbanery

But what I found is two things:

1) I couldn’t find a tool I liked that gave me everything I needed and still provided public access
2) I didn’t want to spend time learning a new tool when I could do it the old fashioned way, with sticky notes.

So I’m afraid we’re on to sticky notes, at least until things get too big to manage that way. So I start by writing down every use-case I can think of that will be involved in creating NoTooMi. Each one goes on a sticky note, along with an estimate of how many hours I think it will take.

I can then put all the sticky notes on the “Project Board”, which is one wall behind my desk. This is the Project Backlog:

Then I define the first sprint. In this case, it’s “Initial release of simple Twitter client.” I then move all the tasks that are involved in getting to that point to the “Sprint board”, which is the wall next to my desk:

So then I’ve got a total for the Project and the Sprint:

Once I’ve been working on this for a while, I will revise my estimates of what’s left, and create the burndown chart, which will give us an estimate of when the sprint will be finished. On a normal project, we’d do this every day, but since I’m not working on the project every day, this will just have to be one of those adaptations I’ll have to make.

OK, I’ll confess: analysis or not, I want to know those things. Let’s face it, everybody does.

So while I will do some analysis to find out what the best package is going to be, while I get to that point I want something in place, even if it’s just so that I have statistics stretching back to the start of the project.

With that in mind, I went ahead and added Google Analytics to NCPP, because:

• I know how it works
• It provides pretty good (and detailed) results
• It’s free

Adding Google Analytics to a WordPress site is pretty straightforward, and consists of three steps:

1. Sign up for a Google account (we did this in Signing up for a Gmail account)
2. Get the tracking code
3. Add the tracking code to your theme files

Activate your Google Analytics account

To get the tracking code, you’ll first need to activate Google Analytics on your Google Account. Go to the Google Analytics site and click the big Access Analytics button in the upper-right-hand corner.

From there you’ll need to log in to your Google account, then click the Sign Up >> button in the lower-left-hand corner.

Next, add your own information to create your account:

Finally, read and agree to the user agreement.

Now you’re ready to get the tracking code.

Get your Google Analytics tracking code

The first think you need to do is decide what you’re tracking. Your choices are:

• A single domain: This is going to be the choice for most people; it’s a single domain, with multiple potential subdirectories, such as (in my case) http://nicholaschase.com, http://nicholaschase.com/blog, http;//nicholaschase.com/blog/features.
• One domain with multiple subdomains: Subdomains are basically the first part of what most people think of a “domain name”. For example, www.nicholaschase.com, blog.nicholaschase.com, and chaos.nicholaschase.com.
• Multiple top level domains: Top level domains are actually the last part of what people think of as a domain name. For example, www.nicholaschase.com, www.nicholaschase.net, and www.nicholaschase.org.

Because I’m dealing with a blog, and URLs look something like http://nicholaschase.com/2011/01/01/post-title/, I’m going to choose the first option.

Once you’ve done that, you can highlight and copy the actual code from the pane on the right-hand side to your clipboard.

Just to be on the safe side, go ahead and paste the code to a text editor such as Notepad, then click the Save and Finish button.

This is the Google Analytics dashboard, but we won’t have anything to look at until we add the tracking code to the site.

Add the Analytics Tracking Code To Wordpess

Now that you’ve got the tracking code, you need to add it to all of your WordPress pages. Fortunately, WordPress, like most content management systems, uses a “theming” system, which means that a few files are used to populate the entire site. The good thing about that is that we can add the tracking code to the theme and it will be propagated throughout the site.

Chances are you looked through various themes and chose one for your site; WordPress is great about making this easy. Fortunately, it’s also easy to edit the files that make up your theme. To start with, log in to WordPress as an administrator and click Appearance->Editor, then click the Footer link in the right-hand column.

Copy and paste the tracking code into the footer file just above the body close tag (</body>) and click Update File.

Now you’ve added the tracking code to your site, but if you go back to the Analytics dashboard, you’ll see that Google doesn’t recognize it yet.

Unfortunately, there’s not much you can do to speed things up, but sometime in the next 24 hours Google will index your page and find the tracking code, and the icon will turn green:

So now you’re collecting data. In a future post, we’ll talk about what that data actually means.

When I was a baby, my parents took me to the pediatrician because I wouldn’t sleep. The doctor examined me, smiled, and told them not to worry. “He just doesn’t want to miss anything.”

Well, I’m all grown up and I still don’t want to miss anything. That’s why I started this project in the first place. The whole idea of NoTooMi is to make it possible to organize all that information so we don’t miss anything.

And the first step in all this is to choose a programming methodology.

Now, since it’s just me, I could certainly hack-and-slash this, but I am not going to do that. First off, experience has shown me that it always, always comes back to bite you in the end. And second, I’m trying to set a good example here.

So I went back and did an analysis of various programming methodologies, compared various methods, made a decision, posted it, and got to work.

I immediately realized I’d made a huge mistake, and chosen the wrong methodology. I temporarily trashed the post while I figured out where I’d gone wrong, and what I should do instead. So here it is again, with the benefit of hindsight.

… So the question becomes, what “methodology” do we use? Turns out that we have dozens to choose from, because all you need to do to create one is to write about what you’re doing and give it a name. So I’m really not going to go into all of them — I don’t think I could if I tried anyway.

The important thing to understand is that there are two basic philosophies: “waterfall”, in which everything is specified to the hilt before anybody builds anything, and “agile”, in which things are a bit more loose.

The waterfall method is good for every large projects in which somebody’s literally going to die if you get something wrong. It was typified by projects from the 1970’s and 1980’s, in which you might spend two years writing the specification for the project, and by the time you were ready to code, the project was out of date.

Thankfully, the waterfall method has evolved over the years, and for large projects it’s usually typified by the Rational Unified Process, named for the Rational Rose tool in which the diagrams and other artifacts used by it used to be built. (IBM now owns the Rational line.)

Now, if you think you’re detecting a little bit of frustration with the waterfall method, you’re right. In fact, a lot of programmers were pretty frustrated with the way things progressed in these projects, and a meeting of 17 of them resulted in the Agile Manifesto, valuing

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That’s pretty general, of course; the fact is that the manifesto is pretty much all that the participants could agree on. So it’s probably no surprise that at this point there are lots of “Agile Methodologies”, which move away from the waterfall method to various degrees. In general, we have a spectrum. On one end, we have the Rational Unified Process, a thorough, deliberate process that (hopefully) results in working software in a final release after everything is completely specified, built, and tested. Change is … well, let’s just say “difficult”. At the other end, we have Extreme Programming (XP) a lightweight process that (hopefully) results in lots of smaller releases, but not a lot of documentation beforehand.

Wikipedia’s got a good look at choosing between plan-driven and agile programming methodologies:

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive (“agile”) and predictive (“plan-driven”) methods.[29] The authors suggest that each side of the continuum has its own home ground as follows:

Agile home ground:[29]

• Low criticality
• Senior developers
• Requirements change often
• Small number of developers
• Culture that thrives on chaos

Plan-driven home ground:[29]

• High criticality
• Junior developers
• Requirements do not change often
• Large number of developers
• Culture that demands order

Formal methods:

• Extreme criticality
• Senior developers
• Limited requirements, limited features see Wirth’s law
• Requirements that can be modeled
• Extreme quality

There is certainly value in both approaches, but for my tastes, they’re both too extreme. In the middle we have the Agile Unified Process, which seems to me to take the best of both worlds; there’s enough design and documentation beforehand to know thing things are well thought out (and can be picked up by additional resources if necessary) but we can also focus on smaller, quicker releases, backed up by automated testing to make sure that everything’s working properly, even if we have to make changes.

Now, I’d originally settled on the Agile Unified Process as a middle ground for building NoTooMi, but I quickly discovered that for a single developer who basically fills all of the roles, from stakeholders to QA, it’s still pretty heavyweight.

So instead, I decided on a different Agile methodology, Scrum. More on that in the next post.

How did we come to that? It’s a reference to TMI, or “too much information”. In other words, NomoreTooMI.

I’ve also been working behind the scenes on a few things, and hope to have some good news soon. In the meantime, I hope to have a first iteration by next Monday, when I’ll be taking volunteers for people who want to give her a shot. If you want to be on the list, head over to the NoTooMi site, and sign up for updates.

To do that, first go to Technorati and if you have an account, sign up or sign in. Once you’re in, click your username to get to your profile.

Fill out your profile, and under “My Claimed Blogs”, enter your URL for “Start a blog claim” and click the Claim button.

Refresh your profile page and click the Check Claim button:

This brings up a message including a code you’ll need to complete the process:

From here, you need to take that code and go back to your blog and create a new posting that includes it (like this one). For example, in my case, that code is “9BPZDRFA3CBR”. (You don’t have to leave this post up forever, though of course we will here. )

After you publish the post, go back to Tecnorati and click the Verify Claim Token button:

At the time of this writing, I don’t know how long the process takes; when I submitted the claim, I received a message saying that they’re improving the quality of their process so it may take some time to clear the backlog. Bulletins as events warrant.

[UPDATE: Final submission is still indicating this may take a while.

10:21PM: It's only been about half an hour, and they've verified the code, but we're still in a holding pattern.

]

[UPDATE:  Well, we never got an email, but here we are on February 5, and we have been approved.  More on Technorati in another post.]