Engineering/Tech Blog

My thoughts about the Verizon iPhone

2011-01-11T22:35:00.000-08:00

AT&T exclusivity is over and Verizon wireless will finally start selling iPhone to their users. So should you jump the bandwagon and switch to Verizon next month? Here's some things to think about.

Verizon iPhone won't be able to use data while taking a call. Verizon's current 3G network does not support this feature. AT&T does.
Verizon iPhone's antenna has been revised and moved the volume rocker and mute switch down. This means that if you are switching from an AT&T iPhone 4, you will have to buy a new case for it.
Verizon iPhone won't be using their 4G LTE network. What does this mean? Verizon's 4G LTE will be using sim cards like AT&T and T-Mobile. This enables their users to switch phones by swapping sim cards. Verizon's iPhone is stuck with CMDA technology. CDMA = no sim card. So why would you want to be stuck with 3G CMDA when they are rolling out 4G devices?

So if you ask me if you should get the iPhone now, I'd say wait till they roll out one that supports their 4G networks. But if you really can't then by all means go ahead and buy it :D.

The Process of Interaction Design

2010-11-10T12:28:00.000-08:00

In my last blog, I was talking about Chapter 7 my Interaction Design textbook which covered the different methods of data gathering. The next three chapters dealt with data analysis, the process of interaction design, and identifying requirements.

In data gathering, data can be broken down into two different categories, qualitative and quantitative. Both types of data can be analyzed differently. Researchers try to find patterns and trends to support their theories and findings. Graphical representation of data helps in identifying patterns easily in quantitative data. Grounded theory, activity theory, and distributed cognition was used by the author of the textbook to analyze qualitative data. These frameworks work by breaking down the qualitative data into smaller and smaller categories so that they can find the trend or patterns at the refined categories.

The next chapter focused on the early stages of interaction design. The planning of interaction design from identifying the needs all the way to implementing the requirements. This chapter emphasized on catering to the user. As a developer, I believe that it's important to base my work upon the user's requirements and request rather than trying to do it my way. This ensures that the user will be happy with the final product. Involving the user during the process is also key to achieving better product. Letting the user play with the prototype let's the designer know what works and what needs to be refined. Different lifecycle models were also explained in this chapter. In my experience, we used Agile development in my software engineering class. Agile development focused on collaboration and that is exactly how we developed for my previous course. Letting you peers do constructive criticism of your code helps you develop and mature as a developer.

Chapter 10 was pretty simple. It uses the previous lectures from data gathering and analysis to identify and establish requirements. Nothing much to talk about since it just talked about how to apply the previous methods.

Next time I hope to find a journal from the ACM library that interests me. I'm currently looking at the latest journals that relates to Android.

Interaction Design

2010-10-27T11:51:00.000-07:00

It's been a crazy past two weeks with all the midterms, career fairs, and job interviews. I've been slowly catching up with the readings for my HCI class. Last time we met, Prof. Robertson assigned me a new book to read called Interaction Design: Beyond Human-Computer Interaction.

The book starts out with some basic intro about interaction design. Comparing good and poorly designed products such as voicemail systems and remote controls. I noticed that these books likes to pick on telephone/voicemail as an example of poorly designed products. It's also interesting that in today's world, we still continue to use those poorly designed products. The book defined interaction design as "designing products to support the way people communicate and interact in their everyday and working lives." I understand that interaction design is the bigger picture and HCI is just one aspect of it. There are many different types of discipline that's involved in interaction design. The book explained some of the benefits and negatives of this. The biggest pro of having people from different disciplines and backgrounds come together is the creation of more ideas coming from different perspectives. This could lead to more creativity. This however is also the biggest con. The clashing of different ideas could lead to conflicts and confusion. Some prefer to do it a certain way while others have their own ways of doing things. The book also mentioned the different usability goals and use experience goals that we have to think about while in the process of interaction design. The text also used the design principles that I read from Donald Norman.

In order to create good designed products, designers has to do some research on the consumers. Chapter 7 of the text covered the different ways of gathering data. Data recording, interviews, surveys/questionnaires, and observations are some of the main ways to gather data.

I have a lot more to read so more to come later.

Everything starts with design

2010-10-13T11:42:00.000-07:00

This semester, I am taking a course about Human Computer Interaction (HCI). I had no idea what to expect coming in to this class. I thought it would just be about how humans interact with computers. As the semester went along, I slowly realized that this course revolves more around the concept of design. The way we interact with everyday items depend on how good or bad it is designed. The main text that I'm reading for this course is called The Design of Everyday Things by Donald A. Norman. I'm not much of a reader but this book is pretty interesting. The book is outdated but the examples that he provides while explaining the concepts are clear and that makes things easier to understand.

Each chapter begins with a real life situation. I really like this way of organizing the text because it's easier for me to understand the concepts. The main principles in terms of design that I got from the first chapter are visibility, mapping, and feedback.

Visibility basically is the labeling part of design. An everyday example of this is a computer keyboard. Each key is labeled appropriately so that it's visible for us users. For users that aren't too familiar with the keyboard layout, visibility enables them to use knowledge that's available in the outside world. So instead of them trying to remember what key corresponds to to what, the label on the keys will give this information thus reducing stress inflicted upon the user. In today's world, visibility is neglected in designing things to make way for "looks." Take mobile gadgets for example. Some buttons aren't marked at all so sometimes there's no way of telling what that button would do before pressing it.

We all know that pressing the power button turn on/off something, pressing the letter J on the keyboard inputs that same letter. We know this because those things are designed to map out with their respective outcome. Poor mapping occurs when a single thing is mapped out to do multiple things. Norman used the telephone as an example of bad mapping. One of the buttons on his telephone example is mapped out to hold, park, or transfer calls. His example wasn't labeled appropriately so bad visibility is shown. I believe that visibility and mapping goes hand in hand in the design process.

For a user to know if their action was taken, the designer needs to implement a feedback mechanism. Many smartphones in the market today are equipped with touch screens. Manufacturers enables haptic feedback so that the device vibrates when the user makes a selection. This example has a tradeoff in terms of battery life. Because UI navigation heavily relies on the user touching the screen, it means that the device is constantly vibrating which sucks a lot of battery life. I always turn this feature off because I rely more on visibility for feedback with my mobile device.

It clearly takes a lot of thought when designing not just software but anything in general. I think that catering the design according to the intended users are important rather than just doing whatever works for the designer. This is where research and studies come first to help with the design process. But no matter how well you design a product, users will always make an error. We are humans, no one is perfect. This is why the designer must also implement the appropriate responses when the user makes an error. A cool example of error detection/correction is the swype technology on android smartphones. This technology enables the user to swype around the software keyboard instead of the traditional tapping method. It's algorithm is smart enough to know the intended word that the user is trying to type. Basically you swype from letter to the next till the word is spelled. But what if the user uses shortcuts words that aren't in the dictionary? Swype is smart enough that it learns the user's custom words by typing it the normal way. Swype adds the new word to the library so that the user can just swype it next time. A lot of times, swyping a certain way can yield multiple result. Swype addresses this issue by having a pop up of words that matches that pattern. The user can quickly tap the intended word and continue swyping. This method makes user input much more efficient and even faster than using physical keyboard on mobile devices. I want to post example pictures of how this technology works but I can't find a way to take a snapshot while trying to swype at the same time. I'll update this post once I figure that out.

Finals week is just around the corner...

2010-05-04T07:42:00.000-07:00

Finally made some progress this week after being stagnant for a while. We tried to tackle our database problem lately with a less efficient solution but it seems to be working so far. So far we only have one verification working (Text Input). Our goal is to make sure that one verification works perfectly so we can apply the same to the other two verification types. The following screenshot shows the text field when a user selects an activity.

This next image shows a list of available activities. It also displays a list of activities that the user participated with.

Lastly, this screenshot shows the backend side where the admin can view a list of user submitted activities for confirmation. This is where the admin can confirm or deny the submission.

We still have a long way to go but I know our group will pull through. Summer, are you here yet?

-David Joel Lazaro

