Pluralsight Author Summit '15

I had the opportunity to go to the Pluralsight Author Summit in Salt Lake City, UT this past weekend. And it was an amazing experience. I wanted to let the experience settle a bit before I tried to write about it. The best parts of the event for me were really about the company, the authors, and the conversations.

The Company
Pluralsight as a company is dedicated to learning. This is not changing, and I don't see it changing in the future. The company has grown incredibly since I first got involved as an author (which was in May 2013). In less than 2 years, they have acquired several other companies, and the library has grown from around 400 courses to around 4000 courses.

With most companies, there would be a concern that a company cannot maintain its culture and core values with growth of that nature. But Pluralsight has managed to do this.

Here's a taste of that:


And this isn't corporate propaganda. I saw these values in the eyes of every employee that I talked to over the weekend. This is what they truly believe.

This goes all the way to the top. Two of the company founders stepped out of their "C" level roles because they were concerned that they would hold the company back. They stepped into roles that allowed them to continue to guide the company, but in different ways. That's the kind of dedication to values that I would like to see spread to other companies -- people focused on doing what's best to drive the vision forward and not just what's best for "me".

In addition, they talked about how each acquisition fits in to the overall goal of the company. This is not "buying out competitors", this is about finding companies with excellent content or tools that fit in well with furthering the Pluralsight mission. This is a strategic process focused on improving learning.

On a personal level, this makes Pluralsight a company that I want to be more involved with.

The Authors
Pluralsight has amazing authors. I don't know that I have ever been in such a large group where everyone is so passionate about what they are doing. I spent the weekend surrounded by people who knew their technologies and were dedicated to sharing that knowledge in the most effective way possible.

And everyone is incredibly open to sharing what they've learned about creating good courses. Some people were sharing tips on how to get the best audio recordings. Other people were talking about how to save time editing.

One author (Michael Perry) wowed everyone with a tool he created to make his own editing and recording process easier. He was soliciting input and has made the software available to other authors.

"Watch My Course"
Creating a course for Pluralsight is a lot of work. And a big reason for that is that the authors are fanatical about getting the best content with the best demos with the best audio with the best visuals all edited together in the best package. And this is why authors are always saying "watch my course". They aren't saying this because they are hoping to get more royalties; they say this because each and every one of them thinks that they have created something of high value (and they have). And they want to share that with as many people as possible.

And now's my chance to say "Watch my courses" ;-) http://www.pluralsight.com/author/jeremy-clark

The Conversations
I had direct conversations with close to 50 authors this weekend (yes, I was trying to keep track of who I met and talked to). There were tons of opportunities for casual and directed conversations, whether during sessions, at meals, at evening activities, and in the hallways. I met a lot of new people, and I got to catch up with folks I haven't seen for a while. I'm looking forward to continuing the conversations in the future.

Sometimes you meet people you already "know". I sat down and started talking to someone, and he told a joke about introvert developers. And I said, "Did you leave that on my blog?" (Comment on "Becoming a Social Developer: A Guide for Introverts"). He said, "Yes", and then we were instantly friends. (BTW, it was Steve Ognibene. Even though the comment has a fairly generic user name, it tracks back to both his blog and Twitter account.)

Open Space
There were 6 time slots dedicated to open space conversations. This is a format where the people pick topics that are important to them (or they think are important to others), they pitch the topic, and then people show up for great conversations. For more info, check Wikipedia for the Guiding Principles (and 1 Law).

The result was a lot of great sessions. Some were "Here's how I was successful with X"; others were "I have no idea how to do this, so let's get together and talk about ideas". Excellent discussions with people who have lots of good ideas. And there were folks from Pluralsight in each and every session, offering suggestions and thinking about ways Pluralsight can incorporate these great ideas.

Here's a photo of a session that I proposed and hosted:

Incredible minds in this room. Great ideas. Brilliant discussion. #AuthorSummit15 #openspaces @pluralsight pic.twitter.com/oJnuS8rP0J
— Megan Russell (@megbruss) March 1, 2015

I was simply the host for the discussion (I was at the front to write down ideas and try to make sure that everyone had a chance to speak). As Megan notes, it was a brilliant discussion. There were about 50 people in the room, and I'm amazed at how open everyone was -- willing to ask questions, sharing experience, and coming up with new ideas.

The conversations from this and other sessions continued through the weekend (and some of them are still going). These sessions were just the seeds to get things started.

Still More
I would be remiss not to talk about the formal content as well. Nancy Duarte did a keynote that was amazingly inspiring. You can get a taste of it from a TED talk that she did several years ago. Nancy shared how great presenters create something that resonates with the listeners/viewers. And this is something that we (as people who produce technical content) can bring to our own courses. Lots of great ideas.

The best part is that these are just small examples of the focus of the entire summit: how can we make things better for the learners.

I know this sounds like an ad for Pluralsight. But it's really hard not to sound like that. I've seen the dedication of the company itself; I've seen the values of the employees; I've seen the passion of the authors. After spending several days in this environment, it's inevitable that you want to be involved in it further.

Happy Learning!

Are You an Over-Abstractor or an Under-Abstractor?

I really like to teach people about different techniques of abstraction. If you don't believe me, just check my website: Interfaces, Dependency Injection, Design Patterns, and even the BackgroundWorker Component (and also my courses on Pluralsight).

One of the reasons that I talk about these particular topics is that they are things that took me a really long time to understand myself, so I like to help people take a short-cut to understanding. But that leads to a problem. Once we learn about them, we might want to use them everywhere, and we end up building a complex mess that's hard to maintain.

But over-abstraction is not our only problem. If we have too little abstraction, then our applications can be rigid and hard to maintain. So as developers, our goal is to find the sweet spot right in the middle. This is why I came up with "Abstract Art: Getting Things 'Just Right'" (which I give as a live presentation and as a course on Pluralsight). We're really looking to follow the Goldilocks Principle when it comes to abstraction: not too much, not too little, but "just right".

The Goldilocks Principle (from the presentation slides)

Observing Developers
So why do we, as developers, have a problem getting abstraction right? There are a number of factors, but the biggest one has to do with our natural tendencies. I'm not sure if anyone has done an official study on this, but I formed this opinion based on my observations of developers that I've worked with (and also by reflecting on myself).

