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.
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.
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:
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
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. :/
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:
So, after_create is occurring before after_save. Let’s switch that up and our problems should be solved:
Result: Same thing. huh?
To see the order in which callbacks are run, we can do this:
That will show the name of the callbacks being called, and will look something like:
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.
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.
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
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)