The Garvin

Dylan Hale: A Great Realtor in NC.

2014-08-04T00:00:00+00:00

If you’re in a rush, and you just want to know whether I’d recommend Dylan Hale as a broker/agent for buying a home, the answer is: Yes. Absolutely, without hesitation, reservation, or any caveat whatsoever: Yes. Dylan is an intelligent, honest, hard-working human being that also happens to be a very good Realtor with a very good team behind him.

Here’s the longer version.

My wife and I were living in Northern VA, and we decided to relocate to the Research Triangle of NC. Our past experiences with buyer’s agents weren’t stellar, and I wanted to try buying our next home without one. This is just to tell you that, at the beginning of this story: I didn’t want a realtor, I thought I could do everything without a realtor (saving 3%!), and I was pretty sure I would be irritated by any realtor that we’d sign up with - all the while wondering “How is unlocking doors to houses worth 3% commission?”

My wife wasn’t necessarily on board with the idea. She humored me, though, and began the process of finding candidate homes using sites like Zillow. She’d see a house that fit our criteria and fill in the little contact form on the side-bar to schedule a walk-through on next trip down to the area. Most of the realtors would respond by the end of the day via email.

One of the listing agents called her within 3 minutes.

My wife was the one that answered the phone and spoke to Dylan initially. After the phone call ended, she reported a very nice conversation with a realtor that wasn’t pushy at all, and just wanted to let us know he was happy to help us out whenever we made a trip down. My wife and Dylan also talked about the issue of not having a buyer’s agent, and of COURSE he offered to represent us (it’s his job, after all!), but she knew I was pretty “enthusiastic” about not getting tied to a potentially lame realtor - so she just politely indicated that we’d discuss it and let him know.

Oh, and discuss it we did! “We haven’t done any research! - This is just some guy that happened to be the first one to call!” - and right there was the first chink in my defenses: this guy called within minutes. He’s clearly on top of his business. “Ok, credit where credit is due - but what else do we know about him? That could’ve been an anomaly!” So my wife, being the marriage-judo master that she is, agreed that I should vet him further.

So, I called Dylan and introduced myself, and I told him about my concerns and hesitations and he was very understanding, and when I asked for references from previous clients, he paused for about 1 second, and then said “Yea, sure, no problem. I’ll get a list to you today.” And he did.

I followed up with the people on his list and got emails and phone calls for responses. The responses that I got were not just “+1 would use again” - they were heartfelt expressions of gladness and relief that they had used Dylan as their realtor. With each reply, I was more surprised at the words being used to describe their experience with a realtor. They were certainly not words I would have ever thought attributable to one. Words like “Hardest Working”, “work-horse”, “integrity”, “reliability”, “never felt neglected”, “on the ball every step of the way”, etc, etc.

My wife and I discussed it more, and decided to take Dylan up on his offer to walk through houses. We told him about our schedule and that we’d be driving down on Sunday so that we’d have all of Monday, Tuesday and Wednesday to look at houses. He explained that he’d make himself available for us during that period so that we’d be able to see all of the houses and areas that we needed to see.

On Sunday, as we drove down to NC, my mobile phone rang. It was Dylan. He asked what time we’d be getting into town, and offered to begin showing us houses that afternoon. We hadn’t assumed he’d be available on Sunday - but he put it out there because he knew were had a lot to cover in a limited amount of time.

Whatever concerns I had about Dylan being dependable and reliable were quickly eroding.

Over the course of the next few days, we proceeded with a routine of waking up, getting coffee, meeting Dylan, seeing houses, eating lunch, seeing more houses, and finally getting dinner and going back to our hotel room to digest the day’s events. Every night, we’d receive emails from Dylan with more listings, and we’d whittle down the list of houses we kept in a spreadsheet.

By the end of the 3 days, we were exhausted - but we had found the right house for us, and we did submit an offer, and Dylan was included on the offer as our agent.

Whatever concerns I had about Dylan being hard-working or dedicated were gone.

