Tuesday night I gave my RSS, Atom, APP, and All That talk to the Amateur Computer Group of New Jersey JUG in Scotch Plains. This is the seventh time I’ve given this particular talk, and I think last night I finally understood something about blogs that had eluded me up till now.

I’ve noticed for a while that blogging really represents a phase change in the Web. It has turned the Web from a read-only medium to a read-write medium. What I couldn’t figure out was why. There’s nothing technically different about using WordPress or Blogger compared to editing HTML and uploading the files to the server. Sure you don’t have to know HTML to blog; but there’ve been HTML editors that look like word processors for 10+ years now, and they didn’t lead to the explosion of content with blogs. FTP’s a bit of a pain for a non-techie, but there’ve been content management systems and editors that use HTTP PUT and/or hide the FTP client. None of them led to the explosion in content we see with blogging.

Nor is it that there’s one service that’s just particualrly well done that has allowed blogging to explode. If so, you’d see something like MySpace; that is, all the blogs on one site or platform instead of the plethora we have today (WordPress, Movable Type, Blogger, etc.).

But there is one thing that all these blog systems (and most others) have in common that none of the editors like DreamWeaver or Content Management Systems support:

User don’t have to pick their URLs.

This entry was posted on Friday, June 16th, 2006 at 6:08 am and is filed under User Interface. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

I’ve probably wasted two hours over the last couple of days trying to debug this line of code:

private static final QName name = new QName("valid-isbn", "http://www.example.org/books");

Do you see the bug? I’ve made it even easier to find by showing you just the line that contains the bug; but it still doesn’t jump out at you. Originally, of course, I didn’t know this was the buggy line. The exception was thrown somewhere completely different in the code base, but this is indeed the buggy line.

This entry was posted on Tuesday, June 13th, 2006 at 8:10 am and is filed under Blogroll. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

I’ve been trying to clean up the serialization story in Jaxen lately. Bottom line is that you really shouldn’t just willy-nilly declare that classes and interfaces implement Serializable. Getting serialization right is not hard, but it is tedious, and it needs to be thought about and tested. There’s a lot more to it than just adding implements Serializable to every class.

After I filed one bug, the usually reliable Brian Ewins made the comment that, “I also thought it was considered best practice not to declare interfaces serializable.” That sounds plausible, but I can’t really figure out why, nor can I make strong case for the opposite position. So here’s the question. Given an interface Foo is it or is it not a good idea to declare that Foo implements Serializable? (given that you do in fact want the instances to be serializable, of course.) Or should one leave implements Serializable off the interface and just place it on the concrete classes? Why or why not?

This entry was posted on Thursday, June 8th, 2006 at 9:53 am and is filed under Blogroll. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.

We’ve known for a long time that cookies are are deeply antithetical to the design of HTTP and the Web (#1). We’ve known they are used to track users and violate privacy (#2). However, I recently had called out to me yet another reason why cookies, specifically user authentication cookies, are bad for you.

This entry was posted on Friday, June 2nd, 2006 at 6:12 am and is filed under Web Development. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.

Most object oriented programming textbooks and courses explain the need for access protection and data encapsulation by claiming that it separates interface from implementation. Thus it allows programmers to vary the implementation independently of the interface for optimization, backend changes, or other reasons. This is wrong, and this claim is the source of a lot of bad theorizing on a host of subjects including finality and the choice between interfaces and concrete classes.

This entry was posted on Thursday, June 1st, 2006 at 7:40 am and is filed under Blogroll. You can follow any responses to this entry through the Atom feed. You can make a comment or trackback from your own site.