Everything being open-source really helped my learning process, and I quickly learned best practices. Right off the bat I used Heroku as my hosting environment, and I found myself doing lots of the things proposed by 12factor, before discovering that document.

Asset management, and assetify

Soon afterwards I made my first contribution to open-source, in assetify, an asset manager that packages up bundling, minification, and cache busting in a piece of middleware. At the time I didn’t yet have the love I’ve been garnering as of late for applications that strive to be as static as possible, and assetify was kind of very tightly coupled.

A few weeks later, I came across Grunt, and wrote a plugin to match assetify, so that the build step could be automated. I kind of fell in love with Grunt, and I started using it for everything, writing lots of little plugins to use with it.

Later on, I would split the functionality in half, allowing consumers to run the build in a separate process from what was ultimately serving the assets. However, I wasn’t really using assetify anymore, except for this blog, which I rarely worked on anymore.

In retrospect, one of my biggest mistakes at this stage was attempting to use Grunt to not only build the application, but run it, too.

Early Blogging Experience

At the beginning, I wrote blog posts about pretty much anything that came to my mind. To get things going, I figured I’d start by talking about what I was working on in the blogging engine, my only real work using Node, at the time. As such, I wrote focused posts that explained some of the considerations I had to make while building the blog.

I wrote an introduction to SEO and Content Indexing in AJAX applications, which explained the steps I took to enable Google to crawl my site, while keeping the awesome extremely irritating AJAX functionality in place. I say extremely irritating because I made the mistake of not rendering the content server-side during the initial page load, which proved to be a huge hit to the usability of the blog, and something I intend to correct at some point in 2014.

I also wrote small blog posts where I described what I had learned through usability books at the time, such as Defensive Design, a book that can be summarized in designing consistent error messages and interfaces in general, and The Design of Everyday Things. In retrospect, I think these blog posts could’ve been a lot more detailed than they resulted.

Next year, I’ll make it a thing to give each article a few days before hitting the Post button.

My Own MVC Framework

That being said, I was particularly happy with how the code looked like, I didn’t use any libraries other than jQuery (which I regret doing), but keep in mind that at that time I hadn’t even tried out Angular yet. My favorite part was how I made it so that if a response came with a particular HTTP status code, my little framework knew what to do with that. It’d prepare the pertinent validation message view, and place that in the context of where the request originated from.

If there wasn’t a context, then the validation message would pop up in a dialog, amusing stuff! Totally irrelevant in a blog, of course. Developing my own MVC framework was thrilling, nonetheless. Regrettably, I didn’t write it in isolation, otherwise I would’ve continued working on it, maybe when I rewrite the engine I’ll put it to good use again. It had wonderful little things, you’d code up views, bind them to routes, and request that a given view fetches some data from the server before getting rendered.

Of course, the views were rendered using the Mustache engine, but some things, like HTTP requests getting tracked, because I wanted to write a caching layer in the client-side, as to fix the usability a bit without the need for server-side rendering, but never got to it. The thin layer in NBrut did enable things like status code validation, and aborting requests when they weren’t no longer necessary (for instance, when fetching an article and then promptly clicking on the header, getting back to the home page).

Actually using the framework wasn’t as bad as you might think, but the thorough lack of documentation makes it really hard to follow the code around, even for me, and I wrote the thing a few months ago.

In the future, I’ll abstain from tightly coupling major pieces of functionality together, and instead force myself to write reusable components which are well documented.

Reading, Reading, Reading

Late in 2012 I bought a bunch of software related books, and I’ve read a large number of them. Here are the ones I read. Can you spot the one that’s not so much about software?

