Author Archive

The Modern Front-End Workflow—From Start to Finish

January 30th, 2014 by Harry

Front-end engineers have gone through a bit of a renaissance in recent years.

There’s been a wild and wonderful spurt in innovation that has completely changed what it means to be a front-end developer.

We now have a vast and wide array of tools available to us, allowing us to develop faster and smarter.

We now can push the limits of what a modern web browser can do, accomplishing things that two years ago seemed impossible.

Bottom line, right now is an amazing time to be a front-end developer.



Today there is almost zero friction to getting set up with a new project. Everything that you need to get started is only a few key strokes away thanks to some powerful new tools.

Git is the version control system of choice for most developers nowadays. It makes sharing code easy and frictionless. When you want to get going on a new code base you only have to run the simple git command of git clone and all the code and all of its history is downloaded directly to your computer.

NPM is the node package manager. It allows developers to package their nodejs code a self contained module and then share it with the community. There are npm packages that provide almost every type of functionality you can imagine, allowing you to leverage the work of the community. Each new project has their own unique set of dependencies they require for them to work. To get all these dependencies installed locally you only need to run npm install, which downloads and installs everything you need.

Bower is a package manager for third-party web libraries. Historically if your project requires jQuery be included you would have to navigate to the jQuery website, download the file, extract it, and move it into your project. Bower simplifies that process by giving you the command bower install which handles getting jQuery into your project.



Actually coding and developing your project is where most time is spent. Nowadays this is one of the most enjoyable parts due to the many wonderful tools available. These tools make dev’ing so smooth that I’d dare say it makes it fun. Scratch that - it makes it oodles of fun.

GruntJS is the most popular task runner amongst front-end developers. There’s already a huge community of grunt plugin authors that to date have written over 2,000 Grunt plugins, all of which are immediately ready for your use. Grunt allows you to automate rote tasks without breaking a sweat. For example if you need to compress all your jpg, gif, and png files you can use the imagemin grunt task .

CSS Preprocessors like LESS, Sass, or Stylus have made it easy to architect maintainable, extendable, and modular CSS. Among the many features that CSS preprocessors provide the two of most value are without a doubt nested selectors and variables. Having the ability to define a color variable in one location and use it throughout allows for a flexibility in CSS that did not previously exist, yet one that was sorely needed.

LiveReload changes the way you develop, as it brings a fluidity to your development flow that you didn’t realize you needed. Whenever you change a file that you’re working on LiveReload will notice that it changed and refresh your browsers so that you can immediately see your changes in place. No longer do you have to save a file, switch to the browser, and then refresh the page. With live reload after you save a file the browser will refresh itself, saving you time and grief.



When you’re ready to push some of your code into the wild it’s always a good idea to review it with your team and run it through some code quality and style tools.

A GitHub Pull Request is one of the handiest ways that you can rally your team around vetting your changes. After opening a pull request you’re given a page that allows you to clearly state what you changed along with a view that shows the changes you made. Coupled with a robust comment system, a GitHub pull request makes it easy for your team to review and give feedback on changes.

JSHint is a tool that programmatically finds errors in your code. It’ll prompt you if you have a function with two arguments, and the second argument is never used, or if you’re missing a semicolon where one should be. All these things ensure your code is in good shape, allowing your teammates to focus on other things that aren’t as nit-picky as JSHint.

JSCS is another tool that is great to have in your repertoire. JSCS is a JavaScript code style checker, focusing on the style of your code and not the quality. You define what code styles you want and when you run your code through JSCS it’ll alert you if there are any areas of your code that are not inline with your project’s expectations.



Getting your code from your computer out into the world is the best part of development, as it’s when you get to share all your work with the world at large.

Continuous integration is a practice that enables and encourages getting your code to production frequently and without fear of breaking anything. A CI server will automatically perform tests across all products, not just the ones you touched. If any tests fail alerts are sent out and any changes to production are halted, preventing regressions from reaching production. When all tests pass your changes are merged into the production ready branch, assets compiled, and production is updated.

This makes the entire process of getting your changes live easy, effortless, and safe. You can view the progress of the CI server as it chugs along, letting you be kept in the loop of what’s going on without having to push the process along yourself.


The life of a front-end developer has never been easier. Browsers are getting better every day, and the tools we have at our disposal have never been better.

No longer are we wallowing in the shadow of legacy browsers, but we’re barreling ahead to stretch what’s possible in the browser.

The processes outlined above lets you worry less about minutiae and just focus on development and the product.

The life of a front-end developer is pretty damn good.

Data in Your Menu Bar—Meet the Chartbeat Notifier

December 4th, 2013 by Harry

chartbeat notifier


Hack Weeks at Chartbeat are always a time of joy. A time of joy for trying and learning new things. It's a great opportunity for everyone at the company to stretch their minds and tackle new challenges they wouldn't otherwise experience. We get to pair up with people we don't usually get a chance to work with, and we get to play around, creating things that sometimes become indispensable for our clients.

