Author: Sean

XUnit.gui.exe – this assembly is built by a runtime newer than the currently…

So ran into this while using XUnit (For my new F# adventure) and I ran into this error when I tried to use the XUnit.gui.exe thing:

“This assembly is built by a runtime newer that the currently loaded runtime and cannot be loaded.”

Pretty straightforward in that I am creating projects in 4.0 and one can infer XUnit wasn’t ready for this. At first I was thinking, painful as that is, that XUnit can’t handle 4.0. To my relief, I found this post at:

www.markhneedham.com

Great… except it only talks about the xunit.console.exe.config and there wasn’t a xunit.gui.exe.config. Well in a moment of questionable brilliance, more like a slight moment of clarity, I decided to copy the xunit.console.exe.config and rename the copied file to “xunit.gui.exe.config” and it worked. Go figure.

This is a picture for the slighty less lazy:

And for those more lazy than that:

Here’s the xml in case you’re more lazy than I am.

Into the unknown… sort of.

So after about eh 3? months of not writing anything (Mostly due to the joy slash nightmare of a newborn) I’ve had a real “come to [Religious Figure]” moment… And that moment has taught me that java based off shoot languages are a pain in the ass to even get started with. This is the typical how to guide:

So yeah, I’m back to the Net but with a twist. Not much an M. Night ‘They call me Mr. Glass’ kind of twist, more of the ‘Oh for &$#@’s sake’ The Happening kind of twist. Yes, I am venturing into F#… and maybe never back again… except for work. But never to be back again outside of work. Ah who am I kidding? Who cares. (That includes me)

Unit Testing 4.0 Web Forms Including Event Handlers Like Page_Load Using Dynamic

If you’re too lazy or just plain impatient, you can find the source code here.

So one of the biggest pains in a place that doesn’t lend itself well to be in pain has been trying to unit test web forms like how MVC controllers can be. Before 4.0, this was an aggrevation at the least. Something in between stubbing one’s toe and getting only chocolate icecrfeam when you ask for a @*&*ing swirl. Serious, how hard is it to pull the swirl lever? Really.

Anyways, so there are certain things in .net web forms that were pretty difficult to hande/mock/get around for testing. Let’s take session for instance. Session is a sealed class with a non public constructor. To make things more interesting, the Page class only has a get for the Session property. Now you could go through a lot of hell, mostly reflection, to get aroud this, but who wants to do that? Personally I gave web forms the ole one finger salute, but being that I am working with web forms again… yeah had to find a way to get around this. The answer? Stems from dynamic.

Basically what I had to do is create a class that has a Session property that is dynamic, and then replace the old Session call with a class that calls a property named Session. The effect to the code, as far as the immediate code behind is concerned, is just this simple adding of the class before the Session call. Far as the code to do this, it’s fairly easy too.

First I started with an interface since using an interface will help later if I need to mock.

This is the bread and butter. Basically we have a container that will hold the session object. Making the property dynamic allows it to be set to anything. All I have to worry about is that whatever I set it to has the functionality used by Session. This is started by implementing the interface fo use on the site:

And then one for use with testing:

How are these used? Well if we take a base page:

So what this does is holds two constructors; One for use by .Net when it runs the site and one for the test class when it is testing the page functionality. The second is a way to stop all the stuff that happens in the Page class constructor when it’s time to unit test this [explitive]. This might look familiar to people who have used things such as Dependency Injection with MVC to help with Controller testing. If not, the idea is simple. It basically just gives the Page the test handler we need it to use when testing. If we aren’t testing, then we let it just use the default handler.

You might wonder why I didn’t instantiate the live version in the constructor, and the answer is: Session isn’t ready to be used at constructor time when doing the normal web site thing. Therefore, it will be set the first time the SessionHandler property is called. If it’s a test, well then it’s fine to set it in the constructor since it is bypassing the normal web site… thing.

The unit test looks something like this:

As you can see, a test version of the handler is created and the Session object is replaced with a Dictionary since that’s what Session is… well it has more to it but the most used feature is the key/value match and it happens to be the only part of Session I show in this example.

Since there is the second, test only, constructor on the page, we don’t have to worry about any asp.net stuff getting in the way when instantiating the page. The page will look like this:

As it can be see, the replacement of the Session call with SessionHandler.Session allows the features of Session but also the testability it lacked for so long. It’s true that if you want to use other features of Session, if there are any and I can’t remember, you’ll have to just add them to the test version so they can be called at test time. I can’t do everything for you.

Off Topic: Austin Dudley and Dragon Karate

So every so often I have the need to see where Sport Karate is at this point, mostly because it’s just plain enjoyable to watch. Being a bo guy, there is some difficulty I’ve had in the recent years watching bo competitors. Most of them have exceptional open hand forms that they just kind of hold a bo and make it a weapons form. A far departure from some of the mid to late 90s non-traditional bow work. At the risk of sounding old with my sort “Music just ain’t like it used to be.” rant, it’s nice to know that there are some out there that still carry on the tradition.





Now I could be biased since he’s a student of Dan Cousineau but I think it’s pretty easy to see Austin is the real thing. Any ways, hope you enjoy.

Test Driven Development… A Simplified Start

So I went to a “doctor’s appointment” yesterday and was asked to do some pair(ed?) programming to solve a simple-ish request. Basically it was:

Get a number in a list of integers that is closest to 0.

Sounds easy enough, right? Well there are a few more rules but nothing game breaking:

  • If the list contains a 0 then return 0
  • If the list is null then throw ArgumentNullException
  • If list is empty then throw ArgumentException
  • If there is no 0 then get the number nearest 0
  • If the closest is the same for positive and negative (Say -2 and 2), return the positive

Again, fairly simple thing to work on.

Right off the bat I set about creating the method for doing this since my usual plan is:

  1. Create method
  2. Unit test
  3. ???
  4. #$@%!

The fourth step is actually repeated a couple times.

So after I had done the more brute force sort of way, and had a failing test, it was suggested I start over. This time stick with the TDD like mindset of

  1. Create test
  2. Fail test
  3. Add code to make it work
  4. Watch it succeed

Now the concept of TDD I have known about for a while, but never really had a chance to really jump into it. After all, most companies just want something done now, not done well. Beyond that, I had reservations of how it works and whether I was smart enough to pull it off. After all, I had always thought you have to be able to see the whole method before it’s written in order to create tests. Well after yesterday I can say I was wrong… at least about the second part.

When I started writing test methods I was told to make them each this way:

Always add to a method the most simple way to get a test to run.

Yeah ok, it sounded better when I heard it yesterday. However, I have examples.

So if we take the first requirement:

If listToCheck contains a 0 then return 0

Well what should I write as a test? Easy:

As you can see I am only checking to make sure there is a 0 returned. Side Note: You might notice that the method is red. This is because it hasn’t been created yet. That’s the next step. What should I put in the method? Remember I only want to put in the most simple way to get the test to pass.

Which gives me this guy:

Right now you’re probably thinking that test is the programing equivalent of Master of the Obvious. I mean, of course it passes because it always returns 0. The next unit test might help with seeing the bigger picture:

Ok so now I’m testing:

If the list is null then throw ArgumentNullException

So naturally I have a test that expects an ArgumentNullException to be thrown. I don’t have that yet in the method though so the expected result when running the test is:

Boom. Go figure. Next step is to add only what is necessary to make the unit test pass.

Now you can see that I have added an exception to be thrown if the list is null. Time to run the tests:

Now I know that the method does take care of the first two requirements. From here I go requirement by requirement and create unit tests to make sure the requirements are met and have them all fail at first. After the test fails, add in the minimal amount of code necessary to get the test to pass.

Eventually you will have a working method that is completely covered.

You might be wondering why this site still exists but you might also be wondering why you should go requirement after requirement adding just what’s needed. The answer is actually simple: It lets you know exactly what changes you make breaks any other test. You see, if you were to do the normal “build the method and test” and there’s a test failing, it becomes harder to track down the issue since the method is now a bunch of code. Since there are multiple points of failure when you start writing the tests, tracking down a specific error is hard.

If you go requirement by requirement, test by test, you can easily find anything that breaks the created tests since you are only working one requirement at a time. I the first three requirements are met and tested when you work on adding the fourth and for some reason what you added to the method is breaking one of the successful test, you know exactly where the issue is.

I have the code here if you want to look at it as I’ve I’ve commented a lot of the code. It is in VS 2010 though. However I don’t think there’s anything that couldn’t work in 3.5.

I admit it’s kind of a different way of looking at it, but I found it incredibly useful in it’s simplicity.

Add Nunit Reference through NUGet/ Visual Studios 2010

From the “Just putting this here for me” update desk: NUget

What’s NUGet? It’s a way to help with adding things from templates to Add Ons. In fact, it can even be used to add references to your project like NUnit without having download NUnit by yourself. Basically it’s another way to enhance laziness. I like this.

The page for NUGet is here and you can download it from here.

After that restart Visual Studios (At least I had to) then:

From there:

Now there should be a button in that image but I had already added the NUnit reference. Real easy stuff.

Apparently there’s lot of stuff like add ons and templates… I think I already wrote that but I’m too tired and lazy to bother checking. Anywho a developer should be like candy in a kids store.

I Have Found Python and… Well I’m Bored.

A while back I wrote a little ditty on python (Not sure if that’s the correct usage of ditty but when have I ever showed a need to use words correctly?) and at the time I was wowed by how easy it was to develop with Python and (“Wish I were getting money for this plug” plug) Pycharm. Sites were so much easier to create using the Pyramids engine. Everything was wonderful.

Enter Andre and the good ship .Net. Andre has an idea of creating a site for cancer survivors (Completely non shameful plug) and at first I was a little reluctant to go back to .Net. And honestly, if it weren’t for how complicated it is to set up python on a server, I probably wouldn’t have. But being as it is, I decided to take another run at .Net 4.0 and MVC 3.0.

Until that time, there had been something nagging me about Python. It wasn’t the performance since it seemed to work very well. It wasn’t the language syntax. I really like the forced syntax since it helps to keep standards. And I like dynamic languages like a person who likes dynamic languages. The f–k was it?!… Sorry that sentence was uncalled for. I’ll try again What the f–k was it?! I mean the language was built to be easy to use and easy to build with. And honestly, it is. What wasn’t I happy with it? WHY CAN’T I JUST BE HAPPY!?!?!?1117

Well right before I went back to C# for the site, I was sort of dreading the idea of having to work in a semi non dynamic and ridgid language. But it was for a good cause and like a man trapped in a jell-o wall, I would just have to push my way through. (Ok so I’m not exactly Leslie Nielsen here)

Then something magical happened. Maybe not David Bowie Labyrinth like magical, but still some degree of magicness. What was this crazy thing? I actually remembered why I liked programming in the first place. Yes C# isn’t as easy to use as Python. Yes it’s more rigid and demanding. Yes you end up with a ton more classes and flies for that matter. BUT I think that because Python is so easy to use, it stifles imagination and creativity. Everything is so lax and unpunishing in Python that it’s so easy to forget the more intellectually (And I use that word loosely in reference to me) challenging aspects of programming. You don’t need interfaces. Mocking object for unit tests is stupid easy. Hell you can even get away with out really creating many classes. Everything is so d—ned easy.

Yeah I know, I’m nuts. I don’t think there’s any question about that. With that said, I think there is some truth in what I’m saying. If you are just a paycheck programmer, you probably could happily roll with Python as it’s structure is by far easier to work with. If you really enjoy the challenge of creating systems that can be refactored and decouple constantly, it’s kind of boring. Don’t get me wrong, you can still do these to some extent with Python but in reality there’s only so many ways you can improve what you have. Far as I know, that’s by design since Python was created more for fast prototyping and development.

I guess I would compare it to cars. Some people would rather spent more money to get the complete package. You could go and buy the new 2012 Mustang Boss and get it loaded for about 45k OR you can buy a GT and spend less than the 15k price gap on aftermarket parts. They both would end up with great performance and both could have good arguments on which is the better way to go. It just depends on the kind of person you are. Some people like the easy path because it’s most likely the faster path. The others, well the others like the journey to get where they want to get. The old “Life’s a journey, not a destination.” cliche.

Which is better? Well that’s up to you. On one hand have Python that is built for fast production. The other is C# that can provide more self challenge and to some more self enjoyment from the challenge. Not sure which side is right, but I just seem to lean to the latter.

Does that make me a horrible person? No it’s just what I like. However, the drink I thought up that’s made from freshly squeezed celebrities might. (Now with less pulp)

Things You Need to Know about Jobs in IT: Free EBook

Somewhere about a year and a half ago or so, I thought to myself, “Self, what do you do well?” Besides the ability to watch Star Trek the Motion Picture twice a week in any given week, I came up with my ability to get a job no matter where or what (including an imploding stock market). I would like to say it’s because of my uncontainable amount of awesome, but it’s mostly that I’ve had 10 jobs in as many years. I know that sounds bad, but with that comes a lot of interviews. And a lot of conversations with recruiters. And a lot of experience with contracts, salary issues, company double talk, and well, a lot more. Basically every step of the hiring process and leaving process.

Then I realized there’s even more than that…

As conceited as this might sound, I started to see that I actually have a lot of knowledge on the given subject. Seemed like kind of a waste to keep it in my head and more accurately, in my brain. (As we all know from the world renown anatomy professor Pudge Rodriguez, “because in the head is the brain.”)

So I started writing everything I could think of down. Anything from how recruiters work to how to avoid costly (Money yo) mistakes when it comes to contracts. Today, I have it ready for the world (or the two people that come here) to see.

Basically it’s the book I wish I had years ago. Then again, if I had it years ago, I wouldn’t have written it. And if I hadn’t written it, I wouldn’t have had it years ago. And if I didn’t have it years ago, I would have written it now…

If you’re an experienced worker you might be thinking, “I don’t like taffy…”, but you might also be thinking, “I can get a job just fine, what the hell could this do for me?”

And that would be a good question. The answer is: It’s not just about getting a job. It’s getting a job YOU want and making sure you get it by beating everyone else out. I won’t lie, experience helps to get most jobs. But I’m not talking about most jobs, I’m talk about the jobs you want. There are a lot of people out there with experience, and there are only so many good jobs. You’ll need every little bit to be triumphant.

So with that in mind…

ByATool.com Presents:

Getting a Job in IT

This eBook will teach you about…

[box type=”tick” style=”rounded” border=”full”]Common Resume Mistakes[/box]
[box type=”tick” style=”rounded” border=”full” width=”300″]How To USE Recruiters[/box]
[box type=”tick” style=”rounded” border=”full”]All the types of Interviews and how to ACE them[/box]
[box type=”tick” style=”rounded” border=”full”]Detailed analysis of contracts[/box]
[box type=”tick” style=”rounded” border=”full”]Detailed analysis of salary[/box]
[box type=”tick” style=”rounded” border=”full”]What to look out for when it comes to salary[/box]

Inside, you will find advice like this…

[quote style=”boxed”]
Be very careful what you say your job title was.If someone calls on a reference and says something like “How was Johnny as an architect?” and you were really a junior developer, bad things happen; Very bad things.

[/quote]

and…

[quote style=”boxed”]
Something you may not understand about the HR side of interviewing is that you aren’t looked at to hire, you’re looked at to eliminate.If you are in a very competitive environment with lots of candidates, the best way to deal with this is to get rid of as many as possible right off the bat.

[/quote]

Has the Programmer Dream Died?

I realize that developers don’t have a Hippocratic Oath but I figure if it did exist would follow in the same footsteps. 

I swear to complete my task to the best of my ability.
I will not settle for good enough to complete a task.
I will admit when I don't know and seek help from those who are more knowledgeable.
I will never obfuscate to ensure my continued employment.
I will prevent future issues by taking care of current ones.

And so on. Now this may not fit with all developers, but I have to think there’s a decent amount of developers that would like to hold this oath as a guideline for development.

“Aye, and if my grandmother had wheels, she’d be a wagon.”

I would have to think that such an oath would work if lives were at stake like they are in medicine. After all, there’s a pretty good indication of failure when a person lives or dies. Programs for the most part are a bit more gray. How many times have you walked into a new job to work on a system that is less than optimal? Then how many times have you asked how the client can stand it and the answer is, “They’re used to it.”

As horrific of a statement that seems to a developer, to the business it’s really not that big of a deal as long as the customer keeps paying. Rewrites and major updates just aren’t going to happen due to the old adage, “If it ain’t broke, don’t try to fix it.” After all, taking time to fix may delay any new features and then could open up a window of opportunity for the competitor. Beyond that, it’s probably a tough sell to the customer. “Sorry we need you to pay more for what you have now because the people we had before working on it weren’t very good. But we seriously have good people this time around! Looooooove youuu.”

So most programs are set in this sort of “Fix it however you can now and we’ll address later” which is the development equivalent of “Don’t call me, I’ll call you.” Of course fixing however it can be fixed only leads to more issues down the road. Around and around the wheels go on the bus.

Because of this unfortunate paradox, I think a little of us dies each time we work on a system. We start to break our oath a bit more every day until the point where we either jump one sinking ship for another or just phone in the code and learn to say, “It’s just work.”

Kind of the overdone cliche about a state representative that sets out to change the world only to end up being accused of snorting cocaine with hookers in Vegas.

I think a good amount of people, and maybe I’m insane (Which I am), want to do it the right way. They want to constantly improve that they’re working with. Problem is, this just doesn’t fit the business mind in the US. (Or other countries, but I can’t speak to that) The US Business culture just isn’t about doing it right, just doing it fast. So systems get built fast, are poorly tested, and covered with layer and layer of “fixes” to the point where it’s so massive that no company will pay to rewrite it. And even if they do, chances are the same attitude that build the mess in the first place will just show up again. Two months after pulling the company off a ledge, you’re ready to get up on that edge.

So how can we solve this? Can it be solved at all? Do any companies get this right and if it does, are they few and far between? Do you have to be in the 90 percentile to get that job?

I have to admit that from time to time I’ve wondered about this. I mean sure you hear of the mystical land of Google or Microsoft, or places built on magical things like TDD and Agile development. But hell, there are only so many jobs and only the top people get them. Does this mean the dream is dead for the unchosen many? Is it possible to bake your oath and eat it too?

MVC3, Entity Framework, jQuery… Everything example

How would you like to have a project that has these features?

Dependency Injection
Entity Framework 4.0 with POCO
Inversion of Control with Castle
The IResult
jQuery
jQuery Ajax Posts
jQuery Custom Css
jQuery Validation
Mocking with Rhino Mocks
MVC 3/Razor
MVC Annotation Based Validation
What I call the Repository Pattern
Unit Tests - Integration With Entity Framework
Unit Test - MVC Controller Actions

And more s--t I can't think of right now!

What’s the price of this gem? Just your time which is worth nothing!

Where can you find it? Right here!

Requirements:

Visual Studios 4.0
Mvc 3
To open the solution and do a search and replace on "Tutorial" to set your directory paths.
A real f--king need to learn!

Act now, operators aren’t in existence since this is hosted on a website, but if they were they would be standing by!

Disclaimer:

This may or may not hit you with a wave of awesome. Be prepared for the worse case awesome scenario. I am in now way responsible for any heart stoppage due to the shock and awe power of the project.