I’ve created a little framework for producing W3C-compliant syndication feeds from ASP.NET MVC.
Right now, there is only a RSS (2.0) formatter in the project, but I’m planning to write an Atom formatter as well.

I know that this functionality is available in the System.ServiceModel.Syndication, but the problem that I had with it, is that the feed XML it produces is non W3C-compliant.

The functionality in my solution is nothing revolutionizing, but might save you a little time.
If you find any bugs or have suggestions, contact me.

How to use:

1. Reference the assembly FirstDraftHell.Mvc.Syndication.dll from your solution.

2. Create a new action that returns a FeedActionResult.

Download:

Download source (9.0 KB)
Download assembly (Release) (4.8 KB)

Grab your copy right away at http://www.asp.net/mvc/.

Lately, I’ve read about several Swedish sites that got their servers hacked - and as a result of this - sensitive user information been leaked to the Internet. Apparently, the developers of the sites have not been salting hashed password (and in some cases, no hashing have been done what so ever).

This is of course a problem, but the good part is that many people have been forced to learn a lesson. Since you never know how a provider of a service chooses to handle sensitive data, it becomes clear to many that it’s important what information to expose about yourself. Can you afford that your email, social security number and similar information circulates in criminal communities?

One of the most important things to know is how to choose passwords.

The number one rule:

You should NEVER use the same password on multiple sites / systems.

What you shouldn’t do:

You should never (never, never, never) use any of the following:

• Your name, nickname, user name, spouse’s name etc.
• Names of fictional characters.
• Nouns, verbs and adjectives that can be found in a dictionary of any kind of language.
• Phone numbers, social security numbers, birthdays.
• Constants (i.e. 3.141592 or 2.71828183) or numeric series (i.e. 123456 or 987654).
• Technical terms
• Reversal of words or phrases.
• Keyboard sequences (i.e. “qwerty”)
• Double words (i.e. “hellohello”).
• Any object that’s in your field of view from your workstation.
• Common phrases (i.e. “I have a dream”).
• Any combination of any of the above.

What you should do:

You should ideally always combine all of the following:

• Nonsense and misspelled words
• Numbers without meaning (but no series)
• Both upper and lower case letters.
• Special symbols

The password should be no shorter than eight letters.

Mnemonic password algorithms:

Using mnemonic password algorithms is a way of remembering complex passwords without the need of a good memory (guilty as charged). There are of course downsides to this approach. If your password is compromised, all your account passwords are compromised as well. Therefore it is a good idea to use several different algorithms and not just one.

Consider the following algorithm (used as an example only):

where the different variables mean:

The result of this applied to a couple of scenarios would look like this:

There is also a good practice to include some kind of rotational, incrementing and variable elements in the algorithm. This helps in some cases since many system’s password expiration policies require you to change your password from time to time.

The above algorithm might seem very complex and awkward, but as long as you design your own so YOU easily can remember it, this is easier than it look.

Now when I think about it, maybe I shouldn’t publish my personal algorithm on the Internet.

So I should memorize ALL my passwords?

Many security experts say that you should NEVER write down any passwords, but I can’t agree to that one 100%. Sometimes you don’t get to choose (or change) a provided password, and some passwords you rarely use at all. It’s in many cases better to write the password down on a paper that you keep secure than outsourcing the responsibility to your memory (and forget) or a third party password vault software (and suffer from a hard drive crash).

The best solution is however always to keep it in memory where applicable.

References:

http://en.wikipedia.org/wiki/Password_strength
http://dc214.defcon.org/notes/july2005/Mnemonic-Password-Algorithms
http://www.cryptosmith.com/sanity/riskyrules.html
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf (PDF)
http://www.scs.carleton.ca/~schiasso/Forget_SOUPS2007_CreateBetterPasswords.pdf (PDF)
http://www.searchlores.org/commonpass1.htm
http://news.cnet.com/Microsoft-security-guru-Jot-down-your-passwords/2100-7355_3-5716590.html

From time to time I find code that’s unreadable because the author cut corners by abbreviating variable names to nonsense.

The code above is of course not a real example, but not that uncommon to find while browsing legacy code.
The actual writing of the code was the big part for the programmer who wrote it. What other reason could there be for cutting corner on variable naming?

Someone who cares about what they do and has thought it through knows better than producing anything that even remotely looks like the example above.

If it takes longer to write code than to think it though, you’re doing something wrong.

I find myself visiting the page 101 LINQ Samples from time to time, when I’m having trouble with a query (yeah, I pretty much suck at LINQ). You probably already know about it - but if you don’t - I can strongly recommend it. The examples are written in C#.

I just stumbled upon a blog entry by Alfred Thompson where he answers why so many programmers use one character index variables. He also explains why the character often is between “i” and “n”.

Very interesting to read.

I was surfing the web and came across a great addin for Visual Studio 2008 called vsCommands.
It makes it really easy to group source files together in the solution explorer without editing the project file.

Download at http://mokosh.co.uk/page/VsCommands.aspx

I found myself writing the same line of codes each time I was acquiring a reader lock with the ReaderWriterLockSlim.
The code used to lock like this and made the code look cluttery when there was a massive lock usage:

But thanks to the collective knowledge of the internet (and of course the blog Hacky Hacky), I now write the same code like this:

How? This is quite easy if you know how to do it.
The secret is to use extension methods for the ReaderWriterLockSlim class to acquire the specific kind of lock (read, write, upgradable read) and creating a IDisposable wrapper that executes the lock’s corresponding exit method when it’s disposed.

I’m currently in Los Angeles attending the Microsoft PDC, and the hotel I’m staying at have a really crappy internet connection, so therefore I’ll keep this short.

I have three words for you: Azure Services Platform

I’ve written a Visual Studio 2005/2008 addin that lets you add a reference path to multiple projects. Since the addin sometimes is a real time saver, I thought that I should share it with you people.

How do I install it?

1. Download the ZIP archive at the bottom of the page and extract it somewhere on your hard drive.
2. Move the files to your Addins-folder in your Visual Studio directory (normally in ‘My Documents/Visual Studio 2008/Addins’). If the Addins folder does not exist, you can create it yourself.

How do I use it?

After you’ve installed the addin, simply open Visual Studio and go to the tools menu. A new menu option called “Add Reference Path…” has been added.

After clicking on the menu option a dialog pops up. Here you should click the browse button to select the path where your dependencies reside. After doing this, select the project in the list that you want to give the selected reference path. Click the save button and lean back while the addin does the work for you.

Some disclaimers

I don’t guarantee that this addin will work for you, but it works on my machine.
You should not use this application without doing a backup of the affected solution.

Download ReferencePathAddin.zip (20Kb)