Tag: speaking

  • Why I Practice Presentations

    I had a new presentation to give this week at IT/DevConnections. This is a paid for conference, and I want to be well prepared and ready for the events. It’s the least I can do for people who have spent money to attend an event.

    I enjoy IT/DevConnections, and it’s probably my favorite US event. Others are good, and SQL Bits is amazing, but I enjoy the variety of topics and speakers at this one, so if you want to try something different, think about this event next year. I hope I’ll be speaking again, and I’m planning on submitting. I believe the event is mid-October 2017, if you want to plan.

    However, I digress. In this case, I was delivering a presentation that I had never publicly presented before. I began speaking, and as usual, I started walking around a bit. I was on slide 7 when the projector went out. I assumed there was an A/V issue, and since I’d already asked someone to get a tech for my microphone feedback, I covered by continuing on with the items on my slide from memory.

    A few minutes later I walked back to the podium to see this:

    Blue-Screen-of-Death-Windows-10-600x344

    The system was actually at 25% in my case, but moving slowly.

    That’s a presenter’s nightmare. I had SSMS running, with multiple queries set up, a few Explorer windows, a VS session, and more. I knew it would take my system at least 5 minutes to restart and get ready.

    The only think I can do is proceed. Fortunately, I’d practiced this talk a few times and could remember what was on the next few slides. I’d be stuck at getting to a demo until things were running, but I could talk.

    I don’t like doing presenting new sessions at the PASS Summit, SQL Bits, or any paid event. I prefer to practice at a user group or SQL Saturday. Sorry, but user groups usually get unpolished, semi-rehearsed sessions. In this case, I hadn’t been able to get this one done before a user group session, so I was stuck practicing on my own.

    Here was my prep, most of these sessions about 1-2 hours:

    • Thur (12  days to presentation) – Outline of talk done, most slides done, demos sketched but not all working. Practice the talk twice, fixing slides and flow.
    • Friday (11 days to presentation) – only working on demos. setup, run, correct items.
    • Saturday (10 days to presentation) – practice demos on laptop (first time on this machine). Fix some issues.
    • Sun – Wed – Speaking at another event, different talks, prep for these talks and practicing them.
    • Thur (5 days to presentation) – Walk through demos on plane flight home. Build up/tear down multiple times on a VM to test the code.
    • Friday (4 days to presentation) – Walk through entire presentation, including demos. Apart from interruptions, goes fairly well.
    • Sunday (2 days to presentation) – refine some demos and slides that don’t seem clear. The flow has been a little off, so I move a couple demos around to separate the concepts.

    Monday (1 day to presentation) – Quick run through before leaving for the airport. Land in Vegas, check in, go through 2nd presentation as a quick reminder from 5-7. Hit the gym at 7. Dinner around 8:30. Final run-through of new talk from 9:30-11.

    Tuesday (day of presentation) – Up early, flipping through entire slide deck, practice opening, but not running code. Double check that all items have been removed and cleaned from the instance. Realize I have 60, note 74 minutes. Make a couple mental notes about what to cut when I’m live.

    A lot of prep for this talk, which I may or may not do again. I had some good feedback from people and a packed room. Quite a few people said they learned a lot and we had a lively discussion.

    Note: my timing was poor for two reasons. One was that I had assumed all my talks were 75 minutes, but this one was 60. My fault, no excuse for not checking. Two, because I hadn’t delivered this before, I had no idea what questions to expect, and how the discussions might go. I let the session get slightly interrupted because I was answering questions. I was unsure I had explained things well, so I chose to answer items.

    My apologies for those that might not have enjoyed the session, and certainly for a couple code items. I must not have cleaned something appropriately as I had a couple errors. Also, I didn’t run all samples because of time, so perhaps I broke something else.

    In any case, next week will be a bit of review of the talk. I have some notes, but I’ll go back through code and try to ensure everything runs correctly and upload corrections.

    Presenting is hard, and I work at it to ensure people enjoy the talks. I think it’s worth the time, but it is an effort. In this case, I was glad I had made that effort.

    And, for the record, after the Meet the Speakers event on Tuesday, I went to the gym at 6:30 for an hour and then reviewed the presentation for Wednesday, despite the fact I’d delivered a similar talk the week before.

    Be Prepared. That’s the motto I try to stick to.

  • Back for a Day

    I hope everyone is well in Florida, but the hurricane caused a postponement of SQL Saturday Orlando. Fortunately I caught the note early enough on Wednesday and spent about an hour at lunch cancelling travel plans and moving my flight from DC to Orlando to Denver to an early DC to Denver flight on Thursday.

    That worked out well, as I delivered my session just before lunch, raced to the airport and made a flight out to Denver, arriving in time to get down to watch my daughter’s volleyball match. I even only missed 9 points.

    Now ‘I’m sad in that I won’t make the 10th SQL Saturday in Orlando, but I am happy to have a day back in my life to catch up on a few things.

  • Bringing Database Devops to DevConnections

    Another alliteration post. Maybe I’ll make all my titles tongue twisters to test your talents?

    This is my new favorite session. I’m slated to deliver this at a few different conferences this fall, and hopefully you’ll come see it in Las Vegas at DevConnections on Oct 10-13.

    The talk is called Bringing DevOps to the Database, and this presentation is designed to show how many of the software development processes that we take for granted with .NET, Java, and other front end applications can be applied to the database. I’ll cover how version control, Continuous Integration (CI), and Release Management (RM) can be applied to database changes.

    This has been a focus of mine as an evangelist for Redgate Software, and I’ve found a number of ways that you can adopt common, best practice software engineering in the database development process. I’ll show how Redgate makes this easy, but I cover the process in a tool independent way. You’ll learn what needs to happen. How you get that working is up to you, but if help is needed, Redgate can cover that part.

    If you’re looking for some training, some inspiration, and are a full-stack developer, or multi-technology IT worker, think about coming out to DevConnections. There are a slew of technologies being covered (VS, ASP.NET, C#7, Azure, PowerShell, AWS, SQL Server, Sharepoint, Exchange, Hyper-V and more).

    Register today, use 500SPKR to save $500, and I’ll see you in Las Vegas this October.

  • Bringing DevOps to the Database

    Abstract:

    DevOps is a hot topic in today’s software development world. However most of the knowledge and experience with DevOps is based around application software and ignores the database. We will examine how the concepts and principles of DevOps can be applied to database development by looking at both automated comparison analysis as well as migration script management. Automated building, testing, and deployment of database changes will be shown.

    Level: 200 – Not to technical, but you should have some idea of how software development works to get something out of this talk.

    Goals:

    1. Conceptually understand how DevOps principles can easily be applied to the database in either state based or migrations based changes.
    2. Learn how databases can be automatically built and tested in a CI/CD environment
    3. Understand how database releases can be automated, but are different than those deployment/releases made for other software.

    Demos:

    This presentation has a few demos where I show how I stored database code in a VCS, perform an automated build, and use a scripted release process to move code from one database to the next. The demos are pre-built, so I just show how they work. I can do this with:

    • git, VSTS Build and VSTS Release
    • git or SVN, Team City, and Octopus Deploy

    Downloads:

    There are a few versions, as this talk has evolved.

    GroupBy – Bringing DevOps to the Database Groupby.pptx

    Live!360/VSLive – VSLive-Orlando 2016.pptx

    SQL Saturday Cambridge – Bringing DevOps to the Database.pptx