Birthday Weekend Over :( back to work

2010-04-26T18:05:00.000-07:00

Took a little break last week to celebrate my 23rd birth anniversary :D. Nothing really much to say about our project at the moment. Still working and getting stuff done slowly but surely.

One interesting thing that I started recently was my Android development. This is a side project that I've been meaning to do since it's free compared to Apple's $100 dev fee platform. I've set up a separate workspace in Eclipse for my Android apps. Right now I'm still in the learning phase. Still trying to familiarize myself with it. So far it's not too bad because I'm coding in Java. Here's a little screen shot of what I have so far:

I can almost see the finish line....

2010-04-20T04:14:00.000-07:00

Wishes do come true! We get to stay in the same group and continue working on this project for the rest of the semester! Only couple weeks of school left and our group is planning on finishing strong. Our current status is still trying to catch up with the other CMS group. We might be a little behind schedule but I think that we are on the right direction and I'm confident that we can pull through.

Right now we are still trying to figure out how to approach the verification type aspect of our Joomla component. We have some ideas to implement so it's a work in progress. Not sure if I mentioned it before but there are three types of verification for this component. A text input, confirmation code, and an upload image form. The following image is the schema that we are currently working with.

This schema might change as we are constantly trying to improve our component. After we finish developing this component, we plan on publishing the final package so that the general public can download and install this on their own Joomla websites. With our DeveloperGuide, we hope that any developer can tweak it to achieve their own requirements. There's a lot of things to do so it's time to do work son!

-David Joel Lazaro

Joomla module madness

2010-04-13T06:09:00.000-07:00

Wow this has to be the most challenging milestone so far. After learning that there's no pre-made module out there that would satisfy the UseCaseActivity, we had to come up with our own component. Unfortunately we didn't satisfy every single requirements for this milestone but I feel like we still accomplished something because our team had to create the component from scratch. So without further ado, lets do a quick tour of what I worked on for this milestone. By the way, before I continue, most of the work I've done was for the back-end of the system.

The first screen shot shows the back-end login screen. Here we have two login modules. One can login with a regular Joomla username and password, and the other uses UH's CAS login service. The UH CAS login module will probably be the main module used for logging in. I just left the other module on so that if the CAS service is down, I'm still able to login to the system. I also finally managed to fix the bug that won't delete the cookie that stores the CAS login information. Now whenever someone logs out of the back-end, they would be prompted to sign in again by UH CAS service.

The next screen shows the back-end's home page. Our main focus here is the addition of Activity Manager in the components menu. Clicking that menu item will take us to the component's main page.

So here is what we have so far in terms of the admin side of the component. Shown here is the main page of the UseCaseActivity component that we created. We have preloaded some sample activities as show in the image. Most of the menu button at the top works except the publish/unpublish buttons. Those are still a work in progress. So far, this component is able to create, edit, and delete an activity. We made the activities in the table linkable so that if we click on one of them, it will take us to the edit page where we can change the details of the activity.

Here is the page with all the forms that we need to fill out to publish an activity. This part was a real pain in the butt to create because the tutorial I was following is outdated. For some odd reason, the Joomla class that I was using was renamed in the new API update. After that problem was fixed it was smooth sailing.

In this screen shot we see the database part of the component. I had to create the table that would hold the information we submit from the forms page. The administrator would never deal with this part of the website. I'm just showing it to show that the component is indeed saving the information the right way.

This last screen shot shows our updated DeveloperGuide. We've added information about our current component development. There's still many things to do and a lot that we can improve for this Joomla prototype. My hope is that we don't get shuffled around and continue developing for this project. *Crossing fingers*

-David Joel Lazaro

Joomla Modules: Time to Program

2010-04-05T12:30:00.000-07:00

After last week's meeting, it was clear that our group was taking the wrong approach for our goal this milestone. We have the UseCaseActivity all laid out for us but were trying to implement it the wrong way. Our group was looking for modules that would implement most if not all of of those requirements. The problem is, there is no such module that would take care of the whole use case for this milestone. Realizing this two weeks before the end of milestone, I feel our group is way behind now because of our wrong approach to the problem.

Now to start catching up, I've been reading up and watching tutorials on how to develop our own Joomla module that would support the use case of activities. I've been reading up on Joomla API and brushing up my PHP so that we can start ASAP. Android development will have to wait until I'm done with this semester's projects....

Done with Spring Break...

2010-03-29T14:39:00.000-07:00

That break went by super fast! Can I get a rewind? Home (Maui) was super relaxing. It was a great time to chill and hang out with family and friends back home. But now it's time to get back to business and continue working on the Dorm Energy Competition website. As I mentioned, I will now be working with Nate as a group. Our main focus for this milestone is to figure out how the activities and goals are carried out for the competition. So far we came up with a bunch of "activity manager" type of modules that we will be testing for the next coming days.

On a side note, I've downloaded the Android SDK last week. Being a phone geek, I want to start learning how to develop mobile apps. I currently have an iPhone but Apple requires a fee to to be a developer. Android is free and is really picking up since it first came out. Didn't have the time to set up everything on my machine yet but I will soon. I'll blog about it later once I have everything set up and running. That's all for now.

-David Joel Lazaro

Milestone 3: Time to collaborate!

2010-03-15T12:31:00.000-07:00

Milestone two came and went and now we are halfway through the semester. Our Joomla prototype has come a long way since the project started but there's still a lot of work to do. We are down to two CMS for this milestone. Our group dropped Silverstripe and dotCMS to focus more on Drupal and Joomla. My partner, Nathaniel Ashe, will be working with me to continue development for Joomla. Our plan is to continue adding features needed for the competition and combining them together at the end.

For this milestone, our focus shifts from mockups to actually developing the more necessary features of the competition like commitments, activity, and goal processing. This week, we plan to work on the illustration of kukui nuts accumulated by each floors. By the way, Kukui nuts is the point system used for the competition. So the more kukui nuts you have, it means the more points you accumulated. We are looking at using Google chart APIs for this part of the prototype. Lots of work needs to be done but collaboration should ease up the work for us a little. Stay tuned for more updates later.

-David Joel Lazaro

End of Milestone 2

2010-03-09T06:00:00.000-08:00

Here we are finally at the end of milestone 2. This version of the Joomla mockup site is better and contains some new useful features for the dorm energy competition. Let's start by having a tour of the updated mockup site.

Here we see the homepage that the general public can access. Currently it contains a featured youtube video, a chart that shows the energy usage of the dorms, a slideshow, and a little description of what the website is about. Also on the left is the Login button that uses the UH CAS login for authenticating the participants.

The user will be taken to this page once they click on the Login button.

If the user tries to login is not listed as a participant, they will be redirected back to the homepage with an error message. Before I forget, if you look at the right side of the top menu, a random tips ticker is displayed. A new tip is displayed every time a page is loaded.

This is where things change depending on what type of permission the user has. The screen shot on the left shows the homepage for an administrator while the one on the right shows the homepage for a regular participant. There are some noticeable differences. The administrator will have an extra item on the top menu named Admin. This takes the user to the admin page where they can modify the website.

The admin also has extra items in the user menu on the left column of the page. These extra options are for adding content to the site. You'll also notice a bunch of edit buttons in the homepage. This is because the administrator have the ability to edit these items. Those edit buttons are hidden for regular participants.

Remember the error that shows up when a non-participant tries to login? Joomla actually creates a user for them but by default they are disabled. The administrator has the ability to grant them access by enabling them or the admin can also delete the user.

Nothing new with the forums page so moving along.

This page provides users with a brief overview of a Dorm Energy Competition. There are videos which will allow individuals to browse through several videos pertaining to Dorm Energy. It also contains links to other universities doing dorm energy competitions. The Resources menu contains three submenu pages, Dorm Energy, Energy Hub, and Have Fun. Only the Dorm Energy page is implemented in this mockup.

Next is a work in progress stoplight page. This page is mainly to test the stoplight group's google gadget app.

This page shows the user information about the Dorm Energy Competition.

Next is a work in progress stoplight page. This page is mainly to test the stoplight group's google gadget app.

The kiosk serves as the billboard page that will be displayed in tv monitors. This gives people a general info about the dorm competition at a glance.

This is the help page of the dorm competition website. It includes contact info incase users run into problems using the website.

This page shows upcoming events related to the competition. This menu item only shows up once the user logs in successfully.

The last two screen shots shows how the user can edit their personal info. They also have the option of posting a profile picture.

For more information about this project, please visit Google Project Hosting. There's info on how you can download and give this mockup site a testdrive on your own server. You'll also find the current status of the project there (ie. what works and what doesn't work, bugs, etc.). I will continue working and improving this prototype website.

-David Joel Lazaro

Lots of catching up to do..

2010-03-01T11:40:00.000-08:00

After being stuck with trying to fix the CAS login, Professor Johnson suggested that we move on to other parts of the mockup. I got caught up with this bug and now my Joomla mockup is behind others' CMS. So this final week of Milestone 2 will be dedicated to pumping out as many webpages as I can to catch up and have a close-to-functional website for the dorm energy competition.

For the next coming days I have some important features lined up to be implemented in my mockup site. I might also change the theme (CSS) of the website. If I find one that looks better and easier to work with then I might implement it before the end of the second milestone. Once I have enough pages done I will update you guys with screen shots of the mockup site. I have a feeling this week will be a long one..

-David Joel Lazaro

Joomla Mockups Galore

2010-02-23T00:23:00.000-08:00

So the past week was all about building the mockups that the design group puts in the project wiki page. So far everything is going along pretty smooth. The only issue that I came across so far was the positioning of the boxes for each tab. My Joomla template has two columns for content. The left side is for other menu items such as the user menu and the latest discussion module. I still have no luck fixing the logout problem I have with the UH CAS login. I've looked at the php files for the external login module that I'm using the CAS with and I can't seem to find where it's doing the logout part. The good news is that I've read the support document from ITS and there might be an easier way to fix the logout bug that I'm having. Fixing this bug is still in my top priority for this milestone.

Another thing that I tried this past week was setting up the mockup site to a host server. I signed up for a free web hosting account at http://www.000webhost.com/. Setting up the database part was a cake. I simply exported my local database and imported it on the host server. Uploading the actual site files was the part that gave me hell. I ended up working on it for about 5 hours straight trying to get everything to work. Basically FTP won't upload some of the files from my machine. Still not sure why it wasn't letting me. I ended up trying the One Click site restore option from the host server. I had to zip the site files from my machine and upload it that way. The problem was the host would extract the directory on its own folder and not in the public folder. What I had to do was use the server's GUI setup to move the files out of that directory and into the public directory. So after about 5 hours and many trial and error, I finally have the test mockup up and running in the host server. I did this only for testing and learning purposes. This was not required for the project but I think it's a good way to learn things for future work. Stay tuned for more updates :)

-David Joel Lazaro

Plans for Milestone #2

2010-02-16T01:03:00.000-08:00

We were really productive with the first milestone for this project, therefore we are now ready to move on to the next. So far Joomla has been on the lead in terms of getting the things we need to work. But we aren't ready to give up on the other CMS' yet. For the next milestone, we will be shifting from just getting things to work with the CMS on to actually following a mockup to replicate a somewhat final product. This way, we might discover something about the other CMS that we didn't know from the first milestone.

As I mentioned, we will be following actual mockups now. Our approach will stay the same by trying to implement things the way the CMS wants to do it. It's quite difficult to force the CMS to do something for us first beginners. One of our main focus for the next coming weeks is to try and separate the content depending on what privilege the current user has. Our site will have three users, public, admin, and participant. Each different users will be able to access different contents. Some of these features are already present in my current Joomla mockup. It's not perfect yet so I have to clean it up. I will be focusing on how the admin account will be able to administer the site using the frontend tools instead of loggin on the backend. By the end of milestone 2, we are hoping to have a usable website for the competition. Stay tuned for more updates.

-David Joel Lazaro

Kukui Cup Tech's 1st Milestone

2010-02-07T23:37:00.001-08:00

After weeks of working with Joomla, I now have the ability to create and manage simple websites. I've learned a lot since we started working on the Kukui Cup project. This post will go through the implemented functionalities that can be used for the Kukui Cup competition.

This is the public home page. I made it so that public and registered users see different articles on the front page of the website. My public front page contains an RSS feed to Forbes.com's energy news and a sample chart made from Google Docs using their Visualization API. The energy news feed keeps the public on news that relates to the goals of this project such as energy literacy. The chart can be used to track of the daily energy usage of the participating buildings.

Another working feature for the Joomla mockup site is the implementation of UH CAS Login. I implemented it using the External Authentication plug in for Joomla. Once installed and configured, a UH user can login in fine. The only problem right now is the Logout part of this plugin. The CAS login uses session that the browser stores in memory. The plugin doesn't destroy the session instance when logging out. This results in the previous session being reused if someone tries to login right after a logout. I'm still working on getting this problem fixed. The author of the plugin is currently unavailable because he is helping with the next release of Joomla. He won't be updating the plugin until around summer time.

Once logged in, a different frontpage will be seen by the user. The registered user has access other parts of the website now. The frontpage now has a Google Calendar that would lists events for the competition. A Google Gadget is also implemented in the registered user's frontpage. For now a gadget that displays the top Green Products at Amazon is good to have. Later on the Stoplight gadget would be added to this page once its done. There's also a User Menu module on the left side which can be expanded as needed later on in the competition. The Latest Discussion module shows the latest posts from the competition forum. A workflow module is also implemented on the right. This can be useful later on for the competition administrator.

The next part is the Discussion Forum for the competition. The administrator can tweak this forum for whatever the needs of the project website. This forum is implemented by installing the Kunena plugin. The cool part of this is that it's fully integrated in the project website meaning its not running on another database. This eliminates the need for dual logins. Every website user would have a forum account automatically.

The standings page shows the implementation of two charts using Google Visualization API. Both were made from Google Docs spreadsheet. This makes it very easy and simple to create charts that shows the buildings' energy consumption. It's also easy to update the charts. Simply update the spreadsheet and Google Docs and the charts should be updated.

-David Joel Lazaro

Joomla: Status Update

2010-02-01T21:43:00.000-08:00

So it's been weeks since this project started and I like our group's progress so far. In last week's meeting, we discussed the difficulties we faced trying to re-create the current mockup. We agreed that it's not the best way of creating a demo mockup for the competition website. Instead, we tried to replicate the mockup the way the CMS wants to do it. In other words, try to replicate most of the functions seen in the mockup even if it doesn't look exactly the same as the mockup images.

Last week, I was stuck trying to get phpBB3 to work with Joomla for our forum. I stumbled upon a Joomla plug in called JFusion. It's main purpose is to integrate other software like phpBB3 into Joomla. Installation was easy as always with Joomla. The problem is that JFusion failed to do what I wanted it to do. The dual login module of this plugin wasnt working for some reason. I spent hours reading the forums and other websites for possible fix but failed to fix the problem. After two days of trying to get it to work I finally gave up and looked for ano

ther way to get a forum running for our project. This is when I found Kunena. Kunena is so much easier to work with and the best part, it's integrated in Joomla as a module! No need for dual logins because every website user will be part of the forum. I also like that it opens up within the Joomla website instead of going to a whole new different page.

Another goal that we achieved this past week was the implementation of Google Gadgets. It's actually pretty simple to put any gadget in our Joomla website. I installed a Joomla module called Mod HTML. This allows developers to copy and paste a script and act as a module in

Joomla. I then did some manipulation to get the module to be in an article so that I can post it in the home page once the users log in. So far everything is running smooth. I have a Bejeweled game gadget on the home page of our Joomla website. I also tried to implement a work in progress Stoplight gadget that the other group is working on.

For next week, I will try and add more content to the website to have a fully working Joomla mockup site. Another feature that I will try to implement is UH's CAS login. This is what UH uses to authenticate the users of their web services. Below are some screenshots of what I have so far in Joomla.

-David Joel Lazaro

Joomla!: My First CMS Experience

2010-01-25T13:08:00.000-08:00

Last week, our kukui tech prototype group's task was to narrow down our selection of CMS for

the project. After our first group meeting with Professor Johnson, we now have a better idea on what to look forward to with the project. Our initial comparisons consisted of 10 different CMS. We read up on Anahita, dotCMS, Drupal, Elgg, Joomla!, MODx, Ning, Pligg, Silverstripe, and Wordpress. We found a lot of good information about these CMS. We setup our review by categories which were based on what we already knew about dorm energy competition. The categories that we gave importance were ease of use, social networking, and

extensibility. We then decided as a group to select dotCMS, Drupal, Joomla!, and Silverstripe to do actual testing. My task for the coming weeks is to get familiar with Joomla and try to create mock up pages for PublicHomePage and StudentHomePage.

So far I have set up my machine (Macbook Pro) to be able to host and manage websites locally with the help of MAMP. MAMP allows me to set up my machine to act as a personal web server. After setting up the web server, I went ahead and downloaded a copy of Joomla. Setting everything up from MAMP to Joomla was pretty easy. So far, all I have are the default pages that Joomla provides. I'm still getting used to how everything works by playing around with the backend administrator settings. There are lots of things to be learned and hopefully by next week I will have a full page mockup.

-David Joel Lazaro

New Semester and New Projects

2010-01-19T02:14:00.000-08:00

This semester, our software engineering class is all about UH Dorm Energy Competition. Our main goal for this semester is to plan and build everything for the competition for next Fall. Our class is divided into groups. Each group has a specific task that benefits the overall project. For the first milestone, I was assigned in the Kukui Cup Technology Prototypes. Our group's goal is to explore various technology infrastructures for the dorm energy competition.

For this week, our group's task is to research content management systems. So far I have read articles and watched videos about CMS such as Drupal and Joomla. Other group members are doing the same. Our plan is to meet up before our first group meeting with Professor Johnson and discuss everything that we researched so far. We will then try to come up with the best technology out there that we can implement in the dorm energy competition. The way we intend to accomplish this is by creating categories and grading each technology that we researched on. We will then tally the scores and discuss the selection before presenting it to Professor Johnson.

-David Joel Lazaro

Software Engineering Experience

2009-12-18T15:27:00.000-08:00

Taking this course really helped me mature as a developer. I learned so much in just one semester. The thing that I liked the most in this class is that we worked on real world applications unlike ICS 111 and 211. Another aspect of the course that I liked is the collaboration of students. In the past we were not supposed to share our work with other student in class. This course is proof that two minds are better than one. It's good to work with other people once in a while. I think it's a win-win situation because everybody gains from collaborating with each other.

I mentioned that collaboration is the best part of this course for me. I've met some awesome people and I'm glad that I was paired up with them. Even though there were times where it was really tough for us working late at night at Sinclair, we were able to keep the morale up high. The tools that were introduced to us in this course will be really helpful in the future as a developer. Version control like SVN and software ICU are some of my favorites. I'm actually looking forward for the next level of this class.

-David Joel Lazaro

Ecologineers v2.1

2009-12-18T15:06:00.000-08:00

Our web application has come a long way since version 1.0. We've done a lot of bug fixes and added a couple of new pages that gives user's useful information. One of the pages we've added was the Home page. This is simply an introduction of our web application and what the other pages does. The second page that we added is the StopLight page. This page provides the user information depending on the carbon intensity of SIM_OAHU_GRID. It has four categories, green, yellow, red, and no data. This gives the user an idea of when they should be plugging their devices to the outlet. The third page is just a modified version 1.0 grid info page that displays the carbon intensity chart for SIM_OAHU_GRID. The user can now select a start and end date for the time period that they want a chart generated for. The user can also select from a pull down menu SIM_OAHU_GRID's sub-sources.

We tried to implement some extra credit features to our web application. One of them is the addition of nice urls for the links. Instead of the wicket gibberish url that it displays in the address bar, it now shows a nice bookmark-able link that is easier to remember. This means that the StopLight page is now called "stoplight" and the GridInfo page is now called "gridinfo" in the address bar of our browser. We also added an ajax page refresh for the StopLight page. What it does is it refreshes the page every minute so that it can update the users quickly instead of waiting for another hour to manually refresh the page.

Working on this application thought me some valuable lessons. It's clear that one person can only do so much. After trying to implement something for hours, I had to walk away from it and pass it to one of my group members. It's also nice to learn something new. The wicket framework can be really useful if I continue to learn it.

To try our updated web application, click here.

-David Joel Lazaro

GreenDepot Review

2009-11-24T17:12:00.000-08:00

In summary, GreenDepot is on the right direction and just needs to fix some major bugs to get their application running smoothly. Right now the application is dependent of Ant. I would check the jar.build.xml to see if it's compiling the needed components for the system to run. I also suggest that a separate session class be created for getting and setting user input. Software ICU and Continuous Integration data shows that the group was working on it consistently. To view my full review, click on the link below.

GreenDepotReview

-David Joel Lazaro

Ecologineers Wicket Application

2009-11-23T09:22:00.000-08:00

After working on WattDepot, it's time to put it in practical use by building a web application that can take advantage of it. We had to build a wicket application that shows the carbon intensity of a certain day. Our group name is Ecologineers. My partners for this project were Paul Galiza, Shaun Ramento, and Jarret Mizo.

Overall I believe that the project went well. Everybody did what they can to contribute to the project. We helped each other out when one needed help. The only thing I observed that got in our way of working on this project was our other class works. Me and Paul have midterms and C++ homework to work on. Meanwhile, Jarret and I also had some lab report to do for our networking course. I think we got most of the job done because we were always able to meet and work on the project as a group.

As for the current state of our application, our group was able to implement most of the requirements. We just couldn't tackle a couple of bugs due to time limit. One of the things that doesn't work is the color coding of the table in the webpage. It shows the text Red, Green, and Yellow instead of the actual color. We only need some more input validation in our date entry forms. Our system could also use some more test cases as you can tell from our hackystat image above. There were times where the system wasn't touched at all because we had other stuff to do. But when we do work on it, we all do it together as a group.

Click here to download and try our wicket application.

-David Joel Lazaro

WattDepot Ekahi Version 2.0

2009-11-16T07:04:00.000-08:00

This assignment enabled us to correct the mistakes we made in the first version of our WattDepot system. Armed with better knowledge after being reviewed by our peers, our group made sure that the second version of our system is way better than the first. The main fix that we had to do was refactoring our code and break it up in different classes for each commands. Doing this enabled us to clean up the system. It also made test cases easier to do because we now have each commands return something rather than being void.

After doing the refactoring, we were able to implement the commands in a much more efficient way. We took many unnecessary codes out also. I believe that we were able to fix most of the issues that the reviewers have raised. The design of the system went from having one giant class to each commands being in their own class. At the end of it, we were able to get a 62% coverage in our system. I think if we worked on it some more then we could easily bring that coverage up.

My partner (Paul Galiza) and I worked pretty well as a team. We both had other things to do outside of this class but we were still able to pull through and work as a team with no problem. We met outside of class to work on the system as much as we can. In our group, we pretty much just worked on whatever was needed to be done. I think we both did a good job of carrying our weight when it comes to working on the system.

A new concept that was introduced to us while building this version of the system is Software ICU. Software ICU is a way of tracking the "health" of our project by monitoring the vital signs of the system. To do this, we used the system called hackystat. In a nutshell, hackystat monitored almost everything that we did involving the project. The screen shot above shows the current health of our system. Although it could be improved, our group really worked hard on getting the system up and running with minimal flaws.

The following questions are something that we are able to answer after getting our system up and running:

What day and time during the month was Oahu energy usage at its highest? How many MW was this?
The timestamp 2009-11-02T20:00:00.000-10:00 netted a high 995MW.
What day and time during the month was Oahu energy usage at its lowest? How many MW was this?
The timestamp 2009-11-02 netted a low 493MW.
What day during the month did Oahu consume the most energy? How many MWh was this?
No available data found for this month to answer this question.
What day during the month did Oahu consume the least energy? How many MWh was this?
No available data found for this month to answer this question.
What day during the month did Oahu emit the most carbon (i.e. the "dirtiest" day)? How many lbs of carbon were emitted?
The timestamp 2009-11-05 is one of the dirtiest day which emitted 29,959 lbs or carbon.
What day during the month did Oahu emit the least carbon (i.e. the "cleanest" day)? How many lbs of carbon were emitted?
The timestamp 2009-11-07 is one of the cleanest day which emitted only 22,908 lbs of carbon.

Click here to download the Ekahi branch of the WattDepot system.

-David Joel Lazaro

Code Review Experience

2009-11-11T02:32:00.001-08:00

Reviewing each other's WattDepot systems clearly has a positive outcome. Clearly the other groups had different ways of building the system. Its good to know that I'm able to help them out by pointing out the errors so that they can improve their system. Reviewing the other systems also helps me because I can see how to improve our system also. I saw some better ways of implementing some methods that would make the system much more efficient.

The best way of responding to a code review is by taking it in positively. The reviewers of our system pointed out many things that we can improve on. They've spotted errors that we didn't catch ourselves. They have suggested many things to improve our system. The next part now is to try and implement those suggestions and fix the errors that they found.

-David Joel Lazaro

Code Review: WattDepot Eono Branch

2009-11-09T04:32:00.000-08:00

This is my software review of the WattDepot System Elima branch by Scott Wong and Kelli Sawai. The template I used was provided by Philip Johnson.

A. Review the build

A1. Download the system, build it, and run any automated quality assurance checks (use "ant -f verify.build.xml"). If any errors occur, note these in your review.

-Build Successful

B. Review system usage

B1. Run the system. Exercise as much of its functionality as possible. Does it implement all of the required features?

help

-Works

quit

-Works

list sources

-Works

list summary {source}

-Invoking the command does nothing but returns to the command line interface.

list sensordata {source} timestamp {timestamp}

-Works

list sensordata {source} day {day}

-Doesn’t check the data for the duration of the day.

list power [generated|consumed] {source} timestamp {timestamp}

-Works

list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}

-Works

list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}

