RadControls for WPF Beta released!

As promised in my recent TechEd post, here is the first of several exciting announcements Telerik will be making over the next week or so: Telerik has officially released the first beta of its brand new RadControls for WPF! If you've been waiting for WPF to gain the tools it needs to be a competitive alternative to your traditional WinForms development, Telerik's entrance in to this market should make your choice a lot easier. This first beta is only introducing a few controls, though, so don't expect a full toolbox right now. We've been investing a lot of energy in to building a super-high performance WPF data grid for this initial release, but as we move closer to the official release in Q2 you can count on more controls filling-out the suite. Included in the first beta are:

• RadGridView for WPF
• RadCarousel for WPF
• RadCalendar for WPF

We'll be showing-off these new controls at TechEd next week, but if you want to play with them now, you can! Simply visit the RadControls for WPF online demos page. That's right, online demos. We've made the WPF demos available as a browser-accessible XBAP application so you can check the demos out without the need for an install. The demo application is about 11MB and it only takes a few minutes to download and startup over a broadband connection. You'll also need IE7 to view the demos (for now), so Firefox users take note- XBAPs have actually crashed Firefox for me when I accidentally try to load them.

I hope you enjoy the early preview of our work for WPF. We've obviously got a ways to go before things are release quality, but we're working very quickly. The first "official" release of the RadControls for WPF is currently targeting our big Q2 release- less than 10 weeks away!

Join Telerik at TechEd 2008

I've been alluding to our presence at the upcoming uber tech event for a few weeks now, so let's go ahead and make the details official. Telerik will indeed be at TechEd again this year, so for those of you in the Orlando area (or those traveling there for a little business and fun), don't miss your next chance to come out and meet the Telerik crew. We'll have a strong contingent of Telerik-ers from our home office in Bulgaria in attendance, and I'll be around, too. We'd love to meet you, so stop by our huge new booth in slot 1101.

This year's event kicks-off with a keynote from Bill Gates (another "last" for Mr. Gates) on June 3rd, and you can bet I'll be there to bring you the live blogging coverage. I know many of you can't make it to TechEd, so I'll do my best to bring TechEd to you on this blog next week.

Meanwhile, in addition to being a Gold Sponsor of this year's event, Telerik will also be giving away more of the oh-so-popular .NET Ninja and Geekette shirts at our booth. I'll try to run another giveaway contest after TechEd to really share the excitement with those of you following along from your desks. On the technical front, we'll be showing-off brand new demo applications built with the RadControls for ASP.NET AJAX and will be premiering our RadControls for WPF and Silverlight. Downloads of the stuff we show-off at TechEd should be available in the next couple of weeks.

Clearly, it will be a fun time. Keep your feed readers locked-in next week for all of the live updates and get ready for a lot of exciting new downloads and announcements from Telerik!

Optimization Tips: Using HTTP Compression

I know it has been a few weeks since the last installment in this series, and with TechEd on the horizon it'll probably be a couple 'til the next, but as long as there is some time in between let's explore another area of performance optimization with the RadControls for ASP.NET AJAX. This week, we're going to take a look at HTTP compression and how this simple technique can deliver a valuable performance boost to your website.

What is HTTP compression?
Since the turn of the century, almost all browsers have supported compressed content via the "content-encoding" (or "transfer-encoding") specs defined in HTML 1.1. When a browser requests a page from a server, it always tells the server if and what kind of content encoding it can handle. This information is communicated in the "accept-encoding" request header. If the server is configured correctly, it can respond to this header value and automatically compress (think Zip) the HTTP content before sending it to the browser. When the content arrives, the browser decompresses the content and renders the page.

The overall goal of HTTP compression is to reduce the number of bytes that must be transmitted over the tubes between your server and the user's machine. Since transmission time is often the slowest bottleneck in loading a page, and since bandwidth directly relates to your costs as a site operator, reducing the bytes you transmit to the user can save you money and improve your site's performance.

How do I use it with ASP.NET?
There are a number of ways to use HTTP compression with ASP.NET. If you have full access to your server, IIS 6 provides some basic compression support. Compression of static content is turned-on by default in IIS 6, but you'll need to take extra steps to enable compression of dynamic content. If you're already in a Windows Server 2008 environment, IIS 7 provides great HTTP compression support, enabling you to define which files get compressed based on their MIME type in your configuration files. Still, to use IIS' compression support, you need to have complete access to your server (specifically IIS), and to get great support in IIS you need to be running Windows Server 2008. (NOTE: For a good overview of compression features in IIS 7, see this blog post on the IIS blogs.)

