In the Spotlight - Josh Holmes

One of the things that I've missed during my tenure here at Microsoft is speaking at some of the independent national conferences such as VSLive. But if you look through the speaker's list at VSLive Dallas you'll find a fellow named Josh Holmes... Woot!

I've actually got 4 talks and I'm sitting in on the ALT.NET panel on Tuesday night.

Definitely come out and see us - Register online or call 800-280-6218 using Priority Code SPHOL and receive $300 off the package of your choice.

DW10 IronRuby and Silverlight, Like Peanut Butter and Chocolate
Josh Holmes
Wednesday, December 10 – 1:45 p.m.
As the DLR (Dynamic Language Runtime) and IronRuby become more polished, it's time to start applying those technologies in new and interesting ways. One of my favorites is in a Rich Internet Application with a Silverlight front end. A perfect joining of two great technologies – IronRuby brings the dynamic abilities to your code that XAML gives your UI. From animations to logic to simple HTML DOM manipulation - it's all possible and a lot of fun. In this session, we will cover the basics of the DLR, a touch of Ruby and play with it all in the context of Silverlight.

DW16 User Experience for Architects: No Longer Optional
Josh Holmes
Wednesday, December 10 – 3:15 p.m.
The user experience is a core part of new applications and those with the best user experience will prevail. When I say user experience, most people think of the graphics and the front end. This, however, is just the lipstick on the application and considered "small d" design. The "big D" Design starts well before the UI layer and can have profound implications on your application architecture. Is it a SaaS application? Or is that one of many front ends? How does that impact your services strategy? How does the information flow impact your database structure? These and hundred more questions are all ways that the user experience decisions can affect the architecture.
In this session, we will cover a primer on user experience for the architect and discuss the various ways that it will affect your application architecture.

DTH6 Mashups from the Ground Up
Josh Holmes
Thursday, December 11 – 9:45 a.m.
When building a Mashup, there are a lot of choices that come into play. Most people they with choosing the UI technologies that are going to be used, but they are wrong. They should be thinking about the information that is going to be used and how to get to that data. Mashups are about exposing new and interesting looks at data so the first thing that you have to do is figure out how to get to that data. Only after that do you start looking at the various front end technologies from AJAX to Silverlight to any number of other Rich Internet Platforms.
In this session, we will compare and contrast building out SOAP services verses REST services with ASMX, WCF and ADO.NET Data Services. We will demonstrate consuming those various services with AJAX, Live Maps, Silverlight and many more front end technologies.

DTH10 Best and Worst Practices for Building Silverlight Applications
Josh Holmes
Thursday, December 11 – 1:45 p.m.
Silverlight, as it's relatively new to much of the community, is putting people through some bumps and bruises as they create amazing experiences for their users. There are a lot of best and worst practices that are starting to emerge as the platform matures and more and more applications are being written. How and where to keep the state management? What networking stacks make the most sense? When does it make sense to use Silverlight or any Rich Internet Application (RIA) platform?
In this session, we will give a cursory overview of what it takes to build a RIA and dive deep into the best and worst practices with Silverlight.

VSLive! Dallas 2008

It's an exciting time here at Microsoft. Last week we announced Microsoft BizSpark!

Microsoft BizSpark is a global program designed to accelerate the success of early stage Startups. Microsoft has realized that most startups have more time than money. This means that in an attempt to save some cash up front, many will pursue free technology paths rather than spending the money on a more complete solution. The issue is that even though they have more money than time, if they don't get to revenue quickly, they will fail. To help out here, Microsoft has taken cost off the table as an issue for the startups adopting any of the Microsoft technologies in their products and offerings.

I'll get to the details of the software offering in a moment. But first I want to point out that this is not just cheap software. There are three key areas that Microsoft has identified where it can help startups. Startups need, in addition to the technology, support and marketing. This is accomplished in a couple of different ways. BizSpark Startups receive professional support from Microsoft as well as community-driven support from Network Partners, active organizations in the entrepreneurial space, who can provide guidance, mentorship and resources to Startups.

By virtue of their participation in BizSpark, Startups can also gain visibility with potential investors, partners and customers.

BizSpark provides software, support and visibility to high-potential Startups:

Software

• All the software included in the Visual Studio Team System Team Suite (VSTS) with MSDN Premium subscription Expression Studio (Version 2), plus VSTS Team Foundation Server Standard Edition - for the entire development team
• Production license use rights, to deploy, host and support Startup’s "software as a service" applications for delivery over the Internet, using the following products: Windows Server (all versions), SQL Server (all versions), BizTalk Server, and Office SharePoint Server for hosting; and Systems Center for managing hosting server operations.

