Updating Deeply Nested Attributes with RSpec

The problem: I had to find a way to test the update action that was nested four layers deep.

The solution: Create RSpecs params in a way I had never done before..

I had been tasked with overhauling the relationship between a Club and Promo (for a gym app), and because of the way a form needed to be setup, I ended up with a one-off controller bulk_promo_controller.rb that had nested attributes four levels deep. There are ways to cleanly test nested attributes, but all examples and documentation stops at one level deep, I was in uncharted territory to say the least.

To ensure you are on the same page, here’s an example of my standard RSpec update setup:

describe 'PUT #update' do
  before do
    @promo = create(:promo)

  context 'with valid attributes' do
    it 'should update the promo and redirect to the index' do
      process :update, method: :put, params: { id: @promo.id, promo: attributes_for(:promo, customer_promo_code: 'Updated Name') }

      expect(assigns(:promo)).to eq(@promo)
      expect(response).to redirect_to(admin_promos_path)


Pretty standard, heres whats happening:

process :update -> which controller action is being called

method: :put -> which type of route is to be used

params: -> params from the controller, in this case for promo

attributes_for(:promo) -> using the Promo model’s FactoryGirl configuration to update the object

customer_promo_code: -> overwriting the default FactoryGirl setting for customer_promo_code to a constant, to be able to test it.

Now, this is the bulk_promos_controller.rb . As you can see, the params include the promo , at the highest level, then the club_promos_attributes , which inherit the club_promo_plans_attributes , and that controller inherits the mms_prices_attributes, which is ultimately what I’m trying to get at.

# frozen_string_literal: true
class Admin::BulkPromosController < Admin::ApplicationController
  before_action :set_promo, only: :update

  def update
    if @bulk_promo.update(bulk_promo_params)
      redirect_to admin_promo_club_promos_path(@bulk_promo), notice: 'Promo was successfully updated.'
      flash[:error] = 'Promo was not updated.'
      render :edit

  def set_promo
    @bulk_promo = Promo.find(params[:id])

  def bulk_promo_params
      :customer_promo_code, club_ids:[],
      club_promos_attributes: [:id, :club_id, :promo_id,
      club_promo_plans_attributes: [:id, :club_promo_id, :plan_id,
      mms_prices_attributes: [:id, :payment_type, :mms_promo_code, :mms_installment_id, :mms_plan_id, :_destroy]]]

I tried to setup the bulk_promo_controller spec in a similar way to the promo controller (or any other updating action for that matter), using the attributes_for method, but the trouble was that I couldn’t burrow down through all the necessary associations to get at the proper mms_price. I don’t have examples of all the attempts, but I tried more iterations than I could count. I threw a binding.pry into the mix, to try and step through the process in the terminal, but it wasn’t happening.

Finally, I acknowledged that this was a bit over my head and requested a pair session with a senior dev. The first thing he asked me was ‘whats the readout from the server logs when you hit the controller from the web interface?’ I hadn’t even thought to check there, but it made total sense, especially because I knew the action was functioning correctly, I was essentially trying to duplicate that process in the test. (Thats definitely not the best practice in writing tests, but this has been an RSpec edge case from the get go). So, this is how I got the RSpec params for the test:

In the terminal running the local server, I ran command + k to clear the server log.

I went to my locally run browser page that had the bulk promo update action, and updated a record. Now, back in the server log, it will display all the parameters that were passed to update that mms_record.

Started PATCH "/admin/bulk_promos/394" for ::1 at 2017-10-05 11:29:16 -0600
Processing by Admin::BulkPromosController#update as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"1l+8oy6dANoziB/PZ5HpRQAAnBU8Pp7j/BIdB2NxgQcyGqpglX7tV+T/EBY5yfPGFz1bKsJPT3hWyiOqpyh5dw==", "promo"=>{"club_promos_attributes"=>{"0"=>{"club_promo_plans_attributes"=>{"0"=>{"mms_prices_attributes"=>{"0"=>{"mms_plan_id"=>"thisistestmmscontent", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2643"}, "1"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2642"}}, "id"=>"1217"}, "1"=>{"mms_prices_attributes"=>{"0"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2645"}, "1"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2644"}}, "id"=>"1218"}, "2"=>{"mms_prices_attributes"=>{"0"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2647"}, "1"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2646"}}, "id"=>"1219"}, "3"=>{"mms_prices_attributes"=>{"0"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2649"}, "1"=>{"mms_plan_id"=>"", "mms_installment_id"=>"", "mms_promo_code"=>"", "id"=>"2648"}}, "id"=>"1220"}}, "id"=>"481"}}}, "commit"=>"Update Promo Plans", "id"=>"394"}

