Rambling about JS and other things

jsFiddle Plugin for Octopress

In my post about moving into Octopress, I mused about how difficult it might be to make a jsFiddle plugin. Turns out, it wasn’t that hard.

I’ve created a simple jsFiddle plugin for Octopress. It allows one to easily embed a jsFiddle into their page. The syntax is pretty simple. For all of these examples, I’ll be using a fiddle of mine that demonstrates the properties of Dojo promises.

Fiddle URL:

Fortunately, the username isn’t actually required in the URL when using the jsFiddle iframe embed code. I’m referring to the portion identified as ccWP7 in my URL as the fiddle shortcode. There may be a better name for that, but if there is, I have no idea what it is.

Anyhow, let’s talk about how it works.

Conditions for Success

Earlier today, my friend Andrew tweeted the following:

Don’t create success. Create the conditions for success.

Doing some quick Googling, I’m sure it’s not exactly the most original quote ever, but it’s one that really resonated with me. It made me think about what I’m working on doing with my next Ignite NM talk, which I titled “Doing what you love: Making a hobby into a career”.

I owe a good deal to Andrew and a bit to dumb luck, but in a way, I’m doing what I am these days not because I went and made my own way, so much as I made myself ready for when the opportunities presented themselves.

In my case, I wanted to work on JavaScript full-time. I could have gone and become a contractor or consultant or something, but instead, I polished my skills. I worked on improving. I read and studied. I spent free time experimenting. I created the conditions for success such that when the opportunity presented itself, I was ready for it, and I couldn’t be happier.

Are you doing what you love? If you aren’t, why not?

Moving Into Octopress

So, some months ago, I set up a new blog on GitHub because I wanted to play around with Jekyll, and I spent some time making it look half decent. It wasn’t bad (okay, yes it was) and it worked and then I got lazy and haven’t done much with it.

Then a few days ago, Rebecca Murphey wrote up a post about her recent shift to Octopress, which is basically a nice framework for Jekyll. It sets up some nice themes and uses Sass to make it super easy to customize the really beautiful layout.

I hopped into the #octopress channel on freenode, asked a question or two, got immediate responses, and basically I was able to move my _posts directory from before into the Octopress setup. It’s built to deploy to GitHub Pages as well, meaning it was ridiculously easy to get the “new” site up.

Of course, I wrote all of two blog posts before, but Octopress has a few niceties to make blogging a bit smoother. It’s very easy to pull in code snippets for display, including from gists. I wonder how hard it’d be to make a jsFiddle plugin…

Don’t Let jQuery DOMinate Your Thinking

For the past few years, I’ve been working on a side project at the University of New Mexico. There’s not a public-facing aspect to it that’s worth highlighting, but the administrative side is a very heavy JavaScript application, and it didn’t start that way.

There are several pages to the application, each of which is dedicated to a major piece of functionality. As our registered user base has grown, the amount of information that needs to be managed has grown quite a bit, and some of my earlier pages were really starting to slow down.

When we first started building the application, we went with jQuery. I’d been writing JS since before the libraries and toolkits were really on the scene, and remember playing with things like YUI 1.0 and Prototype in prior websites, but my coworker/team lead was really keen on trying out this tool that was starting to get some traction.

From a CS perspective, at first, jQuery’s interface really bothered me. I liked that Prototype made JS feel a lot more like C++ to me. It felt like I could build some interaction, using an approach that felt natural and proper to me, like it was somehow “fixing” JS. Also, let’s be honest: chaining is ugly.

However, jQuery made working with the DOM so much easier, and Ajax work was just dead simple (especially when cranking out JSON on the backend), so I stuck with it.

After working in jQuery for a while, I stopped thinking about JavaScript. I let jQuery kind of take over my brain. For a while, I fell really heavily in love with it. It felt just magical. Things just worked. Working with IE wasn’t as awful (though still not great, of course).

I was quite the fan of jQuery – and in many ways, I still am. jQuery is really a fantastic tool for doing DOM manipulation and simple Ajax work. The problem is, my application outgrew simple Ajax work and DOM manipulation.

