Category: Productivity

May24202024 May 202024 May 20201Commentby Gregor Suttie

PowerToys

Posted in PowerToys, Productivity

If you haven’t heard of or used PowerToys then this blog post is for you.

Microsoft PowerToys is a set of utilities for power users to tune and streamline their Windows experience for greater productivity. Inspired by the Windows 95 era PowerToys project, this reboot provides power users with ways to squeeze more efficiency out of the Windows 10 shell and customize it for individual workflows.

To get up to speed with PowerToys then check out my YouTube video below.

You can find the source code for PowerToys here: – https://github.com/microsoft/PowerToys

I hope you find PowerToys useful.


Apr28202028 April 202028 April 20201Commentby Gregor Suttie

What have I been up to since I was furloughed?

Posted in Productivity, Training

So April 2020 has been an interesting month for me personally, the project I was doing at work got paused due to the customer not being able to support remote working, work had nothing in the pipeline for me to do so I got furloughed, wow talk about being kicked in the nuts, but rather than complain, let’s use this opportunity to learn.

Thank you to everyone who has reached out to me, they know who they are and it’s hugely appreciated.

If you know me then you know that I am always learning, always setting myself goals for the months ahead and so I decided to not write blog posts or produce content for the time I’m furloughed and spend it learning. If I had to write down everything I wanted to learn and read about it would turn into a book itself.

So that being said I wanted to learn containers and GitHub Actions as the first 2 port of calls and fit in some extra community work in between that.

I have probably done more community work this month than in the past 3 or 4 combined and it been amazing – being able to work from home and just get on a call with folk wanting to learn something or getting on a call to help someone figure out an issue has been very sweet. Being able to moderate Michael Crump’s Twitch stream has been super cool, twitch is something I think has a very bright future.

Working from home (albeit not actually working) is amazing, its so much more productive than working in an office or out on-site at a customer.

The following is a list of just a few of the things I’ve accomplished this month, it doesn’t cover the hours, the calls, the number of times I had to change the schedule fo the gav event – would I change what I did if I had the month over – nope!.

  • Global Azure Virtual 2020 – One of the organisers, website creation, speaker sign-ups, chasing people for content, updating the schedule. Also a moderator on the 3 day which was the Live Stream (9 hours).
  • Moderator and participant in Michael Trumps Twitch Streams covering Azure app config, Live Share, GitHub Actions, WSL, and other more general fun topics.
  • Spoke at the Belgium User Group – on Supercharging your Azure Learning as part of the Belgium Community Week
  • Spoke at the Boston User Group – on Supercharging your Azure Learning.
  • Time spent doing Pluralsight this month learning GitHub Actions.
  • Completed Cloudskills course on – Docker Jumpstart.
  • Microsoft Learn learning – 3 modules complete.
  • Microsoft Products Groups (10 PGI’s)
  • Mentoring several people with starting blogs, learning Hugo, exam study guides, and people looking for advice on how to become an MVP.
  • Created a DP-300 Administering Relational Databases on Microsoft Azurestudy guide: – https://gregorsuttie.com/2020/04/19/azure-dp-300-study-guide/
  • Spoke 1-1 with more a number of community people which a probably the best part of being off.

In May I plan to brush up on my SQL and PowerBI skills and looking forward to that, it’s been a few months since I touched either.

Still amazes me just how many great people I have spoken to this past month and it’s been a blast.


Jan0320173 January 20173 January 20170Commentby Gregor Suttie

New Job Role

Posted in Productivity

In November last year I was given the chance to change my job role from a developer to become the teams SRE (Site Reliability Engineer) – this meant less time coding and I had to think about this, do I really want to do this as I do love writing code.

Taking a look at the direction the world of web development was heading I had to think do I really want to give up on time coding and look for another challenge, and boy do I enjoy a new challenge.

At this time I was a .Net Developer writing C# and had been doing that for a long time, we were using AngularJS and doing the Agile thing with sprint ceremonies and what not. I really like AngularJS, writing API’s and tying it all together in our sprint work – but something just wasn’t quite right.