Fortunately, there are alternatives for developers that want to deploy HTTP compression support with their applications (or for those devs that don't have access to IIS, such as in shared hosting environments). Several open source projects and commercial products exist on the interwebs that provide HttpModules to compress your content based on configuration rules. Once such commercial tool that I've used successfully in the past is ASPAccelerator.NET. By simply adding a HttpModule reference to my web.config and deploying a single assembly in my bin folder, I can instantly begin compressing my HTTP content (served by IIS6 or 7) based on an intelligent set of rules.

For today's tests, that is the approach that will be used to compress our test site. And since we're interested in seeing how HTTP compression helps "real world" site performance, we're going to be doing our testing a little differently this week than we have in the past.

Help Desk demo testing with Gomez
Have you heard of Gomez? If you work for a large, Fortune 500 company chances are you are using their services to actively monitor and measure your company's web performance. Gomez is one of the largest providers of website performance measurement and tracking, and as such, they have some of the best tools available for measuring a site's performance.

What you may not know is that Gomez provides a free "instant site test" that you can use to take one-off measurements of your site's performance as seen by one of Gomez's 12,000 test computers. The free service allows you to supply a URL and select a test city (L.A., New York, Chicago, Beijing, or London), and then Gomez generates a detailed report showing you how responsive your site is. This is a great (free) way to see the real world effects of latency and bandwidth on your site, which makes it a perfect way to measure the effects of HTTP compression on our test site.

And to conduct today's tests, we'll be setting-down our fun InterWebs demo in favor of using the slightly bulkier Telerik Help Desk demo. This demo displays a fair amount of data pulled from a SQL Server 2005 database, and it uses many RadControls, such as RadGrid, RadTreeView, RadMenu, RadCombobox, RadSplitter, RadAjax, and RadCalendar. RadWindow and RadEditor are their, too, but they won't have an impact on today's tests of the primary Help Desk landing page.

How will the tests be run?
To conduct today's tests, we'll start applying the techniques we covered in parts 1 and 2 of this series to the Help Desk demo, collecting 5 Gomez test results from their Chicago test server (the demo today will be hosted on a DiscountASP server in California). All tests will be run as if on empty browser cache (thanks to Gomez) and the average of the 5 tests will be reported. Once we've layered-on our previous performance improving techniques, we'll enable HTTP compression with ASPAccelerator and see what kind performance benefit it provides.

Make sense? Then let's run our tests and analyze the results.

The test results
With the tests run and the averages collected, let's take a look at the effect our different performance improving techniques had on our live test site:

While the absolute numbers here aren't great, they're also not important. This is a completely unoptimized application running on shared hosting with very little server resources, communicating from California to Chicago. What are important are the trends, and the they reveal some very interesting facts:

1. If you didn't believe the impact of leaving complication debug = true from part two of this series, believe it now. Simply setting debug to false reduced the time it took for our page to load by almost 30% (7 seconds)! ALWAYS set debug to false in production.
   
2. The same advice is true for the RadManagers (RadStyleSheetManager and RadScriptManager). By simply adding these to my page (and doing nothing else), I further reduce page load time by over 50%. Combined with the first step, 60 seconds of work has shaved almost 70% of the loading time off of my page.
3. Finally, adding the HTTP compression shaves another 30% off my page load time, producing a page that takes almost 80% less time to load than the original version! And I haven't changed any code.

The bandwidth comparison
Just as important as page load time in today's tests is measuring how much HTTP compression saves me on total bandwidth. If there is anything in this largely free marketplace we call the Internet that increases our costs as our sites become more popular it's bandwidth (and the servers required to fill it, of course). So if HTTP compression- in combination with our other performance improving techniques- can reduce the bandwidth we consume to send the same pages to our users, we'll directly impact our bottom line. Let's see how bandwidth varied over each stage of our test:As you can see, HTTP compression had a huge effect on the number of bytes we needed to send over the line to load the same exact page.

• With no "treatments" applied, we sent over 1 MB of data to our user's browser on the first visit! That's a lot of data.
  
• Setting debug to false reduced our bandwidth usage by about 15%, and adding the RadManagers only slightly lowered bytes sent from there.
  
• When we added the HTTP compression, though, we reduced the number of bytes sent over the wire by over 75%! That's a huge bandwidth savings that should directly translate into higher throughput on on our servers and improved page response times.
  

We can validate the improved page response times with the overlaid page load time stats. As the bytes are reduced with HTTP compression, we see page load time decrease. But notice how much page load time drops when the RadManagers are added to the page even though they don't significantly impact the page's footprint. Remember, all the Managers are doing are combining data, not compressing. They deliver huge performance gains by reducing the number of links on the page, thus reducing the number of requests the browser needs to make to load all of our images, stylesheets, and JavaScript.

Gotchas
As with all performance tips, you do have to be smart in your application. While HTTP compression is generally a very efficient operation that doesn't significantly task the CPU, you should be careful on high volume sites. The extra CPU cycles required to perform the compression could make site performance worse than it would with compressed traffic. In most low- to medium-volume scenarios, though, you can compress without concern. In the coming weeks, I'll highlight a hardware solution that can solve the woes of compression on high-volume sites (in addition to providing a number of other helpful performance boosters). If you want to explore the tool on your own in the mean time, visit the Strangeloop AppScaler website.

You also need to be careful with HTTP compression and Ajax. Some HTTP compression tools do not play nice with Ajax requests, breaking callback functionality on the page. ASPAccellerator provides support for the ASP.NET AJAX framework, but not all tools may be as helpful. Choose wisely.

Optimization Tip Summary
What have you learned today? Quite simply this:

• The rules from parts 1 and 2 of this series are still among the most important for improving page performance.
• Adding HTTP compression to your page with the RadControls for ASP.NET AJAX can measurably improve page performance and significantly lower bandwidth requirements.
  

Hopefully these tests help you understand and visualize the benefit HTTP compression can play in squeezing every bit of performance out of your site. In the coming weeks, I'll try to do some comparison tests of different HTTP compression methods- IIS 6/7, port80, ASPAccelerator, open source- to give you more guidance if you're trying choose a compression provider. Until then, compress away and do your part to help reduce the bits clogging the Internet's tubes!

Windows 7 (barely) demoed, Gates and Ballmer reflect

Despite all of the press surrounding Windows Vista, the Redmond crew is pushing forward and moving the conversation officially (if ever so slightly) on to Windows 7. In a special interview with the Wall Street Journal tonight, Steve Ballmer and Bill Gates took the stage to retell stories of Microsoft's early days and give a super-early preview demo of Windows 7. Engadget provided the live-blogging of the event, so if you're interested in the play-by-play rundown of what happened, check them out. For this audience, I think the Windows 7 portion of the evening is of the greatest interest.

Unfortunately, the "small little snippet" of Windows 7 shown-off by Ballmer tonight does little inspire on the software side of life. The demo primarily focused on new support for multi-touch in Windows 7, a feature in my opinion largely driven by hardware. And unless we all start swapping out our 24"+ monitors out for touch-capable screens, this isn't a feature that many of us will use. Similar to Ink's usage in the still tepid tablet pc market. (UPDATE: A video of this feature is already available online (posted earlier today), so check it out if you're interested.)

Still, if we are to accept that Windows can drive future computing trends, here's what we have to look forward to in the Windows 7 era (still on target to ship "3 years from Vista general availability"- in other words, early 2010): heavy focus on alternative input techniques- multi-touch, voice, ink, et cetera. And sadly, that's about all we can glean from tonight's demo. No talk of radically changing UIs (other than to accomodate aforementioned multi-touch). No talk of the once heralded WinFX file system. No talk of tighter "cloud integration."

Does that mean those things aren't coming in Windows 7? Of course not! In fact, based on the demos, I think tonight's stunt was largely Microsoft's effort to make it clear to the world that they thought of multi-touch in the OS before Apple makes it even more pervasive than it is today in OS X. They're trying to stem the "you copied Apple" criticism that Vista suffered around the time of its launch. Will the stunt work? I guess we'll find out in about 18 months.

For a better explanation of what Windows 7 will look like and why Microsoft is being more tight-lipped than usual about its development, check-out a post on the Windows Vista blog published today by Chris Flores. In short, despite tonight's public stunt, Microsoft still isn't ready to publicly talk about Windows 7- at least not beyond its support for new input techniques.

Telerik TV is live!

I have some very exciting news to share with you today. For months now, Telerik has been working on a "secret" project in partnership with Carl Franklin at Pwop Productions to develop a regular screencast show (a la DNR TV) that showcases the amazing applications built by Telerik's customers with the RadControls. A lot of people have been busy working on this project and we've already recorded a number of great episodes with some of Telerik's more innovative customers. This week we're happy to unveil the fruit of that work: Telerik TV.

Telerik TV is going to be a bi-weekly videocast (screencast, video show, whatever you want to call it) that shows-off your applications, your innovation, and (of course) your company. The only requirements are that your application is unique enough to be interesting to the viewers of Telerik TV and that it uses the RadControls (for ASP.NET or WinForms) to drive the UI. If you think your app meets those guidelines and you want to show it off in a future episode (and you don't mind talking about your app for an hour with Carl Franklin), submit it to tv[at]telerik.com

To get things kicked-off, Episode 1 of Telerik TV is featuring a product built by our great partners at Falafel Software. Lino Tadros, President, CEO, and all-around entertaining guy, takes the mic with Carl and shows you how ActiveFocus uses the RadControls to deliver a desktop-like experience via the browser. I've blogged about ActiveFocus in the past as an example of an application that really pushes the performance boundaries of the RadControls, so if you want a deeper look at how the RadControls can be maximized for performance, don't miss this episode. If you're just interested in test driving the latest release ActiveFocus, you can do that, too.

Now, I know you are bombarded with media from all directions as a developer, especially on the increasingly crowded podcast and videocast front, so I don't take it lightly to ask you to add another subscription to your media feeders. But if you use the RadControls (or are thinking about using the RadControls) and want to see the elusive "real world" examples of our controls in action, built by people completely outside of Telerik, subscribe to Telerik TV today! We'll only ask for 2 hours of your time every month and we promise to make it worth your while.

I hope you enjoy this new way to learn about Telerik's tools. We'll be eagerly listening to your feedback to help guide our future plans. In the mean time, we've got a few more exciting announcments to share as we get ready for TechEd 2008, so stay tuned for the fun!

ASP.NET MVC Preview 3 released today

For all of you MVC fans out there, listen up: the third preview release of the ASP.NET MVC Framework has just dropped and is now available for download at the normal locations. This release comes about two months after the last "official" release (Preview 2 - released March 18th) and continues the iterative release trend Microsoft has adopted for the MVC project. Under this model, Microsoft is releasing bits for its new framework much earlier than it normally would and relying heavily on community feedback to guide the direction of the product. The approach has its pros and cons- we get to play with code earlier (pro) but lots of incorrect (a.k.a. outdated) information about the framework floods the internet (con). I'll reserve my judgment on this "experimental" product development approach 'til we see what the MVC team ultimately produces, but in the mean time, use caution when searching the interwebs for ASP.NET MVC help. It's likely already out of date.

Point in case, the new Preview 3 release makes a number of fundamental changes to the way ASP.NET MVC works. These changes are to be expected as the MVC team tweaks the Framework's API to "feel right," but if you've been dipping your toes in the MVC pool with Preview 2 be preparred to make some code changes. Among the key changes in this release:

• Action methods in MVC Controllers no longer rely on the static RenderView() method to render a view. Instead, a more flexible ActionResult is now returned by action methods. There are 6 enumerated ActionResult types, easily enabling you to do everything from render HTML (ViewResult) to redirecting the users (RedirectResult). This change will affect Preview 2 apps.
• The ViewData property of ViewPage no longer returns T. Instead, a new property has been added to the page's ViewDataDictionary to handle that task: Model. Call the Model property to access a strongly typed collection of data passed to the page.
• Routing has changed a lot in in Preview 3. The most significant change is the way routes are defined in the Global.asax file. A new MapRoute extension method makes the process much simpler than Preview 2, significantly reducing the number of lines of code it takes to define routes. This is a welcome change, but it will also require you to update your Preview 2 apps.
  

For a complete overview of the changes in Preview 3, be sure to review the release notes (caution: Word link). You can also find an exhaustive post covering all of the changes in Preview 3 from the master of increbile blogging, ScottGu.

Many of these changes are going to make MVC more enjoyable to use. The new ActionResult, for instance, is going to dramatically simplify MVC unit testing by removing the previously painful mocking required to test views. We also get the impression from Scott's post that the MVC team is "starting to feel good" about the MVC URL routing and controller/action components, so we may start to see these APIs stabilize in future releases. Scott's also indicating that future MVC releases will focus more on delivering improved HTML Helpers and better Ajax integration, two areas that are very interesting to those of us that spend a lot of time in the UI. I guess we'll find out in another couple of months.

Until then, enjoy the new preview and let us know what you think. Is ASP.NET MVC something that you'd consider using instead of WebForms in your organization?

Great Indian Developer Summit 08 Wrap-up

The first annual Great Indian Developer Summit is almost over, but the .NET portion- "Bleeding Edge .NET"- has been over now for a couple of days. And now that I've made the 20+ hour journey back to the US from Bangalore (with a quick stop in the oh so hip Dubai), it's time to provide some final thoughts and follow-up. In short, for a first-year event, GIDS 2008 (at least the .NET portion of it) was an amazing success! There were about 1,000 developers in attendance for both days of the .NET sessions, which for those not aware of "average" .NET event sizes is incredible. It solidly makes GIDS the largest .NET event in India and probably among the largest in that part of the world.

Beyond it's success in numbers, the event was also very well run. Attendees really seemed to be enjoying themselves and I know the speakers were all very satisfied with session turn-out. Each of my sessions was easily attended by well over 100 devs, the largest of which was probably attended by close to 300. And if my Silverlight session had been in the main keynote hall, I bet I could have attracted 600 people to the talk. I guess we'll never know...

If you didn't catch my earlier posts, be sure to take a moment and grab the slides and code I presented on days one and two. They are great resources for review if you're interested in ASP.NET AJAX, ASP.NET MVC, WPF, or Silverlight. If you're interested in pictures of this year's summit, be sure to check out the photos Jean-Luc David (MS Team System DE) posted to Flickr. He's also got a Bangalore set that features some of the speakers (yours truly included), so check that out if you've never been to India or are interested in seeing some speakers model for the camera.

I think GIDS has a great future and I look forward to participating in the coming years. GIDS 09 planning is already underway, so watch soon for the dates for next year's event. For me, it's now on to TechEd 08!

Slides and Code from GIDS Silverlight Deep Dive

Another day of "bleeding-edge .NET" at the Great Indian Developer Summit and another great presentation to archive. On day one, I had the pleasure of delivering a handful of focused sessions on various Microsoft technologies, but on day two it was all about the Silverlight. Deemed a "workshop" by the schedule, but in reality more like an in-depth presentation, my near 4-hour Silverlight 2.0 Deep Dive was a fun presentation for Silverlight learners of all experience levels. I called it "101 to 301 in 3 hours."

Really, the only negative aspect of the presentation was that the room was too small. We had people filling every seat, crammed shoulder-to-shoulder in the aisles, and spilling out the doors for most of the session. Some GIDS attendees where even willing to stand for over 2-hours to watch the presentation from the door jam. I suspect we managed to cram about 125 or so people in to a room designed for 75, and I know many more simply didn't get to attend because there was no room.

Fortunately, for those that didn't get to get in, all is not lost. At the bottom of this post you can find the slides and code demos from the Silverlight Deep Dive session. In about a month, you'll also be able to grab the video of the session from the conference organizers, who are putting all sessions on a DVD. I want to extend a huge thanks to those of you that did attend, especially those that lasted all 4 hours. I had a great time and you had some great questions. I hope you enjoy these materials and I look forward to meeting many of you again on the .NET road!

Silverlight 2.0 Deep Dive
Slides Code

Slides and Code from Day One at the GIDS

Now that you know I'm in India speaking at the first annual Great Indian Developer Summit, it's time to move on and start doing some presentation wrap-ups. As I mentioned in yesterday's post, I've so far delivered three focused sessions on three relatively new Microsoft technologies- ASP.NET AJAX, ASP.NET MVC, and WPF. These topics are clearly of great interest to the local .NET community as every one of my talks (except for the first, which was in the keynote main hall) were filled to capacity, standing room only. Even my first talk in the keynote hall was easily attended by over 300 people. Needless to say, the turnout is great.

For everyone here in India that attended one (or all, as I've had some people report) of my sessions, thank you very much for coming out and being a great audience. I know I can speak fast, so hopefully I wasn't too hard to understand. If I was, you were all very polite and faked enjoying my presentations well!

For everyone that couldn't make it to India for my presentations (I know there are a few of you out there), you can find the slides and demo code from my presentations at the bottom of this post. Some of the demos, especially those borrowed from Interknowlogy (like the 3d WPF apps and the XAML Cruncher tool), I'll omit from my downloads, but you can find links to download them yourself on Tim Huckaby's blog. I also can't make the Telerik RadControls for WPF "sneak peak" available for download right now, but watch for a public beta right before TechEd (I'll announce it on this blog).

Otherwise, I hope you can take away some useful tips from these decks and find practical help for diving deeper in to these emerging and maturing technologies. Watch for another update soon with the slides and code from today's Silverlight deep dive.

ASP.NET AJAX and the Future of Web Development
Slides Code

First Look: ASP.NET MVC
Slides Code

WPF: The Road Ahead
Slides Code

Telerik at the Great Indian Developer Summit

With day one almost in the rear view mirror, I figured I should fix a bit of an oversight and let you know that I am at the Great Indian Developer Summit this week! I usually try to let you know about my whereabouts when I'm going to be on the road so you can make plans to attend my sessions if you're nearby (or bored, independently wealthy, and willing to buy a plane ticket). In this case, my mad rush to prepare my demos and my international travel left me no time to properly give notice on this blog. I'll do better next time.

But enough with the apologies. If you are in Bangalore (India, for the geographically and context clue challenged), definitely make sure you come to Day Two of the Great Indian Developer Summit. There are hundreds of .NET developers here, a number of great companies in the exhibitor area, and, of course, some great .NET speakers. The event kicked-off today with "Bleeding Edge .NET", and the .NET sessions will run through tomorrow. After that, the event moves-on to "Rich Web" and "Daring Java" to round out the week.

I did three presentations today on three totally different technologies- ASP.NET AJAX, ASP.NET MVC, and WPF. Tomorrow I've got a fun 3+ hour Silverlight "deep dive." I should have asked to do a WinForms presentation and then made it a home run of .NET UI platform presentations! Today's presentations were very well attended and all went pretty smooth. I'll throw another post up later with my code and presentations, though, so I'll save the recap for that.

All-in-all, it looks like GIDS is off to a great start as one of India's premier .NET events and I can't wait to be a part of it in future years. Stay tuned for more updates and some great GIDS stories. Also, for those of you eagerly awaiting my next installment in the "Optimization" series, I haven't forgotten about you. I promise that I'll get that series back in gear as soon as I get back to the States!

First Service Pack for RadControls for ASP.NET AJAX released

About a month ago (hard to believe that much time has already passed) Telerik released the big Q1 2008 RadControls for ASP.NET AJAX. By many standards, it was one of the most successful releases in Telerik's short history, shipping right on time with relatively few problems. But even great releases need to be serviced, so today we're shipping the first Service Pack for the Q1 2008 release. The SP1 release, as usual, is loaded with fixes for all of the RadControls and it also packs-in a few handy new features, too. The full release notes are available online, but for those too busy to look now, here are some highlights:

• Over 20 fixes and 8 new "features" for RadGrid
• 19 fixes for RadEditor and several improved dialogs
• New client-side "click" events in RadMenu and RadPanelbar
• New client-side enable/disable methods in RadTabStrip
• Change to modal RadWindow behavior- Escape will now not close the window

The one obvious "gotcha" to look out for in this SP release is a breaking change in RadTabStrip. Specifically, the "ReoderTabsOnSelect" property has been changed to "ReorderTabsOnSelect" to fix the obvious typo. Otherwise, this SP should be safe to apply to your projects and begin testing for roll-out to your Prod environments. Hopefully the new fixes and features will suite your needs 'til the next big release- Q2 is quickly approaching, you know!

Download the Service Pack now from your Client.net account

Microsoft CodePlex now using RadEditor

It has been a lot of fun to start sharing with you over the last few months the work that Microsoft is doing to using the RadControls on their various sites. Today I get to share another exciting Microsoft implementation. The CodePlex Wiki is now using the RadEditor on all Project Discussion pages. The Editor implementation is relatively simple, but it makes the process of adding formatted content to the CodePlex discussions much more intuitive. If you're an active user of this community resource, hopefully you'll enjoy the improvement!

We're all very excited at Telerik to be able to keep providing you with these great "real world" examples of our controls in action. I've said it before, but it's worth re-iterating: awards and trophies are great, but solid real world uses of the RadControls on huge, high-volume sites like MSDN, TechNet, and CodePlex are much better proof the quality of the work we're doing. If our tools are the choice for some of the most active sites on the web, there is no question they can support the demands of your next project.

In fact, do you have any cool implementations of the RadControls you want me to feature? I'd love to show-off your work with the broader community, so if you have a public site that features the RadControls that you want me to highlight, send an email to todd[dot]anglin[at]telerik[dot]youknowwhat. You may just find your site as the next great "real world example" of the RadControls featured on this blog!

[Note: To see the RadEditor on CodePlex, simply visit a project page and then start a new Discussion. You must be logged-in to do this.]

New Telerik Help System Live

There is nothing worse when trying to solve a problem with 3rd party tools than to be presented with a difficult to use documentation system. You're already frustrated, so you need docs that are easy to navigate so you can find your answer quickly and get back to being productive. And, if we're being frank, Telerik's online documentation system hasn't been as good as it needs to be to meet those simple requirements. The docs have been loading in an ancient frame-based layout and the tree navigation took forever to load (clearly, it wasn't using RadTreeview). I'm happy to report that's all history as we've just rolled-out a brand new online documentation system!

The new tool has been in development for a while now and was one of the major tasks completed during our Q1 2008 efforts. We would have rolled it out with the release, but it needed a few extra days to be perfect and everyone was heads-down making sure your release questions were handled promptly. Now that the Q1 release is out the door, the new online documentation system is up.

Unlike previous iterations, this system has been built largely in-house using Telerik's RadControls for ASP.NET AJAX, and it features a number of improvements over the old version. Among my favorite improvements are:

• SEO friendly (and easy to copy-and-paste) URLs. No more frames "hiding" the URLs!
• Clean, easy-to-read, modern design. I love Telerik green, but the old system was just hard on the eyes.
• RadTreeview topic navigation. We finally get all of the RadTreeview "goodness" for navigating the docs, like load-on-demand nodes, automatic node locating, and clear selected node styling.
• Google-based search. Our Google Mini search appliance is powering the online doc search, so you should be able to find what you need, when you need it.

So whether you use the online docs a lot or every now and then, you should find the new experience to be much more enjoyable. You'll be able to quickly find your answer among the thousands of pages of documentation and impress your co-workers that much more quickly with the "magic" you can perform with your RadControls. Check out a post from Nikolay Dobrev for another perspective on the new system and then give the docs a try for yourself!

VS 2008 and .NET 3.5 SP1 beta now available, Early adopters beware

Have you been eagerly waiting for the first round of service packs for Visual Studio 2008 and .NET 3.5? If you haven't, then you are probably unaware of all the new features these service packs are delivering. These are aren't "standard" SPs that ship mostly invisible improvements and hotfix roll-ups. No, these SPs are shipping so many new features that it took the blogging powerhouse ScottGu a little over 4,000 words to describe them all. And since I expect many of you don't have the time to pour through a 4,000 word blog post, let me summarize the highlights of these betas (an impending final releases) here:

• .NET 3.5 SP1
• New! ASP.NET Dynamic Data (scaffolding support)
• New! ASP.NET Routing Engine (URL routing ripped from MVC)
• ASP.NET AJAX History Support (Fix back button, Support bookmarks)
• ASP.NET AJAX Script Combining (combine any JavaScript files on the server)
• Client and web performance improvements
• Client apps cold starting up to 40% faster
• ASP.NET apps improving throughput up to 10%
• New! WinForms Controls (go figure...)
• Including VectorShape, DataRepeater, PrintForm
• New! WPF Extensible Shader Effects
• Hardware accelerated visual effects (like DropShadow, Blur, etc.)
• Tons of WPF performance improvements
• New! ADO.NET Entity Framework and LinqToEntities
• Can be used with any database, not just SQL Server!
• New! ADO.NET Data Services (formerly "Astoria")
• REST-based data service support
  
• Visual Studio 2008 SP1
• Improved IntelliSense support for multiple JavaScript/Ajax frameworks
• HTML Designer and Source view performance improvements
• Improved WPF project and designer support and performance
• In other words, WPF development experience is much improved
  
• New! ADO.NET Entity Framework designer
• Looks like LinqToSql designer
  
• Improved C# real-time error checking (more red squiggly errors sans-compile)
• Um...finally!
• Complete support for SQL Server 2008

Clearly, a lot is packed-in to these updates. If you weren't eager to install these SPs before, you're probably a little more excited now that you know what they're bringing to the table. But before you run off to volunteer as a guinea pig for these freshly baked service packs, there are a few serious "issues" with these betas you should consider:

1. If you're using Vista, you must have SP1 installed.
2. You need to uninstall the VS 2008 Tools for Silverlight 2 Beta
• A compatible version of the tools will be available in a "few weeks"
3. You need to install a new "special" version of Expression Blend
• The "special" version addresses a temporary problem in .NET 3.5 SP1 that will go away in the final release, at which point you'll need to reinstall Expression Blend...again.

If those aren't deal breakers for you, then take a minute to read ScottGu's post and follow the download link to grab all of the new bits. For everyone else that would prefer to wait for more stable bits, look for the final release of these service packs "this summer."

Survey Says: Unit Testing Still Not Mainstream

Another survey and another set of interesting results. For the last couple of weeks I've been running a survey on this blog asking you to indicate if you use unit tests A) pretty much all the time, B) once in a while, or C) never. And within the last option, I gave you the opportunity to indicate if you're not using unit tests because you don't know what they are or because simply don't think you need them. Clearly, I expected a large number of you, dear readers, to fall in to categories A and B, but just as with the "why do you code" survey, you've surprised me.

Frankly, I'm still trying to decided whether these results represent humor responses or painfully honest feedback. I find it hard to believe that in this day and age of TDD and Agile buzzing all around that you can escape knowing what unit tests are. Still, 9% of you indicate that is the case, so clearly it is possible. More shocking than not knowing about unit tests, though, is the large group of respondents that said they know about unit tests but don't think they need them! Almost 40% of those that answered fell in to this category.

That raises the most interesting follow-up question: Why don't you think you need unit tests? Clearly their benefits are well extolled across the interwebs, so it shouldn't be necessary to point out how unit tests help you write better, more maintainable code. Knowing that, though, many of you still (apparently) rely on manual testing. Are unit tests still to hard to integrate in to your programming work flow? Do you generally write perfect code ([cough]...liar)? Sound-off in the comments and let us know.

And just to be clear and set the tone, I don't unit test all of my code (not nearly to the degree I know I should). Largely it's because I'm a web developer and I've always found it too hard to create unit tests for code that spends most of its time reading or updating databases. How much does a unit test help when you start mocking everything out? Still, I'm getting better and I increasingly depend on unit tests for writing better code.

Regardless of your answer, thanks to everyone for participating in another survey. The next survey is already up, and with summer approaching, I'm asking how often you manage to leave the computer and spend some time outdoors. As always, be honest.

Optimization Tips: Using RadAjaxManagerProxy Controls

In this installment of my ongoing series covering RadControls for ASP.NET AJAX optimization tips, I am going to take a short break from talking about how to optimize your page performance and instead cover a tip that will help you optimize your code. Specifically, we're going to take a look at the RadAjaxManager and the RadAjaxManagerProxy controls to see how they enable you to very easily ajaxify all parts of your application.

The ASP.NET AJAX Era
Long before ASP.NET AJAX was a gleam in Microsoft's eye, Telerik was providing robust Ajax tools to its customers. Telerik developed a full Ajax framework that made it very easy to implement Ajax in ASP.NET applications, the cornerstone of which was the RadAjaxManager control. When we began making the transition to ASP.NET AJAX, though, we decided to completely leverage Microsoft's framework in our RadAjax product. We wanted to deliver all of the time-saving benefits of the RadAjaxManager at design-time while relying on ASP.NET AJAX at run-time.

Needless to say, the RadAjax product that exists now does exactly that. It is built completely on ASP.NET AJAX and delivers all of the power of the Microsoft framework through Telerik's award winning tools. But the new RadAjax does more than change the underlying technology handling the Ajax "magic"; it also makes your Ajax configuration easier than ever.

The Old Days
Before RadAjax for ASP.NET AJAX, the task of defining Ajax settings in site's that utilized MasterPages and UserControls (read: almost all sites) was...a bit of a challenge. If you wanted the benefits of the AjaxManager's visual configuration tool (or even in-page IntelliSense mark-up), you had to place a RadAjaxManager on every ContentPage. This worked to a point, but if you wanted to also ajaxify controls on MasterPages, you were stuck with two RadAjaxManagers that wanted to control the same rendered page. To solve the problem, you could put a RadAjaxManager on your MasterPage, but then all settings in your ContentPages and UserControls had to be made programmatically- a laborious and code-cluttering requirement.

Enter the Proxies
With the advent of ASP.NET AJAX, Microsoft introduced the ScriptManager control. This control must be present on any page that uses ASP.NET AJAX and- like the RadAjaxManager- can only be on the page once. To work around the problem of ContentPages and UserControls, the ScriptManager introduced a companion control called the ScriptManagerProxy. This control enables developers to define settings for the primary ScriptManager that are rolled-up in to the primary manager at runtime.

RadAjax for ASP.NET AJAX mimics that architecture. You can now easily define a single RadAjaxManager in your application's MasterPage and then add RadAjaxManagerProxy controls to all ContentPages and UserControls. At runtime all settings in the proxies are rolled-up to the primary RadAjaxManager, but at design-time you get all of the benefits of Source View IntelliSense and the RadAjaxManager visual configurator. See Slide 1 of my embedded Google Presentation (below) to see this layout illustrated.



By utilizing the RadAjaxManager and RadAjaxProxy controls, you greatly simplify your ASP.NET AJAX ajaxification process. First, you don't have to clutter your markup with the UpdatePanels normally required by ASP.NET AJAX, making your code easier to maintain and read. Next, you don't have to manually think through how Triggers should be defined on your UpdatePanels. The RadAjaxManager automatically figures that out based on your simple definition the controls that should be updated after specific control events fire. And finally, RadAjaxManager provides a complete client-side API that makes it easy to perform advanced ASP.NET AJAX operations without having to write a lot JavaScript manually.
Client-side Support
Among the client-side support that the RadAjaxManager offers is the definition of two JavaScript events you can subscribe to: OnRequestStart and OnResponseEnd. You can see the code required to wire-up these client-side events on Slide 2 of my embedded presentation deck (see above). The events are very handy if you want to do anything on the client (such as validation) before an Ajax event fires. You can even cancel an Ajax request before it fires.

This is an extremely easy way to take more control over your application's Ajax, but what if you want to customize the JavaScript events that handle Ajax settings in your Proxy controls? Since the Proxy controls are not actual instance of RadAjaxManager, they do not expose ClientSettings directly. Instead, you need to work a little JavaScript magic to provide custom client-side event handlers for your primary RadAjaxManager that only handle controls ajaxified by your proxy.

Handling Client Events in UserControls
You recall that all ajax settings in the Proxy controls are rolled-up to the primary RadAjaxManager at runtime. That means there is only one point to define the JavaScript events that fire on Ajax requests: the primary RadAjaxManager. You cannot define JavaScript events for each Proxy control. You can, however, change the JavaScript events defined on the primary Manager in the PageLoad of any ContentPage or UserControl.

To change the events defined in the RadAjaxManager, the code shown on Slide 3 of my presentation should be added to the PageLoad event. Notice that the RadAjaxManager class exposes a very handy "GetCurrent" method that makes it very easy to get a reference to our primary RadAjaxManager from any position in our application (on a ContentPage, UserControl, etc.). With a reference to our primary Manager, we can quickly set the OnRequestStart and OnResponseEnd event names (just simple strings).

But wait! Now what happens when an ajax event defined in our MasterPage fires? It travels through our new JavaScript event handlers in our UserControl. That's no good. We only want controls ajaxified by our Proxy to get handled by our new JavaScript event handlers. Is there any way to "route" ajax events triggered in our UserControl to one set of JavaScript event handlers and ignore other ajax events? Yes, sorta.

Route the Events
Since there can only be one active set of JavaScript functions that handle RadAjaxManager client-side events, we have to manually provide support for "routing" events to the proper JavaScript functions. We can do this by inspecting the EventTarget property of the eventArgs passed to the OnRequestStart JavaScript function. That property will contain the full ClientID of the control that initiated the Ajax event. For example, if our button is located in UserControl "ProxyUserControl" on page "Default" in a MasterPage, we might see an ID like:

ctl00$ContentPlaceHolder1$ProxyUserControl1$btnUpdateTime

Ah hah! We have a way to tell where the Ajax event came from. By using some JavaScript to see if our UserControl name exists in this EventTarget string we can correctly route the RadAjaxManager client events. See Slide 4 in the embedded presentation for a complete look at the JavaScript code that handles this routing.

Gotchas
While this is a great solution for enabling custom handling of the OnRequestStart and OnResponseEnd events in UserControls, it does require a couple of assumptions that make our code a little brittle. First, you must know the names of the OnRequestStart and OnResponseEnd JavaScript functions in your MasterPage and you must assume those functions are present. Second, you must know the name of your UserControl so that you can correctly detect if the current Ajax event was fired from within the UserControl. Other than that, you're good to go.

Optimization Tip Summary
So what have you learned today? A few key points:

• RadAjax for ASP.NET AJAX implements ASP.NET AJAX (not proprietary Ajax). Spread the word.
  
• You can (and should) use RadAjaxManagerProxy controls to define Ajax settings in ContentPages and UserControls
• You can use JavaScript to "route" OnRequestStart and OnReponseEnd events to different client-side functions by interrogating the EventTarget property of the eventArgs

Hope this helps you develop ASP.NET AJAX-enable applications faster than ever and gives you the tools you need to take exacting control over your Ajax behavior. In the next installment in this series, we'll resume with our look at techniques that improve your page load performance when using the RadControls for ASP.NET AJAX.

Optimization Tips: Testing Page Performance

Welcome back to my new series covering optimization tips for the Telerik RadControls for ASP.NET AJAX. The last time we visited, I showed you how you can reduce your initial page load times 30%, on average, by simply adding the RadScriptManager and RadStyleSheetManager to your application's pages. In this installment, we'll look at two follow-up issues: how does the web.config debug property affect page load performance and how much slower is Cassini than IIS.

When I conducted the tests for the first installment, I made sure "compilation debug" was set to false in my web.config and I used IIS to get pretty accurate results (I add the qualification because I didn't run the tests on a high performance web server, but you can expect that would only improve the absolute values). What would have happened, though, if I deployed my test website and forgot to set the debug property to false? Or even more serious, if I had used the Visual Studio Web Server (Cassini) instead of IIS for my tests, how would that have impacted my perception of page performance? That's what we'll quantify in part two. The results may or may not surprise you, but they'll certainly prove to you why it's important to save your impressions of page performance until a site is running in IIS with "debug=false" in the web.config.

Simple property, big impact
One of the easiest ways to tank the performance of your fancy ASP.NET AJAX website is to forget to set the compilation debug property in the web.config to false. This property has been used by ASP.NET for years to control debug and release builds, but the introduction of ASP.NET AJAX and it's richer client-side programming environment has added a serious client-side page load penalty for sites running in debug mode. Specifically, when ASP.NET AJAX detects that a site is running in debug mode, it loads a special debug version of the ASP.NET AJAX client libraries tuned for maximum debugging- not performance.

This feature of the ASP.NET AJAX framework is great for development because it makes it much easier to debug client-side code without impacting the performance of "release" libraries. And when the time comes to move your application to production, a simple property change will let ASP.NET AJAX know that it should deploy the tuned-for-performance release versions of the client libraries and turn-off the excessive debugging. That is, of course, if you remember to change the property.

The compilation debug property is located in your application's web.config file within the system.web block. It is a boolean property that defaults to false, but if you develop with Visual Studio, it is very easy to set this property to true without thinking. If you've been developing with ASP.NET for any amount of time, I'm fairly certain you've seen this setting, but you may not fully understand how substantial the impact is of not setting this property correctly.

To answer that question, I turned to the same sample application we introduced in part one of this series. It consists of a page with RadGrid, RadTreeview, RadMenu, RadSplitter, RadAjax, and (for these tests) RadScriptManager and RadStyleSheetManager. I tested page load times using IIS and IE7/8 and FF2/3, loading the page 6 times in each browser: 3 loads with a primed cache, 3 unprimed. The key difference for these tests, though, is that I set debug in the web.config to true.

In the above chart, the "Unprimed" and "Primed" series are the same values from part one's page load tests with the Rad Managers. They serve as our baseline for the new tests. Next to the old results, you see "Unprimed+Debug" and "Primed+Debug." These series show the difference in page load times when you simply forget to set "debug" to false. From these results we learn a few things:

• On average, across browsers, debug = true makes initial page loads 27% slower
• On average, cached page loads are 23% slower
• Firefox is again the poor performer
• Initial page loads are almost 40% slower in debug mode with IIS!

The obvious point: don't deploy applications with debug still set to true! You can hurt application page load time by 25% if you miss this.

Convenient and slow
Do you remember when Visual Studio didn't have a web server built-in? I know it's been a while now, but there was a day when every web site developed in VS had to be manually setup in IIS just to see it run. Thankfully, those days are behind us and the Visual Studio Web Sever (originally Cassini) has made the process of quickly building and testing web sites as easy as a single keystroke.

While Cassini is great for rapid application development, it's far, far from being the robust ASP.NET server that is IIS. I think all ASP.NET web developers understand this fact casually (we'd never try to run an ASP.NET website in production on Cassini- if it were even possible), but I don't think the difference between Cassini and IIS performance is well understood- especially in the context of page load time with ASP.NET AJAX. To make that difference clear, I ran another batch of tests, this time testing page load times in Cassini, still with debug set to true.
As with the debug chart, this chart compares our baseline page load times to page load times for our test page (in debug mode) served by Cassini. The results are pretty dramatic:

• Firefox- even the new and improved Firefox 3- shot page load times through the roof
• On an unprimed cache, pages load 91% slower (FF2 & 3 avg.)!
• On primed, pages still loaded 72% slower
• Across all browsers, pages loaded on average 50% slower
• Excluding Firefox, pages loaded an average of 20% slower in IE7 & 8

So what? What are supposed to do about a slow development server? Nothing, really. The point here is that you should never make judgments about how long it takes your page to load if you're using Visual Studio's Web Server. When pages are in debug mode (which they usually are in Cassini), your page load time could take more than twice as long in development than it actually will in release mode served by IIS.

Optimization Tip Summary
This tip doesn't really provide you with anything you can specifically do to the RadControls to make them load faster, but it does drive home important points about measuring the performance of your pages that use the RadControls for ASP.NET AJAX. Now that you've seen the actual impact of compilation debug and the Cassini web server on page load time, you know that they can have a dramatically terrible impact on your page's performance and thus on your perception of the RadControls. Always make sure you test performance using IIS with pages running in release mode to get an accurate picture of how your pages are performing.

If you practice this tip, combined with the Rad Managers talked about in part one, and future optimization tips in this series, you'll be guaranteed to see page load times that make you smile- not scream!