The IE team published an in-depth post over the weekend, raising a few concerns about StatCounter’s methodology (or lack thereof) for reporting browser market share. Their points were interesting to consider, but one of them stood out to me:

You’ll notice some pretty big differences in the weighting of StatCounter versus Net Applications. First and foremost, the most populous country in the world, China, doesn’t make the top 20 for StatCounter, when in fact it represents the world’s largest internet population.

[...]

To further explore this problem, we re-ran the StatCounter numbers and weighted their publicly reported individual country browser share numbers by the CIA internet population data. This calculation would then represent a true country or geo-weighted view of worldwide browser data based on the actual world’s internet population.

It’s true that we should be wary of methodology issues that can creep into data extracted from analytics services that weren’t designed with aggregate statistics in mind. StatCounter’s data is often accepted at face value, without any detailed scrutiny. However, I believe this geo-weighting approach they’ve explored may be as flawed as the raw, unadjusted data itself.

Click here to read the rest of this post »

There’s been some confusing back and forth lately about ASP.NET Web API and JSON. During the time between the last WCF Web API preview and the current ASP.NET Web API beta, it’s clear that effort has gone into smoothing out some of DataContractJsonSerializer’s (DCJS) quirks. However, while things like DateTime and Enum deserialization have been improved, issues have still persisted with Anonymous Types, Dictionaries, and DateTime serialization.

Unfortunately, the underlying cause of those remaining issues was too fundamental to simply spackle over. One of the most frustrating aspects of DCJS is that it’s rooted in WCF’s mindset that all things can be expressed as XML and then translated to other formats. In that world, data like Anonymous Types and simple collections of key/value pairs are uninteresting oddities. So, as long as ASP.NET Web API is saddled with DCJS, it’s at a disadvantage in scenarios requiring more flexible JSON serialization.

Click here to read the rest of this post »

Note: If you haven’t read my initial impressions of the Zenbook, you might want to head over and read that first: The ASUS Zenbook UX31: Initial impressions

I’ve been using my ASUS Zenbook for just over a month at this point, and it’s time for a second review now that I’ve used it for a while on a day-to-day basis. I’ve heard from many of you about being eager to read the next installment in this process, so I’m glad to know that you’re finding this experiment useful too.

Click here to read the rest of this post »

There’s been a bit of controversy lately concerning the rising dominance of WebKit-based browsers (e.g. Chrome, Safari, and Mobile Safari) and the potential that we’re repeating past mistakes:

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely… IE6 is gone, the problem is back.

However, I believe there’s one gigantic difference between IE6 then and WebKit now that’s being overlooked.

Microsoft put the brakes on Internet Explorer development after IE6 because they realized that they were helping build the runtime for their own competition. If Internet Explorer releases had continued at the same pace, most everyone would probably be using IE15 today and IE6 would be as memorable as Chrome 4 or Firefox 7.

Conversely, Google has a vested interest in Chrome’s ongoing success (and WebKit’s success by extension). Instead of threatening Google’s primary revenue stream, WebKit and Chrome serve to enhance Google’s golden goose. So, unlike the past situation with Microsoft, Netscape, and IE6, Google has no motivation whatsoever to shutter active development on Chrome and WebKit if it overtakes Internet Explorer and Firefox.

Does that make vendor prefixes and targeting experimental features a great idea? Maybe not. Frankly, I’m not qualified to speak intelligently about cutting edge CSS features.

What I do know is that just because the current climate seems similar to the one ten years ago, that doesn’t mean it’s reasonable to assume history is repeating.

One of the hardest parts of being privy to NDA information is keeping my mouth shut about new developments that I wish I could share with you immediately, often for months at a time.

Recent developments around ASP.NET Web API (formerly WCF Web API) are a perfect example of that conundrum. As development on WCF Web API seemingly stagnated on CodePlex, Microsoft had actually rolled the project into ASP.NET itself. The project was in no danger whatsoever, but (frustratingly) I wasn’t able to tell you that.

So, it’s a relief that today’s today’s ASP.NET MVC 4 Beta release has made that news public:

Top Features

• ASP.NET Web API
• Refreshed and modernized default project templates
• New mobile project template
• Many new features to support mobile apps
• Recipes to customize code generation
• Enhanced support for asynchronous methods

Though Web API isn’t necessarily a gigantic step forward from using MVC’s controllers as a makeshift API for simple scenarios, it’s great that ASP.NET now has common mechanism for creating these endpoints that works the same way on both WebForms and MVC.

I’ve long held out against pressure to move from ASMX to WCF in WebForms projects, because accepting WCF’s complexity primarily only rewarded me with less flexible JSON serialization. By contrast, I’ve begun converting some of my projects from ASMX to Web API, and have been pleased with how easily Web API replaces ASMX.

I believe Microsoft has finally found a good balance between ASMX’s simplicity and WCF’s power with Web API.

Since it was built with jQuery in mind from the very start, I’m finding that Web API is perfect for the sort of work that I usually write about here. It even automatically responses to requests from jQuery with JSON, even if you use simple URL encoded parameters with the request, so adding an endpoint for AJAX interaction in either WebForms or MVC is a breeze now.

