RandomThink.net

2013 in review

Tue, 31 Dec 2013 00:00:00 +0000

Inspired by several similar sorts of posts (and the realization that this will be only my second post this year), it feels like a good time to look at 2013, as well as to look forward a bit at some things I’d like to change next year.

Good Things in 2013

There were several things that went well this year.

Logan’s first calendar year

This year was the first year that I was a dad from start to finish. Logan aged from seven months to nineteen months, and getting to watch his growth and development during 2013 was nothing short of amazing. I wish I could find words for how it feels to watch him grow and learn. Each and every day still has new things, and watching my baby grow into a toddler has been the highlight of the year.

Professional Growth

Back in July, I started a new job with Bazaarvoice, which has been a great experience so far. It’s a completely different stack of technology than anything I’ve worked with before, at an amazing scale (over half a billion people load BV content each month).

I do miss my training travel to various spots all over the US, but if I had to pick one city to be my primary travel target, Austin is a pretty great choice.

Additionally, I got to talk at a couple of national-level events, which was pretty awesome. I was one of the first speakers in the new Trainer Track at JSConf 2013, and I gave a talk on Debugging at jQuery Conference Austin. (I’ll be giving an updated version of the Debugging talk at jQuery Conference San Diego in February!)

Travel

It was another fun year for travel. In the first half of the year, I got to visit some places I hadn’t been before. I really enjoyed Atlanta, and visiting Amelia Island for JSConf was pretty amazing. Logan also had his first out-of-state trips, including road trips to Arizona and Colorado (both for weddings) and a flight to Austin for my orientation week.

Also travel-related, but not my travel, my good friend [Mark Z][] came to visit in October for the [Albuquerque International Balloon Fiesta][], after several years of discussing it. It was a great visit, and definitely one of the highlights of the year.

Not-as-good Things in 2013

I’m not normally one to dwell on the negatives, but in assessing the year, I think it’s important to at least look a little bit at some of the things that weren’t as good.

Weight and Diet

Back in early 2010, I was able to find some willpower and made some changes that resulted in the best weight loss I’d had in my adult life. I made it down to 217 at my low point (which was the lowest I’d been since high school). Shortly after that, I started a work-from-home job and became quite sedentary. Over the course of the past few years, I’ve completely undone all of that loss, to the point that as of this year, I’m very near to my highest weight ever.

Communication

I feel like I’ve done a really poor job of keeping in touch with my friends and family. I know communication is a two-way street, and it’s not all on me, but I’ve been less available, both in-person and online, and it’s definitely something I could work on.

Looking Forward

A few days ago, I read an article on developing systems instead of goals, and it really resonated with me. I feel that I can greatly attribute my career successes to date (which I’m fairly proud of) on the fact that I didn’t really set specific goals, so much as that I had systems to develop myself professionally. Keeping that in mind, there’s a few things I’d like to work on in the upcoming years (not just 2014).

Be More Active

During the last week of 2013, we were all pretty sick with some stomach bug. In an effort to feel better, we took a walk on a couple of days, and it really reminded me how much I used to enjoy trying to walk (and even run) a few years ago. I wound up pushing myself a bit even, and in this past week, I’ve walked over eight miles (most of those while pushing Logan in a stroller). I plan to simply take a bit of time each week to get out and move more.

Get Back to Writing

I have all these things I want to write about. I like the idea of small personal asides as well as larger technical writeups, and I plan to do more of both. In particular, I’ve developed a passion for knowing as much as I can about DevTools in Chrome and Firefox, and I’d like to share some of the more useful tidbits and ideas.

Personal Hobbies

I haven’t really spent all that much time on personal hobbies in the past year or two. While I did acquire several new board games in 2013, I didn’t spend tons of time actually playing them. There’s a challenge on BoardGameGeek to play 10 games 10 times each that I’d like to complete. Too often, I’d purchase a game, find one chance to play it, and move on. I need to really take time to enjoy the things I have, rather than constantly looking for new things.

I’ve also not read many books for almost two years. I’m fairly sure March 2012 was the last time I read something other than a technical book.

Thanks

While not perfect, 2013 was a pretty solid year. Here’s looking forward to 2014!

Board Gaming Nights

Sun, 09 Jun 2013 00:00:00 +0000

