Currently, many developers use a centralized version control system such as Visual Studio Team System (VSTS) or Subversion. With such systems there is a central repository (i.e., Team Foundation Server (TFS)), usually located remotely, that houses the different versions of source code.

Unfortunately, a number of issues accompany typical source control systems that are based on a centralized repository, including, but not limited to the following:

• Many operations such as checking code in or out can perform poorly over slow connections.
• Working offline results in a reduced set of functionality, such as branching or committing multiple features or bug fixes.
• Moving the repository can be difficult due to the fact that there is front-end and back-end management.
• Working between networks that may never become bridged is impossible or difficult, since a connection must be made to the central repository.
• Private work is typically not under source control.
• There is often a single point of failure.
• Security must be managed, and may become complex due to multiple permission sets and projects.

Distributed source control systems (or distributed version control systems, "DVCS" for short) are starting to gain popularity because they offer many advantages over the traditional, centralized repository.

They allow users to work independently in either a connected or disconnected environment. There is a tremendous amount of flexibility in regards to merging, managing different branches of development, and managing product features.

Adopters of this technology include Google Code and Sourceforge. Moreover, many major projects such as GNOME, Perl, MySQL, Python, and Ubuntu are also using a distributed source control system.

You may have already heard about some of the popular implementations. Git, Mercurial, and Bazaar are a few choices that have started to become mainstream. If you’ve worked with Subversion, you’ll find that migrating to this new generation of source control systems doesn’t mean giving up the features that you’re used to.

There are many problems with centralized repositories that simply disappear when you’re working with a distributed system:

• Merging is a core feature and works how and when you want.
• Security is trivial since everyone works in their own sandbox. You simply choose who you allow pushing and pulling changes to and from. In open source projects, this typically means allowing certain trusted individuals to push changes to the project repositories. When needed, additional security models such as authentication can be imposed.
• Working disconnected doesn’t require any preparation. You are working offline by default. The only online operation is synchronizing with other repositories.
• All operations are near-instantaneous. Synchronizing is the only operation that is dependent on the speed of your connection.

What is a Distributed Source Control System?

Distributed source control systems have the same purpose, but work much differently than systems like Team Foundation Server (TFS), SourceSafe, Subversion, and CVS. Instead of having a single repository that contains the source code and history, there are many repositories that have the source code, and some or all of its revision history. One or more peers have repositories for a project, and synchronize what they want, when they want to. There are really no requirements or restrictions. The focus is on synchronizing and working independently.

Workflow

Examples & screenshots included here are from Mercurial using the TortoiseHg explorer extension. Git has similar functionality using TortoiseGit. You can also use the command line for all/some operations if you prefer.

1. Clone a repository – To create your own local repository, you have to clone (copy) all or part of an existing repository. Since each developer has a copy of the repository, you can clone it from anyone.

2. Create a "working copy" of the code – Even though you have the full repository from another developer, you still need to "check-out" or get the latest version of the code. Since the repository is local, this operation is quick and can be done offline.

3. Make changes – Simply make any changes you like, without concerning yourself about how your source control works. This is similar to Subversion, and contrasts sharply with TFS which needs to track any changes you make by interfacing with Visual Studio.

4. Check-in changes – When it’s time to check in your local changes, they are simply committed to your local repository. They do not affect any other repository. Changes are detected by comparing the newest committed revision with the current version on disk.

5. Push or pull changesets – To actually send your changesets to another repository, you need to "push" or "pull" them. In the Mercurial dialog below, there are options labeled "Incoming" and "Outgoing" which simply compare the local changes with the remote changes and determine what will get pushed or pulled. The "Push" and "Pull" operations send your changesets to another repository, or pull changesets from another repository respectively.

When changesets are transferred between repositories, they do not affect any working copies. This flexibility allows changes to be synchronized without affecting work in progress.

Online/Offline Operations

Operation	TFS	Subversion	Mercurial/GIT/Bazaar
Get/Update	Online	Online	Offline
Check-out	Online	Online	Offline
Check-in	Online	Online	Offline
View History	Online	Online	Offline
Revert	N/A	Offline	Offline
Compare working changes	Online	Offline	Offline
Change tracking	Limited*	Offline	Offline

* Changes can be made in a special "offline" mode, and edited files will be checked-out when returning to "online" mode.

Merging Divergent Development Branches

