Note: I wrote this post on a personal blog a few years ago, but I think it still pertains to developers using Coda or any all-in-one application.

…Panic software (the makers of Transmit FTP) have released a new “all in one” web site management application called Coda. The basic goal of this app is to take a bunch of things needed to build websites and place them all together in one application. Now, pardon my skepticism and negativity, but the best part about using an operating system, particularly one like Mac OS X, is that I can easily use multiple simple or complex applications in a quick fashion to complete projects. And to put it in short, I just don’t get the point of putting everything together in one app, even if it is developed by some of the best software makers around.

In fact, the whole idea seems to go against all the benefits of running OS X, much less running multiple applications targeted to exactly what I need. Granted, some apps get a little intense and do more than I may need. For example, I can’t say I use scripting in many apps that support it, but that’s because I don’t have to. An application like TextMate gives me the opportunity to pick and choose exactly what I want from a text editor. It isn’t trying to do too much, particularly because if it did it would interrupt the way I work. The things I don’t use don’t get in my way, and the things I do use are easy to get to. Sure, there are applications out there .. iTunes .. hut…hum.. that do handle tons of tasks all under one umbrella. But guess what, advanced music creators probably don’t use iTunes to do the majority of their composing, editing, and refining. Even though it may have the capability to do some of these tasks. This is why Apple created iWeb for novice web builders, because it allows them to do what they need without getting drug into the depths of web development. The problem is, Coda is iWeb for pros, which is a paradox in and of itself.

Here’s the gist of what I am getting at — the ideal application should be great at handling everything you need to do and shouldn’t get in the way if you don’t use every feature it offers.

Coda, to me, doesn’t seem to follow this line of logic. Rather, it forces the developer to use everything it provides and it doesn’t give much leeway in one direction or the other. For instance, Coda comes with Transmit FTP built in. Which sounds great until you want to connect to a client’s site to update one tiny PDF file. Suddenly you find yourself launching the entire client web project just to make one tiny update, an update that won’t even require 80% of the tools that Coda brings up. It’s like using photoshop to casually view pictures, no one wants to do it! Having an application that does too much is like having a beautiful piece of jewelry that weighs too much to wear. It may look great but dealing with it first hand just seems like a waste of time and comfort.

Recently here at Imulus we had a production server go down, meaning all of our clients’ websites on that box were unreachable.  Thankfully, we had the proper precautions taken and backups were restored in hours.  Yet it was a very stressful time for all of us and it led me to wonder what else was out there and how much better we could have responded in an emergency.

After a bit of research I found Microsoft’s Web Deployment Tool, also sometimes referred to as MSDeploy.  Of course it only applies to Windows Servers with IIS, so if you are looking for another OS/web server solution this article is not for you.

I was somewhat skeptical at first because, well, I’m skeptical of everything.  They even call me the skeptic here at work.  It also seemed a lot of people that were writing about it were fanboys and it was a very new product (I started testing when this product was still a release candidate).  After reading about it thought I should give it a shot since it sounded very powerful.  Here is a short version of what we were looking for:

• Able to take all manual steps out of recovery
• Backup all files and code that made up the website
• Include all settings, SSL Certificates, Bindings etc.

After playing with it and doing some tests I was very impressed.  The tool does deployment/backups per site, so if you host multiple sites on a server and want to customize depending on site you are able to do that.  You can view code dependencies, backup databases – do almost anything you want.  You can choose to use the GUI from IIS Manager or go command line.  You can choose to export the package to another server immediately or create a folder with an archive of all necessary files for restoration later.

If you are interested in using it for deploying, go get it,  check out this overview page or visit their forums.

If you are interested in seeing how we created a fully automated solution, read on.

Since we wanted something that had little or no human interaction, and therefore not error prone with a high degree of reliability, I came up with a solution that took all human involvement out of the backup and recovery process.  The solution we came up with is broken into 3 parts.

1) Backups of all sites in IIS needs to occur in case of a server failure.

2) Replicate backups to other available live servers as well as offsite automatically.

3) The ability to recover our site(s) needs to be easily and quickly available with fewest manual steps as possible.

To address all these I wrote a small, simple program to help the Web Deployment Tool with this process.  The program has two purposes and can easily be scheduled through the task manager in order to create a repetitive and up-to-date solution.  The program writes two files.  The first .bat file should be run nightly, or however often you want, and contains commands for msdeploy that create an archive backup for each site in IIS.  The second bat file contains all commands for msdeploy to install/restore each website that has been archived.  This second file should only be run if a server goes down and you need to restore sites on your standby server.

