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!

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
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!

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!

Monday, March 31, 2014

April 2014 Speaking Engagements

March was a busy month. I got to travel to Salt Lake City and Las Vegas, and I spoke all around Southern California (LA, Orange County, San Diego). I had a lot of fun, and it was great to make a bunch of new friends and talk to devs working with different tools.

April is shaping up to be pretty busy, too. I've got 3 events planned so far, and there's a couple more waiting in the wings. If you're in the area, be sure to stop by.

Saturday, April 5, 2014
Desert Code Camp
Chander, AZ
http://apr2014.desertcodecamp.com/
Topics:
o IEnumerable, ISaveable, IDon'tGetIt: Understanding .NET Interfaces
o Learn the Lingo: Design Patterns
o T, Earl Grey, Hot: Generics in .NET

The Desert Code Camp is always a lot of fun. I've been out there 6 times so far. I'm looking forward to seeing a bunch of old friends and making some new ones.

Tuesday, April 8, 2014
Inland Empire .NET User's Group
San Bernardino, CA
http://www.iedotnetug.org/sf/Index.aspx
Topic: Shields Up! Defensive Coding in C#

Thursday, April 10, 2014
EastBay .NET
Berkeley, CA
http://www.meetup.com/BayNET/events/171840062/
Topic: Shields Up! Defensive Coding in C#

Defensive Coding is all about making sure our code is robust and effective. We want to make sure that our users have the best experience possible. And this means that we need to be prepared for the unexpected and make sure that our application behaves appropriately.

Stay tuned. More items will show up as they get confirmed.

Happy Coding!

Sunday, March 9, 2014

New Video: Generic Interfaces

Last month, I started a series on C# Generics on my YouTube channel. Part 2 is now available: C# Generics- Part 2: Interfaces

I'm a big fan of interfaces (as evidenced in IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces). When we add generics to interfaces, we get code that is flexible and reusable. In this video, we take a look at 2 different interfaces that are so similar that we can't help but want to combine them. It turns out that merging them into a single interface is made easy with generics.

Future videos will look at generics in methods as well as generic constraints. So stay tuned for more to come.

C# Generics:
Playlist
Part 1: Collections
Part 2: Interfaces

Happy Coding!

Thursday, February 27, 2014

March 2014 Speaking Engagements

It looks like March will be pretty busy for me. I have four events scheduled so far:

Wednesday, March 5, 2014
SoCal .NET Developers Group
Buena Park, CA
http://www.socaldotnet.com/
Topic: Dependency Injection: A Practical Introduction

Saturday, March 15, 2014
Utah Code Camp
Salt Lake City, UT
http://www.utahgeekevents.com
Topics:
Learn to Love Lambdas
Clean Code: Homicidal Maniacs Read Code, Too!

Tuesday, March 18, 2014
Disney .NET Developers Group
Burbank, CA
Topic: Keep Your UI Responsive with the BackgroundWorker Component

Thursday, March 20, 2014
SoCal .NET Architecture
Newport Beach, CA
http://www.scdna.org/
Topic: Abstract Art: Getting Things "Just Right"

Tuesday, March 25, 2014
San Diego .NET User Group
San Diego, CA
http://www.sandiegodotnet.com/
Topic: IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces

Thursday, March 27, 2014
dotNetGroup.org
Las Vegas, NV
http://dotnetgroup.org/
Topic: Dependency Injection: A Practical Introduction

Dependency Injection continues to be a popular topic. DI is extremely useful for creating loosely coupled applications. Unfortunately, most devs are introduced to DI by being thrown into code that uses a Dependency Injection container (such as Unity, Ninject, or StructureMap). We start learning DI by implementing it manually. That way, we understand the concepts and the steps involved. After we have a good handle on that, we look at how containers can help take care of the tedious bits and also provide extra functionality.

Stay tuned: I have a number of event scheduled at the beginning of April. So, if you're in Phoenix AZ, Los Angeles CA, San Bernardino CA, or the San Francisco Bay area, you'll have a chance to come see me soon.

Hope to see you at an upcoming event. And if you want me to come to your event, just drop me a note.

Happy Coding!