In traditional, centralized source control systems, the only way for a divergence in code paths was to explicitly create a branch. While this is still possible in a distributed source control system, it is also possible for multiple developers to make independent changes that may or may not conflict.

The beauty of the system is that divergent code paths can be merged at any time. It is possible for the developers to make multiple changes, perform multiple synchronizations (pulls), yet not have to merge until they want to, or until they need to push their changes to another repository.

Where Is My Repository?

If you’re working with a team of 20 developers, and each one has a full copy of the repository, you don’t need a central repository. However, there are a few reasons why it is recommended:

1. Central backup location – Even though you have numerous copies of the repository, it is still useful to have a single location that can be used as a place where an automated backup process is able to find it.
2. Central communication hub – The logistics of pushing and pulling code between a number of developers can get complicated. Distributing your repository simplifies many of these problems, but is not perfect by itself. Having a central "authoritative" repository can make it quick and easy for developers to collaborate.
3. Central location for builds – Automated builds and continuous integration servers need a location to pull source code from, which an authoritative repository provides.
4. Central merge location – If multiple developers are pulling changes from one another, implicit branches can be created. A central repository serves as location where all of these branches are merged into one development line.

Repositories can typically be easily hosted internally using Apache, a built in daemon, CGI script, or simply just a file share. For simplicity, there are many services that provide repository hosting. For Git, there is GitHub and SourceForge. For Mercurial, there is BitBucket, Google Code, and SourceForge.

The beauty of distributed source control is apparent when you take into account the administrative overhead of a central server. Since the central server is no different than any other peer, it can be easily moved or modified. For example, you can start out with no central server, then you can use BitBucket to store your revisions, then you can move to another service within minutes. Changing providers simply means pushing your changes to another server.

Common Operations

Importing Existing Code

Importing existing code is an extremely simple operation. If it is new code that is not yet under source control, you can simply create a new repository within the folder that contains your code. You can then check in your code as desired.

In Subversion, the import process involved importing the code into the repository, and then checking out a working copy. Mercurial does not have this complexity.

Mercurial also comes with built in support for converting existing Subversion repositories to Mercurial repositories, including the entire revision history. More information is available here.

To convert from an older source control system such as Visual Source Safe, you can first convert the repository to Subversion, and then to Mercurial.

  Checking-in Code

It is worth mentioning a typical philosophical difference between how some source control systems promote the check-in process for changes. Systems like TFS and Visual Source Safe only provide limited functionality for reverting and re-applying specific changesets. For this reason, developers tend to check-in groups of unrelated changes. This tends to lead to less useful generic or incomplete comments such as "done for the day".

Flexible source control systems such as Subversion, Mercurial, and Git provide a lot more value when changesets are fine-grained, and represent a single change to the system. For example, renaming a page and changing the tab order are two changes that should be checked-in separately. If needed, either feature can be pulled in or out, moved, synchronized, or used to patch other versions. It also reduces the likelihood of conflicts, and typically makes conflict resolution easier. Other developers can quickly scan through the changelog and get a clear list of the features that were added, or bugs that were fixed. In an ideal world, all commits should be tied to a bug or feature to increase traceability.

Managing Branches & Releases

It is simple to create explicit branches that allow you to maintain parallel development of different features or versions. Branching simply involves entering a branch name when you commit your code. Switching between branches is as easy as performing an update to the latest revision of a branch. In contrast, TFS requires a branch to be created before you can commit changes to it. TFS also keeps a copy of each branch on the developers machine, which is optional with Subversion, Mercurial, and others.

Since changes can be made independently, there is also a concept of implicit branching. If we have two users, Ann and Bob, they are free to make changes independently of each other. If Ann checks in her changes, and then Bob pulls down those changes while having changes of his own, there are now two implicit branches of development. In this case pulling changes will automatically create multiple parallel lines of development. Changes cannot be pushed unless the code has been merged. The system is designed this way so that merging is only necessary when pushing, typically to a central repository or build server. The effect is that repositories that are only "pushed to" can be easily and cleanly maintained remotely.

Most distributed source control systems include tools that allow a visual display of code branches. This functionality is also likely to be included in Team Foundation Server 2010.

Tagging Revisions

In order to mark the significance of certain revisions, they can be tagged with a specific label. For example, when you release a specific version of your project, you can tag that revision with the label "v1.2" as seen below. Additional flexibility is provided by the "local tag" functionality, which lets you tag code on your computer without sharing the tag with others.

