What I'll Take Away From This Class Is...

Like all things, it must come to an end eventually, and after a while we take a long look back and reminisce in the memories and experiences that we made and will never forget.

It sounds like a cliche of highschool but in college it happens every semester.

This semester I was fortunate enough to take the ICS413 software engineering class taught by Professor Johnson. A class and I know for sure I will take away a lot.

It was a interesting learning experience and has really given me a lot of insight into software engineering.

Overall the class was not overly hard, but still required some effort to do well in. The screencasts and reading were done at home and part of this inverted pedagogy as professor Johnson calls it. It allowed us to restructure our time in and out of class, allowing us to choose when to listen to a long lecture and instead in class either do an activity or get a pre-emptive start on the assignment at hand with the ability to ask questions early.

I thought it was unconventional for an ICS course but worked very well and I could definitely see it working in certain types of courses.

In terms on the ARCS model of teaching, which stands for Attention, Relevance, Confidence, and Satisfaction. I felt that the course structure and assignments fulfilled all of those foundations well. The variety of assignments were relevant to our interests and kept our attention, I can recall that the Robocode assignment was a very interesting idea and the class competition was an interesting day in class.

Upon finishing this course I do feel slightly more confident about my ability as an ICS student and more professionalism.

Rounding the Home Stretch: Greenometer v2

Greenometer v2 is finally here just in time to save you from Green$.

After our initial experiences with working in a larger group and creating our first web application, once again I have to commend our group members Kelvin Green and Edward Meyer. Both of them did an outstanding job in taking charge and adding a lot of functionaility to the overall system.

While our first project was very ambitious, we tried to tackle a lot more this time around adding a much functionality as we could and then finally adding some very nice finishing touches thanks to Kelvin' experience.

Overall this time around we worked a lot more as a group, each member was more hands on with the coding itself and adding functionality, although much of the harder code was once again accomplished by the more experienced members. But overall collaboration was up and everyone contribute a good amount of code, and while not coding was also around to answer each other's questions.

As an end result we are left with a very professional, in my opinion, looking site with a lot of functionality. We were able to implement five of the extra credit criteria and even went as far as added extra functionality that was not originally on the list.

I feel confident and proud in our overall package and am confident that it is truly something I can proudly display on a public site for others to use.

Eco-Depot Code Review

We are once again tasked with doing a code review. Each time we do this, we are hoping that it gets easier. This time we are reviewing a web application based on our Wattdepot clients. We will be using it in conjunction with wicket to develope page that users can use to determine when we can defer electrical usage.

Today I will be reviewing the Eco-Depot system.

My review can be found here.

The eco-depot system fulfills most of the basic requirements of the system. The quality of the code is good and is designed properly. The only part of the system that requires improvement is the testing and overall group process. Some members are doing a vastly greater amount of work than others. Suggesting that the project issue manager should be used to delegate tasks properly.

Wicket Good: Web App Development Using Wicket

No longer are we working in small pairs, but now we are a quartet of different people with different abilities. Will having a larger group with more responsibilities hinder our progress or will it be smooth sailing with that much knowledge on board. With our combined knowledge we are Greenometer!

After completing our Wattdepot clients last week, our group was paired up with another group forming our quartet and were assigned to create a web application that displays a table of carbon emissions for an requeste

d day. The table has a color code that will tell the user the carbon intensity of the grid at that hour to help them decide how to better manage their electrical usage.

One of the first things we did have was two group members clearly taking charge. Having a project manager to keep the work delegated and in track was very useful. Each part of the overall project was able to be laid out and each member was assigned a task base on their ability.

Those with more understanding of how to build a Wicket application did most of the development of the web app. While those who were more unfam

iliar were assigned to doing more menial tasks like gathering test data and documentation while looking at the development of the application to get a good understanding of wicket.

With one of our more knowledgeable members, Kelvin Green, we took an ambitious route and did more than the basic specifications. We took it up a level to add a better visual representation of the sampled data to give users a graphical layout of the data rather than a simple table format. One downside to this layout was that it is difficult to users to view the actual numbers from the sampled data.

Overall I believed we worked well together. Members were there to keep each other in check, and although we had varying schedules and were unable to meet face to face, the quick relay through email and online instant messaging was an acceptable substitute.

