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)
ember-cli 1 is a command line application that creates a separate project for your ember project.
It is crafted by the Ember core team and extended by the Ember community .
So: your backend API will be in 1 app/repo, and ember in a seperate one. This is
a good thing for all sorts of reasons, but mostly: Your Front End App has grown
So excited by how Ember CLI is
shaping up. This is the story I've been wanting to tell about developing web
apps for the last 3 years.
ember-cli includes the ability to build SCSS, Coffee-Script, include bower assets, and test your code.
It will generate ember components for you in the same style as “rails generate model Customer”
ember-cli can run all of your front-end tests. Fastly. Without hair-pulling.
ember-cli can build the code for you (into a dist) folder, which can be deployed, or copied to a Rails public folder.
ember-cli can also be deployed directly to Heroku, or used to build Cordova applications on iOS and Android.
** Tl;dr ember-cli is the awesome **
However: There is a confusion generating getting-started period where you might be confused by some of
the conventions. (confession: I had to fiddle around to figure stuff out.
Hopefully, you dear reader won’t have to do so).
If you’ve used ember before in Rails or Lineman3, moving to ember-cli could confuse you a bit —
ember-cli uses ES6 modules, which you may have never seen before.
Prior to ember-cli, you may have declared your ember data models in this fashion:
** app/js/models/user.js **
Things to notice: in this file, we assume that Ember and Ember Data have already been loaded,
and are in the global namespace ready for use.
ES6, on the other hand, requires you to be explicit about what you want to use — you import namespaces,
name them what you want, and then use them.
** app/models/recipe.js **
We import the “DS” from ember-data, and it exports the object we define. What we notice:
We never say this is a “Recipe”. Instead, the ember-cli “Resolver” knows that this is from recipe.js and
therefor is a “Recipe”.
The “export default” is important. Without it, nothing happens.
It’s extremely important to name files correctly. Extreme Extremeness.
Getting Sass Working
Coming from Rails, the first thing I want to do is work with Sass. I found a couple of loops you had to
jump through to get your .scss working again.
Step 1: install brocolli-sass and broccoli-merge-trees
If you’re new to npm, the “–save-dev” means “use only in this project”.
Step 2: edit Brocfile.js
Make it look like this:
This will create an asset-pipeline of sorts for you. Broccoli will compile any sass files in app/styles and vendor/css, and compile app.scss into “assets/app.css”.
Generally, this is what you want.
Step 3: Customize your sass
Move app/styles/app.css to app/styles/app.scss. You can now use scss all you like:
(We’ll use Bourbon in a future article)
This will create app/routes/index.js (and create “routes” directory for you, cool). We’ll change the default to the standard ember starter:
And we’ll create a template to show.
This created app/templates/index.hbs. We’ll change its contents to:
If things are good to go, you’ll see the colors listed out on the screen. WOAH, the power.
Building for Deploying
This creates a “dist” directory with “index.html” and other static assets. We can deploy this to S3, or anywhere else. TOTES AWESOME.
Deploying to Heroku
If we run into CORS problems, or generally want to use Heroku, there’s a build pack for maximum awesome.
At this point, you have an ember app, build with ember-cli, hosted on Heroku.
We can set an API Proxy to get around CORS problems:
heroku config:set API_URL=http://api.example.com/
If you want to checkout a repo where this is hooked up 3
Where to go from here?
Check out ember-cli-cordova https://github.com/poetic/ember-cli-cordova
Watch Jake from Poetic Systems’s Houston.JS talk on using this to build mobile apps