Modernizr has built-in detection for most HTML5 and CSS3 features that’s very easy to use in your code. It’s very widely adopted and constantly enhanced. Both Modernizr and jQuery are shipped with the ASP.NET MVC tools.

As HTML5 and CSS3 become more and more prevalent feature detection is increasingly relevant.

A growing number of ready-made “fallbacks” for many HTML5 features, known as shims and polyfills, can ease that burden. These come in the form of CSS and JavaScript libraries or sometimes even as Flash or Silverlight controls that you can use in your project, adding missing HTML5 features to browsers that don’t otherwise support them. The difference between shims and polyfills is that shims only mimic a feature and each has its own proprietary API, while polyfills emulate both the HTML5 feature itself and its exact API. So, generally speaking, using a polyfill saves you the hassle of having to adopt a proprietary API.  The HTML5 Cross Browser Polyfills collection on github contains a growing list of available shims and polyfills.

As .Net developers we are usually insulated from browser incompatibility issues, however, there may be situations where you are not using the .Net framework.  There is a good example of using yepnope (a conditional resource loader) for HTML5 Form Validation at CSSKarma.  I tweaked and re-implemented  the example using a .Net MVC application which you can see below.  A couple of “gotchas”:

· Modernizr is part of the .Net MVC tools that come from Microsoft, however, yepnope is not in the release of the MVC tools that at least I have on my machine.  You will need to download version 2.0 from modernizr.comto get yepnope support.

· The JQuery syntax for working with YepNope takes some getting used to.  Make sure to load JQuery first.

· Visual Studio 2010 does not seem to know about HTML5 and will warn of a validation when you use its attributes. See figure #2.

Figure 1 – MyValidation.js – based on the example at CSSKarma

Figure 2 – HTML5 Source

Figure 3 – Output

References:

http://yepnopejs.com/

http://haz.io/

http://modernizr.com

Scalability is the ability to handle additional load by adding more computational resources.  Performance is not scalability, however, improving system performance mitigates to some degree the need for scalability.  Performance is the number of operations per unit of time that a system can handle (e.g., words / second, pages served / day, etc.).  There are two types of scalability – vertical and horizontal.

Vertical scalability is achieved by by adding more power (more RAM, faster CPU) to a single machine.  Vertical scalability typically results in incremental improvements.  Horizontal scalability is accommodating more load by distributing processing to multiple computers.  Where vertical scalability is relatively trivial to implement, horizontal scalability is much more complex.  Conversely, horizontal scalability offers theoretically unlimited capacity.  Google is the classic example of infinite horizontal scalability using thousands of low-cost commodity servers.

If you have the luxury of working off of a blank sheet of paper or have the flexibility to implement a major new technology stack some of the better solutions for implementing scalability include ActiveMQ, and Hadoop. Microsoft’s AppFabric Service Bus promises capability in this area for Azure hosted applications. Many times scalability was considered when an application was first created but has proven to be inadequate for current demand.  The following are suggestions for improving an existing application’s scalability.

Microsoft’s Five Commandments of Designing for Scalability

• Do Not Wait- A process should never wait longer than necessary.
• Do Not Fight for Resources - Acquire resources as late as possible and then release them as soon as possible.
• Design for Commutability- Two or more operations are said to be commutative if they can be applied in any order and still obtain the same result.
• Design for Interchangeability – Manage resources such that they can be interchangeable (i.e., database connection).  Keep server side components as stateless as possible.
• Partition Resources and Activities – Minimizing relationships between resources and between activities

Microsoft’s Best Practices for Scalability

• Use Clustering Technologiessuch as load balancers, message brokers, and other solutions that implement a decoupled architecture.
• Consider logical vs. physical tierssuch as the model view controller (MVC) architecture.
• Isolate transactional methodssuch that components that implement methods that implement transactions are distinct from those that do not.
• Eliminate Business Layer State such that wherever possible server-side objects are stateless.

Shahzad Bhatti’s Ten Commandments for Scalable Architecture

