Honesty & Lessons at the VBC

For the past 15 weeks I've managed to not write about one of the best learning experience I've had in my college career: developing a game, full-time, with twelve other students. I'm disappointed in myself, but to be fair, this semester has been kind of a blur. Commuting an hour each way every day and working on only one project this semester —no standard classes, no homework, no tests — has been a mentally exhausting process. It has been challenging, but it is a near perfect conclusion to my time at Ball State University, and I'll look back on my time at the Virginia Ball Center very, very fondly.

I sat in my car after quittin' time one day this past week, soaking it all in. It's hard to believe that soon I will graduate college and dive into the new job, my wife and I will move into our first home, and we will welcome our first child into the world. It all has come so quickly, and I've tried to absorb as much of it as I can, even if sometimes it feels like I'm trying to grab a hold of a passing train.

 With production of the game complete, the members of Root Beer Float Studio took an academic look at what we've learned this semester. Many, many concepts were mentioned during our time-boxed 50 minutes, the topics ranging from technical skills to the more transferable skills, such as communication and commitment. All of the students took different things away from this experience, which is one of the great things about the teaching capabilities of what Ball State calls "Immersive Learning": a group of people can take part in one project, but come away with wildly different skills and abilities.

The four graduating Computer Science students involved with the project, including myself, discussed what we took away from this semester. One of the bigger pluses of this experience was being able to have a real-world software development experience without the fear of financial repercussions for failure. We also noted that we learned a lot about ourselves; I, myself, learned as much about what makes me tick as I did about C# or test-driven development. Speaking of TDD, we noted that at a point in the semester we, as a group, abandoned it. Much of that had to do with the Unity3D environment being a pain to test, but the four of us agreed that we would be more vigilant in our professional careers to hold true to best-practices. It's great that this experience has us asking these questions, questions of professionalism and commitment.

 This morning I was reading a blog post by Jeff Atwood, titled Trust Me, I'm Lying. In it, he talks about absolute honesty as a way of avoiding white lies and building stronger relationships. As I was reading his post, I realized that I could generalize nearly all of my non-technical take-aways from this semester into a single word: honesty. Being honest about commitments that I don't truly plan on fulfilling, being honest about what I think of the music in the game, being honest about how someone isn't being accountable: these all are areas that absolute honesty could have benefited the project and the people working on it. Sure, it helps to tell white lies to avoid hurting feelings, but I wonder if being 100% truthful would've avoided some of the pitfalls we fell into.

There are a lot of life-long lessons that I've learned this semester, most of which I won't even realize for a considerable amount of time. I know this semester has prepared me well for the demands of full-time employment, such as what 40 to 50 hour work weeks feel like. I've experienced hours of sitting in front of a work computer, as well as stressful team collaboration, but I've come through the other side a stronger person. If you would like to read more about the game(check out the team blog!), or even play it(!), check out this page:

Design an Exhibit home page.

An Afternoon with Version Control

I've had a few interviews that have stressed introductory-level concepts, such as data structures and algorithms. It has shown me how in the past couple of years I've gotten out of practice with some of these ideas.

With that in mind, I decided to write a few of my own data structures. My thinking was, by implementing my own I will be more aware of how lists, maps, and others really work, which would allow me to make good decisions as to which one to use when problem-solving.

I started writing my own List implementation, but I realized I was doing things wrong.

First off, I implemented without much of a plan, which wasn't really a huge misstep, but I realized that I could use this opportunity to practice some test-driven development. So I wrote a few tests and worked on getting them to pass.

I realized my second mistake immediately after: I didn't set up any version control. I had been hacking away and I went to commit my code, but I realized I couldn't. So I stopped and backed up.

Setting up a repository took longer than I thought it might, mainly because I've never really set up my own. I've used BitBucket before, so I went there and made my own repository. I tried cloning it, which I could do easily enough through the Mercurial Eclipse plugin, but I couldn't create files; Eclipse screamed about how "the source folder is not a Java source folder." I looked at it for a bit and was somewhat stumped.

Instead of solving that problem, I thought perhaps I'm doing things backwards. So I looked into creating a repository locally and pushing that. I searched the internet about how to turn a project into a local repository and found TortoiseHG Workbench. After installing it, all seemed to be going well, until I tried to push changes. Nothing seemed to be getting pushed, and the BitBucket repository wasn't being updated. The error I was getting was pretty vague ["push aborted, ret 1"]. I'm sure it was user-error, but this path didn't seem to be getting me any closer to my goal.

Hmmm...

I backed up and went to the Mercurial wiki and found the help I needed. It looked like I would need to use the command line, which worried me slightly. I haven't had a great deal of experience utilizing terminal commands, but I figured out what I needed to do and successfully pushed a few changes.

To summarize:
Before you can commit anything, you should set up the URL of the repository in the .hgrc file. Per the recommendation of the tutorial I was following, I set up my username and repository location as follows:

[ui]
username = Josh Hurst <myEmail>
[paths]
default = https://bitbucket.org/..../

Then, I performed the following:

1. via the command line, navigate to the project folder you wish to have as your repository 
2. execute hg init
3. execute hg status, which shows you which files have not yet been "added" to the repository
4. execute hg add, adding the files to the commit
5. execute hg commit -m <Insert your commit message here, exclude angular brackets>
6. execute hg push, which will push to the URL you've provided

This is one of those things that once you do it, it's much, much easier to do again. I'm probably not using all of the features available to me, but setting up my own sandbox to commit things and have access to them, regardless of my latitude and longitude is awesome.

Hopefully as I work on this, I can get some experience with the terminal. It's an area where I can grow as a developer, and my inexperience with it shows how I grew up using GUIs (Windows 3.1, Win95, etc) and not the command line. It makes me wonder how the next generation of technology users will fare due to the huge push toward touchscreens and tablet PCs.

I Programmed Today

Despite having no homework, tests, or commitments outside of class, I've found it difficult to make time to write this semester. The type of thinking I do most days leaves me drained, and whatever energy I have left is typically zapped by my evening commute home.

At any rate, today was such a good day that I can't help but write a bit. I'm working on a project at the Virginia Ball Center, which has been a very rewarding project. I've had the chance to work with some quirky, brilliant people. As a group, we've been doing game design and internal play testing for the better part of two months. Game design uses a part of my brain that I find very taxing, but today was a bit different.

As our project moves away from game design and into software design and development, I get the chance to actually write software. I'm not resentful for things taking as long as they have; at any point, I could have said,"I don't feel like prototyping any more, I'll just write some code." But I feel that I have a good idea as to the creative direction that the game is going in. It wouldn't be fair to drop someone else into this role, I have too much momentum to do anything other than hashing out game mechanics,IMHO.

With most of the game designing done, I was able to focus some attention today on a programming task. I jumped into things via pair programming. I navigated, while a team member steered. We employed the builder pattern for the section of code we were working on, which I had not had the chance to work with yet. Today was also one of the first chances I've had to make use of some of the concepts within Clean Code, by Robert Martin. The Computer Science students within the team are reading through this book together, and we've all found it very informative.

Once our code was refactored and we determined that no code smells permeated the air, it was lunch time.  After some discussions around the dining room table and our respective meals, the Computer Science students involved with the project came together and put in some really solid collaborative work regarding use cases—something none of us were proficient with yet.

Overall, the project is beginning to really come into focus. The game is taking the shape of a game, and it's hard not to be excited! Throw some gorgeous leap-year day weather into the mix and it's easy to see why today was so great! I'm looking forward to the lessons I'll learn and the tools I'll pick up in the next two months.