There never seems to be quite enough time in the day anymore to solve all of the problems when faced with the challenge of examining the intrinsic techniques of being a great software engineer. Despite that feeling, I feel that there have been several things that I have learned up to this point that will bring me that much closer to an understanding to what it means to be such from the techniques I have both examined and applied so far. These questions are only a few in number but they are representative of how far I have traveled and also just a hint at the direction that I will be traveling in.
1. What are some of the common types of problems that Configuration Management are good at solving?
If you have problems such as (but not limited to): (a) Not being able to reproduce a bug that was witnessed in your own copy of the system, (b) Unable to determine what happened to your fix of the code, although it was fixed at a time prior to your being unable to determine and (c) If you wonder if a bug you saw is fixed within the copy of the system you have, then configuration management will be useful!
2. How does CVS solve the three classical problems that configuration management faces?
For issues with double maintenance,CVS has a centralized repository with a single master copy of each file.
For issues with shared data, CVS allows multiple developers to create local copies of that master copy to work on.
For issues with simultaneous updates, CVS allows multiple developers the ability to edit files simultaneously and CVS creates a "merged" file with all the changes.
3. What are three scalability issues build systems face?
Modularity, Incrementality, and Coupling
4. What is the responsibility of the *.build.xml file?
The *.build.xml file is responsible for implementing support for single functions such as checkstyle,jar,Javadoc,PMD, and Distribution?
5. In a version control system, what is a "delta" representative of?
"Deltas" are a representation of the difference in the versions of files.
Tuesday, October 25, 2011
Thursday, October 20, 2011
Sharing Files...It's just THAT simple!
When it comes to collaborating with teammates by sharing software projects, believe me, I would love to say gone are the days where emailing each other is a requirement. Alas, it is not something that is completely true, however, the task has become easier thanks in part to Google Project hosting and configuration management software clients such as Subversion and Git. Subversion, or SVN for short, is a software versioning and a revision control system distributed that developers use in order to provide current and historical versions of files such as source code, web pages, and documentation.
With the combination of Google's project hosting service and Subversion's configuration management capabilities, project developers are able to create a centralized repository where pertinent documentation, for example, the project's user & developers guide, summaries and also the project itself, can be found and downloaded. Moreover, with the subversion capabilities teammates are able(granted, they must have commit privileges) once downloaded to commit any changes they have made to the project. It really makes sharing projects widespread and simple.
Thanks to that, sharing my Robocode project, DaRumble, was as easy as one, two, three. The only difficulty that I encountered was in creating the pages with the specific documentation (the user & developer guides)due in part to the wiki markup syntax (it took me about five minutes to get the page to display an underscore!), but aside from that, giving a partner commit-access to the project and creating a trunk folder where that partner can commit changes did not take much time to do. In fact,when I was setting the trunk folder up for access, I cleared up the misconception that I had earlier when I thought that any user must download the project first and then re-upload any changes made. I learned,however, that if the user has any configuration management system client, they are able to visit the repository of the project and commit any changes even without downloading the project.
All in all, I think from working with this configuration system, I have gained another useful tool in working with software systems and, to a larger extent another perspective that will being me closer to understanding to what being a great software engineer is.
If at all curious, please feel free to visit my project's page at:
http://code.google.com/p/robocode-wch-darumble/
With the combination of Google's project hosting service and Subversion's configuration management capabilities, project developers are able to create a centralized repository where pertinent documentation, for example, the project's user & developers guide, summaries and also the project itself, can be found and downloaded. Moreover, with the subversion capabilities teammates are able(granted, they must have commit privileges) once downloaded to commit any changes they have made to the project. It really makes sharing projects widespread and simple.
Thanks to that, sharing my Robocode project, DaRumble, was as easy as one, two, three. The only difficulty that I encountered was in creating the pages with the specific documentation (the user & developer guides)due in part to the wiki markup syntax (it took me about five minutes to get the page to display an underscore!), but aside from that, giving a partner commit-access to the project and creating a trunk folder where that partner can commit changes did not take much time to do. In fact,when I was setting the trunk folder up for access, I cleared up the misconception that I had earlier when I thought that any user must download the project first and then re-upload any changes made. I learned,however, that if the user has any configuration management system client, they are able to visit the repository of the project and commit any changes even without downloading the project.
All in all, I think from working with this configuration system, I have gained another useful tool in working with software systems and, to a larger extent another perspective that will being me closer to understanding to what being a great software engineer is.
If at all curious, please feel free to visit my project's page at:
http://code.google.com/p/robocode-wch-darumble/
Tuesday, October 11, 2011
The End All Be All : Top Robot!
Have you ever wondered what it must be like for those contestants that compete on shows like Top Chef or Iron Chef America. The competition is completely maddening and with the added pressure of making top gorumet meals in sometimes less than an hour surely makes it worse, I would think.
Subscribe to:
Posts (Atom)