-Invoking “>list total energy generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30” results in the following error:

Exception in thread "main" org.wattdepot.client.BadXmlException: 400: Range extends beyond sensor data, startTime 2009-11-15T00:00:00.000-10:00, endTime 2009-11-15T00:00:00.000-10:00: Request: GET http://server.wattdepot.org:8182/wattdepot/sources/SIM_WAIAU_8/energy/?startTime=2009-11-15T00:00:00.000-10:00&endTime=2009-11-15T00:00:00.000-10:00&samplingInterval=30

at org.wattdepot.client.WattDepotClient.getEnergy(WattDepotClient.java:566)

at org.wattdepot.client.WattDepotClient.getEnergyValue(WattDepotClient.java:614)

at org.wattdepot.client.WattDepotClient.getEnergyGenerated(WattDepotClient.java:637)

at org.wattdepot.cli.ListCommand.listTotalGenerated(ListCommand.java:362)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:109)

chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}

-Can’t get this command to work properly. Nothing happens when I invoke the command.

B2. Try to break the system by providing it with unexpected input. Can you make the system crash or generate a stack dump? If so, note the input that caused the failure.

>list total energy generated SIM_WAIAU_8 day 2009-11-15 sampling-interval 30

at org.wattdepot.client.WattDepotClient.getEnergy(WattDepotClient.java:566)