Terminology

Distributed Version Control System (DVCS) – Version control systems manage the changes of documents. In software development, their primary purpose is to store the source code for an application, as well as every revision created during its development.

Repository – A container for a set of changes that represent the history of the source code for a project. A repository may have the ability to store a partial history of the project, or the entire history. The repository is typically optimized by using compression and by only storing deltas or changes of files.

Changeset/Revision – A particular "delta" or change in the codebase. This can include any type of change, in any number of files. Visual Source Safe stored revision numbers for each file. Team Foundation Server and Subversion have global revision numbers for the entire repository. Distributed source control systems often use GUID’s or hash codes to represent specific revisions.

Working copy – A particular revision of the code that has been extracted or checked out from the repository. This revision includes the full version of all the files involved so that the developer can load and make changes to the code.

Bundle – A bundle is a file that contains a set of changes that is intended to be sent to another user to update their repository. This technology allows users to be physically disconnected yet pass code changes to each other. This file typically employs some form of compression to minimize file size.

Patch/diff – A patch is a file that shows the changes between two versions of a file or multiple files. It contains enough information to transform the old version into the new version, or vice-versa. It’s a quick way of sending someone a changeset. Patches are usually in the "unified diff" format, which looks like the following:

--- /path/to/original timestamp
+++ /path/to/new      timestamp
@@ -1,3 +1,9 @@
+This is an important
+notice! It should
+therefore be located at
+the beginning of this
+document!
+
 This part of the
 document has stayed the
 same from version to
@@ -5,16 +11,10 @@
 be shown if it doesn't
 change.  Otherwise, that
 would not be helping to
-compress the size of the
-changes.
-
-This paragraph contains
-text that is outdated.
-It will be deleted in the -near future.
+compress anything. 

 It is important to spell
-check this dokument. On
+check this document. On
 the other hand, a
 misspelled word isn't
 the end of the world.
@@ -22,3 +22,7 @@
 this paragraph needs to
 be changed. Things can
 be added after it.
+
+This paragraph contains
+important new additions
+to this document. 

References

• http://msdn.microsoft.com/en-us/library/ms194956(VS.80).aspx
• http://www.pumacode.org/projects/vss2svn
• http://www.selenic.com/mercurial/wiki/PublishingRepositories
• http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
• http://code.google.com/p/tortoisegit/
• http://bitbucket.org/tortoisehg/stable/wiki/Home
• http://msmvps.com/blogs/vstsblog/archive/2008/08/17/how-microsoft-uses-team-foundation-server-internally.aspx
• http://blogs.msdn.com/bharry/archive/2007/09/15/update-on-microsoft-tfs-adoption.aspx
• http://blogs.msdn.com/bharry/archive/2008/09/15/september-08-devdiv-tfs-dogfood-statistics.aspx

Recommended Reading

• Illustrated introduction to distributed version control
• Mercurial QuickStart
• Mercurial: The Definitive Guide
• TortoiseHg Download
• Google’s Analysis of Git vs Mercurial

Performance

I’ve taken a site that I consider a “playground site”, and converted it over to run in Azure. One of the metrics I wanted to look at was the responsiveness of the deployed application. I run the main version of the site on a dedicated server, and I don’t think it’s unreasonable to use that as a baseline. After all, the purpose of Azure is to have the advantages of all the different types of hosting, yet have less to worry about.

To gauge performance, I used the Firefox add-in called Firebug. This let me see the amount of time that each requested element took to be transferred from the server. It also gives some insight into the amount of time it takes for the page to render. In the future, I’m going to use some server tracing to find specific operations that may be taking longer.

This is the baseline data from http://www.simpletracking.com. As you can see, the page is served up very quickly. The page takes less than 100ms to render (1/10 of a second), and the entire page comes through in less than half of a second.

Now take a look at the same code running on Azure:

To render the page, instead of 89ms, it now takes ~650ms. It takes a full second for the entire page and its elements to be sent down to the client.

Running both pages several times started to give me interesting results. The dedicated server was giving me extremely consistent results (even with other users hitting it). Azure however, was all across the board. It was typically around 1 second for the entire page to render, but would spike up to 5 seconds occasionally. Personally, I think this is completely unacceptable performance. Hopefully this is not indicative of the performance I can expect once it’s released.

IoC

