NDepend V6

As anybody reading my blog for a while can tell you I like NDepend and a new version was recently released.

Disclaimer: I do not work for NDepend but I was lucky enough to be provided a license to use the software, my opinion in this post is my opinion and nobody else’s.

My first impression of the new version is that there aren’t a huge number of new features in this release rather there has been a number of incremental changes & improvements to various parts of it.

What’s new and changed?

V6 brings with it integration for VS2015 (which V5 didn’t have) and there have been several enhancements around making the experience of using NDepend smoother – better VS integration, VS theming, high DPI support, able to work with portable class libraries etc.

For a long time integrating NDepend into a build process on a CI server needed you to perform additional work to get it hooked up but in V6 its been made easier and there is closer integration with a few CI server technologies, TeamCity being the one I’m most interested in, where NDepend now makes it easy to integrate into the build process.

One area NDepend has suffered with is compiler generated code, such as anonymous types, lambdas, async/await, etc. This has been tackled in V6 so instead of being told  <>f__AnonymousType0<int,string> breaks a rule it now tries to determine if the rule is really broken or if its only due to generated code which will hopefully reduce the number of false positive rule violations.

Additional support has been added around tests so that NDepend can now tell you percentage of code covered by tests and the treemap has had additional colouring added to enable you visualize the code coverage over the assemblies analysed.

My thoughts on V6

As I mentioned before this release feels more of an incremental change rather than a big functional change but that is to be expected with a mature product such as NDepend.

The enhancements around VS integration, VS theming etc are something that the product needed simply to stay where it was i.e. its not a selling point per say rather what people just expect a modern application to support.

Although the test coverage additions seem useful, in practice I find myself using the existing tools I already have to work with this so I’m not sure I’m going to use these new features all that much.

My favourite new feature in V6 is the ability to attach NDepend to a solution using the solution user options (.suo) file rather than the solution (.sln) file. The benefit of this is that because .suo files are not normally stored in version control it means that I can use NDepend on a solution where others in my team don’t have NDepend and it doesn’t cause anybody any issues when loading the solution.

Should you upgrade?

If you’re already using NDepend V5 with VS2013, unlikely upgrade and not impacted by most of the enhancements or only use NDepend from the command line then upgrading may not provide much value.

However, if you are going to be upgrading to VS 2015 and use NDepend inside of VS or in your build progress then I think you’ll want to upgrade to get the latest enhancements.

A day of intensive TDD training

Last Saturday (25/7/2015) found me in South Wimbledon attending a 1 day intensive TDD training course being run by Jason Gorman from codemanship.

Although this course is usually run over 2 days codemanship occasionally run the course as a reduced price 1 day intensive format.

I had decided to attend because although I have been trying to do TDD for the past few years I have never had any formal training so wanted to check what I was doing was correct and see what else I could learn about TDD.

Introduction

Once everybody was set up Jason told us what we could expect from the day starting from the most basic TDD techniques progressing through you use TDD to drive the design to using mocks/stubs and finally applying techniques to work out behaviour required from user stories.

Jason pointed out that when you first start doing TDD you need to be mindful of what you are doing to ensure you are following the practices we would be doing that day as it was easy to slip into bad habits, this will mean you will be slower until you become comfortable with the various practices but you would become faster the more you did them.

TDD Back to the beginning

After the introduction Jason took us right back to basics explaining the red-green-refactor cycle and stressing that the refactor part is just as important as the test to ensure you end up with good code.

Jason then had us pair up to write tests/code around transferring money between two bank accounts, in fact all activities during the day were done as a pair which was great as I also got to practice pairing with different people. 

Jason didn’t give us any specific guidance about how we should do this, other than write a failing test, make it pass, refactor – not forgetting to refactor tests as well.

After you had created an object oriented way to handle the transfer Jason got us to go back to just doing it with variables and then refactor that to find and eliminate the duplication, teasing out methods where necessary and giving you insight into

More TDD Basics