Support

• Guidance, resources and mentoring provided by Network Partners, active members of the global software ecosystem who are qualified to provide support and advice to Startups
• Access to MSDN Premium: managed newsgroups, online library, online concierge, etc.
• Two technical support Incidents per Startup

Visibility

• Each BizSpark Startup will have the opportunity to profile their company in the BizSparkDB, an online Startup directory, hosted on the Microsoft Startup Zone web site. Startups will get exposure to potential investors, partners and customers around the world.
• Opportunity to be highlighted on the BizSparkDB as a featured company and be promoted as BizSpark Company of the Week on the Microsoft Startup Zone website.

Costs - on exit of the program (read three years after you sign up), the participants will be invoiced a $100.00 fee. This means that there are no up front costs for the startups.

Who's Eligible?

An eligible Startup must have the following characteristics at the time of joining:

• Actively engaged in development of a software-based product or service that will form a core piece of its current or intended business. This means that the startup must be producing software or services as the means to them getting paid. Either selling or leasing the software and/or service.
• Privately held.
• In business for less than 3 years.
• Less than US $1 million in annual revenue. This varies slightly by country but here in the US it's $1 Million.

To be eligible for Production License rights, Startups must also be developing a "software as a service" solution (on any platform) to be delivered over the Internet.

Examples:

Does Quality:

• An Independent Software Vendor (ISV) that is producing software for sale.
• Producing a service such as a claims processing services that you lease to other companies so that they can outsources their claims management.
• A combination application that sits on the clients machine and calls services that you have produced with any form of monitization be it leasing or for sale to third parties.

Does Not Qualify:

• If you are developing an internal claims processing system solely for your own company.
• Developing a web site for your company as your marketing presence.
• Are a pure consulting agency with no products.

To break it down, if you are getting paid through the software and/or service that you are producing then you probably quality.

If you think you are qualified and are interested in signing up - Anand Iyer has a great walk-through that explains how to sign up at http://tr.im/joinbizspark. 

Network Partners

Our Network Partners consist of University Incubators, Government Agencies, Entrepreneur Organizations (incubators, business angels,…) and Investors themselves depending on the volume of startups that they deal with. These Network Partners are able to offer a lot of services to the startups than Microsoft ever could because they are in the trenches and offer a lot of different services.

Depending on the network partner, some of the services could include office space, access to funding sources, introductions to potential clients, legal advice, business plan mentoring and tons of other support.

If you are interested in joining BizSpark, you can do so easily by contacting one of our network partners. Or you can contact me and I'll get you in touch with a local network partner that can help you out.

If you are interested in being a Network Partner, sign up online or reach out to me.

One of my first Network Partners, who actually offers almost all of the services listed above, is TechTown. TechTown, Detroit’s research and technology park, was established in 2000 when Wayne State University, General Motors and the Henry Ford Health System convened to create an engine of economic growth with both local and statewide impact. TechTown stimulates job growth and small-business creation by developing companies in emerging high-technology industries including advanced engineering, life sciences and alternative energy.

TechTown is a 501(c)(3) non-profit organization and is the Woodward Technology Corridor SmartZone.

In the years since its inception, TechTown has developed into an epicenter of high-tech business creation by equipping new companies with the services, support and resources they need to grow and thrive. The 12-block park is poised to become a critical source of job growth in Michigan.

Highlights:

• TechOne, the 100,000-square-foot business incubator facility, now hosts 40 growing companies.
• More than 30 high-tech startups have enrolled in TechTown’s business accelerator programs.
• NextEnergy, an alternative energy incubator founded to encourage the commercialization of emerging energy technologies, opened its $12 million research facility in TechTown.
• Asterand, a biomaterials bank and TechTown’s first tenant, has become an international, publicly traded company on the London Stock Exchange.

TechTown Detroit

SRT Solutions 

Microsoft BizSpark

We've got a fantastic opportunity for you here in the Heartland district. Visual Studio 2010 is the next generation of tools for building .NET applications of all varieties. One of the things that we are taking to heart is testability and testing tools. You can come meet the guy that's in charge of building all of those tools. Do you want to know how they test the testing tools? Do you want to know how to use those tools to the best of your abilities? Do you have any questions at all? Come meet Mark Mydland!

