The Eight Queens problem
My colleague recently introduced me to the eight queens problem (you can read more about it over at Wikipedia). In summary, you have to be able to place eight queens down on a chess board without any of them attacking any other.
This sounds easy at first, but I found that taking a few guesses on a piece of paper yielded no results. Rather than simply solving the problem, I decided it would be more fun to write a program that would find all the solutions for me. I’d been looking for a nice little programming problem to teach myself F# for a while, so I thought I’d give this a go. Well, after a few false starts and a lot of F# Googling, here’s my solution:
Validating .NET MVC 4 anti forgery tokens in ajax requests
CSRF (Cross-Site Request Forgery) is an attack against a website “whereby unauthorized commands are transmitted from a user that the website trusts.” [Wikipedia]. Protection against this attack is essential for any modern web application.
In the case of .NET MVC, Microsoft have implemented an easy-to-use protection method against CSRF. There’s an attribute in the MVC framework that you can put on your controller actions: ValidateAntiForgeryToken. This works well, but it has a few disadvantages:
-
You must manually decorate all your post actions with the attribute.
It’s easy to forget to do this, so it’s preferable to decorate your entire controller with the attribute (or better yet, a base controller that your whole application uses). Unfortunately, this doesn’t work with the standard ValidateAntiForgeryToken attribute, as this causes all your GET actions to be validated as well (and they will always blow up, as the client doesn’t send any form data with a GET request). -
It doesn’t work with ajax posts.
The standard attribute doesn’t work with ajax because it inspects the Request.Form collection when looking for the token field. When you’re making ajax posts this form is always empty. This is the reason I originally started looking for alternative implementations of the anti forgery token validation.
EntityFramework 6 and async database queries
Microsoft is going all-out on .NET 4.5 and C#5’s async feature. Windows RT (the .NET libraries for interfacing with the windows runtime) makes heavy use of task-based asynchrony in the API, and Microsoft’s rule of thumb to all .NET developers is to make any method that can reasonably be expected to take more than 50ms should be asynchronous. This includes web service requests, file read and save operations, and more.
Given the examples in the previous paragraph, most people will instantly think “Well, what about databases?” (as I did). Indeed, so did Microsoft, and they’ve got us covered. Entity Framework 6.0 (currently in alpha state at time of writing) has been updated to support asynchronous queries. What does this look like? Currently there are five methods that make use of asyncrony – SaveChangesAsync() and ExecuteSqlCommandAsync() for non-queries, and FindAsync(), SingleAsync() and ToListAsync() extension methods for IEnumerable.
I’m looking forward to testing this code out to see how it runs. So far I haven’t used async in production code, but from the work I’ve done on my own personal projects, I can say that I’m very impressed with how well .NET async works as well as how easy it is to use.
Keeping your Powershell profiles and functions synchronised between computers
If you’re like me and you use Powershell on a regular basis, you probably have a load of functions set up in your profile.ps1 file so that they get loaded when you start a new session. The moment you start doing this, there’s the constant problem in the background of how to keep this in sync between different computers. I will often be fooling around with some new technology at home and will come up with a super-useful Powershell command, and will then need it at work as well.
I solved this problem with use of Dropbox (you could use any other file syncing app you like, such as Skydrive (or even a network share), the only prerequisite is that it supports symbolic links).
- If you haven’t already, separate your Powershell functions into distinct files, and have them all be loaded by your profile.ps1, which acts as a bootstrapper. Your profile will look something like this:
$scriptFiles = gci "$home\Documents\WindowsPowerShell\*.ps1" -Exclude "profile.ps1" foreach ($scriptFile in $scriptFiles) { . "$($scriptFile.PSPath)" | out-null }Once you’ve accomplished this, you need to create the symbolic link. Open the command prompt and cd into your My Documents folder. If you already have a directory called WindowsPowershell in there, you’ll need to delete it, copying all the files within into your new directory in Dropbox. The command you need to run is this:
mklink /D WindowsPowershell <dropboxPowershellDir>
where <dropboxPowershellDir> is the full path to the directory of scripts in your Dropbox folder. Et voilà, you now have a Powershell profile that synchronises between computers!
Ensuring you get the CLR version you want when remoting in Powershell
This is an issue I ran into recently when trying to run some of our regular Powershell scripts recently – they were the same scripts we’d always run but now we were trying to run them remotely (instead of making a person log in over RDP and run a batch file. Very high-tech, I know.) but we were running into an issue to do with the CLR version that gets loaded with your Powershell session.
We’re using our own binaries (written in C#) in our Powershell scripts, and we need v4 of the CLR loaded to get them to run. Normally v2 is what you get, but we found that you can edit the file $pshome\powershell.exe.config with the contents:
<?xml version="1.0"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>
This caused v4 of the CLR to be loaded, but only when you run Powershell locally. If you want to do the same when you remote into the machine, it doesn’t work.
I couldn’t find any documentation on this, but thanks to some nice people on StackOverflow I now have the answer. The configuration file contents above are still what you need, but you need to put them in another file. Two other files actually, if you’re on 64-bit. The files you need are located at c:\windows\System32\wsmprovhost.exe.config file and c:\windows\SysWOW64\wsmprovhost.exe.config.
That should be all you need!
- ← Previous
- 1
- …
- 3
- 4
Richiban 