Joel Varty

UX Fail: IE 9

2011-07-29T13:23:19Z

The people who designed IE 9 did a poor job of copying Chrome’s nice and clean interface.

Why oh WHY would the little button to change into compatibility mode (which shouldn’t be necessary at all) be the same size as the refresh button? And why does the “stop” button never go away?

It’s all just wrong. And IE 9 STILL causes layout issues all over the place. Chrome, Firefox? No problem, they update every few weeks with nary an problem that has even come close to the shitstorm that happens after an IE update.

Unacceptable.

I will only ever use it for testing.

more later – joel

Azure SDK 1.3: Error on Web Role Publish…

2011-01-26T15:21:33Z

If you get this error:

The "TransformXml" task failed unexpectedly.
System.UriFormatException: Invalid URI: The URI is empty.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString)
   at Microsoft.Web.Publishing.Tasks.TransformXml.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)

Check the web.config of any of your web roles for malformed XML – it could have been tweaked without your knowing it. Here where my problem was:

<mailSettings>
         <smtp deliveryMethod="Network" from="My Site &amp;lt;support@mysite.com>">
                  <network host="123.server.net" port="25" userName="123" password="abc" />
         </smtp>
</mailSettings>

See it? The email address in the from attribute has a > in. Nasty. Switch that thing back to > and you should be good to go.

more later – joel

Azure Deployment - Be careful adding a Remote Desktop connection to deployments that you want to swap staging with live…

2010-12-07T15:46:24Z

Adding Remote Desktop capability adds an external endpoint onto the deployment, meaning it may have more endpoints that your current live deployment. When there is a difference in the number of endpoints between a staging and live deployment, you can’t swap them in the Azure portal. Oops.

So you have to the remote capability to your live deployment first if you want to do this…

more later – joel

Error 400 with WCF REST Services

2010-11-17T14:15:45Z

I recently worked on a site that had a strange issue where “sometimes” the WCF service (JSON encoding) that we accessed via JavaScript (using jQuery) was throwing an HTTP 400 error. Setting a breakpoint at the web method itself was useless as it would never be hit.

Well, it turns out it was a simple problem – WCF throws this error internally (via the JSONP Encoder) whenever a parameter cannot be parsed into the correct type. In this case, an int parameter value was being read from a cookie that was returning null. Changing the code to pass a -1 instead of null worked just fine. In retrospect, it might even be smarter to pass the paramters as strings and parse them yourself. At least that way you can control what formats are allowed and, moreover, you’ll understand what the devil is going on!

more later – joel

Razor + Agilty will be a match made in heaven

2010-10-20T13:22:42Z

I just finished reading Scott’s post on ASP.NET MVC 3 and the new @model key in Razor and it got me thinking about how we could change Agility module output templates to support MVC with strongly typed partial views based on the module definition. That way, you’d get intellisense in Visual Studio based on the types that are autogenerated from the Module Def and the definitions of any linked content.

Combine this on the backend with the ability to read any of the data on the front end in json or xml with OData and all of the sudden your Agility is unlocked and ready to rock.

more (much more) later!

joel

Server Controls vs Plugins

2010-09-23T15:07:15Z

I think the ASP.NET world has changed completely as far as reusable code is concerned.

Let’s start with a bit of background…

Server Controls

I remember when making reusable code in ASP.NET meant writing custom server controls that had all kinds of logic for outputting complex html based on simple templating. Heck, remember? I still write and use these things all the time!

But wait a minute, what’re the server controls I hate the most? Grid. ListView. Menu.

What’re the ones I use the most? Repeater. Placeholder.

What the… ? The server controls I use the most DON’T EVEN OUTPUT HTML. All they do is provide a way of controlling the output of HTML that I put into the markup myself.

That’s the key to a good server control: CONTROL. I mean, what good is a control that outputs a <table> tag when you want it to output an <ul> tag? No good at all, I say.

Plugins

I remember a time when I scoffed at Microsoft’s implementation of DHTML behaviors in IE (I think they first appeared in 5.5). I knew that the idea was profoundly useful in theory, but the DOM traversing and manipulation capabilities were so browser specific, not to mention the fact that they only worked in IE anyways) that it never had a chance.

