Edit /boot/config.txt

Add a line anywhere :

Where

• X = 0 : normal
• X = 1 : rotate 90 degrees clockwise (left edge)
• X = 2 : upside down
• X = 3 : rotate 90 degrees counter-clockwise (right edge)

The unexamined code is not worth releasing – Socrates (probably)

I wrote plato because socrates was too long a name for a command line tool. I also wrote plato because I love metrics. I love stupid little numbers that mean arbitrary things and I love watching some of them go up and I love watching some of them go down.

Most of them are meaningless.

Or maybe they’re super meaningful.

Does it matter?

What really matters is questioning your work. Why do these numbers come up? Why do some numbers go down when you do foo and why do some go up when bar? Do you like your code more when the number is higher, or lower?

I see a lot of comments regarding the relative value of plato’s metrics, as if I thought of them, and that’s great but missing the point. The truth is, even if I did pull these metrics out of the air, if they are consistently generated based off open criteria then they are still useful as long as you find them to be meaningful. You can have opinions as to what is considered an operand vs an operator and what those mean to other calculations, but the relative validity of an individual metric in this scenario is irrelevant. The value is the baseline you come to and maintaining alignment with what you find important.

One of the common points of contention is the “Estimated Number of Bugs” which is a metric I love in part because it looks so intuitive to the untrained eye (read: management). It doesn’t mean that your silly little dropdown might not work in IE8 if the user logs on with a spotty 3g connection while riding a donkey in singapore. It means that, given the complexity of the work that has been provided, there is a potential likelihood of X errors in the implementation. You may have 0 actual bugs, you may have 1000. Don’t get hung up on it, just think about it a minute.

At the end of the day, the best code is what powers the tools that people use daily and find valuable in their lives. Some of the most useful tools have code that would knock a wildebeast dead (vi anyone?) but that’s not what history remembers.

Release quickly. Refactor always.

Mass, overdue updates for people following me due to random projects.

- The JavaScript-Particle-System was rewritten to use requirejs and an event system on loan from Backbone (also featured in the NodeKnockout 2012 winner Disasteroids)
- Moved the bulk of grunt-preprocess out and published npm module preprocess. Grunt 0.4.0 support is available on a branch.
- RCL is up to 0.3.4 with features and fixes from Chris Miller for better firefox handling, also includes a small slew of other fixes only in the client. Server got updates to be more useful as a grunt task.
- grunt-contrib-jasmine was brought up to date with the feature-frozen grunt 0.4.0
- grunt-contrib-uglify has been updated to use the new UglifyJS version which includes support for sourcemaps.

Deprecation notices
- grunt-jasmine-runner will be deprecated as soon as grunt 0.4.0 hits, in favor of grunt-contrib-jasmine.
- I’m hoping to deprecate grunt-strip soon in favor of grunt-groundskeeper if that ends up serving the same purposes better. Everyone using grunt-strip is encouraged to check out that project.

I’m sitting in an airport after two days at HTML5 Dev Conf with plenty of time to think about the conf sprinkled with the occasional double check of my boarding pass to make sure I’m at the right gate.

Overall, the conf was worth going to, but the quality of the talks flip flopped between frustratingly amateur to mind blowingly awesome.

Paul Irish talked (slides) about how to enhance your toolchain and churned out loads of tools or aspects of tools I didn’t know about. SASS support around the corner in Chrome’s DevTools? Persistent JS snippets? Even Command-O was new to me and that’s already available. I had walked into the keynote expecting to hear mostly about Yeoman, which I’ve already played a bit with, but when he started talking I quickly had an “Oh shit” moment and realized I needed to break out the laptop and take notes.

Chris Heilmann talked about the broken promises of HTML5 and how unproductive it is to be wowed at and emulate things that Flash developers have been doing for the past 8 years. It’s awesome, yes, but we’re still under water when it comes to functionality that others have already come to expect and that we need to be making great applications. What is going to get us further, faster is to start exploiting the web for what it is best at and make bigger swings with widely accessible and richly functional sites/applications. Firefox OS promises to bridge a gap when it comes to device functionality exposed to web tech, but they’re targeting markets that I’m not in. It makes sense and is probably a good future investment but I’d love to see some focus in the US.