After the first exercise Jason talked to us some more about the techniques you use in TDD to help drive the design of the code such as tests only having one reason to fail, always write the assertion first, triangulation, etc.

One thing he stressed was that the idea isn’t to do no design before you code but only do enough design to inform where you start your tests (something we came back to later).

Triangulation was something that really helps with this as Jason explained you want to be driving from a specific solution towards a more general solution, writing meaningful tests which are self explanatory using data that helps tells a story e.g. boundary values.

Another thing that was highlighted out was writing the assertion before you write the code isn’t just to ensure you have a failing test but to make you think about what it is the code needs to do to satisfy that assertion,  and the assertion should be related to helping satisfy the requirement(s).

Armed with this new knowledge we tackled our second example of creating a Fibonacci generator.

Yet more TDD Basics

After the second exercise Jason talked to us about refining what we were doing, isolating tests, never refactor with a red test, test organisation, etc.

Another key point here was to pay attention to the requirements so that you didn’t needlessly create tests that you had to throw away later, this tied back to writing the assertion first to make sure you are writing a test that helps satisfy the requirements.

Jason stressed again the need to importance of maintaining the tests, this means refactoring the tests where necessary to try to ensure they are clear, easy to understand and testing what is necessary (circling round to not writing needless tests)

We then tackled are 3rd and final exercise of the morning having to create a FizzBuzz program with with some additional requirements.  If we completed the initial work Jason challenged us to rewrite the generator so that it didn’t use any conditional statements when generating the sequence i.e. if, switch or tertiary operations.

Test Doubles

The afternoon started with Jason touching on the London & Chicago schools of TDD and how the London school favoured the use of the various types of test doubles to allow testing of interaction between classes.

After discussing the various types of double we jumped into our first example of the afternoon creating a system (in the loosest terms possible) that could tell you if you were able to book a holiday for a specific week of a specific year.

Pulling it together

When we stopped the 4th exercise Jason started talking to us about how we pull all of this together to help design a system.

Users & goals

He talked about determining requirements and how a common way to capture this information was via user stories.  What was stressed though is the user story should be seen only as the starting point for a discussion, hopefully with the user, to get more details around/about the functionality needed.

We utilized the Given…When…Then format to get this additional information with each of the then clauses becoming the requirements to be satisfied. Although this helped us gain further understanding about what was required Jason pointed out that they weren’t executable specifications, to understand specifics we needed concrete examples for each then to allow us to create tests that can satisfy them.

Class Responsibility Collaboration Cards

With this additional info could examine the stories to determine the roles, responsibilities & collaborations that we believe we need and to help us visualize the objects we used Class-Responsibility-Collaboration (CRC) cards where we have 1 card per role (object) listing its responsibilities (methods) and other objects it communicates with (collaborations).

This helps to enable a “tell don’t ask” design where you communicate by message passing  which also identifies boundaries where you can mock the interactions when you come to writing the tests.

Testing the design

We then did an exercise where in a pair we took a user story, created expanded details and added specifics then Jason took our finished work and handed it to another pair to create the CRC’s for it.

Once everybody had completed the CRC’s Jason took one or two and showed us how we could test the design by running through the Given...when…then and seeing if the objects and interactions would successfully satisfy the criteria.

Finishing up

Jason re-iterated what he had said at the beginning that we needed to ensure we practiced the techniques we had learnt today as if we didn’t practice it was easy to slip into bad habits and asked us all to think about what we could do to practice.

We all then went to the pub to have a drink and discuss the day a bit further.

My thoughts on the day

Firstly I can see why this is billed as an intensive course, we really didn’t stop during the day. Ideally I would have liked a little extra time doing the exercises but in general I liked the pace, it kept you focused on what you needed to do without overloading you.

I really enjoyed the course, it reinforced my existing knowledge, highlighted areas where I have picked up bad habits and I came away having learnt more around triangulation and using CRC cards to test specifications.

Whether you are a complete beginner or have been doing TDD for a while I’d recommend this course, I’m sure you would get a lot out of it.

Agile…..its all about the code

