Doing More Cool Things with WattDepot

Alright, since it’s probably taken all the way from the last time until now to finish reading straight through the last post (the technical review of TNT’s Hale Aloha Command Line Interface), I suppose it’s time to tell you about the next steps my team and I have taken with this project. Keeping the original code base, we implemented further functionality on the product, to see if it could be done and with what effort and challenges. Our goal was to add three basic functions: set-baseline, monitor-power, and monitor-goal. Monitor-power outputs the current power readings of a tower or lounge every user-defined number of seconds until a character is entered, which terminates the task. Monitor-goal takes a baseline (defined by set-baseline) as well as a user-defined percentage reduction goal and calculates whether or not the tower or lounge is meeting that goal or not, and like monitor-power, outputs this every so many seconds as defined by the user.

Although there were some issues with implementing this such as getting the timer to work, especially with terminating on any character being pressed, majority of the issues arose from the fact that the bulk of the code— and it being the base, too— was built by other developers. Fortunately for us, the code base was built very well, with many advanced and well-implemented techniques; much more robust and easy to use (in the long run) than our own one was built. However, because some of the implementations went over our heads, it was difficult to understand it and get used to it in the beginning. But I don’t think that this was due to a lack of keeping with Prime Directive number 3 (an external develop being able to understand and install the system), because it was not due to poor documentation or unreadable code, or anything similar to that. It just took a little bit of time to understand, which is probably just normal with taking over someone else’s code. As mentioned in my technical review of TNT's product, the Three Prime Directives of Software Engineering were met, because the product definitely accomplishes something useful, the documentation provides clear instructions to installing and using the system, and an external developer can easily (or at least relatively easily) develop and enhance the system.

As far as the Issue Driven Project Management went, just as it was with our own Hale Aloha Command Line Interface, everything was rather smooth-sailing and we didn’t run into any issues. Again, it was great in the beginning for portioning out the work load, but as we had to make modifications to our code, it became less of a required thing and a little more of a nuisance. This time it wasn’t as bad though, because the command interface and processors were all created already, so we only had to implement the functions (and their associated test classes) themselves.

Most of our enhancements to TNT’s Hale Aloha CLI work well, and I’m actually quite surprised at what we were able to accomplish, given the little amount of time we had to spend on it, and the complexity of the tasks. One thing that doesn’t quite work properly is the functioning of the timers implemented in monitor-power and monitor-goal. It took a while just to get the timer properly implemented, and we could not get the termination of the loop to end properly. We would have liked for it to end when the user types in any character, but instead it only does so upon entering a carriage return. Another defect in the system is the full checking of whether a baseline was set before the monitor-goal command is run. The current setup has it where the baseline is not tower-specific. If set-baseline is run only for Ilima, for example, the user could run monitor-goal on Lehua, and not encounter any errors. This is a minor error and could probably be fixed rather easily, had we had more time. Other than this, everything seems to be working well, and I’m very pleased at the quality of the enhancements that we were able to produce in just a couple of weeks. The test cases prove that our system is pretty robust (other than the aforementioned flaw), and it is fully documented and working.


Working with someone else's code base-- or anything for that matter-- is difficult and can be a headache-- especially in the beginning when everything is so foreign-- but this process is beneficial in many ways. The obvious one is that it provides you with examples-- good and/or bad-- of implementation techniques, and so you can learn new tricks if there are any, and fix the places that are substandard. Secondly, however, being put in an environment where you are not only requires you to work as a team but to also switch products to compare or improve them forces you to write better code. Especially when you know that others' eyes are going to be looking at the code you wrote, you want it to be clean, correct, and the best it can possibly be. This includes documentation and code formatting, which are things that are often left attention-deprived when you know that only one set of eyes will be looking at the code. Plus, there's the pride aspect of providing really good code-- perhaps implementing a cool trick that you learned that makes a certain function simple, correct, and efficient; you can show it off in a "look at what I know how to do" kind of way, and that makes things a bit more fun, rather than "it's messy, but... ah, it works so it's good enough for me." Friendly, harmless "competition"-- if I may even call it that-- never hurts anyone, and is one way to intrinsically encourage good code in a pain-free way!

TNT's Explosive Performance

