And So It Ends...

As we continue removing more and more unneeded divs, my goal for this week was to "complete" the profile page and continue to another if given the chance.

After my theme being rejected, I decided to use more realistic clouds for a background and change the colors of the widgets to green to give the page a more "natural, yet playful" feel. I'm not sure how this will roll with the group, but my friends say it looks okay. Once this was done, I learned that Twitter Boostrap contains a class that modifies table tags and makes them nicely responsive. However, it adds a weird hover action that might not work with mobile devices since you can't exactly "hover" with a mobile device. Here is my "final" result in both full and mobile size:

I had some extra time so I decided to move on to the help page. I was curious on making videos responsive so I decided to tackle that challenge. It after searching for a few tutorials, I found some code that I decided to use (and gave credit to) in my .less file. It works very nicely and the YouTube video actually responds to the change in the size of the screen. Also, I found out that YouTube has an opt-in trial to turn all YouTube flash videos to html5 videos by opting in here. Once opt in, all YouTube videos. Like the profile page, I removed other unnecessary div tags, which was fairly simple since I already knew what to look for. Here is my "final" result in both full and mobile size:

I will continue working through the weekend. My goals for the weekend will be to get it looking nice in a tablet size and fix the badge images in the profile page to make them respond nicely as well.

So Many Divs @__@

No one really likes to clean, especially when it comes to cleaning up code that seems like a child came him and started mashing on the space bar and the return key. However, when it's done, modifications and changes can be done much quicker. The goal for this week was to remove as many unnecessary <div> tags from the html as possible. This would reduce the amount of lines in the file as well as make the file look cleaner. Another part of this task required removing necessary "id" properties in the <div> tags that had to be there. In the beginning, I thought this would be a relatively simple task, however it was full of headaches just like every other task is.

For this task, I chose to clean up the Profile page from the Kukui Cup Website. Removing the extra tags proved to be pretty simple. However, this meant that indentation would be off. After removing as many extra <div> tags that I could find, I had to go back and fix the indentation of the lines of code that remained. This took a few hours and by the end, my head was spinning.

