ICS 413 Soft Engineering final thoughts

ICS 413 seemed valuable because it may be the only class that teaches how to program in a professional setting. That's what I thought at first. What I think I'll value from this class most is the level of preparation I received in programming and project management. Over the course of this semester our class worked on continuous integration tools, open source software development, project health and even making a portfolio. These things are really crucial to preparing me and making me feel prepared for a professional career in programming.
I'll start off by saying that the lecture videos aspect of this class was helpful in constantly reminding me how things should be. As helpful as a lecturer may be, I don't think people are comfortable making professors repeat a certain topic over and over again.
Software Integration is a topic I was not familiar with at the beginning of this class, but now I can understand it and appreciate the role it plays in making a project that has good flow. It can help programmers make progress, and what's more important is that it makes things a lot faster and easier.
Open source software was something I had a idea about, but now I got the history of it as well. It's given me perspective about the technology world and society as it is today. This idea of sharing software and making contributions to a project is very comforting. If the world is truly connected, then anybody can contribute. I am very excited about the idea of many people sharing and contributing to the body of work in any project. I'd like to think it is perpetuating progress. History has shown that communication and the distance between people has been a big road block to the sharing of ideas and advancements in technology.
This semseter we also used something called software ICU. I wasn't not familiar with it at all and didn't know you could do something like that. We setup sensors in the programs we used like eclipse and ant. Then when we used those programs it showed how well we used them and how often. It is a reflective way of looking at our progress in a project and whether the habits are healthy. If progress is steady and updates are added incrementally then it's healthy. However, it can also show that you spent the whole night before the due date working on the project in order to get it done. I think it is very practical to use this to kind of keep yourself honest.

Lastly I was able to develop my online persona using this blog and through working on the projects. It's a big plus! I was really scared that once I graduated I wouldn't have anything to show propective employers. I'm always getting emails from my counselor with employers asking for people in the field that have a year or two of
programming experience. How can I have experience if nobody hires me?

Overall, this class has been a positive influence on me because of how many I learned. Of course I had to work my butt off to get a good grade. I think it's made me a better programmer.

GreenDepot Project

I've been working on the GreenDepot and version 2.0 is out. Although it has some flaws in it, it has come a long way from version 1.0. Take a look at this url http://code.google.com/p/greendepot/. I think there are improvements to be made and new features that could help users. I've already implemented some styling changes to the pages. I think it looks a lot better, but I definitely need some input from other people. Please leave feedback.

The GreenDepot project

The deadline for this project was always at the back of my mind during the time our group worked on it. I have to say that I honestly had a tremendously fun time working on GreenDepot version 2.0. Unlike working on version 1.0, there was no overhead in creating the structure of our web application. Once the initial functions set up, we started throwing ideas around and figuring out how improve our application. Granted, the project was probably the worst application in our class at the version 1.0 phase. I feel that we made great progress and feel really proud of our work.

It started on the second week of November. Our groups were chosen and I was partnered up with Nate and Edwin. We had some trouble getting together to meet because of our varying schedule. Night was the only time we could meet and talk, so we talked over google chat. And for a time that sufficed, but now that I look back I think the few times we met up outside of class were really valuable. Those times allowed us to talk and make sure we were on the same page with each other.

GreenDepot is a web application that uses wicket as the basis. Wicket allows programmers to just use html a markup language and java. The application is geared toward displaying data in a meaningful manner, using WattDepot as the source for all the data. WattDepot is a open source software project that allows developers to get simulated data from the Oahu power grid. This software was the foundation for GreenDepot. Without it, we wouldn't have anything to work with. Using this data we displayed it in two ways.

First there is the StopLight page. This page shows you a meter with green, yellow and red, and acts as a sort of stoplight. It will generate data using WattDepot and based on our thresholds for what is a low carbon emission time and what is high, we indicate green for a good time and red for a bad time for using eletricity. We also provide suggested hours on the side which indicate data from yesterday which hours were best.