But what was the idea behind “Behaviors?” It was intended, in my opinion, to add interactive functionality to existing markup. This includes the ability to inject additional DOM elements and unobtrusive Javascript events into a set of elements that were included in a given behavior.

“But Joel,” you say, “this is what a jQuery plugin does!”

Totally, I know. Awesome idea, huh?

Reusable code in Repeaters and Plugins

Now, when I write a server control, it follows this pattern: Repeater + Plugin = Control.

Let’s take the example of site navigation. Often, it’s useful to ouput this as a series of nested <ul> tags, which each page in the sitemap represented by a <li> tag. This looks some what representative of the site structure when viewed with no css or interactivity – you see all of the pages in the site.

Now, you could (and should) control a lot about how those lists look based on CSS rules. You can give the first level certain formatting, and, for example, hide the sub-levels. But how do you show the sub levels on mouse-over or click? This is where the plugin logic comes in. You can write a jQuery plugin to control the behavior of the <ul> and <li> elements based on user input, and it can all be done without including Javascript inside the markup (no document.write() or any crap like that).

Where is this leading?

I am saying we shouldn’t be relying on crazy server controls to magically output html and Javascript to make pretty websites and apps.

May ASP.NET developers hate this idea – it means they have to actually think about the markup that will be produced by the stuff the put on their pages and user controls. “Our world is crumbling!”

Well, I say suck it up – we should have paying more attention to client markup and less to server markup for the last 9 years or so.

.Net without the ViewState

This is what I want to see! This is why MVC is so cool, but most .Net developers will continue to ignore it, so what do we do? Think about the pattern of Repeater + Plugin = Control

I have one last suggestion to you, in the form of a challenge: in your next project, take out the <form runat="server"> tag from the page or master page. It will FORCE you to stop using control that rely on viewstate, and these are almost ALWAYS the ones that output crazy html and inline styles that suck when you want to have control over your markup.

more later – joel

Amazon adds CloudFront API for content invalidation

2010-09-01T13:20:53Z

Good news from Amazon this morning as they have announced what I’ve been asking for – an API for content invalidation. Previously, they allowed content to have a max-age of 1 hour, but it didn’t allow for the control that a manual invalidation would have. According to the press release, the API call will allow for the removal of files from all edge locations. A set of files can be removed as well.

“Invalidation requests for the first 1,000 files each month are provided at no additional charge; above this level, there is a $0.005 charge for invalidating each additional file.”

This is great news on 2 fronts:

It’s a great feature that was missing from an already solid product.
It’s a sign that Amazon is listening to it’s customers and providing updates without deprecating existing APIs.

Here’s a screenshot of the API call from Amazon’s CloudFront developer documentation:

via Amazon Web Services

more later - joel

VS 2010–Fix for hang on debugging ASP.Net 3.5 Apps…

2010-08-26T18:41:41Z

Just got this in an email from Microsoft:

Greetings from Microsoft Connect!
This notification was generated for feedback item: VS 2010 - Hangs when debugging ASP.Net 3.5 web application or website which you submitted at the Microsoft Connect site.
Hello,
The fix for this is now available for download and install from https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30738&wa=wsignin1.0
or
http://code.msdn.microsoft.com/KB2106584
Best Regards,
Visual Studio Debugger

Note: The fix for this issue was packaged with the fix for another issue, the KB article currently only lists the other issue, but this download does contain both fixes
You may receive a general "Feedback Item Updated" notification as well, if any other changes were made by Microsoft.
Thank you for using Microsoft Connect!
Regards,
the Microsoft Connect Team

more later – joel

Getting comfortable with Javascript callbacks

2010-08-26T13:28:09Z

It seems every language has it’s own way of implementing callbacks.

Back in the VB days (daze?) we used the addressof operator and all kinds of win32 stuff to get app and activex control to do what we wanted.

In C#, we have the delegate (and the anonymous delegate) that makes life pretty easy in terms of defining how to subscribe to a callback “even” and how to broadcast that callback.

