Our Cleveland-based Software Engineering 101 event was modeled after two previous, successful events in Columbus and Nashville. The event was held at the Microsoft office in Independence, Ohio. The event went over very well; we managed to get a great group of about 50 students out for the event. Our negative feedback was the lack of Internet access and the fire alarm, which interrupted the event. Our schedule was thrown off a bit by the fire alarm, and we only needed to leave for lunch slightly early as a result. Other than that things went off without a hitch.
These are my slides on Object Oriented Principles, Practices, and Patterns. The practices of object oriented development I covered tie the principles together, and the patterns, strategy and template method, tie the principles together as well as prepare for Steve’s talk which followed mine.
These are my demos on Object Oriented Principles and Patterns. They’re simple and show the basic concepts of the slides.
Before throwing people into the deep with testing, I did a quick 15 minute introduction to testing.
Our hands-on programming exercise also went very well. I think we challenged some attendees and gave others some due practice by following previous examples and using the Greed Kata. This problem was great for reinforcing the concepts of my first talk, and if someone tried to follow the Open/Closed Principle while doing the problem they likely used the strategy pattern. I’d love for people to send me their implementations of the Greed Kata, so lets see what you’ve got.
Overall the event went well. Perhaps there is another one in our future. Let us know if you’d like us to do another.
We of course could not have done the event without the help of our organizing sponsors: Hudson Software Craftsmanship, NimblePros, and Microsoft. We are also grateful to our prize sponsors who offered up great prizes for the attendees: Pluralsight, DevExpress, NimblePros, JetBrains, and PreEmptive Solutions.
This week I'll be speaking at a free day-long event for developers to improve their software engineering skills. The event is being held at the Microsoft office in Independence, Ohio. Microsoft is hosting the event being organized by the Hudson Software Craftsmanship group and NimblePros consulting services.
I’ll be kicking off the event with my main topic: Principles of Object Oriented Programming. Other topics will include: SOLID Software Development, Software Testing, and Specification Driven Testing. In the afternoon we’ll be doing Hands-On Exercises.
There are only a dozen seats remaining for the event scheduled for July 16, 2010. We’ll be starting in the morning at 8:30 AM and running until 4:00 PM. We’re looking forward to seeing you there!
Registration for the event is free and easy. Sign up now for the Software Engineering 101 – Cleveland event. Seats are limited, so register soon.
Earlier this week, the second iteration of this developer-targeted online challenge was released. The Toughest Developer Puzzle Ever started last year, and you can do either of the puzzles. I recommend tackling TDPE 2 if you haven’t done either one yet. There will be prizes sent out to the first 100 people to finish the puzzle, so get solving! Very few people have solved the puzzle so far.
TDPE Classic was created mostly by Jeff Blankenburg with assistance from Sarah Dutkiewicz and me. The puzzle ended up being 30 levels, and I it was a challenging set of puzzles. It was great fun working on it, and solving the puzzles was also a blast.
This year, we kicked things up a notch. We made harder puzzles, we made more puzzles, and we got extra help working on them. If you were looking for a challenge, I think we have a good one this year.
This years puzzle making team includes:
And to help you on your way I’ll give you some advice.
- Don’t believe everything you see in the puzzle.
- A puzzle may seem tedious even when it isn’t.
- There may be more than one way to solve a puzzle.
- Find all available clues, not just the obvious ones.
- Use your head.
I hope you enjoy the puzzle! Good luck!
One too common programming practice that irks me when I find it in source code is throwing or catching non-specific exceptions. I believe firmly that it is important to fail fast, and exceptions are a great way to ensure fast-failing code. If you drag out a failure you can hide the initial issue or allow a process to continue after an error has happened. Using non-specific exceptions will also hide information. Failing quickly is important as is being able to respond correctly to an exception and track down the cause.
Steve Smith posted recently saying that one should not throw duplicate exceptions. He gave a great example of where people will check for two different cases and throw duplicate exceptions.
public void Foo(SomeClass someArgument)
{
if(someArgument == null)
{
throw new InvalidArgumentException("someArgument");
}
if(!someArgument.IsValid())
{
throw new InvalidArgumentException("someArgument");
}
// Do Real Work
}
Checking for null as well as custom validity is important, and you want them to be separate cases. The suggestion from Steve is that you give them unique messages or use a more specific exception to allow people to tell what caused the error.
public void Foo(SomeClass someArgument)
{
if(someArgument == null)
{
throw new ArgumentNullException("someArgument");
}
if(!someArgument.IsValid())
{
throw new InvalidArgumentException("someArgument");
}
// Do Real Work
}
public void Bar(SomeClass someArgument)
{
if(someArgument.Quantity < 0)
{
throw new InvalidArgumentException("someArgument",
"Quantity cannot be less than 0. Quantity: " + someArgument.Quantity);
}
if(someArgument.Quantity > 100)
{
throw new InvalidArgumentException("someArgument",
"SomeArgument.Quantity cannot exceed 100. Quantity: " + someArgument.Quantity);
}
// Do Real Work
}
I lean toward using unique exceptions for handling this. It allows for better handling of the result and less duplication of the code. For example in the method listed above instead of using an InvalidArgumentException when the Quanitity is negative, I could use a NegativeSomeClassQuantityException. For the second one I might use an ExceededSomeClassQuanityException with the following resulting code.
public void Bar(SomeClass someArgument)
{
if(someArgument.Quantity < 0)
{
throw new NegativeSomeClassQuantityException("someArgument", someArgument.Quantity);
}
if(someArgument.Quantity > 100)
{
throw new ExceededSomeClassQuantityException("someArgument", someArgument.Quantity);
}
// Do Real Work
}
This is great because my code isn’t concerned with how to format these exceptions. My code just passes the required information via constructor parameters and the exception knows how it should be formatted. The calling code can catch each of these exceptions if it has a special way of handling either one or through the use of polymorphism it can handle both of them.
We want to make sure that we inherit from a relevant exception as well, so we could use the InvalidArgumentException.
public class NegativeSomeClassQuantityException : InvalidArgumentException
{
public NegativeSomeClassQuanitytException(string argumentName, int quantity) :
base(argumentName, "Quantity cannot be less than 0. Quantity: " + someArgument.Quantity)
}
public class ExceededSomeClassQuantityException : InvalidArgumentException
{
public ExceededSomeClassQuantityException(string argumentName, int quantity) :
base(argumentName, "SomeArgument.Quantity cannot exceed 100. Quantity: " + someArgument.Quantity)
}
Last year, Steve Smith, Rich Henning, and I started a local user group called HudsonSC. As a software craftsmanship group, we focus our efforts on improving one’s abilities as a developer. I’m not sure I can say enough about the need for developers to practice and learn to increase their abilities. Developers are providing a service in the form of software development. We should be proud of what we achieve through our efforts.
Our last meeting of our Software Craftsmanship group focused on the idea that software development is not the creation of things, but a service which when provided results in a new thing every time. We have this great topic and great meeting of the group thanks to a great idea and presentation from Michael Falanga. I will say that he is almost as good as Kevin Kuebler at keeping his talks short. Michael’s slides are available on SlideShare.
My favorite part of the talk was the comment that, “we’re not building cars. We are creating something new each time.” This I think is a very important point to make, and I agree with it. I don’t make the same thing every time. I am using techniques I’ve learned, and those aren’t the same techniques as anyone else. We all do things a little bit differently, and we’re all creating different implementations of the same kinds of things.
Our group is free-form and guided by our members. Sure, we have an agenda, but we hardly stick to it. It’s a rough outline for when things don’t spontaneously change.
At StirTrek I was discussing the group with Michael, and he was saying that he wanted the group to get back to the roots of software craftsmanship and discuss some of the finer points of the trade. The consensus of those around us at the time was that the programming exercises at the end of the events were great, but we should also focus more on the “why” we’re doing things the way we are.
If you’re user group isn’t discussing what you want, take the reins and guide it. It worked very well in this case as this meeting was one of the best our group has had.
Anyone can bring a talk to discuss in our open spaces or by giving a short talk, and I believe that this makes for a great user group. The occasional topic from a speaker is great, but I get a lot more out of discussing a topic than having someone tell me a topic. (This of course tells you that there was some debate on certain aspects of Michael’s talk.)
Take charge of your developer community and make it a better place for everyone involved. If you’re in the area, you should stop by HudsonSC and let us know what you want to discuss. We’re always looking for your great ideas.