Old MATLAB Improvements, Java Data Objects Primer

Matlab m-file (Download and run) 

Matlab Source Code (to view online)

For the most part I haven't changed the workings of this code. I did change one error dialog that told you the height needed to be between 0 and 20,000 meters when inputting an incorrect value for the height increments. Just a copy-paste situation where I forgot to edit the message. The big changes here are comments. It's quite thoroughly commented now and should be a bit easier to follow. I also commented-out the "Standards Selection" box, which was unusable, and centered the title information to make it look more natural. Finally I cleaned up a function call that was passing the constants array despite the fact that the other function had full view of the same array. Basically, unnecessary transferring of variables. Theoretically should have sped up the code. Considering the ambiguity of some of this code and the amount of time that passed between writing it last and doing this editing, I'm quite pleased with my ability to understand what was performing which actions throughout.

After finishing that I decided not to start the new assignment yet. Instead I started reading my book on JDO. The more I read, the more excited I get about the system. It really seems quite easy to work with and I'm excited for the implementation of it all.

I'm not sure I've talked much about JDO and why it's important to my application and Java in general, so here goes. Java code is run in a Java Virtual Machine. This is what enables it to be so universal... once the JVM is started up, one computer "appears" to be exactly like any other. At least in terms of executing the code. Unfortunately, every action the code performs is done in this Virtual Machine, and this means that everything that's been done is deleted when the code finishes, as the code finishing results in the JVM being closed. Saving in Java is done by file output during the execution of the code, by Serialization, or by storing the values of a class's variables in a database.

The first, file output, is mostly for saving a text file or similar. It's simple and useful sometimes, but it's simple and therefore not useful other times. In the case of my simulation, it's impractical due to the methods of parsing a text file back in (it would take AGES) and due to the ease of editing that text file between sessions to hack the game. Besides that, saving the file on your computer makes it tough to have an exciting multiplayer experience.

The second, Serialization, is complex. Essentially it converts the state of an object into a stream of bits and bytes, then on loading deserializes it back into its object form. These bytestreams can be large, but more importantly it's a bit unwieldy to program a class to be Serializable and program the Serialization and Deserialization across a full application like the simulation. There's also, again, the problem of things being stored on a client computer and making multiplayer a bit lackluster.

The third is storing values in a database. To start with, we'll ignore JDO. Storing values in the database means building a database (using SQL, most likely), linking the Java code up with it through the JDBC API, and programming in all the possible commands for editing the database that the client will ever use. While it sounds daunting, it's certainly doable and it had my vote for a while. Every time the client-side application is run, the user would log into the database and it would load all of his/her details, initializing all the objects necessary and setting the values back to what they are in the database.

Then comes JDO. JDO is a standard that allows me, as a Java developer, to program everything in Java code. I don't need to build my database with SQL to start with, I don't need to include ridiculous amounts of SQL hidden among the Java I'm writing, I don't need to specially format my classes. All I do is write the class as normal, enhance it with an automated tool (which builds into the class all of the methods necessary to view and edit it, automatically), initiate my database with a similar automated tool, and tell my program to make an object persistent whenever I need it to. Loading that object isn't always done per se, more often you just access the values in the database. It's just that those values are set within the Java application and without any complicated translation are plopped into the database in a Java-accessible structure.

It's really the easiest of the bunch I've seen so far. I can't wait to actually use it.

But first... I have more MATLAB to code.

Java Hiatus

Alright, I'm officially putting my Java development on hold from this point until... well, when I change my mind (probably no more than a couple of weeks, possibly much shorter). The reasons for this are twofold:

1. While I enjoy Java more, I'm actually required to do my MATLAB assignments, so I need to get to work on them.
2. Before going on with serious development, I need to know what exactly is required for creating a Java Data Object database.

If I continue without researching JDO more thoroughly, I may well find myself stuck deep in the mud when suddenly it turns out I needed to implement specific classes for each of my classes, or I needed to ensure certain formats matched up or whatever.

I managed to find a book on JDO online in PDF form for free download. If you search Java Data Objects on Yahoo! Groups, the first result should be a site for the book, and if you become a member you can download it as a PDF. I haven't read it yet but it should be more useful than nothing by a long shot. That's what I'll be doing when I'm not thrilled with the idea of MATLAB and I need to progress on my Java developing.

Also, I've started scrolling through Yahoo! Answers, trying to provide help to people looking for Java//Generic Programming help. I refuse to outright code people's homework (or midterms, like one person asked) but hopefully the information I give is useful for those who want to learn what they're doing. It's also a little bit of publicity for the blog, by having it linked from my profile. We'll see if it gets anywhere, I'm not holding my breath.

Contract for the Material class

Today's post is mostly organization for me, setting down guidelines for the Material class I'm working on. Still, this could also serve as an informative post as I'm using strategies set out in some of my books.

A contract is essentially what the name implies: a list of terms and conditions. In these particular circumstances, it's a list of things that the class is expected to be able to do. In the professional world, a contract is often what a programmer will receive. How the person works out the inner dealings of the code is unimportant, so long as they accept inputs defined by the contract and return outputs defined by the contract.

So, without further ado, the Material contract:
The Material class must be able to:
-Create a new instance, with String inputs name and matcode.
   -Verify the formatting of the input (11 characters, a-z only).
   -Convert the characters of the matcode to integer values 0-25.