Like most companies and teams within companies we had some technical debt to pay back and if you know me well I do love a good moan when things aren’t how they should be.

So now I have the opportunity to fix things, and I think this is my best skill if I’m honest, finding bugs and fixing them or taking something that works and making it better – better is a matter of opinion obviously.

Moving back to my new role, it’s a devops/sre role with my own kanban board and list of stuff to work on with which itself will be mean a number of different things to get my teeth into, work for the rest of 2017 at least.

Some of the things I will get my teeth into this year include improving our build pipeline, database deployments, metrics on a number of things including builds, code quality and the like.

We have some good metrics already and I’d like to add some tools I’ve used in the past which include @OctopusDeploy and @Raygunio

At work I’m an application security champion which means I have to make sure our code is secure and passes all of the security measure in place at work which I thoroughly enjoy – so lots to get stuck into.

Heres to a productive 2017 and we shall see how far I get with some big changes ahead.


Feb27201627 February 201627 February 20161Commentby Gregor Suttie

My company’s 2 day hackathon

Posted in Events, Ideas, Productivity, Training

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


Tags:

Jan19201619 January 201619 January 20167Commentsby Gregor Suttie

Tips for Deploying your .Net project

Posted in Best Practices, Ideas, Octopus Deploy, PowerShell, Pro Tips, Productivity, TeamCity

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.


Jan12201612 January 201612 January 20162Commentsby Gregor Suttie

Continuous Deployments for SQL Server – Part 4

Posted in Continuous Deployment, Pro Tips, Productivity, RedGate, Tools

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.


Jan0420164 January 201612 January 20162Commentsby Gregor Suttie

Continuous Deployments for SQL Server – Part 2

Posted in Best Practices, Continuous Deployment, Pro Tips, Productivity, RedGate, Tools

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).
sqlcompare4

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.

sqlcompare5

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

sqlcompare6

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.


Jan0120161 January 20161 January 20160Commentby Gregor Suttie

My todo list for work in 2016

Posted in Continuous Deployment, PowerShell, Pro Tips, Productivity, RedGate, Testing

Its 2016 and I like to make a list of things I wanna look into and put into place at work so here is a list of things I am aiming to do which also includes at my job in 2016:-

  • A blog post each week, last year I only managed 11 blog posts and that’s poor, so more blog posts will come in 2016.
  • Lightning Talks, we have started doing these at work and this year I plan to do a few of them if given the chance, I’m doing one on the 6th of January on as Developers Top 10 Best Practices which I will share about once I have done my talk.
  • Test 3rd party end points, have a dashboard page which tells us what is up and what is down, going to try to use the Chrome add-on called Postman and use collections within Postman to do this.
  • Database Deployments, currently we manually script everything and then get the dba to run the scripts in manually, we need to script the database and put it into Source control each release as a starting point, I’m looking forward to this as it well help aid with our deployments and speed them up. Hoping to get the RedGate Sql Toolbelt into the company so we can use this to help us achieve this.
  • Red/Green deployments, we currently deploy at weekends and this can and should change so that we aren’t spending time at weekends doing releases which take quite a lot of time, we can automate them more and this year I plan to fix that.
  • More Testing, we are closing in on unit testing our PowerShell scripts, this will be another nice addition to the number of different areas which we are currently testing which is great.
  • Code Reviews, need to figure out a way that keeps everyone from being bored, brings benefit to the team and keeps us developers on our toes going forward.
  • Continuous Improvement, test more, more in-depth code reviews, automate more, release finished work, tackle the back log each sprint.

That’s it for now, I will add to this lost throughout the year as we go, i will keep an eye on this post and how we get on and blog about each one individually, hopefully I’ll get the chance to work on some if not all of these this year.

Feel free to follow me on twitter at @gsuttie


Aug28201528 August 201528 August 20151Commentby Gregor Suttie

Coding Guidleines – how do you do yours?

Posted in Productivity