at org.wattdepot.client.WattDepotClient.getEnergyValue(WattDepotClient.java:614)

at org.wattdepot.client.WattDepotClient.getEnergyGenerated(WattDepotClient.java:637)

at org.wattdepot.cli.ListCommand.listTotalGenerated(ListCommand.java:362)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:109)

>list sensordata SIM_OAHU_GRID timestamp break

should never happen.

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.ListCommand.listSensorDataTimestamp(ListCommand.java:320)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:65)

>list sensordata test day test

should never happen.

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.ListCommand.listSensorDataDay(ListCommand.java:92)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:77)

C. Review the JavaDocs.

C1. Does the System Summary (provided in an overview.html file) provide an high-level description of the purpose of the system? Does it explain how each of the packages in the system relate to each other? Is the first sentence self-contained?

-The system summary provides a high-level description of the purpose of the system. Doesn’t really explain how the packages in the system relate to each other because only one package exist.

C2. Do the Package Summaries (provided in package.html files) provide a high-level description of the purpose of the package? Do they explain how the classes in the package related to each other? Is the first sentence self-contained?

-Main package summary refers to an example of WattDepot interaction.

C3. Do the Class Summaries (provided at the top of each .java file) provide a high-level description of the purpose of the class? Does it provide sample code for clients of the class, if useful? Is the first sentence self-contained?

