Over the last few years I've had many discussions about what constitutes a good PR with fellow developers. I want to summarize here what I've learned and touch base with the rest of developers in the wild (you).

Note: For the context this post, I'm talking about PR's inside an organisation. The requirements for PR's on open source projects may be very different and very often depend on what type of project it is.

Why do we use pull requests?

To understand what constitutes a good pull request, we must first define the reason why we use the pull request process:

• PR's are a great way of sharing information about the code base. They limit code ownership (check my post on avoiding code ownership to see why that's a bad thing)
• It creates an extra gate before our code goes to production
• It improves code quality. This is not only because there's another person to catch mistakes. If you know someone will review your code, you're probably, at least subconsciously, making a bigger effort to write better code.

Creating good pull requests

Whenever I review a PR, I look for the following qualities:

• Logical commits. Each commit should be a single, coherent change.
• All commit messages are descriptive
• The list of commits are related and implement a complete story
• The work in the PR adds quantifiable value.
• Code complies with the defined standards
• The pull request is as small as practically possible

Logical commits

When reviewing a PR, it's really difficult to judge code quality when you only have half the information. Therefore, it's very import that each commit contains a single coherent change, that in theory should be reviewable on its own.

I also prefer that each commit would be deployable individually, although sometimes this can be a bit hard to achieve. However hard it may be in some cases, I always strive towards that end.

Commit messages

This is a pet peeve of me, but far too often I see commit messages that just describe what is done. While that is important information, it's only part of the story. Usually, what is done is easily verifiable from the code. What interests me, as a reviewer, and later as a reader of the code, is why a particular change was implemented. The key questions a commit message should answer are:

• What has changed
• Why was the change necessary, possibly referencing a formal requirement
• What are direct and indirect consequences of the change

What does not need to be in the commit message?

• Who made the change (that is already part of the commit)
• When the change was made (also part of the commit)
• How this code can be improved (this should go in the backlog)
• How you feel about the code

Related commits

When you submit a PR, it should relate to a single theme. Reviewing code can be a difficult task since very often the context is not entirely clear. If a PR tries to fix or implement multiple things, this only gets harder. To avoid this, we should strive to divide a user story we're working on into multiple related commits and submit them as a single PR.

The pull requests adds quantifiable value

This could be in fulfilling a customer requirement, but could also be a refactor, performance improvements, new tests etc.

In the case of implementing requirements, it's fairly easy to see that this adds value. However, in the case of a refactor or performance improvements this may be harder. In these you usually want to discuss this beforehand. Nevertheless, it should be fairly obvious once the PR has been submitted that there is value in the addition.

Code complies with defined standards

While I don't believe style checking should be performed by a human reviewer (this task is better suited to automated tools), there are other standards that do need a review. These could be things like the data access method, a recurring pattern that's been used, usage of internal libraries vs rolling your own.

Before submitting the PR, these are things that should be checked by the submitter of the PR.

Smaller is better

Reviewing code can be a daunting task. As a consequence, the larger the PR, the harder it will be to review. The harder it is to review, the less deep the review will be and it will be more of a code "scan", rather than a code "review".

A good review

Conversely, creating good PR's doesn't mean that you have a good review process. The flip side of it, reviewing the code, is also very important. This is a list of questions and attitudes towards the code under review that could help:

Does this code solve a problem?

Ideally, this should have been a pre-condition before even starting work on the code, however, there are cases where it may not be clear-cut and this is a good first question to ask. If it doesn't solve a problem, then all the rest is pointless.

Does the code do what the submitter intended?

Once established that the purpose is sound, we need to verify whether the implementation is actually correct. This could be trying to find potential bugs, but also unwanted side effects that the submitter did not intend to cause.

How would I have solved this?

This is a tricky one. Sometimes developer styles vary wildly. The purpose of this question is not to force the developer to do it your way, but rather contrast different coding styles and evaluate if one is preferable over the other.

Are there any useful abstractions?

Sometimes the problem may already have been solved elsewhere, but the author is unaware. It's good to point this out and suggest ideas on how to make use of this. In some cases, it will simply be reusing existing code, in others, it might need introducing a new abstract concept to rely on.

Play advocate of the devil

Try to catch any mistakes, errors, violations against conventions, ...
That said, be nice about it. The goal is to improve the code, not to prove your superiority over the other developer. All review comments should strictly be about the code. It's the code that is under review, not the developer.

Is this code covered by tests (and does it need to be)?

Tests are important, not only for regression issues, but also for documentation. If the code is highly algorithmic, then you probably want automated unit tests in place (hint: these are a nice place to start the review, as it will give you a nice list of requirements that are being implemented).

Conversely, if it's mainly coordinating code, question why unit tests are being added and whether they are really necessary. (Check out my post on the test pyramid for more information on what to test and what not)

Does this code follow styles and patterns?

As I mentioned before, pure code style issues should probably be caught by automated tools. Regardless, some things won't be possible through static code analysis, so you want to have a look at those more closely.

Setting standards and guidelines

Apart from submitting good PR's and executing good reviews, another part of the puzzle is having a clear understanding of when a PR will be rejected and when it can be merged. Here are some of the standards that I believe should be in place. The specifics of these may vary under circumstances, but regardless of the parameters, it's good to have a clear understanding between all developers:

Reasons for rejection

Certain things may be a clear reason for rejection. It's important to list these and agree with everybody. The reason is that an early rejection can save a lot of time, both on the reviewer as well as on the submitter side. It avoids discussions over trivial problems. Some of the things that can lead to a straight rejection:

• Failing tests (even better is to enforce this by the CI server)
• Not following styling guidelines (even better to enforce through an automated tool)
• Infractions against the rules of a good PR. This could mean non-descriptive commit messages, very large PR's, multiple stories in one PR, ...

Conflict resolution

Eventually you'll run into the situation where two developers will disagree. That is perfectly fine and actually a sign of good team dynamics. What is not fine however is having endless discussions about it or one developer overriding the other because of reasons like seniority, having the admin rights, etc.

It's better to prevent these situations from happening and have a conflict resolution strategy. One particular method that works well is to always require at least two code reviewers. In those cases, it's simply the majority vote that counts.

Review lead time

One of the biggest reasons I have seen people skip PR's is because it blocks them. When the product team is pushing for a deployment, it doesn't help when your PR is being left in the review code for days on end.

Ideally, a PR should be reviewed within an hour. If PR's are following the practices mentioned in this post, this should definitely be doable. Where it breaks down is on large PR's.

It's therefor very important to keep PR's as small as possible and ensure that reviews are executed promptly.

Another year, another C# update. This time we’re up for already C# 8. I want to dive into the most likely new C# 8 features, what they look like and why they’re useful.

Disclaimer: The information in this blog post was written well before the release of C# 8 and all information in this post is subject to change. This applies to possible inclusion of features in C# 8 as well as the described syntax.

C# 8: Nullable reference types

This feature is the most anticipated feature of C# 8 because it brings a lot of value and is known from other languages such as F#. For backward compatibility reasons however, it will work slightly different in C#.

What?

Hold on! Aren’t reference types already nullable? Yes, they are indeed. What this features brings is a slight shift: from C# 8, all reference types will be considered to be non-nullable by default. When you want a nullable reference type you will have to express that explicitly.

Why?

