Sending Outlook Invites

Sun, November 11, 2012, 05:18 PM under Communication

Sending an Outlook invite for a meeting (also referred to as S+ in Microsoft) is a simple thing to get right if you just run the quick mental check below, which is driven by visual cues in the Outlook UI.

image

I know that some folks don’t do this often or are new to Outlook, so if you know one of those folks share this blog post with them and if they read nothing else ask them to read step 7.image

  1. Add on the To line the folks that you want to be at the meeting.
  2. Indicate optional invitees. Click on the “To” button to bring up the dialog that lets you move folks to be Optional (you can also do this from the Scheduling Assistant).
  3. Set the Reminder according to the attendee that has to travel the most. 5 minutes is the minimum.
  4. Use the Response Options and uncheck the "Request Response" if your event is going ahead regardless of who can make it or not, i.e. if everyone is optional. Don’t force every recipient to make an extra click, instead make the extra click yourself - you are the organizer.image
  5. Add a good subject
    1. Make the subject such that just by reading it folks know what the meeting is about. Examples, e.g. "Review…", "Finalize…", "XYZ sync up"
    2. If this is only between two people and what is commonly referred to as a one to one, the subject would be something like "MyName/YourName 1:1"
    3. Write the subject in such a way that when the recipient sees this on their calendar among all the other items, they know what this meeting is about without having to see location, recipients, or any other information about the invite.
  6. Add a location, typically a meeting room.
    1. If recipients are from different buildings, schedule it where the folks that are doing the other folks a favor live. Otherwise schedule it wherever the least amount of people will have to travel. If you send me an invite to come to your building, and there is more of us than you, you are silently sending me the message that you are doing me a favor so if you don’t want to do that, include a note of why this is in your building, e.g. "Sorry we are slammed with back to back meetings today so hope you can come over to our building".
    2. If this is in someone's office, the location would be something like "Moth's office (7/666)" where in parenthesis you see the office location.
    3. If some folks are remote in another building/country, or if you know you picked a time which wasn't free for everyone, add an Online option (click the Lync Meeting button).
  7. Add a date and time.
    1. This MUST be at a time that is showing on the recipients’ calendar as FREE or at worst TENTATIVE. You can check that on the Scheduling Assistant.
    2. The reality is that this is not always possible, so in that case you MUST say something about it in the Invite Body, e.g. "Sorry I can see X has a conflict, but I cannot find a better slot", or "With so many of us there are some conflicts and I cannot find a better slot so hope this works", or "Apologies but due to Y we must have this meeting at this time and I know there are some conflicts, hope you can make it anyway". When you do that, I better not be able to find a better slot myself for all of us, and of course when you do that you have implicitly designated the Busy folks as optional.
  8. Finally, the body of the invite.
    1. This has the agenda of the meeting and if applicable the courtesy apologies due to messing up steps 6 & 7.
    2. This should not be the introduction to the meeting, in other words the recipients should not be surprised when they see the invite and go to the body to read it. Notifying them of the meeting takes place via separate email where you explain the purpose and give them a heads up that you'll be sending an invite. That separate email is also your chance to attach documents, don’t do that as part of the invite.
    3. TIP: If you have sent mail about the meeting, you can then go to your sent folder to select the message and click the "Meeting" button (Ctrl+Alt+R). This will populate the body with the necessary background, auto select the mandatory and optional attendees as per the TO/CC line, and have a subject that may be good enough already (or you can tweak it).

Long to write, but very quick to remember and enforce since most of it is common sense and the checklist is driven of the visual cues in the UI you use to send the invite.


How I Record Screencasts

Thu, November 8, 2012, 11:51 AM under AboutPresenting

I get this asked a lot so here is my brain dump on the topic.

What

A screencast is just a demo that you present to yourself while recording the screen. As such, my advice for clearing your screen for demo purposes and setting up Visual Studio still applies here (adjusting for the fact I wrote those blog posts when I was running Vista and VS2008, not Windows 8 and VS2012).

To see examples of screencasts, watch any of my screencasts on channel9.