Over the next few weeks we proceeded through negotiation, inspections, more negotiations, and all the other things that wrack the nerves during the home-buying process. Dylan and his amazing team were on-point for EVERYTHING.

They arranged inspection, and because I couldn’t be there, Dylan was present on my behalf. For all of the issues that we learned during inspection, Dylan reached out to his network of contacts to get answers, estimates, and expert opinions on various items.

We secured our loan with Davis Orebaugh at OnQ Financial. He and his team met the bar that Dylan had set for service, professionalism, and just being decent human beings. I can’t stress that part enough: these were all good people. Also, we got great loan terms - much better terms than we were able to get through other lenders. So, you know, there’s that.

When I finally traveled down to NC for the closing, the whole team was there. I met Chris Mann, the closing attorney. He whipped us through the signing process of a massive stack of papers, explaining everything along the way, answering any questions I might’ve had.

So, it’s all said and done. We moved in to our new home about two months ago and I’m writing this review on my blog, because the 150 characters Zillow affords wasn’t enough.

Whatever concerns I ever had about Dylan being the right choice for us, are gone.

We consider ourselves lucky to have met Dylan and worked with him, and his team.

The Disciplined Programmer

2012-01-28T00:00:00+00:00

When you run across a project that suffers from things like messy code, poor design, or lack of tests, there are two possibilities: The first is that the responsible party was so inexperienced that they had no idea they were making a mess. It honestly never occurred to them that they were doing a poor job. The second possibility is that the responsible party knew they were writing messy code, they knew they weren’t being thoughtful about the design, and despite knowing all about TDD, they still skipped writing tests. This second group is one that I think most developers fall into at some point.

If you’ve ever explained a messy code base, or terrible test coverage with this excuse:

We had no time, we had to get it done ASAP.

then this post is for you. We’ve all felt the pressure of “ASAP”. We’ve all read Rework, which convinced us that “ASAP” is poison. We know that when everything is ASAP, then NOTHING is. And we know that when we rush to get things done ASAP, we inevitably cut corners that hurt us in the long run: We skip writing tests. We commit messy code that we’re embarrassed by. We trade moments of quiet thinking about the problem for frenzied keyboard clacking, as if words-per-minute could ever make up for a deficit in thoughtful design. We do all this despite knowing it’s wrong.

So why do we do it?

I believe it’s one of those classic disconnects between what we intuitively feel versus what intellectually know. Intuitively, we feel like we’re getting things done faster when we blast through code and don’t take the time to TDD. Intellectually, we know that TDD reduces software defects and speeds up development (in the long run), and that thoughtful design yields cascading benefits that permeate entire systems.

Most programmers probably have the same harmful intuition when stressed. However, given the same stressful circumstances, some programmers will behave according to their intuition, and others will behave according to what they know intellectually. Why?

Discipline

It is the unsexiest of programmer attributes. I think of how many times I’ve heard people talk about the exciting elements of programming: solving hard problems, writing elegant “beautiful” code, being creative, automating away inefficiencies and taming the techno-beast. These things come up when trying to convince others that we are passionate about our craft in a job interview, or explaining why our job doesn’t suck to children at Career Day. But how often have you heard someone talk about methodicalness, or the virtue of embracing routine, or the necessity of regular and critical reflection? What about the discipline that is required by all of those things?

The most productive programmers I know comprise their daily routine from a series of repeatable work flows. They are methodical. Even creative tasks are performed in a methodical manner. Their routines become habit, and they can sense when the routine needs adjustment - like a wobbly wheel that’s out of alignment. In addition to being generally productive, they also tend to produce clean, thoughtful, tested code.

Discipline is not glamorous. I doubt we’ll see “disciplined programmer” supplant “ninja” or “rock star” in job postings any time soon. Nonetheless, I’ll be focusing on it more as a deliberate addition to my programmer psyche, and encouraging it more in others - especially those who shout to others from atop their heap of disastrous code “Sorry about this mess, I was in a rush!”

