2D Head with a clock as an eyeball.
 Thursday, September 18, 2008

I often start personal coding projects on a weekend because I am passionate about programming. I wouldn't be here if I wasn't. The problem is that those projects don't get finished very often. The sorts of projects I do find myself finishing are the ones when I've been truly interested in the problem domain.

This isn't a ground breaking revelation. I just have to remind myself of this every now and again. My problem is not that I need to develop with passion, rather I should attempt to develop for things I am passionate about.

Being passionate about programming gives me a special benefit: I can come up with useful ideas for other programmers and implement them.

Unfortunately coming up with cool ideas for programming usually ends in finding somebody else is already halfway through implementing it.

Time to revisit my alt.pursuits for inspiration.


Filed under:
 Wednesday, September 10, 2008

 

Its been a while but F# and Project Euler have been on my mind of late. Problem four plays with palindromes.

Find the largest palindrome made from the product of two 3-digit numbers.

What I like about this question is that we can still break out the math and improve on the obvious brute force method. For instance the palindrome we are after can be written as ABCCBA which can be simplified thusly:

100000a + 10000b + 1000c + 100c + 10b + a

= 100001a + 10010b + 1100c

By finding the lowest common factor for a, b & c we can prove our palindrome must be divisible by that factor. In this case, it happens to be:

11(9091a + 910b + 100c)

So our palindrome must be divisible by 11.

Armed with this knowledge we can hunt for numbers divisible by 11 that are between 100000 and 998001 that are palindromic and choose the biggest one. Using F# we can take advantage of list comprehension, lambdas and some great built in functionality.

In this case I want a list of products of 11 that will match the pattern ABCCBA. This means I can ignore integers below 100 as factors since 99*99=9801 and doesn't fit the ABCCBA pattern. In F# this can be achieved like this:

let products = [ for x in 110 .. 11 .. 999 do for y in 100 .. 999 -> x * y ]

In this example we are taking the multiples of 11 between 110 and 999 and assigning it to x, and then assigning y a number between 100 and 999 and then yielding the product of x and y.

The next trick we need is to be able to check if a number is palindromic. The .NET framework has no real built in for this, but we can use the F# Array class to reverse arrays. Lucky us, because the String class implements seq<char>. That is to say in F# we can treat strings as sequences of chars and indirectly as Arrays:

let reverse_string (s:string) = 
    new string(s |> Seq.to_array |> Array.rev)

Using a function like this we could compare the original string with the reverse to tell if it is indeed a palindrome. Finally we can use List.max to choose the max value of a list.

Putting these techniques together makes for an elegant solution:

#light
let solve() =  
   [ for x in 110 .. 11 .. 999 do for y in 100 .. 999 -> x * y ] 
   |> List.filter (fun x -> x.ToString() = new string( x.ToString() |> Seq.to_array |> Array.rev )) 
   |> List.max

In the above code I hope you can see how I'm using the string reversal code in a lambda expression to filter the non-palindromic numbers out of the list. Once I've done that List.max outputs the final answer. On my dev box, this runs in under 2 tenths of a second. Not bad... Hopefully I'll get some time to compare a similar C# solution. I'll bet C# is faster, but I won't be solving this problem in 4 readable lines...

Oh...and if you can see a more optimal approach please share!


Filed under:
 Tuesday, September 09, 2008

I know its minor and easily fixed but I have to say that I really hate this about 3rd party installations to Visual Studio. I get quite used to certain keyboard shortcuts for every day tasks and the last thing I need is my F12 key hijacked.

Some products are great about this aspect of tool development, some aren't. What I didn't expect was the recent F# CTP to do it to me. In fairness, it is still essentially in beta.

One of the great Visual Studio features of late has surely been smart tags in code, which can be expanded using Ctrl+. or the abominable Shift+Alt+F10:

Smart tag expansion from a C# code file

