Saturday, March 21, 2009

Keeping this terser than usual. Got a new keyboard three days ago and want to record initial thoughts. Follow up to come in a few weeks. For now: Freakin’ HATE it! Space on one thumb, backspace on another. Alt-tab requires same hand stretching exercises I did during piano lessons. Common coding symbols (e.g. /}{][=) hard to reach. No Insert key without activating keypad. Enter right next to Space.

Things that have helped:

• Dumping Launchy in favour of Executor (Better handling of file paths, can use space instead of tab for google searches)
• Mapping CapsLock to Esc with SharpKeys
• Mapping LCtrl+RCtrl to Alt-Tab and LCtrl and RWin to Shift-Alt-Tab through AutoHotKey
• Mapping F1 to Esc with SharpKeys (Is this key useful for anything?)

Review unfair as still learning. Hope to return to sentences that don’t sound like written by Rorschach soon. Point in favour: no more pain in arm and wrist already.

Kyle the Fruistrrwated

Friday, March 13, 2009

I could just update my existing post from a couple of days ago but I have another point to make afterward.

Firstly, there is a minor release of ViEmu available as of yesterday. What I found most notable was near the end where Jon says he will be working on the ReSharper issue mentioned in my last post as well as an updated keyboard configuration dialogue. Both will be welcome additions and I’ll be grabbing that release hot off the presses.

Here’s where I think I missed the boat a little. I thought I’d blogged on ViEmu before so I didn’t dwell so much on my opinion of the software. Last June-ish, I decided to give the various vi/vim tools a try because they’d been getting some press. I gave a good college try to ViEmu for VS, SQL Server, and Word. I also had Vimperator for browsing. I tried all of them for at least a month and after that time, I still wasn’t as productive as I was without them.

Recently, as I mentioned, I’ve had a more vested interest in reducing my dependency on the crack we all call “mouse”. So Vimperator and ViEmu came back into the fold. I was pretty surprised at how much I had remembered from last time. This helped a lot because it meant the learning curve was that much lower. Whereas the last time, I had to get used to the navigation before I could learn the more involved intricacies of the products, this time, I had the navigation and search features buried in the back of my head somewhere.

Where I’m going with all this is I think ViEmu for Visual Studio is a good buy for developers, a point that didn’t come across in my last post. I don’t know that I do enough in Word and SQL Server to justify those but that’s me. Maybe you’re in SQL land more often. But I spend enough time in Visual Studio that it makes sense to investigate ways to improve the experience. I mean, how long does a carpenter hammer in nails before he gets a nail gun?

There’s a heck of a learning curve as with all things vi. (This kind of goes against my philosophy of “If something is hard to learn, it’s not worth learning” but I’ve made an exception in this case. See also: NHibernate). There are still minor hiccups, not least of which is my tendency to press j and k in Live Writer. And I was expecting this huge rush of superiority to descend upon me when I started to “get” it but I guess I’m still not quite at the “holier-than-thou” stage of the process. Looking forward to that because I do so respect those people that are so dismissive of others for not liking the same tools they do.

In any case, you’ll also find the author is very receptive to questions and suggestions on both the site and, more recently, on Twitter. And speaking of Twitter, you’ll find no group more helpful than ViEmu and ReSharper users. Give it a try by asking “What’s your favorite tip for <insert either one>?”. (Since you asked, it’s one I just discovered: Unbind Esc from Edit.SelectionCancel. Many thanks to Aaron Jensen and Joey Beninghove for that one.)

This public service announcement inspired by the author’s knowledge of how &*%$ HARD it is to build decent add-ins for Visual Studio.

Kyle the

Thursday, March 12, 2009

Should’ve known better to ask this question on Twitter. Let it not be said that there are no downsides to always poking fun our tendency to take things too seriously.

Here’s some code:

function void Process( Job job )
{
    for ( var i = 0; i < 5; i++ )
    {
        switch ( job.status )
        {
            case ( JOB_STATUS.NEW ):
                ProcessNewJob( job );
                break;
            case ( Job_STATUS.CANCELLED ):
                CancelJob( job );
                break;
            default:
                UpdateJob( job );
                break;
        }
    }
}

The question is: What is the cyclomatic complexity of this code?

Cyclomatic complexity is a measure of the number of paths through your code. So my first intuition was that the answer is 15. One for each case statement, plus the default, and multiplied by 5 for each time through the loop.

