Learning Ember

by Jess Brown

Recently I've been working on a new product for my company and I decided it was a good fit for Ember. I'm just now learning Ember so it's a new endeavor for me.

I got about 60% of the way through the project and hit somewhat of a wall. I've gone about as far as the introduction tutorials I've found take you.

I've been pretty comfortable in my role as a senior or advanced rails developer for some time now. Not that I don't struggle or work on hard problems, but rails as a framework isn't getting in my way or slowing me down. I'm able to focus on my problems and not focus on the framework.

Now that I'm learning ember, I'm reminded of back when I was learning rails and how difficult and frustrating it can be to learn something new. To solve a simple problem, it requires a lot of digging and learning. But that's the price you pay for learning a framework. In a recent talk I gave about learning rails, I explained that it was difficult to learn rails (or any framework for that matter), but that the investment was well worth it.

I spent about 10-15 minutes live coding with them went through doing a quick prototype of their website. I saw some pretty impressed smiles from the crowd when they saw rails work it's magic.

I struggle with this upfront cost, but have to take some of my own medicine every now and then remember that it's worth it in the long run.

Writing Challenge Update

by Jess Brown

A few weeks ago, I took a blogging challenge and I failed in my goal of writing for 30 straight business days. I started on 9/1 and did pretty good for 3 straight weeks, writing 15 blog posts in total. My downfall was 2 weeks. My goal at the beginning of the challenge was to write at least 1 case study / white page on a recent project we'd completed. I figured it would take me about the same amount of writing 3 blog posts, so I set aside 3 days to complete it.

I did start it and I did write for those three days, but there was just too much to it all. I wanted to chronicle the step by step process we took in redesigning the www.montlick.com website. I had a lot of photos, screen shots, notes and sketches to pour over.

I'm still in the process of writing it and hope to publish it soon.

Couple of lessons learned...

Consistancy is hard

Doing anything consistently is hard. If you really want to do something consistently, you have to be truly dedicated to it...whether you're exercising, dieting, working, or blogging.

Long term goals are more difficult to achieve

When I was blogging daily, it was easier to publish something. The goal was clear, the end result was within grasp. I did fall behind once or twice, but I didn't want to miss a day so I always caught up. By contrast, the 3 days I spent writing the white paper was more ambiguous. I wasn't sure how much I needed to complete each day. Also, the goal of three days was not set in stone.

I liken this small example to working on creative projects, which are notorious for being late and over budget. If an overall project deadline is not set with milestones along the way, then there's usually a good chance the project will drag on and on. I learned this early on in my business. I'd have 2-3 larger projects to work on but also daily small tasks on existing projects. It's so easy to take care of the small tasks and forgo the dedication it takes to working on something due 3 months away.


Good habits are hard to form. Starting small and committing to be consistant are key.

Just Ask

by Jess Brown

On Friday's while Patty is at CrossFit, I usually take a break from work and watch Nate for a few hours. This morning I asked him what he wanted to do and he said, "I want to see a train". Ok, that's a random one, how do I fulfil that request?

Well, while out cycling the other day, I just happened to ride by a CSX station in a town nearby, so we hopped in the car and drove out to it. It was an old building with no windows or glass in the door, but I knocked and when no one answered I just went in. It was a very non public place with lockers and years old flooring and walls. Once inside though, I bumped into a man just said, "hi, we'd like to see a train, are there any out in the yard we can look at?"

Csx train

To our surprise, he was very accommodating and took us out in the yard and showed us all kinds of stuff: tracks, cars, engines, a choo-choo-truck; he even blew the train horn! It's amazing what people are willing to share with you if you just ask!

I've done this quite a few times, with fire stations, police stations, etc. We have a small local airport that I took the kids to once. We walked into the mechanics shop, and struck up a conversation with the first person we saw. It turned out he was the owner of one of the planes in the shop and invited the kids up into the plane and answered all kids of random questions from the kids. The owner of the shop even ended up giving the kids some wooden model airplanes. Another time we saw a hot air baloon land near by. We drove over, started up conversation with the folks, and winded up getting a ride.

Kids airplane

Just Ask

I was chatting with a business assiciate the other day and we were talking about this concept of asking. Whether you're thinking of asking for a sale, for the job, for an investment, or for the promotion...just don't be afraid to ask. I typically find people are much more willing to entertain the idea than you think they might be. Even if they're not, it may open the doors to something else. Besides, the worst thing that can happen is you get a No, and that's not a bad risk to reward ratio!

