Help Blog*Spot suck
Danger: sarcasm ahead! Note that I have spent quite literally thousands of hours helping people use Blogger and Blog*Spot, because I believe in the power and value of personal publishing. I also believe that if you are pulling tens of thousands of hits, you should get the hell off Blog*Spot, now. The reason Blog*Spot sucks these days is because people are using “the quick spot for your blog” as “the permanent place for your blog, because you don’t want to pay for hosting for a page pulling serious numbers.” I don’t want Blog*Spot to fail: I think that it is a very important part of Blogger’s success. In a few minutes, with no cash outlay, you can see how Blogger works, and see your thoughts published on the web. I just don’t see any way of moving the people (*cough* instapundit *cough* samizdata *cough*) who should be getting their own hosting out, short of either publicly stating, again and again, that they need to get the hell out, or Blog*Spot getting intolerably bad. Thus, a modest (hint: that means sarcastic) proposal…
It seems I’m not the only person who thinks that Blog*Spot should suck harder. Rand Simberg wrote himself a script which checks Blog*Spot (every thirty seconds), and displays a traffic signal in his (non-Blog*Spot) weblog to tell you whether or not Blog*Spot is up. You know, if you can’t tell whether an “unable to find server” error means that it’s down, or…, it’s down. Yeah. But the good part is, checking every thirty seconds, with a GET request, rather than a measly HEAD request that would just return a 400-odd byte header, Rand is managing to add almost 3000 extra hits a day to the overloaded Blog*Spot server. Doesn’t matter whether anyone is viewing his weblog at 3 am on a Sunday, it’s still checking. And just in case that’s not enough, now he has made his script open source, so anyone who can run Perl scripts can add another 3000 extra hits a day. If just two people do it, that’s nearly 6000 extra hits a day. And if 50 people do it (can you imagine, 50 people a day), why that would be an extra 144,000 hits each and every day.
It’s a beautiful effort, but it leaves out all those people who would like to help destroy Blog*Spot, but can’t run a Perl script day and night. How about this: it wouldn’t be difficult to do a Javascript which would just reload a Blog*Spot blog or two in frames, say every five seconds. Then all you have to do is leave a browser window open whenever you aren’t using your computer. If you pick blogs with a ton of posts on the main page (who needs archives, when you can just leave 150K of posts on the main page?), with a little adjustment of the timing and the number of blogs you are reloading, you should be able to keep a constant stream of requests going to Blog*Spot. Think of it as a DDoS-by-blog attack. We can make Blog*Spot so bad that nobody will want to use it in no time.
And by the way, I wouldn’t count on his traffic signal actually telling you whether Blog*Spot blogs are available or not, since it’s checking www.blogspot.com, which isn’t always down when Blog*Spot blog are unavailable. I just hope that won’t affect its ability to hammer the server. </sarcasm>
Gee Phil, I hope you are not encouraging people to DDoS blog spot?
While I hate things (and companies) that suck too, I wouldn’t encourage such aggressive revolution.
Just email Ev every time Blog Spot is doing VeryBadThings™ .
Oh. So you’re saying I veiled the sarcasm a little too heavily?
I also got the impression you were supporting this. In fact, Im still not clear you arent.
are you?
There, how’s the new version? Probably not so good for the color-blind, but you can’t win them all.
heh. much better :)
That perl script doesn’t check to see whether or not it’s already running before it starts. So what do you think the chances are that there’s going to be at least one perl newbie who ends up running the command 20 times while testing it out, not realizing that all 20 processes are running concurrently?
Doesn’t Blogger Pro limit the traffic you can have up to certain point, then you have to pay? Or something to that effect? Ev should start doing the same thing with Blog*Spot – but on a decidedly un-Geocities-Angelfire sort of way. I mean, 90% of B*S (heh) users aren’t garnering the sort of traffic that the biggies are, right?
I’m not proposing the End Of Free, mind you, just a little help from the people who are filling B*S with so much B*S that it can’t function properly anymore.
I mean… if Ev charged an amount that was super-competitive with an actual hosting company, I think he could get away with it.
Ev should put a ”hit cap” on sites. After a certain amount of traffic, do what GeoCities does: ”Sorry, this site is over it’s limit.”
That would kick the moochers in the ass and hopefully shame them into coughing up $9 a month to host a blog properly.
Like Ev has time to code that up, though.
In theory, you have to pay extra if the total size of your posts in Pro goes over 100K per month. In fact, almost every single Pro user (including me) whined about it so much that it isn’t being enforced.
I think a B*S cap would be a great thing, both in terms of bandwidth (”Hey, ___, I tried to get to your blog, but it said ’this site has exceeded its bandwidth allowance for this hour’ – why don’t you move to a decent host?”) and in terms of main page size (which you could do automatically in the publishing routine, adjusting the number of posts shown on the main page to keep it reasonable), but both caps would require Ev’s time and effort to implement, and both would increase his email load, when my goal is for B*S to take up less of his time, so he can spend more time working on things I really want (API support for Pro features, RSS, cross-browser interface, on and on…).
Running 20 instances of Blogspot Watch – terrible, and likely. I can’t believe I missed seeing that. Make that an extra half-million hits a day.
Damn, I’ve got to either type faster, or remember to preview, so I don’t say the same thing someone else said eight minutes before!
Frankly, Phil, I can’t believe the amount of patience you have to answer (the same damn) service questions from B*Sers (I like that) who complain when their free service isn’t working.
It seems like the staff is caught: restrict or limit access (say you can only spend 6 months on B*S or put hit caps) and you alienate users (granted, they’re cheap users), or drive B*S into the ground.
I guess I’m just left saying ”thanks” for the support you provide. I’m grateful it’s there, and when I move, I’m sure I’ll miss how easy it was.
Hey Phil – is YACCS down or something? I can’t get into a bunch of my daily reads, and I think the thing they have in common is YACCS. My journal also won’t come up (yes, YACCS) but the rest of my site will. [insert pouty rockstar face here]
i think its down.
And down for a long time, by Hossein’s standards. I might be able to work out a way to do it like my remote dotcomments script, which fails quietly without slowing down the page load when the remote host isn’t available (at the expense of not giving counts to anything but IE5+ and NS6+/Mozilla), but YACCS has had so little downtime that I haven’t ever gotten around to seeing whether or not I can work it out.
Hey Phil, I would appreciate it if you could explain to me how you do the delayed loading. I remember seeing the ”comment” link change to ”x comments” on your old radio page, which was nice.
I’d be happy to talk your ears off about it (your eyes out? blech!), but I think we talked about it in December or January, and you felt then that counts for any browser were better than no-delay loading.
You can see all the code in my remote dotcomments blog and you can still see it in action in my FAQ blog, but in a nutshell, you add defer=”defer” to the remote script loading tag, so the browser doesn’t wait for it to load, add <span id=”commentcomment</span> where you want the comment count (you would probably need to move the link into the Blogger template, instead of writing it from the remote script), and then the body onload event calls a function that checks to be sure it’s in a browser that can do DOM-based stuff (if (document.childNodes) seems to work in browsers where it will work (IE5+, NS6+/Mozilla, without letting Opera lie its way in), checks to be sure that the remote script loaded (if typeof(a var from the script) != ”undefined”), and then goes through the array of comment IDs that the remote script provided, trying to getElementById(theID). When it gets an element with that ID, it works its way down through childNodes, looking for one with nodeType = ”3” (a text node, because sometimes in some browsers, the text inside the span isn’t the first child node), and if it can find a text node child, replaces the nodeValue with the count for that comment ID, provided by the remote script.
Problems that occur to me so far, doing it in YACCS: you’ll have to send a bit more data, since you have to keep sending the get_comment_link function while adding a dom_comment_count function; your installation instructions get more complicated (”do this if you want counts for all browsers, do the other if you want to not have your page hang if the server is down”); adding a onload=”dom_comment_count()” to the body tag isn’t trivial to support, since you’ll have people who already have an onload, and people whose page doesn’t always load enough to fire the onload (Blog*Spot with ads is bad about hanging when an ad doesn’t fully load); and, at least in my last-August experience, after you say four or five times in the instructions that it only works in IE5+/NS6+, you’ll have people saying ”but it doesn’t work in my NS4.x!”
I think it’s worth it (in part because I love redrawing the page with the DOM – you should have seen me hitting reload and laughing and hitting reload again when I first wrote it), but my audience is highly filtered by being Blogger users, so I rarely see anything but IE5+ and Gecko-based browsers. Your audience, and their audience, may have a lot more NS4.x and IE4 and Opera.
phil rocks :)
Doesn’t he? :D
Phil: Has anyone told the guy making this script available what a horrible idea it is? I’ll do it if no-one else has, but since I’m just going to link to you, and I don’t usually read him…
Oh yes: would just adding ”defer” to my Blogger template, by itself, help if YACCS goes down again? (I caught it early and commented out the script links, so I didn’t have much of a problem, but a lot of people don’t realize that if it’s hanging on a remote site, you might just try hitting ”escape” and see if the rest still loads…)
He knows now, and seems quite agreeable to making it less abusive. I tend to think of B*S as being in nearly the same class as YACCS: something that someone is doing entirely on their own tick, out of their bedroom, that should be protected at all costs. I tend to forget that from the outside it looks more like Geocities: a business venture that doesn’t deliver what it seems to promise.
No, you can’t just add defer=”defer”, because that says the script isn’t needed to lay out the page, and right now it is: if it doesn’t load before the first comment link tries to call get_comment_link(), then the whole thing blows up. Lets give Hossein a couple of days to think on it, and if he (reasonably) doesn’t want to try to support yet another scheme, I’ll look at grafting it on from the outside this weekend: I’m pretty sure you could do a DOM-based script that extracts the counts from his script, but since it’s written to minimize bandwidth (ycsx is the longest variable name, most of them are single letters), I’d rather let him do it, so I don’t have to sort out what’s what.
All this geek talk is turning me on. Stop it, you guys.
rawr!
Ok, I think I’ll give it a shot. I’m just really backed up right now, so it might take a few weeks. In the meantime, you can check out the commented, readable javascript code here if you want to mess around with it.
Now that I think about it, you don’t have to change or add a thing to the remote script: since you have to have at least the function that the body onload calls and the check for whether the remote script loaded in the template, outside the remote script, you might as well have all of it there. I’ll try to look at it this weekend, and see if I can either slim it down/pretty it up, or make it a little more cross-browser. Despite being one of Google’s top resources for lots of ”Opera someDomProperty” searches, I haven’t really looked at what they have got implemented for quite a while.