Mark Mydland is the Principal Group Manager of the Visual Studio Team System Test Edition team (that means that all program managers, developers, and testers on VSTS Test in Redmond report up to him).  He is touring through Michigan, Ohio, Kentucky, and Tennessee for a short time in November.  Mark will be visiting companies during the day and speaking at user groups in the evenings.  The user group talks are open to the public - this is a fabulous opportunity to speak directly with someone who created Visual Studio (and in fact runs the entire Test Edition team). 

At the user groups, Mark will be delivering a technical talk on the new features coming in VSTS 2010, codenamed "Rosario".  This talk encompasses "some architect stuff, some dev stuff, some cool research stuff for concurrency and for bounds checking, 3-tier execution and data recording (aka Tivo for debugging)."  I purposely planned this tour to take place after PDC so Mark can discuss any new announcements made there. 

This is also his team's work: http://news.cnet.com/8301-13860_3-10052412-56.html?part=rss&subj=news&tag=2547-1_3-0-20.  Cool, huh? 

Want a preview of VSTS 2010?  Mark is doing a number of user group talks that are open to the public.  And did I mention that there will be free dinner and giveaways?  Please stop by:

Grand Rapids, MI - Tues 11/11 at 6pm
Watermark Country Club, 5500 Cascade Rd, Grand Rapids, MI 49548

Ann Arbor, MI - Wed 11/12 at 6pm
SRT Solutions, 206 S. Fifth Avenue, Suite 200, Ann Arbor, MI 48104

Cleveland, OH - Thurs 11/13 at 6:30pm
Sogeti office, Beacon Place Office Building, 6055 Rockside Woods Blvd, Independence, OH 44131

Columbus, OH - Fri 11/14 at 6pm
Microsoft "Polaris Parkway" office, 8800 Lyra Dr, Columbus, OH 43240

Cincinnati, OH - Mon 11/17 at 6pm
MAX Training, 4900 Parkway Dr, Suite 160, Mason, OH 45040-8429

Louisville, KY - Tues 11/18 at 6:30pm
Muhammad Ali Center, One Muhammad Ali Plaza, 144 N. Sixth Street, Louisville, KY 40202

Nashville, TN - Wed 11/19 at 6pm
Microsoft Nashville office, MPR room, 2555 Meridian Blvd, Suite 300, Franklin, TN 37067

Memphis, TN - Thurs 11/20 at 6pm
New Horizons, 4775 American Way, Memphis, TN 38118

Knoxville, TN - Fri 11/21 at 6pm
Edfinancial Training Center, 120 North Seven Oaks Dr., Knoxville, TN 37922

For all the updates along the way - make sure you watch Jennifer Marsman's blog at Meet the Principal Group Manager of VSTS Test!

I've been a long time supporter of PreEmptive Solutions. They've done a great job of supporting .NET. As a Cleveland based company, they are in my territory as an evangelist.

Microsoft just released a huge press release on the new things that PreEmptive is doing - specifically, they are expanding well beyond obfuscation to anti-tampering, run time intelligence, licensing support for ISVs and much much more.

PreEmptive is no longer just an obfuscation company.

Read the official press release below...  

Microsoft and PreEmptive Solutions to Provide Application Feature Monitoring, Usage Expiry and Tamper Defense in Visual Studio 2010

Post-build utility utilizes software plus services and instrumentation to improve application security, portfolio management and usability.

LOS ANGELES — Oct. 27, 2008 — Microsoft Corp. and PreEmptive Solutions announced today at Microsoft’s Professional Developers Conference 2008 that an enhanced version of Dotfuscator Community Edition™ (CE) will be included in Microsoft Visual Studio 2010. Dotfuscator CE, which has been included with every version of Visual Studio starting with Visual Studio 2003, prevents the reverse engineering of .NET applications. The Visual Studio 2010 version, renamed Dotfuscator Software Services Community Edition™, has been extended with instrumentation capabilities including tamper detection and defense, feature level application monitoring and automatic time limits on .NET application use.

“Instrumentation is an important component of good software development practices as part of an overall application lifecycle management (ALM) approach. Microsoft knows that extending the ability to modify an application’s behavior to the time after compile is a valuable part of good ALM practices,” said Norman Guadagno, the director of product management for Visual Studio Team System at Microsoft Corp. “.NET developers can now protect, manage and increase the value of their application development investments easily and without having to write additional code.”

Development teams will be able to track feature usage to improve adoption and quality, ISVs will be able to integrate evaluation software usage into Microsoft Dynamics CRM to increase win rates, and enterprises will be able to integrate application runtime data into Microsoft Business Intelligence Solutions to improve business agility.