Javascript callbacks are the simplest, and arguable the more nebulous, implementation of them all. Once you understand how callbacks work, using libraries like jQuery, and our own UGC Javascript API becomes much easier.

Why do we need it?

Think of the way code normal iterates from line to line. It’s straightforward and simple: you loop over a list, and at the end of the loop, you keep going; you use an if statement, and after that you know that the condition has been met; similarily, when you call a method, you know that it has done all of its work and returned something useful. Right? Well… not always. Sometimes that method will invoke web requests that need some time to process, or it may call another method that has to do some processing or is waiting for user input… These kinds of operations can be implemented asynchronously, and the only way to manage that logic programmatically is with a callback parameter.

How does it work?

A callback parameter on a Javascript method is essentially passing a reference to the enter function definition into the method so that the method can call that function when it needs to.

Here’s an example:

function doSomething(callback) {
    if (somecondition()) {        
      callback(true);
    }
}

function entryPoint() {
    doSomething(function(yesOrNo) {
       //do something else
    });
}

Let’s assume that the entryPoint() method is being called first. It calls doSomething(), which in turn exits right away. The only way that the entryPoint method will know what the doSomething method wanted to return is to pass in a function as a callback, and take the return value as parameter. In this case, it’s a boolean value, but it could be anything (or more that one thing).

A lot of the useful methods in the jQuery library use this logic, especially the unobtrusive event handlers on buttons or links.

$("#btnSubmitForm").click(function(e) {
    e.preventDefault();
    //do something
});

Notice how the click method takes a function parameter, which in turn has a “e” parameter with the event data from the button click.

Now let’s look at how Urls can be invoked asynchronously (remember the first letter of the AJAX acronym is asynchronous).

$.ajax({
  url: 'path/handler.ext',
  success: function(data) {
     //do something with the data
  },
  error : function(request, errorType, exception) {
     //handle the error
  }
});

You’ll notice that this implementation is a bit different – the ajax method from jQuery is passed an object that has several fields defining how that method is meant to behave. The first one here is the Url, which will be invoked. Then we have 2 separate functions that are passed in – one for the success condition that is passed the data that was returned from the Url handler, and another with the error condition.

There is also a way to invoke the ajax method synchronously, such that it blocks the calling method until the web request handling is complete, but that may cause the user’s browser to appear frozen if the request takes a long time, so be super careful with this one.

var html = $.ajax({
  url: "filepath.ext",
  async: false
 }).responseText;

There are lots of other things to consider when using callbacks in Javascript. Mostly, you’ll need to be able to quickly refer to whatever documentation is available so that you can determine with the expected parameters and fields are for each callback function itself.

more later – joel

Twitter OAuth Authentication with TweetSharp

2010-08-12T14:11:14Z

The Twitter API is something that you may have learned to love and hate over the last while, but as of August 16th, you may have to change the way you access it.

Basic Authentication is Going Away

Previously, the easiest way to authenticate a Twitter app was to ask for a user’s credentials and pass them directly to the Twitter API in the Authentication HTTP Header. This is, incidentally, how any site that uses basic authentication behaves. Your credentials are passed in a base64 encoded string in the header on EVERY request. Encoded – not encrypted. So if the site isn’t using SSL (and Twitter doesn’t) you could be exposing credentials to anyone who wants to sniff them.

Twitter has acknowledged this fact, and has provided an OAuth alternative based on an open and accepted standard of token based authentication. Up until now, though, the OAuth standard has not been enforced, since it was more of a development hurdle for folks who just wanted to get their work out there and were willing to accept the risk of sniffed credentials.

The OAuth Authorization and Authentication Process

What do we mean by authorization versus authentication? Authorization is the process by which an end user of your Twitter app (if you haven’t created one of these yet, do it here) will allow it to access their account. This is done in a browser window, and the user, once they’ve clicked “Allow Access” will be presented with a short PIN sequence will they will have to copy and paste or enter manually into your application. Given that PIN, your app will have the ability to create (and store) an OAuth Token and Secret that will allow your app access to that Twitter account until access is denied.

