I was saddened to find out about Sir Clarke's death as I am a fan of his Odyssey and Rama novel series and firmly believe that 2001: A Space Odyssey is still THE BEST Sci-Fi movie to date. I was listening to Eve Radio around 1:00pm (-10 GMT) and the DJ made a comment that Clarke was not dead, but merely with aliens. It seemed like an odd thing to say so I went to check the news through iGoogle and there it was, a headline announcing his death.
Clarke is best known to most people as a grand master of science fiction, but he is also a visionary. He popularized the ideas of geosynchronous satellites and space elevators, and although the ideas did not originate with him, he did elaborate on them. He predicted that satellites in geosynchronous orbit would be great for telecommunication relays, and authored books going over their technical details. In his 1979 novel, The Fountains of Paradise, he introduced his ideas for space elevators. He also wrote a two part article in 1981 called "The Space Elevator: 'Thought Experiment', or Key to the Universe?" He supposedly said that space elevators will be his legacy and I hope it's true.
Up until the end of his life and through his deteriorating health from post-polio syndrome, Clarke continuously worked on something - a novel, a cause, an idea. He received many awards, honors, and even knighthood. It amazes me and makes me wonder where his drive to do all that he has done came from, and I hope I have even a tiny bit of the drive he had as I go on with the rest of my life past college.
Goodbye Sir Arthur Clarke.
Tuesday, March 18, 2008
Monday, March 17, 2008
Continuous Integration with Hudson
Today I learned about continuous integration using the Hudson server system and before this I didn't know anything about continuous integration. It was pretty simple for me to get up and running by just following the tutorial on this site (just make sure you register on IBM first). It may take longer though if you do not already have some prerequisite software installed such as the Java JDK, ANT, and JUnit.
Continuous integration (CI) is a process where projects are automatically built to make sure that any issues encountered will be detected as early as possible in the software development cycle. This automated process requires various types of tools to work. The minimum tools required are an automated build system, a testing framework, and a code repository. Other tools can be used as well to increase the quality of the project such as PMD and FindBugs. For my trial of Hudson, I used the Ant build system, JUnit test framework, and subversion code repository.
So the way the CI process works is pretty simple. The user specifies the code repository's url, when and how often the repository must be checked for a new build version of the project, and then it is downloaded, built, and tested when a new version is found. It's such a simple process to run, but its usefulness and success depends a lot on the developers.
The process of CI alone will not ensure a quality system. There are practices called anti-patterns in this article that developers follow that can make CI a failure for them. A couple of the anti-patterns mentioned in the article that I find myself guilty of doing:
As I mentioned earlier, I used Hudson to get a feel for continuous integration. Installation was pretty simple and the only problem I ran into, which was pretty stupid, was when I couldn't get Hudson to load on my system after using the "java -jar hudson.war" command. At the time I had my Apache HTTP server running, and it too was using port 8080. After a few minutes (yes it took me minutes) to realize that I could just stop the server! The rest of the Hudson installation and configuration went smoothly afterwards. Oh, and I used the ambientHackystat project to test out Hudson.
CSDL Hudson Server
Getting the ambientHackystat project working on the CSDL server won't take much effort since it is a Java project. I suspect that the server is already setup with Ant and JUnit so all that's left to do is create a new project, specify the subversion repository url, the interval for Hudson to check the ambientHackystat code repository, that Ant should be executed when Hudson has downloaded the recent build, then specify the location for the test reports xml file.
Continuous integration (CI) is a process where projects are automatically built to make sure that any issues encountered will be detected as early as possible in the software development cycle. This automated process requires various types of tools to work. The minimum tools required are an automated build system, a testing framework, and a code repository. Other tools can be used as well to increase the quality of the project such as PMD and FindBugs. For my trial of Hudson, I used the Ant build system, JUnit test framework, and subversion code repository.
So the way the CI process works is pretty simple. The user specifies the code repository's url, when and how often the repository must be checked for a new build version of the project, and then it is downloaded, built, and tested when a new version is found. It's such a simple process to run, but its usefulness and success depends a lot on the developers.
The process of CI alone will not ensure a quality system. There are practices called anti-patterns in this article that developers follow that can make CI a failure for them. A couple of the anti-patterns mentioned in the article that I find myself guilty of doing:
- Checking code in to the repository infrequently. The idea behind this is that code should be checked in frequently so that other team members know what's going on with development and allow them to give their own input before changes go too far.
- Submitting broken code. Broken code can remain unfixed for a long time even if other members try to fix it, but it can also hold up development in the long run.
As I mentioned earlier, I used Hudson to get a feel for continuous integration. Installation was pretty simple and the only problem I ran into, which was pretty stupid, was when I couldn't get Hudson to load on my system after using the "java -jar hudson.war" command. At the time I had my Apache HTTP server running, and it too was using port 8080. After a few minutes (yes it took me minutes) to realize that I could just stop the server! The rest of the Hudson installation and configuration went smoothly afterwards. Oh, and I used the ambientHackystat project to test out Hudson.
CSDL Hudson Server
Getting the ambientHackystat project working on the CSDL server won't take much effort since it is a Java project. I suspect that the server is already setup with Ant and JUnit so all that's left to do is create a new project, specify the subversion repository url, the interval for Hudson to check the ambientHackystat code repository, that Ant should be executed when Hudson has downloaded the recent build, then specify the location for the test reports xml file.
Wednesday, March 12, 2008
Code Review: Visual Studio 2008 Hackystat Sensor
I am reviewing the Visual Studio 2008 Hackystat Sensor project.
Installation
I was able to get both the sensor working and the source code compiled by following the Project's Installation Guide and the Developer Guide. If I hadn't been informed earlier that the source code wouldn't compile due to a missing package called NUnit and hadn't been provided with a newer release of the source code, compilation would have failed.
Others may not agree, but I think that it was enough to state in both guides that in order to use this sensor, the user would need to download the Hackystat sensorshell. The link provided went directly to the Hackystat sensorshell page too which had its own installation guide for the user to follow. Good enough for me as a user.
The Code
The Visual Studio sensor is programmed in C#. I was briefly exposed to C# for a database course I took a couple of years ago when I had to create an application for a MS SQL database. It's funny to see how much has changed. Back then, syntax such as functions followed C++ convention by utilizing the underscore and sometimes the "m_" prefix was used for variables. Even commenting was simply using inline tags. Now code convention looks more like Java and commenting includes XML tags.
As far as the project's code, I can't really provide good input since I never really got into C# (although I always meant to). One thing I would recommend though is sticking to a 100 max characters per line to avoid the ugly wrap-around of long code.
Testing
To test the sensors, I used a project from another class written in C++ as well as looked at the User Guide to see what data would be available on the Hackystat sensordatabrowser. Each data listed on the user guide excluding the NUnit related data appeared. Beyond this, I didn't know what to test for.
Addition: I just got an error about the sensor not starting up when I started a second instance of Visual studio to view some old C# code.
Usefulness
The current data that the sensor monitors is pretty limited for now, but I expect that as development continues, there will be more. I must say though that I do not see the need of having separate events for opening, closing, and saving a file. It could all be combined to one event. Simply state that the file was opened and if it was edited, set it to true which implies that the file was saved. I don't think I even need to know that I closed a file while working in Visual Studio.
As far as what data I'd like the sensor to pick up, I was thinking of events that when combined, would reveal information on what a programmer's work environment was like. I'm not sure if the sensor could do it, but if it was able to grab the screen resolution that the programmer used while working in Visual Studio and see if a programmer was using multiple display screens (i.e. multiple monitors or projects) and combine that with how they arrange their visual studio workspace (e.g. do they use auto hide for other windows like properties or solution explorer?), we could see the optimal environment that a programmer works in. I'm not sure though if this idea is useful for an individual, but I could imagine software development companies finding the information handy.
Conclusion
I think the project is on a good track. It just needs more useful dev events.
Installation
I was able to get both the sensor working and the source code compiled by following the Project's Installation Guide and the Developer Guide. If I hadn't been informed earlier that the source code wouldn't compile due to a missing package called NUnit and hadn't been provided with a newer release of the source code, compilation would have failed.
Others may not agree, but I think that it was enough to state in both guides that in order to use this sensor, the user would need to download the Hackystat sensorshell. The link provided went directly to the Hackystat sensorshell page too which had its own installation guide for the user to follow. Good enough for me as a user.
The Code
The Visual Studio sensor is programmed in C#. I was briefly exposed to C# for a database course I took a couple of years ago when I had to create an application for a MS SQL database. It's funny to see how much has changed. Back then, syntax such as functions followed C++ convention by utilizing the underscore and sometimes the "m_" prefix was used for variables. Even commenting was simply using inline tags. Now code convention looks more like Java and commenting includes XML tags.
As far as the project's code, I can't really provide good input since I never really got into C# (although I always meant to). One thing I would recommend though is sticking to a 100 max characters per line to avoid the ugly wrap-around of long code.
Testing
To test the sensors, I used a project from another class written in C++ as well as looked at the User Guide to see what data would be available on the Hackystat sensordatabrowser. Each data listed on the user guide excluding the NUnit related data appeared. Beyond this, I didn't know what to test for.
Addition: I just got an error about the sensor not starting up when I started a second instance of Visual studio to view some old C# code.
Usefulness
The current data that the sensor monitors is pretty limited for now, but I expect that as development continues, there will be more. I must say though that I do not see the need of having separate events for opening, closing, and saving a file. It could all be combined to one event. Simply state that the file was opened and if it was edited, set it to true which implies that the file was saved. I don't think I even need to know that I closed a file while working in Visual Studio.
As far as what data I'd like the sensor to pick up, I was thinking of events that when combined, would reveal information on what a programmer's work environment was like. I'm not sure if the sensor could do it, but if it was able to grab the screen resolution that the programmer used while working in Visual Studio and see if a programmer was using multiple display screens (i.e. multiple monitors or projects) and combine that with how they arrange their visual studio workspace (e.g. do they use auto hide for other windows like properties or solution explorer?), we could see the optimal environment that a programmer works in. I'm not sure though if this idea is useful for an individual, but I could imagine software development companies finding the information handy.
Conclusion
I think the project is on a good track. It just needs more useful dev events.
Tuesday, March 11, 2008
Experience with Flash CS3 & ActionScript 3.0 Part I
Lately I've been working with Flash CS3 and its programming language, ActionScript 3.0, to make little games for my game design class. ActionScript is pretty similar to O-O languages like C++, Java, and C#. As a beginner ActionScript programmer I find it irritating to work with Flash as an IDE (apparently it's considered an IDE) for solo projects and near painful for team projects, but from a design perspective it's a nice suite to work in.
My First Game
When I started learning Flash and ActionScript I put all of my code into the .fla file itself. For my first program I had to modify the example Breakout game on the Adobe website. I had to use custom art and sound provided by the class artists to replace the existing game objects, and I had to add new features . I only added a scoring system, but other programmers implemented some nice stuff like unbreakable bricks, multiplying balls, and random brick positioning.
One annoyance I ran into was the code autoformatter. It wouldn't simply format the code for me so it was readable. It would complain that there was an error in the syntax. Sometimes it even complains when there's no syntax error, which I found out is an existing bug in Flash CS3. It would also format code incorrectly. The multiline comment tags don't get properly indented with the section of code it documents so I have to go back to using inline comments to make the code look nice.
Another annoyance with Flash CS3 is the code folding feature. Unlike IDEs such as Eclipse or Visual Studio or even text editors like Notepad++ that have + and - signs along the left, Flash can only fold code that's highlighted or by using some of the marginally useful options in the right click interface. I can see where being able to hide only the highlighted code comes in handy, but it's ultimately useless when you want to hide multiple screens of code. That's where "right click -> Collapse Between Braces" comes! But not so fast! You have to be precise about where you right click because Flash considers parentheses as braces!
After that experience I thought there had to be a better alternative - a better IDE. I went straight for Eclipse since I was already working with that. Two options I ran into were the ASDT plugin and the Flex 3 SDK. ASDT was a dead end since it only supported up to ActionScript 2. I had high hopes for Flex 3 since the retail version, Flex Builder 3, uses the SDK on top of Eclipse, but that too failed me. Apparently Adobe decided not to provide instructions on making their free SDK work with Eclipse so I turned to the web in search of user made guides. I found one, but the hoops I had to jump through made it a waste of my time to try to get to work. I also found out from this site that Adobe left out (purposefully or not) a key xml file that Eclipse required to support ActionScript. In the end I settled on using Notepad++ since it at least supported the language syntax.
My Second Game
After the Breakout game, my instructor put the class into teams with 2 programmers and an artist. The ratio wasn't precise so my team ended up with an extra artist which meant 2 versions of the same game with different art (so the artists can be graded and made sure they were doing their work). Everyone in the team was responsible for providing input for the design of the game and we decided to do a sidescrolling racing game along the lines of Super Mario or Donkey Kong with 1 set of art being ninjas and the other being robots.
I decided to look into some books that taught ActionScript. This is how I found out about ".as" or actionscript files which is where source code can go. In order to use an actionscript file the main .as file needs to be defined in the document class field in the fla file. This is where it gets really irritating for me. Not only can code go into fla files, but they can also go in actionscript files.
Flash CS3 Workspace: Stage & .as file definition
Where Code Can Go
Putting almost all the code into the .fla file is not good when it comes to team projects in at least my case. Every programmer in my class initially learned to program in the same way since we all had to modify the Breakout example game - we put the code in the .fla file. When we switched to team projects, we had free reign on what kind of game we were going to develop and we started learning actionscript independently. Most if not all continued putting the code the .fla file while some like me looked into actionscript files and tried to adopt it into our project.
For my second game, I took the responsibility of trying to implement these actionscript files, but since I was just learning to do it the first time and I still wasn't completely familiar with how Flash worked my team just went with one actionscript file. Needless to say, one programmer ended up doing the bulk of the code since you really need the .fla file to test your code. My responsibility ended up getting the final code working with the final art assets and audio provided by the artists. This is where it got bad for me.
Since the other programmer did the bulk of the coding i.e. player movement, physics, and collision, I didn't really understand all too well what was happening even though we went over what his code was doing during the two times we met to work on the game. Although he was doing the actual coding, I was still trying to learn how player movement, physics, and collision worked on my own because I had to make the final layout of the 2 games. When I got the other programmer's code (that programmer didn't take software engineering with Professor Johnson) it was badly formatted and barely documented so I had to clean it up and read through it. I ended up realizing that how I learned to do player movement, physics, and collision was way different from how he did it in the code. In his code, the images were loaded programmatically. The way I learned to do it, which is also the more practical way, was to put it on the stage. I'll explain more on how this works on another post since this one is getting long. I ended up pulling an all-nighter having to redo most of the program so everything worked the way I learned it. Also, since I got the art assets real late, I was in a mad rush trying to import all the art into their respective .fla files. By the time it was due, I wasn't able to implement audio for the game or the race traps that we wanted as obstacles.
My Third Game
I won't say much about this game except that I tried to push for multiple actionscript files so both programmers could work concurrently and tried to get a consensus on how to go about programming so when we combined our code, everything would go smoothly. When it came down the line, the other programmer (admittedly the more talented programmer) chose to stick with their way because he felt more comfortable with it. Due to other circumstances none of my work got into the final product. One circumstance being that the artists (yes I got stuck with 2 artists again) were unable to give us their work early enough due to their other commitments like work which I felt was understandable. The other being that the other programmer stopped communicating with me except to say he finished the games seven hours before it was due. I spent 3 days trying to do my part which relied a lot on the art that the artists did not finish yet and for 2 of those days I tried to keep in contact with the other programmer who made it hard since he would only communicate by e-mail (seemingly ignoring my questions) and not use instant messaging which me and the artists were using when we were online.
My First Game
When I started learning Flash and ActionScript I put all of my code into the .fla file itself. For my first program I had to modify the example Breakout game on the Adobe website. I had to use custom art and sound provided by the class artists to replace the existing game objects, and I had to add new features . I only added a scoring system, but other programmers implemented some nice stuff like unbreakable bricks, multiplying balls, and random brick positioning.
One annoyance I ran into was the code autoformatter. It wouldn't simply format the code for me so it was readable. It would complain that there was an error in the syntax. Sometimes it even complains when there's no syntax error, which I found out is an existing bug in Flash CS3. It would also format code incorrectly. The multiline comment tags don't get properly indented with the section of code it documents so I have to go back to using inline comments to make the code look nice.
Another annoyance with Flash CS3 is the code folding feature. Unlike IDEs such as Eclipse or Visual Studio or even text editors like Notepad++ that have + and - signs along the left, Flash can only fold code that's highlighted or by using some of the marginally useful options in the right click interface. I can see where being able to hide only the highlighted code comes in handy, but it's ultimately useless when you want to hide multiple screens of code. That's where "right click -> Collapse Between Braces" comes! But not so fast! You have to be precise about where you right click because Flash considers parentheses as braces!
After that experience I thought there had to be a better alternative - a better IDE. I went straight for Eclipse since I was already working with that. Two options I ran into were the ASDT plugin and the Flex 3 SDK. ASDT was a dead end since it only supported up to ActionScript 2. I had high hopes for Flex 3 since the retail version, Flex Builder 3, uses the SDK on top of Eclipse, but that too failed me. Apparently Adobe decided not to provide instructions on making their free SDK work with Eclipse so I turned to the web in search of user made guides. I found one, but the hoops I had to jump through made it a waste of my time to try to get to work. I also found out from this site that Adobe left out (purposefully or not) a key xml file that Eclipse required to support ActionScript. In the end I settled on using Notepad++ since it at least supported the language syntax.
My Second Game
After the Breakout game, my instructor put the class into teams with 2 programmers and an artist. The ratio wasn't precise so my team ended up with an extra artist which meant 2 versions of the same game with different art (so the artists can be graded and made sure they were doing their work). Everyone in the team was responsible for providing input for the design of the game and we decided to do a sidescrolling racing game along the lines of Super Mario or Donkey Kong with 1 set of art being ninjas and the other being robots.
I decided to look into some books that taught ActionScript. This is how I found out about ".as" or actionscript files which is where source code can go. In order to use an actionscript file the main .as file needs to be defined in the document class field in the fla file. This is where it gets really irritating for me. Not only can code go into fla files, but they can also go in actionscript files.
You can stick code into each frame of each layer of each scene to control the behavior of each frame and it can get unwieldy. Even though everything is overall linear it can become confusing when you start jumping to different frames using the Flash equivalents of GOTO statements, which are gotoAndPlay() and gotoAndStop(). Unfortunately, these are necessary for Flash in order to switch frames if you don't want to put everything in one frame and manipulate their visibility programmatically.
Flash CS3 Workspace: Stage & .as file definition
Where Code Can Go
Putting almost all the code into the .fla file is not good when it comes to team projects in at least my case. Every programmer in my class initially learned to program in the same way since we all had to modify the Breakout example game - we put the code in the .fla file. When we switched to team projects, we had free reign on what kind of game we were going to develop and we started learning actionscript independently. Most if not all continued putting the code the .fla file while some like me looked into actionscript files and tried to adopt it into our project.
For my second game, I took the responsibility of trying to implement these actionscript files, but since I was just learning to do it the first time and I still wasn't completely familiar with how Flash worked my team just went with one actionscript file. Needless to say, one programmer ended up doing the bulk of the code since you really need the .fla file to test your code. My responsibility ended up getting the final code working with the final art assets and audio provided by the artists. This is where it got bad for me.
Since the other programmer did the bulk of the coding i.e. player movement, physics, and collision, I didn't really understand all too well what was happening even though we went over what his code was doing during the two times we met to work on the game. Although he was doing the actual coding, I was still trying to learn how player movement, physics, and collision worked on my own because I had to make the final layout of the 2 games. When I got the other programmer's code (that programmer didn't take software engineering with Professor Johnson) it was badly formatted and barely documented so I had to clean it up and read through it. I ended up realizing that how I learned to do player movement, physics, and collision was way different from how he did it in the code. In his code, the images were loaded programmatically. The way I learned to do it, which is also the more practical way, was to put it on the stage. I'll explain more on how this works on another post since this one is getting long. I ended up pulling an all-nighter having to redo most of the program so everything worked the way I learned it. Also, since I got the art assets real late, I was in a mad rush trying to import all the art into their respective .fla files. By the time it was due, I wasn't able to implement audio for the game or the race traps that we wanted as obstacles.
My Third Game
I won't say much about this game except that I tried to push for multiple actionscript files so both programmers could work concurrently and tried to get a consensus on how to go about programming so when we combined our code, everything would go smoothly. When it came down the line, the other programmer (admittedly the more talented programmer) chose to stick with their way because he felt more comfortable with it. Due to other circumstances none of my work got into the final product. One circumstance being that the artists (yes I got stuck with 2 artists again) were unable to give us their work early enough due to their other commitments like work which I felt was understandable. The other being that the other programmer stopped communicating with me except to say he finished the games seven hours before it was due. I spent 3 days trying to do my part which relied a lot on the art that the artists did not finish yet and for 2 of those days I tried to keep in contact with the other programmer who made it hard since he would only communicate by e-mail (seemingly ignoring my questions) and not use instant messaging which me and the artists were using when we were online.
Wednesday, March 5, 2008
Code Review: Ambient Hackystat
I tried out the Ambient Hackystat project using the code review release featured on the project's Google code front page (version 0.1.221). The idea behind this project is that an ambient device (e.g. Ambient Orb or Nabaztag) will perform a predefined action such as flashing a color and/or making a sound when it receives a trigger caused by activities posted onto the Hackystat sensorbase.
Installation and ANT
To install the project on my system, I followed the installation and developer guide found on the project wiki. There were environment variables that were missing from the developer guide so it was a bit of an inconvenience to find out that I hadn't set it all up. I planned on adding the variables after each time that ANT complained, but after having to restart twice so the changes took effect I remembered that all the variables needed were specified in the build path when the project was loaded on Eclipse. It was mentioned by Professor Johnson that most of these dependencies were unnecessary during the AmbientHackystat team's overview of their system, so this shouldn't be an issue for future releases.
These were the variables not mentioned in the developer guide:
HACKYSTAT_DAILYPROJECTDATA_HOME
HACKYSTAT_SENSORBASE_HOME
HACKYSTAT_TELEMETRY_HOME
HACKYSTAT_UTILITIES
RESTLET_HOME
After all this, my first task was to make sure that ant -f verify.build.xml was successful, but it failed due to size.xml missing in the project's Build/SCLC directory. Running the JUnit ANT task failed as well. One error I was able to fix was JavaMail being uninstalled correctly. After some trial and error, I found out that mail.jar goes inside the Java/jdk/jre/lib/ext directory and not the Java/jre/lib/ext directory as instructed by the Hackystat InstallingJavaMail wiki.
These are the following JUnit errors I couldn't fix:
[junit] Test org.hackystat.ambientdevice.server.TestAmbientServer FAILED
[junit] Running org.hackystat.ambientdevice.trigger.TestCommitTrigger
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.152 sec
[junit] Error:
[junit] 03/05 11:11:40 Derby: previously initialized.
[junit]
[junit] Derby shutdown hook results: Derby system shutdown.
[junit] Test org.hackystat.ambientdevice.trigger.TestCommitTrigger FAILED
[junit] Running org.hackystat.ambientdevice.trigger.TestCoverageCompareTrigger
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.466 sec
[junit] Output:
[junit] C:\Users\Owner/.hackystat/sensorbase/sensorbase.properties not found. Using default sensorbase properties.
There are more JUnit errors, but they all involve trigger testing which I suspect is related to derby being initialized already and having to shutdown.
Changing Colors
To test whether the system worked, I modified the configuration.test.xml so that the ambient orb turned chartreuse when an ANT build was a success. After executing ant on the project itself and waiting for about an hour, the orb finally changed to chartreuse. The whole time I thought I was doing something wrong because I kept getting a warning that the sensorbase host address I specified was incorrect (which it wasn't).
Trigger Action Language
Overall the trigger action language is understandable, but some improvements could be made. The four tags enclosed between the project tags should only have to be specified once to shorten the amount of lines in the file. I think it will affect readability when more triggers are added. The value and comparation tags should also be renamed to something more meaningful.
I've also noticed that there are other triggers, but most haven't been implemented in the xml file. These triggers also center around the testing and coverage tools so triggers for other tools would be recommended such as triggers for code style.
Java Code
The Java code looks fine for now. It just needs descriptive documentation.
Bogosities
I could only think of one and it's that it takes too long for the color to change. It's not the team's fault since they're using the ambient orb company's pager system, but it would be great if the time it took for the color to change was shortened to around 2 minutes so that the triggers were more useful for productivity.
Everything else about the implementation seems reasonable for its stage of development.
Installation and ANT
To install the project on my system, I followed the installation and developer guide found on the project wiki. There were environment variables that were missing from the developer guide so it was a bit of an inconvenience to find out that I hadn't set it all up. I planned on adding the variables after each time that ANT complained, but after having to restart twice so the changes took effect I remembered that all the variables needed were specified in the build path when the project was loaded on Eclipse. It was mentioned by Professor Johnson that most of these dependencies were unnecessary during the AmbientHackystat team's overview of their system, so this shouldn't be an issue for future releases.
These were the variables not mentioned in the developer guide:
HACKYSTAT_DAILYPROJECTDATA_HOME
HACKYSTAT_SENSORBASE_HOME
HACKYSTAT_TELEMETRY_HOME
HACKYSTAT_UTILITIES
RESTLET_HOME
After all this, my first task was to make sure that ant -f verify.build.xml was successful, but it failed due to size.xml missing in the project's Build/SCLC directory. Running the JUnit ANT task failed as well. One error I was able to fix was JavaMail being uninstalled correctly. After some trial and error, I found out that mail.jar goes inside the Java/jdk/jre/lib/ext directory and not the Java/jre/lib/ext directory as instructed by the Hackystat InstallingJavaMail wiki.
These are the following JUnit errors I couldn't fix:
[junit] Test org.hackystat.ambientdevice.server.TestAmbientServer FAILED
[junit] Running org.hackystat.ambientdevice.trigger.TestCommitTrigger
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3.152 sec
[junit] Error:
[junit] 03/05 11:11:40 Derby: previously initialized.
[junit]
[junit] Derby shutdown hook results: Derby system shutdown.
[junit] Test org.hackystat.ambientdevice.trigger.TestCommitTrigger FAILED
[junit] Running org.hackystat.ambientdevice.trigger.TestCoverageCompareTrigger
[junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.466 sec
[junit] Output:
[junit] C:\Users\Owner/.hackystat/sensorbase/sensorbase.properties not found. Using default sensorbase properties.
There are more JUnit errors, but they all involve trigger testing which I suspect is related to derby being initialized already and having to shutdown.
Changing Colors
To test whether the system worked, I modified the configuration.test.xml so that the ambient orb turned chartreuse when an ANT build was a success. After executing ant on the project itself and waiting for about an hour, the orb finally changed to chartreuse. The whole time I thought I was doing something wrong because I kept getting a warning that the sensorbase host address I specified was incorrect (which it wasn't).
Trigger Action Language
Overall the trigger action language is understandable, but some improvements could be made. The four tags enclosed between the project
I've also noticed that there are other triggers, but most haven't been implemented in the xml file. These triggers also center around the testing and coverage tools so triggers for other tools would be recommended such as triggers for code style.
Java Code
The Java code looks fine for now. It just needs descriptive documentation.
Bogosities
I could only think of one and it's that it takes too long for the color to change. It's not the team's fault since they're using the ambient orb company's pager system, but it would be great if the time it took for the color to change was shortened to around 2 minutes so that the triggers were more useful for productivity.
Everything else about the implementation seems reasonable for its stage of development.
Subscribe to:
Posts (Atom)