1. Divide and conquer – Design a loosely coupled and shared nothing architecture.
2. Use messaging oriented middleware (ESB) to communicate with the services.
3. Resource management – Manage http sessions and remove them for static contents, close all resources after usage such as database connections.
4. Replicate data – For write intensive systems use master-master scheme to replicate database and for read intensive systems use master-slave configuration.
5. Partition data (Sharding) – Use multiple databases to partition the data.
6. Avoid single point of failure – Identify any kind of single point of failures in hardware, software, network, power supply.
7. Bring processing closer to the data – Instead of transmitting large amount of data over the network, bring the processing closer to the data.
8. Design for service failures and crashes – Write your services as idempotent so that retries can be done safely.
9. Dynamic Resources – Design service frameworks so that resources can be removed or added automatically and clients can automatically discover them.
10. Smart Caching – Cache expensive operations and contents as much as possible.

References:

• http://cacheonix.com/presentations/best_practices_for_scaling_java_applications_with_distributed_caching.pdf
• http://www.diranieh.com/DistributedDesign_1/Scalability.htm#Designing%20for%20Scalability
• http://msdn.microsoft.com/en-us/library/aa291566%28v=vs.71%29.aspx
• http://msdn.microsoft.com/en-us/library/aa291563%28v=vs.71%29.aspx
• http://weblog.plexobject.com/?p=1569
• http://highscalability.com/google-architecture

Red Flags

• Architecture that will not scale (possible walk away)
• Application cannot be re-built / run from source control checkout
• Inability to engender a sense of confidence that the solution really works
• Lack of forethought (this is where I’d like to go)
• Architecture that cannot be cleanly expressed
• Prima donna developers
• Absence of technical leadership
• Reliance on obsolete technology (i.e., Delphi)
• Business logic consistently found in the presentation layer
• Absence of any documentation whatsoever
• Critical code that no one owns (i.e., that was developed by abc who isn’t here anymore)
• Serious ethical breakdowns

Reasonable expectations

• Absence of perfect documentation (even the best organizations are challenged to have up to date documentation)
• At least one thing that impresses you as “world-class” (the more the better)
• Good code
• Finding that there are one or two go-to people
• People wear many hats (product manager, QA, developer, etc.)
• Insufficient infrastructure
• Reliance on free services
• Lack of published standards, metrics, or formal process
• Informal bug tracking
• Out of date off-the-shelf software
• Limited requirements documents

Things to give you pause

• Non-homogenous technology configuration
• Bleeding edge / specialized technology (e.g., Cassandra, assembly)
• Dependence on a service provided for free (Google Translate API)
• Sloppy code
• Lack of appreciation of the competition
• Insufficient knowledge of best practices (JQuery vs. JavaScript)
• How well will the system under examination compliment / be incompatible with existing systems?
• Are some areas more complete than others? (some code is more battle tested)
• Is there something that should be patented?
• Poor user interface
• General sense of mediocrity

• Review of current architecture either via documentation and whiteboard.
• Watch the application run from an OS console. (e.g., top, perfmon)
• Watch the application run from purpose-built administrator tools.
• Describe the hosting architecture.
• Where is the system hosted?
• How redundant is the system?
• How is the system monitored?
• What are the biggest bottlenecks in the system?
• Has your system ever been compromised?
• Characterize the reliability of your system.
• Have you done any vulnerability or penetration testing?
• How would you handle 10X volume, 100X volume, 1000X volume? (This is a big one.)
• Inventory of hardware and software (technology) assets.
• Where is your source code stored?

Software

• Review the source code (looking for good coding practices, clean architecture, exception handling, etc.).
• Review database schema and query the live database (or copy of live).
• Inventory custom components and software license agreements.
• Are there any public or private APIs?
• Review (developer) documentation associated with the code.
• Review user-facing documentation and/or training materials.
• Build all applications from source code and deploy to hosting environment.
• Is there a debug / development interface?
• Is there a database of customer feature requests or open issues?
• Are any obsolete technologies (i.e. Delphi) in use?