Then it was pointed out to me by someone who has actually used it in practice that the for loop counts as 1 regardless of what’s inside it. This is confirmed here. Which would make the answer 4. This actually does make some sense to some degree because even though we are looping through five times, we aren’t actually adding any new paths through the code. I think. Maybe.

A quick Twitter poll seemed to lean toward 4 as well (after discounting answers that amounted to “it depends”). But I’d like to get some more thoughts on it before calling the matter closed.

Having said that, the most accurate answer was provided by my dear and loving cousin, who I can always count on to put things in perspective: I think the answer is you need to up your medication. That question didn’t even make sense on the metaphysical level.

Kyle the Ontological

Monday, March 09, 2009

Let it not be said the RSI is all fun and games. The hillbilly has just realized that he can legally date someone half his age and while that might open up a world of possibilities within his family tree alone, it also means he’s getting elderly.

One of the symptoms is a nice dull ache above my right elbow. I’m attributing it to one or more of three factors:

• Having to reach over both the cursor key cluster and the numeric keypad whenever I need to reach for my mouse
• My wrists twisting at odd angles on the keyboard
• My constant habit of wh---....actually let’s leave it at two reasons

My current keyboard is the standard Apple one (the wired one) which I picked up within a week of receiving my new desktop. The stock Dell one is not unlike a Speak N Spell when it comes to typing, the most egregious failure being the funky home key cluster. I’m not sure when they switched from the standard 2 x 3 to a 3 x 2 but I have to wonder what the thinking is behind such a switch. My own fault I guess for shelling out three large without putting any thought into my primary interface for the thing.

Its replacement is on its way based on the recommendation of someone whose opinion I respect highly and whose state of mental well-being is frighteningly similar to my own. Which is the only reason I shell out that much sight unseen, especially in a country not generally known for its excellent warranty service.

In the meantime, I giving another college try to various vim incarnations, particularly Vimperator and ViEmu. I tried both (and vim itself) for about a month some time ago and just couldn’t get into it. These days, I’m doing a lot more hard-core coding and have a more vested interested in getting off the mouse. Surprisingly, it wasn’t as hard as I thought to get back into the saddle, at least for the basic navigation commands.

Anyway, on to the real reason I called you all here today.

ViEmu and ReSharper are not quite best friends yet. They’re tolerant of each other and try to stay out of each others’ way but I hit some issues after installing ViEmu. There may be more incompatibilities but I ran into two before negotiating a detente ‘twixt the two:

• Shift-Alt-L no longer works (R# shortcut for opening Solution Explorer with the current file highlighted)
• In Fonts and Colors, the ReSharper options disappeared under the Text Editor settings.

The second caused some issues because in my fit of re-ergonomics, I’m also trying out a light-on-dark Visual Studio theme again after also discarding that some years ago. I’ve also got the Highlight Current Line option turned on in ReSharper and if you don’t have the ReSharper Current Line option listed in Fonts and Colors, the default is a very bright and very unintelligible white.

The issue seems to be the order in which things are installed. I had installed ReSharper first, then ViEmu. I also uninstalled both, then re-installed them in the same order. But before installing ViEmu, I verified that Highlight Current Line worked as expected. After installing ViEmu, I was back to a veritable blank line for my highlighted row.

Next, I uninstalled both and installed ViEmu first, followed by ReSharper and all appears right with the worl—...well, let’s not get carried away. I’ve got Visual Studio working the way I want is all.

Kyle the Mediator

Thursday, March 05, 2009

Going ahead with this post without a full investigation because, well, isn’t that pretty much the defining characteristic of a blog?

I’m working on an application that reads data from a database and dumps it to an XML file. So I’m trying to figure out how to use NInject to inject dependencies into an SSIS package that uses managed code. I almost have it working but I have one small issue with the…

Haha, I’m kidding of course. But I would love to have seen the collective spit takes all of you did when you read that.

In fact, it’s a console app. It takes a single parameter which determines what kind of entity we want to export. Hypothetically, let’s call them Critters, Recipes, HuntingGrounds.

The export process is identical for each of these: retrieve data from a repository and iterate over each item, dumping it to a file. The only difference is which repository is used to get the data. Which is where contextual binding comes in.

This is my first foray into NInject which is my way of seguing into “If you know a better way, I’m all ears.” I’ll skip the NInject overview because it’s described on their wiki. Instead, here are the important bits of the module:

public class AIDependencyModule : StandardModule
{
    private readonly string _exportType;

    public AIDependencyModule( string exportType )
    {
        _exportType = exportType;
    }

    public override void Load()
    {
        // ... Bind other dependencies
        Bind<IExportRepository>().To<CritterRepository>()
            .OnlyIf( l => _exportType == "critter" );
        Bind<IExportRepository>().To<RecipeRepository>()
            .OnlyIf( l => _exportType == "recipe" );
        Bind<IExportRepository>().To<HuntingGroundRepository>()
            .OnlyIf( l => _exportType == "huntingground" );
    }
}

This is all shiny and happy and works swimmingly. When my data reader class thingy needs a repository to retrieve the data, the correct one is used based on the exportType, which is supplied via command-line arguments. Pretty much a text-book case for contextual binding.

But it’s not what I really wanted to do when I first looked into this. Initially, I was looking for syntax like this:

To clarify, this is NOT valid NInject code.

public class AIDependencyModule : StandardModule
{
    private readonly string _exportType;

    public AIDependencyModule( string exportType )
    {
        _exportType = exportType;
    }

    public override void Load()
    {
        // ... Bind other dependencies
        Bind<CritterRepository>().ToSelf().WithName("critter");
        Bind<RecipeRepository>().ToSelf().WithName("recipe");
        Bind<HuntingGroundRepository>().ToSelf().WithName("huntingground");

        Bind<IExportRepository>().ToItemWithName(_exportType);
    }
}

That is, I want to register all of the repositories in the container, then bind IExportRepository to one based on the name. This seemed cleaner to me. If I want to add support for some other type, I can just added its repository to the container and be done with it. Instead of adding conditional logic to the IExportRepository binding.

That said, this is less efficient than the way I’ve actually done it above. In that case, the only repository in the container is the one I need. With my fanciful, non-existent way, I’d add a bunch of repositories, then end up using only one (unless I actually do need the other repositories elsewhere, which is not the case here).

To provide full disclosure, I had initially started typing this post with the aim being “why can’t I do it the way I want to.” It wasn’t until I started getting the ideas down that I realized my way would be sub-optimal. Just the same, I’m wondering:

• a) if providing bindings based on name might be useful in other contexts, or
• b) if it’s already available, how does one go about it?