-Accurate high-level description of the purpose of the class. Doesn’t provide sample code for clients of the class.

C4. Do the Method Summaries (provided before each method) explain, from a client-perspective, what the method does? Do they avoid giving away internal implementation details that could change? Do they document any side-effects of the method invocation? (Note that you can click on the method name to see the source code for the method, which is helpful to assessing the correctness and quality of the javadoc.)

-The method summaries does a pretty good job on explaining what the method does. They were able to do it without giving away internal implementation details.

D. Review the names

D1. Do another pass through the JavaDocs, this time concentrating on the names of packages, classes, and methods. Are these names well chosen? Do they conform to the best practices in Elements of Java Style, Chapter 3? Can you propose better names?

-Naming scheme looks fine.

D2. Once you have reviewed the names displayed in the JavaDocs, review the source code for internal names in the same way.

-Source code internal names looks fine also.

E. Review the testing.

The system should provide a useful set of test cases.

-Only test present is the example test provided by the instructor.

F. Review the package design

F1. Consider the set of packages in the system. Does this reflect a logical structure for the program? Are the contents of each package related to each other, or do some package contain classes with widely divergent function? Can you think of a better package-level structure for the system?

-System only contains one package. Maybe create a separate package for commands class, test cases, etc.

G. Review the class design

G1. Examine its internal structure in terms of its instance variables and methods. Does the class accomplish a single, well-defined task? If not, suggest how it could be divided into two or more classes.

-After going through the instance variables and methods of the system, I conclude that the classes in the system could be divided into separate classes instead of one big class that does many things. This will make the code easier to read and makes creating test cases easier.

G2. Are the set of instance variables appropriate for this class? If not, suggest a better way to organize its internal state.

-Looks fine.

G3. Does the class present a useful, but minimal interface to clients? In other words, are methods made private whenever possible? If not, which methods should be made private in order to improve the quality of the class interface to its clients?

-No private methods observed in the system.

H. Review the method design

H1. Does the method accomplish a single thing? If not, suggest how to divide it into two or more methods.

-Each methods seems fine in accomplishing a single thing.

H2. Is the method simple and easy to understand? Is it overly long? Does it have an overly complicated internal structure (branching and looping)? If so, suggest how to refactor it into a more simple design.

-The methods looks fine. They are easy to follow and understand.

