måndag 30 december 2013

FakeMaker - helping you with test driven EPiServer development

Test driven development and EPiServer?
Relax. Test driving the CMS actually got a whole lot easier with version 7. Most of the built in features are implementing interfaces and you can use asp.net mvc. Those ones are two really good friends of test driven development. However, creating that fake content and set up mocked repositories isn't really as smooth as it should (could) be, right?
When mocking code is all you see on your screen, this little library called FakeMaker may help you. Okay, a bigger screen also would, but is probably more expensive. With FakeMaker, you have two classes: FakeMaker and FakePage. The FakeMaker class takes care of the mocking and FakePage helps you create content.
Here's some examples.

Create an instance of FakeMaker:
var fake = new FakeMaker();

Create the pages you need:
var page = FakePage.Create("MyPageName");

or a page of a specific page type:

Add it to the mocked repository:

You can now pass the fake repository to your code (also known as Dependency Injection) from the ContentRepository property or use the built in EPiServer ServiceLocator feature.

Please let me know what you think about it.

Check out the documentation, the examples and the source code:

You will also find FakeMaker at NuGet:

onsdag 18 december 2013

Upgrading to EPiServer 7.5 - without the headache

Earlier today I managed to transform the day from huge #FAIL (with headache) to the good feeling of #SUCCESS (headache gone). Oh, this is not twitter. Sorry, I forgot. 

The project I'm involved in currently, we develop an application with EPiServer 7 (it's actually 7.1 to be precise) and I personally enjoy the product being a lot more testable than ever before. Stay tuned for an upcoming post on test driven development with EPiServer. (and there goes the holidays ... why did I promise that?).

The latest version - 7.5 - was recently released and since we are at the beginning of the project there cannot be a better opportunity for an upgrade. So, we made the decision to at least give it a try.

There is an upgrade guide at the EPiServer World site, but I guess there are a couple of scenarios that the team over there did not try out. I have sent them feedback on this and some issues raised here will probably be solved shortly.

Have a look at the upgrade guide.

I suggest that you follow the upgrade guide along with the stuff I describe here. 