Over the last few posts I’ve talked about principles, I’ve talked about culture and mentioned methodologies.

Although I’ve touched upon development/engineering practices in most of these posts you could be forgiven in thinking that these practices are unimportant or just another thing you should do.

This couldn’t be further from the truth.

The key to achieving success with agile in software development is by implementing the various development/engineering practices.

Without these practices “agile” just becomes a different way to organise the work, it doesn’t improve the quality of the code and it doesn’t speed up development.

On the flip side just adopting the development/engineering practices won’t help protect the team from being bombarded with requests for work, having to chop and change between projects or working on “the wrong thing”, the other agile practices exist specifically to help the team with this allowing them to focus on getting software into the hands of the users/customers, which after all is the ultimate goal.

Agile Culture - is it a thing? is it important?

In the last few posts I've covered a variety of aspects of agile, how the artifacts and practices associated with agile don't make you agile, the underlying concepts in a good agile team, how agile methodologies are just tools and the benefits that you will hopefully see with a fully agile team/business.

A couple of times I've mentioned agile culture but not tried to actually define it in any meaningful way or described what it is and why it is important, so this post I'm tackling just that.

What is an organisations culture?

Before trying to define what an agile culture is its worthwhile defining what culture means in this context.

I looked around the internet and found a few different definitions about what culture is (such as here and here) and I believe you can generalise the various definitions and say that:

Culture is the combination of the values, beliefs, practices, etc that people in a company adhere to.

Some of these may be explicit e.g. a mission statement and others may be implied e.g. social norms in the company.

Whilst a company may have the same values and beliefs as another company, the implementation of those values, beliefs & social norms may well differ resulting in a different culture even though at their core they are based on the same things.

Agile Culture

Having defined what a culture is, and understanding that every companies culture is going to be different, what values, beliefs & practices could we reasonably expect to see within an agile culture?

Embracing agile principles and practices

Unsurprisingly an agile culture is one that embraces agile principles but not just within development teams but throughout all aspects of the business that are involved with project/products.

Not all agile practices are appropriate for people outside of the development team e.g. TDD, but practices such as sustainable pace, value stream mapping, limited work in progress, transparency, etc are suitable across the business so everybody can benefit from using them.

Focus on delivery

One of the tenets of agile is "stop starting and start finishing" it is about delivering and people in an agile culture do just that across the business in relation to whatever work they perform.

Value of a piece of work is understood

Agile talks a lot about value (I wrote a post about this a while back) and wanting to focus on delivering value for the business. In an agile culture this idea is understood across the organization which can make decisions about prioritisation and delivery easier since when people have to make a decision they do so with the common understanding of the value that they believe a piece of work will provide for the business.

Actively seeks feedback

How do people know if what they are delivering is the right thing? they seek feedback.

When it comes to feedback a development team is spoilt by all the different forms of feedback they have available to them - unit tests, continuous integration, product owner/champion, users, etc. For other parts of the business the form and type of feedback will depend on what is being delivered, and who it is delivered to, but that doesn't stop them seeking feedback be it from a person, team, department or company.

Learning

Many organisations want to promote a culture of learning due to the benefits that it brings, an agile culture has an advantage with the feedback mechanisms providing information about what is delivered and what may need improving.

The other advantage is that agile methodologies have built in practices such as "Inspect & Adapt" from Scrum or "Continuous Improvement" in Kanban which actively encourage teams to look at what they are doing to enable them to improve how they work.

Good companies don't just stop at looking to improve processes but also encourage individuals to learn, understanding that if people learn they bring that knowledge into the organization and the business ultimately benefits from that.

Do companies with an agile culture actually exist?

So is this an actual thing? When people hear this description they frequently comment that this "sounds great in theory, doesn't work in practice" or they say it seems like an agile nirvana or fantasy, and I understand that for a lot of people it seems that this way of working is a million miles away from how their own businesses work day-to-day.

Probably the most well known company that you could point to as appearing to works this way is Spotify (checkout these blog posts for more detail Part 1 and Part 2).