Why

  1. If you are a technical presenter, think of when you get best reactions from a developer audience in your sessions: when you are doing demos, of course. Imagine if you could package those alone and share them with folks to watch over and over?
  2. If you have ever gone through a tutorial trying to recreate steps to explore a feature, think how much more helpful it would be if you could watch a video and follow along.
  3. Think of how many folks you "touch" with a conference presentation, and how many more you can reach with an online shorter recording of the demo. If you invest so much of your time for the first type of activity, isn't the second type of activity also worth an investment?
  4. Fact: If you are able to record a screencast of a demo, you will be much better prepared to deliver it in person. In fact lately I will force myself to make a screencast of any demo I need to present live at an upcoming event.
  5. It is also a great backup - if for whatever reason something fails (software, network, etc) during an attempt of a live demo, you can just play the recorded video for the live audience.

There are other reasons (e.g. internal sharing of the latest implemented feature) but the context above is the one within which I create most of my screencasts.

Software & Hardware

I use Camtasia from Tech Smith, version 7.1.1. Microsoft has a variety of options for capturing the screen to video, but I have been using this software for so long now that I have not invested time to explore alternatives…

I also use whatever cheapo headset is near me, but sometimes I get some complaints from some folks about the audio so now I try to remember to use "the good headset". I do not use a web camera as I am not a huge fan of PIP.

Preparation

First you have to know your technology and demo. Once you think you know it, write down the outline and major steps of the demo. Keep it short 5-20 minutes max. I break that rule sometimes but try not to. The longer the video is the more chances that people will not have the patience to sit through it and the larger the download wmv file ends up being.

Run your demo a few times, timing yourself each time to ensure that you have the planned timing correct, but also to make sure that you are comfortable with what you are going to demo. Unlike with a live audience, there is no live reaction/feedback to steer you, so it can be a bit unnerving at first. It can also lead you to babble too much, so try extra hard to be succinct when demoing/screencasting on your own.

TIP: Before recording, hide your desktop/taskbar clock if it is showing.

Recording

To record you start the Camtasia Recorder tool

image

Configure the settings thought the menus

  • Capture menu to choose custom size or full screen. I try to use full screen and remember to lower the resolution of your screen to as low as possible, e.g. 1024x768 or 1360x768 or something like that.
  • From the Tools -> Options dialog you can choose to record audio and the volume level.
  • Effects menu I typically leave untouched but you should explore and experiment to your liking, e.g. how the mouse pointer is captured, and whether there should be a delay for the recording when you start it.

Once you've configured these settings, typically you just launch this tool and hit the F9 key to start recording.

TIP: As you record, if you ever start to "lose your way" hit F9 again to pause recording, regroup your thoughts and flow, and then hit F9 again to resume.

Finally, hit F10 to stop recording. At that point the video starts playing for you in the recorder. imageThis is where you can preview the video to see that you are happy with it before saving. If you are happy, hit the Save As menu to choose where you want to save the video.

 

 

TIP: If you've really lost your way to the extent where you'll need to do some editing, hit F10 to stop recording, save the video and then record some more - you'll be able to stitch the videos together later and this will make it easier for you to delete the parts where you messed up.

TIP: Before you commit to recording the whole demo, every time you should record 5 seconds and preview them to ensure that you are capturing the screen the way you want to and that your audio is still correctly configured and at the right level. Trust me, you do not want to be recording 15 minutes only to find out that you messed up on the configuration somewhere.

Editing

To edit the video you launch another Camtasia app, the Camtasia Studio.

image

  1. File->New Project. File->Save Project and choose location.
  2. File->Import Media and choose the video(s) you saved earlier.
  3. These adds them to the area at the top/middle but not at the timeline at the bottom.
  4. Right click on the video and choose Add to timeline. It will prompt you for the Editing dimensions and I always choose Recording Dimensions.
  5. Do whatever edits you want to do for this video, then add the next video if you have one to stitch and repeat.

In terms of edits there are many options. The simplest is to do nothing, which is the option I did when I first starting doing these in 2006. Nowadays, I typically cut out pieces that I don't like and also lower/mute the audio in other areas and also speed up the video in some areas. A full tutorial on how to do this is beyond the scope of this blog post, but your starting point is to select portions on the timeline and then open the Edit menu at the very top (tip: the context menu doesn't have all options). You can spend hours editing a recording, so don’t lose track of time!