-Include classes to set individual attributes with int 0-25 input.
-[OPTIONAL] Include classes to set/get attributes by name.
-Include a class to get the current matcode of the material.
-Include all classes to produce a GUI to view and modify the material.
   -Construct input panel.
   -Construct edit panel.
   -Construct output panel (display graphic).
-Include a list of market prices for the past 12 weeks (or more).
   -Method to set current price (saving old price as above)
   -Method to archive prices when they're removed from above list.
   -Method to get current price
   -Method to display a graph of past prices
   -[OPTIONAL] Display graph including archive.


I'm pretty sure that's all, at least for now. I think it's safe to say that everything except the market prices has been coded, though it hasn't all been migrated to be within the Material class.

Remember I said that it's up to the programmer to decide how to then code the inner workings? That's how I think I've come up with another class. And then from the fact that I'm also developing the whole thing, I decided on another still. Internally, the Material class will also host the MatCode class. This class will make it easy for a Material method to alter a specific attribute by calling methods within that class. It will allow for error checking, editing materials by supplying integer OR character values, and overall serve to be a convenience class for making the Material class look cleaner. That said, it won't be needed outside of the Material class and serves as a good internal class.

As an external class, I need Price. Basically all it does is store a price and the date that price was set. It will be used for a number of different objects and needs to be outside of the Material class. Mostly, it makes the eventual database more useful when the price is its own object storing pertinent information.

With these done in a day or two, I'll be able to move on to the next class, probably Planet. But also expect some work done on both my old MATLAB project (ISA Calculator) mostly in the form of adding comments, and my new MATLAB project.

Mission Accomplished!

For the first time in my blogging career of nearly two weeks, I have something to show you that I've been promising in relation to my Simulation. That's right, I have finished my material decoder. Well, at least functionally, certainly it needs work to be implemented.

That, my reader(s), is my new MatCode Interpreter in action. Type in 11 characters, hit evaluate, and a new shape will be made for you. I admit, it has limited practical use as it doesn't supply exact values (it could, just doesn't), but it gives a good representation of approximate values. The color of the figure shows an interpretation of the material's "Workability Factor," a fancy name for cost modifier. The interpretation is that the darker/redder the color, the more expensive it is to work with. This random material apparently is very cheap to work with. The ten named values are (clockwise from right (3 o'clock)) integrity, conductivity, combustibility, heat resistance [index], transparency, elasticity, magnetism, nuclear value [index], decay resistance [index], and [intrinsic] value. Bear in mind that mid-range values are assumed to be average. In other words, the only places this material is above-average are magnetism, elasticity, heat resistance, and perhaps combustibility.

Above average isn't always better, though.

Anyway, this is my first actually vaguely complex Java program, and my first go with Java graphics aside from JFrames (basically, windows and buttons). I had made the text layout in photoshop, but I decided instead to render it using Java's graphics, in part to better acquaint myself with the system and in part because for a long time I was having trouble figuring out how to get the image into the program. I've since figured it out, but that was after setting Java up to do it.

So... what's my next step? I have no freaking clue. But I have plenty of other classes to work on. Some should be pretty easy, just the structural classes for my JDO database. Others are more involved, making frames and panels for managing different pieces. I have a lot of work to go, but I've made the first sizeable step.

SQL Concurrency versus JDO, and why I want to make the switch

Small update tonight. I managed to not do much tonight except think. And think. And plan. The outcome is a decision to "scrap" what I have so far on the simulation and start new. Including, (most likely) the database.

And here I was promising the material decoder, huh? Not that it took very long to get nearly finished with that. Another couple of days and I'll probably have that finished, I just need to go through some organization first.

So what am I changing in starting new? Let's go into one of my standard bullet lists:

• (Probably) Removing the SQL from my side of the coding by using Java Data Objects.
• Creating classes for the different objects (like planets and ships) rather than tables per se.
• Truly attempting to take advantage of the object-oriented nature of Java, a la Budd.
• Avoiding so-called "Concurrency" issues
• (Probably) Making the code easier on me to develop.

Java Data Objects, or JDO, are a method of storing entire Java Objects within a database. In my case, by creating a class for each in-game item, I can then store the classes in the database. This becomes useful in terms of the concurrency issues mentioned above. Concurrency in SQL is a problem where multiple users attempt to access the same data at the same time. When one person edits the data, the second person may well overwrite those changes even though the information they based it off of is no longer accurate. Generally this is handled by locking the row, so that only one person can access data at a time.

This is a major problem in my program because of the nature of the database I built, and how it would be accessed. The database is built with 'foreign keys,' or references to other tables, so that all of the data is interconnected. If one user is accessing all of the necessary data to run their empire, then a significant portion of the database is locked up while they're doing that work. Not a very user-friendly methodology. On the other hand, if the planets and ships and everything else are stored as independent objects, the user only accesses those that belong specifically to them and there aren't concerns about simultaneous edits.

I'm not too well-versed in the JDO things yet (I've just stumbled upon them today, really), so I'm not certain, but I do get the impression that using JDO means not needing to use SQL, and this simplifies my coding as well as removing the SQL altogether. Unfortunately, while I've found books that cover JDO, I can't find any at a library near me. I'm considering purchasing a copy somewhere off the web, but for now I'm going to try using the online documentation for it. Until I run into major issues, I'll probably stick with that.

My next couple of days are pretty slim in terms of time spent in-school, so hopefully I'll have a nice structure fleshed out and work started by... the weekend, at the latest? Wish me luck on that!