muonlab

Following on from Robert Pickerings F# introduction at Progressive.Net in London last week, I was inspired to try and do something with this powerful functional language.

As an exercise I though’t I’d port some old code I wrote in Haskell several years ago, a simple Caeser Cipher cracker.

A Caeser Cipher works by shifting each letter of the alphabet by n positions. A shift of 3 would encode “ABCD” as “DEFG”. Due to this simple linear transform (y = x + c), the Caeser Cipher is incredibly easy to crack with frequency analysis. By shifting the ciphertext by 1-25 positions and comparing the frequency of each letter in the resulting plaintext candidate to a table of English letter frequencies, it is possible to easily discover the original plain text (assuming there is sufficient data to make the expected freqency distributions).

Here’s the code!

Disclaimer: This is the first F# code I’ve ever written, so don’t count on it being remotely decent. Suggestions for improvements are more than welcome!

#light

let alphabet = ['A'..'Z']

let getpos x xs = List.find_index ((=) x) xs

let let2nat c = getpos c alphabet

let nat2let i = alphabet.[i]

let shift i a =  nat2let ((let2nat a + i) % 26)

let encode i s = new string(Seq.map (fun c -> shift i c) s |> Seq.to_array)

let decode i = encode (26 - i)

let count c s = Seq.filter ((=) c) s |> Seq.length

let percent a b = (float a / float b) * 100.

let freqs ws = [for x in alphabet do
                   yield percent (count x ws) (Seq.length ws)]

let table          = [8.2; 1.5; 2.8; 4.3; 12.7; 2.2; 2.0; 6.1; 7.0;
                        0.2; 0.8; 4.0; 2.4; 6.7; 7.5; 1.9; 0.1; 6.0;
                        6.3; 9.1; 2.8; 1.0; 2.4; 0.2; 2.0; 0.1]

let chisqr os es =
    let chied = [for x, y in Seq.zip os es do
                       yield ((x - y) * (x - y)) / y]
    List.sum chied

let crack ws =
    let wws = [for x in [0..25] do
                   yield chisqr (freqs (decode x ws)) table]
    let n = getpos (Seq.min wws) wws
    decode n ws

let ciphertext = encode 5 "THEQUICKBROWNFOXJUMPEDOVERTHELAZYDOG"

let plaintext = crack ciphertext

System.Console.WriteLine(ciphertext)
System.Console.WriteLine(plaintext)

This produces:

YMJVZNHPGWTBSKTCOZRUJITAJWYMJQFEDITL
THEQUICKBROWNFOXJUMPEDOVERTHELAZYDOG

Ok this was an annoying one, If your TDD.Net runner keeps telling you “No tests run (No tests where found)” and you’ve run the “InstallTDNetRunner.bat” you can try the following:

Edit the InstallTDNetRunner.bat

and comment out the last 2 lines:

regedit MSpecTDNet.reg
del MSpecTDNet.reg

Run the bat file and a .reg should appear in the same folder. Edit this.

in there you should see: AssemblyPath”=”<some path>\\Machine.Specifications.TDNetRunner.dll”

Make sure this path is actually correct (it wasnt for me). Then save the .reg and run it.

Job done

Just a quick one, but it took me a while to figure this out. Hopefully this can help someone else out.

To get MSpec working with ReSharper you need to copy all the MSpec dlls into the resharper’s plugins folder, so you end up with:

ReSharper/bin/plugins/machine.specifications/<dlls here>

Make sure you delete whichever one of the ReSharperRunner dlls is not your ReSharper version!

Enjoy

Recently I posted about how you can split your CSS up into separate files, and use a NAnt task to combine them on build to aid development.

This can be very useful, but theres still room for improvement.

The YUI Compressor is a brilliant tool to remove whitespace and other bloat from your scripts which take up valuable bandwidth. Combining it with an automated build tool such as NAnt allows you to have all your scripts minified automatically on deployment.

Here are two example build tasks for minifying JavaScript and CSS respectively:

<target name="compress-js">
	<foreach item="File" property="filename">
		<in>
			<items basedir="output/build/assets/javascript/">
				<include name="/**/*.js" />
				<exclude name="/**/*.min.js" />
				<exclude name="/**/*.pack.js" />
			</items>
		</in>
		<do>
			<exec basedir="." program="${JavaPath}java" commandline=" -jar ${YUICompressorPath}yuicompressor-2.4.1.jar --type js --charset utf-8 -o &amp;quot;${filename}&amp;quot; &amp;quot;${filename}&amp;quot;" failonerror="true" />
		</do>
	</foreach>