When you are done editing, save again, and you are now ready to Produce.

Producing

Production is specific to where you will publish. I've only ever published on channel9, so for that I do the following

  1. File -> Produce and share. This opens a wizard dialog
  2. In the dropdown choose Custom production settings
  3. Hit Next and then choose WMV
  4. Hit Next and keep the default of Camtasia Studio Best Quality and File Size (recommended)
  5. Hit Next and choose Editing dimensions video size
  6. Hit Next, hit Options and you get a dialog. Enter a Title for the project tab and then on the author tab enter the Creator and Homepage. Hit OK
  7. Hit Next. Hit Next again.
  8. Enter a video file name in the Production name textbox and then hit Finish.
  9. Now do other stuff while you wait for the video to be produced and you hear it playing.

After the video is produced watch it to ensure it was produced correctly (e.g. sometimes you get mouse issues) and then you are ready for publishing it.

Publishing

Follow the instructions of the place where you are going to publish. If you are MSFT internal and want to choose channel9 then contact those folks so they can share their instructions (if you don't know who they are ping me and I'll connect you but they are easy to find in the GAL). For me this involves using a tool to point to the video, choosing a file name (again), choosing an image from the video to display when it is not playing, choosing what output formats I want, and then later on a webpage adding tags, adding a description, and adding a title.

That’s all folks, have fun!


Link instead of Attaching

Tue, October 30, 2012, 09:37 PM under Communication

With email storage not being an issue in many companies (I think I currently have 25GB of storage on my email account, I don’t even think about storage), this encourages bad behaviors such as liberally attaching office documents to emails instead of sharing a link to the document in SharePoint or SkyDrive or some file share etc.

Attaching a file admittedly has its usage scenarios too, but it should not be the default. I thought I'd list the reasons why sharing a link can be better than attaching files directly.

In no particular order:

  1. Better Review. It allows multiple recipients to review the file and their comments are aggregated into a single document. The alternative is everyone having to detach the document, add their comments, then send back to you, and then you have to collate. With the alternative, you also potentially miss out on recipients reading comments from other recipients.
  2. Always up to date. The attachment becomes a fork instead of an always up to date document. For example, you send the email on Thursday, I only open it on Tuesday: between those days you could have made updates that now I am missing because you decided to share an attachment instead of a link.
  3. Better bookmarking. When I need to find that document you shared, you are forcing me to search through my email (I may not even be running outlook), instead of opening the link which I have bookmarked in my browser or my collection of links in my OneNote or from the recent/pinned links of the office app on my task bar, etc.
  4. Can control access. If someone accidentally or naively forwards your link to someone outside your group/org who you’d prefer not to have access to it, the location of the document can be protected with specific access control.
  5. Can add more recipients. If someone adds people to the email thread in outlook, your attachment doesn't get re-attached - instead, the person added is left without the attachment unless someone remembers to re-attach it. If it was a link, they are immediately caught up without further actions.
  6. Enable Discovery. If you put it on a share, I may be able to discover other cool stuff that lives alongside that document.
  7. Save on storage. So this doesn't apply to me given my opening statement, but if in your company you do have such limitations, attaching files eats up storage on all recipients accounts and will also get "lost" when those people archive email (and lose completely at some point if they follow the company retention policy).

Like I said, attachments do have their place, but they should be an explicit choice for explicit reasons rather than the default.


Visual Studio Continued Excitement

Sun, September 23, 2012, 10:45 PM under Personal | VisualStudio

As you know Visual Studio 2012 RTM’d and then became available in August (Soma’s blog posts told you that here and here), and the VS2012 launch was earlier this month (Soma also told you that here). Every time a release of Visual Studio takes place I am very excited, since this has been my development tool of choice for almost my entire career (from many years before I joined Microsoft). I am doubly excited with this release since it is the second version of Visual Studio that I have worked on and contributed major features to, now that I’ve been in the developer division (DevDiv) for over 4 years.

