Real World Javascript Performance Tips

I’ve been writing a large single page application using Angular that does a lot of data visualization. I wrote a post for New Relic about Javascript Performance tips that have come in handy for crunching through and displaying large amounts of data.

What I Don't Know

I’ve had a couple of moments today where I realized I should speak up about things I don’t know. What I realized is that it’s a signal that I need to ask for help and/or learn something new. I also realized that I’m not alone in how I feel. While it’s scary to say “I don’t know how to do something”, really, speaking up is a strength. It gives voice to those people who feel the same way and haven’t spoken up yet, or may never speak up. And points to assumptions and blindspots in education about the work we do. It’s ok to ask the question (Or ye ole proverb: There is no dumb question). Especially in a space where we so often expect everyone to be an expert. There is probably always something to learn from someone else’s questions.

So, here’s what I don’t know. Without any answers.

I don’t know how to give code reviews.

At my current job we use pull requests and code reviews to ensure a high level of code quality. We ‘sidekick’ the PRs to our coworkers for review and require that the sidekick give a seal of approval before we merge the code into the master branch.

Recently I’ve realized that when my coworkers ask me to review their work I hesitate. deep breath I hestitate because I don’t know what to do. exhale I don’t know what to look for in order to spot possible problems in their code. I don’t know what questions to ask. I mean, I can look for semantic errors, but what about bigger problems? When do I tell them confidently that their work is good enough to ship? And bigger than that, how can I give constructive feedback to someone who is pushing me to approve their work because they are on a deadline?

I don’t know what good tests look like

I totally believe in the power of testing. Someone once told me when I was just learning how to code that tests would be the savior for my anxiety about the code that I write. And how I have learned that that is the truth. However, that assumes that you know how to write tests. This skill has been one of the harder things for me to learn as a developer. People speak lots of important talk about TDD and BDD and the importance of tests. As if writing tests just comes naturally. I think it’s a skill just like writing good Ruby code. In reality there are good tests and bad tests. So, how does one write good tests? What’s the best/easiest way to start writing tests for a piece of code? What should I test exactly (I would bet that no one writes 100% test coverage, nor should they)? And I had bigger questions once I stepped into a legacy code base with a large-ish test suite. How do I judge tests just by looking at them? How can I tell the test coverage? How can figure out areas that need tests?

Now what?

I found it really helpful to figure out what I don’t know. It gives me very clear guidelines for areas I need to improve in. And because I’ve formalized my questions I can sit with more experienced engineers and ask them for help or guidance. I then can share with others what I’ve learned. Hell, learning the skills needed to be a web developer is a moving target and honestly I feel like it’s one of the joys of the job. So, here’s to new neural pathways!

Angular First Impressions & Resources

I cut my teeth with a Javascript MVC frameworks on the granddaddy of them all, Backbone. Managing a page’s events, views and data away with a framework rather than just straight JS and JQuery was a godsend. The learning curve was steep though. There was a lot of confusion on the “right way” to do things and each app required a lot of boilerplate code that needs to be written. A year has passed and things on the JS MVC front have changed significantly. You can take a look at Addy Osmani’s TodoMVC project to how the field has grown. Look at all those options!

My current gig doesn’t require much JS work. I’ve been watching from the sidelines and growing jealous of my peers that have had opportunities to build big single page apps in Angular. Thus, I recently decided to scratch my own itch and started a small project for managing cooking recipes. Time to take Angular to the mat and form my own opinion.

So far Angular feels like magic compared to Backbone. Automatic binding????!?! Say wat?! As with every framework, learning the lingo is key and good documentation is essential. I’m impressed with Angular’s documentation. There are a lot of examples that a user can not only look over but edit and play with. They have a tutorial set up as well. Each step includes instructions on the site along with a code repo to check out. I haven’t downloaded the code so I can’t speak to its usefulness but the instructions alone are helpful with seeing the process involved in adding complexity to an app.

Ryan Bates has as Railscast episode on integrating Angular with a Rails app. I always appreciate how well he lines up his tutorials. They are simple and straight forward. Great for getting a quick overview of how the app interfaces with Rails.

