Jason Rudolph

As Creative As We Make Time to Be

2013-01-23T00:00:00-05:00

Our creative products represent the best ideas we've had so far — the best ideas available to us based on the time and space we've allowed for creativity so far.

If we want our creative output to represent the best ideas we're capable of producing — as opposed to merely the strongest idea we thought of this morning — it's up to us to operate in a way that allows our best ideas to form. It turns out that their ability to form is dependent both on the way we approach our creative work and on the way we spend our time between periods of focused creative work.

Over the past year, my creative artifacts (e.g., prose, presentations, code) have benefited from that realization. And in large part, I credit that realization (and my specific techniques for acting on it) to the insight offered by these gentlemen:

Each of these items is worth absorbing in its entirety.

ClojureScript: 4 Things That Might Worry You, but Shouldn't

2012-09-11T00:00:00-04:00

When I first considered taking ClojureScript for a spin, there were several things that gave me pause: "What's the debugging experience like?" "How often am I going to find a problem in my app, only to discover that it's actually a bug in ClojureScript?" And so on.

I was new to ClojureScript (and fairly new to Clojure at the time as well), so I didn't take these things lightly. Once I got started, I was pleasantly surprised with the results. The actual experience wasn't just better than I expected; the actual experience was pretty darn good.

If you're on the fence about giving ClojureScript a shot, I hereby present: 4 things that might worry you, but shouldn't.

Debugging

My Worry

ClojureScript compiles [1] to JavaScript. Any error that occurs will be reported to me as JavaScript; probably as horribly obfuscated JavaScript. How am I going to trace that error back to the root cause in my ClojureScript code? Will I even have a fighting chance? [2]

My Experience

Finding the ClojureScript code that produced a JavaScript error is straightforward and reasonably fast. Despite coming to ClojureScript with little Clojure experience, it has never taken me more than 60 seconds to go from A) seeing a JavaScript stack trace in the browser to B) identifying the exact culprit inside my ClojureScript code. And on average, it's much faster than that.

When an error occurs, the console shows you the error and the file where the error occurred. When you click on the filename in the console, it takes you directly to the JavaScript line that generated the error. (Sounds familiar, right? Browsers have worked this way for an Internet eternity or two.)

For me, the surprise came when I viewed the compiled JavaScript. It provides all the clues you need to quickly identify the source of the problem. For starters, the first line of the file tells you the exact ClojureScript namespace that produced the error. Armed with that context, you're ready to look at the line of JavaScript that gave you the error. And as it turns out, that JavaScript looks similar enough to your ClojureScript code that you can perform the mental mapping between the two without much effort. [3]

The following screenshots illustrate this workflow.

API Stability

My Worry

ClojureScript is barely a year old. [4] I'll bet the dev team is still rapidly evolving the API. I don't want to have to fix my app every time I upgrade to each and every point release of ClojureScript.

My Experience

ClojureScript benefits from the stability of Clojure's API. I've upgraded the same app to new releases of ClojureScript several times. Only once did an upgrade require changes to my application code, and even then, those changes were minor syntax tweaks.

Quality

My Worry

Did I mention how young ClojureScript is? I'm okay with "leading edge," but am I prepared for the bleeding that goes with "bleeding edge?" Do I really want to be the guinea pig for some bug-ridden alpha software?

My Experience

ClojureScript is quality software with a responsive dev team. In eight months of working with ClojureScript, and through several ClojureScript upgrades, I've only been impacted by a single bug. I reported that issue on the mailing list at 7:30pm on a Monday night. Figuring that I wouldn't hear anything until the morning, I decided to go grab some dinner, and then work on something else.

Enter David Nolen. Fortunately for me, David hates dinner, and he hates software bugs even more. So for him, 7:30pm seems like a perfectly reasonable time to be churning through JIRA tickets. Clearly my expectations were too low; David wasn't going to let me wait 16 hours for a reply. Instead, he fixed the issue, committed it, and replied—in just 42 minutes.