So, if you too are fond of using the Ctrl+. combo in Visual Studio to expand smart tags to do things quickly like include references, insert using statements and correct syntax errors and you want the latest F# goodies then for the time being you'll need to re-map the key combo. Or you could use the alternative wrist bender Shift+Alt+F10, and for me that was not an option.

To do this, open the Options dialogue from the Tools menu in Visual Studio. Browse to the Keyboard options under the Environment heading and re-map the View.ShowSmartTag command.

Remapping the View.ShowSmartTag back to its original state

I've written to F# feedback to let them know about this minor issue.

***UPDATE***

Luke Hoban from  F# Bug reports confirms this workaround and assures me that this will be included in a soon to be released list of known issues. Thanks Luke!


Filed under:  | 

Just a quick post to highlight the recent release of the F# compiler for Visual Studio. This release shows some real improvement upon the IDE integration featuring true F# project files and an improved language service which benefits both intellisense and background compilation.

I didn't realise how much I liked Visual Studio projects until I was deprived of their functionality. Just simply having a project file that operates like C# or VB projects is a real boon to F# newbies and experts alike.

My previous experiences with intellisense in F# were such that I would often ignore it as it was easily confused. This appears to be less of a problem now and is much more of a help than a hindrance.

So if you haven't already, download and install the F# September CTP from the MS download centre and have a look.


Filed under:  |  |  | 
 Wednesday, August 27, 2008

While reading Chuck's excellent post on the value of both knowing your problem domain before tackling your problem and checking in often, I found myself nodding profusely. I love it... he states:

Write tests first! Do it! DO IT NOW.

I'd like to add: NOW CHECK IN!!

I wish I could...often my problem is *when* to check in. I know I have to do it often, but when? After I finish a task? What if that is a few days away? What is a reasonable amount of time?

When I say task I am referring to a TFS work item. Since we are a scrum shop now it is actually a sprint backlog item. I have TDD at my side, and we have CI builds at work. Why not check in after every passing test cycle?

To be honest, checking in after every passing test feels like I'm wasting more time doing the check in dance, than I am saving time. Having said that, it appears that this is a widely accepted approach. 

Martin Fowler suggests otherwise. It appears he is task oriented when it comes to checking in:

Now I take my working copy and do whatever I need to do to complete my task. This will consist of both altering the production code, and also adding or changing automated tests.

...

With a good build, I can then think about committing my changes into the repository.

I think it feels more natural that way. Its like a 'reward' for finishing a task. The feedback loop advantage of TDD isn't hindered by the longer feedback time of a CI build so much.

However, I'm often left with sprint backlog items whose scope might mean that I'm programming for days on end. This is the root of check in evil for me. If a work item is so broad that it will take days to complete, then the impetus to check in is diminished such that I can get so wrapped up in the detail of the problem that I will forget to check in.

And that's my fault.

I'd love to blame it on the process but I can't. Sure the analysis of the product backlog item could have been more thorough, but we don't want to get too far into implementation details at that point or else we waste the whole teams time.

I should have the sense upon undertaking a task that has been written up as "Import old Foo data for Foo version 2", to split it up in to its discreet units of work. There are SQL tables to write create scripts for. There is a transformation layer to design and implement. There is deployment to think about. Acceptance testing. So on and so forth.

It is *my job* to define the goals on the road to task completion.

Carve up vague work items into byte sized pieces

So I come full circle and refer back to Chuck's post and the idea that we should think about what we are going to do before we go and do it. Coding from hip make pain for coder </grunt>

Accept a task and analyse the problem domain.

Divide it up into check in sized work items.

Eat. Repeat.


 Friday, August 22, 2008

I've always loved vi and vim with a passion, and when after reading a post from JP Boodoo about ViEmu I felt compelled to give it a whirl. ViEmu integrates vi/vim functionality with Visual Studio. Yes.... you too can :wq code files. Initially, I was concerned that it would hinder rather than help, mainly due to a discordance between the editing paradigms of vi and Visual Studio. Vi uses discreet editing, navigation and selection modes to maximise the usefulness of the keyboard in light of traditional console based terminals.

