Greenometer v2.0: Saving Green$ While Going Green

The final project for my Software Engineering class was to polish my group's first iteration of the Wicket Application: Greenometer. Continuing from my previous post about creating Greenometer, this blog post is my final overall thoughts on the whole process. The final specifications for version 2.0 were released here.

Greenometer v2.0 can be downloaded here.

Prof. Johnson had originally planned for us to make a v1.1 release, specifications found here, he decided to forgo the due date of v1.1 and have v2.0 due instead, reason being v2.0 should have all revisions and changes that would have been made in v1.1.

So, for the last month of the semester I have been constantly working around the clock with my group members to get the specifications for v2.0 done. I have gotten more acquainted with using Wicket in combination with Java and took on various tasks that dealt with the actual UI of our interface, to the actual source code, and testing.

My journey into first semester Software Engineering - ICS 413 certainly gave me a little taste of every aspect of being a software engineer. I learned the group collaboration process, which entails splitting group work, getting group members motivated to participate, and making sure the project is still on schedule, all while having an overall great time. The coding aspects seemed to revolve around learning how to create test cases and learning the different between high coverage and quality coverage. There is definitely a difference between creating a functional interface versus a quality interface.

Prof. Johnson had stressed that although creating a quality end product is the ultimate goal, a partially complete system that's high quality is better than having a system that's partially tested and mostly functional.

Our final project features 5 pages:

• Home
• Stop Light
• Grid
• Concepts
• Contact Us

As noted in my previous post regarding this project, the functionality of this application is to provide users with detailed information about the Oahu power grid. In an attempt to gain users attention about Going Green and saving energy. Our simulated application allows its users to view the energy generated at specific sources given a date or range of dates.

Project Details
Home
The home page briefly describes the applications purpose and it's functionality, mainly outlining the other 4 pages; Stop Light, Grid, Concepts, and Contact Us.

Stop Light
This page features a stop light that shows either red, yellow, or green depending on the Carbon Intensity (lbs CO2 / MWh) of the current time. This pages queries the WattDepot and gathers carbon intensities for the whole day, then determines the color value for the current time.

Grid
The grid features a Google Chart, either a Bar or Line chosen by the user, based on the Energy Emitted (MWh). The user can also specify which source he/she wants to view. It's currently defaulted to the overall Oahu power grid, but can be changed via a drop down menu.

Concepts
This page outlines the motivation for the application and gives in-depth explanation how how to understand and use the Grid and Stop Light pages.

Contact Us
Provides the projects Google Site, Discussion Group, and a link to each developers Professional Portfolio.

From Robots to Energy Grids: Software Engineering Reflection

Prof. Johnson's ICS Software Engineering class was a unique experience this semester. It was the first class that actually made me feel like a Computer Scientist. Working towards a real-world problem, collaborating with others, and learning new tools all made it surreal and thrilling. Granted this course takes a lot out of you, at times I felt like the assignments didn't bear enough time and that I had to focus most of my energies into this course. This course felt like a job and my pay was my final grade.

What I found most valuable were the new software engineering tools such as Ant, Subversion, and Quality Assurance tools, JUnit, Checklist, PMD, and FindBugs. For the assignments that we did, from Robocode, to Wattdepot, to Wicket, it was hard to find a balance between Quality and Functionality. Prof. Johnson constantly encouraged us to create test cases as we developed our projects, but I found it difficult to come up with what aspects to test. Testing takes a considerable amount of time with every run of Ant. JUnit would take an excess amount of time to complete and it seemed like it hindered the overall time spent waiting for the project to pass verify.

The group aspect gave me another take at what it is to collaborate with others, especially with those in my field. It seemed that the group went only as far as the strongest person. Sure everyone has their forte, but doing everything shouldn't be one of them. It was hard to find an even split of work for everyone to do. There was always some aspect that bled into another, and it was hard not to just work on a single method or class without waiting for someone to commit their changes.

We were introduced to an array of technologies and experienced many different aspects of being a software engineer. We were fortunate enough to have coded in Java throughout the semester, a language that has been drilled into my brain every since my beginning semesters as an ICS student. Though, the one thing that I would like to learn more about is the framework for planning. Splitting the work load is always a big issue. How do you come across as knowledgeable rather than bossy? Or try and get someone to carry their own weight in a tactful way that doesn't sound too threatening. Indeed, it might have turned out differently if we had everyone in our group share what are strengths and weaknesses were. However, group work isn't something that is deeply encourage in the lower levels of ICS, so it takes some getting used to the concept of collaboration and the sharing of ideas.

Learning a new system and how to use it such as WattDepotClient, and learning a new language, via Wicket, are the types of things expected of every Computer Scientist in order to keep up in this field.