dan-menard.com

Software architects are a strange breed.

They obsess over code quality. They can’t explain anything without a whiteboard. They adore design patterns that most of us have never even heard of.

When the project is in trouble, they swoop in and save the day.

And they constantly reject my patches.

But I’m thankful for that — all of it. I’ve been fortunate enough to work with some really, really great architects in my (admittedly short) career, and through it all I’ve managed to distill the one skill possessed by every great architect I’ve ever met:

The ability to identify potential pitfalls.

Expecting something more dramatic? Well, tough luck. I know it’s not sexy, but if you want to be a great software architect someday, you need this skill.

Here’s why:

Pitfalls are easy to spot when building a room.

The wife and I are currently finishing our basement. I’m learning a lot during this process, like how to make sure a wall is straight, and the joys of using a ramset.

And of course while I’m swinging that same old hammer into about the fiftieth 3″ nail, my mind starts to correlate what I’m learning about building a room to what I know about building software.

The biggest realization so far?

In simple construction, spotting potential problems is very easy.

If you line up a 2×4, you’re going to notice if it’s not the right size. Measure again, cut again. Problem solved.

If you have to extend some piping, it’s easy to grok the current pipe system and figure out where to make a cut. Plumbing refactored, job well done.

If you’re about to fire a nail through a plank of wood to affix it to the floor, it’s easy to visualize that you’ll have trouble cutting out a doorway there later. Nobody wants to hack through molten metal, so put those nails around where the door is going to be. Crisis averted.

In fact, it’s so trivial to see problems in advance that we’ve yet to make any major mistakes. This is amazing to me! Can you imagine saying anything like that about a software project? (Even a small one?)

Of course you can’t. And you already know why:

Pitfalls are nearly impossible to spot when building software.

How many times have you had to refactor some code you wrote last month, because it wasn’t up-to-snuff? Or had to completely re-write a feature that you implemented earlier in the project?

Seeing potential pitfalls in software is hard.

You would never build a cutting-edge webapp, then turn around and brag about how you got everything right on the first try. Your fellow developers would think you’re crazy, and your QA wouldn’t be able to stop laughing.

Every software developer makes mistakes all the time. Functions that aren’t quite single-purpose, dependencies that aren’t strictly necessary, routines that are a little too verbose. And we always end up paying for it later. Who will save us from this madness?

Architects, that’s who.

Great software architects mitigate rework and lost time by identifying pitfalls in advance.

They can look at a framework and tell you if it’s too abstract or not abstract enough. They can examine an existing codebase, and have a pretty good idea of where to start refactoring. They can tell when a new patch is going to break a valuable design pattern, or introduce inconsistencies into the codebase, or need to be re-written before the end of the next sprint.

This skill, this ability to look at some seemingly-harmless change and intrinsically know what problems it will cause later — it’s amazing. I don’t understand how they do it, and I don’t know if I’ll ever acquire that talent.

But I know it’s something I admire. And if you ever want to become a great software architect, this is the one thing you need to get right.

Now if you’ll excuse me, I have to go fix up my latest patch…

The last day of SenchaCon was a hackathon, where everyone that stuck around (probably over 100 people) grouped together and hacked away to see who could make the coolest one-day project. There were a LOT of great apps, and several came away with cash and prizes (all of it very well earned!).

Not featured in the winners list is the app I made, because I missed the submission deadline by about twenty minutes. All this because I lost far too much time debugging issues with HTML5′s native drag-and-drop API. (I was planning on writing a rant about it, but Quirksmode beat me to the punch.)

In any event, I’ve uploaded the incredibly raw creation, and you can now play my simple HTML5 Video Puzzle Game. I only tested in Chrome, but it seems to run alright in the latest Aurora build of Firefox. Basically the app loads up an HTML5 video, slices it into 16 canvases, and scrambles the pieces. Your job is to re-arrange them by dragging them back into place (using HTML5′s native drag-and-drop, of course).

It’s really, really unpolished. I spent all of about 8 seconds on the styling, and there are a lot of features that are complete but inaccessible (like slicing the video into more pieces). I might try to fix it up later.

Anyway, the whole day was a lot of fun, just like the rest of the conference. It would be awesome to go again next year. We’ll see!

Until then, happy hacking, all my fellow attendees!