People

• Meet key employees and get to know their backgrounds.
• Who is the go to person?
• How do people collaborate?
• Describe your SDLC?
• Where do requirements come from?
• How is the software tested?

Product

• See a demo of all products, utilities, and supporting software.
• Product Roadmap: Recent, Past, Present, Future.
• Review current business model and sales process.
• Are there any prototypes or product concepts that we should see or discuss? (These can be hidden gems)

There are a bunch of good checklists out there for buying an entire company.  See references below.  Most of these checklists talk about software diligence relatively generically. After looking at a number of different organizations for a variety of different reasons I’ve built myself a checklist that may be useful starting point for others. I think my checklist is most applicable for medium sized applications (~1MM SLOC) built by teams of 3-10 people. Larger applications probably warrant a more sophisticated approach.

This post is not about valuing the business, assessing the product, or anything to do with market position. It is all about looking at the code, how the code is hosted, and assessing the technical assets of a business. If you are doing a project for a VC they typically want to know if there are any “red flags.” There are two types of red flags – those that are correctable and those that are not. A correctable red flag is something like lack of off-site backups or a non-redundant server. An uncorrectable red flag (which typically means walk away) are prima donna developers, limited / no documentation, or an architecture that cannot scale. If you are doing a project for a business that is trying to integrate a property with their own systems they want to know about the red flags but they also want an understanding of what they are going to be inheriting and what it’s going to take to make it useful as fast as possible.

Invariably the technical examination will overlap with looking at the business itself. For example, when buying a product that claims to have a million users its prudent to query the database and see that there are at least a million email addresses in the database. Similarly, the business development folks are often after any information that they can use to value the business or close the deal.

I think that much of technology due diligence is common sense. The good news is that, if it’s done right, you quickly get a feel for the goodness of the product.  A process that has served me well is to sit in on the preliminary conversations (which are often over the phone) with the management team. I may / may not ask some general questions during that meeting. I will then follow-up with a call to the CTO (or technology lead) to get into more detail. The goal of the technology call is to confirm my understanding of the technology stack and to set expectations for an on-site visit.

I am not a big fan of questionnaires.  I believe an on-site visit is critical to getting a good understanding of the technology. More recently I’ve been challenged to find a place to visit as many of the principals work remotely from themselves. I think it is important to meet the people face to face. My primary objective is to learn as much as I can about the technology as possible. My secondary objective is to meet the development team and form an option about their respective competencies. By its nature diligence is the process of looking for problems. Rarely do you come back from looking at a business thinking that you under estimated how good it is. On the other hand I can think of many occasions where I’ve come away blown away by the people – their technical acumen, tenacity, and single minded determination to make something work.

Picking who goes on-site is a particularly important consideration. I think the minimum number is two – one subject matter expert on the business and someone who is proficient with coding in the language of the business being acquired. (You do not want a .Net person doing a Ruby on Rails evaluation). If budget permits an IT person is a very nice to have resource. Their perspective often compliments that of the business and developers.

References:

• http://www.lannigan.org/due_diligence_checklist.htm
• http://www.astutediligence.com/Diligence_Checklists.htm
• http://www.cunacfocouncil.org/news/342.html
• http://www.techrepublic.com/article/the-art-of-technology-due-diligence/1038683
• http://stackoverflow.com/questions/814071/what-typically-takes-place-during-the-due-diligence-phase-of-an-acquisition-of-a

I regularly use all three mainstream browsers and have a pretty good sense of their strengths and weaknesses. I did a bunch of real-world testing trying various sites, configuring the layout of the browsers, and looking at different features. In the end, with the exception of things that matter only to a relatively small audience, I came away feeling that all three are all more than adequate for day-to-day business usage.

Internet Explorer