I have myself worked for companies that came very close to what I have described, they may not have implemented everything I've outlined but they focused on ensuring the team could build & deliver the software without putting any unnecessary roadblocks in the way.

Is this important?

I believe that working this way is very important, it helps companies understand that although the development team are the people producing the software they are only one part of a larger process which involves everybody upstream & downstream of the developers; companies need to understand that this larger process is what generates the companies income and the true cost of any project/product is related to everybody involved in the process, rather than just one part of it.

More explicit knowledge of how the various parts of an organisation interact helps to identify where any bottle necks exist slowing the delivery down, allowing a company to focus on the problem area rather than just presuming they know which part is causing the problem, often incorrectly.

Possibly the biggest advantage is having people in an organisation understand the larger process, it may not change the work that they do day-to-day but it can mean they understand their impact on other peoples work in the company, plus they are able to weigh decisions they need to make based on feedback received, perceived value and what needs to be delivered, rather than simply "doing what they are told to do" people hopefully become engaged, active participants rather than sheeple.

Agile methodologies are just tools

Agile methodologies (XP, Scrum, Kanban, DSDM, Crystal, etc) are for the most part made of really simple tools, so simple in fact that anybody could be told about them and start using them almost immediately

However, in my post agile isn't I said

even if you are doing everything a methodology says you should do doesn't necessarily make you agile.

I said this because the various methodologies are really just a bunch of tools designed to help you with your work, but tools alone won't make you agile.

A comparision

I have a friend who is a master carpenter, his toolbox contains many of the tools I have in my garage, and whilst I can use my tools my results are never as good as his. The reason for this is he has years of experience and a passion for working with wood, not only can he pick the best tool for the task at hand but understands how best to use that tool to get the result he wants. Combine this with his knowledge of wood, techniques for working with wood (joints, cuts, etc) and he will always be better at working with wood than I am.

I could practice with my tools and gain insight into how best to use them and which one to chose but it wouldn't make me a master carpenter, for that I also need the other knowledge my friend has about wood and techniques for working with wood.

Could I learn this? of course but from seeing my friend work and talking to him I can see its not something you learn out of a book, you do it by practice and feedback from more experienced people.

How's this relate to agile then?

As I mentioned before agile methodologies are made up of what are really simple practices and people read books, blogs or attend a 2 day course and belive that they understand how to use these practices.

However, this is no different to me having a bunch of tools in my garage, I know what they are and I have a basic idea of how to use them but I'm not going to get the best results.

This brings me back to my quote from my earlier post, unfortunately a lot of agile implementations out there are done by people who only have the tools they have no passion for it and haven't tried to learn more about not only the practices they follow but agile itself, leading to some of the nightmares you hear about agile in the work place.

It takes time, experience and practice to take these simple tools and understand how best to use them to get the most out of them, you need to spend time listening to other experienced practioners, talking to them, asking questions, etc.

Although my post Agile is... outlines some of the concepts underlying agile, at its heart its about people and tools will only help they won't do the work for you.

What does a good agile environment give you?

In my last post I talked about what made a good agile environment and the post before that I mentioned practices that people often mistake for being agile.

When you put the concepts and practices together the result should be an agile environment with everybody aligned towards the same goal

Trust

One of the biggest gains that you get in a good agile implementation is the increase in trust between the organisation and the team.

Historically projects have failed and organisations have lost trust in teams to deliver so they then started implementing tighter project management in an attempt to ensure projects succeed, which frequently leads to more project failures.

The trust can be restored with the team increasing communication with the rest of the organisation by being transparent with the work (tracking work on a card board, charts showing progress, meetings, etc) and through collaborating with the rest of the organisation about work being done and the work to be done.

If the team is trusted to deliver the focus moves from when something will be completed to what is to be completed and how soon it is needed.

Value

Frequently work is prioritized based on a vague idea of what the business thinks is best for the product but often without any context of how simple or complicated a feature will be, collaborating with the team can feed in to discussions around the cost of developing that feature versus the benefit the business anticipates it will get from it.