Now that my group and I have finished our Hale Aloha WattDepot implementation, I'm curious to see how other groups tackled on the same tasks, and to what extent of quality their products are. So I decided to take a look at the "TNT" group's Hale Aloha WattDepot implementation. In assessing the group's product, I believe that it is befitting to review them under the Three Prime Directives of Software Engineering. By doing so, I can grasp a large understanding of many components of the product, and also sharpen my knowledge of what the Three Prime Directives are and what I need to keep in mind whenever developing a piece of software, to make sure that the product is useful, easy to install, and easy to understand and enhance.

Therefore, to get started with the First Prime Directive: "does the system accomplish a useful task?", I took a look at the overall functionality of the product to see if all of the components were there. The group was able to retrieve the current power of a tower/lounge, get the energy for a tower/lounge from a specific date, get the energy usage for a tower between two given dates, and finally give a sorted order from least to most between two dates. These are all of the functions that we implemented in our own system as well, and they are useful tasks indeed.

The Second Prime Directive is: "Can an external user successfully install and use the system?"

Taking a look at the homepage, I found very precise information about what the system does, although to find sample input and output, I had to go into the User Guide wiki page. This 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 order to test how robust the system was, I input various commands, both valid and invalid, to see how the product handles them. Here are some of the commands I input, with a description of what was output:          

·      “help”

o  Gives the proper output.

·      “current-power Lehua”

o   Gives the proper output of Lehua’s power.

·      “current-power lehua”

o  Since tower is case sensitive, gives a bad syntax error.

·      “Current-power Lehua”

o   Since command checker is also case sensitive, gives a bad command error.

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

o   Gives the proper output of Lehua’s daily energy for Nov. 25, 2011.

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

o   Since the date is in the future, gives a bad date error.

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

o   Since date isn't properly formatted, gives a bad syntax error.

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

o   Also gives a bad syntax error because there is only one format for the date.

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

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

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

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

·      “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   Since it recognizes that the start date is after the end date, gives both a date error and a bad syntax error.

·      “quit”

o   Properly closes 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.

 

Finally, the Third Prime Directive: "Can an external developer successfully understand and enhance the system?" was reviewed, and for this, I took a look at the Developer's Guide wiki page to see if it provides sufficient instructions on building the system from its sources. TNT's Developer’s Guide wiki page does indeed provide 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.

 

 In addition to the Three Prime Directives, a number of other components must be reviewed as well in order to get a complete understanding of the quality of not only the functionality but the documentation and the process and progress of the product as well. JavaDoc, Build System, Coding Standards, as well as the Issue Driven Project Management and Continuous Integration must also be reviewed, and for TNT, the results of reviewing these components are as follows:

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 not know 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 the overall quality of these classes is great, and so it is clear that this member worked hard as well but maybe just didn't have the experience levels of the other two.

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 with having about eight out of ten.

 

Conclusion

            From this extensive review of TNT's Hale Aloha command line interface system, it is safe to say that the Three Prime Directives of Software Engineering were fulfilled. The product can successfully be developed and enhanced by new programmers, and everything was well organized and presented. This group definitely had some features and functionality that was more advanced than my own group's ones, but that is a good thing, because I can learn from this and apply my newly realized techniques to other projects in the future. TNT's product was extremely robust and very impressive, and I see it as sort of a model for me to remember and refer to when implementing similar desired features. Although this review was very lengthy and time consuming, I learned a lot, and felt that the TNT group did an excellent job working together and putting together a solid product.

Issue, fix, issue, fix,...

In my latest experience, I got to know how to work in a completely new environment-- that is, working with others rather than by myself, which I have been more-or-less doing up until now. Now, you may think, "what's the big deal with working with others? People do that all the time, even with computer-based projects." This is very true, but the question is, "are they doing it correctly?"-- as in effectively and efficiently. They may, or they may not be, but I definitely received an exposure to a great process collaborate as a team on a project involving continuously-changing code, as well as an efficient way to utilize it. The process is called Continuous Integration, and the way to use it is through Issue-Driven Project Management.

Basically, Continuous Integration (CI) keeps all the group members up-to-date on the status of the project, notifying members immediately when something is "broken", and when it is "fixed". Issue-Driven Project Management (IDPM) is exactly what it says-- it's a system for managing a project by utilizing "issues". Issues are tasks set up by project members for designated members in order to 1) make sure that members aren't going, "uhhh, what should I work on now?", 2) make sure that members aren't working on the same part of the project at the same time, and 3) keep track of who did what. For our project, we used a combination of SVN + Jenkins (CI) and Google Project Hosting (IDPM) to create a project where we implement the WattDepot application-- the same one I introduced to you last time with my WattDepot Katas.