Two Hack Weeks ago I worked on a project called Chartbeat Notifier.  It was started by our former CTO Allan, and he had already completed a large chunk of it.  However it wasn't completely finished, nor was it in a state that we could share.  So I finished the Notifier, polishing the parts of the project that needed a little more TLC.

This most recent Hack Week, I pruned off the remaining rough edges and it is with great joy and pride that we are releasing the Chartbeat Notifier project as an open source project!

Chartbeat Notifier is a native Mac application that lives in your menu bar.  For your domain it can show one of two metrics in an always visible location:

 1. the number of concurrent visitors on your domain

2. the average Engaged Time of all the users on the domain

Either number will be always visible in your menu bar, and is continuously updated as the day goes on.

chartbeat notifier


Chartbeat Notifier also serves as a handy way to quickly jump into your dashboard.  Simply click on the Chartbeat menu bar icon and the 'Open Dashboard' link and you'll be taken directly to your dashboard.  Quick and easy, just the way we like to keep things.

There's only one thing that I love more than Hack Week, and that's when we are able to share our hacks back to the community.  Click on over to the Chartbeat Notifier project page and click the download link to get started!

PS- To see more of our great hacks in action, visit Chartbeat Labs.

Links We Like: Frontend Development and Design

September 20th, 2013 by Harry


Hello and welcome back to another fun roundup of new trends and technologies in the world of frontend development!

In this fast-paced field things are always in motion. I'm here to help you stay on top of what's new and what you need to know.

To start things off let's jump into a nice article that explores the what are the top languages used on GitHub in 2013 (so far). Compiled using Google BigQuery the results are in line with what you would expect of GitHub developers: JavaScript and Ruby take the top spots (first and second respective). What does surprise me is that Java is way up on the list at number 3. I suppose that should be expected given Android is built in Java.

Taking a detour into more tech-heavy articles, I came across this article which shared a tip on how to ignore library code while debugging in Chrome. Why is this cool? Well if you've ever been neck-deep in a call-stack trying to figure out a bug's origin you can sometimes get lost in the libraries you're using on the page (e.g. jQuery, Backbone, Angular). What this trick allows you to do is have these libraries excluded when debugging, allowing you to focus only on your code! Pretty handy!

Another handy trick is this break-on-access repository on GitHub. If you want to spy on when a property of an object is accessed or modified this library will allow you to enter the debugger at that point. Very handy for situations where you may not know when an object is being modified, but you know that it is being modified.

A fun Tumblr blog popped up over the past week, highlighting what applications could look like if they were designed for iOS 7. With iOS 7 released on September 18th you can bet you'll see its design ethos echoed across the internet. This is a nice way to prepare yourself.

Along with finding inspiration for how to design for iOS 7, take a look at this very comprehensive post about how to create a web app that looks like an iOS 7 native app. Especially useful if you're looking to create a Phonegap hybrid application. There are many tips, tricks, and nuanced details in this blog post that will prepare you for developing iOS 7-like web apps.

And there you have it! This week's roundup of what's new and what's being talked about on the world wide web. As you can tell, Apple still has quite the influence - punditry aside. The release of iOS 7 is only the start of ripples that will grow.

As always, keep learning and looking for what's new. I'll be here doing the same.


Harry also maintains a personal blog at

Links We Like: Frontend Development and Design

August 2nd, 2013 by Harry

As a frontend engineer at Chartbeat I am constantly on the lookout for the next new and exciting web trend. Things change so quickly on the web that if you don't keep yourself constantly immersed in learning you can easily fall behind. Personally I take great joy and pride in staying ahead of the ever-changing curve that is frontend design and development. One of the main ways that I keep myself educated is by always being on the lookout for new articles and resources as they surface. I've thrown together a sampling of recent articles that I've been reading. Their topic matter ranges but inevitably the focus is on web development, teaching and guiding readers to be the best engineer they can be.
  • Making - A wonderful in-depth article about the process taken to create
  • Tiff - if you're looking to brush up on your knowledge of fonts and typography this is an invaluable tool. It allows you to visually see the difference between fonts.
  • - good code is worth almost nothing without good documentation. is a new tool that automates the process of creating documentation for your software.
  • ECMAScript 6 and Proxy - a forward thinking yet timely article discussing the future benefits of the Proxy feature set to land in the next version of ECMAScript - aka JavaScript.
  • SlimerJS - the Gecko equivalent to the Webkit powered PhantomJS. Basically a headless browser that you can script. Great for testing.
  • Mind the Gap - An interesting analysis of the gap that arises between the conception and creation of a product.
  • The Making of Face to GIF - one of the coolest tech demos I've seen in a long time is the very awesome Face to gif tech demo. It lets you take a gif of your face directly from your web browser. This article discusses how that demo was created.
I hope you enjoyed this link roundup. Let me know what you think on Twitter!