With advent of the graphical text editor, this paradigm fell from favour as keyboard usage was gradually overtaken by ever increasing armies of icons and other visual metaphors.

In spite of this, coders generally pride themselves as 'shortcut-smiths' and I found that my vi skillset was proving useful even with Visual Studio. I should also point out that at home I run Resharper and at work I use Refactor Pro and CodeRush, and that Viemu for the most part appears to play very nicely alongside them. ViEmu also works from Word, Outlook and SQL Management Studio.

So what more could I possibly get out of Visual Studio using a tool like viemu? I'd like to share some of the things I like the most about Viemu.

Navigation

In short, and without giving a course on vi usage, we can move around a and edit code files in ways that other editors don't even bother with. The following is a small sample of the possibilities.

  • Want to move 10 lines down from your current position? 10j
  • 5 words to the left? 5w
  • End of a word? e
  • Next line of whitespace? }
  • Move up to the closing parenthesis? %
  • Now move to the matching opening parenthesis? % again
  • Move to the 5th instance of the , character? 5f,

Editing

  • Delete the next 10 lines? d10d
  • Change the next 5 words? c5w
  • Append to the end of the current word? a
  • Append to the end of the line? A
  • Delete everything up to the closing parenthesis (a personal fave)? d%
  • Change the text upto and including the 3rd ) character? c3f)

I'm often confronted with the comment "But who deletes 10 lines of code?" Well, for starters, I work with line numbering ON. Let's say I don't want 3 methods anymore. I look at my current line position, I look at the line the last method ends on. I subtract the two values in my head, that comes to 43 lines. I then type d43d and I'm done.

The point is, that you begin to notice patterns in code. Assignments are usually at least three words long. A method with no parameters in C# takes 3 words to move to the opening bracket. Hitting %% gets me to the same place in that case also. Having the ability to add numbering and repetition to navigational and editing tasks is very powerful, and now I'll show you just one of the myriad way you can harness it.

Vi Macros

Once you have familiarized yourself with the toolset, it becomes quite easy to record macros for repetitive tasks. We use SQL scripts to deploy test data at work and every now and again I'll hear the repetitive tap-tap-tap of somebody hitting the following sequence of keys: END, CTRL+V, DOWN ARROW over and over and over again. Here is an example:

PRINT 'Employees.'

INSERT INTO dbo.Employees
(EmployeeNumber, EntityGuid, DomainLogin)
	SELECT 'EM001', '018B163B-7D4F-49E1-A640-6BD9B65073FF', 'DOMAIN\EM001'
UNION	SELECT 'EM002', '3D3201F8-523D-43B1-89BC-F2FF8CAEBD56', 'DOMAIN\EM002'
UNION	SELECT 'EM003', '48EC5825-374F-4043-849D-308B2C8AA093', 'DOMAIN\EM003'

--repeat 50 more times		

GO

The usual goal might be that a role column was added, and for starters we want to assign each employee to the same role. First we go to the insert line and add the Role column at the end. Now to begin the macro that will do the heavy lifting.