Secondly there is the GridInfo page. It serves as a chart that will display the 24 hours data from the date you chose as input. Right now, we have a start date input and an end date input. This way you can set the time as long as you like to get an idea of the carbon emission, whether it be for a day or ten days. This was implemented in a much easier way using google charts. I've really come to love all the software tools google offers. I never knew that google had invested so much into developing so much software for users everywhere. There is a lot to look at when you click that "more" tab in their front page.

More recently, I've added a contact page for information pertaining to our project and also changed the layout of the page. It has a smoother look and I think it doesn't look as junkie as it used to. Before the page had too much stuff that distracted the user. Now it can focus the user to the results of the page and what we have to say.

This project had some bumps, but I've tried to work on it daily and the software ICU has shown that the development side has been healthy.


This project was really hard. Wicket was hard to learn and I struggled at first. But I learned a lot. What amazed me was the amount of time I spent on this. I was really excited for this project. It really drew my attention and I think it shows that I could do this as a profession. Writing software and creating applications has a great appeal for me and I would love to continue doing it.

A peek at other peoples code.

I was able to review another group's project code and see what they had done. It was very interesting to actually examine all they had accomplished. It made me even more determined to improve my group's work and get coding!

There are a lot of different details to consider when reviewing a project. My professor very eloquently wrote the list for it in his website. These are the main points.

• The build
  
• System Usage
  
• Javadocs
  
• Naming conventions
  
• Testing
  
• Package design
  
• Class design
  
• Method design
  
• Overall feel and look of implementation
  
• Documentation
  
• Software ICU data
  
• Issues management
  
• Continuous integration
  

Take a look at the review I wrote based on these criteria. Link.

I felt that Ecologineers' web application was at the brink of success. This group has done good. They managed to produce a web application that worked. Although they need to polish their implementation and their user interface, they're on their way to creating a solid application.

GreenDepot 1.0 , but not quite

It's my very own web application. This week through the work of a group of me, Edwin Lim and Nathaniel Ashe, we were able to create a humble web application that dealt with carbon density during a 24 hour interval. It's a culmination of all that we've learned in ICS 413. We're using everything from continuous integration tools like Hudson to open source sottware like WattDepot. These types of software have been discussed on my blog before, but now they're all part of the project my teammates and I are working on. Take a look here.

GreenDepot is a software source software as well. It's primary use is to gauge at what time of day is the most efficient for power consumption. As of this moment, I'm sorry to report that our project is unsuccessful in meeting the criteria set a week ago. Our professor wanted certain things done by now and they are not. What we have is a Wicket web application that takes a date and stores it in a variable. We've even managed to calculate the all the carbon density data for all the hours of a day, but haven't been able to output to an appropriate medium.

Now what's Wicket you may ask? It's a web application design tool. It certainly has many functionalities. It quite a long time just to understand how Wicket worked. This tool is one that works toward creating an application without using too many different types of languages. All you need is html and java. With a combination of markup language and high level programming language, the results seem pretty good. Things are kept simple by limiting programming to only two languages. It allows people to quickly go through it and understand it. However, I bring up again my results. It was not easy learning this new construct.

Another factor that led our team to meet only a few of the goals was that again, our communication failed. I mentioned in my last blog that communication between Edwin and I was difficult at the start. It didn't get better this week either. We weren't able to effectively decide what to do and so time was wasted. Nate our new teammate was well new, and it took some time for us to set up ways to communicate. Ultimately it kept us from deciding on what to do and how to do it.



As you can see from the HackyStat evaluation, our performance was not great. We were behind from the start and so had to rush at the end to make some progress. If we are to continue in this project and be successful I think we need to communicate more and be able to work together more frequently. It's only when we are working as a group that things are getting done. One team member might get stuck on something and the other helps out. Most of our problems have been solved that way.

WattDepotCli Version 2.0

My partner and I have updated our WattDepot Client project. This improved command line based program can now take 3 more commands and provide you with a good idea of what is happening in the grid of Oahu's power plants.