The M in DOM stands for Model

2011-09-07T00:00:00+00:00

This is a response to a post by my friend Ken Collins: “How Do You Encapsulate Your Javascript”.

I agree 100% with Ken that poorly organized code, code that litters on the global namespace, and code written such that it can’t be reused is a sign of amateurness. However, I disagree that jQuery plays a role in leading developers astray regarding good software design principles.

Part of Ken’s criticism is that jQuery doesn’t sheperd new developers “into learning some sort of way to encapsulate their object behavior.” Why should it? jQuery isn’t relevant to the problem space of modeling domain objects. Javascript, the language, provides those facilitates. You can model complicated behavior all day and night using nothing more than core Javascript. Even so, most developers find the core facilities of Javascript too foreign, or too basic for building their applications. Thankfully, plenty of great libraries/frameworks have been invented to address that need.

jQuery is a library for working with the DOM and normalizing all the annoying variations across browser specific APIs. The way I like to think of it is: Your web application always has at least one model: the Document. Like any other object, it has state (e.g. the node tree, document properties) and behavior (e.g. adding and removing nodes). jQuery provides the interface through which you work with that object. jQuery is not a library for helping you model other parts of your application.

With that in mind, I think writing a class that gives you another model on top of the DOM, just so you can ape classical OO in Javascript, is a smell. As an illustration, I’ll rewrite Ken’s example using the jQuery plugin approach.

  $.fn.flash = (content = null, htmlClass = "notice") ->

    flashElement = this.find("div.flash")
      .html(content)
      .removeClass("notice alert")
      .addClass(htmlClass)

    $.mobile.silentScroll(0) if content?
    flashElement.toggle(content?)

With the $.fn.flash plugin defined, we can use it to set the flash on any page:

  $(currentPage).flash("OMG it worked!!! <3 <3 <3") # sets and shows flash notice
  $(currentPage).flash("Broken. (._.)", "alert")    # sets and shows flash alert
  $(currentPage).flash()                            # clears and hides flash

I believe it has feature parity with Ken’s example and is just as reusable, but has the advantage of being idiomatic jQuery that’s simpler and has fewer dependencies.

To explain the phenomenon that so much Javascript is written so poorly by so many, I hold the (relatively uncontroversial) theory that: most developers write Javascript without actually learning it. Heck, I myself didn’t actually read my first Javascript book until after I had already spent a few years barely grokking the occasional Javascript snippet and making things barely work by sheer coincidence.

On the flip side: I’ve seen well functioning, non-trivial, and well tested Javascript applications where the primary unit of reuse was the jQuery plugin, and encapsulation was had via closures.

The classical OO approach is not the only game in town for good software design. Don’t forget that the DOM is already a model that has its own state and behavior, and jQuery plugins are your best bet for creating reusable code with naturally occurring encapsulation via scoped variables and closures.

Why doesn't your business use MongoDB?

2011-02-25T00:00:00+00:00

Nathen Harvey invited me to speak at the Washington DC MongoDB Users Group this month, and the purpose of the talk was to raise the question: “Why doesn’t your business use MongoDB?”

A few people asked me to post slides from the talk, but they would’ve been difficult to derive meaning from without the accompanying talk and discussion, so I added sticky notes to the slides to help with narration. I also added a post-meetup notes slide with a few links.

Download

MongoDB 1.8rc0!

As fortune would have it, 10gen pushed out the release candidate for MongoDB 1.8 on the same day as the meetup, so we all got to hug and cry (happy tears) as a group. The big news here is that MongoDB can now employ write-ahead journaling.

That’s great news for the single-server durability hold-outs, as they may now comfortably proceed with their full embrace of MongoDB.

Tips For Learning Vim

2010-08-04T00:00:00+00:00