</target>

<target name="compress-css" depends="combine-css">
	<foreach item="File" property="filename">
		<in>
			<items basedir="output/build/assets/css/">
				<include name="/**/*.css" />
				<exclude name="/**/*.min.css" />
				<exclude name="/**/*.pack.css" />
			</items>
		</in>
		<do>
			<exec basedir="." program="${JavaPath}java" commandline=" -jar ${YUICompressorPath}yuicompressor-2.4.1.jar --type css --charset utf-8 -o &amp;quot;${filename}&amp;quot; &amp;quot;${filename}&amp;quot;" failonerror="true" />
		</do>
	</foreach>
</target>

Using this in combination with my CssCombiner, I achieve an average of 70% compression!

Enoy

One of the most difficult aspecs of web development today is managing and maintaining your stylesheets. Typically you have a single huge file, divided into sections by comment blocks (if you’re organised). Navigating to the group of styles you need to edit typically involves Ctrl-F and lots of inside knowledge. Individual CSS developers tend to have their own quirks when it comes to the internal organisation of their “monolith.css”. Some like to separate structure and layout from colour and style whilst others like to define all attributes for a selector in a single place. The result of all these different, typically unmanaged techniques can make it very difficult for maintenence developers to get to grips with legacy stylesheets, surely there must be a solution?

Take a look at this CSS from a recent project I worked on…

default.css contains:

@Import url(Reset.css);
@Import url(MainLayout.css);
@Import url(Components/Header.css);
@Import url(Components/Misc.css);
@Import url(Components/WhiteBox.css);
@Import url(Components/Forms.css);
@Import url(Components/BaseModal.css);
@Import url(Components/CustomModal.css);
@Import url(Components/Popup.css);
@Import url(Components/DefinitionList.css);
@Import url(Components/ResultMessage.css);
@Import url(Components/ShipmentCalendar.css);
@Import url(Components/Severity.css);
@Import url(Components/Document.css);
@Import url(Components/ResultsTable.css);
@Import url(Components/TaskList.css);
@Import url(Components/TodoList.css);
@Import url(Components/ContractList.css);
@Import url(Components/ShipmentList.css);
@Import url(Components/EditIcons.css);
@Import url(Components/UserList.css);
@Import url(Components/SimpleList.css);
@Import url(Components/ApplicationForm.css);
@Import url(Components/jquery.ui.css);
@Import url(Components/Blank.css);
@Import url(Components/thickbox.css);

Each file in the components folder contains just a few lines of related styles, on the topic of the filename.

The more astute among you may have realised however that whilst this mass of @Imports might be super useful for development, its going to create an HTTP request spamathon on each page request.

Step up my CSS combining NAnt task.

As an aside, I am currently migrating towards Rake instead of NAnt as my build tool, and when I do I shall create a Ruby version of this.

Point the task at your CSS files, and it will run over them, replacing each @Import directive with the CSS that would actually be imported. Awesome! This means you can divide your CSS up into a million, super granular files and not need to worry about any HTTP request overheads, because in the live environment, you will only have a single file

To use the task:

1. Import the dll into your .build file
2. Point the CssCombiner task at your built CSS files (NOT YOUR SOURCE CODE)
3. Go and do something else with the time you have saved

Here is an example:

<loadtasks assembly="./tools/CssCombiner.NAntTask.dll" />

<target name="combine-css">
    <CssCombiner>
        <fileset basedir="output/build/">
            <include name="/**/*.css" />
		</fileset>
	</CssCombiner>
</target>

Enjoy

Having recently sold ReSharper to the rest of my development team, we have collectively experienced some serious environment colouring woes.

Firstly, installing (upgrading) Visual SVN can cause all your ReSharper colour settings to disappear from the Fonts and Colours menu. Repairing your ReSharper installation will fix this.

Here is some newsgroup activity on the subject.

Secondly, I’ve discovered that importing/exporting your colour settings in VS does not include all of the ReSharper colour settings, which can lead to some confusion.

Luckily in my environment this was not a problem. However there is an option in ReSharper that can cause things to look weird.

ReSharper -> Options -> Code Inspection -> Settings -> Color Identifiers

You probably want to untick this.

Thanks to Saint Gerbil on StackOverflow for this tip.

In the case where strange things are happening surrounding colours being different to their settings the the options dialog, sometimes “OKing” the colours settings can sort this out, combined with a restart of Visual Studio.

As an aside, here are my current colour settings to download