Azure is designed so that if you have an application that runs in medium trust, it shouldn’t require any conversion to run straight in Azure (in most cases). If you’re using a database, there are other restrictions because Azure doesn’t use a standard SQL database. In addition to these obvious issues, a non-obvious issue is that if you’re using an IoC container, it probably won’t run in medium trust.

My application uses the IoC container Spring.NET, which immediately failed. I suspected (incorrectly) that Windsor might have worked better, but couldn’t tell from the documentation. To make it easy to plug in different IoC containers, I started using the Common Service Locator. If you’re doing IoC without the common service locator, I really recommend you check it out.

I was then fortunate enough to find this page, which has great information on the different IoC containers and their Azure compatibility:

Castle Windsor – My preferred IoC container, but it won’t run under medium trust. Out!

StructureMap – My second favorite IoC container. Runs under medium trust locally, but not under Azure. Submitted bug report to Jeremy Miller. Reading through the StructureMap user’s group, it looks like he’s going to try to fix that early this year.

Ninject – I didn’t really monkey around with Ninject much. The sample code I saw was riddled with [Inject] attributes, which kinda turned me off. Apologies to @nkohari if I dismissed it too early.

Autofac – Works great in medium trust under Azure, easy to configure, but doesn’t support registering arguments for constructor injection at configuration time. You have to specify them when you resolve the service.

Unity – No problems at all! Worked great in medium trust on Azure, easy to configure, supports everything I need! I gotta say I’m really impressed by how far Unity has come in such a short time.

My only reasonable option was Unity, which is Microsoft’s IoC container. After another fun conversion, I was up and running! I honestly don’t have any complaints about their IoC offering.

Instances

The Azure team decided to introduce the concept of “Instances”. You have to decide how many virtual instances of a web server that you want running. I really don’t understand the logic here. Their sales pitch is all about handing unpredictable traffic patterns, yet an instance based approach just gives me another aspect of the application that I have to worry about. They’re promising that a configurable heuristics system will eventually be in place to handle the management of the number of instances. In effect, they are putting a band aid on a problem that they’ve created even before release.

Contrast this design with the Google App Engine. With their system, you don’t have to worry about configuring instances at all. It automagically scales from nothing to infinity automatically.

Instances on the worker roles make sense. Worker roles are not public facing, they are there to process data. By configuring the number of worker role instances, I can change the rate at which my data gets processed.

Conclusion

I realize that Azure isn’t even in beta yet, so I shouldn’t expect the world. I had my fingers crossed that their CTP would be production quality (wouldn’t that be nice?). I think that Microsoft will eventually have a great cloud platform on their hands, it’s simply a question of timing. Personally, I really don’t want to have to worry about uptime, scaling, RAID, drivers, viruses, etc. so I think cloud computing is the inevitable solution.

Now that I’ve gotten the chance to put DropBox through its paces, I have to say that I’m very impressed. I’ve done a lot of operations that can sometimes choke file monitoring software like moving and renaming files, copying files while synchronizing, and in-use files. DropBox powered through like a champ, never giving me any errors, and without any noticeable mistakes.

In addition to simply synchronizing your files, their service also keeps a copy of your files on their server. Better yet, it automatically revisions the files. It seems to be fairly efficient, even considering all my files and revisions. Right now I’m only using 7.8% of the 2GB of space they give you for free.

One of the applications that I use the most is OneNote. Pretty much all of my disconnected thoughts go into OneNote until I can get them organized. I figured it was a great application to test the responsiveness of DropBox. I opened OneNote on two different computers. When I changed the text on one machine, the changes showed up on the other in 10-15 seconds. Perfect for keeping my notes in sync!

My one and only complaint about DropBox is that I can’t create multiple DropBoxes. A single DropBox is simple and efficient, but it would be nice to have a little more flexibility.

Live Mesh

A few nights ago, I got a demo of the Azure platform by a Microsoft Evangelist. Azure is a huge blank term for a group of confusing technologies. Even the name itself is confusing, since Azure is a cloud computing platform and is also the color of the sky when there are no clouds.

More importantly, one great thing to come out of the “Live Services” portion, is a free product called “Live Mesh”. It’s essentially a competitor to DropBox. The nice thing about Live Mesh is it’s flexibility. I can make any number of synchronized folders, and they all seem to be as reliable as DropBox. Thanks to a sophisticated permissions system, you can even share folders with other people. For example, you can have a folder set up to distribute your photos to your family.

