Productivity Tools For Web Development (A Monday Series: Part 2)

[Note: busy day yesterday! Apologies that this part of my Monday series is being posted on Tuesday. Can anyone say, "post scheduling"? Amen!]

Monday #2: A good* replication process – Oh, man. This is one of my favorites.

When I first started developing for the web, I hated deploying new versions of our web applications. Why? Well, because when I first started, I deployed using the following process:

1. Copy the newly compiled executable to the clipboard
2. Open Windows Explorer and navigate to the first web server’s production app directory
3. Rename the current production version
4. Paste the executable from my clipboard into the production app directory
5. Repeat for each web server (less than 10, but not by much)
6. Weep softly, wondering why I’m still doing something so glaringly inefficient

Best case, doing all that usually took around 2-3 minutes if the network was responding quickly. And pray that there wasn’t a bug that somehow escaped testing, because if there is, the whole process has to be reversed for each server.

Finally, I decided that this was no good. Remember our dear, old friend, the batch file? With a couple of easy steps, a batch file can make all of our wildest dreams come true (assuming that our wildest dreams entail file replication. Be still, my beating heart!)

You’ll need:

1. A directory into which you can put files you want to replicate – I use C:\replication, but you can create it anywhere you want and call it anything you like
2. A batch (.BAT) file – There’s a few ways to do this. I have 2 that I use.

   replicate.bat: This allows me to specify a directory as a command line argument. Assuming that your web servers are all configured identically, this will copy the files in your replication directory to the same location on each web server.

   set directory=%1

   for %%f in (1,2,3) do copy /-Y C:\replication \\yourWebServer%%f\d\%directory%

   Example usage from the command prompt: replicate myDirectory\yourShoppingCartApp

   replicate_app.bat: This one copies to the same directory every time, which is what I want when I’m deploying apps.

   for %%f in (1,2,3) do copy /-Y C:\replication \\yourWebServer%%f\productionApps

   Example usage from the command prompt: replicate_app

Once those are set up, just compile or copy your executable to your replication directory. Open a command prompt and run your batch file of choice to deploy your file(s) to all servers in one shot. Total elapsed time: 10 seconds or less.

To save a backup of the current production app, I rename it and put it in the replication directory right next to the new version I want to deploy. Then when I run the replication, the backup is copied to each server along with the new version. You know – just in case. . .

I know there are various utilities that’ll achieve similar effects, but I don’t know of a good free one. And then of course there’s Windows File Replication Service, but that’s sort of low on my list at the moment.

Got a better way to do it? Let me know in a comment.

*”Good” in relative terms.

Productivity Tools For Web Development (A Monday Series: Part 1)

I decided that I need something to fill in gaps between posting longer articles, so it’s time for a series. I’ll post a new part each Monday until I run out of ideas, start a different series, or die. LIFO rules apply here. So let’s get this show on the road…

About 3 months ago, I started on a journey. The destination? Better productivity and organization. Along the way, I’ve read thousands of productivity articles, a few books, and tried hundreds of different apps, shortcuts, and systems.

What follow are the tools I’ve adopted to make web development more productive. However, many of these are applicable to any flavor of development and some will apply to any sort of computer work at all.

Monday #1: Firefox bookmarks – Not just any ol’ bookmark, each Firefox bookmark is customizable with a keyword that lets you enter it into the location bar instead of the URL. So, for example, if I want a shortcut to my shopping cart page named ’sc’, I first create the bookmark the way I would any other bookmark. Then, I right-click on the bookmark in either the toolbar or the Bookmarks menu and click on Properties. I enter a keyword (’sc’ for example) in the Keyword field and click ‘Ok’. Now I can type ’sc’ + Enter to navigate right to the shopping cart page.

On our website, we use different URLs for testing than we do for production, so from the example above, I might set up a bookmark for the shopping cart test URL and give it a keyword of ‘tsc’. I’ve set up bookmarks for all the URLs I frequently hit for testing and it’s saved me a bunch of mousing around.

Got a better way to do it? Let me know in a comment.

And stay tuned for a long post this week! I’ve got a post or two marinating that I think you’ll find tasty.

What? Mouseless browsing in Firefox without an add-on?!?

