Our assignment this week was to become a bit more knowledgeable on the Open Source world. To this end we read a few articles on http://opensource.com/, and also downloaded and built an open source game called Freeciv.
Since Freeciv was pretty straightforward for me, I will talk about that. I didn't really have any problems downloading or building it, because the directions were fairly easy to follow. This is not to say that they were straightforward or direct however. They tended to meander and lead you on a lot of false trails in an effort to make you fail and teach you how to research problems for yourself. While I can appreciate leading people through the steps they need to solve their own problems, I did not particularly enjoy being jerked around by my book. Though I suppose that in the end, it did manage to give me proper step by step instructions for building Freeciv. Either way, this part of the assignment really didn't give me any problems besides a slight amount of annoyance.
For my first reading from the website, I chose to read 10 ways to get started with open source, by Jason Hibbets. I found this article very informative, and while I had done a few of the steps already, it did provide further insight into how to become further ingrained into the open source community. One of the things that I really found helpful in this article was the link to The Open Source Way. This is an online book that tells you how to get involved with open source communities or how to create your own. I didn't read all of it, but it looks like it will make a valuable resource in the future of our team.
The next article I read was about teaching Python to Children. This article was a basic book review that helps lay out groundwork for teaching python to children. The author seemed very pleased with it, but was more interested in passing along his love for programming to children. He reviews the book and finds it a worthwhile resource for helping to teach adults to teach children python.
My team also had a meeting tonight as well. We split up responsibilities for added functionality to Obsidian, and even solved a bug or two. To assist in understanding Obsidian as a project, we all made UML Class diagrams of the project to help us visualize it. I think this was a very good idea, as it allowed us to each come with questions about the project, and really engage with it in a meaningful way. It also has the added bonus of giving us readable UML Diagrams that we can include in our later documentation of the project.
My part of the project is the first step of Updating, which will allow Obsidian to look at tests that it has already created and determine if it needs to remake them. This kicks in when Obsidian is run twice on the same project of course. We determined the first step in this process is to read in the preexisting tests, so that we have something to compare the new version with. This seems rather simple, but as it is my first step into programming on this project I have a slight amount of trepidation. I have a whole week to get this functionality built, and a whole team to support me though, so I have high hopes.
Wednesday, January 30, 2013
Monday, January 28, 2013
Line 5: Subversion Under Control
Our assignment for this week was to install subversion and get it up and running on our machines. We were to play around with it a little bit, and then download our projects and build them. To this end, Team Obsidian, decided to hold a meeting tonight to get all of our members up and running.
In the last week or so, Hunter got Obsidian posted to a subversion repository hosted at the school. We were all given access to our own little branch of the repository where we may look at, and play with his code, but not actually effect it in any way. We will quickly move out of this state, but for now we all agreed it would be safer for us to learn in an environment where we can't destroy the whole project. We made plans for committing bug fixes in the future, which will involve us going through our code with another member of the project in the hopes that this will prevent faulty code from being pushed. We are also planning on having weekly code reviews, to discuss what our efforts should be focused on each week. Overall, I think these are good precautions to take, and will help us to really focus our efforts and make good progress in bug fixes and making the code more robust.
We are all using the subversion plugin in the NetBeans IDE to commit and checkout our code. This was fairly easy to set up, because you can just run it from inside the IDE. After all members had the project downloaded, Hunter gave a short demonstration of Obsidian and then walked us through the code. He did an admirable job, but as this project is a large amount of code to process, I think I will need to really study it more on my own before I truly get the hang of what it is doing.
Since last I wrote in here, we decided to break from the milestone schedule that we had set for ourselves. The duties we had broken down were each of varying difficulties and lengths, and while some might take all 4 milestones to complete, others would barely take one. Instead, we opted to work on our code base exclusively for the first 2 milestones. This allows each of the members to get familiar with Obsidian, and gain a good understanding of how it works. This way, when we start working on documentation of the project, we will each have that understanding to draw from. We hope that this will make the documentation that much better in the long run.
That being said, I am still going to focus some of my efforts on getting the IRC Channel fully up and running in the next few weeks, and the other members will most likely be tinkering with their given assignments as well. We are just not focusing exclusively on them right now.
We ended our meeting with each member having a working copy of the source code, and a basic understanding of how to utilize it. We will be meeting tomorrow morning to discuss what needs to be done in the coming week.
In the last week or so, Hunter got Obsidian posted to a subversion repository hosted at the school. We were all given access to our own little branch of the repository where we may look at, and play with his code, but not actually effect it in any way. We will quickly move out of this state, but for now we all agreed it would be safer for us to learn in an environment where we can't destroy the whole project. We made plans for committing bug fixes in the future, which will involve us going through our code with another member of the project in the hopes that this will prevent faulty code from being pushed. We are also planning on having weekly code reviews, to discuss what our efforts should be focused on each week. Overall, I think these are good precautions to take, and will help us to really focus our efforts and make good progress in bug fixes and making the code more robust.
We are all using the subversion plugin in the NetBeans IDE to commit and checkout our code. This was fairly easy to set up, because you can just run it from inside the IDE. After all members had the project downloaded, Hunter gave a short demonstration of Obsidian and then walked us through the code. He did an admirable job, but as this project is a large amount of code to process, I think I will need to really study it more on my own before I truly get the hang of what it is doing.
Since last I wrote in here, we decided to break from the milestone schedule that we had set for ourselves. The duties we had broken down were each of varying difficulties and lengths, and while some might take all 4 milestones to complete, others would barely take one. Instead, we opted to work on our code base exclusively for the first 2 milestones. This allows each of the members to get familiar with Obsidian, and gain a good understanding of how it works. This way, when we start working on documentation of the project, we will each have that understanding to draw from. We hope that this will make the documentation that much better in the long run.
That being said, I am still going to focus some of my efforts on getting the IRC Channel fully up and running in the next few weeks, and the other members will most likely be tinkering with their given assignments as well. We are just not focusing exclusively on them right now.
We ended our meeting with each member having a working copy of the source code, and a basic understanding of how to utilize it. We will be meeting tomorrow morning to discuss what needs to be done in the coming week.
Wednesday, January 23, 2013
Line 4: Joining the Project
After forming teams officially last class period, we all jumped into the projects that we chose to pursue. My team, Team Obsidian, had been unofficially meeting for a week or so prior to forming. We used this time to lay the groundwork of our project, and develop a tentative presence online for it. Included in these tasks was setting up an IRC channel, mailing lists, a Google Code page, and the beginnings of our team, and project wikis. We also set a schedule to work by, with milestones being due every 2 or 3 weeks. Hammering out details like this and coming up with a cohesive plan to launch Obsidian into the world of open source software really allowed us to take an active stance on our work.
We accomplished all of the tasks listed above, and are now refining each of them so that by the end of the semester we will have a fully functioning open source community. These accomplishments felt like a major step for our group cohesion, and allowed us to start developing real bonds of trust between each other.
Personally, I was responsible for registering our IRC Channel and Twitter account. Since Twitter was the easier of the two tasks, I attacked it first. We decided in our preliminary meeting that we would be using twitter as a sort of quick news post for our project. @ObsidianTesting will be currently posting updates about what we are working on. Later in the semester it will be more of a tool for communicating with the community we hope to create. The IRC Channel was something that Mike and I worked on together. We looked into a few channels on freenode.net, and registered #obsidiantesting as our own. One channel we looked at before registering ours was #obsidian, however it had a single user idling in it every time we checked. Since the room was created by the freenode staff, we decided that we will ask them for ownership of it in the future, when we have a more comprehensive online presence for the project.
When the group met today, I brought the rest of them up to speed on IRC basics, and got them up and running. They each discussed their parts of the project and we made plans to meet again on Monday.
For now, it looks like my responsibilities will lay mostly with the IRC channel and the twitter account. I plan to talk to Dr. Starr about some twitter accounts he feels would be worthwhile for us to follow. I also am going to begin tweeting updates about our project, so that we can hopefully begin to get some followers. In regards to IRC tasks, my next plan is to add a bot to sit in the channel for us. The bot will be in charge of issuing op commands for the channel when we message him with the commands. This allows us to appear as regular users, which Michael says is important so that we do not scare off new visitors to the channel.
All in all, I think this was a good start for our team.
We accomplished all of the tasks listed above, and are now refining each of them so that by the end of the semester we will have a fully functioning open source community. These accomplishments felt like a major step for our group cohesion, and allowed us to start developing real bonds of trust between each other.
Personally, I was responsible for registering our IRC Channel and Twitter account. Since Twitter was the easier of the two tasks, I attacked it first. We decided in our preliminary meeting that we would be using twitter as a sort of quick news post for our project. @ObsidianTesting will be currently posting updates about what we are working on. Later in the semester it will be more of a tool for communicating with the community we hope to create. The IRC Channel was something that Mike and I worked on together. We looked into a few channels on freenode.net, and registered #obsidiantesting as our own. One channel we looked at before registering ours was #obsidian, however it had a single user idling in it every time we checked. Since the room was created by the freenode staff, we decided that we will ask them for ownership of it in the future, when we have a more comprehensive online presence for the project.
When the group met today, I brought the rest of them up to speed on IRC basics, and got them up and running. They each discussed their parts of the project and we made plans to meet again on Monday.
For now, it looks like my responsibilities will lay mostly with the IRC channel and the twitter account. I plan to talk to Dr. Starr about some twitter accounts he feels would be worthwhile for us to follow. I also am going to begin tweeting updates about our project, so that we can hopefully begin to get some followers. In regards to IRC tasks, my next plan is to add a bot to sit in the channel for us. The bot will be in charge of issuing op commands for the channel when we message him with the commands. This allows us to appear as regular users, which Michael says is important so that we do not scare off new visitors to the channel.
All in all, I think this was a good start for our team.
Tuesday, January 22, 2013
Line 3: FOSS Experiences and Reflections
Over
the weekend we had a mini exercise to give us a refresher on
downloading and building open source software. We were simply expected
to get any open source project, and construct it on our machine. Since I
am working with Team Obsidian, and Hunter
is still putting some finishing touches on his code before he makes it
public to us, I downloaded and built my project from last semester
again.
Last semester I worked with a team to develop an automated testing framework for the Google Visualization Suite, specifically focusing on Google Charts. So, I re-downloaded and built the code again on my machine. It went off pretty much without a hitch, since I had done the same thing a semester ago.
With that done, I set about on some activities for my team. I had been put of setting up the IRC channel for our project on freenode.net. We discussed using freenode, because it is very popular among open source projects. So, Michael Cole and I went onto IRC to play around and check out some channels. We investigated #obsidian, #obsidiantest, and #obsidiantesting. The #obsidian room had another person in it, but both other rooms were not owned at all. We decided to register #obsidiantesting for now, and try to obtain the room #obsidian in the future, as it does not seem to be in active use.
After this, I tackled the second part of our homework. This was to read the paper “The Cathedral and the Bazaar” by Eric S. Raymond. This paper was about the author’s experiences as he was developing a mail client using Linus Torvalds’ approach to open source software development. These principles basically come down to releasing early and often, and allowing as many people to help you develop as you possibly can. He compares this approach to a Bazaar, where anyone can set up and contribute to the market in their own way. This is in comparison to traditional software development, in which a few designers are responsible for all major decisions. They decide the direction of the project, and are ultimately responsible for the final incarnation.
He compares and contrasts the two methods, and ultimately walks away very impressed with the bazaar style. He numbers out notions that he considers to be very important to this development style, from the very easy release early and often, to other findings. One that really grabbed my attention was the idea that if you communicate with your beta testers like they are your greatest asset, they will become your greatest asset. I liked this part, because he talked about many methods of communicating with his testers, and how they met his enthusiasm with equal enthusiasm of their own.
One other thing I found interesting was his theory on why Linux has such a high quality of code. He posits that because the people working on the project are so excited about the part they are working on, they make it much better than they would had they been forced to work on something they were not interested in or did not love. I agree with this theory quite a bit, and I think that it bodes well for our project. All of our team members seem to be very enthusiastic and proactive about tackling the parts of the project that they were assigned.
Last semester I worked with a team to develop an automated testing framework for the Google Visualization Suite, specifically focusing on Google Charts. So, I re-downloaded and built the code again on my machine. It went off pretty much without a hitch, since I had done the same thing a semester ago.
With that done, I set about on some activities for my team. I had been put of setting up the IRC channel for our project on freenode.net. We discussed using freenode, because it is very popular among open source projects. So, Michael Cole and I went onto IRC to play around and check out some channels. We investigated #obsidian, #obsidiantest, and #obsidiantesting. The #obsidian room had another person in it, but both other rooms were not owned at all. We decided to register #obsidiantesting for now, and try to obtain the room #obsidian in the future, as it does not seem to be in active use.
After this, I tackled the second part of our homework. This was to read the paper “The Cathedral and the Bazaar” by Eric S. Raymond. This paper was about the author’s experiences as he was developing a mail client using Linus Torvalds’ approach to open source software development. These principles basically come down to releasing early and often, and allowing as many people to help you develop as you possibly can. He compares this approach to a Bazaar, where anyone can set up and contribute to the market in their own way. This is in comparison to traditional software development, in which a few designers are responsible for all major decisions. They decide the direction of the project, and are ultimately responsible for the final incarnation.
He compares and contrasts the two methods, and ultimately walks away very impressed with the bazaar style. He numbers out notions that he considers to be very important to this development style, from the very easy release early and often, to other findings. One that really grabbed my attention was the idea that if you communicate with your beta testers like they are your greatest asset, they will become your greatest asset. I liked this part, because he talked about many methods of communicating with his testers, and how they met his enthusiasm with equal enthusiasm of their own.
One other thing I found interesting was his theory on why Linux has such a high quality of code. He posits that because the people working on the project are so excited about the part they are working on, they make it much better than they would had they been forced to work on something they were not interested in or did not love. I agree with this theory quite a bit, and I think that it bodes well for our project. All of our team members seem to be very enthusiastic and proactive about tackling the parts of the project that they were assigned.
Wednesday, January 16, 2013
Line 2: My FOSS Preferences
The
first step to contributing to an open source project is obviously to
research which one you want to contribute to. My search for a project
was probably a little bit different from many of my classmates’ because I
was approached by some classmates who already had a project in mind.
However, I still did a little bit of research on my own. I will use this
opportunity to talk about 2 open source projects, before I talk about
the project that my classmates want me to join them on.
One of the famous open source software projects is Mozilla Firefox. It is an open source web browser is developed for Windows, OSX, and Linux platforms. It is probably one of the more popular open source projects that I am familiar with. In fact, Firefox is my web browser of choice. One of the interesting things about it is the high amount of add-ons for it. These work to help the user customize their browser and add functionality to it.
Another large open source projects is the Linux operating system. This project exists to give users a choice of a free operating system that is able to compete with major commercial releases. Linux is also fully customizable, and many users have created many different forms of it. These Linux distributions allow users to have a choice in how they want the operating system to run. Some distros emphasize speed, while others focus more on ease of use. Anybody can create their own Linux distro and release it to the public. If it becomes popular enough, then the community at large might adopt it. This type of approach to software is highly indicative of the open source mindset. You are able to take the base releases, and add to them until they are suitable for your needs.
However, it is unlikely that I will work on either of these projects, because as I said before, I was approached by a group to help them with their project. Michael Cole, Hunter Hegler, Joanna Illing, and Laryea Quaye asked me if I would help them work on creating the community for an open source project. I can’t say much about the project right now because the paper describing it has not been presented to the community at large, but I can say that it is called Obsidian, and is test case creation software. Like I said earlier, this semester we will be responsible for trying to foster a community for this project. This will require us to make a wiki to tell people how to get our software up and running, an IRC channel where people can ask questions in a live environment, creating a website for the software, and many other tasks to get people to adopt Obsidian.
Overall, I am very excited by this project right now. I like the idea of trying to create a community for this project. We will also be trying to make the software better throughout the semester, but I think that the majority of our time will be focused on getting this software’s name out there. I feel like there is a lot to learn from this, and I look forward to the semester eagerly.
One of the famous open source software projects is Mozilla Firefox. It is an open source web browser is developed for Windows, OSX, and Linux platforms. It is probably one of the more popular open source projects that I am familiar with. In fact, Firefox is my web browser of choice. One of the interesting things about it is the high amount of add-ons for it. These work to help the user customize their browser and add functionality to it.
Another large open source projects is the Linux operating system. This project exists to give users a choice of a free operating system that is able to compete with major commercial releases. Linux is also fully customizable, and many users have created many different forms of it. These Linux distributions allow users to have a choice in how they want the operating system to run. Some distros emphasize speed, while others focus more on ease of use. Anybody can create their own Linux distro and release it to the public. If it becomes popular enough, then the community at large might adopt it. This type of approach to software is highly indicative of the open source mindset. You are able to take the base releases, and add to them until they are suitable for your needs.
However, it is unlikely that I will work on either of these projects, because as I said before, I was approached by a group to help them with their project. Michael Cole, Hunter Hegler, Joanna Illing, and Laryea Quaye asked me if I would help them work on creating the community for an open source project. I can’t say much about the project right now because the paper describing it has not been presented to the community at large, but I can say that it is called Obsidian, and is test case creation software. Like I said earlier, this semester we will be responsible for trying to foster a community for this project. This will require us to make a wiki to tell people how to get our software up and running, an IRC channel where people can ask questions in a live environment, creating a website for the software, and many other tasks to get people to adopt Obsidian.
Overall, I am very excited by this project right now. I like the idea of trying to create a community for this project. We will also be trying to make the software better throughout the semester, but I think that the majority of our time will be focused on getting this software’s name out there. I feel like there is a lot to learn from this, and I look forward to the semester eagerly.
Monday, January 14, 2013
Line 1
The purpose of this blog is to chronicle my time spent working and learning in the Software Engineering Practicum at the College of Charleston. This class is meant to expose students to open source projects, and have them jump in and start contributing to these projects. The end goal is we, the students, develop our programming skills in a real world environment, and also better the programming world through our efforts. Later in the semester we will be attending the Palmetto Open Source Software Convention, or POSSCON for short. We will be meeting with members of the open source community and discussing their projects, and our own experiences in the open source community with them. I am actually looking forward to this event quite a bit, as other tech community events such as Charleston Barcamp and the Pecha Kucha talks have both provided excellent experiences to me.
As this is my first post, I suppose I will provide a slight introduction for myself. I am Micah Jenkins. I am a senior at the College of Charleston, majoring in Computer Science. I first began programming when I was a junior in high school, and grew to love it from there.
This class marks the second half of a yearlong class chain that focuses on software engineering, and the techniques and organization that the discipline requires. Last semester we were split into groups and required to develop an automated testing framework to test an open source project of our choosing in Linux. My group last semester worked on the Google Visualization suite, which is a tool for generating and manipulating data and outputting it into HTML code for embedding in websites.
My team generated 25 unique test cases that test different parts of the source code, and an automated framework to run and report on these test cases. We also developed a poster that will be shown at the College's Math and Science Poster Session.
That experience was immensely valuable to me, and it really opened the door for this semester. We picked up many skills, such as usage of online repositories like subversion, knowledge of scripting to automate processes, and gaining familiarity with Linux (specifically the Ubuntu distribution). It was a great preparatory experience and got me excited to actually contribute to one of these projects this semester rather than just extensively test on one.
So far, we have created a class wiki where all of our class blogs are linked, and we are all going to be blogging about 1000 words a week on our progress. By the end of this projects, we hope to have contributed in some way to the open source project we choose as groups, whether this be by doing bug fixes, or trying to help out in the community. Some projects will be big, and others will be small. Some might even require their groups to create the community for them by setting up wikis and how-to instructions for building and running the code. The projects I have researched so far all seem to have middling to large communities, but I think that working on a small project could be a very rewarding experience as well. This project, and semester, looks to be quite an interesting one.
As this is my first post, I suppose I will provide a slight introduction for myself. I am Micah Jenkins. I am a senior at the College of Charleston, majoring in Computer Science. I first began programming when I was a junior in high school, and grew to love it from there.
This class marks the second half of a yearlong class chain that focuses on software engineering, and the techniques and organization that the discipline requires. Last semester we were split into groups and required to develop an automated testing framework to test an open source project of our choosing in Linux. My group last semester worked on the Google Visualization suite, which is a tool for generating and manipulating data and outputting it into HTML code for embedding in websites.
My team generated 25 unique test cases that test different parts of the source code, and an automated framework to run and report on these test cases. We also developed a poster that will be shown at the College's Math and Science Poster Session.
That experience was immensely valuable to me, and it really opened the door for this semester. We picked up many skills, such as usage of online repositories like subversion, knowledge of scripting to automate processes, and gaining familiarity with Linux (specifically the Ubuntu distribution). It was a great preparatory experience and got me excited to actually contribute to one of these projects this semester rather than just extensively test on one.
So far, we have created a class wiki where all of our class blogs are linked, and we are all going to be blogging about 1000 words a week on our progress. By the end of this projects, we hope to have contributed in some way to the open source project we choose as groups, whether this be by doing bug fixes, or trying to help out in the community. Some projects will be big, and others will be small. Some might even require their groups to create the community for them by setting up wikis and how-to instructions for building and running the code. The projects I have researched so far all seem to have middling to large communities, but I think that working on a small project could be a very rewarding experience as well. This project, and semester, looks to be quite an interesting one.
Subscribe to:
Posts (Atom)