Overview
This past week we were given our first crack at a review for our classmates DueDates Software system. Some were good, some were bad... The thing is, we were previously given a bootstrap of the software, so about 80% of the programming was done for us! The programming portion of the assignment was really simple, just simple arg handling in the main(). I feel that the real exercise of the assignment was to make use of all of the techniques and tool that learned the first half of the semester and execute something useful. The review process is nice and quick, thanks to Google Code Project hosting. The tasks/issues, commit logs, and source change logs make this a peice of cake.
Pros
Reading other people's code opens a whole new insight on things: coding styles, logic, and feedback on our own code. I find reading code that makes sense to be a treat, a lot harder to find these days. The feedback we get on your code is great, another form of constructive crisitism! Funny how this is the first time someone has ever told me to use the Scanner class vs Buffered Reader (Something I learned back in 04'). I feel that we need more peer code review in software development; I find it to be a big help when it comes to improving the quality of my code.
Cons
Its really a disappointment when you are reviewing code that is supposed to be "completed" and there are just signs of "last minute effort" all over the code. There was a group that didn't even check if the table being retrieved was the table of interest. Also comments like "Author: Philip Johnson" and "Assume the first table is the one we need. Not true in general." were ignored. The amount of time spent on the project is really reflected on the amount of time that was put into it.
Friday, October 24, 2008
Monday, October 20, 2008
DueDates
Overview
I felt that this was our first "real" software engineering task. After learning the tools, standards, and practices, I finally got a chance to put these skills into use. I felt that the majority of the assignment was to exercise our ability to incorporate the use of Google Code, Subversion, HTTPUnit, and Java. I took on this portion of the project with my partner Arthur Shum. We met approximately 4 times during the course of this week, but spoke daily over a messenger service. Luckily, our communication was great and we easily got our ideas across to each other. Was the purpose of this project successful? Definitely. There were some ups and down, but overall: a great experience.
Breakdown
Google Code makes project hosting simple yet intricate. I found it really easy to throw in issues, classify them, then work on them. The fact that its all listed and easy to refer back to makes project organization really effective. One thing that I found intriguing is that the commit logs can easily reference a certain issue by just typing "Issue #". Wikipages! Great way to put up documentation pages. We threw up a User and Developer Documentation that is easy to follow to guide you through the hassles of figuring things out yourself.
HTTPUnit is great. I have had my share of "screen scraping" using PHP CURL module and getFileContents() function. Since PHP is more of a scripting language, I was more used to ripping apart the HTML by searching for keywords and tags and extracting information that way. HTTPUnit pretty much takes all that and does the work for you. I was blown away by the built in functions that were available, such as the getTableStartingWith, getCellAsText, and getFormWithName functions. I may even convert to doing all future "screen scraping" in Java because of this! Good stuff.
Once again Subversion made it really easy to work with a partner and program on the same files. This ties in with Google Code and the use of commit logs to track changes. It became really routine to run ant -f verify.build.xml before and after every commit, which is extremely good practice. This does lead into one annoying PMD error that I will talk about later on.
I have been programming with PERL and PHP for the past 5 months and to jump back into Java was a little strange for me, especially when it came to small trivial things like string matching/manipulation and the use of regular expressions. Java is a really powerful language and has so much to offer, I just felt like it was too much of a "step up" for these simple tasks. I guess the syntax of these scripting languages have taken its toll on me. I guess the best practice is to keep using Java and be aware of its different approaches and methods.
Issues
Now, the bad. This really irritating PMD error was persistent throughout the week and had something to do with a "Singleton" class. The only way than we could fix this was to throw in a public void method that wasn't static. Another issue I had with this project is the use of Wiki Markup. I can't believe that there is no < br / > equivalent in WikiMarkup! I found my self pulling my hair out, trying to make certain images on their own line without making it a bullet; I still don't know if this is possible.
Conclusion
I am real fortunate that we got through the assignment with no big headaches. Of course, this is due to the use of these tools that were available to us. I could not imagine trying to do this over a system where you must mentally keep track of an issues list or consistently emailing source code to one another only to find that there are conflicting lines of code that are incompatible. I also learned that effective communication is a huge factor in working together, which included prioritizing and distributing work evenly across group members to ensure a fair work flow. I look forward to advancing thing project with even more group members and functionality added to it.
I felt that this was our first "real" software engineering task. After learning the tools, standards, and practices, I finally got a chance to put these skills into use. I felt that the majority of the assignment was to exercise our ability to incorporate the use of Google Code, Subversion, HTTPUnit, and Java. I took on this portion of the project with my partner Arthur Shum. We met approximately 4 times during the course of this week, but spoke daily over a messenger service. Luckily, our communication was great and we easily got our ideas across to each other. Was the purpose of this project successful? Definitely. There were some ups and down, but overall: a great experience.
Breakdown
Google Code makes project hosting simple yet intricate. I found it really easy to throw in issues, classify them, then work on them. The fact that its all listed and easy to refer back to makes project organization really effective. One thing that I found intriguing is that the commit logs can easily reference a certain issue by just typing "Issue #". Wikipages! Great way to put up documentation pages. We threw up a User and Developer Documentation that is easy to follow to guide you through the hassles of figuring things out yourself.
HTTPUnit is great. I have had my share of "screen scraping" using PHP CURL module and getFileContents() function. Since PHP is more of a scripting language, I was more used to ripping apart the HTML by searching for keywords and tags and extracting information that way. HTTPUnit pretty much takes all that and does the work for you. I was blown away by the built in functions that were available, such as the getTableStartingWith, getCellAsText, and getFormWithName functions. I may even convert to doing all future "screen scraping" in Java because of this! Good stuff.
Once again Subversion made it really easy to work with a partner and program on the same files. This ties in with Google Code and the use of commit logs to track changes. It became really routine to run ant -f verify.build.xml before and after every commit, which is extremely good practice. This does lead into one annoying PMD error that I will talk about later on.
I have been programming with PERL and PHP for the past 5 months and to jump back into Java was a little strange for me, especially when it came to small trivial things like string matching/manipulation and the use of regular expressions. Java is a really powerful language and has so much to offer, I just felt like it was too much of a "step up" for these simple tasks. I guess the syntax of these scripting languages have taken its toll on me. I guess the best practice is to keep using Java and be aware of its different approaches and methods.
Issues
Now, the bad. This really irritating PMD error was persistent throughout the week and had something to do with a "Singleton" class. The only way than we could fix this was to throw in a public void method that wasn't static. Another issue I had with this project is the use of Wiki Markup. I can't believe that there is no < br / > equivalent in WikiMarkup! I found my self pulling my hair out, trying to make certain images on their own line without making it a bullet; I still don't know if this is possible.
Conclusion
I am real fortunate that we got through the assignment with no big headaches. Of course, this is due to the use of these tools that were available to us. I could not imagine trying to do this over a system where you must mentally keep track of an issues list or consistently emailing source code to one another only to find that there are conflicting lines of code that are incompatible. I also learned that effective communication is a huge factor in working together, which included prioritizing and distributing work evenly across group members to ensure a fair work flow. I look forward to advancing thing project with even more group members and functionality added to it.
Wednesday, October 8, 2008
Configuration Management
Google Code and Subversion
The idea of having a controlled systems where multiple people can access the same code, make changes and continue to work as a whole is genius. Now there are multiple ways to handle this:
Obtaining someone else's
Since I'm using a Mac for the class, the Subversion client I was to download and install is called SmartSVN 4. Amazingly, it has a really nice GUI, the setup was incredibly easy, and I found my self connected to the repository in minutes. After taking on the task to download the stack-johnson repository files, using the SmartSVN was like 2nd nature. Distinguishing recently changed files and committing files with message was a peice of cake. It is amazing how a tool like this could be this easy to use.
Creating my own
After creating my own code space on google code, I used SmartSVN to help create a new repository locally and remotely off of my recent stack project. After running ant -f verify.build.xml, initially I had trouble when it came to selected which files I was to upload. The file hierarchy that Google Code makes it easy to double check and ensure that the right files were committed.
Conclusion
I found all of the tasks to be easy to do once you figure out how to use your SVN client. The hardest thing to do is to configure the client and have it link to your repository. I could see myself using SVN/CVS in a group projects where multitude of members are making changes to important files. Paired with efficiency and functionality, SVN can easily save a lot of headaches and time.
The idea of having a controlled systems where multiple people can access the same code, make changes and continue to work as a whole is genius. Now there are multiple ways to handle this:
- Revision Control System (RCS) - open source, unix based, involves "locking" of files
- Concurrent Versions Systems (CVS) - uses RCS as backend for version control and adds configuration management support. Allows multiple developers to checkout the same file, but merge confilcts. "optimistic locking"
- Subversion (SVN) - back-end repository is a database, versions are not file-based, but repository-wide, "directory" based tags and branches, arbitrary metadata.
Obtaining someone else's
Since I'm using a Mac for the class, the Subversion client I was to download and install is called SmartSVN 4. Amazingly, it has a really nice GUI, the setup was incredibly easy, and I found my self connected to the repository in minutes. After taking on the task to download the stack-johnson repository files, using the SmartSVN was like 2nd nature. Distinguishing recently changed files and committing files with message was a peice of cake. It is amazing how a tool like this could be this easy to use.
Creating my own
After creating my own code space on google code, I used SmartSVN to help create a new repository locally and remotely off of my recent stack project. After running ant -f verify.build.xml, initially I had trouble when it came to selected which files I was to upload. The file hierarchy that Google Code makes it easy to double check and ensure that the right files were committed.
Conclusion
I found all of the tasks to be easy to do once you figure out how to use your SVN client. The hardest thing to do is to configure the client and have it link to your repository. I could see myself using SVN/CVS in a group projects where multitude of members are making changes to important files. Paired with efficiency and functionality, SVN can easily save a lot of headaches and time.
Subscribe to:
Posts (Atom)