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."
Subscribe to:
Posts (Atom)