Most Sencha Touch applicaions are small, single-purpose mobile apps. Those aren’t the ones I’m talking about.

Over the past 9 months, I’ve worked on a Sencha Touch app with a team of 15 people. It’s for a major, world-famous client. It contains tens of thousands of lines of code. It could be the biggest Sencha Touch app ever built.

My talk will be about how we built it, and how we made it perform well despite the sheer size of the application.

If you’re at SenchaCon, and this sounds like something you want to know more about, here are the details:

Time:
11:35am — 12:20pm

Session Name:
Community Code: Macadamian

Location:
Grand Ballroom, Section 3, 6th Floor

Hope to see you there. I’ll be the guy glowing with enthusiasm :)

Click for full size.

We had a great time.

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. This week’s post was the first to be published after the switch to regular, weekly updates. Here it is again, better than ever!

2009 was an exciting year for the web browser crowd:

• Google released Chrome.
• Apple ported Safari to Windows.
• Firefox picked up a lot of market share.
• Microsoft actually produced a half-decent version of Internet Explorer.
• The iPhone and Android finally made mobile browsing popular.
• Support for HTML5 and CSS3 was way up across the board.

The term crowd is especially appropriate here because it really is starting to get very crowded. For a long time the browser war has been fought largely between two major players at a time (IE/Netscape, IE/Firefox) and all of a sudden we have four major companies with fantastic browsers available to the vast majority of users.

Oh, and then there’s Opera.

Here’s the thing about Opera…

Opera is in serious trouble because it doesn’t have a “thing”:

Internet Explorer’s thing is its existing market share. It has a lot more users than everyone else, so its going to be relevant for the foreseeable future.

Firefox’s thing is its community. Not just its core developers, but the people who create addons or personas or rally everyone they know to go download the latest version on launch day. It’s easily the most passionate user group of the bunch.

Chrome’s thing is its brand. When people think web, they think Google. Google has the best search, the best email, why not the best browser? Users rely on Google for a great online experience, and Google has a lot of high-traffic areas where it can push Chrome.

Apple’s thing is its loyalty. Apple fanboys are a loyal bunch — most of them will stick with Safari on their Mac and many will consider getting Safari for any Windows computers they’re forced to use. Apple also has the iPhone, which gives it a growing space where it has the only browser (not that any iPhone users mind — loyalty, remember?).

What does Opera have? The Wii? Please.

• It used to be the most advanced browser for HTML5 support, then everyone else caught up.
• It used to be a major player in the mobile space, then Apple and Google obliterated it.
• It used to be a fun browser for geeks to talk about, but now the buzz is all Chrome.

Simply put, it’s not enough to be an alternative to IE anymore; users are demanding more from their browsing experience, and they’re flush with places to find it.

Any Opera fans out there?

What’s even worse is that there isn’t really anything you or I can do to help.

Opera’s engine isn’t open source, like Gecko (Firefox) or Webkit (Chrome/Safari), and it doesn’t benefit from a strong plugin community, like Firefox/Chrome. It isn’t an OS-default browser like IE (Windows), Safari (OSX) or Firefox (linux). Even if I wanted to rally some Opera enthusiasts, where would I start? How many people do you know that have even heard of Opera?

I don’t have anything against Opera (it’s a fine browser), it’s just it has fallen behind the times — there are too many better options around preventing Opera from picking up new users, and I can’t think of a single significant reason for its existing users to stick with it.

Do you use Opera? Care to share any thoughts on Opera’s future?

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. Like last week’s resurrection, this is an old favourite of mine, updated for your reading pleasure.

One of my favourite things about New Year’s Eve is making resolutions. You know, those promises to ourselves that we can never seem to keep.

I like this ritual because I like setting goals for myself. One of my resolutions for 2010 was to have a new post up every Monday (a tradition I’ve kept to this day). I made other resolutions that year as well, and as ridiculous as it sounds, by March I was already planning resolutions for the following year.

That’s when it hit me:

Set goals more than once per year.

Why wait until some arbitrary holiday to set goals for yourself?

You can set realistic, helpful, attainable goals right now. And they don’t have to be scoped to a full year, either.

Mix it up and have some that are month- or week-based. Short-term goals are easier to keep, provide benefits right away, and can help build confidence to hit more lofty goals that take a bit longer to reach.

Here are some goals that I’ve set for myself recently:

• (for 2010) Write a blog post every Monday.
• (for March) Cook breakfast every morning.
• (for this week) Get up every day at 6:30am.

Each of these goals has taught me something interesting.

I’ve learned that writing blog posts gets easier the more you do it. That cooking a full breakfast helps me sort out my day (and is delicious). And that I am absolutely not meant to be up at the crack of dawn.

This brings me to my next point:

It’s ok to fail.

Many of my goals don’t play out exactly as planned, and sometimes they get completely cancelled if they turn out to be terrible ideas (6:30 mornings, I’m looking in your direction).

The point is to experiment and see what works for you.

Instead of becoming discouraged when you’re consistently not hitting a goal, pause and consider if this is really a goal worth pursuing. Did you over-estimate how much you could do? Is there a better way to get the result you were after?

Often it’s the goal that is the problem, not you.

Here’s how I hit my goals:

I use a few simple tricks to keep up with whatever goals my past-self may have signed present-me up for. This is what works best for me:

First and foremost, I try to be realistic. It won’t do me any good to set a goal that I won’t be able to reach, so especially for goals that are more than a week long, I’ll run my idea by someone I can trust to give me honest feedback.

This way if a goal is too ambitious, at least I’ll have a red flag telling me that I may need to adjust my targets. Of course, ultimately I know best; if I really think I can do something, I’ll still try it even if the feedback I’m getting back isn’t all roses.

Second, I find it helps to tell people if it’s an interesting goal (like breakfast). Maybe they’ll want to do it too, which makes motivation easier, or maybe they’ll pressure me into remembering to do it, which is nice when needed.

I find this works really well for me, for certain types of goals. However, it seems my opinion on this subject is not very popular. Your mileage may vary!

Third, I find it’s important to give myself visual reminders of my goals.

The tool I use most for this is a web-based task-management application called HiTask. For my month-long breakfast experiment, for example, I added a task to HiTask with a flashy-coloured label and a star, so that it really stuck out and was always at the top of my to-do list.

Low-tech works as well: At the start of the year I printed out a grid of every Monday in 2010, broken down by month, so that I could check them off after publishing each weekly post.

Does any of this sound useful to you?

I’d love to hear about what’s helping you hit your goals right now. What tools do you use? What strategies work for you?

If you haven’t set any goals for yourself lately, why not start now?

(What do you have to lose?)

This post is part of the Classics Week(s) feature, which will run for three weeks while I’m off overseas. It’s the first of three posts from the early days of the blog, dug up from the archive and polished ’til good as new!

Ladies and gentlemen, allow me to share with you a tale of two photographers.

Back in the summer of 2010, my fiancée and I were featured in a piece for our local newspaper. The columnist wanted an image to accompany her content, and sent a photographer to our apartment to take a photo of me and my soon-to-be bride.

The photography session played out as I’d expected. Some nondescript ‘dude’ with a camera sauntered in, looked around the room for all of about six seconds, arranged a semi-interesting shot involving a mirror, snapped a few pictures and left. Took around ten minutes.

A few days later, the writer called back and asked if she could send over another photographer. Apparently the shot the boring fellow took was too similar to a shot the newspaper was running on another article — on the same day, in the same section — so they needed a different one.

The second photographer was Christopher Pike.

Christopher ran things a bit differently. After introducing himself, he spent a few minutes looking around our humble abode and the surrounding area. He then asked what my fiancée and I thought of a few potential shots, and started taking pictures.

Many pictures.

We posed on our balcony. We posed on a bench. We posed near a wall, and then next to a fence. Every time Christopher noticed something that might make for a cool shot, he asked if we wouldn’t mind another photo.

After about an hour of this, he thanked us and left.

Like the first photographer, Christopher was a freelancer hired by the newspaper. Presumably, the two of them were each paid the same amount for their work. But while the former spent ten minutes taking a picture he had decided upon in advance, Christopher spent seven times that long experimenting and looking for the perfect shot.

What does this have to do with programming?

Just like photography, programming is a craft.

That first photographer, the one whose name I couldn’t be bothered to remember, was just in it for the job. The columnist wanted a cute photo of a young couple, so our unremarkable photographer snapped an equally (un)impressive shot, and left.

This is how unremarkable coders look at programming. You need a function that converts X inputs into Y outputs? Sure. Let me whip up a quick algorithm that does that. Done. What’s next?