One thing that was very nice about using Continuous Integration and Google Project Hosting was the sharing of wealth; group members could work on portions of the project that were in their respective areas of expertise, or could even help fix something that another member broke, helping that person to understand the problem and become a better programmer.

On the other hand, having multiple people work on the same project has its downsides, especially when it comes to consistency. One person's thought-process, style, and knowledge is different from another's, and the same thing can be said about coding. No two people code in exactly the same way. So while I used Regular Expressions to check if a date was valid, another person used Lists and String matching to verify the location specified. Neither of us is more correct (although speed, code-length, and accuracy might differ), and so it was extremely difficult to resist the temptation to try and correct someone else's program and adjust it to fit your own coding styles.

But overall, we were able to work together with this framework and complete this project successfully. Our product is a command line interface program that users can use to view various data from the Hale Aloha residence halls at the University of Hawaii. For now, there are 4 basic functions to view the data for-- Current Power, Daily Energy, Energy Since, and Rank Towers, but the system can easily be expanded to accommodate more in the future. Entering "current-power " and a tower name will output the latest power readings for that tower. Entering "daily-energy [tower] [yyyy-mm-dd]" (without brackets, and where yyyy-mm-dd is a date) will give the energy consumption for the specified tower on the specified day. Similarly, "energy-since [tower] [yyyy-mm-dd]" will output the energy consumption for the specified tower, but as the total consumption from the specified date until the current time. Finally, entering "rank-towers [yyyy-mm-dd] [yyyy-mm-dd]" will output a list of all the towers sorted by their total energy consumption for the interval given. Additionally, the command line interface program supports the commands "help", which lists and explains the available commands to use, as well as "quit", which is used to exit out of the program. Until the user enters "quit", the program remains in a loop, so you can keep running commands and viewing data to your heart's content.

I believe that while far from perfect, our project turned out to be one of rather high quality. Perhaps we could've structured it differently to allow for better testing, or enhanced it to make it more robust, but it does what it needs to, and is fully functional. Because we got to share our knowledge, we got to see various new methods of accomplishing certain tasks and use those techniques in our own components of the project, rather than using the same old sub-optimal ones that we have been using for the longest time. There are always challenges with working in groups, but in the end, if there are even just a few parts which turned out to be implemented in a better way due to the collaborative efforts for everyone in the group, then I think the project is successful because each member takes away something learned, and can apply it with future projects.

WattDepot to the Rescue!

This week, I’ll be sharing with all of you my experiences with WattDepot in the past few days. As you may already know from my previous post (and from other sources), Hawaii is not in a very good position right now in regards to energy reliance and the future prospects of its energy. That’s where WattDepot can be a stepping stone—several, in fact—to building up public awareness of energy as well as bringing Hawaii into a state of renewable energy usage rather than continued reliance on oil.

First off, WattDepot is an open-source project that uses electrical monitors to record and report data to a server, which can then be accessed through client programs and applications. Users can collect data from different locations, different time periods, and even manipulate them to get another perspective on the data, such as a sorting by consumption amounts.

Because there are so many features that WattDepot has to offer, there was only one way to tackle learning how to use the API and the many components of WattDepot-- Katas, of course! The katas I needed to implement in order to become comfortable with WattDepot were:

1. Connecting to a server and listing the sources hooked up to it, along with their descriptions.
2. Calculating and listing the latency (how current the data is) of the sources, sorted by increasing latency.
3. Displaying the hierarchical listing of the sources and subsources.
4. Listing the energy consumption of each source from yesterday.
5. Listing the highest power consumption recorded yesterday along with the time at which it was recorded.
6. Calculating and listing for each source the average energy consumed over the past two Mondays.

Starting off with these katas was not too bad at all, because I was using a WattDepot simpleapp as sort of a template for the first two. The part that was tricky with kata #2 was the sorting of the latency. I had to brush up on my Collections, Generic Data Types and Comparators and implement an additional class called Data to help take care of the sorting. This made this kata take much longer than I expected it to-- maybe about an hour in total, whereas kata #1 took only a couple of minutes to complete.