TL;DR: Board games are fun. If you live in ABQ, we should play more. I have an idea on how to do that. If you don’t live in ABQ and/or aren’t interested in board games, you should probably skip this post.

While I was off and away at the amazing JSConf 2013, my latest board game acquisition (Belfort, from a Kickstarter) was delivered. I decided that I’d use Logan’s nap today to set it up. It amounted to having to apply 144 stickers (gross) to little wooden blocks along with popping of several chits for money and whatnot.

This afternoon, while he napped some more, I remembered that another board game I own (Ground Floor, also from a Kickstarter) hadn’t been set up either, and so I popped out pieces from 13 boards worth of game pieces for money and building improvements and whatnot.

I looked at these games as I set them up, and found myself thinking about the hobby. While I enjoy the process of setting up board games to be played, I really enjoy actually playing them too. I got to play a decent bit of games on my trip (which I should also blog about at some point soon), but it got me thinking about ways to play more games.

I still plan on doing my annual birthday party gaming event, but trying to do that more than once a year isn’t something that I could pull off before we had Logan, and it’s definitely not something we can pull now. Even with friends who do the occasional gaming day, the reality is that attending a day of gaming is simply not feasible for the time being.

In recent months, I’ve managed to occasionally get in a board game during lunch with friends, but that’s been hard to set up as well, and the time pressures of squeezing in a game over lunch means we have to play something with a 60 minute or less timeframe, and honestly, playing a 60 minute game at lunch means lunch is running too long anyways.

On my last night in Boston, I went to the Bocoup Loft to play games. I was feeling nervous because I didn’t get there until like 8pm, and I was thinking about my 8am flight the next day and thinking I was going to be sacrificing some sleep in order to really get some games going.

Instead, we played one really good seven person round of 7 Wonders, then a couple of rounds of a little very light game, and that was it. I was there maybe two hours. However, I still had a lot of fun. It had the joy of getting some gaming going, without feeling like this weighty commitment.

So, all that being said, what I think I’d like to try now is to organize a few gaming nights here and there at my home, but different from the gaming days in some important ways:

Just a couple of hours. While I can’t put together a long lunch or a full day very easily, Logan is very consistently in bed and asleep by 7:30pm, meaning 8-10pm would work well for me, and I suspect/hope for most people.
Just one game. Pick something and play it as many times as we can in the two hours. This likely means just one playthrough, but that’s okay. We can then talk and reflect and move on.
Just a few people. No need to have a dozen or more people over. Enough to play. Most games only really work well with 3-6 people anyways. Not that I don’t love the parties, but it’d mess with the first couple of goals.
Keep it light. People often feel like the party is an obligation or a big commitment, and I want this to be a casual thing that people can do without feeling like it’s an obligation or burden to attend.

I’m thinking of trying this out near the end of the month, probably on a Tuesday. I’d like to run Belfort, which claims to be 90-120 minutes of play. Normally that’d mean it’s going to take more like 2-3 hours, but if people are willing to invest a little time beforehand, there’s a fantastic series on Watch It Played that covers how to play Belfort in pretty thorough detail. The first video shows game setup and describes turns, and the rest are a detailed playthrough.

Thoughts? Any interest?

Breakpoint Actions in JavaScript

Wed, 28 Nov 2012 00:00:00 +0000

Earlier today, I filled out the Chrome DevTools Survey & Feedback (which you should too, if you’re a web developer), and near the bottom of the survey, there was a question:

Are there any tools or features you think are missing that would better help you develop your webapps?

My initial answer was No, there wasn’t anything I felt was missing. DevTools are awesome, and there hasn’t really been anything I’ve felt like I needed.

Later in the day, I ran into a very common scenario: I was debugging something where I wanted to observe a value at a particular line of code. There are a couple of ways to approach it:

Drop in a debugger statement or set a breakpoint to stop execution and use the console and/or watch statements to observe the value
Inject some console.log statements to write the value out to the console

In this case, the console.log approach would be ideal. However, I didn’t have access to modify the code directly, and while I could have used the live editing features, it was also minified code, meaning that live edit was an ugly option.

Thinking back to the survey question, I now had an answer: Wouldn’t it be nice if there was some way to have some sort of action kicked off, breakpoint-style, where I’m not editing the code directly?