Value itself is a tricky thing to pin down: is it about money, cost, user experience? Recently there have been some posts (notiable this post and this post) discussing value and showing that it is a very nuanced area.

The good thing about this is value will need to be considered and discussed amongst everybody involved across the business so that everybody understands value around the work being done it can help them with making decisions themselves as to priority of the work.

Speed

One reason that organisations want to adopt agile is because they are under the impression that it will speed up development, they are then disappointed when following a methodology the work isn’t being done any faster.

The potential increase in speed, and it is only potential, comes about mainly because with better engineering practices, building the features that are of most value and focusing on creating working software the business ends up being able to use/sell the software in days/weeks rather than months/years.

The people aren't actually creating the work any faster than they were before it is just that they are having to do less rework which means the software is available to the end users sooner, and there should be less defects meaning less time needing to be spent on support all of which combines to allow more time to be spent developing the product in the first place.

Flow

Good agile implementations don't restrict themselves to looking at the team creating the work, they look at the organisation as a whole and work out everything that is involved in creating a product, how the work flows through the business.

Once you start seeing the team as only part of the overall flow it may become apparent that there are both upstream and downstream activies which are causing problems for the organisation and it is these areas that need to be tackled to improve rather than just focusing on the team.

A side effect of this can be to question the need for estimates, if you have a team that is reliably deliverying work and is only 1 part of a bigger process what value does the business get from estimates from the team? This isn't to say the business isn't going to want estimates but it is understanding the value of that estimate in context to the larger organisation versus the value from the thing they want to create.

Summary

Creating an agile environment is hard, you can take a team and implement an agile methodology but that is only a small part of the story. Done right agile will involve a lot of the organisation (if not all of it), it changes the way people in the business look at the work and focuses them on what is being produced and the part everyone has to play in getting that work done.

More than that though it can prompt people to look more deeply into various aspects of running the team/organisation such as value, reward, motivation and learning to name a few.

Hopefully these posts have given you an idea of what agile actually looks like rather than the perception that it is a methodology or just a few meetings, charts and user stories.

Agile is...

My last post covered a lot of things that people associate with agile and how just doing those things don't make you agile, this time I'm going to cover things that good agile implementations tend to display.

Communication

The keystone of all good agile implementations is good communication.

The last post listed meetings & visual work tracking which are are all ways to communicate but what is key is that an agile team doesn't restrict themselves to just these methods, they will communicate whenever they need and not restrict themselves to "set" meetings.

For me agile revolves around communication - communication between members of the team, the team and the larger business, the business and the customer, etc. From communicatin we get

Collaboration

Another key part of a good agile implementation is collaboration, it forms the basis for working in the team and for the team working with the customer/business.

I mentioned capturing user stories as requirements in the last post, these should involve collaboration between the customer/product owner/product champion and the team. The team shouldn't be separate from these discussions it should be a part of them able to provide not only technical insight but frequently a different view on the product as the team has unique domain knowledge from working on the "product".

If there is no collaboration then people tend to fall into silo's & lose the view of the whole product as well as fostering the mindset "it's not my area/problem/issue/job".

Cooperation

Whilst collaboration is about working with other people toward a single goal,cooperation is about working with others towards your own goals. Think about this. In a team everybody is doing their own work to pursue the larger goal that the team is working towards, but an agile team co-operate understanding that everybody needs to complete their work for the team as a whole to succeed.

What does this mean in practice? An example isif one team member finishes their work and can see other people still working on theirs they offer to help them complete existing work before starting anything new.

Control

For a long time developers were told what they had to work on, when they should work on it and often how long it should take them to complete it, they had no influence over what they did or when.

Agile turns this on its head, collaborating with the business the team should be involved in all aspects of the work from generating user stories, prioritising the work, developing, testing, etc.

This apparent reversal of traditional control is done to allow the team to be able to make decisions quickly, rearrange the work based on changing circumstances/priorities to enable them to deliver the work.

Commitment