Then came katas 3 and 4. My goodness, were these tough for me! Without much of a template to follow, I was stuck with going out and staring at the API for several hours trying to make sense of it. I could see what I wanted with the subsources and energy consumption, but I just did not know how exactly to get it. Perhaps it is a difficulty common to most programmers, or maybe it's just me, but I tend to have quite a difficult time understanding APIs (other than the Java API). It's like, "ok, I see you, and I want to get you. But how exactly do I do that?! And what kind of data type do you return?!" I guess I've been relying on the Java API too much.. But finally, finally after hours and hours (and hours and hours) of painfully staring at the computer screen (occasionally wanting to just hurl my laptop into the wall), I was able to figure out a way to parse through the list of subsources, figure out what the hierarchical ordering is logistically supposed to be, and then implementing a way to display it in a list. Phew! That only took 5 hours! Now on to kata 4.. Kata 4 took about 3 hours to complete, because I was slightly warmed up to using the API and I had already designed a Data class and a sorting class that I could tweak just a little to get it to work with the Energy Consumption values. Figuring out the calendar dates and whatnot was a pain, but other than that, it was not too bad overall.

I was already pretty much out of time by the time I got around to finishing Kata #4, so currently I only have part of Kata #5 implemented, and I did not even get to start on the last one. It was difficult to get these katas done in such a short amount of time, especially since the WattDepot application is one that I am not familiar with, and so it took a while to even minimally understand how it works. Especially for me, because I know that I take a really long time to learn knew things, more time is always very helpful. I probably could have paced out my scheduling for this assignment a little better, but sometimes you just get really crazy days where you can't do much of anything, and that happens to everyone, so you just have to live with the consequences and do better next time.

Through this exploration, I learned a lot about WattDepot—its capabilities, its potential, and just a few of its many features. WattDepot is an extremely neat and useful tool, and it is great for many applications. I can see it being used not only to monitor and report energy consumption and generation, but also using that information to analyze what is using a majority of the energy and where. This information, as well as many other findings can be used to inspire more reserved energy usage and help solve Hawaii’s energy crisis problem. Energy data manipulation may seem like only a concern for electricians and engineers who have to set up and monitor electrical components, but it can actually be constructed into user-friendly applications to be used by anyone to visually see what they are doing to their environment and their wallets. I sure hope to see a lot of people in the near future using applications as such to really think about their lifestyles and change for the better-- for their health, their finances, and their surroundings.

Sustainable Paradise

     Ahh the images of Hawaii: sandy beaches, blue skies, and-- what's this? Photovoltaics, wind turbines, and other renewable energy generators? Well, not so much yet, but hopefully in the years to come, Hawaii will not only be the epitome of paradise, but also of sustainable, renewable energy. For those who call Hawaii “home”, a less expensive, cleaner, sustainable source of energy is not only desirable for economic reasons but also for aesthetic reasons, because keeping Hawaii paradise-worthy is an important aspect of pride for us who are living here.
     I know what you're thinking-- “Hawaii is such a small and isolated place. Why should you guys care about renewable energy sources? The mainland and other bigger areas use more energy, so they should be the ones thinking about renewable energy.” Well, I agree that other areas should consider using more alternative energy sources, but just because Hawaii is small and isolated doesn't mean that renewable energy should be dismissed as an option. In fact, small places like Hawaii may have more reasons to transition towards alternative energy sources than larger areas, because here we face issues such as inefficient power generation, higher reliance on oil, and therefore higher price to pay for energy.
     Due to its small size and water-delimited major land masses, Hawaii does not have the large energy “supergrids” or even “grids” that the U.S. Mainland has to manage the power generation and distribution across the land. This results in having to rely on small, inefficient mini-grids in order to get power to all residents on all islands. Because of this, energy in Hawaii costs three to six times (or even more!) the amount that it does on the Mainland. Furthermore, over three-fourths of Hawaii's energy comes from high-cost oil, as opposed to the measly one percent that the U.S. Mainland relies on as their source of energy. If we do nothing to change our energy sources, Hawaii's expensive energy cost could continue to increase as time progresses.
     Another reason for Hawaii to look towards alternative energy sources is because of the high availability of many different sources of energy. Hawaii has easy access to solar, geothermal, wave, wind, hydroelectric, and many other natural sources due to its geography. In fact, there are so many options that would yield high energy output, that the entire state of Hawaii can run completely on its own generated clean energy. With such a promising possibility, what reason is there to not switch to these alternative energy solutions?
     Unfortunately, there are some negative aspects to converting to renewable energy sources, such as having to pay to set up the facilities and switch over to them. Taxes would increase, and therefore many people may oppose this, especially if they themselves aren't going to be reaping much of the benefits directly. Some organizations are actually against renewable energy sources, due to the cultural and environmental damage that the building of the structures causes to the surrounding area. But not switching to renewable energy sources will cause even more environmental damage in the end, as greenhouse gas pollution causes temperatures and sea levels to rise, greatly impacting Hawaii's landscape. And as for the cost issue, if we don't pay for cleaner energy now, we will certainly pay for it later, in the form of not only higher fuel and oil costs, but for everyday items as well, as prices will have to increase in order to compensate importing costs.
     So there are many reasons for Hawaii to really start getting its act together and really pushing for renewable energy sources. Everyone can and must do their part in order to make Hawaii a hospitable place that can be called home even decades into the future. Conservation of energy is something we can all do to help keep energy costs down, and supporting renewable energy can help us achieve the goal of a cleaner, sustainable paradise. This is our world-- our home. We should want to keep it a place where we can live free of worry, hazardous conditions, and high costs. It is our responsibility to take action and do what is right for our future.

