For the Devcathlon project my group was tasked with creating a UI mockup consisting of HTML files. It's been a while since I've done anything advance with HTML so it took me some time to get off the ground. At first we decided to make some webpage designs and pick the one that we will use. Our final design became an amalgam of our design ideas. Some of our ideas included creating a gamer card that a player could use in places such as forums. Others included achievements which were unique goals that a player could attempt to reach. Most of our ideas had a Web 2.0 slant to them, giving the game a community aspect. We started off a little late on working on the actual mockup. We each gave ourselves specific tasks to work on. Most of our work was done on the last day.
One of my tasks was to create the achievements page. We had some ideas about how it was going to be implemented. We thought about having team achievements but we sidelined that in order to focus on individual achievements. We also thought about specific achievements for matches but for now we focused on global achievements.
I forgot to invite myself into the Hackystat project until after the all the work was done. This has happened on more than one occasion and now when I think about it, it would have been very helpful if there was an email reminder. It probably wouldn't have matter anyway since the Hackystat sensors were only for Eclipse and i spent my time working with Dreamweaver.
If this was a match, commit-related events would probably work for this project. Code-related events definitely wouldn't apply to this project. We probably wouldn't have won but who knows, the jury is still out. Point allocation in this and most other matches should be a mixture of team and individual efforts.
Monday, January 26, 2009
Wednesday, January 21, 2009
Developing Software By Playing Games
My project for this coming semester involves developing a game for software development. It is called Devcathlon and it is focused on using game mechanics to improve the health of a project and to motivate programmers.
Through my research on game design I found this informative lecture on game design by Will Wright. In it he incorporates ideas from the fields of psychology, biology, computer science, and physics into his idea of good game design. A game designer needs to understand the mind of a player, giving him many possibilities of success. A designer should avoid having an optimum path to success and instead allow players to use different, viable strategies to reach their goals. Playing a game is very much a learning process so a designer should use successes and failures to teach players how to play. Each learning tier should build up on the one before. In games where players have to interact with each other, players can find themselves grouping together in order to achieve goals that they couldn't accomplish individually. In these groups specialization usually occurs, with some individuals more skilled than others at certain tasks. A designer usually must find a balance between competition and cooperation. He must give the player reasons for cooperating and reasons for doing their best.
Through my research on game design I found this informative lecture on game design by Will Wright. In it he incorporates ideas from the fields of psychology, biology, computer science, and physics into his idea of good game design. A game designer needs to understand the mind of a player, giving him many possibilities of success. A designer should avoid having an optimum path to success and instead allow players to use different, viable strategies to reach their goals. Playing a game is very much a learning process so a designer should use successes and failures to teach players how to play. Each learning tier should build up on the one before. In games where players have to interact with each other, players can find themselves grouping together in order to achieve goals that they couldn't accomplish individually. In these groups specialization usually occurs, with some individuals more skilled than others at certain tasks. A designer usually must find a balance between competition and cooperation. He must give the player reasons for cooperating and reasons for doing their best.
Monday, December 8, 2008
Quad Squad
2 weeks ago I was assigned to a new group for the DueDates project. This time instead of working with a partner I had to learn to work with 3 other people. Things got a bit complicated in term of group management but it was nothing we couldn't manage. Professor Johnson once stateed that group leaders didn't need to be assigned because they naturally rise from the group to take that role. Well, he was right. It was clear from the beginning that Ronnie had the sense of responsibly and ability to coordinate easily among different group members that was needed in a leadership position. He had us coordinate our schedule using Doodle so that met several times over the past two weeks. These meeting were located at Sinclair Library and usually occured almost every evening.
We decided to use the DueDates-silver project as a foundation for our new code since it already had xml parsing already built in which was one of the features we had to implement in this project. The only problem with silver was that coded in such a way that made it really difficult for new developers to get a grasp of. That taught me that I had a much easier time with code that I built from the ground up than code that would be handed to me. It took a while but Ronn manage to cut the code that was superfluous to the new project and that helped alot.
Several days later I noticed that mine and other member's statistics weren't being recorded and I realized we didn't add ourselves to our own Hackystat project. I also informed Ronnie that he had to add codesite-noreply@google.com and csdl.hudson@gmail.com because we weren't being emailed any info on the project.
Each of us was given a task to work on. While the others worked on the xml parsing and the web site I had a hand in redoing the the sort implementation and working on the extra credit assignment that involved being able to dynamically load libraries. I know we weren't suppose to work on additional features before we did the main components of the the project but my previous project was developed in similar and I was admittedly weak with Wicket. I felt that I didn't go too much out of my way to work on it. I also did coverage, wiki pages, and fixed a jar issue that was preventing it from running the program. I tested out my extensible library feature and it worked perfectly. I even tested it with a jar.
Eventually when it came down to the wire everything was up and running except for one problem. We couldn't hook up requestInfo to the wicket meaning we couldn't output any info to the website. This was devastating as it was less about needing more time but more about getting help. Many hours were spent trying to find a solution but none were found. None of us could figure it out so we had to set up example output to test the other features of the project.
The jar file of the project can be found here and the distribution can be found here.
We decided to use the DueDates-silver project as a foundation for our new code since it already had xml parsing already built in which was one of the features we had to implement in this project. The only problem with silver was that coded in such a way that made it really difficult for new developers to get a grasp of. That taught me that I had a much easier time with code that I built from the ground up than code that would be handed to me. It took a while but Ronn manage to cut the code that was superfluous to the new project and that helped alot.
Several days later I noticed that mine and other member's statistics weren't being recorded and I realized we didn't add ourselves to our own Hackystat project. I also informed Ronnie that he had to add codesite-noreply@google.com and csdl.hudson@gmail.com because we weren't being emailed any info on the project.
Each of us was given a task to work on. While the others worked on the xml parsing and the web site I had a hand in redoing the the sort implementation and working on the extra credit assignment that involved being able to dynamically load libraries. I know we weren't suppose to work on additional features before we did the main components of the the project but my previous project was developed in similar and I was admittedly weak with Wicket. I felt that I didn't go too much out of my way to work on it. I also did coverage, wiki pages, and fixed a jar issue that was preventing it from running the program. I tested out my extensible library feature and it worked perfectly. I even tested it with a jar.
Eventually when it came down to the wire everything was up and running except for one problem. We couldn't hook up requestInfo to the wicket meaning we couldn't output any info to the website. This was devastating as it was less about needing more time but more about getting help. Many hours were spent trying to find a solution but none were found. None of us could figure it out so we had to set up example output to test the other features of the project.
The jar file of the project can be found here and the distribution can be found here.
Monday, November 24, 2008
Wicked?
This week I started using Wicket to implement a stack web implementation. Suffice it to say I had a rather difficult time with it. I didn't get around to finishing it Mostly it was my fault because I didn't devote enough time to learning Wicket and when it came around to coding I didn't have enough time due to other obligations.
First thing I did was figure whether I wanted to base the main class of my project on the Jetty.class in Example 2 of the wicket examples, which can be found here, or on the Start.class in Example. After some failed attempts getting something similar to the Start.java to run I switched over to Jetty.class which worked out fine. Then started a series of stumbles where I tried to implement something, then finding that it depended on a class that I didn't implement, implementing that class, then finding out that the class also required another class that I didn't implement. At the end I was a bit confused at how PropertyModel worked and I was getting bugs where the it suggested the stack class needed a get method. So now I think that I need a variable in the stack class to hold the data from the textField on the web page and that when a button is pressed on the page the corresponding stack method will use that variable.
My biggest problem that I have to change is time management. I already spent quite some time with the project but didn't realize that I it would take much more than what I had available.
A distribution of the project can be found here.
First thing I did was figure whether I wanted to base the main class of my project on the Jetty.class in Example 2 of the wicket examples, which can be found here, or on the Start.class in Example. After some failed attempts getting something similar to the Start.java to run I switched over to Jetty.class which worked out fine. Then started a series of stumbles where I tried to implement something, then finding that it depended on a class that I didn't implement, implementing that class, then finding out that the class also required another class that I didn't implement. At the end I was a bit confused at how PropertyModel worked and I was getting bugs where the it suggested the stack class needed a get method. So now I think that I need a variable in the stack class to hold the data from the textField on the web page and that when a button is pressed on the page the corresponding stack method will use that variable.
My biggest problem that I have to change is time management. I already spent quite some time with the project but didn't realize that I it would take much more than what I had available.
A distribution of the project can be found here.
Monday, November 17, 2008
Spamalot
This week began the development of the email alert and the scheduled task component of the project. For the email alert we wanted the system to email the user a list of books that are due. For the scheduled tasks we wanted the program to perform a scheduled task. That way we could, for example, have the program check everyday if there are books that are about to be due.
Since we were told that it wasn't too difficult to code, we decided to split the work with me working on the scheduled task and my partner working on the email alert. For my part, first I had some difficulty juggling the data types. I had to parse a double argument and use it as a long for one method and a int for another method along with figuring out time in milliseconds. After creating the Wakeup class for executing the schedule task I realized that I had to somehow run the program without calling main again. Eventually I came to the conclusion that I had to move most of the the code from the main method to the DueDates constructor so that I could execute the program outside the main.
Because of the "simplicity" of this part of the project we met twice this week for 30 mins. Next week we will more than likely meet up for longer since I expect to be given something more difficult. When we met I had issues with my JAVAMAIL_HOME argument where the program will only run if I removed it. Turns out it was somehow conflicting with the mail.jar in the lib/ext of the Java installation. I moved it out of there and redirected the enviromental variable to its new location. Later on I realized that in order for the DueDates.jar file to run correctly I needed mail.jar back in that directory so I just copy and pasted it back in.
Working on version 1.2 was actually in some ways more difficult than 1.1. I definitely got stuck more often in 1.2 than 1.1. In 1.2 had to move around large sections of code in the main. In 1.1 I had to remove more code and add more code than in 1.2.
This week we manage to get code that will fail verify on our local system but pass in Hudson. Because we didn't have system variables for emails in Hudson we had to hard code them in the Junit test case TestMailer.java. Since the host was mail.hawaii.edu it would only work when the system was hooked up to hawaii.edu network. To test email on my system I used smtp-server.hawaii.rr.com.
Next time I want to get more practice with test cases and I want to reconsider how the code is structure. At the moment it works but it isn't a very elegant solution.
A distribution of the new version of the project can be found here.
Since we were told that it wasn't too difficult to code, we decided to split the work with me working on the scheduled task and my partner working on the email alert. For my part, first I had some difficulty juggling the data types. I had to parse a double argument and use it as a long for one method and a int for another method along with figuring out time in milliseconds. After creating the Wakeup class for executing the schedule task I realized that I had to somehow run the program without calling main again. Eventually I came to the conclusion that I had to move most of the the code from the main method to the DueDates constructor so that I could execute the program outside the main.
Because of the "simplicity" of this part of the project we met twice this week for 30 mins. Next week we will more than likely meet up for longer since I expect to be given something more difficult. When we met I had issues with my JAVAMAIL_HOME argument where the program will only run if I removed it. Turns out it was somehow conflicting with the mail.jar in the lib/ext of the Java installation. I moved it out of there and redirected the enviromental variable to its new location. Later on I realized that in order for the DueDates.jar file to run correctly I needed mail.jar back in that directory so I just copy and pasted it back in.
Working on version 1.2 was actually in some ways more difficult than 1.1. I definitely got stuck more often in 1.2 than 1.1. In 1.2 had to move around large sections of code in the main. In 1.1 I had to remove more code and add more code than in 1.2.
This week we manage to get code that will fail verify on our local system but pass in Hudson. Because we didn't have system variables for emails in Hudson we had to hard code them in the Junit test case TestMailer.java. Since the host was mail.hawaii.edu it would only work when the system was hooked up to hawaii.edu network. To test email on my system I used smtp-server.hawaii.rr.com.
Next time I want to get more practice with test cases and I want to reconsider how the code is structure. At the moment it works but it isn't a very elegant solution.
A distribution of the new version of the project can be found here.
Friday, November 7, 2008
Emergency Room
Recently we started working with the idea of "Software ICU" where the progress and "health" of a project can be tracked. The idea is to takes information from the project such as coverage and commits and track these statistics over time. It's helpful to be able to see the history of project because that will in turn influence the future development of it. In our project we used Hackystat to assist us with this idea. I installed all the necessary tools which included Perl, JavaNCSS, DependencyFinder, and SCLC and followed the instructions. Then I verified that I was sending vital signs from the example project, stack-johnson, and duedates-yellow. Note that in order to send vitals signs, we had to update our build files and create a Hackstat project. We also created a daily build for our project. Some obstacles I encountered was the usual getting the enviromental variables correctly set and running the build files in eclipse because it's my prefered method rather than using the command prompt. So far I noted that in the Software Project Portfolio Analysis the weakest part of our project is coverage. Otherwise the others stats are generally good.
Monday, November 3, 2008
Climbing the Ladder
This week we started the next phase of the DueDates project. We gained some experience with Continuous Integration using Hudson. Hudson gives us another level of oversight on our program, allowing us to double check our code. I found that it was a good way to catch errors that might not crop up during testing on a local system such as forgetting to upload a newly created java file. At one point Hudson was giving me errors about using @Override in certain portions of my code even though it passed verify on my system. Turns out that it noticed that those methods didn't actually override the superclass methods so @Override was unecessary.
Additionally we were tasked with adding new capabilities to our program, including supporting multiple libraries, sorting, and output control. To deal with the new arguments I added a bunch of conditional statements. To deal with the new requirements I first thought up of a complex program structure that involved storing book objects into a ArrayList for each library and storing each of those list into another ArrayList. Eventually my partner John Ly came up with a much simpler implementation that only needed a single ArrayList.
For the sorting method, at first my partner created a sorting method that used bubble sort. I decided that it was simpler to use the Collection class to sort the ArrayList and override the necessary methods. I spent some time fighting with FindBugs over EQ_COMPARETO_USE_OBJECT_EQUALS but eventually I resolved it. Additionally we first assumed that sorting by library didn't need any work since books were placed in the ArrayList by libraries according to the order of the arguments but eventually we realized that we didn't consider multiple account request to the same library. After some research I used the Comparator class in the Java API to add the library sort capability.
As for the within method we used a Calendar class help us contain the date information and used it also drop books from our ArrayList that weren't due within the user specified number of days.
For the project we met up twice for about 2 hours. During that time we shifted from my idea for the program structure to John Ly's idea for it. Having face to face helps quite a bit when you have to discuss complex program structures and features. It's a good way to ensure that the other person understands them. With other forms of communication it becomes a bit more diffucult. Eventually we finished meeting the requirements for the project. A distribution of the current state of the project can be found here.
Additionally we were tasked with adding new capabilities to our program, including supporting multiple libraries, sorting, and output control. To deal with the new arguments I added a bunch of conditional statements. To deal with the new requirements I first thought up of a complex program structure that involved storing book objects into a ArrayList for each library and storing each of those list into another ArrayList. Eventually my partner John Ly came up with a much simpler implementation that only needed a single ArrayList.
For the sorting method, at first my partner created a sorting method that used bubble sort. I decided that it was simpler to use the Collection class to sort the ArrayList and override the necessary methods. I spent some time fighting with FindBugs over EQ_COMPARETO_USE_OBJECT_EQUALS but eventually I resolved it. Additionally we first assumed that sorting by library didn't need any work since books were placed in the ArrayList by libraries according to the order of the arguments but eventually we realized that we didn't consider multiple account request to the same library. After some research I used the Comparator class in the Java API to add the library sort capability.
As for the within method we used a Calendar class help us contain the date information and used it also drop books from our ArrayList that weren't due within the user specified number of days.
For the project we met up twice for about 2 hours. During that time we shifted from my idea for the program structure to John Ly's idea for it. Having face to face helps quite a bit when you have to discuss complex program structures and features. It's a good way to ensure that the other person understands them. With other forms of communication it becomes a bit more diffucult. Eventually we finished meeting the requirements for the project. A distribution of the current state of the project can be found here.
Subscribe to:
Posts (Atom)