ES2015 Generators

I have written a guest blog post, “ES2015 Generators“, on the eNotes developer blog:

Recently I had the opportunity to re-write the content tree control that we use to manage content nodes in www.enotes.com. We’ve all worked with the DOM, which represents HTML nodes in a tree structure but has some challenging deficiencies and a relatively grumpy API, the tortures of which prompted me to take a stab at a smoother tree-like design. During this process I experimented with several approaches to managing nodes in a tree structure, the first of which was a “flat hierarchy” which is as obtuse as it sounds and didn’t get much traction. I then opted for the more traditional parent/child approach, but still wanted a way to treat an entire tree of nodes in a “flat” manner. The ES2015 generator function was my solution…

Read the rest of this article on the eNotes developer blog.

LaunchCode 101, Unit 1

The first unit of LaunchCode 101 is almost complete. Class size has probably halved (based on visual inspection, not exact numbers) since the beginning because, though the material is introductory, it is also challenging. Those who remain have made serious personal effort to stay on track, and the buds of knowledge are finally beginning to bloom.

What’s really interesting to me is how different minds approach the same problems. Just tonight I reviewed three assignments wherein each student achieved the same goal by taking a unique approach. And all three were different than my solution.

The class also stretches my communication skills. When I explain things to other seasoned programmers, I can make assumptions about the knowledge that we already share and talk at a higher conceptual level. For students who have no prior programming knowledge, it is necessary to build a hierarchy of concepts from the ground up. Talking about complicated things in simple terms is both trying and rewarding.

This unit has also been more math intensive than I anticipated, which is good for *me* because I am mathematically weak. Working problems along with students gives me an opportunity to expand my own knowledge beyond the realm of code. And that’s music to a nerd’s ears.

Other than some technical difficulties, LC101 has been a success. Everyone is ready for winter break, but I think students and TFs will return for a strong start in January.

The necessity and beauty of motion

I get lost in my own inner philosophical world when I ride my bike. I don’t know, maybe it’s the scenery. Maybe it’s just all that fresh air rushing by, or the pulse of blood through every inch of my body. It gets me thinking, whatever it is.

And today, as I rode, I thought about motion. Have you ever tried to stand still on your bike and maintain balance? One might think that standing still is the safest way to be, that moving on a two-wheeled bit of aluminum at high speeds is the danger. But the truth is that you only have stability when you’re moving. When you stop, no matter how hard you try to stay upright, you’ll be putting a foot down to stop the fall eventually.

Maybe life is a bit like that. Standing still is deceptively comfortable, but it’s really the most unstable state in which one can be. Movement, motion, forward momentum–those are the soul’s lusts.

I tried to imagine a world with no motion, and it came to me that all of our senses–sight, smell, touch, taste, hearing–all of them require motion to convey anything to our minds. You only feel what moves against your skin. You only smell what wafts your way. Sight is light mercilessly barraging your eyeballs and hearing is vibrations and pressure changes stroking your eardrum. The chemical interactions that produce vibrant flavors is taste to your tongue. All of it requires motion.

So motion gives us stability and knowledge of the world. And attempts to stop motion are frowned on by nature. Inertia compels us in the directions we move. When I ride the switchbacks to the river my brakes remind me the whole way down how much work they do to stop my forward motion.

It makes me feel unstoppable and free, and I think that is something humans need to feel often.

JavaScript Frameworks for Modern Web Dev

JavaScript Frameworks for Modern Web DevI am thrilled to announce the publication of my newest book, JavaScript Frameworks for Modern Web Dev, available now from APress!

A year ago my friend and former co-worker Tim Ambler approached me with a project: a list of strong frameworks and libraries in the JavaScript space that can each be effectively introduced in a single chapter. Over the last twelve months we wrote numerous drafts and revisions, and created a somewhat frightening amount of source code for these sixteen topics:

  1. Bower
  2. Grunt
  3. Yeoman
  4. PM2
  5. RequireJS
  6. Browserify
  7. Knockout
  8. AngularJS
  9. Kraken
  10. Mach
  11. Mongoose
  12. Knex and Bookshelf
  13. Faye
  14. Q
  15. Async.js
  16. Underscore and Lodash

Obviously, the scope of each topic is greater than its chapter, but the book’s goal is to be a quick but thorough introduction to the core concepts in each framework and library. The source code is non-trivial and executable, so a reader can see concepts in action while following along in the text.

Some of the technologies covered have aged (like fine wine!), and some are much younger, but we believe that each has staying power and stands well among its peers. Between us we have used all of these technologies in our own projects and in production deployments, and while we cannot claim complete expertise, we humbly submit that, to the best of our knowledge, the information here is both sound and practical.

We sincerely hope that this book brings much value to you and your team!

 

 

Learning Gulp? Start here.

My only beef with Bleeding Edge Press is that I was asked to review Developing a gulp Edge after I had already spent weeks pouring over documentation, github issues, and StackOverflow questions ad nauseam while trying to learn Gulp on my own. Developing a Gulp Edge is the book with which I should have started.

This book covers all the Gulp basics by having the reader create and run standard tasks in a demo application, publicly available on github. Anyone familiar with build systems will find common case examples aplenty in this book, from SASS compilation, JavaScript concatenation, linting, watching, etc. Each example clearly covers the gulp plugins necessary to accomplish each task, and examples build on each other as the reader progresses.

The real value of this book, however, lies in the fact that it helps the reader navigate a rapidly shifting Gulp landscape by identifying community-blessed alternatives to blacklisted plugins, such as gulp-browserify. This, more than anything else, caused me a great deal of confusion when I initially started using gulp. Google search results lack historical context, so articles that often appeared first in search results actually delivered bad or outdated advice. This book avoids all that by keeping the reader on the straight-and-narrow, by explaining why certain practices have been abandoned in favor of others.

The last three chapters are particularly strong. They move the reader beyond basics into advanced Gulp automation. This includes tasks which enrich the development environment itself, such as running a development server, syncing browsers across devices, and automatic cache busting. The reader is also shown how to speed up builds with caches, so that continuous integration processes and watches run as fast as possible.

The last chapter is a full tutorial on building custom Gulp plugins. This is where the authors really lets it all hang out, as the reader is introduced to vinyl File objects, through streams and buffer manipulation techniques. Once the reader has finished implementing each example he is left with a useful plugin accompanied by unit tests, a code coverage implementation, and a Travis CI configuration–all project features that the Gulp community strongly encourages, nay outright demands, of any Gulp plugin author or contributor.

Developing a Gulp Edge has a single Appendix containing a long and very useful list of Gulp plugins for most any development task imaginable. I will refer to this Appendix often, and with fondness.

While this book does have a few spelling and grammatical errors its overall style is clean, friendly, and concise, and the content is structured quite well. Each chapter, each example, builds on previous knowledge in such a way that reader has a strong grasp on what Gulp is, what it does, and how to leverage it for daily use.

Conditionally adding object methods

I stumbled my way into an interesting experiment today where I discovered that, within a JavaScript constructor function, one might conditionally add a method based on whether the prototype has that method already or not.

This code ensures that when the method `bar` exists on the prototype for Foo, the instance implementation of `bar` added in Foo’s constructor won’t be applied. So the instance implementation is kind of like a “default implementation”. This might really only be useful if a constructor function’s prototype property changes over time, a scenario that is not likely to occur in most applications.

This came in handy for me while writing unit tests, however. I have a complex mock that creates an object for which I control both the prototype used and the constructor function. What I do not control, however, is how the object is instantiated within the module I am testing because it is ultimately instantiated through a factory function. So I can’t intercept the object and just “append” an overriding method onto the instance; the function must be added to the prototype before the object is even created by the factory function. But if a method is created on the prototype AND the constructor defines a method of the same name, the constructor function’s method will take precedence in the prototype chain. Instead, I used the conditional logic shown in the gist above to ensure that the method I define on the prototype (which I control for the purposes of the test) is the one that will be used.

There are probably much better ways to accomplish this. Conditional constructor methods reek like a code smell, so I would probably not implement anything like this in production code. For a little unit test mock, though, it is a fun thought experiment.

hintme

I use jshint to lint JavaScript code in my projects. Typically I include a project-wide .jshintrc file which contains a set of the linting options I wish to be applied whenever jshint scans my code. I keep a gist with a list of all possible options and the settings I normally use. This works pretty well but I thought it might be nice to create a tool that would interactively prompt a user for jshint settings and then create a .jshintrc file based on user response. So I created hintme, a small node.js CLI tool that does just that.

hintme

Right now it iterates through every jshint option and prompts the user for a setting value. Each setting has a default value, which may be chosen by simply hitting enter at the prompt. Defaults were chosen based on a simplistic criteria, one which I tend to refine a bit:

  1. the default for enforcing options is always TRUE
  2. the default for relaxing options is always FALSE
  3. the default for environment options is always FALSE

I also want to add some better command arguments, such as being able to specify known settings via a switch (e.g.: –use=eqeqeq=true;forin=true). The user wouldn’t be prompted for these settings since they’ve been specified already.

The –live=true switch forces hintme to screen-scrape the jshint options page and then prompt the user for the most “current” options instead of using the options.json file included with the hintme module. This is probably a tenuous way to get the most current options but it works for now.

I intend to add a suite of unit tests soon, and probably break up the code a bit. Releases < 1.0.0 should be considered rough drafts.

If you have any feature suggestions please leave a comment!