The dreaded NullReferenceException! We’ve all run into this exception plenty of times and they are mistakes that could have easily been caught at compile time if only we had the means to express it. Nullable reference types don’t solve this problem, but they do allow you to express your intent much better.

Apart from that, there’s an inconsistency between reference and value types: Value types are by default non-nullable, when adding the ?-modifier to the type we can make them nullable. Reference types on the other hand are currently nullable and there’s no way to express a non-nullable reference type.

How?

Similar to nullable value types, in C# 8 you will be able to declare that a variable is non-nullable by simply using the type. In case you want a nullable reference type, you will have to explicitly mention that by appending the ?-modifier at the end of the type. The first syntax enhancement is the ability to express a nullable reference type:

string? someText = null;

The above denotes the syntax for non-nullable reference types. Nullable reference types will then get the following syntax:

string someText = "this is some string"; 
someText = null; // WARNING!

As you can see in the above example, the current syntax will start to have a slightly different meaning: all reference types are considered to be non-nullable. That is a breaking change though. Since C# is so widely used, it’s quite impossible to make such a breaking change, so that’s the reason why the second line says “Warning”, rather than “Error”. If this would be considered an error it would promptly break thousands of code bases. Furthermore, even if this doesn’t break code, it’s still a breaking change because you now get a warning where you didn’t get one before. Therefore, nullable reference types will be considered an opt-in feature.

Static flow analysis

Apart from the rather obvious example above, there will be more benefits through the application of static flow analysis. Consider the following examples:

string someText = null; // Warning: Cannot convert null to non-nullable reference 
string? otherText = null; // OK, assign null to nullable 
string nonnull = otherText; // Warning: possible null assignment

On line 3, the analyzer can detect that we are assigning a value that is potentially null to a non-nullable variable and will correctly raise a warning.

string? text = null; 
var length = text.Length; // Warning: Possible dereference of a null reference

The same applies to dereferencing a nullable variable. The compiler knows that we are potentially dealing with a null reference and will raise a warning. There are two ways to get around this issue: either we declare the original variable as a non-nullable type or we do a null check. Through static analysis, it can detect that the variable cannot possible be null:

string? text = null; 
if(text != null) 
{ 
    var length = text.Length; // OK, you checked 
}

Limitations

There are however some limitations on what static analysis flow can provide:

• Methods that return a non-nullable type will be interpreted as safe. They can however still return a null reference. (For example a library that has not been updated)
• It won’t always recognize whether you have done a proper null check. When you call string.IsNullOrEmpty for example, the analyzer won’t go into that method call to check this.

The first item cannot be solved unfortunately. Because of historical reasons, there’s no way to fit strict non-nullability into C#. This feature will reduce problems with null references, but will not eliminate it.

The second issue is more of an annoyance, as you would have to do an explicit null check even if you know that the item is not null. This would lead to this sort of code:

public void DoSomething(string? text) 
{ 
    if(!string.IsNullOrEmpty(text) && text != null) 
        Console.WriteLine(text.Length); 
}

The above code is obviously redundant and we need a terser way of describing that. Therefore, the !-modifier is introduced. It allows you to specifically get rid of the warning:

public void DoSomething(string? text) 
{ 
    if(!string.IsNullOrEmpty(text)) 
        Console.WriteLine(text!.Length);
}

By adding the !-operator when dereferencing the string, we tell the compiler “trust me, I know what I’m doing!”. The same can be applied when assigning a nullable reference to a non-nullable reference:

string? text = "some text"; 
string someText = text; // Warning! 
string otherText = text!; // OK, I trust you

C# 8: Asynchronous Streams

What?

The ability to use async/await inside an iterator.

Why?

When you implement an iterator, currently you are limited to doing it synchronously. There are cases where you might need to await a call on every iteration to fetch the next item.

How?

To support this feature, a couple of things need to be implemented:

• New types: the async equivalents of IEnumerable and IEnumerator
• Methods with a yield return don’t currently support async/await.
• The ability to specify an await on an iterator construct such as foreach

The new types that will be introduced are IAsyncEnumerable and IAsyncEnumerator. IAsyncEnumerable will just have a single method that returns an IAsyncEnumerator. The interesting interface is IAsyncEnumerator which is defined as follows:

public interface IAsyncEnumerator<out T> : IAsyncDisposable 
{ 
    Task<bool> MoveNextAsync(); T Current { get; } 
}

This allows you to build an iterator that can await each call to the MoveNextAsync method.

The second thing that will be added is the support for async/await in methods that yield results:

static async IAsyncEnumerable<int> GetNumbers()
{ 
    for (int i = 0; i < 100; i++) 
    { 
        await Task.Delay(1000); 
        yield return i; 
    } 
}

Some notable things:

• We have an async keyword, but the return type is not a Task<>. This is the support that will be built-in and specifically enabled when you return an IAsyncEnumerable
• We can await any calls inside the method

The last bit that will be added is the consumption side. When we iterate over an IAsyncEnumerable we need to make sure that the calling method also awaits the call, so from the caller we also await the call:

foreach await (var number in GetNumbers()) 
{ 
    Console.WriteLine(number); 
}

C# 8: Default interface implementations

What?

The ability to provide an implementation on an interface method. This makes it optional for implementers to override the method or not.

Why?

It allows for (a limited type of) multiple inheritance in C#

How?

Very similar to abstract classes you will be able to express method bodies inside an interface declaration:

interface ILogger 
{ 
    void Write(string text) 
    { 
        Console.WriteLine(text); 
    } 
}

This then allows you to implement the interface without implementing the Write-method explicitly:

class Logger : ILogger { } 
ILogger l = new Logger(); 
l.Write("text");

Note, however that the class does not inherit the method of the interface and the following will still give you a compilation error:

Logger l = new Logger(); 
l.Write("text"); // Error: Logger does not contain a method "Write"

This is also the reason why we can't really call it multiple inheritance. Consider the following implementation:

interface IA 
{ 
    void Write(string text) 
    { 
        Console.WriteLine(text);
    }
}
interface IB 
{ 
    void Something() 
    { 
        // ... 
    }
}
class C : IA, IB {}

The following won't work, because you need to dereference it through the interface in order to use the default implementations:

var obj = new C();
obj.Write("test");  // Error
obj.Something();    // Error

To circumvent this issue, we need to dereference the methods through the interfaces:

(obj as IA).Write("OK"); // OK
(obj as IB).Something(); // OK

This feature has quite a few edge cases, which you can read about in the proposal here: Default interface methods proposal
Note also that for this feature, it will be necessary to modify the runtime, which is one of the reasons why it is unsure as whether this feature will make it into C# 8 or potentially a future version.

C# 8: Extension everything

What?

The ability to create extension properties, fields and operators.

Why?

When extension methods were introduced in C# 3 it was a supporting feature to enable LINQ. Once published it became clear that there’s a lot of value in it outside of LINQ. The ability to create extension properties, fields and operators would greatly increase this value.

How?

Currently extension methods are declared as static method which accept a special first parameter: the instance which the method is extending. In essence, it’s syntactical sugar over calling a static method where you pass in the instance as the first parameter. With extension everything, this syntax will change. There are a few competing design proposals and it’s unclear which will be the ultimate design, but for illustration’s sake I will use one of them. It’s highly likely this will change though:

