So it's been about 2 weeks since I released BlogFile, and what's happened in that time?

Well, it spent some time on the HackerNews front page; a few people have found it, adapted it, and are using it (it's always good to have that as a form of validation); the auto-spam filter I built has already protected me from a heap of web-crawlers looking for comment fields; and the software has served up more than a few thousand page views.

I also received some criticism about the way I dealt with certain things in the code, which I'd like to address here.

1 - Using sleep() as an attempt at slowing brute-force attackers just opens an easy DOS vector.

Yes, you're right. It does, and so I've removed that. Ideally, I would love to use bcrypt or scrypt to hash passwords, but as far as I'm aware, the PHP implementations of it are only available in PHP 5.3+, which rules out just about... most shared hosting environments on the net (I'm hosting this site on Dreamhost myself, because I like not having to fight with servers if I can help it).

2 - Using two fast hashing algorithms (md5 and sha1) won't protect passwords for long.

No, probably not. It's better than a single md5 hash (even a salted md5 hash), but let's face the facts here; this is blog software, not a bank. There's only a single user to sign in, so if someone does go to the effort of brute-forcing the hashing of passwords, all they'll get for their effort is... one password. Which you can change. If you're using your banking password to control access to your blog, then you have bigger problems than a slow hash can help you with.

3 - Why are you serving out the CSS in the body with every request? That's slow and bad!

If I had a massive amount of CSS, that may be the case. If I was worried about the massive amounts of data transfer needed, then I would have cause to be concerned. To you want the reality, though? The download footprint of this blog, with CSS, is tiny. So tiny that the Google Analytics tracking code is 3 times larger than the entire home page that it's tracking. I ran a few tests, and even running on a shared host, the entire content for the home page of my blog is generated and returned within about 1 second, including DNS lookups and connecting to the server. Separating out the CSS into another file could only make that slower (it would need to perform more lookups, more connections, and do more processing just to even tell you that the file hadn't changed).

4 - A 1000+ line long switch statement? That's madness!

Yes, not my finest moment, but it does the job. At some point, I'll consider re-writing it (maybe making another helper class or two) to make everything more concise. Who knows?

5 - There's a micro-blog in <x language> which has less lines of code...

So? This isn't a code-golf blog. The main purpose was for me to test out a few thoughts and ideas that I had relating to building a full system in a single file, and to see how a single-file constraint would affect design decisions (both UI and code) that I made. Well it turns out that the constraints made me realise that I didn't actually need a few features that I was building, and didn't need extra cruft like JavaScript (in case you hadn't noticed - everything here is pure html/css - apart from the GA tracking code, but that's non-standard).

Aside from that, a few of those "low code micro-blogs" are actually building on top of frameworks (such as Ruby On Rails), so while the code written specifically for the app is tiny, the code required to run it is rather less so.

Anyway, The blog is running, and running well. I'm happy to see a few people getting in the spirit and mashing my code into their projects. It makes a man proud.

Happy 2 weeks, BlogFile!