lördag 6 februari 2016

FakeMaker is updated with Episerver 9 support

Hi Episerver developers!

I have updated FakeMaker (helping you unit test your Episerver code) to support the version 9 binaries. Breaking changes caused compile errors (oops!) and made the tool incompatible with the latest versions of Episerver. It turns out that the base library context no longer has to be mocked, and that's a good thing! The solution was simple: delete code. I love deleting code, maybe even more than writing code.

FakeMaker may help you delete your code.

When writing unit tests, creating fake content and mocked repositories can be a bit depressing. When mocked code is all you see on your screen, this little library may help. A bigger screen probably also would, but is probably more expensive (and won't cure depression).

The latest version is available for download on NuGet, and the source code is on GitHub. Both are targeting version 9.6.1 of the Episerver Core libraries.

If you need Episerver 8 support, download an earlier version from NuGet, or clone the GitHub repo and checkout the epi-8-support branch

Please let me know if you have feature requests or run into any issues.

Here's an example of what you can do with FakeMaker: 
you are about to write code that uses the episerver page tree to find pages of a certain type, children of a root node, or maybe just the start page. FakeMaker makes easier to write unit tests for code like that, by creating an in memory page tree and add it to a fake content repository.

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

or a page of a specific page type:
var myCustomPage = FakePage.Create<CustomPageData>("MyOtherPageName");

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

Add it to the mocked repository:

Want more examples?
You will find more examples at the FakeMaker GitHub repo.

fredag 5 februari 2016

Windows? No, I'm a .NET developer.

A couple of days ago, I talked about and coded some of the new ASP.NET Core 1.0 things at the Swetugg 2016 conference in Stockholm. I used my Ubuntu laptop, the one I write code on every day at work (also used for occasional night coding at home, when the kids are sleeping).

Nowadays, I mostly write Python and JavaScript code, both are platform independent languages. I love it! When I was about to begin where I currently work, I knew very little about what kind of dev tools the team (or even the Python community) were using.

"Well, some of us use editors like Sublime or Vim, some use an IDE like PyCharm. Most of us have macbooks, but a couple of team members have various Linux distros installed on their computers. It doesn't matter. You'll be fine as long as you can run the 'make' command. What stuff do you use?"

I think my brain exploded.

Remember this movie scene? That was me.

(it's from the 1990 version of Total Recall. The AI/robot/thing gets an unexpected question from a human, doesn't know how to respond and finally breaks.)

I have never, ever, in my life as a software developer heard that question before! .NET development usually equals Windows and (often a specific version of) Visual Studio, at least from my experience.

On my first day at work I was very excited to use Ubuntu, code in PyCharm and write strange terminal commands. Today, a couple of months later, the terminal has become my new best friend. Ubuntu is fast, responsive and doesn't get in my way. Well, sometimes a bit tricky to use when native apps are missing, but that's fine. It feels like I'm on a diet.

It would be great if we, the .NET people, also were able to freely choose our favourite tools, editors and even operating system.

Because it's fun! We shouldn't underestimate the value of fun. If the tools we use are platform independent, we can be platform independent as developers too. That will bring us closer to other dev communities. Chances are we will learn (and share) more than when staying in isolation. Being a platform independent developer is a good thing.

In fact, .NET developers can do all of that now.

I have been following the development of ASP.NET 5 (recently renamed to ASP.NET Core 1.0) from the early beta versions, and started experimenting with it on my Ubuntu Linux machine a couple of months ago. This is my current setup: write C# code in Atom, push commits to GitHub, trigger builds and publish to Azure Web Apps when pull requests are merged.

Developing on a Linux dev machine and publishing to a cloud based Windows machine.

Atom, really? I know, Visual Studio is hard to compete with, especially when used together with ReSharper. But editors like Atom are lightweight. I like that. They are not only lightweight, they also have the possibility to install plugins like OmniSharpOmniSharp add editor features close to the ReSharper experience.

Lightweight tools need friends, and one of them is the terminal. It might be a bit intimidating at first if you are not already a command line user. It was for me. Now, I rather write oneliners like this, than right clicking some menu option or opening a dialog window:

git checkout -b my-new-feature-branch

Once learned, it is so simple. Let's stay in the command line window, because there is another essential tool for platform independent .NET development: Yeoman.

With Yeoman, we get the command line version of "File -> new project". You can also install Yeoman as a plugin to Atom. I usually create a new C# project from the command line and later add files using the Atom plugin.

What about Mono?
I haven't figured out how to exclusively use the new modular CoreCLR on my Linux machine. I can't get it to work without selecting the Mono version in the .NET version manager (the dnvm command). I guess it will be fixed soon, but it doesn't really matter if you want to get started now. Mono is the platform independent version of the system wide installed .NET Framework on your Windows machine.

Besides that, Mono comes with a great tool: the REPL.

Great for experimenting and learning about new cool C# features. Just type the word csharp in the terminal and start experimenting & learning.

So far, the .NET development on Linux experience has been very nice.

tisdag 10 november 2015

Test friendly JavaScript modules - without Dependency Injection

A while ago, I was trying to figure out how to use test driven development with ES2015 (also known as ES6 at the time). It turned out to be a nice experience, and I wrote a blog post about it: Can I test it?

However, I had some concerns about the import feature and how to deal with module dependencies. I wrote a blog post about that too: Is the ES6 import feature an anti pattern?

Recently, I have been learning Python and was surprised by the similarities with JavaScript - in coding style, philosophy and language features. I guess Python has been a source of inspiration for the new ES2015 stuff. I have quickly become a fan of Python and I think it is a very nice language.

 At first, as a Python newbie, I stumbled upon the same questions on how to unit test modules containing a bunch of import statements. Luckily, at work I am surrounded with great programmers in general, that also are experts in the Python language. With Python, the answer to my questions was both simple and obvious. Python is a dynamic language: load the dependency in the unit test, then just override it. The code under test will use the already loaded in memory module. Simple, huh? It seems to me that there is no need for c#/java like dependency injections. I guess it was my typed language mindset that had guided me to IoC and DI patterns.

What about JavaScript?
I think it is (almost) as simple! Modules and imports in JavaScript are similar to (but not exactly like) the Python way. In JavaScript, I guess it also depends on the module loader used in the current environment. I have experimented with this. My setup contain ES2015 modules and unit tests, that are transpiled with Babel to RequireJS modules, runs in a browser or with PhantomJS. With this setup, I have managed to override module dependencies with fakes from a unit test. The module under test will actually run the fake dependency, and there is no need for custom Dependency Injection.

An example: a unit test
import foo from 'modules/foo';
import bar from 'modules/bar';

const fakeMessage = 'a fake message.';

const original = bar.getMessage;
const fake = () => fakeMessage;

QUnit.module('my example tests', {
    beforeEach() {
        bar.getMessage = fake;
    afterEach() {
        bar.getMessage = original;

QUnit.test('can an imported module be mocked?', assert => {
assert.equal(foo.message(), fakeMessage);

And the actual code under test:
import bar from 'modules/bar';

let foo = {
    message() {
        return bar.getMessage();

export default foo;

I would appreciate your feedback on this!

You will find unit tests, code, settings, project structure and setup at my GitHub page:

måndag 27 juli 2015

Coding in the dark: ES2015 and TypeScript on an iPad

Coding in the dark
Summertime, and the Swedish weather is ... not great, but good enough! I have spent some of the vacation days here at the countryside of beautiful Värmland, Sweden, without writing any code at all. But ideas have popped up and I want to try them out. So, now I code when everybody is sleeping. The "Dark Theme" of the editor dim the bright screen light - and hopefully won't wake up the family in the middle of the night.

Direct link: Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.

Offline coding
I really want to write code on my iPad mini, instead of using the laptop (that I also have with me, of course). With low bandwidth - sometimes no connection at all - remoting to & write code on a Cloud based VM is not an option here in the wilderness. Local and offline is better. The Coda for iOS app supports local offline files and the latest version has some really nice features. But why code on an iPad? Well ... why not! And it's convenient too, experimenting with code snippets is just a smart device away from being realized. The solutions I present here are of course useful for countryside coding on a laptop too.

ES2015 on the iPad
I decided to give ES2015 coding a try. Does it work, using an iPad and the app only? Yes, the built in web browser and file system of Coda for iOS makes it possible. When I figured out how to transpile and run the scripts in the web browser (by using Babel and the es6-module-loader library), I got carried away and thought it would be cool to also write TypeScript on the iPad. It turns out to be just as easy as the ES2015 setup.

TypeScript on the iPad
I found a nice library on GitHub by Basarat Ali Syed, that makes it possible to transpile TypeScript files to JavaScript in a web browser: basarat/typescript-script 

Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.

Command line experimenting with the JavaScript Playground
One of the new features of the Coda app is a command line based JavaScript playground. Scripts can easily be loaded into it and the transpiler functions can be executed from the command line. I think it is a useful alternative to the web browser, and very helpful when I want to see the actual output from a transpilation.

Happy iPad coding!

måndag 25 maj 2015

Building a bank with EPiServer?

Can it be done?

Yes. And this blog post is about how it can be done. I want to share my thoughts and experiences about writing EPiServer sites, connected to third party services and/or external APIs, with code examples and design suggestions.


Should it be done?

Yeah, why not? Long answer: if you already have a nice and smooth communication between product owners and developers - a daily constant flow of feature and content production releases - you probably wouldn't need a Content Management System (CMS) at all. But if you release code a couple of times a month, maybe even longer in between the releases (like most companies out there), a CMS is great to have in place. EPiServer is a good choice for that. Let's build a bank with it!

Actually, I have built one already. Well, no. Not really. But I wrote an example project with some of the building blocks I think an EPiServer site connected to external back end systems should have. 

Here's the code (at Github)

I know, I know ... it's a very simplistic example. I wanted to get rid of all the noise, and focus on the "core" stuff that I think is important. I think most of the features in the example code are ready for you to use today, a few things are for demo purposes only (like the implementation of the logger interface). 

NoScript First

The example code is an EPiServer MVC site: one page instance with a form that is posted to a controller on the server. The server code is sending the data to an external web service and the service returns user data to be displayed in the user interface. 

Let's zoom in to the form and the posting. All user input should be sanitized and validated. The data sent should be restricted to http POST, along with an anti forgery token. Use the built in model binding and data annotations for the validation of data.

I would recommend you to start developing with JavaScript disabled in the browser. That is a development style I like to call NoScript First. I think it will help you to focus on the security and the basic flow. When you are done with the basics, enable JavaScript and write client side code for a better user experience. You can hijack the form submit action and post the data with ajax, instead of a full page reload.

Here's some more info (with code examples) about NoScript First:
You might not need JavaScript


The basics with Dependency Injection

Try keep the controllers as light weight as possible. Extract methods to specialized helper files and inject all dependencies by using a tool like StructureMap. For testability, use c# interfaces instead of concrete classes when injecting the dependencies.

There are trade offs: your source code may seem complex at first look, especially for developers not used to these kind of patterns and abstractions. By hiding the implementations behind APIs (interfaces), you can switch between different implementations, even in runtime. But why would anyone want to do that? I'll will answer that shortly.


Isn't unit testing dead?

Dependency injection will simplify testing. A unit test can focus on a specific part of the source code, by providing it with fake implementations of the dependencies and control the data that is passed between them. But why unit test stuff at all? For me, test driven development is a style. A tool, helping me to write code that is specialized, minimalistic and (hopefully) readable. For me, the actual testing is secondary. That's why I think some parts of the source code can be just fine without unit tests. It is alright! However, be strict with unit testing your validation features, like the custom data annotations in the example code. Write unit tests until you are sure that your validation methods does the right thing. Try different scenarios, not only the happy path. Be evil. If you wake up in the middle of the night, because you had dreamed about ways to bypass the validation, write a unit test that prove it. Solve the issue and run the tests again.

To get the dependency injection stuff in place in your controllers, start with a simple unit test "newing up" a controller, develop and refactor the code from there. I think unit tests eventually will help you find the flow, especially when it's done test driven style.

If your controllers handles EPiServer content, such as traversing an EPiServer page tree to create menus or lists, I recommend using FakeMaker - a tool that simplifies unit testing for scenarios like that.


Something between the web and the services: Providers

A third party web service or a back end API is probably developed for general purpose, to be used by many different channels. A web site is specialized and customized. The data passed from a service will most likely not fit perfectly with the view of a web user interface. To create a nice user experience, the data probably has to be rearranged in some way (formatted, combined, simplified, renamed). Do that in a separate class library.

Map the data objects from the service to local domain objects that are customized for your user interface. Map the service class properties you need to a local domain object. Let AutoMapper handle the mapping, it's a great tool. Also, make sure you unit test the mappings! Included in AutoMapper, there is a unit testing feature called "AssertConfigurationValid". It has saved my life many times.

Let the library take care of the connection to the service, and keep the user interface unaware of the service API. The library should have only the features needed by the web user interface, no more than that.

I would call a library like that a Provider. Consume the providers by injecting them into the web project code (as described earlier with Dependency Injection). The web communicates with the API (the interface) of a Provider, that means that controllers also are unaware of the actual provider implementation (the concrete class). In the example code, the mappings between interfaces and concrete classes is handled by the StructureMap configuration.

With providers, you can switch service implementations without the need to alter the code in the web project. The same goes for the providers themselves. One provider implementation can be switched to an other one. But why would anyone want to do that? Okay, maybe it's time to give some answers.


Fake it!

During development, the back end services may also be developed in parallel and could go offline from time to time. Being dependent on an unstable external service is risky. To be able to write code, browse and test the features of a site, using fake implementations of providers returning fake data is a way out of the problem. Faking it will make it possible for the team to be "offline" and still be productive, i.e. no direct dependencies to a web service or third party system.

There are other practical uses of fake Provider implementations. The site pages that are heavily based on presenting data from back end systems (like an account transaction list) will not look any good at all when logged in as an EPiServer editor (that most likely isn't identified as an existing customer in the back end system). To create a good user experience for editors (and avoiding embarrassing page exceptions in edit mode) fakes can be very useful. Instead of cluttering the controllers with if-else statements all over the place, determining if the current user is an editor or not, you could use your already existing fake providers! That means fake providers actually will be used in production.

To be able to switch between fake and live providers, the injected dependencies need some modification. That is because the StructureMap configuration will run on application start, and checking the logged in user role there won't work. It has to be done per request, triggered from the controllers.


Be water, my friend (inject the Factories)

You probably already have noticed in the example code that some sort of factory is injected into the controller, and not the actual provider. The provider is retrieved later in the constructor, by calling a factory method. This occurs on every request. The factory method is where the if-else checking takes place. Is the current user an editor or not? The StructureMap configuration also has two implementations added - one fake, one live - for a provider interface. This makes it possible for the factory to pull the desired implementation from the dependency resolver.

Note: Today I met Jeremy D. Miller (the creator of StructureMap) at the DevSum conference here in Stockholm, and he showed me some examples on how to configure StructureMap without the need of factories. I like it a lot I will try this out (and update the GitHub code repository).

(Okay, maybe this video hasn't that much to do with injecting Factories, but I like Bruce Lee and think this video is cool)


What's Pippi Longstocking got to do with it?
Finally, let's talk about the fake data itself. Using this setup, the development team have the opportunity to stress test the UI every day, by providing data that goes beyond the perfect and well balanced placeholder text areas in the design templates delivered by the UX team. 

One obvious thing to test is the name of the logged in user. Here's an idea: add a fake data user with the name Pippilotta Viktualia Rullgardina Krusmynta Efraimsdotter Långstrump (that's the swedish full name of Pippi Longstocking)! How will the user info section of the site behave with a name like that? Well, maybe "Pippilotta Viktualia Långstrump" would be enough, let's not exaggerate. But be aware, in the real world, there are people out there with some really messed up names ... being prepared for it might be a good idea.

What do you think about all of this? Please share your thoughts and ideas about building a bank with EPiServer.

Here's the code (at Github)