Saturday, February 27, 2010

When you spend your professional life at a computer, there are tasks that you repeat many times a day. Checking email. Responding to email. Writing code. Testing code. Showing the desktop. Individually, each task only takes seconds and seems relatively insignificant. But combined, our little repetitive actions can waste significant amounts of time.

We can regain massive amounts of productivity by saving seconds at a time.

Take, for example, replacing a mouse behavior with a keyboard shortcut. On the surface, it seems like a simple matter of preference. Some people prefer the mouse; some the keyboard. Switching from the keyboard to the mouse, though, has a time penalty. You’ve got to reposition your hand twice (move to the mouse and back to the keyboard), you’ve got to visually scan your entire screen to locate your “click target,” and then you’ve got to precisely move the mouse to the target and click. For common tasks, this can all be done in a few seconds, but it is almost always slower than what could be achieved with direct keyboard shortcuts.

So what? What’s a few seconds? Let’s do the math:

If you can save just 2 seconds on a task you do (let’s say) 30 times a day by learning the keyboard shortcut, you save:

In a day, 1 minute

In a month, 20 minutes

In a year, 4 hours

In a 30 year career, 15 work days!

Just saving 2 seconds a day will give you back 15 working days over a career! And that’s just you and just one keyboard shortcut. Let’s expand the math to imagine a dev team of 5 people saving 20 seconds with 10 keyboard shortcuts for common tasks performed about 20 times a day. Savings would be:

In a day, 33 minutes

In a week, 3 hours

In a year, 17 work days!

In just one year, a team that commits to saving 2 seconds on 10 common tasks can reclaim more than 3 weeks worth of productivity. Do you see what I mean? The seconds add-up quickly!

A personal challenge

I challenge you to join me in reclaiming your time. Find one task you’re doing everyday that “requires” you to use the mouse and find a way to replace it with a keyboard shortcut. It doesn’t have to be a big time savings to matter. A simple savings of 2 seconds is all you need to start making a difference.

A keyboard shortcut for .NET web developers to get you started

I’ve always been in the camp of keyboard shortcuts are nice, but not a big deal…until I did the math. I don’t know about you, but I want my time back. One task I always seem to be doing via the mouse when doing web development is “View in Browser.” I’m easily wasting seconds here every time I have to use the mouse to do this.

There is an easy fix. Map “View in Browser” to a keyboard shortcut:

In Visual Studio, go to Tools > Options

Under the Environment section, click on Keyboard

Type “File.ViewInBrowser” in the Show Commands textbox and select it