Before you start, I recommend that you take a copy of the database and use the copy when upgrading (don't forget to update the connectionstrings configuration file). 

The first impediment I ran into was that the installer failed because the site was using a VPP folder in an external share. Before you run the installer, copy the VPP folder to your local disk and update the episerverframework configuration file.

If you would wake up in the middle of the night and realize upgrading was a bad move, all you need to do is a rollback of the source code. You only messed up the copy of the database and the local VPP folder. Don't worry.

Follow the steps 1-9 in the guide.

The following step in the guide is about updating the assembly references. Here is a bug. In our project we have added the assemblies from the EPiServer NuGet feed and to update without the headache this what one need to do: right click the references folder, select "Manage NuGet packages" and navigate to the Installed packages folder. Uninstall the references to "EPiServer.CMS.Core" and "EPiServer.Search".

Next up is where I found the bug: when I browsed the new assemblies in the EPiServer feed and installed them, the reference to StructureMap had the wrong version and the code would not compile. What I did was to install StructureMap from the official NuGet feed first. Then I went back to the EPiServer NuGet feed and installed "EPiServer.CMS.Core" and "EPiServer.Search". The previously installed version of StructureMap was already there and was not overwritten.

Here is the version existing in the EPiServer NuGet feed.

Here is the newer version from the official NuGet feed.

The solution is ready to be built. Most likely the compilation will fail, because of the breaking changes of the 7.5 version. Step 12 in the guide is about making the source code changes.

One thing that I find confusing is the code existing in the EPiServer.UI assembly. We have written a custom report in this project and that needed to be updated. The new stuff to use is within the namespace EPiServer.Shell, but the actual assembly is EPiServer.UI. And that assembly isn't referenced when getting the stuff from the EPiServer NuGet feed. So, what did I do? Well, I picked up the local dll from the EPiServer installation folder (the 7.5 folder).

Confusing, isn't it?

Finally, the code actually compiles without any errors. Tadaa!

But wait. Don't browse the site! I did that. And it lead me to the wrong problem solving path. Headache. The site should actually not be browsable at this point, and that is fine. So, move on to the next step in the guide and run the update add-ons stuff from the Deployment Center.

By now, the upgrade is almost done. So close, and yet so far away. The next move is to migrate the VPP files into the new media system. The guide mentions the VPP Migration Tool. But where is it? Guys, a link to the download page from the guide would save us lots of time (and headache). Finally I found the tool at the download page for the CMS 7.5 page (the column to the right with the header "You might also want to download"). 

Almost done. Don't give up! Have a banana and drink some water.

It's time to follow another guide: Migrating VPP-based files to the new media system.

I added the classes GenericMedia, ImageFile and VideoFile. I still am not sure if that really was needed. The guide describes the code as just examples. To be safe I also regenerated the GUIDs with some help from Visual Studio.

The final impediment is the kind of problem that is so simple, but sometimes so difficult to see. I think it's about that tree and the forest, you know? The Migration Tool threw an exception when I tried to connect to the site. The exception was about not being allowed to use external assemblies. "What? Where? Who?"

Man, did I google to find a solution. Whew!

The executable file itself was blocked by Windows since it was a downloaded file. By right clicking it and selecting properties, the "Unblock" button will appear. Click it. Just do it. Run the Migration Tool again and you will finally be able to tweet #SUCCESS.

The things described here has been verified in two different virtual machines, one with Windows Server 2012 R2 and the other one with Windows 8.1 Pro.

Good night.

måndag 24 juni 2013

Kanban bubbles

Recently, a sunny day when my son and I went to the playground, there was a child blowing bubbles. The soap bubbles were flying higher and higher, sometimes they seemed to just hoover high up over the ground, suddenly take a dive and then back up in the air again. Both of us were fascinated.

"-Kanban bubbles."

I liked the sound of it. I guess there was some work issues processing in my head and the brain felt like combining work and play: Kanban bubbles.

At work, I am a part of a small team. We are about four team members working with software development, Kanban style. During the year we have changed stuff, improved things and experimented with tools like test driven development, pair and mob programming. We do, reflect and adjust.

We use a pretty standard way of visualizing our work, a Kanban board with swim lanes. In our agreed definition of done we have feedback (peer review) and exploratory testing as required activities after writing the code. One team member mostly gets to be the tester. The rest of us are mostly coders and peer reviewers

Our swim lane board doesn't really show that when all steps are passed, the release to production is done by the same team members that perform the first step. What goes around comes around. I tend to focus too much on the coding swim lane and too often miss what is happening at the right side of the board. Can our work be visualized in a different way?

Here is a suggestion, Kanban bubbles style.
The Whiteboard has two sections, the to-do area and the work in progress area. The to-do area is where we add stuff, prioritize and estimate. Important stuff at the top, not-so-important stuff at the bottom and we pick the most important stuff to work with.

Let's take a look at the work in progress area. In this drawing I have also added an imaginary circle.

Here I (sort of) have added our team definition of done steps and also tried to avoid those robotic terms that we usually see in Kanban and Scrum boards. After all, coders are humans, believe it or not.

In this picture one of the team members, let's call him Dave, has chosen something from the to-do area to work with. He moves the note to somewhere near Coding… word, draws a circle around it and a connector line to the word (make sure to only use those whiteboard pens, folks).

After some time the work in progress bubbles might look something like this.

What about limiting the work? By visualizing this way, there isn't very much space to add items, the actual (limited) space at the whiteboard is used for that. I think this way of visualizing probably is better suited for small teams.

The Kanban bubbles board is just an idea materialized from a moment of inspiration. Maybe our team will try this out in the real world, maybe not. The real world at the office is probably the only way to actually know if ideas are good or not. Or is it in the playground?

lördag 15 juni 2013

Hipster or neckbeard?

Man, that (asp.net) webforms thing really suck, doesnt it? We should convert all our sites to mvc. For all the new stuff we’re about to develop, there is only one way: mvc. But wait a minute. I forgot to ask.


If you are developing stuff for the EPiServer CMS product, choosing between the two is a big thing these days. I think many EPiServer developers has felt left behind (myself included), being stuck with webforms when the rest of the world writes cool and awesome stuff with mvc and the frameworks that comes with it. I guess those poor SharePoint guys feel the same, dont you think?

The times are different now. All of us can be cool these days (well, almost all of us. SharePoint will get there too some day).

Ok, so it’s about being cool?

Maybe. I would choose mvc because of one thing only: test driven development (tdd). Mvc is designed for that. Webforms isn’t. The rest is just style and preferences: design patterns, view engines, frameworks.

Is test driven development cool?

I think tdd is a great tool for helping you create both short term and long term value. The result will most likely be a product with nice and simple code. Nice & simple, as in easy to understand, maintain and refactor. Test driven development with webforms is mostly depressing. But hey, that is a different blog post.

Writing testable code, huh?

Well, Im not really talking about just writing testable code. Dont do that. Do test it & the code will follow. That's doing it the test driven way.

So who is the cool guy then, webforms or mvc?

I don’t know if anything used together with .NET and Visual Studio can be considered cool, really. We should probably check with @hipsterhacker or @neckbeardhacker about that. But don’t just settle with writing testable code with asp.net mvc. Without unit tests that proves it, the code base won’t probably be testable anyway.

So, without unit tests all that is left is choosing by style and preferences. Think about if that generates any value. Then make your decision on which way to go.

Check out my recent posts and videos on test driven development:

måndag 10 juni 2013

From the streets of Test Driven Development: JavaScript

"... Let the unit testing drive your design. Write a unit test that specifies what should be done. Do a couple of variations if necessary, and then write the code that does the job. Switch back and forth between the unit tests and the code, refactor and clarify.

If you don't trust your code, write another unit test that provokes side effects. Do that until you feel confident. Then go home and have a good night sleep. ..."

(Okay, it's me. I said that. I just thought it would be cool having a quote as an intro to this post)

Test driven JavaScript? 

Write a simple test, write a simple function. Done. 

That was the twitter version. What about the blog version? I think test driven development (TDD) is a good tool for helping you write code with high readability and a design with ease of use in mind (sometimes).

As a tool for testing (no matter what programming language you choose) TDD is overrated and quite often misunderstood. Probably because of the word Test in it, don't you think?

Before we start, I want you to don't care about stuff like code coverage, what frameworks to use and every line of code should have a corresponding unit test. That last thing is just nonsense. Think about the result, the code that actually will run in the production environment. The result is important. No matter how many nice unit tests there are, the result should be as simple as possible. Simple, as in easy to understand, maintain and refactor.

Simple is really difficult! I have failed with that many, many times (and still do, but never give up trying). What I have learned is that having a bunch of unit tests doesn't compensate for unnecessary complex production code. With or without unit tests, complicated code still sucks.

Also, don’t start the TDD journey by evaluating all those tools and worrying about continuous integration scenarios. Leave that for later. 

Do it the Agile way: experiment and learn.

"- Cool, I know unit testing already. I use that when writing C#. But TDD with JavaScript, how?"

If you come from a C# or Java background and already write unit tests (but have little experience of JavaScript) I think test driven development will help you understand and explore the language.

TDD has helped me to break free from the mindset chains of C# and Java style programming. JavaScript is not object oriented like in those languages. There are no classes, it is a language of functions and objects (and functions are objects). Objects can inherit from other objects and every object has a force field surrounding it (aka Closures) that is really powerful. Maybe we could call JavaScript the class less society? ...Because everyone has a function there.

Enough. (Want the basics? Check out my talk "Rediscover JavaScript" from dotNetConf.)

I have made a 15 minute video on how test driven development can be done with JavaScript and tried to write the code with simplicity in mind. I have avoided the common JavaScript language gotchas, like prototype inheritance and pseudo classes with the new or this keywords. In this video I use only one tool for unit testing (QUnit).

Take a look at the video and please share your thoughts about it!

tisdag 7 maj 2013

Love letter to the Community

Almost two weeks ago dotNetConf took place, right here at the Internet. Sessions were broadcasted live and published on Youtube. It was a two day conference, with a total of 17 different sessions and speakers from at least three continents and a whole lot of different time zones.

The broadcasts were about 45 minutes long with ten minute breaks between the sessions. Everything was recorded with high quality video and audio that made it possible for everyone to follow the sessions in full screen mode. To be able to arrange a conference like this you would need great Infrastructure, sponsors with a lot of cash and a huge team. Right? 

Yes, no and no. Yes, dotNetConf had really good Infrastructure. But no sponsors and a very small team.

- How's that possible?

I think dotNetConf is really about Passion. And Fun. And Free. People passionate about what they do. Coding at work, coding after work, coding talks, coding in thoughts (coding in sleep?). People who want to learn new and cool stuff, share insights and all of this because it is fun! People who love what they do and they'll even do it for free.

- Dude, nothing's for free.

Okay, the guys that arranged dotNetConf most likey has spent a huge amount of their own time making this happen. And about $10 (!) for hosting the web site on Azure. With passion, time and $10 you can create a space where 2.400 people join live talks, demos and chat rooms. I think that is amazing.

Thousands of people from all over the world registered to the event. A couple of weeks later there is now a long tail of daily page views at the dotNetConf Youtube channel. As being one of the speakers I am stunned by the positive feedback I've got after my session. Thank you!

Here's the recording from my session Rediscover JavaScript. Please contact me if you have any questions or feedback about the presentation.

If you like the presentation style and level, you might be interested in checking out the video Quick Start: Test Driven Development from aspConf 2012.