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.

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.

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.

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.

The Programmers Wall

I have noticed lately that during the course of a programmers education they hit a "wall" of sorts. This proverbial wall that everyone hits makes or breaks the programmer. THIS is the moment that you can do something to change their life. Will you help them and keep them interested in programming, or will you watch them struggle as they decide to quit programming forever. I know what I would do (and have done in the past).

This "wall" is normally hit after a few different things are learned. The "Small Wall" is the first hurdle into computer science. This wall is normally during the students first few weeks when they are learning program flow (If, Else, Loop, While, For, Case, Function Calls). This wall should not take long to get over, otherwise you might want to be concerned about the future of that persons career. The normal ways of getting over this hurdle is to force the person to sit down and get them to experiment with flow control (you will notice a pattern with my solutions, they all include this step). Show them on paper how the program will run through a loop. Get an IDE that shows the flow of a program (Dr. Racket does this pretty well if memory serves me correctly). This wall isn't one you will see outside (very often) of academia (unless they are just getting into programming).

The second wall I normally see is the "Medium Wall". This shows up during a paradigm shift (Scripting (Python) to Object Oriented (Java), Object Oriented (Java) to Declarative (Logic based ones like Prolog)). Normally during this time the specific parts of the language make people frustrated, and they might entertain the thought that can't keep up with their peers (who look like they are excelling). This is the most common with programmers who are 2-5 months into heavy programming. The reason for this is that this wall seems larger depending on how many paradigms the person has learned/faced before. If this is their first shift (normally into OO) they will feel more pressure/stress. Again the first step to help them is to sit them down and make them experiment with (my OO example) Objects. During this step I normally give them examples of real life problems, and how I would make it into a program. My default example is a card game. Explaining how Cards can be an object that Deck holds. And how Hand can interact with Deck by drawing cards and replacing them seems to help them wrap their heads around the idea of OO pretty well.

The third wall is (as you might have guessed) the "Big Wall". This is a wall that you will forever face. The question you face is "How do I become better at my craft". You can never be perfect at the craft, there is always room for improvement. The question that everyone will ask themselves is "How do I go about doing that?" The way that I try to get better is to force myself to work on something I normally wouldn't have, look at different paradigms, do programming competitions, read historical and recent texts (Pragmatic Programmer, Thinking in Java, any academic paper based in Computer Science or Math). I also ask peers what they are working on to try and soak up knowledge. But I think the best way of improving your craft is to work on projects. Pick up anything from another project at the office, or work on an open source project that you use on a regular basis. Eric Raymond actually covers this part pretty well in How to be a Hacker (You should also read his other stuff like The Cathedral and the Bazaar By Raymond, Eric S. (Google Affiliate Ad)).

Right now I'm still trying to study these walls that I have noticed, and looking for more literature about them (if they exist). I am wanting to do my Bachelors Essay on how students learn and what we can do to help them if they ever get stuck.

Here are some links to books/movies that I would recommend people to read and watch (especially some of my fellow students).

• Revolution OS (On Netflix I believe)
• Godel, Escher, Bach By Hofstadter, Douglas R. (Google Affiliate Ad)
• The Mythical Man Month
• Code Complete By McConnell, Steve (Google Affiliate Ad)
• Any book from this stackoverflow question
• These TED talks
• And anything that you think could be relevant to making you better at your craft. (Online code practice like Code Chef and Project Euler are good places to start)

Hopefully some of my peers will read this paper and know what wall they are at. I hope that they will ask for help if they ever get truly stuck so that we keep pushing the boundaries of what is possible.