This is it. It's all come down to this. Tomorrow is the last day of classes, team presentations will be May 2nd, and then the semester is over. So this will be my last blog post for this class. That being said, I want to discuss how I felt about the class and give some well-deserved thanks...
Overall Experience
Aside from the frustrations I had trying to get RMH Homebase to work on my machine (which is still a no-go), my experience in this course has been a good one. I'm honestly just not that fond of that particular project, which is why I'm eternally grateful to each of my team members for not considering that project for our team project this semester. I feel that, when looking at some of the code, it just wasn't as thoroughly thought out as it should have been. Like my classmates Marianne Rogers and Trevor Mehard said during their experience presentation, I hope the author of Software Development will pick a different project for the next edition of the book.
I liked the Teaching Open Source online textbook. Not only does it discuss open source, it IS open source, and I loved that. The exercises were great in each chapter of TOS and really got you to understand exactly what you were reading and doing. This should definitely be made a permanent fixture in the required textbooks for this class. I honestly feel that I learned more from this book than I did from the other textbook.
The lectures we had were different from any other course I took this semester because Dr. Bowring didn't sit there and lecture us; he sort of let us do the lecturing. For every assignment we had, we would sit in class and share our experiences and thoughts about it with everyone. We'd discuss what went right, what went wrong, what we liked, what we didn't like....collaboration was encouraged. I also felt the assignments related to what we were doing as well. We were allowed to use the blogs of other students in the class as a reference if we got stuck, and we were also allowed to work with a partner on assignments if we had difficulties. The best part of this course was getting to go to POSSCON. It was incredible and I got to meet so many interesting and amazing people, and I learned a lot about open source software there.
Thank Yous
I'd like to start off by saying that overall, this has been a great course. A lot of classes you take in computer science will only go so far as to teach you the theory behind the things you have to do in the real world. This class has been different. Dr. Bowring let us go beyond that and get a taste of what working on software projects in the real world can be like. So thank you, Dr. Bowring, for that.
A HUGE thank you goes out to Scott Rosenbrook and Erin McCall. Without your blogs as a guide I would not have been able to get as far as I did on some of the assignments.
Thanks to the XBMC Community for allowing my teammates and I to work on your project. It was an awesome experience.
Finally, to my teammates: Jimmy Joy, Jason Leonard, David Schirduan, and Matthew Vaveris....I could not have asked for a better group of guys to work with. Thanks for being awesome, guys. And we're going to rock that team presentation :).
Sunday, April 22, 2012
SD Chapter 8: Developing the User Interface
The user interface, as we all know, is main way that users interact with the software. It is one of the most important elements of a piece of software. The book outlines the design principles essential to making a good user interface. Here's the list with the descriptions from the book:
- Completeness - "All the steps of every use case in the design must appear on a page or group of related pages in the user interface, but no more." In other words, the user interface should be designed with every possible scenario that could happen in mind.
- Language - "The language of the interface must be consistent with the language of the domain and the user. All labels and user options that appear on individual pages must be consistent with their counterparts in the design document and the application's domain."
- Simplicity - "No page should contain too much information or too little. Each page should be pleasant to view, yet its functionality should not be buried by excessive detail or elaborate stylistics." It's the basic rule for all user interfaces - if it takes longer than 15 seconds to figure it out, it needs to be redone. Simplicity is a key component because, let's face it, no one wants to spend more than a minute or have to buy a book to figure out how to navigate the user interface for the software they're using.
- Navigability - "Navigation within a page and among different pages should be simple, explicit, and intuitive." This goes along with the previous one.
- Feedback and Recovery - "Each page must provide the user with a clear indication of what has just been done, what can be done next, and how to undo what has just been done." If for some reason a user entered incorrect information and wanted to retrieve it for correction, there needs to be a way for users to recover that data.
- Data Integrity - "The types and valid values for individual user data entries must be clearly indicated. the software should validity-check all data at the time of entry and the user should be required to correct errors before the data are kept in the database." In other words, users need to know exactly what they should enter or be entering into the database. We wouldn't want the wrong data!
- Client-server Integrity - "The activities of several different users who happen to be using the system at the same must be kept separate and independent." This is crucial, otherwise data would get mixed up, or worse, the server could crash. And that is the last thing anyone wants for their software.
- Security - "An individual user should have access to the system's functionality, but only that functionality for which he/she is authorized." Any information, but especially sensitive information about users, should be safe from any outside access. This is pretty much a given.
- Documentation - "Ever page or group of pages in the user interface should be linked to a step-by-step on-line instruction that teaches a user how that page can be used to accomplish a task." Just in case the user can't figure it out, there should always be documentation to explain what the software is for and how to use it.
Team TripleJ Update
I missed the team meeting two weeks ago due to a previous engagement with family, so I haven't posted a team update in a while and thought I should post something. We haven't had a team meeting last week or today because of conflicts that arose, but we met after class and during class time when Dr. Bowring allowed all of the teams to do so. As you can see in one of my recent posts, we just had the School of Science and Mathematics Research Poster Session and I have to say our poster looked amazing. It's now hanging up with the others in the halls of the Computer Science Department for all to see.
We've decided to meet this Thursday and next Sunday to prepare for the team presentations on May 2nd. Instead of a final exam, each team is to do a presentation on their project and experiences with it over the course of the semester. I believe Dr. Bowring is going to give us more specific information on that tomorrow, the last day of class.
We've decided to meet this Thursday and next Sunday to prepare for the team presentations on May 2nd. Instead of a final exam, each team is to do a presentation on their project and experiences with it over the course of the semester. I believe Dr. Bowring is going to give us more specific information on that tomorrow, the last day of class.
TOS Chapter 5
This chapter is about building code and working with Freeciv. So what are the steps when building?
The chapter lists some things you should keep in mind when doing any of this:
- Compiling the code - Source code has to become machine code, and compilers take care of that for you.
- Linking object files and libraries - You need to know exactly what libraries have to be included in order for the code to work before compiling because the compiler will be expecting them to be there.
- Determining build order and dependencies - Keeping track of all the dependencies needed is a tall order, but a necessity. After all, a change to a single line of code in one library can have an effect across the entire project.
- Testing the build results - Testing for bugs sooner rather than later is a very good idea. You wouldn't want to let untested code be unleashed into the technological world, would you? I didn't think so.
- Packing/Deploying - You can install the program you just built so it can be run anywhere on the system and other programs/users can find it, or you can bundle it all together into a format that lets anyone take your executable and install it themselves. While this isn't necessary for every build you do, you will want to do this for the builds you know are good.
The chapter lists some things you should keep in mind when doing any of this:
- Read instructions carefully - It's just like when you're assembling a piece of furniture. Do you take all the pieces, pick up a hammer or drill and say, "I don't need anything to tell me what to do! I can do this without instructions!" If this is your philosophy, then it needs to be changed. Now. Just like your furniture, every project has a different set of dependencies needed to be built and installed so look at the README file carefully and make sure you have all you need before starting.
- Don't expect to understand every word - You're probably not going to be able to look at every word in a build log and say "I know what that means", so you better understand that right now beforehand. Even developers don't understand everything they read in the build logs they encounter, so don't feel bad if you don't.
- Read logs carefully and thoughtfully - This. Is. Crucial. Whenever you encounter an error, read what the program is telling you and try to figure out what it means instead of glancing at it and saying "meh, I'll figure that out later". And don't freak out either, just read it and try to work your way through it. That's the best approach.
- Google is your friend - In times of error message translation troubles, this one should actually read "Google is your bestest best friend in the whole wide world". Like Princess Leia in Star Wars, sometimes you have to pull up the Google search page and say, "You're my only hope". Chances are someone else out there encountered the exact same error and knows how to handle it.
- Ask for help - After everything is done and you still don't know what's going on, it's ok to ask for help. Go to the wiki, IRC channel, mailing list, and even the message boards to find the help you need with a particular problem.
TOS Chapter 4
This chapter covers source control management (SCM) tools and how to use them, specifically teaching you how to use Subversion.
Exercise 4.2.1 - Installing Subversion
I was first introduced to Subversion last semester when Dr. Bowring had us use it as a way to communicate with our team members and keep our projects updated. I can honestly say that I wish we had read this introduction last semester because we had to learn how to use it on our own, and it can be a bit confusing at first. I think it took me a little over a month to finally get the hang of Subversion once I figured everything out all the features I had to use.
The first step is to "check out" a working copy of the code you want to work on. This basically means you're going to ask Subversion through a series of commands to download a copy of the code to your computer, that way you'll be able to look through it and make corrections/additions to the copy of the code that you have without having to worry about messing up the code that's already out there.
Exercise 4.4.1 - Initial Checkout of the Sample Codebase
Subversion claims that it can't checkout the code I'm supposed to get for this exercise, saying "Host not found". Well, that's not good.
As this chapter explains, there's a work cycle that normally takes place when using SVN:
Update your working copy
--> svn update
Make changes
--> svn add
--> svn delete
--> svn copy
--> svn move
Examine your changes
--> svn status
--> svn diff
Possibly undo some changes
--> svn revert
Resolve conflicts (merge others' changes)
--> svn update
--> svn resolved
Commit your changes
--> svn commit
This cycle is basically what you do every day, minus using all the fancy tools that Subverison offers.
Exercise 4.5.1 - Update your Working Copy
I can't do this exercise because I can't get a working copy checked out to my Subversion.
Making changes to your code isn't hard to get the hang of. It's similar to making patches. You can do file changes or tree changes. File changes can be made with a text editor, and Subversion automatically checks for which files have had changes made, and it also handles binary files as well as text files. Tree changes can be made by asking Subversion to mark files/directories scheduled for removal, addition, copying or moving. These changes might take place immediately in your working copy, but they won't show up in the code in the repository until you've committed them. There are 5 Subversion commands that are normally used when making tree changes: svn add foo, svn delete foo, svn copy foo bar, svn move foo bar, and svn mkdir blort.
Exercise 4.6.1 - Create a Biography File and Add it to the Local Repository
Once again, I can't do the exercise because of the problem I had getting the code checked out.
To take an overall look at any changes you make in the code, use the svn status command. This command will detect all file and tree changes made to the code if you use it with no arguments. Using the command with a specific path will show changes made only to that particular item. svn status -u will predict conflicts between files. The svn diff command will do the same thing, just the shorter version.
But what if you decide you don't like the changes you made to a file, or you accidentally deleted a file? Never fear, my friends, for all you have to do is use the svn revert command. This command will revert the file to its pre-modified state (i.e., what it was before you messed with it). Pretty nifty!!
If you're making changes and you update and get a "C" next to your file, well then you've got a conflict. Conflicts mean that changes in the server overlapped with your own. Every time a conflict occurs, Subversion will do 3 things:
1. Print C during the update, remembering that the file is in a state of conflict.
2. If Subversion thinks that the file is manageable, it will place special conflict markers that delimit the sides of the conflict into the file to visibly demonstrate the overlapping areas.
3. For every conflicted copy, Subversion places 3 extra unversioned files in your working copy: filename.mine (your file as it existed in the working copy before the update and without conflict markers, and isn't created if the file isn't considered to be manageable); filename.rOLDREV (the file that was the BASE revision before the update, i.e. the file you checked out before you made the edits, with OLDREV being the revision number of the file in your repository); and filename.rNEWREV (the file your Subversion client just received from the server when you updated your copy, and it corresponds to the HEAD revision of the repository, with NEWREV being the revision number of the repository HEAD).
If you experience any confusion when this happens, just consult these 3 files to get it straightened out. You can also copy one of the temp files created by Subversion into your working copy if you want to get rid of the changes you made, or just revert them if you decided to scrap what you've done and start over.
Once you've made your changes, done updates and resolved any conflicts that came up, and all systems are go, then it's time to commit your work! Just use the svn commit to send all of your changes to the repository. You add a log message to it by putting -m at the end of the command, or use -F to pass the file name of the message you want to put with it.
Exercise4.11.1 - Commit Code to the Repository
Can't do it, Subversion still being uncooperative.
Well, I pictured that going a bit differently, but still an informative reading!
Exercise 4.2.1 - Installing Subversion
I was first introduced to Subversion last semester when Dr. Bowring had us use it as a way to communicate with our team members and keep our projects updated. I can honestly say that I wish we had read this introduction last semester because we had to learn how to use it on our own, and it can be a bit confusing at first. I think it took me a little over a month to finally get the hang of Subversion once I figured everything out all the features I had to use.
The first step is to "check out" a working copy of the code you want to work on. This basically means you're going to ask Subversion through a series of commands to download a copy of the code to your computer, that way you'll be able to look through it and make corrections/additions to the copy of the code that you have without having to worry about messing up the code that's already out there.
Exercise 4.4.1 - Initial Checkout of the Sample Codebase
Subversion claims that it can't checkout the code I'm supposed to get for this exercise, saying "Host not found". Well, that's not good.
As this chapter explains, there's a work cycle that normally takes place when using SVN:
Update your working copy
--> svn update
Make changes
--> svn add
--> svn delete
--> svn copy
--> svn move
Examine your changes
--> svn status
--> svn diff
Possibly undo some changes
--> svn revert
Resolve conflicts (merge others' changes)
--> svn update
--> svn resolved
Commit your changes
--> svn commit
This cycle is basically what you do every day, minus using all the fancy tools that Subverison offers.
Exercise 4.5.1 - Update your Working Copy
I can't do this exercise because I can't get a working copy checked out to my Subversion.
Making changes to your code isn't hard to get the hang of. It's similar to making patches. You can do file changes or tree changes. File changes can be made with a text editor, and Subversion automatically checks for which files have had changes made, and it also handles binary files as well as text files. Tree changes can be made by asking Subversion to mark files/directories scheduled for removal, addition, copying or moving. These changes might take place immediately in your working copy, but they won't show up in the code in the repository until you've committed them. There are 5 Subversion commands that are normally used when making tree changes: svn add foo, svn delete foo, svn copy foo bar, svn move foo bar, and svn mkdir blort.
Exercise 4.6.1 - Create a Biography File and Add it to the Local Repository
Once again, I can't do the exercise because of the problem I had getting the code checked out.
To take an overall look at any changes you make in the code, use the svn status command. This command will detect all file and tree changes made to the code if you use it with no arguments. Using the command with a specific path will show changes made only to that particular item. svn status -u will predict conflicts between files. The svn diff command will do the same thing, just the shorter version.
But what if you decide you don't like the changes you made to a file, or you accidentally deleted a file? Never fear, my friends, for all you have to do is use the svn revert command. This command will revert the file to its pre-modified state (i.e., what it was before you messed with it). Pretty nifty!!
If you're making changes and you update and get a "C" next to your file, well then you've got a conflict. Conflicts mean that changes in the server overlapped with your own. Every time a conflict occurs, Subversion will do 3 things:
1. Print C during the update, remembering that the file is in a state of conflict.
2. If Subversion thinks that the file is manageable, it will place special conflict markers that delimit the sides of the conflict into the file to visibly demonstrate the overlapping areas.
3. For every conflicted copy, Subversion places 3 extra unversioned files in your working copy: filename.mine (your file as it existed in the working copy before the update and without conflict markers, and isn't created if the file isn't considered to be manageable); filename.rOLDREV (the file that was the BASE revision before the update, i.e. the file you checked out before you made the edits, with OLDREV being the revision number of the file in your repository); and filename.rNEWREV (the file your Subversion client just received from the server when you updated your copy, and it corresponds to the HEAD revision of the repository, with NEWREV being the revision number of the repository HEAD).
If you experience any confusion when this happens, just consult these 3 files to get it straightened out. You can also copy one of the temp files created by Subversion into your working copy if you want to get rid of the changes you made, or just revert them if you decided to scrap what you've done and start over.
Once you've made your changes, done updates and resolved any conflicts that came up, and all systems are go, then it's time to commit your work! Just use the svn commit to send all of your changes to the repository. You add a log message to it by putting -m at the end of the command, or use -F to pass the file name of the message you want to put with it.
Exercise4.11.1 - Commit Code to the Repository
Can't do it, Subversion still being uncooperative.
Well, I pictured that going a bit differently, but still an informative reading!
Thursday, April 19, 2012
Poster Session Awesomeness
Well, it all came down to this...the CofC School of Science and Mathematics Research Poster Session!! I got there about 10 minutes before it started so I could find the poster (David set it up 30 minutes prior to the session starting I think), and the other teams from my class were on the same floor, but not all in the same area. I took a look around at some of the other posters on display, and I have to say there were some pretty impressive projects.
We had a couple of members from the Board of Trustees stop and talk to us about our poster. They asked us questions about the project and the software engineering practicum class. Dr. Bowring was there and had a poster there for a project he's working on with one of the students in the department. Dr. Starr, the department chair, was also there to see what projects had been entered by computer science students.
Below is a picture of the poster we submitted. We decided not to submit it for judging so no pretty maroon ribbon for us, but that's ok :) . Overall, I'd say it went very well!
We had a couple of members from the Board of Trustees stop and talk to us about our poster. They asked us questions about the project and the software engineering practicum class. Dr. Bowring was there and had a poster there for a project he's working on with one of the students in the department. Dr. Starr, the department chair, was also there to see what projects had been entered by computer science students.
Below is a picture of the poster we submitted. We decided not to submit it for judging so no pretty maroon ribbon for us, but that's ok :) . Overall, I'd say it went very well!
Monday, April 9, 2012
The Wonderful World of POSSCON
First off, I have to say that I truly enjoyed going to POSSCON. I learned a lot during those two days about the influence of open source software and it's involvement in the world. I want to share with you some notes from some of the presentations that I attended as well as the mini interviews I did with the three people listed in my blog post from March 25th. So sit back, relax, and enjoy the highlights from POSSCON :) .
"Opening" Up the Prisons: How Open Source Solutions improve IT services and control costs at the SC Department of Corrections
Litz started by explaining his job, the number of "clients" (referring to the inmates) who access computers, and the budget. The budget for the DOC prisons is $400 million. How much does the IT department there get? $3.3 million, and of that amount about $1.5 million goes towards the upkeep of outdated technology. It's a sad thing to hear, but completely understandable when you have 22,500 inmates to look after. Litz went into a little overview of the software, and presented two open source budget solutions: cost averse and cost control. The first is not a plan that the government likes (mainly because there wouldn't be a vendor to blame), one which implements only FOSS with direct replacement of licensed software and support from an online community. The latter option would include the purchase of support contracts and licensed FOSS versions, implement support/license on production servers only, and would have development test and QA servers run pure FOSS solutions on the older Intel-based servers.
I was able to catch up with him later that day, and ask him a couple of questions.
Q: How did you get started with working for the Department of Corrections?
Litz: "I had just graduated from the University of South Carolina and started with DOC as a programmer. As I was working there the systems managers started giving me more tasks to work on, and I built trust with them as I completed more and more of them, and I worked my worked my way up."
Q: I know you do some travelling with your job to go to conferences like this one, but do you work here at the main office or go to one of the institutions in another part of the state to solve a problem with the system?
Litz: "I work here at the DOC headquarters here in Columbia and help solve problems remotely using the network we have set up."
Lunch came next, and for my "Birds of a Feather" session I chose to go to the one given by Jon "Maddog" Hall with Linux International. I think this was one of the best decisions I made the whole time I was at POSSCON. Maddog is an interesting fellow, and it was an entertaining lunch to say the least. He told a few anecdotes and basically let us take control of the session by asking whatever questions we wanted.
The next session I attended was given by the second speaker I'd chosen, Carol Smith, about Google Summer of Code. GSOC is a program designed to encourage college students to participate in open source software development ("flip bits, not burgers"). The students send in an application and project proposal, which Google passes on to the participating companies. These companies choose which students they want working for them over the summer. (For more information, go to their website here.)
I spoke to Carol Smith after the session was over and asked her a couple of questions....
Q: You have a degree in photo journalism. How did you get in involved with Google?
Smith: "A friend recommended that I apply for a job there. I started as an administrative assistant and got involved with some other programs there, and the woman who ran GSOC left so I took the position."
Q: What's your favorite thing about working for Google?
Smith: "That I feel appreciated and not like I'm replaceable. I'm not treated like I'm just another cog in the workings of the company."
I finished off my day by attending a demo for GitHub, where they showed how they use their own software to run the software. This session was given by Ben Bleikamp who is a designer at GitHub. Bleikamp went through the various features of the site and software tools.
I didn't go to as many sessions on the second day as the first, mostly because I only had one interview left and his session was the only one I had definitely planned on attending at that point. I also had a pair programming assignment in another class and was trying to communicate with my partner for a good portion of the day.
I started the second day of sessions (after the keynote) by going to "Open Security: How DHS is deploying open source software to address national cyber security challenges", given by Douglas Maughan, Ph.D., Director of the Department of Homeland Security's Science & Technology Division, Cyber Security Division. I learned that a lot of the software used by the Department of Defense is open source and basically wouldn't exist if we took away open source software. Dr. Maughan talked about the HOST program (Homeland Open Security Technology). HOST investigates open security methods, models, and technologies. He also announced a new portal coming out soon from DHS, opencybersecurity.org.
After the DHS session came lunch and a BOF session on PHP. I really wanted to go to this one because I would like to go into web development when I graduate and want to learn PHP, so I figured this would be a good way to learn a little bit about it. However, I was disappointed to learn that the session was a way to find locals interested in forming a PHP user group. I went to the session with one of my classmates, and since we can't travel to Columbia and back every month for the meetings (along with several other people who don't live in that area and came to the session), they decided to set up a Google group so we can stay in contact and learn some stuff that way. They wrote down several topics that people wanted to know more about, but never discussed them.
I perked right up after that by going to see the last person on my list, Chris Aniszczyk, give his presentation "Open Source and Twitter: The Technology that Powers a Tweet". I've been using Twitter since last summer and I had no idea that it was almost completely built on open source software. That blew my mind! They have a developer's website that uses Drupal where you can create your own Twitter app and they prefer to open source almost all of the stuff involved in Twitter.. There's also Blueprint which is Twitter's internal tools, and Finagle which is the network stack for Java Virtual Machine from Twitter.
I caught up with Aniszczyk after the session was over and asked him a couple of questions.
Q: How did you get started working at Twitter?
Aniszczyk: "I was working at Red Hat at the time, and a friend of mine recommended me during a meeting at Twitter. I got a phone call from the company and they asked me to come work there. I originally said no, but we worked things out with Twitter and I eventually left Red Hat and started working here."
Q: We see a lot of social media sites (like Facebook and Google+) adding features to their news feed that resemble or mimic the Twitter feed. How do you see Twitter impacting social media?
Aniszczyk: "By keeping it simple. Our goal is to keep it simple for users and to work with countries to make sending tweets like sending an SMS message."
Day 1
The day dawned with the promise of gaining insight into the open source world and tinged with excitement (although this might have been due to all the coffee consumed by the class on the way to Columbia). I had gone through the schedule online the day before and planned which presentations to go to, and what days the presenters I wanted to interview would be there. I made sure to note those sessions on my schedule because I felt that it would be a good idea to attend their sessions before speaking with them. Once we got to the convention center and checked in, we went around to the different companies who had booths set up to see what they were all about/network/apply for jobs. The conference started off with a welcome given by the organizers and mayor of Columbia, and a keynote presentation ("Open Source - Now and in the Future") given by Larry Agustin, CEO of SugarRCM In his presentation, Augustin listed three key trends that are driving technology investment today:- Mobile - This is enabled by open source software. Here we were shown a graph detailing the increase in various mobile operating systems platforms. The fastest growing OS? Android. Yes, you read that correctly. Android is increasing becoming the platform of choice in the smart phone world, mainly because app creation is a much easier process where you can create the app you want and put it in the Android app market.
- Social - Social media (Facebook, Twitter, Google+, etc) is increasing the demand for open source, especially Twitter. We'll come back to that later.
- Cloud - It's built on open source software (which drove licensing) and is running mostly on Linux, an open source operating system.
From there I was off to the first presentation given by one of the speakers I'd chosen, Mark Litz. Litz is Senior Manager of the Systems, Database & Computer Operations of the South Carolina Department of Corrections.
"Opening" Up the Prisons: How Open Source Solutions improve IT services and control costs at the SC Department of Corrections
Litz started by explaining his job, the number of "clients" (referring to the inmates) who access computers, and the budget. The budget for the DOC prisons is $400 million. How much does the IT department there get? $3.3 million, and of that amount about $1.5 million goes towards the upkeep of outdated technology. It's a sad thing to hear, but completely understandable when you have 22,500 inmates to look after. Litz went into a little overview of the software, and presented two open source budget solutions: cost averse and cost control. The first is not a plan that the government likes (mainly because there wouldn't be a vendor to blame), one which implements only FOSS with direct replacement of licensed software and support from an online community. The latter option would include the purchase of support contracts and licensed FOSS versions, implement support/license on production servers only, and would have development test and QA servers run pure FOSS solutions on the older Intel-based servers.
I was able to catch up with him later that day, and ask him a couple of questions.
Q: How did you get started with working for the Department of Corrections?
Litz: "I had just graduated from the University of South Carolina and started with DOC as a programmer. As I was working there the systems managers started giving me more tasks to work on, and I built trust with them as I completed more and more of them, and I worked my worked my way up."
Q: I know you do some travelling with your job to go to conferences like this one, but do you work here at the main office or go to one of the institutions in another part of the state to solve a problem with the system?
Litz: "I work here at the DOC headquarters here in Columbia and help solve problems remotely using the network we have set up."
Lunch came next, and for my "Birds of a Feather" session I chose to go to the one given by Jon "Maddog" Hall with Linux International. I think this was one of the best decisions I made the whole time I was at POSSCON. Maddog is an interesting fellow, and it was an entertaining lunch to say the least. He told a few anecdotes and basically let us take control of the session by asking whatever questions we wanted.
The next session I attended was given by the second speaker I'd chosen, Carol Smith, about Google Summer of Code. GSOC is a program designed to encourage college students to participate in open source software development ("flip bits, not burgers"). The students send in an application and project proposal, which Google passes on to the participating companies. These companies choose which students they want working for them over the summer. (For more information, go to their website here.)
I spoke to Carol Smith after the session was over and asked her a couple of questions....
Q: You have a degree in photo journalism. How did you get in involved with Google?
Smith: "A friend recommended that I apply for a job there. I started as an administrative assistant and got involved with some other programs there, and the woman who ran GSOC left so I took the position."
Q: What's your favorite thing about working for Google?
Smith: "That I feel appreciated and not like I'm replaceable. I'm not treated like I'm just another cog in the workings of the company."
I finished off my day by attending a demo for GitHub, where they showed how they use their own software to run the software. This session was given by Ben Bleikamp who is a designer at GitHub. Bleikamp went through the various features of the site and software tools.
Day 2
On the second day of POSSCON, POSSCON gave to me....a keynote given by Scott McNealy!! A man so well known for his contributions in computer science that even my parents - who know next to nothing computer science-y, by the way - know who he is. Wow. Needless to say I was very excited about this. So excited that unfortunately I forgot to take notes during his talk. Yes, I know. How very silly and forgetful of me.I didn't go to as many sessions on the second day as the first, mostly because I only had one interview left and his session was the only one I had definitely planned on attending at that point. I also had a pair programming assignment in another class and was trying to communicate with my partner for a good portion of the day.
I started the second day of sessions (after the keynote) by going to "Open Security: How DHS is deploying open source software to address national cyber security challenges", given by Douglas Maughan, Ph.D., Director of the Department of Homeland Security's Science & Technology Division, Cyber Security Division. I learned that a lot of the software used by the Department of Defense is open source and basically wouldn't exist if we took away open source software. Dr. Maughan talked about the HOST program (Homeland Open Security Technology). HOST investigates open security methods, models, and technologies. He also announced a new portal coming out soon from DHS, opencybersecurity.org.
After the DHS session came lunch and a BOF session on PHP. I really wanted to go to this one because I would like to go into web development when I graduate and want to learn PHP, so I figured this would be a good way to learn a little bit about it. However, I was disappointed to learn that the session was a way to find locals interested in forming a PHP user group. I went to the session with one of my classmates, and since we can't travel to Columbia and back every month for the meetings (along with several other people who don't live in that area and came to the session), they decided to set up a Google group so we can stay in contact and learn some stuff that way. They wrote down several topics that people wanted to know more about, but never discussed them.
I perked right up after that by going to see the last person on my list, Chris Aniszczyk, give his presentation "Open Source and Twitter: The Technology that Powers a Tweet". I've been using Twitter since last summer and I had no idea that it was almost completely built on open source software. That blew my mind! They have a developer's website that uses Drupal where you can create your own Twitter app and they prefer to open source almost all of the stuff involved in Twitter.. There's also Blueprint which is Twitter's internal tools, and Finagle which is the network stack for Java Virtual Machine from Twitter.
I caught up with Aniszczyk after the session was over and asked him a couple of questions.
Q: How did you get started working at Twitter?
Aniszczyk: "I was working at Red Hat at the time, and a friend of mine recommended me during a meeting at Twitter. I got a phone call from the company and they asked me to come work there. I originally said no, but we worked things out with Twitter and I eventually left Red Hat and started working here."
Q: We see a lot of social media sites (like Facebook and Google+) adding features to their news feed that resemble or mimic the Twitter feed. How do you see Twitter impacting social media?
Aniszczyk: "By keeping it simple. Our goal is to keep it simple for users and to work with countries to make sending tweets like sending an SMS message."
Tuesday, April 3, 2012
SD Chapter 7: Developing the Database Modules
The topic of this chapter is pretty self-explanatory (see this post's title), so let's just jump right in, shall we?
The term "database management system" is used throughout the chapter to describe the implementation of a database model, or DBMS as it is referred to in the book. The book introduces the DBMS MySQL, which I've heard of but never actually used before. For those of you that don't know what it is, MySQL is an open source database platform that's firmly base in math. It's pretty straightforward to get up and running (using a server such as LAMP, WAMP or MAMP) and maintaining it. The chapter goes through the process of creating a database and connecting a program to the database.
There are various database design principles discussed throughout this chapter along with explanations of the basic functions you need to know to use MySQL. It's definitely written as a way for the reader to get his or her feet wet with the platform. I like the code samples provided that show you how the different functions work. It talks about creating tables, searching through them, and working in general with the database.
There are other things, like backup and recovery, that are topics for different sections. That topic in particular is important for everyone to remember. This is mainly due to the fact that your database could contain A LOT of data that would be, let's be honest, a pain in the you-know-what to reenter that information one-by-one if something caused it to disappear and lost for all of time. If you prefer to handle things like that instead of backing them up properly, then it's possible you've lost your mind because you've got to be crazy to want to reenter tons of data one at a time by hand....ok, time to get back on track. Where was I? Oh yes. The book explains how the server you're running MySQL on (like LAMP) has direct backup and restore capabilities that it provides in its user interface. All in all, the chapter's very informative and useful.
The term "database management system" is used throughout the chapter to describe the implementation of a database model, or DBMS as it is referred to in the book. The book introduces the DBMS MySQL, which I've heard of but never actually used before. For those of you that don't know what it is, MySQL is an open source database platform that's firmly base in math. It's pretty straightforward to get up and running (using a server such as LAMP, WAMP or MAMP) and maintaining it. The chapter goes through the process of creating a database and connecting a program to the database.
There are various database design principles discussed throughout this chapter along with explanations of the basic functions you need to know to use MySQL. It's definitely written as a way for the reader to get his or her feet wet with the platform. I like the code samples provided that show you how the different functions work. It talks about creating tables, searching through them, and working in general with the database.
There are other things, like backup and recovery, that are topics for different sections. That topic in particular is important for everyone to remember. This is mainly due to the fact that your database could contain A LOT of data that would be, let's be honest, a pain in the you-know-what to reenter that information one-by-one if something caused it to disappear and lost for all of time. If you prefer to handle things like that instead of backing them up properly, then it's possible you've lost your mind because you've got to be crazy to want to reenter tons of data one at a time by hand....ok, time to get back on track. Where was I? Oh yes. The book explains how the server you're running MySQL on (like LAMP) has direct backup and restore capabilities that it provides in its user interface. All in all, the chapter's very informative and useful.
4/1/2012: Team Meeting
The guys and I (with the exception of Matt who wasn't feeling well, but still communicated via Google Chat) met up on Sunday afternoon to discuss our team progress and create a poster for the School of Science and Mathematics Research Poster Session. The deadline for entries is Friday the 13th (dun dun duuuuuuuun) so we were getting our poster's layout exactly like we wanted. Basically, it's just a PowerPoint slide blow up to a certain set of poster dimensions. Matt had already written the abstract and created the slide, so all that was left was to add content and screen shots. Jimmy and I looked at XBMC logos trying to figure out which one we wanted to add while David, Jason, and Matt added screen shots and bullet points with some information about what we've done with the project this semester.
Sunday, March 25, 2012
3/25/2012: Team Meeting and Getting Ready for POSSCON
We met at our usual time, but were down two team members due to illness and a prior engagement. So it was just Jason, Jimmy, and myself today. Our task is to complete the next milestone (Milestone 4 - Wiki/Documentation Edits). Unfortunately, we couldn't work on that while on campus because campus internet has slowed to a crawl since Friday and it refuses to load some of the pages on the wiki thanks to time-outs. So we're each working on wiki pages from home and looking for specific changes to make. Mine are spelling and grammar, along with correcting function names if necessary.
So...POSSCON...I started out with a list of 5 potential speakers who I really want to see give their presentations. After giving it a great deal of thought, I've narrowed it down to 3.
So...POSSCON...I started out with a list of 5 potential speakers who I really want to see give their presentations. After giving it a great deal of thought, I've narrowed it down to 3.
- Mark Litz - Senior Manager of Systems, Database and Computer Operations for the South Carolina Department of Corrections.
- Chris Aniszczyk - Open Source Manager for Twitter.
- Carol Smith - Program Manager at Google.
Thursday, March 22, 2012
SD Chapter 6: Exercises 6.1 and 6.4
These are the two exercises that are to be done for this blog post....
Exercise 6.1--"For the Person class, define a new pair of functions to set and retrieve the value of the variables $employer, $contact_person, and $contact_phone in preparation for implementing new features 1 and 9d in RMH Homebase."
Exercise 6.4--"Refactor the existing Person class by removing all the mutators that are not called from anywhere in the code base. Be sure to test your changes by rerunning the test suite."
I've got RMH Homebase on Windows and not Linux because I had issues getting it on my Virtual Machine. I've got a Wamp server up and running and everything. I opened Eclipse to work on the code and do these exercises, but Eclipse crashed on me while I was trying to figure out how to build a PHP project in it. THREE TIMES. I really don't understand this. It's like my computer's on strike tonight when it comes to my 462 homework. This makes me want to hit my head against the wall, but since I don't want to hurt the wall I'll just try to figure out what the problem is. Maybe. Hopefully.
Exercise 6.1--"For the Person class, define a new pair of functions to set and retrieve the value of the variables $employer, $contact_person, and $contact_phone in preparation for implementing new features 1 and 9d in RMH Homebase."
Exercise 6.4--"Refactor the existing Person class by removing all the mutators that are not called from anywhere in the code base. Be sure to test your changes by rerunning the test suite."
I've got RMH Homebase on Windows and not Linux because I had issues getting it on my Virtual Machine. I've got a Wamp server up and running and everything. I opened Eclipse to work on the code and do these exercises, but Eclipse crashed on me while I was trying to figure out how to build a PHP project in it. THREE TIMES. I really don't understand this. It's like my computer's on strike tonight when it comes to my 462 homework. This makes me want to hit my head against the wall, but since I don't want to hurt the wall I'll just try to figure out what the problem is. Maybe. Hopefully.
Learning to Play Nicely With Others: TOS Chapter 3 and SD Chapter 2
The readings for this post are from the two texts we're using, and deal with working in a global community and working with a a project team, respectively.
TOS Chapter 3
This chapter is about learning how to interact with the open source global community. No matter how big or small the project may be that you pick, you have to first and foremost understand that working on open source projects means working out in the open, and communication with everyone involved is the key element to doing so. You have to remember that every FOSS community has their own way of doing things, their own culture. This isn't influenced by the culture of the countries of those involved, but by the "shared experiences, humor, social norms, and conventions that define that community, building up a synthetic third culture". The qualities of the community are listed as follows:
1. Language barrier--this one is obvious. I mean, sometimes understanding what another person is saying can be difficult from region to region in the same country, not just from country to country. Establishing a common language (or, depending on the project, a common measuring system) is essential to breaking down the communication barrier. Coding comes easily. Talking is hard.
2. Time and distance--also obvious. Not everyone operates on the same schedule; some prefer coding at night and others during the day. Meeting face to face can be difficult because the other person could be halfway around the world. Communicating through other methods, like via email and IRC channels, is a good way to overcome that. Wikis and blogs are also a good way of communicating with others about your project.
3. Ego--while there's not a lot of money (or none at all) involved when taking part in a FOSS project, wanting individual recognition can really hurt a community like this. Acting like this will make others not want to work with you. It's the same reason no one wants to pick you for their team in kickball--no one likes an egotistical jerk.
Exercise 3.5: Project Wikis
1. Our project, XBMC, uses the MediaWiki software package for its wiki page.
2. The project's history is in the wiki under Team XBMC-->XBMC.
3. The last revision of the wiki was made on March 10th by Ned Scott. I would consider this to be thriving since it's a very active project.
Exercise 3.7: Linking Your Blog to Planets
For this exercise we are to link our blog to our class planet (the class wiki). We did this at the very beginning of the semester.
Exercise 3.9: Learning IRC
Already did this one at the beginning of the semester, too. Hooray!!
Exercise 3.11: Joining the Mailing List
XBMC doesn't have a mailing list, only a forum and bug tracker which I have joined.
That's it for TOS Chapter 3. On to the next part of this post!!
SD Chapter 2
This chapter talks about interacting with a team and how to choose a good FOSS/HFOSS project. Working in a team setting is like a development community, only it's on a much smaller scale and more structure. Each team member has a key role, however, the same person may have two or more roles simultaneously. They are:
When it comes to choosing your team project, you're looking for a project that (hopefully) has these qualities:
TOS Chapter 3
This chapter is about learning how to interact with the open source global community. No matter how big or small the project may be that you pick, you have to first and foremost understand that working on open source projects means working out in the open, and communication with everyone involved is the key element to doing so. You have to remember that every FOSS community has their own way of doing things, their own culture. This isn't influenced by the culture of the countries of those involved, but by the "shared experiences, humor, social norms, and conventions that define that community, building up a synthetic third culture". The qualities of the community are listed as follows:
- Focus: What the community wants to achieve.
- Maturity and History: The age of the project.
- Type of Openness: This can vary from active communities with strict management hierarchy headed up by a development leader (read: dictator) to communities that are completely open to any and all.
- Commercial Ties: Whether or not the project is being sponsored by a company or companies.
- Subgroups: Whether or not the community operates as a whole or is divided into subgroups.
- Skills: Each community focuses on and requires a certain skill set for contributors, so having new contributors come it with skill sets not already a part of the project can be beneficial.
- Mentoring and Training: There's no Mr. Miyagi here, but some communities do have some simple training or mentoring programs to help the community grow and learn. Wax on, wax off...
1. Language barrier--this one is obvious. I mean, sometimes understanding what another person is saying can be difficult from region to region in the same country, not just from country to country. Establishing a common language (or, depending on the project, a common measuring system) is essential to breaking down the communication barrier. Coding comes easily. Talking is hard.
2. Time and distance--also obvious. Not everyone operates on the same schedule; some prefer coding at night and others during the day. Meeting face to face can be difficult because the other person could be halfway around the world. Communicating through other methods, like via email and IRC channels, is a good way to overcome that. Wikis and blogs are also a good way of communicating with others about your project.
3. Ego--while there's not a lot of money (or none at all) involved when taking part in a FOSS project, wanting individual recognition can really hurt a community like this. Acting like this will make others not want to work with you. It's the same reason no one wants to pick you for their team in kickball--no one likes an egotistical jerk.
Exercise 3.5: Project Wikis
1. Our project, XBMC, uses the MediaWiki software package for its wiki page.
2. The project's history is in the wiki under Team XBMC-->XBMC.
3. The last revision of the wiki was made on March 10th by Ned Scott. I would consider this to be thriving since it's a very active project.
Exercise 3.7: Linking Your Blog to Planets
For this exercise we are to link our blog to our class planet (the class wiki). We did this at the very beginning of the semester.
Exercise 3.9: Learning IRC
Already did this one at the beginning of the semester, too. Hooray!!
Exercise 3.11: Joining the Mailing List
XBMC doesn't have a mailing list, only a forum and bug tracker which I have joined.
That's it for TOS Chapter 3. On to the next part of this post!!
SD Chapter 2
This chapter talks about interacting with a team and how to choose a good FOSS/HFOSS project. Working in a team setting is like a development community, only it's on a much smaller scale and more structure. Each team member has a key role, however, the same person may have two or more roles simultaneously. They are:
- Team Leader: the person who oversees the development process. Tasks include setting weekly agendas and milestones, assigning tasks to team members, coordinating overall system architecture, teaching other team members about new techniques, leading regular team discussions, and helping resolve design issues.
- Analyst: someone who understands the user's domain, elicits requirements, defines use cases, evaluates risks and alternatives, and sketches the initial design of the software to be developed. Tasks may also include cost estimation and project scheduling.
- Developer: the person who writes test cases from requirements, and reads, writes, tests, debugs, and refactors program code. Also refine requirements and use cases, write documentation and online help pages, and solicit feedback from users at each stage in the project. Basically a programmer who can also read, write, and communicate effectively with users.
- User: the person who is knowledgeable about the application's domain. Tasks are to review use cases, provide data for test cases, review the output of code written by developers, provide feedback on the quality of that output, and find bugs in the software after each iteration has been deployed.
- IT Technician: filled by persons who configure and maintain the technical environment used by the team. Tasks are to set up and maintain the code repository, the staging server, the videoconferencing system, the team discussion site, and other software tools needed by the team to develop the software effectively.
- Observer: someone who is interested in watching the project develop and/or whose project management expertise may provide occasional high-level advice on particular design decisions. This is a fairly passive role.
When it comes to choosing your team project, you're looking for a project that (hopefully) has these qualities:
- Popular: look at how many downloads its software has each month and how active its user and developer forums are. If it's barely surviving or flat-lining, you don't want it.
- Vitality: check out the project's statistics. The often include the number of new code contributions that have been made, and the number of new releases that are created each year. All these are measures of a project's vitality and therefore show its receptiveness to the addition of newcomers.
- Growth Potential: don't go with projects that have matured and plateaued. They may have a large user base and deliver a lot of value, but they don't provide newcomers with an opportunity to make an impact.
- Welcomes Diversity and Promotes Contributions: go for projects that are open communities with lots of opportunities for newcomers, not the close-knit group of buddies with a lot in common.
- Enjoyable: the project, not your class grade, should be the motivating factor for choose a project. Chances are that choosing it because it's what your instructor would find fascinating isn't a good enough reason to work on a particular project. Pick something that you're interested in and will be excited about working on it every chance you get.
Wednesday, March 21, 2012
SD Chapter 6: Developing Domain Classes
As the book says, "domain classes are at the heart of the software architecture". They are the key element in understanding any system. The book lists the main steps of developing domain classes as different sections of the chapter. Here they are in the highlights version (or Reader's Digest version, however you want to describe it):
1. Reading a Design Document--A design document is described as a document that contains a domain analysis, a requirements analysis, and a set of use cases. These are used in the following ways:
- domain analysis: describes how the current application works including any existing software that may be used to support that application
- requirements analysis: identifies the activities that the new software must support
- use case: provides a transformative view, showing how the system should support specific kinds of interactions between types of users (called user roles)
3. Identify Instance Variables--Here, we look for detailed entities in the use case that characterize the state of an object in a class
4. Identify Methods and Functions--You want to look for information that helps designers specify actions that need to be implemented for each class. In a nut shell, you're looking for methods or functions.
5. Reading Code--This one is pretty much a no-brainer. I mean, how can you work on developing a system or work on a current system without reading the code? Developers will get the code base and read to find the information they need. There are 3 main goals here:
- To understand the overall architecture and functionality of the existing software
- To learn the vocabulary established by the domain classes
- To identify the extent to which the code must be referenced before it can be modified to support the functions of the new system
6. Examining the Domain Classes--The domain classes characterize the central concepts in a software system. Basically, the define a name space that permeates the entire application and its documentation. The names themselves originate from the user's domain, so that they characterize objects and actions with which the users are already familiar.
7. Adding New Features--The client or group of end users of a software system usually provides the catalyst for adding new features to an existing software system. As the developer, it's your job to make the necessary changes to the current system to add the features. The system developers should have good communication channels with users, that way if there is a problem or new needs they can be quickly transmitted and resolved.
8. Top-Down Analysis/Bottom-Up Development--Going along with "Reading a Design Document", after the key elements are identified (top-down analysis), their implementation evolves through the code base (bottom-up development). This is done by first revising the domain classes, then the database modules, and finally the user interface modules.
9. Documentation and Bulletproofing--Whenever a new function is designed, it should be documented using standard practices and appropriate preconditions and postconditions. This is particularly important for non-trivial (non-getter and non-setter) functions.
Sunday, March 18, 2012
3/18/2012: Team Meeting
It's crazy how fast this semester has gone by. Spring Break has (unfortunately) come and gone, and in a little over a month the dreaded exam week will begin. It's definitely NOT my favorite time of year. Exams and group presentations and papers....oh, my!
The focus of today's team meeting was once again the bug fixes we are working on. The School of Science and Mathematics Research Poster Session is coming up in a few weeks, and we will have to make a poster to display there, so we're going to begin getting ready for this.
POSSCON is next week, and I'm preparing for that. We have to find speakers we wish to interview for our blog, so I'm looking at the list and trying to figure out questions I might want to ask.
The focus of today's team meeting was once again the bug fixes we are working on. The School of Science and Mathematics Research Poster Session is coming up in a few weeks, and we will have to make a poster to display there, so we're going to begin getting ready for this.
POSSCON is next week, and I'm preparing for that. We have to find speakers we wish to interview for our blog, so I'm looking at the list and trying to figure out questions I might want to ask.
Thursday, March 15, 2012
3/15/2012: Team Meeting
We decided to meet up today to get some more work done on our project before Monday. I brought in a Blu-ray disc with me so I could take another look at the bug that I was assigned to tackle (Bug #12594). I found that it takes XBMC 46 seconds to fully boot up when I start it immediately after inserting the disc, but when I wait for the drive to read it or have no disc in the drive, it takes XBMC only 5 seconds to fully boot up. This leads me to believe that there is no problem with XBMC. I think the problem was with that guy's disc drive. So even though the bug couldn't be replicated, it's great that we were able to rule out any sort of issue with XBMC in that particular case.
Tuesday, March 13, 2012
3/13/2012
Just thought I'd place a quick update here for y'all....
All of the groups presented yesterday to let everyone in the class know where they stand in their projects. Our group is going to meet again tomorrow afternoon so that we can continue to work on our project.
Campus Internet died today around noon for some reason, and was pretty weak for the rest of the day. I was going to take the opportunity to catch up on some blog posts, but I'm currently unable to access Dr. Bowring's website in order to look at the syllabus. I can't even access the department's website for that matter. Hmm...well, that's not good. I hope it's not related to what happened to the Internet today. The class wiki is still accessible because it isn't a site through The College. However, it's link to the syllabus doesn't work. Hopefully tomorrow it will be better.
All of the groups presented yesterday to let everyone in the class know where they stand in their projects. Our group is going to meet again tomorrow afternoon so that we can continue to work on our project.
Campus Internet died today around noon for some reason, and was pretty weak for the rest of the day. I was going to take the opportunity to catch up on some blog posts, but I'm currently unable to access Dr. Bowring's website in order to look at the syllabus. I can't even access the department's website for that matter. Hmm...well, that's not good. I hope it's not related to what happened to the Internet today. The class wiki is still accessible because it isn't a site through The College. However, it's link to the syllabus doesn't work. Hopefully tomorrow it will be better.
Sunday, March 11, 2012
3/11/2012: Weekly Group meeting
Today after a lovely Spring Break, Team Triple J met up to discuss our group's progress during the break. There was good news and bad news. The good news is that we were able to replicate a couple of the bugs from our list. The bad news is some others were fixed by other developers and a few of the bugs couldn't be replicated, including the one that I was working on (I'm still trying though). Because of this, we've had to start looking at the bug tracker and pick out a few ore bugs to look at in place of the ones that have been fixed. We updated our project timeline to reflect these changes. Oh, and over the break the developers released a new release of XBMC: "Eden" Candidate 2 so we spent time today downloading this version on Ubuntu.
Wednesday, February 29, 2012
2/26/2012: Weekly Group Meeting
We were short one team member today as Jason was out of town and unable to get back in time. We each looked for a few more bugs, just in case we couldn't replicate or figure out the bugs we picked last week.
Our team has managed to replicate a bug today (Bug #12653). We found a bug that deals with Blu-Ray issues (Bug #12594), and since I have Blu-Ray built into my laptop we will be able to look at this one as well.
Our team has managed to replicate a bug today (Bug #12653). We found a bug that deals with Blu-Ray issues (Bug #12594), and since I have Blu-Ray built into my laptop we will be able to look at this one as well.
Exploring opensource.com
Today's assignment was to go read and discuss two articles from opensource.com. I chose "How to teach undergrads how to become open source contributors without writing any code" which is about a class full of college students learning to become functional open source contributors without having to write code (redundancy here due to the title I know. Sorry about that), and "Culture eats strategy" which is about why understanding a company's culture is so important. Let's get to it, shall we?
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
"How to teach undergrads how to become functional open source contributors without writing any code" by Sebastian Dziallas
I chose this article mainly because of the course I'm currently in, which is why I created this blog. I felt that what was done in the class taught by Dziallas is almost exactly the same as what we're doing in this class with Dr. Bowring--learning how to become functional contributors to open source projects without writing code. The author lists three main elements to the class: the cultural, the technical, and real projects and interactions. This is Dr. Bowring's approach as well. We are assigned articles to read about working in open source development and case studies (the cultural); we learn about packaging (the technical); and finally, we learn about and interact with real projects (real projects and interactions). Now, here's where the difference in the two classes comes into play. Unlike Dziallas's class, we don't work as a collective whole to make contributions to a project. Dr. Bowring divides the class into groups (teams) who each get a project to work on, and no two teams are allowed to have the same project. Reading it, I enjoyed seeing a slightly different take on this approach to this type of class.
"Culture eats strategy" by Jonathan Becher
I chose this article based on the title. It just really caught my eye and looked interesting. In the article, Becher discusses his experiences at a company called SAP. While his experiences are in the marketing department of the company, I found the lessons he learned from them relevant to software engineering. His main point is that without an understanding of the culture in your work environment your strategy won't work, regardless of how good it is. Becher basically says that thinking "all successful change management projects require executive support", or "if you aren't the lead dog in the sled, the view always looks the same" is a load of crap. I completely agree. Managing projects is a team effort, not something that is done by only one person. If one person makes the decisions, then they're not going to be as open to suggestions and will do whatever they decide to do. Team decisions promote communication between team members, which in turn leads to better decisions about a project and better performance overall in the team.
Sunday, February 19, 2012
2/19/2012
We had our weekly group meeting today at 2 (our group decided to make them a weekly thing today). We have been working on a timeline for the class project and creating milestones. We've decided to work on at least three bugs, one every two weeks, instead of working on one major bug for the rest of the semester. The interval was chosen so we would be able to fix our first bug before spring break. We discussed various bugs that we found on the bug tracker, and selected five bugs to try and fix this semester.
Tuesday, February 14, 2012
2/15/2012
The assignment for this post was to read chapter 4 in Software Development: An Open Source Approach. This chapter covers Software Architecture. The book describes software architecture as being "an organizational model for a moderate or large software system...provides strong guidance on how modules interact with each other, how a test suite can be designed, how refactoring strategies can be exercised, and how program bugs can be detected and removed."
It lists 4 architecture patterns:
It also lists the 3 important software architecture development principles:
It lists 4 architecture patterns:
- Mutlti-Tier: distiguishes the user interface layer from the core class layer from the database later. GUI components are isolated within the user interface layer and database interactions are isloated within the database layer.
- Client-Server: separates the functionality of a typical user of the system from that of the server that hosts the database that all users access. The "client-side" code is that which resides on the user's computer, including GUI components. "Server-side" code resides on the server's computer, including the database components.
- Transaction Processing: useful for systems that accept a stream of transactions and process each transaction fully before moving on to the next.
- Model-View Controller (MVC): useful for systems that have substantially complex user interfaces. The idea here is to separate the functionality that underlies the user interface from the code that controls how the user sees and interacts with the system.
It also lists the 3 important software architecture development principles:
- Layering Principle: Every module belongs in a single layer. No module should skip over its neighbors in the layer immediately above or below it, in order to provide or obtain services from another layer.
- Maximum Cohesion Principle: All the functions that relate to a single concept are gathered into a single module or class. A software architecture is maximally cohesive if all its modules and classes are cohesive in this way.
- Minimum Coupling Principle: Two modules are coupled if either one shares information or receives services directly from the other. A software system is minimally coupled when the number of interactions between all pairs of modules is kept to a minimum.
Sunday, February 12, 2012
Group Meeting--Fixing a Bug
Our group met today at 2 to work on the group assignment due this week--fixing a bug in the project. We had already established what we wanted to work on. David found a bug a couple of weeks ago (bug #12565) that dealt with the incorrect display of images in slideshow mode. He created a test image for the developers, but no one was able to replicate the bug. We decided to fix the README.ubuntu file, which has some incorrect links and is missing some of the dependencies needed to get the source code for XBMC.
Friday, February 10, 2012
2/10/2012 (TOS Chapter 7)
This chapter covers patches, and how to create and submit them. We were asked to do exercises 7.2.2, 7.8, and 7.9.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
To do exercise 7.2.2, the authors want you to create the file used in the example to compare the outputs of a diff command using the -u flag and without it. The file is a simple "Hello, World" program, very simple to write (just copy and paste into the text editor). I booted up Ubuntu--I prefer it for my homework in this class because that's the OS we have to use for our projects--and opened up my text editor (gedit) so I could get the program pasted in and saved the file. I then opened up the terminal window and followed the instructions in the example, which I needed to do before completing the actual exercise. With that taken care of, I started playing with the diff command as stated in the exercise. I noticed that without the -u flag, the only output to my terminal window is the original line of the program and the new one that contains the change. When the command has the -u flag, the output shows where AND when the change was made. It even prints out the program text with the original and new lines of code--a "-" for the line that will be replaced and a "+" for the new line of text that will be going into the program. After seeing the outputs for both versions of the diff command, I prefer the one with the -u flag because it contains more information, but I suppose that doing the command without the flag would be more efficient if you have a lot more going on in your terminal window. I prefer it because I like to know exactly where it is being changed. On to the next!
7.8:
This exercise says to create a patch file that represents a new file, foo being with the contents bar. I'm little confused by this one actually. I wasn't sure if we were supposed to create a patch for the hello.c files or if it was for a different program. Maybe I'm just being an idiot, I don't know. Let's hope the last one goes better...
7.9:
This is a step-by-step exercise that wants you to create a patch echo for a project. I actually really like this one because I'm a Windows user, so I don't know a whole lot about the bash commands except for what I used last semester in CSCI 362. Unfortunately, my terminal keeps telling me that the commands I'm trying to use aren't correct, and typing exactly what TOS is telling me to type in the exercise. I don't understand why this is happening. I did read through the exercise and I'm pretty confident that I understand what's going on. It's basically a reinforcement of the two previous exercises along with teaching the new concept of creating a working echo binary.
Tuesday, February 7, 2012
2/8/2012 (TOS Chapter 6)
For this post we are to do exercises 6.4, 6.5, 6.6, and 6.7 from chapter 6 of "Teaching Open Source".
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
6.4:
The oldest bug I could find was #5231 (DVD Player: Certain AVI-files play too slow/fast after seeking forward/backward). This ticket was first created 3 years ago and is still an unresolved problem (it was last modified 3 weeks ago). The bug here doesn't seem to be occurring on a consistent basis, which is a problem when debugging software and is probably the reason why this one hasn't been fixed yet. I can't think of a solution to this bug. No bonus points for this chica. (Insert Debbie Downer sound clip here).
6.5:
This is something that I had already done before the assignment because you have to have an account to get into the forums. Can I get bonus points for that one? (Don't look at me like that. A girl can dream, you know.)
All kidding aside, you have to have an account to contribute in any way to the XBMC project, and each member of our group registered in the forum community before we began looking at the bug tracker.
6.6 and 6.7:
I could not do these two exercises because my VirtualBox screwed up somehow. Lovely. Just lovely. Thank the Lord I remember how to install it.
**NOTE: Something's wrong with the Blogger tonight, so I had to highlight the bulk of this post in black so I could read it. If it changes back to normal later, I will fix this post.
Sunday, February 5, 2012
2/6/2012
Our group met today at 2 to discuss where we were individually and fix a bug. At this point, everyone has the XBMC source code compiled and working, and almost all of us are in members in the forums (I just got in today) on the XBMC website. I had to create a new Ubuntu OS in my VirtualBox before I could get mine, which takes a while because of all the updates and length of the installation process when run through VirtualBox. Many, many thanks to Jimmy and Matthew for all of your help with my getting the source code downloaded and compiled. :)
The original plan was to fix a bug in the README file of the code as the bug to fix and submit for the class. This plan fell through when we discovered that someone else had already fixed it. (Insert disappointed sigh here). The team split up, with some of us looking at long-term fixes and the others looking for short-term for next week.
Our group is getting along well thus far. There's definitely a relaxed vibe among the members, and we don't have any personality clashes. This great group dynamic is making this a fun project for me, and hopefully for the others as well.
Friday, February 3, 2012
Reflection: Magazine Article
My previous post was a reflection on an essay chosen by Dr. Bowring for us to read and discuss. This time he let us choose what we wanted to read and review. He passed out some magazines and asked us to find an article that interested us for this assignment. I picked up a copy of IEEE Software and found an interesting article right off the bat about software components in cars. I read it, and then I saw the title of the article right after it and I knew I was not going to be writing this post about cars. Instead, I chose an article about mobile applications. Let me explain why. I'm also taking CSCI 360: Software Architecture and Design where, like this class, we have to do a group project. The group that I'm in has decided to make a mobile app, and when I saw that article I just had to read it.
The article is "Development Platforms for Mobile Applications: Status and Trends" by Damianos Gavalas and Daphne Economou from the University of the Aegean. In it, the authors break down and compare the four most popular runtime environments used for "resource-constrained mobile devices"--Java Mobile Edition, .NET Compact Framework, Flash Lite, and Android--by looking at earlier research, technical specifications, white papers, an informal survey of 32 mobile-application developers with hands-on experience using the four platforms reviewed, and even creating their own app to run implementing each runtime environment to showcase the advantages and disadvantages of each one. I really like that they created an mobile app to test each one. It shows that they wanted to be able to contribute their own opinions to the article, not just what the other developers had to say. So let's take a look at each one as they broke it down....
Java Mobile Edition (ME)
Java ME is a subset of the Java platform that contains a certified collection of Java APIs for developing software for resource-constrained devices like cell phones, PDAs, and set-top boxes. Its features are:
- It runs on top of the kernel-based virtual machine (KVM), which allows for reasonable, but not complete, access to underlying device's functionality
- Supports cross-platforms through configurations and profiles, and was designed to be cross-platform. This is done by having specification and implementation as two separate processes
- By targeting individual operating systems, developers using Java ME have access to a large set of well-defined and mature Java Specification Requests (JSRs)
- The Java Language motto "write once, run anywhere" doesn't apply here. Developers must provide slightly different application versions to address variations in JSR sets and implementations across a wide range of device capabilities and choice of profiles, configurations, and APIs. This often results in something called device fragmentation, where dozens of executables for a given title have to be written. This increases the operational costs over the product's life cycle, restricts the devices that Java ME apps can reach, and is overall more suitable in apps that target devices with similar capabilities and Java API support
.NET Compact Framework (CF)
This runtime environment was designed for applications on Windows Mobile. It is a subset of Microsoft's full .NET platform that preloads the Common Language Runtime (CLR) engine in the device's memory to facilitate mobile-application development. Its features are:
- .NET CF runtime is analogous to the Java Virtual Machine (JVM). Instead of writing native code for the underlying device's operating system, .NET developers write managed code, which targets a managed execution environment
- .NET CF user interface design is based on a rich subset of .NET Windows Forms
- Comparable to Java ME with respect to providing a managed runtime environment, rich libraries and components for reuse. It has advanced user interface components, network connectivity, data management, XML Web services, in addition to familiar APIs from the full .NET framework, such as Windows Forms control. These features ease the transition for desktop developers to mobile apps.
- It is "language-agnostic" and simplifies the Common Intermediate Language (CIL) instructions.
- Demonstrates API-level consistency and compatibility with the full .NET platform. This has had unforeseen memory footprint costs, but the .NET CF nevertheless represents a fast-paced implementation driven by a powerful vendor
- Offers satisfactory integration with device-specific functionality. It doesn't exhibit Java ME's fragmentation problem. .NET CF targets a limited set of Windows end devices, and the VS.NET development tools include license costs
- It restricts the operating system support to Windows platforms, which represent only a small part of today's mobile device products
- Core components are a subset of the full .NET framework, and it only has about 30% of .NET's classes and functionality. Some of the classes exist in both .NET and .NET CF, but the .NET CF version doesn't necessarily support all the full version's class members (like properties, methods or events). Many classes aren't implemented at all, and others are only partially implemented. Unique .NET CF classes address device-specific and third-party extensions
Adobe Flash Lite
Flash Lite is a "propriety technology" that is popular as a multimedia and game programming platform. It was created specifically to help vendors to rapidly deploy rich content and interactive interfaces to mobile devices. Its features are:
- Stores its contents and GUI description in the vector-based SWF graphics and animation format
- Implements its application and presentation logic in ActionScript
- A Number of original equipment manufacturer (OEM) operator and developer adapters, which is increasing rapidly worldwide
- Flash Lite 1.1 supports Flash 4 and ActionScript 1.0, Flash Lite 2.0 and 3.1 support ActionScript 2.0. Both Flash Lite 2.0 and 3.1 are based on Flash Player 7 and 9, respectively.
- All versions support the World Wide Web Consortium (W3C) Tiny standard
- Is a reasonable choice for graphics-intensive phone and PDA applications
- Rapid development is a primary benefit. Developers skilled in Flash for desktop applications can easily switch to Flash Lite for mobile applications. Its easy to learn and easy to migrate Flash applications, and it includes a rich set of designer/developer tools. It offers rich media support (images, sound, video, animation), a relatively broad runtime installation base, and small deployment files based on vector graphics
- Isn't suitable for developing full-fledged stand-alone applications, mainly because it lacks the powerful mobile-oriented APIs of Java ME
- Exhibits poor graphics performance, partly because of the complex processing required for vector graphics
- Ships with an extensive toolset, but the toolset requires a license fee
Android
Android, which currently has the largest developer and deployment bases, was launched in 2007 by Google to advance open standards for mobile devices. It is an Apache free-software platform with an open source license for mobile devices based on Linux. It features:
- Written in Java and compiled in Dalvik executable (DEX) format. Each application executes its own process, with its own instance of the Dalvik virtual machine (DEX files are more compact and efficient than class files)
- Full access for developers to all the frameworks and APIs that the core applications use and to Google-developed software libraries
- Android software development kit (SDK) supports authoring applications with rich functionality
- Supports a relatively large subset of the Java Standard Edition (SE) 5.0 library. This implies reduced migration cost from Java desktop applications
- Supports several third-party libraries
- Similarly to Java ME, application development is powered by popular Java integrated development environments (IDEs)
- Provides inherent support for modular service-oriented applications and interapplication communication
- New platform releases, while great for introducing new user and developer features, raise fragmentation concerns. The platform's openness in the targeted device stacks aggravates the fragmentation problem
So after implementing the app on each platform, the authors found that the .NET CF and Android applications were easier to develop because of their improved compatibility with the full .NET and Java SE frameworks.
Subscribe to:
Posts (Atom)