The Microsoft Azure Evangelist showed us a demo with the client installed on his laptop, and another client installed on his Windows Mobile phone. When he takes a picture on his phone, it’s immediately pushed over to the other clients. It’s a neat trick, and does make my mobile device more useful.

As far as I can tell, Live Mesh doesn’t have plans to support a revision system like DropBox. I think this is a horrible, horrible mistake. Having a file on multiple machines provides nice redundancy, yet if you accidentally delete a file on one computer, Live Mesh will happily delete every copy of it. It even happened to Scott Hanselman. In my opinion, this completely destroys any hope it has of competing with DropBox (at least for me). I’m hoping that they’ll add a backup feature, or someone will use their API to add it for them.

Others

One service I have yet to try is SugarSync. It looks promising because it syncs multiple folders, stores revisions, and even has a Windows Mobile version (although it’s missing real-time sync). On paper, it looks like it has all the options you would expect from this type of service.

Syncplicity looks respectable, but with so many alternatives, I’m just not sure if they have anything unique that sets them apart.

Conclusion

I think this type of application is going to have a huge market. This is one of those few killer app’s that if done well, will be on everyone’s computer. Obviously Microsoft’s offering will be positioned to dominate, but we all know that they don’t always have the absolute best product.

For now, I’ll be using DropBox for my main document folder. It suits my needs, and until it messes up, I won’t need to look elsewhere.

Here is a screenshot of what you’ll see in the stock Team Foundation Server compare tool:

See how hard it is to spot the difference? The problem is, ANY change on the entire line causes it to show up as “changed”. That includes whitespace changes. For this reason, I frequently end up with extra full lines that are colored as having been changed, making it harder to see the actual code changes. For the most part, I really don’t care about whitespace changes because they deal with the formatting of the document, and I’m more concerned with functional changes to my code.

The good news is that those smart guys at Microsoft make it easy to integrate a third party compare tool right into their tools. James Manning was even kind enough to include detailed instructions and the exact settings needed for every major compare tool. You can even use them for merging if you like.

Since my background is in Subversion and TortoiseSVN specifically, I pulled out my trusty KDiff3 (SourceForge) compare tool. It’s a common alternative for TortoiseSVN’s own diff tool.

After wiring up KDiff3, here is what I saw when I compared revisions:

Notice how easy it is to see that I changed a single letter (it’s obviously easier when it’s full-size).

There are other good reasons to use a third party compare tool (which vary by tool obviously):

• Easily compare entire file structures (folder diff)
• Inline editing
• Easy to use outside of Visual Studio – often with an explorer context menu

I recommend giving a few of the compare tools a try and see which works best for you. I don’t really see any risk in using a third party compare tool, but there are certainly a lot of advantages that you may not even know you’re missing right now. I suggest also taking a look at WinMerge in addition to KDiff3, since it seems to be fairly popular and feature-rich as well.

If you’re not familiar with ClearType, you can head over to Wikipedia for a full explanation. In a nutshell, it takes advantage of the fact that each pixel in an LCD screen actually has 3 sub-pixels. They can be “hacked” to improve the anti-aliasing of text displayed on the screen. I’ve been a huge fan of the feature, especially for source code, and I have a hard time living without it. In XP (locally), it’s turned off by default, but turned on in Vista.

I had always noticed the remote desktop would not give me ClearType. However, I became curious when I found the following options on my Vista machine. Apparently ClearType over RDP is now supported in the client, and is also supported when using Vista as the RDP server (no hacking needed).

Unfortunately, these options have no effect when using XP. If you want ClearType over RDP with XP SP3 (sorry, only SP3+), add the following registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations]
"AllowFontAntiAlias"=dword:00000001

After you add that registry key, simply reboot the server (XP), and reconnect. From what I can tell, the client options no longer matter. Even if I uncheck the “Font Smoothing” option, it still uses ClearType. It’s not a big deal, but I thought it was worth mentioning.

So far, after using this option for a while, I haven’t seen a significant performance impact over a VPN on the Internet.

If you want to take this a step further, install Consolas, it’s a font designed specifically for software development, and to take advantage of ClearType. It’s a free download from Microsoft.

I’ve tried or considered many different ways of hosting my content:

