More screenshots

Here are a couple of screenshots of the progress so far. The top one shows a landscape mode screenshot from Chrome, the bottom a portrait mode screenshot from Android. To avoid accidental actions, I'm putting the game actions (resign, draw, confirm, cancel) into a dropdown so that you have to select the option then hit OK to perform it. Other actions will also be in this dropdown (like player stats) to conserve screen space.

Chrome Screenshot:

Android Screenshot

Notice in this screenshot that the board isn't quite the whole width of the screen. I'm not sure what is causing this yet, and it only seem to happen at random on the first page load - if I hit refresh then it fixes itself and takes the whole screen width. Must be a timing issue somewhere, but the load is all done in the jQuery ready method, so I'm not sure what it is exactly related to. I thought it might be related to the fact that the images may not be fully loaded when I go through the computations, but I would hope that the browser would show the images at the size I assign at runtime even if they were not fully loaded. I might try not generating the board until after the images have loaded to see if that makes a difference.

Android screenshot

Here is a quick screenshot of the play screen so far, as seen on an Android device:

GZip compression broken on Safari, Android?

I just tried testing the board page layout on devices other than Chrome on my Macbook, and had some surprising results. I use Tomcat for my app server for my java war file, and in my war file I have configured a GZip stream compressor I wrote years ago. Unknown to a lot of web users, browsers tell the servers if they support GZip compression for content, then the server can send the data back compressed for faster downloads. I just enabled this compression on the server side for .js and .css files, since the jQuery 7 .js file is over 100k. On Chrome this works fine, but on Safari on my Macbook and on the default browser on my Android phone the whole page broke. The reason seemed to be that those browsers were telling my server they supported GZip compression for those resources, but wasn't decompressing the data I sent down! I turned on the compression on my server for .js and .css files and, sure enough, the page started working again. Very weird, I'll have to report that to Google and Apple.

Server side data storage and access

One of the biggest issues Chess Buddies has is performances - far too often the app just gives up waiting on the server to respond to a request. As a user, this is frustrating to say the least. So if Chess Juice is going to be a better mousetrap, it has to perform really well. Toward that end, I'll be using a split data storage approach on the server. For games in progress, where performance is a premium, all storage will be done using Lucene instead of a traditional sql-based server like MySQL. Lucene is very fast for look-ups, which is critical for checking on new moves for example.

For archival storage, I'll use MySQL for all completed games, keyed by game number and indexed on player name. This should allow for reasonably fast look-ups even after the archive gets larger. A simple User table will hold the game number keys for all games that user has played.

So that's what I'm working on right now on the server side. Should have the core done by the end of this weekend, that's my goal anyway.

Status update - making a chess move

I was sort of dreading implementing the move validation because it's a bit tedious. But then I had an idea - since the javascript I'm using to validate a PGN file already validates individual moves, I should be able to just hook into that somehow. I need to mention that my PGN validator, jChess 1.0, was written by Ben Marini - thank you, Ben, wherever you are, you saved me so much work! I didn't have to reorganize much in Ben's code, and I now have a new move validator. All my code had to do was generate a new move in algebraic notation format, pass it in to the jChess PGN move validator, and catch any exception. Ben's code doesn't actually trap bad moves, it just chokes on them - so I just catch the resulting exception to know that the move is no good. Could hardly have been easier - whew!

Next up - server coding!

Chess pieces

The first thing I like to do when I start an app, particularly a game like Chess Juice,  is to create my core graphics. For Chess Juice, this mean the chess pieces. I am a horrible artist, and I cannot possibly stress horrible enough. So creating pieces from scratch was right out.

Next I searched for chess fonts, thinking I could use HTML5's web font facility to load the font to the page and then just use the font for the pieces since I could have the browser scale them to any size I wanted. Yeah, I actually thought using fonts for this was going to work. Now to realize why that was such a horrible idea if you didn't lol right away, you have to know that fonts make their little images by just specifying which dot is foreground color and which isn't. And by isn't I mean background color. But of course I need to put a white chess piece (which in a font is just a black outline and not filled in) on top of a chess board, so the color of the square just shows through. Ahem.