Please shoot me. As long as I have been using Firefox, I only today tripped across this Lifehacker post from November of 2005: Hack Attack: Mouse-less Firefox Whoa.

One of my most bemoaned activities in life was browsing the internet because I always thought it had to be so damned inefficient. Yeah, I could get to the address bar (CTRL + L), use a keyword for any bookmarks (right-click a bookmark, enter a keyword into the Keyword field, type the keyword into the location bar + Enter), or launch a Google search in a new tab from the toolbar (modify about:config together with CTRL + K), but I still had to use the mouse to click links. Yuck!

I normally don’t do short posts, but I’m banking on the fact that some of you may not have seen it either. Very cool stuff!

The problem with “The Problem with Tabbed Interfaces”

UPDATE: I posted this before reading the comments on the post I referenced, so if you read those, don’t read this

Jeff Atwood of Coding Horror published a post today entitled The Problem with Tabbed Interfaces. He explains that he has difficulty finding the site he already has open because it’s obscured by the tab mechanism, which results in him opening multiple instances of Gmail, for example.

The depressing thing is that it’s usually faster to mindlessly launch a new browser than it is to go through this tedious routine of playing Where’s Waldo with (n) browsers and (n) tabs

Well, yeah. I remember having that issue, too, before I realized that I didn’t need (n) browsers open. That’s sort of the point of having a tabbed interface, isn’t it? All I could think while reading the post was, “Close all your browsers but one! Problem solved”.

Anytime I need to find a site that I know I already have opened, I find the single instance of Firefox in my task switcher, hit CTRL+TAB a couple of times, and smile. Maybe Jeff works drastically different than I do, but I’m missing the part where using a single browser is an issue.

Trust me: don’t fire that bad developer just yet (part 2)

So you didn’t take my advice (part 1). You went ahead and fired the guy anyway, didn’t you?

Now you’ve done it. This is terrible. Your IT department is going to disintegrate and your company will go the way of BetaMax, 5″ floppies, CRT monitors, and the buttermilk pancake helmet (delicious but ineffective, as any historian familiar with medieval times will attest)! Run for your lives!!

Ok, ok. It isn’t that bad. BUT here are some things you might’ve done when you fired that dude.

1. You’ve created a slippery slope – Once you let someone go because they required a tad too much effort and supervision, it becomes a little easier to let the next person go, and next thing you know, you’ve not only fallen down the slope, you’ve landed on your groin and lost a shoe on the way. You may start to see patterns in another developer that remind you of the bad developer you fired.

   Don’t misunderstand: people absolutely do behave in patterns, BUT the evaluation of those patterns should be confined to each person; they’re not necessarily transferable from one individual to another. So, for example, if you notice that Bill has difficulty understanding your shopping cart module just like that guy you fired, don’t assume that there will be other similarities. Maybe that particular module is just tough, but Bill will do a killer job once he gets the hang of it.

2. You’ve created an atmosphere that doesn’t allow failure – Without meaning to, you made a martyr of that guy you fired. He’s now the example your team will relate to when they’re feeling overwhelmed or confused. Even the developers that agreed with the decision at the time will come to resent it to some degree and wonder if it might’ve been possible to give the guy just a little longer.

   If you want to see developers that are paralyzed to do any real risky work , start firing their co-workers for not “getting it” or for making mistakes on a project. And by “risky work”, I mean working on any system that is truly key to your business – think order taking or shipping, for example. It’s risky because it’s the type of system that has to work. You may know these systems as “the ones that actually make us money“. These types of projects are already stressful enough without your developers thinking that they could be canned if they make a slip.

3. You’ve created a hole in your consistency bubble – Cycling quickly through developers (remember: our hypothetical programmer has only been working at your company for 1 or 2 months), causes a high level of uncertainty for the rest of your team, and it’s only worse if they actually like the guy you fired. Serious personality types won’t like him on principle because he’s a weight to the rest of the team; carefree types won’t mind so much. Regardless, though, everyone needs time to adjust to team dynamics. Change them too often and you’ll sacrifice more than just productivity and deadlines.

Your mileage will vary, but you should certainly examine your situation to ensure that any of the above issues are identified and dealt with to the best of your ability. Unless you don’t care, that is.

In that case, fire away!