MSWebDay – What I took away from it

Today, Feb 16th, I attended MSWebdevday ran by Microsoft in Glasgow which was an event covering all things web related from Microsoft, the speakers were @christosmatskas, @thebeebs and @martinkearn and was an all day event.

The Schedule for the day covered various topics and it was great to learn so many new things and get my first glimpse at some new technologies, I always love learning something new, and I even sat next to the illustrious Gary Ewan Park, someone who I have chatted to a few times on twitter but not every managed to meet.

Ok so lets cover the actual event:-

The first talk was by on What’s New in ASP.Net Core 1.0 and was a tour of the new features, how to get it, how to use it, whats new, whats no longer there and he also talked about how you can just take the files and drop them into a folder when deploying, there’s no gac, you can just deploy the Core files in a folder alongside your code, this is very neat, its cross-platform, and it means you could have the same site running under different version of Core going forward should you choose to or need to have this.

The second Talk was Building with JavaScript Task Runners, this was mainly about how to get gulp, how to set it up and how to run some tasks to minify your css, javascript files and all that good stuff, how to add it into Visual Studio as a build step after you compile your code, showed an example gulp file and lots more.

The third talk was Entity Framework Core 1.0, and covered EF and how to use it, how to use code first and also mentioned EF6 how its improved greatly from previous versions and why you should choose this version at the moment whilst EF Core 1.0 is still being worked on and has the tooling added to it for the Core 1.0 release.

The fourth talk was APIs: the cogs behind the machine and this talk was about api’s and mainly web api and how in Core 1.0 there is no MVC and WebAPI its just one thing now and your controller is an API controller, so no need for MVC and WebAPI there is just the controllers now which kind of merge both together.

The fifth talk was Dev Ops in Azure and this covered deploying your website to Azure, making changes, showing the changes, getting the publisher file for using in side Visual Studio and publishing your changes from Visual Studio using Git int his example to deploy your changes from within VS up to the new Azure portal.

The sixth talk was Hitchhikers Guide to JavaScript, this talk focused on ECMAScript and the future of JavaScript and basically how a lot more code that we write will be JavaScript and we saw examples of the features coming in the next few years etc.

The seventh talk was Web Performance and how to check your websites performance using tools like YSlow and Google Page Speed etc and then how to go about making it make far less requests, cache JavaScript, enable IIS features and how to optimise images etc to make your website perform much faster that it currently does.

The eight talk was Single Page Applications and was about KnockoutJS and Angular, talking about Angular 2 and how it makes use of TypeScript and showed code covering KnockoutJS and AngularJS.

The ninth talk was about Hybrid Web Apps and how you can create application that can appear as Windows 8/10 tiles, make use of Microsoft Office and showed some very neat stuff using ManifoldJS which is itself very cool stuff.

Other stuff mentioned
I wrote some notes during the talks (should have taken a lot more) but a couple of things I need to look at are listed below:-

The event was great, full days learning, a lot of content covered, great speakers and good turn out. Spoke to some guys I chat to on twitter and all in all an awesome day spent learning some new stuff. There was a lot of content, I’ve missed half of it I’m sure so take a look at the slides on the site at MSWebdevday.

Dear Microsoft can we have some more of these days please? – especially Azure and Core related content.

Technical Debt in your team

technicaldebtOn twitter recently I read a few people talking about technical debt and how it occurs and how to best tackle it, so here is my view on said subject.

Technical Debt

Technical debt comes in many forms, shapes and sizes and almost every team/developer is aware of technical debt within your company.

Over the years I’ve worked in several companies most of which knew they had a fair bit of technical debt and did very little about it, sometimes nothing, so here are a few examples and how to go about fixing your technical debt:-

We didn’t write it
So the developers who wrote the code have all left, ok then task a couple of current developer to report on this project and ask them to give your team a heads up on the state of the code base and there suggestions for removing this as technical debt, either get people up to speed with the code base, document the current state of the code base and perhaps even find out if its worth re-writing but by all means do something with this technical debt.

Don’t let it mount up over time, It’ll be like the cupboard or the attic in the house where you put all the stuff you don’t want look at and that is not where you want to get to.

If the code is apart of your projects then your team owns that code, no one else does, it’s not an excuse.

The code is written using old technology
Same as above, then document it, offer suggestions to get it up to newer technologies and task people with doing something about it, don’t let it remain in the state it currently is.

The code has no tests
Same as before, get a developer up to speed with it and write unit tests, refactor the code and document they’re findings, it won remain technical debt for very long

