err... blog anyone ?

Check out ma shiny new blog.. not much in yet and to be honest  I always hated writing a diary as a kid

But... it should be useful to keep reminders of techy/geeky stuff

blog

days off

here's me on a day-off

there may be more in the Gallery

Hi there! , welcome to stooboo.com

This is not the first time I've scrapped and restarted my home page, let's just hope that this time it's a bit more successful and I get into the habbit of updating a little more regularly ;-)

Remember, this 'blog' and site are really just a way of me jotting down ideas and methods in one place so that I can look them up in the future when I forget them

If you disagree with anything you see, fine .. I am interested to know what I may have got wrong and I'm up for some 'chat' to iron out some ideas ..

..but I don't want to get drawn into any big 'my X is better than your X' discussions whether X is .. an OS .. a framework  ... an ORM .. or just an X-girlfriend !

cheers

Stu

 

 

Using White

White

  • Installation

    Not as straightforward as I'd hoped

    I created a project for my UA Tests

    I addeded the White Nuget to the project .. all seemed ok .. until I tried to run the following

      [Test]
            public void Test()
            {
                using (var application = Application.Launch(@"D:\... MyApp.exe"))
                {
                    var contactListWindow = application.GetWindow("ContactList", White.Core.Factory.InitializeOption.NoCache);
                    Assert.IsNotNull(contactListWindow);
                }
            }
    

    For some reason I was getting a load of 'could not load assembly' errors .. so Ok .. I went into app.config and added the following binding redirects

       <dependentAssembly>
            <assemblyIdentity   name="Castle.Core"   publicKeyToken="407dd0808d44fbdc"/>
            <bindingRedirect   oldVersion="0.0.0.0-1.0.0.0"   newVersion="1.1.0.0"/>
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity   name="Castle.DynamicProxy2"   publicKeyToken="407dd0808d44fbdc"/>
            <bindingRedirect   oldVersion="0.0.0.0-2.0.0.1"   newVersion="2.1.0.0"/>
          </dependentAssembly>
    

    Ok ? err no .. it seems that White ver 0.2.0 HAS to have log4net ver 1.2.10 .. and no ver 1.2.11 won;t do it .... ( I think the prob is actually with 'Bricks' and not White itself but still it wouldn't work) .. no amount of binding redirects would sort this out :-(

    So I made sure that my log4net was set to 1.2.10 using nuget .. and hey presto .. it Worked ! :-)

    Initially I thought I might have to run it in .net35 but it works fine (so far) in .net4

    I'm just doing proff of concept with White at the moment.. I', driving the tests using SpecFlow so that the users can make complete sense of them 

    I'll post code soon  

    In the meantime check out this excellent White Tutorial

     

SQL Connection Scope. or .. How to avoid MSDTC

Check out these two excellent articles on why you would want to avoid MSDTC and how you can under certain conditions

http://nullablecode.com/2011/02/how-to-avoid-unnecessary-msdtc-escalations/

The approach is very similar to ContextManager<TContext>in CSLA

 

MSDTC and Trace

It appears after enabling MSDTC on our SQL2k8 box that SQL Profiler and Trace seems to block MSDTC causing exceptions in our apps

Can't see  any other reference to this though on the web .. strange ..

Tasks vs Threads

.net 4 gives us TPL (Task Parallel Library)

This simplifies parallel programming

 

See also 

 

Tasks vs Threads

Testing

I'm in the process of writing a personal 'pet-project' with some basic CRM functionality

I intend to use it in the future to demonstrate 'proofs - of concept' for a number of things like programming practices and general extensions that could be used on our 'works' CRM

Obviously it won't include any 'real' business logic from my day job, but I will probably implement some common business rules.

I've got it to a state that some of the basic requirements are met, but now I can see that I need to implement testing.

Yes I know I'm late in introducing the testing, but testing is something I've tried before and I'm finding it hard to do TDD

Why testing now then ? Well .. did I mention I want to reproduce 'similar' behaviour in WPF and in ASP.net MVC

What I've been doing so far is writing some functionality in WPF, then, when it 'works'... implement the same in MVC. But now I'm adding 'more', the manual testing is getting ... tedious... unreliable... time-consuming.

So the tests I'm talking about are really User Acceptance tests rather than Unit Tests

What I'm intending to do is 

  • write specs using SpecFlow, this will 'drive' the tests
  • implement the 'step-definitions' using 
    • Selenium for targetting the MVC implementation in
      • IE
      • Chrome
      • FireFox 
    • White for targetting the WPF implementation

