I just discovered a friend of mine from highschool had a blog online tracking his trip across the US to every ballpark. Check out Summer of Glove to see what a true fan is all about! I'm very jealous! My original blog actually was started when I went to Europe for a couple months and updated my site with my progress as I traveled around. It's great fun to allow friends and family keep up with you while you're on the road.
Not sure if this is old news, but the World as a Blog is a pretty interesting concept. Just yet again another indication that social networking technologies really are taking off in a big way. This one is truly very interesting to watch (though I'm not sure how much real value I get from it).
Hani points out some problems with the Servlet spec that hit painfully close to home.
I'll add a couple that I've run across:
The fact that Filters are only applied to the initial request and not subsequence child requests (RequestDispatchers) is insane. An example of such a need comes up every day, with the most recent being: we use Struts at Spoke (I know, I'm working on switching them to WebWork and Struts is crappy enough not provide any way to log (in a standard format) what JSPs an action forwards to. Now since Struts is probably never going to be good, I figured that at least if the Servlet Spec was decent (I can dream, can't I?) then I could just use a LoggingFilter to do real performance analysis and logging. Imagine:
/dashboard.action 250ms
- dashboard.jsp 180ms
- panelX.jsp 80ms
- panelY.jsp 100ms
Of course, WebWork supports this pretty easily Atlassian has released a profiling tool to do this for WebWork 1.3, I'll add 2.0 support soon.
Another pain with the Servlet Spec is the oddness with JspWriter vs. PrintWriter vs. ServletOutputStream. I know, there are reasons for each one, but honestly, can't everyone just get together and figure out one, simple way to write content to a response?
Also, what's up with having multiple paths to get to places. Sure, helper methods are nice and all, but take for instance: ServletContext.getRequestDispatcher() vs. ServletRequest.getRequestDispatcher(). Yes, I know that ServletRequest has that method just to be helpful, but in reality it's just annoying. In fact, I'd wish that ServletContext lost the method and it was only accessible through a request. When will anyone ever make a request dispatcher with no associated current request? The reason I hate that there are two ways to do this is because Struts chose to use the ServletContext approach, eliminating any chance of me finding a workaround for my logging woes described above. If at least they used ServletRequest instead I could wrap the request and intercept the neccessary calls for logging. Alas, I cannot.
In short: I blame the Servlet Spec followed closely by Craig McStruts. Now if only the rest of the world realized that Struts was horrible, rather than thinking it's "the way to build webapps" (you have NO idea how many people in this community think Struts is the best thing since sliced bread -- I generally just assume they are retarded.)
This blog post by Ross Mayfield (founder of SocialText) seems to indicate Google is going to purchase Friendster. That wouldn't surprise me, since Google has a vast amount of data and could apply social networking to it with little ease (especially given the incredible brain power they hire).
To me this marks the first real shot fired in the battle for social software. I work for Spoke Software that some might describe as "friendster for the business" (it's a bit more than that, but in 4 words it's not a horrible description). I expect to see an incredible amount of battles taking place in the next year on this front.
Interestingly enough, Ross Mayfield's SocialText is one of the many companies looking to redefine the basic Wiki. Another of them is our very own Atlassian, founded by a cohort of mine, Mike Cannon-Brookes. Atlassian recently put out their first alpha of Confluence which aims to take the Wiki to the next level -- or something like that.
Personally, I'm still waiting for the "groupware" that ties in ease of collaboration, bug tracking, and publishing (wiki/bugtracker/blog) in such a manner that is cohesive to your software engineering efforts. I think that a general social software product is nice and all, but development teams do things in a very specific way I've yet to see totally catered to in any product (yet, I'm holding my breath for Confluence).
I'm on Friendster, if anyone wants to be my friend. But I'd love to see more people from the blog community on Spoke. Unlike other social networking software, Spoke takes care of all the data input for you by taking a quick peek (don't worry, it doesn't take anything it doesn't need) at your Outlook, Eudora, or Lotus emails and contacts. I developed Hotmail and POP3 support as well that should be live any day now.
Lastly, check out SpokePeople to see what who has been harvested in our network -- you might be surprised!
Dave Johnson gave a little plug to my book today. Yipee!
A friend of mine today pointed out the first (of many to come, I'm sure) of a problem in my book: a code example in the text doesn't work properly. However, the good news is that overall he says the book is great:
Awesome! Go get yours today!
Hani points out one of my pet peeves: people who write code that assumes there is a file system. I won't restate what he said -- but keep in mind that it also makes unit tests harder to get working. In general, the more dependencies your unit tests has (DB, file system, internet access) the harder it is for people to use and thereby they will become less inclined to write tests.
Looks like the Democrats (Davis or Bustamente, who knows) will continue to run our state since the Republicans can't get their act together. Good news!
blah
Today I updated my website. Apparently I use the word "hella" too often. My bad.