public extension class ListExtensions<T> : List<T> 
{ 
    // instance extensions
    private int _sum = 0; 
    public int GetSum() => _sum; 
    public int Sum => _sum; 
    public List<T> this[int[] indices] => ...; 
    
    // static extensions
    static Random _rnd = new Random();
    public static List<T> GetRandomLengthList() =>
        new T[_rnd.Next].ToList();
    
    public static implicit operator int(List<T> self) => self.GetSum(); 
    public static implicit List<T> operator +(List<T> left, List<T> right) => 
        left.Concat(right); 
}

Conclusion

All in all, I think the planned additions will be a significant improvement in making C# more robust and terse. None of the above is set in stone, but it’s very likely these features will appear in C# 8 and if not they will surely come to the next version of C#. All of the discussion are these new features are open and available on GitHub. I encourage you to have a look at them and have a play with it once they are ready for trial.

I came across a tweet today about refactoring badly written code. I’m always interested in that, so I saw a few fellow devs had taken some badly written code and then applied refactoring to it, following good software design principles.

It all started with this article on CodeProject from April last year: https://www.codeproject.com/articles/1083348/csharp-bad-practices-learn-how-to-make-a-good-code

The author shows a piece of badly written and then goes through a slew of refactorings following Liskov, strategy patterms, dependency injection and many other well-known principles.

While I’m a big fan of good software practices, the number 1 principle I like to adhere to is KISS: (Keep it simple, stupid). If you have been reading my blog before, you’ll certainly have come across the theme. I’m not the only though, there were a few follow up posts as well:

• Don’t let cleaning go overboard (by Ralf Westpahl)
• An F# rewrite (by Roman Bassart)
• Using C# 7 and Succin to give F# a run for its money (by David Arno)

I like many of the ideas expressed in the above posts, but I couldn’t stop to think about how this code could be made much simpler. Looking at the posts I still see things that are complicating matters much more than necessary.

Code before refactoring

For reference, this is the initial code from the first post:

public class Class1 
{ 
    public decimal Calculate(decimal amount, int type, int years) 
    { 
        decimal result = 0; 
        decimal disc = (years > 5) ? (decimal)5/100 : (decimal)years/100; 
        if (type == 1) 
        { 
            result = amount; 
        } 
        else if (type == 2) 
        { 
            result = (amount - (0.1m * amount)) - disc * (amount - (0.1m * amount));         } 
        else if (type == 3) 
        { 
            result = (0.7m * amount) - disc * (0.7m * amount); 
        } 
        else if (type == 4) 
        { 
            result = (amount - (0.5m * amount)) - disc * (amount - (0.5m * amount));         } 
        return result; 
    } 
}

This is indeed not very nice code. What I do like about it though, is that it’s compact. When I read this, I can probably figure out relatively quickly what this code does. It has many problems though (as discussed in the original post).

The “issue” I have with the refactorings in the other posts is that they try to cater for use cases that simply aren’t specified. From what I can tell, these are the requirements:

• Give a discount based on what type of customer it is
• Give a loyalty discount which equals the amount of years the customer has been active, with a maximum of 5
• Both discounts are cumulable

The simplest possible solution

UPDATE: after comments on twitter / reddit, I noticed that the tests were incorrect. I had taken them from one of the refactorings and assumed they were correct. I have modified the data and updated the tests to reflect what the original code does.

UPDATE 2: I went against my own adage: going to far. Smuggling the discount info into the enum was too much. I have refactored it to a dictionary, which is easier to maintain.

static readonly Dictionary<Status, int> Discounts = new Dictionary<Status, int> 
{ 
    {Status.NotRegistered, 0 }, 
    {Status.SimpleCustomer, 10 }, 
    {Status.ValuableCustomer, 30 }, 
    {Status.MostValuableCustomer, 50 } 
}; 
decimal applyDiscount(decimal price, Status accountStatus, int timeOfHavingAccountInYears) 
{ 
    price = price - Discounts[accountStatus] * price/100; 
    return price - Math.Min(timeOfHavingAccountInYears, 5) * price/100; 
}

It’s a simple calculation, so why not express is at as a simple calculation? While I see the power of functional programming, sometimes discriminated unions, partial application and the likes are just overkill for simple problems.

For a coding kata like this, I understand that people want to provide a most elegant solution for future needs, but unfortunately I see these patterns arise far too often, complicating already complex problems even more.

Bonus 1: Tests

[Fact] public void Tests() 
{ 
    applyDiscount(100m, Status.MostValuableCustomer, 1).Should().Be(49.5000m);
    applyDiscount(100m, Status.ValuableCustomer, 6).Should().Be(66.5000m);
    applyDiscount(100m, Status.SimpleCustomer, 1).Should().Be(89.1000m); 
    applyDiscount(100m, Status.NotRegistered, 0).Should().Be(100.0m); 
}

Bonus 2:

Want a UI with that? Here you go! 🙂

Most developers love open source software, and often we come across a piece of software that we’re writing and think “it would be great if that already existed as an open source package”, but then, it doesn’t. Since we’re writing software for a company, the natural tendency is then to implement it in-house. The thing is, if you had that thought, chances are someone else might have had the same thought. So, why shouldn’t we open source it? From a business perspective, telling your boss you want to write open source software on company might not make much sense to him. After all, he’s paying you to write software for everyone. If you argument is going to be “open source is cool”, you probably won’t get very far.

Apart from being cool, developing open source software as a company actually has a lot of benefits.

Before I iterate over what I think the advantages are, I want to make one thing clear. When we write open source software on company time, we don’t want to open source the company’s unique selling point. It’d be foolish to think any company would allow that. When I talk about open sourcing company software, I’m talking about general purpose software. Software you need to develop to support your domain. This could be an interface to a database, some utility functions you often use or any other piece that could be usable outside of the context of your company.

Open source software advantages

Quality

Open source software is, by its nature, public. That means that any hack you implement, any security mistakes will be visible for everybody. Therefor, when you’re working on something public, it’s natural to be a lot more cautious about how you develop. But that’s only one way open source improves  quality.

Another reason quality improves is that it forces you to decouple it from your domain. In in-house software it often becomes tempting to include domain logic inside external libraries, because it’s just easier, faster. In the long run, you will have less separation of concerns which affects maintainability. Writing general purpose open source software, forces you to decouple it.

Testing

If your project is popular, a community will form around it. Once you have a community, they will start using it and possibly discover bugs before you run into them. If you have an active community they might even create a pull request to solve the bug for you. That’s free testing and bug fixing for the company.

New features / scenarios

Similar to the scenario with bug detection and public testing, it’s possible someone runs into a use case that the current software doesn’t handle. If they really need it, they might decide to implement it and create a pull request.

Exposure

If your software is of a high quality, it will start becoming popular. Being open source doesn’t mean it needs to be white-labeled. So, every time someone gets in contact with the software, your company’s logo will be there. This gives exposure of your company’s name to a potential large audience of developers.

There are plenty of examples of tech companies that are open sourcing software, to name a few:

• Uber: https://uber.github.io/
• Spotify: https://github.com/spotify
• Google: Android
• AirBnb: http://nerds.airbnb.com/open-source/
• Facebook: React