To be honest I've already started on the Selenium part, I'm using page objects and it looks really promising.

I'll post code and more info on another day, this was just to get down some of my intentions. 

CQRS and Domain Events

Bear with me, this is just a holding-post to list some things that I want to come back to.

It's going to get a bit waffly from here, but that's while I work out what I want from CQRS and DDD, and more importantly how I can leverage them in my code !

As I understand it ..

  • CQRS is rising in popularity
  • CQRS is NOT event sourcing
  • CQRS can be applied gradually to your current programs
  • Implementing CQRS will (hopefully) allow you to do other things in the future e.g. event sourcing
    • It'll encourage you to write 'task-based' or 'inductive' UIs rather than 'deductive' UIs

 

  • Domain objects should NOT have getters or setters
    • This seems really strange but ..if you have getters then someone somewhere will write logic outside your domain object based on the state of that domain object (you can't necessarily prevent that, but you want to minimize it)
  • Domain objects are about BEHAVIOUR and not STATE
    • if you have a domain object with loads of properties and no methods then it's a Anaemic Domain Object.. this is bad … where is the behaviour (i.e. all those methods ?) .. in services? .. tied up in code-behind on a website or in WPF ?  .. BAH !!!
    • Not everyone (every class) wants to know the same things about an object's state… so when we do present state outside of a domain object there many be many 'representations' of that state .. but ALL of them should be considered read-only

Sources

Site Styling

I know that on some of my pages the styling appears to be broken, it's not my fault (not really)

Umbraco has a problem in it's XSLT's

If you write

<blah />

then Umbraco will process it into

<blah>

losing the self-closing .. Bad Umbraco !

So you write

<blah></blah>

Nope … you still get

<blah>

So… the answer?

<blah>&nbsp;</blah>

It's a little frustrating, but it means I need to go back thru my XSLT's as thee styling isn't really broken .. but Umbraco is leaving a whole load of tags open for me by mistake !

Magic strings are a no-no

Magic strings in code are a no-no

Why?

Ok let's say you have a connection string "MyConnection" in config.. and all throught your code you refer to it as "MyConnection", then if you ever need to change it you will have to do a search/replace on the string...

Ok .. so what's the problem ?

What if you have a class called VerifyMyConnection ... search/replace will change the name of that class too .. that's BAD !

So .. wherever possible use constants instead of strings 

In MVC you might want to write

@Html.ActionLink("Home", "Index", "Home")

in one of your views, this is really brittle code, if you change the name of that method on your controller your code will fail !

Also there are TWO parameters with value "Home", looking at it .. which is which ? .. one is the name of the controller .. one is the link text .. 

So.. add a nuget reference to https://nuget.org/packages/Mvc3 Futures

it will allow you to write

@Html.ActionLink((HomeController a) => a.Index(), "Home"

Ok, there is 'slightly' more processing overhead involved in parsing the lambda expression (so far this has proved to be neglible),

but it's far more maintainable and a lot more 'intention-revealing' !!

Note that there is now only one param "Home" which is the link text :-)

Note this works fine with Async Controllers in MVC

stop writing HTML

..sort of ..

If you're using Asp.NET MVC then in your views you may be writing lots of lovely HTML .. because you can . after all that's one of the reasons you switched from webforms isn't it? .. so you'd have more control of the HTML ?

Ok, but remember, the more you hand-code stuff then ..

  • more chances of duplication.. (try to keep it DRY)
  • more chances of typos 

So instead of hand-coding the HTML try to use the HTML Helpers 

e.g.

@Html.ListBox.. blah blah blah

What about Tables ?

Add a nuget reference to 'MvcContrib.Mvc3-ci' and check out http://mvccontrib.codeplex.com/wikipage?title=Grid, a great advantage is that you can change renderers.. so if you have a mice new fancy shmancy client side table script you want to leverage ... you don;t rewrite all your views .. you just change the renderer - GENIUS !

Dynamic Linq

Linq is great for making queries consistent and readable .. etc .etc 

There's plenty on the web about normal Linq ...

And you're used to writing

   items = items.OrderBy(x => x.AProperty);

But .. what if you don't know the name of the property until runtime, e.g. the user is viewing items in a grid and can choose any column to sort on

Add a nuget reference to System.Linq.Dynamic and then you can write

 items = items.OrderBy("AProperty ASC");

(ASC is not required, it was just a reminder to me that you can put ASC or DESC on the end of the string)

remember in this case AProperty is just a string (a MAGIC string ! bad !) .. so there's no compile-time checking, but if the items in the IQueryable don't have a property called "AProperty" you WILL get a runtime exception