Are you a developer thinking of upgrading your PC? I have a very good reason for you not to upgrade.

It boils down to one thing: testing.

If you want to test your application from the user's perspective, especially from the lowest common denominator user's perspective, then your PC configuration needs to match those specs. If you have a top-notch PC that only 2% of your users have, guess what: 98% of your users will perceive your application as being "slow."

Rule of Thumb: 90th Percentile

Since you don't want to give your users the perception that your apps are slow, always match the 90th percentile of what your users are likely to have. So for example, if 90% or more of your users have at least 256 MB of RAM, then your development machine should have only 256 MB of RAM.

It turns out that about 90% of my users have dual-core CPUs (not quad core or single core) and at least 2 GB of RAM. They also have a video card that generally gets at least 30 TTP/s in the 3D test. My current dev PC is about twice those specs. It is a dual-core Intel Core 2 Duo E8400 with 4 GB RAM, and it gets around 70 TTP/s in the 3D test. It is a bit more powerful than I want it to be, and I will certainly not be upgrading it for a while.

When I developed Dacris Benchmarks 5.0, in late 2001, I did so on an Athlon 1 GHz machine with only 256 MB of RAM. That became roughly the 90th percentile PC spec in early 2002 (for power users). I also had to target Windows 98 and Windows 2000 at the time. I had to set up virtual machines in VMWare to test those OSes, since I was already running Windows XP.

I have basically been following the 90% rule for at least 9 years, mostly not by choice - since I did not have the lavish budget to spend on the latest & greatest hardware. However, in the past 2 years I have been consciously following this rule and if anything it has given me a great excuse not to spend too much money on upgrades.

Going Against the Rule: Windows Vista, .NET

An infamous example of not designing for the 90th percentile can be seen with Windows Vista. In early 2007, the 90th percentile configuration was quite out of reach of the system requirements imposed by Vista. Keep in mind that Windows has to run on all kinds of PCs. Also, Vista is not like Dacris Benchmarks where users are knowledgeable about hardware and usually have more powerful hardware than your average PC user. Bottom line - the jump from XP's basic 64 MB RAM requirement to Vista's 1 GB was too much for mainstream PC users. The result - Vista never reached more than 19% market share!

And if you still doubt that performance matters, take a look at how slow the adoption of .NET has been. .NET is much more resource-hungry than "raw" C++. It requires lots of memory to do JIT compilation. You can hardly run a .NET app without major disk thrashing on less than 512 MB of RAM. That is part of the reason why .NET adoption did not really begin until late 2004. I remember the JVM (Java Virtual Machine) being extremely slow (again due to insufficient RAM) even as late as 2005.

Stick to a $2000 Budget

My advice to those thinking of building a super-ultimate beast for a development box: don't. Try to spend less than $2000 on your beast. Otherwise, you'll be living in an elite fantasy world, isolated from the real world inhabited by most PC users. Note - if your users are super-power users, then the $2000 budget is trumped by the 90th percentile rule. Always try to match the 90th percentile.

If, on the other hand, you want to do R&D, by all means go for the latest & greatest hardware. It is the best way to stay ahead of the game and develop ideas for software that will only be commercially viable in 3+ years. It is a great idea as part of a larger R&D strategy to have at least one "R&D beast" machine. However, you should never do real "production" development on your R&D beast.

Conclusions

Development (for your products) should always be confined to your 90th percentile configuration, so that performance is accurately modeled for 90% of your users. Otherwise, you may have a surprise when your users start complaining about performance issues.

It is far too easy to become tempted to write slow code if, on your PC, the slow code isn't really slow. Even if you plan to test your software on other (slower) PCs, the time you spend during that testing may not be enough to give you a solid feel for how your users will perceive your software. And even if you do spend enough time testing your software on slower PCs, if you catch performance issues at that late a stage in development, the effort necessary to correct them is much greater than if you simply designed your software for that PC configuration in the first place.

What is Vmana?

Why is it a revolution?

How is it being done?

Why cloud?

• Guaranteed performance.
• Guaranteed reliability.
• You only pay for what you use.
• Easy setup and deployment.

Why not a "bare bones" search engine like Lucene?

• Steep learning curve.
• Integration effort is costly.
• Maintenance is difficult (often requires dedicated staff).
• No analytics or reporting features.

Conclusion

Here is the example:

using System;
using System.Runtime.Serialization;
using System.Xml;
using System.Xml.Serialization;
using System.Collections.Generic;
using System.Text;

[Serializable()]
public class SerializableDictionary<TKey, TVal> : Dictionary<TKey, TVal>, IXmlSerializable, ISerializable
{
        #region Constants
        private const string DictionaryNodeName = "Dictionary";
        private const string ItemNodeName = "Item";
        private const string KeyNodeName = "Key";
        private const string ValueNodeName = "Value";
        #endregion
        #region Constructors
        public SerializableDictionary()
        {
        }

        public SerializableDictionary(IDictionary<TKey, TVal> dictionary)
            : base(dictionary)
        {
        }

        public SerializableDictionary(IEqualityComparer<TKey> comparer)
            : base(comparer)
        {
        }

        public SerializableDictionary(int capacity)
            : base(capacity)
        {
        }

        public SerializableDictionary(IDictionary<TKey, TVal> dictionary, IEqualityComparer<TKey> comparer)
            : base(dictionary, comparer)
        {
        }