H3. Does the method have a large number of side-effects? (Side effects are when the result of the method's operation is not reflected purely in its return value. Methods have side-effects when they alter the external environment through changing instance variables or other system state. All "void" methods express the results of their computation purely through side-effect.) In general, systems in which most methods have few or zero side-effects are easier to test, understand, and enhance. If a method has a large number of side-effects, try to think about ways to reduce them. (Note that this may involve a major redesign of the system in some cases.)

-No side-effects observed.

I. Check for common look and feel

I1. Is the code implemented consistently throughout the system, or do different sections look like they were implemented by different people? If so, provide examples of places with inconsistencies.

-The code seems to be consistent throughout the system. It doesn’t look like two people implemented the code.

Code Review: WattDepot Elima Branch

2009-11-09T03:25:00.000-08:00

This is my software review of the WattDepot System Elima branch by Anthony Xu and John Mack. The template I used was provided by Philip Johnson.

A. Review the build

The first part of any review is to verify that the system builds and passes automated quality assurance.

A1. Download the system, build it, and run any automated quality assurance checks (use "ant -f verify.build.xml"). If any errors occur, note these in your review.

-Build Successful

B. Review system usage

If the system builds, the next step is to play with it.

B1. Run the system. Exercise as much of its functionality as possible. Does it implement all of the required features?

help

-Works

quit

-Works

list sources

-Parent and Description is missing from the output.

list summary {source}

-Command only returns the string “list source summary”

list sensordata {source} timestamp {timestamp}

-Works

list sensordata {source} day {day}

-Output of the command is not formatted correctly. Also doesn’t check the data for the duration of the day.

list power [generated|consumed] {source} timestamp {timestamp}

-“No such command” output when I tried to invoke the command listed in the help menu.

list power [generated|consumed] {source} day {day} sampling-interval {minutes} statistic {max|min|average}

-“No such command” output when I tried to invoke the command listed in the help menu.

list total [carbon|energy] generated {source} day {day} sampling-interval {minutes}

-“No such command” output when I tried to invoke the command listed in the help menu.

chart power [generated|consumed] {source} {startday} {endday} sampling-interval {minutes} file {file}

-Can’t get this command to work properly. I get the following error:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 9, Size: 9

at java.util.ArrayList.RangeCheck(ArrayList.java:547)

at java.util.ArrayList.get(ArrayList.java:322)

at org.wattdepot.cli.command.ChartPowerCommand.doCommand(ChartPowerCommand.java:35)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

B2. Try to break the system by providing it with unexpected input. Can you make the system crash or generate a stack dump? If so, note the input that caused the failure.

> list sensordata SIM_OAHU_GRID timestamp 2009-

Unable to create timestamp

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.command.ListSensordataTimestamp.doCommand(ListSensordataTimestamp.java:41)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

> list sensordata SIM_KAHE_1 day day

Unable to create timestamp

Exception in thread "main" java.lang.NullPointerException

at org.wattdepot.client.WattDepotClient.getSensorData(WattDepotClient.java:372)

at org.wattdepot.cli.command.ListSensordataDayCommand.doCommand(ListSensordataDayCommand.java:41)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

> chart power consumed

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 3, Size: 3

at java.util.ArrayList.RangeCheck(ArrayList.java:547)

at java.util.ArrayList.get(ArrayList.java:322)

at org.wattdepot.cli.command.ChartPowerCommand.doCommand(ChartPowerCommand.java:31)

at org.wattdepot.cli.CommandLineInterface.main(CommandLineInterface.java:155)

C. Review the JavaDocs.

Download the system and generate the javadocs (use "ant -f javadoc.build.xml"). Navigate to the build/javadoc folder and click on index.html to display the JavaDocs in a browser. Read through the JavaDocs and assess the following:

C1. Does the System Summary (provided in an overview.html file) provide an high-level description of the purpose of the system? Does it explain how each of the packages in the system relate to each other? Is the first sentence self-contained?

-The system summary provides a high-level description of the purpose of the system. Doesn’t really explain how the packages in the system relate to each other.

C2. Do the Package Summaries (provided in package.html files) provide a high-level description of the purpose of the package? Do they explain how the classes in the package related to each other? Is the first sentence self-contained?

-Pretty clear high-level description of the purpose of the package.

C3. Do the Class Summaries (provided at the top of each .java file) provide a high-level description of the purpose of the class? Does it provide sample code for clients of the class, if useful? Is the first sentence self-contained?

-Accurate high-level description of the purpose of the class. Doesn’t provide sample code for clients of the class.

C4. Do the Method Summaries (provided before each method) explain, from a client-perspective, what the method does? Do they avoid giving away internal implementation details that could change? Do they document any side-effects of the method invocation? (Note that you can click on the method name to see the source code for the method, which is helpful to assessing the correctness and quality of the javadoc.)

-The method summaries does a pretty good job on explaining what the method does. They were able to do it without giving away internal implementation details.

D. Review the names

One of the most important (if not the most important) form of documentation in any software system is the choice of names for program elements, such as packages, classes, methods, instance variables, and parameters. Due to evolution in requirements and design changes, the name originally chosen for a program element may no longer be appropriate or optimal. An important goal of review is to ensure that the names of program elements are well suited to their function. Due to the refactoring capabilities in modern IDEs such as Eclipse, renaming need not be a burden.

D1. Do another pass through the JavaDocs, this time concentrating on the names of packages, classes, and methods. Are these names well chosen? Do they conform to the best practices in Elements of Java Style, Chapter 3? Can you propose better names?

-Naming scheme looks fine.

D2. Once you have reviewed the names displayed in the JavaDocs, review the source code for internal names in the same way.

-Source code internal names looks fine also.

E. Review the testing.

The system should provide a useful set of test cases.

-Only test present is the example test provided by the instructor.

F. Review the package design

The JavaDoc review is focussed on whether the system design is correctly explained. In this section, you start to look at whether the system design is itself correct.

F1. Consider the set of packages in the system. Does this reflect a logical structure for the program? Are the contents of each package related to each other, or do some package contain classes with widely divergent function? Can you think of a better package-level structure for the system?

-Package structure looks good and organized. This is how the structure of the system is supposed to be like.

G. Review the class design

Examine each class implementation with respect to at least the following issues.

G1. Examine its internal structure in terms of its instance variables and methods. Does the class accomplish a single, well-defined task? If not, suggest how it could be divided into two or more classes.

-After going through the instance variables and methods of the system, I conclude that not all the class in the system accomplished a single, well defined task. This is because one of the class that does the list source summary command is not complete.

G2. Are the set of instance variables appropriate for this class? If not, suggest a better way to organize its internal state.

-Looks fine.

G3. Does the class present a useful, but minimal interface to clients? In other words, are methods made private whenever possible? If not, which methods should be made private in order to improve the quality of the class interface to its clients?

-No private methods observed in the system.

H. Review the method design

Examine each method implementation with respect to at least the following issues.

H1. Does the method accomplish a single thing? If not, suggest how to divide it into two or more methods.

-Each methods seems fine in accomplishing a single thing.

H2. Is the method simple and easy to understand? Is it overly long? Does it have an overly complicated internal structure (branching and looping)? If so, suggest how to refactor it into a more simple design.

-The methods looks fine. They are easy to follow and understand.

H3. Does the method have a large number of side-effects? (Side effects are when the result of the method's operation is not reflected purely in its return value. Methods have side-effects when they alter the external environment through changing instance variables or other system state. All "void" methods express the results of their computation purely through side-effect.) In general, systems in which most methods have few or zero side-effects are easier to test, understand, and enhance. If a method has a large number of side-effects, try to think about ways to reduce them. (Note that this may involve a major redesign of the system in some cases.)

-No side-effects observed.

I. Check for common look and feel

I1. Is the code implemented consistently throughout the system, or do different sections look like they were implemented by different people? If so, provide examples of places with inconsistencies.

-The code seems to be consistent throughout the system. It doesn’t look like two people implemented the code.

Wattdepot: A Smart Consumer's Tool

2009-11-04T05:15:00.000-08:00

Last week, our class was introduced to the Wattdepot project. Wattdepot is a system that lets us store and analyze our power consumption by reading the meters. It's a great tool that gives smart consumers the ability to monitor their power consumption.

My partner for this project is Paul Galiza. Paul worked on the early parts of the system. I think Paul and I did pretty well as a team. He was always available for help whenever I'm stuck on some parts of the system.

I believe that we achieved most of the goals of this system. We were able to create all of the ten commands listed in the CommandSpecification page. A lot of time and effort were put in to getting our system done. Some of us stayed at Sinclair library overnight trying to finish our project. Paul and I pretty much just picked the next parts that was needed to be finished while helping each other out.

The biggest issue we had was creating our test cases. Our system didn't implement interfaces so we had one giant class that includes all of our commands. It was difficult to create test cases for one giant class. We will most likely modify our system later on to fix this problem. We would have done the changes but we didn't have enough time before the deadline. Click here to download our ekahi wattdepot system.

-David Joel Lazaro

Implementing Continuous Integration

2009-11-02T09:09:00.000-08:00

Continuous integration is a practice that helps developers working in groups. Basically what it does is set up a general environment that gets the source code from a repository and verifies to see if its in a working condition. It monitor's the repository continuously to check for any errors when someone commits.

We are using Hudson for implementing continuous integration. The project set up was a breeze and only took about 3-5 minutes. We set up our project in the Hudson server so that every 5 minutes, it will download the source from the repository. It will then run the hudson.build.xml file which is pretty much running the verify Ant command. When something is wrong, it emails the group to inform that an error occurred while building the project. It's very helpful because it also shows what failed and who committed the file.

Using continuous integration can be very helpful when working on a project with many committers. It tells you when the project has errors not long after you perform a commit. The only negative I see in implementing continuous integration is the time lost setting up the Hudson server. Other than that, I think that continuous integration is all positive for a developer.

-David Joel Lazaro

Study Time!

2009-10-18T23:01:00.000-07:00

Some questions to help study for this week's midterm:

1. Name one reason why using Unix based OS is better than using Windows in software development.

There's many reasons why a unix based OS is better than Windows in software development. One of them is that you don't get the usual problems that Windows users get such as getting infected by a malware and/or spyware. Stability could also be a reason.

2. Provide an example on how to properly ask a question in an online community forum.

Subject: NullPointerException when running a robot in Robocode

Body: Hello, I'm using Eclipse 3.5 on my Intel Macbook Pro running Snow Leopard. The error shows up when I try to run the robot Movement04. It throws the NullPointerException error before the robocode application gets a chance to open up.

*code here*

3. Why is it better to focus on doing one thing instead of multitasking?

The quality of work decreases if not focused on one thing.

4. Name one advantage of using automated quality assurance.

It saves precious time and money.

5. Provide an example of a JUnit Antipattern and explain it briefly.

Happy Path test validates the expected behavior of the system.

6. What automated quality assurance tool checks for proper coding standard?

Checkstyle

7. Provide an example of an acceptance test design.

Test to see if my own robot can beat a sample robot.

8. Why would a developer implement version control on their programs?

By implementing version control, we can see what types of changes were made in the system. For example lets say we have a system that's currently in version 1.1. If we compare it to say version 1.1.1, we can tell that its just a minor bug fix if the developers were following the version standards. If it was 1.2, then we know that something new or a major revision was done.

9. Name one advantage of distributed version control over centralized version control.

Everybody has their own copy of the project. If the project gets lost or corrupted in a centralized server, unless someone kept a backup, the whole thing is gone.

10. What does ANT stand for?

Another Neat Tool

Project Management with Google

2009-10-14T03:45:00.000-07:00

In this homework assignment, I learned how to use a centralized configuration manager by using SmartSVN and project hosting with Google Code. The tasks for this assignment were pretty easy if done correctly. The first thing I did was install SmartSVN on my machine. This is the program that does all the subversion work for us. It didn't take long before I got the hang of using SmartSVN on my machine. I used the "robocode-pmj-dacruzer" project to test SmartSVN.

After getting SmartSVN up and running on my machine, I then went ahead and created a new project in Google Project Hosting called "robocode-djl-dabeast." With the help of SmartSVN, I got my robocode system hosted in no time. I went ahead and tried to download the project anonymously in SmartSVN and ran ant -f verify.build.xml. The build was successful which means that everything is set up correctly.

I was able to accomplish all task except for one. An issue with Google that wouldn't allow us to add codesite-noreply@google.com as a member in our discussion list. The main purpose of this was to send out notifications whenever someone commits to the project. I filed the issue here and tried their fix but I'm still not able to generate an email after committing. I think this is the most difficult part of the assignment for me.

There is one important lesson I learned from this and that is to not "Update" my local directory when the repository is empty. I made this mistake in SmartSVN. I didn't commit the local project to the repository before I did the update and it resulted in an empty local directory.

Here are the links to my project and discussion pages:

robocode-djl-dabeast

robocode-djl-dabeast-discuss

Leave a message with your email if you want to contribute to this project :)

-David Joel Lazaro

Robocode: JUnit Testing

2009-10-07T09:00:00.000-07:00

This homework assignment was about gaining experience writing our own JUnit test codes. I think the hardest and most frustrating part of this homework for me was getting our distribution directory to import and play nice with Eclipse. I spent the whole class time trying to setup my environment inside Eclipse. Once I got everything up and running the way I wanted, it was time to brainstorm on what I should test in my robocode.

My JUnit test cases consisted of two acceptance test and four behavioral test. For my acceptance tests, I tested whether DaBeast can win half the time against the sample robots Corners and Crazy. One of my behavioral test check whether DaBeast actually goes into one of the corners of the battlefield mainly the bottom left corner. The other test checked whether DaBeast travelled near the left wall by checking if it went to the bottom left corner and top left corner. Another behavioral test was to see if DaBeast rams its opponents. Lastly, I made a test to make sure that DaBeast's firing power is within range of what I set it to be.

The easiest test to create were obviously the acceptance test. All we needed to do was assert if we won the battles half the time. The behavioral tests were the difficult ones to create for me. I think it's because I wasn't familiar with the syntax of the snapshot interfaces that were built in robocode.

I'm not really 100% sure about the quality of my test cases. Two of the tests had bugs that I can't quite figure out how to fix. My bullet power test for example takes all the bullets in the battlefield at the end of each turn. This means that it also uses the bullets of the enemy robot for testing purposes. My robot only fires either to the power of two or three. For some reason, even if I was going against SittingDuck, I would see a bullet fired with the power of 1 which doesn't make sense to me. Another test that's flawed is when I check to see if DaBeast travels next to the left wall. It only checks whether DaBeast goes to the bottom and top left corners. DaBeast moves from the bottom left corner and goes straight up to the top left corner near the left wall. If anybody can help me fix that test then I'd really appreciate it.

When I ran Emma, it revealed that all of the methods of my test cases were executed. From my experience, it seems like having your code broken down into smaller pieces and testing each of those is the easiest way to test my robot. Click here to download the distribution of my system and see if you guys can implement my test cases in a much better way :).

