andyBlog [andy britcliffe]

Moving

Just a brief note to say that I'm leaving the Conchango nest and hence this blog site - it's been a blast. I'll be moving in the meantime back to my dotnetjunkies blog which can be found here.

Andy.

Posted 04 December 2007 15:34 by Andrew.Britcliffe | 0 Comments

Filed under: Cowbell, Bye Bye

What Silverlight is up against - Flash at its best

I came across this flash interface today.

Simple, stunning.

Posted 05 October 2007 12:29 by Andrew.Britcliffe | 1 Comments

Filed under: Silverlight, Flash

Silverlight 1.0: Applying a Render transform dynamically

Here is an interesting one. Typically with the Silverlight 1.0 object model you can access properties and methods directly through Javascript. Now given this you would expect that to dynamically set a Transform, for example a rotation on a TextBlock, you would do something along the lines of textblock.RenderTransform.TransformGroup.RotateTransform.Angle="45" or something to that effect. However this will error. To do this you actually have to create the Transform from XAML using the createFromXAML method.

So to add RotateTransform to a TextBlock you need to do the following:

var textblock = rootCanvas.findName('tb');
var trans = control.content.createFromXaml('<TransformGroup><RotateTransform Angle=\"45\"/></TransformGroup>');
textblock.renderTransform = trans;

and that will dynamically add the rotation to the TextBlock.

Posted 27 September 2007 11:57 by Andrew.Britcliffe | 2 Comments

Filed under: Silverlight

CreateSilverlight.js and Silverlight.js

When you starting using Silverlight you will quickly become aware of these magic javascript files called CreateSilverlight.js and Silverlight.js that are part of your projects. I've seen a number questions around why these scripts are there and how do you use them. There is a great article here are MSDN that can give you all the information you need.

Posted 27 September 2007 09:21 by Andrew.Britcliffe | 1 Comments

Filed under: Silverlight, MSDN

Silverlight error codes

When working with Silverlight you can often come across cryptic error messages.Fortunately Benjamin Nitschke has done a great job in attempting to document some of the more common ones that occur and made avaible on his blog. This can be a real time saver.

Posted 25 September 2007 13:02 by Andrew.Britcliffe | 1 Comments

Filed under: Silverlight

Deploying a Silverlight application to IIS and nothing shows up?

I'm currently working in the depths of Silverlight and we've recently come across a interesting issue when trying to deploy to a test environment.

As ever, everything was working fine locally, but when we deployed to a W2K3 box the Silverlight content of the site wasn't displaying. No errors, just nothing displayed. We checked the scripts and Xaml files were in place correctly and they were so we were a little puzzled.

Anyway we decided to use fiddler to check the traffic and that told us that when Silverlight was trying to load our Xaml file it was getting a 404 error. We double checked that the Xaml file was there, and indeed it was so immediately this smelt like an IIS configuration issue.

After some digging around the solution was to setup a MIME type in IIS for the Xaml being served. Big credit goes to Jim at Microsoft who has this blog post explaining the solution.

Posted 21 September 2007 10:15 by Andrew.Britcliffe | 2 Comments

Filed under: Silverlight, IIS, Fiddler

Good engineering practices breed good software

Seems obvious when you state it out loud, however it is quite amazing how many companies seem to miss this crucial fact when trying to deliver software. To give some context to this topic I was going through my usual evening reading of blogs when I came across a post from Steve Yegge , a Googler titled:

Good Agile, Bad Agile

Now the title attracted me initially as we're certainly interested in the Agile arena. The post its self actually turns into something of a sales pitch about how great it is to work at Google and how they look dis-organised on the outside, but there is a method to their madness. All interesting stuff but hardly ground breaking. However I came across one paragraph which really resonated with me and is, in my opinion one of the major reasons why Google is so good at doing what it does:

"Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places."

You have to have the basic ingredients in place to make a good meal, and the basic ingredients that are vital to a good meal of software development are:

Source control
Code conventions
Code coverage from Unit tests - Doesn't have to be 100% coverage though
Code reviews including security.
1 Step build process / Continuous Integration
Good tools
A consistent development methodology of your choice
A consistent development environment

I've previously written about Ruby on Rails on this blog, and I guess one of the areas that really appealed to me in RoR was the convention over configuration. Like in Steve's quote above, if you go to another Rails project you immediately feel at home in it, the directory structure looks the same, running unit tests is the same, configuration is the same. Now I'm not sure you can say that about all (or even the majority) of .Net projects YOU work on.

As developers we have a professional responsibility to ensure that any project we work on adheres to the above, otherwise you WILL hit problems further down the road. Get the solid foundation in place, so the building doesn't collapse later on.

Posted 04 September 2007 20:19 by Andrew.Britcliffe | 0 Comments