I’ll be writing more about actually using Web API here in the future, but I wanted to get this post published right away to help spread the news that Web API isn’t dead.

To learn more about what exactly Web API is and does, have a look at its section in the release notes. To get up and running quickly with some example code, take a look at the new Web API material on the ASP.NET site.

I took part in The Code Project’s A Coder Interview series recently, and the result was published there yesterday. Terrence happened to send the questions at a rare moment when I wasn’t running in five directions at once, which led to me accidentally writing quite a bit.

Part of it touches on something important to me that I plan to write more about eventually:

What advice would you offer to an up-and-coming programmer?

Write about programming. Start a blog, answer questions on The Code Project or Stack Overflow, or whatever else suits you, but find some way to write about programming.

I can’t count how many times I began writing about something I thought I knew thoroughly, only to find that I had to fill in several important gaps in my knowledge to write about it competently. Just as important, you have to learn topics more comprehensively to distill and teach them in simple terms. The combination of writing about programming and making that writing as clear and simple as you can is a powerful exercise.

[…]

The interview also exposes my shameful stance on tabs vs. spaces, but you’ll have to go there to read that part…

Click here to read the full interview at The Code Project

For over a year now, I’ve been using a 13” MacBook Air as my only laptop. Though it’s a bit underpowered and I prefer Windows to OS X, I was ultimately unable to resist Apple’s build quality compared to the Dell I had used previously.

However, I never fully resigned myself to accepting a dichotomy between quality construction and operating system. Thankfully, the recent proliferation of Windows-based Ultrabook™ machines seems to be rapidly bridging that divide.

Given my already-growing desire to find an alternative, when I was contacted about reviewing the ASUS’ Zenbook UX31 Ultrabook™, I decided to give it a go. I know I’m not alone in having been frustrated with a choice between machines that run Windows well and quality hardware, so I hope that you’ll find my experience of trying to move back from the MacBook hardware useful.

Disclaimer: Up front, I want you to know that I’m receiving a complementary UX31 in return for evaluating it and writing a few posts about that experience. I’ll give you my honest assessment of it and only recommend it if it meets my own standards, but I also think it’s important to be transparent and not potentially abuse your trust.

Click here to read the rest of this post »

Hey Dave, is there a way to create an event handler so when .tmpl() is done it will fire a function? I’m trying to make it global, so I was hoping I could say, when ANY template gets done, do this…

The question of how to retroactively add hooks before and/or after a pre-existing JavaScript function executes is one that comes up from time to time. Whether it’s a simple method like tmpl(), a server-generated script artifact, or a function in a third-party script, sometimes it’s desirable to alter a JavaScript function without access to change the original declaration of the function.

One of the handy things about JavaScript is that you can combine its functional and dynamic aspects to make surprisingly quick work of tasks like this one. Doing so is fairly straightforward, but it involves an approach you might not consider if you’re more familiar with languages that lack JavaScript’s unique features.

In this post, I’ll briefly cover a few examples of how to “patch” existing JavaScript functions with callbacks. We’ll begin with simple examples, then address an issue that stems from applying this approach to jQuery plugins, and finish with a more elegant way to handle the problem of patching functions that accept parameters.

Click here to read the rest of this post »

As I ponder the title of this post, I’m conflicted.

I clearly remember writing last year’s post and thinking that it didn’t seem like four years could have possibly passed since I started publishing here. As I write this one, I find myself feeling like it’s surely been much longer than five years.

I guess you could say 2011 has been a long year?

Relativity aside, this week saw the fifth anniversary of the night that I hastily threw this site together and published my first post. So, I guess it’s that time again.

Click here to read the rest of this post »

Work on client-side applications long enough and it’s just about inevitable that you’ll eventually want to make an AJAX request that breaches the browser’s XMLHttpRequest security restrictions. Limitations on cross-domain requests are great when they’re preventing malicious sites from malfeasing, but are a thorn in the side when they complicate your legitimate applications.

Traditionally, direct communication across the same-origin boundary required using a rickety (though clever) workaround called JSONP. JSONP is a reasonable compromise if all you need to do is make blind requests to a third-party API like Twitter, but comes up short if you need to use any HTTP verb other than GET. Of course, that’s a deal-breaking issue when you’re working with ASMX ScriptServices or ASPX page methods.

Luckily, a relatively new feature has been making its way into browsers which provides a robust solution to the cross-domain AJAX problem: CORS.

In this post, I’m going to show you how to recognize exactly which requests are cross-origin, how to enable CORS for your ASP.NET site, and the extra configuration necessary when you’re working with ASP.NET’s JSON-enabled services.

Before we get started, I want to emphasize that this approach won’t work with any version of IE prior to IE10. If supporting older versions of IE is a requirement in your target environment, you’re stuck with something like JSONP or a server-side proxy. This will work in any version of IE if Chrome Frame is installed and enabled by your site/server though.

Click here to read the rest of this post »