Currently and just finished reading: I just visited my local library and picked up a copy of Planet of Twilight, which is the third book in a Star Wars trilogy. I’ve recently finished reading the second book of the same trilogy, Darksaber. Although I don’t like the name “Darksaber,” it is a well-written, entertaining book. My wife tells me, however, that I will not find the same to be true of Planet of Twilight.

I plan to be reading a little bit less right now as I have been playing StarCraft 2. Let me know if you want to play a match.

From what medium I like my books: I haven’t ever gotten any of the digital readers, but I have read PDFs on my computer and on my phone. I’ve also used some of the book reader applications for my phone, and I tend to prefer reading books on pages printed on dead trees. Perhaps it’s just that I’ve not yet tried a good enough interface for digital reading. I intend to try one eventually.

A while back I started reading a copy of the Art of Agile Development, which is a great book. I was reading the book for more than one reason. I obviously wanted to learn more about how others approach agile development, but I was also looking for a book to recommend to other developers as well as to businesses.

One of the biggest troubles with agile development is the initial resistance to agile development shown by both developers as well as businesses. I am even talking about the developers and businesses who have already bought in to the idea that agile can be a good thing. People agree with the overall idea of agile, when it forces them to change their existing practices many will put up at least passive resistance.

This book is my new answer to some of that. The book is written with a good amount of details and examples that will backup the information it provides about agile development, and it does so in such a way that both development teams and those working with the teams can have a better understanding of how agile development can work.

The Art of Agile Development is loaded with information about real-world problems faced by software development teams, and how agile development worked in these situations. The book covers these examples while describing the specific steps the author recommends for performing agile software development.

I don’t follow the same practices in all cases as what the book describes. I don’t manage stories in the same way, and I don’t estimate and track the time on that work the same way. This doesn’t matter, because the book is really providing information on how agile can work and how it has worked in the past. Each team needs to find how best they can apply agile and work with them. I use a mix of Agile, Scrum, XP, and anything else that the team thinks will make us work better. As long as the process helps us deliver better software we’re all about it.

If you’re considering agile or trying to convince other people to consider agile, I would recommend reading this book and passing it along to others when you’re done reading it.

Full disclosure: I did not pay for this book. The copy of the book that I read was sent to me by the publisher.

Trust levels in web development can be a pain in the rear. As a developer, I tend to not like them, because when they’re important it means that my options are being restricted. I am often required to perform extra work to complete the same tasks I would be performing elsewhere.

Medium trust is the trust level commonly used by web hosting companies, because it gives them a good balance of security and options. Ideally, as a programmer I can work in full trust, which allows me to do pretty much anything I want. That is, however, not at all what shared hosting requires. They need some extra added security.

Generally we develop for medium trust when we are either on a medium trust hoster or are working on a program which could be hosted in many places (including shared hosting).

For a project on which I am currently working, we needed to bypass some restrictions of medium trust to allow us to make an external request to a web service on another domain. Doing this will cause a security exception at run time. Keep in mind that the trust level can be violated when the site compiles, because certain things cannot be used at all in medium trust. In this case, it is our external service which caused the issue. I believe you could also have an issue if you’re running a web farm.

So how do we get around it?

We need to set up our trust element in the web.config file and hope that the hosting company is not overriding the use of this work-around. If the hoster is blocking this trick then you will want to see if you can resolve the issue using proxies. Some hosting companies will work with you to get your application running as long as it is not a security risk for them.

The key is the “originUrl” property of the trust element. We need to set that using a regular expression to define which URL we want to use. You should try to be more specific with the regular expression, but “.*” is still OK. That one will basically say any combination of any characters is OK. If we want to be more specific we might say that since our web service calls are all on the same domain we could use something like this “http://www.mywebservicedomain.com/.*”, and this would allow anything on that site.

<trustlevel="Medium"originUrl=".*"/><!-- or this --><trustlevel="Medium"originUrl="http://mywebservicedomain.com/.*"/>

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.

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.

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!

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.

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.

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.

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.

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.

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.

Growing up I always enjoyed a good game of Othello. The rules of the game are very simple, but it takes a lot of work to become really good at Othello. There is a great tagline used to describe this game; “A Minute to Learn...A Lifetime to Master”.

The same can be said about Test Driven Development. In fact, when NimblePros hires interns in the summer, we go to recruiting events and set up laptops for people to write some code using TDD. When there are no students in the room, we’re the ones working on the code. Even our seasoned developers need to practice using TDD or we’ll never become better at using it.

The great part about this is that you don’t need any experience with TDD in order to sit down and start. You don’t want to sit down and start using TDD on legacy code, but simpler problems are a great way to get started.

We like doing these exercises as it allows us to not only see who can write code, but also who is willing to take the leap and try new things. This is one of our self-selecting techniques of evaluating people. Would you hire an employee not willing to go out on a limb and try something new? I wouldn’t.

I have two points to make: it’s easy to get started with TDD and if you don’t practice it you’ll never master it.

Sure, I can grab students from a college who may have only heard of unit testing in a class and have never really implemented it, but will those students ever get good at TDD. I think that they will if they work hard and actually use TDD. You have to practice it though. TDD will slow you down at first, which is why you need to practice it.

If you’ve ever had a team responding to the needs of multiple stakeholders I am sure you’ve seen some interesting trends. Some stakeholders will sit quietly and have their requests ignored while others will always push their needs to the front. This of course happens in a lot of different fields. There are always the pushy people who want their stuff done first, because it’s “top priority”. Maybe it is, but that’s not for the team to decide.

So how can you prevent problems from arising from this type of behavior?

I recommend that you spread as much information about things as possible. In the past I’ve found that when dealing with decision makers it is best to make them aware of the other things you’re working on. If your team has an informative workspace that makes available all of the tasks you’re working on they’ll be able to see what is currently being worked on.

Keep your backlog of tasks in priority order and make the whole thing visible. Make sure also that adding something to the front will require physically moving another task back. It’s much harder to ignore the displacement of someone else’s request when that request must be physically moved.

Another great way of handling this is to make sure all of the stakeholders are present when ordering the list of tasks. This will make it quite clear if one person’s requests are all being put at the front of the line, and can help allow for some compromises to occur instead of an argument.

Disagreements over whose need is more important are not the place for the development team to be involved.I’m not saying that a fist fight will break out, but you want to avoid upsetting anyone. Your best situation is when you don’t have to make a decision about whose task to work on. I find that people are more considerate of other people’s needs when they’re made visible, so make sure that stakeholders see the displacement of another’s work.