Dotfuscator Software Services CE also has enhanced capabilities to stream alerts and runtime data to one or more cloud-based services.

“Dotfuscator’s ability to integrate application behavior with one or more cloud services not only improves application quality and value, it actually creates new business opportunities for software service providers and developers alike,” said Gabriel Torok, president of PreEmptive Solutions.

Dotfuscator Software Services Community Edition is scheduled to ship with all versions of Visual Studio 2010 (other than Visual Studio Express) at no additional charge.

About PreEmptive Solutions

PreEmptive Solutions produces the Dotfuscator and DashO instrumentation and obfuscation product families and the Runtime Intelligence application analytics service. With more than 3,000 corporate clients, 40,000 registered installations in 100+ countries and inclusion with Microsoft’s 6,000,000+ Visual Studio seats, PreEmptive Solutions has become the clear choice for every organization that is serious about source code protection, application security and IT governance. To learn more, e-mail solutions@preemptive.com or call +1 216 732 5895.

About Microsoft

Founded in 1975, Microsoft (Nasdaq “MSFT”) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft Web page at http://www.microsoft.com/presspass on Microsoft’s corporate information pages. Web links, telephone numbers and titles were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may contact Microsoft’s Rapid Response Team or other appropriate contacts listed at http://www.microsoft.com/presspass/contactpr.mspx.

More links:

Official Press Release
http://www.microsoft.com/Presspass/press/2008/oct08/10-27PreEmptivePR.mspx

http://www.sdtimes.com/content/article.aspx?ArticleID=33003

http://dotnet.sys-con.com/node/725076

I did a joint session with James Ward from Adobe at the JAOO conference. As you know I'm an evangelist for Microsoft focusing on RIA and UX. James is one of the Flex evangelists for Adobe.

This is a talk that James and I have been talking about trying to pull off for quite a while and I was thrilled that we actually got to do it. James and I have been going back and forth for over a year and a half now talking about the definition of RIA as well as what are the best and worst architectural patterns. Some of this was based on an article that James co-wrote for InfoQ called “Top 10 Mistakes when building Flex Applications”. I borrowed the mistakes that applied across the board regardless of what RIA technology you were using and added the best practices part.

The first time that I delivered a version of this session it was with Mike Labriola at RIAPalooza.

James and I both welcome emails and contact - email addresses in the slide. You can also comment on the blog. We'll both be watching the comments here.

The first question that we have to ask ourselves is - what do we mean by RIA?

The acronym could mean anything.
It could be the Rural Inoculation Association whose out there in the world trying to immunize all of the cows and chickens in the world.
If could be the Rare Isotope Accelerator - you know, the one in Switzerland that didn't end the world... Yeah - I'm thrilled about that.
All the way down to Really Inane Acronym - which is the one I often go with.

But in this session we're talking about RIA as Rich Internet Applications. This means that we are not talking about simple media players or fancy splash screens or advertisements. We are talking about solid enterprise quality applications that leverage the Internet as a deployment model and typically are built on one of the Rich Internet platforms such as Silverlight or Flash. These are meant to enhance the user's experience and if you do a good job with design, you will dramatically improve the usability of the application. This is what James and I are both passionate about.

Before you decide that you need to build a RIA, you need to first think about your users and how they are going to use the application. This will help determine where on the continuum of user experience you should target and what type of application you should write.

On the far left hand side, if you are going for absolute ubiquitous reach and need to have information in front of the widest possible audience, text over http is the lowest common denominator. HTML and CSS will still have a long and prosperous life on this end of the spectrum.

On the far right hand side, the guys that were writing Halo for the XBox 360 were able to test the exact hardware, right down to how fast the hard drive spins and which exact video card was in the machine. This means that they are able to make trade offs between how large a map is and what textures are on the walls and so on. This is a huge advantage when trying to create a really rich experience for the users.

However, most people don't have the luxury of shipping hardware with their software. But can you target a desktop application on a given operating system? Or a family of operating systems?

If you can't, then you need to start looking at this supplemented web space that we are talking about with RIA.

So what's different with this RIA development. Really it depends on the skill set of your team. The interesting part is that it's actually a much tougher jump for web developers than desktop developers.

