Photo by Chris Sternal-Johnson, http://www.flickr.com/photos/ceejayoz/371137761/

This is all a bit anti-climactic given that if you were an actual Chat Catcher user, you’ve known that the system was going away since at least October 20th, but the final day has come and gone.

Shannon Whitley, the creator of the Chat Catcher service, wrote in an email to all the users:

While it was fun to create multiple Twitter applications in 2008, Twitter’s extreme growth has made it tough for a single developer to manage this type of software project. Hosting, storage, and ongoing support costs are just too high to justify the continuation of a free service.

I really liked Chat Catcher, which I first discovered as a combination WordPress plugin and service back in 2008 – liked it so much I built a Drupal module for it.

The core value of Chat Catcher was that it turned tweets referencing URLs in your domain into trackbacks, essentially – by pinging you (via a defined web hook) whenever your domain was mentioned in a tweet, even if that URL had been run through a URL shortener.

While I know BackType has an API you can use to *request* all the tweets mentioning a given URL, that requires you to be constantly polling: much less efficient.

That said, what are the alternatives? Kris Buytaert started an issue on the Drupal module page looking for alternatives, and I mentioned a few WordPress plugins there – but I don’t think there are any external services which proactively reach out to your site rather than requiring you to constantly search twitter for your URLs.

Know of any?

Photo by Mike Johnston - http://www.flickr.com/photos/mikejsolutions/3078513728/

Just found this long overdue review of Ajax and PHP: Building Modern Web Applications – Second Edition sitting in a drafts folder – looks like I never published it. (Full disclosure – Packt sent me a review copy).

This is the successor to the wildly popular Ajax and PHP: Building Responsive Web Applications, which came out back in 2005. The authors of this edition are Bogdan Brinzarea-Iamandi, Christian Darie, and Audra Hendrix. (Brinzarea-Iamandi was also one of the authors of the first edition).

This is a really useful book for the right audience, covering:

• Simple PHP, including connecting to MySQL
• Basic MySQL and relational databases, including some basic queries
• JavaScript, including a discussion of object oriented JavaScript and the benefits thereof
• JQuery, which is rapidly becoming the dominant JavaScript framework (and is now included in applications like WordPress and Drupal)
• Debugging approaches and techniques, including profiling
• Cross-site scripting exploits and how to mitigate them
• Cross-domain ajax calls using server proxies, Flash, iFrames, and JSONP

In other words, although it does use Ajax as the ostensible subject at hand, in order to explain how Ajax works in the context of real web applications, the book ends up covering a wide ground in a rapid fashion. The book culminates in two practical examples: a chat application and a data grid, both using JQuery, PHP, and MySQL together in familiar patterns.

More experienced readers might be frustrated by how quickly the book moves through these topics. Trying to cover, for example, “Object oriented programming concepts” in four pages requires a very concise definition and not a huge set of examples or illustrative excercises. The book also doesn’t stray outside the LAMP stack, to talk about Ajax in Microsoft.NET, Java, Python, or Ruby applications, and doesn’t address other relational databases, let alone the whole NoSQL movement. There’s also no HTML5 discussion, but you have to remember the book was published in December of 2009.

One decision which struck me as odd, but may be a reflection of my personal experience, is that they cover (in an appendix) setting up XAMPP for Windows and Linux, but for Mac OS they send you to a web tutorial. Have you been to a web dev conference lately and seen how prevalent the Apple logo is? I get why you’d want to focus in and not try to cover all the cases, but I think based on my experience I might out Mac instructions first.

But coming to this book expecting detailed architectural discussions across multiple platforms is looking for wisdom in all the wrong places. Peruse the table of contents at the PACKT site and see which category you (or whomever you’re buying the book for) might fit in.

All was well and good until the OAuthpocalypse arrived:

The OAuthpocalypse was the end of basic auth, the mechanism involving storing your username and password, which earlier versions of ReTweeter used. Well, Twitter did shut off basic authentication, though in reality it took a bit longer than the announced August 31:

Photo by Bruno Pedro http://www.flickr.com/photos/bpedro/4951321821/

Luckily this weekend I found time to update ReTweeter to accomodate OAuth – get the new ReTweeter 1.0 and give it a try. I’ve used Abraham Williams’ OAuth for Twitter library, which itself relies on Andy Smith’s OAuth library for PHP. Both are MIT licensed and are included in the download.

You’ll need to register your retweeter with Twitter at the register an application page, which will give you a “Consumer Key” and a “Consumer Secret” – you’ll need to copy these values into the configuration section at the top of retweeter.php.

Twitter Application Settings (Click for Full Size)

Then, making sure you are logged in to Twitter as the username for which you will run Twitter (the account which will follow people and where the retweets will be posted), click on the “My Access Token” button in the right rail of the Application Settings page. Here you’ll need to copy the Access Token and Access Token Secret to the appropriate places in retweeter.php:

OAuth Tokens for ReTweeter

Now that you’ve got all the info, open retweeter.php and (in addition to the existing configuration like username, database username, database password, database host, and database name) fill out the OAuth section of the configuration:

// we'll need some OAuth stuff here
// register your retweeter at http://dev.twitter.com/apps/new
$consumer_key = 'Consumer Key';
$consumer_request = 'Consumer Secret';

And:

// then click on "my token" on the resulting page and get these (make sure
// you are logged in AS THE USERNAME you intend to use, as these keys are
// specific to the user:
$retweeter_oauth_token = 'Access Token';
$retweeter_oauth_secret = 'Access Token Secret';

That should do it!

I’ve also updated Retweeter to follow the RT convention, so retweeted tweets will now look like this:

(@drunkjeckman is an old account which I no longer use except for testing. I expect my twitter followers to determine my level of sobriety based on the content of my tweets, not my username).

(photo by hobvias sudoneighm, click for photo page)

Thanks to troubleshooting help from mommyknows and other users, I’ve been able to track down and fix an issue with posting to different kinds of pages.

Thanks to Brooke Dukes, we also now have a site for the plugin itself: wpbook.net – with instructions, blog posts about the plugin, and the like.

Grab 2.0.8.1 from the plugin repository and check it out!

(2.0.8 somehow incorporated a nasty syntax error – whitespace ahead of the opening PHP tag – so skip that and go straight to 2.0.8.1).

For a long time now WPBook has enabled users to cross-post excerpts from their blog posts to either the wall of their personal profile or the wall of a Facebook fan page.

However, in setting up WPBook many users were ending up with:

• Your WordPress blog outside Facebook. (Example: www.openparenthesis.org
• The Facebook application view of your blog. (Example: apps.facebook.com/openparenthesis)
• The Application Profile page for your new Facebook application.(Example: https://www.facebook.com/apps/application.php?id=12797741823)
• A Facebook Fan Page for the Blog, or other Fan Page on which the blog gets published. (Example: https://www.facebook.com/pages/WPBook/44062579871, which in this case isn’t a fan page specific to the blog but to the WPBook plugin itself).
• Facebook Tabs, which can be added to users’ personal profiles (including your own), or Facebook pages (either a Fan page or an Application Profile page). (Example: https://www.facebook.com/pages/WPBook/44062579871?v=app_12797741823).

Starting with 2.0.8.1, WPBook can instead post directly to the wall of the Application Profile page – which is a nice way of showing potential application users what kind of blog posts come through the application.

Of course, you can post to your own profile’s wall in addition to a second target, which can be any of these:

• A Fan Page wall
• Your Application’s Profile page
• The Wall of a Facebook group

If you post to a Fan Page wall or an Application Profile wall, the post will come from the Application; if you post to the wall of a Facebook group, the post will come from your personal profile.

Settings for Profile ID and Page ID

You should provide your personal Facebook Profile ID in the WPBook settings, and then in the field provided for “PageID,” you can provide:

• An actual Page ID, for a Fan Page. (To find this, click on “edit page” – the url will look something like this: https://www.facebook.com/pages/edit/?id=44062579871 – the Page ID is the part after id=)
• An application ID, for an Application Profile page. (To find your application ID, go to the Application profile page, the url of which will look something like this: https://www.facebook.com/developers/apps.php?app_id=12797741823 – the Application ID is the part following app_id=)
• A group ID, for the wall of a Facebook group. (To find your group ID, just visit your group page, the url of which will look something like this: https://www.facebook.com/group.php?gid=149948248362737 – the Group ID is the part following gid=)

As always, please post in the support forums with your experiences.

While Times Reader focused on creating a desktop experience that had some of the richness of the print edition, this one is focused on the kind of rapid update stream of information made popular by Twitter, Facebook, FriendFeed, et al.

Times Wire (Click for Full Size)

The best description I saw was Nicholas Carr, who quipped:

The news scroll updates every minute, as fresh stories flicker into consciousness and old ones flicker out. Times Wire doesn’t just give the Gray Lady a facelift; it jabs an IV into the ashen flesh of her forearm and hooks her up to a Red Bull drip bag. It’s Times Wired.

It’s interesting, certainly, to consume the NY Times the same way one consumes updates from long-lost high school buddies on Facebook, but it isn’t clear whether this experience plays to the NY Times strengths, which might be closer to in-depth substantive reporting, investigative journalism, and reasoned opinion, not the latest breaking celebrity gossip or tech scoops. As Tech Crunch put it:

Overall, it definitely seems like a step in the right direction for the organization, as real-time is a hot trend right now. And it’s useful as a live overview of the entire site. But for people only interested in certain topics, it’s probably fine to stick with RSS because the real-time river isn’t flowing fast enough to necessitate keeping the page open.

Richard MacManus at ReadWriteWeb was even less sanguine:

This particular product probably won’t be hugely useful for the general public, it seems more like a product that info junkies (like bloggers) and newshounds would enjoy. But it’s definitely a worthwhile experiment.

Increasingly, I think we’re seeing an openness to experimenting in public. Rather than assuming that “they” (whether you read that “they” as large scale media companies, or as referring to web application designers and developers) know what users/readers want, the developers at the NY Times are experimenting: trying out new approaches, based on hypotheses gathered from experiential data, and then seeing what happens when those experiments are released to the wild.

Check out this 7-minute video from Creativity Online with Nick Bilton and Derek Gottfrid, both part of the overall R&D / Development team at the NY Times, where they discuss how technology relates to journalism and the public experiment that is the NY Times APIs:

(Creativity Online doesn't allow embedding, so click through to view the video)

I love the concept of moving (or helping enable the evolution of) readers into users and ultimately creators, and the idea of journalists who code. Getting a better, deeper and broader understanding of digital technologies infused throughout large media organizations is clearly movement in the right direction.

I wonder, though, if it isn’t better to focus on journalists (and managing editors) with a better understanding of digital media overall, paired with smart programmers who have a broad understanding of journalism.

In other words, rather than journalists who have learned to write code, I think we need journalists who really use the Internet and have a broad understanding of what digital media make possible; they can set the hypothesis for the kind of public experimentation we need, and be paired with coders (and user experience folks) who broadly understand journalism but have a depth of focus on application design and development to implement those experiments well. Which, it seems to me, is exactly the approach the NY Times is taking.