lectroid.net

After thinking it through a little bit I decided a while back to run with the Traffic on Twitter thing and do it up right. The result: sactraffic.org.

I used that same XML feed from the CHP and in addition to Twittering new incidents I created a local JSON feed of just Sacramento area incidents and “mashed up” some geocoding/mapping, local news, videos and even local weather.

Hopefully this makes a simple, yet useful, tool for folks as there are RSS feeds that can be tailored to a particular set of streets or freeways (think: check your commute in your RSS reader before you leave for the day) and what’s even slicker is using Twitter’s new “track” feature to get live updates on traffic incidents at the street or freeway level right to your phone.

Most of this was made possible by the Google Feed and Maps APIs.

It’s been a fun hobby project and was a good refresher on JavaScript which I was getting rusty at (and perhaps still am). Clearly my design skills still suck (hey, anyone have a line on decent traffic icons for Google Maps?).

I’m serious when I say “hobby project” as I’ve tried really hard to keep work on this limited to my spare time at home. I have plenty of work-type work to do at work, messing around with stuff like this at work would probably be frowned upon.

Anyway, I stuck a big ol’ Google AdSense ad on it so if it gets popular maybe I can subsidize my caffeine habit ;).

So if you notice this type of thing at all, you may have noticed some changes to the sidebar over there on the right. Using just WordPress’s built-in text widget I’ve been able to take JSON feeds from Flickr, Twitter and Google Reader and then use a little JavaScript to create nice CSS styleable blocks for display.

In other words, with few lines of code I’ve been displaying information from people’s sites on my site all purdy like.

I love this. Because it means that with a little brain power I don’t have to be limited to the “badges” or whatever other canned widget frou-frou gunk that these sites provide. What’s also cool, it that with a little more brain power I suppose I could “mashup” all this data in some way I haven’t thought up yet, man how web-two-point-ohy is that, huh?

These days my world at work revolves around getting news stories out of my employer’s newspaper publishing system and onto the web via my employer’s in-house web CMS.

Welcome to my nightmare.

You’d think it would be easy, just issue a SELECT * FROM news WHERE date = $today; and be done with it, right? Well, not so much.

Continue reading ‘Why it’s so hard to get print stories online’ »

So I kinda sorta completed my first Facebook app: an app to display Google Reader Shared Items.

Yeah I know it’s been done, that’s not the point. I wanted to see how it’s done, and specifically I wanted to see how to update profiles based on some 3rd party action (in this case “sharing” something w/in Google Reader).

I gotta say, it’s pretty neat. In the case of the Shared Items mentioned above you have a cronned script look at the Shared Items RSS feed and make decisions based on what’s new since the last time it looked. The “righter” way to do it, of course, would be to have the actual act of “sharing” an item update Facebook, but that’s for Google to do, not me.

I think that the most interesting aspect of Facebook is that is can serve as a sorta “meta-blog” where all these various web 2.0 thingys (like Twitter, last.fm, del.icio.us and of course blogs) can dump updates so your Friends can see what you’re up to (um, if they… or you… care about such things).

While I see huge applications for this in my chosen profession, this primarily served as an academic exercise satiating only my geek curiosity, mental calisthenics if you will. Now that it’s done — ok, so it’s not done per se, it’s “proof of concept 80% done” which is “done” to me — I have time to read Deathly Hallows.

Like most newspapers, the one(s) that I support are trying desperately to control expenses and are looking under every rock for spare pennies. One tactic oft deployed is the “write once; deploy many” approach to software (or more commonly: “buy once; deploy many”).

The problem is every newspaper is unique. Simply put, what works for one doesn’t necessarily work for another.

As an example, the papers I support were recently introduced to a new web content management system. The system isn’t really bad, although there are some latent issues, but every paper got — or will get — the exact same interface.

But every paper has subtle differences in the way they do things and this “standard” interface causes issues. It slows down production, forces workflow changes, and even in some cases forces product changes — all in the name of saving some nominal amount of money.

To avoid such nastiness, those papers lucky enough to have access to journo-geeks have them work up all manner of band-aids and workarounds. Yours Truly is certainly guilty of such hackery. The problem here is that who’s gonna support said band-aids if/when that journo-geek disappears? What if your journo-geek gets hit by the proverbial bus? Furthermore, what will happen when the offending system/application/whatever is updated? Will the band-aid update with it or will it blow apart requiring frantic emergency pages in the middle of the night?

The obvious (to me) solution is to shoot for “one size mostly fits all,” then provide ways for the journo-geeks and their ilk to tweak and modify things as they need. Make that way flexible yet scalable (upgradeable). And for crying out loud, make it documented.

Make it an interface so that programmers can modify your application.

Get it?