5 Important Points of Software Engineering

While there are countless aspects of Software Engineering that are extremely important-- to the point where you could call many of them "the most important aspect of software engineering", I would like to share with you all just five of those points in the format of a mini quiz. See if you can answer all of them!

Questions:

1. Why should you use annotations in Java even though they are not necessary?
2. Automated quality assurance tools are also very important to programming effectively. The following code will result in which automated quality assurance tool (Checkstyle, PMD, or FindBugs) to report an error?: if (true) { x = 6; }
3. What is JaCoCo used for, and what is one aspect to beware of when using it?
4. Give an example of a good way to incorporate different types of software reviewing at various stages along the lifespan of a program.
5. How and why would you recommend using an IDE to someone who normally codes using a text editor?

Think you got all the answers? Check out my answers below and see how much you know about these software engineering components!:

Answers:

1. (Why should you use annotations in Java even though they are not necessary?) Although the Java Interpreter ignores them, annotations are useful in that they associate various “metadata” with elements within the program. They allow Java tools such as the compiler and Javadoc, and even automated quality assurance tools such as Checkstyle and PMD to find errors in your code more effectively. Annotations are sort of like extra tools that help make sure that what you are writing is actually what you mean to write. For example, if you are intending to override a superclass method but you spell the name wrong or use different arguments, having put the @Override annotation will give you an error saying that the method does not in fact override a superclass method. After realizing this, you can fix the error in your code right away without having to ponder and search through your code later to figure out what is causing the problem.
2. (Automated quality assurance tools are also very important to programming effectively. The following code will result in which automated quality assurance tool (Checkstyle, PMD, or FindBugs) to report an error?: if (true) { x = 6; }) This code will result in PMD reporting an error. Because PMD searches for possible bugs, dead and suboptimal code, overcomplicated expressions, and duplicate code, the above will be flagged as it is redundant; the condition inside the if statement is always true. It is syntactically correct and will not show up as a bug in the Java bytecode, so neither Checkstyle nor FindBugs will raise a concern for this statement.
3. (What is JaCoCo used for, and what is one aspect to beware of when using it?) JaCoCo is a tool for automatically analyzing how many lines of code in a program are covered by test cases that are written for that program. When using JaCoCo, it is important to keep in mind that coverage does not equal perfect testing. Although it is important to make sure that as many lines as possible are tested, just because you have a 100% line coverage does not mean that your code will be unbreakable if the tests pass. You could very much have a test that runs through only 50% of the lines but is a much better test than a test that runs through 100% of the code, because the test case itself is much more rigorous and exposes more flaws. So when testing code, just use JaCoCo to get a sense of how many lines you have covered, and then work on making sure those lines are covered as best as possible. Then you can add more to the test or make another test in the same way to cover more lines of code, and your program will be extremely robust!
4. (Give an example of a good way to incorporate different types of software reviewing at various stages along the lifespan of a program.) Following the general software development process: Requirements specification, Design, Implementation (Coding), and Testing, you should incorporate a reviewing process between each of these four stages. One example of how you could go about doing this is to first start off with a Walkthrough after analyzing the requirements. Since there is no code or design produced yet, just a basic check to make sure the idea is valid or thinking about other general issues may be sufficient at this point. Then, after coming up with a software design, it would probably be good to perform a little more in-depth Technical Review, since there will be more technical specifications at this point, so it would be a good way to check the design and find any defects and resolve ambiguities, before moving on to code the program. Another walkthrough could perhaps be performed in addition, to informally check the overall integrity of the program. Finally, after the coding is done, some nitty-gritty Inspections ought to be performed, to really detect and remove defects. Technical reviews and walkthroughs may also be good to incorporate, but streamline programs that are to be distributed for public use should definitely go through thorough inspection to get rid of as many bugs as possible, even before moving on to test the code.
5. (How and why would you recommend using an IDE to someone who normally codes using a text editor?) IDEs are made to do more work for you, so that you don't have to. They do not only simple tasks such as closing open parentheses and braces and automatically indenting new lines of code, but IDEs also contain libraries that enable things such as auto-complete, allowing you to view the available methods right then and there in case you forgot the exact spelling or what parameters are needed. IDEs will also tell you if something is spelled wrong or is invalid syntax, and also provide a place for compiling (which is done in the background), running, and debugging code, without having to compile and execute the code manually. All in all, IDEs allow for far more efficient programming that is also much more accurate, so you will probably never have to dig through code to fix an error caused by forgetting to close a brace or by using the wrong method name, because the IDE will take care of that for you.