Every request you send to Twitter (either for new status updates or for queries) should have that token provided as a credential. This will mark any status updates with your application’s name and provide a link for other users to go to your application URL.

Here the Step by Step Process for Authorization

Create a Twitter App
- keep track of your Consumer Key and Secret, you’ll need these
Generate an unauthorized token
Generate a authorization and direct your user’s browser to it
Give your user the opportunity to enter the PIN into your app
Generate the authorized token and secret
Persist the token and secret

TweetSharp and other OAuth Libraries

In its own OAuth FAQ, Twitter mentions that you really shouldn’t tackly OAuth with raw HTTP requests (although you can if you want). The fact of the matter is that there are lots of different wrappers written for OAuth itself, which could in theory be used with any standard OAuth provided (Google and Yahoo also use OAuth) as well provider specific wrappers written to give you a high level access to the logical functions of the system you are accessing.

TweetSharp is a very nice .Net API for Twitter, but it’s authors have based it upon another library that they built, the more generic Hammock which they are still actively developing. Apparently nobody has been helping them build TweetSharp, so they are leaving it for the community to work on from now on.

One of the things that TweetSharp makes super simple is the generation of the Tokens and Authorization URL that I outlined above.

First of all, download the TweetSharp API and add a reference in your app to the TweetSharp and TweetSharp.Twitter assemblies.

The follow code snippets are all that you need after that:

using TweetSharp.Model;
using TweetSharp.Twitter.Extensions;
using TweetSharp.Twitter.Fluent;
using TweetSharp.Twitter.Model;
using TweetSharp.Twitter.Service;

//generate the token and url that will we need
OAuthToken unauthorizedToken = service.GetRequestToken(twitterConsumerKey, twitterConsumerSecret);
string url = service.GetAuthorizationUrl(unauthorizedToken);

//TODO: get the pin from the user

//once you have the pin from the user, build your authorized token
OAuthToken authToken = service.GetAccessToken(twitterConsumerKey, twitterConsumerSecret, unauthToken, pin);

//store the authToken.Token, and the authToken.TokenSecret

//make an authenticated call
var service = new TwitterService();
service.AuthenticateWith(twitterConsumerKey, twitterConsumerSecret, syndicationService.OAuthToken, syndicationService.OAuthTokenSecret);
if (service.Error == null)
{
    TwitterStatus status = service.SendTweet(value);
}

TweetSharp also has some nice documentation on this process, and a couple of different methods that you can do it here.

more later – joel

JavaScript Compilation: Is this what will turn the web into the new desktop?

2010-07-23T13:21:06Z

The Web is the New Desktop

Can we finally expect to see web browser truly competing with native apps?

IE 9 does JavaScript in the background on the first load of a page, running in non-compiled mode until the scripts are ready, and then they run from the native commands after that. It is detailed here on the IE MSDN blog. They talk about going beyond the benchmarks, which look like this:

Going beyond the benchmarks means thinking about how the web page as a whole responds to the user in a practical way, and JavaScript performance is just one part of that. Frankly, this is kind of ironic coming from the teams that put out IE7 and 8, because they talked about the same things when those things were introduced. I think the problems with the legacy IE codebase is exactly that – too much legacy bloat.

Most of the gains you see with IE 9 are about the JavaScript compilation happening on a second core, and hardware acceleration. Ars Technica covered that here.

But IE isn’t the only browser going that way – Google is putting 2D acceleration into Chrome 6 and the Mozilla team are getting it into Firefox for HTML5 elements.

Mobile Web is the New Desktop

On the phone OS side of things, Android 2.2 introduces a similar behaviour to what IE 9 is doing with JIT (Just In Time) compilation.

Currently, I am using an iPhone or iPad for mobile browsing, so while I can’t compare performance to Android, I certainly welcome the competition.

Also, it’s useful to note that the Blackberry 6.0 OS will be using a webkit based browser, so that’s reassuring. Coding for Blackberry browsers is a real challenge at the moment.

What does this all mean? It’s a great time to be a web developer, but don’t sit on your laurels! CLient side programming in the browser is getting a whole lot more interesting.

more later – joel

