1. What does it mean when projects are created in the "cathedral" versus the "bazaar"?
Typically, the cathedral model is based on having a select group of trained professionals working on a project and closely monitoring its progress. This approach would likely be very controlling and not just anyone would be able to contribute.
The bazaar model would be open to all with little to no oversight and not as much control or management. People would be free to make changes at will and there wouldn't be a clear system of accountability.
2. Which system does an open source project typically look like?
As it turns out, it's a lot more like the cathedral model than people predicted. Most open source projects have a group of people that administrate and monitor changes to the system. They are the ones that give permissions for people to join the project, usually after demonstrating a certain level of professionalism and skill, who can then update and make changes to that system.
3. Why is it good for every programmer to get involved in an open source project?
Being accepted into an open source system as a developer is great for a number of reasons. It establishes a public example of the kind of code you are capable of writing, shows that you have a certain level of proficiency and professionalism, and it shows that you can coordinate in a lucid team environment with people from all over.
4. How many "learn to program in 10 days" books do you need to become a good programmer?
None. The 'best' way to become a 'good' programmer is to get a little experience each day. There are plenty of resources online such as language tutorials, API documentation, discussion forums, etc. that you can learn from. The idea that you can read a few "learn language such-and-such" in a short amount of time and be proficient at it is an error. You really need to take continual steps over a long period of time, closer to 10 years or so, before you really develop a lot of proficiency in a field. It is also good to continually push yourself further in your understanding by challenging yourself as you learn.
5. What are some basics that will be necessary for an interview as a programmer?
First of all, you should not be afraid to write some code in your interview! Be able to at the very least demonstrate a firm understanding of languages that you list on your resume, which means being able to write syntactically correct code from memory without references. One site recommends that you should be able to write code for various abstract data types and implement basic algorithms in each of your "proficient" languages. It is also helpful to know a variety of language types. Somethings are much more difficult to implement in an interview with an imperative language like C++ or Java, but can be accomplished easily with a scripting language like Perl or JavaScript. Also, be sure to know the basics of Object Oriented Programming and the primitive data types. (It also helps to dress for the interview, don't forget to present yourself as a professional in person)
Tuesday, October 25, 2011
Friday, October 14, 2011
Working with Configuration Management
So far, I have had a little experience with configuration management and version control systems. I have currently worked with Unfuddle and recently posted a project on Google Project Hosting. Both of these sites allow for free project management tools and each has SVN hosting. I enjoy working with Unfuddle since it has many useful features, not the least of which is the ability to close tickets from within your SVN commit message. My experience with both of these systems has been extremely positive!
For now, I am going to focus on the project that I recently set up on Google Project Hosting. If you managed to read my last post about a rather dismal Robocode robot named Tankadin, then you know that the robot is not going to win many championships. However, creating the robot, its build system, and now having set up project hosting for it, has all been an interesting endeavor. I have learned a lot about the Java based Ant build system and how to manage a project locally. From there, I have learned more about how to actually host a project and start up a subversion repository. I've already been using subversion for a few months now, so I started this project out with a degree of familiarity.
While I am already used to the idea of configuration management tools due to my experience with Unfuddle, I continue to learn and expand my capabilities and experience as I learn and use other tools. As far as open source projects go, Google Project Hosting is decent in that you can easily set up wiki pages for the general public to inform people of your project and allow for easy downloading to anyone. For my Robocode project, I added a User Guide page which shows anyone how to download and install my robot, Tankadin for target practice. I have also included a Developer Guide that describes what dependencies are needed to make much needed improvements to the robot, as well as information about how to checkout a working copy from the SVN repository. For the developer guide page, I copied the template from another Robocode project.
Right now, I only have one other member to the project, although I would welcome anyone that wanted to work on the robot. My goal is to continue working on the project when I finish more of my current responsibilities and have some free time to spare. If you stumble upon this page, please feel free to check out the project and see what changes have been made. I have a link to it in the first paragraph, but you can also click here.
For now, I am going to focus on the project that I recently set up on Google Project Hosting. If you managed to read my last post about a rather dismal Robocode robot named Tankadin, then you know that the robot is not going to win many championships. However, creating the robot, its build system, and now having set up project hosting for it, has all been an interesting endeavor. I have learned a lot about the Java based Ant build system and how to manage a project locally. From there, I have learned more about how to actually host a project and start up a subversion repository. I've already been using subversion for a few months now, so I started this project out with a degree of familiarity.
While I am already used to the idea of configuration management tools due to my experience with Unfuddle, I continue to learn and expand my capabilities and experience as I learn and use other tools. As far as open source projects go, Google Project Hosting is decent in that you can easily set up wiki pages for the general public to inform people of your project and allow for easy downloading to anyone. For my Robocode project, I added a User Guide page which shows anyone how to download and install my robot, Tankadin for target practice. I have also included a Developer Guide that describes what dependencies are needed to make much needed improvements to the robot, as well as information about how to checkout a working copy from the SVN repository. For the developer guide page, I copied the template from another Robocode project.
Right now, I only have one other member to the project, although I would welcome anyone that wanted to work on the robot. My goal is to continue working on the project when I finish more of my current responsibilities and have some free time to spare. If you stumble upon this page, please feel free to check out the project and see what changes have been made. I have a link to it in the first paragraph, but you can also click here.
Tuesday, October 11, 2011
An Exercise in Frustration and Futility
We cannot always win. That is a perfectly true statement. Oh sure, we may have winning streaks here and there, but we will inevitably meet with opposition which defeats us. Sometimes, it can seem almost as if we cannot even manage to win at all. That is how I felt with regards to my personal competition robot for the robocode system.
To be completely honest, I am frustrated, disappointed, and depressed by the fact that my robot is horrible. My robot, which I called "Tankadin" as a nod to my appreciation of paladins, could not consistently beat a single test robot that shot back at it. That is correct, I could beat most of the sample robots in robocode some of the time, but never one of the others all of the time. That is, aside from the "SittingDuck" robot, as well as "Target" or any other robots that never shot at me.
Where did I go wrong? Most likely it was due to the fact that I wanted to implement a movement strategy that utilized one of my favorite methods from my robocode kata robots, the method that allowed my robot to move to any specific location on the map. Unfortunately, the best use that I could think of for this ability was to send my robot to various corners of the map. But I wanted to be able to use that movement over and over during an engagement, so I developed a method that allowed me to randomly move to any of the 4 corners of the battlefield. As I left it, the robot moves to random corners when it hits a wall or another robot. I had implemented dodging capabilities and on-bullet-hit behaviors that were subsequently removed due to ineffectiveness or conflicts with targeting mechanics.
I soon realized that whilst my robot was in transit, it was not firing and often got pummeled to death en-route to its destination. I had also wanted to utilize my tracking ability to follow enemy robots with the gun so that most shots would land. What I managed to end up with was a less-than mediocre robot. Although, my robot does track and fire consistently when at rest.
I also wanted to implement some decent test cases, but I spent so much time changing behaviors, adding new movement strategies, removing them, and eventually settling for a disappointment that I didn't have time to implement them.
There were a few changes along the way that would beat one robot, but then lose consistently with all the others. Thus, I found myself trying new strategies only to have to remove the code for those strategies because they impeded on previously successful behaviors.
I have learned a great deal in the process of building "Tankadin". I realized that either movement or firing should be simple. Trying to implement tracking and fancy movement can often have bad side-effects such as interfering with the ability to dodge incoming shots, or to be able to consistently track your opponent. Also, as far as testing is concerned it would be best to settle on a particular strategy such that you can develop test cases right away to help determine effectiveness rather than trying to "fix" behavioral flaws in the robot as you see new situations arise with different opponents. Also, being able to devote more time towards development would greatly aid in the evolution process. I believe that would have allowed me to generate a decent level of performance in my robot.
To be completely honest, I am frustrated, disappointed, and depressed by the fact that my robot is horrible. My robot, which I called "Tankadin" as a nod to my appreciation of paladins, could not consistently beat a single test robot that shot back at it. That is correct, I could beat most of the sample robots in robocode some of the time, but never one of the others all of the time. That is, aside from the "SittingDuck" robot, as well as "Target" or any other robots that never shot at me.
Where did I go wrong? Most likely it was due to the fact that I wanted to implement a movement strategy that utilized one of my favorite methods from my robocode kata robots, the method that allowed my robot to move to any specific location on the map. Unfortunately, the best use that I could think of for this ability was to send my robot to various corners of the map. But I wanted to be able to use that movement over and over during an engagement, so I developed a method that allowed me to randomly move to any of the 4 corners of the battlefield. As I left it, the robot moves to random corners when it hits a wall or another robot. I had implemented dodging capabilities and on-bullet-hit behaviors that were subsequently removed due to ineffectiveness or conflicts with targeting mechanics.
I soon realized that whilst my robot was in transit, it was not firing and often got pummeled to death en-route to its destination. I had also wanted to utilize my tracking ability to follow enemy robots with the gun so that most shots would land. What I managed to end up with was a less-than mediocre robot. Although, my robot does track and fire consistently when at rest.
I also wanted to implement some decent test cases, but I spent so much time changing behaviors, adding new movement strategies, removing them, and eventually settling for a disappointment that I didn't have time to implement them.
There were a few changes along the way that would beat one robot, but then lose consistently with all the others. Thus, I found myself trying new strategies only to have to remove the code for those strategies because they impeded on previously successful behaviors.
I have learned a great deal in the process of building "Tankadin". I realized that either movement or firing should be simple. Trying to implement tracking and fancy movement can often have bad side-effects such as interfering with the ability to dodge incoming shots, or to be able to consistently track your opponent. Also, as far as testing is concerned it would be best to settle on a particular strategy such that you can develop test cases right away to help determine effectiveness rather than trying to "fix" behavioral flaws in the robot as you see new situations arise with different opponents. Also, being able to devote more time towards development would greatly aid in the evolution process. I believe that would have allowed me to generate a decent level of performance in my robot.
Subscribe to:
Posts (Atom)