Blog

URL parameters with Javascript

So this took me by surprise the other day. JavaScript doesn't have a function to retrieve a URL parameter value. i.e. There is no Request.Querystring command! Of course it wouldn't start Request as it's executing on the browser rather than the server but you would have thought there would be a built in command to do it.

After a bit of searching though I came across this script that does it:

1// Read a page's GET URL variables and return them as an associative array.
2function getUrlVars()
3{
4  var vars = [], hash;
5  var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split('&');
6  for(var i = 0; i < hashes.length; i++)
7  {
8      hash = hashes[i].split('=');
9      vars.push(hash[0]);
10      vars[hash[0]] = hash[1];
11  }
12  return vars;
13}

The function returns an array/object containing the parameters and their values. e.g. The following URL:

http://www.example.com/?Name=Tim&Sex=Male

Would return:

1{
2    "Name": "Tim",
3    "Sex": "Male"
4}

To use it in your code you would write

1var name = getUrlVars()["Name"];

And that's it

Converting users from Membership to SimpleMembership

In ASP.NET 2 Microsoft introduced the Membership provider. By many accounts it is not perfect, but as a one size fits all solution it's not bad. Plus it had a major advantage that a lot of other people would also be using it, so if you wanted to grab a forum solution to stick on your site, chances were it would use the same Membership provider.

Now though there is a second Membership provider from Microsoft called SimpleMembership. It simplifies a lot of things that weren't needed with the original Membership provider and also introduces support for working with OAuth providers. Not only that but if you create the MVC 4 project from the default template that is what your solution will be set up to use.

The problem however is Membership and SimpleMembership are not compatible. They store their information in separate tables and if you do try to copy all the users from one to the other, you will soon discover the hashing algorithm used on the password is different. You probably also had all your passwords one way hashed so you can't even generate the new ones.

There is a solution however. Paul Brown has written a nice bit of code to update the MVC 4 account controller so that when your users log in they will first be authorised against SimpleMembership, if that fails it will then authorise against the original Membership and if that succeeds it will generate the new password in SimpleMembership using the one just provided by the user.

Over time as your users log in the will be slowly migrated over. The second time the log in the SimpleMembership will authorise them and the extra code won't even be hit.

http://pretzelsteelersfan.blogspot.co.uk/2012/11/migrating-legacy-apps-to-new.html

Calorie Buddy

Calorie Buddy is the latest of my apps released during summer of this year. Following on from the series of apps Training Buddy and Weight Buddy, Calorie Buddy is another app aimed at helping you keep track of your general health and fitness.

As the name suggests Calorie Buddy is all about monitoring your calorie intake. Simply set a target, enter your consumption each day and a handy pie chart will show you how many calories you have available left to eat that day. To navigate between different days simply swipe to the left or right.

One of Calorie Buddy's best features though is its live tile that enables you to see your remaining calories that day without even opening the app!

Download Calorie Buddy today

Back to basics string vs StringBuilder

This is simple stuff but is something I see people easily miss by just not thinking about it.

A string is an immutable object, which means once created it can not be altered. So if you want to do a replace or append some more text to the end a new object will be created.

A StringBuilder however is a buffer of characters that can be altered without the need for a new object to be created.

In the majority of situations a string is a perfectly reasonable choice and creating an extra 1 or 2 objects when you append a couple of other strings isn't going to make a significant impact on the performance of your program. But what happens when you are using strings in a loop.

A few weeks ago one of my developers had written some code that went through a loop building up some text. It looked a little like this:

1string foo = "";
2 
3foreach (string baa in someSortOfList)
4{
5    foo += " Value for " + baa + " is: ";
6 
7    var aValue = from x in anotherList
8                 where x.name == baa
9                 select x;
10 
11    foo += aValue.FirstOrDefault().value;
12}

Everything worked apart from the fact it took 30seconds to execute!

He was searching through convinced that the linq expressions in the middle was what was taking the time, and was at the point of deciding it could not go any faster without a new approach.

I pointed out not only had he used strings rather than a StringBuilder, but the loop also created around 10 string objects within it. The loop which repeated a couple thousand times was therefore creating 20000 objects that weren't needed. After we switched froms strings to a StringBuilders the loop executed in milliseconds.

So remember when your trying to work out why your code may be slow, remember the basic stuff.