Tuesday, October 11, 2011

Robocode: Lessthan20charsyeah

Due to time constraints I shall skip right to the nitty-gritty:

Design

I wanted my robot to keep its distance while trying to track its opponent. Upon being hit with a bullet, it tries to avoid it by alternating movements. What resulted was something like a cross between Walls, Corners and MyFirstJuniorRobot. It scales the walls until its at a certain distance from the enemy, then it scans and tries to shoot at the enemy. If it gets hit by a robot, it turns inwards and travels far, and if it gets hit with a bullet, it tries to avoid it by zig-zagging or going further up the wall, depending on which stage its at.

Robots that Lessthan20charsyeah can regularly beat (in a test of 5 rounds)

- Corners (5/5)
- Crazy (5/5)
- Fire (5/5)
- MyFirstJuniorRobot(3/5)
- MyFirstRobot(4/5)
- RamFire(4/5)
- SpinBot(4/5)

Testing:

- Acceptance Testing:
My goal for the robot was to keep away from close robots and to dodge bullets. As such, I picked two robots to do acceptance testing on, Corners, since it picks a corner tracks a robot, and RamFire, since it tries to track and get as close as possible to the robot as possible. Lessthan20charsyeah has an acceptance rate of greater than 80% (more often than not it is 90%) which, in the my view, is sufficient enough for a competitive robot.

Behavior Testing

Due to time constraints I was able only to test the robot's ability to keep ones distance. I calculated the distance between the robot and RamFire for a typical battle. I tested to see if my robot was able to keep a distance of more than 200 for more than 70% of the time and it came out to be successful. Such, it does an acceptable job of keeping its distance.

What I learned:

I learned the importance of testing and documenting. More specifically, that no matter how imperfect a product is, it pays off to test often and test early. Testing takes up a lot of time and such one shouldn't try to fine tune a product and leave no time for testing. The documentation would be incomplete, giving the client less than perfect confidence in the correctness of the product.

Thursday, September 29, 2011

Ant: A common build system for Java deployment.

"You say: toe-MAY-toe..."


There often comes a time that language barriers are a difficulty in real life. Helping travelers find their way to the nearest mall is one example. With the ever increasingly fragmented state of computing, language barriers can cause problems, too. There are three main OSs that have their strange idiosyncrasies, Linux, Mac OS X and Microsoft Windows. Within these systems are differences in file structure, new-line symbols and a plethora of other things which make deployment a hassle. With build systems, it allows for a programmer to reach the most amount of people, automating the process to make code deployment a breeze.



Introducing Ant

Like its GNU couterpart, make, Ant provides a framework for interacting with the system to build a provided system. What Ant does is act like a translator between the system you provide to the user and the user's computer. This means that no matter what OS they're using, Ant would be able to configure your system to work with theirs. Using XML, all one needs to do is provide simple targets that Ant has to execute. Using Java, ant could do anything from compiling:




To archiving a system:




All through xml. All the user has to do is invoke ant on the xml file and they're done. Through automating the process, the user of the code doesn't have to go through the headache of trying to figure out what one needs to download/configure in order to use a great piece of code, and the group that provided the code can rest assured that their code will be the best to use.

Tuesday, September 20, 2011

Robocode: Productive Entertainment

Human beings are great with tools, it's a proven fact. Otherwise we wouldn't have built great empires and technologies during our short time here on Earth. With the advancements of technologies, very many people weren't delegated to long arduous hours of physical labor. Thus came about how we proved ourselves to be good at using tools not only to achieve tasks, but to use them in ways completely unintended for our personal entertainment. Take, for example, sword swallowing. Swords/knives are great for everything from chopping down brush, carving up pigs and stabbing your enemies, but just how much downtime do you need to be that bored to think, "hmm, I bet could swallow that razor-sharp sword no problem"? Bets, dares and challenges gave way to all that's popular, now. We use things like racquets and bats to hit things not to build something, but to see how hard we can hit it. We use gloves not handle things with care but to catch things to beat the other team.

Fast forward to the modern-era and we have not only physical tools but digital tools. Our entire economy is now (for better or for worse) fortified with the backbone of the Internet. The world is ever-shrinking and computers are assisting in computations in everything from business to protein folding. In those terms, we also have games that incorporate productivity skills into entertainment. In terms of contests, battles between algorithms are one of the most popular. Algorithms can mean that a company pulls in more money in the real world or finds a solution the first, but in terms of entertainment it would make for more explosions that result in points. Here is where we introduce Robocode, a game programmed in Java in which we program simulated robots to do our bidding, namely kill the other robots in the field.

Robocode: Robots in Plain View


