Manipulating scope with the Javascript "with" statement

The with statement in Javascript allows you to tack the scope from an expression into the current execution context. It's really similar to the VB With statement. Here's a simple example:

function showDivStyle(){
  
   with($('my_div')) {
     console.log(style.backgroundColor);
   }
}
showDivStyle(); //logs the string "yellow" at this point.

It gets even more interesting when you combine it with a closure, as the scope is extended even more.

function showDivStyle(){
   var myClosure;
  
   with($('my_div')) {
     myClosure = function() {
       console.log(style.backgroundColor);
     }
   }
  
   return myClosure;
}

theClosure = showDivStyle();
theClosure(); //logs the string "yellow" at this point.

Growl4Rails - Rails == Growl4???

I've had a few people ask how to setup Growl4Rails without using rails. It's pretty easy as is, although you may be a little miffed by the directory structure. Feel free to go in and munge with the source if you'd like it to be more flexible, or to update it to suit your needs. All of the path dependencies are in the CSS files.

First, grab the source from GitHub:

git clone --depth 1 git://github.com/jfiorato/growl4rails.git

After that, create and images/growl4rails, javascripts/growl4rails, and stylesheets/growl4rails directories under your public folder.

From the Growl4Rails source, copy the contents of the public/javascripts, public/images, and public/stylesheet directories to your newly created folders, respectively.

Then, make sure to copy prototype.js and effects.js to your javascripts directory.

Once all the resources are there, all you need to do is add the includes to your layout/masterpage/template:

<script src="javascripts/prototype.js" type="text/javascript"></script>
<script src="javascripts/effects.js" type="text/javascript"></script>

<script type="text/javascript" langauge="javascript">
  var growl4rails_duration = 5000;
  var growl4rails_max_showing = 5;
</script>

<script src="javascripts/growl4rails/growl4rails.js" type="text/javascript"></script>
<link href="stylesheets/growl4rails/growl4rails.css" media="screen" rel="stylesheet" type="text/css">

Foolish writers and readers are created for each other

Probably like a lot of people, the hoo-ha between Atwood/Spolsky and Robert Martin on the importance of code quality and unit tests has had me thinking a lot lately. But it's not the suggestion code quality is of little value, or that writing unit tests are thriftless that was the subject of my reflections.

What's got me thinking about it all, is how both sides of the argument are extremely anecdotal. Atwood, Spolsky and Martin are all being very prescriptive about subjects that are extremely idiosyncratic, and these guys professionally represent two extreme ends of the programming spectrum; big company consulting and small team software R&D. I'd even go so far as to say they are different professions.

Anyway, I've come to the conclusion that I need to be more careful when being so prescriptive in my writing, and I need to do a much better job at qualifying my opinions on not-so-cut-and-dry matters.

"Foolish writers and readers are created for each other."
- Horace Walpole

Working Remotely Successfully

Before I started here at Nextpoint, I had some doubts that working remotely would work out all that well. Yes, not having to put pants on in the morning and being able to make a trip to the pantry every half hour for more Thin Mints certainly has it's appeal, but I was worried about being "That guy in Chicago".

However, 4 months in, and I've been extremely happy with the way it's all panned out. I think there's some key arrangements and tools that we've had in place that have made it successful. Keep in mind that our team is small, 4 people (not including me), so your mileage may vary.

Regularly make trips to see the team in person

This is the most important thing, as it allows me to personally connect with the team. We get a meal or two in, get the water cooler talk in, and we can get the personal connections together. I'll usually take some time as well to give the team a tour of what I've been working on.

I've found that if I don't make these trips regularly, I'll start to feel disconnected, and actually start becoming a little distressed. Being up there lets me tap into the vibe, and gets me pumped about what I'm doing. I'm fortunate enough to be able to do it every other week, since the office is in driving distance and I can keep the trips to a single day. But, I think that if the distance were greater, once a month or once every two months would be a good interval as well.

Group chat is a must

Group chat is a key tool that has made working remotely successful. Justin found a fantastic group chat feature of AIM that allows you to create a group then invite other AIM screen names to be members of this group. Each AIM screen name adds the group as a buddy. Then all instant messages are blasted out to each of the members. This eliminates the need to organize everyone into the chat, and just lets you chat and whoever is online gets the messages.

We had also tried out Yammer, but we weren't all keen on more apps/configurations/browser tabs in order to use the tool. We already use Adium, so just adding another account was simple.

Daily IN/OUT status

Being remote, it's hard to know what everyone is working on. It's also equally difficult to let everyone know that you're making progress. I wanted to let everyone know that I wasn't just sitting at home and watching Days of Our Lives.

Providing "what I'm going to work on today" when we get in, and a "here's what I did today" is a great way to keep up with what everyone is working on. We've been using Basecamp for tasks and Wiki, and with it, you get a group chat tool Campfire. This is different than the AIM tool, because there's a history kept, and you don't have to be online to catch up. This way, I can see what everyone else is working on, and what they've done. If we didn't have Campfire, a tool like Yammer could work well.

Video conferencing isn't necessary

When I first started, I thought for sure that we'd need a video/audio conference solution as well as a virtual white board. At first I tried to make a point of it to call with Skype, but that was difficult to do as a group (plus video of of me with my cat humping the bed in the background was a little difficult for the rest of the team to watch). So then I bought a Skype speaker phone, which ended up being a waste of money. Then Justin (we call him MacGreerver) crafted a speaker phone out of an old set of iPod headphones, which worked 100x better than the $160 speakerphone I purchased.

We haven't used any of these things in a couple of months now. The AIM group chat has completely made this unnecessary. Any time we need to talk one on one, we chat. When we need to talk as a group, we group chat. When we need to leave status, we use Campfire.

These tools and ideas have really made working remotely successful. If we adopt any new tools or ideas, I'll make sure to update this post.

So, as I sit here, with no pants on and minty-chocolate breath, I'm extremely happy that I gave it a try.