I have a new video available on YouTube: Anatomy of a Lambda Expression.
Lambda Expressions mystified me for a long time. I was working with them for about 6 months before I had the "light bulb moment" when I really understood how they worked. Since then, I've been trying to help people skip that 6 months of mystery.
Anatomy of a Lambda Expression is a 10 minute explanation of some of the syntactic curiosities that make lambdas really cool and a bit difficult to grasp. We walk through the process of turning a named delegate into an anonymous delegate into a lambda expression. It's a lot easier than it sounds.
And if you want more information on lambda expressions, be sure to check out the materials on my website: Learn to Love Lambdas.
Happy Coding!
Saturday, August 31, 2013
Friday, August 30, 2013
More Cool Stuff
So, my C# Interfaces course on Pluralsight did really well in its first month. Since it was in the Top 10 for the month of July, I was awarded the Pluralsight Crystal Microphone.
The thing that makes this really cool is knowing how many people have watched my C# Interfaces course and have been able to learn from it. It's great to be able to reach so many people that I'll never be able to meet in person (although I would like to -- if you see me at an event, be sure to let me know if you've watched one of my courses).
Happy Coding!
Happy Coding!
Wednesday, August 28, 2013
September Speaking Engagements
I've got 2 speaking engagements currently scheduled for September. Be sure to stop by if you can make it.
Tuesday, September 3, 2013
LA C# User Group
Pasadena, CA
http://www.lacsharp.org
Topic: Clean Code: Homicidal Maniacs Read Code, Too!
Wednesday, September 4, 2013
SoCal .NET Developers Group
Buena Park, CA
http://www.socaldotnet.com/
Topic: Clean Code: Homicidal Maniacs Read Code, Too!
Clean Code is still a very popular topic (it's one of those things that will never go out of style). One of the best things about writing clean code is that it shows that you actually care about the quality of the work that you produce. The code we write is part of our legacy, and we should take pride in that.
If you'd like me to come speak at your event, be sure to drop me a line. I speak at both public and private events, and I'll be glad to tailor my talk to your specific needs. I specialize in making intermediate programming topics approachable to developers of all skill levels. And we always have a lot of fun along the way.
Happy Coding!
Tuesday, September 3, 2013
LA C# User Group
Pasadena, CA
http://www.lacsharp.org
Topic: Clean Code: Homicidal Maniacs Read Code, Too!
Wednesday, September 4, 2013
SoCal .NET Developers Group
Buena Park, CA
http://www.socaldotnet.com/
Topic: Clean Code: Homicidal Maniacs Read Code, Too!
Clean Code is still a very popular topic (it's one of those things that will never go out of style). One of the best things about writing clean code is that it shows that you actually care about the quality of the work that you produce. The code we write is part of our legacy, and we should take pride in that.
If you'd like me to come speak at your event, be sure to drop me a line. I speak at both public and private events, and I'll be glad to tailor my talk to your specific needs. I specialize in making intermediate programming topics approachable to developers of all skill levels. And we always have a lot of fun along the way.
Happy Coding!
Tuesday, August 20, 2013
More Pluralsight Courses Coming - What Topics Do You Want to See?
I've recently published 2 Pluralsight courses: one on C# Interfaces and one on the BackgroundWorker Component (also check my Pluralsight author page).
I'm working on more courses over the coming months. Currently in progress: Design Patterns On-Ramp. The goal of this course is to get comfortable with Design Patterns and see that we already use patterns everyday even if we don't realize it. This is a gentle introduction to get you ready for a deeper dive into the topic.
Be sure to check back; I'll post more information once this course is published.
What Topics Do You Want to See?
I have several slots to fill in my schedule. So what topics would you like to see me put into a Pluralsight course? Leave your suggestions in the comments, and I'll take them under consideration. In addition to a topic, try to include a specific angle. For example: "Design Patterns for the everyday developer".
I'm not an expert in everything, and topics that I speak and write about are technologies or principles that I've worked with in production code. In addition, the Pluralsight library is quite extensive; many topics are already covered. So don't be surprised if your topic is not selected; it's nothing personal.
I'm looking forward to hearing your suggestions.
Happy Coding!
I'm working on more courses over the coming months. Currently in progress: Design Patterns On-Ramp. The goal of this course is to get comfortable with Design Patterns and see that we already use patterns everyday even if we don't realize it. This is a gentle introduction to get you ready for a deeper dive into the topic.
Be sure to check back; I'll post more information once this course is published.
What Topics Do You Want to See?
I have several slots to fill in my schedule. So what topics would you like to see me put into a Pluralsight course? Leave your suggestions in the comments, and I'll take them under consideration. In addition to a topic, try to include a specific angle. For example: "Design Patterns for the everyday developer".
I'm not an expert in everything, and topics that I speak and write about are technologies or principles that I've worked with in production code. In addition, the Pluralsight library is quite extensive; many topics are already covered. So don't be surprised if your topic is not selected; it's nothing personal.
I'm looking forward to hearing your suggestions.
Happy Coding!
Sunday, August 18, 2013
Do I Really Need a Repository?
I use the Repository pattern in a number of my presentations, whether talking about Interfaces, Generics, or Dependency Injection. The primary reason I use this is because it's a very easy problem to describe: we need to access data from different data sources (Web Service, SQL, Oracle, NoSQL, XML, CSV), and we want to keep the complexity out of our core application code.
But the question often comes up: Do I really need a Repository in my application?
And I'll give my standard answer: It depends.
Let's take a closer look at the Repository pattern and how it fits (or doesn't fit) with some scenarios that I've dealt with.
What is a Repository?
We'll start with a definition of the Repository pattern:
This means that from our application code, we simply call "Repository.GetPeople()" to get a collection of Person objects from the data store. Our application code does not need to know what's on the other side of that "GetPeople" call. It could be a SQL query; it could be a service call; it could be reading from a local file. The application is insulated from that knowledge.
[Editor's Note: For more exploration of Repositories, see "Applying the Interface Segregation Principle to a Repository".]
But do we really need this in our application?
Add Abstraction as You Need It
Developers generally fall into two groups: over-abstractors and under-abstractors. Neither group is better than the other; they are just natural tendencies. But the challenge for both groups is to find just the right level of abstraction which is generally somewhere in-between. (For a closer look, see Abstraction: The Goldilocks Principle.)
By nature, I am an under-abstractor. This is because early in my career, I supported an application that was severely over-abstracted. The application was extremely difficult to maintain, and even the senior devs had trouble getting expected behavior out of the code base. So, my first inclination is to limit abstraction as much as possible.
But I've learned some good lessons over the years, which included creating an under-abstracted application that was difficult to maintain. So now I'm always looking to find the balance. Here is the best advice that I've come across so far:
How does this apply to repositories?
Add a Repository When You Need It
A Repository is a layer of abstraction. So, let's look at some times when we might or might not need an explicit repository.
Scenario 1: No Repository
I worked for many years in corporate development in a fixed environment. All of our custom-built applications used Microsoft SQL Server for data. That was it. And having that consistency made it very easy to support our application portfolio.
But what this also meant is that we did not usually need an explicit Repository. It was very unlikely that we would swap out the data storage layer; it was always SQL Server. So, we did not have a repository.
Now, even though we didn't have a physical repository layer, we still kept all of our data access code nicely corralled. We did not have SQL queries scattered across the code base; we kept them in well-defined parts of our business layer.
Scenario 2: Repository
But there was a time when I needed to add a Repository. One of my applications imported data from a third-party application. That application was going through an upgrade and some changes. One of those changes was switching from Microsoft SQL Server to an Oracle Database.
So, for this application, I added a Repository layer. This allowed me to prepare the application for the switch-over once that third-party application went into production. Based on a configuration change, I could switch the application from using a SQL Server repository to an Oracle repository. This meant that I could develop, test, and deploy my updated code before the switch-over happened. And the upgrade process went very smoothly.
Scenario 3: Maybe Repository
Another reason we may want to add a repository is to facilitate automated testing. With a repository layer in place, it's easy to swap out a fake or mock repository that we can use for testing. But whether we need this will be based on how our objects are laid out.
For example, we may be working with smart-entities; a smart-entity is basically a collection of properties with retrieval and update capabilities. In this case, there really isn't anything to test. The data access methods populate the properties and update the data store. Since we don't really have any logic to test in these entities, we would not get much advantage by adding a repository layer.
On the other hand, we may be working with robust business objects; a robust business object is one which has business logic (business rules and validation) built in. In this case, we do have logic that we want to check in automated tests. A repository layer would make those tests easier, so we would get an advantage from that.
Wrap Up
Do we really need to have a repository in our application? It depends. A repository is a layer of abstraction. If we add abstraction where we don't need it, then we add unnecessary complexity to our application. So, let's add abstraction as we need it.
We've seen two main reasons why we may want to add a repository layer: (1) to swap-out data access code for different data stores, and (2) to facilitate unit testing. If either of these apply, then we should consider adding a repository.
I use the Repository pattern in my presentations because it is an easily-understandable abstraction. But whether we actually need it in our own applications depends on our environment. In most of the applications I've written, I have not needed it. But in the few where I have needed it, it has been a great asset.
Happy Coding!
But the question often comes up: Do I really need a Repository in my application?
And I'll give my standard answer: It depends.
Let's take a closer look at the Repository pattern and how it fits (or doesn't fit) with some scenarios that I've dealt with.
What is a Repository?
We'll start with a definition of the Repository pattern:
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
[Fowler, et al. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.]The idea behind having a repository is to insulate the application from the data access code. Here's a fairly typical interface that shows a CRUD (Create, Read, Update, Delete) repository:
This means that from our application code, we simply call "Repository.GetPeople()" to get a collection of Person objects from the data store. Our application code does not need to know what's on the other side of that "GetPeople" call. It could be a SQL query; it could be a service call; it could be reading from a local file. The application is insulated from that knowledge.
[Editor's Note: For more exploration of Repositories, see "Applying the Interface Segregation Principle to a Repository".]
But do we really need this in our application?
Add Abstraction as You Need It
Developers generally fall into two groups: over-abstractors and under-abstractors. Neither group is better than the other; they are just natural tendencies. But the challenge for both groups is to find just the right level of abstraction which is generally somewhere in-between. (For a closer look, see Abstraction: The Goldilocks Principle.)
By nature, I am an under-abstractor. This is because early in my career, I supported an application that was severely over-abstracted. The application was extremely difficult to maintain, and even the senior devs had trouble getting expected behavior out of the code base. So, my first inclination is to limit abstraction as much as possible.
But I've learned some good lessons over the years, which included creating an under-abstracted application that was difficult to maintain. So now I'm always looking to find the balance. Here is the best advice that I've come across so far:
Add abstraction as you need it.And this literally means "as you need it", not "because you think you might need it at some point in the future." This has helped keep me out of a lot of trouble, and it's also helped me when working with teammates who are over-abstractors by nature.
How does this apply to repositories?
Add a Repository When You Need It
A Repository is a layer of abstraction. So, let's look at some times when we might or might not need an explicit repository.
Scenario 1: No Repository
I worked for many years in corporate development in a fixed environment. All of our custom-built applications used Microsoft SQL Server for data. That was it. And having that consistency made it very easy to support our application portfolio.
But what this also meant is that we did not usually need an explicit Repository. It was very unlikely that we would swap out the data storage layer; it was always SQL Server. So, we did not have a repository.
Now, even though we didn't have a physical repository layer, we still kept all of our data access code nicely corralled. We did not have SQL queries scattered across the code base; we kept them in well-defined parts of our business layer.
Scenario 2: Repository
But there was a time when I needed to add a Repository. One of my applications imported data from a third-party application. That application was going through an upgrade and some changes. One of those changes was switching from Microsoft SQL Server to an Oracle Database.
So, for this application, I added a Repository layer. This allowed me to prepare the application for the switch-over once that third-party application went into production. Based on a configuration change, I could switch the application from using a SQL Server repository to an Oracle repository. This meant that I could develop, test, and deploy my updated code before the switch-over happened. And the upgrade process went very smoothly.
Scenario 3: Maybe Repository
Another reason we may want to add a repository is to facilitate automated testing. With a repository layer in place, it's easy to swap out a fake or mock repository that we can use for testing. But whether we need this will be based on how our objects are laid out.
For example, we may be working with smart-entities; a smart-entity is basically a collection of properties with retrieval and update capabilities. In this case, there really isn't anything to test. The data access methods populate the properties and update the data store. Since we don't really have any logic to test in these entities, we would not get much advantage by adding a repository layer.
On the other hand, we may be working with robust business objects; a robust business object is one which has business logic (business rules and validation) built in. In this case, we do have logic that we want to check in automated tests. A repository layer would make those tests easier, so we would get an advantage from that.
Wrap Up
Do we really need to have a repository in our application? It depends. A repository is a layer of abstraction. If we add abstraction where we don't need it, then we add unnecessary complexity to our application. So, let's add abstraction as we need it.
We've seen two main reasons why we may want to add a repository layer: (1) to swap-out data access code for different data stores, and (2) to facilitate unit testing. If either of these apply, then we should consider adding a repository.
I use the Repository pattern in my presentations because it is an easily-understandable abstraction. But whether we actually need it in our own applications depends on our environment. In most of the applications I've written, I have not needed it. But in the few where I have needed it, it has been a great asset.
Happy Coding!
Tuesday, August 13, 2013
Book Review: Pro ASP.NET MVC 4
It's been a while since my last book review, and there are a couple of reasons for that. First, I've been really busy this summer (between speaking engagements and producing 2 Pluralsight courses). And second, because I picked a 700 page book as my next read: Pro ASP.NET MVC 4 by Adam Freeman (Amazon link). The good news is that this was a very good read.
Two Parts
I really like the layout of this book. It's split into two primary parts.
Part 1 covers the first 300 pages: Introducing ASP.NET MVC 4. After some introductory chapters (about the MVC pattern, the Razor view engine, and some other tools), Freeman leads us through the process of building an on-line store. During each of these steps, more and more features are explored through the code. This includes things like strongly-typed views, controllers and actions, routing, dependency injection, validation, and security.
These are all "just enough" explanation to get the application to do what we need it to do. This seems like a very relevant example, and I found it helpful to follow along (sometimes typing things in and sometimes just going through the code for the completed project -- although I'll admit to having a run-in with Entity Framework not behaving as I expected it to).
Part 2 is the rest of the book and dives into the details. This makes for an excellent reference and covers pretty much all of the topics: URL Routing, Controllers, Actions, Filters, Views, Helper Methods, Model Binding, Model Validation, and Bundles.
Each of these chapters starts out by looking at the standard "in-the-box" functionality and then goes on to show how you can either customize the behavior or completely replace it with your own objects. Another thing I like is relevant warnings. For example, there may be a section that shows how to put validation into the Controller, but then emphasizes that it probably doesn't belong there; it really belongs in the Model itself or through custom model binding (in order to preserve the separation of concerns recommended by the MVC pattern).
Some Complaints (not mine)
I want to address some complaints that have shown up in some reviews. But first, we need a little history. I own Pro ASP.NET MVC 2 Framework by Steven Sanderson. This is the 2nd edition of this same book.
[Editor's Note: I actually did a review of this book in 2011: Book Review: Pro ASP.NET MVC 2 Framework]
Next comes, Pro ASP.NET MVC 3 Framework by Steven Sanderson and Adam Freeman. This is the 3rd edition (which I do not have). There were some complaints that the 2nd and 3rd editions had much of the same material and didn't really show the differences in the versions. Personally, I don't have a problem with that. I see this as a reference for whatever current version is referred to. There are other references to see "What's New in MVC 3" or whatever.
Pro ASP.NET MVC 4 by Adam Freeman (the book we're looking at here) is the 4th edition. This has a lot of duplicated information from previous editions (the Sports Store example is the same example as was used in the MVC 2 book, but with some obvious updates for the new features). As mentioned above, I don't see the duplication as a drawback -- this is a 700 page reference book.
A Few Quirks
With that said, there are a few quirks to the book that are minorly distracting. This is to be expected in any technical book of this size; however, since this is the 4th edition, I would have hoped that more of these would be worked out.
One strange thing is that it looks like there was a search-and-replace done for several words to facilitate the diagrams and code samples. For example, in Chapter 16, there is a sentence with the phrase "...which isn't suiTable 16-for all action methods." I'm sure this should read "...which isn't suitable for all action methods", but the word "table" was replaced with "Table 16-". This also happened with "figure" as in "... you can conFigure 17-the settings of the default factory..."
Another quirk has to do with the history of the book. As mentioned above, the 3rd edition was co-authored by Adam Freeman and Steven Sanderson. A few vestiges still exist in the 4th edition. For example, there are a few places that say, "We both agree that..." which seems a little strange if you don't know the history of the book. In addition, other books by both Freeman and Sanderson are referenced for more details. Again, it seems a little strange based on the "voice" of the author.
But none of these items would keep me from recommending this book.
Wrap Up
Pro ASP.NET MVC 4 is a complete reference of the MVC framework. I really like the practical walk-through example that takes up Part 1 of the book. And I also like the deeper dives into each feature that is covered in Part 2. It's nice to know that I can replace the view engine if I really want to (although I really don't see that happening for me).
I'm a big fan of ASP.NET MVC (especially since I spent so much time working/fighting with WebForms). It's nice to see that many of the features (such as URL Routing and Script Bundling) are making their way into the base ASP.NET libraries so that we can use them regardless of how we build our websites.
In the near future, I need to revamp my website. ASP.NET MVC is definitely a contender technology. But I may simply use it as a framework to deploy a mainly HTML/JavaScript site. We'll see what happens. One of the big challenges is to create some "pretty" URLs without breaking any of the existing links that I have scattered across the internet.
But back on topic, if you need a reference for ASP.NET MVC, I would definitely recommend this book.
Happy Coding!
Two Parts
I really like the layout of this book. It's split into two primary parts.
Part 1 covers the first 300 pages: Introducing ASP.NET MVC 4. After some introductory chapters (about the MVC pattern, the Razor view engine, and some other tools), Freeman leads us through the process of building an on-line store. During each of these steps, more and more features are explored through the code. This includes things like strongly-typed views, controllers and actions, routing, dependency injection, validation, and security.
These are all "just enough" explanation to get the application to do what we need it to do. This seems like a very relevant example, and I found it helpful to follow along (sometimes typing things in and sometimes just going through the code for the completed project -- although I'll admit to having a run-in with Entity Framework not behaving as I expected it to).
Part 2 is the rest of the book and dives into the details. This makes for an excellent reference and covers pretty much all of the topics: URL Routing, Controllers, Actions, Filters, Views, Helper Methods, Model Binding, Model Validation, and Bundles.
Each of these chapters starts out by looking at the standard "in-the-box" functionality and then goes on to show how you can either customize the behavior or completely replace it with your own objects. Another thing I like is relevant warnings. For example, there may be a section that shows how to put validation into the Controller, but then emphasizes that it probably doesn't belong there; it really belongs in the Model itself or through custom model binding (in order to preserve the separation of concerns recommended by the MVC pattern).
Some Complaints (not mine)
I want to address some complaints that have shown up in some reviews. But first, we need a little history. I own Pro ASP.NET MVC 2 Framework by Steven Sanderson. This is the 2nd edition of this same book.
[Editor's Note: I actually did a review of this book in 2011: Book Review: Pro ASP.NET MVC 2 Framework]
Next comes, Pro ASP.NET MVC 3 Framework by Steven Sanderson and Adam Freeman. This is the 3rd edition (which I do not have). There were some complaints that the 2nd and 3rd editions had much of the same material and didn't really show the differences in the versions. Personally, I don't have a problem with that. I see this as a reference for whatever current version is referred to. There are other references to see "What's New in MVC 3" or whatever.
Pro ASP.NET MVC 4 by Adam Freeman (the book we're looking at here) is the 4th edition. This has a lot of duplicated information from previous editions (the Sports Store example is the same example as was used in the MVC 2 book, but with some obvious updates for the new features). As mentioned above, I don't see the duplication as a drawback -- this is a 700 page reference book.
A Few Quirks
With that said, there are a few quirks to the book that are minorly distracting. This is to be expected in any technical book of this size; however, since this is the 4th edition, I would have hoped that more of these would be worked out.
One strange thing is that it looks like there was a search-and-replace done for several words to facilitate the diagrams and code samples. For example, in Chapter 16, there is a sentence with the phrase "...which isn't suiTable 16-for all action methods." I'm sure this should read "...which isn't suitable for all action methods", but the word "table" was replaced with "Table 16-". This also happened with "figure" as in "... you can conFigure 17-the settings of the default factory..."
Another quirk has to do with the history of the book. As mentioned above, the 3rd edition was co-authored by Adam Freeman and Steven Sanderson. A few vestiges still exist in the 4th edition. For example, there are a few places that say, "We both agree that..." which seems a little strange if you don't know the history of the book. In addition, other books by both Freeman and Sanderson are referenced for more details. Again, it seems a little strange based on the "voice" of the author.
But none of these items would keep me from recommending this book.
Wrap Up
Pro ASP.NET MVC 4 is a complete reference of the MVC framework. I really like the practical walk-through example that takes up Part 1 of the book. And I also like the deeper dives into each feature that is covered in Part 2. It's nice to know that I can replace the view engine if I really want to (although I really don't see that happening for me).
I'm a big fan of ASP.NET MVC (especially since I spent so much time working/fighting with WebForms). It's nice to see that many of the features (such as URL Routing and Script Bundling) are making their way into the base ASP.NET libraries so that we can use them regardless of how we build our websites.
In the near future, I need to revamp my website. ASP.NET MVC is definitely a contender technology. But I may simply use it as a framework to deploy a mainly HTML/JavaScript site. We'll see what happens. One of the big challenges is to create some "pretty" URLs without breaking any of the existing links that I have scattered across the internet.
But back on topic, if you need a reference for ASP.NET MVC, I would definitely recommend this book.
Happy Coding!
Tuesday, August 6, 2013
New Pluralsight Course: Introduction to the .NET BackgroundWorker Component
I'm happy to announce that my new Pluralsight course is now available: Introduction to the .NET BackgroundWorker Component.
The BackgroundWorker component is one of my favorite little tools. It does a great job of keeping the UI responsive by moving a long-running process onto another thread. It also includes progress reporting, cancellation support, and error handling -- all in an easy-to-use package.
Introduction to the .NET BackgroundWorker Component
Happy Coding!
The BackgroundWorker component is one of my favorite little tools. It does a great job of keeping the UI responsive by moving a long-running process onto another thread. It also includes progress reporting, cancellation support, and error handling -- all in an easy-to-use package.
Introduction to the .NET BackgroundWorker Component
Keep your UI responsive. If we're not careful, a long-running process will cause our application to "lock up". The BackgroundWorker component gives us an easy-to-use solution by moving that long-running process off of our UI thread. We'll see how the BackgroundWorker component can keep our WinForms, WPF, or Silverlight UI responsive and also explore features such as progress reporting, cancellation, and error handling. After that, we'll see how easily the BackgroundWorker component fits in with an application using the Model-View-ViewModel (MVVM) pattern. And finally, we'll compare the BackgroundWorker component to the Task Parallel Library to make sure we're using the right tool for the job.After watching this (short) course, you will know everything there is to know about the BackgroundWorker component (yes, it really is that simple). Here are the modules:
- BackgroundWorker Overview
Here, we take a look at the problem the BackgroundWorker solves: a non-responsive UI due to a long-running process. Then we see the basics of using the BackgroundWorker component in a WinForms application and in a WPF application. - Progress, Cancellation, and Error Handling
We take a deeper dive into the features including progress reporting, cancellation, and error handling. We see that the component handles communication between the threads for us, so we don't need to worry about those details. - BackgroundWorker and MVVM
How does the BackgroundWorker component fit in with an application that uses the Model-View-ViewModel (MVVM) design pattern? Very well, actually. MVVM applications have the same potential issue (a long-running process that locks up the UI), so we can use the same solution: the BackgroundWorker component. - BackgroundWorker vs. Task
Finally, we replicate the BackgroundWorker component functionality using the Task Parallel Library (TPL). What we find is that all of the functionality is there, but sometimes it's easier to use a specific-purpose tool (the BackgroundWorker) than a general-purpose tool (the TPL).
Happy Coding!