The readings for week 2 were pretty interesting , both based around the same concept, the open source community, but both presented in different and interesting ways. Both of their concepts seemed to be tried to inspire the same thing, the motivate people into jumping into the open source community, because they David said, you are not going to be invited in.
The most powerful idea they both seemed to be presenting was that, trying to wait and build up your skills before jumping into the open source community is a flawed approach, though one that is pretty much the standard approach used elsewhere. They tried to emphasize that its OK to just jump in and absorb whats going on around you, its OK to try and fail. By simply taking part in any small part of the community, you are helping build the community, and even if what your attempting to do fails, you will learn enough not to make the same mistakes the next time and you will grow more integrated into the community.
One thing that struck me about what Mike Beltzner said was that one of the most useful skills you will learn in the open source community is who you should listen to, and who you can safely ignore, and that you can probably safely ignore 80% of the those who are communicating in the community. This spurred a few conflicting thoughts in my head, while I would naturally completely agree with such a statement, that most talk is simply noise, it makes me wonder if that means in the open source community, if you are just entering the scene, does that mean your goal is to try and fight your way into the 20% margin of people worth listening to? Or is it OK to simply go ignored until you have done something worth listening to, though this sorta conflicts with the idea that you should just jump in and try....
One last thought I had came from David's speech about the festivals. By simply going to the festival, does that really make you part of the community? Or are you simply there to utilize the fruits of the community's efforts? What I am trying to differentiate is the use of the community vs participating in the community. A festival doesn't come together the day of, it requires much planning and preparation, and by simply going to the festival doesn't make you a part of it. How do you make the transition from festival goer to actually participating in it? While I believe there is value in going and seeing and understanding the activities, the transition into actually becoming a part of it hasn't been well illustrated here...
Wednesday, September 28, 2011
Tuesday, September 27, 2011
Open vs Closed Licenses
For this entry I have read the BSD license and the proprietary license for Skype. I will be illustrating 3 things about these licenses that stuck out to me below.
The first thing that stuck out to me was their vastly differing sizes. The BSD license seems to be written in a broad, vague, all encompassing manner using very simple and easy to understand concepts to dictate the purpose of the license. It would seem that it is written this way to invite people to read, understand and use the license to its fullest. In contrast, the Skype license is very long, repetitive and very bloated, repetitively using long strings of synonyms to concretely dictate very simple ideas that could be written much more concisely. It seems the purpose of this tactic is so that consumers will not actually read these and simply agree to them, thus allowing them to sneak in sketchy terms that the user might otherwise not agree to.
The second things that stuck out was not a difference between the licenses, but a similarity. Both licenses dictate that if the software somehow ends up causes any form of damages, that the copyright holders are not liable. With the BSD license, it pretty much flat out states that no matter what you can't go after the copyright holders for anything no matter what the software may end up damaging. The Skype license spends several paragraphs dictating what they are not liable for, but at no point flat out states that they are not at all liable for any damages as the BSD license does. Interestingly, the Skype license also spends a fair bit of time dictating what belongs to what company, presumably spreading around liabilities.
The final thing that stuck out specifically about the Skype license is that they pretty much state that you don't own anything and that they can change anything as they will without notice. If you purchase a phone number from them, in the eula they state that you do not own it, that they can change it at any time and that you cannot transfer ownership to another person if you wish. It also states that any content you put up can be taken down for any reason at any time and they are not required to put it back up or return it to you. They also reserve the right to cancel your account at any time if they believe you have in anyway broken any agreements you agreed to, which can be changed at anytime and by simply continuing to use the product you agree to the amended terms.
Those are what really stuck out to me about those licenses. One thing it makes me question is the viability of the BSD license in a business situation, because the use of it makes it impossible to hold the creators liable, making it hard to want to invest time/money into software could fail at any time and there would be no one liable for the possible damages or loss of data/time/money as a result of the failures....
The first thing that stuck out to me was their vastly differing sizes. The BSD license seems to be written in a broad, vague, all encompassing manner using very simple and easy to understand concepts to dictate the purpose of the license. It would seem that it is written this way to invite people to read, understand and use the license to its fullest. In contrast, the Skype license is very long, repetitive and very bloated, repetitively using long strings of synonyms to concretely dictate very simple ideas that could be written much more concisely. It seems the purpose of this tactic is so that consumers will not actually read these and simply agree to them, thus allowing them to sneak in sketchy terms that the user might otherwise not agree to.
The second things that stuck out was not a difference between the licenses, but a similarity. Both licenses dictate that if the software somehow ends up causes any form of damages, that the copyright holders are not liable. With the BSD license, it pretty much flat out states that no matter what you can't go after the copyright holders for anything no matter what the software may end up damaging. The Skype license spends several paragraphs dictating what they are not liable for, but at no point flat out states that they are not at all liable for any damages as the BSD license does. Interestingly, the Skype license also spends a fair bit of time dictating what belongs to what company, presumably spreading around liabilities.
The final thing that stuck out specifically about the Skype license is that they pretty much state that you don't own anything and that they can change anything as they will without notice. If you purchase a phone number from them, in the eula they state that you do not own it, that they can change it at any time and that you cannot transfer ownership to another person if you wish. It also states that any content you put up can be taken down for any reason at any time and they are not required to put it back up or return it to you. They also reserve the right to cancel your account at any time if they believe you have in anyway broken any agreements you agreed to, which can be changed at anytime and by simply continuing to use the product you agree to the amended terms.
Those are what really stuck out to me about those licenses. One thing it makes me question is the viability of the BSD license in a business situation, because the use of it makes it impossible to hold the creators liable, making it hard to want to invest time/money into software could fail at any time and there would be no one liable for the possible damages or loss of data/time/money as a result of the failures....
Thursday, September 22, 2011
Sickness, recovery, and so many open sores...
I'll start with the obligatory yet meaningless reason as to why this is my first blog in some time; I got pretty sick last week and I really wasn't able to accomplish much of anything. I am finally catching up on my work now and though this post will be quite outdated and possibly meaningless, I'll write it anyways, gotta keep the spirit alive right?
The readings put open source development is a slightly new light that I hadn't considered before. I have never been a huge supporter of open source development, not that I am particularly against it, but I am just not one to look at a proposed methodology and simply accept it as being a more correct or superior methodology without having given all other methods serious consideration. With that said, open source development does seem to have a very concrete and everlasting place in the software development world. Still I can't see it overtaking all aspect of software development, closed source development has just as concrete a future in the software world.
The cathedral and bazaar paper illustrated where I think open source development really thrives, where people have a common issue they need solved. With Eric's example of his fetchmail project, he made it seem that he was able to muster up such an large number of people to assist him because they wanted to see the product work, they wanted the problems that they had fixed and that they just wanted to feel like they were contributing something useful. Though I have started noticing more and more that open source seems to be more like an intern program, something you do simply to be able to put it on a resume or to start making contacts and gaining experience, be it unpaid. But perhaps my views on this are clouded, on the tail end of college and only seeing this trend in my peers desperately clamoring for employment.
There is one thing I find brilliant about the bazaar method, quite obviously its greatest strength, which is illustrated in Eric's version of Linus' Law; "that given enough eyeballs, all bugs are shallow". Any programmer knows that finding bugs and narrowing down their cause is likely to be your greatest source of wasted time when you are trying to develop something. Having your clients act as testers and developing rapid fixes for the bugs that arise is probably the best way to make the most out of your programmers time, allowing them to develop more things faster. But this does come with one risk, and that is of course taxing your clients patience, which is why the split distribution is such a good idea, having one stable and one unstable build, allowing the clients to revert to the stable versions if they simply want to work with the product without dealing with bugs.
That about raps up my thoughts on these readings. One thing I did find funny about the people in the video was that, you would think that open source figures like them would be open and (to a degree) submissive but in fact they came across as very territorial, especially towards each other.
As a last note, I filled in my wiki page with some basic information about myself, so if you want to know a bit more about me, check out http://zenit.senecac.on.ca/wiki/index.php/User:CloudScorpion.
The readings put open source development is a slightly new light that I hadn't considered before. I have never been a huge supporter of open source development, not that I am particularly against it, but I am just not one to look at a proposed methodology and simply accept it as being a more correct or superior methodology without having given all other methods serious consideration. With that said, open source development does seem to have a very concrete and everlasting place in the software development world. Still I can't see it overtaking all aspect of software development, closed source development has just as concrete a future in the software world.
The cathedral and bazaar paper illustrated where I think open source development really thrives, where people have a common issue they need solved. With Eric's example of his fetchmail project, he made it seem that he was able to muster up such an large number of people to assist him because they wanted to see the product work, they wanted the problems that they had fixed and that they just wanted to feel like they were contributing something useful. Though I have started noticing more and more that open source seems to be more like an intern program, something you do simply to be able to put it on a resume or to start making contacts and gaining experience, be it unpaid. But perhaps my views on this are clouded, on the tail end of college and only seeing this trend in my peers desperately clamoring for employment.
There is one thing I find brilliant about the bazaar method, quite obviously its greatest strength, which is illustrated in Eric's version of Linus' Law; "that given enough eyeballs, all bugs are shallow". Any programmer knows that finding bugs and narrowing down their cause is likely to be your greatest source of wasted time when you are trying to develop something. Having your clients act as testers and developing rapid fixes for the bugs that arise is probably the best way to make the most out of your programmers time, allowing them to develop more things faster. But this does come with one risk, and that is of course taxing your clients patience, which is why the split distribution is such a good idea, having one stable and one unstable build, allowing the clients to revert to the stable versions if they simply want to work with the product without dealing with bugs.
That about raps up my thoughts on these readings. One thing I did find funny about the people in the video was that, you would think that open source figures like them would be open and (to a degree) submissive but in fact they came across as very territorial, especially towards each other.
As a last note, I filled in my wiki page with some basic information about myself, so if you want to know a bit more about me, check out http://zenit.senecac.on.ca/wiki/index.php/User:CloudScorpion.
Tuesday, September 6, 2011
OSD600 Blog
I am not really gonna say anything in this blog post, simply putting it in to make sure it works.
Saturday, December 19, 2009
OOP344 Assignment 2 Implementation
With exams done at last, I can finally take a minute to write about OOP344 A2. We have decided to build a text editor, which keeps getting more complex each time we talk about it. I am currently writing a word wrapping feature for the text editor, that is taking longer than expected but it should be done soon enough, I am just hoping that I don't hurt the team with this little tangent I decided to follow.
The program is going to need a whole new batch of classes to work correctly, first the controller, which will actually control the program and will act as the programs root class, which will organize all the classes and access the programs menu manager, file manager, and settings classes, while containing all the forms and fields it requires. I am responsible for the controller, so that is my mess to figure out. The menu manager system controls the primary menu and holds a series of other menus and function pointers inside of it, so when a menu item is selected, it either displays another menu, or calls a function that will accomplish some task. This has already been completed by northWind, and he did it in such a way that adding, organizing and displaying menus is very simple, which makes my job of creating the controller a bit easier. The file manager allows the program to open, read, write and close files on the fly, this will allow the controller to access files more easily, this is being handled by Ausley. The settings will be a class of their own and this will allow a function based interface with all of the program settings, and quick access to all the setting variables, I think northWind wants to do this class as well. The rest of the work is still kinda up in the air, but we are planning on making specialized forms, a small button system, a highlighting system (which I plan on doing, if the dead line doesn't come up too quickly), copy, paste, ect. So, this is the plan, for everyone else planning on making a Text Editor program, see you at the finish line >:-D
The program is going to need a whole new batch of classes to work correctly, first the controller, which will actually control the program and will act as the programs root class, which will organize all the classes and access the programs menu manager, file manager, and settings classes, while containing all the forms and fields it requires. I am responsible for the controller, so that is my mess to figure out. The menu manager system controls the primary menu and holds a series of other menus and function pointers inside of it, so when a menu item is selected, it either displays another menu, or calls a function that will accomplish some task. This has already been completed by northWind, and he did it in such a way that adding, organizing and displaying menus is very simple, which makes my job of creating the controller a bit easier. The file manager allows the program to open, read, write and close files on the fly, this will allow the controller to access files more easily, this is being handled by Ausley. The settings will be a class of their own and this will allow a function based interface with all of the program settings, and quick access to all the setting variables, I think northWind wants to do this class as well. The rest of the work is still kinda up in the air, but we are planning on making specialized forms, a small button system, a highlighting system (which I plan on doing, if the dead line doesn't come up too quickly), copy, paste, ect. So, this is the plan, for everyone else planning on making a Text Editor program, see you at the finish line >:-D
Monday, December 14, 2009
Onward into the shadows
Well, this is the last week... I just woke up from a great little sleep and now its time to get ready and study for my INT322 exam that is in 6 hours. My biggest advice to anyone reading this, is make damn sure you have a good night's sleep before an exam, I really messed up some of my other tests because I simply didn't allow myself time to sleep. I plan on going over my previous two INT tests and writing out the two pre-tests we were given in the tutorials to hopefully get my self set for INT, then all I got left is DBS and I am gone.
I also wanted to post my opinions about the OOP344 exam here too. I have always hated the concept of a programming exam, essentially writing some small piece of junk code, in a short period of time. I have two methods of writing tests: take my time and write it correctly, but lose a bunch of marks at the end for questions I don't have time to answer, or write it quick and sloppy and finish all of the questions, but lose marks on questions answered incorrectly, often on purpose. I usually take the former method, but for the OOP344 exam I thought I'd try the latter, but it nearly killed me doing so, I intentionally wrote at least 3 questions completely wrong, simply because I knew I didn't have the time to write the whole thing out correctly, which is really infuriating, because I already know how it is supposed to be written, but I know my hands simply can't write fast enough to allow me to write it. For the save and load functions on the exam, I simply wrote something like 'f.write((char*)this, sizeof(queue);', I know how completely wrong this is, but I didn't have time to write it correctly. Exams should be short IMO, but w/e, its water under the bridge, or w/e that saying is.
I am gonna end this off with the OOP344 assignment, which is gonna be worked on through out the holiday so by the time it is time to hand it in, we have something that is actually worth something, an actual working text editor. Lets see how it goes.
I also wanted to post my opinions about the OOP344 exam here too. I have always hated the concept of a programming exam, essentially writing some small piece of junk code, in a short period of time. I have two methods of writing tests: take my time and write it correctly, but lose a bunch of marks at the end for questions I don't have time to answer, or write it quick and sloppy and finish all of the questions, but lose marks on questions answered incorrectly, often on purpose. I usually take the former method, but for the OOP344 exam I thought I'd try the latter, but it nearly killed me doing so, I intentionally wrote at least 3 questions completely wrong, simply because I knew I didn't have the time to write the whole thing out correctly, which is really infuriating, because I already know how it is supposed to be written, but I know my hands simply can't write fast enough to allow me to write it. For the save and load functions on the exam, I simply wrote something like 'f.write((char*)this, sizeof(queue);', I know how completely wrong this is, but I didn't have time to write it correctly. Exams should be short IMO, but w/e, its water under the bridge, or w/e that saying is.
I am gonna end this off with the OOP344 assignment, which is gonna be worked on through out the holiday so by the time it is time to hand it in, we have something that is actually worth something, an actual working text editor. Lets see how it goes.
Wednesday, December 9, 2009
The time of darkness draws near
So, the exam is in a few hours, and I just woke up from a beautiful 17 hours of sleep, and I am set and ready to do some last minute cramming. I will explain my studying plans each day for the next few days so anyone who doesn't know where to start will have a good idea, mind you, this will include all of my classes, not just OOP.
So, for tomorrow, I have SYS366 and OOP344, and I have a detailed plan already set. For SYS366, I will simply review my previous two tests, see what I did right and what I did wrong, then I will re-write it so that it matches what should be worth a perfect mark. That should take about two hours, and then I figure I am set for SYS366, for anyone reading this that thinks they need more help than that, I would also suggest checking out the slides and example models that Mary-Margaret Walton has posted on her class schedule.
For OOP344, I will be looking at my previous tests, but since I got perfect on one and near perfect on the second, I won't spend much time on them, I will also re-read chunks of the Evan Weaver text and look over the quizzes, then I will assign myself random programming tasks on areas that I am not too confident in, and do my best to make complete and working examples of how that specific area works. This will likely add up to 5-6 hours of studying, Then I guess I am as ready as I am going to be.
As a final note, with all that is going on, I want to stress the fact that everyone has to remember to do the INT322 assignment 2, do not forget, do not leave an inadequate amount of time for it.
So, for tomorrow, I have SYS366 and OOP344, and I have a detailed plan already set. For SYS366, I will simply review my previous two tests, see what I did right and what I did wrong, then I will re-write it so that it matches what should be worth a perfect mark. That should take about two hours, and then I figure I am set for SYS366, for anyone reading this that thinks they need more help than that, I would also suggest checking out the slides and example models that Mary-Margaret Walton has posted on her class schedule.
For OOP344, I will be looking at my previous tests, but since I got perfect on one and near perfect on the second, I won't spend much time on them, I will also re-read chunks of the Evan Weaver text and look over the quizzes, then I will assign myself random programming tasks on areas that I am not too confident in, and do my best to make complete and working examples of how that specific area works. This will likely add up to 5-6 hours of studying, Then I guess I am as ready as I am going to be.
As a final note, with all that is going on, I want to stress the fact that everyone has to remember to do the INT322 assignment 2, do not forget, do not leave an inadequate amount of time for it.
Subscribe to:
Posts (Atom)