What if money was no object?

Currently Listening to:
Noisestorm - Solar
Love Automatic - Save My Soul 

One of my favorite things to do in this world is problem solve. Other things that I love to do include teaching peers. These two passions of mine come together quite often, helping fellow students learn new technologies, or helping them understand something they didn't quite understand in class. I've quoted some of my favorite people in the past like Daniel Pink and Sir Ken Robinson, but today I'm going to talk about Alan Watts. One of my favorite lectures included the "What if money was no object" talk.

How many of you reading this actually like what you do at work? Maybe the environment is bad, maybe the people are annoying, but do you actually like what you do? Most people that I've talked to seem to not enjoy their job. This baffles me. They go to work day in and day out trying to make money but they don't like their job. They have the "fun" on the weekend. "All rech and no vomit" is the phrase Watts used to describe this mentality of forcing yourself to do this, "... you will spend your life completely wasting your time. You will be doing things you don't like doing in order to go on living. That is, to go on doing things you don't like doing... Which is stupid!"

Personally I love what I do. If I lived in a post-scarcity utopian society, I would still do what I do now. I may not be the best person to come up with an algorithm, I may not be the best coder, but at least I can say I love what I do. Asking students in the computer lab about what they want to do, I get plenty of answers that have nothing to do with coding, and to those students I've started asking why they went into computer science. "For the money" is a typical response I get. These students are about to graduate and they either don't know what they want to do for a living, or actively don't want to go into software development. I understand that knowing how to code can improve almost everyones problem solving techniques as well as help them with the day to day for their job (knowing how to script a mundane task saves you in the long run), but I have problems when the students seem to despise what they do.

Another issue that I've seen recently is the lack of effort on the part of the individual to better themselves. Ignoring the population that does not like what we do, we are left with those who I would assume are like me, motivated to better themselves over the weekend by working on a project, reading a book on the subject, contributing to a big open source project, or attending a conference/seminar. I've tried to put on events for my fellow students and peers in the area, including BarCampCHS, local programming competitions, helping with the Hack-a-thon, teaching teachers how to teach, and so on. However, when I start telling everyone to attend these events for the learning experience, or the meet and greet that they would have with local gurus in the community as well as people in a position to hire you, I get the same students every time. I've started referring to these students as "my go getters". They are the ones that attend/plan/promote all the events. All in all that is about 30 students that seem to enjoy what they do enough to want to better themselves. I can't say that the other students are bad, because honestly I haven't met them. They don't want to hang out in the lab (understandable, I know that I'm a very extroverted person and most of my peers would define themselves as introverted), or they don't think that going to these things are very important.

When I'm talking to some of my friends who do things in the local community I'm normally asked to give recommendations to them about who I would hire, and to pass on the message that someone is hiring to them (remember it is who you know, not what you know). Why would I recommend someone who I've only met once in the classroom who never speaks out. I would rather recommend someone who I've dealt with outside the classroom in a professional manner. The planning team of BarCampCHS sits pretty high on that list seeing as how I saw on a weekly basis their problem solving techniques as well as planning and execution of running a big event. Students who talk to me on a regular basis about interesting problems or new technologies are right behind them. The conversations I've had range from talking about ICPC problems, new technology stacks, hosting of web apps, design issues, high performance computing, low level hardware coding, open source licensing,  and many other topics that range from an individual problem to problems spanning the entire field of software development.

I've had conversations about why students don't want to do these things, and the mutual agreement is to just not even care about them, so consider this my last plea to those who don't seem to care (and honestly, if you are reading this either you do care, or you just like me): Instead of that one game of league maybe you could solve a problem on UVa, instead of going to r/funny you can instead read an article from r/learnprogramming or r/programming, instead of complaining about your grade in advance algorithms maybe you can implement your own library containing sorting algorithms and different data structures. I promise you, if you do these things you will feel better about your choice in degree/job. You will start to hone in on the part of programming/computer science that you enjoy most, because as Alan Watts said, "Better to have a short life that is full of what you like doing than a long life spent in a miserable way. And after all, if you do really like what you're doing, it doesn't matter what it is, you can eventually become a master of it. The only way to become a master of something is to be really 'with it' and then you'll be able to get a good fee for whatever it is. Therefore it's so important to consider this question. What do I desire?"

Contributing to Open Source, Mentoring Improves Knowledge

Currently Listening to:
GoldFish - One Million Views
Approaching Nirvana - 305 

I've been working at Sparc for almost eight months now, and I can honestly say that having responsibilities outside of class related to your major will increase your skill level exponentially. I'm not talking about an internship where you are just fetching coffee for the people, but actually contributing to the workload in a meaningful way. This is what should be encouraged by academia, jobs that actually push you to try to maintain a work/life balance where work is split off into academia and a career.

My parents have always told me that I needed to take a job during the school year. I've done the jobs that were not related to what I wanted to do during high school (bouncy castle birthday party place), but during my senior year of high school I realized that I could get a job for what I wanted to do for a career (at the time), computer repair. During my senior year in high school, as well as the next 5 years of college (2 at Trident Tech for an Information Systems degree, and 3 years at College of Charleston working to a Computer Science degree) I did everything from go to peoples houses repairing computers, working at a chain store repairing computers, and being a systems administrator for almost three years. But I knew that after those 6 years of doing I.T. work, I wanted out. The grind of doing the same thing ("turn it off and on again") was becoming old hat. Sure I was good at what I did, and could make a nice living off it, but it wasn't what I wanted to do.

That is where software development comes in. During my time working on small projects (and some not so small projects) at school I realized that I enjoyed the problem solving that coding brings. Working on open source projects (the class that made me keep this blog/work on open source) showed me that I could make money solving challenges that I enjoyed working on. I applied to a few different places to see if I could get an internship around town for my last year of college, a few places responded back but I had friends who worked at Sparc, so I eventually decided to work there (I'll write a post about working there soon).

Working on a big project that you didn't help create is a humbling experience. Everything seems to be a jumbled chaos, you don't know why everything is written the way it is, and you don't know where to look for the simplest bug fixes. Reading other peoples code and understanding the flow is a gained skill, and thankfully my work on open source projects helped me gain those skills. After working at Sparc for about 4 months, they introduced a game to the company (on top of the Hackathon that they already did). A bingo board was produced with the top 24 most starred GitHub repos with 5 spots (4 repos and a free square) already claimed. The rules were simple, get a pull request in, receive bragging rights (as well as cash). The moment I saw the board I ran over to my computer and created a pull request to GitIgnore for a project type I knew they didn't have. After not hearing back within a few days my enthusiasm dwindled for that project, but I decided that I would want to work on projects that A) I use at work or home and B) would sharpen the skills I wanted to improve (Javascript specifically).

Eventually finding the Brackets project and using it at home I found a few solutions for bugs and worked on them over the weekend. I talked to a few people on the project and most of my pull requests were accepted! I was excited. Talking to Jeremy at work I learned I was the first one to get a request pulled. The feeling was great, I found something that I could help with outside of work that will help me with work. Around a week later I learned that my request for GitIgnore went in (Another one bites the dust goes here). A second spot on the board? My bragging rights just increased more, as well as my knowledge of software development in general.