First I enter normal mode by hitting escape or ctrl+[. Next I type qa to start recording a macro to register 'a'. I then type A to append to the end of the line. I'm now in insert mode, so I type , 'Users'. I exit insert mode with escape or ctrl+[ and then move to the next line with j. Finally, to finish the macro I hit q.

To recap, all I typed was: <esc>qaA,'Users'<esc>jq Thats a whopping 15 keystrokes including the string I had to write anyway.

I now have a macro I can reuse by simply using the recall macro command @. To recall macro 'a' I actually have to type @a.

'So what', you say, 'That only does it once and having to type @a over and over again is just as tedious as paste, end, down??'

Well the final trick is that to do it 52 times over I type 52@a. Repetition of commands is definitely one of vi's strengths and you can use it pretty much everywhere. 

Variation: I want the the Role column to be the 3rd column in my insert. Simple.. a few minor changes like instead of using A I would use ^2f, to move to the second comma. I would have to write: <esc>qa^2f,i'Users', <esc>jq then finally 52@a and I'm done.

I'll admit, there is a bit of thinking going on there, and I might not be typing at 80 wpm, but I'm saving myself a whole lot of RSI. Oh... and looking totally l33t when I run that macro 52 times.

So is it worth it?

Well, I think so, but I think it really depends on the type of person you are. If you've already fallen for vi, and Visual Studio seems only bearable with Resharper installed, then I'd say absolutely get Viemu. It doesn't cost much and you can utilize almost everything vim has to offer. If not, the learning curve isn't huge, but its significant. Thankfully, Viemu maps Ctrl+shift+alt+V to instantly turn it on or off, so if it starts hurting your head, you can escape the pain. It plays nicely with existing productivity tools, and caches any keyboard mappings that it steals during operation, and it will put them back if you switch it off.

Still, vi is a cryptic way of editing code, so if you struggle with remembering the keyboard shortcuts for Build, Step Into & Step Over, then I'd suggest that this product isn't for you. But if you want to add a new light sabre to your existing Jedi toolkit, then I'd encourage you to give it a try. Maybe even install gvim for a while to replace notepad, to help get used the whole vi thing.


Filed under:  | 
 Sunday, July 13, 2008

So after a great day yesterday of presentations and, ultimately pizza, I'm sitting here in a Lecture Theatre at the University of South Australia in Adelaide enjoying presentations for Code Camp SA, day 2.

Personally, I've been very impressed with the quality of presentations, and some highlights for me thus far have been:

I'm also keenly awaiting a presentation by Corneliu I. Tusnea on CLR Production Debugging. This particular topic should be dear to all our hearts as developers, and Corneliu really knows his stuff.

Hopefully in the next day or two I'll have some information regarding a presentation that Jason Stangroome and I gave, we decided to give a bit of a feature comparison of Subversion and TFS SCCMs smackdown style. I'm grateful to Paul Stovell for helping Jason and I polish our ideas and giving us plenty of inspiration and motivation.

So another big thankyou should go to Peter Griffith and ADNUG for making CCSA a reality, and yeah the pizza last night was awesome. I must say its nice to sit back today and not worry about my own material, and I look forward to the rest of the day. And if your at CCSA08 today, collar me at lunch and say hi!


Filed under:
 Wednesday, June 11, 2008

Today Resharper 4.0 goes RTM, if you haven't been following the EAP, you might be interested to know that we now have full C# 3.0 language and LINQ support.

That's not all we get, there are a swag of cool new refactorings, solution wide code analysis, extra framework annotations, camel humps in code completion....the list just goes on.

There are some improvements to the VB experience like new refactorings only previously supported in C# 2.0:

  • Convert Method to Property
  • Convert Property to Method
  • Pull Members Up
  • Push Members Down
  • Extract Interface
  • Extract Superclass
  • Convert Interface to Abstract Class
  • Convert Abstract Class to Interface
  • Extract Class from Parameters
  • Use Base Type Where Possible
  • Replace Constructor with Factory Method
  • The ASP.NET guys don't miss out either, amongst other things - a performance increase to page analysis, which has been a real problem for large ASP.NET pages in the past.

    Personally, I find Resharper to be the best C# productivity tool out there for the money, and they are paying more and more attention to VB.NET. Combined with Viemu its my productivity suite of choice and I encourage you to give them both a try.


    Filed under:  |  |  | 
     Wednesday, May 21, 2008

    Drought. Heat. Life.

    MexicanSun_thumb

    1280x1024

    2560x1024

    1920x1080

    3840x1080

    Its been almost a year, I wish I had done more desktops, but life has been tough. 

    Suitable as a diptych or just a single monitor. Let me know if you want the original for your own cropping pleasure (60MB @ 5120x4096)

    If you haven't seen my previous desktops, you can find them here.


    Filed under:  | 
    © Copyright 2009 Jim Burger