I work on TypePad, but I mostly work on the engine and not the bodywork...

Update has been hidden from all public facing feeds in Typepad

Recent Activity

While I agree that it's important to pay attention to this problem of maintenance of existing systems, I'd argue that this is still a form of technical debt; not spending time keeping systems up-to-date is still a shortcut that leads to pain in the long term, which is exactly the definition of technical debt.
I think a better analogy is the distinction between taking vitamins and taking painkillers: the latter makes you feel better when you're sick, but the former can reduce the likelihood of getting sick in the first place.

Back when I worked at LiveJournal, Brad Fitzpatrick commented: Our standards are continually being raised, so by definition any old code is ugly because new best practices have emerged in the meantime. This has always stuck with me in the back of my mind, but it came up again in a conversatio...

I'm curious to hear why you find PUT confusing, since I personally find it much more intuitive, but maybe that's because I've remolded my brain sufficiently. :)
Using Apache is of course just an example. Working closer to HTTP's core concepts means firstly that more of the required software stack is already out there and secondly that the PubSubHubbub spec can be simpler since it can just refer to HTTP's existing definitions of these concepts.
And as for "who uses Apache for their PubSubHubbub listener?", right now that's probably close to zero but I wonder if that's just because it hasn't been easy until now. It's unlikely that someone would use a feed-like resource in this way, since they'll want some application code to extract the items out of the feed rather than to just store the feed verbatim, but for something more atomic like an image or a Word document it's more likely that I'd just want to copy the data byte-for-byte onto my own server, and most HTTP servers can already do this.
And sure, we can debate this in the group, but the debate there tends to get pretty heated so I think I'll wait until later, when I'm less busy, to start a thread. :)

PubSubHubbub was concieved as a protocol for delivering push notifications of updates to Atom and RSS feeds, and I think most would agree that it has been somewhat successful in doing so. However, almost immediately people became interested in either making it support other specific serializatio...

Julien,
The difference is really just that PUT has better-defined semantics and therefore generic server software like Apache HTTP can handle it out of the box for simple cases rather than needing to run some custom application code to handle the notification. Of course, in many cases you will want a custom application to do something deeper with the new data, but I like the idea of applying this to simple cases like, for example, copying an image onto another server and updating it when the source changes.
Since HTTP basically defines POST as "some action but we don't know what it is" you always need specialized software to handle it, and the PubSubHubbub spec needs more prose on how to process the notification rather than just referring to what's been established by HTTP.
But really my proposal was not about using PUT specifically but rather applying the full set of HTTP resource manipulation verbs (DELETE and PATCH too) to this problem rather than wrapping the result in a "notification envelope" as we do for Atom and then having to re-invent mechanisms to communicate the difference between "this is a full resource", "this is a delta" and "this is a notification that the resource no longer exists".

PubSubHubbub was concieved as a protocol for delivering push notifications of updates to Atom and RSS feeds, and I think most would agree that it has been somewhat successful in doing so. However, almost immediately people became interested in either making it support other specific serializatio...

Most commercial software has any warranty disclaimed by the EULA too, so that's a bit dumb.
Not to mention that there are a bunch of risks around commercial software: bugs you can't see or fix for yourself because the source is unavailable, company going out of business and software going unmaintained, etc, etc.
Dumb, du-dumb dumb dumb!

Some of our solutions contain open source software, which may pose particular risks to our proprietary software and solutions. We use open source software in our solutions and will use open source software in the future. From time to time, we may face claims from third parties claiming ownershi...

The problem with this idea is that the password on sudo is not there to authenticate your connection -- that's what the auth handshake at connection time is for -- it's there to try to prevent attacks of the class where you walk off and leave your desktop unlocked and someone else walks up and uses your already-established session to run privileged commands.
Therefore, for the purpose that password check is intended for, you defeat the object entirely by making it just re-use the ambient connection auth credentials; you might as well just enable NOPASSWD on sudo and have done with it, since the result will ultimately be the same.

I am perpetually tired of typing in a password to authorize my actions. Though that's enough in my mind to warrant a search for a solution, there is also the world of auth system conflict. Companies are perpetually in search of a "unified auth system." Or at least this is common enough that your...

I used to do this except that I would have my email clients write my outgoing messages directly into the archive by configuring it to be the "Sent" folder. Then I view my Inbox in flat mode as a todo list of things to deal with and have the archive folder in threaded mode where I can see context if I need to.
However, since Exchange makes it hard (impossible?) for me to configure server-side filters without a Windows I'm back to manually managing my mail. *sigh*

I've spent years and years in pursuit of the best email management scheme. Consistently I find that the folks who are on top of their email are the folks who've adopted a scheme like this one. So, it works. It's very simple. (1) On your email server, you configure a server-side rule that copies ...

TypePad generates open graph protocol markup to help Facebook find the right picture, but it generates a tag for each of the images in your post and then a tag for your userpic. (and then, for some reason, a second identical tag for your userpic.)
So my best guess would be that Facebook was previously taking the first og:image tag and using that, but it switched to the last og:image tag instead? It doesn't look like anything changed on the TypePad side recently that would inspire this change in behavior, but I guess some further investigation is required.

lately i've seen some pesky bugs with typepad.... anyone else seeing this behavior? 1) the blogit bookmarklet: when i use the blogit bookmarklet the title is not sticking for some reason. instead of what i enter into the title field, it is replaced by the page title of the source. (which also be...

I wish more sites would follow TypePad's lead with default userpics. As you said, they are attractive but don't convey any particular mood or personality, so they don't inadvertently set any preconceptions about the person who they are associated with.
But best of all each user -- even anonymous commenters -- gets one assigned at random from a pool of 20 and that userpic sticks with them until they upload a "real" userpic, so if you have a discussion with 3 different default-userpic users, chances are they'll each have a different but consistent userpic so you can easily follow who is who not only in that discussion but across discussions too.
The TypePad "spirograph" userpics have a big place in my heart because, although I can take no credit whatsoever for the ideas behind them, implementing them in code was my very first project when I started at Six Apart and I loved the idea as soon as it was explained to me by all of these new coworkers I barely knew. :)

Did you get a visit from the Google Feature Fairy yesterday? I did, and some lovely new colors appeared in the top navigation bar. I saw some changes on the Grand Ol’ Search Engine page, too. Then, a curious little bubble hovered in the right sidebar of my Gmail inbox, reminding me of the us...

My problem with most of the blog posts I read They’re too long. via www.quid.pro With the advent of stripped down sharing services like Instagram and SoundTracking, that make a virtue of simplicity and lack of features, I'm wondering if there should be a blogging service in the same spirit....

This is neat! But I think it will have problems if a new entry is posted while scrolling, since it'll knock the item indices off by one. You could work around this by keeping track of which entry ids you've already rendered and ignoring any that repeat when you get the next page.
Of course, this doesn't fix deleting an entry or reordering entries, but hopefully those are less common operations. It's a shame we don't have a stream interface for blog content.

It looks like pagination is a new [marquee tag](http://en.wikipedia.org/wiki/Marquee_element). Now all hip websites like [Twitter](https://twitter.com), [Facebook](https://www.facebook.com/) got a fancy infinite scrolling. Scroll down more, you'll get more tweets, status updates or contents. Just...