I had some extra time on my hands, so I continued to rework the page because the way the information was being displayed in the widget boxes was ugly. The widgets contained data pulled from a back end, so I had to create my own information for the sake of making the page look as it would with some information. Currently, at the full version, the information is displayed nicely, even though it covers multiple lines. However, when it gets to the mobile size, it looks a bit funny. This is mostly because the widths I am using for the table columns are fixed (I know  I'm not supposed to, but I needed some kind of idea of how long "100%" would be when determining the size of the table). I plan to fix the tables in the next couple of days to insure that they respond nicely, but for now, I'm more worried about the overall source code so that these changes can be made quicker.

Back to Responsiveness

Sorry for being MIA for a week. It was spring break and we were given a nice short vacation, but now it's back to work. This week was used to begin working on more of the Kukui Cup pages and making them responsive, and making them use our LESS file instead of the old and clunky screen.css.

For this task, I am currently working on the Profile page. Using the Twitter Bootstrap framework, I was able to get the page to be responsive, however, in my opinion, it does not look visually appealing yet. I set my page up similar to those of the tutorials we watched about Twitter Bootstrap using a 2-column layout and putting each widget into rows. It works, however the huge gap between the "My Badges" widget and the "My Achievements" widget throws the page slightly out of proportion. Also, I personally don't like how the widgets touch the edge of the page. Even though we're losing pixels, I personally feel that adding a small (maybe 10px) padding to each side would make the page look much better. The only problem might be the loss of pixels when viewing on a mobile device. Our group will meet soon to determine the fate of that padding, but for now, the most important thing is making the page respond nicely.

Another thing I've been working on, is trying to find a nice editor for LESS files. So far, no luck. I did manage to find one that is built on Eclipse's XText plugin, but it doesn' work. Even after fighting with it for an hour or so, no luck. If any other suggestions are out there, I would greatly appreciate it.

Not a lot of drastic changes have been made this week. I had a huge project due for another class so a large amount of time was spent considering a different layout. It still seems a little too plain in my opinion, but that is a topic for another time.

Doing More with LESS

This week was dedicated to working with LESS and working with making the Kukui Cup page responsive using the Twitter Bootstrap framework. After some reading and tutorial videos I felt like I was ready to take a stab at implementing them both into the Kukui Cup page. However, it wasn't with its own challenges.

Working with Twitter Bootstrap was actually not too bad. It was similar to using the Skeleton structure we tried using a few weeks ago, but a little more straight forward with the class names and exactly what they did. It came with a nice class that allowed divs to be put into rows as well as a 12-column system that allows divs to put into 12 even columns or other versions of it (ie. 3 columns of width 4, 2 columns of width 6, etc.). It seemed easy, until actually inserting the div tags around already existing divs. With a page already having a few dozen div tags, it was quite simple to find the opening div I wanted to surround, but finding the corresponding closing div was a task that took some time. Now that a few of the simpler pages are done (ie. news and profile) its time work on the others like 'activity' that contain fixed with width objects.

As for LESS, as expected it was WORLDS simpler than having to re-enter the same css code or having a semantically bad css file that is hard to read. LESS allowed me to save things like color and paths to pictures in variables to reuse them later in other lines of the code. This saved a lot of time since I wouldn't have to go back and search through what color I used or look up what color that hex or RGBA code was. There are still some problems however. When I try loading the page in Google Chrome, the less.js file throws an error and I am not sure how to fix it. I will be looking into it more over the next few days so that the file will work well in all browsers (or well, maybe not Internet Explorer).

Time to Bootstrap in!

After weeks of redesigning, we're finally moving on to the next step of redesigning the Kukui Cup website. We are now in the step of using Bootstrap, a simple HTML5, CSS3, and JavaScript structure from Twitter to make the site responsive. After watch watching a bunch of excellent tutorials (found here), Bootstrap seems so much easier to use than the previous frameworks that we have tested.

So far, all I have done is set up a local file structure to prepare to incorporate the new Kukui Cup website with Bootstrap. I am quite excited to begin work using Bootstrap as it seems WORLDS easier than a lot of other frameworks.

In addition to Bootstrap, I have started looking into "less" and good gravy is this going to make my life SO much easier. Sometimes, less is more and in this case it is more and will save me (and the rest of the group) a lot of headache in refactoring CSS files. Less allows us to declare "variables" and save things like colors to them. This will save us from hours of headaches in figuring what color is what and the overall semantics of the CSS file. Finally, some programming-ish features in website design.   

Narrowing Down the Palettes

This week, with the help of my coworker, I searched user-made color palettes on a site called Colour Lovers. It is a site where users create and share their own color palettes and where others (such as myself) can use them. For my updated theme for the Kukui cup site, I chose to work with the "w o r d l e s s . " theme that matches white, green, black, and beige together nicely. Through the process, I developed what I think is a nice layout, however, I am currently having problems designing a background that would match the layout. I found out quickly that using a preexisting image would be difficult as these colors are very light and pastel and would not work very nicely with the bright colors of a still shot image.

Because the Kukui Cup is about energy conservation, I want my theme to have a very "natural" feeling using greens and browns to enhance the experience. This is easier said than done. I've been spending hours looking up similar layouts to no prevail and even just going at it at designing my own. I've come up with a couple ideas that seem to work okay, but do not really match in my opinion. I feel like something is always missing. Below are some of the backgrounds I have been messing with; all designed from scratch or a preexisting image by me. The ones that look kind of weird affect the color of the container so to give it a "softer" look.

A Crash Course in Graphic Design

We're still currently working on creating a new "look and feel" aspect to the current Kukui Cup website and frankly, its been quite rough. For this entire week, I've been basically tackling various things head-on. For the Kukui Cup, I've been working on finding a color pallet that would work for the page, as well as designing a background that would be able to be nicely responsive, as well as match the overall theme of the page. Honestly, props to those who do this professionally because they must have a really good eye for color, images, and sizing of things. I was only able to create one theme this week because of all the craziness going on with my other classes. 

Although, I've been taking short notes on color pallets based on things I see elsewhere like stores, other websites, mobile, apps, etc. for colors that would seem to have a "natural" feel. The only problem now is actually implementing them into the website and making it aesthetically pleasing. This coming weekend is a long weekend, which means I'll have an extra day to work on a couple other color schemes. The hardest part seems to be finding a nice background that would match the widget-like layout of the pages. 

I'm In Control

Just like last week, we took another half-step back in the redesign of the Kukui Cup page. This, time we worked primarily on redesigning the back-end framework by ideally making it easier to make changes to all the pages at once by setting up "global" CSS files that would affect the all the pages when changed. At the same time, the plan was to also separate the "local" CSS files. This was a lot easier said, than done.

At the start of the week, I was able to more or less separate the "about" page's CSS file and originally thought that was a great idea. However, after continuing working on the others, I just confused my self and ended up starting over (which lead to much more headaches). In the end, it kind of worked out, but I feel like the theme files (which are still currently still the screen CSS file), could be broken down farther into smaller, more manageable files that would eventually lead to a smaller margin of error when making changes to the page. More could have been done, but it is midterm time and lots of stuff are going on at the same time. However, I've committed an equal amount of time to working on making sure this file structure will be as efficient as possible to prevent (or limit) bumps in the road later because of a bad file structure. I also did not have time to start looking into more color palettes (outside of the one used in the mockup from last week), but I do have some ideas in mind that I'm hoping to mess around with within the next couple of days.

Kukui Cup Redsign Challenges

So we've hit a bump on the road to redesigning the Kukui Cup Page. Its basically a "one step forward, two steps back" kind of deal. Last week, we had a crash course in responsive web design and more or less got a working page that nicely responds to the browser size, however the aesthetics of the page were horrendous. The white background and the neutral colored widget boxes made the site look bland and overall, boring. Because of this, production of the actual responsiveness to the page has come to a stop, and an overall redesign of the page aesthetics has begun.

Each of us were responsible to submit our own mockups as to what we felt the Kukui Cup page should look like. For my design, picking out a new color palette was the hardest part. The process of finding contrary colors that had a "natural, earthy" feel to it was quite difficult without running into a puke colored green or a poop colored brown. I personally have only dabbed into webdesign and graphic arts, and along with working with a graphic arts major a few years back, I learned quite a bit about Adobe Photoshop and was able to use that to create my mockup. My inspiration for my design was to keep it organized, making especially the navigation bar seem like it was one in the same with the page, by having it be part of the overall layout and not have it in it's own box floating around in space somewhere. However, with my new concept, comes new challenges. A lot of images are involved including the "tabbed" navigation bar. Making all of those responsive may be a bit of a challenge since we haven't got a working fluid image yet, but it is definitely doable.

Overall, the page came out to nearly what I wanted it, and modifications can always be made. If I can somehow get a hold of my old coworker and talk to him about color schemes that would help a lot since not many (if any) of us know anything about graphic design. If not, research about contrary colors would have to be done and I'm not sure how successful that would be. Here is what the page looked like after the first redesign.

However, after meeting with the group, and learning new constraint, especially how the "Quest" bar worked, changes to the left side bar had to be changed because a lot of text would be displayed when the "Quest" bar is used. After some redesign the page looks like this.

Kukui Cup Responsive UI Week 2

We are currently into the second week of working on the project for the Kukui Cup and a lot of things have happened. Let's see, where to start off. Well, first of all, I switched groups. I am now part of the Makahiki-rui group that consists of three members plus myself. The group seems to have a much better communication and everyone is giving their best to contribute. Because of the change, it took me some time to figure out the group's code structure. After reading through code, it was actually quite simple, however I wasn't really sold on the use of a fluid grid.

Secondly, after having our previous site reviewed, the responsiveness worked, however, the page was aesthetically unappealing. Because of this, lately, we have been talking about possible designs for the page as well as possible color schemes to implement. At the same time, we have also looked into possible frameworks. We chose to try the skeleton framework as it was the easiest to read. However, actually implementing it into the current site was difficult. In the end, adding ID properties to already existing css files proved to be the most efficient for now.

As of now, we are considering using a color scheme similar to that of the movie and game, Tron. A dark background with an electric color scheme. The desktop layout will be similar to the currently existing one, the tablet layout will be similar to a video game where buttons will be at the bottom and a built in "screen" will be fixed in the center of the page and will show information. The mobile aspect will be similar to the current facebook mobile application. A simple large print interface with a menu tab that pops out offering the user options to go to other pages. It is still a working progress and learning how to do some of these things will be another future challenge for the group.

Because we are in the process of figuring out a layout, the responsiveness of the page is limited to just familiarizing ourselves and getting comfortable with CSS3 and HTML5. Once we have an agreement on a new site layout and have a working nonresponsive site up and running, making the page responsive should be easy. In theory anyway.

Attempt at Responsive Web Design

This week, our group made an attempt at redesigning an already existing webpage into a responsive one. For this experience, we chose to redesign the "news" section of the site as it was already shown to be in two columns. Our goal was to simply make the second column move under the first column once the page was resized. Then after tons of research, we decided to use the Skeleton framework as the source was the most organized and was easy for us to read.

Once we understood the examples provided, we began experimenting. Miraculously, after inserting a new <div> tag around the "2nd column", and calling the appropriate class from the skeleton.css file, it magically appropriately moved under the "1st column" after the screen was minimized. This is because the css files recognizes the screen size and allows the change to happen. This got us thinking about how to start making the other items on the page responsive, but since a lot of it are jqueries, it is quite difficult and requires slightly more research.

The Future of Website Design

Smartphones and tablet PCs are exponentially growing in numbers in the computing market. These days, people can literally carry a computer in their pocket or in their bag. However, to compensate for convenience, the size of the screens being used must be sacrificed to often times just slightly larger than a credit card. So how do we adjust for this? Mutlitouch compatibility introduced pinch to zoom and that made it slightly easier. It allowed users to zoom in to what would be tiny text then scroll around the page to read the material. This worked for a while (and is still in use in a lot of website) but can be frustrating to those who use smartphones and/or tablets to read regularly. So this is where HTML5, CSS3, and responsive web design come into play.

HTML5 is the next generation of HTML (Hypertext Markup Language) that allows developers to incorporate media objects such as video and sound without the use of a flash player. CSS3 is the next generation of CSS (Cascading Style Sheet) that allows the customization of objects through CSS, something that was also done through the use flash at most times. So basically these two things are replacing flash. And why replace flash? From what I understand, because flash is technically a third party application, it continues draining battery on the mobile device much faster than if the page were to simply render the HTML and CSS codes and nobody likes carrying around a dead mobile device. The combination of HTML5 and CSS3 allow web developers to create responsive websites that are easily read on any device rather it be on a 24" desktop monitor or a 4" smartphone screen. Below are some links to the various topics mentioned. Some give very distinct examples, some offer API information, and others are simply a more detailed explanation of the topic.


Links to helpful HTML5 pages
http://www.w3schools.com/html5/default.asp
http://www.switched.com/2010/05/11/what-is-html5-and-why-should-you-care/
http://msdn.microsoft.com/en-us/ie/aa740476
http://www.inmotionhosting.com/infographics/html5-cheat-sheet/
http://www.apple.com/html5/

Links to helpful CSS3 pages
http://www.w3schools.com/css3/default.asp
http://webdesign.about.com/od/css3/a/differences-css2-css3.htm
http://coding.smashingmagazine.com/2009/07/13/css-3-cheat-sheet-pdf/
http://css3generator.com/

Links to helpful responsive web design pages
http://ux.fusionapps.com/2011/12/23/what-is-responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
http://msdn.microsoft.com/en-us/magazine/hh653584.aspx

Modification of Hale-Aloha-CLI-TNT

Remember the Hale-Aloha-cli project from a few weeks ago? (if not, you can read about it in the earlier blogs). Well, for this part of the project our group (hale-aloha-cli-tiger) swapped codes with the hale-aloha-cli-tnt group in an attempt to modify and enhance each other's projects.

From the start, it took our group some time to even get started. The other group's code used reflection to link their command modules to the command processor while ours was simply hard coded. Because of this it took us a little while to figure out how reflection worked and how it processed the classes. Once we got and idea of how reflection worked, it was time to get started. 

Because of reflection, not changes had to be made to the group's command processor. The only thing we had to follow was their defined interface and how the processor processed the commands and their arguments. There were three commands we had to add to the existing code and because there was three people in our group, each of us were responsible for working on a single command each. The three additional commands were:

• set-baseline [tower | lounge] [date]
• This command defines [date] as a baseline for [tower | loung] and gets the power value for each of the 24 hours for [date]. Additionally [date] is an optional parameter and defaults to yesterday if not given.
• monitor-power [tower | lounge] [goal] [interval]
• This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds. Additionally [interval] is an optional parameter and defaults to 10 seconds if not given. The command is terminated by pressing any key on the keyboard.
• monitor-goal [tower | lounge] [goal] [interval]
• This command prints a timestamp and current power being consumed by [tower | lounge], and whether it is meeting its power conservation goal. [goal] is an integer between 1 and 99 and defines the percentage reduction from the baseline for this [tower | lounge]. This command also will not work unless the set-baseline command was previously called.

For this modification, I was responsible for the set-baseline [tower | lounge] [date] command. This command was very similar to some of the commands from the first part of this project and a lot of lines of code were reused. I had difficulty with the timestamps at first and the code kept returning 0.0 kWh. After a few hours of debugging and asking group members for help, I was able to get the command working fairly quickly and have be accessible to the monitor-goal command. Overall, the quality of my personal additional command is okay compared to the other commands implemented. I was overall more impressed by the reflection used in the command processor.

As a group we were able to complete all the additional tasks. The only problem we ran into was stopping the monitor-power command using any key. We were able to get it to stop while using the return/enter key, but not when any other key is pressed. The command, however, still prints out the required information. As for the other two additional commands, we were able to get them fully functional based on our understanding of the requirements.

In terms of the Three Prime Directives of Software Engineering: 

• Does the system accomplish a task?
• Can an external user successfully install and use the system?
• Can an external developer successfully understand and enhance the system?

The hale-aloha-cli-tnt application fulfills them all excellently. The system does indeed accomplish the task of querying the WattDepot server and returning various forms of data. An external user (in this case our group) was easily able to install and get the project working on our local systems. External developers (our group) was able to successfully understand and enhance the system. Even though we were not able to meet all of the requirements for the additional commands, we were able to add a semi-working command to the application.

Taking over a preexisting code is a pretty rough task. If the original code is unstructured, contains few comments, and/or is hard to read, modifying it becomes very difficult as a lot of time is spent trying to figure out how the code works. Our group was lucky enough to enhance code that was structured extremely well and provided a very strong base for additional modifications. I learned a lot from taking over this project and will use this experience in the future to make sure that any code I work out either alone or in a group is made as simple as possible so that an external developer can simply make modifications.

Review of hale-aloha-cli-tnt

The three prime directives should be looked at whenever you try to review a code. The three prime directives are:

• Does the system accomplish a task?
• Can an external user successfully install and use the system?
• Can an external developer successfully understand and enhance the system?

We can use these directives to review how user friendly the code is to both the end user as well as an external developer.

For this project assignment we were to, as a group, create a system that accesses data from the WattDepot server for the Hale Aloha dormitories at the University of Hawaii at Manoa. The system would be a command line interface system that does the following:

• Gets the current power for a tower or a lounge
• Gets the daily energy for a tower or a lounge for a given date
• Gets the total energy for a tower or a lounge from a given date until now
• Ranks the Towers by energy consumption between two given dates

In addition to these commands, we were to design the system in a way where additional commands may be added later.

            For this review, I took a look at the hale-aloha-cli-tnt system. It is a command line interface based system that makes use of the WattDepot server to gather information.

So what is WattDepot? If you haven’t read my earlier blogs, then here is a brief summary of WattDepot is. WattDepot is an open source, RESTful web service that collects electricity data (such as power and energy). For more information, check out this link.

Let’s review the system using the Three Prime Directives.

Does the system accomplish a useful task?

            The overall functionality of this application meets all the basic things that were required. The project is able to successfully retrieve the current power of a tower/lounge, get the energy for a tower/lounge from a specific date after 22 November to the current date, get the energy usage for a tower between two given dates as long as the were after 22 November, and finally give a sorted order from least to most between two dates as long as the dates were after 22 November. The reason the dates had to be after 22 November is because the server failed around that time and the only accessible data is from after 22 November.

Can an external user successfully install and use the system?

            The homepage contains very precise information about what the system does, however the sample input and output is located in a User Guide wiki page. Like mentioned earlier, the User Guide wiki page contains a sample input and output for the system along with simple instructions on running the system. In the download page, the group offers the option to download an executable jar file for those simply wishing to run the application. In addition to this, they also offer an executable jar file along with their source files so that the external users do not need to compile the system first before executing it. The distribution file contains a version number along with a timestamp for external users to monitor any changes and how long ago the changes took place.

            In terms of testing, both valid and invalid commands were used. The following are the commands and the type of output it gave:  “help”

·      “help”

o  Gives the proper output.

·      “current-power Lehua”

o   Gives the proper output of Lehua’s power.

·      “current-power lehua”

o   Gives a bad syntax error showing that it is case sensitive

·      “Current-power Lehua”

o   Gives a bad command error showing that the command checker is also case sensitive

·      “daily-energy Lehua 2011-11-23”

o   Gave the proper output of Lehua’s daily energy

·      “daily-energy Lehua 2012-11-23”

o   Gives a bad date error.

·      “daily-energy Lehua 11-23-11”

o   Gives a bad syntax error showing that the date must be properly formatted

·      “daily-energy Lehua 11-23-2011”

o   Gives a bad syntax error that there is only one way to write the date.

·      “daily-energy Lehua 2011-10-21”

o   Gives a date error showing that the date should be after 22 November.

·      “energy-since Lehua 2011-11-23”

o   Gives the proper output of the amount of energy used in Lehua since 23 November

·      “energy-since Lehua 2011-12-25”

o   Gives a date error

·      “rank-towers 2011-11-23 2011-11-25”

o   Gives the proper output rating the towers from least to most.

·      “rank-towers 2011-11-25 2011-11-23”

o   Gives both a date error and a bad syntax error showing that it recognizes that the start date is after the end date.

·      “quit”

o   quietly closed the application

Overall, the system does very well and is very useful. The system did not crash when providing bad inputs and it provided correct and useful outputs when providing valid commands.

Can an external developer successfully understand and enhance the system.

            The Developer’s Guide wiki page provides clear instructions on how to build the system once the sources are downloaded. Quality assurance is done automatically by running ant –f verify.build.xml that runs checkstyle, PMD, and findBugs. The wiki instructs the user to run this command first before any sort of additional modifications to the code to ensure the original code didn’t have any errors. In terms of coding standards, the wiki page mentions the eclipse format and provides a link to the xml document for users to use. The application wiki mentions that it follows issue driven project management and continuous integration. Continuous integration is a practice in where smaller pieces of code are verified for validation at smaller increments instead of at the end of construction. Often times, each integration is automatically verified (in our case using the “ant” tool) and assists the group find out who, when, and what broke the code if there is a build failure. Issue driven project management is a practice in which the over build is broken down into smaller issues, usually about two days worth of work. For this project, we submitted issues in Google Code and used that service to also monitor and add our issues. A link is provided to the continuous integration server to that is associated with the application. The only thing the Developer’s Guide is missing is how to construct the JavaDoc documentation. The information contained in the Developer’s Guide is very concise and doesn’t contain any useless information.

JavaDoc Review

            I was successfully able to create a JavaDoc documentation successfully. After reading through the various class documentations, the documentation shows that the entire application is linked together by the Processor class. The package names are named appropriately where the Main class is contained in a higher-level directory, the command processor is in a subdirectory of the main directory, and the various commands are also in a subdirectory of the main directory.

Build System Review

            Using the ant command “build.xml”, I was successfully able to build the system without any errors. The author(s) of each piece of the code are listed in the source code to allow external users to know who wrote each piece of code. In terms of coverage, after running JaCoCo, the project doesn’t have 100% coverage.  In some cases such as the Main, Processor, and InvalidArgumentException classes, the coverage is 0% mainly because test cases were not made for those classes. However, the sub-100% coverage is due to the fact that none of the test cases contain a case where the author asserts an invalid statement. The current set of test cases successfully tests the application pretty well for the valid inputs. However, because of the lack of test cases for invalid inputs, there is a slight chance that an external user may create an enhancement that calls throws some random exception and the external developer may have no idea why it is being called.

Coding Standards Review

            What I found to be really nice is that each of the command classes were formatted in the same way (because of the interface class). What I found to be very surprising at the same time was hardly any private methods were used. But this is okay since WattDepot provides a lot of the methods already. The only files I had small problems reading was the Main class and the CommandManager class. In the main class the only thing I had issues with was figuring out when the IOException would be thrown. Documentation on what would have thrown it would have been nice. The CommandManager class was beautifully written using some advanced Java techniques that I have not come across before and because of this I had some problems reading and had to take some time to do a bit of research on some of the things. This is was not a problem caused by the author.

Issues Page Review

            The issues page associated with this project makes it very clear on who worked on which part of the system. It seems that a different person worked on different classes in the system and because of this, if an external developer had any questions about the system, it would be very easy for them to contact the author(s) that worked on that piece of the system. In the group of three, it seems that two of the developers did more of the work. The other group member worked on a single command class, its test case, the Main class, and the Help class. Most of these classes were fairly short and it is clearly shown in the amount of issues posted by that author. However, I would give him a slight break, as he is an undergraduate student working with a two graduate students.

Continuous Integration Server Review

            The Jenkins continuous integration server shows the progress of failed and good builds. Other than at the very beginning of the project between build three and four where the time it took to fix the project was about a day and a half, all failed builds were fixed within an hour. Most were even fixed in as little as 10-15 minutes. As for commits that were associated with issues, less than nine out of ten of them were related to an existing issue.  However, the group was pretty close to having nine out of ten commits be associated with issues; approximately eight out of ten.

Conclusion

            Based on my review of the hale-aloha-cli-tnt system, I have come to the conclusion that an external developer could successfully understand and possibly enhance its features. Although some of things are slightly advanced for where we are, the enhancements would be relatively simple because the sources are very uniformly organized. The overall system works very well and I was not able to make it crash. The source codes are documented so that most users would be able to understand it, however I would like to have seen comments around some of the exceptions and the things they caught. The group did a very good job implementing it, as well as a very good job working as a group.