Bell’s Expedition Stout is growing on me tonight. I didn’t like it much at first, but it’s growing on me.
I overheard someone here at work the other day saying that they like to take a late lunch because it makes the day go by faster. Man, I haven’t felt like that about a job–just doing my time–since I worked as a bagger / cashier for Farmer Jack.
I’ve alternated between states of so thoroughly enjoying what I was doing, and feeling stuck for the long haul until I managed to finish what I was doing. In either case, whatever hour it happened to be never figured into it.
Hot damn–one chapter left to write for the first draft. Hoping to have that done by Monday or mid-week, then I want to take a tour through the whole beast and ruthlessly slice and dice all the crap code I’ve left here and there and improve things in general.
It’s strange, but it took me awhile to realize that most everything I’m doing for this book are things I wanted to eventually do for FeedReactor. That realization hit me like a miniature paradigm shift that made me really want to rework some of the chapters I’d written months ago and attempt to pull things together in a more coherent toolkit / narrative. (That sounds kind of pretentious / awkward, but it’s what comes to mind.)
Now I alternate between worries that I’ve made things too complex, or that I’ve not done enough. I’m really hoping I’ve overcome my Beginner’s Mind worries in this book by the end, and have produced something worthwhile. It’s occurred to me, finally, that what I want this thing to be is a possible baseline starting point for anyone wanting to hack feeds.
I see so many projects starting from ground zero, reinventing so many wheels. If they’re lucky, a given tinkerer has least delegated parsing to something like Mark Pilgrim’s feedparser. But–and this is a big goal–I’d like this book to have done for other areas of feed consumption and production a bit of what feedparser has done for the ground floor of feed hacking. (Albeit lacking about 2000 tests.)
That is, providing a practical and usable swiss-army knife array for use in all your syndication feed experiments. It won’t necessarily be the most theoretically pure set of tools, but it should help you on your way to getting your job done.
The coolest thing for me would be if some tinkerers out there got their hands on my book and–instead of wasting time on yet another way to remember what feed entries their program has seen before, or fussing with syndication format conflicts, or hashing out one more way to handle various HTTP headers–they actually got straight down to some more interesting applications and analysis of feeds.
Anyway, excuse any oddness in the previous prose: I’ve emptied 3 of those aforementioned Expedition Stout bottles so far this eve. Good stuff.
-
About Me
Hi there! My name is Leslie Michael Orchard. I'm a serially enthusiastic, caffeine-dependent {web,mad,computer} scientist and {tech,scifi} writer working for the Mozilla Corporation and living near Ann Arbor / Detroit in Michigan.
-
Buy my books
6 Comments
I seem to have waited in vain for years now for ports of feedparser to other languages. In particular PHP and C#. For PHP, Magpie is not bad but it still barfs on feeds that are not perfect XML. And without re-igniting that debate, I want a parser that will do it’s best even when the feed is broken.
Maybe this is a lazyweb request.
Well, for Java, there’s also Rome (https://rome.dev.java.net/), although I’ve not yet had a chance to play with it.
But, yeah, the existence of feedparser only for Python has exerted quite a pull in keeping me programming in Python while I want to play around with Lisp, Ruby, and C#. And, I seem to remember someone was playing around with a port of feedparser to another language, but the link escapes me.
Anyone trying to port the thing is likely to go mad, though… have you ever looked at what all that thing does? :) It’s a very useful tool, but it’s also a concrete demonstration of why we really need to insist on valid feeds.
(Oh yeah, and valid feeds from clear and consistent specs, too.)
(must..resist..retort…)
Personally, I don’t see what the deal is about generating valid XML. It’s just not that difficult.
(Now, talk to me about getting encodings right, then we’re on the same page: that can get arbitrarily complex. But I’ll tell you to simply stick to UTF-8 and forget your worries, because that Just Works.)
Anyway:
Count yourself lucky. Very few people have this luxury, even in the “civilized,” “modern” world.
PS.: I was going to ask you to enable at least some rudimentary markup such as italics, blockquotes and the like, since you moderate your comments anyway. Then I noticed in preview that you’re running your comments through Markdown. That’s even better, but maybe we could have a notice about that on the comment form?
I’ve tried to port some tests from the feedparser suite to the RSS library in Ruby. Due to lack of time and ultimately interest, I drop the ball very soon. I also had a look at Mark’s code, but gave up the idea of a port as well: that thing needs time to be studied before attempting a raw port to any language. But, yes, it would be cool to have someone (else) to do it.