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.

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.

Weeks 29 & 30

160919 – 161002 — Total classroom hours – 23

Well, apparently Im doing something right, because I’m currently two weeks into an internship! It’s with an independent contractor, working on two client-side Rails apps. I’m working with him 4-5 hours a week, so it’s not too taxing on the already tight school/work/life schedule. It’s a completely different beast to work with an existing code base, especially when the other person built it, and knows it forwards and back. As I’m sure is common with a good portion of web development jobs, a lot of what I’m doing is dependent on my abilities to even find the necessary file that needs to be refactored. I think its actually a legitimate ‘test’ for someone in my position, something that evaluates my problem solving skills right out of the gate. When looking at a locally-run web app, how can I identify the problem and find the necessary file in a codebase with 1000+ files. Oh, and did I mention that the entire app itself is being refactored, admittedly by mentor in a very ad-hoc way, so one quarter of the existing files are non-functioning. Im getting skilled at mining for files.

Once I’ve actually found the file, with him literally over my shoulder, knowing exactly where it is in the first place, now I have to identify the code to be refactored. This has two factors that make it interesting, the first is that I have no idea how this file was written. It. Is. Full. Of. Partials. As it should be, I suppose. The idea of DRY programming is that if theres a way to not repeat yourself you utilize it. Digging into a file and its partials just ‘spices up’ the whole process on my end, which, ultimately, I appreciate. The second factor is that the entire app has been refactored from .erb to .haml. Ultimately, it’s not that much different, it’s doing essentially the same thing, but its just something that I’ve never worked with before now, and it’s a bit daunting to take it all in, especially with the other elements that are being introduced to my workflow.

AND! Those new elements are vim and tmux! I’ve known of vim for a while, but the idea of moving that direction was a bit spooky to me. Then, in the course of one week, I was told by two different people that I should give vim a try. I started digging into it and quickly found that vim has a built in tutorial (next time you’re in the terminal type ‘vimtutor’), so thats pretty awesome. The tutorial took me about 45 minutes to work through, and once I was finished I was pretty confident that I could start editing files with vim without causing too much damage. It’s still not part of my everyday workflow, I’m just quicker with a text editor, like Atom. What I did was set vim as my default editor for my commit messages and terminal aliases. This way I have to use it a little bit every day (I’ve been making a lot of terminal aliases lately) and after a while I’m sure I’ll start using it on everyday file editing.

Tmux is also a super handy tool that seems to be widely used. In a nutshell, tmux subdivides your one terminal window into as many different independent terminal windows as you need. Before tmux I was doing a similar thing, only with tabs. I had my first tab as the standard terminal (file navigation, git commands, etc), the second as the server, and the third as the console. The same setup on every project. Now I can have all that in one window. My workflow was pretty good before the introduction of vim and tmux, but now its getting even better (faster). What I’m learning is that its all about your fingers never leaving the keyboard, and when you get really serious about it, your fingers never leaving the home row of keys.

All of this and I haven’t even touched on school yet. School is school, only now its frontend instead of backend. The first round of HTML/CSS curriculum went super smoothly, and now I’m working through Javascript. It seems to be coming to me pretty ‘easily’. I’m sure that I will get tripped up by something, but I feel like having spent so much time troubleshooting languages and frameworks as complex as Ruby and then Rails, the concepts of Javascript aren’t all that much different. And I’ve become pretty good at searching the interwebs for answers to questions. I’ve probably been spending more time on the internship and networking than I have on school. But I’m ahead of the school’s pace at the moment, so I’m more than ok with my current time distribution.

Speaking of networking, I attended Rocky Mountain Ruby last week and it was a pretty great experience. That was definitely the first time I was in a room with so many other Rubyists ( I think thats a term…). I’m also pretty certain that I was one of probably less than a dozen non-working professionals in attendance. I’m sometimes surprised at how few students I come across at events like that, or even meetups. This industry seems to be all about the people you know, and theres no better way to meet people than to go to events where everyone has something like web development in common. Almost my entire web dev network has come from events and meetups, and I’m talking to those people about one thing or another almost daily. I’m sure this is something that is obtained with less effort when attending a brick and mortar code school, but when attending an online program like Bloc I have to go above and beyond to make it happen.

