Release Early, Release Often! Back to my favorite conglomerate of papers written by Eric S. Raymond. This segment talks about the development model of the Linux kernel, as well as a common development model for most open source projects.
Back in the early days of software development it was common to work with the Cathedral building development, this way your early buggy versions do not disgruntle users or even change their workflow. The idea that the objective was for users to run into the least amount of bugs kept this perpetual cycle of one leader programming and slow patching schedules going for a while. It wasn't until Linux started gaining momentum that another way of developing code seemed to work better. Linus treated his users as co-developers, bug hunters, and documentarians.
His use of leveraging users to let them collaborate allowed him to pick ideas and incorporate them (if the user didn't already incorporate it themselves). This turnaround sometimes lead to releasing a kernel update more than once a day. This helped motivate the co-developers, either from their sense of the gift culture that open source is now known for, or for the ego satisfying love that hackers have when their name is on a project. This lead to better code with the idea that "given enough eyeballs, all bugs are shallow" otherwise known as "Linus's Law". If the project dev group is large enough a bug will be caught faster, and bugs will have a higher probability of having a quick and obvious fix to someone who might have seen that type of problem before.
Releasing early and releasing often is most likely going to be the development model for Obsidian. Hopefully builds will be twice a month at first, and when the project becomes more stable the ability to refactor parts that we know we want to change (like the methodMap) can come later. We just need to find a collection of developers that like our project and will continue to use it even if we are not developing it anymore. I hope the original team will continue to work on it, but the open source community is already used to people moving on and new people taking over, we just need to find our developers first.
Speaking of Obsidian, we have a week to go before POSSCON and our release of the code to the public. The poster now has cool graphics to show how each pattern works. The wiki is tentatively declared done, but as it is a wiki it will never be done. Something will always need to be changed, something else will always need to be updated, it is just the name of the game when it comes to an evolving project. The documentation needs to change to keep up.
Lets just hope it doesn't need to be changed that much.
Tuesday, March 19, 2013
Thursday, March 14, 2013
The Doc is in!
The exercise this week was all about documentation. Seeing as how we are in the middle of writing all the documentation for Obsidian I decided just to keep at it and continue working on the Obsidian documentation. My feelings on documentation were described in a earlier post, but I feel like Jeff Atwood describes the best methods of commenting on his blog Coding Horror. If the complexity of the code is high enough for you to write a dissertation in the method, you might want to reconsider refactoring it to be separated out a little bit more.
One of the exercises was to write a wiki page of developer documentation for each program. Seeing as how I took hold of the "How to Contribute" page I decided just to finish it up with some common coding standards as well as modifying the build instructions for the source code. Other then that most of the documentation is almost finished, we are just working on the documentation for the poster.
The team's meeting recently has been about the layout and wording of the poster. We tried making the sections understandable without being too much, but to fully explain parts of the project we had to write full paragraphs. An example of some of the poster documentation:
Overview:
Obsidian has four different patterns for tests that are determined by two factors: whether the function has parameters and whether the function throws exceptions. With the usage of these patterns Obsidian can create a test implementation for different types of methods.
And an example of one of the patterns:
Call:
The CALL pattern, the simplest pattern, is generated on functions that do not have parameters and do not throw exceptions. All Obsidian can do in this case is call the method, and generate the assert statements. This is the basic building block of Obsidian, and is used in all of the other patterns.
I'm really excited to see how it turns out. I'm just sad that I will not be there the night before to help setup. I have a test the night that the rest of the team will be driving up, so I will not be at the welcoming party. This is good news in a way, seeing as how the stickers should be arriving the day that everyone else is heading up, so I'll be bringing them with me the next day (the first day of POSSCON).
Tuesday, March 12, 2013
After the break...
During the break I told myself that I was going to get a bunch of homework done on the first few days, and while this is true I also said that I wanted to work on Obsidian for a few days after, this is not so true. I did work on what I had to finish but the break allowed me to recharge my batteries which I desperately needed. Especially because I got sick halfway through the break.
So after the break the team got together to see what we needed to finish. The documentation had a good "first pass" where everything had a little bit of information, be that bullet points or just setup of the page. During the next week the main focus will be documentation seeing as how most of the bugs and enhancements/features are now completed and fixed over the weekend. There are refactoring things we want to do, but currently we want to have the documentation in place so people can help contribute.
One of the side items that I have been working on is to try and figure out how I would want to implement Global Equality Methods. These methods are there to allow the programmer/test engineer how each object that is in the project is equal to another object of the same type. The problem that we know exists is one of how to address the objects. Our code styling for the Package and Class level of the Equality Methods just use the name of the class. One of the projects that we use contains two classes with the same names in different namespaces, so we have a problem with ambiguity between the classes with the same name. It seems like we are going to have to use fully qualified names when we create the areEqual methods (example: areEqual(com.foo.bar x, com.foo.bar y) instead of importing com.foo.bar and using areEqual(bar x, bar y)).
Other then that the team is going to start meeting on Friday nights, bringing the total time working together 3 days a week. We figured that while writing the documentation it is easier to just ask everyone at the table what the wording should be, or what should go on what page instead of emailing everyone to wait for a response. Hopefully the Friday meetings are going to allow us to work on the project to get it out there faster and decrease the amount of stress that the group has been feeling. That plus the pop quizzes Hunter has been giving us (to test our knowledge of Obsidian) are sure to help ease everyone's nerves about the upcoming booth unveiling at POSSCON.
So after the break the team got together to see what we needed to finish. The documentation had a good "first pass" where everything had a little bit of information, be that bullet points or just setup of the page. During the next week the main focus will be documentation seeing as how most of the bugs and enhancements/features are now completed and fixed over the weekend. There are refactoring things we want to do, but currently we want to have the documentation in place so people can help contribute.
One of the side items that I have been working on is to try and figure out how I would want to implement Global Equality Methods. These methods are there to allow the programmer/test engineer how each object that is in the project is equal to another object of the same type. The problem that we know exists is one of how to address the objects. Our code styling for the Package and Class level of the Equality Methods just use the name of the class. One of the projects that we use contains two classes with the same names in different namespaces, so we have a problem with ambiguity between the classes with the same name. It seems like we are going to have to use fully qualified names when we create the areEqual methods (example: areEqual(com.foo.bar x, com.foo.bar y) instead of importing com.foo.bar and using areEqual(bar x, bar y)).
Other then that the team is going to start meeting on Friday nights, bringing the total time working together 3 days a week. We figured that while writing the documentation it is easier to just ask everyone at the table what the wording should be, or what should go on what page instead of emailing everyone to wait for a response. Hopefully the Friday meetings are going to allow us to work on the project to get it out there faster and decrease the amount of stress that the group has been feeling. That plus the pop quizzes Hunter has been giving us (to test our knowledge of Obsidian) are sure to help ease everyone's nerves about the upcoming booth unveiling at POSSCON.
Tuesday, February 26, 2013
Reflections on my Progress
Team Obsidian is confirmed for having a booth at POSSCON. The team sat down tonight to discuss the work we need to finish. The tutorials on the Wiki as well as some small changes to the code still need to be made, but everyone on the team seems to be getting better acquainted with the code-base. So now that we know we have a booth we need to determine what our plan is for the table. Everyone agreed that a demo would be cool, that way we can show that this isn't just a planned project but one that is actually in a workable form so the theory of Stone Soup can be applied (Stone Soup being the idea that if you have a workable base other people are more interested in helping/giving). So we are planning on finding other open source Java projects to run Obsidian on during our time at the table. Another idea is to have another "floating" computer for people to type in their information so we can email them about the project later down the line to remind them to check it out. We have the stickers that we designed for the project, and they look amazing, so we will also be giving away stickers to people who come up to the table.
The documentation that I chose to work on consisted of "How to Contribute" and "How to Run". Contributing was harder then the how to run in my opinion. Coming up with the rules and norms of how to submit a patch as well as standard coding practices we used was a little difficult. I emulated some of the bigger open source projects while trying to keep in mind that we are a smaller project, so automated scripts and automated testing are a little bit of overkill. During the meeting we discussed how people can claim bugs, and our preferred way of submitting the solutions. Another thing that is currently in the contributing page is how to get and build from source. I put it here originally because contributors will need to be able to get the source, but after running a few tests with our fellow students a lot of them went to the "How to Run" page to build from source. I'm planning on talking to the group about this to either make a separate page for source code building, or linking the "How to Run" page to the section in contributing.
Everyone is busy working on their bugs and documentation, but lots of us have been feeling a strain with the semester coming into full swing. I know personally I need to work on other classes a little more, so before I go to POSSCON I'll be sitting down and working on all the homework for the next week so I don't have to worry while I'm at POSSCON.
The documentation that I chose to work on consisted of "How to Contribute" and "How to Run". Contributing was harder then the how to run in my opinion. Coming up with the rules and norms of how to submit a patch as well as standard coding practices we used was a little difficult. I emulated some of the bigger open source projects while trying to keep in mind that we are a smaller project, so automated scripts and automated testing are a little bit of overkill. During the meeting we discussed how people can claim bugs, and our preferred way of submitting the solutions. Another thing that is currently in the contributing page is how to get and build from source. I put it here originally because contributors will need to be able to get the source, but after running a few tests with our fellow students a lot of them went to the "How to Run" page to build from source. I'm planning on talking to the group about this to either make a separate page for source code building, or linking the "How to Run" page to the section in contributing.
Everyone is busy working on their bugs and documentation, but lots of us have been feeling a strain with the semester coming into full swing. I know personally I need to work on other classes a little more, so before I go to POSSCON I'll be sitting down and working on all the homework for the next week so I don't have to worry while I'm at POSSCON.
Thursday, February 21, 2013
Refactoring Mindset
What is good code? Code that runs, right? Well, if you never have to go back and work on the code then yes, that would be the definition of good code. But in the open source community there will always be a problem with people who need to come in after you to fix bugs. Readability starts coming into play when you work with someone other then yourself. If I were to ask you what this code segment does, you would have to play with it for a long time just to understand what does what:
This code is what we would call "bad code", and to tell you the truth it was designed that way. This segment of code was written for the International Obfuscated C Code Contest and was written by Natori for the 15th international contest. His code prints out an ASCII moon to the terminal that is representative of the phase of the moon currently. The problem with code today is one of readability.
Refactoring is the idea of taking a segment of code and changing it to act the same externally while changing the internal workings to have reduced complexity as well as improved readability and maintainability. For our homework we had to take some code from the RMH Homebase and refactor a specific piece of code into something more manageable and readable.
Knowing little to no PHP did not help me with this problem, however looking at the code it is easy to see that they are looking for very specific parameters to be true or false. By taking the existing code and just making some additions to spacing and comments allows the next set of people to come along and make modifications.
This (while still ugly) is better then having the next person coming along and not understanding what the if statement is doing. Also having a comment before the if statement explaining what the requirements of the conditional are can also help improve readability. The simple act of adding a line stating "Do the following if the edit is enabled, access is 2 or more, and the year is between X and Y" can make this line just that much better.
The only problem with comments like these are putting programmers into the habit of over commenting their code. I have seen plenty of students who have a teacher who punishes students for not commenting. However, I think that with good variable names and simple structures, comments can become useful for the once in a while complicated structure that we need to solve the problem. Jeff Atwood shares my sentiment about comments in code over in a post on his blog Coding Horror.
#include stdio.h
#include math.h
//What does this do?
double l;main(_,o,O){return putchar((_--+22&&_+44&&main(_,-43,_),_&&o)?(main(-43,++o,O),((l=(o+21)/sqrt(3-O*22-O*O),l*l<4&&(fabs(((time(0)-607728)%2551443)/405859.-4.7+acos(l/2))<1.57))[" #"])):10);}
This code is what we would call "bad code", and to tell you the truth it was designed that way. This segment of code was written for the International Obfuscated C Code Contest and was written by Natori for the 15th international contest. His code prints out an ASCII moon to the terminal that is representative of the phase of the moon currently. The problem with code today is one of readability.
Refactoring is the idea of taking a segment of code and changing it to act the same externally while changing the internal workings to have reduced complexity as well as improved readability and maintainability. For our homework we had to take some code from the RMH Homebase and refactor a specific piece of code into something more manageable and readable.
if ($edit==true && !($days[6]->get_year()<$year || ($days[6]->get_year()==$year && $days[6]->get_day_of_year()<$doy) ) && $_SESSION['access_level']>=2)
Knowing little to no PHP did not help me with this problem, however looking at the code it is easy to see that they are looking for very specific parameters to be true or false. By taking the existing code and just making some additions to spacing and comments allows the next set of people to come along and make modifications.
if ($edit==true //if can edit && //and !($days[6]->get_year()<$year //not before this year || //or ($days[6]->get_year()==$year && $days[6]->get_day_of_year()<$doy) ) //after this year && //and $_SESSION['access_level']>=2) //the access level is 2 or greater
This (while still ugly) is better then having the next person coming along and not understanding what the if statement is doing. Also having a comment before the if statement explaining what the requirements of the conditional are can also help improve readability. The simple act of adding a line stating "Do the following if the edit is enabled, access is 2 or more, and the year is between X and Y" can make this line just that much better.
The only problem with comments like these are putting programmers into the habit of over commenting their code. I have seen plenty of students who have a teacher who punishes students for not commenting. However, I think that with good variable names and simple structures, comments can become useful for the once in a while complicated structure that we need to solve the problem. Jeff Atwood shares my sentiment about comments in code over in a post on his blog Coding Horror.
Tuesday, February 19, 2013
That could be me in x years
Today was the Alumni Symposium at CofC. We had alumni from the computer science department come in and talk to the current students. Each one of them is given 3 minutes to talk about whatever they want to talk about, followed by Q&A from the current students to ask anything they want. The theme for this years event seemed to stem from "personal projects = jobs". Most of the speakers talked about how they got into the position they are now by having personal side projects that they worked on before they started working, and projects that they keep up with even while they have a full time job. The advice only seemed to have one warning, and that was to make sure that if you work on the project outside of work that it does not break the contract. This I think is really good advice, and one that will probably follow me for the rest of my career seeing as how I love working with open source.
Speaking of open source, lately I have been working with Obsidian to get it ready for POSSCON. To understand the code I have been dissecting different parts by changing things here and there to see the changes and understand the control flow of the program. One of the things I'm currently looking into is making the source code IDE independent, and coming up with the tutorials on how to make it work on most of the platforms. That should be an interesting task for me, playing around with ant and writing technical documentation will be a learning experience.
Going back to what I could be doing in the future, I have given a lot of thought into what I want to do as a career path, but I haven't finally decided on anything yet. The main issue that I face is do I want to switch careers halfway down the line, or do I just want to stick to one track? The two tracks that I'm torn between are teaching and software engineering. I love the idea of teaching the next generation, but I feel that without some real world experience (10 years as a software developer or so) that I might not be able to impart extra wisdom to the class (the extra wisdom being non-academic advice). So the way I'm thinking about my future right now is going to work writing software for a few years, and eventually while I work teach on the side. Eventually I would transition from that dual job title and go fully into teaching, the only problem with this is the advice that I have been getting from people. Most of the academics and non-academics that I talk to suggest that I should go straight into teaching and not bother with going into the non-academic sector because of the money. Apparently if I go into the private sector I will get used to a lifestyle, and not want to return to the academia world. I do not know how true this is, but enough people have warned me about it to start putting serious doubts in my head about doing the dual career paths.
Whatever path I decide to take, I still think it would be cool to make the one idea I have had for a while and bring it into fruition. I have always wanted to make a company where the contracts we take on will pay for the bills, while the other half of the company will be a R&D/Open source department. Anyone in the company can take a day a week to work on an open source project (or create one) and put it out there for other people to use. I figure this way the open source software we do use will be improved with the features the company wants, and if people see the work that our workers are capable of they will pay for our services. The other part of the company is the student side. I would love to be able to have students on the team, working on both sides of the company, as well as getting real world experience along the academic experience they are receiving. This is something I really need to put a lot of thought into before my undergrad finishes up, that way I have a clear idea of what I need to do moving forward.
Speaking of open source, lately I have been working with Obsidian to get it ready for POSSCON. To understand the code I have been dissecting different parts by changing things here and there to see the changes and understand the control flow of the program. One of the things I'm currently looking into is making the source code IDE independent, and coming up with the tutorials on how to make it work on most of the platforms. That should be an interesting task for me, playing around with ant and writing technical documentation will be a learning experience.
Going back to what I could be doing in the future, I have given a lot of thought into what I want to do as a career path, but I haven't finally decided on anything yet. The main issue that I face is do I want to switch careers halfway down the line, or do I just want to stick to one track? The two tracks that I'm torn between are teaching and software engineering. I love the idea of teaching the next generation, but I feel that without some real world experience (10 years as a software developer or so) that I might not be able to impart extra wisdom to the class (the extra wisdom being non-academic advice). So the way I'm thinking about my future right now is going to work writing software for a few years, and eventually while I work teach on the side. Eventually I would transition from that dual job title and go fully into teaching, the only problem with this is the advice that I have been getting from people. Most of the academics and non-academics that I talk to suggest that I should go straight into teaching and not bother with going into the non-academic sector because of the money. Apparently if I go into the private sector I will get used to a lifestyle, and not want to return to the academia world. I do not know how true this is, but enough people have warned me about it to start putting serious doubts in my head about doing the dual career paths.
Whatever path I decide to take, I still think it would be cool to make the one idea I have had for a while and bring it into fruition. I have always wanted to make a company where the contracts we take on will pay for the bills, while the other half of the company will be a R&D/Open source department. Anyone in the company can take a day a week to work on an open source project (or create one) and put it out there for other people to use. I figure this way the open source software we do use will be improved with the features the company wants, and if people see the work that our workers are capable of they will pay for our services. The other part of the company is the student side. I would love to be able to have students on the team, working on both sides of the company, as well as getting real world experience along the academic experience they are receiving. This is something I really need to put a lot of thought into before my undergrad finishes up, that way I have a clear idea of what I need to do moving forward.
Thursday, February 14, 2013
What's Happening?
For this blogpost we had to grab a recent article from an ACM or IEEE magazine and talk about it. I chose to write about "The Great and Terrible Oz" by Grady Booch from the January/February 2013 edition of IEEE Software.
The article expresses the importance of education of the public when it comes to computers. As technology use increases and gains momentum the public seem to be getting further and further from how software actually works. Everyone from your parents to politicians are losing touch with how technology works, and this is a problem. The further the curtain puts people out of the knowledge the less they understand about technology and the prevalence of "magic" in the system will increase. I have seen this gone awry many a time. People think that they "just get viruses" because lack of knowledge. People pay a prince in Nigeria to be part of the rich. People steal software because "it is already made". Without the proper knowledge people are going to get more and more lost.
The problem with this day and age is that technology is growing faster than the population can adapt. Sure the tech savvy know what is going on, but the rest of the world will blindly go out and buy iPad's because of targeted advertisements. My parents in particular still ask me for computer help from time to time, but I have trained them to a level where they only ask if they really need help. Another thing that I have done to help them be more educated is to send them videos of scams and tutorials of different technologies. They won't be falling for a 419 scam anytime soon because they know a little bit about electronic banking.
I have also noticed that with education the amount of viruses on a given machine approaches zero. Switching my parents from IE to Chrome (admittedly by tricking them into thinking Chrome was IE) drastically reduced the number of phone calls asking for help. Now, I'm not saying that everyone has to do what I did to my parents (that was for my own personal gain), but a little bit of education goes a long way. With acts going through congress like SOPA and PIPA an education of the public would go a long way of protecting the internet and my job security in the future.
The article expresses the importance of education of the public when it comes to computers. As technology use increases and gains momentum the public seem to be getting further and further from how software actually works. Everyone from your parents to politicians are losing touch with how technology works, and this is a problem. The further the curtain puts people out of the knowledge the less they understand about technology and the prevalence of "magic" in the system will increase. I have seen this gone awry many a time. People think that they "just get viruses" because lack of knowledge. People pay a prince in Nigeria to be part of the rich. People steal software because "it is already made". Without the proper knowledge people are going to get more and more lost.
The problem with this day and age is that technology is growing faster than the population can adapt. Sure the tech savvy know what is going on, but the rest of the world will blindly go out and buy iPad's because of targeted advertisements. My parents in particular still ask me for computer help from time to time, but I have trained them to a level where they only ask if they really need help. Another thing that I have done to help them be more educated is to send them videos of scams and tutorials of different technologies. They won't be falling for a 419 scam anytime soon because they know a little bit about electronic banking.
I have also noticed that with education the amount of viruses on a given machine approaches zero. Switching my parents from IE to Chrome (admittedly by tricking them into thinking Chrome was IE) drastically reduced the number of phone calls asking for help. Now, I'm not saying that everyone has to do what I did to my parents (that was for my own personal gain), but a little bit of education goes a long way. With acts going through congress like SOPA and PIPA an education of the public would go a long way of protecting the internet and my job security in the future.
Subscribe to:
Posts (Atom)