Christopher, on the other hand, was there to take great pictures.

He was passionate, and he approached photography as a craft. Yes, the result was still just a photo to sell to a newspaper, but believe me when I tell you that’s not why Christopher is a photographer.

Here’s how I look at coding (and hopefully how you do too):

You need a function that converts X inputs into Y outputs? Ok. Let’s first consider the context, ask a few questions, then create a proper solution. Functionally, it may be the same as Joe-first-photographer’s solution, but a programmer that cares about his craft took the time to:

• Verify that a single function is in fact the best solution.
• Keep future maintenance and extensibility in mind.
• Write clear, reusable code.
• Add useful comments when necessary.
• Refactor the function to be as simple as possible.
• Switch spaces to tabs to match the existing code-base.

Which photographer would you rather hire?

Which programmer would you rather have on your team?

Later today I shall board a plane bound for Europe.

I won’t be back for a full three weeks. But fear not! While I’m out gallivanting about, amidst fine architecture and breathtaking scenery, you will not be left without updates.

Introducing Classics Week(s)

It occurred to me that this blog has been around for a couple of years now, and not all of you were here in the beginning. You’ve probably missed some great posts!

This is unacceptable, and I’ve devised a solution:

Every Monday for the next three weeks, this blog will feature a re-run of a classic post from the early days of its existence.

I’ve selected three of my favourites and given them a quick sprucing-up. I tried to choose a matching set of posts; the goal was to reflect the general content of the blog. In any event, you’ll have something nice to read, and that’s what counts.

The only internet-capable device that will be near my person for the duration of this adventure will be the wife’s iPod Touch, so I’m not expecting to check my mail very often. I’ll also be slow at approving and replying to comments, and you won’t see much of me in my other haunts.

This does not mean you should avoid emailing me and posting interesting tweets. Quite the contrary! I look forward to conquering a content mountain upon my return. Heaping piles of hypertext and prose!

Like a little ASCII version of the alps :)

See you in mid-October!

I’ve been using a Mac at work for the past few months. It’s refreshing.

My first computer that was actually my very own computer was an iBook (G3) back in 2003 or so. I loved it. I downloaded all kinds of software to make it do interesting things (or do boring things in interesting ways), and when I ran out of things to download I fired up Applescript Editor and wrote some myself.

Having not used a Mac regularly for a few years, I was a bit curious to see how quickly I would get back to my old ways when I was put on an iPad project. The answer: not long.

I thought it might be fun to share my setup in case some of these tools are useful to anyone else. For posterity, I’m using Snow Leopard on a Mac Mini, with a standard Apple keyboard and a Magic Mouse. (Lion and a touchpad should work just as well.)

Let’s start with the easy stuff.

Even without any mucking around, OSX is somewhat configurable. One of the first things I did on my new office Mac was re-map the Exposé hotkeys.

The default function keys are nice, but on the keyboard accompanying my Mini, I have to hold down the Fn key before hitting F11 to reach Show Desktop. This is annoying; I use that functionality all the time, and those keys are on opposite corners of my keyboard. System Preferences to the rescue:

By opening System Preferences, then Exposé and Spaces, you can re-wire the hotkeys for Exposé settings.

I use Right-Command, Right-Control, and Right-Shift for All Windows, Application Windows, and Show Desktop respectively.

Another big one is Hot Corners. A lot of people like to map Exposé-type actions here, but I prefer screen-related actions. The only one I have set right now is my top-right corner, which puts the entire display to sleep.

That’s not all a vanilla install can do, either. Check out System Preferences > Keyboard and Mouse > Keyboard Shortcuts for more options.

Hide and seek.

Hide is my favourite feature of OSX. In any application, press Cmd+H and the app will disappear. This is not the same as minimize, which eats valuable Dock-space; hide causes all application windows to completely vanish. To access a hidden application, either re-launch it or cycle to it using Cmd+Tab.

That’s good already, but for applications I use all the time, I like to have a single, global access shortcut. What I want is to hide the app if it is open, and bring it back into view if it’s hidden. I do this with a handy Applescript that looks like this:

if application "Application" is frontmost then
    tell application "Finder" to set visible of process "Application" to false
else
    tell application "Application" to activate
endif

Replace “Application” with the name of whatever application you want to show/hide, and voilà! You’re all set!