I wanted needed more more knowledge. Sparc was helping me learn Angular/Play/Design and other things, but working on these other projects helped reinforce all the things I was doing at work. Turning working on open source projects into a game made me want to learn more, to share more. Eventually I had to modify part of our code to implement Modernizr to check if the browser would support our new feature. Modernizr was also on the bingo board. During that weekend I learned a lot more about the Dom as well as how to create tests to see if a browser supports a feature. I decided that I wanted to work on implementing a test for the Keygen tag. But for the life of me I couldn't figure out why everything wouldn't work for me. Eventually seeking out help from Calvin at work, I learned about something called the Shadow Dom. I've never even heard of it because I didn't know where to look. Just having a mentor there who can point you in the right direction is a godsend.

After a few more days of banging my head against the wall Calvin and I had another talk, this time he told me that he was also working on a pull request for Modernizr. Game On. We spent a few days working on different things, me on my Keygen problem and Calvin his own feature detection bugs. We both opened up a second pull request around the same time because we wanted to gain the bragging rights (and with both of us working on two different bugs it means we still have the same chances of getting ours selected). Then it happened, "guess what? ;p" was the message. I've lost. But just because he got his request in first to me wasn't as bad when I thought about everything I learned over just that short period of time. Having someone there forcing me to try and become better by being a rival was one of the best things that I've ever done. I know that competition helps with the competitive "I want to be better" spirit, which is why I've started the coding competition practices at College of Charleston. It is what I believe to be the reason Sparc does the Hackathon, to help create a collaborative, yet competitive stage to help people become better at their craft.

So why tell you all of that? To help make a point. Students who seek out knowledge/mentors/competition will most likely have more fun than their counterparts. Attend events like POSSCON and BarCamp to improve your knowledge and find a mentor. Compete in competitions like the Hackathon and ICPC to be in an environment that will make you want to be better. Work on projects outside of the classroom (Open Source ones for community, personal projects for the itch (first lesson) that you will get to write something for a problem you know of). Those are the type of students I want to see more of.

Creating a Reliable Testbed for Play Framework with a MySQL Database

Recently I have been working with the Play framework, and my job was to create a reliable test base class that would handle cleanup of the database after every test. Originally I was trying to use DBUnit to make my life easy, but I was never able to get the filter to work correctly to create the required flat XML file/dataset that is required to dismantle and create the database. Eventually (after a few days of frustration) I went a more direct path with my solution of restoring the database to a known state.

Using built in MySQL commands I was able to create a dump of the MySQL database at the beginning of the class (using @BeforeClass) by calling the system command "mysqldump". In Java it is important to note that the act of piping information is not available with the Process class, so the normal command of

mysqldump -hHost -uUser -pPassword Schema > dump.sql

was not going to work. The real command should be

mysqldump -hHost -uUser -pPassword --result-file=dump.sql Schema

Same goes for restoration of the database (which I do in the @Before annotation). Piping is not legal, so instead I used

mysql -hHost -uUser -pPassword -e "source dump.sql" Schema

Hopefully those of you using the Play framework will find this useful to create a simple backup and restore procedure for testing purposes. I would recommend using DBUnit if at all possible, and I do plan on changing it if I have the time, but for now this runs fast enough for me, and is reliable.

Google Code Jam Problem B.

Currently Listening to:
KOAN Sound - Sly Fox
Funkanomics - The Goonies Island

CSCI 462 has no more required blog posts. Now it is time to start blogging about specific problems I have been having as well as observations that I have.

Last weekend I participated in the Google Code Jam. This online programming competition is open to students and professionals alike. Out of the 4 problems I solved 2 of them with small and large datasets, and one of them with just a small dataset bringing my score for the competition to 80 (you only need 35 to qualify for the next round). My favorite problem to solve from a critical thinking standpoint was problem B, the lawnmower problem. 

The problem stated that if you have a patch of grass and a lawnmower that can only cut in straight (horizontal and vertical) lines, would it be possible to create the given pattern. Originally I was going to solve the problem by just checking to see if the rows and columns had a valid line, but this misses test cases. 

Eventually I got to the point where I figured that if you remove the smallest valid line that the lawnmower made (i.e. the last pass chronologically that the lawnmower made) and remove that line, you can work your way back in time until you have the original lawn. For the sake of simplicity I just removed the line out of my list completely and if I had a list of nothing it at the end of the loop was a valid lawn, otherwise if I still had stuff in the list something went wrong and it wasn't a valid cut. The method for checking is to find the smallest value in the list and checking to see if either the horizontal or vertical line was filled with the same values. So this is what a lawn looked like as it ran through the code:

2 1 2

1 1 1

2 1 2

(bold and underline is the smallest)

changed to:

2 2

1 1

2 2

which changed to:

2 2

2 2

which eventually turned into an empty list. That meant that it was a valid lawn. If at any point both the horizontal and the vertical check failed it would break out of the loop, which caused the "isEmpty" to be called and a judgement of the lawn set. My problem B solution can be found here.

POSSCON Report

Currently Listening to:
Hol Baumann - Endless Park
Can't Stop Won't Stop - Toys for Boys

I can't stress enough how comfy the bed was at POSSCON, just throwing it out there that I passed out early and woke up before my alarm.

I have been to POSSCON before but this is the first one that they held at the IT-oLogy building. I do like the facilities, but the space seems cramped in comparison to the locations of years past. During the first day I spent most of my time running the demo of Obsidian, not trusting myself to speak very much and let the code do all the talking after what I consider a mess up at the ACM meeting. We did talk to a bunch of people interested in the project. It seems like a lot of people want to extend Obsidian to work with .Net and C#. In reality it doesn't matter what language Obsidian is because the project is more about the design patterns which are just that, a pattern. Any language that has something akin to the Reflection library in Java could potentially create an Obsidian package to work with it. I know one of the people from the local LUG in Charleston caught up with me and asked if I'll try making it for Perl (Could be fun).

Right before lunch I caught up with +Eric Wages and had a fun conversation about what we have both been up to since the last time we both saw each other (must have been right after the last BarCampCHS). While talking Christian Heilmann from Mozilla showed up in our corner of the room. We all proceeded to talk about the new Mozilla Phone and how to target a niche audience. Eric had to leave to give a talk a little bit later so I got lunch at got back to the booth to do another shift.

After the first day of POSSCON there was the GitHub Drinkup. It was fun seeing old friends that I have made over the years hanging out. After catching up with a lot of people I hung out with the rest of the CofC crowd. It was fun to finally let loose after all the tension leading up to POSSCON finally let go. One of the conversations we had over drinks was +Tyler Sawyer's app idea with +Reece Long. Talking to Tyler about how he could make the app more modular in design to make more than one app was a good conversation. He could use the framework he should build *cough cough* (get on it Tyler) to create different apps for different customers. After the Drinkup a bunch of the students went out to get dinner at a local restaurant. The night was filled with stories and triumphs of the day, all concluding to the best bed in the world for my sleepless body.

The second day was more fun than the first. I got back into soldering and learned a bit about programming an Arduino (which I played Simon Says on for the rest of the day). Other than the Arduino class I spent my time on the Obsidian booth. Talked with more potential co-developers of Obsidian and got more feedback for it (moving to GitHub as I write this). During the wrap up of POSSCON Dr. Bowring and the rest of the CofC gang was called out for being at every POSSCON since the beginning and always being active participants in the talks. Obsidian was also acknowledged for being a student run project out of our department at CofC. It felt awesome for being acknowledged for being active members of POSSCON. Hopefully we will be able to send more and more students every year (one of the ideas thrown around by a few students was the ability for people about to take 462 to attend POSSCON, and then attend again while they are in 462 so they have the perspective of open source before they get involved and again while they are invested).