But I really, really liked the chess font I found, Chess Alpha 2. So I decided on an arbitrary maximum board size - 800x800 seemed like a good size - which makes the square size 100x100. I created the pieces at a size of just under 100x100 in Gimp, then filled in all the transparent areas with white. At runtime I then compute a real size for the piece based on the device the page is running within, and let the browser do all the scaling for me. Like magic, I get pretty nice looking pieces with very little work:

Development Environment

I'm a long-time Eclipse user for my java/web development. But if you look closely at the screenshots I've posted, you'll see I'm using Netbeans for developing Chess Juice. Now I'm not trying to start an IDE holy war here, but what made me use Netbeans for this project? Basically it's Netbean's context-sensitive support for CSS3, HTML5, and javascript - from my experience, it just blows Eclipse away in these areas. I prefer a lot of Eclipse's other features over Netbeans, however, and I use Eclipse at my real job so I won't be completely switching to Netbeans anytime soon. Still, Chess Juice is a lot of HTML5, CSS3, and javascript development, so right now for this project I'm really enjoying Netbeans a lot.

Status Update

I did all my initial development a couple of weeks ago, then got heavily involved in a project at my real job that prevented me from touching Chess Juice since. So far I have the basic board rendering at any resolution up to 800x800, which should be plenty big for computers and tablets. I've got the PGN engine done that can parse and replay a PGN game on the board as well. The server side will be storing all the games as just vanilla PGN files with ancillary data (like timestamp of last move) in a database. Next up for the board code is to allow making/validating the next move.

I'm still working out how I want the communication with the server to work. I'll likely just send up the PGN text - that's the easy part. How to send a move back to the server is the part I'm wrestling with. Sending the move in straight PGN/algebraic notation is obvious enough, but should I protect this with some sort of encrypted data to keep anyone from trying to hack a game? Seems like a reasonable thing to do.

Here is a screenshot of the board pre-loaded with a sample PGN file (don't pay much attention to the look of this page yet, just the board):

HTML5 + CSS3 + jQuery = Yummy Developer Goodness

I've been doing web development for way longer than I care to admit, and in the olden days HTML was quite the mess. It seemed like more things worked differently on the browsers of that era than worked the same, and I absolutely loathed that crap. If it weren't for the overwhelming allure of getting stuff out there on the web, I wouldn't have stuck with it this long. :)

HTML5 has been a long time coming, that's for sure. Now things are so much more standardized, and work mostly the same on FireFox/Chrome/Safari, although you have to ignore Internet Explorer - and believe me, that is something I try to do every day. HTML5 and CSS3 have all kinds of goodies that I'll be using on Chess Juice, cool stuff like Web Workers (threads in Javascript at last!), better page layout abilities (Flex Box!), and of course enough css/javascript effects to choke an elephant.

One feature I won't be using is Canvas. It's really tempting, but just seems like overkill for this app. It is so easy to use jQuery to manipulate the DOM in a very efficient manner that I just can't see the benefit in investing my time to learn the Canvas API on top of everything else I have to do for Chess Juice.

If you're a developer and you're on the fence on HTML5, jump over that fence and romp though the lush fields of HTML5 today! It is clearly the future of the web, so don't get left behind.

ChessJuice.com started!

Welcome to the ChessJuice.com developer blog! You can follow my progress here to know exactly when the app is available, and if you're a fellow developer I'll also be posting any tips and tricks I learn along the way.

First, what is this app? Check http://www.ChessJuice.com for details, but basically it's an HTML5 webapp for playing chess online, but not "live". It's like the old-school correspondance chess - you make a move when it is convenient for you, and your opponent will do the same. Moves do have timeouts, with the default being 2 days.

With that out of the way, why on Earth am I doing this? I started as a user of the Android app Chess Buddies, and you can find me there as twinfeats. Man, does that app have a lot of bugs, and the server side has a lot of performance issues. So there's your answer - I want to build a better mousetrap. :)