# Processing is so cool

I’ve begun reading the excellent book, The Nature of Code and watching its accompanying videos by the equally cool Daniel Shiffman, and I’m truly fascinated by what I’m learning. Daniel uses a casual and fun teaching style to explain how to get started with creative coding using Processing, to create motion graphics that literally come to life.

I’m relearning some of the math and physics I learned in college, but this time within the context of actually creating something with them. It’s a really gratifying experience to instantly see what these equations and rules actually mean in the real world (or at least in a simulation of it), and it’s profoundly shifted my perception of the real world more toward its underlying mathematical, beautiful magic. I’d once taken a Computer Graphics course in college, but this time around, Processing makes it really easy. There’s no need to dig into the guts of the OpenGL API to make something pretty.

In learning how physical forces like wind and gravity work, I created a demo of the ship from the game Asteroids. As I built my knowledge through the first few chapters, I kept adding what I learned, with surprising results.  Click each picture to see a live demo. Here’s the first go I had with it:

Asteroids Demo – First Go

Just a basic demo — flying ship with the arrow keys, pixel bullets with the shift key, and teleporting with spacebar. As I learned about Newton’s law of universal gravitation, I decided to make the demo more like the classic game, Space War:

Asteroids Demo – One Planet

A single “planet” at the center of the screen, ever pulling the ship toward it. As I relearned trigonometry, the motion of the planet became more sophisticated, now revolving around a center point:

Asteroids Demo – Revolving Planet

Now for the cool part, objects with different masses gravitationally affecting each other! This time the demo behaves more like a particle system:

Asteroids Demo – Planets with Gravity

Finally, I wondered what the screen would look like if I removed the code blanking out each video frame before the redraw:

Asteroids Demo – Total Light Show

Ooo, pretty.

# Minimal Responsive Web Design with SASS

I wrote a while ago about my adventures with Twitter Bootstrap and SASS, trying to discover a way of getting the same effect of Bootstrap’s presentational classes (like .row , .span6 , etc.) without actually including them in my HTML. The conclusion, at least when it came to media queries, left me with mixed feelings. It wasn’t effortless to pull off, and not very flexible.

With one of my ongoing projects, grunt-express-workfow — a scaffold for new web applications — I needed a way to easily incorporate Responsive Web Design (RWD), and I wanted to do it in pure SASS. With a little bit of ingenuity and a little bit of reverse engineering Bootstrap, I created a SASS partial that can do just that.

I call it, rather uninspiringly, responsive-sass-grid. It’s a small, tight module that gives you nothing but SASS mixins and optional CSS classes so that you can define your rows, columns, and breakpoints without putting anything extra in your HTML. You can alter how many columns fit in a row and the spacing of each by declaring a couple of variables, and even define different breakpoints for different elements, just by including one of a few mixins with a couple of arguments. Check out grunt-express-workflow to see an example, or read the documentation and try it out for yourself!

# Running an Express server with Grunt and Yeoman: Part 3

Back in part 1 of this series I introduced a small number of tools that make a web engineer’s life easier: Grunt, Yeoman, Express, and Nodemon. In part 2 I provided a repository of files and explained how to use them to have a running server that’s capable of automatic browser and app server reboots for rapid development.

Now, in part 3, I’ll explain how we can use this workflow to automatically run unit tests when development files or test files change, backend or frontend, and how to expose internal functions and properties in our Node or RequireJS modules to the testing environment so that we get less bugs. Onward!

## The Skinny

Our repository has been outfitted with Karma, Mocha, Chai, Sinon, Sinon-Chai, and Istanbul. In our starter set of files in the repository, a neat set of examples have been written to familiarize you with how they can fit together in your project. In addition, Grunt tasks have been included to leverage these tools to run your unit tests and code coverage whenever your files change.

You don’t need to do anything more than create test files in the  test/  directory that end in .spec.js , create client-side files in app/scripts/app/ , and server-side files in lib/ . In the  coverage/ directory you’ll find  .html files showing just how thorough and robust your tests really are. This’ll give you a greater level of confidence in your work now and in the future.

### Special Notes

There’s an issue in the  grunt-contrib-watch task where if two targets are watching the same file(s), only the last defined target will run if the file(s) change. Right now this means client-side tests will run and livereload will not when client-side scripts are saved. You can switch this behavior by altering the watch target order in Gruntfile.js . Watch grunt-contrib-watch issue #25 and upgrade your local copy of that library using  npm when it’s fixed. The  grunt-contrib-watch task has been updated and  grunt-express-workflow has been updated to include the fix! Thanks to the  grunt-contrib-watch developers for a fantastic tool.

Since your RequireJS client-side development environment,  grunt build environment, and test environment are by necessity all different, it’s important that you maintain each environment’s corresponding RequireJS configuration file. These are found in app/scripts/app/config.js ,  Gruntfile.js under the  requirejs task, and test/frontend/app/config.js , respectively.

You can configure the  grunt-karma task to use multiple browsers for testing. Adding  'PhantomJS' as a test environment gave me issues, but they turned out to be that my version of node was outdated and Chai has an issue with `should` on PhantomJS. These can be fixed by running  Node >= v0.10.12 and with the shim I included in test/frontend/app/config.js .

### Running Tests Manually

The  grunt test command is configured to run your frontend and backend tasks with code coverage. This can be changed easily to no coverage in the Gruntfile . The  grunt build command is configured to run these tests and output a production build of your application if they pass.

You can run tests for either your frontend or backend files right from the command-line. If you’d like to run your backend tests with coverage, use grunt backendCoverage ; without coverage, use grunt simplemocha:backend . This command is significantly faster.

For the frontend, the command for running tests with coverage is grunt karma:appContinuous . “Continuous” signifies that the test run is also a single-run, not a long-running process. For a test run without coverage, use grunt karma:appContinuousNoCoverage . The  karma:app and  karma:appNoCoverage tasks are long-running processes that are meant to be run alongside the  watch task if desired. The  karma:app task is configured this way by default, with  karma:app:run declared under the  watch task, taking advantage of the Karma server started by karma:app in grunt server .

By modifying the  watchgrunt servergrunt build , and  grunt test tasks in the Gruntfile , you can alter what types of tests run and how.

## What is Istanbul and what is code coverage?

Istanbul is a fairly new tool that will give you insight into how well your test cases are covering your production code. It “instruments” your files and when the tests are run, records every time a function, statement, branch, etc. is executed. You’ll know where you may need to aim future tests. Here’s an example of what an Istanbul report looks like.

## Running Server-side Node.js Code in a  test Environment

Server-side tests run with the global node.js variable  process.env.NODE_ENV  set to 'test' . You can take advantage of this in your server-side code by exporting more variables or functions for testing when a test for that is true, like so:

## Exposing Internal Functions and Properties in RequireJS Modules to your Tests

Exposing internal functions and variables in RequireJS apps to your test environment is a little more complicated. Since RequireJS modules export their returned value whenever they’re require()d, we’ll need some way to export something different when they’re require()d in a different context. Has.js to the rescue!

By including has.js in your development environment and including a  has property in your  Gruntfile.js for the  requirejs build task, all you have to do is register a global environment variable with  has.add() and a  has() test in your module, and when your module is require()d, it can potentially return something completely different than it normally would. Anything you want. When you run grunt build , that entire  has() branch in your module is removed, leaving only your production code. Let’s review a few files to get a better picture of what’s going on.

And that’s how we can make our RequireJS tests a lot more robust!

## Expanding to More Namespaced Client-Side Apps

The folder structure and  Gruntfile.js are organized in such a way that the main client-side app lives in app/scripts/app/ . This allows us to make other client-side apps that use RequireJS but that don’t interact with and are separate from the app that lives in app/scripts/app/ . For instance, if you have a single-page app with its own modules and want to create another single-page app for another part of your site with its own modules, it’s possible to do so by creating another namespace for it in, say, app/scripts/otherApp/ . Now all you need to do is set it up with Grunt so that it’ll watch files for changes and run your tests. You’ll need to:

• copy the  karma.app.conf.js file to a separate  karma.otherApp.conf.js file
• make a  karma:otherApp target in the Gruntfile’s  karma task and include it in the  grunt server task
• reference the  karma.otherApp.conf.js file in the  configFile property of your karma task target in the Gruntfile
• make a  karma:otherAppContinuous target in the  karma task and include it in the grunt build task
• include a  karma:otherApp:run into the  tasks array of the  karma target of the  watch task, or modify the  watch task to run tests and  livereload on your  karma:otherApp:run task only when its files change

It sounds complicated, but once you get started it’ll make a lot more sense, for sure.

Happy hacking!

# Running an Express server with Grunt and Yeoman: Part 2

Update: The grunt-express-workflow project has been updated to include a full front-end and back-end testing framework by leveraging Grunt, Karma, Mocha, and Istanbul. Read all about how to test your code easily in part 3 of this series.

In part 1 of this series I introduced a small number of tools that make a web engineer’s life easier: Grunt, Yeoman, Express, and Nodemon. In this second part of the series I’ll explain how to get started using them together. You’ll soon have a server running with LiveReload that’s capable of automatic browser and app server reboots for rapid development.

## Getting the Right Tools

The first thing you should do is download and install Node.js if you haven’t already. It should come with a package manager called npm. You’ll need to install the proper tools with it:

I recommend having a tool like nvm to manage multiple local installations of node with user privileges.

## Quick Start

I’ve set up a repository of all the files you need to be up and running. Be sure to read the repository’s  README.md to get an idea of what it’s all about. As I fleshed out this project, I realized how much I had changed of the original Yeoman scaffold. If you’re interested to see what an initial Yeoman project directory would look like, type  \$ yo webapp into a terminal that’s inside of an empty directory, follow the prompts, and poke around a bit.

What we’ll be referencing from here on are these repository files I’ve heavily modified from that initial Yeoman scaffold.

Now you have a copy of the repository to play with.

These will install all your server-side and client-side dependencies. Then:

I won’t be going into great detail about Grunt or the included Grunt plugins in this post — for that you can research the Grunt documentation and the documentation of each plugin — but by poking at the files in this project and reading Gruntfile.js you can get a pretty good idea of how it all works together.

Now your Express server is running from  server.js with a minimalistic client-side app, and with tests! Expand on it to your heart’s content and watch happiness spread out across the land.

## What’s Included?

Popular client-side libraries included and configured:

Server-side libraries included and configured:

Testing Libraries included and configured:

Grunt plugins I included in  package.json and configured in  Gruntfile.js are:

## Caveats

1. If you want to  grunt build for a production-ready build of the project with Handlebars included, you’ll need to change the Handlebars runtime library code from the initial var Handlebars = {}; to  this.Handlebars = {}; so that it’ll be attached to the  window and found by RequireJS modules. It seems this is being fixed upstream with the Handlebars developers at the time of this writing.
2. There’s an issue in the  grunt-contrib-watch task where if two targets are watching the same file(s), only the last defined target will run if the file(s) change. Right now this means client-side tests will run and livereload will not when client-side scripts are saved. You can switch this behavior by altering the watch target order in Gruntfile.js . Watch grunt-contrib-watch issue #25 and upgrade your local copy of that library using  npm when it’s fixed. The  grunt-contrib-watch package has been updated and  grunt-express-workflow now uses the new version. Many thanks to the maintainers!
3. If you want to test your media queries in old IE with respond.js , be sure to modify your  Gruntfile.js to switch your  compass:server options from  debugInfo: true to debugInfo: false . This removes Compass’ ability to inject certain media queries into your CSS, which would make it easier for you to debug your styles in modern browser debuggers, but confuse the logic of ``` respond.js.```

## Differences to yo webapp

Since Yeoman is being worked on for a 1.0 release, there are a few things that we can upgrade in the meantime to make a better experience for ourselves. Here’s what I did:

• Bower’s  component.json has since been standardized to bower.json
• grunt tasks  grunt-contrib-livereload and  grunt-regarde are replaced with  grunt-contrib-watch ~0.4.3, which does file watching and livereloading so that you never have to manually refresh your browser to see changes again
• Client-side and server-side scripts and tests are watched for changes, which trigger a run of unit-tests and Istanbul code coverage output in the  coverage/ directory
• grunt server  will now compile any necessary files and launch nodemon tasks like Express and node-inspector
• grunt-concurrent ~0.2.0 installed, to be able to see nodemon terminal output and run  node-inspector and  watch concurrently with the Express server
• the RequireJS task will concatenate and minify scripts in the dependency graph into one file for production. The smaller almond loader will be used, and the built script will be wrapped in an IIFE so no script variables (even  require and define) are exposed globally. The project now uses grunt-contrib-requirejs , which does not yet have almond support.
• the  useminPrepare task will now refer to  usemin.html to prepare script files in the usemin task. The useminPrepare and usemin tasks now produce a production build with file revisions for cache busting. It will copy and update your Jade views automatically into the  dist/views/  folder.
• grunt-nodemon is installed, and its settings are set in a variable in Gruntfile.js
• The RequireJS  path settings used in  Gruntfile.js for grunt build have to be maintained in alignment with the client-side app’s main RequireJS config file and test config file, in this case <span class="lang:default decode:true  crayon-inline">config.js. The usemin task now takes care of this, but the grunt  requirejs  task can be used to override any options you need to.
• The  relativeAssets option in the  compass grunt task has been changed to false , since  relativeAssets: true produces incorrect references to sprites in the final CSS. Images are now referenced relative to the definitions in the root file compass.rb .

## How does it work?

At a very high level, the  grunt server command will start a bunch of tasks that do quite a few things:

• Compile and watch files for changes
• Implicitly set up intermediate folders for compiled files
• Run unit tests and code coverage analysis on front-end and back-end code after every change. Here’s an example of a coverage report with Istanbul
• Start up your Express server serving your local and implicit files and directories, with Jade templates replacing what would otherwise be static HTML files
• Start up node-inspector so that you can debug your Express server inside a WebKit-based browser like Chrome, Chromium, and Safari!

### Client-side files

In the root directory is a folder called app/ . That’s where all your client-side files go. The  app/scripts/ directory is for scripts, and has three folders:

• app/scripts/app/ : all scripts related to your app are namespaced into this directory. The idea is that if you have multiple apps, or multiple pages using different scripts, they can all be grouped separately from one another, namespaced into their own folders. The RequireJS task in your  Gruntfile.js is the place to declare new namespaced app targets for the build step.
• app/scripts/misc/ : for scripts not intended for use with RequireJS. During a build, they’ll be wrapped in an IIFE, minified, and kept as separate files for use with the  <script> tag.
• app/scripts/vendor/ : scripts for use either with RequireJS or not – components you couldn’t otherwise get through Bower.

When you run grunt server , your client-side files will automatically be watched for changes, with unit tests and code coverage run and the browser refreshed when they’re changed. In the case of SASS changes, the grunt  watch task will compile the CSS and inject it into the page without a refresh required. When edited and saved, any watched files that are compilable will automatically be compiled into  .tmp/ with an identical file structure. The server is configured to also serve files out of  .tmp/ (along with app/) during development. Files watched are:

• app/scripts/app/rawTemplates/ : your Handlebars templates
• app/styles/ : your SASS files. CSS files in this folder are also watched for changes
• app/images/ : for your images of cats and/or kittens

The  app/images/sprites/ folder is special. Each folder you create in it should represent a spritesheet you’d like to create for production that’s composed of the images inside. You can tell Compass to create these spritesheets using Compass’ sprite helpers. Once you do a grunt build , what’s left inside the  dist/app/images/sprites/ folder is your compiled spritesheets, named by the original folder name. An example of this is in the project. Try it out for yourself!

The  dist/ folder is automatically regenerated every time you run grunt build . It’ll hold all your usemin-updated Jade templates in dist/views/ , and in  dist/app/  will hold your compiled SASS and Handlebars templates, and concatenated and minified scripts and libraries, along with efficiently-processed images. After a build you can freely delete the  usemin.html file in the  dist/ folder, and if you’re using almond with RequireJS, the  components/requirejs folder. The  cssmin task in  Gruntfile.js determines which CSS files in  .tmp/ are combined and placed in dist/styles/ .

### Server-side files

With grunt server , Express will run with the  env environment variable set to  'development' by default, which you can detect in your server scripts with  app.get('env') === 'development' in order to branch into a different set of behaviors, such as setting certain variables in your views for more verbose error-handling. Files will be served out of  app/ and .tmp/ .