Robocode was first produced by IBM, but support for the game was later dropped. The code, however, was made open-source and is maintained by hobbyists that I would guess, like the sword-swallowers, have a lot of downtime on their hands. When that downtime and effort results in a game as entertaining as Robocode, however, I don't see a problem with that. Robocode is an extremely easy way of building simulated battle robots that you can then put into a ring together for a battle to the death. All you need to do is download the site freely available from sourceforge run the jar install file and use the provided programs to compile and run your robots. The Robot class provided gives you all the functionality you need to make a competitive robots, namely their three basic functions: moving around the battlefield, scanning for other robots and firing their guns.

Professor Philip Johnson proposes that in order for one to become proficient at the sport of Robocode, as one often does in any other sport, one should submit oneself to learn and practice the basic functions of Robocode in order to increase your proficiency at both programming and the understanding of the game. His form of programming katas incorporated learning how to move to certain parts of the field and how to target/follow certain enemies. I found that learning to do these gave me ideas that I wouldn't have had if I started to kill robots on my own.

For instance, the idea of keeping distance from a robot in one Kata proved difficult since I kept running into walls as I backed up, essentially causing my robot to be trapped by the enemy robot ready to be blown up. My idea for keeping distance, however, by reversing perpendicularly off the wall looked like an effective way to keep distance, even if for a brief time you're going towards the enemy robot, you'll probably be better off in the long run and your gun is still faced at him.

Another challenge I had was figuring out, by myself, how to calculate angles for my robot to travel, not just in x then y, but in diagonals. What I believed would make me a better programmer, and one of the basic functions of robot katas, is to challenge myself and solve the problem myself, without open-source samples. This shows in my code since I have no doubt it's anything but optimal. However, I successfully learned to travel directly to the center using Javas atan function with the difference in coordinates between the robot and the point I wanted to go to. This having come after much trial-and-error, I believe I have a better understanding of the coordinate system than if I simply copied another person's code.

The downside to figuring things out for yourself, however, is the time that it takes for you to figure out the problem. It took me awhile for me to learn how to travel with a wall, use the radar system and using the several events to my advantage, so much so that I didn't have time to formulate a working plan to track a moving target (I believe I have fully finished the rest). The good thing about programming katas, however, is that if you repeatedly practice you will eventually have enough experience to solve problems in a quick and effecient way. And in that I intend to learn from this assignment and tackle things with minimal assistance, since it would make me a better programmer to understand things conceptually instead of just on the surface.

Tuesday, August 30, 2011

FizzBuzz, A Return To Java

The last time I've really coded in Java without learning a concurrent language was ICS 111. Since then I've renounced Java, as alternate dynamic languages I've learned in such classes as 215 and 313 was a lot more appealing to me. Diving back into Java on the first day of 314 was a challenge (though, it was akin to riding a bike, you never really forget it).

Asking to go back to Eclipse was another blast from the past after switching over to Emacs in the past year. The first problem being that in Emacs I use viper-mode, a plugin that emulates the keybindings for vi. To get writing the code, I had to dig into the settings to switch to emacs keybindings, which was a little more familiar to me. Factoring this into the equation I produced the following code in about 10 minutes:

Sunday, August 28, 2011

JFreeChart vs. JChart2D, a tale of two philosophies in Open Source Software

One of the greatest things about software development in the modern world is the amount of free, open-source software made available for anyone with the know-how and determination to use them.  With the popularization of cloud storage, easy version control systems like svn, cvs and git, and sites like sourceforge and github, one can easily host projects that are easily accessible and maintained.  With the popularization in open software comes a over-saturation in options to choose from.  It's with guidelines like that proposed by Philip Johnson's Three Prime Directives, that one can judge a project usable and truly open.

Here I will use the simple JChart2D in comparison with a much more complex JFreeChart to demonstrate the best ways to successfully produce a truly effective open-source program.


Could this ...


... be better than this?

Prime Directive 1: The system successfully accomplishes a useful task. 


The reason I chose graphing programs was my experience with trying to find a suitable graphing program for my needs in ICS 311. Along with deploying an applet, we were required to graph the ratio of Maximum Flow graphs. We had an option to use Third-party software but due to time constraints I was unable to find one that would suit my means. Both JFreeChart and JChart2D would have suited me fine in plotting out the data calculated, and so would've allowed me to pass the class.

Prime Directive 2: An external user can successfully install and use the system.

Here is where the philosophies of both softwares diverge. From a perspective of a cash-strapped college student, one can only successfully use a system if it's either intuitive to use or there exists free documentation provided to quickly help me achieve my goal. JFreeChart, despite the name, provides insufficient documentation through sourceforge and instead charges $65.00 per client. The system being so popular (4,747 downloads on the week of August 21st), I thought I would be able to use a powerful system that would help my code be presentable and sophisticated. I, however, was left dredging through undocumented source files and demos whose source code I could only purchase.

JChart2D, though being a less polished and unpopular charting system, has an intuitive, understandable usage page explaining the infrastructure involved and providing code samples for plotting and drawing a simple graph. The time it took from downloading the provided jars to building my own graphs was significantly less than it would take for me to understand and use JFreeChart without the documentation. While JFreeChart provides source code and allows for free usage, provided that you can decipher its infrastructure, JChart2D embodies the spirit of truly free open-source software in that it doesn't require its users to pay for its service.