Work needs to be completed & users using it for it to be of any value to the business, people working in an agile environment understand this.

Don't confuse this with the team committing to complete work in a sprint from the older Scrum guides, this is the business being able to trust the team to complete the work, this doesn't mean working ridiculous hours to finish by the end of an iteration(although the team may decide to do that), it is knowing that when a piece of work is started (barring any changes in priority or direction) the work will be completed and delivered.

Adaption

Agile isn't static, when you first start you may have a framework that you work within but as a team becomes more experienced they use techniques like retrospectives to determine how they can improve what they are doing.

Should you wait till a retrospective to make a change? No. Just like you shouldn't wait until a meeting to talk to other people there is no reason why you can't make changes to the process outside the retrospective.

Summary

People will often point to the agile manifesto and say "that's agile" but it doesn't tell the whole story, other people will point to the agile principles which provide more examples of how an agile team should work but still can't convery the subtleties of working in an agile environment.

Underlying both the manifesto and the principles are the concepts I've outlined above, regardless of if you are practicing an agile methodology or not, you can tell if a team/organisation is agile by observing them and seeing if their culture embodies the concepts listed here.

In my next post I'm going to go into how some of the benefits of being agile, often listed as reasons to go agile, are in fact side-effects of having the right culture and mindset based on these concepts combined with the practices from my last post

Agile isn't...

Meetings

Various agile methodologies outline specific meetings but holding these meetings doesn't make you agile

Capturing requirements as user stories

You aren't writing large requirements documents, you're capturing the details using a form of "As a <user> I want/need <functionality> so that <desired result> This is a good way to focus on functionality that you need for the system (it does have its pitfalls and nuances) but doesn't make you agile

Visually tracking work

Having a board that shows progress of work is really good to help people understand what the team is currently doing and what they've done, similarly charts summarising progress can help people understand trends but doing this doesn't make you agile.

Engineering practice's

Your team practice TDD, pair programming, continuous integration/delivery/deployment, that's awesome and will help you a lot in your day to day work. These practices aren't restricted to agile working so this doesn't make you agile either.

Following an agile methodology

I can hear people say "we do all that, and we have people dedicated to ensuring we follow the process etc" and I would not doubt you but from experience I can still say that even if you are doing everything a methodology says you should do doesn't necessarily make you agile.

So what is agile?

The items listed above all have value in them and I wouldn't suggest you stop if you're doing them already. Just don't think that by doing those you are agile.

In my next post I'll detail what things are common to successful agile implementations that I have seen.

Emailing support

A while back I was working with a colleague and we ran into an issue that required us to email a company for support.

My colleague expressed an interest in how I went about structuring the email and asked if I could write up my process for them, hence this blog post.

Structure

The way I structure any of my mails, to support or otherwise, is along the lines of:

• Explaining reason for the email
• Provide any information I may have on subject
• If asking for something clearly state what I need/would like

In addition if I am able to provide anything to help, such as test project with failing tests, they should be attached or easily accessed.

One of the additional things that I take into account when writing an email for support is thinking “what would I need to help

Example

Below is an example email written about a problem with a fictitious component aBxZ:

Hi Support,

Here at MadeUpCompany.com we are using your aBxZ component and are concerned about the number of duplicate calls it is making to the 123.com api and can see no way to stop this.

We have been using Fiddler to profile aBxZ’s behaviour on our QA environment whilst testing with a similar load to our production environment and have attached the data we captured.

If you look at the captured sessions you’ll see that aBxZ makes a call to 123.com for every request, this is happening even when we don’t call aBxZ explicitly.

We read the documentation and ensured that we have followed the instructions and guidance on how to use aBxZ and we posted on StackOverflow about it but nobody was able to provide a solution.

We managed to replicate the behaviour in a test project, which is attached, and it appears to be happening when aBxZ is instantiated.

Please can you let us know:

1. Are we using the component correctly?
2. If using it correctly is there anything we can do to stop this?
3. If it is a bug with aBxZ when you think you might have a patch/fix