jQuery Code Snippets for Visual Studio 2010

2010-07-21T18:30:15Z

These are just genius. I especially like the one for adding an AJAX call to an asmx, which is always a pain.

http://jquerysnippets.codeplex.com/documentation?referringTitle=Home

There is a quick demo of them here.

Type in jqajax, and follow the intellisense…

Gives you this…

Nice time saver. The plugin template is good too.

more later – joel

Programming for APIs

2010-07-20T13:42:29Z

There seems to be as much or more attention paid to “Apps” these days as there is to websites. Whether it be for iOS, Android, Blackberry, Adobe AIR, Silverlight or even the (gasp) Desktop, we as “web” programmers are often called upon to implement APIs for these things.

Sometimes it’s in addition to a website, and sometimes it’s a stand alone API that is only meant to service a specific need for a specific app. In either case, it’s a good bet that can easily get cornered by the temptation to do what you’ve done before. Usually, for Asp.Net folks, it means a simple asmx or (better still) a WCF service that can be controlled through configuration. Either of these choices is fine, but if you are just envisioning the scope of what you are doing, you need to step back from the actual implementation details and ensure that the functionality you wish provide from this API is not reliant on the service technology itself.

Just start from a basic data API, but keep in mind that everything you are working with may need to be stateless. That means no session state, no reliance on cached values (since your code could be deployed to a web farm) and no (or few) global variables. Once you’ve cut all the crap and spaghetti code from what will become your data access layer, you can be left with a set of simple methods that take some parameters and return an object or collection of objects.

Sounds easy to test, doesn’t it? That’s the point! You should be able to test the whole API before you even decide on whether the service is SOAP, JSON, ATOM or whatever. I recommend you do that. One thing to note, is that I would be wary, at this point, of copying and pasting code from “getting started” tutorials. By all means, read those tutorials and understand what they are doing, but don’t feel that you have to jump into one technology or some pattern that doesn’t resonate with you after playing around with it. Sometimes a standard data layer with static methods and custom objects calling custom written stored procedures in a database or writing files or whatever, is better than relying on some generic layer of logic like LINQ-SQL, Entity framework or nHibernate. Not that I’m saying you shouldn’t use these technologies, they can make your life MUCH easier and speed your implementation process up greatly. But it can also introduce unnecessary complexity into what should be a simple process of moving data from one tier or layer into another. Always remember that simple is better, and anything you don’t understand isn’t simple because you won’t be figure out what’s wrong if it breaks.

When you come to your objects that will store the data, be wary of using object that are creating by another framework like LINQ-SQL or Entity framework. These objects are sweet as a starting point because you don’t have to worry about all that typing, but you may run into situations where the serialization required by your specific object on a specific service protocol will need customization that you can’t do in a partial class. I won’t go into specifics here, but if you don run into the situation where you need to create your own custom objects, don’t hesitate. Just do what you need to do to ensure you understand how your objects are being created, serialized and de-serialized. It will be simpler and more reliable in the long run.

Now you’ve got a data access and/or a business logic layer that you can test, and you should go ahead and do that before you start implementing the service itself. You probably won’t, but knowing that you should have will help out later.

At this point, if you can, use Asp.Net 4.0. If you can’t ask yourself why not. Ask everyone why not. Do some research on WCF in .Net 4.0 (the biggest kicker is that in .Net 4.0 you don’t need to worry about multiple host headers screwing with your service). If folks won’t listen to you, start arguing and argue with all your might that you need to code this API in Asp.Net 4.0. Trust me, it will be worth the time you spend convincing yourself and them.

Now, make a decision and either code the thing for OData or simply implement it in WCF. Those are the only real choices that make sense, as far as I am concerned. WCF lets you do REST style APIs or SOAP style without re-coding everything, but OData is better. Why OData? Do some research on that too, and you’ll find out that in the real world, your API will be most useful in one of two formats: XML and JSON. OData does XML in Atom format, so it’s inherently readable in most browsers. OData lets you flip to JSON or JSONp without messing with your API. WCF is OK, but OData, if you can get your head around it, tends to be much better.

