Down to Business

It’s that time. The final four weeks have come and we’re about to begin our final projects. Each person must have an individual project and a second  (or third) project which can be built in teams.

For my individual project I decided to make a tournament web app with social features. The idea is that you can setup a group, for instance “My College Buddies”. In that group you can have a bunch of tournaments and track the stats of the users on a per group basis. I imagine this could come in handy with various gamer circles throughout the world. I knew people in college who would play Super Smash Brothers every day with the same crew of people and I bet they would love the ability to track their stats… and bring some legitimacy to their trash talk. At the very least, its something I’d want to use to catalog my ongoing series of Mario Party 2 games and especially with the upcoming new Smash Bros that comes out next month.

I’d like to incorporate the steam API to pull in steam groups, allow you to login with your steam account, and automatically be enrolled in all those groups on my app. Then steam groups can have their own tournaments and stat tracking! How neat that might be. That will probably be tougher than getting the core functionality down, so who knows if I can make this happen (or if it’s possible. I have not looked into the API yet, just came up with this idea).

Another tack on feature might be a twitter bot that tweets victories out into the the twitterverse proclaiming victors to the world… and maybe shaming losers depending on your how your group feels about that

As for the second project, I still have no idea what I’m doing. Darrell and I are the resident science nerds of cohort 9 so we decided to look into various genomics APIs. We’re trying to come up with something interesting and within our skill set. That limits it down to maybe pulling some cool data and visualizing it… but who knows. I just love science so reading about these APIs is cool even if we can’t find a use for them!

Advertisements

Ruby on Rails and Design Principles

Rails week is upon us.

After being told endlessly about the wonder of rails for the past several weeks I was eager to get going with it. I’d wondered why it took so long for us to get into such an important topic, but I can see now that everything we’ve learned has been preparing us for this point. The concepts we learned with sinatra, active record, and building out our own MVC in javascript have prepared us perfectly for rails which is a conglomeration of these topics. I don’t expect to ever build out my own MVC for anything ever again – there’s frameworks for that, but the lengthy (and difficult) experience drove the topics home and made me appreciate the tools available.

Recently I’ve been reading and watching videos about software design principles. So far I’ve really enjoyed reading Practice Object-Oriented Design in Ruby: An Agile Primer. It’s amazing how much more readable (and more importantly extensible and maintainable) I feel my code has become. Keeping a few solid design principles at the forefront of your mind can make a big difference. Do you see what I did there? I haven’t had to make sense of horribly written code just yet in my career but I hope to avoid inflicting that fate on others.

Hackathon, Ping Pong, and brain overload

Four weeks later I come back to you! It’s easy to get caught up in the experience and forget to write blog posts. Four weeks have passed and I’ve learned so much. The biggest topic of the past two weeks or so has been javascript. I’ve gone from total noob to somewhat competent in some realms of javascript land.

Today we began our first hackathon. We formed groups of 2- 4 and each set out to bring our idea to life… in 36 hours. Next Friday is the cohort nine ping pong tournament so we decided we’d create a web app for that. I’d say we are ~75% complete at this point and we need to present by 5pm tomorrow. We’re in a good place I think.

We created a database using ActiveRecord and postgresql which allows us to store play names, match outcomes, tournament outcomes, and calculate various statistics based off of these. We currently have an eight player bracket available, which allows you to click on the winner of each match and then progress the tounament to the next round. These clicks will cause an ajax post request to our sinatra server which will then update to track victories as they occur.

We still have a few kinks to work out, as well as various ideas we could flesh out further. We’d like to add the ability to add pictures to users and have them go “head to head” in a matchup, during the match. Maybe we could display that on a projector in the background of the match. I think that could be pretty entertaining. Hopefully we will have the time to get some cool things in.

Days 3,4

Day 3:

The morning started off with a bit of review on ruby classes. We had a short assignment where we created a cars class and various subclasses. Next we started a fairly large project in which we had to create a library , book, and borrower class and create a functional library application complete with various methods you might expect. We had to write tests for each of them as well. What we didn’t finish was assigned for homework and we went to lunch.

When we returned we began an algorithms unit. We learned about the internal implementation of the ruby array class and why certain methods have longer run-times than others. This was used as an example to introduce us to Big O notation – a way to describe the speed of an algorithm. We did two sets of algorithmic problems and had to give the Big O notation of each solution.

I’ve always liked doing algorithms. Once I figure out a complex problem I definitely get a rush of euphoria. It’s like I’m winning a game! If back-end is where the algorithms come into play I’m pretty sure that’s where I’ll end up.

 

Day 4:

In the morning we went over solutions to all of day 3’s projects. It is interesting to see how a bunch of different people attack a problem. Some were similar or nearly identical to my own whereas others took a radically different approach. I guess this is where the art is in programming.

In the afternoon we did a exercise on test specification writing. We were given ten methods which were relatively simple to write and had to come up with the necessary tests. For testing we have been using rspec. Some of the methods had curve-balls which required a bit of research on rspec to figure out. By the end I had a decent grasp on rspec and had learned some of the finer points of its functionality.

 

 

Day 1,2

Day 1:

Upon arrival we were each assigned to one of three tables. Apparently they put a lot of thought into composing them. I’m curious what went into that. At my table I was surprised to see a familiar face – the guy that interviewed me for MakerSquare! Apparently he was on the entrepreneurship side of starting MakerSquare and now he wants to go through the program he helped create. We did some introductory activities and then jumped straight into some exercises on ruby data structures. Towards the end of the day we were given a fairly challenging text parsing problem. Time ran out and we were asked to finish it for tomorrow.

It was at this point I was convinced that this a good decision. The difficulty of the problem was on a similar level to some of the computer science homework I had done to get a CS minor. They are not messing around. Neither are the students. Everyone is smart and driven – it’s an amazing environment to be immersed in.

Day 2 :

We dove into a lesson on git and github – the version control system of choice. I had used git/github during the prework, but never really grasped what exactly I was doing. One well designed lesson and a few hours later I felt I had achieved a significant leap in understanding.

In the afternoon we switched gears to unit testing. I was pumped. Programming job posts always want you to know unit testing. I’d never touched the idea in any previous coursework and felt it was a big hole in my understanding. There was a lecture about unit testing and then we jumped into exercises. We had to write the tests first – this is a technique called behavioral driven design. You write the tests first to get an idea of what you want to happen – then build out your actual code! I found it to be pretty useful.

 

I’m going to MakerSquare!

Next week MakerSquare’s ninth cohort begins – and I am a student!

The past few months has been whirlwind of events for me: I graduated from university, decided against trying to go to graduate school, instead chose to switch gears to programming, applied to MakerSquare, got accepted, moved from Iowa City to Austin, and have spent endless hours on the prework and other online resources learning Ruby/JavaScript/HTML/CSS.

I’ve also been trying to squeeze in some adventuring in Austin. I went kayaking, checked out the amazing Alamo Draft House, hiked around the greenbelt, and went to Blues on the Green. Austin really is awesome (minus traffic). It’s easily my favourite city, and I live there – how convenient!

Next week my quest to become a developer enters the critical stages. I will become one with my computer chair(s) and master the arts of code wizardry!