        public SerializableDictionary(int capacity, IEqualityComparer<TKey> comparer)
            : base(capacity, comparer)
        {
        }

        #endregion
        #region ISerializable Members

        protected SerializableDictionary(SerializationInfo info, StreamingContext context)
        {
            int itemCount = info.GetInt32("ItemCount");
            for (int i = 0; i < itemCount; i++)
            {
                KeyValuePair<TKey, TVal> kvp = (KeyValuePair<TKey, TVal>)info.GetValue(String.Format("Item{0}", i), typeof(KeyValuePair<TKey, TVal>));
                this.Add(kvp.Key, kvp.Value);
            }
        }

        void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
        {
            info.AddValue("ItemCount", this.Count);
            int itemIdx = 0;
            foreach (KeyValuePair<TKey, TVal> kvp in this)
            {
                info.AddValue(String.Format("Item{0}", itemIdx), kvp, typeof(KeyValuePair<TKey, TVal>));
                itemIdx++;
            }
        }

        #endregion
        #region IXmlSerializable Members

        void IXmlSerializable.WriteXml(System.Xml.XmlWriter writer)
        {
            //writer.WriteStartElement(DictionaryNodeName);
            foreach (KeyValuePair<TKey, TVal> kvp in this)
            {
                writer.WriteStartElement(ItemNodeName);
                writer.WriteStartElement(KeyNodeName);
                KeySerializer.Serialize(writer, kvp.Key);
                writer.WriteEndElement();
                writer.WriteStartElement(ValueNodeName);
                ValueSerializer.Serialize(writer, kvp.Value);
                writer.WriteEndElement();
                writer.WriteEndElement();
            }
            //writer.WriteEndElement();
        }

        void IXmlSerializable.ReadXml(System.Xml.XmlReader reader)
        {
            if (reader.IsEmptyElement)
            {
                return;
            }

            // Move past container
            if (!reader.Read())
            {
                throw new XmlException("Error in Deserialization of Dictionary");
            }

            //reader.ReadStartElement(DictionaryNodeName);
            while (reader.NodeType != XmlNodeType.EndElement)
            {
                reader.ReadStartElement(ItemNodeName);
                reader.ReadStartElement(KeyNodeName);
                TKey key = (TKey)KeySerializer.Deserialize(reader);
                reader.ReadEndElement();
                reader.ReadStartElement(ValueNodeName);
                TVal value = (TVal)ValueSerializer.Deserialize(reader);
                reader.ReadEndElement();
                reader.ReadEndElement();
                this.Add(key, value);
                reader.MoveToContent();
            }
            //reader.ReadEndElement();

            reader.ReadEndElement(); // Read End Element to close Read of containing node
        }

        System.Xml.Schema.XmlSchema IXmlSerializable.GetSchema()
        {
            return null;
        }

        #endregion
        #region Private Properties
        protected XmlSerializer ValueSerializer
        {
            get
            {
                if (valueSerializer == null)
                {
                    valueSerializer = new XmlSerializer(typeof(TVal));
                }
                return valueSerializer;
            }
        }

        private XmlSerializer KeySerializer
        {
            get
            {
                if (keySerializer == null)
                {
                    keySerializer = new XmlSerializer(typeof(TKey));
                }
                return keySerializer;
            }
        }
        #endregion
        #region Private Members
        private XmlSerializer keySerializer = null;
        private XmlSerializer valueSerializer = null;
        #endregion
}

The full C# file can be downloaded here: SerializableDictionary.cs

This class is both XML-serializable and binary-serializable. It is hard to find examples out there that do both.

1. Take out all the WCF junk from the web.config. God knows WCF likes to flood you with configuration.
   
   
2. Add one line to Global.asax.cs, in Application_BeginRequest:
   MyService.ProcessRequest(HttpContext.Current);
   
   
3. Then, create a class called MyService, with a bit of reflection to figure out which service method to call (based on your URL and query string parameters), and a call to XmlSerializer to convert the return value to XML. One example (in my case, called SearchService), can be found here.
   

• IIS --> Windows Azure
• SQL Server --> SQL Azure
• Outlook --> Gmail
• Backup --> Mozy
  
• Bugzilla
• SVN

1. Purchase, deploy, and maintain a gigantic enterprise search application (e.g. Google search appliance, Endeca, FAST).
2. Integrate Lucene (or another free search engine) into your application (Java/ASP.NET) and develop your own management interface for it.
3. Drop the customization and integrate a basic Google search box into your web app, that can only index & search your HTML pages.

1. You go to vmana.com and sign up for your free entry-level search account.
2. Just like App Engine, Vmana is metered. Let's say your entry-level account has 500 MB of index space and 100,000 queries per month.
3. Using an easy-to-use admin interface, you configure your data sources:
1. You want some data to be pulled in from your blog, so you give it your RSS feed URL.
2. You want it to crawl your website, so you give it your home page URL.
3. You set up some exclusion lists using regular expressions to filter out unwanted URLs.
4. You have some custom objects with metadata that you will feed in with your own feeder application.
4. Vmana handles all of your object types & indexes them regularly. You can check your stats using the built-in dashboard.
5. Vmana provides a testing console - a simple web page where you can type in queries, see results, and build out customized result templates for use later.
6. You then use the Vmana XML API to send queries from your web application. Your web app just builds the query, sends it to Vmana, and retrieves the results in XML format. Then, you apply a bit of XSL and magic happens - you've got your fully-customized search results page.