After getting through a very busy March and April, things are a bit lighter in May. I have 3 events scheduled so far.
[Late Addition 4/28/2014]
Thursday, May 1, 2014
Bay.NET
San Francisco, CA
http://www.meetup.com/BayNET/events/179877642/
o IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces
It took me a long time to fully understand interfaces. I love showing people the how and why. This is a great first step for people planning on coming to the Education Day later in the week.
Saturday, May 3, 2014
Education Day
San Francisco, CA
http://www.eventbrite.com/e/clean-code-principles-patterns-and-practices-for-better-code-tickets-11345612031
o Clean Code: Principles, Patterns, and Practices for Better Code
This is a full day event with me and Theo Jungeblut. It should be a lot of fun, and I've already mentioned how much I'm looking forward to it.
Monday, May 5, 2014
Los Angeles .NET Developers Group
Los Angeles, CA
http://www.meetup.com/LADOTNET/events/178660642/
o Abstract Art: Getting Things "Just Right"
Abstraction is awesome. And abstraction is awful. The key to success is to find the balance -- to get the level of abstraction "just right" for your application. We'll learn how to recognize our natural tendencies toward abstraction and what we can do to keep ourselves from getting into trouble. This is a topic that is near and dear to me. I've had problems with too much abstraction (ack!) and too little abstraction (ugh!).
That's all I've got scheduled for now. If you have an event you'd like me to speak at, just drop me a note or send a request through INETA.
Happy Coding!
Sunday, April 27, 2014
Wednesday, April 23, 2014
Goodbye HTC, Hello HTC
I tend to hang on to my gadgets for a while. I'm not someone who jumps to the latest and greatest. But sometimes, we have to face facts that it's time to move on.
Goodbye HTC
It's time to say goodbye to my T-Mobile MyTouch Slide (by HTC):
It's been a great phone since I got it back in August 2010 (what's that in phone years?). It's never let me down. The battery life has been good. It makes phone calls. And I actually like the slider keyboard. Yes, I realize that keyboards are really uncool, but I came to this phone from a Blackberry.
On the down side, it's stuck on Android 2.2. The camera really sucked (like sucked so bad I would use it only in emergencies). The memory was constrained: I constantly had to clear Twitter data to free up space. And I had to keep deleting Google Play Services because every time it would update, it would use all the on-board storage. I also had the fear that it was just going to quit working. I replaced the screen at one point, didn't seal it up quite right, and now there's all sort of dust under the glass making it almost impossible to read in sunlight.
So, Goodbye HTC phone. You've served me well.
Hello HTC
What a difference 3-1/2 years makes:
This is the HTC One (M8), and it seems rather gigantic next to the MyTouch. It's got about twice as much screen real estate. And it seems really huge to me -- at least for now. I'm sure I'll get used to it.
The big advantages: it's running Android 4.4 (so, it should last me for a while). The camera doesn't suck. I still need to do some tests with the camera, but it looks pretty good so far. And even though I really love my LX3 (which took these pictures as well as the flower picture that I've got as my wallpaper), I don't carry it with me as much as I should. The primary rule of cameras: the best camera is the one you have with you.
Amazingly, it weighs about the same as the old phone. It's bigger, but thinner. And it doesn't feel awkward to carry in a pocket.
And even though it does seem big, I need to remember that I do have some pretty gigantic hands:
It almost looks like an IPhone 5 in a normal person's hands, huh?
So. Hello HTC phone. I'm looking forward to lots of time together.
Why Not Microsoft?
A big question you might ask is why didn't I pick a Windows Phone? After all, I make my living programming in the Microsoft environment.
This was a tough decision. I know a lot of people who have Windows Phones and are very happy with them. And I like the idea of running the same apps on all devices (phone, tablet, desktop, XBox). There were a couple of things that went into my decision.
First, there are a lot of things I like about Google. For my email, I have my own servers set up, but I forward it all to a GMail account. I use Google Calendar to track my appointments and trips. And I also use Google Voice for my business line.
These apps all worked well on my old phone. And the web apps work really well on my desktop. I realize that other providers (Microsoft and Apple) have these services as well. But I know the pros and cons of the one that I'm with now.
Next, I haven't gotten along well with my Surface 2 device. I haven't found good apps that work well with GMail and Google Calendar. And the touch version of Internet Explorer is terrible at interacting with the Google websites. Most importantly, I need to have a good Google Voice interface in the mobile world. The rumors are the Google Voice is going to be replaced with Hangouts functionality, but we're still waiting to see how that plays out. Either way, there doesn't seem to be much available for this on the Windows Phone platform.
Finally, I've heard a lot of good things about Google Now. I've already seen bits and pieces of this. When I have a flight confirmation in GMail, Google provides the current flight status, and offers to add it to my Calendar. As long as I have my data in the Google ecosystem, I might as well take advantage of it. (Yeah, I know, Siri and Cortana are promoting similar features.)
And I'm also looking to take advantage of G+ and Hangouts. I haven't really done much with these so far, and I'm looking for creative ways to use them to keep in touch with folks (and maybe offer some live presentations on-line).
Wrap Up
So, Goodbye HTC, and Hello HTC. If anything interesting happens, I'll be sure to let you know. But I'm expecting that the new phone to slide into my life with no major disruptions. The best technology is technology that stays out of the way. Fingers crossed.
Happy Coding!
Goodbye HTC
It's time to say goodbye to my T-Mobile MyTouch Slide (by HTC):
It's been a great phone since I got it back in August 2010 (what's that in phone years?). It's never let me down. The battery life has been good. It makes phone calls. And I actually like the slider keyboard. Yes, I realize that keyboards are really uncool, but I came to this phone from a Blackberry.
On the down side, it's stuck on Android 2.2. The camera really sucked (like sucked so bad I would use it only in emergencies). The memory was constrained: I constantly had to clear Twitter data to free up space. And I had to keep deleting Google Play Services because every time it would update, it would use all the on-board storage. I also had the fear that it was just going to quit working. I replaced the screen at one point, didn't seal it up quite right, and now there's all sort of dust under the glass making it almost impossible to read in sunlight.
So, Goodbye HTC phone. You've served me well.
Hello HTC
What a difference 3-1/2 years makes:
This is the HTC One (M8), and it seems rather gigantic next to the MyTouch. It's got about twice as much screen real estate. And it seems really huge to me -- at least for now. I'm sure I'll get used to it.
The big advantages: it's running Android 4.4 (so, it should last me for a while). The camera doesn't suck. I still need to do some tests with the camera, but it looks pretty good so far. And even though I really love my LX3 (which took these pictures as well as the flower picture that I've got as my wallpaper), I don't carry it with me as much as I should. The primary rule of cameras: the best camera is the one you have with you.
Amazingly, it weighs about the same as the old phone. It's bigger, but thinner. And it doesn't feel awkward to carry in a pocket.
And even though it does seem big, I need to remember that I do have some pretty gigantic hands:
It almost looks like an IPhone 5 in a normal person's hands, huh?
So. Hello HTC phone. I'm looking forward to lots of time together.
Why Not Microsoft?
A big question you might ask is why didn't I pick a Windows Phone? After all, I make my living programming in the Microsoft environment.
This was a tough decision. I know a lot of people who have Windows Phones and are very happy with them. And I like the idea of running the same apps on all devices (phone, tablet, desktop, XBox). There were a couple of things that went into my decision.
First, there are a lot of things I like about Google. For my email, I have my own servers set up, but I forward it all to a GMail account. I use Google Calendar to track my appointments and trips. And I also use Google Voice for my business line.
These apps all worked well on my old phone. And the web apps work really well on my desktop. I realize that other providers (Microsoft and Apple) have these services as well. But I know the pros and cons of the one that I'm with now.
Next, I haven't gotten along well with my Surface 2 device. I haven't found good apps that work well with GMail and Google Calendar. And the touch version of Internet Explorer is terrible at interacting with the Google websites. Most importantly, I need to have a good Google Voice interface in the mobile world. The rumors are the Google Voice is going to be replaced with Hangouts functionality, but we're still waiting to see how that plays out. Either way, there doesn't seem to be much available for this on the Windows Phone platform.
Finally, I've heard a lot of good things about Google Now. I've already seen bits and pieces of this. When I have a flight confirmation in GMail, Google provides the current flight status, and offers to add it to my Calendar. As long as I have my data in the Google ecosystem, I might as well take advantage of it. (Yeah, I know, Siri and Cortana are promoting similar features.)
And I'm also looking to take advantage of G+ and Hangouts. I haven't really done much with these so far, and I'm looking for creative ways to use them to keep in touch with folks (and maybe offer some live presentations on-line).
Wrap Up
So, Goodbye HTC, and Hello HTC. If anything interesting happens, I'll be sure to let you know. But I'm expecting that the new phone to slide into my life with no major disruptions. The best technology is technology that stays out of the way. Fingers crossed.
Happy Coding!
Tuesday, April 22, 2014
Education Day, San Francisco - May 3, 2014
My friend Theo Jungeblut and I are putting together a full day of awesome for Saturday, May 3, 2014 in San Francisco, CA.
Clean Code: Principles, Patterns, and Practices for Better Code
A big thanks to Bay.NET and Mathias Brandewinder for setting this up. I'm looking forward to a great event. Hope to see you there.
Happy Coding!
Clean Code: Principles, Patterns, and Practices for Better Code
You already code. Now it's time to take the next steps to becoming a better developer. Those steps are not difficult; we just need to put them into practice. The end result is code that is easier to maintain, easier to test, and easier to extend. Through lots of examples and hands-on labs, we'll learn about software design principles and the patterns that help us implement them. We'll see how Dependency Injection helps us create loosely-coupled code. And we'll spend a bit of time looking at Software Craftsmanship: ensuring that our code is readable by humans while still easy to maintain and test.This is a full day event. Cost is only $39, and that includes lunch. For full details and to register for the event, visit Eventbrite: Clean Code: Principles, Patterns, and Practices for Better Code.
A big thanks to Bay.NET and Mathias Brandewinder for setting this up. I'm looking forward to a great event. Hope to see you there.
Happy Coding!
Monday, April 21, 2014
Dependency Injection Questions
A friend of mine recently watched my Dependency Injection On-Ramp course on Pluralsight and sent me a few questions. In my experience, if one person has a question, there are probably other people with the same question. So, here are the questions and answers.
Note: these same questions/answers apply to my live presentation: Dependency Injection: A Practical Introduction.
Interfaces vs. Abstract Classes
Q: I see that interfaces are used with DI. Is there a reason abstract classes aren't used? Just wondering.
In the example, we create a repository interface so that we can add a layer of abstraction. Then we use constructor injection to get the repository into our view model class. Here's that code:
With this code, our view model does not need to know anything about the concrete repository types (so we can eliminate the coupling between the view model and those repositories). But there is nothing about Dependency Injection that limits us to using interfaces. In fact, in another part of the example, we inject a concrete class into our view:
Here we are injecting a concrete view model (MainWindowViewModel) into our view (MainWindow). For this, we do not get the same loose-coupling as we do with the repository example above. But Dependency Injection here still gives us some good advantages, namely adhering to the separation of concerns (SoC) and single responsibility principle (SRP). These principles often go hand in hand.
In this case, even though we need a compile time reference to the view model class, we have still freed the view from the responsibility of creating and managing the lifetime of the view model object. This means that creating the view model is not the responsibility of the view (separation of concerns) and the view can concentrate on what it does best -- providing the user interface for the application (it's single responsibility).
I guess I haven't answered the question yet (well, I've sort of answered it).
A: We can use whatever abstractions we like with Dependency Injection.
The type of abstraction is completely separate from dependency injection itself. That means we can use interfaces, abstract classes, or base classes. To make the decision, we'll just look at the pros and cons of using these types just like we do in our other code.
Specifically, interfaces are good where we do not have any shared code in the implementations (thus, no duplication). We can implement as many interfaces as we want, so we are not limited by single inheritance when we apply interfaces. And we're free to descend from another class if we want.
Abstract classes are good where we have shared code in the implementations. This lets us put the shared code into the abstract class and all of the child classes can use it (thus, no duplication). We are limited by single inheritance, so we cannot descend from an abstract class and another class at the same time.
If you want more information on how to make a decision between interfaces and abstract classes, you can check out my C# Interfaces course on Pluralsight, or reference the materials for my live presentation: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces.
Client Applications vs. Server Applications
Q: All of your examples are with a client app. Can this be used server side, too? I'm assuming yes.
In the examples, we use Dependency Injection to break the coupling between the layers in a WPF (desktop client) application. Specifically, we break the coupling between our view model (presentation) and repository (data access) so that we can more easily extend and test our application.
And we can get these same benefits server-side as well. So, the answer is...
A: Yes, of course.
Another of my presentations uses an ASP.NET MVC project as an example: Shields Up! Defensive Coding in C#.
This example has a custom controller factory that uses Ninject. Here's that code:
The details aren't all that important here. What we're doing is creating a custom ASP.NET MVC controller factory. This class uses Ninject to inject the repositories for the objects in our application. This allows us to easily swap out the repository (similar to our WPF example above).
For this particular example, I'm showing the dangers of SQL injection. So I have a SQL repository that is vulnerable to SQL injection and another repository that uses parameterized SQL (and thus, is not vulnerable to this specific attack). Using the IRepository abstraction along with Ninject allows me to swap this out very quickly in my demo.
Okay, so you're probably saying that isn't a "real" server application (although, the code is running on the IIS server, not the client machine). So, here's another example. This is taken from a lab for an upcoming Education Day (more info on this soon).
This is an application that is designed to run inside an automated job. It loads a file, parses the data, and outputs any errors to a log file. In this case, we want to isolate the data parsing code to make it easier to unit test. So instead of having a logger hard-coded in the parser, we use constructor injection:
This lets us use the file logger when we're running this in production on our server, but it's easy to swap out the logger for a mock during our unit testing. (In fact, this particular lab is all about how to make code easier to test.)
So we can get the benefits from Dependency Injection (extensibility, testability, maintainability, late binding, parallel development) whether we are working with client applications or server-side code.
More Advanced Ninject
Q: How would you use the CachingRepository decorator with a container such as Ninject?
In the example code, we start out pretty simply: we manually wire our application pieces together in the composition root of our application. Here's the example using the repository that uses a WCF SOAP service:
This is pretty straight forward since we're using constructor injection all the way down. We create a repository, pass it to the view model, and then pass the view model to the view.
Using a container eliminates some of these steps. Rather than wiring everything together, we just create a binding between the abstraction (IPersonRepository) and the concrete type (PersonServiceRepository):
So we tell Ninject that if someone asks for an IPersonRepository, we want to return a PersonServiceRepository (and the InSingletonScope means we only want one of these that gets re-used throughout our application). We let the dependency injection container (Ninject) take care of figuring everything else out.
But in the example, we also created this really cool caching repository. This wraps any existing repository and adds a client-side cache to it. This was pretty easy to wire up manually:
We start with our concrete repository (PersonServiceRepository), pass that to our caching repository, then pass that to our view model, then pass that to our view. We just snap the pieces together in a different order.
But what about using a container? We can't just associate the IPersonRepository with the CachingPersonRepository because it also needs an IPersonRepository as a parameter. It seems like we'd end up in an endless loop.
A: Ninject (and other DI containers) provide lots of advanced features to handle complex situations.
When we configure our container, we just need to supply a little more information:
The first part of the configuration is the same (Bind...To...InSingletonScope), but then we add some further instructions. In this case, we specify that the CachingPersonRepository has a constructor parameter called "personRepository". When Ninject comes across this parameter, it should supply a PersonServiceRepository.
This has the same effect as our manual code: it takes a PersonServiceRepository and wraps it in the caching repository.
What this shows is that it pays to spend some time with a particular DI container. Learn the ins-and-outs of what is available. There are tons of options.
Wrap Up
Dependency Injection is still one of my favorite topics. It's a powerful tool that can give us some good advantages in many situations. Like every tool, it is not appropriate everywhere. But if we understand what it is good for, then we can make sure we use it in the right situations.
I'm always open to answering questions about the topics that I speak about. There is no such thing as a stupid question. This is how we learn.
Happy Coding!
Note: these same questions/answers apply to my live presentation: Dependency Injection: A Practical Introduction.
Interfaces vs. Abstract Classes
Q: I see that interfaces are used with DI. Is there a reason abstract classes aren't used? Just wondering.
In the example, we create a repository interface so that we can add a layer of abstraction. Then we use constructor injection to get the repository into our view model class. Here's that code:
In this case, even though we need a compile time reference to the view model class, we have still freed the view from the responsibility of creating and managing the lifetime of the view model object. This means that creating the view model is not the responsibility of the view (separation of concerns) and the view can concentrate on what it does best -- providing the user interface for the application (it's single responsibility).
I guess I haven't answered the question yet (well, I've sort of answered it).
A: We can use whatever abstractions we like with Dependency Injection.
The type of abstraction is completely separate from dependency injection itself. That means we can use interfaces, abstract classes, or base classes. To make the decision, we'll just look at the pros and cons of using these types just like we do in our other code.
Specifically, interfaces are good where we do not have any shared code in the implementations (thus, no duplication). We can implement as many interfaces as we want, so we are not limited by single inheritance when we apply interfaces. And we're free to descend from another class if we want.
Abstract classes are good where we have shared code in the implementations. This lets us put the shared code into the abstract class and all of the child classes can use it (thus, no duplication). We are limited by single inheritance, so we cannot descend from an abstract class and another class at the same time.
If you want more information on how to make a decision between interfaces and abstract classes, you can check out my C# Interfaces course on Pluralsight, or reference the materials for my live presentation: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces.
Client Applications vs. Server Applications
Q: All of your examples are with a client app. Can this be used server side, too? I'm assuming yes.
In the examples, we use Dependency Injection to break the coupling between the layers in a WPF (desktop client) application. Specifically, we break the coupling between our view model (presentation) and repository (data access) so that we can more easily extend and test our application.
And we can get these same benefits server-side as well. So, the answer is...
A: Yes, of course.
Another of my presentations uses an ASP.NET MVC project as an example: Shields Up! Defensive Coding in C#.
This example has a custom controller factory that uses Ninject. Here's that code:
For this particular example, I'm showing the dangers of SQL injection. So I have a SQL repository that is vulnerable to SQL injection and another repository that uses parameterized SQL (and thus, is not vulnerable to this specific attack). Using the IRepository abstraction along with Ninject allows me to swap this out very quickly in my demo.
Okay, so you're probably saying that isn't a "real" server application (although, the code is running on the IIS server, not the client machine). So, here's another example. This is taken from a lab for an upcoming Education Day (more info on this soon).
This is an application that is designed to run inside an automated job. It loads a file, parses the data, and outputs any errors to a log file. In this case, we want to isolate the data parsing code to make it easier to unit test. So instead of having a logger hard-coded in the parser, we use constructor injection:
So we can get the benefits from Dependency Injection (extensibility, testability, maintainability, late binding, parallel development) whether we are working with client applications or server-side code.
More Advanced Ninject
Q: How would you use the CachingRepository decorator with a container such as Ninject?
In the example code, we start out pretty simply: we manually wire our application pieces together in the composition root of our application. Here's the example using the repository that uses a WCF SOAP service:
Using a container eliminates some of these steps. Rather than wiring everything together, we just create a binding between the abstraction (IPersonRepository) and the concrete type (PersonServiceRepository):
But in the example, we also created this really cool caching repository. This wraps any existing repository and adds a client-side cache to it. This was pretty easy to wire up manually:
But what about using a container? We can't just associate the IPersonRepository with the CachingPersonRepository because it also needs an IPersonRepository as a parameter. It seems like we'd end up in an endless loop.
A: Ninject (and other DI containers) provide lots of advanced features to handle complex situations.
When we configure our container, we just need to supply a little more information:
This has the same effect as our manual code: it takes a PersonServiceRepository and wraps it in the caching repository.
What this shows is that it pays to spend some time with a particular DI container. Learn the ins-and-outs of what is available. There are tons of options.
Wrap Up
Dependency Injection is still one of my favorite topics. It's a powerful tool that can give us some good advantages in many situations. Like every tool, it is not appropriate everywhere. But if we understand what it is good for, then we can make sure we use it in the right situations.
I'm always open to answering questions about the topics that I speak about. There is no such thing as a stupid question. This is how we learn.
Happy Coding!
Tuesday, April 15, 2014
I'm Back!
So, I haven't posted much for a while. That's because I've been travelling and speaking and talking to old friends and meeting new folks. I've got a bit of a "break", so I hope to catch up on some articles I've been meaning to get to. Overall, the last 6 weeks have been a lot of fun (and a bit tiring).
Here's a recap:
Pluralsight Author Summit
At the beginning of March, I was in Salt Lake City (UT) for the Pluralsight Author Summit. This was a great weekend of talking to the folks at Pluralsight and spending time with other authors from around the world. It was also great to see Pluralsight's commitment to education, and it makes me want to produce more courses. (Stay tuned; I'll be starting a new course soon.)
Code Camps
I also spoke at 2 Code Camps: Utah Code Camp in Salt Lake City (UT) and Desert Code Camp in Chandler (AZ). Both of these events were a lot of fun. It was my 2nd time at the Utah Code Camp, and it grew a lot in the last year. It was cool to meet some people who already knew me through my Pluralsight courses. And (as usual), I found some people I didn't know to have lunch with. It was a great facility with nice, big rooms. I had about 100 people in each of my presentations.
It was my 7th time out to Desert Code Camp. The weather in the Phoenix area is actually very pleasant in April and November. And since I've been out there so many times, I've got lots of friends. It was great to catch up with people I haven't seen for a while and to meet more new people.
Distant User Groups
I've been travelling for user groups as well. I went out to Las Vegas (NV) for dotNETGroup.org. That group is also growing, and I had a really great time talking about Dependency Injection. One of my favorite things is to see a group that has grown since the last time I spoke there. Getting more and more people involved in our developer community events makes us stronger as a whole.
And last week, I went up to Berkeley (CA) to speak at EastBay .NET. It turns out that Berkeley and Phoenix are the same distance from where I live in So Cal. I spent a couple days in the Bay Area and got to see some friends I haven't seen for a while. And I met new people as well. I ran into someone who came to the user group on the BART platform (Hi, Nicolay!), and we got to talk for a while.
Local User Groups
And I spoke at a bunch of local user groups as well (where "local" means Orange County, Los Angeles, San Bernardino, and San Diego -- basically, within 100 miles of where I live). I see the local folks a bit more often, but even so, I got to catch up with some folks I haven't seen for a few months.
In addition, the San Diego .NET Developers Group celebrated its 20th anniversary (and before you ask, it used to be a VB group). David McCarter has done some great things with the group over the years, and he invited some of the "founding fathers" to come and talk about the beginning of the group. In addition, he got Scott Hunter from Microsoft to come down and speak (pretty impressive since it was the same week as BUILD).
For a full listing (and links to a user group that may be near you), you can check out March Speaking Engagements and April Speaking Engagements.
I don't have anything scheduled for the next few weeks. But I'm working on some new events. In case you haven't figured it out yet, I love to speak -- actually, I love to teach and watch people learn. So, there will definitely be more to come.
Happy Coding!
Here's a recap:
Pluralsight Author Summit
At the beginning of March, I was in Salt Lake City (UT) for the Pluralsight Author Summit. This was a great weekend of talking to the folks at Pluralsight and spending time with other authors from around the world. It was also great to see Pluralsight's commitment to education, and it makes me want to produce more courses. (Stay tuned; I'll be starting a new course soon.)
Code Camps
I also spoke at 2 Code Camps: Utah Code Camp in Salt Lake City (UT) and Desert Code Camp in Chandler (AZ). Both of these events were a lot of fun. It was my 2nd time at the Utah Code Camp, and it grew a lot in the last year. It was cool to meet some people who already knew me through my Pluralsight courses. And (as usual), I found some people I didn't know to have lunch with. It was a great facility with nice, big rooms. I had about 100 people in each of my presentations.
It was my 7th time out to Desert Code Camp. The weather in the Phoenix area is actually very pleasant in April and November. And since I've been out there so many times, I've got lots of friends. It was great to catch up with people I haven't seen for a while and to meet more new people.
Distant User Groups
I've been travelling for user groups as well. I went out to Las Vegas (NV) for dotNETGroup.org. That group is also growing, and I had a really great time talking about Dependency Injection. One of my favorite things is to see a group that has grown since the last time I spoke there. Getting more and more people involved in our developer community events makes us stronger as a whole.
And last week, I went up to Berkeley (CA) to speak at EastBay .NET. It turns out that Berkeley and Phoenix are the same distance from where I live in So Cal. I spent a couple days in the Bay Area and got to see some friends I haven't seen for a while. And I met new people as well. I ran into someone who came to the user group on the BART platform (Hi, Nicolay!), and we got to talk for a while.
Local User Groups
And I spoke at a bunch of local user groups as well (where "local" means Orange County, Los Angeles, San Bernardino, and San Diego -- basically, within 100 miles of where I live). I see the local folks a bit more often, but even so, I got to catch up with some folks I haven't seen for a few months.
In addition, the San Diego .NET Developers Group celebrated its 20th anniversary (and before you ask, it used to be a VB group). David McCarter has done some great things with the group over the years, and he invited some of the "founding fathers" to come and talk about the beginning of the group. In addition, he got Scott Hunter from Microsoft to come down and speak (pretty impressive since it was the same week as BUILD).
For a full listing (and links to a user group that may be near you), you can check out March Speaking Engagements and April Speaking Engagements.
I don't have anything scheduled for the next few weeks. But I'm working on some new events. In case you haven't figured it out yet, I love to speak -- actually, I love to teach and watch people learn. So, there will definitely be more to come.
Happy Coding!