If we should be doing something different to what we do currently please could you alter the attached test project and send it back to us.

Looking forward to your reply

Analysis of the email

Looking at the mail it follows my structure and breaks down like this:

• Paragraph 1, say who we are and what the problem is
• Paragraphs 2 – 5 provide details about what has been tried and provide to them additional information in form of captured fiddler sessions and a test project
• Paragraphs 6 & 7 ask, hopefully as clearly as possible, for help to resolve the issue.

Summary

Hopefully this is of use to you, for me it seems to be very clear but I’d be interested to hear from other people how they structure their emails and if you think I’m missed something out.

Simple.Data Asp.Net Identity Provider

ASP.Net Identity is Microsoft's latest implementation of a membership and identity service which will replace ASP.Net Membership, SimpleMembership and Universal Membership.

The out of the box implementation of ASP.Net Identity is, unsurprisingly, coupled to Entity Framework (EF) which means if you do want to use the new identity functionality but your app doesn’t use EF for data access you either end up having to include it in your project anyway or not use Identity.

Simple.Data

On a project I was part of towards the end of last year we ran into this exact problem, we were using Simple.Data for data access but wanted to use the new features of Identity.

One of the advantages of identity over previous membership implementations is that it is possible to provide a different data access layer allowing you to use the database you want but keep the rest of the functionality provided by identity e.g. password encryption, OAuth, etc

The advantage of using Simple.Data is that you aren’t limited to connecting to any one database as you simply include the relevant provider for the database you want to use (if it is supported).

The Provider

The result is a Simple.Data provider for ASP.Net Identity which should be able to dropped into an existing application using EF with little to no change.

You can install it from Nuget using the package manager console with the following command:

PM> Install-Package Simple.Data.AspNet.Identity

If you prefer to use the “Manage Nuget Packages” GUI it is easiest to search for Simple.Data:

If you want to just look at the code or feel like building it from code yourself the repo on GitHub can be found here.

Limitations

There are a few limitations with this implementation that its worth knowing about:

• Due to ASP.Net Identity being designed around generics you must use concrete classes with it, you cannot use dynamic.  To help the provider comes with 2 classes IdentityUser and IdentityRole classes for you to use.
• Database tables – currently you need to use database tables that match the IdentityUser and IdentityRole classes although they don’t have to be named the same.  The Nuget package includes a script for Sql Server to create these tables.
• Relies on referential integrity – when deleting data ASP.Net Provider does delete any data that may be effected, instead it relies on db referential integrity to clean up linked records.
• Ids stored as strings – although ids for users, roles, etc are generated as Guids they are stored as strings, this mimics the standard EF model.
• No IQueryable support – Simple.Data doesn’t support IQueryable this means that the Users property on UserStore and Roles property on RoleStore will throw not implemented exceptions.  If you need to query Users and Roles you need to do that yourself
• Only works with Simple.Data v1 – a version is coming for Simple.Data v2 (which supports async await) but this is still a work in progress.
• Db Connection – the provider supports using Simple.Data default connection or a named connection, it currently doesn’t support taking a connection string directly.

Although you need to use the identity classes in the provider you can inherit from them just like the EF code.

Samples

To try and make it as easy as possible to get started with this provider I have built 2 sample applications based off of the normal MVC project template:

1. MVC 5 Standard Sample – this is the standard MVC project template the only change is that it uses Simple.Data for data access.
   
2. MVC 5 Sample – this sample is an extension of the standard sample as it includes using roles with identity to be able to control access to pages of your web application

The easiest way to work with these samples is:

1. Create new ASP.Net Web application
2. Select the Empty project template
3. Once the project has been created add the appropriate Nuget package

If you want the standard sample then at the package manager console type:

PM > Install-Package Simple.Data.AspNet.Identity.MVC5.Standard.Sample

Or if you want the sample that includes roles:

PM> Install-Package Simple.Data.AspNet.Identity.MVC5.Sample

When you install these packages you will have all the necessary classes and references added to your project and it will create a database in localDb so you should be able to build and run the code to start working with it immediately.

