No, in a good way. :)

We've been working through a lot of stress testing at work for jSeamless to prove that it can stand up to an unreasonable load only exceeded by getting "slashdotted. We have faired quite well and we're currently working to get the document released for public "consumption". This will be a really great proof of the stability of jSeamless and put to rest a lot of the fears people have of its viability in a heavy traffic scenario.

I generally post a message in my blog after I've already done it, but this time I'm trying something a bit different and posting the idea as a mechanism to draw it out.

In my jCommon project I have Object Pooling support already, but it's explicitly limited to the pooling itself. While developing Galaxies Beyond I'm finding there are some things that would be useful to support in the pooling that would simplify usability in application. Currently you simply get() for an object from the pool and it will create the object if it doesn't exist and hasn't reached the maximum number of objects allowed for that pool or return an object that is in the pool. This works fine in most scenarios, but for more advanced pooling I need to cleanup after an item has been returned to the pool and perhaps re-init certain things when they are actually pulled from the pool.

...okay, after I got done typing all that it dawned on me that I might have already written this before. Sure enough, ObjectPool in jCommon already has support for all of this. Perhaps this should be changed to "How sad is it when you write so much code you end up re-inventing the same ideas over and over again?", but what's particularly sad is I've done this on various occasions. In fact, I wrote similar functionality for ObjectPooling in jME before I remembered that I had already created the object pooling support in jCommon. What makes it even worse is that the code I wrote was better the first time.

I'm 28 years old and if my memory is this bad now, I can't imagine what I'll be like at 80. In my defense I will state that I write thousands of lines of code a week, so there is a LOT that can be forgotten. :)

Yeah, I've done it again. I'm well known for reinventing the wheel and this is no exception.

As I've previously mentioned I decided to write a Multiplayer Sudoku game that you can compete with other players online playing. Well, I sort of got stuck for a while on the puzzle generation. I hate the idea of hard-coding puzzles and pulling from a list when it is something that could be generated. Yes, I did look around for other APIs to generate puzzles, but they either weren't in Java, were very poorly written, or were tied to a UI (like AWT or Swing). Sure, I could have made one of them work, but I decided that if I teamed up with my Wife I could create an awesome API that I could make open-source and then anyone else venturing for such a solution in the future wouldn't have the hardships I had to deal with.

On that note, I've gotten the actual solution generator written. It works quite well generating a solution in about 200 milliseconds on average. I still have to write the puzzle generator that takes into account difficulty, verification that a solution can be determined logically, and that there is only one solution. However, the majority of code I've already written can be reused for most of it.

I'll be posting a link to the project when it's completed so anyone who wants can use it. It won't be too long after that's done that I'll have it plugged in and usable in my jSeamless Sudoku game.

It's a little odd that I'm creating a Sudoku game at all really...I've never really enjoyed playing them all that much, but I do appreciate the logic of the game. My wife is much more interested in it than I am, so I'll just say I'm doing it for her. ;)