The grunt  nodemon task generates a  .nodemonignore file in your project root and is configured to ignore your client-side files when watching for changes that will restart the server. You can edit which files are ignored in Gruntfile.js .

After a build with grunt build , you can invoke your node server directly for a production environment with  \$ node server.js production or \$ NODE_ENV=production node server.js . The  dist/ folder will be used for serving files, and not  app/ or .tmp/ . If your server-side views with Jade are set up with usemin to process your css and js files, the switchover should be seamless.

The file  node-inspector.js exists so that node-inspector can be spawned by nodemon when running grunt server .

If you prefer not to use Jade, simply remove the  app.get blocks in server.js  referencing res.render() . All html files in the  app/ directory will still be served as expected. You’ll be missing out on all sorts of wonderfulness, though!

## Tests

Karma, Istanbul, and Mocha run automated tests and coverage for the frontend and backend. This happens when development files or test files are changed during a grunt server  run, or when the  grunt test command is run on the command line. See part 3 for an in-depth explanation.

## Debugging the Server with node-inspector

Once you run  grunt server you can debug your node server on the fly by opening a new tab in a WebKit-based browser and navigating to http://127.0.0.1:8080/debug?port=5858. Since nodemon starts node in  --debug mode, grunt is configured to run a separate node-inspector process that will attach to that debug session and relay requests on that URL to a WebKit Inspector view, where you can use breakpoints and step debugging just like you’re used to on the client-side.

For instance, if you set a breakpoint in the  app.get('/') block and refresh another tab running your client-side app — http://localhost:9000 in this case — the response from the server will be paused while you switch to your node-inspector tab and step through the server code to squash bugs. Resuming script execution will finally send the response, even if the request has already timed out. This is all really amazingly cool and saves countless time debugging your server application, so I encourage you to read the node-inspector documentation and use it to amazing effect.

## Conclusion

On to part 3 for how to work with unit tests and code coverage!

# JavaScript and the `delete` keyword

You learn something new everyday. Today I learned that the statement object.property = null  is significantly more performant than delete object.property in all modern browsers. Even though using  delete  feels safer because the property is totally gone and thus can’t be used unintentionally (say, with a loop of Object.keys or _.each(object, ...) ), definitely consider instead using checks like if (typeof object === 'object' && !!object.property) {}  if you’re into performance, or even just to be safer. On the other hand, the performance gains you get will probably only make a dent during a loop of hundreds or thousands of these operations. Grains of salt rain from the sky!

# Running an Express server with Grunt and Yeoman: Part 1

In this series, I’m going to explain how to instantly and easily start a custom back-end server based on Node.js and Express, and automatically see your incremental front-end and back-end changes applied both in your browser and on the server. Also, a bonus: how to debug your Node.js server in WebKit Inspector / Chrome Developer Tools. Excited yet? Let’s get started.

## Intro

If you’re still reading this, you just might be a web engineer. If you’re using Node.js (which you totally should, it’s awesome!), your workflow probably goes something like this:

1. Change a few JavaScript files.
2. Refresh the page.
3. Change a few Sass/LESS files.
4. Recompile said Sass/LESS files.
5. Refresh the page.
6. Maybe you have some client-side templates. You change ‘em.
7. Maybe you precompile said templates. You recompile ‘em.
8. Refresh the page.
9. Change a few files on the backend.
10. Restart the web server.
11. Refresh the page.

You see where I’m going with this. More than 50% of those are time-consuming tasks that are more time spent not writing code. And we love to write code, right? That’s why we do this thang.

## What is Grunt?

Grunt is the engineer’s Tylenol, created to alleviate this pain felt by engineers the world over. It will watch the files in your project for changes and automatically send them to the right tool to be processed. Sass and templates compile themselves the moment they’re saved, and the page refreshes itself. Heck, if it’s CSS-related, the style changes are displayed immediately, no refresh needed. It’ll concatenate and minify your JavaScript and CSS. If you use RequireJS, it’ll even build out all of the modules in your project for production. And the list of Grunt’s awesome tasks just goes on like that.

