Todays assignemnt had to do with Subversion. This was not particularly simple.
First I downloaded and installed TortoiseSVN. I created a folder and put a text file in it. That part was rather simple.
The actual server, for which I downloaded VisualSVN, was harder to work with.
Messing around in the command line has been fun. We are also learning command line for Unix in Operating Systems class. Ive been using that part of the VisualSVN.
I got into the proper directory in command line by typing cd 462playground. After I updated a file in my folder, I went to the command line and typed in svn commit -m "Second update, saying that I updated it."
Thursday, January 27, 2011
Tuesday, January 25, 2011
1/25/2011
Last week I wrote about the project we are doing (ITK), its members, and its history on our team wiki.
We ended up organizing our front page to look more like this:
Today we updated the page about Ideas for contribution. We chose some bugs that looked interesting to fix. The reason for this was that the email we received back by Johnson Hans told us to do this so they can get an idea of what we are capable of doing. He also said he would be our mentor if we worked on ThinPlateSpline Algorithms with him. This is an alternative to choosing something on their wish list and working on it on our own.
We ended up organizing our front page to look more like this:
Selecting an OpenSource Project:
Potential Projects
Delving Deeper Into the Project:
Project: ITKToday we updated the page about Ideas for contribution. We chose some bugs that looked interesting to fix. The reason for this was that the email we received back by Johnson Hans told us to do this so they can get an idea of what we are capable of doing. He also said he would be our mentor if we worked on ThinPlateSpline Algorithms with him. This is an alternative to choosing something on their wish list and working on it on our own.
Thursday, January 20, 2011
The Cathedral and the Bazaar
This article talks about the open source project called Fetchmail. It uses the development styles "Cathedral" and "Bazaar" to talk about it, hence the title. The Cathedral is what most of the world uses. But Linux uses Bazaar. A central tenent of these is how they go about software debugging.
The author originally thought that no beta releases should come out before hand and that you should work in isolation, but ended up adopting the style of Linux which was to release early and often and delegate to others. The author states his first rule as: 1. Every good work of software starts by scratching a developer's personal itch. I agree that this does seem to be obvious, but apparently its not as programmers spend their time on things that are not necessary. He also believes in the idea of not reinventing the wheel when he says: 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). I love how he calls it constructive laziness, that is a great euphemism. Linus Torvald, the founder of Linux followed this principle as he used ideas from Minix to create Linux.
His third rule is: 3. ``Plan to throw one away; you will, anyhow.'' Basically this means that you may not know enough the first go around, so you should be willing to start over at least once. The fourth and fifth rules are: 4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. The author talks about inheriting pop-client and its users. The users can be very useful in terms of debugging. He explains this in: 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. We have Linus again to thank for this. You could say he is a trailblazer in terms of programming.
The next rule is: 7. Release early. Release often. And listen to your customers. In terms of release early and release often, a reason this was not previously practiced is that it was believed that if you constantly released buggy versions that the users would get annoyed and impatient. Actually back in 1991 Linus would sometimes release a new kernel every day. The author does not see Linus Torvald as a genius of design, but rather a genius of engineering and implementation. From what I have read in this article I would have to agree since the entire article is geared towards backing up this belief. In fact, he could even have this statement as his thesis at the beginning.
Source code level bug reporting tends to be quite efficient. One reason is because the communication is clearer between parties. A single error can have multiple symptoms. His ninth rule which could be counter-intuitive is: 9. Smart data structures and dumb code works a lot better than the other way around. The next rule is a psychological one. The tenth rule is a psychological one. 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. This is basic self-fulfilling prophecy. The idea of not working in isolation is talked about when he says that: 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. I like that some of these principles are general enough that you can apply them to other practices. In his next lesson he says: 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. You can't find a solution if you are looking in the wrong place or looking at it in the wrong way completely. Once he had reached simplification, he decided to change the name from popclient to Fetchmail. This is illustrated in his next rule that: 13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' A lot of the ideas and lessons so far have made a lot of sense and seem obvious in hindsight, but this is one of the ones that stood out a bit more and did not hit me right away. The author decided to expand to support needs of others. He did this with multi drop addressing. 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. His beta testers also wanted support for 8-bit MIME operation. MIME is Multipurpose Internet Mail Extensions. This extension would have been buggy were it not for him following his next lesson: 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
To be able to do Bazaar Style, there are certain pre-requisites according to the author. One that has already been talked about is that you dont start in Bazaar style, you just implement with it. The coordinator has to both be able to come up with great original designs but also recognize great designs from others and implement those. The most surprising may have been that you have to have people skills. This is not normally associated in the computer field. Of course the author says that the future of open source programming lies not in the Cathedral but in the Bazaar. Some of his other lessons seem to just be iterations of earlier statements, so I left a couple of them out.
There were some interesting lessons to learn here. The ones that were not so obvious were 9 and 13. My favorites were 2, 6, and 12. I do think the article was rather repetitive. Some of the rules and the concepts were either re-stated in slightly different ways or re-stated the same way later on in the article. Id also be interested to know what others think about the Bazaar style and who does or would use it as opposed to the Cathedral style.
The author originally thought that no beta releases should come out before hand and that you should work in isolation, but ended up adopting the style of Linux which was to release early and often and delegate to others. The author states his first rule as: 1. Every good work of software starts by scratching a developer's personal itch. I agree that this does seem to be obvious, but apparently its not as programmers spend their time on things that are not necessary. He also believes in the idea of not reinventing the wheel when he says: 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). I love how he calls it constructive laziness, that is a great euphemism. Linus Torvald, the founder of Linux followed this principle as he used ideas from Minix to create Linux.
His third rule is: 3. ``Plan to throw one away; you will, anyhow.'' Basically this means that you may not know enough the first go around, so you should be willing to start over at least once. The fourth and fifth rules are: 4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. The author talks about inheriting pop-client and its users. The users can be very useful in terms of debugging. He explains this in: 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. We have Linus again to thank for this. You could say he is a trailblazer in terms of programming.
The next rule is: 7. Release early. Release often. And listen to your customers. In terms of release early and release often, a reason this was not previously practiced is that it was believed that if you constantly released buggy versions that the users would get annoyed and impatient. Actually back in 1991 Linus would sometimes release a new kernel every day. The author does not see Linus Torvald as a genius of design, but rather a genius of engineering and implementation. From what I have read in this article I would have to agree since the entire article is geared towards backing up this belief. In fact, he could even have this statement as his thesis at the beginning.
Source code level bug reporting tends to be quite efficient. One reason is because the communication is clearer between parties. A single error can have multiple symptoms. His ninth rule which could be counter-intuitive is: 9. Smart data structures and dumb code works a lot better than the other way around. The next rule is a psychological one. The tenth rule is a psychological one. 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. This is basic self-fulfilling prophecy. The idea of not working in isolation is talked about when he says that: 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. I like that some of these principles are general enough that you can apply them to other practices. In his next lesson he says: 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. You can't find a solution if you are looking in the wrong place or looking at it in the wrong way completely. Once he had reached simplification, he decided to change the name from popclient to Fetchmail. This is illustrated in his next rule that: 13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' A lot of the ideas and lessons so far have made a lot of sense and seem obvious in hindsight, but this is one of the ones that stood out a bit more and did not hit me right away. The author decided to expand to support needs of others. He did this with multi drop addressing. 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. His beta testers also wanted support for 8-bit MIME operation. MIME is Multipurpose Internet Mail Extensions. This extension would have been buggy were it not for him following his next lesson: 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
To be able to do Bazaar Style, there are certain pre-requisites according to the author. One that has already been talked about is that you dont start in Bazaar style, you just implement with it. The coordinator has to both be able to come up with great original designs but also recognize great designs from others and implement those. The most surprising may have been that you have to have people skills. This is not normally associated in the computer field. Of course the author says that the future of open source programming lies not in the Cathedral but in the Bazaar. Some of his other lessons seem to just be iterations of earlier statements, so I left a couple of them out.
There were some interesting lessons to learn here. The ones that were not so obvious were 9 and 13. My favorites were 2, 6, and 12. I do think the article was rather repetitive. Some of the rules and the concepts were either re-stated in slightly different ways or re-stated the same way later on in the article. Id also be interested to know what others think about the Bazaar style and who does or would use it as opposed to the Cathedral style.
Tuesday, January 18, 2011
1/18/2011
Project Acquired
Today we chose our official project, which is ITK. It is a segmentation and registration toolkit for the national library of medicine which has software tools for image analysis. We found out that there seems to be no IRC channel. We joined the emailing list and created a google group so that all of the emails for this project will be viewable for everybody.
I added information about the project and its history and contributors to the team wiki.
After this I am going to read the article The Cathedral and the Bazaar and blog about it.
Today we chose our official project, which is ITK. It is a segmentation and registration toolkit for the national library of medicine which has software tools for image analysis. We found out that there seems to be no IRC channel. We joined the emailing list and created a google group so that all of the emails for this project will be viewable for everybody.
I added information about the project and its history and contributors to the team wiki.
After this I am going to read the article The Cathedral and the Bazaar and blog about it.
Thursday, January 13, 2011
1/13/11
Today we got together and chose some possible ideas for our project. We got four and posted them on our team wiki.
These projects are:
These projects are:
- Tor
- VuFind (Villanova University)
- Plone
- ITK
1/11/11
In class today we formed groups, chose our positions, team names, and answered some simple questions.
Creating this blog was easy. As was using the wiki space. I like that it can be publically edited once you are added.
Creating this blog was easy. As was using the wiki space. I like that it can be publically edited once you are added.
Subscribe to:
Posts (Atom)