We've done our code review and although we were well aware that there were a lot of problems, some particularly embarrassing issues that I never noticed have begun to surface. Granted, we are at a bit of a disadvantage because so much of the work we have done thus far is not even code and so cannot be included in the code review. In fact we decided to create the Overviewer application that is being reviewed in part so that we would have something to present. That I think limits us to the level of functionality that we have, but there are some fundamental usability issues that we never considered:
-Mislabeled pages-
The first mock-up of the Overviewer had a page for each team so that we could begin to put together what we were imagining it would look like in the end. When we started to add functionality like the calendar and the project map, we just added them to separate project pages arbitrarily.
Problem created:
Understandably, this created some confusion with what our code reviewers were supposed to do. We asked them to get their projects up and running with the project map, and some accidentally assumed that meant the page for their project had to display the information. All we wanted was for them to change the tree that was already available on the Info-Work page to their own tree. Even that turned out to be, contrary to our expectations, a non-trivial task - so the fact that some of our code reviewers tried to implement the tree in their own project was very bad indeed.
-Project Tree-
The project tree itself, after seeing it from the eyes of our reviewers is quite pointless. When we (finally) got it up, it was a beautiful thing to behold at the time because it had taken us so long and it was satisfying to see results. Now that that little honey-moon is over, I've realized that this form of presenting the project info is not only nothing special, it puts the focus not on who's editing what, but on what the file structure of the project is. That is not the point of the map and so it fails to serve it's purpose.
-Conclusion-
Our focus has changed from the informative workspace to the overviewer as we have discovered that some sort of context to the information of a large e-bulletin board is necessary. This code review has helped us to realize that the map is the most important part of what the overviewer can provide and that so far we've done it wrong. The discovery of the HeatMap is very exciting and so I have a sneaky suspicion that we will be changing focus from the overviewer as a whole to just the heat map after our next meeting.
Wednesday, April 2, 2008
Wednesday, March 19, 2008
iHacky Code Review
The iHacky system right now is nothing more than a project name rememberizer. Even though a lot of the missing functionality is just not implemented yet, not much really works that apparently should. For example I can try to look for other people who use Eclipse supposedly, but nobody shows up - I can't even set that I use Eclipse.
The profile page is useless. I'd like to see some forms that I can fill in to individualize my page; my suggestions would be to have a tag cloud of languages with the size directly proportional to proficiency, an actual list of what software >I< use, and links to project pages that are maintained outside of iHacky. But honestly, at this point I'd be happy with ANYthing - as there is currently nothing.
Also, I'm not sure if it's an issue with hackystat or with iHacky, but the members of my project are not listed. There also isn't anything available in the Team page, but it looks like that might also be connected to hackystat? It's hard to tell what should be editable and what isn't because it's a hackystat thing; some clarification of that would be nice.
Signing up and getting started was pretty easy, but maybe when someone signs on for the first time it should prompt for the hackystat account info right away, rather than depending ont he user to go find it. That's a very minor issue... I'm just trying to find a way to make my compliment critical because they asked for brutality ;^P
The profile page is useless. I'd like to see some forms that I can fill in to individualize my page; my suggestions would be to have a tag cloud of languages with the size directly proportional to proficiency, an actual list of what software >I< use, and links to project pages that are maintained outside of iHacky. But honestly, at this point I'd be happy with ANYthing - as there is currently nothing.
Also, I'm not sure if it's an issue with hackystat or with iHacky, but the members of my project are not listed. There also isn't anything available in the Team page, but it looks like that might also be connected to hackystat? It's hard to tell what should be editable and what isn't because it's a hackystat thing; some clarification of that would be nice.
Signing up and getting started was pretty easy, but maybe when someone signs on for the first time it should prompt for the hackystat account info right away, rather than depending ont he user to go find it. That's a very minor issue... I'm just trying to find a way to make my compliment critical because they asked for brutality ;^P
Monday, March 17, 2008
Hudson
"The IBM developerWorks Web site is currently under maintenance." and has been the whole night I was trying to access the tutorial. But there are other tutorials out there, so I was still able to figure it out. I fully intend to go through the tutorial once it becomes available.
I suppose it shouldn't be too much of a surprise, but I've found a lot of indication that information radiators are an important part of Continuous Integration environments. It kinda validates the potential of my team's project. I imagine the ambient devices group felt the same way.
I am also pleased to know that my often-ridiculed habit of checking in multiple times per day is actually a good thing. I haven't been quite as on it recently as I should be (partly because I've been giving in a bit to the faintly critical comments of co-workers and classmates from previous semesters) but now I know how to tell them where to shove it. I code in small tasks - now I just have to code MORE tasks!
Anyway, Hudson is a very handy system that seems to run very well in the short time I've had to work with it. I don't want to get caught with my pants down right before it explodes, but as of now I don't see why Professor Johnson would have to do anything more than create a new project at http://informative-workspace.googlecode.com/svn/trunk, and schedule a daily build. Well, that and selecting Ant and specifying build.xml, but yeah - nothing special in other words.
I suppose it shouldn't be too much of a surprise, but I've found a lot of indication that information radiators are an important part of Continuous Integration environments. It kinda validates the potential of my team's project. I imagine the ambient devices group felt the same way.
I am also pleased to know that my often-ridiculed habit of checking in multiple times per day is actually a good thing. I haven't been quite as on it recently as I should be (partly because I've been giving in a bit to the faintly critical comments of co-workers and classmates from previous semesters) but now I know how to tell them where to shove it. I code in small tasks - now I just have to code MORE tasks!
Anyway, Hudson is a very handy system that seems to run very well in the short time I've had to work with it. I don't want to get caught with my pants down right before it explodes, but as of now I don't see why Professor Johnson would have to do anything more than create a new project at http://informative-workspace.googlecode.com/svn/trunk, and schedule a daily build. Well, that and selecting Ant and specifying build.xml, but yeah - nothing special in other words.
Wednesday, March 12, 2008
Visual Studio Sensor Code Review
My first comment would be that the name of the project is slightly misleading - it should be Visual Studio 2008 Sensor ;^P
In all seriousness though, I was warned in the overview on Monday that I would need 2008. There was a little bit of confusion, because I knew I was using vc8, which I thought was 2008 (I don't know why I never thought about the fact that I've been using it for 2 years). But 2008 is actually vc9. So I had to do an emergency last minute download of the 3.3 Gig cd and go through the hour long install process on Tuesday evening. Considering the difficulty of getting ahold of visual studio and the incredible size of the software, I consider this to be a weakness.
That is not to say I'm criticizing the choice of visual studio. Jared and Kayee are not asking people to install visual studio to use their product, they are providing a product for people who use visual studio. The criticism is that it requires 2008, when nothing I've seen seems to indicate that it's using any exclusive features of 2008 (correct me if I'm wrong). This will dramatically cut the user base of the sensor, as I'm sure many people will not have the patience or interest to upgrade to 2008 just to use the sensor.
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|
So considering I only had a couple hours to work on it before class this morning, I must say, the system is very easy to set up. The only snag, was that the wiki page tells the user to download the msi file from the downloads page, when in fact you need to download the zip, open the solution file, build the project, and then run the msi file. This was not a problem because they mentioned this in class on Monday, but it could confuse someone new to the project and the wiki page should give accurate instructions.
I love how the team has a fancy installer to take care of everything. But the default instalation directory tries to create a folder that has commas and spaces... I dunno if that's horribly wrong, but it feels horribly wrong. I know Microsoft broke with convention to have spaces, but does the use of commas break some sort of convention?
It was very easy to get going, either way, and impossible to break in the time I've had to use it.
In all seriousness though, I was warned in the overview on Monday that I would need 2008. There was a little bit of confusion, because I knew I was using vc8, which I thought was 2008 (I don't know why I never thought about the fact that I've been using it for 2 years). But 2008 is actually vc9. So I had to do an emergency last minute download of the 3.3 Gig cd and go through the hour long install process on Tuesday evening. Considering the difficulty of getting ahold of visual studio and the incredible size of the software, I consider this to be a weakness.
That is not to say I'm criticizing the choice of visual studio. Jared and Kayee are not asking people to install visual studio to use their product, they are providing a product for people who use visual studio. The criticism is that it requires 2008, when nothing I've seen seems to indicate that it's using any exclusive features of 2008 (correct me if I'm wrong). This will dramatically cut the user base of the sensor, as I'm sure many people will not have the patience or interest to upgrade to 2008 just to use the sensor.
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|
So considering I only had a couple hours to work on it before class this morning, I must say, the system is very easy to set up. The only snag, was that the wiki page tells the user to download the msi file from the downloads page, when in fact you need to download the zip, open the solution file, build the project, and then run the msi file. This was not a problem because they mentioned this in class on Monday, but it could confuse someone new to the project and the wiki page should give accurate instructions.
I love how the team has a fancy installer to take care of everything. But the default instalation directory tries to create a folder that has commas and spaces... I dunno if that's horribly wrong, but it feels horribly wrong. I know Microsoft broke with convention to have spaces, but does the use of commas break some sort of convention?
It was very easy to get going, either way, and impossible to break in the time I've had to use it.
Wednesday, March 5, 2008
Ambient Hacky Code Review
Verify works for me except for a fail in JUnit at TestCommitTrigger. It took a lot of environment variable setting that wasn't specified in the tutorial section, but more on that in the problem section.
I set the color to DISCO and the animation to CRESCENDO. It did take, however, 20 minutes to change!! I'm not sure how that's going to go down in class.
I like the flexibility of the trigger action language in that you can set multiple triggers and multiple actions in the same block. It would be cool if there were a reference of available trigger types and what string to use in the configuration file. Also, for testing purposes, it seems awkward to set a trigger for some event instead of being able to change the color directly.
5 Biggest problems:
-Java Build path in the eclipse settings are not fixed yet. Perhaps the review version was locked before the presentation?
-configuration.example.xml has many inconsistencies that make it more difficult than it should be to learn how everything works. Comparison is mis-spelled at "comparation", which is easy to look over, so if not copying and pasting, the correct spelling is a typo. Also there are multiple values being used and I couldn't tell if only one or both of them were correct (FAIL/FAILURE, SUCCESS/PASS).
These appear small, but are amplified by the fact that one must wait up to 20minutes to an hour to determine if there's an error. Anything that might be wrong should not have to wait until the color changes to be confirmed.
-In the wiki pages, there is a tutorial page that discusses the environment variables needed to make this work. Nowhere in that page is any mention of Restlet, GWT, SCLC, Derby, or the hackystat server paths. Forcing a tester to run verify over and over again to find out which next one needs to be set.
-The list of triggers in the wiki pages does not include the list of triggers available to use in the trigger-action language. Nor is there a reference tool for colors and animations available, and no example on how to get animations to work.
-The length of time it takes for the color of the orb to change is not the fault of the ambient devices team. However, they should give warnings and be very clear on how to initiate it to prevent confusion. Running the jar file as instructed will make the system loop over and over, during which time I was left wondering if I have to force quit it and run a build to set a trigger, or if force quitting it would reset the system and I'd have to start all over again.
I set the color to DISCO and the animation to CRESCENDO. It did take, however, 20 minutes to change!! I'm not sure how that's going to go down in class.
I like the flexibility of the trigger action language in that you can set multiple triggers and multiple actions in the same block. It would be cool if there were a reference of available trigger types and what string to use in the configuration file. Also, for testing purposes, it seems awkward to set a trigger for some event instead of being able to change the color directly.
5 Biggest problems:
-Java Build path in the eclipse settings are not fixed yet. Perhaps the review version was locked before the presentation?
-configuration.example.xml has many inconsistencies that make it more difficult than it should be to learn how everything works. Comparison is mis-spelled at "comparation", which is easy to look over, so if not copying and pasting, the correct spelling is a typo. Also there are multiple values being used and I couldn't tell if only one or both of them were correct (FAIL/FAILURE, SUCCESS/PASS).
These appear small, but are amplified by the fact that one must wait up to 20minutes to an hour to determine if there's an error. Anything that might be wrong should not have to wait until the color changes to be confirmed.
-In the wiki pages, there is a tutorial page that discusses the environment variables needed to make this work. Nowhere in that page is any mention of Restlet, GWT, SCLC, Derby, or the hackystat server paths. Forcing a tester to run verify over and over again to find out which next one needs to be set.
-The list of triggers in the wiki pages does not include the list of triggers available to use in the trigger-action language. Nor is there a reference tool for colors and animations available, and no example on how to get animations to work.
-The length of time it takes for the color of the orb to change is not the fault of the ambient devices team. However, they should give warnings and be very clear on how to initiate it to prevent confusion. Running the jar file as instructed will make the system loop over and over, during which time I was left wondering if I have to force quit it and run a build to set a trigger, or if force quitting it would reset the system and I'd have to start all over again.
Monday, February 25, 2008
07. REST
I gotta admit, I feel like I was clueless about http until I heard about REST. I wonder why it took so long...
Anyway, our projects in 414 absolutely should use REST. Everything that gets put on the internet should use REST, or there's really no point in putting it on the internet. The projects would still be technically accessible without it, but finding the application would be harder; also, following REST makes it easier for anyone to get just what they want out of an application without jumping through as many hoops. REST was designed to be a common interface, it's responsible for the internet's existence, it certainly ought to be used.
That being said... does the SensorBase REST API follow REST format? Well I'm assuming the question refers to the single web-page of words that the assignment links to. At first it appeared not, because it's just a single page that displays formatted words and there's nothing to do to it. But then I realized you can certainly GET it... but that's everything on the web. Then I started to think how utterly ironic it would be for a REST API to not be RESTful and how unlikely it is that Johnson would let that happen. It's an architectural question and this page is too simple to really understand the architecture of - but it's in the google wiki, which is assuredly RESTful and that pretty much settles it. (despite my less-than-complete understanding)
The project viewer is much less ambiguous - it absolutely does follow REST. The url is the resource of the actual project viewer and that information can be accessed by verbs largely hidden from the user. This same url is used for every member of the class, but the verbs being used on it are different. (Well, the verbs are the same too, but the direct objects are different)
Anyway, our projects in 414 absolutely should use REST. Everything that gets put on the internet should use REST, or there's really no point in putting it on the internet. The projects would still be technically accessible without it, but finding the application would be harder; also, following REST makes it easier for anyone to get just what they want out of an application without jumping through as many hoops. REST was designed to be a common interface, it's responsible for the internet's existence, it certainly ought to be used.
That being said... does the SensorBase REST API follow REST format? Well I'm assuming the question refers to the single web-page of words that the assignment links to. At first it appeared not, because it's just a single page that displays formatted words and there's nothing to do to it. But then I realized you can certainly GET it... but that's everything on the web. Then I started to think how utterly ironic it would be for a REST API to not be RESTful and how unlikely it is that Johnson would let that happen. It's an architectural question and this page is too simple to really understand the architecture of - but it's in the google wiki, which is assuredly RESTful and that pretty much settles it. (despite my less-than-complete understanding)
The project viewer is much less ambiguous - it absolutely does follow REST. The url is the resource of the actual project viewer and that information can be accessed by verbs largely hidden from the user. This same url is used for every member of the class, but the verbs being used on it are different. (Well, the verbs are the same too, but the direct objects are different)
Tuesday, February 12, 2008
04. Hackystat
Ok, so I should have just posted on what I did get done Monday morning - but I wanted to actually finish it first.
I didn't have any time over the weekend, but I thought it would only take an hour or two to set up the sensors and poke around. I had a hang up in the beginning with connecting to the sensor base, but that cleared itself up after trying again this evening. The whole process actually took a lot longer than I expected, first because Hackystat is much more than I realized and second because "Ant sensors" isn't just a sensor for Ant, it's a set of sensors for several tertiary programs that I needed to set up. Bleh, lesson learned.
As for the prime directives, Hackystat most definitely serves a useful task - I can't wait to get enough data to start messing with it. It's hard to tell so far if the system is easily expandable for developers because I haven't delved into the code. The wiki page is a good by-developers-for-developers summary so it would seem that it's doing a good job on that end. However, the wiki doesn't seem very well geared toward user-friendly installation (or rather, the wiki explains a very user-unfriendly situation); but the software itself is more user-friendly than I anticipated. So it's hard to say if my first impressions are any good judge of the second two prime directives.
I also realized that Hackystat suffers from the same challenge that the IW project suffers from in that it's dang near impossible to make set up easy without making it a closed system.
I didn't have any time over the weekend, but I thought it would only take an hour or two to set up the sensors and poke around. I had a hang up in the beginning with connecting to the sensor base, but that cleared itself up after trying again this evening. The whole process actually took a lot longer than I expected, first because Hackystat is much more than I realized and second because "Ant sensors" isn't just a sensor for Ant, it's a set of sensors for several tertiary programs that I needed to set up. Bleh, lesson learned.
As for the prime directives, Hackystat most definitely serves a useful task - I can't wait to get enough data to start messing with it. It's hard to tell so far if the system is easily expandable for developers because I haven't delved into the code. The wiki page is a good by-developers-for-developers summary so it would seem that it's doing a good job on that end. However, the wiki doesn't seem very well geared toward user-friendly installation (or rather, the wiki explains a very user-unfriendly situation); but the software itself is more user-friendly than I anticipated. So it's hard to say if my first impressions are any good judge of the second two prime directives.
I also realized that Hackystat suffers from the same challenge that the IW project suffers from in that it's dang near impossible to make set up easy without making it a closed system.
Subscribe to:
Posts (Atom)
