Category: Pro Tips

May14202114 May 202124 May 20210 Commentby Gregor Suttie

What advice would you give…

I see people on Twitter saying what advice would you give to younger people or what career advice would you give people who are just getting started in their careers.

Ok, so, I have been in the I.T. industry for 25 years, I didn’t do any Computer Science courses, etc, I am a self-taught programmer and here is my advice, yep that’s right my advice, you may disagree and that’s great, be boring if we all agreed all the time.

Ask for help, don’t be shy to ask for help always.
Ask for feedback, on all types of things, feedback is important for growth, you may not like it but you’ll learn more from negative feedback than you will from positive feedback.
Work like someone is watching you, never slack, put a shift in each and every day.
Do something you enjoy doing, at your job you will be doing it day in and day out for a long time most likely.
Find a mentor, and talk to them regularly.
Be passionate about what you do. Learn something outside your comfort zone, as often as you can, staying in your comfort zone teaches you next to nothing.
Don’t try and learn it all, no one knows it all, and neither will you.
Pick a subject area and be someone who stands out in this area.
If you are thinking about doing something and it’s a challenge, go for it, just do it, stop overthinking.
If you have a job that you don’t like – find another job.
Be honest and trustworthy and you will go a long way, no BS, leave that for others.
Thank the people who help you.
Give back when you can.
Network with like-minded people, there are lots of people out there just like you.
Work smart, not hard.
Share failures and successes, no one wins all the time, you’ll learn more from your failures.

Don’t forget to subscribe to my YouTube Channel.

Dec27201927 December 201927 December 20193 Commentsby Gregor Suttie

Failure(s) and comfort zone

Posted in Ideas, Pro Tips

I wanted to cover some of the failures I have endured during the year. It’s not something you read a lot about from people and its important to talk about failure(s). I tend to mention my success’ but its also relevant to realise that there have been a number of failures in 2019.

I sat a number of Azure exams last year and failed on more than one occasion. I learned from this that no matter how much you study and put in you wont always have a successful outcome.

I wrote numerous blog posts which were sitting in my drafts folder for a long time which will never see the light of day.

I recorded umpteen videos which I never released and I still have them on my laptop, which again will never see the light of day.

I created PowerPoint presentations which yep you guessed it wont ever be used for talks.

I started numerous books and never finished a single book, was asked to review 3 or 4 books and again didn’t get the job done.

At times throughout the year I spread myself too thin and was trying to do too much, end result was the above.

Everyone has failure’s its part of becoming a better version of you.

As I reflect on this past 12 months its clear to me that failure is a good thing. Failure has taught me that each time I fail I learn something about myself which is key if you want to improve yourself.

Commitment
I have spent the last 2 years investing in myself, I commit myself to learning new skills and gain knowledge, with this comes failure, failure in my eyes means I am doing. It’s easy to say you want to do this or that but if your not actively doing something about it then it wont ever become a reality.

I have never given up after failing an exam or throwing away a presentation or a video, I use it to motivate myself to do better then next time, I keep the content as reminders.

The trick for me is to have goals, I write my goals on a piece of paper and have that pinned above my computer monitors on the wall. Last year I failed in only one goal and then this year I knocked it out the park, I kept the paper there until I had achieved that goal and now its been replaced with a new set of goals.

Stop holding yourself back
I stopped holding myself back, I used to think I’d love to do x or do y but I never truly thought I had anything to offer.
I spoke to some people at conferences who weren’t blogging but were right into tech and I suggested they should start, I wanted to say stop holding yourself back and just do it, they know they’re stuff and weren’t sure why they hadn’t been blogging.

I watched people speak at user groups and conferences and I thought wow I’d love to do that, I did nothing about it, I was holding myself back, scared I would make a fool of myself, I might still, but I am going to be going after it and see where it takes me.

Everyone has failures, you don’t hear about them, stop holding yourself back if that’s you, if your not failing regularly then perhaps your still in your comfort zone.

Tags:Failure

Dec17201917 December 201924 May 20210 Commentby Gregor Suttie

How I had a successful 2019

Posted in Pro Tips

This year has been an amazing year for me, too many good things to recall if I’m honest and I’ll keep it short, below are some of the highlights for me (in no particular order)

Invited to meet Scott Guthrie at an ask me anything session in London
Awarded MVP in Azure in August
Helping run the Glasgow Azure User Group
Ran the Azure Global Boot Camp, Glasgow Edition
Attended my first ever Microsoft Ignite in Florida
Attended my first ever Experts Live Europe in Prague
Microsoft Certified: Azure Solutions Architect Expert
Microsoft Certified: Azure DevOps Engineer Expert
Microsoft Certified: Azure Developer Associate
Microsoft Certified: Azure Security Engineer Associate
Microsoft Certified: Azure Fundamentals
Helped work become Gold Certified in a few more competences
Blog has had over 200,000 hits this year (50 posts this year)
The Azure Advent Calendar has been a huge success, more info on that later this month.
Joined TechSnips.Io
Started a YouTube channel
Named in Nigel Frank International in the Top 20 Azure influencers on Twitter
3 podcast appearances

Looking forward to 2020 which will bring the following :-