In terms of functionality I feel that our client program does everything it's supposed to. Yet, it's not the shiniest of code. There's a lot of polish that needs to be applied still. More tests and error checks can still be applied to the program in order to cover some vulnerabilities. That's probably one of our weaknesses. WattDepot-Cli-Umikumalua still needs more polishing. What we were able to do was to create more exceptions to handle things like null pointer errors and making sure that a source/power plant existed before we threw that name into a function. These tests and error handlers have made things look better, but it hasn't made me feel safer about it.

I've worked really hard on upgrading the way the command line interface works. Before, the interface was really just one big class that was extended. But now, I understand how to make a interface and how to use different classes that are highly flexible and scalable. If I wanted to add more functionality to just one command, there would be room to expand and it would not cause all kinds of havoc.

A new tool I was introduced to was HackyStat. It's a type of monitor that tracks your actions when your developing software. So it can show you how often you've updated your project and code, or how much time you've put into a certain task. It's definitely worth looking into. I say this not because my grade in class depends on it, but because when it comes to productivity you should want to have some insight into what you are doing and what you think you should be doing. It's another way of reflecting on your capabilities and habits. Even if it's that helpful or improving your skills, it can still serve as proof that you did something.

Although it may seem to be a complicated and unimportant system, I have used this client software to derive some useful facts and insights into how my island home of Oahu operates.

Using this Client I built, I conducted a test for the month of November to determine which day had the maximum and minimum power generated and which day had the maximum and minimum carbon emitted. These tests looked at a particular plant or a network of plants and calculated the amount of carbon or power that was emitted for a particular day based on an interval of checking. What I found out was quite interesting. Our habits shine through even in the data. Based on the outputted data (which you can access here), the SIM_OAHU_GRID was at the peak during weekdays. A peak day like November 16th and 17th saw 995 MegaWatts of power being generated within the Oahu grid. On the other hand during the weekend, energy emissions were down to to 665 MegaWatts of power being generated which is about two thirds of the usual power consumption. The results for carbon emissions were in the same pattern as for power generation, as expected. Since there was more power being generated the carbon emissions rose as well. Emissions ranged from a weekend low of 22.8 million lbs to the weekday 29.9 million lbs of carbon. I would like to think that Oahu is a very industrious city and most of our power consumption is used during weekdays because of businesses.

Feel free to take a look at my distribution package and the WattDepot-Cli project page. here

My Experience with Software Review

I was tasked with reviewing a project of some fellow peers and also to provide insightful feedback to help them better their results. While I did this, a few revelations came to me through their own feedback of my project. The comments have made me aware something.

A major point stressed in the beginning of the semester by my professor in ICS 413 was that when you are creating Open Source Software there are "three prime directives." One of these directives was being able to create software that users could work with effectively and understanding it. I feel that, I have been weak especially in that department. A common comment I got was "it needed more error checks." It reflects bad on my understanding of interfaces because one of the most common habits people have is to use something without reading the manual. I need to make it so that human error is not a major factor in the program. I know I cannot totally provide a solution to the things that can happen, but testing and error checks can help.

I also learned about development through this review process. It was quite surprising and amusing. I learned that I had some strengths and also weaknesses in programming and so did my peers. I never thought to do validations for certain inputs like the html address, but the others did. One of my strengths was that I had a strict coding standard in terms of grammar and getting the details right. When I used the command line built by the other students, it was bad. Their system was not as clean as mine, but they had better program testing. Whereas I had done more happy tests to make the program work better on the command line, they had done testing to provide coverage on the unit and behavioral level. I was kind of narrow minded that way. What I was focusing on was the way the program ran and how the user felt. That's why I was really annoyed when the other programs did not work as expected. For example, they had a help command that printed the syntax of the commands to be inputted. But it didn't work. I had to tediously check the source code to figure out exactly how to input the values and get the right results. On the other hand, I had worked very hard on this portion of my program.

This review has led me to look at programming in a changed manner. Although students are taught not to work together in the first years of computer science, it's become essential in software development because of the different techniques and approaches other programmers have for a specific task. It's made me want to continuously seek input from my peers in order to get a well-rounded outlook on what needs to done to write good programs.