Kyle the Contextual

Sunday, March 01, 2009

This post is here for informational purposes only and is meant to be hit by users searching for a specific error. If you are reading this in your RSS reader, I apologize in advance for forcing you to read this far.

The context: An MVC application using what I believe is RC1 of ASP.NET MVC and Sharp Architecture.

The error:

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0433: The type 'System.Web.Mvc.ViewPage<HoochBase>' exists in both 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\GrowOpMgr\9ce51819\6bc1e534\assembly\dl3\e30b5990\f8ba0707_929ac901\GrowOpMgr.Web.DLL' and 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\GrowOpMgr\9ce51819\6bc1e534\assembly\dl3\27c4ec24\01860e2f_d595c901\System.Web.Mvc.DLL'
Source Error:

Line 170:    
Line 171:    [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 172:    public class views_hooches_index_aspx : System.Web.Mvc.ViewPage<IEnumerable<HoochDto>>, System.Web.SessionState.IRequiresSessionState, System.Web.IHttpHandler {
Line 173:        
Line 174:        private static bool @__initialized;

Source File: c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\GrowOpMgr\9ce51819\6bc1e534\App_Web_index.aspx.9399a72b.8jtr0zsp.0.cs    Line: 172

 

The cause

I had created a view page without the aid of the MVC templates. I.e. I added a regular Web Form and manually changed the Inherits attribute in the Page directive at the top to System.Web.Mvc.ViewPage<HoochBase> like so (notice I also deleted the CodeBehind and AutoEventWireup attributes):

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<HoochBase>" %>

That is, I want to derive from the ViewPage<T> class, not from the code-behind. But I forgot to delete the code-behind files that were created by the Web Form template. I can only guess at what’s happening behind the scenes.

Note that if you do the same, this compilation error will occur on every MVC-based page, not just the one you created.

I imagine this doesn’t occur when you create an MVC View Page directly from the Add New Item dialog but I don’t have those templates. Installing them requires one of the following:

• Running the msi package for MVC
• Extracting the templates from the msi package and installing them manually

I don’t want to do the first because it installs MVC in the GAC which I absolutely do not want given the number of MVC apps I have lying around my machine using various versions of the framework. As for the second, I’m lazy, okay? YOU’RE NOT MY MOTHE---actually, I probably shouldn’t make that claim…

Would be nice if the MVC templates for creating view pages and view user controls were available outside of the .msi but it’s not hard to create pages/user controls without them.

Except when you get compilation errors, I suppose.

Kyle the Runtimed