All of this makes Grunt a powerful, time-saving tool that should be in every developer’s toolbox. Because we all know, a good developer is a lazy developer. But we’re not done yet, because Grunt will even run a web server for your front-end files right on the spot. No setting up and maintaining complicated web servers like Apache or Nginx. Just one command and your files are served and watched for changes. Ctrl+c or cmd+c in the terminal and the server disappears into the ether.

## What is Yeoman?

Yeoman is a command-line tool to scaffold out new apps. What this means is that if you’re starting a new webapp, no matter what technologies you’re using, yeoman can download and set up all the boilerplate files you need to start much further ahead than on a blank canvas. It’ll set up your project folder with JavaScript libraries, modules, styles, HTML5 Boilerplate, and much more with one command. Best practices are baked right in. It even includes an all-important starter Gruntfile.js file that Grunt will use to manage your tasks.

## What is Express?

With Node.js you can create your own custom web/application server. No doubt about it, it’s awesome. But with Express, multiply that x1000. It bills itself as “a minimal and flexible node.js web application framework, providing a robust set of features for building single and multi-page, and hybrid web applications.” A layer over Node that abstracts away all the low-level work and makes development faster and easier. If you plan on making a web server with Node, use Express. It’s that simple.

## What is Nodemon?

Nodemon is a command-line tool which will run any node-compatible JavaScript file through node, and when any files you specify in your project folder change, restart that node process. What this means is that if you run your main server.js or index.js file with nodemon, you’ll be testing against your latest server logic as you develop it. You can specify which files it should ignore as it watches your project directory for changes to restart your server.

## Next Up

In part 2, we’ll explore how you can combine these technologies to achieve the ultimate front-end / back-end workflow.

Till next time!

# Twitter Bootstrap: Custom Class names using Sass

Update: More research has been done on how Sass @extend works with media queries, and this post has been updated with examples and explanations on how to use it well. Enjoy!

Update #2: I’ve come up with a small SASS module that implements fluid responsive grids with a lot of flexibility. If that’s your aim, why not check it out?

There’s no question why Twitter Bootstrap is the most watched repo on Github. It’s amazing – saving developers everywhere from reinventing wheels and giving them the time they need to work on features that apply specifically to their project. In my mind, there are only two things that could make Bootstrap better:

1. Sass!
2. The ability to make custom semantic CSS classes.

Pamela Fox and BVision explained the second issue very well. The gist: Bootstrap gets updated, or you want to switch frameworks, and now your HTML, JavaScript, CSS, and possibly even backend code need to be updated to reflect the new CSS class names. What a nightmare! What’s more, some of Bootstrap’s class names are non-semantic, giving developers little clue of what their code will change.

I’m going to explain to you how to use CSS class names that make sense to you while benefiting from the awesome power that is Twitter Bootstrap. Keep in mind that I’m using the 3.0.0-wip branch. I’m not sure if this specific fix works for 2.x, but the detective work described in this post is likely the same (and will likely need to be reapplied as the branch is developed.. such is living on the bleeding edge ). If you’re pressed for time, here’s the summary:

1. Download Bootstrap off their GitHub 3.0.0-wip branch and build it with make . It’s explained how to do this in the README.
2. Remove a couple LESS comment blocks in bootstrap.css that will cause errors. You can find them by searching for LESS variables that start with @. Or just use your bash debug console, haha.
3. Rename boostrap.css to boostrap.scss and  @import  into your blank scss file.
4. Apply span-fix below.
5. Edit any JavaScript you’re using to reflect your chosen class names.
6. @extend  away!

## The Breakdown

SCSS, one of Sass’s two syntaxes, is a superset of CSS, and will allow you to mix regular ol’ CSS with SCSS. By importing Bootstrap’s plain-jane CSS into an SCSS file, you’ll be able to create custom classnames that  @extend  from Bootstrap’s default ones, like .btn .

But Sass won’t import a plain CSS file into an SCSS file with @import . So you need to rename bootstrap.css to .scss, and  @import  that at the top of your scss file for Sass to actually parse it.

One thing that tripped me up was using spans like .span6 and the like. Simply @extend-ing a span will not work. It turns out that Bootstrap uses CSS attribute selectors for classnames in spans and spans alone, in a variety of situations. Here are just a few I found:

Luckily all the other attribute selectors I found were for HTML attributes that weren’t class names, so they should apply regardless.