• Shared hosting – Cheaply host your sites, but be at the mercy of their IT guy messing with your computer and rebooting it for automatic updates. Also, in my experience, the performance is terrible if your traffic spikes. They typically have hundreds of users on the same server as you, and you all get to compete for performance.
• Dedicated hosting – This is what I use now, because it ensures that I get the full performance of a machine. The disadvantage is that I have a single point of failure, and I have to manage the machine myself.
• Hosting from home – Yes, people actually do this. If you have a high enough upload speed it shouldn’t be too bad. The problem is that your connection typically won’t be able to handle traffic spikes. You’ll also potentially be a victim of power or Internet outages, where professional hosts would have redundant systems in place (in theory).

Now, let’s talk about cloud computing. That magical cloud that many don’t understand. There are two potentially viable cloud computing methods available right now:

• Cloud virtual machines – Amazon’s EC2 solution is probably the most popular in this category. Basically, you can create, start, and stop virtual machines remotely. You just pay an hourly rate while the computer is running. You can even upgrade and downgrade the hardware as needed. The advantage is that you can treat the computer like a physical machine and configure and use it however you like. The disadvantage is that maintaining individual machines can be time consuming and is not necessarily part of your core business.
• Cloud application server – Instead of creating virtual machines, a cloud application server runs your application directly. You no longer worry about the constraints of a physical machine. You application could potentially be run on dozens or hundreds of servers simultaneously. The major advantage is that there is little to no maintenance, because that is the job of the provider.

I see the cloud application server as having some of the greatest advantages. You’re free to write your application with a level of abstraction, which allows you to solve the problems you really want to solve.

One of the most well known cloud application services is the Google App Engine, which currently supports Python applications. Microsoft joined the game recently with Azure for ASP.NET.

As I mentioned, not only do application servers let your applications scale up, they let you pay only for what you use. This is great for the small to medium website’s that are stuck with bad shared hosting or difficult-to-manage dedicated hosting. The fact is that most sites get a few hundred visitors daily or less. If you start to think about how often a page is actually requested, you’ll realize that it’s not very much. Even with 500 users requesting 5 pages each in a 12 hour period can easily be handled with a very low end server from years ago.

The reason that application servers are so much more efficient than shared hosting is because they’re built from the ground up to spread the load around. This results in higher utilization, but more headroom for any single application. Shared hosting providers can move users between servers, but it’s usually a manual, and often difficult process. You’re bound to a specific physical machine (unless it’s VPS hosting), and if it goes down, so does your site.

Cloud computing is also a great way to handle traffic spikes such as the Digg effect. Let’s say that you only have 500 visitors today, but might get 10, 100, or 1000 times more in a single day. It happened to FaceStat. They went from 10,000 page views per day to almost a million because of a story on the front page of Yahoo. They had to scramble to add application servers and develop a scaling strategy immediately.

Conclusion – Cloud Application Server Benefits

Cloud computing has tremendous benefits. You no longer have to worry about scaling the underlying hardware, you simply pay as you go, and you can handle traffic spikes with ease. Once cloud computing becomes mainstream and absolutely reliable, there will be few reasons to not use it.

XAMPP Super-Quick Overview

XAMPP is basically a quick way of setting up MySQL, PHP, Perl, and Apache. You can download it, extract it, and run it from any location. If you’re not experienced Apache/PHP world, this is the easiest way to get something working ASAP. In the next image, you’ll see the directory structure under your XAMPP directory:

Here are the key folders you would probably need to worry about:

• apache – Contains the installation of Apache.
• htdocs – Contains the folder that is served up by Apache. If you want to install a web application such as Wordpress, you probably want it in here.
• mysql – Contains the installation of MySql.

Now, if you simply want to install Wordpress on XAMPP, I’m not going to write yet another tutorial. There are plenty out there, most with screenshots of step-by-step instructions, just Google for them.

Securing XAMPP

Once I configured XAMPP, I stupidly assumed that the utility applications like phpmyadmin would not be publicly available. I was very wrong, and was warned before anyone decided to do something bad.

Most of the instructions I found through Google for securing the utility paths seemed kind of weak to me. They basically work by securing those paths with a password. I’m a little paranoid, so I don’t want those paths remotely accessible at all.

The first thing I did was lock down Apache security so that it’s very restrictive by default (apache/httpd.conf):

<Directory />
    Options Indexes FollowSymLinks Includes ExecCGI
    AllowOverride All
    Order deny,allow
    Deny from all
</Directory>

Make sure that you don’t have any other directory directives in your configuration file that may override this.