Yehuda recently wrote about his trials in trying to switch to Vim, the failed approaches, and what finally did work for him. I thought this was great, because different people learn in different ways, and the unique approach someone else comes up with might work well for you too. In that spirit, I wanted to share a few methods I used while learning Vim that worked well for me.

Separated into their own posts for digestibility, and in no particular order…

Don’t forget the built in help!

Vim has a ridiculously useful help system built in. This may seem obvious, but I always forget this fact and rush off to google to figure something out, and the search will regularly lead me back to the Vim docs.

  :help

Vim links

Here’s a few resources that helped me along:

I highly recommend the O’Reilly book. It’s big, but it’s a worthwhile investment if you’re going to make Vim your One True Editor.

Switching From Arrows To hjkl

2010-08-04T00:00:00+00:00

(Part of the Tips For Learning Vim series.)

Moving your hand off the home row to use the arrow keys is a sin in Vim, but getting used to the hjkl keys for movement was a HUGE pain for me. In fact, I used vim for years without kicking the arrow key habit. I finally kicked the habit with the help of some focused finger training.

The goal of this exercise is to build new neural pathways so that your brain no longer has to go through the cognitive effort of translating your desire to have the cursor move down by one line into pressing the letter j on the keyboard. You want your brain to optimize for the relationship between your will and your fine motor movements. In fewer words: you want to build muscle memory.

You might notice that the exercise focuses on training the opposite pairs (up & down, then left & right) instead of all of the directions at once. This reinforces the behavior where you group you vertical and horizontal movements rather than trying to interleave the two (creating diagonal cursor movements, which will be slower and probably not what you want to do in Vim anyways).

Open a file with some text in it and put the cursor somewhere in the middle.
Rest your right hand on the home row (index finger on j, middle finger on k)
Now just rapidly alternate between pressing the j and k keys.

As you press the keys, the cursor will move up and down. Just stare at it while you press the keys. Let your brain soak it in. Try to forget the keys you’re pressing, and just feel the shape of your hands on the keys, the way your fingers feel while you make the cursor go up and down. Sounds goofy, but it should help build muscle memory.

Then repeat the exercise with your index finger on h and your ring finger on l. The cursor moves left and right. Just get your fingers going then stare at the cursor movement while it wiggles back and forth. Let your brain soak it in.

Then start doing a several key presses on each side: jjjjkkkkjjjjkkkk, hhhhllllhhhhllll and do that over and over.

The last ingredient is to avoid using the arrow keys while you are coding. For me, just the act of moving my right hand away from the home row annoyed me enough to remind me that I should instead use hjkl keys.

An approach that didn’t work so well for me

I also tried using mnemonics: hjkl + “left, down, up, right” = “heft, jown, kup, light”.

So if I needed to move the cursor down by 3 lines, I’d decipher in my head that “down” became “jown”, which started with a j, so I need to press j three times. This was slow, and it sucked, and my friends had endless hours of amusement watching me use my mental decoder ring just to move around my editor.

Fringe Benefits of using `hjkl`

After you get used to hjkl movement, you can enjoy their use in other applications.

Gmail - Enable shortcut keys, then use jk to move the selection arrow up and down your inbox.
Any browser with a Vim-like plugin - use hjkl to scroll around

In Chrome I use the Vimium extension which has a few great features.

There are extensions for Safari and Firefox as well.

Remap Caps Lock to Control

2010-08-04T00:00:00+00:00

(Part of the Tips For Learning Vim series.)

This is a popular thing to do for people that use editors that rely on the control key for various functions. The Caps Lock key is big, it’s in an easy to access and complementary location to other modifier keys, and you weren’t using it for anything anyways. It’s not Vim specific, but I definitely think it makes using Vim more comfortable. It’s easy to configure on Mac OS X. Just open System Preferences and search for “reset modifier keys”.

You can see in the screen shot that I disabled the original control key to speed up the retraining of my brain.

Don't Start From Scratch

2010-08-04T00:00:00+00:00

(Part of the Tips For Learning Vim series.)