IE9 has come a very long way. Its predecessors were buggy, full of security problems, and lacked standards compliance. IE9 is a fine, feature rich browser. I mainly use IE to access internal sites based on SharePoint (to take advantage of the tight integration with the operating system) and to access email remotely via Outlook Web Access (using an ActiveX control). I don’t think IE is as good as either Chrome or Firefox (largely because of the lack of a rich extension / add-on marketplace) but the gap is rapidly closing.

Firefox

I am a long-time Firefox user; it has been my main browser for as long as I can remember. Initially I started using Firefox because IE was so problematic. Five years ago Firefox had unique and innovative features like tabs, extensions, and was much more secure than IE. What really hooked me on FF was the adblock plus extension. I cannot remember the last time I saw an ad in Firefox never mind clicked on one. Over the past year I’ve become more conscious of how long it takes for Firefox to start-up, load web pages, and how much memory it consumes. Part of my speed and memory problems are no doubt related to the extensions I have running.

Chrome

Over the past year I’ve started to use Chrome more and Firefox less. What first grabs you about Chrome is the out-of-the-box speed. The application loads nearly instantly, pages render quickly, and in general the application feels zippy. Chrome has many of the nice features of Firefox but without the bloat. Most importantly for me most (but not all) extensions I use regularly are now available for Chrome. The extensions I use are Adblock plus, autocopy, Firebug, Instapaper, LastPass, StumbleUpon, UserAgentSwitcher, and Xmarks. One really nice under the hood feature that is unique to Chrome is that you don’t need to restart the browser after installing an extension. The other thing I’ve noticed is that Chrome seems to do a good job of memory management and distributing applications into separate processes. In my unscientific test of IE, Firefox, and Chrome, IE uses the least amount of memory. On the other hand, IE doesn’t have the add-ons/extensions that Firefox and Chrome do so the test is not really fair.

Besides the inertia of switching from one browser to another, what has held me back from hopping on Chrome bandwagon is the overhead of learning its development tools. I’ve become very attached to Firebug which is Firefox specific and I fairly regularly use the UserAgentSwitcher add-on which is not available for Chrome. Interestingly John Barton, the lead firebug developer, has recently joinedthe Google Chrome team.

Summary

For the moment I am “stuck” using all three browsers. Stuck really isn’t the right word for it. Until IE gets a richer extension model I probably won’t be using it unless I have to. Unless something unexpected happens I do expect that that Chrome will become my everyday browser.