I've paid good money for support nowhere near as responsive as this!

Performance Profiling and Tuning

My Worry

What the heck am I going to do when I discover that part of my app is too slow? I'm pretty sure there are zero ClojureScript performance profiling tools out there.

My Experience

While you're unlikely to find a ClojureScript-specific perf tool, the Google Chrome profiling tools give you what you need. [5]

Eventually, part of my ClojureScript app became slow—unusably slow. The Chrome profiling tools helped me track down the bottleneck. [6] The screenshot below describes the process.

Runtime Tooling in General?

Debugging and performance profiling are two specific worries I had. In each case, the existing JavaScript runtime tools were sufficient for satisfying my ClojureScript needs. (And in both cases, I already had those tools installed—they are built-in to the browser!)

The landscape of JavaScript runtime tooling extends well beyond these two examples. Is other runtime tooling similarly applicable for ClojureScript development? Perhaps. Where there's a runtime tool for doing x with JavaScript, it might just be a decent tool for doing x with ClojureScript as well.

What, me worry?

I approached ClojureScript expecting each of these things to be a source of pain. Thankfully, I was wrong. If any of them have caused you to think twice about giving ClojureScript a try, I contend that they shouldn't.

Notes

[1] "Transpiles" if you're nasty.

[2] Of course, this concern is not unique to ClojureScript. It's a longstanding worry for languages that compile to JavaScript (and probably for most other compilation targets throughout the history of computing).

[3] I suspect that one day—perhaps very soon—we'll have source maps for ClojureScript. When that day comes, we'll look back on the current workflow as "The Olden Days of ClojureScript Debugging." You know: when we used to walk 7 miles in the snow, uphill both ways, in order to track down the source of an error. But in all seriousness, while I look forward to having source maps for ClojureScript, the debugging experience is sufficient without them.

[4] Actually, my initial worry dates back to early 2012, when ClojureScript was even newer. Do I really want to dive head first into a six-month-old language?

[5] Safari, Firefox (via Firebug), and Internet Explorer offer similar functionality.

[6] It turns out that you probably don't want to construct a 30 kB string (30 kB!) for every single event that fires inside your app.

Thanks to Brenton Ashworth, Stuart Sierra, and Luke VanderHart for reading drafts of this post.

ClojureScript Experience Report: Resources

2012-08-17T00:00:00-04:00

Thanks to everyone who came out to the Triangle Clojure Users Group for my talk last night. It was great to see all the enthusiasm for ClojureScript.

For those that want to dig in further, here are the resources I mentioned:

One Rep Max — an open source ClojureScript app; the source of the experience behind this "experience report"
- Network architecture
- A sample event flow
ClojureScript One
- one.dispatch — event dispatching library
- Design mode
Domina — DOM manipulation library
Converting from JSON to Clojure data and vice versa
- js->clj (from cljs.core)
- clj->js (from Chris Granger's fetch library)
Shoreleave — up-and-coming collection of ClojureScript libraries
ClojureScript: Up and Running — soon-to-be-beta book from Stuart Sierra and Luke VanderHart

Enjoy!

Programming Achievements: How to Level Up as a Developer

2011-08-09T00:00:00-04:00

How does a good developer become a great developer?

Forget greatness for a moment: How does a decent developer become a good developer?

There is no definitive path from Step 1 to Step n. Heck, it's not even clear what Step n is. And as logically-minded developer types, the lack of a well-defined route can make for a daunting journey from novice to master.

I've spent a fair bit of time over the last few years bumping up against this conundrum. What's next? How do I go from being a good developer to a being really good developer?

What Does Success Look Like?

I do my best work when I have a goal with clear, measurable criteria for success. For example, I want to run a 5-minute mile. Okay. That's easy to measure, and success is well-defined. I can figure out how fast I can run a mile now, and the Web is full of advice and training programs for getting faster. I can choose a training program, work hard, and I can be confident that I'll eventually get where I want to be. And it's so wonderfully measurable that, every week, I'll know just how close I am to my ultimate goal.

But how do you measure whether you've attained the rank of "really good developer?" In short, you can't. That goal, as stated, is too subjective, too vague, and is simply not measurable. So how do we find something that is measurable?

Much like the goal of wanting to run a 5-minute mile, we can start by looking at where we are as a programmer versus where we want to be. What experiences has a 5-minute-mile runner exposed himself to that a 10-minute-mile runner is lacking? What experiences has the master programmer benefited from that the novice programmer is missing? It's the experiences that matter.

We've all had specific experiences that clearly advanced our skills as developers. We've learned a new language that exposed us to a new way of thinking. Or we crafted the perfect design, only to watch it unveil its gross imperfections in the harsh realities of a production environment. And we became better programmers because of it. Some experiences equip you with new techniques. Others expose you to anti-patterns...and allow you to understand why they are anti-patterns. It's these experiences that teach you, that influence your thought process, that influence your approach to problems, that improve your designs. And conveniently, it's simple to measure whether you've gained a particular experience. (It might be fun to think of them as achievements.)

So it took a while, but I'm becoming more comfortable with the immeasurability of my pending goal: earning the rank of "really good developer." If such a developer earns this distinction because of his experiences, then maybe we can still have a well-defined path marching in the general direction of "really good developer" and beyond. I suspect that path looks something like this:

Identify the experiences that advance a person as a developer.
Select a particular experience to pursue.
Pursue that experience to completion. (Achievement unlocked!)
Reflect on that experience. Really soak it in. [A]
Return to Step 2, this time selecting a new experience.

And what better way to get started with Step 1 than to crowdsource it? Here's a first cut at a list of programming achievements, loosely organized into groups. [B] I'll offer multiple ways for you to chime in with your thoughts at the end.

Achievements

Learn a variety of programming paradigms:

Write a program in assembly language
Write an application in a functional language
Write an application in an object-oriented language
Write an application in a prototype-based language
Write an application in a logic programming language
Write an application using the Actor model
Write an application in Forth [C]

Experience the ins and outs of programming for different platforms:

Write a nontrivial web app
Write a nontrivial desktop app
Write a nontrivial mobile app
Write an embedded app
Write a realtime system

Enhance your understanding of the building blocks that we use as developers:

Write a networking client (e.g., HTTP, FTP)
Write a device driver
Write a B-tree database
Wrap an existing library to provide a better (more pleasant) user experience
Write an application or framework that provides a plugin model
Write a testing framework
Write a programming language

Enlighten yourself with koans, katas, and the wisdom of ages:

Complete five code katas
Complete the programming koans for a language that you want to learn
Attend a code retreat
Read SICP and complete all the exercises

Program in the open:

Contribute to an open source project
Have a patch accepted
Earn commit rights on a significant open source project
Publish an open source project
Perform a Refactotum of an open source project

Learn by teaching others [D]:

Present a lightning talk
Present at a local user group
Present at a conference
Deliver a training course
Publish a tutorial
Publish a constructive code review of an open source project
Write a programming book

About the Achievements

Now, let's go meta for a moment. Note that each of these achievements is measurable. Each one is Boolean: you've either completed it or you haven't. For example, it's hard to measure whether you've learned a functional language, but it's easy to know whether you've written an app in a functional language. The latter is observable. Measurable. Boolean. This measurability applies, quite intentionally, to all of these achievements.

Admittedly, the measurability isn't perfect. Consider the achievement of presenting at a conference: you could certainly do a half-assed job just to say you've earned this achievement. But if you're reading this post, I assume you want to be excellent. You know that it's lame to phone it in just to cross an item off the list.

Since We're Talking About Improvement ...

Since we're talking about improvement, what would you change about this list?

The list is available as a gist on GitHub. Feel free to fork it and add more achievements. (Make sure they're measurable.)

Or, fork it and mark off the achievements you've already conquered. You might even flag the one that you're currently working on. (For example, check out these forks from Justin Blake, Pierre Chapuis, and Yann Esposito.) [E]

Or just sound off in the comments: What experiences have made you a better developer? And what achievement will you unlock next?

Notes

[A] I can't emphasize Step 4 enough. To get the most out of each achievement, you owe it to yourself to pause and reflect on the experience before you move on to the next one. Introspect. Ask yourself what you learned. Take the time to write down those thoughts. And even better still, share them with someone else and see how your learnings compare to other people who've also earned this achievement.

[B] It's interesting to see some aspect of this achievement-based model at work on coderwall.com.

[C] Forth is essentially its own paradigm.

[D] This quote comes to mind: "Whoever teaches learns in the act of teaching ..." — Paulo Freire

[E] Nathan Hwang has developed and open sourced a tool for visualizing and tracking your journey through these achievements.

Updated 8/9/2011 4:32pm UTC - Added links to example forks of the achievement list.

Updated 11/27/2011 8:10pm UTC - Added links to Nathan Hwang's contributions.

Thanks to Michael Parenteau for providing the artwork for this post.

Thanks to Michael Nygard, Glenn Vanderburg, Alan Dipert, and Vojtech Rinik for providing feedback on drafts of this post.

Helpful Resources For Upgrading to Rails 3.1

2011-06-06T00:00:00-04:00

The first Rails 3.1 release candidate has been out for a couple weeks now, and the official release of 3.1.0 can't be far behind.

Upgrading To Rails 3.1

I upgraded a Rails 3.0 app to 3.1 this past weekend, and all in all, it was a pretty smooth process. Along the way, I was grateful to discover a few helpful posts from developers that had already made this journey. If you're getting ready to upgrade an existing app to Rails 3.1, or if you just want to get a feel for what to expect, I recommend checking out these write-ups.

More Rails 3.1 Resources

If you're already up to speed on all the new features in Rails 3.1, then you're ready to give the upgrade a shot.

Still here? Well, I'm guessing that means you want to spend a bit more time wrapping your head around what's new in Rails 3.1, and then you'll be ready for the upgrade. Good news: you've got quite a few resources to lean on:

The Big Picture

Individual Features

Party On, Dudes

If Rails 3.1 has piqued your curiosity, it's definitely worth a quick spike to try out an upgrade. Just create a branch and give it a shot. After all, you wrote all those tests for a reason, right? Take Rails 3.1 for a spin, and let your test suite tell you where things need to be patched up. What have you got to lose? Party on, Dudes!

Updated 8/27/2011 - Added links to the asset pipeline docs from Ryan Biggs and the new RailsCasts episode on "Understanding the Asset Pipeline."

Updated 9/6/2011 - Added link to the new RailsCasts episode on "Upgrading to Rails 3.1." Added link to the official Rails 3.1.0 release announcement and release notes.

Now Available: Getting Started with Grails, Second Edition

2010-02-08T00:00:00-05:00

The first edition of Getting Started with Grails was well received. Matt Raible even dubbed it "the perfect book to learn the basics of Grails quickly." But technology moves fast, and Grails has certainly been no exception. Much has changed since the days of Grails 0.3—the then-current version of Grails in January, 2007. So when Scott Davis offered to bring Getting Started with Grails up to date, who was I to say "No?"

Today, Scott and I are pleased to announce that the second edition of Getting Started with Grails is now available as a free PDF [1]. Or, for those that prefer the crisp feel of the printed page, the paperback version is available as well.

In addition to being the first book fully compatible with Grails 1.2, the second edition expands on the coverage of the first edition. You'll find entire new sections tackling a variety of key topics from plugins, to codecs, to services, and more. And thanks to the testability improvements introduced in Grails 1.1, you'll also find an increased emphasis on testing.

Still here? What are you waiting for? Grab the book and get started. We hope you enjoy it!

[1] InfoQ requires that you register before you can download the PDF, but registration is free and only takes a moment.

Live JavaScript TDD Action Coming to raleigh.rb

2009-07-15T00:00:00-04:00

Next week at raleigh.rb, Larry Karnowski and I are pairing up for a round of live test-driven JavaScript development with Blue Ridge. Come see how easy and natural it can be to give your JavaScript code the testing love it deserves.

The meetup is at 7 PM on Tuesday, July 21. Hope to see you there!

Git Up! 10 Reasons to Upgrade Your Old Git Installation

2009-05-27T00:00:00-04:00

Git has seen a huge influx of newcomers over the past year. Many folks installed Git as they read through their first tutorial, got it working, and are still using that same trusty installation today. But rest assured, Git has not been standing still.

If you installed Git a year ago (perhaps when Rails made the move in April of last year), you would've grabbed v1.5.5. The Git team has cranked out five feature releases since then, full of usability improvements, a few new tricks, and, of course, numerous bug fixes. So it's time for some spring cleaning of your dusty old Git installation.

If you're not yet sportin' the 1.6.3 hotness, here are ten reasons to Git up!

And this is by no means an exhaustive list. An upgrade from v1.5.5 to v1.6.3 includes well over 100 improvements. While no one of these improvements is revolutionary, they each make this awesome VCS just a tad nicer. And collectively, they make it well worth the upgrade.

So what are you waiting for? Invest five minutes right now to upgrade. C'mon. You're sittin' around reading blogs. What else have you got to do? Git up!

Notes

If you're on OS X, I recommend using MacPorts for quick and easy upgrades. Let Rob Sanheim show you the way.

Image courtesy of Midnight Digital (flickr.com/midnight-digital). [Creative Commons License]

RailsConf 2009: JavaScript Testing in Rails Projects. No, Seriously!

2009-03-24T00:00:00-04:00

Going to RailsConf in Las Vegas this year? Larry Karnowski and I are presenting a session on giving your JavaScript code the testing love it deserves.

Our talk is on Tuesday, May 5 at 1:50 PM in Ballroom B.

JavaScript Testing in Rails: Fast, Headless, In-Browser. Pick Any Three.

You wouldn’t consider developing a Rails application without having a solid test suite for your Ruby code, but you’ve somehow convinced yourself to cross your fingers and look the other way when it comes to JavaScript. It doesn’t have to be that way. In this session, you’ll learn how to apply test-driven and behavior-driven development to your unobtrusive JavaScript code in a Rails-friendly manner.

Hope to see you there!

Developer Day: Evolving Your Git Workflow, and Much More

2009-03-12T00:00:00-04:00

Next Saturday, March 21, Viget Labs and Relevance, Inc. are presenting Developer Day, a one-day conference representing a veritable cornucopia of high-tech awesomeness.

Here's the rundown:

Staying current with the ever-evolving technological possibilities can be challenging, but you love trying. Why? Because you’re a fantastic web developer who loves building things, (and, frankly, that's just how you roll).

Which is why this conference is perfect for you.

Hear eight presentations given by active practitioners on topics ranging from JavaScript and Scala to Rails performance and security. Each is tailored to give you insight into various topics that may positively influence how you work, regardless of your specialization.

So, come meet cool people, eat some lunch (from local Durham restaurants), and give yourself the day to learn and participate in several great discussions — all for the low, low price of $50.

I'll be speaking about taking your Git-fu to the next level.

Evolving Your Git Workflow

Git has attracted many developers away from various centralized source control tools, but it’s easy to find yourself using Git like a slightly-better variant of your old VCS. “You don’t even have to be online to commit. Cool!” That’s a nice touch, but Git has way more to offer, and by picking up a few intermediate and advanced Git techniques, you can save a ton of time (and sanity) for yourself and your team.

Check out the site for registration and full details. Hope to see you there!