I asked some friends, and it turns out, other development environments have a similar concept. Xcode has Breakpoint Actions (as do some other IDEs) which look to be exactly what I wanted. While bouncing this idea around, I realized that I could actually fake it in the browser, right now.

Chrome supports conditional breakpoints. Adding them is easy. First, find the line you want to set a breakpoint on, and click the line number to apply a breakpoint like normal:

Then you right-click on it, and select “Edit Breakpoint”:

You’re presented with your cursor in a field like so, where you can define an expression. If the expression evaluates to a truthy value, execution will break here.

It’s not uncommon to set simple expressions like someObj.id === '1', but I realized that any valid JS expression would be evaluated any time this line was hit – including the console.log statement I wanted to add!

This approach works quite well. Looking over at the console after moving my mouse around a bit on this page (which happens to be the Chrome DevTools Breakpoints page), you can clearly see the added console.log firing:

Since console.log doesn’t have a meaningful return value, the undefined means the conditional breakpoint won’t pause execution, and the code moves on. It’s just like a coded console.log statement, without having to actually modify the code.

Using a conditional breakpoint like this feels horribly hacky, and yet, I love this idea. It achieves the exact goal that I wanted. It’s not elegant, it’s not by design, but it gets the job done, like so many other things in web development.

As an added note, Firebug supports conditional breakpoints in much the same way, and this approach totally works there as well. In both cases, it’s working simply because you’re just evaluating the expression, and only pausing execution if it evaluates to a truthy value.

Hopefully you’ll find this useful at some point! I already have.

Callbacks and Promises

Thu, 18 Oct 2012 00:00:00 +0000

Anyone who’s written even a little bit of JavaScript is likely familiar with the callback pattern. Even if you don’t know it by that name, you’ve probably written code using it. When calling a function, we’ll pass it another function as an argument, which will be used to let us know that something has happened. In particular, callbacks are frequently used for responding to things that happen asynchronously.

For example, event handling is based on this pattern. We take a DOM node and provide it with a callback function so that when the associated event occurs on that node, it has a way of letting us know what’s going on.

``` javascript Simple document-based click handler document.addEventListener(“click”, function(e){ console.log(“Document was clicked!”); }, false);


This sort of code is very commonplace, and is one of the more powerful features
of JavaScript. When using code that accepts callbacks, we don't usually think
too much of it.

As we create richer applications, we'll often need to create functions that pass
information back to our users. If the information we're passing back comes from
asynchronous sources, it may be beneficial to create functions that that accept
callbacks. Because JavaScript functions are [first-class objects][1], you can
receive them as arguments, and then simply invoke them.

I prefer [Dojo][] these days, but for simplicity's sake, I'll show an example
using [jQuery][], as I suspect that will be more familiar to most people.

``` javascript Simple function that accepts a callback
function getManagers(callback){
  // Kick off our Ajax request for information.
  $.ajax({
    url: "/company/allEmployees.json",
    dataType: "json",
    success: function(data) {
      // Using our callback, provide manager data to our user.
      if (data.managers && typeof callback == "function") {
        callback(data.managers);
      }
    }
  });
}

Notice that in this case, I’m not returning anything from the getManagers function. I’m communicating with my user by invoking the callback they’ve provided to me. This approach is very effective, and people are generally comfortable with using callback-driven functions, so it’s a solid and perfectly valid way to write code. It could also be extended to handle not just a callback for success states, but another one for errors.

``` javascript Improved version with callback/errback support function getManagers(callback, errback){ // Kick off our Ajax request for information $.ajax({ url: “/company/allEmployees.json”, dataType: “json”, success: function(data) { // We’re breaking the logic to check just for managers first, // in order to better facilitate error handling. if (data.managers) { // We have our data, so invoke our callback. if (typeof callback == “function”) { callback(data.managers); } } else if (typeof errback == “function”) { // We have no manager data, so if we have an errback, // give it something meaningful to indicate failure. errback(new Error(“No managers found”)); } }, error: function(jqXHR, textStatus, errorThrown) { // If we have the errback, just give it the error we got. if (typeof errback == “function”) { errback(errorThrown); } } }); }


Using this function is actually quite easy:

``` javascript Using getManagers
// Simply call it and provide your callback.
// In this case, I'm not going to worry about errors.
getManagers(function(managers){
  for (var i = 0, l = managers.length; i < l; i++) {
    // Do something with each manager here
  }
});