For desktop developers, there are a number of things that they have to get used to. For example they are locked into a secured browser based sandbox. This means that they can't do a lot of the things that they are used to doing such as reading and writing anywhere on the hard drive, reading from the registry, accessing local hardware or any number of other typical tasks that desktop developers do.
The back and the refresh button are also quite scary to the desktop developer. Conceptually, you can think of it as opening up the task manager and killing your application. Oops. The question is what do you do when someone does that? There are a lot of different strategies that you can leverage but the point is that you do have to think very clearly about this potential issue.
State management is also an issue that we have to think about more. On the desktop, it's natural to just have your state locally. But in this RIA space, what do your users expect if they open up a browser on a second machine? hmmm. You might need to store your state on the server side.
And typically you have a more limited runtime in the browser than you do on the full desktop. For example, the full .NET runtime is about 50 meg and Silverlight is just 4 meg. That's quite a difference.

However, none of these issues are fundamental shifts in how you think or go about doing your job.

For web developers, on the other hand, there are some serious mind shifts that have to happen. We are used to, as web developers, having everything from the server on hand at any given time. The UI itself is simply rendered HTML. All of the logic and work happens on the server. Often, this happens in a single tier.

Now that we are looking at the RIA space, we have to think about where the business logic goes. Sometimes that's on the UI side running in the browser. Fundamentally this means the web developer needs to understand service oriented architecture. This is a big change from what we are used to where we could, if we so desired, open up a database connection and query directly from the UI logic layer. Instead, our UI logic is happening out in the browser where they don't have access to do that through the firewall etcetera.

Ron Jacobs talks about a lot of the possible issues in a set of talks called SOA Patterns that can be found
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Patterns-and-Anti-Patterns-for-SOA-Applied/ and
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Patterns-and-Anti-Patterns-for-SOA-Part-2-of-2/

For example many people look at mapping their database directly to their web service tier. This is the anti-pattern that Ron calls the CRUDy web service layer. Really, you are not service orienting your application. Rather, you are simply exposing the database tier out to the rest of the world.

Once you get over this hump, the rest of the changes are relatively small in comparison.

Onto the best practices... We have laid out 10 best practices here. These are not by far the only solid practices. These just happen to be the 10 that James and I thought were in the top 10 that are across the board regardless if what RIA platform you are using.

 

Those couches, no matter how pretty they are, are not amazingly comfortable. The primary point here is that your application has to be functional and usable or nobody will use it regardless of how pretty it is or what technologies you are using.

The easiest way to make sure that you are building a functional application is to focus on the architecture.

This is a picture of from Taliesin West, Frank Lloyd Write's winter home in Arizona. He spent a lot of time working on the overall architecture of the building and the looks of the building. 

However, he spent almost as much time on the inside. He built much of the furniture, designed the lighting, the flow of the rooms, the acoustics and much more.

The lesson that we can learn from this is that we should spend as much time on the inside of our application and the architecture of the client side as we do on the overall application. You really need to apply a lot of rigor to the architecture of the client side as well as the overall application.

There are two client side architectural patterns that are the front runners that we should talk about.

First in the MVC or Model, View, Controller pattern. The idea here is that you have three separate layers with very distinctive roles.

The model is the first layer that we need to talk about. It reflects your web service layer, not the database but what's returned from the services. This is the only access layer to the services and hides away the details of which services, protocols, security and other details from the other layers.

The second layer to talk about is the controller. This is the logic. It makes the decisions as to which view is shown, what data is changed in the model and so on. It watches what's going on in the view for various events and responds to those events by making updates in the model.

The third layer is the view. Often, there are multiple views for a given controller. For example, there might be a complex and a simplistic rendering of a given item from the model. The view is very thin as far as logic goes. It watches the model for changes and updates itself based on those changes. Those changes are either the result of logic in the controller or from a web service call. Often, in Silverlight, WPF or even Winforms, this watching for changes in the model is often implemented as data-binding. As it's data-bound to objects, the view can decide on what attributes of the object it wants to show.

The second pattern to talk about is the MVP or Model, View, Presenter pattern.

The first layer, the model, is actually very similar.

The second layer is the presenter. One of the big differences here is that the presenter actually updates the view with the changes from the model rather than the view watching for those changes. The result here is two fold. First the view are much closer tied together. The second is that, since the presenter is doing all of the input and output, it's easier to unit test.

The last layer, the view, is much thinner then in the MVC pattern. It's simply a presentation of the data that the presenter has chosen to show.

I personally prefer the MVC pattern. I don't thing that the extra testability that you get out of the MVP is not worth the loss in flexibility in the view. Unit testing is still quite possible in MVC and definitely should be part of the process.