Steve Souders gave a great talk on caching and harped on some of the basics that are really important to get right like setting max-age and other cache headers. He mentioned why relying on heuristic caching, or what browsers or other clients do when no cache behavior is explicitly set, is unreliable for such an important aspect of your site and business. A few of Souders’ other stats highlighted just how important cache is, being more important than a fatter pipe or even disabling JavaScript in your browser (or, extrapolating from that, stripping all JavaScript from your site).

James Pearce of Facebook, a smart guy without a doubt, gave his frustratingly negative perspective on mobile web applications to the wrong crowd. The focus was the experience Facebook had developing and supporting their mobile application, generally considered a very poor quality app until they moved native. I can absolutely respect frustrations with mobile development with web technology; there are so many unknowns, problems that don’t yet have standard solutions, and a lack of decent development tools to aid the process. I, personally, might not even recommend going web tech at all on mobile depending on the developers you have access to, but to use the Facebook app as an example of the failure of the entire platform is irresponsible and genuine misinformation. One of the glaring failures of Pearce’s talk is his quote that the installed application’s lists look “pixel for pixel” the same as m.facebook.com because the same html is served. That is not a web application. That is a wrapper around a website. Facebook’s developers made some poor decisions and it is being used, publicly, as a shining example of how immature the web platform is. It was counter-productive and inappropriate for the audience and conference he was at.

Fortunately, Steve Newcomb gave a talk later in the day that appeared to expose a tip of the iceberg on untapped potential of the web platform. The Famo.us project makes some very large promises about performance on mobile devices and the demos were what everyone was talking about for the rest of the day. There were live demos on iPads after the talk that seemed to support the claims but, as with anything not actually released, it’s hard to know exactly what is being done and whether or not this is a general solution that will help many or a specific implementation that won’t be widely applicable. Check out the demos at the Famo.us site.

I’d love to get a closer look at the internals, so if you happen to sign up for early release, please use http://famo.us/r/VMCB to group your and my requests in the same bucket, hopefully weighting all of our requests more heavily.

There were other great talks (like Shay Howe‘s talk “Tactical CSS“) but my plane is landing. Maybe next time.

I came across grunt a few months ago and was amazed at how little time I spent looking at my build process before it. JavaScript was already in control of my frontend, backend, mobile, system scripts, and now it’s the entire build process. It’s amazing.

I’ve got tasks set up that look as gorgeous as this

Here are 6 grunt tasks that I’ve published this month that, when combined with everything already out there, have accelerated my development a huge amount.

grunt-strip

grunt-strip allows you to strip out console.logs from your JavaScript source files. It also supports configuring other nodes you might want to strip out (like other debug libraries).

Example config

grunt-preprocess

grunt-preprocess allows you to exclude or include parts of JavaScript and HTML files via directives that optionally depend on environment configuration.

Example config

Example Syntax

Example JavaScript Syntax

grunt-open

grunt-open simply allows you to open urls or files via task configuration.

Example config

Allows for task chains like

RCL

RCL (Remote Client Logging) is a tool written with grunt that allows you to log from your JavaScript application remotely to a terminal or web client. Visit rcljs.com for full documentation.

grunt-jasmine-runner

grunt-jasmine-runner is an tool to automate the generation and running of a jasmine-based specrunner through phantomjs.

Example config

grunt-requiredir

grunt-require-dir allows you to automatically generate requirejs-compatible AMD modules out of a directory tree. This is useful for bucketing alike resources without resorting to an full precompilation step that might remove some of the benefit of AMD.

Example config

Generates output like

All told, grunt has opened up massive possibilities for me with JavaScript development. There is nothing particularly revolutionary about it, it’s just a bunch of incredibly useful tools located in one glorious place. Having such an important step be written in JavaScript makes it trivial to recognize a need for a task, switch to writing and finishing that task, and get back to coding your app with no expensive context switch.

