Right Tool for the Job

I am dealing with this game system that cannot handle too many views to the ranking system. Sheesh. What is a developer to do? Scrape the screens, reengineer the data, and put up some new pages. That's what. I already grabbed the HTML output from a bunch of ranking screens. Now I need to parse through the heavy HTML and extract the raw data. Java is my tool of choice for this task.

I got a bunch of files. And I have studied them to learn the pattern of how the web pages are laid out. Now I need to go through the HTML, line by line, and grab the raw data. Luckily each page seems to fit a pretty well defined pattern. I just need to teach my Java code to read for the data like my own eyes can now.

Heck. Maybe I will even write the new implementation using Java. The original product was written in PHP. I suspect they have a MySQL backend database. For my first try, I plan to grab the data and stick it in an Oracle database. However it could just as easily work with a MySQL database.

The only question is that once I have an optimized replacement system, what language will I use to serve up the data? PHP? Java? Or maybe something else. For now Java seems best. I actually don't know PHP. So that is a main consideration.

Calendar Ease

I have been writing some toy programs to relearn my Java skills. This time around I decided to write a calendar app. Nothing fancy mind you. I just put out a text calendar to the console.

Initially I had visions of computing all kinds of dates. I thought I could start with a known day falling on a certain day of the week. Then I could compute all relative dates with some formulas. Sure I would have to deal with leap years and such. But that would be a great project.

I found that the Calendar class in java.util was almost all I needed. No need to compute the day of the week the first day of the month falls on. I just set up a Calendar object with that date. Then I interrogate it to figure out which day of the week it is. Same thing with determining the number of days in a month.

This exercise was quite useful. I got some practice. I also learned some details of a new class. Calendar feels like a nice API. You just have to learn some of its constants. Then you can get() or set() to your heart's content. I banged out my calendar app in about 50 lines of code. Given that I am a bit wordy with my code, that is not too shabby.

Case of the Blank Screen

I decided to continue my Java graphics programming with a simple program to draw a sprial. This should have been a cake walk. I kept in mind that the Math functions took angles in radians. My mind thinks of angles in degrees. The Math package can convert between the two units. For some reason, my graphics were not showing up on the screen. This was frustrating. A good developer know how to debug these things.

I output my coordinates to the console. Everything looked fine. Coordinates were getting further and further away from the center. Looked like the drawLine funciton was just not producing any output. I did all my drawing in a loop contained in the paintComponent function. I tried sticking some hard coded coordinates in my drawLine call. No change.

Then I moved over to the Graphics2D world. The draw function there did not work either. I did eventually make a breakthrough. Calls to drawLine outside my loop worked. WTF? Loops should not matter. And the output was good. I saw it on the console. Finally it hit me. I was initializing all my variables in the JPanel constructor. The loop stopped drawing when the lines went off the screen. My problem was that paintComponent was getting called more than once.

The first call to paintComponent worked fine. It also output the correct coordinates to the screen. However the subsequent call(s) to the function erased the screen. By then the variables had incremented past the point where they could be viewed on the screen. I guess I need to learn how to run the code in real time in a debugger. This is a little tricky with graphics programming, as I would need to see the graphics being drawn in real time as well. Sounds like a need for some type of graphics debugger.

Getting Rusty

I spent the last semester learning the basics of JavaScript. I promised myself that afterwards I would come back to the Java programming language. And here I am. I find that I have become a bit rusty in my Java programming. It has only been half a year since I knocked out some impressive Java programs. This was disappointing.

I broke out an old notebook that contained ideas for programs I wanted to write. Figured it would provide some inspiration for some practice Java programs. I started with an Address Rolodex program. It was nothing special. I had to relearn some of the GUI programming tricks I picked up last semester. Luckily I had to look up a few specifics. I recalled some of the tricks after a while. For example, I knew it was easiest to implement the ActionListener interface with my JFrame object. That way I coud just addActionListener(this) to set up my events. Much simpler than separate or inner clases.

The mechanics of storing my addresses were simply an ArrayList. Had to make a couple design decisions, like figuring out where the latest address you added goes in the list (I chose the front). I started getting a prototype down with a FlowLayout that looked terrible. All the controls were all over the place depending on the size of the window. At the end, I decided to use a BorderLayout. It does not look awesome. But at least the rows and columns line up nicely. That's because each part of the BorderLayout is a JPanel containing a GridLayout that does the dirty work.

Now I need to choose project number two. I figure I have all summer to relearn the Java skills I have deep down inside somewhere. I was even contemplating picking up a community college class to use to drive my Java coding. A friend mentioned such a class she is taking next semester. I checked the schedule of classes and found it only meet during the day. Us nine-to-five types cannot register for classes like that which interfere with the work day.

Object Oriented Programming

When I was setting up my game engine, and even when developing my game, I took the time to create a nice class hierarchy. It took a little extra time. I did not go overboard. There may have been 15 classes tops. And some of those were small subclasses.

During a final round of testing, I found some of the text was coming out wrong. That was disturbing as the text worked fine in some scenarios. I traced it back to find some code doing extra work to get the job done right. To fix the global problem, I moved that code to a base class. Then everyone got the fix. I did have to tweak a few instances where the specific code made some wrong assumptions. But I essentially fixed the problem in one location. Bonus.

As an aside, I find the Java Collections Framework very helpful in developing games. Now I cannot imagine how I lived without them. Oh yeah. I used arrays. Painful. Luckily there is no more of that pain in my projects.

JDialog to the Rescue

I had a requirement to display a list of choices in a window. Furthermore I wanted the dialog to be dismissed as soon as the user pressed a key. Turns out the JDialog was the class I needed. Mapped the keys of interest to a listener and I was good to go. But then I needed to handle the display of the dialog.

I must confess that I really did not have that much experience with JDialogs. Found out that it defaults to a BorderLayout. For my application, I needed more of a GridLayout. I surveyed a bunch of code on the web while searching for my solution. Learned that I could call the pack() method to size the dialog with the minimal amount of space required to fit the contents.

I had one hiccup where I wanted to map the keys with the JRootPane. Thought I needed to do that when I created the JRootPane in createRootPane(). Unfortunately that method gets called from the superclass. I could not pass it any data. That's okay. I found I could later call getRootPane() and handle my business.

All About the Keys

I wanted to provide an easy to use interface in my latest program. At times I put up a dialog where the user must choose a value. I want the user to be able to just press one key to make the choice. Initially I tried using the JOptionPane. But it required the user to press enter after making the choice.

I thought I needed to somehow specify an option (no pun intended) for the JOptionPane to just require a keypress. After a while, it felt like I was hacking to much to get this to work. I seemed to need to set some weird user interface options, then set up some maps, and I was still struggling to figure out which key got pressed.

Then I researched some mneumonics. Turns out those require you to press the Alt key along with the choice you make. No good. Finally I figured I needed some custom code. I forgot about the canned JOptionPane and started concentrating on a straight JDialog. Got an assist from the Java2s web site. A map plus a listener was all I needed. Now I am going back to the basics of drawing some user choices on the dialog. That should be a snap. I wish I knew to go straight to the JDialog in the first place. I been spending most of the day on this issue.