Additionally, I am very excited about the new era that VS2012 starts with VSUpdate for continued customer value: instead of waiting for the next major version of VS to get new features, there is new infrastructure to enable friction-free updates. The first update will ship before the end of this year, and you can read more about it at Brian’s blog post. I also noticed that a CTP of the first quarterly update is available to download here.

In the last two months, the VS2012 family of products we all worked on in DevDiv shipped, coinciding with the end of the Microsoft financial/review year, and naturally followed by a couple of organizational changes (e.g. see Jason’s blog post)… On a personal level, this meant that I was very lucky to have an opportunity present itself to me that I simply could not turn down, so I grabbed it! I’ll still be working on Visual Studio, but not in the Parallel Computing part of the C++ team; instead I will be PM-leading the VS Diagnostics team… Stay tuned for details of what is coming in that space, in the VS updates and in the next major VS release, as I am able to share them…


The last word on C++ AMP...

Fri, August 31, 2012, 12:47 PM under GPGPU | ParallelComputing

Well, not the last word, but the last blog post I plan to do here on that topic.

Over the last 12 months, I have published 45 blog posts related to C++ AMP on the Parallel Programming in Native Code, and the rest of the team has published even more. Occasionally I'll link to some of them from my own blog here, but today I decided to stop doing that - so if you relied on my personal blog pointing you to C++ AMP content, it is time you subscribed to the msdn blog. I will continue to blog about other topics here of course, so stay tuned.

So, for the last time, I encourage you to read the latest two blog posts I published on the team blog bringing together essential reading material on C++ AMP

Got questions on C++ AMP? Hit the msdn forum!


Get started with C++ AMP

Tue, July 24, 2012, 11:22 PM under GPGPU | ParallelComputing

With the imminent release of Visual Studio 2012, even if you do not classify yourself as a C++ developer, C++ AMP is something you should learn so you can understand how to speed up your loops by offloading to the GPU the computation performed in the loop (assuming you have large number of iterations/data). We have many C# customers who are using C++ AMP through pinvoke, and of course many more directly from C++.

So regardless of your programming language, I hope you'll find helpful these short videos that help you get started with C++ AMP

  1. C++ AMP core API introduction... from scratch
  2. Tiling Introduction - C++ AMP
  3. Matrix Multiplication with C++ AMP
  4. GPU debugging in Visual Studio 2012

In particular the work we have done for parallel and GPU debugging in Visual Studio 2012 is market leading, so check it out!


Attend my Fusion sessions

Wed, June 6, 2012, 07:50 PM under Events | GPGPU | ParallelComputing

The inaugural Fusion conference was 1 year ago in June 2011 and I was there doing a demo in the keynote, and also presenting a breakout session. If you look at the abstract and title for that session you won't see the term "C++ AMP" in there because the technology wasn't announced and we didn't want to spill the beans ahead of the keynote, where the technology was announced. It was only an announcement, we did not give any bits out, and in fact the first bits came three months later in September 2011 with the Beta following in February 2012.

So it really feels great 1 year later, to be back at Fusion presenting two sessions on C++ AMP, demonstrating our progress from that announcement, to the Visual Studio 2012 Release Candidate that came out last week.

If you are attending Fusion (in person or virtually later), be sure to watch my two-part session. Part 1 is PT-3601 on Tuesday 4pm and part 2 is PT-3602 on Wednesday 4pm. Here is the shared abstract for both parts:

Harnessing GPU Compute with C++ AMP

C++ AMP is an open specification for taking advantage of accelerators like the GPU. In this session we will explore the C++ AMP implementation in Microsoft Visual Studio 2012. After a quick overview of the technology understanding its goals and its differentiation compared with other approaches, we will dive into the programming model and its modern C++ API. This is a code heavy, interactive, two-part session, where every part of the library will be explained. Demos will include showing off the richest parallel and GPU debugging story on the market, in the upcoming Visual Studio release.

See you there!


Attend my GTC sessions

Sun, May 13, 2012, 01:36 PM under Events | GPGPU | ParallelComputing

The last GTC conference in the US was 2 years ago and I was there as an attendee. You may recall from that blog post that we were running UX studies at the time.

It really feels great 2 years later, to be back at GTC presenting two sessions on C++ AMP, demonstrating our progress that includes input from those early studies.

