While my focus has been on Amazon's EC2 and related grid computing type of approaches (ServePath, etc...) I've noted several versions of pre-configured application image stacks lately and have tried a few of them.  I believe this approach has merit and may help to speed the adoption of open-source projects.  At the very least I expect this approach will broaden the appeal of open-source projects as it removes much of the burden of installing and configuring the 'environment' required to run these projects. 

The idea is that a potential user will be more likely to examine a project closely if the amount of effort required to get the project setup is minimal.  I know this to be true for most folks I've worked with. 

JumpBox takes a virtual machine approach to these images.  One simply has to download the virtual machine and run it with an existing virtual platform - most are supported - and that's it.  The machines are ready to go and just work.  JumpBox also claims to have an automated data backup system in place for each image - I didn't look into this feature although it is compelling.

BitNami takes a local application approach with all the required elements included in the downloaded package.  The obvious upside is that the downloaded file is smaller than with JumpBox.  This approach is simple and proven - I personally installed the downloaded packages to a Virtual Machine anyhow so it added a step to my process.  If you were to install it into a physical machine - or download directly to a virtual machine - the process may be more streamlined.  BitNami makes the UI very simple and one need not be any sort of geek to run with this.

Amazon EC2  is a bit of a different approach than the above.  It should be noted that Amazon's EC2 service did not set out to fulfill the same niche as the above services but that I include it here because I think it can be used in this manner.  This service is really utility computing made available easily, however Amazon has a defined machine image format (called AMI) that can be created by any user and offered publicly.  The idea in using the Amazon AMI image is that anyone who has an Amazon Web Services Account can start an instance of a public AMI image and evaluate or use the assets it contains immediately.  There is no requirement for a local machine (physical or virtual) so that one can evaluate projects from the comfort of an armchair in a coffeehouse / bar.  That may be why I like this approach best.

What about .Net based open-source? 

I have made a large personal bet on the future of open-source projects based on the Microsoft platform (.Net in particular) and so I'm keen on how these might fit into these approaches.  I have a effort in progress to create an Umbraco AMI for Amazon with Windows Server running on Linux with QEMU as the virtualization platform.  I hope this is something that will be widely used for evaluations of Umbraco and as a model for additional usage of this platform to promote easy adoption of the 'other' open-source without requiring investments in infrastructure.  There is much more to be written on this topic so please check back.

-Paul

Rob Conery has just made a nice post discussing (in his opinion) the merits of each of these ORM projects. 

I work with SubSonic frequently and so it is familiar to me - and I prefer it.  dashCommerce uses SubSonic as it's data provider.  Umbraco v4.* will, I hope, use SubSonic but, at the minimum, is planned to use LinqToSql.

ASP.NET MVC: Choosing Your Data Access Method

-Paul

I've completed the dashCommerce Payment Provider using the CyberSource Simple Order API SOAP interface.  At this point I've had it in the test environment at Homax for a few days and it appears to work as expected but I'd appreciate some testing by other community folks.  Over the next few days I'll create the usage guide and dependencies list and put them up here

http://www.motusconnect.com/dashcommerce/providers.aspx 

If you're using CyberSource, or considering using it, please give this provider a try and send me your feedback.

-Paul

I seem to remember seeing some of these tips in other posts from active Umbraco community members, but being fresh off the Level 2 course I thought I'd put down this quick list of the items I've set in my Umbraco Visual Studio 2008 development environment.

First, an important note:  I like to do my development in a Virtual PC instance of Windows Server 2003 with VS 2008 installed and using IIS as the web server.  After many years of spending the occasional frustrating day tracking down that one thing that changed and hosed my development environment I've decided the nominal additional effort required to run in this manner is worth is.  Additionally, being able to have a 'portable' development machine (albeit virtual) has served me well in moving between machines, employers, and clients.  Lastly, it's very useful to save your 'baseline' virtual hard disk image in case of catastrophic machine failure, new team members, etc....

Okay, enough of that topic.  Now for the tips:

1. Install Umbraco in a different directory - using the installer - than you use for your Visual Studio solution - using Umbraco source code.
   1. I use c:\websites\umbraco\ for my Umbraco runtime directory
   2. and c:\work\umbraco\ for my Umbraco development directory
2. Create a post build event (from Project > Properties > Build Events) to copy *.aspx and *.dll (and *.pdb) to your runtime folder - this assumes you're working with user controls, could be similar for other extensions.
   1. XCOPY "$(ProjectDir)\bin\Umbraco*.*" "c:\websites\umbraco\bin\" /y
   2. XCOPY "$(ProjectDir)\usercontrols\*.ascx" "c:\websites\umbraco\usercontrols\" /y
3. To debug:
1. Open the Umbraco IIS site in your target browser(s) - making a shortcut to the section you're working with helps
2. In Visual Studio select the Debug > Attach to Process menu
3. Select w3wp.exe from the list and press OK
   1. NB:  for IIS on XP/2000 select asp_net.exe and press OK
      
4. From Visual Studio you can set breakpoints, step through code, examine runtime values, etc...
5. NB:  make sure you copy the *.pdb file to the runtime directory, otherwise you may find your breakpoints are not hit

That's it.  A few minutes of work and you're on your way to Umbraco development happiness.  At least I am.  In my experience this work with all 'like' versions of Umbraco; I.e., I install 3.0.3 in the runtime directory and build 28441 in the development directory and I'm able to debug accordingly.

-Paul

I've always been a believer in the hosted approach to infrastructure but with our software firm, Mold Inspection Solutions, we decided to host our own servers. It's a long story but the gist is that it was prohibitively expensive to maintain a dedicated server at a host. The upside was that we had redundancy in terms of connectivity and power.

Last summer we built out our infrastructure as follows:

• -Server :: 3GHZ dual core, 4GB RAM, 170GB RAID-1 disks, dual NIC
• -Connection :: Comcast cable + Earthlink DSL balanced using a PepLink load balancing router
• -Power :: dedicated circuit, 30 minute backup battery, auto shutdown/startup
• -Backup :: dedicated backup server with 'offline copy' to a duplicate external drive and offsite backup at Amazon S3

Understanding the tradeoffs in terms of reliability we have been able to reduce our costs by over 80%. That was enough to convince us.

This morning, for the first time, the server was offline - this happened just as I boarded the bus for the airport. An hour or so later it became apparent that the server itself was not the issue - the Comcast router had failed and was unable to be reset. We expected the PepLink router to take over and redirect traffic using the Earthlink connection - that didn't work. The Comcast tech showed up about two hours after the original incident - bravo Comcast for this amazing response time.

Within 90 minutes the tech confirmed the router wasn't working - after initially reporting there were no problems since he was looking at the Earthlink DSL router - and was able to replace the router (SMC) and reset the configuration. (Though we did loose all our firewall rules, port forwarding, etc...). The total downtime was a bit less than 5-hours.

Assuming you've read this far, what can we do to reduce the chances of this reoccurring? Are we risking too much by running our own servers? Does anyone else have experience with successfully using the PepLink load balancing routers?

-Paul