Saturday, April 25, 2015

New Video: Deciphering the LINQ Join Method

I really love using the fluent syntax with LINQ. This gives me full access to all of the very useful extension methods.

In Part 2 of the Lambdas & LINQ video series, we took some time to understand the parameters of the Where method and also OrderBy. After seeing this, folks sometimes ask me: "What about Join?"

And why do they ask this question? Because this is the method signature:


But when we break things down, it's nothing that we haven't seen before. And that's exactly what we do in my latest video: Deciphering the Join Method.

If you'd rather have a text version, check out this article: The LINQ Join Method: Deciphering the Parameters.

And find the other videos, links to code on GitHub, PDF walkthroughs, and other articles here: Learn to Love Lambdas (and LINQ, Too)

I'm looking to produce other videos based on my articles (so that different folks can learn in the way that works best for them). If you have a favorite topics that you'd like to see put into video, let me know.

Happy Coding!

Monday, April 20, 2015

New Video: Captured Variables & for Loops

Captured variables are a really cool feature of lambda expressions. But it can also be dangerous if we try to capture the indexer of a "for" loop.

In my latest video, we take a look at the problem that we run into when we try to capture an indexer. And we'll also see how easy it is to get around the problem. There's just one thing we need to keep in mind:
The value of a captured variable is the value at the time it is used, not the value at the time it is captured.
And if you need a reminder of what captured variables are, be sure to check out Part 1 of the Lambdas & LINQ series: Lambda Expression Basics.

If you'd rather read about this problem (and solution), check out this article: Lambda Expressions, Captured Variables, and for Loops: A Dangerous Combination.

Otherwise, watch it here (or on YouTube):

There's also a playlist to watch all of the videos in the series: Lambda Expressions and LINQ in C#.

For more links, articles, and to find the code on GitHub, check out Learn to Love Lambdas (and LINQ, Too) on my website.

Let me know if you like the videos. If so, there will be lots more coming. But don't worry, the articles will keep coming as well. Some people like text, and some people like video. I'm glad to provide both where I can.

Happy Coding!

Wednesday, April 15, 2015

Users Don't Fail; Designers Do

It's really easy to feel like a failure as a user: maybe we can't find a piece of information on a website; maybe we can't figure out how to enter some data; maybe we can't open a door.
Whenever you feel like a failure as a user, remember that you didn't fail, the designer did.

And this holds true when we are the developers: Our users don't fail; we do.
I've come across a few things that have made me think about this lately, and I'll talk about those in a bit. First, I need to tell a story about how I felt like a failure as a user.

Jeremy Gets Trapped on a Balcony
Several years ago, I was attending a convention at a local convention center. As often happens while working in tech, some issues came up at work. As I was walking along the hallway on the 2nd floor of the convention center, I got a phone call. So I answered the phone and headed outside to the balcony to take the call.

I was only out there a couple of minutes. But I ran into a problem when I tried to get back into the convention center. I grabbed the door handle, and the door didn't move. Crap, locked.

I grabbed the other door handle and tried it. Locked. Maybe I wasn't supposed to go out that door.

So I tapped on the glass to get the attention of someone inside. And I motioned for them to come open the door for me.

He looked at me, and while motioning with his arms, he said a single word: "Push".

Thinking About Affordances
So what makes me think about one of the not proudest moments of my life? I'll blame it on listening to a recent episode of .NET Rocks! UX Thoughts with Danielle Cooley.

I had the opportunity to meet Danielle (@dgcooley and at the Nebraska.Code() event last month. User Experience (UX) is a topic that I've been interested in for a long time (you can see some of the books I've read on my website), so I was happy to have a chance to talk to someone who specializes in UX research and how humans behave. We had a good conversation at one of the evening get-togethers and shared experiences.

And I was reminded of my "failure" while listening to .NET Rocks!, first because she mentioned how users don't fail, designers do (and "designer" is whoever is doing the design -- probably a developer in a lot of cases). I was also reminded of a book that was *not* mentioned in the episode but is one of my favorite design books: The Design of Everyday Things by Donald A. Norman (Amazon link).