I feel like I’m on a good trajectory with everything so far. Finished the first half of school with time to spare, landed a solid internship, have an ever-growing network of fellow developers, and starting the second half of school with a bang. I’m looking forward to the next few months.

Week 28

 160905 – 160918 — Total classroom hours – 20

Project parkfinder has turned into AdventureSearch, and by the looks of available domain names, I have a hunch that it will change again. But, luckily, it’s just a name. More importantly, its complete!(ish) When I say complete in this case that doesn’t mean that I will never have to touch it again, but instead that I have accomplished the cards I have assigned to the project and it is in MVP (Minimal Viable Product) stage. It works almost exactly like I had envisioned it, with the user merely clicking a button and the three closes National Parks are then shown. Its rough, but entirely functional. I have ideas on how to improve upon it (include more recreation areas, add more user functions to the park’s individual pages, etc) but I’m going to let it be and see what I can apply to it from my work in the frontend portion of the program that I will be starting next week. Take a look and find the closest three National Parks to you!


My other project over the last two weeks has been to clean up the code of my four main projects I have on GitHub repository. This is definitely one of those scenarios where it would have just been easier to do it right the first time (which is usually my style), but when I’m debugging things I have a tendency to get it working and jump to the next card. I’ve come to realize that in this debugging process I have pretty clean code, but my indentations are terrible. I’ve gotten comments on my ‘proper’ formatting when getting help from people, so it seems that people are looking for it, or that it stands out like a sore thumb if it’s not done properly. With this in mind, and because of a comment from my mentor, I decided that it would be well worth the time to make sure all my code looked as clean as possible, not just functional. I have the links to all my projects github repositories on my resume, so if someone is curious they will dig, and it will be one of their first impressions of my programming abilities. Im positive that I’m not the most efficient programmer, but I can at least be a formatting-conscious one and show my attention to detail.

That leads me to the other work I’ve been doing, networking. Networking my ass off. Its been quite some time since I’ve talked this much about myself. I’m a pretty modest person, so this exercise is something that I have to refamiliarize myself with. It’s been nice though, Ive had 3 or 4 very informal conversations about my intentions and goals of being an intern, and those have been followed quite conveniently later in the week by slightly more formal conversations. If things go well, the formal conversations will turn into the most formal conversations in the way of interviews. Time will tell, and in that time I will keep making moves to help ensure that I get to those most formal of conversations.

I have the next week ‘off’ as I am between programs at the moment, but I don’t intend to just sit around. I’ve got some companies to research as well as some pre-coursework to complete before the frontend program begins. No rest for the weary!

Week 26

160829 – 160904 — Total classroom hours – 9

The end is near. As gloomy as they may sound, in this case it’s a good thing. I have two more weeks of school, then a week ‘off’, then I start the frontend course. Not knowing exactly what to do with my remaining time, I consulted my mentor, I mean, he knows best, right? I expressed to him that doing code challenges for the sake of code challenges wasn’t really something I was all that interested in. I can’t remember if he necessarily agreed with me, be we ultimately came to the conclusion that I should start working on another project.

I had plenty of options, there are like 6 projects I could choose from in the curriculum, I had the group project that I could continue to contribute to, and I also had/have a few ideas floating around for a capstone personal project. He quickly recognized the enthusiasm I have for the personal project, and after helping me flesh out the idea and the stages of development, we decided that was the path I should pursue.

rails new parkfinder -T

And just like that, I’m off. A new project is in the works. It’s going to do a few things for me, mainly keeping me fresh on ruby/rails, especially when I start the frontend program and begin learning another new language. Its also going to be a much different structure from the Bloc.io projects, so it will keep me on my toes and have me asking new questions. There is also a lot of room for growth, so I can keep expanding it as my skills increase. I’ve been thinking about this project for some time and I’m pretty excited to get working on it.