Default parameter specifiers are not permitted

This error started appearing in our Cruise Control .NET build. However, we were not getting any errors from Visual Studio in the development environment. We are targeting .NET 3.5, and it turned out some methods were using optional parameters, which do not exist in .NET 3.5. However, Visual Studio is smart enough to be able to compile the code, but csc.exe (which is used by CC.NET) is not. We had to remove the optional parameters and to make sure it didn't happen again, we set the Language Version to C# 3.0 in Project Properties -> Build -> Advanced -> Language Version. Check out this post for more detailed information

http://engineering.thetrainline.com/2013/06/20/using-visual-studio-2010-to-target-net-3-5/

Upgrade from ASP.NET MVC 4 to ASP.NET MVC 5

Personally, I think Microsoft makes a mistake in not making ASP.NET MVC 5 compatible with Visual Studio 2012. You need to follow the instructions in these 2 links to make it work:

http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2

http://stackoverflow.com/questions/17926552/attempt-by-security-transparent-method-webmatrix-webdata-preapplicationstartcod

After giving it some thought, the underlying problem is that Visual Studio is highly coupled with specific versions of .NET (and there is no reason why it's done that way). After all, Visual Studio is just an IDE, and it (ideally) should be able to compile code for any version of .NET as long as you have the specific version of the .NET framework installed.

XMLHttpRequest cannot load http:///socket.io/1/?t=1383952162872. Cross origin requests are only supported for HTTP

Lately I've been learning socket.IO in preparation for a new project. You'll come across simple errors as with any new tool you learn. The first error I had to figure out with this technology was: 

XMLHttpRequest cannot load http:///socket.io/1/?t=1383952162872. Cross origin requests are only supported for HTTP

The solution is simple, but it's part of the learning process. It turned out that I was loading the page in a browser as E:\example.html instead of http://localhost:8081/example.html. Fortunately it only took me a few minutes to fix.

KnockoutJS Tips and Tricks

I wanted to share this video by Ryan Niemeyer, who talks about really useful things to know about KnockoutJS  bit.ly/18004A5

Autoformatting in Xcode

Xcode is not as helpful as Visual Studio when it comes to formatting code. Moreover, if your developers don't follow code standards as much as you'd like, you'll end up with ugly code. Probably the best option is to use Xcode formatter (https://github.com/octo-online/Xcode-formatter), which uses uncrustify to achieve the formatting. You can even edit the rules to follow your own code standards. I found it very helpful, since you can run it after each build.

Auto Layout on iOS Versions prior to 6.0 error

It happened to me after updating to Xcode 5. There are possible solutions to this error. In my case first I tried disabling the auto layout checkbox in the xib's that were causing this error. But this didn't seem like a clean solution. I googled a little more and found that the deployment target was set to 4.3, when it should be set to 6.0 since I'm using auto layouts.

It seems like Xcode 4 should also throw this error, but it didn't. So this error isn't related to Xcode 5, it's just that Xcode 5 does tell you about it.

Knockout performance in Internet Explorer 8

Knockout offers a lot of advantages, but when in comes to IE8 there are some things to consider:

1) Minimize the number of observables you have. Sometimes it's not necessary to have observables for everything, so if you don't need to observe a variable, don't declare it as one. I have received an alert in IE8 saying "a script is running slow in the page" because of this.

2) Plugins and advanced techniques sometimes generate the same alert "a script is running slow in the page". This happened to me when I used the mapping plugin, so I ended up doing the mapping manually instead of using the plugin. My guess is that the flexibility of the plugin comes with the need to execute more lines of code. That's why sometimes it's better to "hardcode" the steps instead of letting knockout "do the magic". At least for IE8.