There was a dinner after POSSCON was over. I had a chance to chat with a professor, his recently retired wife, and a open source advocate for Microsoft. The four of us talked about everything from GIS, Remote Sensing, Open Source licensing, our favorite talks, my budding career in open source (I had to talk about Obsidian, remember, trying to get users), plans for after college, and why CSCI 462 at the school is one of the best ideas they have heard of in a long time. They all wished that their colleges had something similar. This shows me that CofC is onto something here with making a class requirement to contribute to a team project in open source.

Maybe other colleges will start trying to emulate that.

Reflections on my progress and plans

Currently Listening to:
Galaxy - Highlight Diver
Dan Pound - Esoterica (Part Eight)

So tomorrow is POSSCON. My team left today right after our ACM talk to go setup the booth for the event. I didn't sleep last night because of my impending fear that I won't get all the work done in time for POSSCON. I think I should have let sleep take over my body seeing as how I don't feel my section of the presentation was lacking in every way. I had to present a demo in front of everyone at the meeting, and my mind was going in a hundred different directions by the time I finished my part of the presentation. The team left after our talk and I stayed in the conference room to finish up more bug fixes and documentation issues. I feel like I let some members of the team down because of my performance today, but I can take solace in the fact that normally I strive under giving talks in front of people (See: BarCamp). Today was just not my day.

I finished my documentation that I wanted to get done and submitted the final diff to Hunter for a bug that I wanted fixed before we debut at POSSCON and proceeded to take a nap. Currently Obsidian is the only thing that I have been working on, and I have been mostly neglecting my other work in other classes. So while the progress has been great on the front of releasing an open source project I feel that on a personal level I should step back and not try to bite off more than I can chew. Currently I want to be on par with the inner workings of Obsidian as Hunter is currently, but that will take more time seeing as how he has a 2 year headstart.

I think the whole team was feeling the stress for the past few days. Sleepless nights of work for the past week have taken its toll on the whole team. I know that looking back on this in hindsight is going to be a great experience, but for next semesters 462 class I will warn the people who want to make their own community that it is a lot of hard work and sleepless nights to make it good.

Oh, and Happy birthday to me. My birthday was this past Sunday which I forced myself to take a break and have dinner with my family. It was fun. I'm most likely going to be buying that mechanical keyboard that I have wanted for a while now with the money I received.


Time for bed so I can wake up early tomorrow to drive up to POSSCON. Wish me luck.

Preparing for POSSCON

Currently listening to: 
Kettel - Boekebaas 
Bassic - Daydreamer

Adding a currently listening to. I think I'll start adding that to my blog posts from now on seeing as how some of my friends ask me for new music to listen to all the time, I might as well give them a easy way of finding new songs ;)

Finally the blog where I get to pick the speakers I'll be going to attend during POSSCON. A few of my friends are actually going to be presenting at the event and I have been asked to attend their talks, but I'll list the talks that I'll be attending for the sake of the class instead.