Filed under: Ruby on Rails, .Net, Convention, Development, Configuration, TFS, Google, Engineering

Flash phone home?

I came across this today about a new VOIP flash component via Ryan and I have to say it is very, very interesting. Having lived out in the US for the last 12 months I've been heavily reliant on Skype for calls back to the UK to keep in touch with friends and family. Now while Skype works well (ahem apart from the last little incident) there is a setup cost attached to it in terms of it needs to be installed on your PC or MAC, and as I move more and more to an online ecosystem for my communication and applications I find myself less tolerant with being tied to my particular pc/mac for an application. Whether it be writing blog posts (I'm composing this in Google Docs), reading blog posts (I use Google reader), e-mail (Gmail and Hotmail), storing data (I use BingoDisk ) I find more and more that I will opt to use an online application that I can access from anywhere with an Internet connection.

So hence my interest with a VOIP application that is deployed as flash, as to me this is not only incredibly powerful, but fits my criteria for roaming use. I think I have to agree with Ryan that this offering from Ribbit could well be a game changer, adding more cowbell to the VOIP market and Skype should certainly be looking over their shoulder (or looking to buy them).

From a user standpoint, it means no more downloading setup files and going through the process of installing it, you have it available to you from any machine that has flash (think mobile as well). From a developer point of view, having the ability to add VOIP to your application as simply as embedding a flex application holds all manner of new powerful communication options.

I look forward to having a play with it when it's released. Now my question is who's going to build the Silverlight version?

Posted 21 August 2007 17:05 by Andrew.Britcliffe | 0 Comments

Filed under: RIA, Adobe, Silverlight, Ryan Stewart, Cowbell, Flash, Flex

JoR - Javascript on Rails. Is it April 1st?

I'm not sure what to make of this one from the Googleplex, it's certainly food for thought but it seems that Steve Yegge at Google has been working on a RoR port to Javascript called Rhino on Rails. Yup you read that right, Javascript on Rails!!

More details here...

Steve has actually written a follow up post on the article here...

I'd need to see this in action to make a rational judgement, but from a practical standpoint if he can get it into byte code and using the JVM, perf shouldn't be an issue, and the language is certainly dynamic. It seems a little pie in the sky at the moment, but hey you never know, especially when the Googlers are involved.

Could YOU see yourself building server applications in Javascript? ~~Anyone know of any projects to get Javascript running on the DLR?~~

Edit: Actually I was reading Jim Hugunin's blog and re-read this post. Seems Javascript is supported on the DLR which I didn't realise in Silverlight 1.1(I think I was too excited about the c# support to notice).

Further Edit: My interest was peeked by this and some further googling reveled this post by Michael Schwartz which quotes Jim who alludes to poor peformance in 1.1.

Posted 27 June 2007 23:18 by Andrew.Britcliffe | 0 Comments

Filed under: Ruby, Ruby on Rails, Silverlight, Java, Javascript, Cowbell, DLR

Understand your verbs when creating actions in your web applications.

Recently, I've been doing a fair amount of reading around RESTFul web services and applications. Ruby on Rails has made it silly easy for you to create applications that offer a REST api out of the box. When dealing with a REST web service it is vitally important you understand the verbs of the HTTP protocol. Now I'm not going to delve into this deeply here (you can find a full description here), but I did want to raise the use of GET Vs POST when creating actions in your web applications.

Now in essence, GET is used to "fetch" a resource - be it a html page, a JavaScript file, an image etc. GET is often misused in web applications, you will often find that a button to, for example a "delete" action, is actually created in the html as an <a> tag. Now you may be wondering why this is an issue. Well the issue arises because the <a> tag, when clicked, makes a GET request to the server but actually actions a change of data on the server. This is what the POST verb was created for, to action changes to state on the server, most commonly changes to the state of data (edit/delete/etc).
This problem can cause strange issues with sites when tools, like a search engine crawler for example, follow a link that causes a GET request which alters state on the server. They can, in some extreme cases, cause security holes. This was highlighted by the Google Accelerator application, which caused numerous problems to websites that followed the above technique. If you use the correct verb POST for actions, this will be avoided.

Now one of the big reasons for using <a> tags for actions is that the <input> tag is extremely limited in terms of how you can style it, and in a lot of cases this was a show stopper for using <input> and alas using POST for the actions. Well hopefully this blocker can be removed as I've come across a great article at Particle Tree that covers this very topic and shows how using the <button> tag can transfer the way you style you action buttons, and it's certainly something I wasn't aware of.

I'd urge any developer/designer looking to build more RESTful applications to check this article out.

Posted 13 June 2007 21:30 by Andrew.Britcliffe | 0 Comments

Filed under: HTTP Verbs, REST, Web Services

Welcome to EMC Consulting Blogs