Here is a view of our HackyStats ICU data.

Many of the ares are pretty good. I would say it is an overall healthy system. We had a mild start with some development time and builds, but it really got going over the weekend which is expected for students.

Big Brother is Watching: WattDepot v2 & Software ICU

In this assignment we were tasked with writing the commands of a command line interface for the WattDepot client. We were paired up with a partner and given our first real software engineering task.

In the second version of this assignment, three new command specifications were added to an updated WattDepot client and we were again working with our partner. The only difference this time was that we were being watched. Using hackystat, our project branch's health was continually being monitored for commits, coverage, work by each member, etc.

This pushed everyone a step further since you couldn't slack off and complete the assignment the night before it was due anymore. But it was also a very useful tool for monitoring your progress throughout the assignment. I had found myself

going to the hackystat project browser to check on our statistics every now and then to see the improvement.

What started off as a minimally functioning system, we designed into a well organized implementation that addressed much of the issue if not the only issues for our previous designs from the reviews. We separated methods that w

ere stored in one class and added many test cases to raise our coverage of the system. We had been lacking any test cases from our initial implementation and have now raise it to around 62% line coverage at around 80% class coverage. Though we chose to have a well designed system with good coverage over completing the three new command specifications. We were only able to complete two out of the three.

I believe this time around the group dynamic was a lot better. We had much more communication between each other, and I believe although we did not finish, we accomplished more than our initial implementation. We were not able to meet regularly, but through online contact we were able to discussion implementation and delegate tasks efficiently.

Here are some comparisons of our progress using the ICU.

Before

After

It could use a bit more work, but there is a huge improvement. Overall I believe it is a pretty healthy project with commits from both sides and improving coverage.

Using our project, we are required to answer the follow questions. We will be doing 4 out of 6 questions because we were unable to complete the last command.

Here are the questions we will be answering:

1. What day and time during the month was Oahu energy usage at its highest? How many MW was this?

2. What day and time during the month was Oahu energy usage at its lowest? How many MW was this?

3. What day during the month did Oahu consume the most energy? How many MWh was this?

4. What day during the month did Oahu consume the least energy? How many MWh was this?

Answers: To be completed when I figure it out, math and problem solving aren't my strong point.

And The Results Are In: Wattdepot Review

I just finished reading the reviews of my groups Wattdepot project and I have to say I am pleasantly surprised. They were mostly all positive. One the exception of course of our group not having any real test cases so that was one thing that everyone commented on.

I believe that the better your system is the easier it is and yet the harder it is the review. When I looked at the reviews for my group's system, many of them were a short and precise: This system works, the described checklist item works and is in order. But from my experience when it is good, it is harder to break or find something for the group to improve on.

One of the strategies I tried during the review, since we had to review two systems, was first trying to break the system and then reviewing the code. After that I tried reviewing the code first and then trying to break the system. I found the latter a lot after and easier to do. The reason being is that when you review the code, you can see which of the specifications were not implemented, and immediately you can see problems. I was able to see which exceptions were not caught and immediate knew how I could break the system. It is a lot faster than trying to think up of ways and then testing all possibilities on how I can break a system.

All in all, I believe that taking different approaches that work well next time can speed up the reviewing process, I found it not so bad and gave me a lot of insight into potential problems and even fixes and ideas on how to improve me own project.

Your code has good Feng Shui: WattDepot Code Reviews

All these parentheses and semicolons really ruin the feng shui of the code!

Although it can often be a very good thing, a lot of programmers hate to do code reviews. So this week we get a hard learned lesson is code reviews.

I have been tasked to review two other groups WattDepot project mentioned in our previous blogs. Watch as I tear it up.

The reviews for these two groups were assessed based on the checklist found here.

To read my full review of the code refer to the links below:

Eolu (eono)

Ehiku

Summary:

Eolu

Not all the commands were completed. Overall the design could use work, the methods can be split into there respective classes and the javadocs require updating. Comments need to also be added to many methods, it is inconsistent.

Ehiku

All but the chart command is completed and functioning. The design for the system is very good, all methods are separated into their own class. Commenting and naming conventions need to be more consistent across the different programmers. Overall well programmed.