Sometimes you just have to start fresh
At some point in nearly every major site's life, it reaches a point where it simply can't always go out to the database for every request. That point in DZone's life came just after the launch of Dzone 2.0. About a week or so ago, I was sitting around at my house one evening and decided to have a second go at implementing a fast, reliable caching subsystem in the DZone architecture. I say my second attempt, because during the Christmas holiday, I had attempted to implement this very same caching system and failed miserably. So, what has changed? I think the primary thing that has changed is my perspective on the whole thing. After our highly successful launch of DZone 2.0, I think I felt a bit like the conquering hero, so I turned my sights onto a problem that had been brewing for some time. When I wrote the first bit of code four months ago, DZone didn't really have any need for the caching system - it wasn't a priority. Now, with the growth of DZone, we have a little more need of the caching system and so the pieces just fell into place. While everything isn't completely perfect yet, we've made big steps to caching nearly all the data that is requested. The queries that were becoming problematic simply ceased to exist as we dramatically simplified what was getting called. In fact, if I were to go through and actually remove the queries from our IBatis mapping file that weren't being used, I would estimate that we are probably half our original file size. By now, many of you are probably asking: what solution did these guys go with? We looked at several of the different options out there, some free and others not. In the end, I selected the latest beta of JBossCache. I'll admit that I wasn't terribly impressed with the earlier versions of JBossCache. Its API was quite a bit foreign to me, but the newest betas appear to have really reworked the entire system, making it feel a bit more natural. On top of that, we've started to implement our own API layer so that if we choose to change implementations later on, we won't have to rewrite our entire system. In addition, the question of "why did you go with JBoss" can be answered quite simply: it just worked. At times, we can be quite the simpletons. When something works, we tend to just go with that. If you have any questions about what we did, please don't hesitate to email or IM me. NetBeans: Shaping up into a nice Ruby IDE
As I've mentioned before, we run several Ruby and Rails applications inside the DZone Network and lately, some of these have become quite large applications. With all these Rails applications we need a strong IDE to be able to develop in. Over the past few months, the quality of Ruby IDEs has steadily increased and I have heard better and better things about the NetBeans Ruby Module. This weekend, I decided to download it and give it a try for some of the Ruby projects we've got in our revision control. First of all, I think NetBeans has made great strides as a general purpose IDE and what they've been able to do with a dynamic language like Ruby is quite impressive. In addition, I think they've got some really neat stuff coming up in the next Milestone, M9, of NetBeans 6. All of this coincides with the breakneck speed that the JRuby team has been hurtelling towards a 1.0 release, and with a viable Java based Ruby solution as a backend, NetBeans should be able to really provide for Ruby what a good Java IDE gives to Java. All that being said, there were obviously still a few things to gum up the works. Quite a few times, I received a popup saying there were errors parsing the text. In addition, on OSX, even though I had pointed NetBeans at my subversion binaries, it still was unable to commit code to the repository. I really think the NetBeans team needs to devote some manpower to using one of the pure Java subversion libraries out there. I think it would certainly simplify the experience from a user's perspective. All in all though, NetBeans with Ruby was a nice experience and its good to see the benefits of Sun hiring the JRuby guys starting to come to fruition. See you at JavaOne
Well, it's that time again, time for another JavaOne. As usual, we're making plans last minute, but it looks like we'll be out there from at least Monday at noon (possibly Sunday) to Thursday evening. What things should we be on the lookout for this year as we do our daily wrapups from the show floor? Will we see more of the same that we saw last year, open source and Ajax, or will we see something totally cool, awesome, and new? Aside from catching each other on the show floor, if anyone would like to grab drinks, lunch, or dinner one night, please shoot me an e-mail. I'm always happy to meet with our members and hear about the cool things that you guys are working on.
Until Next Time,
Matt Schmidt
matt@dzone.com
|
Back to newsletter list
Make Java Applications More Valuable
Perspective
IntelliJ IDEA 7.0 M1: Touch the Future
Picks of the Week: