March was a busy month. I got to travel to Salt Lake City and Las Vegas, and I spoke all around Southern California (LA, Orange County, San Diego). I had a lot of fun, and it was great to make a bunch of new friends and talk to devs working with different tools.
April is shaping up to be pretty busy, too. I've got 3 events planned so far, and there's a couple more waiting in the wings. If you're in the area, be sure to stop by.
Saturday, April 5, 2014
Desert Code Camp
Chander, AZ
http://apr2014.desertcodecamp.com/
Topics:
o IEnumerable, ISaveable, IDon'tGetIt: Understanding .NET Interfaces
o Learn the Lingo: Design Patterns
o T, Earl Grey, Hot: Generics in .NET
The Desert Code Camp is always a lot of fun. I've been out there 6 times so far. I'm looking forward to seeing a bunch of old friends and making some new ones.
Tuesday, April 8, 2014
Inland Empire .NET User's Group
San Bernardino, CA
http://www.iedotnetug.org/sf/Index.aspx
Topic: Shields Up! Defensive Coding in C#
Thursday, April 10, 2014
EastBay .NET
Berkeley, CA
http://www.meetup.com/BayNET/events/171840062/
Topic: Shields Up! Defensive Coding in C#
Defensive Coding is all about making sure our code is robust and effective. We want to make sure that our users have the best experience possible. And this means that we need to be prepared for the unexpected and make sure that our application behaves appropriately.
Stay tuned. More items will show up as they get confirmed.
Happy Coding!
Showing posts with label Code Camp. Show all posts
Showing posts with label Code Camp. Show all posts
Monday, March 31, 2014
Sunday, November 3, 2013
November 2013 Speaking Engagement: Desert Code Camp
Desert Code Camp in Chandler, AZ is less than a week away. This will be my 6th time out there, and it is always a lot of fun.
If you can make the time, be sure to come out. There are a ton of great sessions (including mine), lots of developers to talk to, and some really good food if you can stick around for the dinner (and there's beer, too).
Saturday, November 9, 2013
Desert Code Camp
Chandler, AZ
http://nov2013.desertcodecamp.com/
I'll be presenting 3 sessions.
Learn to Love Lambdas
I really like talking about lambda expressions. It's one of the first sessions that I ever did. This time around, the sample application and presentation have been updated based on giving this presentation 15 times.
Desert Code Camp session link
Clean Code: Homicidal Maniacs Read Code, Too!
I'm still having a lot of fun with this session. At the Silicon Valley Code Camp, I had folks standing in the doorway to watch (thanks, "doorway developers"). We can all make our code more readable, and we'll look at some really easy ways of doing that.
Desert Code Camp session link
Abstract Art: Using Patterns to Solve Real Problems
This is a brand new session. Getting abstraction right is tricky. If we have too little abstraction, then our code is difficult to read and maintain. If we have too much abstraction, then our code is difficult to read and maintain. We'll help you identify which type of programmer you are, and how to overcome your natural reactions. And of course, we'll have lots of fun as well.
Desert Code Camp session link
I've got some really cheesy free giveaways, so be sure to come to at least one of my sessions if you're in the area. And if you can't make it to my sessions, be sure to stop by at some point to say hi.
Happy Coding!
If you can make the time, be sure to come out. There are a ton of great sessions (including mine), lots of developers to talk to, and some really good food if you can stick around for the dinner (and there's beer, too).
Saturday, November 9, 2013
Desert Code Camp
Chandler, AZ
http://nov2013.desertcodecamp.com/
I'll be presenting 3 sessions.
Learn to Love Lambdas
I really like talking about lambda expressions. It's one of the first sessions that I ever did. This time around, the sample application and presentation have been updated based on giving this presentation 15 times.
Desert Code Camp session link
Clean Code: Homicidal Maniacs Read Code, Too!
I'm still having a lot of fun with this session. At the Silicon Valley Code Camp, I had folks standing in the doorway to watch (thanks, "doorway developers"). We can all make our code more readable, and we'll look at some really easy ways of doing that.
Desert Code Camp session link
Abstract Art: Using Patterns to Solve Real Problems
This is a brand new session. Getting abstraction right is tricky. If we have too little abstraction, then our code is difficult to read and maintain. If we have too much abstraction, then our code is difficult to read and maintain. We'll help you identify which type of programmer you are, and how to overcome your natural reactions. And of course, we'll have lots of fun as well.
Desert Code Camp session link
I've got some really cheesy free giveaways, so be sure to come to at least one of my sessions if you're in the area. And if you can't make it to my sessions, be sure to stop by at some point to say hi.
Happy Coding!
Wednesday, April 24, 2013
Cool Stuff: Building a DSL
Code Camp is a great place to expand your thinking. Whenever I attend, I like to go to sessions on topics that I wouldn't normally seek out on my own. I've already dedicated the day to attending, so I might as well try out some new things. (I also go to meet other developers -- find out what works, what doesn't work, and what's really cool.)
This past weekend during Desert Code Camp, you may have seen "MIND BLOWN" come across my Twitter feed (and if not, then you can follow me: @jeremybytes). This came from the session "Building a DSL with an OData Source".
I didn't attend this session because I had a particular interest in the topic -- I've never worked with an OData feed, and I've always thought DSLs (Domain Specific Languages) were complicated (more on this in a bit). I attended because it was presented by a friend of mine from the dev community: Barry Stahl (blog: Cognitive Inheritance; twitter: @bsstahl). I was amazed at what I saw.
The Scenario
Barry showed how to query the OData feed from StackOverflow. StackOverflow is a good choice since pretty much every developer is familiar with the site. To query the data in its "native" state (meaning, after Visual Studio has a chance to make a service proxy based on the Atom feed), the original query looks like this:
This query gets questions that were asked in the last 30 days that have at least 1 accepted answer. There are a lot of details that you need to know to write this query. For example, "Parent == null" means that this is a root element (meaning, a question). And, "AcceptedAnswerId != null" means that there is at least one accepted answer.
The goal was to create a DSL that would save the developer from these details and make this query readable and discoverable. Like this:
This version is much easier to read and hides the details of the original API. You can get the slides and code download for this session from Barry's site: DCC 2013.1.
The Mind Blowing Realization
What was amazing about this presentation is how easy this is to implement. I had always thought of a DSL as something complex to build. This put it into the "you probably don't need to do this" category in my mind -- best left for the big brains who work on languages and compilers and that sort of thing.
But Barry showed that building a DSL can be exactly the opposite -- something easy and obvious. He used a combination of helper classes and properties along with extension methods to shield the user of the DSL from the underlying details.
For example, the "Questions" property (from the FluentStack object above) wraps the "Posts where ParentID == null" part of the original query. The other elements are similar wrappers that make the API easy to use and discoverable (through IntelliSense).
Very simple. Extremely approachable. Amazingly cool.
Wrap Up
I never would have thought of this approach on my own. I still don't know if I'll end up ever working with an OData feed. But I do know that I'll be using some of these techniques to make complex APIs easier to use.
Barry is really smart and a great presenter (plus, he's a good guy to sit around and chat with). He travels to Code Camps around the country, so be sure to look for him at an event near you.
Code Camp is a great way to expand your horizons, learn new things, and maybe even be surprised from time to time.
Happy Coding!
This past weekend during Desert Code Camp, you may have seen "MIND BLOWN" come across my Twitter feed (and if not, then you can follow me: @jeremybytes). This came from the session "Building a DSL with an OData Source".
I didn't attend this session because I had a particular interest in the topic -- I've never worked with an OData feed, and I've always thought DSLs (Domain Specific Languages) were complicated (more on this in a bit). I attended because it was presented by a friend of mine from the dev community: Barry Stahl (blog: Cognitive Inheritance; twitter: @bsstahl). I was amazed at what I saw.
The Scenario
Barry showed how to query the OData feed from StackOverflow. StackOverflow is a good choice since pretty much every developer is familiar with the site. To query the data in its "native" state (meaning, after Visual Studio has a chance to make a service proxy based on the Atom feed), the original query looks like this:
This query gets questions that were asked in the last 30 days that have at least 1 accepted answer. There are a lot of details that you need to know to write this query. For example, "Parent == null" means that this is a root element (meaning, a question). And, "AcceptedAnswerId != null" means that there is at least one accepted answer.
The goal was to create a DSL that would save the developer from these details and make this query readable and discoverable. Like this:
This version is much easier to read and hides the details of the original API. You can get the slides and code download for this session from Barry's site: DCC 2013.1.
The Mind Blowing Realization
What was amazing about this presentation is how easy this is to implement. I had always thought of a DSL as something complex to build. This put it into the "you probably don't need to do this" category in my mind -- best left for the big brains who work on languages and compilers and that sort of thing.
But Barry showed that building a DSL can be exactly the opposite -- something easy and obvious. He used a combination of helper classes and properties along with extension methods to shield the user of the DSL from the underlying details.
For example, the "Questions" property (from the FluentStack object above) wraps the "Posts where ParentID == null" part of the original query. The other elements are similar wrappers that make the API easy to use and discoverable (through IntelliSense).
Very simple. Extremely approachable. Amazingly cool.
Wrap Up
I never would have thought of this approach on my own. I still don't know if I'll end up ever working with an OData feed. But I do know that I'll be using some of these techniques to make complex APIs easier to use.
Barry is really smart and a great presenter (plus, he's a good guy to sit around and chat with). He travels to Code Camps around the country, so be sure to look for him at an event near you.
Code Camp is a great way to expand your horizons, learn new things, and maybe even be surprised from time to time.
Happy Coding!
Monday, November 5, 2012
Coming Soon: Desert Code Camp
Desert Code Camp is coming up on November 17th, 2012: http://nov2012.desertcodecamp.com/. If you are in the Phoenix area, be sure to stop by if you can (even if just for part of the day). Code Camps are a great place to meet other developers and talk about what's working and what's not. Plus, it's a full day of free training from folks in the developer community.
I've got 3 sessions scheduled:
T, Earl Grey, Hot: Generics in .NET
Dependency Injection: A Practical Introduction
IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Hope to see you there.
Happy Coding!
I've got 3 sessions scheduled:
T, Earl Grey, Hot: Generics in .NET
Dependency Injection: A Practical Introduction
IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Hope to see you there.
Happy Coding!
Thursday, October 11, 2012
Session Spotlight - Dependency Injection: A Practical Introduction
I'll be speaking at SoCal Code Camp (Los Angeles) on October 13 & 14. If you're not signed up yet, head over to the website and let them know that you're coming: http://www.socalcodecamp.com/.
Also, I've got a brand new session: Dependency Injection: A Practical Introduction
How Do We Get Started With Dependency Injection?
One of the big problems with getting started with Dependency Injection (DI) is that there are a lot of different opinions on exactly what DI is and the best ways to use it. At its core, DI is just a set of patterns for adding good abstraction to our code. The objects we create should be focused on doing one thing and doing it well. If there is functionality that is not core to the the object, then we "outsource" it to another class. This external class is a dependency (our primary object depends on this other class to provide a functional whole in our application).
Dependency Injection gives us a way to keep these external dependencies separate from our objects. Rather than the object being responsible for creating/managing the dependency, we "inject" it from the outside. This makes sure that our classes are loosely coupled which gives us good maintainability, extensibility, and testability.
In this session, I combine my personal experience using DI with the excellent information provided by Mark Seemann in Dependency Injection in .NET (I posted a review on this book a few weeks back).
DI is an enormous topic. I have picked out a few key areas (like examining tight-coupling and loose-coupling) and design patterns that will give us a good starting point for the world of DI. (As a side note, the sample code also gives a quick example of using the Model-View-ViewModel (MVVM) design pattern.)
If you can't make it out to the SoCal Code Camp, you have another chance to see this session at the Desert Code Camp (in the Phoenix, AZ area) in November. And as always, the code samples and walkthrough are posted on my website.
Hope to see you at an upcoming event.
Happy Coding!
Also, I've got a brand new session: Dependency Injection: A Practical Introduction
How Do We Get Started With Dependency Injection?
One of the big problems with getting started with Dependency Injection (DI) is that there are a lot of different opinions on exactly what DI is and the best ways to use it. At its core, DI is just a set of patterns for adding good abstraction to our code. The objects we create should be focused on doing one thing and doing it well. If there is functionality that is not core to the the object, then we "outsource" it to another class. This external class is a dependency (our primary object depends on this other class to provide a functional whole in our application).
Dependency Injection gives us a way to keep these external dependencies separate from our objects. Rather than the object being responsible for creating/managing the dependency, we "inject" it from the outside. This makes sure that our classes are loosely coupled which gives us good maintainability, extensibility, and testability.
In this session, I combine my personal experience using DI with the excellent information provided by Mark Seemann in Dependency Injection in .NET (I posted a review on this book a few weeks back).
DI is an enormous topic. I have picked out a few key areas (like examining tight-coupling and loose-coupling) and design patterns that will give us a good starting point for the world of DI. (As a side note, the sample code also gives a quick example of using the Model-View-ViewModel (MVVM) design pattern.)
If you can't make it out to the SoCal Code Camp, you have another chance to see this session at the Desert Code Camp (in the Phoenix, AZ area) in November. And as always, the code samples and walkthrough are posted on my website.
Hope to see you at an upcoming event.
Happy Coding!
Sunday, September 30, 2012
Session Spotlight - IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
I'll be speaking at So Cal Code Camp (Los Angeles) on October 13 & 14. If you're not signed up yet, head over to the website to let them know you're coming: http://www.socalcodecamp.com.
Back again: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces.
Abstraction Through Interfaces
When people talk about interfaces, they often refer to the User Interface -- the screens and controls that allow the user to interact with the application. But "interface" also refers to a very powerful abstraction that lets us add extensibility and loose coupling to our code.
My first encounter with interfaces was in Delphi (Object Pascal) as a junior developer. I understood what they were from a technical standpoint, but I didn't understand why I would want to use them. We went to the Borland conference every year; and as a new developer, I took the opportunity to absorb as much information as I could, even if I didn't understand most of it (this is also a great way to use Code Camp -- to experience technologies you haven't taken the time to look into yet). I was very excited because there was a session in Interfaces at the conference.
"Great," I thought, "I'll go and get some practical examples of how to use interfaces and find out why I would want to use them." So, I get to the session, sit down, and grab my notepad -- ready to spend the next hour getting a practical introduction.
The speaker gets up and starts the presentation. "So, let's say that we have an Foo class. And we also have an IBar interface."
"Noooooooooooooooo!" I screamed (well, screamed inwardly anyway). "I need practical examples. You can't use Foo / Bar / Baz examples." But that's the way it was, and I didn't get anything new out of the session. (I also talked to some of my senior developer coworkers who attended, and they didn't get anything out of it either.)
It was several more years before I had a good grounding in object oriented design and the hows and whys of abstraction. The goal of "IEnumerable, ISaveable, IDontGetIt" is to give you a jump-start to understanding interfaces. We use real examples from the .NET framework and from actual application abstractions that I have coded in my professional career.
In addition to the So Cal Code Camp on Oct 13/14, I'll also be presenting this session at the Desert Code Camp (Phoenix) on Nov 17. And if you're quick, you can also see me present this information this week at a couple of user groups.
Hope to see you at an upcoming event.
Happy Coding!
Back again: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces.
Abstraction Through Interfaces
When people talk about interfaces, they often refer to the User Interface -- the screens and controls that allow the user to interact with the application. But "interface" also refers to a very powerful abstraction that lets us add extensibility and loose coupling to our code.
My first encounter with interfaces was in Delphi (Object Pascal) as a junior developer. I understood what they were from a technical standpoint, but I didn't understand why I would want to use them. We went to the Borland conference every year; and as a new developer, I took the opportunity to absorb as much information as I could, even if I didn't understand most of it (this is also a great way to use Code Camp -- to experience technologies you haven't taken the time to look into yet). I was very excited because there was a session in Interfaces at the conference.
"Great," I thought, "I'll go and get some practical examples of how to use interfaces and find out why I would want to use them." So, I get to the session, sit down, and grab my notepad -- ready to spend the next hour getting a practical introduction.
The speaker gets up and starts the presentation. "So, let's say that we have an Foo class. And we also have an IBar interface."
"Noooooooooooooooo!" I screamed (well, screamed inwardly anyway). "I need practical examples. You can't use Foo / Bar / Baz examples." But that's the way it was, and I didn't get anything new out of the session. (I also talked to some of my senior developer coworkers who attended, and they didn't get anything out of it either.)
It was several more years before I had a good grounding in object oriented design and the hows and whys of abstraction. The goal of "IEnumerable, ISaveable, IDontGetIt" is to give you a jump-start to understanding interfaces. We use real examples from the .NET framework and from actual application abstractions that I have coded in my professional career.
In addition to the So Cal Code Camp on Oct 13/14, I'll also be presenting this session at the Desert Code Camp (Phoenix) on Nov 17. And if you're quick, you can also see me present this information this week at a couple of user groups.
Hope to see you at an upcoming event.
Happy Coding!
Tuesday, September 25, 2012
Upcoming Speaking Engagements - October 2012
October is shaping up to be a busy month. I have several speaking engagements which will be a lot of fun. Code Camps and User Groups are a great place to get out and talk to
other developers -- find out what works and what doesn't work, and learn
a lot of great new techniques.
Tuesday, October 2, 2012
LA C# User Group - Manhattan Beach, CA
Topic: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Wednesday, October 3, 2012
So Cal .NET - Buena Park, CA
Topic: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Saturday / Sunday, October 6 / 7, 2012
Silicon Valley Code Camp - Los Altos Hills, CA
Topics:
Get Func<>-y: Delegates in .NET
Learn to Love Lambdas
Saturday / Sunday, October 13 / 14, 2012
SoCal Code Camp - Los Angeles, CA
Topics:
Dependency Injection: A Practical Introduction
IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Learn to Love Lambdas
T, Earl Grey, Hot: Generics in .NET
Stop by if you can; the more, the merrier.
Happy Coding!
Tuesday, October 2, 2012
LA C# User Group - Manhattan Beach, CA
Topic: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Wednesday, October 3, 2012
So Cal .NET - Buena Park, CA
Topic: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Saturday / Sunday, October 6 / 7, 2012
Silicon Valley Code Camp - Los Altos Hills, CA
Topics:
Get Func<>-y: Delegates in .NET
Learn to Love Lambdas
Saturday / Sunday, October 13 / 14, 2012
SoCal Code Camp - Los Angeles, CA
Topics:
Dependency Injection: A Practical Introduction
IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
Learn to Love Lambdas
T, Earl Grey, Hot: Generics in .NET
Stop by if you can; the more, the merrier.
Happy Coding!
Tuesday, September 18, 2012
Session Spotlight - Learn to Love Lambdas
I'll be speaking at SoCal Code Camp (Los Angeles) on October 13 & 14. If you're not signed up yet, head over to the website and let them know that you're coming: http://www.socalcodecamp.com/.
Back by popular demand: Learn to Love Lambdas
Lambda Expressions
Lambda expressions are a very powerful tool that can add elegance to our code. The problem is that they look like a secret code the first time you see them. You've probably come across something that looks like this:
It looks daunting, but it's fairly easy to learn. The lambda expression that we have here is just an anonymous delegate. If we were to use a more verbose syntax, we get something like this:
We are probably a bit more comfortable with this syntax. Here, we can tell that we're hooking up some sort of event handler, and it has standard event handler arguments: object and some type of EventArgs. Inside the method body, we are assigning the Result property of the EventArgs to display in a list box.
This anonymous delegate is equivalent to the lambda expression above. To create the lambda expression, we just replace the "delegate" keyword (before the parameters) with the "goes to" operator (=>) after the parameters. The parameter types are optional, so we can get rid of those. Also, since the method body only has one statement, we can remove the curly braces. This leaves us with a compact and readable syntax.
Delegates abound in the .NET framework (and in add-on frameworks like the Prism library). Whenever we have LINQ extension methods, event handlers, callbacks, or tasks, we can use lambda expressions to add compact blocks of code right where they are most useful. And in some instances (like when working with the Prism variants of RaisePropertyChanged) we can make our code more conducive to refactoring by replacing strings with compiler-checked pieces of code.
Once you get used to lambda expressions, they are extremely readable. In this session, we'll learn the lambda syntax, use lambdas for asynchronous callbacks, see a really cool feature that makes code safer, and see how lambdas were designed to be used extensively in LINQ. If you'd like to Learn to Love Lambdas, be sure to stop by my session at a code camp near you.
In addition to the SoCal Code Camp on Oct 13/14, I'll also be presenting this session at the Silicon Valley Code Camp on Oct 6/7 (this session is scheduled for 2:45 p.m. Sunday afternoon -- last session of the day).
Also be sure to check out the walkthrough and code samples here: Jeremy Bytes.
Hope to see you at an upcoming event.
Happy Coding!
Back by popular demand: Learn to Love Lambdas
Lambda Expressions
Lambda expressions are a very powerful tool that can add elegance to our code. The problem is that they look like a secret code the first time you see them. You've probably come across something that looks like this:
It looks daunting, but it's fairly easy to learn. The lambda expression that we have here is just an anonymous delegate. If we were to use a more verbose syntax, we get something like this:
We are probably a bit more comfortable with this syntax. Here, we can tell that we're hooking up some sort of event handler, and it has standard event handler arguments: object and some type of EventArgs. Inside the method body, we are assigning the Result property of the EventArgs to display in a list box.
This anonymous delegate is equivalent to the lambda expression above. To create the lambda expression, we just replace the "delegate" keyword (before the parameters) with the "goes to" operator (=>) after the parameters. The parameter types are optional, so we can get rid of those. Also, since the method body only has one statement, we can remove the curly braces. This leaves us with a compact and readable syntax.
Delegates abound in the .NET framework (and in add-on frameworks like the Prism library). Whenever we have LINQ extension methods, event handlers, callbacks, or tasks, we can use lambda expressions to add compact blocks of code right where they are most useful. And in some instances (like when working with the Prism variants of RaisePropertyChanged) we can make our code more conducive to refactoring by replacing strings with compiler-checked pieces of code.
Once you get used to lambda expressions, they are extremely readable. In this session, we'll learn the lambda syntax, use lambdas for asynchronous callbacks, see a really cool feature that makes code safer, and see how lambdas were designed to be used extensively in LINQ. If you'd like to Learn to Love Lambdas, be sure to stop by my session at a code camp near you.
In addition to the SoCal Code Camp on Oct 13/14, I'll also be presenting this session at the Silicon Valley Code Camp on Oct 6/7 (this session is scheduled for 2:45 p.m. Sunday afternoon -- last session of the day).
Also be sure to check out the walkthrough and code samples here: Jeremy Bytes.
Hope to see you at an upcoming event.
Happy Coding!
Wednesday, September 12, 2012
Session Spotlight - T, Earl Grey, Hot: Generics in .NET
I'll be speaking at SoCal Code Camp (Los Angeles) on October 13 & 14. If you're not signed up yet, head over to the website and let them know that you're coming: http://www.socalcodecamp.com/.
Also, I've got a brand new session: T, Earl Grey, Hot: Generics in .NET
Generics in .NET
Most C# developers have worked with generics to a certain extent (often by using classes from the base class library like List<T>). But we don't have to stop by merely consuming classes with generics; we can also create our own classes and methods that take advantage of this great framework feature.
We got generics way back in .NET 2.0, and they really were transformational at the time (now we're hopefully used to seeing them). Using generics, we can add type-safety to our code while still maintaining extensibility. By making our code type-safe, we are more likely to catch errors at compile time and also avoid strange behavior that might come from casting objects to different types. Our code also becomes more extensible -- it can work with types that it may not have been originally intended to work with.
Generics also offer us some performance enhancements (which, granted, seem fairly minor when talking about the processing resources of modern devices) by reducing casting calls and boxing/unboxing of value types.
In the session "T, Earl Grey, Hot: Generics in .NET", we'll take a look at the basic features of generics (by comparing non-generic and generic versions of classes from the base class library), see how we can incorporate generics into our own classes and methods in a practical way, and explore the various options to take full advantage of generics in our code (like "default" and generic constraints).
If you can't make it out to the SoCal Code Camp, you have another chance to see this session at the Desert Code Camp (in the Phoenix, AZ area) in November.
Hope to see you at an upcoming event.
Happy Coding!
Also, I've got a brand new session: T, Earl Grey, Hot: Generics in .NET
Generics in .NET
Most C# developers have worked with generics to a certain extent (often by using classes from the base class library like List<T>). But we don't have to stop by merely consuming classes with generics; we can also create our own classes and methods that take advantage of this great framework feature.
We got generics way back in .NET 2.0, and they really were transformational at the time (now we're hopefully used to seeing them). Using generics, we can add type-safety to our code while still maintaining extensibility. By making our code type-safe, we are more likely to catch errors at compile time and also avoid strange behavior that might come from casting objects to different types. Our code also becomes more extensible -- it can work with types that it may not have been originally intended to work with.
Generics also offer us some performance enhancements (which, granted, seem fairly minor when talking about the processing resources of modern devices) by reducing casting calls and boxing/unboxing of value types.
In the session "T, Earl Grey, Hot: Generics in .NET", we'll take a look at the basic features of generics (by comparing non-generic and generic versions of classes from the base class library), see how we can incorporate generics into our own classes and methods in a practical way, and explore the various options to take full advantage of generics in our code (like "default" and generic constraints).
If you can't make it out to the SoCal Code Camp, you have another chance to see this session at the Desert Code Camp (in the Phoenix, AZ area) in November.
Hope to see you at an upcoming event.
Happy Coding!
Sunday, June 17, 2012
Updated Samples for Code Camp
So Cal Code Camp - San Diego is coming up quickly (next Saturday & Sunday). Be sure to check the schedule and stop by one of my sessions if you can.
I've updated the sample applications with all new XAML -- they are now a bit more "Metroid". Here's a comparison between the old and new sample for my talk on Interfaces:
The UI re-design does not affect the code that drives the applications; one of the great things about XAML is that you can update the UI to look however you like and still keep the underlying functionality. The updated code can be downloaded from my demos page: http://www.jeremybytes.com/Demos.aspx.
In a future article, I will cover the custom templates (control templates and data templates) that I used to create the updated look.
Even if you don't attend one of my sessions at Code Camp, be sure to stop by to say "Hi" sometime during the weekend. One of my goals at Code Camp is to talk to as many developers as possible -- both old friends and new friends. See you there!
Happy Coding!
I've updated the sample applications with all new XAML -- they are now a bit more "Metroid". Here's a comparison between the old and new sample for my talk on Interfaces:
Old Repository Interface Sample
New Repository Interface Sample
The UI re-design does not affect the code that drives the applications; one of the great things about XAML is that you can update the UI to look however you like and still keep the underlying functionality. The updated code can be downloaded from my demos page: http://www.jeremybytes.com/Demos.aspx.
In a future article, I will cover the custom templates (control templates and data templates) that I used to create the updated look.
Even if you don't attend one of my sessions at Code Camp, be sure to stop by to say "Hi" sometime during the weekend. One of my goals at Code Camp is to talk to as many developers as possible -- both old friends and new friends. See you there!
Happy Coding!
Wednesday, April 25, 2012
Now Is Your Chance
Code Camp is all about developers sharing with developers. Now is your chance. The next So Cal Code Camp is 2 months away (June 23rd and 24th).
Code Camp is made possible by developers volunteering to speak for other developers. We've all learned interesting things; now is your chance to pick your favorite and share it with others. Every developer should try speaking at least once. Code Camp is a great place to get started because we're talking to folks just like us.
For some tips on preparing your session, check out this article: Meet the Next Code Camp Speaker: You!
You've got a little over 8 weeks to put your presentation together. So pick a topic and sign up at the So Cal Code Camp site.
Happy Speaking!
Code Camp is made possible by developers volunteering to speak for other developers. We've all learned interesting things; now is your chance to pick your favorite and share it with others. Every developer should try speaking at least once. Code Camp is a great place to get started because we're talking to folks just like us.
For some tips on preparing your session, check out this article: Meet the Next Code Camp Speaker: You!
You've got a little over 8 weeks to put your presentation together. So pick a topic and sign up at the So Cal Code Camp site.
Happy Speaking!
Tuesday, August 16, 2011
Meet the Next Code Camp Speaker: You!
If you are in the So Cal area, the next code camp generally right around the corner (3 times per year). It's the perfect time to consider speaking: http://www.socalcodecamp.com/.
Code Camp speakers come from the developer community. That's you! It turns out that most developers have something to say. We have all picked up tips and tricks with each new project we work on. In addition, we constantly find things in the development platform that we weren't familiar with before. And many times we find ourselves saying, "I wish someone had told me about this before."
Now's your chance. Code Camp is an easy place to get started as a speaker. As a developer, you are speaking to other developers. We all understand each other. Also since Code Camp is free, we're not expecting professional technical speakers (although, I'll admit that I've heard speakers at Code Camp who were better than some of the speakers at the professional conferences).
Code Camp speakers come from the developer community. That's you! It turns out that most developers have something to say. We have all picked up tips and tricks with each new project we work on. In addition, we constantly find things in the development platform that we weren't familiar with before. And many times we find ourselves saying, "I wish someone had told me about this before."
Now's your chance. Code Camp is an easy place to get started as a speaker. As a developer, you are speaking to other developers. We all understand each other. Also since Code Camp is free, we're not expecting professional technical speakers (although, I'll admit that I've heard speakers at Code Camp who were better than some of the speakers at the professional conferences).
Update: User groups are another place to get started. Here's a secret: user group leaders are always looking for speakers. And you don't need to be an expert to Help Those Behind You.
I'm going to share some tips that I've learned along the way, including some things that I specifically set out to avoid. There are no rules for speaking. Everyone has a different style. These are a set of tips which have worked for me. They may or may not work for you.
Danger: You May Get Hooked
I had done a few presentations for fellow developers within my department at work but never thought I would get up to speak in front of complete strangers. But after speaking at my first Code Camp, I was hooked. I signed up to speak at more Code Camps in my area, and let the local user groups know that I was interested in speaking.
Here's what hooked me: there's nothing quite like helping other people. The speaking part itself is a lot of fun for me, but what is most rewarding is if I get an email a week later from someone who let me know how they were able to use the information that I presented. Being helpful to someone else really drives me forward.
How Did I Get Started?
I got started as a speaker almost by accident. In my mind, I didn't have anything ground-breaking to talk about. I wasn't dealing with the latest beta products or cutting-edge software. I was just a competent developer working with established technologies. It seems like everyone was interested in whatever was new and shiny, so I didn't think I had anything to say.
Then I was listening to .NET Rocks! (a really good podcast, by the way). There was a panel discussion and one of the topics that came up was the lack of beginning and intermediate sessions for people who were new to development or just new to .NET. When .NET was first released, there were all sorts of introductory sessions including the basics of the languages, the CLR, garbage collection, and just how to get started creating applications. Then over the years, the introductory sessions faded away to be replaced by whatever the latest technologies were. The panel agreed that there was a need for people to present those introductory topics to keep bringing more people into the world of .NET development.
I thought, "Hey, I can do that." And I took it as a challenge. About 2 weeks after the podcast, I heard about an upcoming Code Camp and determined that I would put together three sessions for it. (It may have been a lot to bite off my first time around, but I had 8 weeks to prepare).
Those first sessions went very well. And I attribute that primarily to the preparation.
So let's take a look at some tips to get started with.
One Rule
Earlier I mentioned that there were no rules. But that wasn't quite true. In reality there is one rule: Have fun! If you aren't going to enjoy this, then no one attending will enjoy it either. It's okay if you are nervous. But once you get started, just like any other performance, the nervousness usually fades away. Just go with it and have fun.
Picking a Topic
One of the first things you will need to do is pick a topic. Pick a topic that you are passionate about, something you really love. Okay, love is a bit of a strong word, but select something that you have found really useful in your development -- something that you wouldn't want anyone to take away from you.
Here's a tip from Scott Hanselman: Give the presentation that you want to attend. When you are thinking about a topic, go back to the "I wish someone had told me about this before" moment. It may be a common subject; it may seem basic or simplistic. That's okay. If it is something that you wish you had known about earlier, chances are that there are a lot of other developers who don't know about it yet.
One other thing about picking a topic: be aware of the scope. You have limited time to present your session. If you pick a topic that is too broad, then you may end up skimming over the top without going into any useful detail. If you pick a topic that is too narrow, you may find that you don't have material to fill up the time slot.
Preparation
I cannot say enough about being prepared for your presentation. I know what I am going to say before I walk in the room. If I end up giving the same presentation a second or third time, it will generally be almost exactly the same content each time.
Often at Code Camp, you will see people in the back of the room frantically typing away. These are usually speakers who are finishing up their slides or code samples. This works for some people (people who love the "deadline"). And if you are a veteran speaker, you can often get away with it. It doesn't work for me. Your first time out, you are going to have a lot of things on your mind (How do I use the AV equipment? Is Visual Studio working right? Can I find my slides?) If you have your presentation nailed down, that is one less thing to worry about.
The first step in preparation is to know your material. By putting together a presentation, I find that I have big gaps in my knowledge about the topic. This is usually because I needed to use a technology for a specific project with specific requirements. But if you want to present the broader topic, you will find that there are parts of the technology that you have not used and need to learn about. This doesn't mean you need to become an expert. But you do need to at least know all of the terminology and have a general idea of how ti all works, even if you can't give the specific details.
Once you have everything put together (topic, slides, demo code, etc.), then practice, practice, practice. Run through the presentation all the way through multiple times. And not just in your head. Speak out loud (pets are a great audience for your first practice runs). I generally run through a new presentation at least 4 times. This helps me find the places where I stumble or need to clarify my thoughts. Sometimes you get tongue-tied. That's what practice is for. Even if I am doing a repeat of a presentation that I've done before, I'll run through 1 or 2 practices to make sure that I still know what I'm talking about.
Stay on Time
One thing that all of the practice will help you with is to stay on time. Is your presentation running long? Figure out what you can cut or speed up. Is your presentation short? That may be okay. It leaves more time for questions or to explore some of the items a little further.
One of the worst things you can do at Code Camp is run long. Code Camp is usually a very compressed day. People have limited time to get from session to session (and to visit the restroom or grab a soda in between). If you run long, then you will lose the attention of the people in the room anyway, so it's best to make sure that won't happen.
Things don't always go according to plan. My first time out, I thought that I had my timing down fine. I was confident and took time for a few questions in the middle of the session. But because I had practiced so much, I recognized about halfway through the time that I wasn't halfway through my material. I made some quick mental cuts and decided what I could skip over. I was able to do this on-the-fly without it being too obvious that I had done so.
Slides
No one likes slides at Code Camp. We're not executives that want bullet points. We want to see code in action. So feel free to go light on the slides.
With that said, I would not recommend ditching the slides entirely. If you have slides, then the folks in the room know that you spent at least a little bit of time in preparation. I've gone to a couple completely slide-free presentations, and they seemed to be completely ad-libbed (which could be fine depending on the topic). My personal approach is to have a couple of slides that introduce me and the topic, but then I spend most of my time in the code. This is just my style; other people approach this differently. Again, the goal is to find what works best for you as a speaker.
Remember the advice to give the presentation you would like to attend. Do you want to see a lot of wordy slides with the presenter simply reading them? Probably not. The slides are there to augment what you have to say, not repeat it or replace it.
One other thing that I do with my slides is have a reference links slide at the end of the presentation. This would contain links to web sites, blog articles, MSDN articles, or other helpful materials. I post my slides on my website so that people can get to these links without having to scribble them all down during the presentation.
Demo
Code Campers love demos. We want to see what you are talking about in action. There are a lot of different styles for this part.
First, there is the advice to never do a live demo. There are too many things to go wrong. And Murphy's Law says that it will probably all go wrong right in the middle of your presentation. Personally, I think that preparation can mitigate a lot of this risk (and I'll talk about a few specific items of preparation that help in just a bit).
If you have a demo set up that is very complex, such as one that requires multiple computers networked together or needs access to a specific web site, then you might consider doing a screen capture of the demo and then playing it during the presentation. And even if you want to do this live, it doesn't hurt to have the video as a backup in case the network goes down or something else goes wrong.
But the most effective demos are live demos. How you approach this will depend on your topic and how deeply you want to cover things. You may want to start with a blank project and build an entire application live. This works well in a lot of cases, but be aware that you will be limited in how much you can show.
You may want to start with several different projects that are in various stages of completion. In this case, you can open the #1 project, add some code and show what it does. Then move on to the #2 project which has more code in place, add some more code and show what that does. This can be a very effective way of presenting a topic.
Here's what I do -- again, take this as part of my personal style based on how I pick topics; it is what has worked well for me. I generally start with a project that is prepared just enough for me to start putting in the important code. For example, if I am doing an introduction to XAML, I start out with a completely new, blank project and move from there. If I am speaking about lambda expressions, then I have the UI already laid out and start with mostly blank code behind the UI. The idea is that anything that is already in place is not necessary to understand for the topic being discussed; it is part of the background.
One other thing you can do. If you have large blocks of code to add as part of your demo, don't make people watch you type. This can be especially painful if you are not a good typist. If you have large blocks of code, then create another file within your project that contains the code in comment blocks. Then you can copy/paste the blocks of code into your project during the demo. This saves you a lot of time, and it also helps to avoid typos.
As part of my preparation, I have 2 copies of each of my projects. The first copy is the "Starter" project. This is the mostly-blank project that I am going to fill in with the code during the presentation. The second copy is the "Completed" project. This is what the project looks like after I have completely run through the demo. This is my safety net. If something goes horribly wrong during the live code demo, I can always open up the completed application and show the pieces already in place. The good news is that I have only had to do this once (knock on wood). I attribute this to preparation; I have practiced the code demo so many times that I know exactly what I need to do. And if something does go wrong, I've probably already seen that same issue during the practice runs.
The Tools
Feel free to ignore this tip. This is a personal preference based on sessions that I have attended. The tip: run naked. Okay, don't do that literally (no one needs to see that). What I mean is disable the add-ins in your development environment unless they are critical to what you are trying to demo. When I see someone do a demo, I want to be able to go home and do exactly the same thing. If the speaker is using an add-in that has magic keystrokes, then it makes it harder for me to follow.
This primarily applies to non-free add-ins. If you have free tools that you find useful, then by all means recommend them. As developers we are always looking for new tools that can make our development faster and more effective.
One other thing about tools: if you know any shortcuts that are native to the development environment, be sure to share them. Not everyone is aware of what Ctrl+K,D does. Not everyone is aware of what the little purple box means. Not everyone is aware that you can press 2 keys to stub out an interface. If you can fit these tips into your presentation, then go ahead and do it.
Organization
How you organize things is part of your preparation. You need to know where all of your slides, code samples, demos, and websites are. I have been in a few presentations where the speaker opened the wrong projects and had trouble finding the code he was looking for. Don't let this happen to you. Something that I find useful is to create a folder that has shortcuts to everything I need. You can put this folder on the desktop or even dock it to the taskbar. If you have multiple shortcuts to code projects, then number the shortcuts so that you can open them in the correct order.
During the Presentation
You will probably be jittery as the presentation starts. That's fine. This is normal. A lot of times, this may lead to you speaking too quickly or getting tongue-tied. If this happens, just pause and take a deep breath. Have a bottle of water with you, and take a sip. You don't have to fill every second with talking. Taking a deep breath will give your brain a chance to catch up and organize your thoughts. Then you can continue clearly and confidently.
Watch your speed. If you have practiced, then you should know where the quarter, half-way, and three-quarter marks are in your presentation. When you hit those spots, how does that compare to the clock? If you are ahead of time, then you may want to slow down, or pause to see if anyone has questions. If you are running late, then you may want to start thinking about what you can skip later on or if you can simply speed up a little bit.
Focus on Individuals
When you are speaking, try to look at individuals in the room. It is tempting to talk directly to one person (the one person who is paying most attention). But make sure that you are talking to everyone. Talking to "everyone" does not mean simply throwing your words into the room; you need to talk to the individual people in the room. While speaking, take a few moments to make eye contact with one person, then move on to another person. Remember that you are talking to actual people.
I forgot this once. I was on my third presentation of the day. The other two presentations had full rooms with lots of energy. The third presentation just had a few people in the room. I tried to continue the energy into that room, but it didn't work. It was awkward, and I bombed the presentation. I got all of the information out there (because of the practice I had), but I never made a connection with anyone in the room. Ultimately, I'm glad that it happened. I learned from what I did wrong, and I've been better able to adjust my presentation style based on the situation.
Taking Questions
It's up to you to decide whether you want to take questions during your presentation. If you are going to take questions freely, then plan your presentation so that it would normally end 10 to 15 minutes before the end of the allotted time. If you want to save questions for the end (if there is time), that is fine, too. Just let your attendees know how you would like to handle questions.
If you take questions, stay on topic. If someone asks a question that will take you off topic, it is okay to put the question off. As developers, we always want to show off how much we know. So if someone asks a question, your first instinct is to answer it. But here's the problem: if the question takes the session off topic, it may be good for the one person in the room (the person who asked the question), but it will be horrible for the rest of the people in the room. After all, they all came to hear you speak about a particular subject. I have often been frustrated (as an attendee) when a session was derailed by someone asking questions that are relevant only to that one person.
If you take questions, it's okay to defer. It may be that the question is either off topic or that the question is on-topic but would take too long to answer. If this is the case, then let the person know that you would be happy to talk to them about it later, either between sessions or in email.
If you take questions, it's okay to not know the answer. You don't have to know everything before you become a speaker. I have often had people ask me a question that I did not know the answer to. This is usually because they bring up a scenario that I had never thought through or tried before. In these situations, I generally write down the question and then say that I will post the answer on my blog once I have time to research it. Exactly how you handle the situation is up to you. But it is better to say that you don't know than to make up an answer.
After the Presentation
There are a couple things that you can do after the presentation to wrap things up. First, if you have code samples or slides that you say you will make available for download, then do it. I have been at professional conferences and had the speaker say that the code from the session would be on the website after a week. I checked after a week, and it wasn't there. I checked after two weeks, and it still wasn't there. Because of curiosity, I went back two months later, and it still wasn't there. If you say that you are going to post your code, then post your code. And by the way, if you don't want to post your code, that's okay, too. Just make sure that if you say you will do something, you follow up on it.
Another "this works for me": I always post my code samples and slides on my website before the presentation starts. This way, I don't have to worry about finding the time to do this later (because I'm very good at forgetting things). It also has the side-effect of forcing me to prepare. I can't post the slides and code samples until after my preparation is complete.
Finally, follow up on questions. If you say that you will post answers on your blog or follow up with an individual over email, then make sure you do that.
Final Words
So, we've talked about a lot of different tips. As I noted, most of these things have worked well for me. Some of them are things that have bothered me from sessions that I have attended. But everyone is different.
Remember the one rule: Have fun! The fate of the world does not depend on you giving a good presentation. If you mess up, no one's going to die. You learn best when things go wrong.
And make sure to be yourself. Everyone has a different style of speaking. Everyone has a different style of coding. Don't pretend to be someone else when you are speaking. Just be yourself. If you are prepared, then things are bound to turn out just fine.
Everyone has something to share with other developers. Take the next step and sign up for the next Code Camp in your area. You might find that you love it, and you'll be speaking more and more. You might find that it's not your thing. That's okay, too. But you never know until you try.
Happy speaking!
I'm going to share some tips that I've learned along the way, including some things that I specifically set out to avoid. There are no rules for speaking. Everyone has a different style. These are a set of tips which have worked for me. They may or may not work for you.
Danger: You May Get Hooked
I had done a few presentations for fellow developers within my department at work but never thought I would get up to speak in front of complete strangers. But after speaking at my first Code Camp, I was hooked. I signed up to speak at more Code Camps in my area, and let the local user groups know that I was interested in speaking.
Here's what hooked me: there's nothing quite like helping other people. The speaking part itself is a lot of fun for me, but what is most rewarding is if I get an email a week later from someone who let me know how they were able to use the information that I presented. Being helpful to someone else really drives me forward.
How Did I Get Started?
I got started as a speaker almost by accident. In my mind, I didn't have anything ground-breaking to talk about. I wasn't dealing with the latest beta products or cutting-edge software. I was just a competent developer working with established technologies. It seems like everyone was interested in whatever was new and shiny, so I didn't think I had anything to say.
Then I was listening to .NET Rocks! (a really good podcast, by the way). There was a panel discussion and one of the topics that came up was the lack of beginning and intermediate sessions for people who were new to development or just new to .NET. When .NET was first released, there were all sorts of introductory sessions including the basics of the languages, the CLR, garbage collection, and just how to get started creating applications. Then over the years, the introductory sessions faded away to be replaced by whatever the latest technologies were. The panel agreed that there was a need for people to present those introductory topics to keep bringing more people into the world of .NET development.
I thought, "Hey, I can do that." And I took it as a challenge. About 2 weeks after the podcast, I heard about an upcoming Code Camp and determined that I would put together three sessions for it. (It may have been a lot to bite off my first time around, but I had 8 weeks to prepare).
Those first sessions went very well. And I attribute that primarily to the preparation.
So let's take a look at some tips to get started with.
One Rule
Earlier I mentioned that there were no rules. But that wasn't quite true. In reality there is one rule: Have fun! If you aren't going to enjoy this, then no one attending will enjoy it either. It's okay if you are nervous. But once you get started, just like any other performance, the nervousness usually fades away. Just go with it and have fun.
Picking a Topic
One of the first things you will need to do is pick a topic. Pick a topic that you are passionate about, something you really love. Okay, love is a bit of a strong word, but select something that you have found really useful in your development -- something that you wouldn't want anyone to take away from you.
Here's a tip from Scott Hanselman: Give the presentation that you want to attend. When you are thinking about a topic, go back to the "I wish someone had told me about this before" moment. It may be a common subject; it may seem basic or simplistic. That's okay. If it is something that you wish you had known about earlier, chances are that there are a lot of other developers who don't know about it yet.
One other thing about picking a topic: be aware of the scope. You have limited time to present your session. If you pick a topic that is too broad, then you may end up skimming over the top without going into any useful detail. If you pick a topic that is too narrow, you may find that you don't have material to fill up the time slot.
Preparation
I cannot say enough about being prepared for your presentation. I know what I am going to say before I walk in the room. If I end up giving the same presentation a second or third time, it will generally be almost exactly the same content each time.
Often at Code Camp, you will see people in the back of the room frantically typing away. These are usually speakers who are finishing up their slides or code samples. This works for some people (people who love the "deadline"). And if you are a veteran speaker, you can often get away with it. It doesn't work for me. Your first time out, you are going to have a lot of things on your mind (How do I use the AV equipment? Is Visual Studio working right? Can I find my slides?) If you have your presentation nailed down, that is one less thing to worry about.
The first step in preparation is to know your material. By putting together a presentation, I find that I have big gaps in my knowledge about the topic. This is usually because I needed to use a technology for a specific project with specific requirements. But if you want to present the broader topic, you will find that there are parts of the technology that you have not used and need to learn about. This doesn't mean you need to become an expert. But you do need to at least know all of the terminology and have a general idea of how ti all works, even if you can't give the specific details.
Once you have everything put together (topic, slides, demo code, etc.), then practice, practice, practice. Run through the presentation all the way through multiple times. And not just in your head. Speak out loud (pets are a great audience for your first practice runs). I generally run through a new presentation at least 4 times. This helps me find the places where I stumble or need to clarify my thoughts. Sometimes you get tongue-tied. That's what practice is for. Even if I am doing a repeat of a presentation that I've done before, I'll run through 1 or 2 practices to make sure that I still know what I'm talking about.
Stay on Time
One thing that all of the practice will help you with is to stay on time. Is your presentation running long? Figure out what you can cut or speed up. Is your presentation short? That may be okay. It leaves more time for questions or to explore some of the items a little further.
One of the worst things you can do at Code Camp is run long. Code Camp is usually a very compressed day. People have limited time to get from session to session (and to visit the restroom or grab a soda in between). If you run long, then you will lose the attention of the people in the room anyway, so it's best to make sure that won't happen.
Things don't always go according to plan. My first time out, I thought that I had my timing down fine. I was confident and took time for a few questions in the middle of the session. But because I had practiced so much, I recognized about halfway through the time that I wasn't halfway through my material. I made some quick mental cuts and decided what I could skip over. I was able to do this on-the-fly without it being too obvious that I had done so.
Slides
No one likes slides at Code Camp. We're not executives that want bullet points. We want to see code in action. So feel free to go light on the slides.
With that said, I would not recommend ditching the slides entirely. If you have slides, then the folks in the room know that you spent at least a little bit of time in preparation. I've gone to a couple completely slide-free presentations, and they seemed to be completely ad-libbed (which could be fine depending on the topic). My personal approach is to have a couple of slides that introduce me and the topic, but then I spend most of my time in the code. This is just my style; other people approach this differently. Again, the goal is to find what works best for you as a speaker.
Remember the advice to give the presentation you would like to attend. Do you want to see a lot of wordy slides with the presenter simply reading them? Probably not. The slides are there to augment what you have to say, not repeat it or replace it.
One other thing that I do with my slides is have a reference links slide at the end of the presentation. This would contain links to web sites, blog articles, MSDN articles, or other helpful materials. I post my slides on my website so that people can get to these links without having to scribble them all down during the presentation.
Demo
Code Campers love demos. We want to see what you are talking about in action. There are a lot of different styles for this part.
First, there is the advice to never do a live demo. There are too many things to go wrong. And Murphy's Law says that it will probably all go wrong right in the middle of your presentation. Personally, I think that preparation can mitigate a lot of this risk (and I'll talk about a few specific items of preparation that help in just a bit).
If you have a demo set up that is very complex, such as one that requires multiple computers networked together or needs access to a specific web site, then you might consider doing a screen capture of the demo and then playing it during the presentation. And even if you want to do this live, it doesn't hurt to have the video as a backup in case the network goes down or something else goes wrong.
But the most effective demos are live demos. How you approach this will depend on your topic and how deeply you want to cover things. You may want to start with a blank project and build an entire application live. This works well in a lot of cases, but be aware that you will be limited in how much you can show.
You may want to start with several different projects that are in various stages of completion. In this case, you can open the #1 project, add some code and show what it does. Then move on to the #2 project which has more code in place, add some more code and show what that does. This can be a very effective way of presenting a topic.
Here's what I do -- again, take this as part of my personal style based on how I pick topics; it is what has worked well for me. I generally start with a project that is prepared just enough for me to start putting in the important code. For example, if I am doing an introduction to XAML, I start out with a completely new, blank project and move from there. If I am speaking about lambda expressions, then I have the UI already laid out and start with mostly blank code behind the UI. The idea is that anything that is already in place is not necessary to understand for the topic being discussed; it is part of the background.
One other thing you can do. If you have large blocks of code to add as part of your demo, don't make people watch you type. This can be especially painful if you are not a good typist. If you have large blocks of code, then create another file within your project that contains the code in comment blocks. Then you can copy/paste the blocks of code into your project during the demo. This saves you a lot of time, and it also helps to avoid typos.
As part of my preparation, I have 2 copies of each of my projects. The first copy is the "Starter" project. This is the mostly-blank project that I am going to fill in with the code during the presentation. The second copy is the "Completed" project. This is what the project looks like after I have completely run through the demo. This is my safety net. If something goes horribly wrong during the live code demo, I can always open up the completed application and show the pieces already in place. The good news is that I have only had to do this once (knock on wood). I attribute this to preparation; I have practiced the code demo so many times that I know exactly what I need to do. And if something does go wrong, I've probably already seen that same issue during the practice runs.
The Tools
Feel free to ignore this tip. This is a personal preference based on sessions that I have attended. The tip: run naked. Okay, don't do that literally (no one needs to see that). What I mean is disable the add-ins in your development environment unless they are critical to what you are trying to demo. When I see someone do a demo, I want to be able to go home and do exactly the same thing. If the speaker is using an add-in that has magic keystrokes, then it makes it harder for me to follow.
This primarily applies to non-free add-ins. If you have free tools that you find useful, then by all means recommend them. As developers we are always looking for new tools that can make our development faster and more effective.
One other thing about tools: if you know any shortcuts that are native to the development environment, be sure to share them. Not everyone is aware of what Ctrl+K,D does. Not everyone is aware of what the little purple box means. Not everyone is aware that you can press 2 keys to stub out an interface. If you can fit these tips into your presentation, then go ahead and do it.
Organization
How you organize things is part of your preparation. You need to know where all of your slides, code samples, demos, and websites are. I have been in a few presentations where the speaker opened the wrong projects and had trouble finding the code he was looking for. Don't let this happen to you. Something that I find useful is to create a folder that has shortcuts to everything I need. You can put this folder on the desktop or even dock it to the taskbar. If you have multiple shortcuts to code projects, then number the shortcuts so that you can open them in the correct order.
During the Presentation
You will probably be jittery as the presentation starts. That's fine. This is normal. A lot of times, this may lead to you speaking too quickly or getting tongue-tied. If this happens, just pause and take a deep breath. Have a bottle of water with you, and take a sip. You don't have to fill every second with talking. Taking a deep breath will give your brain a chance to catch up and organize your thoughts. Then you can continue clearly and confidently.
Watch your speed. If you have practiced, then you should know where the quarter, half-way, and three-quarter marks are in your presentation. When you hit those spots, how does that compare to the clock? If you are ahead of time, then you may want to slow down, or pause to see if anyone has questions. If you are running late, then you may want to start thinking about what you can skip later on or if you can simply speed up a little bit.
Focus on Individuals
When you are speaking, try to look at individuals in the room. It is tempting to talk directly to one person (the one person who is paying most attention). But make sure that you are talking to everyone. Talking to "everyone" does not mean simply throwing your words into the room; you need to talk to the individual people in the room. While speaking, take a few moments to make eye contact with one person, then move on to another person. Remember that you are talking to actual people.
I forgot this once. I was on my third presentation of the day. The other two presentations had full rooms with lots of energy. The third presentation just had a few people in the room. I tried to continue the energy into that room, but it didn't work. It was awkward, and I bombed the presentation. I got all of the information out there (because of the practice I had), but I never made a connection with anyone in the room. Ultimately, I'm glad that it happened. I learned from what I did wrong, and I've been better able to adjust my presentation style based on the situation.
Taking Questions
It's up to you to decide whether you want to take questions during your presentation. If you are going to take questions freely, then plan your presentation so that it would normally end 10 to 15 minutes before the end of the allotted time. If you want to save questions for the end (if there is time), that is fine, too. Just let your attendees know how you would like to handle questions.
If you take questions, stay on topic. If someone asks a question that will take you off topic, it is okay to put the question off. As developers, we always want to show off how much we know. So if someone asks a question, your first instinct is to answer it. But here's the problem: if the question takes the session off topic, it may be good for the one person in the room (the person who asked the question), but it will be horrible for the rest of the people in the room. After all, they all came to hear you speak about a particular subject. I have often been frustrated (as an attendee) when a session was derailed by someone asking questions that are relevant only to that one person.
If you take questions, it's okay to defer. It may be that the question is either off topic or that the question is on-topic but would take too long to answer. If this is the case, then let the person know that you would be happy to talk to them about it later, either between sessions or in email.
If you take questions, it's okay to not know the answer. You don't have to know everything before you become a speaker. I have often had people ask me a question that I did not know the answer to. This is usually because they bring up a scenario that I had never thought through or tried before. In these situations, I generally write down the question and then say that I will post the answer on my blog once I have time to research it. Exactly how you handle the situation is up to you. But it is better to say that you don't know than to make up an answer.
After the Presentation
There are a couple things that you can do after the presentation to wrap things up. First, if you have code samples or slides that you say you will make available for download, then do it. I have been at professional conferences and had the speaker say that the code from the session would be on the website after a week. I checked after a week, and it wasn't there. I checked after two weeks, and it still wasn't there. Because of curiosity, I went back two months later, and it still wasn't there. If you say that you are going to post your code, then post your code. And by the way, if you don't want to post your code, that's okay, too. Just make sure that if you say you will do something, you follow up on it.
Another "this works for me": I always post my code samples and slides on my website before the presentation starts. This way, I don't have to worry about finding the time to do this later (because I'm very good at forgetting things). It also has the side-effect of forcing me to prepare. I can't post the slides and code samples until after my preparation is complete.
Finally, follow up on questions. If you say that you will post answers on your blog or follow up with an individual over email, then make sure you do that.
Final Words
So, we've talked about a lot of different tips. As I noted, most of these things have worked well for me. Some of them are things that have bothered me from sessions that I have attended. But everyone is different.
Remember the one rule: Have fun! The fate of the world does not depend on you giving a good presentation. If you mess up, no one's going to die. You learn best when things go wrong.
And make sure to be yourself. Everyone has a different style of speaking. Everyone has a different style of coding. Don't pretend to be someone else when you are speaking. Just be yourself. If you are prepared, then things are bound to turn out just fine.
Everyone has something to share with other developers. Take the next step and sign up for the next Code Camp in your area. You might find that you love it, and you'll be speaking more and more. You might find that it's not your thing. That's okay, too. But you never know until you try.
Happy speaking!
Subscribe to:
Posts (Atom)