Joseph wrote an interesting post on the futility of rel=nofollow for blogs. Apparently he is not alone–there’s an anti-nofollow organization, NoNoFollow.net, that lists several valid objections to this technique. They also list a few plugins for WordPress which are supposed to disable the rel=nofollow “features”, but according to conversations with Joseph none of these are 100% effective. So I have followed his lead and manually edited my WordPress 1.5.2 code to remove the nofollow bits. I also added a 
badge on the left column of my blog.
Monday’s Sacramento Bee had an article on Regional Transit’s recent problems with light rail operations. The most frustrating thing about the system running behind schedule (to me) is lack of notification. I usually don’t care if my bus is running 10 minutes late — I just don’t want to stand at the bus stop for an extra 10 minutes, especially when I don’t know how long I’ll have to wait. Near the end of the article, a passenger-notification system is mentioned:
In Washington, D.C., rail officials now send electronic alerts directly to commuters’ computers, cell phones and personal digital assistants.
Joseph and I discussed a similar system for the Sac State shuttle service, which routinely runs behind schedule at the beginning of every semester. Joseph’s idea was to set up an email list server with a separate list for each of Sac State’s three different routes. Transit riders would subscribe to the alert service for the route(s) they take, using their cell phone’s text messaging address, an alphanumeric pager address, or any other device capable of receiving email. Thus if the driver on route #2 is running behind schedule, s/he would alert the dispatcher, who would in turn send a single email to route #2’s subscribers. The email list server would then notify all the subscribers’ pagers, cell phones, PDA’s, etc. This same information could, with a bit more effort, also be posted on a web page or put into an RSS feed. Email list servers are very mature technology, and they don’t require much infrastructure. Such a system could be implemented on a commodity PC in a matter of hours. The only other requirement would be a decent internet connection.
According to the Bee article, RT’s future projects list includes a public information system for light-rail stations, costing $2,000,000. ?!? That’s crazy! RT should follow Washington DC’s example (or just hire Joseph for a few days) and send alerts directly to patrons’ alphanumeric pagers and cell phones. How much could such a system possibly cost? Granted that they have many more routes and riders than Sac State, but the basic idea should scale up very well by investing a bit more money in the hardware. Spending $2 million just on kiosks at light rail stations doesn’t make any sense to me.
Several weeks ago I mentioned a new ping service that I’ve been using for my blog, but I wasn’t able to give details since it was experimental. Well, the cat is now out of the bag!
PingQueue is Joseph’s recently-announced ping service. Details of this service are available via the links in this entry. But in a nutshell, the advantage of this service is that ping requests are queued up–this sounds like a disadvantage, but the response time for adding a request to the queue is much faster than synchronously pinging multiple services.
Check it out! I’ve been using this service for the last 1.5 months or so, and I’ve been very happy with it.
Need a laugh? Check this out!
About a month ago, Sac State rolled out a new logo and “identity package” with much fanfare, complete with a page on the CSUS web site. My buddy Joseph posted this story about the new logo on his blog at the time the announcement was made. All fine and good.
Now fast-forward to today. Do a Google search on sacramento state logo. What’s the top result? Why, Joseph’s blog of course! It’s much more relevant than the official “identity package” web page. 
I’ve intentionally left out any links to the official site. Just doing my (miniscule) part to keep it from becoming result #1! 
You can always go to Google and scoll down a bit if you really want to see it.
Kevin Burton frets about a potential “ping crisis”:
…in the long run it seems to be a big difficult (sic):
1. Everyone wants to spam you.
2. You’re not a consumer level service so you can’t run Ads to make money.
3. The more traffic you get the more your costs go up.
4. Scaling a system is difficult once you get to that volume.
5. All your pings need to be delivered fast (see #4).
Those are some interesting points to ponder. Point #1 is particularly troublesome, so let’s think about points 2-5 first. It seems to me that we’d do well to look at some other services for ideas and inspiration. The first one that comes to my mind is DNS. No ads on DNS, and not many fees are being charged for it. Perhaps we should come up with some sort of distributed model for handling blog pings? If we have a distributed service, no single server would have to bear the entire load, and we can probably avoid the traffic cost and scaling issues. But now about point #5 — Obviously pings need to be acknowledged very quickly, but do pings need to be delivered fast? Joseph’s ping service is based on a queueing model, which seems reasonable and more practical to me. What do I care if my posts are advertised “immediately” or I have to wait 5 minutes?
So now back to point #1, blocking spam. Do we need some sort of RBL? Open-source tools to identify spam? I really don’t know the answer to this. We need some input from people on the front lines about this topic.
Ping-o-Matic (the default pub-notification service in WordPress) is a great idea: You publish a new post, and WordPress notifies PoM, and PoM passes the update along to a whole bunch of update services. Very slick! But there are two problems with it:
- Single point of failure. If PoM is down (or busy or otherwise unavailable) when you click the Publish key, you’ll get to watch your browser spin in circles for a bit while it tries to contact PoM.
- Real-time pinging. If PoM is available when you Publish, it seems like it holds you connection while it notifies all the update services.
Joseph started discussing these problems with me the other day, and the delays I’ve sometimes noticed upon clicking the Publish button came to mind. Turns out that he had an idea for a streamlined notification service, which he’s now opened up for testing. I’ve installed the new service in place of PoM, and it seems to be a significant improvement. I’d like to collect some data comparing the new service to PoM, to get a more objective look at this.
Some things to note:
- Joseph’s service could still be a single point of failure, assuming one were to replace PoM with this service in the Options/Writing/Update Services setting.
- The basic idea of the new service is to respond to a blog’s update notification as fast as possible, then later to notify all the update services. The cost of this approach is a small delay (a few minutes) between publication and notification, but the quick response between clicking Publish and getting back to my blog admin page is worth it!
I stopped by Joseph’s blog a few days ago and read the article about Vint Cerf moving to Google. This got me thinking about an earlier Google-related post about sitemaps on Joseph’s blog, where he wondered about a WordPress plugin to generate Google sitemaps. I figured that the WordPress community had probably finished with this by now, and it seems that they have. This article discusses the development of several such plugins and their features. If you check this link, you can peruse a menu of sitemap plugins.
I chose Arne Brachhold’s sitemap generator plugin. As usual with WordPress, installation was simple. I had two minor problems (see below), both covered by the FAQ section on the sitemap plugin page.
I downloaded the plugin to my WordPress’ wp-content/plugins directory, then activated it from the Plugins admin page, http://your.blog/url/wp-admin/plugins.php. Next I went to Options/Sitemap and adjusted the options to suit my blog, then clicked “Rebuild Sitemap” and ran into problem #1–I had forgotten to make sitemap.xml and sitemap.xml.gz writable. Easy to fix, see the FAQ section on the sitemap plugin page. Once I took care of this, I successfully built my first sitemap file, but got a “Could not ping to Google” error, also addressed in the FAQ section (although not in the plugin sourcefile). I clicked on the URL after the “Could not ping to Google” error, which basically told me that I needed a Google account. (Yet another password to keep track of, sigh…) So, create Google account, wait for email address verification, then manually cut-and-paste the sitemap URL into the Google account manager. Am I finished yet? No! Google now wants me to prove that I have access to the sitemap’s directory by creating a particular Google-supplied filename. I’m starting to wonder if Google sitemaps are worth the hassle, but I’ve come this far and hopefully this is the final step. touch GOOGLE0123456789abcdef.html, click “Verify” on the Google’s “My Sitemaps” page, and a nice green VERIFIED message comes up. Then I went back to my WordPress Options/Sitemap page and tried “Rebuild Sitemap”:
Successfully pinged Google at http://www.google.com/webmasters/sitemaps/ping?sitemap=http://my.blog/url/sitemap.xml.gz
Woo hoo, success! I’d better alert my web hosting company so that they aren’t blindsided by the sudden bandwidth spike.
A few days ago, Joseph and I were talking about bolting statcounter onto our blogs. He’s the one that pointed out statcounter to me, and all he needed to do was add the statcounter script to his theme’s footer.php file. This would probably work for any single-theme site, but I’m still running multiple themes on my blog. I need to do one of the following if I want to use statcounter:
- Drop all but one theme. There are several good reasons for this, most important of which is maintenance. This would allow me to add the statcounter script to the remaining theme’s footer.php and I’d be done.
- Add statcounter to all my themes. This probably wouldn’t be too bad, except for maintenance–whenever a new version of one of my themes came out, I’d have to manually reapply my changes.
- Write a plugin to insert the statcounter script in the footer of every page. This would be the most work up front, but it would give me a good excuse to learn how to write plugins for WordPress.
I found some useful resources for plugin authoring. The WordPress codex has a section on writing plugins. Owen’s tutorial is a great introduction–just read it and start hacking! 
Carthik’s Plunge into Plugins article has lots of good advice, but isn’t a tutorial–check it out after/while you get started with Owen’s page. More good info is available on the Codex page Writing a Plugin.
I’ve started working on this plugin, and I’ve already been bitten by the “extra blank line” problem. (Admin interface was reporting “Cannot modify header information - headers already sent by…” error. Note to self–scroll to the bottom of each PHP file, and make sure the PHP close tag is right at the bottom of the file.) I have the code to insert arbitrary text into the footer, but I still need to add the Options menu which would allow J. Random User to edit the text to be inserted. (Right now, the text is hard-coded in the “plugin”, which I have installed and activated on this blog. Check the bottom left corner of any blog page for the statcounter.)
I don’t see any reason for this plugin to be statcounter-specific. It would be more useful to provide some sort of generic footer plugin which would allow HTML or javascript to be inserted in the footer. We’ll see how it goes. If I’m happy with it by the end of the night or later this week, I will go ahead and release it.
I stumbled across this post from almost exactly one year ago. Joseph, I salute your effort, and the fact that you made this work is very cool, but I think this approach (relatively low-level network programming) may be the wrong track to pursue. I think a more appropriate method would be network API’s for new or existing applications, or at least higher-level libraries.
Network overhead is obviously vastly more “expensive” than local function calls, so you should probably reserve network functions for heavyweight applications. You mentioned databases–I think this is actually a good use of network programming! I have in mind something like the USPS’s ZIP code lookup. There is obviously a database backend on this web app. Granted, one cannot make arbitrary database queries (nor inserts, updates, deletes), but it does serve up the data quickly and competently. The database sits on the same machine (or topologically “close”) to the API server. Google is another example, and smarter people than I will come up with many more already-existing web services with DB backends. I think this is where Internet programming can really shine!
One of the reasons that I chose WordPress for my blog software was because of Joseph’s and Acetylene’s blogs. Now I need to upgrade from my out-of-the-box theme and get something a bit more interesting!