The second best practice is that you should have a set of design tenets that the team shares. Really these are values that should be held by the designers, developers and all of the stake holders. This has to be agreed on by the team at the beginning of the project. I actually like to do two. One for the UI layer and the second for the overall development process of the application. For example, in the UI layer, Search is Failure. This means that if the user has to hit search in order to find something on your web site in the course of normal navigation - you failed in the design and navigation of the application. On the development side, think about TDD or Test Driven Development as one of the tenets that you hold.

The third best practice is to use the appropriate level of fidelity for the user's context. There are couple of things to talk about here.

The first is when you are developing a prototype. If you bring in an amazingly beautiful wire framed application with a ton of colors and full animations the user is going to do one of two things. Either they are going to argue with you over the exact shade of red or some other little detail without really getting through the functionality of the application or they will say - cool, you're done. It's really hard to explain to a non-technical person the difference between a good looking prototype and a a finished application and why it's going to take 9 months to make that leap.

The answer to this is to use a set of printed mockups for the look and feel and a skin such as ProtoXAML for the running prototype so that you can work through the functionality without getting into the arguments about look and feel. 

The second item to talk about with regards to fidelity is the forest for the trees. This means understanding the user's context and only showing them the data that they need in that context. For example, if you are dealing with a C level executive you shouldn't show them how much it costs for a particular pencil. Instead, you should only show them how much it costs for office supplies in general. If the want to dive into that detail, then you should let them dive into that level of detail. Another thing to think about is what should be on a dashboard verses in the full application or report.

The fourth best practice is to build with both the customer and user's input. Step one here is to recognize that these are indeed separate people. The customer is the one who is signing the checks. Often this is some layer of management far removed from the actual day to day operations that the users are doing. The users are the ones that are actually going to be using your application and getting upset with you about the things that don't work the way that they want.

This is one of the central themes in most agile methodologies. Most actually want to have one of the users on the development team sitting in the meetings and providing input the entire time.

The fifth best practice is to understand who your users are and what type of users you have. For example if you have a public facing web site, you'll have something like the curve in the slide with some large percentage of your users being first time visitors to your site, some smaller percentage being repeat visitors and some really small percentage being your power users.

Your goal should be to turn those brand new to the site into repeat visitors and then into power users. For those that are brand new to the site, you need to explain what your web site does and why they want to come back. One the other end, the power users shouldn't be bothered by that introductory information that you present to the new visitors. A couple of sites that do this really well are WordPress and Twitter.

Sixth is planning for concurrency. Concurrency is always an issue in application development, it's just highlighted in RIAs as the client is running somewhere on the network or across the Internet in the client's browser.

The fun issue is with concurreny is that it's hard to test for in development because typically the developer has their own dev environment and/or a database full of junk test data. This makes it hard to spot concurrency issues. Instead they find these issues in training when the trainer asks the 30 students to open up Mr. Jones and change his address and save. At that point, what happens? Which of the users actually saved the new address successfully?

There are two basic forms of concurrency. Optimistic and Pessimistic.

Pessimistic includes locking down the rows that you are accessing until you are finished with them. It really isn't a consideration in RIA as you don't have a long running transaction with an open connection to the database.

However, simple last in wins optimistic concurrency is really not concurrency either. You need to think through the various scenarios and understand where you need to detect that there was a change and then decide on what to do with that change. In order to detect that there was a change, the traditional strategies are to either pass both the original version of the data that you retrieved in the first place as well as the changes or to use a timestamp of some sort. As far as what to do with the change, you might be able to perform logic to make the determination on what to do such as if there is an addition or subtraction of some numerical amount. Most of the time, however, you need to raise awareness to the user that there was a change and have them decide what to do. Other times you need to think about doing some type of escalation to a manager. Obviously that requires more development and thought but it's worth the time.

The seventh best practice is balancing the computing load. Think about the fact that you've got the ability to do a lot of logic client side and you can offload the computing load on the server that way. However, there's still a lot of good reasons to keep the logic server side. The question is what's the decision tree on where the logic should run. My preference is to keep the operations as close to the data as possible. If most or all all of the data that you need is client side, there's no reason to burn the extra network traffic and time waiting on the the round trip. On the other hand, if the majority of the data is server side and you can process the data and just return the results of the processing - do that.

Security is a huge issue and really hard to get right. If you make it too tough, people will find ways around it or stop using your application all together.