Both sample projects are in one repo which you can find here if you wish to play with the code that creates the samples although installing the Nuget package is by far the easiest way to get working with the code.

The future

This version is 1.0.0, it is stable and should work without problems (taking limitations mentioned into account).

Going forward there are several improvements that I intend to make:

• Simple.Data v2 – complete work on this implementation
• Support connection strings – to match normal Simple.Data connection options add the ability to be passed a connection string.
• Support different id variable types – normal ASP.Net Identity allows for different variable types for ids via more generics, I’m looking to add this in.
• Automated builds – looking to use AppVeyor to build and test the code
• Automate Nuget publishing – once AppVeyor is building the code look to automate generation and publishing of the Nuget packages
• More samples – add samples showing use of the provider in different ways e.g. not tied to Owin context

Summary

This provider should make it easy for people that wish to use ASP.Net Identity with Simple.Data right now.

With the planned future improvements the additional functionality will bring it up to parity with the full EF model.

CodeProject

Node School–Bristol

Last Saturday I got to attend the first NodeSchool to be held in Bristol.

The event was held at the MixRadio offices in the heart of Bristol who were sponsoring the day by hosting the event, the room was at the top of their building looking out over Bristol which was brilliant.

The Day

I, like most attendees, started arriving about 9:15 finding somewhere to sit and getting their laptop ready.

Just after 10 the event began with an introduction telling us all about the day, what we could expect, how to get help and thanks to the sponsors that had made the day possible.

The format for the day was to follow the tutorials in the learnyounode workshop from NodeSchool (which you can install using npm install –g learnyounode) the difference being that instead of having to do it on your own, and try and complete the exercises simply by Googling for solutions, there were “mentors” on hand to help if you got stuck.  The mentors were volunteers who had experience with node and could help solve the exercises in the workshop.

The original timetable for the day had attendees having a break at 11 but most people were heads down working on the exercises with mentors helping out as required.

Lunch was supplied by JustEat, who were also sponsoring the event, who provided some awesome pizza for everyone to eat.

After lunch there was a short update on what the plan was for the afternoon and other tutorials that you could look at before we carried on with the exercises.

At 4:30 we stopped for a talk from Adam Butler on “5 Things to build with NodeJS” the highlight of which was Adam flying a couple of different drones using node.

After the event there people went for drinks at Big Chill which unfortunately I wasn’t able to attend.

The workshop/exercises

The learnyounode workshop code is structured into a series of exercises that take you from “Hello World!” through multiple async http calls to creating your own http server.

Everything is done at the command line with learnyounode providing a list of all the exercises and marking each as completed when you successfully complete an exercise.

When you start an exercise you get told what it is you need to do and then get a “Hint” giving you more information about how to accomplish what it is you need to do, once you’ve written your solution you verify its correct using the learnyounode inbuilt test harness. 

If your code doesn’t pass the test you get test failure output showing what was expected and if you pass you get shown the “official” solution to the problem.

My Day

During the day I managed to complete the entire workshop, which was the intention for everybody.

I also managed to complete the Express workshop, ExpressWorks, and what was interesting (to me at least) was how noticeably easier it was to use node with a framework like express after having had to code at the lower level for most of the day. 

Summary

It was a really good day in a fantastic venue, we were fed watered and looked after really well throughout the day, I must give a big thanks to Katja ,Tristan, Tom & Adam for organising the day.

Although I wouldn’t say I’m now a proficient node developer I feel I have a much better idea of how node works and also through doing the Express workshop can see how easy it would be to put  together an application on node.

I know that they are planning future events and I would recommend attending one if you want to explore the world of node but were unsure where to start.

2014 in review

Just like previous years I’m blogging a little review/retrospective on what I got up to last year, what goals (if any) I managed to achieve and what plans I have for the year ahead.

2014 Goals

As I did so badly in 2013 with my goals I changed tack for 2014 with only 3 main goals:

• JavaScript/SPA
• Code
• Blog