Norman mentions the idea of "affordances". He deals primarily with things in the physical world, and affordances are those clues that tell a person how something is supposed to be used. This can be the materials, the shape, the position of buttons or handles, or any other aspects of how an object presents itself to a potential user.

I really enjoyed reading this book, and it makes me look at things in the world in a different way. (I have the 2002 edition; I didn't realize there is a 2013 expanded edition, so I guess I need to pick that up.)

And if you're curious about the item on the cover of the book, this is based on the "Coffeepot for Masochists" designed by Jacques Carelman.

Norman's book contains a section about affordances on doors in popular architecture and how they can often fail the people who have to use them. And that's what leads back to my "failure" to use a door properly.

Analyzing the Failure
As you can imagine, as soon as I heard the word "Push", I was rather embarrassed. A simple push on the door freed me from my trap. And I could feel my cheeks start to burn.

Soon after, the analysis began: How did I get myself into that situation? And how do I prevent it from happening again? There were several contributing factors.

1. I was distracted when I went out the door.
I was on the phone and payed no attention to which way the door swung as I went outside. I was concerned with who I was talking to and trying to get out of the crowd of people.

2. Public building doors normally open out.
When we go into a public building, we're used to pulling a door open to get inside. Why? We can thank the fire codes for this. In event of a fire, the way out of the building must be as free from obstacle as possible. This means that doors swing out so that we can easily get out of the building in an emergency.

But this door swung in. Why? Because this was a balcony with no other exit. So in an emergency, the way "out" was to go into the building. So that's why this door opened "in" even though I was outside.

3. The designer went for aesthetics over functionality.
The door handle was a vertical bar. Let's see what Norman has to say about this:

From The Design of Everyday Things by Donald A. Norman

So, I wasn't far off here. The door handle looked like the one on the right (vertical bar that curved into the door). To make things even worse, the handle on the other side of the door was exactly the same vertical bar.

The designer had decided to go with what looks nice rather than what is easy to use. (And I'm sure it looks really great in pictures.)

Result: I was doing what humans normally do.
That's not something to feel bad about. I'm not the one who failed in this situation; the designer did.

Failing as a Designer
As a user, I should not feel like a failure; it is the designer who failed me.

As a developer, I need to take this same attitude toward my users. If my users can't figure out how to do a particular task, they have not failed. In that situation, I am the one who failed (as designer of the software).

There was one particular application where I failed as a designer. At the time, I knew I was failing as a designer. But there were ROI decisions to be made.

Let's get into some details. I worked on a calendaring application for a theme park. Every scheduled event went into this calendaring system: this included maintenance items (such as painting and repaving), publicity items (such as press events for a new ride), operational items (such as operating hours), and entertainment items (particularly shows and parades) -- and it even included special events like weddings.

The data entry screen that we had to enter these items worked for 95% of our users, and it worked pretty well. But it was very awkward for 1 user: the person from the entertainment area who entered the shows and parades.

I always wanted to write a special data entry screen just for this one person. She was constantly entering events -- there was *a lot* of entertainment at this location. We did have some templates to make it easier to duplicate items, but it never got to where it should have been to make entering these types of events easy.

So, in this case, I failed as a designer.

Mitigating Failure
The one good thing about this is that I was aware of the failure. Because of this, I spent extra time with this one user to make sure that she was as comfortable as possible with the awkward process. And whenever she ran into issues, I made sure to resolve them as quickly as possible.

I know that this extra effort payed off. The result was a good relationship with this user (and the department in general). In fact, when that person left the position and a new person came in, I found out that she spoke very highly of me to the new person. And I made sure to stop by their office to introduce myself and let the new person know that I was available to answer any questions.

Face-to-face conversations really help build relationships. I've been able to build trust with the people who use my software even when the software was not ideal.

Wrap Up
We have a big responsibility as developers: usually we are also the designers who decide how users interact with our software. And if our users end up "failing" when trying to use our software, it is not the user who has failed. It is we who have failed our users.

Think about the time that a piece of software (or a door handle) has frustrated you. Did you feel like a failure? Remember this when you're designing your own software. We want our users to be successful. And in doing so, we need to make sure that *we* don't fail them.

Happy Coding!

Tuesday, April 14, 2015

New Video: Declarative Programming with LINQ

I just published Part 3 of my video series on Lambda Expressions & LINQ in C#. This time around, we look at the difference between imperative programming and declarative programming.

Imperative Programming is what we're used to: we tell the computer *how* to do something. This usually involves giving step-by-step instructions such as looping through data, using "if" statements to make comparisons, and then doing the pieces of work that are important to our task.

Declarative Programming is a bit different: we tell the computer *what* we want done. Then we leave it up to the computer (or library) to figure out the rest. It turns out that we can use LINQ methods to make our code more declarative. And in doing this, we make our code easier to read and understand.

So be sure to check out Declarative Programming with LINQ:

This completes the basics of lambda expressions and LINQ. All of the videos are collected in this playlist:

Playlist: Lambda Expressions & LINQ in C#
I have a couple of bonus episodes planned (to cover some more details on captured variables and the Join method). So be sure to stay tuned for future episodes.

Happy Coding!

Monday, April 13, 2015

Talk with Dustin Davis on //c0deporn

I had a chat last week with Dustin Davis (@PrgrmrsUnlmtd) about one of my favorite topics: Lambda Expressions.

You can watch the video on YouTube: Getting Started with Lambda Expressions with Jeremy Clark

If you want to have a chat about technology, just drop me a line.

Happy Coding!

Sunday, April 12, 2015

New Video: Demystifying LINQ Methods

I just published Part 2 of my video series on Lambda Expressions and LINQ. You may have heard about Part 1 (Lambda Expression Basics) on This Week on Channel 9 (big thanks to Channel 9 for the mention).

A big problem with LINQ is the apparent chaos of the method signatures:

When we see this for the first time, it seems extremely complex. But once we dive into the different pieces, we see that things aren't as complicated as they seem. And that's exactly what we do in this video: Demystifying LINQ Methods:

While exploring LINQ, we mention a couple of other topics that are covered in separate videos:
As a reminder, Part 1 covers the basics of lambda expressions. And in future videos, we'll look at how LINQ can help us make our code more readable through declarative programming. We'll also take a look at the Join method and the intricacies of using captured variables in "for" loops.

Get links to all of the videos, plus code samples, additional articles, and a PDF walkthrough here: Learn to Love Lambdas (and LINQ, Too!)

Happy Coding!

Thursday, April 9, 2015

April 2015 Speaking Engagements

After a very busy February and March, things have been a bit quieter for me in April. I spoke at a corporate event earlier this month, and I have one event scheduled next week.

Thursday, April 16th
Central California .NET User Group
Fresno, CA
Meetup Link
Topic: Unit Testing the Smart Way

Unit testing is a key tool in my toolbox. There was a time when I thought I was doing just fine without it. I was wrong. After I started testing regularly, I found that I was coding more confidently, and I am able to code faster than I did before.

Along the way, I've been experimenting with different techniques and trying out new tools. In this session, we'll take a look at Test-Driven Development (TDD) and use Conway's Game of Life as an easy way to get started. We'll look at MS Test (which is included with all editions of Visual Studio) and also NUnit (which is free and easy to get through NuGet). Finally, we'll take a look at a new tool coming with Visual Studio 2015: Smart Unit Tests. We'll be using a preview version, but the release version will be headed our way soon.

If you're in the central valley, be sure to stop by. If not, and you'd like me to come to your event, just drop me a note. I love going out to new places and meeting new developers.

Happy Coding!

Monday, April 6, 2015

New Video: Lambda Expression Basics

I just started a new video series based on my presentation Learn to Love Lambdas (and LINQ, Too!). LINQ is one of my favorite tools in C#, and lambda expressions play a key role in using LINQ methods.

Lambdas & LINQ in C# - Part 1: Lambda Expression Basics
In part 1 of the series, we take a look at the syntax of lambda expressions and how to create anonymous delegates. In addition, we look at captured variables which allows us to scope our variables more appropriately.

Watch Part 1 on YouTube (or here):

Future episodes will take a look at how to read and understand the signatures of LINQ methods. This allows us to use LINQ effectively in our code.

Coming Soon!
Part 2: Demystifying LINQ Methods -- 04/12/2015: NOW AVAILABLE!
Part 3: Declarative Programming with LINQ -- 04/14/2015: NOW AVAILABLE!
Plus, bonus episodes that look at the Join method syntax and the dangers of using captured variables with "for" loops.

Lots of good information coming. If you can't wait for the information, be sure to check out the PDF walkthroughs and articles available here: Learn to Love Lambdas (and LINQ, Too!).

Happy Coding!

Sunday, April 5, 2015

My Approach to Testing: Test Public Members

In my presentation "Clean Code: Homicidal Maniacs Read Code, Too!", I spend quite a bit of time refactoring code (not as much time as I'd like, which is why I put out a supplemental video: Clean Code: The Refactoring Bits).

Unit tests are a vital part of the code that I show. The unit tests are what make sure that I don't inadvertently change functionality as I refactor the code. Much of the refactoring involves extracting out pieces of code and putting them into their own methods. This makes the code easier to navigate.

I do get questions about my testing technique as I show this code. Here's a question that I got at Nebraska.Code() right after the presentation:

Question Time!
How do you modify your tests after extracting code into the new private methods?
The short answer is: I don't.

The longer answer is my approach to unit testing: I test the public members of my code.

Let's take a look at some examples so that I can show this in action, and then I'll talk about why I take this particular approach.

Refactoring Code
Here's the "Initialize" method that we start with:

During the process of making this more readable, I extract out a couple of methods and move some assignments around. What we end up with are a couple of private methods in addition to our public one:

This takes some of the details and "hides" them in private methods. This way, when we first walk up to the "Initialize" method, we can easily decide which parts of the code are important for what we're doing. If we don't care about the dependency injection container bits, then we can skip right over those and go to the "RefreshCatalog" method.

Here's another example; this time we refactor the "RefreshCatalog" method. Here's the original:

And the version with bits extracted:

This makes "RefreshCatalog" much easier to follow. We get a high-level overview of what the method is doing. If we need to look at details, then we can drill into those methods. This is especially appreciated when you walk up to this method for the very first time. (And we have to remember that sometimes we keep walking up to the same method "for the very first time" over and over again -- we get put on other projects and have to come back to this application 6 months later to make some enhancements, and we have to get our bearings again.)

Testing Public Members Only
So why don't my unit tests change as part of this process? Because I'm only testing the public members of my class -- whether public methods, properties, or events.

So if we turn on CodeLens and take a look, we'll see that only the public methods have unit tests:

In the case of "Initialize", we see that there are 19 tests (which is all of them). This is because each of our tests runs the "Initialize" method as part of the setup even if it's not explicitly testing this code.

We see something similar for "RefreshCatalog":

In this case we have 4 tests that call "RefreshCatalog" directly. In 2 of these tests, we check to see if the service is called based on the state of the cache:

If we look at the details of the first test, we see that it does call "RefreshCatalog":

And it also indirectly calls the "IsCacheValid" property and the "RefreshCatalogFromService" method.

I won't go into the other details of this test; it gets a little weird because we're testing an asynchronous service that uses APM (Asynchronous Programming Model) wrapped in a Task which (sort of) changes it to TAP (Task Asynchronous Pattern). So there's a little helper object ("tracker") to make testing easier. This would be a good topic for another day.

[Update: You can see how the tracker works in this article: Tracking Property Changes in Unit Tests.]

Why Not Test Private Members?
So the question is why don't I create tests for the private members? My reasoning is that I like to keep the code as clean as possible.

When I create production objects, I want to modify the code as little as possible for testing. When we want to test private members, we basically have 3 options:

Option 1: Reflection
Our first option to test private members is to use reflection to crack open our class so that we can access the bits of code we're not normally allowed to look at.

I don't really like this option because our tests become *very* complicated very quickly. Reflection is one of those things that is difficult to understand on its own. When we make it a requirement for our unit tests, then we're just asking for trouble.

The end result when we take this approach is that we just don't bother with tests because they are too difficult to create.

Option 2: Change Access Modifiers to Public
Another option is to change the "private" members that we want to test to "public."

I'll just cross this option off immediately. I don't want to mess with making things visible to the outside world when it's not appropriate. Scoping and visibility are huge parts of building good objects, libraries, and APIs. We can't compromise that for testing.

Option 3: Change Access Modifiers to Protected
Another option is to change the "private" members that we want to test to "protected." When we do this, we can then create a wrapper class in our tests. This wrapper class descends from our production class, so it has access to the protected members. It can then supply wrapper methods or properties to access the protected members of the base class.

I don't like this option, either. The main reason for that is that I feel like I'm not testing my production code. Instead of testing my actual class, I'm testing some mutation of that class. I'm not confident that the behavior between the test class and the production class will be identical, so I lose faith in my tests.

What if I Really Need to Test a Private Member?
In the examples that I've shown here, it's pretty easy to say, "I'm okay testing at a higher level." By testing the "RefreshCatalog" method, we end up testing all of the private members indirectly.
But what if one of those private members is so important to my functionality that I really want to test it directly?
For example, if I'm accepting credit cards, I want to do the Luhn check against them. This will at least make sure that the number itself is potentially valid before checking against a credit card processor.

My answer to this is pretty simple:
If a private method is important enough that I need to test it directly, it's probably important enough to have its own class.
This really takes me to the Single Responsibility Principle and Separation of Concerns. Needing to test a private method directly is a code smell. If I run across that, then it probably means that it's a separate concern that needs its own place in the code.

When I extract that out into its own class (whether an instance class or a set of related methods in a static class), now I can test that class directly.

Of course, we would have to get into a discussion on the proper visibility of the new class and methods. But that's easier to take care of. If I have a protected or internal class that's only available to the code in the same assembly or namespace, I can create a test class that is only responsible for directly calling into this protected class. But I'm not wrapping the class itself, just creating a test class that is capable of calling into the real class.

Many Approaches to Testing
There are many approaches to unit testing. And I will be the last one to say that this is an example that everyone should follow. This particular approach of testing the public members has worked out well for me in the majority of situations that I've run into. It has the added benefit of being fairly resistant to refactoring.

When we create the public members of our classes, these generally remain unchanged. This is because the public interface is how the outside world interacts with our objects. So we try to change these as little as possible.

The private members, however, are subject to change. We can rename private methods, move things to other methods, properties, or classes, and combine similar code into consolidated methods. If we are directly testing the private members, we're less likely to make these types of changes because it would mean making major changes to our tests as well (especially if we're using reflection which would not give us compile-time errors, only run-time errors).

Wrap Up
I encourage people to try different approaches to testing. Each has its advantages and disadvantages. I've managed to dial in an approach that works well for me and the types of applications that I normally build. But that doesn't mean that I don't keep exploring.

I'm still working on TDD. I've had some really good successes with it lately, and I've got another piece of code that needs some help, so I'll be doing some more experimentation this week.

Overall, automated testing gives me confidence in my code. The tests are proof that my code does what I think it does. And I can get immediate feedback by re-running tests whenever I change code (without having to run my application).

So experiment, try different techniques, and come up with a testing approach that works well for you. Ultimately, you will end up with better code.

Happy Coding!