Oh, and OData in .Net 4 is implemented as WCF Data Services. It used to be called ADO.Net data services.

There are also a ton of client SDKs for OData, but XML is so easy to consume, your API consumers will be able to see the value of your API with just a browser.

That’s the real point – with a well written, simple and testable data layer, and OData on top of that, your API services will be reliable and elegant to use. Folks will WANT to use APIs that are easy to understand and reliable.

more later – joel.

Thoughts on Azure – Compute, Storage and SQL

2010-06-22T13:50:10Z

I think Azure is ready to go as a platform for a Software as a Service platform. When we think of cloud-based infrastructures, it has many pieces that make it both viable and attractive from many points of view. For one, it’s hooked tightly into a great development tool in Visual Studio 2010, and the latest SDK and Tools make it a simply process to publish to the cloud directly from the IDE.

On top of this, you can also hook into your Compute and Storage account right from Visual Studio Server Explorer windows, which is nice.

So what is Azure, really?

I attended a technical briefing for Microsoft partners in Toronto last week, and this was the biggest question. I think there is a lot of misconception out there about what is offered and was is possible with Azure.

Windows Azure - Compute

To be quite blunt, this is primarily meant for Web Apps and Web Services, with the Compute platform tailored to what are called “Web Roles” and “Worker Roles”. These can ONLY to be coded in managed code, however they can invoke executables written in whatever language you like. Basically, a web role is a web app, and do pretty much anything a web app can do. A worker role is akin to a windows service, and if you’ve coded your windows services with decent separation of concerns, you should be port one of those over with no difficulty.

The real power of the Compute platform is that is allows you to manually ramp up the number and size of Instances (read: Virtual Machines) that you want the app to be deployed, both for Web and Worker roles. This means you can flip a config variable and ramp up the power without ever calling IT or touching any routers or load balancers or anything. If you have a multi-tenanted app, this is nice. If not, if you have a an app that’s is single-server, uses a ton of session, is coded like the tutorials, and isn’t meant to be publically available… you might want to reconsider if you need a cloud solution at all.

What’s really good here is that, as of June 2010, .Net 4.0 is supported in Compute.

Windows Azure – Storage

Table Storage – this is really “entity” storage (I know, I know, kind of the same thing), but really this is just a serialized object repository which the ability to be queried in OData style using the Data Services API. Basically, you can dump objects in and get them out again. It has automatic partitioning based on a partition key, meaning this is very scalable. What stinks about it right now is that it only supports a pretty small subset of the OData (and therefore Data Serviecs) specification.

Blob Storage

Blobs equal files. You can do block (sequential, or streamed) blobs or “paged blobs”. These are not good names, but who cares? The biggest annoyance is that it isn’t as good as Amazon S3 (yet), except that it’s stored in the same environment as your Compute instance(s), meaning that you don’t pay for data transfer to and from the Compute and Storage. You only pay for data transfer in and out of Azure itself.

Queue Storage

A queue where items live for up to seven days, 8kb string max. Useful for implementing a multi-instance worker role pattern where the web roles create items in the queue and they are processed by an offline worker role. These are not MSMQ, but they are still wicked useful.

SQL Azure

Databases in the cloud. Great! Except that you can’t do Table partitioning based on filegroup, which is major pain. The only way to scale is to do what is called database sharding. I’m hoping I can hold out until we can do something less useless. I don’t want to rewrite app code and join data in my data access layer. That defeats the purpose of SQL Server at all.

To be continued…

Windows Azure AppFabric

The most important thing about Azure AppFabric is to know that it is NOTHING like Windows Server AppFabric. Which is too bad – because there isn’t yet a decent solution for distributed caching Azure Compute… a real shame.

All in all, Azure is the real deal, and you’d do well to research this carefully – the naming of the technology has changed over the last 18 months and there is as much misinformation and rumor out there as anything else. If in doubt, stick with what MSDN tells us.

more later - joel

Adding OpenID to your own domain

2010-06-18T13:33:08Z

This is something I’ve been pondering for a while – and this article makes it seem pretty simple.

via Lifehacker via Smarterware

more later - Joel