Next, in the .htaccess file for each Wordpress installation, I added this line: “Allow from all”. This basically tells Apache that this folder is safe to serve up to everyone.

Now, the problem is that XAMPP has a configuration file that overrides the utility paths and allows access for anyone. To fix this, perform a search and replace in the (in Apache/Conf/Extra) “httpd-xampp.conf” file to change “Allow from all” to “Allow from 127.0.0.1″. Now, all of the XAMPP directories will only be served locally.

Conclusion

My background is certainly not Apache/PHP, but I’m still learning. If I made any mistakes in my configuration, please leave a comment or send me an email.

Watching the progress of Vista, I couldn’t help being disappointed. Vista was supposed to change the world. There would be an amazing new file system, a cutting edge graphics system, and .NET driving many of the core functionality. But one by one, the features got neutered or disappeared completely.

When it was released, the bad hype had already nearly killed it for me. Then I installed it in a virtual machine and learned what a pile of crap it really was. It took minutes to boot, and the UI was barely usable. Every few seconds I would get security prompts. I was done with this OS for a long time.

Fast forward to Windows 2008. I started reading great things about how this OS made a great desktop OS. At the core, it’s Vista SP1, but with much of the crap removed. I tried it out, and loved it. I had a few issues with incompatible drivers, but that’s expected when using a just-released 64-bit OS.

Then, Vista SP1 was released, and most of the cynics said it was "decent". Time had helped fix the driver issues, and SP1 addressed specific pain points. Eventually I got around to installing Vista SP1 (64 bit) over Windows 2008. I was amazed. Nearly all of the drivers were already included. It was fast, and some of the new features, while not life changers, were a boost to my productivity none-the-less.

Recently, I purchased a new laptop. It’s shocking what you can get for a mere $650. It’s a 14.1" HP (dv2910us) with 3GB RAM, 2GHz Core 2 Duo, 250GB hard drive, 802.11n, DVD burner, and even a built-in removable remote control. Of course it included a license for Vista. HP includes a shocking amount of crapware, so I reinstalled Vista from my MSDN media. One major improvement over XP is that your OEM key works with MSDN media. That means I can actually use the key that was on the sticker of the laptop! Thank you Microsoft (and it’s about time)!

It runs great on my laptop, and I’ve had no complaints whatsoever. In fact, I think I’ve had less issues than if I was running XP. Much to my surprise, a few days ago I get a prompt to install updates. The update in the list was SP1. Yes, that’s right, I wasn’t even using SP1. Maybe Vista was bad when it came out, but I think the horsepower of modern computers combined with finally decent driver support erases the bad history.

I’ll sum up what I love about Vista over XP in one paragraph. Integrated search from the start menu rocks, and I use it constantly. I also love the new copy dialog, which tells me the actual speed of file transfers. As far as 64-bit support, I’ve been very impressed. It’s very possible to run the 64-bit version and have a decent change of all of your devices working as expected. This is a must since typical new high-end computers are going to start going over 4GB RAM soon (if they haven’t already). There are even hard to find features that are very nice. When you copy a folder over another folder, it actually gives you a reasonable set of options, as well as enough information to make a decision about merging, overwriting, or even renaming them.

Now what about UAC? You know, the feature that pops up an annoying dialog every 5 seconds? Well, if you run your computer as a local administrator (like you did in XP), you’ll rarely see them. I actually appreciate them because it does make your computer safer.

Conclusion

Make up your own opinion about Vista and give it a try. It’s mature enough that I recommend it to my tech friends. I was just as apprehensive as everyone else, but I’m glad I made the switch. In case you’re wondering, no Microsoft hasn’t paid me, but it sure would be nice .

Features I was looking for:

• Reasonably Priced
• Automatic
• Reliable
• Scalable
• Well performing
• Easy

Price

To automate my backups, I’m using a product called JungleDisk. You can purchase it for $20, and you get free upgrades for life. I love products that have free upgrades for life, since I don’t have to worry about when buy it. They also allow you to use it on unlimited computers, which I definitely need.

JungleDisk by default talks directly with S3, so they don’t need to run any servers. You’re counting 100% on the reliable storage provided by S3.

Organization

Amazon stores your files in "buckets", which you can think of as a single level folder/directory structure. JungleDisk can easily connect to multiple buckets at the same time. You configure each bucket independently. JungleDisk can automatically detect all of your buckets, and you can easily create new ones.