[UPDATE: I just got an email from someone saying they use tabs over spaces because visually aligning everything by repeatedly pressing the spacebar is too cumbersome. That is not what is meant by using spaces over tabs! Every IDE/editor supports replacing tab presses with a dynamic and variable number of spaces until you get to the appropriate indentation level. It would be insane if this misunderstanding turned out to be one of the cruxes of the issue.]

I never really understood the Tabs vs Spaces debate. When I first started programming I started using tabs but almost immediately realized they just weren’t suited for the job. They promise flexibility but, in practice, that flexibility is largely a lie and you tie other developers to your indentation style regardless. If you are tying developers in to a style, then why use tabs which can add unexpected confusion?

In the examples below, tab characters are colored a darker grey. Don’t get hung up on the coding style, the issues of alignment are what’s important and the code is terse for example’s sake.

Tabs with 4 char widths

This example shows an initial setup that uses a 4-width tab for nearly everything. It looks great and beautiful when you are set up for a 4-width tab, but try changing the tab width with the buttons below the example.

All the careful alignment goes to crap when you change the tab width. Yes, the fact that you can change the tab width is a great option to have, but if it requires you to reformat your code then it is not actually a real feature of using tabs, it’s the same situation in any scenario. Either manual or automatic reformatting all around.

Tabs with 2 char widths

Below is the same example as above, but optimized for a 2 character width tab. The exact same problem applies, but you can also see that it takes a different number of tabs to produce similar alignments.

Tabs for block indent only

The last entry on our tabstop tour is an example that only uses tabs for block level indentation, which some people use as a solution to the above problems. This still has its own issues when alignments occur across block level indentations (look at the last block) but also raises the simple question “why?” Block level indentation is the simplest thing for an IDE to take control over, and the actual act of block indentation is almost always hidden from the developer. It is also the easiest to reformat globally since the rules for that are relatively standard, configurable in most decent IDEs or, at the least, tolerable.

Even if this is the most tolerable solution, it introduces yet another wrench into enforcing style with other developers. Now you need to make sure a developer only uses tabs for block level indentation, and spaces for alignment purposes.

Spaces for tabs, two character indent

And here is the example that doesn’t include tabs at all, just spaces and a 2 tab indentation level. The benefit here is unmistakable intent.

There is no chance for confusion and what you see is what you get.

Contributors/teams do still need to set a common config as to the number of spaces for indentation, but that is better than assuming you don’t need to do that with tabs and getting conflicting code style regardless.

Personally, it really doesn’t matter to me as long as there is a standard. If you use tabs, then you still need to add the tab width you are coding with to coding guidelines. The reason I use spaces is because the environment is self-describing. If you see two spaces, you know the guideline is a two character indentation level. If you see a tab and effed up alignment, you need to experiment with a few configurations in order to find the style the original developers were coding towards.

(and yes, “flexible” or “smart” tabs sound awesome, but are impractical in mixed environments where IDE/editor support is so spotty)

I finally published the require-dir task to npm last night so you can now install it alongside your gruntfile with

This task automates the process of grouping files or modules into an AMD container compatible, at least, with requirejs. Essentially “require”-ing a whole directory. I find myself creating module namespaces to group like-content together and this automates that, previously manual, process.

It allows you to turn a directory tree like this

into this

I’ve always loved optical illusions. Anything, really, that reminds me that I am not my brain.

I recently came across a old, great illusion that I have loved and have always wished that I could tweak to find out what point I start to lose grasp of the circles. I built a visualization in JavaScript (original static image) using canvas today that allows you to alter the properties of the circles, sizing, and rotation and it allows you to do just that.

The key to the illusion is the alternating rotation of the squares in each circle guiding your eyes in conflicting directions making you visualize separate spirals. If you uncheck ‘alternateRotation’ you get a more subtle illusion of one attached spiral, which is still cool.

Concentric Circle Illusion in JavaScript on Canvas