The first talk that I want to attend is one that I already signed up to do with my current boss Clay. There is a special workshop held on the second day where SparkFun is going to be teaching us how to solder, and then later in the day teach us how to program our newly made simon says game. The class is going to be held by a few people from SparkFun and should make an interesting second day to POSSCON (that and I get to annoy Clay on the ride back by playing simon says the ENTIRE ride back to Charleston. I'm sure he would love that).

The second talk that I want to attend is actually a SparkFun employee who is giving a talk on how to teach STEM in schools. Lindsay Craig will be leading the session. I have already talked about my wanting to work in education here, here, here, and here. So I feel like this is a class that is almost required of me to attend. Hopefully he talks about motivational techniques like gamification and other types of external and internal motivators that we can instil in the younger generation.

The third talk that I want to attend is "Javascript: the language every developer should know" by Tom Wilson from Jack Russell Software. Seeing as how I have met Tom a few times (BarCamp, Code workshops for test driven development, Hack-a-thons) I feel like I should trust him with a title that has an absolute, "Everyone should know". The abstract for the talk indicates that Javascript has matured to the point of being something beyond just a scripting language, and I feel like I should look into it more than I have in the past.

Other than attending the talks my job during POSSCON will be to sit at the Obsidian booth giving out stickers and showing off the functionality of the project. I can't wait to see if there is any hype or feedback from them. Besides, I'll be keeper of the stickers that everyone in our class wants so bad >:D

Release Early and Often

Release Early, Release Often! Back to my favorite conglomerate of papers written by Eric S. Raymond. This segment talks about the development model of the Linux kernel, as well as a common development model for most open source projects.

Back in the early days of software development it was common to work with the Cathedral building development, this way your early buggy versions do not disgruntle users or even change their workflow. The idea that the objective was for users to run into the least amount of bugs kept this perpetual cycle of one leader programming and slow patching schedules going for a while. It wasn't until Linux started gaining momentum that another way of developing code seemed to work better. Linus treated his users as co-developers, bug hunters, and documentarians.

His use of leveraging users to let them collaborate allowed him to pick ideas and incorporate them (if the user didn't already incorporate it themselves). This turnaround sometimes lead to releasing a kernel update more than once a day. This helped motivate the co-developers, either from their sense of the gift culture that open source is now known for, or for the ego satisfying love that hackers have when their name is on a project. This lead to better code with the idea that "given enough eyeballs, all bugs are shallow" otherwise known as "Linus's Law". If the project dev group is large enough a bug will be caught faster, and bugs will have a higher probability of having a quick and obvious fix to someone who might have seen that type of problem before.

Releasing early and releasing often is most likely going to be the development model for Obsidian. Hopefully builds will be twice a month at first, and when the project becomes more stable the ability to refactor parts that we know we want to change (like the methodMap) can come later. We just need to find a collection of developers that like our project and will continue to use it even if we are not developing it anymore. I hope the original team will continue to work on it, but the open source community is already used to people moving on and new people taking over, we just need to find our developers first.

Speaking of Obsidian, we have a week to go before POSSCON and our release of the code to the public. The poster now has cool graphics to show how each pattern works. The wiki is tentatively declared done, but as it is a wiki it will never be done. Something will always need to be changed, something else will always need to be updated, it is just the name of the game when it comes to an evolving project. The documentation needs to change to keep up.

Lets just hope it doesn't need to be changed that much.

The Doc is in!

The exercise this week was all about documentation. Seeing as how we are in the middle of writing all the documentation for Obsidian I decided just to keep at it and continue working on the Obsidian documentation. My feelings on documentation were described in a earlier post, but I feel like Jeff Atwood describes the best methods of commenting on his blog Coding Horror. If the complexity of the code is high enough for you to write a dissertation in the method, you might want to reconsider refactoring it to be separated out a little bit more. 

One of the exercises was to write a wiki page of developer documentation for each program. Seeing as how I took hold of the "How to Contribute" page I decided just to finish it up with some common coding standards as well as modifying the build instructions for the source code. Other then that most of the documentation is almost finished, we are just working on the documentation for the poster. 

The team's meeting recently has been about the layout and wording of the poster. We tried making the sections understandable without being too much, but to fully explain parts of the project we had to write full paragraphs. An example of some of the poster documentation:

Overview:

Obsidian has four different patterns for tests that are determined by two factors: whether the function has parameters and whether the function throws exceptions. With the usage of these patterns Obsidian can create a test implementation for different types of methods. 

And an example of one of the patterns:

Call:

The CALL pattern, the simplest pattern, is generated on functions that do not have parameters and do not throw exceptions. All Obsidian can do in this case is call the method, and generate the assert statements. This is the basic building block of Obsidian, and is used in all of the other patterns.

I'm really excited to see how it turns out. I'm just sad that I will not be there the night before to help setup. I have a test the night that the rest of the team will be driving up, so I will not be at the welcoming party. This is good news in a way, seeing as how the stickers should be arriving the day that everyone else is heading up, so I'll be bringing them with me the next day (the first day of POSSCON). 

After the break...

During the break I told myself that I was going to get a bunch of homework done on the first few days, and while this is true I also said that I wanted to work on Obsidian for a few days after, this is not so true. I did work on what I had to finish but the break allowed me to recharge my batteries which I desperately needed. Especially because I got sick halfway through the break.

So after the break the team got together to see what we needed to finish. The documentation had a good "first pass" where everything had a little bit of information, be that bullet points or just setup of the page. During the next week the main focus will be documentation seeing as how most of the bugs and enhancements/features are now completed and fixed over the weekend. There are refactoring things we want to do, but currently we want to have the documentation in place so people can help contribute.

One of the side items that I have been working on is to try and figure out how I would want to implement Global Equality Methods. These methods are there to allow the programmer/test engineer how each object that is in the project is equal to another object of the same type. The problem that we know exists is one of how to address the objects. Our code styling for the Package and Class level of the Equality Methods just use the name of the class. One of the projects that we use contains two classes with the same names in different namespaces, so we have a problem with ambiguity between the classes with the same name. It seems like we are going to have to use fully qualified names when we create the areEqual methods (example: areEqual(com.foo.bar x, com.foo.bar y) instead of importing com.foo.bar and using areEqual(bar x, bar y)).

 Other then that the team is going to start meeting on Friday nights, bringing the total time working together 3 days a week. We figured that while writing the documentation it is easier to just ask everyone at the table what the wording should be, or what should go on what page instead of emailing everyone to wait for a response. Hopefully the Friday meetings are going to allow us to work on the project to get it out there faster and decrease the amount of stress that the group has been feeling. That plus the pop quizzes Hunter has been giving us (to test our knowledge of Obsidian) are sure to help ease everyone's nerves about the upcoming booth unveiling at POSSCON.

Reflections on my Progress

Team Obsidian is confirmed for having a booth at POSSCON. The team sat down tonight to discuss the work we need to finish. The tutorials on the Wiki as well as some small changes to the code still need to be made, but everyone on the team seems to be getting better acquainted with the code-base. So now that we know we have a booth we need to determine what our plan is for the table. Everyone agreed that a demo would be cool, that way we can show that this isn't just a planned project but one that is actually in a workable form so the theory of Stone Soup can be applied (Stone Soup being the idea that if you have a workable base other people are more interested in helping/giving). So we are planning on finding other open source Java projects to run Obsidian on during our time at the table. Another idea is to have another "floating" computer for people to type in their information so we can email them about the project later down the line to remind them to check it out. We have the stickers that we designed for the project, and they look amazing, so we will also be giving away stickers to people who come up to the table.

The documentation that I chose to work on consisted of "How to Contribute" and "How to Run". Contributing was harder then the how to run in my opinion. Coming up with the rules and norms of how to submit a patch as well as standard coding practices we used was a little difficult. I emulated some of the bigger open source projects while trying to keep in mind that we are a smaller project, so automated scripts and automated testing are a little bit of overkill. During the meeting we discussed how people can claim bugs, and our preferred way of submitting the solutions. Another thing that is currently in the contributing page is how to get and build from source. I put it here originally because contributors will need to be able to get the source, but after running a few tests with our fellow students a lot of them went to the "How to Run" page to build from source. I'm planning on talking to the group about this to either make a separate page for source code building, or linking the "How to Run" page to the section in contributing.

Everyone is busy working on their bugs and documentation, but lots of us have been feeling a strain with the semester coming into full swing. I know personally I need to work on other classes a little more, so before I go to POSSCON I'll be sitting down and working on all the homework for the next week so I don't have to worry while I'm at POSSCON.

Refactoring Mindset

What is good code? Code that runs, right? Well, if you never have to go back and work on the code then yes, that would be the definition of good code. But in the open source community there will always be a problem with people who need to come in after you to fix bugs. Readability starts coming into play when you work with someone other then yourself. If I were to ask you what this code segment does, you would have to play with it for a long time just to understand what does what:

#include stdio.h
#include math.h
//What does this do?
double l;main(_,o,O){return putchar((_--+22&&_+44&&main(_,-43,_),_&&o)?(main(-43,++o,O),((l=(o+21)/sqrt(3-O*22-O*O),l*l<4&&(fabs(((time(0)-607728)%2551443)/405859.-4.7+acos(l/2))<1.57))[" #"])):10);}

This code is what we would call "bad code", and to tell you the truth it was designed that way. This segment of code was written for the International Obfuscated C Code Contest and was written by Natori for the 15th international contest. His code prints out an ASCII moon to the terminal that is representative of the phase of the moon currently. The problem with code today is one of readability.

Refactoring is the idea of taking a segment of code and changing it to act the same externally while changing the internal workings to have reduced complexity as well as improved readability and maintainability. For our homework we had to take some code from the RMH Homebase and refactor a specific piece of code into something more manageable and readable.

if ($edit==true && !($days[6]->get_year()<$year || ($days[6]->get_year()==$year && $days[6]->get_day_of_year()<$doy) ) && $_SESSION['access_level']>=2)

Knowing little to no PHP did not help me with this problem, however looking at the code it is easy to see that they are looking for very specific parameters to be true or false. By taking the existing code and just making some additions to spacing and comments allows the next set of people to come along and make modifications.

if ($edit==true //if can edit 
&& //and
!($days[6]->get_year()<$year //not before this year
|| //or
($days[6]->get_year()==$year && $days[6]->get_day_of_year()<$doy) ) //after this year
&& //and
$_SESSION['access_level']>=2) //the access level is 2 or greater

This (while still ugly) is better then having the next person coming along and not understanding what the if statement is doing. Also having a comment before the if statement explaining what the requirements of the conditional are can also help improve readability. The simple act of adding a line stating "Do the following if the edit is enabled, access is 2 or more, and the year is between X and Y" can make this line just that much better.

The only problem with comments like these are putting programmers into the habit of over commenting their code. I have seen plenty of students who have a teacher who punishes students for not commenting. However, I think that with good variable names and simple structures, comments can become useful for the once in a while complicated structure that we need to solve the problem. Jeff Atwood shares my sentiment about comments in code over in a post on his blog Coding Horror.

That could be me in x years

Today was the Alumni Symposium at CofC. We had alumni from the computer science department come in and talk to the current students. Each one of them is given 3 minutes to talk about whatever they want to talk about, followed by Q&A from the current students to ask anything they want. The theme for this years event seemed to stem from "personal projects = jobs". Most of the speakers talked about how they got into the position they are now by having personal side projects that they worked on before they started working, and projects that they keep up with even while they have a full time job. The advice only seemed to have one warning, and that was to make sure that if you work on the project outside of work that it does not break the contract. This I think is really good advice, and one that will probably follow me for the rest of my career seeing as how I love working with open source.

Speaking of open source, lately I have been working with Obsidian to get it ready for POSSCON. To understand the code I have been dissecting different parts by changing things here and there to see the changes and understand the control flow of the program. One of the things I'm currently looking into is making the source code IDE independent, and coming up with the tutorials on how to make it work on most of the platforms. That should be an interesting task for me, playing around with ant and writing technical documentation will be a learning experience.

Going back to what I could be doing in the future, I have given a lot of thought into what I want to do as a career path, but I haven't finally decided on anything yet. The main issue that I face is do I want to switch careers halfway down the line, or do I just want to stick to one track? The two tracks that I'm torn between are teaching and software engineering. I love the idea of teaching the next generation, but I feel that without some real world experience (10 years as a software developer or so) that I might not be able to impart extra wisdom to the class (the extra wisdom being non-academic advice). So the way I'm thinking about my future right now is going to work writing software for a few years, and eventually while I work teach on the side. Eventually I would transition from that dual job title and go fully into teaching, the only problem with this is the advice that I have been getting from people. Most of the academics and non-academics that I talk to suggest that I should go straight into teaching and not bother with going into the non-academic sector because of the money. Apparently if I go into the private sector I will get used to a lifestyle, and not want to return to the academia world. I do not know how true this is, but enough people have warned me about it to start putting serious doubts in my head about doing the dual career paths.

Whatever path I decide to take, I still think it would be cool to make the one idea I have had for a while and bring it into fruition. I have always wanted to make a company where the contracts we take on will pay for the bills, while the other half of the company will be a R&D/Open source department. Anyone in the company can take a day a week to work on an open source project (or create one) and put it out there for other people to use. I figure this way the open source software we do use will be improved with the features the company wants, and if people see the work that our workers are capable of they will pay for our services. The other part of the company is the student side. I would love to be able to have students on the team, working on both sides of the company, as well as getting real world experience along the academic experience they are receiving. This is something I really need to put a lot of thought into before my undergrad finishes up, that way I have a clear idea of what I need to do moving forward.

What's Happening?

For this blogpost we had to grab a recent article from an ACM or IEEE magazine and talk about it. I chose to write about "The Great and Terrible Oz" by Grady Booch from the January/February 2013 edition of IEEE Software.

The article expresses the importance of education of the public when it comes to computers. As technology use increases and gains momentum the public seem to be getting further and further from how software actually works. Everyone from your parents to politicians are losing touch with how technology works, and this is a problem. The further the curtain puts people out of the knowledge the less they understand about technology and the prevalence of "magic" in the system will increase. I have seen this gone awry many a time. People think that they "just get viruses" because lack of knowledge. People pay a prince in Nigeria to be part of the rich. People steal software because "it is already made". Without the proper knowledge people are going to get more and more lost.

The problem with this day and age is that technology is growing faster than the population can adapt. Sure the tech savvy know what is going on, but the rest of the world will blindly go out and buy iPad's because of targeted advertisements. My parents in particular still ask me for computer help from time to time, but I have trained them to a level where they only ask if they really need help. Another thing that I have done to help them be more educated is to send them videos of scams and tutorials of different technologies. They won't be falling for a 419 scam anytime soon because they know a little bit about electronic banking.

I have also noticed that with education the amount of viruses on a given machine approaches zero. Switching my parents from IE to Chrome (admittedly by tricking them into thinking Chrome was IE) drastically reduced the number of phone calls asking for help. Now, I'm not saying that everyone has to do what I did to my parents (that was for my own personal gain), but a little bit of education goes a long way. With acts going through congress like SOPA and PIPA an education of the public would go a long way of protecting the internet and my job security in the future.

Squashed?

So I have created a patch that we have now accepted into the trunk repository.

The issue I worked on was that PackageEqualityMethod was not importing the public/package/protected inner classes to be used in the "areEqual" methods. At first I developed a few new methods into the system to try and grab all instances of inner classes in a specified package but at a code review session we talked about how to take the things I learned from creating those methods and how we can modify the code to grab the inner classes, seeing as how it already grabs everything else.

Here is an example of a class that we are trying to grab:

//Demo of program that creates bug
//would import just fine in PackageEqualityMethods
public class Foo{
    private int x;
 
    public method1(){
        //Do stuff
    }
 
    //would never import into PackageEqualityMethods
    public class Bar{
        private int y;
        private method2(){
              //Do stuff
        }
    }
 
    //never needed to be imported because it is private
    private class PrivClass{
        //Private class
    }
}

This class created 2 areEqual methods, one for Foo and one for Bar. The private method does not generate an areEqual method, but we are considering making that enhancement at a later time if public opinion and want is high enough.

Here is part of the prototype code that was used to grab the inner classes and put them in the import statement list:

//Class TestAbstract
 
//Method to grab all internal classes and add them to the imports
public  void addInnerClasses(Class classToScan) {
        Class[] classes = classToScan.getDeclaredClasses();
        for (Class c : classes) {
            String importString = c.getName();
            //The getName will return the name with a “$” to show it was internal to the class, replace with a “.”
            importString = importString.replaceAll("\\$", ".");
            //Check to see if it is a member or an enum, and if the modifier is not private
            if ((c.isMemberClass() || c.isEnum()) && (!Modifier.isPrivate(c.getModifiers()))) {
                //if the class is not already imported
                if (!dynamicImportContains(importString)) {
                    getDynamicImports().add(importString);
                }
            }
        }
    }

We then found the part of code that imports classes into the PackageEqualityMethod, and modified it to create this:

//code segment in Class TestAbstract
boolean shouldBeIgnored = false;
 
//code to check if it is not already in dynamic imports
 
//make sure: not in same package
if (classToImport.getPackage().toString().compareToIgnoreCase(
  classTested.getPackage().toString()) == 0) {
  //Added statement to allow member/enum/local classes.
  if (!(classToImport.isMemberClass() || classToImport.isEnum()
                     || classToImport.isLocalClass())) {
    shouldBeIgnored = true;
  }
}
 
//rest of the class that creates the import statements

The final solution to fix this bug was a single conditional statement added to make sure that inner classes were not being ignored.

All in all I believe that sitting down with the code and running multiple open source programs through it has brought me to a better understanding of how reflection works in Java, as well as a greater understanding of Obsidian. After submitting the patch (diff file) I have also started looking into what coding standards and patch requirements we might implement when we release the software in 5 weeks, but I'll talk about my findings next time.

This Bugs Me

Let me talk about my first bug in Obsidian, but first let me explain what the PackageEqualityMethod is and why it is important.

PackageEqualityMethod is a class generated when creating the framework for testing. It holds equality methods for all the classes in the package that the test engineer will then be able to modify to allow non-primitive classes to have a isEqual method that we then use to check for equality. Normally a test engineer needs to write these out for each class if it is needed, however Obsidian takes care of this by having three levels of equality checking. A GlobalEqualityMethod is currently being developed that will have equality methods for every class in the project. This will be the main location where test engineers put most of their work. Below that is the PackagEqualityMethod. The package equality will by default call the global equality, but if needed the test engineer can go in and change the way equality is checked for that specific package. The third level is at the individual class. This equality method will by default use the package equality methods (which in turn may be using the global if it has not been modified), but can also be modified to test for equality in a different way for just that class.

Currently the issue tasked to me is Issue 6. Issue 6 deals with the building of the PackageEqualityMethods and it missing required import statements. I have been studying the errors with a few open source projects and it appears to be an issue with Nested Classes. The way I found this out was by running obsidian with the  different open source projects and manually fixing the errors. When I fixed the errors I went into the offending class that was not being imported and discovered that all of them had to do with being nested classes and in certain conditions Enum's. While one of the projects I tested had a lot of nested classes inside, most of them were not accessible outside that class (most were private). The reason for the errors was that Obsidian was trying to make an equality method for that class without importing it specifically. An example of a class that produces the bug follows:

 public class Foo{
 private int x;

 public method1(){
 //Do stuff
 }

 public class Bar{private int y;
  private method2(){
  //Do stuff
  }
 }
}

This creates a problem whenever Obsidian creates the equality methods because in the PackageEqualityMethod it does not "import com.foo.bar", it only imports "com.foo". It also creates a problem when two nested enum classes are put into the PackageEqualityMethod. I am currently working on how to change the import creation, but depending on what the group thinks I might change the way Obsidian creates the equality methods to ignore nested classes. The second option feels more like a cheap way of fixing the problem while also hindering the test engineer. If the code has a public nested class you should test it separately as if it was another class.

Bug Juice

The team has now come out with a public Google Code Repository that we are using to track our progress as well as the bugs we find and the features/enhancements that we want in the software. Our new timeline is to have all the functionality and bugs mostly done (if not completely done) by POSSCON. This is going to require a lot of effort from the group, especially if we need all the documentation done at the same time. That is why the plan is for Hunter (the main developer currently) to continue to integrate the enhancements while Micah, Laryea, Joanna, and I fix bugs. During the bug fixing we are also assigned secondary tasks. These tasks include adding new bugs and features that we find/want in the issue tracker, as well as working on documentation. Hunter and Laryea are creating a new logo and website, Joanna is extracting the information from the academic paper and putting it into the documentation, Micah (self dubbed King Wiki) is adding what we know about Obsidian and how it runs into the Wiki, while I'll be working on creating guides for how to work on the project with different IDE's and OS's.

The issues that I have been assigned are fixing the generated PackageEqualityMethod's and what they import, as well as implementing the Null and Primitive equality methods at the global level. The first one that I want to tackle is the import issue with PackageEqualityMethod. This task is going to involve finding out how Obsidian currently gathers the required imports, finding common missing import statements and figuring out why Obsidian misses the common missing imports. I'll be spending a good amount of time finding other open source projects written in Java to throw Obsidian at so I can have sufficient data about the missing import statements. Hopefully I'll be able to see common trends with missing imports (an example being that it misses every import statement from com's but not org's) and then quickly come up with a patch.

The other teams all seem to be working hard on their respective projects. I'm really interested in how this class succeeds in reaching their personal goals for this semester. Some teams have picked to work on a lot of bugs while a few will be working on primarily enhancements for their project. I can't wait to see what happens in the next few months.

Reflections on Open Source in Today's World

What license should we use?

Obsidian is currently using the MIT license, and seeing as how we haven't released it yet we still have an opportunity to change it. Reading which open source license should you use it might become a topic of discussion for our group. The main thing that we would have to discuss is how much freedom people have on the choice of returning changes to the code base back to the main developers. This idea has been coined Copyleft. Copyleft is the idea that instead of copyrighting the software to not allow anyone to modify or redistribute the product you are allowing people to work on it as if it was in the public domain (which some developers do), but still give someone ownership. The main owner of the software is allowing you access to make modifications, but when you publish your modifications it must abide by the same rules of modification that you received from the source.

The different licenses have specific uses and rules to them, an example of this would be the ability to use a copyleft license product (or parts of code) in a proprietary system. Licenses like this include the Microsoft Reciprocal License and the Mozilla Public License. If you want to allow unlimited freedom with the software the MIT and the 3-clause BSD license have no copyleft and no discussion of patents. Both of these licenses are out there for anyone to tinker with and use in any fashion they want because of the academic ties that they both grew from. If you want to make sure that every modification is published, and everyone who uses components gives their users information about the component the GPL licenses are most likely the best ones. Another factor we could possibly use is to change the IP/license depending on the entity using it. We could have specific licenses depending on if this is for a company, student, or personal use. We will have to discuss as a group what type of license we like the most.

What hosting should we use?

Obsidian has been using CofC's SVN server during the development that Hunter has already put into it. Now we need to pick what infrastructure we are going to want, as well as who is going to be hosting it. The first one that comes to mind is keeping it on the SVN at CofC. The only downside that I can see with this is that if we wanted to add people to the project we would have to develop a portal for a way of giving usernames/passwords to potential contributors. The other point I would have to single out is the fact that there are already plenty of people who offer this service, why try to confuse people with a new system/repository when they most likely already used to the other repository services. 

The main repository services that open source developers like to use include Sourceforge, GitHub, Google Code, Gitorious, and Bitbucket. They all allow you to add your source code as well as a download page to allow people easy access to the binary files. Each has their strengths and uses, but we are thinking of going with Google Code. We liked it for the built in Wiki and issue tracker as well as the capability to integrate Google Groups to allow for easy management of the contributors. The one benefit that I like from GitHub is the idea of a very social environment, and by that I mean that it is very easy for someone to develop their own branch and create a patch that we could then integrate with the base. This question will most likely just come down to personal preferences of everyone in the group.

How to teach Programming

Subversion Under Control

Our team had a dinner meeting tonight. Hunter told us that we would be receiving our source code later in the evening. Everyone was excited to head back to the lab to talk about the source code. I now have on my hard drive a working copy of Obsidian. We talked briefly about the different main parts of Obsidian, but the main idea is for each of us to go in and explore the code ourselves. We came up with a list of functionality that is needed for completion of the project as well as some possible areas of extension that we could work on. To learn the source code we decided that going through the source and creating class diagrams of the packages and how everything interacts would be best. This way we are forcing ourselves to look at every file and method in the project and understand their connections. We might even get a good class diagram that we can use to teach other people about the code at a faster pace then them just looking around.

Programming Education

I have advocated that the educational paradigm that we have currently (not just for programming) is broken and needs to be drastically changed. Sir Ken Robinson is one of my favorite public figures who shares very similar viewpoints on how education should be changed. The main problem with school is the fact that it hasn't evolved since its growth during the revolution. The level of importance on each subject is very skewed to catering to "creating professors" as Sir Robinson puts it. By this he means that we put Math and Sciences first, followed by everything else, with any type of art usually being at the bottom. Now, this might be all well and good for anyone who wants to go to what we know of right now as higher education (Math and Sciences being the main competitors while liberal arts colleges being the only schools who entertain the thought of an art major) but it isn't the best if we want to be able to start seeing problems from different angles. I'll talk more about general education in a later blog post, but for now lets talk about programming.

The main idea behind learning different paradigms like Object Oriented and Functional languages is for the expanding of our cognitive self, to be able to see the problem from different ways. This is also the same reason that we learn about different ways of solving the problem (recursive solutions vs iterative solutions). So with this reason well established I must ask, why do I feel like most of the people who try to go through a programming degree switch? Why do some students really struggle with the problems? I remember specifically when learning about linked lists and our teacher taught at a high level (concepts) and wanted you to figure out how to program it by yourself. The problem was that most of the students around me seemed to not understand how to code it. When I would sit the student down and try to get them to explain to me what a linked list is they could draw the diagram, and how to move though it, but they never made the connection that "currentNode = currentNode.next()" is the way that you can move to the next node. Why did so many students not seem to grasp the concept? I honestly don't have a concrete answer, but I can say that the students that didn't get it the first time seemed to grasp the concept a lot better when I used real world code examples and a visualization of what happened step by step. I feel like if we want to teach programming more we need to change the way we tackle the situation. And this doesn't mean just teaching the syntax either! I remember being in another class where we learned syntax for most of the class and then for the final I was asked questions about higher level concepts that (again) some students didn't seem to grasp. It seems that no matter how you teach there are just going to be students who don't understand parts of concepts. I know a full range of programmers, ones who know many different ways of solving the problem, but they couldn't program the simplest of solutions to a problem. Others who if given the method signatures could program everything, but couldn't come up with their own solution to the problem. How do we bridge the gab so we don't have this large whole in our talent.  

Bret Victor (former interface designer at Apple) says that the "new" ways of teaching programming by using tools like Codecademy and Khan Academy are doing everything wrong. In his interactive paper he explains that both the environment and the language should be able to allow the student to learn the way of thinking that is required of us to get our creative ideas into code. He emphasizes that Code and Khan Academy are just teaching the "rote skill" of programming, which as he puts it, "Learning about 'for' loops is not learning to program, any more than learning about pencils is learning to draw". The goals of a programming system should be, "to support and encourage powerful ways of thinking, as well as to enable programmers to see and understand the execution of their programs". His paper has started influencing developers to help create his vision of a new programming system that would allow students to easily pick up the theory of programming without getting lost in the syntax that teachers seem to want to push under the rug until a later time (I had to go look up what the main method in Java actually meant because of the lack of explanation in class to keep the smoke and mirrors afloat until after people learned syntax). For me and the other students who have both a strong skill-set in programming as well as problem solving seems to stem from the fact that we continue to learn outside the classroom. These are the students I would want working with me on any project. The ones who stay here late at night solving a programming problem because they want to and not because it is just the day before the homework is due. I want the ones who work on projects outside of class, who work on projects that are not their own, who help teach other students. Those are people who I think go to class to get the grade, but they are also the ones who if given the opportunity to make their own curriculum of what they want to learn would choose bigger and harder challenges. THAT is what we need to change our current students into. And the only way to do that, is to change the way we think about teaching. 

Motivation

Joining the Project

The groups have finally settled, the projects are slowly being picked, and Team Obsidian is officially a team. The more we talk about what we are going to be doing for the project the more excited I become. We have almost finished writing out our milestones for the project, including where we want to be at the end of the semester (hopefully we can show it off at POSSCON to some people I know who are going to be there). We hope to have a few people from outside our group interested in the software as well as a contributor or two. We are actually going to host a party if we get someone from outside the college interested in the project during our development semester. So far my section of the project is setting up/help set up our communication channels. This includes the a Google group for the developers as well as an open group for people to ask questions. The other thing that I helped with was the initial setup of our IRC channel. Eventually Micah and I will have a bot in there to do some basic functionality stuff (kicking people and controlling our op powers so we don't scare people away).

Daniel Pink/Clay Shirky on Motivation

Lately I have been reading a lot of Daniel Pink. The two books specifically I have been reading are "A Whole New Mind" and "Drive". Originally I read A Whole New Mind because the department chair recommended it to me after my interest in teaching was discussed one day and while it is a good book it isn't one I want to talk about today. I feel like I can relate Drive and another book Cognitive Surplus (by Clay Shirky) easier to software projects and open source, so that is what I'll do. Now, I love watching videos online about anything that might might be informative or entertaining, and normally these come in the form of TED talks. These videos normally help me figure out how I would want to run my company one day. Dan Pink's talk about "the surprising truth about what motivates us" was turned into a RSA-Animate video, and I feel like anyone who runs a software development company (or any company for that manner) should watch the video and understand what motivates us isn't as straight forward as you think. The three key elements that he deems important for better performance and personal satisfaction are: Autonomy, Mastery, and Purpose. With these key items I can see why the open source community continues to grow. We have the ability to choose what we want to work on (autonomy), we can continue to get better at our craft (mastery) and every software product we create has a higher reason for existing (like Wikipedia and Ushahidi) which gives us our third element, purpose.

Now while Daniel Pink does hint at open source, most of his video and book deal with how to motivate people within a company. This is a good thing as companies can work on open source software and make a profit, if only to get the idea of money off the table, so employees can stay focused on work. Just make sure you learn about the different ways open source can possibly make a profit (of which I'll talk about in a later post, but for now read the Magic Cauldron from my favorite book that I seem to talk about way too much for my own good), but seeing as how Obsidian is not for profit, and the people who are working on it are not getting paid (except by a grade, but I can safely say we are not even thinking about that, the project is much too interesting) I am more interested in the idea of Cognitive Surplus (video) to help us get people interested on working on the project. The idea of Cognitive Surplus is that people now have the means to use their free time in a more collaborative environment, as well as pointing out the generosity that people have to create for their fellow man. The cool part about our project is the fact that we are working on a tool that will help other people who create software. Imagine during an interview and you ask them how they test their software, "Oh we use Obsidian to unit test our code". I would just sit back and chuckle silently while I tell them I was on the team that helped make that open source. 

Knowing the factors of how and why people choose to collaborate on open source software is going to be very useful later on when the project is officially released online for people to play with. I believe gaining momentum by showing people the output of Obsidian and getting input from people early and often will only help the software grow.

FOSS Experiences and Reflections

The project that I want to work on for this semester is Obsidian. And seeing as how we would be creating the open source community behind Obsidian, I thought it would be good to go out into other open source projects and see how other people build their communities. During this effort I looked at big open source software packages (Ubuntu, Firefox, Chrome) as well as smaller ones (HTTPAgentParser, Team Talk) and a few in between (JUnit, Super Tux Kart). It is really interesting to see the differences in the amount of people change the whole dynamic of a group. For the small projects there is usually only one or two developers who have total control over everything that happens in the it. You can copy the project and make modifications but normally it is really hard to get in touch with the developers because the lack of formality with the community. Most of these projects are normally someone's quick fix to a problem that they just happened to release into the wild of open source. For the bigger efforts you can see a lot of formality with the project. If you want to submit code to fix bugs it has to go through verification processes (normally someone else signing off on the patch) and if you do not belong to the group who works on that section of the code (or you are new to the project) you have to jump through even more hoops just to make sure that your solution will not break any existing code. No matter which way you look at these scenarios they all hold a common element, they are built using a Bazaar style of organizing themselves.

The Bazaar style of development is (as Eric S Raymond puts it) the open market style of development, where you take in opinions and reviews from people who are normally outside the project. This contrasts what was perceived to be the better way of doing things the Cathedral way. The Cathedral style of development is one with very specific set of goals and a main "architect" who controls the whole project, an example of this would be GNU's Emacs and GCC. Both are restricted with a specific group of people who can contribute. Now when first looking at any level of open source software you might think that everything is actually developed in a Cathedral way (with a main person or group of people controlling everything), but that is not true. As Eric Raymond said in Homesteading the Noosphere's section called Ownership and Open Source, "According to the standard open-source licenses, all parties are equals in the evolutionary game." This means that anyone could direct the path that the project will take, however as he goes on about Open Source ownership he makes the point that in practice this can not really work. Every open source project will be dictated by everyone. So in real world practice of the Open Source licenses an Owner is usually found. This owner can be a single person (JUnit's Kent Beck) or a group (Ubuntu's Canonical), but you can easily find out who the owner of the project is by looking for something really specific for the project: "The owner is the person who has the exclusive right, recognized by the community at large, to distribute modified versions". So right now Obsidian has (to my knowledge) one owner, Hunter. Later on in the semester the ownership will shift slightly as everyone in our group starts getting more and more input about the direction of Obsidian, until eventually it will be more like Ubuntu instead of JUnit in terms of ownership.

Tomorrow I learn if I actually get into the team with the people that I want to work with, and if that happens then Obsidian is the obvious community we will be working on, seeing as how we have already had meetings about what needs to be done and who would work on setting up or initial websites and emailing listings as well as setting up an IRC channel for when we start getting other users on our project. The group seems really interested in the project and open source in general. Lets just hope that I can put my experiences and knowledge that I have to good use for the sake of making the community better and the software more accessible to everyone who wants to use it.

Picking a Project (A.K.A. My FOSS Preferences)

As I sit in the school computer lab I ponder to myself, "what type of free software/open source user/advocate am I?" Am I the Richard Stallman, or the Bill Gates? I think like most people I would consider myself in the middle ground. Not filled with disgust of closed source, but prefer open source when a good/reliable project can fulfill my need. An example of this would be LibreOffice or GIMP. Even though I would only consider myself in the middle of the spectrum I do love learning about the Open Source Movement and believe in everything they stand for. I actually tried to work on a few projects over winter break, but I'm still working on the patches before I submit them back into the project. So taking this all in consideration I believe I have picked my top three projects that I would like to work on for my CSCI 462 class at CofC: Obsidian, Melange, and Processing.

Obsidian (links will be provided when our job is done) is a project created by Hunter with Dr. Bowring's guidance. Without getting into too much detail about the project before it is released, it will help create a framework for test engineers to create unit tests. What I do feel comfortable talking about is what our team would be doing for the project. As hunter said in his post a team is forming, and one that I think meshes really well. Joanna and Micah are people I have wanted to work on a project with for a while now and last semester I had the pleasure of working with Laryea (who was on a team with hunter and myself) for our 362 project. Our work for 462 would be a little different than the rest of the class. Instead of contributing to an existing project we will (hopefully) be creating an open source community around the project (if Dr. Bowring puts us on a team together). Now what does that entail? We would have to create an open community that people would want to join. Seeing as how I have studied and advocated (and with some luck contributed to) open source in the past I feel like I have a decent grip on what a community should have as well as what it should try to avoid. Things we would be working on include: making the existing code base available and accessible to newcomers, working on a wiki page to keep a knowledge base that users and contributes can use to learn about the project, creating modes of communication with the developers (us for now) with mailing groups/IRC rooms/FAQ's, creating a way of tracking bugs and feature requests, and of course making the project better by adding features and fixing bugs. This is my number one pick seeing as how I have been begging to see/work on it since last semester when I first saw output of it for our 362 project and with my knowledge on open source I think I would be a great asset to the project.

Melange is a framework that creates "a framework for representing Open Source contribution workflows". If you have ever contributed to Google Summer of Code you have been on a Melange powered site. Melange is powered by Google App Engine (for now) and I believe that creating a framework that other open source projects can use to create a workflow for contributions is a noble cause. I know of one or two students who currently work on the project or have done so in the past and they all say that the work is challenging but rewarding, and seeing as how programmers are constantly looking for a challenge and get joy from challenging problems as well as being optimists during the whole ordeal, I want the challenge and sense of accomplishment that my fellow peers have felt.

My third project that I would want to work on is Processing. Processing is the project that I helped create a test framework for last semester. It is an "open source programming language and environment for people who want to create images, animations, and interactions." It is written in Java and works on a multitude of platforms including Android and in web browsers with Javascript enabled. The idea of working on a tool that can help students learn programming as well as artists create works of art is the original reason I picked this project last semester, and that passion for helping other people is still there for me.

Both Melange and Processing are projects that have a medium (10-40) number of developers actively working on them, while Obsidian will only have the students in the group working on it (at first). I would be happy to work on any of these projects and if I work on Obsidian I might (in my spare time) work on the other two projects as well to get more ideas on how to run an open source project. 

Bring on the Challenge!

Warning: The following blog post has a lot of links. I would recommend at least looking at the links after reading the post to get a better understanding of where I am coming from.

A new semester begins, and with that phrase students get back into the swing of things. The streets don't feel as empty as they once were during the Winter break and people are hanging out in the computer lab. Everything is slowly changing, but hopefully for the better.

The reason I deleted my old blogs and started this one is now upon us, CSCI 462 (otherwise known as Software Engineering Practicum). After taking CSCI 362 (the prerequisite for 462) I have been looking into testing more. Specifically I have been reading (or re-reading in some instances) papers and books that address the issues of software engineering in relation to: time management, open source ideals, project complexity, licensing, history of Linux, user interface, as well as going into open source projects to see where I can help out. This semester is going to be about putting everything we have learned into real world practice by submitting patches to existing Open Source projects (examples from last years class include Firefox, GIMP, and XBMC). Talking to a bunch of the students who hang out in the computer lab (hereby referred to as 218), every one of them seems anxious to start. I can feel a passion come out when I talk to them about what project they would like to work on.

It might just be my imagination running wild but after seeing a bunch of my peers start attending events that I have helped put on (and others I have attended) aimed at the tech industry it seems like students are more willing to put themselves out there instead of just attending class for a grade. Seeing students talk about the practice programming competitions and the fire in their eyes when talking about how much better they will do next time is great for me. I have talked about my own personal sense of accomplishment when I help a student get over a programming wall, but this seems to go deeper than that. I have setup another programming competition that will be on Friday 1/25/2013 and everyone seems to be paring off already into groups.

I'm really excited to be in 462 this semester for another reason (besides working on open source projects). Every student is given the opportunity to attend POSSCON (Palmetto Open Source Software Conference). My first interaction with the Computer Science department at CofC was actually the semester before I started. Dr. Starr (The department chair) invited me to attend by riding with a teacher who was driving students (for the same 462 class that I am taking right now) to the conference. Wanting to get involved early at the school I accepted. I got to talk to Jon 'maddog' Hall as well as hear talks from people involved with hosting services like github and linode. The best part is that this year one of my friends Adrian who helps with +BarCampCHS might be presenting this year! It will be interesting to see someone I look up to give a presentation in front of a room full of hundreds of people.

After looking on the Class Wiki (which holds all the blogs for this semester) and reading most of my peers initial posts I have to say, everyone seems to be really interested in POSSCON as well as working on an open source project. I do have to give +Tyler Sawyer a shout out for talking about my favorite topic, FOSS. Specifically about the difficulty starting to work on a big project when we are more secure in our old ways of working on a small project for a homework assignment. Everyone can learn from his lessons about how difficult it can be, but to not give up, for the benefits outweigh the pain and struggles that you may face.

Talking about FOSS I'll just throw up a video clip from the movie RevolutionOS (Which we should watch in class *cough cough*), where Bruce Perens talks about free and open source software. Specifically he talks about the (at the time) 9 rights (now 10 rights). The 10 rights of open source spell out the ideals of the open source movement including the idea of "copyleft", the opposite of copyright. I'll talk more about my thoughts on copyleft as well as open source in general thought the semester, specifically when I talk about Eric S. Raymond.