Ever run into those situations when you've been put into a group and everyone's working on different parts of the same project, and then you run into problems trying to combine it all? For example, a component that one person took hours to edit being replaced with an unedited version from another group member, or certain parts of a project just magically 'disappearing', sound familiar? Well, for all those unfortunate souls that go through these lapses in communication, the all-powerful Google has a solution to your problems.
Google Project Hosting, which can be found here, is an online space where you and other collaborators can access and make changes to the group's project. A handful of useful tools for collaboration are provided, including an 'Updates' page that automatically shows when and where an update has taken place, a list of all members involved in the project, a wiki where instructions for files and other valuable information may be added, an 'Issues' page for posting problems regarding the project, and many other utilities.
With regards to handling different versions of files and updates, Google makes use of many different types of software designed to handle file revisions and controls, however with regards to this project, the software that we are using is called Subversion, which does a really good job at making sure every member is on the same page, and is considered an industry standard for collaborative programming. Basically, there is a master copy of the project, in this case the instance hosted on Google project hosting, and all members have a copy of that master copy in a folder on their computer. When one makes changes or additions, one uses a Subversion client and "commits" their copy to the master copy, or in other words, replaces the master copy with their own copy. Of course, before doing this it would be wise to make sure that the version you plan to upload does not have any errors in it and plays nicely with other components of the project, lest everyone be stuck with a faulty master copy. The Subversion client I used for this project is called TortoiseSVN, a free client that can be found here.
The site I created for this project can be found here: http://code.google.com/p/robocode-ari-dontshootihavecake/
Our objectives for this project were to create a hosting space using Google Project Hosting, where we would upload the code for our competitive robot. Setup didn't take long at all, and after entering basic information the site was successfully set up. The next step was installing TortoiseSVN, which didn't take too long either. Unlike the SVN client for Macs which was featured in our class screen-cast and had a dedicated GUI for operations, Tortoise worked directly through the file directory, and was fairly intuitive to use. Before uploading my robot to the site, I had to make sure that my robot was working properly, and using apache ANT to verify my robot, once I made sure my robot would work, I created a fresh distribution and once putting it into the special folder on my computer for this site, I used Tortoise to commit my files to the online hosting space. This took a matter of seconds and was relatively hassle-free.
Upon uploading my files, I looked around the site and noticed that my actions were promptly noted within the 'Updates' and 'Changes' sections, easily visible to other collaborators. Looking in the 'Source' section of the website, I saw a directory containing all of the files from my distribution, which can also be seen by other members.
After getting acquainted with Google Project Hosting and Subversion software, I must say that this makes it a lot easier to collaborate with others on group projects, and is less of a hassle then having to email individual files or drag-and-drop out of flash drives. My experiences with these tools went pretty smooth, and I would definitely use them when working in groups on codes (Which I have a feeling we might have to in the future).
Thursday, October 20, 2011
Thursday, September 29, 2011
Let's mess around with ANT!
On our continuous journey through the glamorous and exciting world of software engineering, we come across another valuable programming tool, which goes by the name of ANT. And yes, while those tiny insects that scrounge the earth may come to mind upon hearing this name, it's actually an acronym standing for "Another Neat Tool". So the whole insect thing was actually just an afterthought, as it turns out. Anyways, so what exactly does this ANT do? Well simply put, it's an Apache-built automated software build tool, which given the right commands, can automatically compile java files, alter directories, grab updates and modules and whatnot from the internet and place them in the proper system directories on your computer, and that's just the tip of the iceberg. It's as if it gives you the power of an ant-whisperer of sorts, where you tell the ants what you want to be done and they just all go off and do what you told them to do. For more fun facts on ANT, here you go.
In order to get our feet wet with ANT, we were assigned 8 little katas to figure out and compile. Some took more time than others, but for the most part they were all relatively straight-forward. In order to complete these katas, we had to make various build files, which were to be done in XML(ANT uses xml files to execute commands and whatnot). Although lacking in prior experience with the language, the resources provided online, including the apache ant website and tutorials pages proved to be of great assistance in helping me to get off the ground.
There are a couple of special things about ANT that I noticed while going through the katas. Why some of these things are present in ANT I do not know, but they're just things that you're going to have to get used to. For example, properties, which can be thought of as variables, are immutable in ANT, meaning that once you've declared something, you can't change the value, which was the point of one of the katas.
Another interesting feature of ANT is dependencies, which are pretty much what targets, which can be thought of as methods, need to do in order for them to run. For example, if I had a target="foo" that had a dependency on another target="bar", denoted by depends="bar", that means that in order for "foo" to run, "bar" must first be run. Even though the code for "foo" might be written before the code for "bar", when compiled, "bar" is run first, followed by "foo". It's a pretty interesting feature of ANT.
Another thing that ANT allows you to do is to run features from JAVA from within ANT. This includes compiling java files, running java files, and even generating javadocs, all of which were some of the katas assigned. In order for ANT to be able to use the features from java, however, it's important to make sure that java is properly installed on your computer, and that all your environmental variables are inputted correctly. This proved to be a minor setback for me completing all of the katas, but eventually I was able to find the errors and fix them accordingly.
Well, that just about sums up my experiences with ANT thus far, and my impressions thus far is that it's a pretty powerful development tool to use, and if done right, it can make one's job as a software developer a lot less difficult.
Tuesday, September 20, 2011
Robocode!
For this week's program we've been dabbling with a little something called robocode, and as the name implies, yes, there are robots involved! Unfortunately however, it's all within a computer simulation, so my hopes of pitting customized roomba bots against each other in a fight to the death will have to wait for now.
Simply put, robocode is a game where you can program custom robots and then put them in a virtual arena where they do battle with other robots until the last one stands. Robots have three basic functions; movement, firing, and detection of other robots, and although that may not seem like a lot, you have the whole java arsenal at your disposal to customize how a robot moves, how it reacts to other enemies, and a multitude of other things. From dancing in sine curves around your enemy to doing a little victory dance when you've destroyed an opponent, the sky's the limit with how detailed and intricate you can get. Robots can be programmed in either java or .NET, but for the purposes of this project java will be exclusively used. For those of you who wish for a more detailed explanation of the wonderful world of robocode, here you go.
I must say that it was a bit difficult at first to get my homemade robots actually working, but after looking over many tutorials and reading through the robowiki, I was able to make a bot that could move around, and eventually destroy other bots. The great thing about robocode is that there is a pretty sizable community, with a multitude of resources including tutorials, explanations, forums and whatnot, something for people of all skill-levels.
Programming knowledge aside however, honestly I'd say the most difficult part of robocode is using trigonometry. Of course, it is by no means mandated that you use trig in order to move around your robot, but without it your code is going to be a lot longer and you're going to have find a lot of workarounds in order to get your robot to do what you want it to do. For example, when locking on to a coordinate, you have to take into account the current angle the robot is facing and the position of the coordinate relative to that robot, calculate the slope and convert that to degrees, then get the robot to face that position and then calculate the distance to determine how far to send the robot. Doing that without trigonometry, you're gonna have a hard time finding those calculations. I personally spent a good 3 to 4 hours trying to come up with a sufficient formula to calculate angles, but not being the trig-whiz I once was in high school, I was unable to figure it out myself. Fortunately however, with help from my good friend the internet, I was able to find a method from a bot that did the exact same thing, and with some slight modifications to the code I was able to implement the function within my robot (properly cited in my code, of course). Right there is another great thing about robocode, you are able to take things you like from other robots and add them to your own, and for the most part it's easily compatible, because all robots are an extension of just one of two classes, Robot or AdvancedRobot.
We were tasked with making a grand total of 13 robots, each with their own specific function. From doing nothing, to travelling in a spiral, to following other robots, to shooting all robots, in all they all pretty much cover the basics of robot movement and action. I was able to complete 12 of the 13 robots, the only one left undone being a bot that tracks another robot with it's gun but does not fire.
Having gotten my feet wet with robocode, I feel that I'm a bit more familiar with the way these robots function. It's easy to pick up, but underneath that simplicity there's just so much depth and so much you're able to do with these robots, that in order to master it, it's gonna take a while. It was really helpful that the project was divided into bots with incremental steps in complexity, so that when you completed one robot you gained insight as to how to program other robots. I'm better off than I was when I started this project, but of course, there's still a long way to go in order to "build the best, destroy the rest!"
Seeing as how the next project involving robocode will be to create a competitive robot and facing off against classmates, I have a feeling that it's definitely going to be harder than fighting with practice bots that just stay still and don't fire at you. It's really going to be important to be mindful of a bunch of factors in order to build a robot that can survive in the arena, things such as ammo depletion, turning direction, trajectory and so on. I know I already have some ideas for my robot (none of which I shall disclose at this time), and am looking forward to programming it in to my robot and pitting it up against my classmates in the upcoming weeks.
Well that just about sums up my experiences with robocode thus far, and I'm sure there's plenty more to come down the line. For those of you who are interested in robots, or just improving your programming skills, I would definitely recommend dabbling in robocode, just to see how far and how skilled you can become.
Programming knowledge aside however, honestly I'd say the most difficult part of robocode is using trigonometry. Of course, it is by no means mandated that you use trig in order to move around your robot, but without it your code is going to be a lot longer and you're going to have find a lot of workarounds in order to get your robot to do what you want it to do. For example, when locking on to a coordinate, you have to take into account the current angle the robot is facing and the position of the coordinate relative to that robot, calculate the slope and convert that to degrees, then get the robot to face that position and then calculate the distance to determine how far to send the robot. Doing that without trigonometry, you're gonna have a hard time finding those calculations. I personally spent a good 3 to 4 hours trying to come up with a sufficient formula to calculate angles, but not being the trig-whiz I once was in high school, I was unable to figure it out myself. Fortunately however, with help from my good friend the internet, I was able to find a method from a bot that did the exact same thing, and with some slight modifications to the code I was able to implement the function within my robot (properly cited in my code, of course). Right there is another great thing about robocode, you are able to take things you like from other robots and add them to your own, and for the most part it's easily compatible, because all robots are an extension of just one of two classes, Robot or AdvancedRobot.
We were tasked with making a grand total of 13 robots, each with their own specific function. From doing nothing, to travelling in a spiral, to following other robots, to shooting all robots, in all they all pretty much cover the basics of robot movement and action. I was able to complete 12 of the 13 robots, the only one left undone being a bot that tracks another robot with it's gun but does not fire.
Having gotten my feet wet with robocode, I feel that I'm a bit more familiar with the way these robots function. It's easy to pick up, but underneath that simplicity there's just so much depth and so much you're able to do with these robots, that in order to master it, it's gonna take a while. It was really helpful that the project was divided into bots with incremental steps in complexity, so that when you completed one robot you gained insight as to how to program other robots. I'm better off than I was when I started this project, but of course, there's still a long way to go in order to "build the best, destroy the rest!"
Seeing as how the next project involving robocode will be to create a competitive robot and facing off against classmates, I have a feeling that it's definitely going to be harder than fighting with practice bots that just stay still and don't fire at you. It's really going to be important to be mindful of a bunch of factors in order to build a robot that can survive in the arena, things such as ammo depletion, turning direction, trajectory and so on. I know I already have some ideas for my robot (none of which I shall disclose at this time), and am looking forward to programming it in to my robot and pitting it up against my classmates in the upcoming weeks.
Well that just about sums up my experiences with robocode thus far, and I'm sure there's plenty more to come down the line. For those of you who are interested in robots, or just improving your programming skills, I would definitely recommend dabbling in robocode, just to see how far and how skilled you can become.
Tuesday, August 30, 2011
FizzBuzz in Eclipse
For this assignment we were tasked with writing the "FizzBuzz" program, which we walked through in an earlier class. What the FizzBuzz program does is print out all numbers from 1 to 100, with a few exceptions:
Completion of the program took about 10 minutes. I originally started with an alternate approach to the problem, which took an int array of size 100, and when put through a for loop gave each int within the array a value of either 0,1,2, or 3 depending on whether it was a multiple of 3,5,3&5, or none of the above, respectively. After this process was done, the completed array would go through another for loop, which printed out "Fizz", "Buzz", "FizzBuzz", or just the number depending on the value in the array. After some consideration, I realized that given the simplicity of this problem there were no advantages to doing it this way, and had this problem been on a larger scale, my original method would have been less efficient and more processor-intensive. Thus, I rewrote the program using the method we covered in class.
There were some problems that I had with using eclipse, mostly with setting up a new project and java file. This was my first time using this particular version of Eclipse, so I was a bit unfamiliar with the options, but thanks to my partner I was able to get past that quickly.
One of the things that I have realized through doing this program, through being in a group and helping each other out, is that working with other people can be a reassuring experience, especially when there's something that you personally do not know. Of course, it was a minor issue this time around for myself, but it was reassuring that there was someone to help me. Yet at the same time, it made me feel embarrassed that I couldn't figure out such a simple problem myself, which made me want to really review java and get up to speed so I'm not left behind and dragging my team down.
- If the number is a multiple of 3,the program replaces the number with "Fizz"
- If the number is a multiple of 5, the program replaces the number with "Buzz"
- If the number is a multiple of both 3 and 5, the program replaces the number with "FizzBuzz"
Completion of the program took about 10 minutes. I originally started with an alternate approach to the problem, which took an int array of size 100, and when put through a for loop gave each int within the array a value of either 0,1,2, or 3 depending on whether it was a multiple of 3,5,3&5, or none of the above, respectively. After this process was done, the completed array would go through another for loop, which printed out "Fizz", "Buzz", "FizzBuzz", or just the number depending on the value in the array. After some consideration, I realized that given the simplicity of this problem there were no advantages to doing it this way, and had this problem been on a larger scale, my original method would have been less efficient and more processor-intensive. Thus, I rewrote the program using the method we covered in class.
There were some problems that I had with using eclipse, mostly with setting up a new project and java file. This was my first time using this particular version of Eclipse, so I was a bit unfamiliar with the options, but thanks to my partner I was able to get past that quickly.
One of the things that I have realized through doing this program, through being in a group and helping each other out, is that working with other people can be a reassuring experience, especially when there's something that you personally do not know. Of course, it was a minor issue this time around for myself, but it was reassuring that there was someone to help me. Yet at the same time, it made me feel embarrassed that I couldn't figure out such a simple problem myself, which made me want to really review java and get up to speed so I'm not left behind and dragging my team down.
Monday, August 29, 2011
Assignment: Three Directives evaluation
The three directives for open source software engineering, as described here, outline the three rules essential in the creation of effective software. A quick outline of these directives:
1. The system successfully accomplishes a useful task
2. An external user can successfully install and use the system
3. An external developer can successfully understand and enhance the system
To gain a better understanding of how the three directives can be applied to software, today we will be evaluating an open-source project to see whether or not it comes up to standards with the three directives. The program we will be looking at is Flesh Snatcher, a first-person-shooter game where the objective is to kill all zombies and escape from a needlessly-complicated mansion of sorts.
From now we will evaluate how well the program complies with the three directives.
Directive 1: The system successfully accomplishes a useful task
In order to evaluate the program on this directive, the first thing that must be established is by what means will it be considered as accomplishing a "useful task". The first and foremost function of this program is to serve as a game, so if the program executes a game that is playable, then it will have complied with the first directive. Enjoyability and subject matter will not be put into evaluation, as there are such things as games that accomplish the tasks they were set out to do, even though they may not be fun to play.
Flesh Snatcher is a fast-paced shooter game, and from the get-go you are constantly bombarded with enemy zombies that you need to destroy. The frame-rate, while low in comparison to modern FPS games, was decent enough that the animations appeared smoothly and that there were no noticeable skips or pauses in the graphics. The controls, using keyboard and mouse input, were responsive and intuitive, using key layouts commonly used for PC shooter games, making the game easy to pick up for those who have played PC shooters before.
As a first-person-shooter, in terms of playability, I'd say that this program does a pretty good job. Simple character and level design put aside, it seems to easily fulfill the first directive of fulfilling it's "useful task".
Directive 2: An external user can successfully install and use the system
Obviously, to play the game and evaluate the first directive, I had to have had successfully installed and ran the program. The fact that I am an external user that has already played the game on my own computer proves that this program fulfills the second directive. Upon downloading the zip file containing the game off of sourceforge, once you unzip the file and run the batch .exe file the game automatically launches. In actuality there is no "installation" required, it's as simple as unzipping and playing.
Directive 3: An external developer can successfully understand and enhance the system
Flesh Snatcher complies with GNU General Public License, which means that in addition to being free of charge, the source-code is readily available for analysis and modification. In the zip file that I downloaded, the source code was already included in a separate folder. Opening up the java files in eclipse I was able to see how the many different parts of the program worked, the AI, the maps, the controls, audio, etc. Although scarce, there was documentation within the code itself, labeling what parts of code did what, giving general overviews of what certain java files did, and so on. By the looks of it, an external developer could rather easily understand and alter the code, and thus this program fulfills the third directive.
This concludes my evaluation of Flesh Snatcher, which seems to comply with all three directives. For those of you wishing to pass some time with a good old-fashioned mindless shooting game or wanting to see how such games work underneath the hood, I would recommend downloading the game and looking through some of the source code.
1. The system successfully accomplishes a useful task
2. An external user can successfully install and use the system
3. An external developer can successfully understand and enhance the system
To gain a better understanding of how the three directives can be applied to software, today we will be evaluating an open-source project to see whether or not it comes up to standards with the three directives. The program we will be looking at is Flesh Snatcher, a first-person-shooter game where the objective is to kill all zombies and escape from a needlessly-complicated mansion of sorts.
From now we will evaluate how well the program complies with the three directives.
Directive 1: The system successfully accomplishes a useful task
In order to evaluate the program on this directive, the first thing that must be established is by what means will it be considered as accomplishing a "useful task". The first and foremost function of this program is to serve as a game, so if the program executes a game that is playable, then it will have complied with the first directive. Enjoyability and subject matter will not be put into evaluation, as there are such things as games that accomplish the tasks they were set out to do, even though they may not be fun to play.
Flesh Snatcher is a fast-paced shooter game, and from the get-go you are constantly bombarded with enemy zombies that you need to destroy. The frame-rate, while low in comparison to modern FPS games, was decent enough that the animations appeared smoothly and that there were no noticeable skips or pauses in the graphics. The controls, using keyboard and mouse input, were responsive and intuitive, using key layouts commonly used for PC shooter games, making the game easy to pick up for those who have played PC shooters before.
![]() |
| From the first level "The Factory" |
Directive 2: An external user can successfully install and use the system
Obviously, to play the game and evaluate the first directive, I had to have had successfully installed and ran the program. The fact that I am an external user that has already played the game on my own computer proves that this program fulfills the second directive. Upon downloading the zip file containing the game off of sourceforge, once you unzip the file and run the batch .exe file the game automatically launches. In actuality there is no "installation" required, it's as simple as unzipping and playing.
Directive 3: An external developer can successfully understand and enhance the system
Flesh Snatcher complies with GNU General Public License, which means that in addition to being free of charge, the source-code is readily available for analysis and modification. In the zip file that I downloaded, the source code was already included in a separate folder. Opening up the java files in eclipse I was able to see how the many different parts of the program worked, the AI, the maps, the controls, audio, etc. Although scarce, there was documentation within the code itself, labeling what parts of code did what, giving general overviews of what certain java files did, and so on. By the looks of it, an external developer could rather easily understand and alter the code, and thus this program fulfills the third directive.
This concludes my evaluation of Flesh Snatcher, which seems to comply with all three directives. For those of you wishing to pass some time with a good old-fashioned mindless shooting game or wanting to see how such games work underneath the hood, I would recommend downloading the game and looking through some of the source code.
Thursday, August 25, 2011
First post
This is the first post of my software engineering blog, where I hope to post things that I learn along the way of taking this ICS 314 course.
Subscribe to:
Posts (Atom)