Ignite the Tour London
Ignite the Tour Zurich
Scottish Summit (doing a talk and helping out)
Azure Global Boot camp (organising & more on that next week)
MVP Summit 2020
Ignite 2020
Hopefully lots more travelling
Hopefully attending conferences
Reach 5000 twitter followers
Recording some training material

It has been a huge amount of fun, learned more a lot about myself, visited a number of places.

My number one highlight might sound corny but meeting the people who make up the community has been incredible, Ignite and at Experts Live I met so many awesome people that I have chatted to on Twitter. I’ve met people I’ve looked up to and asked for advice from and the people who inspire me.

If you need help or have questions about anything please reach out to me on twitter or LinkedIn, always happy to help with anything I can.

I could never thank everyone but trust me I’m thankful for meeting each and every one of you.

This #azureadventcalendar has been a fantastic way to end the year and soon I’ll be at Ignite the Tour London and then the Scottish Summit here in Glasgow at the end of February.

Huge waves and thanks to everyone who I chatted to throughout 2019 and lets do it again next year.

Happy Holidays! – Gregor.

Apr21201821 April 201821 April 20180 Commentby Gregor Suttie

Global Azure Bootcamp – Glasgow April 21st 2018

Posted in Azure, Cloud Computing, Events, Logic Apps, Pluralsight, Pro Tips, Training

Saturday April 21st was the day for the Azure Global Bootcamp which say people attend user groups all around the world as you can see below, so we all spent a day as the Azure community learning all about Azure in many different ways from speakers all around the globe.

I took part and my talk was on learning Azure and becoming ready for the exams into the bargain.

As promised here are my slides:- HowToLearnAzure3

The Glasgow event was awesome and we also had Analben Mehta talking about serverless and Azure Functions and then we had Kenny Lowe talking about Azure Stack, great content and lunch and beers/soft drinks provided, all in all great to be apart of and hopefully people enjoyed they’re day.

Hope to see the people attended at the next Glasgow Azure User Group.

Jan19201619 January 201619 January 20167 Commentsby 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 20162 Commentsby 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:-

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

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.

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

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.

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.

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.

Jan0820168 January 20168 January 20160 Commentby Gregor Suttie

Lightning Talk – Top 10 Best Practices for Developers

Posted in Pro Tips

Today at work, Friday 8th January, I gave a 5 minute lightning talk at work and I chose to talk about my list of top 10 best practices for developers, being 5 minutes I hadn’t much time but here is what I talked about with a little more meat on the bone in this blog post.

Keep your kills up to date

Use video websites like Pluralsight and the like to keep your skills relevant and up to date so you’re not left behind.
Read books
Have a blog
Use twitter to keep up to date when possible, it’s a fast paced world and its difficult to keep up to date so try to make time

Share your knowledge

If you hear about or read something of interest to colleagues pass it on
Share the new technologies you’ve looked at or some code you came across which is well written.
Give demo’s to your team mates and show them why this might be something worth learning etc.

Have good personal discipline

Check your code in regularly
Keep your check-ins small, don’t wait days before committing and don’t have one big check-in with hundreds of file changes if you can help it.
Keep an eye on your build server, try not to have broken builds for days, when you check-in check your code builds on the build server, don’t be lazy.
Tidy up as you go, don’t leave files, folders, backups etc. lying around.

Take an interest

Take part in code reviews, add your thoughts and comments.
Take part in team meetings, add your voice, don’t be silent.
Know your codebase, well as much of it as you can.
Know how everything works from writing code, building it, running the tests on the build server and also how does it get deployed, don’t leave it for others to do.

Test Everything

Write unit tests.
Write Integration tests.
Write front end tests.
Write tests for your build scripts.

Automate everything where possible

Automate Builds.
Automate Tests.
Automate Deployments.
We are engineers so automate, less manual steps the better.

Read other team members code.
Read code from Github, BitBucket etc.
Learn from other developers, there are plenty of great examples out there.

Document your processes

Document your build process.
Document your servers, accounts, permissions etc.
Think of the next developer, maybe a new employee how would they benefit from your documentation.
Limit technical debt – keep on top of your technical debt each sprint for example.

Leave the code in a better place than when you found it

Clean up your codebase, remove dead code, remove unused namespaces etc.
Remove or fix Skipped Tests.
Tools like ReSharper can help you clean up code in seconds.

Feedback

Feedback good or bad is important, from colleagues, your boss, your end users/customers.
Get Feedback on your software from people who use it day in day out.
Get Feedback from your build server, how long are the builds taking, how long do tests take to run.
Feedback is golden, and the beat way to improve.

Give Back

Do a lightning talk at work.
Do a presentation or a demo at work.
Giving back can be very rewarding.
Encourage people, don’t criticise or condemn.

It was fun doing it and I look forward to doing more talks soon.

Jan0420164 January 201612 January 20161 Commentby Gregor Suttie

Continuous Deployments for SQL Server – Part 3

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

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.

Jan0420164 January 201612 January 20162 Commentsby 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).

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.

Jan0420164 January 201612 January 20161 Commentby Gregor Suttie

Continuous Deployments for SQL Server – Part 1

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

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