If you go through the list, you’ll see they’re not open sourcing their main selling point, but parts that orthogonal to their business model (ie: you won’t see Google open sourcing their search algorithm, or Facebook’s timeline rules). The above is also a list of companies that are *hot *among developers. A lot of developers want to work in these companies, precisely because of their openness. Having exposure of your company to developers could attract new talent. That’s not to say that this is the ultimate hiring strategy, but it’s another channel which could yield some interesting results.

Developer satisfaction

Good developers are, in my opinion, passionate about their work. They will feel happier if they can work on something that solves more than the daily problems they’re running into. Having a happier development team aids in productivity, retaining talent and general atmosphere in the company. Working on something which is open source and not “just” for the company might also trigger them to spend some hobby time on it which again is free work for the company.

Developer involvement

Sometimes developers move on from the company. One of the first things you do, is remove their access to the code repository. Even if they feel they did something useful and want to continue using it, they’ll have to work on it privately on a copy they have. Technically they’re not allowed to, but that’s not the reality.

On the other hand, if the code is open source, and they move on, they can still contribute to it. Likely they will use it in the next company they’re at. This will minimize the loss of knowledge in the team and again get more development time on the software for free. This is something that I experienced first hand when moving on from a company. The software we had written was by no means popular, but I found it to be useful, so I introduced it at my new company. Now we’re happily contributing to it when we need it.

It’s a win-win-win. It’s good for my new company, because they get software that was already developed, it’s good for my old company, because I (and my colleagues) are adding new features and bug fixes for their software and it’s good for me, because I didn’t have to do it all over again.

Conclusion

A lot of the above advantages are only real if your software becomes popular. But what do you have to lose? If it doesn’t become popular it’s just the same as developing it in-house which was the starting point.

Another argument, although not very tangible, is that it’s just the right thing to do. We live in a world where we can only achieve what we’re achieving by standing on the shoulders of others. I’m sure 99,99% of closed source software is using open source software somewhere, so why not be a good citizen and contribute back to the community?

Creating development silos, is a practice I have seen in many different teams. What I’m talking about is having developers specialize in parts of the domain, i.e. one developer handles all the code related to invoicing, another one does everything around order management, etc. It’s a natural tendency to select the same programmer for the same part of the application all the time. The reason is that it creates immediate and tangible results. Assigning the developer that has most knowledge of the code at hand, is the one that will complete the task as fast and as good as possible.

However, in the long term, I believe there’s more benefit in doing the exact opposite. Although counter intuitive, I think spreading the knowledge of the domain throughout the development team has a lot of advantages.

Knowledge sharing

If you assign a task only to a developer that has worked on a feature before, you concentrate the knowledge of that part of the domain in that developer. While having a lot of knowledge is good for a single developer, it’s not good for the team. Having the knowledge spread out over the team unlocks a bunch of advantages:

Consistency

Initially, a developer with more knowledge of the code will complete a task faster. That is a logical fact. The same is true for the opposite: if you give the task to a developer with no knowledge of the code at all, it will take him considerably more time and effort to complete it. In an ideal world, a team is always the same size and no one ever leaves, takes holidays or is off sick. In reality however, teams change, have other responsibilities and are in general not constant.

By having knowledge concentrated on a developer/feature basis, you will see a lot of highs and lows in the productivity of the team. The highs occur on moments that the team is in a stable period with no one leaving the company, no sick days and/or holidays. The lows happen when someone leaves. All of a sudden a lot of knowledge has left the company and someone needs to pick that up. The same happens when someone goes on holiday. In a way, a holiday is even worse, because the rest of the team will just sit and wait to start “that feature that touches invoicing” until John, who knows all about invoicing, is back from holiday.

If you spread the knowledge however, you will eventually get to a point where development speed is consistent. Holidays are spread over the year and the team just picks up any work that’s available. The same happens when someone leaves the company. What’s more is that a new developer can be trained by anyone, not just by that one other guy who also has the knowledge required (provided there IS actually another one around).

Responsibility

If you know that no one will look at the code you’re writing (at least not until you’re gone), there’s a natural tendency to get sloppy. Conversely, knowing that this code will be viewed tomorrow by your colleague tends to put you on edge. This is not just because developers are sloppy or because of a bad developer. To some extent, every developer is prone to this, regardless of how good or professional they are. It’s simple human nature.

Communication

Having shared knowledge moves code ownership from the individual to the team. With everyone at the same wavelength, it will improve communication within the team, and mistakes will get picked up by the team, not by individuals. Individuals can have good days and bad days. A team usually zeroes that out.

Code Reviews