-David Joel Lazaro

Ant: Project Building Made Easy

2009-09-30T00:57:00.000-07:00

Ant is one of the best java programming tool I've used to date. Before Ant, it was just about writing the code, manually checking it for errors, then be done with it. Ant gives us the ability to create better software and automated quality assurance tools. This homework assignment allowed us to experience working with Ant by using robocode-pmj-dacruzer system as a template for our robots.

Getting Ant to run on my machine didn't go so well. After downloading the latest version of Ant and setting up the paths for it, I still couldn't get it to run. After some time, I came across a page that says Ant is installed with XCode tools for mac. I had XCode installed on my machine so I went ahead and check if there is a version of Ant installed by removing the new one that I just downloaded. After invoking the command ant -version, I was presented with a 1.7.0 version of Ant. I then removed that version and tried to install the newest build and the error disappeared. I then ran the ant invocations for the robocode-pmj-dacruzer system and passed all of it.

The second task of the homework was to use robocode-pmj-dacruzer as a template to implement on our own robocode project. I found that the best way to understand how Ant works is by tracing the xml files. It gave me an idea of how the build system worked. After modifying the build files, I was able to invoke ant and have a successful build.

The third task involves automated quality assurance on our project. The tools that we used for this project are Checkstyle, PMD, and FindBugs. As you all know, Checkstyle helps us developers to write codes that adhere to coding standards. In the past, I would do this manually by going through each line of the code. This quality assurance is automated by Checkstyle. After invoking ant -f checkstyle.build.xml for the first time, it flagged my code with two errors. The first error involves my use of "@date" which is not a valid Javadoc tag name. I simply removed that tag and replaced it with an @version tag instead. The other error was due to the lack of package-info.java file. I made a simple html file with the appropriate information. I rant the checkstyle build again and it flagged five more errors in my code. The first error was because I missed a period in my sentence. The other error was a missing Javadoc comment. The rest of the errors was due to missing @param tags for my methods. Checkstyle passed with no errors after my last fix. PMD reported no errors in my code which is good news. FindBugs however found one error. The error was URF_UNREAD_FIELD: Unread field. I had a variable that wasn't being used. This is a performance type of warning. All is good after removing that variable.

I may become very dependent with these quality assurance tools. They would make my future software development much more easier to debug. Also, utilizing these tools greatly cuts down the debugging time so we can focus more on making our software better.

Click here for my robocode-djl-DaBeast system.

-David Joel Lazaro

Robot's First Shot at Glory

2009-09-21T02:44:00.000-07:00

My last entry was about deciphering the enemies' strategy. Now it's time to implement what I learned and build my first competitive robot. My first shot at glory is probably the most basic robot out there. But don't let it fool you. It was able to beat five out of the eight sample robots that I reviewed in my last blog.

DaBeast

When I was trying to figure out the movement of this robot, my main concern was to avoid being hit by a bullet. I figured I might was well keep it simple for now and just move back and forth in the battle field. The movement was actually quiet effective for most of the sample robots. I also made it so that when it hits a wall, it turns around and move forward a bit to avoid hitting the wall again. DaBeast also borrowed some move from RamFire. When it hits an enemy robot, it turns to face it, then fires hard. For targeting, I simply made my robot's gun go 360 each turn to track the enemy. I made this robot so that it comes out guns blazing. It really goes for the kill as it fires a hard shot every time.

DaBeast can reliably beat Crazy, Fire, Corners, Tracker, and SittingDuck. In reality, as much as we want to, we can't really win them all. DaBeast has a hard time defeating Walls, RamFire, and SpinBot. I think I'm going to take a different route next time and modify what I believe is the best sample robot which is the Walls. The Walls robot is the most elusive one to defeat and tweaking it could make it even more deadly.

Click here if you guys want to try out DaBeast.

-David Joel Lazaro

Robocode: Studying the Enemy

2009-09-16T01:11:00.000-07:00

In Robocode, learning the way of the enemy can help in building the ultimate robot. By understanding how the sample robots work, we can combine all the good parts and come up with an awesome robot. I will be reviewing eight sample robots that came with the Robocode package. I'll review their strategy in terms of movement, targeting, and firing.