The premise is that every developer has a default state as either an over-abstractor or an under-abstractor. Over-abstractors like to build stuff and think about all the possible uses of an application in the future. This may lead to overly complex implementations for features that will probably never get used. Under-abstractors like to keep things simple. This may lead to things like global variables, tightly-coupled components, and "god classes" with all sorts of functionality.

This is just our "default state" -- meaning, without any external influences, we lean one way or the other. But as we gain experience as developers, we run into difficulties with our default state and so we go in the other direction. This often results in us swinging too far, and we end up correcting back the other way.

The Pendulum Effect (from the Pluralsight course)

Eventually, we figure out the dangers of both over-abstraction and under-abstraction through trial-and-error. The main reason I wrote my presentation and Pluralsight course is to give people some best practices so they can skip some of these bad experiences.

One Group is Not Better Than the Other
The first time I gave this presentation, I ran into a bit of a problem: one of the attendees thought that I was promoting one group over the other -- for example saying that under-abstraction is better than over-abstraction. And that is definitely *not* the case.

Both groups have problems. With too much abstraction, we end up with code that is overly-complex, difficult to debug, and can cause frustration in people who are not intimately familiar with the code (which may include the original developer 6 months later). Ultimately, the code is difficult to maintain.

With too little abstraction, we end up with code that is rigid. It is hard to find bugs and very difficult to test. Ultimately, the code is difficult to maintain.

So we have a common result: code that is difficult to maintain. What we need to do is figure out how to recognize our natural tendency so that we can watch for the warning signs and hopefully end up with abstractions that are "just right" for our application.

Do You Meet More Over-Abstractors or Under-Abstractors?
In my presentations, I would love to do an informal survey to see if the developers identify themselves as over-abstractors or under-abstractors. But because I want to be careful not to create "teams" in the room, I don't do that.

I've been curious if there are more over-abstractors or under-abstractors in our field (or if there's an even split). I've been able to make the case of both groups.

The Case for Over-Abstractors
The main reason I would think that there are more over-abstractors in our field is that what we do is all about problem solving. We are developers because we like to come up with creative solutions and then implement those solutions by building things.

And a big part of that is the building. We don't want to use code that someone else wrote; we want to write it ourselves. This is often referred to as the "not invented here" syndrome.

Another part of this is that we like to plan for the future. Sure, we could build a robot that fetches a soda from the refrigerator. But wouldn't it be cooler if the robot would also vacuum as it goes? (Yeah, I know, we already have a vacuum cleaner that works well, but it will still be cool.) This is a fairly common mindset that we see in developers -- we are creative people.

Based on this, I might think that there are more over-abstractors in our industry.

The Case for Under-Abstractors
The main reason that I  would think there are more under-abstractors in our field is that there are a lot of developers who do not understand abstraction or what it is good for. As a young developer, I had a lot of trouble understanding why I would want to use interfaces in my code. I could tell they were important, but I couldn't find the right person to explain it to me. (This is one of the main reasons that I like to talk about Interfaces -- I don't want developers to go through the same struggle that I did.)

I come across a lot of developers who are like I was: they do not understand the basics of abstraction. I meet some of these developers when I'm helping them with their code; I meet some of these developers at my presentations. And my goal is to give them a better understanding of the topic while I have a chance to talk to them.

Based on this, I might think that there are more under-abstractors in our industry.

Any Ideas?
So, what are your thoughts? How do you identify yourself? Do you have more over-abstractors or under-abstractors where you work? What about the developers you meet at conferences or other events?

If you're not sure where you fall, you can check out the "Default State Quiz" that's part of my Pluralsight course.

By nature, I am an under-abstractor, but I've also swung into the over-abstraction world for a while. After my many years of experience, I like to think that I'm pretty well balanced, but I still have a tendency to lean toward my "default state" from time to time.

The first step to overcoming my default state was to recognize it. Since I've done that, I can now catch the times when I'm leaning too far toward under-abstraction. This gives me a chance to review some best practices to steer myself to a more balanced state.

Feel free to leave a comment with your thoughts (or drop me a note privately). I'm interested to hear what you think about the topic.

Happy Coding!

Pluralsight Learning Path: Getting to Great with C#

Pluralsight has a lot of courses (like hundreds and hundreds). So it can be daunting to figure out where you need to start. To help get people pointed in a direction that works for them, Pluralsight has a collection of Learning Paths that highlight a set of courses to help you meet a goal -- whether you're working toward certification or want to learn to build a particular type of application.

A new learning path was published today: Getting to Great with C#.

Getting to Great with C#

• Object-Oriented Programming Fundamentals in C#
• Defensive Coding in C#
• Clean Code: Writing Code for Humans
• C# Interfaces*
• Abstract Art: Getting Things "Just Right"*
• Dependency Injection On-Ramp*
• SOLID Principles of Object Oriented Design
• Design Patterns On-Ramp*
• Design Patterns Library

Be sure to follow the link (here it is again)  to get the details on the goals of the learning path and descriptions of all the courses.