As the application grew in functionality and codebase, performance really started to sink. It was quite awful. However, I was fortunate enough to have stumbled upon a relatively new podcast named yayQuery. Listening to the yQ crew talk about anti-patterns and hiddenhancements and such, I really grew interested in optimization. When jQuery 1.4 came out, I was ready to take advantage of it, and managed to take one particular page from a load time of ~12 seconds to ~3.

Over the past year, I’ve gone through and created a couple of new pages to replace some of the worst offenders, and tried cleaning up here and there where possible, but on the whole, I realized the major problem I’d run into was that I stopped thinking about my data as data, and started thinking about it more as DOM.

If there is one takeaway from my entire ramble here, it is this: Don’t let jQuery DOMinate your thinking. When all you have is a DOM hammer, everything is a DOM node.

I had been creating ridiculously complex markup with a lot of hidden elements in order to preserve data, rather than using things like to store JS objects. I was also doing things like not saving my resulting jQuery objects, running code like $("#foo") repeatedly, not thinking about the impact of creating several new jQuery collections. It’s almost embarassing to admit that I was generating a bunch of <li> tags and actively adding them to the DOM one at a time, for literally hundreds of list items, but I was.

You’ll note that not all of the things I was doing above are jQuery’s fault. It’s just that with jQuery, I stopped thinking about JavaScript – and, in retrospect, that was a really bad thing.

These days, I’m doing a lot with Dojo and while it’s not the JS panacea, it’s the first of all of the toolkits and libraries that’s felt like I’m really writing JavaScript, and not just writing something else that doesn’t feel like JS. I’ve grown to love JavaScript as a language for its own merits.

So, whether you’re coming to this post and you’re a huge jQuery fan who hasn’t tried other tools, or you’re a seasoned vet with the DHTML scars to prove it – I encourage you, reach out and try something else. It doesn’t matter what you go for, so much as you’re trying something different.


Larger libraries/toolkits (typically cross-browser, all with rich DOM/Ajax support, often including UI frameworks, etc):

Smaller libraries (focused on specific pieces of functionality):

Other reading:

Proof of Concept: ScoreSettler

When I’m playing Settlers of Catan with friends, it always seems like either 6 or 8 is really hot, and dominates the rolls. I realize that they’re common rolls, and that 7 is theoretically the most common roll, but it never quite seems that way, that either 6 or 8 is dominant. It also seems like 5 or 9 is way more frequent than its statistical pairing, and I’ve wanted an easy way to track these stats in the past.

So, I thought, “Hey, I know how to code, it would be a simple UI in a browser, with minimal JS needs, just make it already.” I got out my notebook and sketched out some ideas on UI… and then let it sit for quite awhile. I’m pretty sure it’s been at least six months, if not more.

It’s been kind of bothering me for awhile now, and even though we don’t play Settlers as much these days (Dominion is amazing), I’ve still wanted to build it. Tonight, finally, I just sat down for a couple of hours and poked it out of my head, and called it ScoreSettler.

You can now go try it out or clone/fork the source for yourself. It’s all here on GitHub, right alongside this blog. I’d call it a proof of concept at this point, which means that if I never come back to it, I can still consider it complete, right?

I make no claims as to the quality of the code. It’s fairly simple and requires a modern browser (which means no IE < 9), as I’m not using any JS libraries to do anything. It’s just plain and simple JS, using event listeners. I’m sure it’s not perfect, that there’s spots to optimize, that it could use a better coat of paint, but hey, it works.

It even has a rolling simulator, which I was using for testing. It’s kind of fun to just watch it roll away though.

Heck, it works on the iPad, meaning I could, in theory, use it right now – and that’s awesome.

So, yeah. Feel free to go play, or fork it and make it pretty or something. It’s nothing that huge or exciting, but I’m glad to have it out of my head now, and I look forward to tracking my next game of Settlers to see how the dice are screwing me. :)