I realise that some technical debt there is just nothing you can do, maybe you don’t have the source code for it or you don’t have any developers who know the language well enough to update the application, perhaps no one in your team knows how it’s supposed to work. The thing here is to try your very best to do something with your technical debt and as a team talk about it, work at decreasing the amount of technical debt your team owns, take actions to fix, document, rewrite or whatever but do something about it now, don’t let time drag on and just let it grow.

Don’t start on new features unless they are critical and fix your technical debt, it could make the next persons job a lot easier and that can only be a good thing.

Document your solutions, the number of times I have started looking at code and asked what does this do and no one in the team can answer the question is quite scary, that should never be the case in my opinion.

Tips for Deploying your .Net project

Over the last 20 years I’ve seen many a deployment, some good, some bad and the ugly, life’s too short for manual/long deployments.

Here is what I recommend

If you have manual steps in your deployments then stop it, now, no seriously, you can deploy with zero manual steps (clicking deploy doesn’t count).

What to do instead

Get yourself TeamCity, yes TeamCity, Jenkins is ok but you get what you pay for, trust me Jenkins isn’t TeamCity. Ok now that you have an excellent build server, you’ll want to script your builds, for this I liked using psake along with PowerShell, honestly people who don’t know PowerShell are missing out, its awesome.

So get your scripts together and kick the builds off from TeamCity using psake.

Unit Test your PowerShell Scripts

Using Pester you can unit test your PowerShell scripts, thus realising that their fragile or poorly written or just large function which are hard to test, well do yourself a favour and use pester to unit test them.
Pester also gives you code coverage for your PowerShell scripts

Deploy your app

To deploy any .Net app use Octopus Deploy, its easy, its painless, it deploys with error handling, rollback using transactions, and you can do blue/green deployments, if you want to deploy a previous release, one click, deploy to multiple environments, any previous version etc. all in one click.

To summarise, no more manual steps, no copying files, manually unzipping files, creating folders etc, – no need to do that, and leads to human error, highly recommend each of those tools.

Continuous Deployments for SQL Server – Part 3

In part 2, I covered how to compare the schemas of two databases, in part 3 I’ll to cover how to compare the data held within these two databases, for that I am going to use SQL Data Compare.

Again we will use the same two databases, imagine your comparing UAT to Production and wish to compare the data within these two databases:-



(If the links are too small click on the image and then when the new window appears click on Original size at 1896 × 316)

The above image shows us that the t_depot database table has 4 rows which are in the Stock_DB_Deisgn table which aren’t within the STOCK_DB_DESIGN_ORIGINAL database. Again same as with SQL Compare, if we now click on Synchronization wizard we will see the following screen:-


And again as with SQL Compare, we get 2 options:-

  • Create a deployment script – use this option if you want to script the changes and review before running in the changes.
  • Synchronize Using SQL Data Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database data after the changes, to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus once again you can source control the script if you really wanted to or share it with colleagues.

In part 4 I’ll cover how to deploy changes to your database whether its schema changes, data changes or both.

Continuous Deployments for SQL Server – Part 2

If you’re using SQL server at work and manually deploying changes to your database using manually crafted scripts then its time to stop, there is a better way to do this by automating it, remove the chance of human error, this will also ensure that before you deploy to production that your changes will work, guaranteed.

In this blog post, I’ll discuss comparing two SQL Server databases which you can use SQL compare to funnily enough compare them and see the differences between the two, very quickly and reliably, imagine you wanted to compare your local Development database with say your Staging database for example, or compare UAT to Production.

In this blog post I’ll go over the steps I went through and how to use Sql Compare to work out what’s changed between the two databases, schema wise, then in the second part I will show you how to use SQL Data Compare. to compare the data within both databases and in part 3 I will either create a script to update the database or run an exe which the tools will create for us to make both databases the exact same, both in schema and in data, so let’s get started.

I’ve made dome schema changes to STOCK_DB_DESIGN and I wish to see whats changed, so lets see how to compare the 2 databases using SQL Compare (I’m using version 11).

In the screen shot above I’ve chosen my databases to compare and the tool will now run and show me what the schema differences between the two. the screen shot below shows the results after the tool has been ran against both databases.


On the left pane we see the changed database, on the right the database without these changes, I clicked on the first row to show the changes in the t_depot table and in the split at the bottom it shows the differences per object – very quick and easy to see what’s changed.

Update time
In order to update the older database with the new changes, we simply click on Deployment Wizard at the top and we get the following screen with options:-