To take care of our first step we must schedule an execution of our custom application to generate our archival and restore bat files.  We must also schedule an execution of the archival .bat file our program generates to be run afterwards.  The bat file execution results in the creation of an archive for each site.

Now that all sites are backed up with step #1, we need to take care of step #2.  To do this, just use your favorite sync tool to copy all necessary files to other server(s) and offsite.  If you don’t know what I am talking about, check out Super Flexible File Synchronizer or Microsoft’s Sync Toy.  Using a program to move files on an automatic basis allows us to be ready to execute step three if we ever need to.

Step #3 is the only manual step in this whole process and is quite easy.  First, bind the new server you are recovering to with all necessary IPs, or do whatever network voodoo you need to.  Secondly, run the recovery .bat file.  The file will install your site(s), application pool, certs and restore all settings.  One click recovery?  Yes please!

If you think this code could be used in your environment you may grab a generic version here – I hope it helps.  Obviously, I make no warranty about any of this process or code.  If you do use the code, please read the readme as well as the code comments.  The code is a Visual Studio 2008 C# solution licensed under GPL.  Use your heads and do your testing people!

If you come up with anything different feel free to comment and let us know how you have improved upon the process.  If you modify the code please send me what you have done.  Enjoy!

I just recently got back into the magic of Pandora, an awesome way to find new music and share music mixes with friends.

However, after a few hours of use I remembered what kept from making it my main jukebox player in the beginning. The answer is simple, it’s hard to use while working in other applications. For someone like me who spends hours at a time locked in a text editor, switching to my browser and tracking down a play/pause button 20+ times a day can be frustrating. My first idea was to move Pandora to a standalone browser instance using Fluid. However, after a quick search and a bit of help from a co-worker I found an even better solution — PandoraBoy. It’s a small free Google code application that works similar to a standalone browser instance but also adds global hotkey controls.

You can set global shortcuts for actions such as: play/pause, next song, next station, previous station, vote up, vote down, player volume, and mute.

Once mapped you can use Pandora as your primary media player without ever having to view it in browser. Props to the makers of this app, it’s exactly what I was looking for. If you’re keen to try it you can download it now.

If you find, like me, that you can’t stand the dock icon you can use the quick one I whipped up. Download my PandoraBoy alternative icon.

We’re happy to formally announce the launch of Support Details, our first planned public product. This is one of those ideas which was in the works here at Imulus far longer then need be. In fact the idea was discussed in ’03 and sadly it fell off the radar until this year. Support Details is an attempt to add clarification to browser related issues between non-technical web visitors and their clients & customers.

This idea started as way to save time. To solve odd browser issues our team was always asking the clients questions like:

“What browser are you using?”, “Which version of Flash is installed?”,”Do you have cookies enabled?” “What is your screen size?”

You get the point.

We simply were losing too much time to explaining the “how to” aspect; hence Support Details.

To be useful the product had to determine what browser a customer was using, along with any other configuration data which could be detected. Then, it needed a reliable way for capturing and sending the data over to the person who was working on the problem.

The concept is simple. That is part of the reason we believe it works so well. Yet, we’re always open to good suggestions for improvement and we’re eager to hear your feedback.

It’s called charging people a monthly fee.

Why are so many web-services scared to charge their user base? Especially when the service kicks ass like Facebook or Twitter. TechCrunch is saying that 1 in 5 people on the web have accessed Facebook. I’m sort of thinking that there is something of value there for that many people have an interest. Why then are these companies still looking for a way to make money when the answer is in their face?

Charge us!

Facebook is struggling with ad supported revenue and Twitter is anyone’s guess. Their customers are asking to be charged and would gladly pony-up some cash if it meant a better service.

Facebook and Twitter set bad examples for start-ups by not charging. It creates the impression that all web-services must be ad-supported. This simply isn’t a good approach to building a long term sustainable service. Locally, I try to attend the monthly Boulder / Denver New Tech Meetup, and I’m continually heartbroken by all the startup founders looking for ways to capture VC funding when they already have a fairly nice service to offer. It’s as if everyone is trying to cash in on building the ‘next big thing’ by growing fast and selling to Google.

I fully understand giving a service away in the beginning in order to draw in the users, but have a clear plan to stop the free services and convert to a paid model. The “try before you buy” model isn’t used enough. Facebook could charge for users who’ve been on their services for over 1 year. Twitter could easily charge by volume of Tweets.

I can already see the comments coming in about how charging will diminish the social / community value of these services. Yet, I would be MORE likely to use these services if I was confident they would be here in the future and not sold off to Google, Yahoo or Microsoft.