What I hope to learn in first quarter of 2017

So for the first 3 months of 2107 I’m planning on learning as much @Docker as I can.

So far I have it installed on my Mac pulled down some different images and played around with Jenkins Blue Ocean and read some online articles, just some very basic stuff.

My goals for between now and end of March is as follows:-

  • Get used to the commands and try them out and see what is available
  • Read up on stuff like Swarm and the other Docker stuff which at this point I know nothing about
  • Create some basic containers and see whats possible

I have some stuff I’d like to try out and see what’s possible, how easy it is and the end goal is to have done a talk at work in February on Docker and to have learned as much as possible each week whenever possible.

I am going to be using the following links, shout out if I am missing some invaluable content, be it blogs, books or training etc.

That’s it for now, let me know if I’ve missed a great resource.

Thanks
Gregor, @gregor_suttie

My company’s 2 day hackathon

Last week at work we did an offsite hackathon over 2 days offsite at Skillsmatter which is in Central London, the idea was to get offsite and brainstorm ideas around how we can benefit our users and add more value to the product we work on.

The hackathon included everyone from the team including UX designers, QA testers, Developers and Product Owners, and we had a clear vision which was our goal for the 2 days.

I had never been to a hackathon or anything like it before and I wont go into too much detail but the following is what we did for 2 days, how we went about it and perhaps you can take some ideas from it and do your own similar thing at your company or with your team.

hackathon

Ground Rules

Define some grounds rules at the start and try to respect them over the 2 days.

Day 1

  • No electronics allowed (i.e. mobiles or Ipad’s), except your laptop.
  • No ideas are silly.
  • Only one person speaks at anytime.
  • Elmos – Enough Lets Move On (if one person talks for too long).
  • HiPPO (highest paid person’s opinion, highest paid person in the office) – everyone’s opinion has same value and weight, bosses don’t make the decisions.
  • Parking Lot – area where some ideas aren’t thrown out but places on this part of the whiteboard for later on future discussions perhaps.

After we set some ground rules we split into teams and individually wrote down all of our ideas for ways to try to meet our vision and then we discussed and grouped them into similar types. From there we decided we had 3 ideas which we then whittled down to 2, we split into teams and started with some sprint planning in each team.

After we planned out our ideas we then started work using small 1.5 hour sprints, each sprint ending with a sprint retrospective and show and tell to the other team, here we gave feedback to the other team and discussed the good and the bad and the potential with each idea etc.

Day 1 lasted from 8:30 am to around about 6pm I think it was and it was a pretty long day but super awesome fun.

Day 2

Day 2 started again with some sprint planning, figuring out what we wanted to achieve and splitting out tasks for each person in the team to have something to work on and something to produce at the end of the sprint. Some people worked on the UI design, developers worked on the code, testers wrote some test and wire frames were also created by the Product Owners and some of the designers too.

I’ll skip to the most important part of the 2 days and what I personally took away from the 2 day workshop/hackathon.

What did we produce

After the 2 days we came away with 2 separate pieces of work which met our vision and will definitely improve our product, we had working code, it was tested, it looked pretty good and with a couple of days work would be production ready.

Lessons Learnt

  • Working in a different way to our normal 2 week sprints was awesome, having everyone in the team, all together, working around a table, throwing ideas out, dismissing some and getting instant feedback resulted in rapid feature creation from start to finish, in 1.5 days of actually doing the work we had something not far off production ready.
  • Instant Feedback – Feedback from everyone right there and then was key to delivering something we all thought worked, and would benefit our end users.
  • Every single person had a voice, every single person had their own ideas and collaborating together to pull the best parts of these ideas together was something which we don’t always get to do.
  • Offsite – being away from work and not having the disruptions of email/meetings/phonecall’s in a nice big building with areas to go eat and relax for a bit helped a lot.
  • Writing down all the ideas, being able to group them together and see the most popular ideas helped drive the towards picking the ideas to work on.
  • Being able to have everyone at the same level and not have the boss have the final say was quite an interesting take on it and one which I think everyone welcomed.
  • This will hopefully change the way we do larger pieces of work going forward in our sprints, getting everyone together and brain storming ideas, designs and getting instant feedback and rapid development so that we can take a piece of work and deliver more over 1 sprint rather than breaking the same piece of work over say 2 sprints.

Summary
I’d recommend your team try something like this, keep it organised, keep it simple, everyone is equal in the room, set ground rules, have a vision or a goal your all attempting to try to reach and have fun, the best part of the 2 days it was fun, we were discussing it all week afterwards and every single person loved it.

We covered a lot more than this but I don’t want to bore people with all the details – if you want to ask me anything about this post add a comment.

Thanks
Gregor

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:-

Summary
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

Summary
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.

Summary
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 4

Ok so we have seen in parts 1, 2, and 3 how to go about adding your database to source control, as well as comparing the schema and the data held within our SQL Server databases.

Its time to go about releasing changes made from one database to another (again think of you deploying changes from UAT to Production). There are several ways to go about releasing the changes, here are two of them:-

  • Script the schema and data changes as 2 separate scripts, which you can easily combine yourself.
  • Use Redgate SQL Packager and even create an .exe to run which will allow us to update the database.

Ok so let me demo how to go about using option two using Redgate SQL Packager which comes with the Redgate SQL Toolbelt.

Start up SQL Packager and you’ll see this start-up screen:-

packager1

I want to package an upgrade to a database so I have selected that option already, the next screen shows this:-
packager2

Above I have chosen my Database server and the database I want to use as the source and the target database (one we want to update).

Below shows the database objects I wish to package and apply on the target database.

packager3

Below shows the tables whose data I want to package and apply to the new database.

packager4

Below shows me the script that has been generated for me, first tab is the schema script, second tab is the data script and the third tab is for any warnings.

packager5

And the last screen gives us a choice to either package the change as a .exe, package it as a c# project, launch the script in SQL Query Analyser or Save the script for further inspection.

packager6

Choose option 1, run the exe and your database updates are complete, that’s all there is to it, any issues found the changes will be rolled back as they are transactional, leaving your database in tact.

Once complete, just run SQL Compare and SQL Data Compare and you can verify all is good – and viola, you’ve just updated production with schema and database changes, and you’ve been given a few different ways to do using RedGate SQL Toolbelt.

Liquidity matrix – what is it and how might it help your team?

Over the years I’ve seen a number of places of work which suffer from the following, a team member leaves or is on holiday and he or she is the go to developer, the developer that’s the only person who really knows that topic or area and as a result you have to wait for them to return, lets face it I’m pretty sure this has happened to a huge percentage of us, so here is an idea to help with this:-

So for example say we take the following as an example:-

lmatrix

From the above we can figure out that Andy doesn’t know anything about the internal and external websites, perhaps he can be brought up to speed, also Andy is the only person who knows anything about the Deployment and the PowerShell scripts, that means he’s the bottleneck or however you want to put it, other developers should be brought up to speed so that he is not the only person with knowledge in that area, if he went on holiday or left then you have a glaring problem.

You can do this same will skills and this is much more common I have found, and yeah not everyone is keen to admit to not knowing much about a certain area but just reassure them that this is not what this matrix is for.

Maybe some of you will find this useful, hopefully it doesn’t show that your team rely on some people, and its good to share knowledge within your teams.