• Test-Driven JavaScript Development (ebook)
• Responsive Web Design (ebook)
• Mobile First (ebook)
• Lean UX (ebook)
• Testable JavaScript (ebook)
• Programming Pearls
• The Mythical Man Month
• The Design of Everyday Things
• The Pragmatic Programmer
• Surely You’re Joking, Mr. Feynman
• Defensive Design in the Web
• Refactoring: Improving the Design of Existing Code
• Getting Real
• Peopleware
• The Lean Startup
• Becoming a Technical Leader
• The Inmates Are Running the Asylum
• JavaScript: The Good Parts (for the second, and third times)
• Don’t Make me Think
• Mastering Regular Expressions (half of it, as it progresses in an excruciatingly slow fashion)
• Code Complete 2 (about a third, reading it on the bus made my hands hurt, and I gave up)

It’s been really refreshing to read books in print form, as during 2012 I read mostly ebooks, but that wasn’t such a great experience. I could’ve gotten by without some of these. For example, Getting Real was mostly a summary of things I already knew, but it was so easy to read that it didn’t really hurt that much, and Becoming a Technical Leader felt like a self-help book, so I couldn’t recommend it, either. On the flip side, The Pragmatic Programmer and Surely You’re Joking, Mr Feynman were absolutely awesome reads. Programming Pearls was also a fantastic classic I really enjoyed.

I already have a ton of books lined up to read in 2014. In particular, I’d like to read more about compilers, operating systems, and mobile development.

Joining a Community

Ever since I started blogging I became much more aware of the community around me, I started using Twitter (yeah, in 2013, I know), and following a lot more blogs, and a lot more actively than I had been doing. While I might argue sometimes that this might’ve hurt my productivity, I actually just came up with a solution to keep in check my addiction to staying up to date. hose is a command line tool that easily knocks off domains so you get to work.

If you’re interested in joining the community at large, there’s an old blog post which might help you get started. If you don’t really know what to read, check out the RSS feeds I subscribe to. I tend to update that file somewhat regularly.

I came into some issues some time after joining the community. Namely, I started obsessing about different social metrics I can’t really act upon. Closely tracking this data is a waste of time and you should stop doing it. Here’s an awesome blog post on the subject: Managing a Mind.

Next year, I’m hoping not to obsess over page views, stars, and followers.

Becoming Heard

According to Google Analytics, this blog received roughly 100k page views in the March-December period, which feels pretty good for a first year, but I don’t really have any data to compare its performance to. At some point in June I published Uncovering the Native DOM API, which was, I think, the first article in this blog to appear on JavaScript weekly, resulting in an exciting 1000 views in a single day. The follow-up article, Getting Over jQuery, also did pretty good, becoming the most widely read article so far, with close to 10k visits, overall. Here’s a graph showing page views over time.

Popular blog articles are below, ordered by page views.

1. Getting Over jQuery ~10k
2. Teach Yourself Node.js in 10 Steps ~8k
3. We don’t want your Coffee ~7.6k
4. Uncovering the Native DOM API ~5.8k
5. Grunt Tips and Tricks ~5k
6. Deploying Node apps to AWS using Grunt ~3.6k
7. The Angular Way ~3.5k
8. 9 Quick Tips About npm ~3.1k
9. Fun with Native Arrays ~2.8k
10. Continuous Development in Node.js ~2.4k

This was definitely an exciting first year for the blog, and I hope to see the trend rise in 2014.

In 2014 I’ll strive to keep on writing and learning through educating myself as I investigate topics to to talk about on this blog.

Contributing

Lastly, I’m glad about the contributions I was able to make to open-source throughout 2013. Most notably, grunt-ec2, which lets you create EC2 instances and deploy Node applications to them in a completely automated fashion. In developing that Grunt plugin I learned a lot about Amazon Web Services and nginx, and that has been a tremendously rewarding experience for me.

In 2014, hopefully, my book on JavaScript Application Design, which I started putting together in 2013, will go to print, and I’m also really excited about that, being my first book, and everything.

Next year I’ll try and participate in other people’s open-source projects, in addition to developing my own.

Overall, 2013 was a great year where I learned a lot of things, and I hope 2014 is exactly the same in that regard. Happy new year everyone!

Such pony.