I don’t know about anyone else, but I have a terrible time trying to read this output, so I copy/pasted it into my text editor, starting after the authenticity token . Now in the editor, I found where it started repeating, and broke out those lines. The indicators are the "id" labels, because thats what I was trying to identify, the id of the club_promoclub_promo_plan, and the mms_pricing.

I ended up with a pretty long hash (to help you read it, I replaced the random integers with the model id). The output was something like this:

{"club_promos_attributes" => {"0" => {"club_promo_plans_attributes" => {"0" => {"mms_prices_attributes" => {"0" => {"mms_promo_code" => "teststring","mms_installment_id" => "","mms_plan_id" => "","id" => "mms_price_id"}},"id" => "club_promo_plan_id"}},"id" => "club_promo_id"}}}

Using that pattern, I was able to assign the dynamic ids from the RSpec tests and place that hash (as a variable) into the params. With some formatting of that hash my working RSpec test looks like this:

describe 'PUT #update' do
  context 'with valid attributes' do
    it 'should update the promo with mms attribute and redirect to the index' do
      promo = create(:promo)
      @club_promo_id = promo.club_promos.first.id
      @club_promo_plan_id = promo.club_promos.first.club_promo_plans.first.id
      @mms_price = promo.club_promos.first.club_promo_plans.first.mms_prices.first

      promo_attributes =  {
                            "club_promos_attributes" => {
                              "0" => {
                                "club_promo_plans_attributes" => {
                                  "0" => {
                                    "mms_prices_attributes" => {
                                      "0" => {
                                        "mms_promo_code" => "teststring",
                                        "mms_installment_id" => "",
                                        "mms_plan_id" => "",
                                        "id" => "#{@mms_price.id}"
                                    "id" => "#{@club_promo_plan_id}"
                                "id" => "#{@club_promo_id}"

      process :update, method: :put, params: { id: promo.id, promo: promo_attributes }


      expect(@mms_price.mms_promo_code).to eq("teststring")
      expect(response).to redirect_to(admin_promo_club_promos_path(promo))

It’s not pretty, probably the ugliest RSpec I’ve written to date, but its functional and not brittle. I also feel like another dev could look at this test and have a pretty good understanding of whats going on, which is important. I’m open to feedback if anyone has a better strategy, let me know!




The Tail of Truncation

Last week I came across a pretty solid problem, by the time I found the most appropriate solution it had evolved quite a bit. I felt it had the making for a worthwhile blog post, so here it goes.

The problem: we need to display only the first 220 characters of the body of a Press article on the Press Index page.

Initial solution: implement Rails truncate helper. It can be used in the view, as such:

truncate(press.description, length: 220)

This worked for the first 9 items on the page, running as a standard each loop. But we are also implementing infinite scroll on this page with javascript, which renders each item after the ninth through an HMTL template and JSON. So, for the template I had to make a method in the press_serializer.rb file that looks like this:

def description

That all worked, but didn’t render well with the other styles on the page, was showing some markup tags, and isn’t the most efficient solution. So, I moved the nuts and bolts from the view to the application_helper.rb and made it into a method:

def truncate_description(description)

So now in the view it looks like this:


I also modified the method in the serializer for the html template to this:

def description

It’s definitely cleaner code in the view file, and its faster coming from the application helper.

Note that the .html_safe is necessary because we are using a WYSIWYG (What You See Is What You Get) editor to create the description, so there are potentially a lot of opening and closing of tags.

This all worked in our QA and the clients. The first 9 records were being produced via the each loop, and all the rest with the JSON and HTML template. But, as it so happened, we came across an edge case, and that was my problem to solve.

New problem: Basically, what was happening was that the clients wrote a description and included a link within the first 220 characters, which was cut off by the truncate helper. This meant that there was a tag that wasn’t closing, and it bled the link content onto the first piece of text in the next description card.

What would have been super easy was just to tell the clients to rewrite the article, and move the link. Oh, and in the future, don’t put a link within the first 220 characters, thanks! But, of course, that’s not an option. The solution seems like an obvious one, even to me as a write this, but it actually took a good bit of googling to find it.

New solution: Ultimately I ended up using the truncate_html gem for the Ruby components and html-truncate gem for the JSON components. The Ruby part can be setup like this:

Add truncate_html gem to Gemfile

Replace truncate with truncate_html in the view


It can be as simple as that, but to add some versatility I also created a truncate_html.rb file in my initializers folder:

TruncateHtml.configure do |config|
   config.length        = 220

The length could have been added to the line in the view file, but it’s cleaner to have the initializer file, and allows for growth, should any other parameters be necessary.

As for the JSON and HTML templates, after I installed html-truncate I just had to two variables to the top of the HTML template file:

var truncate = require('html-truncate');

let description = truncate(press.description, 220);

Now both the Ruby gem and JS package will close any open tags before truncating, allowing for there to be links, bold tags, or whatever at any place in the description with no problem at all.


Ask Me Anything!

I’ve been developer for nearly 4 months now, and it baffles me how hard it is to digest anything I’ve done into something I feel is post-worthy. It’s the same situation with presentations for Boulder Ruby Meetup, I just don’t know what to talk about. Don’t get me wrong, I have leveled up more in the last three months than I could have even dreamed of, but I’m just not sure how to filter that into something to talk about. I’m thinking I might do a ‘brain dump’ post, where I literally just list off all the things I can think of that I’ve come across, or gotten help with since I started, but I’m still working on that list.

One thing I have been doing in the past few months is giving advice. I’ve had people get in touch with me about various things, but mostly asking specific questions about my path from non-dev to student to paid dev. I got to where I am because I asked a ton of questions to just about anyone I could get in touch with, so I am always more than happy to do the same to anyone who contacts me. With that said, I want to be more proactive about helping others and put it out into the whole of the interwebs that I’m open to any questions from anyone about my experience up to this point. Im not claiming to be any kind of expert, but ask away and I’ll do my best to respond with helpful input.

Yes, I’m serious. To be honest, just about everyone I’ve ever encountered in this field would probably do the same, but few advertise it. And I know for a fact that a lot of people wouldn’t think to ‘cold-call’ someone they didn’t know with questions, so I’m opening the door. As a student I followed up on a strangers’ Twitter post where he offered a half hour of his time to anyone, and it helped steer me in a better direction when I was getting a bit off course with school.

This isn’t a one-way street, the interactions will help me determine what the community as a whole would like to hear more about, which will help guide me as to where I should focus future posts and presentations. And the flipside is, if I get questions I don’t have immediate answers to, that will force me to dig around and find those answers, helping with the ‘you don’t know what you don’t know’ scenario.

For the time being, let’s start off with emails. Ill try to get back to them within a few days, but who knows what might happen, so I’ll say with certainty within a week. For the sake of my spam box I’m not going to link my email, but a message sent to noelworden(@)gmail will get to me.

This is an experiment, lets see how it goes!

My First 8 Weeks as a Junior Engineer

Well, the highly anticipated My First Weeks as a Developer post is about a month overdue. This is the second time I’ve blocked out a chunk of time to write this post and I still don’t really know what I’m writing about. I’ve definitely had plenty of ‘ah ha’ moments in the last 8 weeks, and most of them a candidate for their own blog post. I feel a need to have life-changing advice or words of wisdom as a recent graduate of bootcamp who successfully found a pretty great job. The trouble for me is that my situation is just that, mine. During school I took some extracurricular actions that I thought would help me in the future, and most of them were well worth the effort, but those same actions may not work for someone else. Ive definitely used this caveat before, and I’m not entirely sure why I always feel the need to preface advice with it. But, with all that said, there are some nuggets of advice from the first eight weeks of me being a Jr Full Stack Engineer that I’d like to share.

First and foremost, it gets easier. This is definitely something that may not be the case for everyone, but for me it’s true. Just this week I’ve tackled two different challenges that I’ve been dreading since I first saw their respective tickets almost a month ago. You’d be surprised how much you know, event if you’re not that confident about it. For instance, the first dreaded challenge of the week dealt with polymorphic associations. I was dreading this ticket because I had only dealt with polymorphisms in one other instance, and it did not go very well. But that was school, and learning in school is so much different than learning on the job.

The first step I took was to look through our existing repos to find another project that used polymorphisms. I’m in a fortunate position where I work in a consultancy, so we have an extensive and diverse git repo that I can utilize. I have also honed my search skills within a repo, something that my internship helped a lot with (more on that later). So, I found a few repos using polymorphic associations and was able to see how the tables were set up, how other models were being associated, and how to produce the results in views. With this in my back pocket I turned to my mentor/team lead/boss (we are a small team) and together we drew everything out on the whiteboard.

After that was wrapped up I started building. I took the rest of the day and built out the table, associations, and the logic to produce the data in the views. The logic was a bit clunky, and I knew it would need to be refactored. But instead of asking how it should be done, I decided to keep pushing on and get it reviewed afterwards. I feel like this shows initiative. Its pretty easy to just ask questions and get the right answers. But chipping away until you have even the crustiest of solutions, then asking for reviews better shows your strengths and weaknesses and that you are accepting of critique. This will make will help you level up faster.

Before the end of the day I got a review of the logic code I had written, and in less than 20 minutes we refactored it down from 9 lines to 3 and with about 20 percent of the original database hits. And that was it, I had tackled polymorphic associations in one day, with almost no banging-head-into-keyboard moments. I solved the problem at hand, and when it comes up again I have working code, written by me, to use as a guide. My original experience with polymorphisms in school kicked my ass for 3-4 days and ultimately my mentor ended up walking me through the process.

That work day was one that I tallied into the win column, and I have already lost count of how many days like that I’ve already had with this job. There are a lot of events that set me on the path to have successful days like that, both in school and out. I think that the internship that I worked while going to school has payed off exponentially. I picked up so many real world developer skills there that school just didn’t have the time to even touch upon. I don’t have any major issues with my school, but at the end of the day it’s a bootcamp, and the point of almost every bootcamp is to give you just enough skills to get your foot in the door as a Junior Developer. The internship helped me refine my git skills, gain more experience working in a collaborative environment, and work with existing, dated, codebases. I can’t recommend an internship highly enough. Even if you feel you’re already maxed out, carve out a chunk of time and get some coding experience outside of your current school or bootcamp, it will pay off.

The type of work environment you end up in is also a huge factor in being a successful Junior. One of the first questions I asked when interviewing was if they had hired a bootcamp graduate before. In my case they had, three, in fact. So my followup question was what kind of mentorship program they had in place. They didn’t have a set mentorship system, but were adamant about their ‘ask anyone anything’ policy, which seemed pretty good to me. This may seem like a given with all companies, but I’m here to tell you that it’s not. There are plenty of companies that hire Juniors because they can get them cheap, then throw them in the deep end with no mentorship and expect them to perform. Some people fresh out of school can rise to the challenge, some can’t. I didn’t want to be in that kind of working environment, so I made sure to ask.

The first few weeks as a Junior were a bit nerve wracking, but positive nonetheless. Once I found my rhythm I started noticeably leveling up, little by little every week. Four weeks in I was made part of a new team, given a fresh domain, and tasked to build out the entire database and a bit of the front-end. Initially I was super nervous that my superiors thought I was a better developer than I actually was. But four weeks in, with three weeks left in the project, I’m knocking out tickets like its cool and feeling confident about being able to make the deadline.

The bottom line, at least as I see it a few months out, is that if you set yourself up right, code school is probably as consistently intense/chaotic/emotionally draining as it’s going to get.

Config files > Github

I’ve been at my new job for two weeks now. Im learning a ton and really enjoying it. But this post isn’t about that. I’m going to give it a few more weeks until I write the to-be-expected My First Weeks as a Developer post. Instead, this post is a quicky about how to setup all your dev application config files with Github so that they are never lost, always updated, and able to be pulled down onto a new machine from anywhere.

The philosophy with all my personal electronics is that everything should live somewhere other than the device. It was more work a few years ago to make that happen, but with high speed internet just about everywhere and cloud storage dirt cheap its really not that big of a deal. Right now I could drop all my devices into a river, walk into an electronics store, buy new ones, and in about 10 minutes be back up and running as if nothing happened. Its nice peace of mind to have.

Before I started my new gig, I completely wiped my laptop and installed a fresh OS. After that process I started wondering what the most efficient way was to keep all my developing application (iTerm, Atom, VIM, etc) config files backed up so that I never had to worry about losing all their respective customization. Initially, I just found the corresponding files and pulled them up to my Google Drive. It wasn’t efficient, but at least they were up in the almighty cloud.

After a few iterations of manually pusing individual config files to my Google Drive I figured that there had to be a better way. I mean, at that point I had pulled down three different repos for work and made more than a few branches and commits on each. Surely if I could pull down and push up that kind of info I could do the same for my config files. It took all of 30 seconds of searching to find the right article:


Definitely take a look at the article, but the gist of it is that you git init your entire root folder, then add all the files to .gitignore, the pull out the ones you want, the config files, then push them up to a new Github repo. Easy peezy. And, when its all done, you can rest assured that all the sweet customization you’ve done to your workflow will never be lost. Along with the above link, Ive also created a Github Gist outlining the process and highlighting which config files I backup, that can be found here: https://goo.gl/pV2Wdc

The Hustle

Oh man, it’s been awhile, longest lapse in posts I’ve had yet! Well, I have a pretty good excuse because I GOT A WEBDEV JOB! The ball started rolling shortly after the last post about being a ‘Yes Person’ and I thought it would be worth holding off on a new post because the lead I had was pretty promising and this would be a great follow-up post. I’ll give a rundown of the series of events that lead up to me receiving the job offer, not for any horn tooting purposes, but to show how my approach to school, extra-curriculars, and being a ‘Yes Person’ all lined up to get me a job before I finished the Bloc program. I’m not implying that this is the only way to go about it, but it did work for me.

The initial job posting was pretty unofficial. It was a posting for a Junior Full Stack Engineer on a jobs whiteboard at a the Denver Full Stack meetup. I hadn’t even attended this meetup yet, but it was on my radar. I had the meetup in my calendar, and was following it on Twitter. They posted a photo of the jobs whiteboard and I picked out the open Junior position pretty quick. You don’t see those very often, so I pounced on it and started putting together an email.

I started off with the questions I had about the company. It was based in NYC, so I was curious if they were looking for a remote dev or starting a shop in Denver? I also asked things like what tech stack they use and if they’ve ever brought on a Junior before? I feel like opening with questions is important. Its starting a conversation, not just asking for a job. I sent that email before the Thanksgiving holiday, so it took a bit to get some back and forth going, but pretty quickly he offered to meet with me if I had the time. This was the best case scenario, to be able to meet with a potential employer in person and not have to sell myself with emails and resumes alone. The meeting came with one caveat, by this time an offer had been made to another developer for the position, so there was a good chance that the position may not be available anymore. It was a no brainer to meet with him anyway (this goes back to being a ‘Yes Person’; only good things could come from meeting with someone in the tech industry).

The meeting went well, and the next day I was on a Google Hangout with the NYC-based CTO. At the end of that meeting we were scheduling a time to have a technical interview the next day. Three rounds of interviews in three days. I don’t know very much about that part of the industry, but I know that’s not common. I was obviously a bit nervous about the technical interview, but I was told that there would be no code challenges, only me talking about the projects I’ve been working on. Again, absolute best case scenario.

I don’t think I necessarily knocked their socks off with my projects, they are pretty boilerplate code school stuff. But where I do think I was able to shine a bit was with my personal project, which I talked about a few posts ago (http://noelworden.com/2016/09/18/bloc-week-28/). I explained that the goal of AdventureSearch was to give the user the most information with the least amount of effort. I talked about my U/I choices of a simple interface and gathering the user location with the GET request and not through the gps functionality of the browser. I also spoke about how I leaned heavily on ruby gems and APIs to make a powerful app with minimal written code. I was trying to convey that I could think like a developer outside of the school structure.

Well, it all worked. I got the job offer, accepted it, and have completed my first week of work. I had some theories about what I would have to do above and beyond Bloc to get a job, and in this case I was successful. I’m not sure if someone following in a similar path would have the same results, I’m also not sure even I would have the exact same outcome if I were to do it over again. But, in this case it worked, and for the time being that’s all that counts.

There were three particular things that all added up to get me to this point, I’ve touched on all of them at one point or another, but for the sake of thoroughness I’ll list them off again:

Pushing job postings to me
I had every source I could find pushing jobs to me. Slack channel alerts, twitter, builtincolorado, meetups, all pushing info to me to then filter through. It was a much more manageable process than digging through pages of classified postings

I cannot emphasize this enough. In a roundabout way is was my network that got me this job. And in a very direct way is was my network that helped walk me through the interview and job offer process when I had no idea what I was doing.

Personal code project
I can’t say with absolute certainty, but I am pretty confident that my personal project (of which I only wrote a total of 200 lines of original code maximum) is what got me this job. Start a personal project. It doesn’t have to be complex. Just find something you are passionate about and start tinkering.

When to be a ‘Yes Person’

For the most part, being described as a ‘Yes Person’ is not a compliment. If you see yourself as a self-motivated, grab-life-by-the-horns type of individual, it’s the last thing you’d want to be labeled as. But, as is the case with many things, there are exceptions to the rule. For almost a year I have been conducting an informal experiment in one particular area of my life and saying yes to any and all opportunities that cross my path in the realm of web development.

I decided to start down the path of becoming a web developer roughly a year ago, and as part of my roughly outlined plain, I decided that I would pursue and make time for any opportunity to meet with someone on an individual level. I was specific about the ‘individual level’ part of it because I’m not exactly a social butterfly, and I know that dropping into bigger events where I know absolutely no one is not a good fit for me, and not a productive use of my time. For the last year I have taken advantage of every opportunity to talk to fellow a developer, pair program, have code reviews, or anything else of that nature that comes my way.

The meeting of people was a little slow at first, one caveat that I’ve mentioned before about learning with an online program is that it severely lacks a person-to-person community. You can only do so much with Slack. To supplement this, I started attending meetups. Initially I went to any and all meetups that piqued my interest. This was good to see what all the meetups had to offer, but attending multiple meetups a week was absolutely exhausting. I narrowed it down to two meetups a month, which may not sound like a lot, but with everything else I have going on, even one every other week is a lot.

Meetups are a great way to meet people. You know that you already have two things in common, the tech stack that the meetup is about, and the fact that everyone attending likes that stack enough to talk about it outside of work/school. Almost everyone I regularly keep in touch with has come directly or indirectly from the Boulder Ruby meetup. Another great thing about meetups is that if there’s not one that fits your particular interest you can just start one! I know I’ve written about this before, but starting a meetup that better fit my interests (beginner level developing) has been incredibly beneficial to my networking and web dev skills. It takes a lot less effort than one might assume, and once it gets rolling there will almost definitely be someone attending that can be coerced into helping plan future events.

Meetups lead to meeting a lot of different people, and those people know other people, and on and on it goes. If I have a great conversation with someone at a meetup I make it a point to try to meet them again on a one-on-one basis. It could be for any reason, I almost never have a prerogative when meeting with someone. I’m not meeting with them to ask about work opportunities, or how they could directly benefit me, but instead to learn more about them and their journey with web development. It always leads to interesting conversations, and sometimes to potential opportunities, but it does that naturally, not because that was the goal of the meeting.

If you can’t carve the time out of your schedule to make it to meetups you can utilize other resources like Twitter and Slack. It can take time to aggregate the right industry people to follow and the best Slack channels to be a part of, but both are super useful services when utilized correctly. I’ve had remote chats with seasoned professionals on the other side of the country because I stumbled across the right tweet. And I’ve had more than a few in-depth discussions with people on local Slack channels that I’ve then followed up with in person.

Following up is a huge part of the process. It might seem super obvious, but after being in the position to hire freelancers in a different career I was shocked at how many people didn’t follow through after a conversation where I basically told them the work was theirs. Just follow through, it’s super simple, and I can almost guarantee that if you do it you’ll be in the minority.

Over the past three months I have met with an average of one new person every week. That means I’ve spoken to at least 12 different people and have heard 12 unique stories of how they got to where they are, the speed bumps they encountered had along the way, and the lessons learned in the process. That’s incredibly valuable to someone like me who is trying to break into the job market with a ton of other junior developers. Ive basically learned from the mistakes and success of 12 different people. That makes for a huge chunk of experience that I don’t have to learn the hard way, on my own. It’s almost like pushing a fast forward button my career.

This whole thing is an experiment, and its not ‘complete’ yet, and it may never be. I’m still in school, have only recently started to actively pursue a job, so I can’t say that this networking experiment was the magic key that landed me a kick-ass developing gig. But I can say that I like my current trajectory and I’m confident something good is right around the corner.

PS – For the sake of consistency with the blog formatting, this post is for weeks 36 & 37 of school with a date range of 161007 – 1611210

Weeks 33 – 35

161017 – 161106 — Total classroom hours – Stopped counting

Well, not too long ago I said I wouldn’t let the blog go more than two weeks without a post. I’m not going to go back and count, but it was probably less than two months ago. So, I didn’t hold true to that very well, but better now than never! I’m not one for excuses, but it definitely didn’t help that I didn’t really feel like I was kicking ass in anything, but at the same time still felt incredibly busy. I did reach some high notes at the end of this week, so that was a good morale boost.

We had our first retrospective at my internship. Scheduled retrospectives of some sort was a prerequisite for my accepting the internship position. He was all for it, so it’s not like I had to fight for it, but I wanted to know that I would be getting and giving feedback to ensure forward progress for both of us. Up to this point the internship didn’t have a whole lot of structure. What I mean by that is I never really knew what we were going to be getting into during each meeting. That, coupled with the fact that it was running on Rails 2.x, and that the codebase was pretty crusty (as my mentor willfully admitted), all made for a learning, but not super productive experience. During our retrospective we discussed this and decided that working on a different codebase might benefit both me and him more.

This new project is a current codebase, Rails 4.2.5, has a full Rspec test suite, and is much less crusty. During the retrospective we decided that we should try me working on my own more, for many reasons, mostly to force me to dig through tough problems and make decisions based on my best judgement. I was a little hesitant at first, thinking it would take me hours just to decipher what was being asked of me. But I sat down on Saturday and looked at my Pivotal Tracker user story and started to chip away at it.

It felt really good to be working through current Rails again. I’ve been working all front-end with Bloc, and old Rails/JS with the internship. This felt like seeing an old friend again. I took about 30 minutes clicking through the file tree to get an understanding of what was going on, then tackled some routes and fresh .haml files. What’s nice about working on an existing codebase is that there’s a good chance a lot of the solutions to the problem at hand can be found somewhere in the code if you know what to look for and how to find it. I blocked most of Saturday for this user story, and to my amazement I had the first PR ready to submit after about 4 hours. I did go back and forth with my mentor a few times about some syntax I wasn’t quite understanding, but I tackled most of the overall problem on my own and I think pretty efficiently. I mean, I’m writing production code! Thats a huge step in the right direction!

When I started this project I also started a sort of journal to keep track of what I am doing, where I’m getting stuck, and what I need to research more. Initially I started it to be able to talk my mentor through my process, but I think I’m going to keep the entries for a while to reference later on down the road. Im sure that if I find myself at a roadblock once I’ll probably be there again in the not-so-distant future. I probably should have been doing some kind of journal all along, but, as is the theme for this blog post, better late than never.

As far as Bloc goes, at this point I’m really just trying to get it done as ‘efficiently’ as possible. The deeper I get into the front-end section the more I’m finding that I’m probably more of a back-end, database developer. That might change, and I hope it does, I hope that I do enjoy both aspects equally, but right now the front-end isn’t nearly as fun as Ruby/Rails. I stopped logging my hours that I spend on the curriculum. I’m on pace to finish quite a bit early, not unlike the back-end section, so I think it’s safe to say that I understand what I’m doing within the scope of how fast Bloc wants me to pick it up. I probably put more hours into the internship per week, especially now that I’m working on Rails code from home. At the end of all this, some day soon, I’ll need to prove to a team that I’m a solid web developer, and I feel like any and all experience that I have under my belt will help me in that endeavor whether it be from school, internship, or personal projects.

Weeks 31 & 32

161003 – 161016 — Total classroom hours – Less than 10

I think the biggest event that’s happened in the last two weeks is that I gave a Beginners Track talk at the Boulder Ruby Group’s Presentation Night (I don’t think I’ve typed that out until now, it’s a mouthful). I’ve been wanting to give a presentation for a while now, but didn’t think I had anything to contribute, being that I’m kind of a noob. I had recently gotten positive feedback on my standardized git commit message formatting, and it occurred to me that not only would an audience of developers appreciate it, the ‘beginners’ might like to know how to set it up.

Now, I’m not going to claim that one day the clouds parted and I had this vision of the perfect commit message, of course I had help, as is the nature of web development, and most of life. One of my now many mentors, Corey Davis, introduced me to this concept a while back when we were working on a group project. He send me a .txt file and then I dug around the interwebs to figure out how to configure it with git. At this point in my coding path I even more green than I currently am, so it took some trial and error to get the message to properly configure. As I found out again recently, testing changes to git configuration can be a beast. Unless I’m missing something obvious, the only way I’ve found is to have a burner file, make a change to it, work through the git add and commit process, and confirm that everything is how it should be. The caveat, especially when dealing with the commit message, is that if something’s not configured properly it can hang the whole process in limbo, which requires an entirely new trial and error process to figure out how to fix that. This is all that to say that I felt like it would benefit some people to give a quick tutorial on how to efficiently setup a standardized git commit message.

I’ve heard from other people how beneficial giving a presentation is for both the audience (obviously) as well as the presenter. I have to say that this couldn’t be more true. I started putting a GitHub Gist together the night before the presentation and quickly realized that although I knew the general workflow of how to create and configure the commit message file, there were a lot of little details that I didn’t know and should probably read up on before I gave the presentation. Because of this I now have a deeper understanding of git and why the .txt file that Corey sent to me was configured as it was.

Before I started the presentation I informed everyone that this was simply my workflow, not the gospel, and that I welcomed any and all feedback. I’m always trying to improve my workflow, which is another reason I wanted to present. What better opportunity to see if you’re doing something right than to show a room full of other developers? I did get some great feedback, in fact there was quite a bit of back and forth during the entire presentation, which to me makes for a better presentation than me just jabbering the entire time. One nugget I received was about another technique on how to stage files for commit.

My previous workflow, mostly because I was mainly only working on one feature or bug issue at a time, was to use git commit -a. Thiswas staging everything for commit. I’ve quickly come to learn, from both my internship and this presentation, that this is the lazy way to stage. I’ve also learned that I should be more thoughtful about what gets staged and what doesn’t. For this I’ve been staging each file manually, then performing a git diff --cached, which essentially shows you all the changes made to each staged file. Then, if there was a file staged that shouldn’t be for that particular commit I would have to go back and manually unstage it. That is, until now! During the presentation I was informed of the command git commit -p, which I’m pretty sure is the patch option. Basically, when this command is run it shows the changes of every file that has been altered since the last commit, and gives the option to stage, not stage, quite the staging process, and about 10 other commands. (here’s a stackoverflow link showing all the commands). This is now my workflow. It handles the code review and staging in one go, which is exactly what I want.

All in all the presentation went very well. I did a little live coding with VIM (with sweaty, shaky hands), had a great dialogue about how/when/why to commit certain things at certain times, and checked a few items off of my programmer-in-training to-do list. I adamantly recommend to every student I meet to attend meetups in their area, and I can now recommend from experience that everyone give a talk as soon as they feel comfortable doing so. This is the link to the Gist, if you have any interest in standardizing your own commit messages. At the bottom of the Gist are some more git references if you want to dive even deeper.