The really cool part: I authored 4 of these courses (marked with *). I've had courses included in other learning paths, but I'm excited and honored to have so many of my courses included in a single collection (plus, I know the other authors and courses, and I'm in very good company).

Happy Coding!

New Pluralsight Course: Abstract Art: Getting Things "Just Right"

I'm happy to announce that my latest Pluralsight course has just been published: Abstract Art: Getting Things "Just Right" (Pluralsight link).

I've been talking and writing about this topic for quite a while, so I was glad for the chance to put everything down in one place. I'm a big fan of the proper use of abstraction. When we use it correctly, it can make our applications easier to extend, maintain, and test.

And many of the techniques of abstraction took me a long time to grab on to when I was a young programmer. To save other developers from having to go through that struggle, I often talk about Interfaces, Design Patterns, and Dependency Injection.

And used properly, these things are really awesome. But we can also take things too far. If we have too much abstraction in our code, then things get pretty awful. Our code can become overly complex, confusing to navigate, and difficult to debug.

Our goal is to find the balance. Part of this is to look at ourselves and see what our natural tendencies are. Does your nature lean toward over-abstraction? Does your nature lean toward under-abstraction? Once we recognize this, we can use it to our advantage to avoid the danger areas.

And the course is full of practical advice. There is no one right answer -- no particular abstraction technique that applies to every situation. So, we'll look at several principles that we can apply to our code. If we keep these in mind, then we'll be headed in the right direction.

So, let's build on the experience of this girl:


And get things "Just Right".

Happy Coding!

October 2014 Speaking Engagements

I'll be traveling a little bit in October. If you're in Silicon Valley or the Phoenix area, be sure to stop by. These events should be a lot of fun.

Thursday, October 9, 2014
South Bay .NET User Group
Mountain View, CA
Meetup Event
o Abstract Art: Getting Things "Just Right"

Saturday & Sunday, October 11 & 12, 2014
Silicon Valley Code Camp
Los Altos Hills, CA
My Sessions
o Clean Code: Homicidal Maniacs Read Code, Too!
o Learn to Love Lambdas
o Community, Career, and You: A Microsoft MVP Panel

This will be my third time going to the Silicon Valley Code Camp. It is an amazing experience. Tons of sessions on all different topics to choose from (there are about 25 sessions to choose from in each time slot). I've met a lot of great people over the last two years, and I'm looking forward to being there again this year.

Saturday, October 18, 2014
Desert Code Camp
Chandler, AZ
Code Camp Site
o Abstract Art: Getting Things "Just Right"
o Dependency Injection: A Practical Introduction
o Learn to Love Lambdas

Desert Code Camp is one of my favorite events (I know, I'm not supposed to have favorites). This will be my 9th time at this event. The Phoenix area has a great developer community, and I always have a lot of fun when I go out there. I'm looking forward to talking to some old friends and also meet a lot of new people.

Abstract Art: Getting Things "Just Right" (the movie)
You may be wondering about my latest Pluralsight course. It's currently going through the final production processes and should be released the week of October 6th.

[Update 10/06/2014: It's published! http://www.pluralsight.com/courses/abstract-art-getting-things-just-right]

In the course, we look at how abstraction is awesome and how abstraction is awful. If we have too much abstraction, then our applications are complex and hard to maintain. If we have too little abstraction, then our applications are rigid and hard to maintain. Our goal is to figure out how to get just the right amount of abstraction in our applications.

We'll do this by looking at ourselves and how our own nature as developers can get in the way of achieving this goal. And the course is chock full of practical advice -- real practices that we can use to help us get things "just right".

And of course, you can also see the live version (which is a bit condensed) at upcoming events. Hope to see you in person soon!

Happy Coding!

Upcoming Pluralsight Course -- Abstract Art: Getting Things "Just Right"

I'm happy to announce that I've just started working on a new course for Pluralsight -- Abstract Art: Getting Things "Just Right". Most of the topics that I talk about are things that took me a long time to really understand well. This is no different.

Abstraction is awesome: it can help make our applications easier to maintain, test, and extend. Abstraction is also awful: it can make our code difficult to understand, navigate, and debug. And there's the problem. If we have too little, our applications can be rigid and difficult to maintain. If we have too much, our applications can be confusing and difficult to maintain. We need to find just the right amount of abstraction for a particular application and environment.

Why is it so hard to get abstraction "just right"? Because it goes against our nature as developers. We have natural tendencies that put us into one of two groups: under-abstractors and over-abstractors. Under-abstractors tend to shy away from abstractions: "We'll just hard-code this and copy/paste that, and it will be fine." Over-abstractors tend to add more abstraction than is actually useful: "We'd better put in these 3 layers and add a plug-in architecture because we might need them later." And even though no one likes to identify with either of these categories, we need to admit to who we are deep down.

The good news is that we can overcome our natural tendencies to find the right balance for our applications. And that's what this course is all about. We'll take a look at some of the mistakes and missteps I've made in building applications over the years, how there's a tendency to over-correct when adjusting our approach, and how I worked with another developer to come up with really good techniques to find the right balance.

There will be lots of practical advice and guidance to help us along the path getting abstraction "just right".

So, stay tuned for progress reports, and let me know if you have any suggestions on things you'd like to see.

Happy Coding!

Dependency Injection Questions

A friend of mine recently watched my Dependency Injection On-Ramp course on Pluralsight and sent me a few questions. In my experience, if one person has a question, there are probably other people with the same question. So, here are the questions and answers.

Note: these same questions/answers apply to my live presentation: Dependency Injection: A Practical Introduction.

Interfaces vs. Abstract Classes

Q: I see that interfaces are used with DI. Is there a reason abstract classes aren't used? Just wondering.

In the example, we create a repository interface so that we can add a layer of abstraction. Then we use constructor injection to get the repository into our view model class. Here's that code:

With this code, our view model does not need to know anything about the concrete repository types (so we can eliminate the coupling between the view model and those repositories). But there is nothing about Dependency Injection that limits us to using interfaces. In fact, in another part of the example, we inject a concrete class into our view:

Here we are injecting a concrete view model (MainWindowViewModel) into our view (MainWindow). For this, we do not get the same loose-coupling as we do with the repository example above. But Dependency Injection here still gives us some good advantages, namely adhering to the separation of concerns (SoC) and single responsibility principle (SRP). These principles often go hand in hand.

In this case, even though we need a compile time reference to the view model class, we have still freed the view from the responsibility of creating and managing the lifetime of the view model object. This means that creating the view model is not the responsibility of the view (separation of concerns) and the view can concentrate on what it does best -- providing the user interface for the application (it's single responsibility).

I guess I haven't answered the question yet (well, I've sort of answered it).

A: We can use whatever abstractions we like with Dependency Injection.

The type of abstraction is completely separate from dependency injection itself. That means we can use interfaces, abstract classes, or base classes. To make the decision, we'll just look at the pros and cons of using these types just like we do in our other code.

Specifically, interfaces are good where we do not have any shared code in the implementations (thus, no duplication). We can implement as many interfaces as we want, so we are not limited by single inheritance when we apply interfaces. And we're free to descend from another class if we want.

Abstract classes are good where we have shared code in the implementations. This lets us put the shared code into the abstract class and all of the child classes can use it (thus, no duplication). We are limited by single inheritance, so we cannot descend from an abstract class and another class at the same time.

If you want more information on how to make a decision between interfaces and abstract classes, you can check out my C# Interfaces course on Pluralsight, or reference the materials for my live presentation: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces.

Client Applications vs. Server Applications

Q: All of your examples are with a client app. Can this be used server side, too? I'm assuming yes.

In the examples, we use Dependency Injection to break the coupling between the layers in a WPF (desktop client) application. Specifically, we break the coupling between our view model (presentation) and repository (data access) so that we can more easily extend and test our application.

And we can get these same benefits server-side as well. So, the answer is...

A: Yes, of course.

Another of my presentations uses an ASP.NET MVC project as an example: Shields Up! Defensive Coding in C#.

This example has a custom controller factory that uses Ninject. Here's that code:

The details aren't all that important here. What we're doing is creating a custom ASP.NET MVC controller factory. This class uses Ninject to inject the repositories for the objects in our application. This allows us to easily swap out the repository (similar to our WPF example above).

For this particular example, I'm showing the dangers of SQL injection. So I have a SQL repository that is vulnerable to SQL injection and another repository that uses parameterized SQL (and thus, is not vulnerable to this specific attack). Using the IRepository abstraction along with Ninject allows me to swap this out very quickly in my demo.

Okay, so you're probably saying that isn't a "real" server application (although, the code is running on the IIS server, not the client machine). So, here's another example. This is taken from a lab for an upcoming Education Day (more info on this soon).

This is an application that is designed to run inside an automated job. It loads a file, parses the data, and outputs any errors to a log file. In this case, we want to isolate the data parsing code to make it easier to unit test. So instead of having a logger hard-coded in the parser, we use constructor injection:

This lets us use the file logger when we're running this in production on our server, but it's easy to swap out the logger for a mock during our unit testing. (In fact, this particular lab is all about how to make code easier to test.)

So we can get the benefits from Dependency Injection (extensibility, testability, maintainability, late binding, parallel development) whether we are working with client applications or server-side code.

More Advanced Ninject

Q: How would you use the CachingRepository decorator with a container such as Ninject?

In the example code, we start out pretty simply: we manually wire our application pieces together in the composition root of our application. Here's the example using the repository that uses a WCF SOAP service:

This is pretty straight forward since we're using constructor injection all the way down. We create a repository, pass it to the view model, and then pass the view model to the view.

Using a container eliminates some of these steps. Rather than wiring everything together, we just create a binding between the abstraction (IPersonRepository) and the concrete type (PersonServiceRepository):

So we tell Ninject that if someone asks for an IPersonRepository, we want to return a PersonServiceRepository (and the InSingletonScope means we only want one of these that gets re-used throughout our application). We let the dependency injection container (Ninject) take care of figuring everything else out.

But in the example, we also created this really cool caching repository. This wraps any existing repository and adds a client-side cache to it. This was pretty easy to wire up manually:

We start with our concrete repository (PersonServiceRepository), pass that to our caching repository, then pass that to our view model, then pass that to our view. We just snap the pieces together in a different order.

But what about using a container? We can't just associate the IPersonRepository with the CachingPersonRepository because it also needs an IPersonRepository as a parameter. It seems like we'd end up in an endless loop.

A: Ninject (and other DI containers) provide lots of advanced features to handle complex situations.

When we configure our container, we just need to supply a little more information:

The first part of the configuration is the same (Bind...To...InSingletonScope), but then we add some further instructions. In this case, we specify that the CachingPersonRepository has a constructor parameter called "personRepository". When Ninject comes across this parameter, it should supply a PersonServiceRepository.

This has the same effect as our manual code: it takes a PersonServiceRepository and wraps it in the caching repository.

What this shows is that it pays to spend some time with a particular DI container. Learn the ins-and-outs of what is available. There are tons of options.

Wrap Up
Dependency Injection is still one of my favorite topics. It's a powerful tool that can give us some good advantages in many situations. Like every tool, it is not appropriate everywhere. But if we understand what it is good for, then we can make sure we use it in the right situations.

I'm always open to answering questions about the topics that I speak about. There is no such thing as a stupid question. This is how we learn.

Happy Coding!

1000 Ratings for C# Interfaces

My C# Interfaces course on Pluralsight hit a milestone today: 1000 ratings:

Thanks to everyone who took the time to watch the course and rate it. Be sure to check out my other courses as well: http://pluralsight.com/training/Authors/Details/jeremy-clark

Happy Coding!

Jeremy's Screencast Production: Hardware, Software, and Process

Several people have asked about the screencast setup that I use for Pluralsight and YouTube: software, hardware, process. Just so I don't have to write the same email again, I'm going to put everything here. I've been using the same tools for the last 6 months or so, so I've had a chance to "dial in" what works for me.

Let's take a look at what I do and the tools I use. I'm not getting any kick-backs from the product vendors, and I'll provide Amazon links for the hardware just because it's easy (no kick-backs from Amazon, either).

Software
We'll start by looking at the software that I use and what I like about it.

Screen Capture
For screen capture, I use Camtasia Recorder 8 (which is part of Camtasia Studio from TechSmith). They have both a Windows and a Mac version. I use the Windows version, so I'll only speak to that.

Here's a screenshot of Camtasia Recorder:

Camtasia Recorder for screen capture and Camtasia Studio for editing go hand-in-hand. The features that are available in Recorder wouldn't be very useful to other video editing applications. You can see that there are options to determine which parts of the screen you will capture as well as whether you're capturing the webcam and audio.

[Note: I've since found out that some people crack open the .camrec file that is generated by Camtasia Recorder and use the individual elements with different editing tools.]

In addition, the audio options allow you to capture system sounds (or not), and the cursor is captured separately so that you can edit it later. All very useful.

I haven't used the webcam recording in a released video (yet). You can thank me later for not having to look at me.

Video Editing
As mentioned above, I use Camtasia Studio for editing. My needs are pretty simple, so I haven't found that I really wanted something that wasn't there (other than "automatically fix the audio" which I'll talk about below).

Here's a screenshot (which looks better on a big monitor with lots of stuff showing/zoomed in):

I won't go over all the features of Camtasia; you can learn about that from the website. But there are a few things that I really like and I use frequently.

As mentioned in the "Screen Capture" section, Camtasia Recorder captures the mouse as a separate object. This means that we can remove it or add effects during the editing process:

I don't generally do too much with the cursor. Primarily, I uncheck the "Mouse cursor visible" option during the slide portions of my videos. I really like that I don't have to think about this during recording, and I can easily fix it during editing.

You can also add "click" effects so that there is a visual change when the mouse is clicked. I don't generally use these, but I see how it could be very useful in a product tutorial where you're showing someone how to use an application.

I also spend quite a bit of time with the Audio tab:

I don't use the processing options (like the volume leveling or noise removal); I don't really have the problems that these options solve. But I do use the "Silence" button quite a bit as well as the "Volume down" button. I'll talk more about these when I go through the production process.

Finally, I really like the Callouts that are available:

I frequently use the "Spotlight" option (which is shown here). And I also use the arrows quite a bit. These are really useful for drawing the viewer's eye to just the right thing on the screen. I've also done a bit of animation with the arrows (to move an arrow around the screen to point to different things). But I usually don't get too complex with my video effects.

And there are lots of other features available as well, including zooming, scene transitions, and narration.

Video Rendering
Camtasia also offers quite a few options when rendering video. You can render to various formats, different bitrates and resolutions, and you can also add a watermark to the video during the rendering process (this is how I get the Pluralsight logo in the bottom right corner of those videos).

Camtasia will also let you do batch rendering of multiple projects. This is really good for something like Pluralsight where I usually have 7 to 10 separate clips that make up a module.

Hardware
Here's a picture of my "studio":

As you can see, things are pretty simple. The piece of hardware that makes the biggest difference to the quality of the screencast is the microphone.

Microphone
I use the RØde Podcaster microphone along with a swing arm and shock mount (Amazon link). This is a USB mic that plugs straight into my laptop, and I'll have to say that this is the best purchase that I've ever made. To demonstrate the difference that good audio makes, compare the following videos:

Laptop mic: C# Properties
Podcaster: Anatomy of a Lambda Expression

Now you might say that I should have used a headset mic instead of the built-in laptop mic, but it turned out that the mic built in to my MacBook Air was actually better quality that the Logitech headset that I had. Either way, the Podcaster is way ahead of the other options.

I also know a lot of screencasters who use the Blue Yeti (Amazon link) and are happy with the results. Again, you'll probably also want a swing arm (for convenience) and a shock mount to isolate the microphone from vibrations from the keyboard. You may also want a pop filter (the Podcaster has an integrated pop filter which works pretty well).

Swing Arm / Work Table
The microphone is attached to a table that is 40 inches tall. This is a good height for me. And because the microphone is mounted on a swing arm, I have the option of recording standing up or sitting down (on a barstool). Being able to change positions is especially welcome when doing all-day recording sessions.

The swing arm is also good because I can simply move the microphone out of the way when it comes time to edit. With my setup, I can move the microphone so that it sits behind the monitor.

Shuttle Control
My newest piece of hardware is a shuttle control. I have the ShuttlePRO V.2 from Contour Design (Amazon link). I've only used this on one video so far (C# Generics Part 1), but this has made a *huge* difference. One of my biggest frustrations in editing was getting exactly the right frame (especially when trying to adjust audio or edit portions of video). The mouse is too fiddly, and the keyboard behaves inconsistently depending on what has focus. The shuttle control eliminates that frustration.

[Update: I've used this shuttle control to edit about a dozen videos now. It's a lifesaver for navigating through the timeline.]

I picked this one based on a blog entry from Scott Hanselman (Human Computer Interaction Diversity - 7 Devices that AREN'T a mouse and keyboard). He points out that Tod created a Camtasia profile for this device (Camtasia Studio and the ShuttlePro V2). I'm sure that I'll be customizing the buttons for the things that work for me, but I've found these settings to be a really good starting point.

[Update 03/03/2014: It turns out that Tod is Tod Gentille, another Pluralsight author, and I got to meet him at the Pluralsight Author's Summit this weekend. He's a great guy, and I was happy to be able to thank him in person for creating these settings.]

Laptop
This stuff plugs into a 13" MacBook Air that's a couple years old (i7-2667M and 4GB RAM). I haven't had any problems with video capture, audio capture, or performance -- no stuttering or other craziness. One big advantage of this laptop is the SSD; I've been told that having an SSD (opposed to a spinning hard drive) makes a huge difference in overall editing and rendering experience.

Rendering is acceptable. I generally record and output at 1024x768, and rendering times are about 1 to 1 (meaning 1 minute of video takes about 1 minute to render). The CPUs max out during rendering, so make sure your computer is well-ventilated during this process.

Process
Finally, I'll talk about my process. This is what works for me. I have published about 20 hours of finished video over the last 6 months, and I've done a bit of tweaking of my process along the way.

Preparation
Preparing for a video takes a bit of time. This is the "creative" part of the process. And this is where I plan, create slides and put together the demo code.

I often get asked about whether I write a script. The answer is, I have a partial script. For the "slide" portion of the videos, I put together a script. I'm pretty good with live presentations, but for some reason, I trip over myself when I'm trying to talk slides during a screencast. So for this portion, I script out what I'm going to say.

For the "demo" portion of the videos, I have an outline of the points I want to hit along with any code snippets that I'm going to type. I'm really good at talking coherently while I'm coding (for some strange reason), so I don't need a full script. In addition, a full script would probably be distracting since I couldn't read from the script and type code at the same time.

Recording
It took me a while to "dial in" the settings for my microphone. I spent a bit of time playing with the recording volume settings and varying my distance from the mic. If it was too high, then I got a lot of background noise. If recording volume was too low, then I had to be really close to the mic to be picked up. I ended up with a setting of 90 and a distance of 2 inches from the microphone.

I got a really good tip from another screencaster. To help you keep a consistent distance from the microphone, attach a gauge of some sort. I have a chopstick rubber-banded to the side of  the microphone that sticks out 2 inches. This helps me keep a consistent distance during the recording process (with the Podcaster, you speak into the end of the mic). Here's a picture of that:

As far as the recording process itself, I will do separate recordings for "slides" and "demos". And for Pluralsight where I may have multiple "slide" clips in a row, I record each clip separately.

When I'm recording, I don't stop recording if I make a mistake. I simply take a breath and try the line again. For slides, this isn't too difficult. Sometimes I need to backup a slide or hit the back arrow to reset an animation, but it's pretty easy to keep going.

For demos, it gets a little trickier. Since I started with live presentations before I did screencasts, I had a tendency to point to things with the mouse. But with screencasting, I "point" to things during the editing process by adding arrows and callouts. So, I generally try to stay "hands off the mouse" as much as possible during recording. This also makes it easier to do clean edits when I'm fixing mistakes.

Now, I'm pretty fortunate: I can talk and type at the same time. So, I record the audio and demo all at once. I do make mistakes (a lot). I'm often backing up to a previous point in the code to try a line again. If you don't let the mistakes frustrate you, it's pretty easy to keep going. That's what editing is for; it doesn't have to be a perfect recording.

If you can't talk and type at the same time, you can always add narration later on during the editing process. I know of a couple of screencasters who do this.

Editing
I spend the bulk of my time in editing. In order to try to streamline the process, I've adapted to making 3 editing passes.

Pass #1: Cut To Length
The first pass is cutting out all of the mistakes. This step takes a long time as I go through and cut out the "dead air" when I pause to get the right words, and also when I need to cut out the mistakes. I find that I cut out about 30% of the raw footage during this pass.

For example, the C# Generics Part 1 video was a little over 25 minutes of raw footage that I cut down to 14 minutes of completed video. For my Dependency Injection On-Ramp course for Pluralsight, I had 3 hours 48 minutes of raw video that was cut down to 2 hours and 37 minutes of final footage. I've found that this is pretty consistent, and I can estimate the final video length based on the raw footage. (This is all based on my recording quirks and mistakes, of course.)

Pass #2: Audio Adjustment
I would love to have a "fix audio" button. Like I said, I spent a bit of time dialing in the settings for my microphone to get the cleanest recording that I can, but I still need to do some audio editing.

I don't get any background noise in my setup, but I do have smacking noises that come from my lips and gums. This is generally when I open my mouth to start a phrase. I still haven't figured out what causes this, and I've tried a few different things (wet mouth, dry mouth), and a friend of mine even sent me an interesting link about it: http://filmsound.org/QA/mouthclick.htm.

I've learned to see these extraneous noises in the audio waveform, and I can select and silence them pretty easily. I'll also remove breathing sounds, but I don't need to do this very often. After enough experience recording, I find myself turning my head away from the mic if I need to take a big breath.

I don't have much of a problem with "pops" (hard "P" or "H" sounds). As mentioned above, the Podcaster has a built-in pop filter, and that works pretty well. I get an occasional "pop", and these are easy to fix by locating the sound (usually just 1 frame) and then clicking the "Volume down" button about 5 times. These are fairly rare in my recordings, though.

I have tried the noise removal tools in Camtasia, but they don't seem to pick up the noises that I'm concerned about. And if I change the settings so that they do get picked up, then it alters the rest of the audio as well. So for the time being, I'm sticking with the manual process even though it's a bit more work.

The reason the "Audio Adjustment" pass is separate from the "Cut To Length" pass is that I found I was spending time fixing audio on segments that I later cut out. That was a waste of time. And I also found that it was easier for me to concentrate on one thing at a time.

Pass #3: Video Effects
The last step of the process is adding the video effects. This includes simple things like transitions between "slides" and "demo" and also adding the callouts and animation. This is usually the easiest and fastest editing pass because I generally don't add effects to "slide" portions, and I limit my effects during "demo" portions to highlighting important elements.

Rendering
Rendering is pretty straight-forward. As mentioned above, my laptop renders at about a 1 to 1 ratio. And I have the common rendering settings saved in Camtasia. So, this step is usually just hitting the "Produce and share" button, picking the saved setting, and choosing an output location.

Rendering with Camtasia has been rock-solid. But I will give you a warning if you output to WMV files (which I do): Windows Media Player has a problem playing WMVs (yikes!). So, when you're watching the output in Media Player, you may see "smearing" of the cursor or multiple pointers on the screen at the same time. But don't worry, if you view the video with another player (like VLC) or upload it to YouTube, it will look just fine.

Wrap Up
I've actually been wanting to do screencasts for quite a while. I'm glad that I finally started in earnest last year. I'm hoping to fill up my YouTube channel with lots of good stuff this year (and I'll have some new Pluralsight courses as well).

So, now you know how I produce a screencast. These are the things that work for me. Hopefully, you'll be able to use some of these tips in your own productions.

Happy Coding!

New Pluralsight Course: Introduction to Localization and Globalization in .NET

My latest course is now available on Pluralsight: Introduction to Localization and Globalization in .NET.

Introduction to Localization and Globalization in .NET

We create the best experience for our users by communicating with them in a way that they understand. .NET provides robust localization and globalization features that allow us to create and deploy applications that adapt for different languages and cultures. We'll take a look at the basics and ready our applications to take on the world.

This course is all about how to prepare our applications to support different languages and cultures. We talk about the fundamentals of culture and the built-in .NET support including thread culture, localizable resource files, and satellite assemblies. A big part of the course is to take an existing application, prepare it for localization, and then apply different languages and cultures.

The world is getting smaller and smaller. Localization is not a complex topic, but it is a topic that many developers never think about. And there are a few "gotchas" out there the first time you localize an application. And if we think about localization while we're designing our application (rather than tacking it on when we're "done"), we'll have a much easier experience in getting localized resources and globalized formats into the app.

Thanks to My Translators
I want to give a big thanks to my translators. They were nice enough to provide me with translations of the strings that I needed for my application. And they haven't asked for anything in return (at least not yet).

Tomas Petricek

Mathias Brandewinder

Filip Ekberg

Volkan Uzun

Tomas Petricek did the Czech localizations. He is the author of Real-World Functional Programming, and he is a Microsoft MVP for Visual F#. Visit him at http://tomasp.net/ and on Twitter @tomaspetricek.

Mathias Brandewinder did the French localizations. He speaks around the world on functional programming and machine learning, and he is also a Microsoft MVP for Visual F#. Visit him at http://www.clear-lines.com/blog/ and on Twitter @brandewinder.

Filip Ekberg did the Swedish localizations. He is author of C# Smorgasbord as well as a Pluralsight author and Microsoft MVP for Visual C#. Visit him at http://blog.filipekberg.se/ and on Twitter @fekberg

Volkan Uzun did the Turkish localizations. He works in the application security world and does wonders with integrating custom auth providers into SharePoint.

More Courses to Come
I've still got a couple more courses in the hopper. Right now, I'm working on Defensive Programming in C#. Look for this course to come out later this month.

Until then, be sure to check out Introduction to Localization and Globalization in .NET, and get ready to take on the world!

Happy Coding!

New Pluralsight Course: Practical Reflection in .NET

My latest course is now available on Pluralsight: Practical Reflection in .NET.

Practical Reflection in .NET

Reflection is an extremely powerful feature of .NET. But there is a big difference between what we can do and what we should do. We'll take a quick look at what reflection is capable of and then narrow our focus to practical uses: balancing flexibility, safety, and performance.

When I first saw reflection, I thought it was really cool (and a bit scary, too). And at the time, I didn't think that I would ever use it in my own applications. It really looked like a tool for people who build developer tools or have an extremely specialized situation. But I was wrong.

Reflection is useful for everyday developers, too. Now, it's true that I only use a very small subset of features that reflection offers, but that's probably a good thing. Reflection has some drawbacks -- primarily speed and safety, so we probably want to limit how much we use anyway.

Real World Reflection
I showed a bit of reflection in the C# Interfaces course. In the Dynamic Loading section, we loaded an assembly based on configuration information, and then created an instance of a type. This is reflection. I skipped over the details of reflection since we were focusing on interfaces.

In the latest course, we take a closer look at the reflection parts of this sample so that we can really understand what's going on. This includes looking at the assembly-qualified names that we used in the configuration file, as well as the Type class that loads a type based on that, and the Activator class that we used to create an instance of that type.

Adding Flexibility
Another example shows how we can dynamically load assemblies from the file system and pick out the types that we want. Why would we ever want to do this? Well, the scenario is a rules engine that allows our clients to create their own custom business rules by simply building classes that implement a particular interface. Then they can drop the resulting assemblies into a particular folder that the application picks up automatically. This allows for greater flexibility of our application.

And this technique can be expanded beyond this scenario as well.

Uh-Oh
The last section of the course covers that scarier parts of reflection. It turns out that nothing in our assemblies is secret. If someone has the assembly, he can look at all of our variables, strings, classes, and functions -- even if they are marked "private". But we shouldn't panic about this, we just need to keep it in mind when we're writing our applications.

There are several techniques that we can use to make sure that our confidential information stays confidential. If you want to learn more about these techniques, be sure to watch the course ;-)

Wrap Up
Pluralsight offers tons of great training courses, and they've been expanding immensely over the last year. Pluralsight offers a 10-day free trial that gives you 200 minutes to use however you like. I've also got some free trials that offer 1 week of unlimited usage. So, drop me an email if you're interested.

This is my 5th published course, and I'm working hard on my next one. I've had a lot of fun producing these, and I love to hear from people who have found them valuable (and also from people who have some suggestions -- I'm always trying to make things better).

Happy Coding!

Shameless Promotion

Three of my Pluralsight courses are currently in the Top 100 as of 10/28/2013 (subject to change):

(I guess there's not much love for the BackgroundWorker Component.) You can see all of my courses in one spot on my author page.

I have more courses coming. If you have topics you'd like to see me cover, feel free to leave a comment. As mentioned before, the topics I select are based on several factors including (1) whether I know anything about the topic (this one is kind of important) and (2) whether Pluralsight already has a course covering the topic.

Pluralsight has over 1,000 courses with a ton of great content. Check the Course Library for some really good resources.

Happy Coding!

New Pluralsight Course: Dependency Injection On-Ramp

My latest course is now available on Pluralsight: Dependency Injection On-Ramp.

Dependency Injection On-Ramp

What is Dependency Injection? The answers to the question seem to cause more confusion than help. This course will get us started on the road to understanding. We'll take an example-based approach to see the problems caused by tightly-coupled code. We'll add Dependency Injection to trade that tight-coupling for loose-coupling. And that loose-coupling makes our applications much easier to extend, maintain, and test. Finally, we'll see how Dependency Injection Containers can provide benefits that would be difficult to implement ourselves. This just scratches the surface. Once we're done, we'll be ready to start our journey on the Dependency Injection superhighway.

I've really enjoyed presenting on Dependency Injection over the last year -- I've given my live presentation 12 times since October 2012.

One of the reasons I really like this topic is because I've found it extremely useful in my own development. It took me a while to get the hang of it and to see the usefulness. But once it clicked (the "a-ha" moment (no, not that "a-ha" moment (but that's a good one, too (I miss the '80s)))), it's hard to imagine building complex applications any other way.

My goal is to give a short-cut to that "a-ha" moment. We can't cover everything we need to know about Dependency Injection in such a short time, but we can get a good understanding of the basic concepts and, more importantly, see real code that shows why we may want to use it in our own applications.

This may be my best course yet. Check it out and let me know what you think.

Happy Coding!

New Pluralsight Course: Design Patterns On-Ramp

My latest course is now available on Pluralight: Design Patterns On-Ramp.

Design Patterns On-Ramp

You already use Design Patterns but probably don't know it. In this course, we'll take a look at several everyday programming scenarios that are implementations of Design Patterns. Once we start to recognize patterns, we're well on our way to using them effectively. Our goals are to get comfortable with the basic concepts, to see how they are useful, and to discover that design patterns are relevant to all programmers, not just architects and system designers. When we're done, you'll be ready to explore the rich and wonderful world of Design Patterns.

This is a great way to get started with Design Patterns. Plus, you get to learn a little about me, including my video game habits and the kind of music I listen to.

I'm currently working on my next course: Dependency Injection On-Ramp. And I'm still looking for topics for future courses.

Enjoy the new course, and I'd love to hear your feedback.

Happy Coding!

More Cool Stuff

So, my C# Interfaces course on Pluralsight did really well in its first month. Since it was in the Top 10 for the month of July, I was awarded the Pluralsight Crystal Microphone.

The thing that makes this really cool is knowing how many people have watched my C# Interfaces course and have been able to learn from it. It's great to be able to reach so many people that I'll never be able to meet in person (although I would like to -- if you see me at an event, be sure to let me know if you've watched one of my courses).

Happy Coding!

More Pluralsight Courses Coming - What Topics Do You Want to See?

I've recently published 2 Pluralsight courses: one on C# Interfaces and one on the BackgroundWorker Component (also check my Pluralsight author page).

I'm working on more courses over the coming months. Currently in progress: Design Patterns On-Ramp. The goal of this course is to get comfortable with Design Patterns and see that we already use patterns everyday even if we don't realize it. This is a gentle introduction to get you ready for a deeper dive into the topic.

Be sure to check back; I'll post more information once this course is published.

What Topics Do You Want to See?
I have several slots to fill in my schedule. So what topics would you like to see me put into a Pluralsight course? Leave your suggestions in the comments, and I'll take them under consideration. In addition to a topic, try to include a specific angle. For example: "Design Patterns for the everyday developer".

I'm not an expert in everything, and topics that I speak and write about are technologies or principles that I've worked with in production code. In addition, the Pluralsight library is quite extensive; many topics are already covered. So don't be surprised if your topic is not selected; it's nothing personal.

I'm looking forward to hearing your suggestions.

Happy Coding!

New Pluralsight Course: Introduction to the .NET BackgroundWorker Component

I'm happy to announce that my new Pluralsight course is now available: Introduction to the .NET BackgroundWorker Component.

The BackgroundWorker component is one of my favorite little tools. It does a great job of keeping the UI responsive by moving a long-running process onto another thread. It also includes progress reporting, cancellation support, and error handling -- all in an easy-to-use package.

Introduction to the .NET BackgroundWorker Component

Keep your UI responsive. If we're not careful, a long-running process will cause our application to "lock up". The BackgroundWorker component gives us an easy-to-use solution by moving that long-running process off of our UI thread. We'll see how the BackgroundWorker component can keep our WinForms, WPF, or Silverlight UI responsive and also explore features such as progress reporting, cancellation, and error handling. After that, we'll see how easily the BackgroundWorker component fits in with an application using the Model-View-ViewModel (MVVM) pattern. And finally, we'll compare the BackgroundWorker component to the Task Parallel Library to make sure we're using the right tool for the job.

After watching this (short) course, you will know everything there is to know about the BackgroundWorker component (yes, it really is that simple). Here are the modules:

• BackgroundWorker Overview
  Here, we take a look at the problem the BackgroundWorker solves: a non-responsive UI due to a long-running process. Then we see the basics of using the BackgroundWorker component in a WinForms application and in a WPF application.
• Progress, Cancellation, and Error Handling
  We take a deeper dive into the features including progress reporting, cancellation, and error handling. We see that the component handles communication between the threads for us, so we don't need to worry about those details.
• BackgroundWorker and MVVM
  How does the BackgroundWorker component fit in with an application that uses the Model-View-ViewModel (MVVM) design pattern? Very well, actually. MVVM applications have the same potential issue (a long-running process that locks up the UI), so we can use the same solution: the BackgroundWorker component.
• BackgroundWorker vs. Task
  Finally, we replicate the BackgroundWorker component functionality using the Task Parallel Library (TPL). What we find is that all of the functionality is there, but sometimes it's easier to use a specific-purpose tool (the BackgroundWorker) than a general-purpose tool (the TPL).

Lots of great info all in one place. Be sure to check it out: Introduction to the .NET BackgroundWorker Component.

Happy Coding!

I Didn't Expect That

My C# Interfaces course launched on Pluralsight last week.  The interest in the course has been much higher than I expected.  And today, it's showing up at the top of the leaderboard (at least for now):

You can see the live list here: Pluralsight Top 100 Leaderboard.

Helping Developers
The most exciting part of this is how many people are getting benefits from my course. For those of you who've seen me speak in person, you know that I really love to share information with other developers.  What really drives me forward is when I get an email from a dev who tells me that he/she was able to make use of something learned from one of my presentations.  It's also great to get an email from someone on the other side of the world who was able to use one of my articles.

I'm focused on helping developers take a step up.  So, it's very cool to be able to reach so many developers through a single source.

I'm available to help you.  If you're looking for training (single day, multi-day, or ongoing) or for someone to speak at an event such as a "Lunch & Learn", user group, or developer conference, contact me through my website.

Check It Out
If you haven't taken a look at Pluralsight, spend a little time and look through their catalog.  There are hundreds of courses on all different technologies.  If you just browse the categories, you'll see a huge variety to choose from.

Everyone learns best in different ways.  Books are my preferred way of learning.  But some people like blog articles, some people like trial-and-error experimentation, some people like videos, some people like live demos, and some people like one-on-one training.  If you are a "video" or "live demo" person, Pluralsight is a great resource.  They offer a 10 day free trial, and this gives you a chance to check out the quality of the courses for yourself.

More to Come
I'm currently working on my next course about one of my favorite things: the BackgroundWorker Component.  It's a great little tool that's easy to work with.  And even though some people say that it's no longer necessary, it definitely still has its place.

So, stay tuned.  There's definitely more to come.

Happy Coding!

New Pluralsight Course: C# Interfaces

As mentioned about six weeks ago, I've been working on a course for Pluralsight.  I'm happy to announce that the course is now available.

C# Interfaces

Do you want code that's maintainable, extensible, and easily testable?  If so, then C# interfaces are here to help. In this course, we’ll take a look at how we can use interfaces effectively in our code. We'll start at the beginning ("What are interfaces?") and then explore why we want to use them. Along the way we'll create and implement own interfaces, see how to explicitly implement interfaces, and take a look at dynamic loading, unit testing, and dependency injection. All of which is made possible with interfaces.

Check out the course for yourself at Pluralsight: C# Interfaces.

Happy Coding!

Coming Soon: Jeremy on Pluralsight

I am happy to announce that I've been commissioned to produce a course for Pluralsight (http://www.pluralsight.com).

If you're not familiar with Pluralsight, be sure to check it out.  They offer high-quality video training by experts in the field.  There's a 10-day free trial so you can get a taste for what it's like.  And they have a number of free courses, including "Teaching Kids Programming with C#" by Lynn Langit and Llewellyn Falco.

My first experience with Pluralsight was when I needed to get up to speed on ASP.NET MVC (way back in the version 1 days).  Their course gave me exactly what I was looking for: I came away with a good understanding of the technology and its capabilities.  It turned out that my particular scenario fit the technology perfectly, and I went on to create a mobile-friendly web application with ASP.NET MVC.

That was several years ago.  Since then, the catalog has been constantly expanding.  There's lots of good stuff to check out.

And don't worry, I'll be sure to announce when my first course is available.

Happy Coding!