Kristian Freeman Engineer at Simple, musician, and some dude in Portland.

Initial Ember.js impressions

I had the chance to write a fairly complex Ember.js app solo over the last couple weeks. While I had worked around the edges of one at my previous job, this was a great opportunity to start from square one and make design decisions on my own. The resulting application benefited from the tight UI handling that Ember provided, and it was a marked improvement over what a Rails-based solution (as it runs inside of a Ralis app) would have looked like.

Spoiler: setting up an Ember app inside of a Rails app is not fun, or easy. I learned this through a couple versions of the app, all working around the Asset Pipeline's benefits and/or limitations:

  1. Single page. All the JS and Handlebars files lived in a single .html.erb file that was wrapped by a stripped down version of the app's application layout file. This was the simplest and bare-minimum implementation of an Ember app, and works great if you have an app of low complexity. This starts to become a problem when you're abstracting pieces of UI out into separate views or components and begin to have a pretty beefy tree of UI components. This version also didn't use Ember Data, so the concept of a model was more or less hard-coded into the view, by dealing with the JSON responses.

  2. Split JS files. By using Rails' great require_tree method, the actual JS source of the Ember app could be taken out of the view file and put in its own directory structure. I chose a structure mirroring ember-cli's, which is also pretty similar to Rails:

Directory structure for Ember App

  1. Handlebars in Asset Pipeline. This was the most difficult part of the process, but also the biggest win in terms of code structure. In ember-cli and other JS-based build tools for Ember, the Handlebars templates become JS as part of the compilation process. In a base Rails app, Handlebars templates live as script fragments with type="x/handlebars" set on them. This means that the closest thing you could get to separating them into separate folders is loading them as partials. They're still under .html.erb files, but they don't all live in one file. This solution worked, kind of - it quickly became a pain to load each partial into the main view every time a new file was made. The solution was a gem called handlebars_assets, which adds Handlebars templates to the Rails asset pipeline. Because we were already using it inside of the project, the set-up process wasn't too difficult. The only problems that I ran into were loading the Handlebars templates with other, non-Ember .hbs files in the project. The solution was two-told: the "Ember Support" section of the guide suggested setting .multiple_frameworks = true in a HandlebarsAssets initializer, which required renaming the templates to a .hbs.ember structure. Second, the Resolver on the app needed to be overridden to deal with the namespacing of the templates (for example: app/index):