Well, almost. We still need a way to bind that script to a single action. Now how are we going to do that?

Enter BetterTouchTool.

BetterTouchTool is a shareware application that adds improved touch events to OSX. It works beautifully with my Magic Mouse, and I’ve heard it’s just as useful for trackpads on all flavours of Macbook.

That show/hide script is one use, but I have others set up as well:

• Two-finger swipe up: Home (scroll to top of page).
• Two-finger swipe down: End (scroll to bottom of page).
• Two-finger tap: Show/hide Mail.
• Three-finger tap: Show/hide iCal.
• Two-finger click: Zoom (the green button in OSX window toolbars).
• Three-finger click: Launch Divvy.

In general, I like to give mouse actions to tasks that will be followed by more mouse actions. For example, I also have a show/hide script for Skype, but I’ve mapped that to a keyboard shortcut; I’m going to be typing as soon as I get into Skype, so I might as well use my keyboard to get there in the first place. For apps where I tend to be more mouse-focused, like Mail and iCal, it makes more sense to access them from my mouse.

I’ll also re-map actions that I find hard to use. That zoom button is pretty out of the way, a two-finger click anywhere on the screen is much nicer. Same for Home/End, especially since I generally scroll with the mouse anyway.

Divvy is another obvious candidate for a mouse-based trigger. If you’re unfamiliar with it, go check out what it can do — it’s a great tool for managing window sizes/locations.

Bring on Quicksilver!

Quicksilver is easily my all-time favourite OSX application. I use it constantly, and it’s the very first thing I installed when our IT guy dropped off a Mini at my desk.

I could write an entire ebook about why Quicksilver is the best thing that’s happened to MacOS since the transition to OSX, but I’ll stick to two main bullet points describing what QS is:

1. A keyboard launcher.
2. A trigger-management tool.

That first point is boring and I’m not going to cover it. There are plenty of other keyboard launchers out there, and they all work about the same way as far as “opening applications with your keyboard” goes.

Now triggers, that’s where things get interesting.

Like BetterTouchTool, Quicksilver lets you run scripts and other actions when “something happens”. In this case, something happening can be as simple as a hotkey being pressed, but plugins for QS add many more interesting possibilities. (We’ll get to my favourite shortly.)

I’m going to start with my hotkey setup. As I hinted at already, I have one of my show/hide scripts bound to Skype. I trigger it with F6. I find this is really useful for “peeking” at Skype to see if any important IMs require my attention — one touch to bring it up, another to dismiss it, and my tab order is unaffected.

I’ve also mapped some hotkeys specific to iOS development: I’m such a fan of Cmd+Ctrl+Up Arrow and Cmd+Ctrl+Down Arrow (for switching between .m and .h files) that I’ve set application-specific hotkeys in XCode and the iOS Simulator to switch between one another on Cmd+Optn+Ctrl+Up Arrow and Cmd+Optn+Ctrl+Down Arrow.

I have another app-specific key binding on my iOS Simulator: I’m working on an iPad application that requires login on start-up, and a while back they changed the default user’s password from “jones123″ to “Oncologist”. I don’t know about you, but I can’t reliably type Oncologist (case-sensitive!) when I’m half-awake at the tail end of a twelve-hour day. So, I scripted it:

tell application "System Events" to keystroke "Oncologist"

This simple script fires whenever I hit Fn+Enter inside the iOS Simulator. It’s immensely convenient, and much faster than typing myself (even if you don’t count the time wasted when I don’t get it right).

I’ve also added a global hotkey to trigger screen lock. Quicksilver provides some convenient options for hotkey events, and the one I used here was the “Hold for” modifier. Now, when I hold Esc for a couple of seconds, QS fires a call to OSX’s built-in screen lock. It’s a little finicky, and my real usage is more like “mash Esc for a few seconds”, but hey, it’s a throwback to how I use vim :)

Ready for something a little more novel?

The magic word.

Abracadabra is a Quicksilver plugin that lets you activate triggers by drawing custom shapes on the screen with your mouse pointer. Sound a bit crazy? It is. And really useful too! This is much better explained with video, and fortunately there’s an Abracadabra screencast you can check out to see it in action (along with how to install it).

