MakerSquare is Over!

Friday was my last day at MakerSquare. I’ve never learned so much or worked so hard as I did at MakerSquare. The staff are amazing, the students are dedicated, and the curriculum is top notch. I’d recommend it to anyone. Now my job search begins? Any takers?

In the meantime I’m continuing to learn, spending a few hours a day applying/searching, and the rest programming. My current task is to learn node.js. After that I might dive into angular. There are so many technologies out there it’s hard to decide which I should get into next! I’m also looking into ways to expand my projects. I recently filled out an application that required learning a bit about PHP to try. They had an application that was broken which once fixed would allow you to send your application through it. Having never touched PHP/laravel I thought I might be screwed but I managed to get it working. During this I realized – Hey! – the PHP framework laravel uses something similar to ActiveRecord called Eloquent. Maybe I can adapt my visualizer to work for both rails and laravel? I’m going to look into that today.


Crazy Graphs

With the first project relatively completed, I set out to come up with another idea. First I looked into phaser.js, a game framework that would hopefully allow me to create a simple game. I messed around with that for a day and decided I wasn’t going to make anything impressive game-wise in two weeks. I needed a better idea…

After scouring the internet I came across a post someone had made suggesting that github have a function to generate UML diagrams for each project. I also thought that was a great idea, but probably a bit too tough for one guy to tackle on a short time-frame. It did lead me down an interesting train of thought though. What if I could visualize how a rails project’s models interacted? What if I could do this with simply the repository’s URL? The premise is this: given a rails project github URL, scrape the website to gather the necessary data to generate diagrams representing the relationships between models (and their table schemas!).

After much headbanging I was able to get a working prototype. I used Wombat, a web scraping gem to gather the necessary data, and then I properly plug that into a ruby gem for GraphViz, a tool that allows you to create graphs.  The end result is something like this:

Screenshot from 2014-11-02 17:25:35
That graph is what it produced when I gave it the URL to my previous project’s github. It’s small and pretty! All the relationships are accurate! Hurray! Better yet this image is an SVG, which allowed me to add more information upon hovering over a node. That information is the database table’s schema which I also scrapped down using wombat. These are just screenshots so it won’t work here!

A gem that surely does a better job at this is rails-erd, but mine lets you do it with simply a github URL rather than installing a gem. This lets you easily see what other people’s projects look like, which has been pretty interesting. Here’s what it outputs when I give it Citizenry, a large open source project.

Screenshot from 2014-11-02 17:37:57

Now that is looking a bit complicated. I need to make more tables… my projects are not crazy enough! That’s a level of complexity hopefully someday I’ll get into. As you can see there are some relationships I haven’t quite figured out the best way to represent yet. In this picture you can see the uncolored circle as one of these. It makes sense I guess but this might not be its final form.

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!

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.