If you’re doing code reviews (and you should: https://www.kenneth-truyers.net/2016/04/08/code-reviews-why-and-how/), rotating the team will also improve their quality. If you review code of which you have never seen the context, it’s a lot harder to assess the quality. Either it takes a lot of time to review, because you have to read and analyze all the surrounding bits, or, more likely, developers tend to think, “looks decent enough, I suppose that’s handled somewhere else”.

If you know the context, it’s much easier to spot bugs, suggest alternate patterns and provide valuable feedback. Without knowing context, code reviews are often reduced to formatting checks, something that’s better left to automation.

Code Quality

By having a broad knowledge of the entire domain, chosen solutions tend to fit better into the whole. It’s easy to provide a narrow solution for the problem at hand, but it’s very difficult to provide a generic solution that will be scalable in light of where the business is heading. By sharing the knowledge, you prevent tunnel vision.

Developer Satisfaction

Development is a creative activity. Nothing kills creativity more than repetition and boredom. By working on the same part over and over again, developers get bored, leave for other, more exciting places or simply go into standby mode, doing what they need to do and nothing more. By having people work on different parts, they will feel more as part of an organization, an idea and can see the goals. That creates a motivating environment and will make them want to do the best possible job.

Planning

Related to the point on consistency, planning workload also becomes a lot easier. You no longer have to check each developer’s schedule and you don’t have to cut out requested holidays (which also helps for developer satisfaction). Because there are multiple developers who can do a job, you can just assign the task to any developer that’s available.

Terms and conditions

Rotating the team around features has a lot of advantages, as explained above. Obviously, don’t take this advice to the extreme. Don’t let your DBA design your front page, don’t let your UX specialist optimize DB queries and, for the love of god, don’t let your PR spokesmen implement your log in page.
Developers all have their specialties, that’s OK, but they should be technical specialties. What you want to avoid is that developers become specialists in a thin slice of the domain.

Another thing to keep in mind is the team size. I’ve found the above guidelines to be useful in small teams. Once your team grows beyond 7-8 developers, I prefer to take the other extreme: separate the teams. The boundaries between the knowledge should be more clearly defined and any team should consider code by a different team as if it were third-party code. This allows teams to be very focused. It also means that external interfaces should be very clear, well documented and above all, stable.

Conclusion

Sometimes doing the non-intuitive thing, is more beneficial than doing what seems natural. Rotating a team around features increases consistency, code quality, responsibility and developer’s satisfaction. While going for short term wins might be tempting, the long term benefits are clear.

I make no secret of the fact that I don’t like ORM’s. One part of why I don’t like them is the way they handle database migrations. To successfully create and execute database migrations, you often need to know quite a bit about the framework. I don’t like having to know things which can be solved in a much simpler way.
Apart from ORM migrations, there are tools out there such as Redgate’s database tools. While this is actually a very good and useful tool, it’s often overkill for small to medium-sized applications. Apart from that, it’s also quite expensive, so maybe not the best tool to use in your start-up.

KISS

Database migrations, contrary to popular belief, are not rocket science. Essentially, you want to execute some scripts whenever you release a new version of your software and possibly execute some scripts to undo those in case you want to rollback a faulty deployment. Building such a thing is not very difficult. It won’t have all the bells and whistles that a tool such as Redgate has, but the knowledge required is far less and, more importantly, instantly understandable for any new hires on a team. If all you need is upgrade and downgrade, you can use the code from this article with your modifications and tweaks. It’s based on some simple conventions without any possibilities for configuration or customization, but again, YAGNI (you aren’t gonna need it). If you end up needing it, then you can just modify the script and get on with more interesting stuff.

The code is very simple in its setup and it works like this:

• A table MigrationScripts is created in the database which contains all scripts that have been executed and at what date
• On startup of the application (or whichever moment you choose), it scans a folder for .sql scripts with the naming convention YYYYMMDD-HHMM-<some_name>.sql
• The code then does a diff to see which scripts have already been executed in the database
• It then runs the scripts that haven’t been executed yet, in the order of the date parsed from the naming convention

Database migrations: upgrading

The example that I’ll be showing here is something I used previously on an ASP.NET MVC app, which was the only client accessing the database. In case you have multiple applications accessing the same database, you probably want to extract this code into a separate application so you can deploy that application whenever a database update is needed. I’ll show the simple version though.

NOTE: I’m using Dapper in this example, as we where using it in said project, but this could easily be done with any other micro-ORM or ADO.NET directly.

public static void Run() 
{ 
    string conString = ConfigurationManager.ConnectionStrings["sql_migrations"] 
                                           .ConnectionString; 
    using (var con = new SqlConnection(conString)) 
    { 
        // check if the migrations table exists, otherwise execute the first script (which creates that table) 
        if (con.ExecuteScalar<int>(@"SELECT count(1) FROM sys.tables 
                                            WHERE T.Name = 'migrationscripts'") == 0) 
        { 
            con.Execute(GetSql("20151204-1030-Init")); 
            con.Execute(@"INSERT INTO MigrationScripts (Name, ExecutionDate) 
                                 VALUES (@Name, GETDATE())", 
                                 new { Name = "20151204-1030-Init" }); 
         } 
                                 
        // Get all scripts that have been executed from the database 
        var executedScripts = con.Query<string>("SELECT Name FROM MigrationScripts"); 
        // Get all scripts from the filesystem 
        Directory.GetFiles(HostingEnvironment.MapPath("/App_Data/Scripts/")) 
                // strip out the extensions 
                .Select(Path.GetFileNameWithoutExtension) 
                // filter the ones that have already been executed 
                .Where(fileName => !executedScripts.Contains(fileName)) 
                // Order by the date in the filename 
                .OrderBy(fileName => DateTime.ParseExact(fileName.Substring(0, 13), "yyyyMMdd-HHmm", null)) 
                .ForEach(script => 
                { 
                    // Execute each one of the scripts 
                    con.Execute(GetSql(script)); 
                    // record that it was executed in the migrationscripts table 
                    con.Execute(@"INSERT INTO MigrationScripts (Name, ExecutionDate) 
                                         VALUES (@Name, GETDATE())", 
                                         new { Name = script }); 
                 }); 
             } 
         } 
         
         static string GetSql(string fileName) => 
             File.ReadAllText(HostingEnvironment.MapPath($"/App_Data/Scripts/{fileName}.sql"));

That’s it, about 20 lines of code (comments and line breaks don’t count ;-)) for a fully working database migration infrastructure.

Database migrations: downgrading

In cases where you want to be able to roll back the database, you could add another convention: all rollback scripts have the same name but with _rollback appended to the filename. Then you can add a separate function which takes as an argument the name of the script you want to roll back. From there on, it’s a case of loading the correct rollback scripts, sorting them, executing them and removing the records from the MigrationScripts table. All in all, another 20 lines.

Conclusion

The above code allows you to:

• Store all your database changes in Git
• Do code reviews on SQL scripts (by anyone, including DB Admins)
• Pull the repo with a fresh database, run the application and get started (handy for new hires)
• Test the migrations locally and in every test environment
• Do data migrations (or any SQL you want to write for your migrations)
• Be flexible: you own the code, so anything is possible (convention change, extract it, deploy it separately, etc. )

It does have a little cost of ownership, as you may need to modify it sometimes. I’d argue however that the cost is smaller than having to know about your ORM’s migration intricacies or learn how to use a database management tool.

Also, this code is fully certified “Works on my machine”-ware. You can use it, tweak it, ask me a question about it, but don’t ask me to create a NuGet package of it, as it would go right back to the place I wanted to avoid with this code snippet.

In statically compiled languages, we usually lean on the compiler to catch out common errors (or plain stupidities). In dynamic languages we don’t have this luxury. While you could argue over whether this is a good or a bad thing, it’s certainly true that a good static analysis tool can help you quite a bit in detecting mistakes. For Javascript, a few tools are available: there’s the good old JsLint, which is very strict, JsHint, created because not all of us are Douglas Crockford and then there’s EsLint. In this post I’ll show you how to create custom EsLint rules.

EsLint is quite a nice alternative for JsHint and is very flexible. While JsHint certainly has its benefits and comes out of the box with a lot of configurable options, EsLint allows you to configure your own custom rules.

These custom EsLint rules can be added to their library and released to the community as optional extra checks, they can be company specific to enforce a certain coding style or they can be project specific.

In this post I want to talk about creating project specific custom EsLint rules. It’s easily transferrable to a more common use plugin if you want to (by publishing to NPM). I found creating a project specific plugin has a few more hurdles, so I’ll explain that.

Analyzing code

Asbtract Syntax Trees

Before we start writing custom EsLint rules, I first want to show how code is analyzed and how we can plug in to that. In order to analyze code we must first build an abstract syntax tree. In this case we want to build an ES 6 abstract syntax tree (AST). An AST is essentially a data structure which describes the code. The next example shows some sample code and the corresponding syntax tree:

var a = 1 + 1;

The above visualization can also be presented as a pure data structure, here in the form of JSON:

{ 
    type: "VariableDeclaration", 
    declarations: [
        { 
            type: "VariableDeclarator", 
            id: { 
                type: "Identifier", 
                name: "a" 
            }, 
            init: { 
                type: "BinaryExpression", 
                left: { 
                    type: "Literal", 
                    value: 1, 
                    raw: "1" 
                }, 
                operator: "+", 
                right: { 
                    type: "Literal", 
                    value: 1, 
                    raw: "1" 
                } 
            }
        }
    ]
    , kind: "var" 
}

When we have this syntax tree, you could walk the structure and then write something like this for each node:

if(node.type === "VariableDeclarator" && node.id.name.length < 2) {
    console.log("Variable names should be more than 1 character"); 
}

Writing custom EsLint rules

Since all of this AST-generation and node-walking is not specific to any rule, it can be externalized, and that’s exactly what EsLint gives us. EsLint builds the syntax tree and walks all the nodes for us. We can then define interception points for the nodes we want to intercept. Apart from that, EsLint also gives us the infrastructure to report on problems that are found. Here’s the above example rewritten as an EsLint rule:

module.exports.rules = { 
    "var-length": context => 
        ({ VariableDeclarator: (node) => 
            { 
                if(node.id.name.length < 2){ 
                    context.report(node, 'Variable names should be longer than 1 character'); 
                } 
            } 
        }) 
    };

This can then be plugged in to EsLint and it will report the errors for any Javascript code you throw at it.

EsLint plugins

In order to write a custom EsLint rule, you need to create an EsLint plugin. An EsLint plugin must follow a set of conventions before it can be loaded by EsLint:

• It must be a node package (distributed through NPM, although there’s a way around it, read on …)
• Its name must start with eslint-plugin

The documentation mentions a way to write custom rules in a local directory and running them through a command-line option. This still works, but is deprecated and will soon break in newer versions of EsLint. It’s recommended to go the plugin-route as described in this post.

Creating the plugin

With the above requirements, we can go two routes:

• Use YeoMan and the corresponding EsLint generator
• Create your own package

The generator sets you up with a nice folder structure, including tests, a proper description and some documentation. However, if you just want to write some quick rules, I find it easier to just create a folder and the structure myself. Essentially, you need two files:

• package.json (remember, it has to be an NPM package)
• index.js, where your rules will live

Here’s a basic version of the package.json:

{
	"name": "eslint-plugin-my-eslist-plugin",//remember, the name has to start with eslint-plugin
        "version": "0.0.1",
	"main": "index.js",
	"devDependencies": {
            "eslint": "~2.6.0"
	},
	"engines": {
		"node": ">=0.10.0"
	}
}

And this is what index.js looks like, with our custom EsLint rule:

module.exports.rules = { 
    "var-length": context => 
        ({ VariableDeclarator: (node) => 
            { 
                if(node.id.name.length < 2){ 
                    context.report(node, 'Variable names should be longer than 1 character');
            }
        } 
        // , more interception points (see https://github.com/estree/estree) }) 
    // more rules };

Installing the plugin

As I mentioned before, if you want to share your plugin, you can distribute it via NPM. This doesn’t always make sense though as you might have project specific rules. In those cases, you can just create the folder with your plugin locally and commit it to your code repository. For it to work, you still need to install it as a node package though. You can do that with the following NPM command:

npm install -S ./my-eslint-plugin

This will install the package from the local folder my-eslint-plugin. That way, you can keep the rules locally to your project and still use them while running EsLint.

Configuring the plugin

For EsLint to recognize and use the plugin we have to notify it through the configuration. We need to do two things:

• Tell it to use the plugin
• Switch on the rules

To tell it to use plugin, we can add a plugins node into the configuration, specifying the name of the plugin (without the “eslint-plugin”-prefix):

"plugins": [ "my-eslint-plugin" ]

Next we need to define the rules:

"rules": { "my-eslint-plugin/var-length": "warn" }

With the plugin installed, you can now run EsLint and it will report on one letter variable names.

Example

While this is all nice, the above rule is probably not very useful, since there’s already a built-in rule for that (http://eslint.org/docs/rules/id-length).

As for general styling rules, EsLint has probably most of them already covered, and the ones it hasn’t are probably quite obscure. Custom EsLint rules come in handy on a project-level basis.

As an example, I’m currently working on an Angular 1 project. The intention is to port this over to a different framework soon. Because of that, we want to make sure we’re as independent of Angular as possible. There are certain things we can do just as easily in plain JS instead of using angular’s utility methods. For others, we can use different libraries that we can port over as well when we port the application.

Now, we don’t want to go off and change all these occurrences at once, because that would be a lot of upfront work. Ideally, we want the following:

• Get notified when there’s a call to an angular-method which could be done easily in plain JS in the module we’re working on
• Get notified on the CI-server (with a warning) if an angular-method is used
• Once we get rid of the warnings for that angular-method, fail the build on the CI-server if that call is detected again

So, as an example, here are a few rules we defined in our project:

module.exports.rules = { 
    "no-angular-copy": context => 
        ({ MemberExpression: function(node) { 
            if (node.object.name === "angular" && node.property.name === "copy") {
                context.report(node, "Don't use angular.copy, use cloneDeep from lodash instead."); 
            }
        } 
    }), 
    "no-angular-isDefined": context => 
        ({ MemberExpression: function(node) { 
            if (node.object.name === "angular") { 
                if(node.property.name === "isDefined") { 
                    context.report(node, "Don't use angular.isDefined. Use vanilla JS."); 
                } else if (node.property.name === "isUndefined") { 
                    context.report(node, "Don't use angular.isUndefined. Use vanilla JS"); 
                } 
            } 
        } 
    }) 
};

We then enabled the rules with a warning in our configuration. As soon as we notice no more warnings for one of these rules, we will switch them to errors. The CI-build is configured to fail when EsLint finds an error. On top of that we have the EsLint plugin for VsCode, which looks like this in the editor:

This combination ensures that we clean up angular calls while we continue development and that no new calls will be introduced.

Sidenote: the rules here are not foolproof since someone could assign angular to a temp variable and then call the methods on the temp variable. Be that as it may, we want to catch the general use case with a simple rule. We could probably write a more thorough analyzer, but it would take a lot of time. Since all of this code still needs to go through code reviews, we don’t worry too much about it.

Other possibilities

The above example is something that was very convenient for our use case, but the possibilities are endless. Here are a few things you could achieve with this:

• Ensure a user message is shown when HTTP calls are initiated and that they’re properly removed once it ends.
• Ensure jQuery isn’t used when we’re using a SPA-framework (or only in certain modules)
• When using jQuery, ensure you’re always calling event-handlers using the .on method instead of the shorthand ,click and similar

There are plenty of possibilities for custom EsLint rules and most of it depends on your project. What other ideas do you have?

Existing plugins

Of course, there are plenty of existing EsLint plugins for existing frameworks on NPM already. If you’re using one of these frameworks, it’s worth checking out the rules and see if you could benefit from enabling some of these

More information on writing custom EsLint rules can be found in the offical documentation

Last week I wrote about the yield return statement in c# and how it allows for deferred execution. In that post I explained how it powers LINQ and explained some non-obvious behaviors.

In this week’s post I want to do the same thing but for Javascript. ES6 (ES2015) is becoming more and more mainstream, but in terms of usage I mostly see the more common arrow-functions or block-scoping (with let and const).

However, iterators and generators are also a part of Javascript and I want to go through how we can use them to create deferred execution in Javascript.

Iterators

An iterator is an object that can access one item at a time from a collection while keeping track of its current position. Javascript is a bit ‘simpler’ than c# in this aspect and just requires that you have a method called next to move to the next item to be a valid iterator.

The following is an example of function that creates an iterator from an array:

let makeIterator = function(arr){ 
    let currentIndex = 0; 
    return { 
        next(){ 
            return currentIndex < arr.length 
                ? { value: arr[currentIndex++], done : false } 
                : { done: true}; 
        } 
    }; 
}

We could now use this function to create an iterator and iterate over it:

let iterator = makeIterator([1,2,3,4,5]); 
while(1){ 
    let {value, done} = iterator.next(); 
    if(done) break; 
    console.log(value); 
}

Iterables

An iterable is an object that defines its iteration behavior. The for..of loop can loop over any iterable. Built-in Javascript objects such as Array and Map are iterables and can thus be looped over by the for..of construct. But we can also create our own iterables. To do that we must define a method on the object called @@iterator or, more conveniently, use the Symbol.iterator as the method name:

let iterableUser = { 
    name: 'kenneth', 
    lastName: 'truyers', 
    [Symbol.iterator]: function*(){ 
        yield this.name; 
        yield this.lastName; 
    } 
} 
// logs 'kenneth' and 'truyers' 
for(let item of iterableUser){ 
    console.log(item); 
}

Generators

Custom iterators and iterables are useful, but are complicated to build, since you need to take care of the internal state. A generator is a special function that allows you to write an algorithm that maintains its own state. They are factories for iterators. A generator function is a function marked with the * and has at least one yield-statement in it.

The following generator loops endlessly and spits out numbers:

function* generateNumbers(){ let index = 0; while(true) yield index++; }

A normal function would run endlessly (or until the memory is full), but similar to what I discussed in the post on yield return in C#, the yield-statement gives control back to the caller, so we can break out of the sequence earlier.

Here’s how we could use the above function:

let sequence = generateNumbers(); //no execution here, just getting a generator for(let i=0;i<5;i++){ 
    console.log(sequence.next()); 
}

Deferred Execution

Since we have the same possibilities for yielding return values in Javascript as in C#, the only what’s missing to be able to recreate LINQ in Javascript are extension methods. Javascript doesn’t have extension methods, but we can do something similar.

What we’d like to do is to be able to write something like this:

generateNumbers().skip(3)
                 .take(5)
                 .select(n => n * 3);

It turns out, we can do this, although we need to take a few hurdles.

To attach methods to existing objects (similar to what extension methods do in c#), we can use the prototype in Javascript. Generators however all have a different prototype, so we can’t easily attach new methods to all generators. Therefore, what we need to do is make sure that they all share the same prototype. To do that, we can create a shared prototype and a helper function that assigns the shared prototype to the function:

function* Chainable() {
} 
function createChainable(f){ 
    f.prototype = Chainable.prototype; 
    return f; 
}

Now that we have a shared prototype, we can add methods to this prototype. I’m also going to create a helper method for this:

function createFunction(f) { 
    createChainable(f); 
    Chainable.prototype[f.name] = function(...args) { 
        return f.call(this, ...args); }; 
        return f; 
    }
}

In the above method:

- It makes sure the function itself is also chainable, by calling createChainable
- Then it attaches the method to the shared protoype (using the name of the function). The method receives the arguments, which gets passed on to that method while supplying the correct this-context.

With this in place we can now create our “extension methods” in Javascript:
```javascript
// the base generator 
let test = createChainable(function*(){ 
    yield 1; 
    yield 2; 
    yield 3; 
    yield 4; 
    yield 5; 
}); 
// an 'extension' method 
createFunction(function* take(count){ 
    for(let i=0;i<count;i++){ 
        yield this.next().value; 
    } 
}); 
// an 'extension' method 
createFunction(function* select(selector){ 
    for(let item of this){ 
        yield selector(item); 
    } 
}); 

// now we can iterate over this and this will log 2,4,6) 
for(let item of test.take(3).select(n => n*2)){ 
    console.log(item); 
}

Note that in the above method, it doesn’t matter whether we first <font face="Courier New">take</font> and then <font face="Courier New">select</font> or the other way around. Because of the deferred execution, it will only fetch 3 values and do only 3 selects.

### Caveat

One problem with the above is that it doesn’t work on standard iterables such as Arrays, Sets and Maps because they don’t share the prototype. The workaround is to write a wrapper-method that wraps the iterable with a method that does use the shared prototype:
```javascript
let wrap = createChainable(function*(iterable){ 
    for(let item of iterable){ 
        yield item; 
    } 
});

With the wrap function, we can now wrap any array, set or map and chain our previous function to it:
```javascript
let myMap = new Map(); 
myMap.set("1", "test"); 
myMap.set("2", "test2"); 
myMap.set("3", "test3"); 
for(let item of wrap(myMap).select(([key,value]) => key + "--" + value)
                           .take(3)){ 
   console.log(item); 
}

One more thing I want to add is the ability to execute a chain, so that it returns an array (for c# devs: the ToList-method). This method can be added on to the prototype:
```javascript
Chainable.prototype.toArray = function(){ 
    let arr = []; 
    for(let item of this){ 
        arr.push(item); 
    } 
    return arr; 
}

Conclusion

If we implement the above, it allows us to write LINQ-style Javascript:

mySet.set("1", "test"); 
mySet.set("2", "test2"); 
mySet.set("3", "test3"); 
wrap(mySet).select(([key,value]) => key + "--" + value)
           .take(3)
           .toArray()
           .forEach(item => console.log(item));

Obviously, this only works in ES2015 and it’s probably not a good idea to actually write LINQ in Javascript using this method (and besides, there are already other implementations of LinqJS), but it does demonstrate the power of Iterators and Generators in Javascript.

Last week I attended my first Open MVP day since I got the Microsoft MVP award. It was a great experience and I wanted to share what I learned and shout out to the great professionals I met there.

For me, it’s an honor to be part of this community. Not only does it feel good to be recognized for the work I’ve been doing but it’s an even greater opportunity to learn from people and build a professional network. The Open MVP day is exactly about that.

It was a busy week, as I just started a new contract, flew out to London and then had to rush to Rome to attend the Open MVP day. Lots of travel, lots of attention required and all in a short time span. While I was happy to be able to do all of that, I can’t say I wasn’t relieved to be back at home as well.

People I’ve met

Apart from the technical information I got, the most important part for me was to get to know as many people as possible and build a network of peers. It’d be great to continue some of the conversations I’ve had with people there and build a relationship with mutual benefits. On the night I arrived I quickly caught up with the Spanish delegation (mostly with Dachi Gogotchuri, Sergio Guerra and Asier Villanueva) and we had a good chat over a beer about what we like (and don’t like) about the technologies we work in. It was particularly interesting to see what grievances are shared and which ones are probably just my own problem :-). It was really great to see so many people with the same shared interests and a commitment to keep learning and exploring technology. If you’re like me (a geek), you probably recognize the feeling where you have a lot of ideas and thoughts and no one to share them with (at least not in person).

Apart from fellow MVP’s, we also had the chance to meet some of the technical evangelists from Microsoft. They’re experts in building and maintaining communities. It was very interesting to hear some new ideas from Alejandro Campos on how to build a community and wake interest in technology. I can’t wait to start and put these ideas in action to foster the local community and build a network of like-minded people here in Mallorca.

Things I’ve learned

Apart from networking, there are obviously technical sessions. While I found that most sessions where rather introductory sessions, I do want the highlight the session by Ricardo Peres on ElasticSearch. While also an introductory session, this one was particularly interesting as I just started a project with heavy usage of ElasticSearch. I definitely learnt a lot in that session and hope to soon start to apply that knowledge in real life.

The warning signs

If there’s one thing I was a bit weary about, I’d say it’s the effect of the echo chamber. This has nothing to do with the organizers or the sessions, but with the very nature of a vendor specific event. Since all attendees are Microsoft MVP’s, the focus naturally lies on Microsoft technology. Even though I’m mostly Microsoft oriented, I like to venture into related technologies to compare, contrast and learn from them. This doesn’t mean I find MS tech worse (or better) than other tech stacks, it just means that, while attending an event that focuses on a particular vendor, it’s important to not get soaked up by it and keep an open mind.

On the other hand, I also like to mention that there a lot of MVP’s that didn’t only specialize in Microsoft tech. As an example, Nicola Iarocci, is a python specialist on the server, but works with MS tech on the client side. His perspective was particularly interesting as it shows that it isn’t necessary to be only “devoted” to MS tech to become an MVP. It shows that the movement towards openness from Microsoft is not just hollow words.

Conclusion

All in all, I’d say that my first Open MVP day was a great success and I can’t wait to attend my first MVP summit later this year. As I’ve been told, it’s a fantastic opportunity to meet peers from all over the world as well as get an insight on “how the sausage is made” at Microsoft.

I want to thank the organizers and everybody I’ve met for making this a great first experience and hope to see everyone at the next gathering.

A few years ago I wrote a post about Javascript namespaces and modules. In that post I discussed a pattern for isolating your code from outside code. I also promised to write up another pattern, the javascript sandbox pattern. I never did though. Lately I received a few emails about this and decided to write it up eventually. While 3 years have past since then, and a lot has happened in the Javascript world, I still think this is a valuable pattern, if only for historical purposes. If you’re using ES6, there are probably better alternatives, but it still is a good way to understand the semantics of Javascript.

The namespace pattern described in my other post has a few drawbacks:

• It relies on a single global variable to be the application’s global. That means there’s no way to use two versions of the same application or library. Since they both need the same global name, they would overwrite each other.
• The syntax can become a bit heavy if you have deeply nested namespaces (eg: myapplication.services.data.dataservice)

In this post I want to show a different pattern: a javascript sandbox. This pattern provides an environment for modules to interact without affecting any outside code.

Sandbox constructor

In the namespace pattern, there was one global object. In the javascript sandbox this single global is a constructor. The idea is that you create objects using this constructor to which you pass the code that lives in the isolated sandbox:

new Sandbox(function(box){ 
    // your code here 
});

The object box, which is supplied to the function will have all the external functionality you need.

Adding Modules

In the above snippet, we saw that the sandboxed code receives an object box. This object will provide the dependencies we need. Let’s see how this works. The Sandbox constructor is also an object, so we can add static properties to it. In the sample below we’re adding a static object modules. This object contains key-value pairs where the key indicates the module name and the value is a function which returns the module.

Sandbox.modules = { 
    dom: function(){ 
        return { 
            getElement: function(){}, 
            getStyle: function(){} 
        }; 
    }, 
    ajax: function(){ 
        return { 
            post = function(){}, 
            get = function(){} 
        }; 
    } 
};

With this in place, let’s now look at how we pass the modules to the sandboxed code. For that, we’ll have a look at a first version of the Sandbox constructor:

function Sandbox(callback){ 
    var modules = []; 
    for(var i in Sandbox.modules){ 
        modules.push(i);
    } 
    for(var i = i < modules.length;i++){ 
        this[modules[i]] = Sandbox.modules[modules[i]](); 
    } 
    callback(this);
}

First we iterate over all the modules and push the names of all of them into an array. Next, we get each module from the static modules object and assign it to the current instance of the box. Lastly we pass the instance to the sandboxed code. That ensures the box has access to those modules.

Improvements

While the above is a good proof of concept, it requires some modifications to make it more versatile and safer to use.

Enforce constructor usage

First of all, let’s make sure that it’s always called as a constructor and not just with a regular function-call:

function Sandbox(callback){ 
    if(!(this instanceOf Sandbox){ 
        return new Sandbox(callback); 
    } 
}

Allow module specification

Next, we want to be able to define which modules we are going to use so that only those modules will be initialized and passed. We do this by accepting an array of module names and then only adding those modules to the box, instead of iterating over all the modules. That makes our constructor a bit simpler:

function Sandbox(modules, callback){ 
    if(! (this instanceOf Sandbox){ 
        return new Sandbox(modules, callback); 
    } 
    for(var i = i < modules.length;i++){ 
        this[modules[i]] = Sandbox.modules[modules[i]](); 
    } 
    callback(this); 
}

Optional arguments

We want to make the modules argument optional. If it’s not provided, we will use all the modules. We also want to add the ability to pass in the modules one by one as strings, instead of in an array. For that we need to do a bit of argument parsing and again iterate over all the modules:

function Sandbox(){ 
    // transform arguments into an array 
    var args = Array.prototype.slice.call(arguments); // the last argument is the callback 
    var callback = args.pop();   
     // modules is either an array or individual parameters 
     var modules = (args[0] && typeof args[0] === "string" ? args : args[0]; 
     if(!modules){ 
         modules = []; 
         for(var i in Sandbox.modules){ 
             modules.push[i]; 
         } 
     } 
 }

Common instance properties

Since we’re passing in the instance of the box to the sandboxed code, we can add some predefined properties to each instance so that all sandboxed code has access to these:

function Sandbox(){ 
    // ... 
    this.sandboxVersion = "1.0.1"; 
    callback(this); 
}

Arguments destructuring

Currently, the client-code has to access the modules through the box-instance. It would be nicer if we could pass in the modules as separate arguments. This makes the dependencies even more explicit. To do so, instead of calling the callback directly, we can use apply to execute the callback. Also, instead of initializing the modules as properties on the sandbox, we save them in an array:

function Sandbox(){ 
    // ... 
    var moduleInstances = modules.map(function(m){ 
        return Sandbox.modules[m](); 
    }); 
    callback.apply(this, moduleInstances); 
}

The complete Javascript sandbox

When we put everything together, our constructor looks like this:

function Sandbox(){ 
    // parse the arguments 
    var args = Array.prototype.slice.call(arguments), 
        callback = args.pop(), 
        modules = (args[0] && typeof args[0] === "string") ? args : args[0]; 
        
    // add properties for all sandboxes 
    this.applicationVersion = "1.0.2"; 
    // ensure constructor call 
    if (!(this instanceOf Sandbox)){ 
        return new Sandbox(modules, callback); 
    } 
    // add all modules if no modules were passed 
    if(!modules){ 
        modules = []; 
        for(var i in Sandbox.modules){ 
            modules.push(i); 
        } 
    } 
    // initialize and add all modules to the sandbox 
    var moduleInstances = modules.map(function(m){ 
        return Sandbox.modules[m](); 
    }); 
    // execute the code 
    callback.apply(this, moduleInstances); 
} 
Sandbox.modules = { 
    dom: function(){ return { 
        getElement: function(){}, 
        getStyle: function(){} 
        }; 
    }, 
    ajax: function(){ 
        return { 
            get: function(){}, 
            post: function(){} 
        }; 
    } 
}

With the sandbox in place, here are a few example usages:
```javascript
new Sandbox('dom', function(dom){ 
    console.log(this.sandboxVersion); 
    var element = dom.getElement(); 
}); 

new Sandbox(function(dom, ajax){ 
    console.log(this.sandboxVersion); 
    var element = dom.getElement(); 
    ajax.post(); 
});

new Sandbox(['ajax', 'dom'], function(ajax, dom){
    // ...
});

Conclusion

The Javascript sandbox let’s you isolate code from outside factors. It also allows you to explicitly define dependencies which reduces coupling and makes it easier to test. While there are other patterns to do this, and certain framework have this built in, this could be a good pattern to use if you’re still working with ES5 and no frameworks.