I have a couple of simple drawing gestures in place to control system volume: A straight line up for louder and a straight line down for quieter. I’m also a total neat-freak when it comes to my Downloads folder. I clear it out several times per day, and using Abracadabra, I trigger a purge by drawing an X on-screen. It’s super-cool!

Here are the scripts if you’re curious:

set currentVol to (get (output volume of (get volume settings)))
set volume output volume (currentVol + 10)

set currentVol to (get (output volume of (get volume settings)))
set volume output volume (currentVol - 10)

set pathToDownloads to "~/Downloads"
set pathToMailDownloads to "~/Library/Mail Downloads"

tell application "System Events"
    set filesInDownloads to every disk item of folder pathToDownloads
    repeat with eachFile in filesInDownloads
        delete eachFile
    end repeat
end tell

tell application "System Events"
    set filesInMailDownloads to every disk item of folder pathToMailDownloads
    repeat with eachFile in filesInMailDownloads
        delete eachFile
    end repeat
end tell

For the music lovers…

iTunes is heavily scriptable. Back on my iBook, I had all kinds of scripts wired up to Abracadabra for changing tracks, toggling shuffle, and all sorts of other functionality.

But lately, I’ve moved to Grooveshark.

Since Grooveshark is a webapp, it’s not very accessible to Applescript or apps like BetterTouchTool and Quicksilver. It also slows Safari to a crawl.

These issues can be solved by running Grooveshark in a single-site browser. I’ve taken a liking to Fluid.

Now that Grooveshark is running in its own application space, we can do all kinds of neat things to it. For now, I’m content with only a couple of scripts:

As you might expect, I have a show/hide script set up for it. This one is triggered via Abracadabra (I invoke it by drawing the musical sign for a flat). I also have a play/pause script, again triggered by Abracadabra, this time with a horizontal line (the fastest, easiest thing to draw).

I tend to stick to Abracadabra for music-related actions; it’s a bit of a tradition as this is what I used Abra for on my old iBook. Hotkeys, BetterTouchTool events, and any other action that lets you run an Applescript will work just as well.

Talk like a duck.

Lastly, you may have noticed a tweet I sent out the other day about Adium and Growl. Here’s a longer description of that hack:

If you use Adium (and you should, it’s a fantastic multi-account IM-chat app) you can have Growl deliver your notifications. This will put little, unobtrusive pop-ups on your screen, alerting you of Adium events. New messages, contacts going online/offline, that sort of thing.

Adium’s notifications are highly customizable, and likewise for Growl. Better yet, Growl provides a number of different formats for its messages. Most are visual, but I recently noticed there’s one called “Speech”.

If you open System Preferences > Growl > Applications > Adium > Configure and set the Display Style to Speech, Adium’s notifications will be read to you, out loud, in a default OS-system voice.

I absolutely love this for message alerts when Adium is not in focus. I can continue to wrap up what I’m doing, half-listening to whatever Growl is reading out. This allows me to judge whether the incoming IM is worth interrupting my current task for, and if it isn’t, I can just keep on working.

I’ve only had it live for a few days, and of course this kind of behavior will get spammy if you don’t wear headphones regularly or you get a ton of IMs from Adium, but I get downright giddy every time it goes off.

The scripts.

I can’t give you a download that will set up Quicksilver, et al. for you, but I can hook you up with a convenient zip of the various scripts I’ve mentioned above.

(I’m not providing a license; they’re a gift. Use them however you please.)

What are your hacks?

Now it’s your turn to share.

I’d love to hear what you’re doing to optimize your environment. Do you use any of the hacks above? What else are you fond of? Am I overlooking anything especially awesome?

Happy hacking!

I didn’t realize it at the time, but back in July (oops) this blog saw it’s one-hundredth post! Sadly, this milestone wasn’t marked by a thoughtful piece about the current state of Firefox or a bold prediction about Google+ — my one-hundredth post was me wishing my fellow Canadians a happy day of patronage.

Not exactly a classic, but I’ll take it :)

I still remember those first few posts I wrote back in the fall of 2009. It seems like forever ago that my friend Dave finally convinced me to start typing into WordPress instead of just Skype. It’s been quite a ride since then!

On a more serious note: Thank you. I know I don’t say it enough.

Thanks for reading, thanks for commenting, and thanks for linking. I really mean it. Every single one of those acts makes me smile.

And here’s to the next hundred! Already 9% of the way there!