Resolver: Ember.DefaultResolver.extend({
  resolveTemplate: function(parsedName) {
    parsedName.fullNameWithoutType = "app/" + parsedName.fullNameWithoutType;
    return this._super(parsedName);

The final implementation of the application structurally resembles a Rails app, in that all the files are loaded given that they're inside the correct directories. This kind of solution would have just worked if it was an ember-cli project, but it was useful to go through the different versions as the app grew in complexity. I think that for single-page applications, storing everything on a single page is fine. It can get unruly very quickly, but the process for dealing with loading of multiple files in a directory structure isn't super easy; it's up to the developer's discretion, in the end.

As for the project itself: Ember is great. The application is a queue process for dealing with various requests that fall under different categories and statuses - processing these through Ember's ArrayController was super easy, and the bindings were super useful in re-sorting the data when it changed. All of that, once again, just worked, and it was awesome to have the part of the application I was least excited about writing come for free.

One of the biggest wins in development came fairly late in the process, when I introduced Ember Data to the architecture. All the data in the application is retrieved with basic JSON calls to the supporting Rails controller: I opted to use RESTSerializer in this instance as it seemed to have more documentation. ActiveModelSerializer probably would've been a wiser choice in the long-run - I ran into a lot of problems with having to re-wrap the data with root keys and data relationship stuff that I hope would be fixed with the AM serializer. One of the more interesting problems I had to deal was the usage of UUIDs as a primary key: luckily, support for that came fairly easily, as you can override model-by-model serializers:

App.UserSerializer = DS.RESTSerializer.extend({
  primaryKey: 'uuid'

The win with Ember Data came when the application started to need to know more about the parent models for the primary data in the application. For instance, as we began to need to know more about the person who created the model instance and the user it was in regards to. Both of these came super easily with the addition of a hasMany or belongsTo in the Ember Data models for the base queue object. Because the service was powered by basic REST, it was literally the addition of about four lines of code to make it work. Awesome.

One of the most amazing parts of developing with Ember is the Ember Inspector for Chrome. The below image (from the extension page) is an example of what an Ember app looks like with the extension enabled:

Ember extension on Discourse

Every part of the app - from the UI-side (views, components) to the backend (controllers, models) are accessible and queryable from the extension. One of its killer features is the ability to send any section of the app to the console as the variable $E, which can then be explored like a REPL. It's a great way, for example, to test if your bindings work - by doing $E.set('something', 'new') you can see if the various computed property functions are updating as expected. It's also fun for the instances where you come across an Ember app in production: it's just as easy to explore as a development app. Vine's official site is a great example of this.

Overall, I'm super stoked with the last couple weeks I've spent with Ember. It's very well thought-out and any problems I've had have turned out to be user-error, not a framework problem. I'm really interested in, given the time, converting a good deal of my projects over to a light backend (maybe in Sinatra or rails-api) and a Ember-based frontend. It seems like this is the way that webapps are going in the future, and Ember (in my opinion) is leading that charge.

Robin Williams

Claire and I watched Mrs. Doubtfire last night. It's probably the only way you can memorialize an actor. Is there a different way to mourn someone you don't really know then appreciating and revisiting their work? Robin Williams was brilliant in that movie. One thing I didn't remember from seeing the film when I was younger was that it's not just a kids' movie. It's about something that's hard: losing people, whether for a month, or forever, is terrifying. Robin's character navigates that in the best way he knows: acting, playing, and learning. There's something we could all probably benefit a bit more from, in our own lives.

Depression is shitty, and scary. Sometimes it surrounds you like a big ocean and makes it hard to find your footing. Other times, it's like a rusty car that you can't quite clean: there's dark cruft around the edges, and in the cracks. You can't completely 'clean' it. There's an awful stigma in the world about mental illness, where people either deny that it is or that the amount of people that it affects. It's not based on class, or race, or gender; it's everyone.

It's hard to help someone with depression. You think you know all the answers to their problems, and you just want to shout "HEY! Please listen to me." But that isn't the solution. Everyone is different, and to be there for someone with depression, start by just being there. It's been interesting to see the varied responses to Robin's suicide - frustrating to see responses like "why couldn't he just be happy", and inspiring to see the outpouring of support for those in a similar situation.

These things are really hard. If you need someone to talk to, shoot me an email or check out places like Reddit's /r/suicidewatch which, despite the fairly intense name, is full of people who are there to help. There's always help out there. <3


This website has been through a bit of change lately - I switched to a static, single-page site for a month or so; it had my usual internet avatar, and a link to my Twitter, GitHub, and email. I realized pretty quickly that I actually missed writing a fair amount, so I switched it over to a WordPress site. It had been a while since I'd used WordPress, and it's still as simple as I remember it being. The setup process is still impressively easy, even for someone with a lack of programming experience. I admire that about WordPress, but I began to miss the combination of writing and being able to easily customize the website. I don't know any PHP (I could probably figure it out if I tried), but the immense support for plugins and themes weren't super appealing to me. There's nothing wrong with the plugins, I just didn't have a use for them. On the other hand, I like being able to just throw a single Markdown or HTML file in my site directory and have an actual pointable route show up on my website.

So we're back to Jekyll. This description of the site's transition is really a distraction, because I have, more importantly, moved. I'm in Portland now, after working a couple weeks remotely. While Simple is very remote-friendly, I've realized that working remotely is just not right for me. I like being in the action, and I like an environment that is highly collaborative whenever it needs to be.

Which brings me to Portland. Claire and I moved to Bellingham, WA in February, so this move was pretty quick on the heels of that. The difference is that this place feels like home. Our new apartment is really great, on its own merits but also because as we came closer to summer, the atmosphere of our last apartment complex became pretty awful to be in (this, of course, because Bellingham is a college town). The north-west area of Portland is beautiful - it's close enough that downtown is immediately accessible (Simple is ~10min by MAX), but the immediate area feels like a warmer Bellingham. A lot of this isn't going to be super accessible to anyone except Portland denizens, but a couple shout-outs:

The Mississippi area is glorious. Like I said, it feels like downtown in Bellingham, and all the restaurants are spectacular. There's a great selection of stores, including a retro video game store (!!), a comic book store, and a cool coffee accessories (because Portland) store.

While I think Lloyd Center itself is pretty sketchy, the theatre next to it seems to be pretty great. We saw Guardians of the Galaxy there, and I'm hoping to catch the Doctor Who 2014 season premiere there as well. It's a great size and doesn't seem to get too busy; I'd guess the theatres downtown get a lot busier. For us, it's about a five minute drive, and there's plenty of (free) parking. Perfect.

The food. THE. FOOD. While there's enough restaurants in each area that I could talk about it for a long time, my favorite place so far is pretty simple and rarely crowded. Kalé is a Japanese curry restaurant that sits right downtown, but rarely has more than a dozen people in it. It's currently dwarfed by construction, but I'd recommend it if you're looking for the sort of restaurant that knows it's good, but doesn't brag about it. Isn't that the best kind, really?

I've only been in Portland for a little under a month, but so far I'm having the time of my life. We're actually going to be returning to Washington this weekend, but it's safe to say that while I'm there, I'm going to be missing Portland. That seems like a good sign to me.

On that note, I hope to be posting more now that things in my life have settled down a bit. Moving and a new job combined (at the same time) is pretty much a recipe for disaster. Luckily that didn't happen, so I'm coming out the other end feeling pretty excited for the next couple months.


I've been missing taking notes. GTD practitioners will tell you that one of the healthiest things you can do to remove stress is to use an "external" system to capture all your thoughts and goals.

For a long time I've used things like OmniFocus to have very serious todo lists. I like todos but find that a lot of the things that I need to do aren't IRL stuff: it's things like bugs, software updates, etc. For that, I use GitHub Issues. However, I still have a huge amount of information sitting around in my brain that is useless 90% but can be referred to later.

Enter nvALT. nvALT is a fork of Notational Velocity, a pretty killer note-taking app. The motivations of the app are explained on NV's site:

NOTATIONAL VELOCITY is an application that stores and retrieves notes. It is an attempt to loosen the mental blockages to recording information and to scrape away the tartar of convention that handicaps its retrieval. The solution is by nature nonconformist.

While the explanation may be a bit pedantic, the motivation is pretty clear when you use the app. Taking notes is fast - there's rarely any need for the mouse, and it writes in exclusively plain text. Retrieving notes is fast - the only pieces of interface are the note text area, a list of notes, and a search bar. There's no cruft in the interface, and day-to-day (or even minute-to-minute) usage benefits from it.

nvALT is an updated version of the app, as the original is somewhat abandoned. Some of the changes to nvALT:

  • Markdown support
  • Preview functionality
  • Auto-pairing brackets, etc.

It's actually not a huge list of changes - the original app was good on its own, but I'd rather use something that is supported. Additionally, both apps are open source: one of the first things I did in OSS programming was to fork the nvALT source and create a native full-screen mode for myself.

I've been using nvALT again the last week or so and have been really enjoying it. I used it years ago, but only for small numbers of notes and things that weren't super useful or worth remembering. My approach this time around is to write down everything: I have reference cards for projects I'm working on, events I'm going to (including transit), people I know (contact forms, times we've met, etc.) and things that may not necessarily have immediate use, but are worth retaining. Because they aren't in my head and they're on an external system, I can fill them with a lot of information at no real loss. Additionally, they're synced on Dropbox as .md files so I feel like they're pretty secure and negligible in disk usage (currently at 27kb).

I've also begun to use the linking functionality more: both between notes and actual files. For example, a budget calculation can link to an external Soulver file that is in the same directory. A journal entry of my day can easily refer to the actual project notes, instead of just naming the project.

There's a lot of additional things people are doing with nvALT to be even faster: these posts by A Better Mess and Caleb McDaniel have some inspired workflows that are in no small part due to the patron saint of nvALT, Merlin Mann. I don't think I'm at the point where I have enough notes in the system to use these effectively, but I'm staying aware of them and as the note count bubbles up, it should become pretty useful.

Feeling for iPhone

The short version: Feeling, my app for keeping a record of your feelings over time, is now on the iOS App Store..

I've been a believer of quantified self tools in a long time, but find them to be horrendously complicated. Feeling is an attempt to distill my interest in quantifying my life at the base level: rate it one to five.

It turns out that doing that is surprisingly easy. For all the stress, happiness and everything in-between that happens can be distilled down into a number. Maybe that's depressing; the reality is that most days, on their own, are quite simple.

If that's not enough, you can add pictures and notes too! Hurrah.

I have a ton of stuff I'm trying to wrap out right now, so the part of this post that isn't being included is the technical bits that make this work, as well as the process behind it. That'll come soon, as well as a bit of a post-mortem on the process, design, and development of the app. I was going to include a video for the project generated with gource; however, I realized half-way through that my relative inexperience with Obj-C and Xcode led to less than optimal Git usage. There's not a ton of commits, even between build versions, and actual updates. Now that it's out and a bit more solidified, that'll change.

The process to the App Store was a little insane - it got rejected for a fairly stupid reason. Here's the story, condensed on Twitter yesterday.

Regardless, I submitted an appeal to the App Review Board and went out to the lake.

When I came back, an email told me that I had a response in the "Resolution Center", which is basically a conversation thread between you and the reviewer of the app. I had another email that told me Feeling was "Processing for App Store". Five minutes later, and it was in! Unfortunately, since the app had been approved, I didn't get a chance to see the response to my message to the reviewer. Looking back, I think I might've been a little angry and should've written something a bit calmer.'s what I wrote, either way. :)

Go check out Feeling if you're interested. Reviews are nice, but bad reviews are nice if you find bugs too. Thanks!