Click in the “Press shortcut keys” textbox and input your desired shortcut (I used Cntrl + ` since it’s easy use and not taken by Visual Studio or JustCode)

What are your favorite keyboard shortcuts that save you seconds everyday?

Friday, February 26, 2010

My how time flies- I almost forgot to mention my trip to the South Florida Code Camp tomorrow! This will be my 3rd consecutive trip to Southern Florida for this event, and every year it is a great time. Hundreds of .NET developers show-up early on a Saturday morning for a full day of geek learning. This year there are 12(!) parallel tracks, covering everything from "Intro to .NET" to SharePoint to Agile development topics.

I'll be doing two sessions this year, both in the ASP.NET MVC/Frameworks track:

8:30 AM - Being Productive with the Telerik Extensions for ASP.NET MVC

1:20 PM - ASP.NET Fundamentals: ViewState Tips & Tricks

Neither session is "brand new," which should mean they'll run on time and be more refined than sessions fresh off the press. Both sessions have been very popular at previous conferences, too, so if you're attending SFCC, come early to get a good seat.

I'll be giving away Telerik swag, of course, with at least 1 Telerik Premium Collection at each session. I'm not beyond bribing you to attend. Everything starts tomorrow, Saturday, February 27th at 8:00 AM at DeVry University in Miramar. Telerik is a Gold Sponsor of the event, too, look for more Telerik swag to show-up at the end-of-day raffles and attendee bags.

Best Practices for Building Site CSS Templates

If there is one thing that every modern website needs, it’s a good CSS foundation. Cascading Style Sheets are the core layout and styling tool for standards-based web development, and when used correctly, they not only help improve performance, they also help improve accessibility and SEO.

Don’t Use Tables for Layout. Embrace the (more) semantic web.

If you’re still using tables for overall site layout, stop. This is an outdated practice, riddled with problems, and the valid excuses from a few years ago that CSS is too hard no longer hold weight. A high quality website should aim to use semantic HTML whenever possible, especially when doing general site layout.

What is “semantic” HTML? Put simply, it means you use HTML that describes the content it contains.

For example, an ordered list (ol) tag should be used for lists of items. An image tag should be used for images. A div tag should be used for “dividing” areas of the screen. A table should be used for…tabluar data. When applied properly, almost every element on a page can be rendered semantically and then styled with CSS. A menu or tabstrip, for instance, should be an order list of items (not a bunch of divs). And if you use the RadControls, you’re already there…can’t help myself.

Why does all of this matter? Isn’t it simply a “religious” debate? No. There are practical reasons to follow this guidance

Semantic HTML is typically more concise than HTML that is used for layout, meaning smaller, faster loading pages. Faster loading because there are fewer bytes to download and fewer HTML elements for the browser to process as it renders the page (the more important factor with modern bandwidth).

Since semantic HTML often “offloads” all styling and layout information to external CSS sheets, performance is further boosted by the cachability of external CSS.

Semantic HTML is indexed better by search engines. Since the semantic usage of HTML conveys meaning about its contents, search engines can better understand which parts of your page are less important. Content, for example, should be given greater index value over navigation. It’s not “web 3.0’s” vision of a giant semantic web, but it is a valuable step.

Along the same lines, semantic HTML is easier for screen readers to parse, thus making its usage more accessible.

Guidelines Are Not Commandments. Bend the rules when you need to.

Sometimes a quick table for laying-out a form is easier to use than CSS. It’s true. With today’s CSS standards, lining-up columns can be tricky. Can it be done with CSS? Absolutely. Is it still easier with a table. Generally, yes.

The goal of CSS-based web design and semantic rendering is to make those situations where HTML is used for layout the rare exception and not the rule.

Save time with CSS frameworks

Programming with JavaScript today almost always starts with a framework. Whether it’s jQuery or Microsoft Ajax, very, very few people continue to write “raw” JavaScript. Why?

JavaScript doesn’t provide a lot of “high level” helpers. Frameworks do and save you time.

The same is absolutely true for CSS. Browsers are notorious for processing CSS differently, and that is how CSS has earned such a painful reputation. Fortunately, CSS is being made fun again with easy to use frameworks that abstract the browsers and make CSS layouts easy. Popular options include:

BlueprintAnother very popular CSS framework deployed on many sites. Unlike YUI Grids, which is based on special CSS classes that help you divide DIVs in to areas, Blueprint prides a CSS “grid” of columns and rows. Positioning content is a matter of simply using the Blueprint CSS rules to position your content in the right column/row. Blueprint also includes typography and form styles, so you get a bit more than layout if you want it.

YAMLIf you prefer a commercial solution, YAML is one of the few CSS templates that is also available with a commercial license and support. There is a free version, but it requires the display of links to YAML in your site template. Otherwise, it’s another robust framework with a visual tool for configuring CSS layouts.

With a good framework, CSS is easy and your site template can be constructed- cross-browser ready- in minutes.

From Concept to Production Ready Template (in hours)

Whether you’re doing a 2-day Give Camp or consulting project, you don’t have hours (days?) to waste on troubleshooting cross-browser CSS. Here’s how Team Telerik managed to go from concept to functional, cross-browser CSS site template in a few hours:

Whiteboard – sketch ideas and start conceptualizing the site’s layout

Mock-up – This is a bit optional for a 40-hour Give Camp, but a must for any other project. Convert those whiteboard ideas in to a collection of mockups. This process forces you to think critically think about your site and always uncovers additional requirements. Balsamiq Mockups is currently my favorite tool for this job.

Create at least 2 design concepts – Pop open Photoshop or (if you have a Mac) Pixelmator and come-up with a couple distinct design ideas. Don’t stop with your first idea even if you think it’s great. The process of working through two designs ensures your final design will be stronger. If you get stuck, browse the web for inspiration. TemplateBox and TemplateMonster are good inspiration starting points.

Build CSS layout with framework – Here I would use YUI Grids to build my basic CSS layout. That process will spit out the starting HTML and CSS that my site will need.

Build your site MasterPage – Now add that HTML and CSS to your “base” MasterPage (nested MasterPages are your friend).

Start customizing CSS – Now that your base CSS and HTML are set and your site layout is ready to work cross browser, you can start customizing with your colors, fonts, and images. Start chopping-up your Photoshop designs to get the CSS background images you need. And don’t forget to create CSS sprites when you can for maximum optimization.

Perfect CSS with Firefox and Firebug – One of the best tools for rapidly testing changes to CSS is Firebug. You can quickly dial-in your CSS design to perfection. And if it looks right in Firefox, it will mostly look good in Safari, Chrome, Opera, and IE7+. That just leaves IE6 for some special testing if you have to support it (and you really shouldn’t these days).

And that’s it. While it looks like a lot of steps, the most time consuming will be all of the steps before CSS. The CSS will be fast and easy and you’ll wonder why you were ever afraid of it.

CSS and the standards-based web are not hard. Stop letting people tell you that they are. They were. But so was JavaScript before jQuery. With a good CSS framework and this simple workflow, you’ll be successful getting your site template ready- 4 hours or 40 hours.

Tuesday, February 23, 2010

This week’s weekly webinar is special. It will deliver one of your first “sneak peeks” at some of the new functionality shipping in the rapidly approaching Q1 2010 release (scheduled for mid-March). The Thursday Weekly Webinar will provide a complete overview of a brand new tool shipping with the RadControls for WinForms in Q1: the new Visual Style Builder for WinForms.

The new Visual Style Builder is a completely new tool, not a minor upgrade of the old VSB for WinForms. It dramatically simplifies the process of creating custom themes for the RadControls for WinForms, and in so doing unlocks more of the power built-in to the Telerik Presentation Framework. I’m not often a WinForms developer, but when I saw the new VSB, my first reaction was that we had built Blend for WinForms. It’s impressive.

Monday, February 15, 2010

In part 1 of this ongoing series, we looked at how you lay a solid foundation for your project with planning. In part 2, we introduced the idea of thinking with tools. That is, during the design phase, expanding your developer creativity and ability by including known features from professional .NET developer tools in your web site design.

Building Software as a Team in TFS (with Sitefinity)

There are (generally) three types of software development:

Individual – it’s just you and your genius code

Small Team – You see them. They see you.

Big/Multi Team – You didn’t even realize your project had code that did that

The need for source control for each of these groups is present, but the motivations are very different. Individual developers often use source control as a simple way to remember what files they’re changing between releases and to have an insurance policy against local system failures or changes that require a rollback.

As soon as you are more than one person, though, source control becomes an essential productivity booster. So essential, in fact, that even for a 2 day website project, we relied heavily on source control.

Use source control when you need it

Especially for a fast project with a small team, sometimes its faster to work outside of source control. What? It’s true.

Here’s the deal: when you’re rapidly prototyping and building a website, it’s usually much faster to work on your small components in an isolated, focused ASP.NET website and then add your work to TFS once you’ve got your component working on its own.

This is very true for a solution with many projects, or a solution built on Sitefinity. You often don’t need the configuration hassle or build-time of the “big project” just to work on your own sliver of functionality. And since Sitefinity is based very “cleanly” on ASP.NET, you can just use a scratch ASP.NET website and “normal” ASCX user controls to quickly build and test something like a custom module before adding it to the master project. It can save you hours.

Here’s the workflow that we used for most of our Sitefinity development:

Each team member had their own copy of Sitefinity and OpenAccess ORM(IMPORTANT: Make sure each team member has the *same version* of whatever tools you’re working with. This will save headaches later.)

Each team member working on custom modules simply built and tested them in their own local environment. Most team members didn’t even use Sitefinity until they had a working UserControl in a “plain” ASP.NET website. Don’t introduce complexity until you have to.

As custom modules were completed, they were integrated in to the “main” Sitefinity website in TFS, which was a simple process of copying ASCX files, sometimes copying some DLLs (or external libraries), and updating the web.config.

As major updates were ready, we would FTP all changes to the staging web server.

Schema changes were handled in the dev environment by the OpenAccess build step (we used forward mapping for our custom objects). To deploy them to staging, we used RedGate tools.

Be careful with Web Sites in Source Control

We had one disaster with source control that cost us a few hours during WAM weekend. Sitefinity 3.7, as you may know, uses the Visual Studio Web Site “project” type. The Web Site project is based on the file system and technically does not have a “project” file. That makes Web Sites easy to work with on their own, but they are potentially problematic when other project file-base projects are added to a solution.

It so happened that part of our team had built a couple of class libraries. Not realizing that the default items in source control for a “web site” lacked a solution file, they added the class library projects to the website. This hosed our solution file.

After a few hours of trying to clean-up the mess, we had this realization:

Source control, when used correctly, saves your team time. Source control, when used incorrectly, can destroy your team productivity with a single check-in.

Lesson? Be careful with web sites. If you can avoid website projects, do. Web Applications are much more reliable in Visual Studio. If you can’t avoid website projects, make sure you add your other projects correctly to the solution file.

One more Sitefinity Special Consideration

If time is short, don’t add the Sitefinity folder to TFS. It has literally thousands of files. Checking those files in and then subsequently checking them out is a time consuming process. It’s actually much faster to just give each member of your team the Sitefinity folder that they can add locally for testing code from TFS.

The Sitefinity folder should be a “static” resource. You shouldn’t generally need to change the files in that folder. Upload it once to your staging site and leave it.

Eventually, you’ll want to add the Sitefinity folder to your repository so that it’s easy for new team members to check-out and work with your code, but in time strapped events like Givecamp, you may be better off following this advice.

Work Items and better teams

In 40 hours, there isn’t much time for creating work items- we relied on a big whiteboard to cover that task. In the real world, though, a big whiteboard isn’t the best way to create and track work items. TFS provides work item support, but the default Visual Studio tools for working with these items remind you that VS is a coding tool.

Work Item Manager is a tool from Telerik that helps you be as productive with managing your work items as JustCode is at making you productive with your code. And we offer it as a free tool for everyone! If you’re working with TFS and you haven’t checked WIM out, I’d really like to know why. It’s a great way to maximize the productivity of your team…when you have more than 2 days to work on a project.

Okay. Enough boilerplate conversation. On to some of the implementation details. In the next part, I’ll talk about how CSS frameworks save you tons of time and why you should be using one. We used one. Find out which one in part 4.

Friday, February 12, 2010

JustCode, Telerik’s new Visual Studio productivity tool, continues to march towards its official v1 in the Q1 2010 release. The next major milestone in its journey dropped today: JustCode Beta 2. This release addresses many of the bugs that you have helped report over the last few months and it introduces some cool new functionality.

Among the most important enhancements in this release: support for Visual Studio 2010! This is something I’ve been waiting for now for a while and I’m very excited to add JustCode to my VS2010 experience. There are a few known issues with 2010, but we’ll continue to polish our support for Microsoft’s new IDE leading up to its official release in mid-April.

Some of the new features I find most interesting in this release:

New “Type Assistance” that automatically adds closing braces/brackets

New refactorings moving classes to new files and renaming files to match type names

Ability to set global filters for files that shouldn’t be analyzed for errors

In part 1, we looked at how you lay a solid foundation for building a website on a very tight timeline. Planning, no matter how long you have to work, should not be “skimped” on.

Mapping requirements to deliverables with tools in mind

Requirements communicate what your client or charity want to be able to do with their website. As a web developer, you have a few choices for how you go about turning those requirements in to a schedule of work for your team. You can:

Build everything by hand, delivering only exactly what is defined in the requirements

Use tools and services to cover requirements where they make sense

When working with users to gather requirements, especially non-technical clients or users, you often need to listen past what they’re saying and try to think about how they will interact with your features when the project is done. For example, take this simple requirement:

Many developers would barely stop to think before dropping a few textboxes on a page, wiring them up to a submit button, and then sending an email with the collected info. Meets the requirement, but is it enough? Is that what the evolved professional .NET developer should be delivering today?

Thinking with Tools

When you have a professional developer toolbox, you gain an entirely fresh perspective on what can be accomplished in a project with limited time. In our example above, a toolbox lets us say during the design phase:

The users want a contact form. Easy. We can not only deliver a contact form, we can deliver a form, with validation, that can be edited at any time using a simple, visual form-editing tool, that can even be reused for any other data collection purpose on the website.

In short, tools turn “No’s” in to “Yes’s” at not extra cost to your project.

When you have tools you know how to use, and you understand the capabilities of those tools, you can deliver way more than expected to your clients. And since tools, like Telerik’s Premium Collection, make it easy for you, the developer, you can spend more time polishing the custom features tools don’t cover.

Designing with Tools

Now that you’re thinking with tools, you go a step further and design with tools. Instead of designing in loose terms, you can plug-in specific tools with known capabilities and quickly get past basic scenarios. Features previously considered “extra effort,” are now “free” because they’re automatically provided by a tool. Or, at least, free to you.

Just as the wide availability of light fixtures, doors, windows, and home automation systems frees an architect to design a more impressive house, tools for .NET developers help you build better software.

Challenge

Next time you start designing a project, try thinking with the Telerik Premium Collection. Review the online demos now, get a sense for all the features built-in, and then watch during your design phase how many places you can quickly improve or enhance a feature with built-in tool features. It will feel like cheating, but it’s not.

Tools used during WAM

To build our charity’s website, we relied heavily on tools to provide superior experiences and to maximize the amount of control we could put in non-technical users’ hands. We wanted to make it possible for non-technical users to have the power to update almost any portion of the site after the project shipped- from email templates to the site header and footer.

Tools we ended-up using:

SitefinityThis was the huge platform time saver. More than half of our team had never developed with Sitefinity before the 40 hour dev sprint began. Two of our team members had only casual experience with ASP.NET. We still delivered incredible results in 2 days, as did all other teams (there were more than 10) that used Sitefinity that weekend. Right out of the box we were able to give our users control over pages, content, templates, and permissions. And with a simple Module system, we quickly added custom business process support, support for customizing email templates, and many helpful page controls for performing tasks like embedding YouTube videos on a page.

RadControls for ASP.NET AJAXThe RadControls actually ship with Sitefinity, so it was natural to use these to extend our website. Built-in features like exporting to Excel and RadEditor’s Word-like content editing gave us quick wins in our project.

OpenAccess ORMWe wanted to be as productive working with our custom data as we were with our UI, so we used OpenAccess ORM for all our custom modules. Again, half of our team was new to this tool on day one, but working productively within hours.

WuFooCool service that let’s non-technical users build and edit forms that can be embedded in a website. We used this service to empower our users to have unlimited control over forms in the future.

KimbiaOur charity wanted to accept donations, and they didn’t want to use PayPal. Kimbia is like a specialized PayPal service focused exclusively on helping sites collect donations.

Now that we’ve finalized our requirements and completed our design, with tools helping us deliver on our ambitious 2 day goals, it’s time to start coding. In the next part, we’ll talk about building websites as a team in TFS.

Thursday, February 11, 2010

I rarely post highly off-topic posts to Telerik Watch, but I’ve come to recognize that every now and then, an off-topic post can be refreshing. There are a few things that we as professional software developers interact with on average for more than 8 hours a day:

Our chair

Our keyboard/mouse

Our monitor

Our computer

Our (computer) desktop

It’s important that each of these things be optimized for your comfort so that you can focus on being a great developer/designer/evangelist/computer person. And of all of these, the easiest to change and optimize is your desktop wallpaper.

Is there a perfect desktop wallpaper? No.

Everyone has their own wallpaper taste. [SIDENOTE: Why do we still call these images “wallpapers?” Wouldn’t “Desktop Background” be more appropriate? Legacy words…] For me, I like wallpapers that are simple and abstract. I like wallpapers that don’t strain the eye by being too bright, or distract the mind by being too busy. Like you, I’ve used many wallpapers in the past, but here’s my current top 5 (including a custom Telerik Wallpaper):

If you’re working with Telerik Reporting, or if you’re thinking about working with Telerik Reporting, I’ve got good news. There are now four new videos on Telerik TV just for you, including the recording from today’s Reporting webinar! To help you find these resources quickly, here are some quick links to Telerik TV:

There are more great videos for Reporting in the pipeline, so check back next week for even more Reporting help. If you’re new to Telerik Reporting, don’t forget to check-out the online demos, too. There are some basic videos there that help you learn how to configure various reports.

Welcome to the first part of a multi-part series on Telerik Watch describing the process for building an impressive website in 2 days. In this series, I am going to share tips and tricks, along with some real world stories, for building a high-quality, usable website that supports critical business processes in less than 48 hours (if you’re working on WAM Weekend Time).

The purpose of this series is two-fold:

If you’re going to participate in a Givecamp, this advice should help your Givecamp team deliver incredible results in the short 2-day period you have to work

If you’re just interested in comparing your website building process to someone else’s, this series may highlight ideas and approaches you’ve overlooked in the past

Along the way, I’ll highlight best practices for building standards-based websites, different tools and frameworks that “Team Telerik” used at We Are Microsoft 2010 to be successful, and, of course, how the Telerik tools helped us do weeks worth of work in two days.

Pre-planning

If you’re going to participate in a Givecamp, or meet with a client for that matter, you need to do some pre-planning. You need to do some research about the people you are about to serve and try to understand their motivations, their expectations, and- critical for web development- where they’re coming from with their existing website.

The goal of pre-planning: create a list of intelligent questions.

If you can have a focused list of questions prepared for your first meeting with your charity (or client), they will have infinitely more trust in your ability to deliver high quality results. It’s like a job interview. A good interview may get you the job, but a great interview will get you the job and a signing bonus.

Requirements

There is very little I can offer on the subject of effectively gathering requirements that has not already been archived somewhere on the web. What I can say is that even in the environment of a Givecamp (or any other time constrained project), detailed requirements gathering is critical. Make sure you spend time getting answers to your pre-planning questions and really try to understand the key goals of your client’s project. Charity or not, failure at this step makes everything that follows much harder.

How much time should you spend on requirements at a Givecamp?

This will obviously vary by team and charity, but Team Telerik did not start touching code until nearly 10:00 PM on day one. We spent a solid 4 to 5 hours meeting with our charity, discussing our objectives, and mapping out our requirements for the weekend. When all was done and said, we had a huge whiteboard that defined our key deliverables, and that served as our road map for the weekend. It also served as the informal contract between our team and our charity for what would be delivered by the end of the weekend.

From our high-level objectives, we started mapping out the specific features and actions that our website would need to support. We also started to identify the tasks that would require extra research or the features that would “Nice to Haves,” but maybe not feasible in 40 hours.

Time to start coding? Nope. Not yet.

Work Smarter, Not Harder.

Now that your requirements are clearly defined, you need to start planning for the execution. Some developers would suggest that means you’re at the point where you start writing tests or code, but if you’re a “work smarter, not harder” developer, that means you want to fully evaluate the tools, services, and frameworks that already exist and that can help you do more in less time.

A great developer does not write every line of code in an application by hand. A great developer knows how to find and use great tools, only writing code where it creates unique value for the project.

With that in mind, stay tuned for part 2: Mapping requirements to deliverables with tools in mind.

It's always an honor, then, to see your efforts recognized in a significant way. Telerik was recognized in a big way by being named to the Red Herring Global 100 list for 2009. The Global 100 lists the top 100 private tech companies in the world. Last year, Telerik placed on the Europe 100, so this year's jump to the Global list is a huge step forward. In the past, companies like Google, YouTube, Skype, and Yahoo have been recognized with this award (and we all know where those companies are today). Other recognized companies on 2009's Red Herring lists include Parallels, Twitter, and Ustream.

Of course, none of this is possible without your continued support and feedback. We drive our business in direct response to your input, so keep it coming. With our new PITS system and some exciting plans for 2010, we're confident that this will be another big year for Telerik, and I can't wait to be part of the progress.

In the mean time, thank you for your support. And thank you to Telerik for taking the bet on me more than 3 years ago. Here's to our continuing global domination in the name of making .NET developers more productive!

Wednesday, February 03, 2010

Here's a handy tool I stumbled upon this week: SQL Profiler Express. While not a web-based tool, it's still handy. It's a small (1.5 MB), free, open-source Windows application that provides SQL Profiler-like features for SQL Express 2005 and 2008. Somewhat ironically, the project is hosted on Google Code and not on Codeplex, but the software runs exactly as advertised.

For those not familiar with SQL Profiler, it is a tool from Microsoft that normally installs with full versions of SQL Server. It allows you to essentially "sniff," or "trace," all of the communication with an instance of SQL Server that you have permission to access. It is a very helpful tool for seeing what's really happening at the database level when debugging or optimizing your application. For example, you can use profiler to see exactly what SQL is being executed when you use OpenAccess ORM or LinqToSQL.

Unfortunately, SQL Profiler does not ship with SQL Express. Kind of a bummer since most .NET developers these days install the Express tools on their local dev machines. Enter SQL Profiler Express.

The tool provides most of the key functionality that you need as a developer from the "full" SQL Profiler, and as I said before, it works exactly as advertised. Point it at a SQL Server Express instance, define your trace parameters, and start watching the SQL activity. In some ways, I even prefer it over the real Profiler since it is small, lightweight, and provides a focused set of features.

Add it to your developer toolbox and be sure to thank the developers for contributing this to the community.

Tuesday, February 02, 2010

If you develop for the web, you know IE6. The default browser that ships with Windows XP is the bane of any "standards-based" developer. For public web site developers, it adds days- if not weeks- to development cycles for testing and tweaking site functions to work in the ancient "broken" browser. If you work in a company still running XP and IE6, you may not notice the problem today, but eventually your sites will have to say goodbye to IE6, and with that transition will come your introduction to the pain the rest of the world has suffered.

Many famous sites have already reduced support for IE6, calling it "unsupported" and providing a reduced or "non-guaranteed" experience. Apple, Facebook, and YouTube are some of the higher profile examples to-date. Now Google is turning-up the heat.

I received an email as an administrator of a Google Apps for Domains (Google's business-oriented service platform for its apps) account that included the following message:

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.
We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

In short, Google is ending support of IE6 for it's major business apps, like Gmail and Google Docs, this year.

This will clearly help accelerate the end of IE6's relevant market share, but it also opens some critical questions. Why doesn't Microsoft adopt the same aggressive stance for its own web apps? For Silverlight? Do you need to support IE6 in your own public web apps?

While we can all hope for a day when web standards will unify to a level that we can really embrace the power of HTML5, Telerik will in the mean time continue to support IE6, as we recognize that some of you may be "trapped" in IE6 organizations. This obviously adds a fair amount of overhead to our own development process since it makes adding new features more difficult, but we are committed to supporting the needs of our customers. While the rest of the world calls IE6 unsupported, Telerik continues to work hard to help you support it if you must.

But what do you think? Is IE6 still relevant to your development? Or can we all agree to join Google and make 2010 the year we say goodbye to IE6? Let me know. I'm always listening.

This week's Weekly Webinar puts me back in the driver's seat to take you on a tour of some very cool tools in Telerik's open source Extensions for MVC. We'll be taking an extended look at the web asset optimization components, ScriptRegistrar and StylesheetRegistrar. These tools have been around since the beginning of our efforts with MVC, but they have been significantly improved with the evolution of the Extension suite. In this webinar, we'll dive-deep and explore the various ways these two components make it easy to embrace the four "Cs" of web optimization:

Combine (reducing initial requests)

Cache (reducing follow-up requests)

Compress (reducing bits over the wire)

Content Delivery Network (reducing latency to bits)

If you're working with MVC, this will be an event you don't want to miss. The techniques I will demo will make it possible to optimize your JavaScript and CSS resources as much as technically possible. We'll also explore the new Telerik CDN (with support for MVC), and cover some future-looking topics about the next release of the Telerik Extensions. It will be a fast-paced, info-packed, Todd Anglin signature webinar.
If you want to join, register now to save your spot and get a link to the live event. You must attend live to participate in the Q&A, and that is often where some of the best info gets shared. The live event happens this Thursday, February 4th at 11:00 AM EST (8:00 AM PST, 4:00 PM GMT). See you on Thursday!

Featured Posts

Quick Updates

Quick Updates

Subscribe

What platform did you primarily develop for before Silverlight?

About Telerik Watch

Telerik Watch is dedicated to previewing, reviewing, and demoing the .NET UI controls and developer tools from industry leading vendor, Telerik, and to keeping you up-to-date on the most important news in the .NET community.Subscribe in a reader now.

About Todd Anglin

To avoid sounding creepy, I won't describe myself in the 3rd (or even 4th) person. I am Telerik's Chief Evangelist and general all around "community guy." I started this blog as a customer, before joining the company, and now enjoy the best job in the world- helping deliver the good news of Telerik to people around the world and helping Telerik build cool, useful products. I am President of the North Houston .NET User Group, an O'Reilly author, and a Microsoft MVP.