Prime Directive 3: An external developer can successfully understand and enhance the system


Both system's source code is readily available through Sourceforge, JFreeChart provided directly from Sourceforge's Download page, and JFreeChart through CVS. Both systems are well-documented, using the Javadoc system to provide descriptions and guidelines for paramaters and return values for each method. The problem with JFreeChart, however, is that its system is never really clearly described (at least, without purchasing the Developer Guide) such that one can't figure out what to change. JFreeChart's source is fragmented, with one section regarding its charting functions and one section regarding its data management, with no clear explanations of its infrastructure (the provided documentation at the root of the data source, for example, reads "The base package for classes that represent various types of data.", with no instructions how to create a dataset for use with a JFreeChart object.


JChart2D on the other hand, has an advantage of having available documentation. One can easily understand the main components of JChart2D because of the simple pictoral representation of its architecture. Granted, its architecture isn't nearly as complex as JFreeChart, due to less functionality, but complexity could be easily solved by good documentation, something that is not available from JFreeChart by default.

In summary, JChart2D, through a comparison with a more popular, yet less intuitive JFreeChart, embodies the benefits of truly free open-source software. It is easily deployable through Sourceforge, provides straightforward explanations of its usage and architecture and invites people to both use it and modify it for free.

Friday, August 26, 2011

...Aaand we're back.

To say that this week has been rough on the state of my computer would be an understatement.  To start off this semester I've made one giant mistake that is often disastrous in both Computer Science and life itself in that I made a last-minute change.

A week before, I had upgraded my laptop's hard drive to a Solid State Disk Hybrid Drive, the Seagate Momentus XT, which combines a small partition of flash memory and a 7200 rpm hard disk.  To my dismay, I found that my existing Windows 7 installation on my computer would not work with the new hardware, even if I cloned it and restored it with Clonezilla.  With not having a optical disk drive (the trade-off with portability) I had a hard time creating a bootable usb drive with the recovery disk I received with the laptop, only to find out that I needed an install cd with the disk.  This is where I gave up recovering my old configurations and started looking for alternatives.

Having found an official Windows 7 SP1 iso online that I could boot with help of Plop Boot Manager, I made a fresh install on the new hard drive only to find out that the Product Key that came with my laptop (and, after a year being spent on the underside of my laptop, was nearly illegible) did not work with an SP1 install.  One would wonder how good a Product Key is if it doesn't work with the updates that it's good for.  Instead of putting myself through more trouble I decided that since there is software available for installing and making a bootable install on a flash drive via UNetbootin, I'd try for a linux partition in replace of my Windows 7 Install.  Instead of the traditional Ubuntu install, I thought I'd stray from what I was familiar with and install Mint Linux LXDE, a distro based on linux that employs both the lightweight manager LXDE and proprietary software like Java and flash by default.  While I did like the window manager, I was unfamiliar with the distro's navigation.  I could not bring up the file system other than from the menu bar, among other things.  The system did not work well with my NVIDIA ION GPU, as well, always resulting in weird artifacts when, say, I'd launch the terminal.  The system crashed a fair amount of times, often when taxing the GPU by watching videos, so I decided to install another linux distro I'd heard was good: Debian.

As opposed to Ubuntu, which is sponsored by Canonical, Debian is tied directly to the GNU open-source project and doesn't have a centeral supporter, and instead is developed solely through volunteers.  This makes it a great incentive for people to support truly free and pure software.  Unfortunately, Debian did not play well with my experience with Linux and with installing a system.  Whereas Ubuntu has live CD's with an easy install system, Debian employed the old system of a series of menus with options about the installation.  Looking to keep a partition to install Windows 7 later on, I tried my hand at manually configuring the partition (1 Ext3 partition for Debian, 1 Swap partition and 1 NTFS partition for Windows 7).  When the installation finished, the morning of the day Assignment 01 for ICS 314 was due, I found that the LILO bootloader did not boot into the Debian install but was dropped down to a busybox shell provided by LILO.  No amount of Googling and tinkering made the install bootable and so I missed Assignment 01.  As soon as I got home, however, I decided to return to the tried and true Ubuntu install.

As of this blog, I am now running Xubuntu 11.04, an Ubuntu distro that uses the XFCE window manager as opposed to Unity, Ubuntu's new window manager which has received mixed reviews.  It is an upgrade from 10.04, which I had installed alongside my Win7 install on my previous hard drive.  It seems to be just as good as I remembered it, if not better with significant improvements.

I've learned a lot about the perils of last-minute changes enough from my work as an A/V Operator at the East-West Center.  I should have given more time for me to get up to speed with my hardware and software but I was unable to get my configuration on par with my desires in time for Assignment 01.  Instead that leaves me with a wake-up call and an incentive to work extra hard in the future to catch up.