Did you get them all correct? I know the answers are rather lengthy, but if you got the general idea down in your head, then congratulations, you know quite a bit of tools that can help you in productive software engineering! If not, then please be sure to learn to love these tools and tips; they will certainly come in handy in your experience as a software engineer. Please be aware though, that these are not the only vital tools to know for software engineering; there are tons and tons more that I have not covered here that are absolutely essential to programming, so please, search and play around with them, and read up on my other blog posts to gain more tools to put under your belt, so that you too may be on your way to becoming an excellent software engineer!

Getting a Sense of the Real World

This week, I'll be sharing with you my experiences with Configuration Management of a project, specifically my Robocode project that I have been working on so far. My robot is ready to be deployed out into the bigger world and be used and improved by people around the world. This is where Configuration Management comes in, and I have chosen to use Google Project Hosting to house my robot, and Subversion as the version control system. But before we get into making my own hosted project, I had to get a taste of what Configuration Management is like.

I have used TortoiseSVN once before on Windows, but since I do my coding primarily on Ubuntu Linux, I was left to find alternative clients. My first approach was to use Subversion from the command line. After downloading Subversion for the Ubuntu Linux terminal, I checked out the robocode-pmj-dacruzer project, made a minor change (setting the scan color to be white) and committed the changes back to the repository. Everything was going rather smoothly except for when it came time to commit the changes. For some reason, my commits were doing nothing; I wasn't being prompted for a user name or a password. I found this to be very strange, since everything seemed to be working-- checking out, updating, making changes. I had two option to solve this problem-- either install an SVN client with a GUI (like SmartSVN) to diagnose the issue, or try and figure out what was wrong by myself. I didn't have much time, nor did I know how long it would take to install SmartSVN and figure out how to use it. So I decided to stick with the command line version and focus on diagnosing the problem myself. After about 45 minutes of frustration, I discovered that the problem was with Eclipse. For some reason, the changes I made weren't being saved, so when I tried to commit back to the server, it would have no reason to do so because there were no changes made. So I opened up the java file in a text editor, made my changes, committed the changes successfully, done. Just in the nick of time.
(I did eventually download and set up SmartSVN just in case, for easier visual diagnostic purposes.)

Now, with a basic feel for Configuration Management, I was ready to tackle hosting my own project up for the world to see. As aforementioned, I used Google Project Hosting to house my project, and posted the zip file (created using Ant) there. I even included a Developer Guide as well as a User Guide so that developers can verify that it works and can be tweaked, and so that users can add Narchi to their systems and watch how it plays out in a battle. I did not encounter many issues at all-- in fact, the hardest part was actually figuring out how to upload the file onto the Google Project page. It took me quite a bit of searching, only to find that it was just in the Downloads tab. Other than that, all has been going rather smoothly so far, and Narchi is sitting cozily at Google waiting for people to check him out, take him home, and make him a better robot.
The robocode-cht-narchi project can be found here.

What I learned from this was the basics on how Configuration Management works. I previously had a running idea of why it is important to have systems like this, but I had never actually gotten to use one for my own project. Now I am able to host my projects on Google, and use Subversion to keep it up to date with the changes that people can commit to it. This is what happens in the real world with real open-source software, so this is a great skill to know and is a big step towards becoming a bona fide software engineer! The future of having a career as a professional is becoming a lot less scary, and I hope that I can learn a lot more so that I am prepared to face on the world with software engineering.