Some people might like the idea of starting with a blank slate for their Vim config, and then adding as they go, and I see the appeal in that, I get that, and (to quote Gary Vaynerchuck) I respect that.

I’m not a patient person though. I want full Vim fabulousness, and I want it now.

A bunch of veteran Vim users have already spent lots of their time cultivating Vim configs that make Vim behave in useful and magical ways. I used one of those configurations as a starting point and tailored it from there. This made a lot of sense for me and helped make me more productive sooner.

The few people I’ve helped switch to Vim have started by forking my dotfiles repository just to leverage the vim config that’s in there. We shared a Textmate background, and we were all doing ruby development, so it made a lot of sense. Since we started off with forks, it was easy to use github to share additions and tweaks we made over time. We’d send each other messages like “Hey, I just added a plugin that does snippets just like textmate - do a pull!” and everyone would benefit for it. Good times.

"Git is just too hard"

2009-12-14T00:00:00+00:00

Here’s the sentiment that’s been delivered to me on several occasions by different people:

“Git is too hard, and Subversion is good enough.”

It saddens me when I hear this. Why does it sadden me? Because some very smart developers are missing out on a great tool that can improve how they work, and enable cleaner project histories.

Basic Git usage is easy

I’d like to dispense with the “Git is too hard” complaint. As I write this, Github’s home page says that they have 155,000 coders using their service. Even if a significant portion of that number is virtual/duplicate accounts, or people signed up to Github despite loathing Git, you still have a huge mass of developers that apparently don’t think Git is too hard. That’s just counting Git users on Github. If they can figure Git out, you probably can too.

That’s my argumentum ad numerum: one hundred thousand developers can’t be wrong! But I don’t like it when people use logical fallacies on me, so I won’t use them on you.

How might we objectively prove that Git is, in fact, not “too hard” when compared to Subversion? Cold hard concrete example, I guess.

Go look at the Git-SVN Crash Course, where you’ll see examples of equivalent commands in Subversion and Git. In many cases, the commands are nearly identical. Consider the typical workflow:

Using Subversion:

  # get the code
  svn checkout http://whatever
  # ... make some changes, then commit them ...
  svn commit

Using Git:

  # get the code
  git clone git://whatever
  # ... make some changes, then commit them ...
  git commit -a
  # optionally share your commits
  git push

That’s the basic retrieve-edit-commit cycle that you do in either Subversion or Git 90% of the time. Your first hint that something is different is with the git push command. One of the key features of Git is that you can do things to commits before you share them. If that concept makes no sense to you, let it serve as a clue to you that you might be missing out on something powerful. Being able to make commits without sharing them with the world is foundational to many of Git’s more powerful features.

Those powerful features of Git are the ones that you don’t have to understand right away. The stash, the index, rebasing, forking and adding different remotes - these are all things that you don’t need to understand on your first day. You can do your basic Subversion-style work flow easily with Git, and learn the advanced stuff as you go; just like everything else you’ve ever learned.

Once you understand Git, Subversion is obsolete

Subversion is only “good enough” until you learn Git. It’s true. I can’t think of any situation where I’d choose to use Subversion over Git. Git can do everything Subversion can do (and better), but not vice versa. Working with Subversion feels utterly primitive after using Git, and I’m definitely not the only one that thinks so. In fact, git-svn was created so that Git users stuck on a project using Subversion wouldn’t have to live without the glorious features that Git provides.

Git is a better tool for the job, and a craftsman should use the best tools available.

Make the switch.

Resources

Here’s some resources that should be helpful for anyone learning and using Git:

http://gitready.com - a great cookbook style reference. Consult it early and often. This is my favorite Git resource.
The Git Community Book
Why Git is better than Subversion.
git_remote_branch ruby gem - it gives you a command line utility that takes care of managing remote branches.
git with github - a command line script which adds GitHub knowledge to a few git subcommands.

Clearer code with jQuery micro-plugins

2009-10-28T00:00:00+00:00