Walls

This robot's strategy is simple yet very effective. It simply moves along the walls of the battlefield. If it scans an enemy, it fires right at it. It is also smart enough to move to the opposite wall when it hits an enemy.

Ramfire

This robot clearly has destruction on its agenda. It scans the battlefield for an enemy by spinning around. Once it finds one, it goes towards the enemy and rams it. It then starts shooting at the enemy but it doesn't kill it right way. It scans the enemy's health to lower its firing power because it wants to destroy by ramming into it.

Spinbot

This robot moves in a circle the whole time. It moves away a little when it hits a wall or an enemy so that it can continue to move in circles. Once it scans an enemy, it fires at it while moving in circles. This makes it hard to fire back at it because of its movement.

Crazy

This robot moves in a "crazy" pattern. It's movement loops in left and right turns. It reverses direction when it hits the wall or an enemy. When it scans an enemy, it also fires right at it.

Fire

This robot just sits in one position and rotates its gun to scan for an enemy. If the enemy is within 50 pixels and the Fire robot has at least 50 percent life, it fires a more powerful bullet. When an enemy rams into it, it turns its gun to that enemy and fires strong bullets at it. The only movement this robot does is when it gets hit by a bullet. It turns perpendicular to the bullet and moves out of the way.

Sitting Duck

This robot does absolutely nothing in terms of movement, tracking, and firing.

Corners

This robot goes to a corner of the battlefield then moves its gun back and forth to scan for the enemy. If this robot sees an enemy before getting to the corner, it stops and fires at that enemy. Its firing power is based on the distance from the enemy robot. The closer the enemy, the stronger the bullet gets. Also, if this robot dies before most of the enemy robots, it picks a different corner to go to for the next round.

Tracker

This robot scans the battlefield with its gun for an enemy. Once it sees one, it locks on to it. It then moves closer to the enemy and fires at it. It will continue to follow that enemy until it's destroyed. When this robot runs into an enemy besides the one its tracking, that enemy becomes its new target. It also does a cool victory dance at the end of the round.

-David Joel Lazaro

The Importance of Coding Stadards

2009-09-14T05:23:00.000-07:00

Implementing standards in our coding is very important especially in today's open source world. Following the standards doesn't just help you as a developer, it also helps anyone trying to read and understand your code. Readability is probably the main reason why someone should follow coding standards. Imagine having to debug over a thousand lines of codes with no documentation or comments written anywhere. That scenario could be classified as a developer's nightmare. It would be very difficult to follow and understand how everything works. It would be difficult to find someone in the open source world interested in your code because of the lack of documentation. Why would someone waste their time trying to understand and figure out how a program works? They could be using that time to add or fix the software if coding standards were followed.

I have been following most of the coding standards throughout my college career. I'm kind of a neat freak so I want my code to look nice and easy to read. One standard that I tend to break is the use of tabs. Using tabs made everything align for me the way I want it. The problem with this is that a different environment might interpret tabs differently. Using spaces instead of tabs eliminates this problem. My problem is that I'm so used to tabbing my codes as I type them. Thank goodness for the Format option of Eclipse :).

I've edited my robocode assignment to follow the coding standards of my class. You guys can download the .jar file here.

David Joel Lazaro

CodingWars with Robocode

2009-09-09T09:33:00.000-07:00

In the past, the Java programs that I've worked on usually involves solving problems and implementing the basics of Java. Robocode has to be the most interesting Java programming that I've ever worked on. The main reason is that, it's a GAME that involves robots beating the crap out of each other. The concept is that you build your robot, have it battle one or many robots, and hope that it destroys all of its enemies. In our homework assignment, we had to build 13 robots with the following traits (taken from the assignment page):

Movement01: The minimal robot. Does absolutely nothing at all.
Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
Movement04: Move to the center of the playing field and stop.
Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
Movement06: Move to the center, then move in a circle, ending up where you started.
Tracking01: Pick one enemy and follow them.
Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).

Creating those robots familiarized us with the basics of Robocode from movement, tracking, and firing. I was able to finish all of the assigned robots with some minor bugs.

One of the things I noticed while working on this assignment was that I had to refer to the Robocode wiki and API a lot because most of the functions that I used were new to me. The robot that gave me the hardest time was Movement05. This robot had to go to each corners of the field diagonally. I was trying to figure out how to make the robot go to a specific coordinate so that I can command it to go to the corners one after the other. A couple of hours later, one of our classmates found this website that shows exactly what we wanted our robot to do. We implemented the code and voila! Movement05 did exactly what I wanted it to do. Of course I cited the website and its author in our code :) .

One thing I learned about how the robots behave is that they can be as flexible as you want them to be, as long as you program them correctly. I also learned that the robot doesn't always behave the way you want it to be :( . I also noticed that there are some kind of physics involved in the game. I noticed this when I was working on the firing robots. Their firing accuracy is higher when their gun turns slowly rather than spinning fast.

My ideal competitive robot would be finely tuned in all ways possible. Pinpoint firing accuracy and bullet evasion would be good. When I work on the advanced robots then I'll have more ideas for what can be done better for competitions.

You guys can download and try my robots by clicking this link.

David Joel Lazaro

OSS Experience: jEdit

2009-08-30T21:14:00.001-07:00

Overview

The purpose of this assignment is to familiarize ourselves with an open source project that's interesting to us. The project I chose to blog about is called jEdit. jEdit is a text editor written in Java. Java enables it to run in multiple operating systems. According to its web page, "jEdit is a mature programmer's text editor with hundreds (counting the time developing plugins) of person-years of development behind it." I went ahead and downloaded the Mac OS X package to see what the project has to offer.

Prime Directive 1

The project's main purpose is to edit text and it does it like every other text editors out there. One of the features that makes this a great text editor for programmers is its ability to be enhanced by installing plugins. jEdit has a large collection of plugins created by a "world-wide developer team." This simple text editor could be configured with the right plugins and become a very useful IDE.

PD1: Pass

Prime Directive 2

As a non-developer, this package was pretty easy to setup. It was up and running in a matter of minutes. The Mac OS X package comes in a .dmg file. Once downloaded, the dmg file mounts itself with one file in its directory. I simply copied the jEdit application file to my Applications directory. The application launched with no problems. The Download page provides an easy to follow User's guide. Another feature that I liked about the application is the display of "Tip of the Day." It's a neat way of learning the application's features.

PD2: Pass

Prime Directive 3

jEdit has a great community based development that continues to fix bugs and add features. A developer can easily join the community and start contributing to the project. A developer can contribute in the following specific category; writing/updating edit modes, writing macros, writing plugins, and fixing plugin or core bugs. From the looks of things, it seems pretty easy for a new developer like me to dive right in and modify and improve the project.

PD3: Pass

David Joel Lazaro

FizzBuzz: Welcome to Software Engineering

2009-08-30T13:55:00.000-07:00

FizzBuzz is the first Java program that I've worked on since Fall 2008. My courses last Spring were about different scripting languages and database so my Java is pretty rusty. The goal of this program is to print out the numbers 1 to 100 with a few twists. When the current number is a multiple of 3, print "Fizz", when the current number is a multiple of 5, print "Buzz", and when the current number is a multiple of 3 and 5, print "FizzBuzz". The following code is my implementation of the FizzBuzz program.


public class FizzBuzz {

public static void main(String[] args) {

 for (int i = 1; i <= 100; i++) {

     if (i % 15 == 0) {
         System.out.println("FizzBuzz");
     } else if (i % 5 == 0) {
         System.out.println("Buzz");
     } else if (i % 3 == 0) {
         System.out.println("Fizz");
     } else {
         System.out.println(i);
     }
 }
}
}

Once I got the algorithm of the program, it took me about five minutes to type and fix my errors in Eclipse. I did not have any problems with Eclipse or Java because I had everything set up even before I took ICS 413.

Before I typed this code in Eclipse, Professor Johnson gave this problem to us as our first quiz to be written on a piece of paper. Without having done some Java coding in a while, I was clueless on how to code this problem. I got the algorithm correct but my mind is still fresh with all the scripting languages I learned last semester. I realized that I have to practice more so that I don't fall behind in the later assignments. I'm hoping to come out of this class with much better knowledge and techniques on developing softwares.

David Joel Lazaro