Both Silverlight and Flash have security protocols around calling web services. It's based on the domain that your application was loaded from and what domain the application is trying to call the service on. If you were loaded from the domain you're trying to call then there are no security issues. The domain is defined as the combination of the domain name (including sub domain such as www), protocol (http or https) and port (such as 80 or 8080). If any one of these are different, then it's considered a cross domain call. That means that http://www.somedomain.com is different from http://somedomain.com and http://somedomain.com is different from http://somdomain.com:8080. The reason behind this is that any of those variables, sub domain, port or protocol could point to different servers. That possibility of changing servers is considered a cross domain call and more security kicks in.

The reason that this matters is that when the application makes that call, all of the cookies for the domain that you are trying to call are passed along with the call. This is not an issue if you are calling a server that doesn't have private information such as the public web services on Flickr or book searches on Amazon and the like. However, this is a huge issue if the application can call some outside domain that does have private information, such as Paypal or your hospital or some other server that has sensitive information, and pretend to be you by passing in those cookies.

Since it's the server that knows whether or not it holds sensitive data, the server gets to decide if it is going to allow that call. The method for doing that is a policy file. The Adobe version of this file is the crossdomain.xml and the Microsoft version is called the clientaccesspolicy.xml though Silverlight will leverage the crossdomain.xml file if it doesn't find the clientaccesspolicy.xml file. In these policy files the server can specify which domains, from all down to a very specific one, are able to call which services.

The quick dos and don'ts for your server that you're expecting RIA applications are divided into private services that your own applications are going to call and public services that you are opening up to third party applications to call.

For private services:
Do use browser-based authentication through cookies, HTTP Auth and so on. This will allow your application to leverage the existing authentication methods that you are using with the rest of your web applications. This is a big win.
Do not, since these are private services that are using browser based authentication, enable public access via a cross-domain policy file of any sort.

For public services:
Do not use browser-based authentication. You can either just open up anonymous access or pass in the credentials on each of the service calls and use more traditional authentication methods from the SOA world.
Check on the calling application's URL and other authentication techniques.
And definitely separate out the public from private services into different domains but at least subdomain or something.

If you've not spent any time in a support center answering calls from irate users, you should. It will change you're outlook on writing software, logging, bug reporting and more. Now, let's have the application running out there in a browser in a secured sandbox so that you're users don't have direct access to any log fine and the issues that they might run into could be network issues and you wouldn't able to log errors on the server side.

Do you see the problem? 

One technique to deal with this is to code for a parameter that the user can pass in on the url that will bring up an error console that the user can read back to you. For the error log, you can store the errors in a cookie or local storage.

The point is that you need to think long and hard about supportability and what could possibly go wrong and how to handle it.

Very importantly, you have to keep your user's context in mind. Are they mobile? Disabled? What role do they play? How are they going to be using your application? What's the minimum data that they need to accomplish their duties?

By remembering your user's context you can build the most effective application for them in their unique situation.

I'd love to hear about best practices that you've uncovered in your work as a RIA designer, developer and architect.

I learn best from my failures and the best practices wouldn't be best practices if there weren't worst practices. As such, I don't think that any best practices talk is complete without addressing the possible worst practices.

The first possible worst practice when creating a rich internet application creating a rich internet application in the first place. You shouldn't use 2.0 technologies to build a 1.0 web site. HTML, CSS and light javascript can go a really long ways in creating a beautiful site that's rich with information. You have to think about the user's interactivity and context when picking the technologies that you're using. We are all guilty of finding a slick technology and picking it as our hammer going around making every problem a nail.

Many RIA applications forget about the page refresh and back button. By default, when the user hits refresh, the application unloads, reloads and starts over from the beginning forcing the user to navigate back to the where they were in the first place. By default when the user hits the back button, the page with the application in it is unloaded as the browser goes back in the history to the previous page. In either case, this is probably not what the user expected.

If they were using a traditional HTML based web application the refresh would simply reload the page that they are on. If there was a postback involved, it will even offer the user the possibility to repost those variables to get the same result again. You can, if you write code to handle it in the unload and load of the application write out the state on unload and recreate the state on load.

For the back button, things are little bit more complicated. One way you can handle this is to build a state machine that tracks the logical pages in your application such as the pages in a wizard. Then you can trap the back button event and unwind the state machine. If you are at the beginning of the application, let the event go and act as normal.

The first thing that a lot of people think of when they start thinking about those challenges with regards to the back and refresh button is to simply disable them rather than going through all of the effort of handling them. This is a choice but if breaks the way that users expect to browse on the web so doing do it.