If you are attending GTC (in person or virtually later), be sure to watch my two-part session. Part 1 is S0242 on Wednesday 5pm and part 2 is S0244 on Thursday 10am. Here is the shared abstract for both parts:

Harnessing GPU Compute with C++ AMP

C++ AMP is an open specification for taking advantage of accelerators like the GPU. In this session we will explore the C++ AMP implementation in Microsoft Visual Studio 11 Beta. After a quick overview of the technology understanding its goals and its differentiation compared with other approaches, we will dive into the programming model and its modern C++ API. This is a code heavy, interactive, two-part session, where every part of the library will be explained. Demos will include showing off the richest parallel and GPU debugging story on the market, in the upcoming Visual Studio release.

See you there!


Visual Studio Exceptions dialogs

Tue, May 1, 2012, 07:03 PM under VisualStudio

Previously I covered step 1 of live debugging with start and attach. Once the debugger is attached, you want to go to step 2 of live debugging, which is to break.

One way to break under the debugger is to do nothing, and just wait for an exception to occur in your code. This is true for all types of code that you debug in Visual Studio, and let's consider the following piece of C# code:

3:  static void Main()
4:  {
5:    try
6:    {
7:      int i = 0;
8:      int r = 5 / i;
9:    }
10:    catch (System.DivideByZeroException) {/*gulp. sue me.*/}
11:    System.Console.ReadLine();
12: }

If you run this under the debugger do you expect an exception on line 8? It is a trick question: you have to know whether I have configured the debugger to break when exceptions are thrown (first-chance exceptions) or only when they are unhandled. The place you do that is in the Exceptions dialog which is accessible from the Debug->Exceptions menu and on my installation looks like this:

image

Note that I have checked all CLR exceptions. I could have expanded (like shown for the C++ case in my screenshot) and selected specific exceptions. To read more about this dialog, please read the corresponding Exception Handling debugging msdn topic and all its subtopics.

So, for the code above, the debugger will break execution due to the thrown exception (exactly as if the try..catch was not there), so I see the following Exception Thrown dialog:

image

Note the following:

  1. I can hit continue (or hit break and then later continue) and the program will continue fine since I have a catch handler.
  2. If this was an unhandled exception, then that is what the dialog would say (instead of first chance exception) and continuing would crash the app.
  3. That hyperlinked text ("Open Exception Settings") opens the Exceptions dialog I described further up.
  4. The coolest thing to note is the checkbox - this is new in this latest release of Visual Studio: it is a shortcut to the checkbox in the Exceptions dialog, so you don't have to open it to change this setting for this specific exception - you can toggle that option right from this dialog.

Finally, if you try the code above on your system, you may observe a couple of differences from my screenshots. The first is that you may have an additional column of checkboxes in the Exceptions dialog. The second is that the last dialog I shared may look different to you. It all depends on the Debug->Options settings, and the two relevant settings are in this screenshot:

image

The Exception assistant is what configures the look of the UI when the debugger wants to indicate exception to you, and the Just My Code setting controls the extra column in the Exception dialog. You can read more about those options on MSDN: How to break on User-Unhandled exceptions (plus Gregg’s post) and Exception Assistant.

Before I leave you to go play with this stuff a bit more, please note that this level of debugging is now available for JavaScript too, and if you are looking at the Exceptions dialog and wondering what the "GPU Memory Access Exceptions" node is about, stay tuned on the C++ AMP blog ;-)


    

Screencasts introducing C++ AMP

Thu, April 12, 2012, 07:07 PM under GPGPU | ParallelComputing

It has been almost 2.5 years since I last recorded a screencast, and I had forgotten how time consuming they are to plan/record/edit/produce/publish, but at the same time so much fun to see the end result!

So below are links to 4 screencasts to teach you C++ AMP basics from scratch (even if you class yourself as a .NET developer you'll be able to follow).

  1. Setup code - part 1
  2. array_view, extent, index - part 2
  3. parallel_for_each - part 3
  4. accelerator - part 4

If you have comments/questions about what is shown in each video, please leave them at each video recoding. If you have generic questions about C++ AMP, please ask in the C++ AMP MSDN forum.