Here’s an idiom that I think would be useful in C#: “property methods” in the style of jQuery.

There are many methods in jQ – html(), val(), width() – that are getters when they are called without an argument, and setters when they are. This makes for some very nice fluent code:

$(“#someElement”).width(“100px”).html(“hello there”);
window.alert(“The width of #someElement is ” + $(“#someElement”).width());

I’d love to be able to do this in C#, to bring in some of that fluency and terseness. For example, I currently have to write:

myPerson.FirstName = “Joe”;
myPerson.LastName = “Smith”;
myPerson.ZipCode = “12345”;

The code smell here is that I refer to myPerson 3 times. Don’t you just wanna say “Yeah, I get it, myPerson, sheesh.” Wouldn’t it be better to write:

myPerson.FirstName(“Joe”).LastName(“Smith”).ZipCode(“12345”);

Of course I could implement the above with overloads and private fields. But I shouldn’t need to do that much notation.

I think it can be done in C# without new keywords. Simply allow methods to have get and set bodies:

public class Person
{
public string FirstName() { get; set ; }
public string LastName () { get; set ; }
public string ZipCode () { get; set ; }
}

The compiler would interpret these much like regular properties, backed by (automagical) private fields, with the caveat that a passed value invokes set. The setter returns the parent object, giving us the fluency.

And as with properties, you could add bodies to get and set as you desire, where the value argument is implied for set.

Overall, this is the equivalent of:

public class Person
{
public string FirstName()  // getter
{
   return _FirstName;
}

public Person FirstName(string value)   // setter
{
   _FirstName = value;
   return this;               // the fluent bit
}

private string _FirstName;   // backing store

//…and repeat for each property
}

Again, I could write my classes this way. But that would be so much boilerplate, uninformative code. Please compiler, do it for me.

Progressive Enhancement is a methodology where a web application is developed in layers. Each layer works correctly on its own, and additional layers on top enhance the user experience.

The justifications for Progressive Enhancement are usually around graceful degradation – people using older technologies are not left out in the cold, while better technologies are exploited for more cutting edge users.

And that’s fine, but there are more compelling reasons to use PE, in my opinion.

Easier debugging

When developing a modern web app, there is a good chance you’ll want to use Ajax. This allows parts of a page to updates incrementally, so the whole page doesn’t need to redraw.

But what if something breaks? The user clicks and nothing happens. Is it a Javascript error, a CSS thing, or is it a problem on the server?

Using PE, you can avoid these mysteries. First, develop the app to work reliably without Ajax. This means focusing on the HTML experience – button clicks that actually submit forms and links that actually go to a new URL. Debug that to the point that you know the server-side is reliable.

Then, sprinkle Ajax on top. Intercept the clicks and submits, and route them to your Ajax bits. At that point, if something doesn’t work, you can say with reasonable confidence that the problem is client-side.

Here’s a tip: use the same “end point” on the server for both Ajax and traditional requests. (In MVC, this would be the controller action URL.)

The end point should perform the same business logic regardless of whether the request is Ajax or not – so don’t write that logic twice. Instead, you simply vary the end point’s response format depending on the request type (Json instead of HTML, say).

Javascript can fail silently

Proponents of PE will tell you that you need to support users that don’t have Javascript enabled (because they’ve disabled it deliberately, or they are using a downlevel browser on a mobile phone).

That’s valid. But, it’s also an edge case.

The greater danger is that your Javascript will have unforeseen bugs. In most browsers, this simply means that the JS will stop executing without notice. What happens then?

If you’ve authored the non-JS experience correctly and separately, then the experience should fall back to the plain HTML experience. Graceful degradation is an insurance policy for our shortcomings, too.

Division of labor

Each of these layers (JS, HTML, server) is a specialty. If your site gets big, you might have separate people working on each. Make sure the jQuery guy and the server girl can work independently.

Keeping up the discipline

Over time, it’s easy to forget the HTML experience, since your Ajax stuff works so well. Remember, each time you want to add a new feature, stick with the above methodology.

Turn off JS in your browser. Develop the feature. Test it thoroughly. Then, turn JS back on and go to town.

I recently had a chat with a peer/CTO-type who has argued before Congress on net neutrality. Got me thinking again. Even though I made these arguments in the mid 00’s (in a more, um, polemic venue) I thought it might be worth revisiting.

http://www.flickr.com/photos/mutantlog/ / CC BY-NC-SA 2.0

(Legislated) Net neutrality preserves the Internet like bugs in amber

The idea of legislating the flow of bits over the Internet strikes me as saying, we like the Internet the way it is now, please don’t let it change.

But we don’t know what the Internet is, or what it “should” be. Certainly, no legislator willed Google or the iPhone into existence. Few people thought that pushing TV shows or real-time audio was an appropriate use of the web in the early 90’s.

The Internet is an essentially emergent medium. We don’t know, a priori, what will and won’t work, what should and shouldn’t be.

And so, to say what private companies can and can’t do with their pipes is to foreclose future possibilities. Perhaps Verizon will only be a provider of dumb pipes. Or perhaps they will invent something crazy that consumers love, but which doesn’t adhere to our 2010 concept of “neutral”.

In fact, maybe we’ll chuckle at the quaint term “ISP” in 10 years time. Maybe a retailer like Wal-Mart will sell broadband. Maybe an advertiser will build its own network. Seeing “content” and “delivery” as separate things, and believing that it must always be so, lacks imagination.

To put it another way: should we have passed a law 10 years ago forbidding Amazon from selling anything besides books?

I’m not arrogant enough to say what the 2020 Internet “should” be. Are you?

Regulation is great for dinosaurs

Here’s the thing about regulation, especially at the federal level: it benefits the big guys.

A high regulatory bar means higher costs of compliance – more lawyers and more lobbyists. Big companies can absorb costs like that, while upstarts can’t. Advantage: incumbents.

And this is to say little about regulatory capture, wherein established players with fortunes to protect work hard to ensure that legislation is written in their favor. Do you know why Wal-Mart supported the federal minimum-wage hike a few years ago? It wasn’t goodwill.

Wal-Mart can afford a higher minimum wage. The local Mom and Pops against whom they compete, can’t.

And so, AT&T et al will accept net neutrality if they see it as inevitable. At that point they will pivot to ensure that the legislation is onerous enough to handicap would-be challengers. And in 10 years, we’ll have the same duopoly.

If you’d like to see the Goliaths slain, create the conditions where it’s easier to be a David.

Yes, we have a last-mile problem

There is not enough competition for the “last mile”, i.e., consumer Internet access. This is a legacy problem which we need to overcome.

We are still emerging from 80 years of state-sponsored monopoly in telecoms. The Bell companies and the cable companies were given essentially exclusive rights to run copper and coax for a long time.

We are emerging. Cable companies now offer phone service. Phone companies offer TV. Both of those things used to be illegal. Now the terms “cable company” and “phone company” are becoming anachronistic.

But we are not there yet. A friend works for Verizon (as a vendor) and I wondered why, in the middle of Manhattan, I cannot get FIOS on my block. His short answer was, Verizon needs special permission from the city to install new service, block by block and neighborhood by neighborhood. (I subscribe to Time Warner, my only option.)

Two competitors is fundamentally different than one. And yet, we have a regulatory legacy that makes competition illegal. And if some politically-unconnected upstart wants to run a fiber to my building, ha! Good luck.

Net neutrality is intended as a salve for this lack of competition. But the last-mile problem is the result of the same sort of (well-intended) lawmaking.

Let’s focus on lawmaking that actually enhances competition by removing barriers for companies that want to build networks – even those that can’t afford lobbyists!

I understand that net neutrality sounds like a cure. It’s time to recognize that it’s actually a recurrence of the same disease.

We have January browser numbers. Firstly, we note that Internet Explorer 8 is now the most popular browser, overtaking IE6.

“Modern browsers”, as previously defined, are now around 60% of the market. Chrome (my fave) gained 0.57 percentage points, which represents a 12% gain in user base.

Firefox stayed approximately even, with a slight downward trend, for the second month in a row.

IE6’s trend of loss leveled off a little bit, to 0.92 percentage points, or 4% of its user base for the month. Adrian Kingsley-Hughes needs to educate himself as to why people use old browsers. “UPGRADE PEOPLE!!” is a swing and a miss.

Today, Google announced that it will begin phasing out support on older browsers, most notably IE6, for Google Docs. It will take this step with Gmail and Calendar later in the year. This is a big step.

There has been much debate about the best way to handle browser obsolescence. On the one had, newer browsers offer a great improvement in user experience and web application capabilities. On the other hand, many people continue to use old browsers, largely because they don’t have other options.

Google has done this math and is making a pretty bold move; Google Apps are used by a lot of corporate clients, which is where legacy browsers tend to persist.

Google is making the calculation that they will not lose business over this. I imagine that IT departments really like Google Apps and so many will be on board – given the choice between upgrading their users’ browsers (and dependent apps) vs. going back to Exchange or Notes, they will choose the former. And you can bet that no IT people use IE6 on their own machines.

It might be a harder sell when dealing with legacy line-of-business apps that depend on ActiveX or which were authored for IE6’s quirks. The business people may be less forgiving. It’s not without risk.

At this point, in 2010, I support the effort. Not simply because I am developer who wishes other people would use the latest and greatest – remember, not everyone is a techie and they have legitimate reasons for not wanting to spend time on this crap (hi Dad!).

Developers (like me) are getting a free ride on this – Google and IT departments will play bad cop while we enjoy a better platform for our work. So I find it hard to complain. :)

I like the concept of e-books, if not their current state-of-the-art. The Kindle device sounds very impressive, I’ve only played with them a bit, and I know they have a lot of devoted fans.

One thing that gets underplayed is that “Kindle” is not simply a device, it’s Amazon’s e-book platform. So instead of spending $300 on the device, I am using the free Kindle for PC application. (There is also an iPhone version but jeez, that’s pushing it in terms of readability.)

Amazon has decided it’s not going to restrict its e-book effort to a particular piece of hardware – instead, it’s a “Kindle everywhere” strategy. I wonder – will Apple do the same?

In other words, when (if) Apple introduces their publishing-oriented tablet, will they simultaneously announce that you can get the e-reader software on your PC? There is a precedent – it’s called iTunes.

I suspect that this publication platform will use iTunes as its hub, and treat publications just like the media it already handles – books and magazines alongside songs, movies and podcasts. You can play those media on your PC just as easily as you can on the iPod. (And if they put it in the cloud, all the better.)

If this comes to pass, you’ll be able to take advantage of the tablet’s e-reader functionality, without buying an expensive, first-generation device. Win.

So, I’ve been going a little Ajax crazy lately. I am using a progressive enhancement approach – make everything work solidly without Javascript, then drizzle on some Ajaxy goodness as refinement.

One problem is, on an Ajax-driven page, your user “loses” the use of the back button. It’s caused a mismatch between what the user and the browser consider to be a “new page”.

You’ll note that in your Ajax page, when the user clicks to a new “page state”, the URL doesn’t change. Now the user and the browser have a different concept of “last page”. And so, if the user hits the back button, they will be taken to the last URL, not the last “page” as the user understands it. That last URL might have been 10 clicks ago.

In trying to work around it, I found the problem to be surprisingly complex. But I’ve found a life-saver of jQuery plugin that solves exactly this.

It does two things: first, it changes the URL on every Ajax click. Second, the plugin “records” the page history in a hidden frame. So now your browser sees each page state as a new page – just like your user. The back button magically works.

This also provides the advantage of deep-linking: each Ajax page state gets its own URL, so you can link directly to that state. Brilliant.

I did a little test. I am using jQuery UI’s dialog, and setting it to be draggable. Pretty standard stuff – after all, dragging windows around your computer is commonplace.

A quick look into task manager and I see that dragging that modal around spikes the CPU to around 50%! (And this is with Chrome, an exceptionally fast browser.) Doing the same with a simple Windows file window pushes the CPU to only 10%. Further, the modal is always a few pixels behind the mouse, which feels sloppy to an end user.

Why does the browser need to work so hard to do the “same” thing? Well, the browser has no idea what a modal is. It simply knows that there is a chunk of HTML that is changing position. And so, with each microscopic change, the browser must recalculate the entire page’s layout, probably dozens of times per second. As with other jQuery tricks, we are hammering the DOM.

The goal of Google and other browser makers is to push performance so that Web apps feel like native apps. Of course, we need to keep browsers capable of working with standard HTML/JS/CSS – ignorant of the goals of that code – but certainly there are optimizations to be found.

Here’s one: a browser should infer when an HTML element is on a z-index that does not affect other parts of the DOM. It should then know to minimize the reflow redraw when that element moves. This would require many fewer layout calculations and CPU cycles.

Of course, this inference is easier said than done. It would need to look at all the z-indexes of all elements on the page, CSS position attributes, possibly some widths. (The browser maker might document that list of requirements, so that libraries could be optimized against them.) But once the browser makes this determination, the modal should perform at close to native speed.

Maybe it can’t be done. Maybe there is no correct determination of “independence” for one piece of the DOM.

But it would be interesting to find out. Dialogs and windows are such a fundamental part of UI’s and user experience that this would be a modest, yet substantial, step forward for the Web.

It appears that the hack against Google was perpetrated via their law enforcement compliance system.

As an eminent group of security experts argued in 2008, the trend toward building surveillance capability into telecommunications architecture amounts to a breach-by-design, and a serious security risk. As the volume of requests from law enforcement at all levels grows, the compliance burdens on telcoms grow also—making it increasingly tempting to create automated portals to permit access to user information with minimal human intervention.

In other words, Google (and other comms companies) are required to build systems for providing wiretaps to government authorities.

That’s like catnip to hacker. If you want to reveal secrets in a system, target the area that’s designed for revealing secrets. Brilliant.

Hat tip to Sarah Lacy for laying it out so well:

Google is ready to burn bridges. This is not how negotiations are done in China, and Google has done well enough there to know that. You don’t get results by pressuring the government in a public, English-language blog post. If Google were indeed still working with the government this letter would not have been posted because it has likely slammed every door shut […] This was a scorched earth move, aimed at buying Google some good will in the rest of the world; Chinese customers and staff were essentially just thrown under the bus.

Google is a self-interested company. Self-interested companies know that righteousness and bridge burning do not sustain successful businesses. Therefore, the company must have come to the conclusion that their business in China is not a successful one.

Google is hovering under 20% in market share in China. They are losing to Baidu. Seems to me they’ve already made a business decision to back out, and are cynically using that fact to drum up some PR sympathy.

I have no complaints about embarrassing the Chinese government; any gov’t really. But Google’s been compromising with the Chinese authorities for a long time. Why are they so upset all of a sudden, now?

I am sure that someone is trying to hack their systems, as the company claims. But I bet that someone is trying to hack Google, all day, every day, in every country of the world. This time set them off? Please.

I happen to agree with Google’s initial decision to enter the Chinese market under less-than-ideal circumstances. For the Chinese people, some Google is better than no Google. It creates a foothold for future openness. It was bold – they could easily have not tried.

But the current situation is not a passionate reaction to an outrage, and there is no mention of what’s best for Google’s Chinese users or employees. This is making the best of a bad situation by scoring a few points with the digerati, of which you and I are a part.

Don’t be evil? Start with sincerity.