Jesse Wolgamott

It started as a simple idea: let’s explore the awesomeness of the new GraphQL API by building a tiny app. Think Travis-CI but for writing. Maybe it could check spelling, grade level, and possibly help with adverbs the way hemingwayapp.com does.

Maybe that app could help people use pull-requests during editorial reviews, much like how tests help developers with code reviews.

It lead to a rather simple question:

What do I have to do to get the following to work?

My birthday is coming up; looking back on what I learned about looking forward on what I want to learn, I noticed a pattern. Each year I spend revolving around the sun tends to have a pattern of what I learn. Maybe it was distributed systems and how easy it is to screw up in 2007-2008. Or APIs from 2012-2013.

There is too much to learn with far too few years to learn. The only way I’ve been able to be ok with this fact is to schedule my learning, learn by doing, and then reading the books on the subject. Note: read the books, not the blogs, is a technique by Chris Oakman and it’s helped me dive into the theory behind the tech. The tech changes, but the theory stays the same.

That said, this is probably a very hip-javascript heavy post. If you’re suffering from JavaScript fatigue, this may or may not help.

Two years ago, my first cohort graduated at The Iron Yard in Houston, Texas. 12 students received their diplomas and started their journey, their career, and their new life.

Five cohorts followed; today my seventh, and final, immersive cohort will present their final projects and begin the next phase of their live. I look back and remember:

One of the cooler features of Elixir (and other functional languages) is the Pipe operator |>. It certainly makes code easier to read, but it’s a bit difficult to grep for the first time.

Let’s use the Turducken to explain it. For the uninitiated, A Turducken is a turkey stuffed with a duck which is itself stuffed in a chicken.

We’ve all scraped a site or two (rite?) but what do you do when bad actors start taking up a non-trivial amount of resources on your app? Further, what if bad actors are masking their user agent to appear as though they were googlebot?

Writing is a series of small burst of rushing water, a thousand words pouring out of me in a very short period of time.

Writing is day dreaming, when no words come at all. The rushing water has stopped, the creek dry and crackling.

Writing is using your own voice and avoiding sounding important or intellectual. Writing is real.

Writing happens in the morning for me. I imagine my brain is still excited about the day in the morning, and like sushi, degrades the further it gets from sleep. I should look into napping. You should find the part of the day you are most creative, and write then. AB test it. Trial and error.

Tools

Many developers spend days, weeks even, on getting the correct Tool. I have used Pages, Desk.pm, IA Writer, Scrivener, and more authoring tools I can remember. They do not do the work for you, and in general do not make anything easier.

You can also spend days, and weeks, on your toolkit to transfer your words into an ebook format. Or, your site’s marketing website.

But here’s the truth: you are ignoring the part that matters: getting words out of your brain and onto ‘paper’. Stop with the tools, and just write. Use softcover or leanpub - both will create a page for you so you can focus on the writing.

Fiddling with tools instead of writing is wankery distraction.

Timeline of a chapter

• Day 1: write an outline of an article or chapter
• Day 2: fill in the outline
• Day 3: edit the first chapter
• Day 7+: revisit and read with a clean mind. I’ll find that I find I didn’t say all I thought I had said. Or, I’ll find typos clear as day that my mind wouldn’t let me see the previous week.

I’m currently putting my ideas on writing into action creating Tex Mex Consulting. Some of my favorite articles:

• Clients do not pay you for the code
• From Employee To Freelancer to Consultant
• Proposals: shitty to super-fantastic

Employees don’t make enough money. You’re not treated fairly, are not respected, and have to put up with a lot of crap.

Most software developers can learn a hellaton from freelancing and consulting; at the very least you can learn what you’re worth. And it’s not $75,000 a year with free soda and 1% equity.

I’ve spent 6 years and many thousands of dollars in mistakes, masterclasses, and good old sweat equity in created a workflow system for expert software consulting.

I want to give you a path to consulting; a path to go from Employee to Freelancer to Consultant. A path to freedom, more money, and more respect.

The basic ethos of the book:

Freelancers are hired by companies. Consultants choose their clients carefully.

Want to try out some the techniques in my system? I’ve created a 30 day free email course on Professional Freelancing – try it out below.

Check out the system for Professional Freelancing at Tex Mex Consulting.

Like most love stories, my love affair with Ember took time to blossom. I first saw Ember in 2011, had some fun, and planned to look at it once the API solidified.

In that time, pre-1.0, Ember’s API would change constantly. Most people saw this as a flaw, after all, it meant that documentation, blogs, and stack overflow searches would frequently reference older versions. The router saw the biggest changes, frequently.

The benefit of this – Ember got the API right. Once it hit 1.0, the API was on point; and with the correct API in place, Ember keeps getting better. Ember is able to make changes under the hood, applying React style rendering, performance enhancements, and generally get better and better over time.

My experience with ember is generally along the lines of Deleting more code than I add; Ember tends to add what I need overtime and I use that instead of my code.