Here we get 2 options:-

  • Create a deployment script – use this option if you want to script the changes and review before running in the changes.
  • Deploy Using SQL Compare – use this option if you want the tool to make the changes for you, you also get the option after its ran to automatically compare the 2 database after the changes to verify.

And that is it, easy, simple and straightforward, no manual steps involving creating scripts, no real chance for it to go wrong, plus you can source control the script if you really wanted to or share it with colleagues.

In part 3 I’ll cover comparing the 2 databases when it comes to data, for this we will use SQL Data Compare.

Continuous Deployments for SQL Server – Part 1

Okay so your using a SQL Server database at work but you haven’t yet put the database into Source Control, here are some reasons as to why you want to do this:-

Source control your database
Trust me your going to want to do this if you haven’t already, it’s a good practice, it may save your skin some day, yes you can take backups which again is a good practice, here is an excellent article on why you want to do this:- Why put your database into source control?.

Okay now that we wish to put our database into source control – we still use Subversion at work so I downloaded Subversion and installed it locally as well as TortoiseSVN.
I have 2 databases called STOCK_DB_DESIGN and STOCK_DB_DESIGN_ORIGINAL within SQL Sever, the former had a few schema changes, imagine this is Development(STOCK_DB_DESIGN) and Staging(STOCK_DB_DESIGN_ORIGINAL).

I created a local repository within Subversion and downloaded RedGate’s Database Lifecycle Management Products.

This tool comes with SQL Compare and SQL Data compare as well as a host of other awesome SQL Server tools which you can find out about at the above link.

For this post I’ll be using Redgate’s SQL Source Control which adds a tab to SQL Server Management Studio and looks something like this:-


So lets go ahead and add a database to our source control using this tool, Select the option above, and then Next


I selected Subversion because at work we still use it, but you can use Git also and others, click Next


I then give it a repository URL, I already created a repository within Subversion for my database and added the URL like above, click Next and that’s it, our database is now linked to source control. Now to get the database scripts into Subversion we need to right click on the Database in question within SQL Server Management studio like so and select Commit Changes to source control:-


This will then add all of the database objects to SQL Source Control, once that’ completed, go into windows explorer and I use TortoiseSVN I can right click within my local SVN repository folder and then select Checkout or get latest version and this will result in the following folders being populated:-


And when I go into say the tables folder I’ll see the following:-


And that’s all there is to source controlling your SQL Server database. If I make change to an object say a table I’ll see whats changed locally in SQL Management Studio and I’ll know I still need to commit the change as seen below:-


In Part 2 I’ll show you how to compare schemas on both databases to work out what changes are required, and how to script them using the tool.

My list of best practices

Over the 19 years I’ve been a developer I can say I have seen some good, some bad and some ugly practices, but lets remain positive and here is my list of best practices/thoughts to which I hope have adopted to over the years:-

  • Make sure you have the latest version of the code before you check in (if you’re using SVN).
  • Small commits and commit often, after you’ve run your tests locally that is.
  • Don’t be the developer who is always breaking the build, check that your code builds on the build server.
  • Check your builds daily, make sure builds aren’t left broken for days.
  • Automate builds/deployments where practical, manual deployments are a no-no.
  • Measure code coverage as it can point to bad smells in your code base.
  • Write Integration tests and Unit Tests which add value, not just to get code coverage up.
  • Clean up after you, don’t leave stuff lying around.
  • Make sure your log files are actually helpful, don’t fill them with useless info and make the log level easily configurable.
  • If you create Helpdesk tickets then give some meaning to the piece of work, don’t be lazy.
  • Don’t check in Third Party Nuget packages to source control – keep your repositories lean as possible.
  • Begin Transaction *put your update statement here* Rollback Transaction, trust me this can save your ass.
  • Leave the code in a better place than it was before you touched it, remove unused code, unused using statements, refactor duplicated code etc.
  • Get the database Id in SQL using ‘select db_id()’ and trace it so you know exactly what your stored procedure is doing
  • At the daily stand up, have a note of what you were working on, “I don’t know what I did yesterday helps no one”.
  • Try and figure out why its broken, don’t leave it for others to fix, you wont learn much doing that.
  • Take an interest from development right through to deployment, the more you know the more you’ll understand and can perhaps help out.
  • We are professionals, act like one and take pride in your work.

I will add to this list over time, feel free to comment on any of this and tell me your thoughts.

Catch me on twitter @gsuttie