Ignoring your bandwidth is another large mistake that people make. There are a couple of different ways that this happens.

To start off, you need to think about the size of your application and how that will effect load times. A lot of desktop applications are many meg in size. This is fine since you are not having to download the application to run it over and over again. If this is the case with your right internet application, you need to think about partitioning your application to optimize load times. The simplest example here is to make sure that you don't embed assets such as videos or images inside your application unless you absolutely need them on startup.

More advanced techniques include partitioning the application itself into multiple easily digestible parts.

The second thing to thing about is video streaming if you are using video.

One more area for concern is the amount of data that you are pulling back at one time. There are a lot of different paging techniques that you can employ with easily implemented patterns.

There are good ways and bad ways to leverage animations. Many times there is gratuitous animation that have been thrown in just because they can.

The good is when a particular animation helps the user visualize data in a unique way or leads the user to the next action. For example, you can, when all required fields are filled in, add a shimmer behind the "next" button to draw the user's eye to guide them along the way.

Another example of good use of animation is showing transitions in state or data. As Mike Labriola put it, if your user rolls a ball and it just disappears as it leaves their hand and appears across the room, they would be very surprised. By showing the state transforming through animation, you can show your user what happened.

We, as developers, are infamous for NIH (Not Invented Here). There are, even with a limited framework, a tremendous amount of utilities in the framework that you don't have to reimplement. There are a lot of possible issues with not leveraging the framework that you're running on. First, you have to maintain it. But the other issue that is more unique to the RIA world is that the user has to download this code when they run your application. This bloats the application and contributes to the other worst practice that we already talked about with ignoring your bandwidth.

Cowboy development is always a worst practice. The problem is that there are times that people get away with it. And that makes them bolder and bolder. "It's just two lines of code. A tweak really. I'll just make that on the production server." Tweaks have brought down more servers than major production roll-outs. The major changes have been through testing and QA and all sorts of engineering rigor. The tweaks has at best been reviewed by the guy sitting in the next cube.

With RIAs, we are building real production applications and we need to apply the same disciplines that we should for any other application development. That includes Source Control, Change Control, Bug Tracking, solid development processes, TDD, Continuous Integration and the whole kit and caboodle.

In laying out the application's interface, it's really easy to get carried away with the number of containers to control the exact positioning of the items on the screen. In the HTML world, we did this with tables until we were all told that tables were evil. The answer was to switch to divs and put divs inside of divs and so on. This proved not to be any better. The real answer was to use CSS to set the relative positioning of the items.

The same idea applies in the RIA technologies. The more containers that you use to create your layout, the more constricted it will be. 

If you have a really complex rendering of a given item, that's not necessarily a bad thing. However, if you take that same item and databind a thousand of them into list - now you have a problem.

Getting religious about your technology decisions is a really common and really horrible practice. You should evaluate the possible technologies on their technical merits rather than on feeling, personal biases or any other non-technical method.

Instead you have to determine if the technology will actually do what you need for it to do, what your team make up is and if they will be able to leverage the technologies, if the IT department will be able to support the roll out of the application and all of the other technical merits of the chosen platform, technology and so on.

This is the point in the talk where James Ward (remember that he's from Adobe and I'm from Microsoft) came over and hugged me on stage!

I'd also like to, just as I asked for your best practices, hear from you about worst practices that you've found over time.

Rich Internet Applications are meant to enhance the users experience. Poorly designed applications don't accomplish this goal. Furthermore, we're probably going to face a period where we have a lot of "Silverlight Blink" so called for the HTML Blink tag that annoyed us all for so long. We all need to champion user centered design to ensure that we are building the applications that will help, not hurt, the user.

The architecture of the client matters, especially now, as much as the overall client. It helps with testability, maintenance, flexibility, changes and a ton more.

These are real applications and should be built following the best development practices. This includes all of the engineering rigor that any enterprise quality application is built with. This includes change control, feature and bug tracking, TDD, continuous integration and the whole ball of wax.

Don't rewrite the framework that you should be leveraging.

Leverage user centered design techniques. There are a lot of great resources out there that you can tap into to learn more. I'll follow up with a post about that in the near future.

Take religion and emotion out of the technical decisions that you are making. Evaluate technologies for their technical merit and choose the one that's going to work best for your team makeup.

Be sure to subscribe to James and I's blog. Follow up with us with questions. Let us know how you're leveraging the RIA technologies. We'd love hear it.

I enjoyed giving this talk and thank Mike and James for joining me in presenting it.