StyleCopLogoHaving looked at different code bases this past 3 weeks, one thing springs to mind, if you use StyleCop use it in a way where all projects are consistent, no point having only a few rules if the code base can compile but look entirely different project to project, be much nicer for a new start to open up 3 or 4 solutions and they all look fairly similar in layout, same naming conventions etc.

What I am getting it really is if you have coding standards how do you enforce them?, oh such a strong words brings terror to co-workers opinions on writing code, but with a little bit of discipline you may be surprised when you look at someone else’s project and the code looks very similar to yours as they are sharing the teams ReSharper and StyleCop settings.

Here is a list of a few things which I think can improve code quality

  • Remove all use of regions
  • If you have coding guidelines – use tools to enforce them otherwise what’s the point
  • Put Using statements in alphabetical order at the top of the file
  • Naming conventions for your code/test projects – check these in code reviews.

So does your company have coding standards?, and if so how do you go about implementing them?, are they enforced? if not why not? – no need to piss developers off, in time they should see the light and you can shape your StyleCop rules etc. to fit.

I still bet out in the wild many teams have a coding standards guide yet they don’t enforce it other than the odd glance if your lucky.


Jan0120131 January 20131 January 20130Commentby Gregor Suttie

Book Review: C# Smorgasbord by Filip Ekberg

Posted in Book Reviews, Dependency Injection, Productivity, TDD, Testing, Tools, Training

smorgasbord

Book Review: C# Smorgasbord by Filip Ekberg

About the Author:
Filip is a Software Engineer working with various techniques such as C#, WPF, WCF, ASP.NET MVC, ASP.NET and much more. Currently working at Star Republic in Sweden as a Software Engineer working with both newer and older technologies in a Windows environment, mainly focusing on ASP.NET MVC development.

During his years of Programming, Filip has managed to accomplish some of the following:
• Software Engineering Degree @ Blekinge Institute of Technology
• Managing the Software Development Company SmartIT eSolutions Sweden which focused mainly on developing software and web solutions.
• Working as an Amanuensis ( Teacher ) @ Blekinge Institute of Technology teaching Java, C++, Sql and Network-programming.

You can read more on his blog here.

I saw a tweet from @daniellangnet who said this book was fantastic and if your looking for something to read over the holidays then give this a go, I actually ordered the book without even reading anything about it, unusual but glad i did!

Chapter 1: Introduction to Parallel Extensions :- Learn the basics of paralleization, use basic Linq, and how to optimize code by introducing parallelization.
Chapter 2: Productivity and Quality with Unit Testing :- Understand why tests are import, create a test project and improve code quality.
Chapter 3: Is upgrading your code a productive step? :- How to find bugs faster, How to use Resharper to get a more manageable project and to get things done faster.
Chapter 4: Creating a challenge out of the trivial tasks :- Challenge yourself to create understandable and higher quality software.
Chapter 5: Asynchronous programming with async and await :- Identify where yo might need asynchronous processing, refactor a synchronous app into becoming more responsive.
Chapter 6: Dynamic program :- Create and extend a dynamic object by using the ExpandObject, also understand why introducing dynamic objects might cause problems long-term.
Chapter 7: Increase readability with anonymous types and methods :identify where you might have single purpose methods that you can replace with anonymous methods for increased readability and lucidity.
Chapter 8: Exploring Reflection :- User reflection to get information about types at runtime and understand more about properties and methods.
Chapter 9: Creating things at runtime :- Create your own method at runtime using Reflection, be able to read IL and understand portions of it.
Chapter 10: Introducing Roslyn :- Create a basic code analysis that suggest issues in your code, run code snippets on entire code files.
Chapter 11: Adapting to Inversion of Control :- Understand the basics of Inversion of Control, introduce a Dependency Injector into your application.
Chapter 12: Are you Mocking me? :- Create a mock of any interface and write tests that introduce

This book as you can see has something for everyone, i have thoroughly enjoyed reading it from cover to cover and will be reading a good few of the chapters again, it’s a very handy reference book and covers a number of topics that as a developer can help you explore, improve and be inspired – just as it says on the front cover.

I picked this book up on Amazon for £19 and its well worth it – recommended reading for 2013.