• · C or C++ if you work on an application where an interpreted language is not acceptable – performance intensive application (CPU or memory), security, hardware, etc.;
• · Java if you work for IBM, Sun, Salesforce.com, or some other big organization / platform that does not embrace Microsoft’s technology stack;
• · .Net (probably C#) if you work for a (typically mid-to-large) organization that embraces the Microsoft stack; 
• · Java if you write Android applications; Objective C if you write iPhone/iPad applications;
• · PHP, Perl, or Python if you write web applications on a LAMP platform that is more than 3 years old; or,
• · Ruby on Rails if you write web applications on a LAMP platform that is less than 3 years old.

If you code in something else you are in the minority.  This can be a dual edge sword.  The good is that you are by definition a specialist and can command higher compensation.  The downside is that there may not be demand for your particular skill. 

Platform as a Service

Platform as a Service (PaaS) service, a component of SaaS – where the hosting platform is moved to the cloud, is clearly maturing.  If an application takes off organizations now have multiple viable options for quickly adding capacity.  Amazon’s EC2 and Microsoft’s Azure are two of the more well known platforms.  For example, Mashable documents how mobile phone app Instagr.am went from 0 to 3M users in less than six months with EC2.

The concept of PaaS is somewhat game-changing for start-ups.  Essentially this means that you only need to invest in the computing power that you need at the moment.  Where 10 years ago a major component of the cost of starting a web business would be the data center, today you only pay for what you use.  If I were to boot-strap a company like Instagr.am I would start with a small number of physical servers in a low-end colo facility.  (See askwebhosting.com to see how cheaply this can be accomplished.)  Only once growth justified it would I move to EC2 (LAMP) or Azure (.Net).

I do believe that Azure is potentially game changing for Microsoft.  Prior to Azure you would never (and I do mean never) hear of start-ups using Microsoft’s technology.  At worst Microsoft’s development eco-system is as good as anything available in the LAMP stack – many people find it superior.  The problem was the cost of deploying Windows/SQL server was prohibitive for all but the largest organizations.  It will be interesting to see if Azure changes the equation.

Mobile

Today mobile application development requires you to be either a Hatfield or a McCoy.  You either are in the iPhone or the Android camp. Mobile application development is dominated by applications written in Objective C for Apple devices and Java for Android devices. I am aware of one cross platform tool Titanium.  While I have not used it personally I do not hear good things about it.  My sense is that you can get away with using Titanium if your mobile app is very straight-forward and / or doesn’t’ take advantage of any device specific functionality. 

Last summer I posted a link to TIOBE Software’s index of most popular programming languages. I went back and re-visited the numbers for this year and see only incremental change from a developer’s point of view. TIBOE update their rankings each month – this is the July report. They use data from Google, Bing, Yahoo!, Wikipedia, YouTube, and Baidu to calculate its ratings. I found another site langpop.com which uses a variety of different mechanisms to calculate popularity. Broadly speaking the two charts correlate. I like the TIOBE formatting and that they update their results each month.

Source: TIOBE Programming Community Index for July 2011

In addition to these languages listed above if you work on the web a professional software developers also needs know:

• · HTML, XML, JSON, JavaScript, and have rudimentary CSS knowledge (1)
• · Basic SQL skills – MySQL, SQL Server, or PL/SQL
• · JQuery JavaScript library
• · Implement AJAX in their respective language of choice

(1) Developers rarely have advanced CSS / Photoshop knowledge. Typically commercial designers are used for this type of work.

Source: LangPop Language Popularity Normalized Comparison – Updated April 13, 2011

Salesforce now has a very interesting collection of technologies – 4 families if you will:

• Tools for Sales– “Sales Cloud” – pipeline management and Jigsaw – leads
• Tools for the supporting Customers – “Remedyforce” – generic customer support and “Service Cloud” – help desk in the cloud
• Social – Chatter – Twitter for business and Radian6 – social network monitoring
• Platform as a Service (PaaS) – Force.com – applications for extending SFDC, Database.com – database in the cloud, Heroku – Ruby on Rails in the cloud

The tools for Sales and Support evolved organically from SFDC’s roots as a CRM company.  The PaaS applications, less Heroku, evolved from the platform that Salesforce built to support the CRM business.  The social stuff is all new and was the focus of much of Marc’s talk.

Social Enterprise

My sense is that it’s the social networking pieces that really excite Benioff personally.  Benioff paints a compelling vision of Salesforce.com (the company) becoming the engine of the social enterprise.  The argument in favor of becoming a social enterprise is based on how dominant social networking (read Facebook) has become to the consumer.  Indeed he asserted that more people are using social networks than email.  He used Facebook as an opportunity to cite McKinsey research on the consumerization of IT.  The key point is for the first time the technology consumers use in their personal lives is now driving enterprise IT strategy.  Today’s consumers expect to be able to interact with brands on their iPhones and via social networks.  Companies ignore this dynamic at their peril.  Indeed as seen in this video he is positioning his companyas the defacto expert in B-to-B social networks.  Chatter (enterprise Twitter) and Radian6 (social network monitoring) are Salesforce.com’s beachheads into the world of the Social Enterprise.

Platform as a Service

Using SFDC as a PaaS provider makes a ton of sense if your organization already has (or will have) a significant investment in their CRM products.  Its logical that Salesforce would make their PaaS offerings available for anyone to use, however, this is a crowded space with strong established offerings available from Amazon, Microsoft, and Google.  I am not sure I fully appreciate the Heroku tie in.

Disclaimer: I am a basically a Microsoft .Net guy but am a very big fan of Ruby on Rails.  I’ve written force.com applications and have done more than the prototypal hello world application in a bunch of languages including PHP, Ruby on Rails, and Java.  I’ve never been wild about the tools (Apex Code and Visualforce) that Salesforce gives you as a developer to natively integrate with their platform.  Apex code essentially allows developers to write stored procedures for the Salesforce.com database where Visualforce is a presentation layer language for their system.  Both of these languages have roots in Java and are based on the model view controller (MVC) design pattern.  My basic problem with the SFDC languages is that they are SFDC specific and there is a learning curve with any new language.  (There is amazing developer support for just about any language you can imagine to interface with SFDC but only applications written in Visualforce or Apex can run on the SFDC servers.)  If you talk to the CRM folks they will tell you that this specialization was needed to achieve the kind of performance and deep integration they wanted.  At the time that these tools were announced I wondered why they couldn’t do what they wanted with Java.  Now SFDC buys Heroku which allows you to run Ruby on Rails in the Cloud.  Ruby on Rails is another MVC-based application and is the “hot” open source language.  How amazing would it be if you could write a force.com application that would run on the SFDC servers in RoR.

Some amusing quips from Cloudforce

• Beware of the false cloud – a cloud is not real if it is not public
• SharePoint is like your grandfather’s attic – what I put in I can never find

This is a huge leap of faith. While I am not an investment analyst and haven’t studied Netflix’s proxy statements I am a customer. From what I can see Netflix is slowly walking away from the DVD in the mail business and moving to the video on demand model. The old way of doing business would have said that ‘our web presence is too core to our business to outsource to a third party’.

This is a tremendous vote of confidence for Amazon. I am sure that Netflix did not go into this partnership with Amazon without thorough due diligence. In this business there is no one-size fits all model and “your mileage will vary,” however, I interpret Netflix’s decision as a statement that the Amazon cloud is ready for primetime. I’ve heard this same message from other people that I know as well.

There was a Window of opportunity. According to the Netflix post they “needed to re-architect” anyhow so the timing apparently worked out to optimize their software to integrate into AWS.

The cost equation is starting to make sense. Every time I’ve looked at AWS I’ve come away thinking that it’s really expensive. A friend of mine observed the following: “they (Netflix) are large enough that they could probably save millions by building it themselves.  However, there would be opportunity cost of putting some of their best people onto scalability instead of feature development.”

AWS is no silver bullet. There are stories out there like Instagram which over night explodes to 1M users. The only way a product like that could have possibly scaled to accommodate that much traffic is with a solution like AWS/EC2. That said, committing an existing business to a cloud-based solution is very much a strategic decision and requires management commitment.

I think about AWS as the established incumbent in the space. They aren’t by any means the only serious player.  I’ve heard good things about Rackspace’s CloudServer offering, and that Windows Azure is an increasingly interesting technology that will be very meaningful – particularly to folks that write code using the Microsoft stack.

Its hard to say how long I’ve been a Yahoo customer but I have to be in one of their first group of users.  I worked at competitive web portal (PlanetDirect.com which became MyWay.com) between 1996 and 2000.  During that period of time I started using Yahoo mail and MyYahoo.  I’ve been a Premium customer (i.e., paid subscriber) for at least the last five years.

While Yahoo may yet pull out of its tailspin and wake up someday as a profitable media company they are not committed to improving the things I care about.  To that end I’ve spent the weekend moving my virtual self from Yahoo to Google. 

Two years ago I moved our family calendar from Yahoo to Google Calendar because the user experience was so much better.  I’ve resisted moving my primary email to gmail because I’ve had my Yahoo account for so long.  The time is now to cut the cord.

Here is my quick and dirty chart of what switching from Yahoo looks like.

Yahoo clearly believes that their future is as a content company.  They have a pile of properties that I don’t use or frankly care much about including news, sports, gossip, fashion, job, finance, etc.  There are obviously many good alternatives for this type of content.