I highly recommend creating buckets for each logical group of files you want to back up. Try to avoid sharing a bucket between computers when possible. If you tell JungleDisk that a bucket is only used on one computer, it doesn’t have to query S3 to determine what needs to be synchronized. The default is set to multiple computers. This setting is under the "Bucket Settings" for each bucket.

Each bucket also lets you choose what to back up. Of course there are extensive options for backing up subfolders, excluding files, etc.

You can even set up how your local folders get mapped to the remote folders. This lets you do multiple folders in one bucket. On my laptop, I have a couple of folders that get backed up to a single bucket, but are organized into different folders so that I could easily restore them independently.

Scheduling

Setting up a schedule is very easy. For example, on my laptop, I have it set to synchronize my files every hour. It uses the timestamp’s of the files to determine if there are any new, changed, or deleted files. Since I’m not sharing this particular bucket between machines, it can instantly determine if anything needs backed up.

Security

JungleDisk has all the security options you would expect. You can communicate with Amazon over port 80 unencrypted, or use SSL. I actually turn off the SSL option, because I use the JungleDisk encryption. I don’t see a reason to do double encryption.

When you create the bucket, you can specify a custom key that encrypts your data. I like this option because I am the only one that has access to the data. Even Amazon can’t tell what I’m storing on there.

Performance

Since Amazon is providing the storage, they’re able to scale indefinitely. You can be confident that they can handle whatever you throw at them. They had no problem letting me upload at over 56,000 kbits/sec from my dedicated host. I backed up 4 gigs in about 10 minutes.

Other Features

• Bandwidth limiting – If you don’t want to use up all of your upstream or downstream bandwidth, you can limit it, and even schedule when it’s limited. This could be useful for limiting the connection during the day. However, I much prefer a QoS solution since it will maximize the amount of bandwidth I can use.
• Previous versions – There are extensive options for storing previous versions of changed or deleted files. This option is very impressive, and great for documents.
• Network drive – You can make a bucket show up as a drive on your computer, which allows you to drag and drop files to and from the bucket.
• Jungle Disk Plus – For $1/month extra, you can get JungleDisk Plus. They use an Amazon EC2 server to proxy your data to S3. This allows you to resume large file uploads, and also lets you send just the differences. If you’re backing up large files and/or files that may have sections change frequently, this could end up saving you money.

Above, you’ll see the typical technology adoption bell curve. What you need to realize is that you’re starting on the left, and you’re trying to get up the hill. Do you think it’s easy? Well, judging by Youtube, twitter, milliondollarhomepage, Digg, or myspace, it must be easy!

The truth is, you should have a path to success. Here are just a couple of paths that have worked for other products:

• Create a product that is leaps and bounds better than anything your potential customers have ever seen – An example is Google, which was originally created by students in college. The brilliance of the algorithm and its implementation were the start of a massive company.
• Have an army of followers that listen to your advice – A great example is Steve Jobs. Before he even makes a new product announcement, people line up at Apple stores. People trust that he’ll make cool stuff, so they listen to whatever he says. You can bet that if Steve Jobs mentioned your product, you would people lining up at your door to buy it.
• Get lucky – It happens time and time again. Multiple products are released at the same time, all with similar features and price. Sometimes one of them gets lucky, and the others die. An example is the VHS vs Betamax format war. VHS was considered the inferior product, yet it went on to become the de facto standard.
• Create a product that is viral by nature – Twitter and Myspace come to mind. Once one person joins, they’re begging their friends to use if. If they don’t, the service is useless. The result is that you get an army of free advertisers talk to your key demographic.
• Spend a ridiculous amount of cash to bombard users with advertising – infomercial’s and those annoying “we’ll double the offer” commercials come to mind.

Hopefully I’m making the situation look difficult. I couldn’t find any concrete numbers, but you can be sure that more than half of online businesses fail within the first couple of years. That includes well-funded businesses. If you expect to start the next Fog Creek Software while working part time in the evenings, you need to have a plan.

The best advice I can give you is to do whatever it takes to get your product into the hands of as many people as possible. It might mean making partnerships with someone of influence, or it might mean creating a viral marketing campaign. It might also mean that you’ll have to give your product away for free, build up your army of followers, and then invent another great product. If you already have a product with a good user base, you’re probably already in good shape. If you are just starting out, don’t think that people will magically find you, unless you’re counting on the “lucky” path I described.