Code School – Postmortem – Part III

Picking up where the last post left off,  our second month introduced the group project work.  Rails and Ruby continued to be lectured on as well as general programming topics, but I think the important thing was that  the students self organized into groups after choosing from project proposals and began to work on delivering them in a short time.  This was exciting to  me because delivering functioning code that someone else asked for was the name of the game and learning to work within a group is a key skill for a developer.  You’ll rarely be a total “lone wolf” working as a professional on a dev team.

Gradual Release of Responsibility:

The idea of agile development came into play as self organized groups took focus away from a strict lesson plan and our first gradual release of responsibility took place.  Coming into the program as a non-advanced student I think at this point I would have preferred more guidance, but others also seemed to thrive when allowed to go their own way with their use of their 9-5 office time.  The key to staying focused was that a lot of the resources I was using already framed out a relatively straightforward learning plan that I could continue to execute, without them I think I might have flailed a lot more.

At a certain point however, what we wanted to focus on became more clear as what you tend to spend more time on you tend to get better at.  Subconscious specialization if you will.  The Development of Discuss-it was the breakthrough moment for me.  Walking through the project from wire frames, mock-ups, and white-boarding to a feature complete app that is working and hosted.  Built with a team and delivered on-time(ish).  It also focused me on Rails and Ruby in a way that theoretical study couldn’t have.  For a lot of the same benefits working through Hartl’s Rails Tutorial is fantastic and a great primer.

This is also where a lot of the value of the code school was for me: surrounding myself with enthusiastic people who I could collaborate with like this and who were at a similar skill level was absolutely crucial to building up my competency and giving me confidence and motivation to continue.

Company Tours:

The time continued to fly by and now we were starting to tour local development companies (and dev teams of non-development companies) through PCS.  This was another great aspect of the code school that I think was key to job hunting success later on down the road.  We toured a whole lot of very cool companies including: New Relic, Elemental Technologies, and Dark Horse Comics.  We were able to ask a lot of questions about the practical day to day aspects of development work and about what me might need to do to better prepare ourselves for a position at one of these cool local companies and build up contacts for future networking.  This part of the program was invaluable and led directly to my first official Developer job right after the program finished.

End Run:

In the last month we experienced another gradual release of responsibility that made essentially all of our class time our own apart from what we scheduled with our instructor, Chuck, ahead of time.  This was both my most and least productive period of learning.  I fell down several rabbit holes, set learning goals I didn’t accomplish, but also learned about tech I didn’t expect to (MongoDB, AngularJS).  I also began work on a group project that did not manage to get off the ground.  Components of it were sound and good work samples, but the project itself did not achieve its goals and that was on its own a very valuable lesson in project management.

The final release of responsibility was off course sending us off to apply to jobs, and our last week was almost exclusively focused on this.  I was surprised to find that there were at least 100 tech companies in Portland that could be a good fit for a Jr. Developer, but there were in fact that many in a list the students worked to compile and with a healthy amount of caffeine I began to carpet bomb them with applications.

I started receiving responses immediately and I literally haven’t stopped receiving them since… more than three months later.

Was it worth it?

I have finished a contract with a company I had at the top of my list to work for when graduating from PCS and have signed on for a QA Engineering position to start at the beginning of the New Year at a start-up that i’m very excited about.  You get back what you put in and I think I’ve gotten everything I wanted and most importantly built a model for my own personal learning plan for the future.  And for that my tenure at PCS was worth what I spent, the time I put in, and the job that I quit to get here.

The program at Portland Code School has now changed, new instructors and staff, new hours and I cannot say whether it still affords the opportunity I got, but I can vouch for the program I attended.

Read Part I Here

Read Part II Here

Testing http requests with VCR

Ruby Gem: VCR

VCR on Github

When working on Discuss-it the team found that testing our API http requests slowed down our testing in a big way and sometimes returned inconsistent results.  Since we didn’t want to test the reliability of our external dependencies VCR was the perfect tool to step in between our http request and our test.

What it does is create a ‘cassette’ file in your spec folder which records the first response to your http request and then on ‘replay’ when you rerun your tests it uses the cassette data instead.  If your tests are http request heavy you’ll be able to test how the requests are handled much more consistently with VCR.

 

 

 

Rails app the Second

A new group project is well underway already: a site that searches out discussions for articles and gives you back links.  We’re making a few Ajax calls and parsing some of the data and feeding it back to the user.  This version doesn’t explicitly need Rails to run an could probably have functioned just as well using Sinatra (i’ll post a little more on why I like Sinatra soon), but its a good exercise in working with the rails filesystem and dealing with its idiosyncrasies.  You should see the final website version of the app posted on the portfolio page very soon.

Step two is to wrap it in Javascript and make it into an site pluggable button, but one thing at a time!

We’re using a lot of cool little gems that i’ll write a little bit about in the next few days, so stick around.

First Rails App

At this point it appears i’ve got a few “first” apps in progress.  One from Hartl’s Ruby on Rails Tutorial and the other a group project.  My group consists of Erica and Lucas from the current Portland Code School cohort.  We’re building a discussion finder, which takes a URL and spits out a discussion about that particular URL on one or more sites.

I’m pretty excited about having a functioning rails app under my belt! I’ll throw it up in the portfolio soon.

Rails against the machine

The dive into Rails has begun during week 5 at Portland Code School.  Sinatra, ActiveRecord and other complimentary technologies are filtering in to our brains.  So far i’m enjoying the division of labor between the different components of web apps we’ve looked at.  I may just be grokking a little more than I used to.

We’ll be plodding through a lot of different resources in the coming days including:

Ruby on Rails Tutorial

Treehouse Rails track

Rails for Zombies

My body is ready.