The following questions, I think would be good for a midterm:
1) What are the pros/cons of Code Review and Automated Code Assurance? Why do we need both?
2) What event would you need to override in order for your Robocode Robot to react appropriately to hitting a wall?
3) What is the main principle of The Principle of Least Astonishment (found in The Elements of Java Style)?
4) What feature was added to Java to make dealing with primitive data types easier?
5) What JUnit method would you use to test if an object is equal to its expected outcome?
Sounds pretty good if I could say myself.
Monday, October 24, 2011
Thursday, October 20, 2011
Version Management
The only thing that's constant is change. That holds for life and for programming, as well. As programs get more and more complex, the more they need to be maintained. Even if you debug your code and release a perfect product, it's likely that you will want to make a change sometime in the future, a new feature or an overlooked security issue, for instance. Version Control is akin to an assistant that keeps track of every change you make to your code to assure that each change you make to your code is logged and kept track of. Acting like save points in a videogame, version control makes it obvious what changed and allows you to revert your code to a previous version if needed.
As a requirement for one of my classes, we had to use Subversion along with Google Code to host our robocode project (the result can be found here.) Having experimented with Git while working with Heroku, Subversion came intuitively to me. Both have command-line and gui interfaces, though with linux the command-line is really the best way to go about your files. With Subversion, you can make changes to your local directory that subversion will note to change on your remote server. It's easy as 'svn commit' when it comes to updating your source. To upload your code to a remote server is easy, too, as 'svn import URL' allows you to import your base directory to the path, assuming that the path is configured for subversion management.
The only thing I miss from git is an easy-to-find ignore list like .gitignore, but for the purposes of uploading a robocode robot to google project, interfacing directly with the folder proved just fine (though it resulted in way more versions than I had planned.) Other than that, managing versions of your software is easy as import, edit, commit.
As a requirement for one of my classes, we had to use Subversion along with Google Code to host our robocode project (the result can be found here.) Having experimented with Git while working with Heroku, Subversion came intuitively to me. Both have command-line and gui interfaces, though with linux the command-line is really the best way to go about your files. With Subversion, you can make changes to your local directory that subversion will note to change on your remote server. It's easy as 'svn commit' when it comes to updating your source. To upload your code to a remote server is easy, too, as 'svn import URL' allows you to import your base directory to the path, assuming that the path is configured for subversion management.
The only thing I miss from git is an easy-to-find ignore list like .gitignore, but for the purposes of uploading a robocode robot to google project, interfacing directly with the folder proved just fine (though it resulted in way more versions than I had planned.) Other than that, managing versions of your software is easy as import, edit, commit.
Tuesday, October 11, 2011
Robocode: Lessthan20charsyeah
Due to time constraints I shall skip right to the nitty-gritty:
- Crazy (5/5)
- Fire (5/5)
- MyFirstJuniorRobot(3/5)
- MyFirstRobot(4/5)
- RamFire(4/5)
- SpinBot(4/5)
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.
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 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.
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:
I decided to omit the curly brackets from the code because of code I read in 211 (and from Java In A Nutshell). Learning Python in 215, I liked how compact it looked and so decide to make similar if statements. I also have a bad habit of not documenting my code, as seen here. Having not really produced code for anyone but myself and the TA grading it, I often try to make code the most compact without really explaining what I'm doing. While I could look back at code I wrote, I wouldn't be surprised if a third-party wouldn't be able to understand it. Even if this is a trivial program, a few lines shows one's proficiency and understanding in writing good code.
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:
I decided to omit the curly brackets from the code because of code I read in 211 (and from Java In A Nutshell). Learning Python in 215, I liked how compact it looked and so decide to make similar if statements. I also have a bad habit of not documenting my code, as seen here. Having not really produced code for anyone but myself and the TA grading it, I often try to make code the most compact without really explaining what I'm doing. While I could look back at code I wrote, I wouldn't be surprised if a third-party wouldn't be able to understand it. Even if this is a trivial program, a few lines shows one's proficiency and understanding in writing good code.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)