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. ;)

I've been trying to think of some good examples of jSeamless that wouldn't take too much time to write, but would show the power of jSeamless and some of its capabilities. To that end I've started developing a multiplayer Sudoku game. The puzzle is generated and displayed to all connected players. As each person provides a correct number they get points and that field is "solved" on all other player's board as well. If you get a number wrong you lose points. A winner is decided by how whoever had the most correct numbers in that puzzle. I'm creating a whole account management system, scoring system, database logging and statistics, and internal chat. This should be a pretty fun game when it's finished.

Here's an early screenshot:

I have to present a prototype in a couple hours that is really important to my job and the company I work for. I think I'm pretty well prepared, but have been trying to go through any last minute details and bug fixes to make sure nothing breaks horribly well I'm demonstrating it.

It's at a time like this that my brain decides to recall a poem I wrote in the third grade. Now, I'm not really sure how I got there, but now that I have I decided I'd write it down because I still like it. :)

Tomorrow is Today, if Yesterday had never been,
Today is a day that will never come again,
Now is the the time that always will be,
Time is the variable, only the mind can see.

Not bad for a third grader, huh? ;) Well, back on track I'm really excited about this demo as it is the largest application I've developed yet utilizing jSeamless and this demonstration is about getting more buy-in for the product, the framework I've written, and jSeamless from the company I work for. Next week I'll be able to start adding massive new features to jSeamless (I couldn't until this demo was completed for fear I'd screw something up).

Anyway, this will hopefully be a short day for me so I think I'm going to go home and spend the rest of the day with my wife...I love Friday. :)

Adobe Flex 2.01 is a very good framework and it is so much better than practically any other web-based UI framework in existence today, but there are so many bugs in the code and so many restrictions that are very difficult to get around I'm locked into a love and hate relationship with it.

I'm using Flex for the reference implementation of jSeamless and it is going quite well over-all, but I'm finding myself re-writing component after component because of either bugs or lack of features. The good thing about this though is that the entire Flex source code is available within the SDK, so I can see exactly what they are doing and how they are restricting me or causing bugs to occur.

My single biggest complaint about Flex is their complete lack of threading "support". That is not to say it is single-threaded. Quite the contrary. Everything is asynchronous in Flex, but thread-safety is an unknown term to the Flex team I believe. There is no way to synchronize, lock, or maintain good concurrency in the system and many a crash has been due to this. In jSeamless I have a full system I wrote to offer some concept of synchronization and though extremely limited because of ActionScript 3 support not being there, it works pretty well.

I'm about to completely re-write the way Effects are called in the Flex implementation of jSeamless because it is causing errors to occur and also offers no way of disabling effects. I'm a Java developer and writing in ActionScript 3 is really not my idea of a good time, so every line of code increases my frustration.

On the bright side, jSeamless has far exceeded the capabilities of what Flex can do because of its "flexibility" and for that I'm extremely thankful.

I know that seems like a strange question to ask, but it's one I often ask myself. In many ways I've been extremely successful throughout my life, and it occurs to me that many of those successes were good successes, and many of them were bad successes. Most of the time it's easy to tell the difference. Sometimes, however, it's very difficult to discern.

I've been feeling this way recently regarding jSeamless. I believe it's one of the greatest development endeavors of my life thus far and have no intention of abandoning it, but it is now beginning to develop a following of users, which is great, but the majority of these users simply use the API and then post when something is missing or broken. Don't get me wrong, I have no problem with this, but I'm getting extremely bogged down with providing functionality for these users instead of them helping and committing to the project themselves. I believe in the long-run it will get better and eventually I'll have some strong developers that are willing to help. For now though, it's draining to spend all day at work writing code to support them, and then coming home and writing code to support the jSeamless community.

I guess a project has to catch on at its own pace, I just wish there were more people interested in helping. jSeamless is becoming a large project and I'm just one person. I often brag about how much this one person can do, but I realize as well as anyone that my limitations are definitely there.