Most non-trivial javascript applications need to do some work after the document loads. jQuery makes it easy to hook into that event, and lots of people use it like this:

  $(document).ready(function(){
    // application code... ALL of it

    var term = searchParameter();
    if (term) $("#search_form input[type=text]").val(term).addClass("focus")

    // .. 200 lines later ...
    // ah, here's the code you need to tweak
  });

Maybe this is OK for really small apps, but when you’ve got a few hundred lines of javascript milling around in there, you’ll eventually start to feel the pain. You’ll try things like punctuating sections of code with comments, which we all know is bad, or breaking your $(document).ready() calls up into a several $(document).ready() calls, one after the other. Gross.

One way to get high-level comprehension of our code is to break the unrelated sections out into their own functions, and then call those functions from the setup block.

  $(document).ready(function(){
    initializeSearchForm();
    initializeRowPointer();
    initializeThumbnailSizeSlider();
    initializeQueueStatuses();
    // and so on...
  });

  function initializeSearchForm() {
    var term = searchParameter();
    if (term) $("#search_form input[type=text]").val(term).addClass("focus");
  };

  // and all the other functions...

Now our setup block gives us a bird’s eye view of what’s going on when the page loads, and we can easily jump to those function definitions to see what’s going on and make changes. That’s better, and it’s how I’ve been doing it for a while, but using a pattern that Ryan McGeary came up with, we can make this code reveal more about what it’s doing and make it easier to maintain by embracing some jQuery-ness.

Bring in the micro-plugins

  $(document).ready(function(){
    $("#search input[type=text]").searchForm();
    $("#orders").selectableRows();
    $("#slider").thumbnailSizeSlider("td.picture img");
    $("#queue_statuses .status").queueStatus();
    // and so on...
  });

  // micro-plugin
  $.fn.searchForm = function() {
    var term = searchParameter();
    if (term) this.val(term).addClass("focus");
    return this;
  };

  // and all the other micro-plugins...

By rewriting our functions as jQuery plugins, we enjoy several advantages over the former approach:

We moved the selector up into the setup block where we can easily see and change it. This gives us a better idea of what our code is doing, all from the comfort of our bird’s eye view.
It’s a jQuery plugin! Any other developer that’s familiar with jQuery, but new to your code, will immediately appreciate the assumptions he can make about your implementation.
It’s a jQuery plugin! It’s very easy to reuse, even if you don’t plan on it.

If you’ve never written a jQuery plugin before, this should really highlight how simple it is. There aren’t any framework hoops to jump through. You just slap a function on jQuery.fn and access the wrapped set via this. It’s the simplicity of jQuery’s plugin system that makes the micro-plugin possible.

What is this tomfoolery!? That’s just a plugin!

Yea, so let’s clear up the distinction between a plugin and a micro-plugin. The difference is the author’s intent when writing the code. Regular jQuery plugins are written with reuse and sharing as a primary goal. Micro-plugins are created solely because they make your application code clearer and easier to maintain, and without any intent to ever reuse or share the code.

If you find yourself reusing a micro-plugin across projects, and it becomes something generally useful, then you can document it, share it, and call it a real plugin.

The Garvin

Dylan Hale: A Great Realtor in NC.

Here’s the longer version.

The Disciplined Programmer

So why do we do it?

Discipline

The M in DOM stands for Model

Why doesn't your business use MongoDB?

MongoDB 1.8rc0!

Tips For Learning Vim

Don’t forget the built in help!

Vim links

Switching From Arrows To hjkl

An approach that didn’t work so well for me

Fringe Benefits of using hjkl

Remap Caps Lock to Control

Don't Start From Scratch

"Git is just too hard"

Basic Git usage is easy

Using Subversion:

Using Git:

Once you understand Git, Subversion is obsolete

Resources

Clearer code with jQuery micro-plugins

Bring in the micro-plugins

What is this tomfoolery!? That’s just a plugin!

Fringe Benefits of using `hjkl`