At the last 2 code camps (So Cal Code Camp and Desert Code Camp), the same question came up. How do exceptions affect the process flow when invoking a multi-cast delegate? Let's do a quick review and then take a closer look. For more information, please take a look at Get Func<>-y: Delegates in .NET.
Multi-Cast Delegates
All delegates in .NET are multi-cast delegates. This means that we can assign multiple methods to the same delegate variable. When we invoke the delegate variable (to run the methods), then all methods that have been assigned are run.
For example, take a look at this Action variable:
Action<List<Person>> act;
Then we can assign multiple methods as follows (in this case using lambda expressions):
act += p => Console.WriteLine(p.Average(r => r.Rating)).ToString();
act += p => Console.WriteLine(p.Min(s => s.StartDate));
Then we can invoke the delegate (assuming that "people" is a list of Person objects):
act(people);
The resulting output to the console window is as follows:
6.4285714285714288
10/17/1975
Single-Threaded Execution
.NET does not do anything magical when it runs the methods assigned to the delegate. They simply run in order, synchronously, on the same thread where the delegate is invoked. In the examples from the "Get Func<>-y" session, we invoke the delegate from the UI thread of a WPF application, and we see that if one of the methods is blocking (such as a MessageBox.Show() method that waits for user input), then the other methods do not execute until that method has completed. (As you can imagine, if we wanted the methods to run on separate threads, we could do that; but that is not the default behavior.)
Exceptions
Now, what happens if we add an exception into the mix:
act += p => Console.WriteLine(p.Average(r => r.Rating)).ToString();
act += p => { throw new Exception("Error Here"); };
act += p => Console.WriteLine(p.Min(s => s.StartDate));
What do we expect to happen? Will all 3 methods execute? None of the methods? Only the first one?
The answer turns out to be pretty simple. Since the methods are run in order, the first method will execute successfully, the second method will throw an exception, and the third will not execute. Since we do not have any exception handling defined, our application will stop working. The console window will have the following:
6.4285714285714288
So, we can see that the first method did in fact run, but the third method did not.
Exception Handling
We can keep our application operational by adding a try/catch block around the invocation of the delegate. This will keep our application from completely erroring out:
try
{
act(people);
}
catch (Exception ex)
{
Console.WriteLine("Caught Exception: {0}", ex.Message);
}
And our output now looks like the following:
6.4285714285714288
Caught Exception: Error Here
But something to notice, even though our application continues (and completes normally), the third method still does not run. And this should not be surprising. When an exception is thrown, the system will walk up the call stack until it finds an exception handler. If it does not find one, then the application will error out. In this case, when the exception in the second method is thrown, it walks back up the call stack to the method that invoked the delegate. There it finds the try/catch and handles the exception. But since we exited out of the actual delegate invocation, the third method is not called.
[Update: For a more robust solution, see More Delegate Exception Handling.]
Some Things to Think About
Now let's consider a bit how we use delegates. Generally, we (as developers) are on one end of the delegate or the other -- meaning we are creating a delegate so that other developers can hook into our code, or we are using a delegate to hook into someone else's code.
If we are creating a delegate that we invoke (such as the call to act(people) above), then we should definitely consider wrapping the invocation in a try/catch block. When someone assigns a method to a delegate that we then invoke, we really have no control over what that assigned method does. This means that we need to protect our code to make sure that someone else's mistake does not cause our code to crash. We need to handle any exceptions that are generated by the invocation so that our application can continue to operate (or at least fail gracefully).
Also, as we noted in "Get Func<>-y", we should be checking the delegate before invocation to make sure that it is not null. In this code sample, it would look like the following:
try
{
if(act != null)
act(people);
}...
If we try to invoke a delegate variable that does not have any methods assigned, then we will get a null reference exception. Alternately, we could handle the NullReferenceException in our catch block, but it's usually better to avoid the exception if it can be anticipated.
But what if we're on the other side of the delegate? What if we are a developer who is assigning methods to a delegate to hook into someone else's code? In that case, we need to follow standard practices for error handling in those methods. We could easily add a try/catch block to the method that we assign to a delegate variable. This way we would have the first shot at handling the exception. And since the exception is happening in our code, we are probably in the best position to try to handle it. If we cannot handle the exception, then we can let it bubble up (as we saw in the sample above). How we handle this will depend on the type of delegates that we are working with, what our business processes are, and how we have designed our error handling and failure modes through the rest of the application.
We always need to be on the lookout for the unexpected. In the sample code that shows up in my demos, the error handling has been excluded (just so that we can more clearly focus on the topic at hand). But when building our applications, we need to make sure that we are following good programming practices and making sure that we can handle the exceptions that may occur in our code.
Happy Coding!
Sunday, November 13, 2011
Sunday, September 18, 2011
Upcoming Code Camps
Code Camps are a great way to spend a day or two hearing great presentations, talking to other developers, and seeing what's hot in the dev community. Best of all Code Camp is always FREE!
If you are a developer, you have something to share. Sign up as a speaker. It's easy, it's fun, and you'll learn a lot doing it. Here are some tips for Code Camp Speakers: Meet the Next Code Camp Speaker: You!
So Cal Code Camp - Los Angeles, CA
October 15 - 16, 2011
If you're in the Southern California area (or are looking for an excuse to go there), come join us at the So Cal Code Camp. There are a ton of sessions to choose from, lots of developers to meet, and always a good time to be had.
So Cal Code Camp
I'll be speaking. Will you?
Desert Code Camp - Chandler, AZ
November 5, 2011
If you're in the Phoenix area (or are looking for a reason to head out to the desert), come join us at the Desert Code Camp. There are great developers to meet, a ton of variety in the sessions offered, and even session tracks just for kids.
Desert Code Camp
I'll be speaking. Will you?
Hope to see you there!
If you are a developer, you have something to share. Sign up as a speaker. It's easy, it's fun, and you'll learn a lot doing it. Here are some tips for Code Camp Speakers: Meet the Next Code Camp Speaker: You!
So Cal Code Camp - Los Angeles, CA
October 15 - 16, 2011
If you're in the Southern California area (or are looking for an excuse to go there), come join us at the So Cal Code Camp. There are a ton of sessions to choose from, lots of developers to meet, and always a good time to be had.
So Cal Code Camp
I'll be speaking. Will you?
Desert Code Camp - Chandler, AZ
November 5, 2011
If you're in the Phoenix area (or are looking for a reason to head out to the desert), come join us at the Desert Code Camp. There are great developers to meet, a ton of variety in the sessions offered, and even session tracks just for kids.
Desert Code Camp
I'll be speaking. Will you?
Hope to see you there!
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!
Tuesday, May 10, 2011
Upcoming Speaking Engagements
I have a couple of speaking engagements scheduled later this month. Come on out if you can.
May 19, 2011
Southern California .NET Architecture Users Group
Santa Ana, CA
http://www.socaldotnetarchitecture.org/
May 24, 2011
BiTKOO Webinar
BiTKOO, a leader in authorization management software (and the company I work for), is hosting a free webinar on Tuesday, May 24 at 1:00 PDT. The topic is "Leveling Up: Authorization in Your Application". You can get more information on the topic and sign up here: https://www3.gotomeeting.com/register/975758094
And next month...
June 25 & 26, 2011
So Cal Code Camp - San Diego, CA
It's code camp time once again. Code camp is a great place to meet and talk to your fellow developers, find out what tools people are using, and what's working and what's not. Plus, you get 2 solid days of FREE sessions -- over 100 to choose from. If you can make it, be sure to hunt me down to say, "Hi".
http://www.socalcodecamp.com
Happy Coding!
May 19, 2011
Southern California .NET Architecture Users Group
Santa Ana, CA
http://www.socaldotnetarchitecture.org/
May 24, 2011
BiTKOO Webinar
BiTKOO, a leader in authorization management software (and the company I work for), is hosting a free webinar on Tuesday, May 24 at 1:00 PDT. The topic is "Leveling Up: Authorization in Your Application". You can get more information on the topic and sign up here: https://www3.gotomeeting.com/register/975758094
And next month...
June 25 & 26, 2011
So Cal Code Camp - San Diego, CA
It's code camp time once again. Code camp is a great place to meet and talk to your fellow developers, find out what tools people are using, and what's working and what's not. Plus, you get 2 solid days of FREE sessions -- over 100 to choose from. If you can make it, be sure to hunt me down to say, "Hi".
http://www.socalcodecamp.com
Happy Coding!
Monday, April 4, 2011
1,000 Attendees!
A big thank you to those of you who came to my sessions at the Desert Code Camp this weekend. I had a great time, and it was good to see some of you back in my sessions again. You helped me pass the 1,000 mark -- over 1,000 people have come to my sessions since I started speaking publicly in January 2010 (although I know it is fewer than 1,000 unique people since some of you have come to more than one of my sessions).
Here's a breakdown of my speaking engagements:
Jan 2010 - So Cal Code Camp - Fullerton, CA
135 attendees (3 sessions)
Feb 2010 - Disney .NET Developers Group - Burbank, CA
30 attendees
Jun 2010 - So Cal Code Camp - San Diego, CA
59 attendees (3 sessions)
Jul 2010 - LA C# User Group - Manhattan Beach, CA
20 attendees
Jul 2010 - So Cal .NET Developers Group - Buena Park, CA
25 attendees
Oct 2010 - ASP.NET SIG - San Diego, CA
30 attendees
Oct 2010 - So Cal Code Camp - Los Angeles, CA
339 attendees (8 sessions)
Nov 2010 - Desert Code Camp - Chandler, AZ
77 attendees (3 sessions)
Jan 2011 - Inland Empire .NET User's Group - San Bernardino, CA
20 attendees
Jan 2011 - Disney .NET Developers Group - Burbank, CA
30 attendees
Jan 2011 - So Cal Code Camp - Fullerton, CA
145 attendees (3 sessions)
Feb 2011 - Disney .NET Developers Group - Burbank, CA
38 attendees
Feb 2011 - San Gabriel Valley .NET Developers Group - Monrovia, CA
20 attendees
Apr 2011 - Desert Code Camp, Chandler AZ
63 attendees (3 sessions)
Grand Total: 1,036!
I've had a great time speaking. Hopefully you've had a great time listening. If you'd like to have me come to your user group or other event, just drop me a note. As a reminder, if you've come to one of my sessions, you can download the session materials from my website: http://www.jeremybytes.com/Demos.aspx.
Happy Coding!
Here's a breakdown of my speaking engagements:
Jan 2010 - So Cal Code Camp - Fullerton, CA
135 attendees (3 sessions)
Feb 2010 - Disney .NET Developers Group - Burbank, CA
30 attendees
Jun 2010 - So Cal Code Camp - San Diego, CA
59 attendees (3 sessions)
Jul 2010 - LA C# User Group - Manhattan Beach, CA
20 attendees
Jul 2010 - So Cal .NET Developers Group - Buena Park, CA
25 attendees
Oct 2010 - ASP.NET SIG - San Diego, CA
30 attendees
Oct 2010 - So Cal Code Camp - Los Angeles, CA
339 attendees (8 sessions)
Nov 2010 - Desert Code Camp - Chandler, AZ
77 attendees (3 sessions)
Jan 2011 - Inland Empire .NET User's Group - San Bernardino, CA
20 attendees
Jan 2011 - Disney .NET Developers Group - Burbank, CA
30 attendees
Jan 2011 - So Cal Code Camp - Fullerton, CA
145 attendees (3 sessions)
Feb 2011 - Disney .NET Developers Group - Burbank, CA
38 attendees
Feb 2011 - San Gabriel Valley .NET Developers Group - Monrovia, CA
20 attendees
Apr 2011 - Desert Code Camp, Chandler AZ
63 attendees (3 sessions)
Grand Total: 1,036!
I've had a great time speaking. Hopefully you've had a great time listening. If you'd like to have me come to your user group or other event, just drop me a note. As a reminder, if you've come to one of my sessions, you can download the session materials from my website: http://www.jeremybytes.com/Demos.aspx.
Happy Coding!
Sunday, March 20, 2011
Desert Code Camp - April 2nd
Desert Code Camp in Chandler, Arizona is coming up quickly (Saturday, April 2, 2011). If you are in the Phoenix area -- or simply need an excuse to go for a road trip -- it's a great way to spend the day. I was able to attend last October, and I'm looking forward to going back again.
Talk to your fellow developers, get some free training, and make some great contacts. There are over 100 sessions on the schedule including a track just for kids.
Desert Code Camp 2011.1
April 2, 2011
Chandler, AZ
Hope to see you there!
Talk to your fellow developers, get some free training, and make some great contacts. There are over 100 sessions on the schedule including a track just for kids.
Desert Code Camp 2011.1
April 2, 2011
Chandler, AZ
Hope to see you there!
Thursday, February 24, 2011
Additional Links for Design Patterns
I've had some folks who have attended my Design Patterns session suggest some links that they have found useful. (And if you want to check out the session materials, just go to my website: Learn the Lingo: Design Patterns.)
Head First Labs - Head First Design Patterns
http://headfirstlabs.com/books/hfdp/
This is the link for the "Head First Design Patterns" book that I've recommended. And there's some really good news. I noted that the book is written with Java samples, but that it's not too hard for a C# developer to follow along. The good news is that the labs includes a link to a collection of C# samples. Just search for "C#" on the labs page, and you should find it.
Head First Design Patterns Study Group
http://onjava.com/pub/a/onjava/2005/04/06/designpatterns.html
The O'Reilly On Java website has suggestions on forming your own study group based on Head First Design Patterns. I've heard from some folks who have done this, and they found that it was a good learning experience for everyone involved. Discussion with other developers usually leads to new insights for everyone.
Do Factory - Design Pattern Framework 4
http://dofactory.com/Default.aspx
This site sells a product called Design Pattern Framework 4. As a disclaimer, I have not actually used this product, nor do I really know much about this. But I have received recommendations from session attendees, so it may be something worth looking into further. In going through the information, there is also an endorsement from Miguel Castro (who is one of the big players in the .NET community), so that leads me into wanting to look at this a little more closely.
If you've had experiences with either the Head First Design Patterns study group or using the Design Pattern Framework 4, please drop me a line and let me know what you think.
Happy Coding!
Head First Labs - Head First Design Patterns
http://headfirstlabs.com/books/hfdp/
This is the link for the "Head First Design Patterns" book that I've recommended. And there's some really good news. I noted that the book is written with Java samples, but that it's not too hard for a C# developer to follow along. The good news is that the labs includes a link to a collection of C# samples. Just search for "C#" on the labs page, and you should find it.
Head First Design Patterns Study Group
http://onjava.com/pub/a/onjava/2005/04/06/designpatterns.html
The O'Reilly On Java website has suggestions on forming your own study group based on Head First Design Patterns. I've heard from some folks who have done this, and they found that it was a good learning experience for everyone involved. Discussion with other developers usually leads to new insights for everyone.
Do Factory - Design Pattern Framework 4
http://dofactory.com/Default.aspx
This site sells a product called Design Pattern Framework 4. As a disclaimer, I have not actually used this product, nor do I really know much about this. But I have received recommendations from session attendees, so it may be something worth looking into further. In going through the information, there is also an endorsement from Miguel Castro (who is one of the big players in the .NET community), so that leads me into wanting to look at this a little more closely.
If you've had experiences with either the Head First Design Patterns study group or using the Design Pattern Framework 4, please drop me a line and let me know what you think.
Happy Coding!
Sunday, February 6, 2011
Upcoming Speaking Engagements
I have a couple of speaking engagements scheduled in February. Feel free to come out if you can.
Feburary 15, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.
February 16, 2011
San Gabriel Valley .NET Developers Group - Monrovia, CA
http://sgvdotnet.org/
Also, it looks like I'll be heading back to the Desert Code Camp on April 2, 2011 in Chandler, AZ. More information here: http://apr2011.desertcodecamp.com/
Hope to see you there! And if you have a user group or other event you'd like me to come speak at, just drop me a line and let me know: feedback@jeremybytes.com.
Happy Coding!
Feburary 15, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.
February 16, 2011
San Gabriel Valley .NET Developers Group - Monrovia, CA
http://sgvdotnet.org/
Also, it looks like I'll be heading back to the Desert Code Camp on April 2, 2011 in Chandler, AZ. More information here: http://apr2011.desertcodecamp.com/
Hope to see you there! And if you have a user group or other event you'd like me to come speak at, just drop me a line and let me know: feedback@jeremybytes.com.
Happy Coding!
Tuesday, February 1, 2011
Thank You for Coming!
I want to thank everyone who attended one of my sessions at the SoCal Code Camp this past weekend (and even those of you who were brave enough to attend more than one of my sessions). As a reminder, the Walkthroughs, Slides, and Code Samples are all available for download: http://www.jeremybytes.com/Demos.aspx.
If you have any questions, suggestions, or even session topics you'd like to see me present in the future, feel free to drop me a line at feedback@jeremybytes.com.
Until next time...
Happy Coding!
If you have any questions, suggestions, or even session topics you'd like to see me present in the future, feel free to drop me a line at feedback@jeremybytes.com.
Until next time...
Happy Coding!
Tuesday, January 18, 2011
Mini Review: Code - The Hidden Language of Computer Hardware and Software
I recently finished reading Code: the Hidden Language of Computer Hardware and Software by Charles Petzold. Here are a few quick thoughts:
This is not really a programming book; it is a description of how computers work. Designed for the layman, it starts off with the basics of codes (Morse Code, Braille, binary codes) and then moves on to how to communicate those codes using electro-mechanical relays (such as telegraph relays). From there, it talks about how these relays can be combined in various ways to create logical operations and built up to a simple adder -- the basic building block of computer hardware. The components are pieced together from the earliest computers to modern machines (well, almost modern -- the book was written in 1999). As a non-CS major, I found this book to be very approachable and it gave me a good understanding of how software can be turned into instructions for the hardware.
Overall, this was an interesting read. For me, it went quite quickly (just a few weeks in small chunks), and I have a better feel for how computer hardware works at its most basic level.
Happy Coding!
This is not really a programming book; it is a description of how computers work. Designed for the layman, it starts off with the basics of codes (Morse Code, Braille, binary codes) and then moves on to how to communicate those codes using electro-mechanical relays (such as telegraph relays). From there, it talks about how these relays can be combined in various ways to create logical operations and built up to a simple adder -- the basic building block of computer hardware. The components are pieced together from the earliest computers to modern machines (well, almost modern -- the book was written in 1999). As a non-CS major, I found this book to be very approachable and it gave me a good understanding of how software can be turned into instructions for the hardware.
Overall, this was an interesting read. For me, it went quite quickly (just a few weeks in small chunks), and I have a better feel for how computer hardware works at its most basic level.
Happy Coding!
Sunday, January 9, 2011
Update: Learn to Love Lambdas
Lambda Expressions have turned out to be a popular topic (I've got three presentations scheduled for January alone). With that in mind, I have expanded the Learn to Love Lambdas walkthrough and demo code.
Get It Here
You can get the complete walkthrough (18 pages) and code samples here:
http://www.jeremybytes.com/Demos.aspx#LLL
Direct Links:
PDF Walkthrough
Code Download
Happy Coding!
Get It Here
You can get the complete walkthrough (18 pages) and code samples here:
http://www.jeremybytes.com/Demos.aspx#LLL
Direct Links:
PDF Walkthrough
Code Download
Happy Coding!
Saturday, January 8, 2011
Quick Bytes: Get Func-y
If you look into the LINQ extension methods, you will run across Func quite a bit. If you see Func in a method definition, you can treat it like a big sign that says "Put your lambda expression here." This quick demo will show that Func is simply a shorthand for creating a delegate and that Func and lambdas go together hand-in-hand.
Get It Here
You can get the walkthrough (just 5 pages) and the code sample here: http://www.jeremybytes.com/demos.aspx#QBGF.
Direct Links:
PDF Walkthrough
Code Download
Happy Coding!
Get It Here
You can get the walkthrough (just 5 pages) and the code sample here: http://www.jeremybytes.com/demos.aspx#QBGF.
Direct Links:
PDF Walkthrough
Code Download
Happy Coding!
Monday, January 3, 2011
Book Review: Pro ASP.NET MVC 2 Framework
I just finished reading Pro ASP.NET MVC 2 Framework by Steven Sanderson (Apress). What I found was a good introduction to ASP.NET MVC as well as a deeper dive into the majority of the features.
This is labeled as "Intermediate to Advanced". It assumes that you are familiar with C# and .NET, but it doesn't expect you to be an ASP.NET WebForms programmer. If you are familiar with web technologies (HTML, CSS, Javascript), then you should be just fine. And although this is covering the 2nd version of the ASP.NET MVC framework, it does not assume that you have any prior knowledge of version 1.
There are several things I liked about this book. First, it is very approachable. The tone is inviting and easy to understand. Next, the code samples are thorough. Since ASP.NET MVC 2 can be used with either .NET 3.5 or .NET 4.0, it shows how to use the framework in either environment, and the differences are pointed out where the environments vary. Finally, the overall organization makes you want to read more.
Part 1 includes an introduction to ASP.NET MVC 2 and a sample application showing a real-world (although simplified) implementation of the framework. Since the MVC pattern lends itself to unit testing and test-driven development (TDD), the book also shows a few useful techniques including using dependency injection and mocking with unit testing. And to keep things more accessible, Sanderson uses free tools (such as NTest) for the examples since not all versions of Visual Studio include unit testing.
Part 2 takes all of the features that were introduced in Part 1 and goes into them in detail. This includes all of the core features of ASP.NET MVC including Routing, Controllers, Actions, Views, and Models. But going beyond just a description of using what's "in the box", the book also talks about how you can extend the framework yourself, such as by creating custom controller classes, filters, or even your own view engine. In addition, it gives a number of helpful techniques for putting together user interfaces including a trip into the world of AJAX and jQuery.
Part 3 covers some of the nitty-gritty details including Security and Deployment. This is where the world of ASP.NET MVC and WebForms starts to overlap. And this last part also goes through many of the features of the standard ASP.NET platform that you will want to make use of in your MVC applications.
Unlike my previous review of an ASP.NET MVC book, I highly recommend this book. The quality of the book is very high. There are few errors (no book is perfect) and the code samples are well done and complete. I have become a big fan of ASP.NET MVC. Although it is not the "best" or "only" way to write web applications, it is a great tool to have in the toolbox. I can think of a number of applications from my past that would have been much more elegant using ASP.NET MVC.
If you are curious and want to get started in the technology, Pro ASP.NET MVC2 Framework is a great way to go. Part 1 will give you a taste of the feature; Part 2 will take you through each one in depth; and Part 3 will show how MVC integrates with the rest of the ASP.NET framework.
Happy Coding!
This is labeled as "Intermediate to Advanced". It assumes that you are familiar with C# and .NET, but it doesn't expect you to be an ASP.NET WebForms programmer. If you are familiar with web technologies (HTML, CSS, Javascript), then you should be just fine. And although this is covering the 2nd version of the ASP.NET MVC framework, it does not assume that you have any prior knowledge of version 1.
There are several things I liked about this book. First, it is very approachable. The tone is inviting and easy to understand. Next, the code samples are thorough. Since ASP.NET MVC 2 can be used with either .NET 3.5 or .NET 4.0, it shows how to use the framework in either environment, and the differences are pointed out where the environments vary. Finally, the overall organization makes you want to read more.
Part 1 includes an introduction to ASP.NET MVC 2 and a sample application showing a real-world (although simplified) implementation of the framework. Since the MVC pattern lends itself to unit testing and test-driven development (TDD), the book also shows a few useful techniques including using dependency injection and mocking with unit testing. And to keep things more accessible, Sanderson uses free tools (such as NTest) for the examples since not all versions of Visual Studio include unit testing.
Part 2 takes all of the features that were introduced in Part 1 and goes into them in detail. This includes all of the core features of ASP.NET MVC including Routing, Controllers, Actions, Views, and Models. But going beyond just a description of using what's "in the box", the book also talks about how you can extend the framework yourself, such as by creating custom controller classes, filters, or even your own view engine. In addition, it gives a number of helpful techniques for putting together user interfaces including a trip into the world of AJAX and jQuery.
Part 3 covers some of the nitty-gritty details including Security and Deployment. This is where the world of ASP.NET MVC and WebForms starts to overlap. And this last part also goes through many of the features of the standard ASP.NET platform that you will want to make use of in your MVC applications.
Unlike my previous review of an ASP.NET MVC book, I highly recommend this book. The quality of the book is very high. There are few errors (no book is perfect) and the code samples are well done and complete. I have become a big fan of ASP.NET MVC. Although it is not the "best" or "only" way to write web applications, it is a great tool to have in the toolbox. I can think of a number of applications from my past that would have been much more elegant using ASP.NET MVC.
If you are curious and want to get started in the technology, Pro ASP.NET MVC2 Framework is a great way to go. Part 1 will give you a taste of the feature; Part 2 will take you through each one in depth; and Part 3 will show how MVC integrates with the rest of the ASP.NET framework.
Happy Coding!
Upcoming Speaking Engagements
I have several speaking engagements coming up in January. If you've always wanted to meet me in person, come on out. I'd love to meet you.
January 11, 2011
Inland Empire .NET User's Group - San Bernardino, CA
http://iedotnetug.org/
January 18, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.
January 29 - 30, 2011
So Cal Code Camp - Fullerton, CA
http://www.socalcodecamp.com/
Hope to see you there!
January 11, 2011
Inland Empire .NET User's Group - San Bernardino, CA
http://iedotnetug.org/
January 18, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.
January 29 - 30, 2011
So Cal Code Camp - Fullerton, CA
http://www.socalcodecamp.com/
Hope to see you there!
Subscribe to:
Posts (Atom)