The Only Certified Rails Developer In Georgia

by Jess Brown

I'm the only certified rails developer in Georgia ™

Only Certified Rails Developer In Georgia is a registered trademark of Brown Web Design, Inc. representing internal standards of quality assessment and service control. The protocol is not administered by government or industry regulatory agencies and does not imply regulatory approval of Brown Web Design Services

Ok wait, I'll explain...

My wife Patty got some kind of free essential oil sample in the mail the other day. It had some fancy phrases all over the packaging like, Certified Pure Therapeutic Grade.

Patty didn't know what it was or what it was used for so she starting Goggling it and came across a website that sort of exposed this company and their claims. It turns out that Certified Pure Therapeutic Grade is actually just a registered trademark of the company and has nothing do with the quality of the product. It's a marketing phrase they registered.

I know companies make all kind of false claims and weave the truth between and around regulations, but this is the first I've heard of trademarking a phrase in this way.

No wonder social media is such a strong influencer of buying decisions. People know they cannot trust a company's own claims, so they rely on someone they know who has experienced the product or service.

So, should I trademark only certified rails developer in Georgia? :)

Tricky Has And Belongs To Many

by Jess Brown

Today I was working on a client project that was using a has and belongs to many (habtm) relationship, but there was only 1 model involved. This part of the application was setup by previous developer and was the source (I believed) of a bug in our API that was my job to fix. Since I didn't setup the relationship, I started investigating how it worked and what I found was pretty interesting so I wanted to share it. I'm going to change the model name just to avoid explaining the context and give you an example.

class Product < ActiveRecord::Base
  has_and_belongs_to_many :related_products

We want to use a join table so we can create related products for a product. The problem is, habtm is setup to work between two models. For example:

class Course < ActiveRecord::Base
  has_and_belongs_to_many :students

class Student < ActiveRecord::Base
  has_and_belongs_to_many :courses

# join table : courses_students
# fields: course_id | student_id

So what does the join table look like for our tricky one model example?

class Product < ActiveRecord::Base
  has_and_belongs_to_many :related_products

# join table: products_related_products
# fields: product_id | related_product_id

This looks pretty good so far. Write your table migration and give it a try.

class CreateProducts < ActiveRecord::Migration
  def change
    create_table :products do |t|
      t.string :name

    create_table :products_related_products, id: false do |t|
      t.belongs_to :product
      t.belongs_to :related_product

Fire up the console:

> product = Product.create(name: "ball")
> related_proudct = Product.create(name: "bat")
> product.related_products << related_product

NameError: uninitialized constant Product::RelatedProduct

Ok, you could have probably guessed this wouldn't work. How does rails know how to relate a related product?

It turns out you can specify the setup of the relationship. Let's give it some guidelines:

class Product < ActiveRecord::Base
  has_and_belongs_to_many :related_products, 
    class_name: "Product",
    foreign_key: "product_id", 
    join_table: "products_related_products",
    association_foreign_key: "related_product_id"

Back to the console:

> product.related_products << related_product
   (0.1ms)  begin transaction
  SQL (0.3ms)  INSERT INTO "products_related_products" ("product_id", "related_product_id") VALUES (?, ?)  [["product_id", 1], ["related_product_id", 2]]

> product.related_products
=> #<ActiveRecord::Associations::CollectionProxy [#<Product id: 2, name: "bat", created_at: "2014-09-18 02:01:17", updated_at: "2014-09-18 02:01:17">]>

Ok, great, it works. But...upon inspection of the sql I got this:

> product.related_products.to_sql
=> "SELECT \"products\".\* FROM \"products\" INNER JOIN
\"products_related_products\" ON \"products\".\"id\" =
\"products_related_products\".\"related_product_id\" WHERE
\"products_related_products\".\"product_id\" = ?"

Wait, does that look right? ON products.id = products_related_products.related_product_id? Shouldn't we be joining the table on products.id = products_related_products.product_id instead?

I thought maybe they had the association_foreign_key reversed at first, but here's what made it click for me. When you call .related_products what do you want returned? You want Product objects that are related. You're returning the related products. So that's why it makes sense to join on products.id = products_related_products.related_product_id

This is a pretty specific post, but I hope to help someone needing to use a has_and_belongs_to_many on a single model and gets confused about what is the foreign_key versus the association_foreign_key

With my acutal bug, the keys were reversed. Which you might guess, doesn't actually matter when when you use rails to call the relationship. However, our API was using a different sql method to fetch the related records and it returnd a bad result.


Subscribe to our mailing list