Told over a series of many (perhaps too many) tweets, here is the story of my transition from Ember to Angular to Ember.

Getting Websockets, CarrierWave, and Fog to play nicely together

Alternate title: “Dancing with Dragons, or, how I got screwed by ActiveRecord Callbacks yet again.”

I’ve been working on the following scenario:

• 2 different people have an ember app open
• One of them adds a new record to the Rails app
• I want other-person’s ember to refresh with that new record instantaniously-ish

The setup

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_create do
    Pusher.notify("new_photo", PhotoSerializer.new(self).attributes)
  end
end

Fairly simple, but here’s what’s going on:

• When our photo is created, carrier wave will resize the image, upload it to S3
• We will send the JSON through Pusher to any clients subscribed to the new_photo channel. The JSON we’re sending is the same JSON that ActiveModelSerializer will use in the API. WIN.

But then, melancholy.

The JSON that comes through has something rather odd for large_image_url - it’s a local path to the /tmp/upload directory, which absolutely does not work. :/

{
    "id": "399ca80efb2bd65e7254f299adfe278a",
    "name": "thumbythumbythumby",
    "large_image_url": "/uploads/tmp/1425583084-37430-8620/large_thumbnail.jpg",
    "thumb_photo_url": "/uploads/tmp/1425583084-37430-8620/thumb_thumbnail.jpg"
}

Basically, when Pusher is sending PhotoSerializer.new(self).attributes, the image has not been stored up to S3. We want to do Pusher later, after fog does it’s thing.

Callbacks are run in this order:

before_validation
after_validation
before_save
around_save
before_create
around_create
after_create
after_save
after_commit/after_rollback

So, after_create is occurring before after_save. Let’s switch that up and our problems should be solved:

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do
    Pusher.notify("new_photo", PhotoSerializer.new(self).attributes)
  end
end

Result: Same thing. huh?

To see the order in which callbacks are run, we can do this:

Photo._save_callbacks.map(&:filter)

That will show the name of the callbacks being called, and will look something like:

[70220584822820, :remove_previously_stored_photo, :store_photo!, :write_photo_identifier]

That 70220584822820 is our block callback. And it’s first. Why is it first? Can we get it to go last? Callbacks are run in a last-first order. Further, changing it to something like the following also doesn’t work.

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do
    Pusher.notify("new_photo", PhotoSerializer.new(self).attributes)
  end
end

So then what the hell works?

We need to store the image before we get the attributes. So, let’s add that store_image! callback we saw in the list of callbacks. This will result in store_image! being called twice, but it won’t actually store the image twice — the second call is basically a no-op.

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do
    store_image! ## It’s this. this is carrierwave saving the image.
    Pusher.notify("new_photo", PhotoSerializer.new(self).attributes)
  end
end

{
    "id": "399ca80efb2bd65e7254f299adfe278a",
    "name": "thumbythumbythumby",
    "large_image_url": "https://sevensevenseven-dev.s3.amazonaws.com/uploads/photo/photo/32/large_thumbnail.jpg",
    "thumb_photo_url": "https://sevensevenseven-dev.s3.amazonaws.com/uploads/photo/photo/32/thumb_thumbnail.jpg"
}

IT WORKS. REJOICE. Then: Anger.

CALLBACKS!!!

It reminds me of a story about a younger Rails developer warning other Rails devs about the dangers of Callbacks, and how they tend to screw you over.

After a few flirtatious encounters with Ruby, I left .NET in 2009. I was looking for something better, something where I didn’t use an IDE, something where I didn’t feel like I was fighting the entire culture, and a place I could be happy being a devloper again.

I found Rails. I found open source. I found Ruby. And I found myself.

Ruby/Rails to me: a community where people help each other learn, full of interesting and fun challenges, and a desire to learn the entire stack from UNIX to CSS.

Fast forward 5 years; I’ve been thinking about what the next 5 years will look like, for both me specifically and for web/mobile application in general.

It’s fairly clear to me that most medium to large’ish apps won’t be a single Rails app with 100 controllers. That dog has tried to hunt, and well… that dog won’t hunt. OneLargeRailsApp is not the future.

Rails isn’t going away. I will still use it for prototyping and for applications where expressiveness is key (billing code and administration of data are two examples). Rails will become part of the puzzle, not the whole thing. I don’t envision anything being the entire puzzle anymore. Too much awesome tech which each do one thing super awesomely.

Prediction: apps in this half-decade will be split up

• Many Apps (iOS/android, some rails, some Ember, some R, some Go)
• Depending on your worldview, gsub/Go/Node|Elixir/

I don’t anticipate quote-unquote leaving Rails. There’s no need to leave like there was a need for me to flee .NET. Instead, the communities will merge together under an open-source umbrella. I doubt there will be one big huge community in which you do ALL of your development.

The future, in my opinion, is many languages. Many communities. Many meetups.

Bring on the future!

(and my hoverboards. and jetpacks. and flying cars)