Writing code that accepts callbacks and uses them is really simple. That being said, callbacks can lead to tightly coupled code. It means that I have to know how I want to process my information at the point of retrieving it. It makes it more difficult to write reusable abstractions of the process used to request data.

Fortunately, there is another approach available to us. Modern JavaScript libraries and toolkits offer us implementations of a concept known as promises. In general terms, a promise is simply an object that represents the value of an asynchronous action. It’s kind of like an IOU for information. It also happens to fit the above scenario quite well.

If you’re using Dojo or jQuery, you already have promises available to you. You can create a Deferred object, which is the mechanism for creating and managing promises.

Working with Deferreds is quite easy. You simply create an instance of the Deferred constructor, and then when your value is ready, you resolve the instance with the value that it represents. If you hit an error state, you can reject the instance. Let’s take the above example and rework it to be using promises instead of callbacks.

``` javascript Getting managers via Deferreds / promises function getManagers(){ // Create our Deferred instance var deferred = new $.Deferred();

// Then, we’ll perform our Ajax request like before. $.ajax({ url: “/company/allEmployees.json”, dataType: “json”, success: function(data) { // This time though, we’ll simply resolve or reject // our Deferred instances. if (data.managers) { deferred.resolve(data.managers); } else { deferred.reject(new Error(“No managers found”)); } }, error: function(jqXHR, textStatus, errorThrown) { deferred.reject(errorThrown); } });

// Give our user the promise object that represents // our managers. return deferred.promise(); }


One key difference above is that we're actively providing a return value now,
whereas in the callback-based version, we didn't. This object that we're
returning is the promise that we're giving to our user, and it provides them
with the ability to get the information we're promising, once that data is
available.

The Deferred is the mechanism by which I manage the promise. It gives me the
ability to create a promise that I provide to my end user, as well as the
ability to then fulfill that promise in a meaningful way.

This approach almost feels synchronous. I create an object at the top of my
function, and I return it at the bottom. The user doesn't give me a callback,
but I give the user a meaningful object.

The promise object gives your user a `then` method, which they can then use to
attach a callback and get access to the value, like so:

``` javascript Using the return value from getManagers as a promise
getManagers().then(function(managers){
  for (var i = 0, l = managers.length; i < l; i++) {
    // Do something with each manager here,
    // such as render a list item.
  }
});

There is still a callback in action here, but now it’s being managed in the code that is consuming the information, rather than in the code that is providing it. We’ve effectively decoupled the process of retrieving information from the process of consuming it, which is a huge win for creating reusable code.

There’s also something to be said about reading promise-based code. It feels very natural. I take this action, then I take this other action. It can reduce excessive amounts of indentation, especially when doing a lot of Ajax work at once.

In fact, this approach is so powerful that both jQuery and Dojo already provide a promise as the return value of their Ajax systems. Dojo 1.8’s new dojo/request module is explicitly promise-driven, so requests look like this:

javascript Using dojo/request to perform a request require(["dojo/request"], function(request){ request.get("/company/allEmployees.json", { handleAs: "json" }).then(function(data){ // Work with your data here }); });

When creating your own modules of code to abstract away the process of data retrieval from data consumption, both callbacks and promises are valid – there’s not one right way to do it. However, using a promise means that you’re giving your users back a meaningful object, and how they deal with the information is up to them. It leads to loosely coupled code, which in turn leads to better reuse and modularization.

Hopefully you’ll consider using promises in your next application! I’ve barely scratched the surface of what makes them awesome. Check out the links below for much more information on promises and Deferreds. Thanks for reading!

Dojo:
- Getting Started with Deferreds
- Dojo Deferreds and Promises
jQuery:
- Deferred Object
Promises/A specification

Full Reboot

Sat, 13 Oct 2012 00:00:00 +0000

So, I said that I was going to be using WordPress and not using OctoPress but after I got things all set up back in WP, I found the experience of writing to be kind of frustrating. I’d written some post drafts in Markdown, and have really been enjoying that format. I also don’t like not having version control in play. I was able to use Markdown for my WP posts, but having to edit in Vim and then copy/paste over and preview, it got kind of annoying.

While OctoPress is definitely a bit more manual than something like WP, it turns out that I’m okay with that. I’ve taken a little time in the evenings after my brain is burnt out on other things and used it to poke and prod OctoPress into doing what I want. This new site is the end result.

Additionally, I figured out how to adjust my nginx settings such that any missing files are now going to redirect to a mirror of my old site, so I’m basically making a clean break. For the first time in over a decade, the folder that houses RandomThink.net is basically clean. Feels good, if a little scary for some reason.

To provide a bit more detail, I’m using the 2.1 branch of Octopress. After some discussions on Twitter, it sounds like 2.1 was basically good to go except for migrations from 2.0. Since I’m not reusing the brianarn@github experiment, no issues there.

I’ve found that OctoPress 2.1 offered some nice things, like the “Respectfully Social” setting, wherein the Tweet / FB / G+ links at the bottom of each post are really just basic links and not the full awful weight of their various APIs. It also felt way easier to specify a few things, such as having a landing page that isn’t just the blog posts.

It was also fairly easy to set up where my feeds and all should exist, and as such, the main links to individual blog posts, the main blog page, and the RSS should all just work. I think.

While I’m still very obviously using the OctoPress theme, I’ve made some customizations. I’ve taken the gradient out of the link bar above, and I really like how clean that looks. I’ve shrunk the sidebar a bit. I’ve also completely reset my font choices (while still using the Google webfont service).

Monospace: Source Code Pro. I’ve been using it in Vim and iTerm 2 for awhile, and I’m really quite a fan.
Sans-serif: Varela Round. There was just something about it that I liked.
Serif: Andada. Honestly, I picked this one because Google webfonts suggested it as a pairing with Varela Round. I tried some others, and this one was the best.

I ran the fonts by Evan and he seemed to approve, and he’s my font authority, so I trust that it looks okay.

I’ve also brought my old landing page over because I’m kind of attached to that stupid mockup image now.

I’m now doing all my blogging through Vim and using git to version control it all, and pushing the full site source up to GitHub as well. That means that all my everything for the full site is going to be in source control. Feels good, man.

Now to finally finish that “Callbacks vs. Promises” post that I’ve been stewing on for a month.

Git Flow Solo

Tue, 02 Oct 2012 00:00:00 +0000

The other day on Twitter, I was discussing workflow with my friend Geoff, and I mentioned that I use Git Flow for some of the work that I do. He mentioned that he’s a solo developer on most of his projects, and so he’s more of a GitHub Flow kind of guy. I’ve read Scott Chacon’s post on GitHub Flow in the past, and it’s a nice and light system. However, I find that Git Flow gives me some great power, and it seems worth discussing how it helps me as a solo developer.

I work for SitePen by day, but in the evenings and on weekends I have a side project for UNM’s College of Education. While I do have a project lead who does most of the styling work and sets direction for the project, I’m doing the full stack of development. It’s a pretty straight-forward LAMP stack application that, over the past four years, has moved from being a basic forms-driven site to a very rich and powerful application. It’s built up using jQuery and a couple of plugins for things like validation and grids and whatnot, and while I prefer Dojo these days, it’s not an option here due to legacy. Anyhow, I manage this application’s source with Git Flow.

Our source code (which is not public, unfortunately) has several branches influenced by the design of Git Flow:

master: This branch is production-ready. Nothing goes on master without acceptance from the project lead.
develop: This branch houses code that has been accepted, but not deployed into production just yet.
feature/*: There are typically one or more branches that start with feature/, and these are where I am actively doing 80% of my work.
hotfix/: There is often one or two of these showing up, and it accounts for the other 20% of work performed.
qa: This is a non-Git-Flow branch that I use to track the current state of the testing server.

We’ve used a variety of project management tools in the past (currently using Trello) and at any one time, I typically have two to three feature requests on my plate, and these features take anywhere from one week to one month to implement. The workflow typically goes like so:

Create a branch off of develop: git flow feature start some-feature
Cook until golden brown and flaky, committing changes both small and large as I go
Once ready for QA, merge into the qa branch and deploy to the dev server
Once accepted, push changes back into develop: git flow feature finish some-feature

Aside: I’m able to use git flow as a command thanks to the wonderful git-flow project, which I can install with Homebrew very trivially: brew install git-flow – Git Flow is a nice process on its own, but this addition to command-line git makes it much, much easier to follow. There’s even bash completion if you’re into that sort of things.

Completed features don’t always necessarily get pushed into production, so sometimes they’ll queue up a little on develop. Once we’re ready to do a deploy of a new feature, it’s as simple as git flow release start YYYYMMDD (we don’t have discrete version numbers so I’ve taken to using year, month, day as an easy means of tracking release). At that point, I can open up my SQL folder where I have any necessary migrations to apply to production, move the applied productions into a deployed folder, and complete the release, which merges into master. From there it’s a simple push to production.

While this is all well and good, and our development cycles are relatively fast, it’s an academic environment. For those who haven’t experienced development in such environments, it’s not uncommon for there to be fires. Sometimes it turns out that the feature in development needs to wait because we need a new report or some element in the user interface is confusing to the new person and we need to address it right now or numbers aren’t adding up somewhere and OMG something is wrong FIX IT NOW. This is where Git Flow’s hotfix branches are wonderful. Anything that needs a quick turnaround winds up going in as a hotfix. That workflow is quite similar to feature development, although the branching is a little different.

Create a branch off of master: git flow hotfix start report-fix
Make adjustments as quickly as I can, introducing no new bugs of course
Merge into qa and deploy to dev server, and notify my project lead immediately so he can test things
Once accepted, push back into master: git flow hotfix finish report-fix

Features for development, hotfixes for production. It’s a really nice duality that isn’t readily visible when you review the Git Flow process the first few times.

This means that I can very easily be working on multiple features at a time (occasionally one gets blocked by need of clearer requirements or whatnot) while also managing the fast and furious hot requests without totally losing my mind of what branch is what and where did I create it and did I do it from master or develop etc.

Git Flow does mention version numbers and whatnot, and if you have a product with version numbers, I’m sure it’s handy, but we’re in a fairly perpetual state of upgrade, so it’s not so relevant. Using Git Flow gives me a very manageable process for handling a lot of requests from a variety of sources. Given that I’m a one-man shop there, it’s nice to have a clean and easy-to-use workflow like this. It’s really not bad, especially if you install git-flow.

If you’re not doing anything for branch management, try out one of the flow-type processes I’ve linked. It’s really been a significant change to how I work, much for the better.

Clearing the cobwebs

Mon, 01 Oct 2012 00:00:00 +0000

I really appreciate the feedback on my Split Personality post. I got some good comments via a wide variety of channels, which kind of made me realize that really, I’m way the heck overthinking it and it’s okay to have some level of crossover.

I decided as a part of the process of figuring out what to do in moving forward, I’d look back. That’s when I read over all 688 posts I’d written on this blog. A few things stuck out at me:

I was way oversharing things, especially in those first few years
It was often way too wall-of-texty over mundane stuff
No, seriously, overshare ahoy
It’s funny to see how much tech has evolved in the ten years I’ve been running this thing
Several posts were little one-off throwaways that are now tweets or Facebook posts
There was way too much discussion about posting or lack of posting or other meta crap that meant something to me but is relatively meaningless to everyone else (in a sense, much like this post)

Of those 688, I wound up hiding 584 of them. I’m causing some massive linkrot in the process, but I tried to keep things that I felt had some sort of enduring value. Whether they’re reflective of me in some way or discussing personal events that still feel like there’s worth in sharing, anything publicly visible at this point is something that I still feel holds some level of value.

I also brought over three of the five posts from my brianarn@github experiment. It was fun and I enjoyed writing the content, but for as interesting of a concept as it is, Octopress requires a bit more time and effort than I really have to play with right now. WordPress is just kind of solid out of the box, especially in later versions, so it works for now.

For a variety of reasons, I cherish some of the overshare stuff because it’s been of real value to reflect lately. Some things in those posts are wonderful from a personal journaling perspective, but serve no reason to be public on the ‘net, so it’s worth closing down a little bit.

All that being said, I feel like I have a better idea of how I want to move forward. Personal and technical thoughts will be intermingled here on RandomThink, and I’ll stick with WordPress because while Octopress was neat, it’s still a bit more fiddly than I’d like to have to mess with for writing. I’m going to be trying to write about more technical topics because I feel those have more value in a public form.

For more ephemeral thoughts – links, memes, etc – I’ll stick with Twitter and Facebook – in particular, as I’ve been doing lately, baby-related things will likely wind up on Facebook, so if you’re interested in that aspect, hit me up with a friend request.

I also think I’m going to start a personal journal, so I have a place to write all those things I’ve recently enjoyed reading but were way too personal and oversharing.

Here’s looking forward to, y’know, actually blogging about something other than blogging.

Split Personality

Fri, 28 Sep 2012 00:00:00 +0000

So, I haven’t written a post on this blog in nearly two years. What a crazy year was the last real one, and so much has changed since then that it’d be hard to summarize. However, that’s not necessarily what this post is about.

Lately I’ve had a real urge to get back into blogging. I don’t always have time to sit and write novels, but I do find chances here and there where I can put a few thoughts out. For example, I have three draft posts on JavaScript topics and one on what it’s like to be a new parent (there’s something drastically different in the time since the last post), but the thing is, the audiences for those topics are drastically different.

Navel gazing regarding blogging isn’t new for me. Really, my concern is crossing the streams. I suspect I still have some family and friends who’d like to read the personal stuff but don’t know what a closure is, while others would be potentially interested to read my technical thoughts but could care less about my child’s latest developmental milestone.

This blog is personal and there’s a lot of old old content in it, and I’ve considered gutting it before and am considering it again, because of the two dozen domains I own, it’s still probably my favorite one and will always feel like home, but I feel bad causing linkrot.

I created brianarn@github the last time I got this urge, and that was a fun experiment with Octopress, but something about having it be a subdomain of GitHub feels a bit funny or odd. I’ve considered buying a domain or using one of the handful of variations on my name that I already own, but then it feels like maybe I’m fragmenting my web presence or whatever.

So, I figure, I’ll reach out this time. What do people think? If you have similar issues, how do you handle it? Separate blogs? Categories? Whoever you are, if you know me and you’ve read this, in particular if you have some experience in this area, please let me know. I know some people just mix it all up, and I’d be open to that, but it feels like I really need to segregate topics in some way and I’m just not sure how best to do that.

Moving Forward

Wed, 28 Dec 2011 00:00:00 +0000

As 2011 closes, we’re excited to be taking up leadership of Webuquerque, however, there have been some recent statements made about the Webuquerque leadership transition that we feel merit a response.

While all parties involved worked hard at the transition process, some things were not as smooth as they could have been. That being said, the hiccups in the transition process have not negatively impacted the presentations or events in any way.

We have nothing but the utmost respect for Emily Lewis and Jason Nakai, the Webuquerque founders. They have created an absolutely amazing community that we are all incredibly honored to be a part of, and proud to help move forward and grow. Our sincere thanks goes out to Emily and Jason for their hard work and the wonderful wealth of information they passed onto us to keep things going strong. We look forward to the continued involvement of Jason and Emily in the Webuquerque community.

We all love and are committed to this community. It has become something very unique and special to all who are involved, helping us improve our craft and our professional relationships. We hope that as Webuquerque moves into 2012 and beyond, the community will continue to be supportive and help Webuquerque grow in size and influence. Thank you!

Signed,
Brian Arnold, Ben Byrne, Zerek Welz

jsFiddle plugin for Octopress

Thu, 04 Aug 2011 00:00:00 +0000

Warning

This post is old and no longer functional, given that I’m not actively using Octopress anymore. I’ve neutered the output a bit, since I’m not using the plugins, and I don’t have plans to port them to Hugo shortcodes at this point.

Original Content

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: http://jsfiddle.net/brianarn/ccWP7/

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.

General syntax:

The general syntax for usage is pretty straightforward.

&#123;% jsfiddle shorttag [tabs] [skin] [height] [width] %}

In the case of any of the latter options, the word ‘default’ will ensure that the plugin fills in the default values as defined by jsFiddle at the time of this plugin’s authoring. The defaults are as follows:

tabs: js,resources,html,css,result
skin: light
height: 300px
width: 100%

Examples

Basic Example

As the most basic use case, an example of a simple embed.

Syntax:

&#123;% jsfiddle ccWP7 %}

Adjusting Tabs

It’s possible to easily adjust the display order of the tabs. In this case, I’m moving the result to be the first item shown.

Syntax:

&#123;% jsfiddle ccWP7 result,js,html,css %}

Presentation: Skin

We can easily adjust the skin. Right now, it looks like light and presentation are really the only supported options, but if jsFiddle announces new options, you can start using them immediately.

Syntax:

&#123;% jsfiddle ccWP7 default presentation %}

Presentation: Height/width

We can also fairly easily adjust the height and width. In this case, I’ll make it a notably taller fiddle, so that everything can be read more easily (given that my fiddle has some write-up in the HTML with some notable output).

Syntax:

&#123;% jsfiddle ccWP7 default default 600px %}

Multiple Options at once

For each prior example, I’ve been changing just one piece, but nothing prevents me from adjusting multiple at once. For example, perhaps I want something really large for a presentation I’m giving, and I want my Results tab first.

Syntax:

&#123;% jsfiddle ccWP7 result,js,html,css presentation 800px %}

Summary

If you haven’t been using it, jsFiddle really is a pretty fantastic service. I’ve been trying to use it when I want to put up something simple and quick. I love GitHub as well, and gists are neat and all, but there’s something special about jsFiddle. This plugin should make it a lot easier to simply embed a fiddle (not that copy/pasting the iframe was hard).

I’ve submitted a pull request to the main Octopress repo, but if you want to grab a copy before it gets accepted (if it gets accepted), you can find it in my GitHub fork of it here. Here’s hoping you find some use for it!

Update: It’s officially a part of Octopress now! Here’s the documentation for it.

Conditions for Success

Sun, 31 Jul 2011 00:00:00 +0000

Earlier today, my friend Andrew tweeted the following:

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

— Andrew Hedges (@segdeha) July 31, 2011

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

Sat, 30 Jul 2011 00:00:00 +0000

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

Mon, 18 Apr 2011 00:00:00 +0000

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 jQuery.data 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.

Resources

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):

Proof of Concept: ScoreSettler

Tue, 29 Mar 2011 00:00:00 +0000

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.

What a crazy year

Tue, 30 Nov 2010 00:00:00 +0000

I remember when I used to feel a little shame in missing a post for one month. Then a few months. Now? We’re looking at nearly a year — and it’s been kind of a crazy year. It’s not over yet, but I find myself in a reflective mood tonight, so, hey.

In 2009, I spent some time playing with some HTML5 APIs, as evidenced by the drum kit and my little canvas demos and such. I’d spent more and more of my free time researching and studying JavaScript more and more. A lot of my little canvas demos had pushed me into looking into optimizations and ways to stop memory leaks.

I still wouldn’t call myself an optimization master, but I’d definitely picked up a number of best practices along the way, which led me to giving a couple of small talks:

Tuesday, March 2, 2010: HTML5 in 5 at IgniteNM 5
Wednesday, April 7, 2010: Rasters, Vectors, and Scripting, Oh My at Webuquerque (I seriously regret that goofy title)

Both talks were volunteer affairs – I wasn’t explicitly asked to talk, I just like to talk about things that excite me. However, the Webuquerque talk led me in an interesting direction.

Long story short, I took a chance, put myself out there, and earned a spot on the SitePen team. I’ve always been fortunate to work for good companies, but I have to say, working for SitePen has been an absolute dream come true. I get to work in JavaScript in some capacity every single day. I’ve gotten to build some really awesome things, to learn leaps and bounds in an immensely short period, and I work with some of the most amazing minds in JS today. It couldn’t be better, and I look forward to being a SitePenner for years to come.

Incidentally, if you’d told me ten years ago that I’d be working in JS every day and loving it, I’d have laughed at you, hard.

This year hasn’t been perfect, by any means. However, it’s definitely been a life-changing one. I really feel like I’m no longer just working a job, but really developing a career. I’ve had some amazing highs and amazing lows in 2010, and even though there’s still a month left to it, I know this year is going to go down in my books as one of the most amazing on record.

So, there’s that. I could say (again) that I’m going to try to post more (again), and I really do hope that’s the case. This blog’s definitely been more personal than technical in the past, but I suspect it’ll move more towards tech stuff at this point, with a rather heavy JS slant.

It’s not that I’m against personal sharing, and I’ll definitely be doing so, but it’s a different world and I’m a different person, and frankly, I suspect it’d be kinda boring if I told you all that I ate lunch at Dion’s again.

Oh, also, I’m down ~30 pounds this year too, which is nice, though I’m definitely kind of hitting up against a wall — but I can’t complain. I mean, 30 pounds is awesome.