Progress

When I first started blogging, or something I think of as equivalent, it was while I was interning at a company called CentrPort, and I was learning Java, to write Java Servlets, and some Perl and first learning about SQL. I wrote e-mails to my friends talking about what I was learning and how it was progressing.

For the record, I think this is better than what I've been doing lately. But maybe I've been influenced too much by things I aspire to. Wanting to be like people I see as authorities.

The way I write now is more prescriptive. Here's what I think is the right way to approach this or that. I'll do this with video games, or board games, or random hobbies, but I don't do it very much with programming.

I think it's because I've got pretty low confidence there, and it's not that I think I'm relatively not a good programmer, but that I don't think anyone's really got it figured out. The whole enterprise is too young. We're all still fumbling around in the dark.

But there are some things I find myself stating over and over, and I figure I might as well write them here.

I'd had some bad client work where I was doing PHP stuff, hacking on WordPress to make it do some crap it's not designed to do, which I feel is roughly normal with PHP gigs, and I was profoundly unhappy. I didn't feel good about nature of the work. I didn't like the client (I'd inherited the gig from a friend who got a salaried job). And I didn't feel proud of what I was producing, even if it was hard-fought. It was neither interesting, nor easy, nor well-paying.

I was really depressed, and it made me unproductive, but constantly stressed out, spending all my waking hours at my desk, and I'd take naps at my desk instead of getting real sleep. I'd play shitty casual games, which are like real games, except you don't really enjoy them or get the restorative effect of guilt-free relaxation.

When I realized what was going on, and got out of that gig, I resolved to get out of the world of crappy PHP sites. Around then, I decided to modernize my skills, and try to get back into my first love, working on the frontend, closer to the user.

Node had revitalized the JavaScript landscape, and you started getting real software development rigor on the client side. There was a slew of new build tools, and testing frameworks, and MVC frameworks. When I started looking into this, Backbone was already popular, but I'd read this post by Gordon Hempton: The Top 10 JavaScript MVC Frameworks Reviewed, and it sold me on Ember.

At the time, Ember was still alpha, and there were breaking changes all the time, and I'd decided to early adopt Ember Data, and that was even worse. This was before the Ember Router was figured out, and there was a lot of pain.

At the same time, I hadn't used data-bound client-side templates before, and Ember's computed property system was saving me a lot of work, and I felt like I was understanding MVC in a way I had just failed to before.

I realize now that it's largely because nobody fucking agrees on what MVC really means, but all the same, I feel like I'm a much stronger developer for having learned to use Ember. Like getting free master classes from Yehuda Katz, and the other people who helped design Ember's APIs.

My first Ember app was a grossly ambitious JavaScript version of Rocksmith. I'd wanted a way to do my own exercises, because there was a lot of stuff missing from Rocksmith. Specifically, I wanted to practice arpeggios, and I like quantified feedback.

I did this project like completely wrong. I wasn't using the router at all, but I don't really regret it, because the early router was kind of bad.

I definitely aimed too high for a one man operation. I had to learn the WebRTC API, the Web Audio API, digital signal processing, made up my own pitch detection algorithms, Three.js for 3D rendering the fretboard and notes, 3D rendering optimizations, etc. I was also planning to write a system to serialize exercises as a series of frequencies, and have the game deserialize them as the most convenient fingering.

I got it working on a basic level, started implementing an alternative tablature view, and I just hit a critical mass, I think, where I couldn't change anything without breaking something, and I kind of threw up my hands and abandoned it. I had no experience writing tests, because I was in JQuery spaghetti wild west land prior to this.

Test support in Ember was also not great at the time, and I think I'd used Yeoman to scaffold it, and that was turning into its own headache.

I'm better with Ember now. Ember CLI and some other projects have taken a lot of the pain out of using it. I try to put in some time in the Ember IRC channel and the EmberJS subreddit, helping people out with questions, whenever I can. I'm no Alex Speller, but I think I do okay. I'm advanced enough that generally nobody answers my questions. :(

This is getting into a lot of specifics that I didn't really want to get into. I think I've spent the better part of my day writing, and I want to get some actual work done.

I wanted to say some things about frameworks.

There's a lot of hate going around these days. Maybe just cynicism. People are sick of new JS frameworks popping up every day. There's also a lot of fanboying. My framework is better than your framework, etc.

First, I just want to make a case for frameworks.

Having spent a lot of time making things with vanilla JS, all the way back to when DHTML was a new concept, doing anything complicated by hand, or even with a library like JQuery, is really time consuming.

If you want it robust and working cross browser, there's a lot of tedious ass code you have to write. Trying to cherry pick what to copy over from your last project and whatnot is also really time consuming.

Bower has improved this situation a lot, but it's still clunky to use. It'll pull your packages in, but you have to link them up, possibly tying it into your module system. There's a lot of room for improvement here.

But even after you've jumped that hurdle, you have to figure out your application structure, and what you're going to name things, and what functionality to put where, and what abstractions you're going to use, and what has access to what, and how you're going to test all of it.

Having these decisions made for you is really a godsend. If you can carry those kinds of decisions between projects, that's even better. If you can have people familiar with these decisions before they even know what your project is, that's better still.

What I really love about Ember is that it keeps me from shooting myself in the foot. Not having to dick around in the DOM, updating things after events happen, getting memoised computed properties, easy to use and compose primatives, that's all gravy.

It makes things I shouldn't be doing inconvenient to do (but still possible, as an escape valve), and that saves you and your team time. Now, your intern comes to you and is like, "Hey, how do I access the view from the model?," and you can just beat them over the head with a stick, telling him that he shouldn't even be trying to do that, instead of just having him do it and leaving a mess you'll have to clean up later.

I enjoy the idea of swappable developers. If a project is large in scope, you can bring in anyone who's worked with Ember and they really need the minimum of onboarding before they can contribute, because they'll already be familiar with directory structures, naming conventions, and how to package together related functionality, etc.

With the development of Ember-CLI, this story is even better, since they can use generators to put things in the right place, and the build and testing processes are standardized, at least on the client-side.

I'm happy with Ember. I think it's shaping up well, and I think it's more forward thinking than alternatives. I'm glad that it puts the router center-stage. I'm glad that it favors maintainability over a shorter learning curve. I'm glad that its score on CodeClimate is climbing, while Angular hangs around a 2.

I really respect Yehuda Katz, and the folks at Tilde, and that they opened right up at the first EmberConf discussing standards of behavior, preempting stupid conference drama.

The people I've met at my local Ember NYC meetup have also been really nice. I tend to skip the main ones, and just go to the Hacker Hours. The main ones are pretty much just talks, and they're available on their YouTube channel later, and then they go to a bar or something later, and I never have time for that, so I have a hard time making the trip from Long Island to those.

The Hacker Hours are smaller, more intimate, and there's actual coding and interaction going on. I really look forward to those. Again, I'm advanced enough that the problems that I run into in my projects aren't generally Ember related (I kind of think that only Mike Bostock knows how to actually use D3), so I'm mostly there to help other people out, but that helps reinforce my basics/exposes me to problems I wouldn't have to solve through the normal course of my own projects.