By applying the span-fix above, all  [class^="span"]  and [class*="span"] selectors will apply to your  @extend .span{#}  sass. The good news is that Sass seems to be smart enough not to copy all the properties (and thereby bloat your compiled CSS), and instead will attach your new classnames along with the default selectors in the base. Sass will even add your class to states, classes, and attribute selectors where appropriate. For instance, if you @extend btn; , your class also gets automatically added alongside the  .btn:hover  and  .btn[disabled]  selectors as  .your-class:hover  and [disabled].your-class . Robust and efficient, that Sass compiler.

I’ve applied the process above to reworking the “Jumbotron” (RIP Hero Unit) example in the Getting Started section of Bootstrap’s online documentation, to great success. If you try this, do note that the  .btn-navbar  and  .brand  classes in 2.3.1 have changed to  .navbar-toggle  and .navbar-brand , respectively, in 3.0.0-wip. The only other caveats are any JavaScript that apply to the page you’re working on. You’ll need to dive into those and see if they rely on any of the default classnames you wish to change.

## Media Queries

Sass @extend follows a few simple but important rules:

1. Sass will take an @extend within selectors defined in the topmost scope (i.e. not inside a media query), and will go through that scope and the scope of all media queries, matching your selector against the extended selector in each, but will NOT mix selectors and properties between different directives. Example:
2. @extend can be in a selector defined inside a media query but will only extend selectors within media queries that are exactly the same. This includes two exact media query blocks defined in different places within the file(s). Example:
3. @extend cannot be inside a media query if the class being extended exists in another other directive, or topmost. Example:

It’s important to note that you cannot extend selectors into media query selectors. Only extensions made to a selector that’s already inside that  @media  directive (it can be in another media block of the same name) are applied. A full description of this can be found in the Sass Documentation. I found that once I used @extend , whether in a  @media  block or not, the media queries would inherit from themselves automatically.

Therefore, the recommended way to use @extend in your Sass is to:

1. Always @extend from the topmost scope, i.e. outside of media queries.
2. Only @extend within @media if you’re absolutely sure the class to be @extended only exists inside a directive of equal definition, including the directive you’re writing in.

## Dénouement

We’ve now learned how to safely abstract our CSS classes in such a way that they’re infinitely more flexible. We can now upgrade frameworks, switch frameworks, or roll our own safely, because our CSS classes are not tied to any particular design, other than our own. Hooray!

# Transformation

I’d like today to talk a little bit about a topic that’s very dear to me — true happiness. I was chatting with a few women the other day about emotions, philosophy, and lifestyle and a couple of them remarked to me that it was very rare for someone my age to speak so familiarly of them, and to carry such a joie de vivre. It got me thinking.. this is a good time to take stock. I’m only just beginning on the path toward ultimate happiness, but I’m going to share with you some of the resources that were influential to me — a few instrumental — in greatly improving my quality of life, as it is today. Continue reading

# Pitfalls – Getting Dojo onto iPhone and Android with PhoneGap

Now that I’ve cut my teeth on web development with my new-ish website, I’ve decided to go dental and start making some phone apps using HTML5, CSS, and JavaScript. After having played around with jQuery for my website, I realized that the code began to grow to the point where just managing it was becoming a tough issue. For a large app, a framework (and not just a library) is necessary, in my view. For this, Dojo, I choose you!

Yes, I drew that. Strange feelings of shame and pride pervade my whole body.

# The kRiSiS Arcade

In high school, I had a dream…

kRiSiS Arcade Team at the High School Tech Prep Showcase

Well, I had two dreams. One dream was to own my own company. That one hasn’t happened yet. But the other dream, the other dream, was to have my very own Galaga arcade machine.

Far-fetched, for sure. Old cabinets were selling on eBay for upwards of \$1000, and weren’t guaranteed to work. I couldn’t justify spending that much on essentially one game, especially with a meager near-minimum-wage budget. So I did what any crazy kid with a love of shooting aliens would do.. I begged my parents. Alas, they echoed back my sentiments. I forgot about it for a while, until I stumbled upon an equally crazy website. Here was a dedicated group of people who were building their own arcade machines on the cheap! They used the arcade emulator, MAME, to run so many games on a computer, and built a cabinet around it. Armed with this knowledge, I crafted the diplomatic message: “Mom, I want to build an arcade machine for a school project.”

Arcade Cardboard Prototype Cutouts

Surprisingly, fantastically, she skeptically agreed. All I had to do was show some initiative — draft a budget and create a prototype. I did these things with an Excel spreadsheet and some cardboard, and my dad, long-time creative wizard and perpetually bored, agreed to help with the construction of the cabinet wherever I lacked experience. Work started before the project officially began, and I was assigned a few teammates at school to get the ball rolling. I was officially a leader. I struggled to assign tasks according to each person’s experience, maintain good relationships, and make sure everyone was doing their part. Honestly, I think leading a group of people is tougher than building an arcade. There are nuances to everything in human relations, and that project has endured long after the arcade was completed. Humans are fascinating creatures.

But I digress! I worked excitedly on lists, plans, schematics. So many new things had to be put in there! And after about eight months, the arcade was complete. Inside was a computer, a TV, a Dreamcast game console, Playstation 2, an awesome custom marquee a friend designed, a dynamic power distribution system, joysticks and buttons for two players, a working coin-door with a trick to give free credits, NES and SNES controllers hacked to work on the computer’s printer port, and a freshly-built Dance Dance Revolution dance pad with a custom arcade interface. I even put a trackball in there that used a hacked, old ball-mouse circuit board to act as the PC mouse and in-game trackball.

Underneath the Control Panel

NES and SNES controllers hacked to work on a computer

Not all was gravy in arcade-land, though. There was a point where we painted the coin-door front panel and controls panel and it didn’t come out smooth. We used paint stripper to try again but it gunked up the whole thing and we had to buy and cut fresh pieces. There was also a point where I’d cut, stripped, soldered, and crimped all 56 wire connections for the buttons and joysticks on the detachable control panel, only to find that when I popped the control panel in place, the wires were too short to reach the main cabinet junction points. I had to do it all over again with longer wires.

Ruined Wood Panels

Still, the process of designing and building the arcade was an incredible experience. Nothing can describe the feeling you get when you roll your work into a public space and get an overwhelming response. Nothing can describe the feeling you get when you stand back, wipe another round of sweat from your brow and think, “It’s done? For real?” Total awe sets in.

The kRiSiS Arcade being played by the crowd

Up until I built my portfolio website, davidarvelo.com, this was the greatest project I’d ever undertaken. I’ll never forget the experience. As I look at my arcade, standing tall on our living room floor, I start to get the feeling again that it’s time to play some Galaga.

Most of the Team. Oh, my bad fashion sense of the day.

First Notebook Sketches

Original List of Goals for the Project

Original Design

Old First Internal Layout Design

Nearly Final Layout Design. The DDR Pad was originally supposed to fit inside the arcade.

Cardboard prototype piece standing beside the cut wooden parts.

A View of the Internal Frame. This was dad's idea.

Fully Assembled Frame, Minus the Control Panel

What the inside of an SNES controller looks like. I bought the controller from a used game store and had to fix a stuck shoulder button.

Hub for all hacked NES and SNES Controllers wired to the PC Parallel Port

Purchased Keyboard Emulator Circuit, Wired Up

Hacked Power Strip that provided dynamic power distribution. The first two outlets are always on. Once the computer is switched on, it trips the 12V relay shown, which causes the rest of the outlets to be powered on. Good for powering marquee lighting, cooling system, and TV.

Power switches for the computer, lighting, and ventilation.

Modified Stock Coin Door. When coin return is pushed, the plunger pushes on an attached microswitch, which triggers free credits in the game.

Me and My Baby

A shot of the arcade with the door open, showing the internal organization of parts. Computer on the bottom shelf, game consoles on the middle shelf, and keyboard and mouse on top.

Me and my teammate, Diego, as we worked to build the Dance Dance Revolution dance pad.

This hacked Playstation controller allows the dance pad to work on a Playstation, in addition to alternate wiring allowing it to work on a computer.

Underneath a Dance Pad Foot Panel. You can see the switches that trigger moves in the game and a lamp that lights the panel up when you step on it.

Completed Dance Pad, shown without Foot Panel Artwork