Taming The Jungle: Working With New Code

July 8th, 2013 by Harry

Reposted from Chartbeat Engineer Harry Wolff's personal blog, An undervalued skill of the common developer lies in their ability to navigate and explore a new code base. Although not the most glamorous or fun task, it is the one that almost always consumes most of a developer's working hours. Despite the percentage of time this work consumes, it is a topic that is seldom discussed on the internet. Reason for that is simple: it's not fun. It's not fun understanding someone else's code, pondering why they arranged code the way they did, why names are named the way they are, and what performance enhancement drugs they were on. At every job I've started I've had to enter the jungle that is "someone else's code". Along the way I've come up with a few strategies to mitigate the pain. Some are obvious while others are even more obvious. And please: if you know of any other strategies to reduce the pain of learning a new code base I would love to hear it. I'm sure everyone reading this post will appreciate it as well.

How Is The Code Structured?

First thing I always ask when encountering a new codebase is, "How is the code structured?" To elaborate: from the time a client makes a request to when the client's browser renders the web page: what is going on? Where is the entry point? How is it funneled through the server side code? Where is the client side code initiated? Where are the pertinent files in the directory structure? Are there any weird gotchyas with callbacks executing critical code in a non-obvious way that without the callback nothing would ever render? These are the questions I ask both myself and my new co-workers. I try to get a grip on the code, understand the general lay of the land if you will. This is the part of the process where I want a high-level view of "what is going on?". The details of the process are distractions at this point: all I need is a working knowledge of all moving parts. This process takes anywhere from a day to a week in my experience. Usually I take around two days to get a general idea of how the code is structured and what it's comprised of. At this point I have a naive understanding of the entire system, enough that I feel confident that I'll be able to make changes, which is the second thing I usually do.

How can I change code and see the results of my work?

In the great words of Yoda, "Do or do not, there is no try." There is no better way to learn something than by trying it out and actually doing what you are learning. This is true for everything (everything!) including learning code. When I am given a small starting task at a new job I take an oblong approach: rather than attack it head on I reduce the task to the smallest unit of provable success. For example if I am tasked to add myself to the about page I'd want to do two things:
  1. Find the file that I think is the about page.
  2. Add the most obvious edit to make sure that a) I'm editing the right file and b) that there is nothing else in-between editing the file and seeing that change reflected. (My personal favorite edit is along the lines of <h1>Pandas Rock</h1> appended to the <body> of the page.)
Rather than assume I am doing everything correct, I actually prove it to myself and avoid working on something that could very well be wrong. The about page that I'm editing may be an outdated one that is no longer used, however still exists in the repository and as such is often confused with the one used in production. By simply testing to make sure I'm in the right place, and doing the right thing, I save myself wasted dev cycles and frustration. This process of orienting myself before making changes further cements my knowledge and understanding of the code base, and prevents me from getting lost. By forcing myself to always breach the surface and take a gasp of air (i.e. seeing my changes reflected) I'm able to take a dive into the code base to find what I need. As I'm able to hold my breath longer (i.e. my knowledge of the codebase increases) my need to come up for air and double check I'm in the right place decreases.

What were the design ideas?

After my memory of the code base begins to solidify and coalesce I begin to ask more introspective questions. I begin to wonder why things were done the way they were and what was the reasoning behind these decisions. These questions allow me to gain a deeper and more intimate understanding of the code and my co-workers. Rather than assume an aspect of the code I find un-intuitive is the result of poor decision making I can ask to find out how it came into existence. Perhaps as the project was developed requirements changed, causing a rush of modifications that resulted in the code that I had just assumed was the result of poor choice. I may have even taken my assumptions as far to assume the developer that came before me hated his own kind and wanted all those who came after him to suffer! What a thought! Through understanding of the why I can at least appreciate and reconcile my differences with the code rather than begrudge it. Not only that I can find my co-workers dislikes and work together to fix our problems. Another benefit of understanding the ideas behind the code is its ability to strengthen and deepen my knowledge. While I may have wondered why some component had a certain name that was not representative of its usage, I may learn it once did what it is named to do and why it was changed.

Getting out of the jungle alive

Every code base is unique. Sure, there are overlaps that will make learning a new code base easier: if you use a framework (Ruby on Rails) or follow a common architecture (MVC). However the spirit of the code lies in the details, and those are near impossible to clone. So you must enter the jungle that is a new code base. With or without trepidation, you must plunge in head first, without knowing what you'll find. And after some time you'll exit the jungle. You'll come out wiping your hands free of dirt, turn around, and see a playground with a brand new swing set. It's the same code base, but now you know what's inside, and you know the fun you can have. Sure you may add some renovations (always need a vomit wheel), but that jungle will have been tamed. And in taming the jungle, you'll now be free to build your own. If you want to follow my adventures in code, visit my personal blog Find me on twitter @hswolff. Feel free to reach out to me in the comments section.