Overall I’m most impressed with the Egghead website. Its vast array of short screencasts provide information in a simple, easy to follow format. Great for taking a break for a few minutes from the regular rhythm of the day. John Lindquist does an excellent job of demonstrating core concepts in a matter of minutes, pointing out gotchas along the way and building on skills throughout the series. If I could forgo sleep I might have watched every episode in one sitting.

I’m excited to see how far I can take my little app with the resources I listed above. I’ll be collecting more tutorials and tips as I go along. If I’m smart I’ll remember to post them here. Until then, data binding here I come!

Collage Machine

I love this form of collage. Layer on layer each items builds to something new. A new dream. A new world. The transformation is unreal.

Tincr + Sass

In an earlier post I talked about using Tincr to help automate the frontend development workflow instead of flipping between the text editor and the browser. Tincr is great when you are working with straight CSS or JS but so often devs like the benefits of working with a compilation language, like Sass or Coffeescript. While we haven’t gotten lucky enough for Coffeescript support in Chrome, Sass support is available.

Sass Setup

1. Install Tincr. The setup instructions vary depending on the type of project. (For the sake of brevity, the rest of this post will assume you are running with a simple http server or loading the files directly into the browser. There are instructions on how to setup Tincr for Rails projects but I haven’t tried it yet so I can’t speak to the difficulty.)

2. Turn on Developer Experiments in Chrome. Go to Chrome’s experiment settings (chrome://flags/), enable the “Developer Tools Experiments” and restart your browser.

3. Enable “Support for Sass”. Open the developer tools settings and select “Support for SASS” under the new Experiments tab.

sass experiment settings

4. Include File Info In Sass Compilation. Sass files will need to include file location information for parsing the source in Chrome. If you are using the Sass gem to generate your css files during development, include the flag --debug-info on the command line with the --watch command. You can also tell Compass to compile Sass files with debug info in a Rack applications config file:

config.sass_options = {:debug_info => true}

This will create a line before each rule in your css that starts with

@media -sass-debug-info{...}

NOTE: You’ll probably want to regenerate the files without the debug info for production environments…Don’t forget to leave off the debug flag before compiling for the real world!!

5. Enable Source Maps. Source Maps are a breakdown of a compiled files initial location. Since we’re including the Sass file info in compilation, we’ll need to make sure the browser can read that info. To do this, enable source maps in the Chrome under the General Settings tab for the Developer Tools.

enable source maps

We can begin editing the file by either clicking the Sass file location shown in the inspector or finding it in the Sources tab in the Developer Tools.

sass location

Next up, tools for reloading HTML files.

Niki & The Dove

I’m a sucker for Swedish pop bands. Niki & The Dove’s songs remind me of Fever Ray, Tegan & Sara, Kate Bush, Bjork and Sinead O’Conner. I’m really enjoying their album. Their videos are pretty great too.


Better workflow habits, Chrome Dev Tools & Tincr

Alongside Sublime Text, Chrome’s Dev Tools are essential to my workflow when debugging and fine-tuning JS and CSS. As my work has moved more and more to the frontend of projects, I have noticed how much I flip between the text editor and manually refreshing the page in my browser.

I thought, there has to be a better way…

Thankfully, there are number of options for automating the frontend development process.

First up, Chrome Dev Tools’ native features.

save css in chrome

My antiquated workflow for css involved copying the new styling and switching back to my text editor to paste it into the CSS file. Besides being too manual, this technique leaves the risk of eagerly refreshing the page and losing changes. With some poking around and experimentation I soon discovered Chrome provides a way to edit the CSS or JS and save directly to the source file (even though Chrome’s Dev Tools are feature rich, I find their documentation lacking — this feature wasn’t obvious to me). When inspecting a file in the source tab, the secondary menu provides a way to save the file. Changes are seen immediately while you’re building your page and they can easily be saved without leaving the browser.

Since there are a number of reasons for continuing to write the bulk of your code in your text editor (syntax highlighting, snippets, etc), Chrome’s native CSS/JS source file saving only covers the debugging/fine-tuning phase of development.

Enter Tincr.

Tincr, a free Chrome extension, couples the cability of saving changes made in the dev tools to the source file along with refreshing those same files in the browser after saving from a text editor. Continue Reading →