I recently finished reading.

Deploying .NET Applications: Learning MSBuild and ClickOnce (Expert's Voice in .Net)

I was interested in this book mainly to find an easier way to deploy ClickOnce applications via an automated build. Most of my build automation experience has been with Nant, so I figured learning MSBuild couldn't hurt.

This book targets the Visual Studio 2005 time frame, so some of the things that it describes is out dated, mainly in regards to ClickCnce.

There was a little coverage on mage.exe but not as much as I had liked. If you're looking for a book to get you into the world of Clickonce or MSBuild, this one's pretty good!

Here are some of the things that I learned straight from the book.

MSBuild

Microsoft.Build.Framework and Microsoft.Build.Utilities contains some stuff to help you with your builds. There's an ITask interface and a Task base class that you can implement if you want to run some custom tasks from MSBuild.

ClickOnce is driven by two XML-based manifest files called the deployment manifest and the application manifest.

• Deployment manifest (.application) contains information specific to the deployment of the system.
• Application manifest (.manifest) captures information specific to version of the system.

ClickOnce Deployment

The ClickOnce technology also has a programmatic interface that you can use to customize deployment and updates. For example, if you have a plug-in where the core of the application is deployed initially and then users are allowed to choose optional features (plug-ins) and have them installed on demand, the ClickOnce API can help.

ClickOnce applications have to be deployed to a Web server, to a file server, and/or to removable media (such as CD/DVD). Moreover, you can deploy these applications in one of two modes: offline or online.

For applications that require finer-grained control over doing updates, application authors can use the ClickOnce APIs to customize installation and updates.

Code Access Security (CAS)

• Permission: The authority to do something.
• Permission set: A grouping of arbitrary permissions.
• Origin based Evidence: Where your code comes from determines what permissions your code gets.
• Content base evidence: Your code content is signed and has a publisher certificate, and that determines what permissions you get.
• Code Group: Associates evidence with a permission set
• Security Policy: Policies define a hierarchy of code groups.

On-Demand Download

ClickOnce offers a facility that called on-demand download. The idea is that you create groups of files and then use the ClickOnce APIs to download each group at runtime. The initial download is reduced to what is needs to be downloaded to run the application, and if a piece of functionality is not needed, it is not downloaded.

You can get the path to the Data directory via:

•                 AppDomain.CurrentDomain.GetData("DataDirectory");

•                 ApplicationDeployment.CurrentDeployment.DataDirectory;

•                 Application.LocalUserAppDataPath;

I recently finished reading...

Data-Driven Services with Silverlight 2

I have been wanting to get in to the world of WCF for some time now, but wasn't really sure how to get started. This book was good at explaining how to get into WCF quick and easy. The sample apps that the author goes through and provides are pretty cool which makes it more fun.

The book explains how data binding in silverlight (which seems to be similar to how it works in WPF), how to pass objects across the wire using WCF. It explains what RESTful services means, and how to build them leveraging tools on the .NET stack.

The sample apps include one that consumes Amazon's RESTful services, as well as a Twitter client called SilverTwit. There's lots of code to dig through, and try out for yourself.

For anyone interesting in Silverlight or WCF, this is a good book to get you started.

If you're looking for the sample code that comes with the book, you can find it here. http://examples.oreilly.com/9780596523091/

I recently finished reading...

Introducing NLP: Psychological Skills for Understanding and Influencing People

I first heard about Neuro-linguistic programming (NLP) while I was reading The Game: Penetrating the Secret Society of Pickup Artists. I thought that it sounded like an interesting subject, because I spend a good deal of my time dealing with people and trying to learn new things. If you're interested in trying to become a better communicator or you are interested in trying to find out what your preferred way of learning is, this book will probably help!

Below are some of the things that I learned straight from the book.

The Four Stages of Learning

1. Unconscious Incompetence
2. Conscious Incompetence
3. Conscious Competence
4. Unconscious Competence

If you always do what you've always done, you'll always get what you've got. If what you are doing is not working, do something else.

Communication is so much more than the words we say. These form only a small part of our expressiveness as human beings. Research shows that in a presentation before a group of people, 55 per cent of the impact is determined by your body language - posture, gestures and eye contact - 38 per cent by your tone of voice, and only 7 per cent by the content of your presentation.

We move our eyes in different directions in a systematic way depending on how we are thinking. Neurological studies have shown that eye movement both laterally and vertically seem to be associated with activating different parts of the brain.

Movements and gestures will also tell you how a person is thinking. Many people will point to the sense organ that they are using internally: they will point to their ears while listening to sounds inside their head, point to the yes if visualizing, or to the abdomen if they are feeling something strongly. These signs will not tell you what a person is thinking about, only how he or she is thinking it. This is body language at a much more refined and subtle level than it is normally interpreted.

Beliefs can be a matter of choice. You can drop beliefs that limit you and build beliefs that will make your life more fun and more successful. Positive beliefs allow you to find out what could be true and how capable you are. They are permissions to explore and play in the world of possibility.

Towards people are energized by goals and rewards. Away people are motivated to avoid problems and punishment. Arguing which is best in general is futile.

It is easy to recognize this pattern from a person's language. Does she talk about what she wants, achieves or gains? Or does she tell you about the situation she wants to avoid and the problems to steer clear of? Towards people are best employed in goal-getting. Away from people are excellent at finding errors and work well in a job like quality control. Art critics usually have a strong away orientation as many a performing artist can testify!

A good teacher will be able to create an environment, so her students learn for themselves how to get the results.

Learning to learn is the most important skill in education, and needs to be taught from reception class onwards. The educational system concentrates mostly on what is taught, the curriculum and omits the learning process. This has two consequences. First, many students have difficulty picking up the information. Secondly, even if they do learn it, it has little meaning for them, because it has been taken out of context.

I recently finished reading...

As usual I fold down pages that contain paragraphs that interest me... below are a few excerpts from the book that I enjoyed!

"Better people" has been recognized as the most promising silver bullet for addressing the software crisis, and yet almost all of our energy has been spent on creating better tools, methods, and processes instead of better people?

Imagine what a team of "better people" can accomplish. Now stop imaging, and start investing in fostering cultures that cultivate "better people" all working towards the same goal.

An unspoken but just as widely held belief that really good developers were not to be trusted - they could not be "managed", they all seemed to be "flaky" to some degree, and they did not exhibit the loyalty to company and paycheck of "normal" employees. Really "good" developers tended to be "artists", and are was (is) not a good word in the context of software development.

Those flaky artist types... *sigh* It's important to allow individuals do what they are good at, that's obviously something they like to do. It breeds innovation, and efficiency. When working in a team it's important to be respectful of one another's opinions and work together.

Every once in a while someone on the team will have a crazy idea that just might slash the complexity of the whole system. If they have courage, they'll try it out. It will work (sometimes).

It's important to have courage on any team. XP teams value courage. Without the courage to grow and challenge one another, your team will remain stagnant. By challenging one another you're showing one another respect by saying that "I want you to get better, and I expect you to want me to get better as well"!

Object thinking is a "crazy idea" capable of increasing simplicity in software design - crazy in the sense that it does not conform to traditional thinking about software development, crazy in the sense that it revolts against the computer thinking employed by most software developers, and crazy in many of the same ways that XP is crazy.

Trying to introduce object's into a culture that's firmly devoted to thinking in terms of data can seem like a crazy idea too. There is a time and place for everything, I'm sure objects aren't great for every system. A little bit of object "thinking" can help though, I'm sure.

As a formalist, the computer scientist expects order and logic. The "goodness" of a program is directly proportional to the degree to which it can be formally described and formally manipulated. Proof - as in mathematical or logical proof - of correctness for a piece of software is an ultimate objective. All that is bad in software arises from deviations from formal descriptions that use precisely defined tokens and syntactic rules. Art has no place in a program. In fact, many formalists would take the extreme position: there is no such thing as art; art is nothing more than a formalism that has yet to be discovered and explicated.

Art is something that I enjoy. One of the reasons that I was drawn to software was the creative aspects of it. I first thought of developing software as a form of art. It's great how Test Driven Development allows you to prove the correctness of a piece of software, but also enables you to refactor and be creative.

An analogy to chess playing might illuminate the relationships among method categories. A beginning chess player follows rules and defined procedures (they are formalists), while a journeyman (informalist) relies on patterns and heuristics. A grandmaster has internalized and transcended the informal to become an aformal player.

I'm currently reading a book on NLP, and it describes how experts do most of their work subconsciously, instead of consciously. It's like when you learn to drive a car (assuming you learned on a manual transmission). First you have a set of steps that you must follow, and repeat. Then you begin to follow patterns. (I used to look at my current speed to decide whether to shift gears.) Then you stop thinking about it, and you just drive.

A human uses mechanical weights and machines in a gym to increase his innate capabilities - to make his own muscles strong and more reliable. Using a more cerebral metaphor (and one therefore more appropriate for object thinking), Kent Beck suggest using method and even XP practices as if they were etudes (musical exercises designed to help the musician internalize certain skills and techniques.)

Time and Focus equates to discipline, according to me.  In order to excel at something you need to invest both time and focus to truly excel at it. There really is no secret to getting better.

A common tendency for new object developers is to list as responsibilities things that an object must "know." An airplane must "know its current location." While this may be true, it can be misleading. It implies too much about how the object might be implemented because "knows" implies an instance variable. It's also quite possible that an object will know things (a private key for decryption, perhaps) that it will not be willing to share with others and that therefore will not be included in the interface for that object. Provide private key would not appear as a service, although the message privateKey might be in the object's protocol with the designation that it is a private message. Decrypt message, on the other hand, might be a listed responsibility. Always state your responsibilities in terms of a service, with an awareness of a possible client for that service.

I know when I first started transitioning from procedural to object oriented programming, I thought mostly about where and how the data was going to stored, and how to get the data. "This auditor class needs to have a sorted list of audits"... Now it's a little more like "An auditor can submit an audit of a company to ..."

This was a great read for anyone wanting to get into objects, or learn more about the history of objects. It was great to read about were a lot of present day ideas originated from.

I finished reading...

Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) by Robert C. Martin, Micah Martin Read more about this book...

What an excellent book, seriously! It was written by Robert C. Martin and his son Micah. The following is a list of excerpts from the book that I can appreciate:

"Continuous attention to technical excellence and good design enhances agility. High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team members are committed to producing only the highest quality code they can. They do not make messes and then tell themselves that they'll clean up when they have more time. They clean any messes as they are made."

"The goal of refactoring, as depicted in this chapter, is to clean your code every day, every hour and every minute. We don't want the mess to build. We don't want to have to chisel and scrub the encrusted bits that accumulate over time. We want to be able to extend and modify our systems with a minimum of effort. The most important enabler of that ability is the cleanliness of code."

"Specifying contracts in unit tests. Contracts can also be specified by writing unit tests. By thoroughly testing the behavior of a class, the unit tests make the behavior of the class clear. Authors of client code will want to review the unit tests in order to know what to reasonably assume about the classes they are using."

"Databases are implementation details! Consideration of the database should be deferred as long as possible. Far too many applications were designed with the database in mind from the beginning and so are inextricably tied to those databases. Remember the definition of abstraction: "the amplification of the essential and the elimination of the irrelevant." At this stage of the project, the database is irrelevant; it is merely a technique used for storing and accessing data, nothing more."

"This style of testing is called behavior-driven development. The idea is that you should not think of tests as tests, where you make assertions about state and results. Instead, you should think of tests as specifications of behavior, in which you describe how the code is supposed to behave."

In case you haven't you should read...

xUnit Test Patterns: Refactoring Test Code (The Addison-Wesley Signature Series) by Gerard Meszaros Read more about this book...

As a reminder, let's talk about a test smell described in the above mentioned book. It's called "Conditional Test Logic".

"Conditional Test Logic: A test contains code that may or may not be executed." xUnit Test Patterns

"A fully automated test is just code that verifies the behavior or other code. But if this code is complicated, how do we verify that it works properly?"

Warning bells should sound off in your head when you start to see looping or conditional constructs within a single unit test.

"Code that has only a single execution path always executes in exactly the same way. Code that has multiple execution paths presents much greater challenges and does not inspire as much confidence about its outcome."

For more information check this out...

Basically Ignore Logic... that could cause multiple execution paths within a single unit test.

Tonight I finished reading...

C# in Depth: What you need to master C# 2 and 3 by Jon Skeet Read more about this book...

This was an amazing book, and definitely offers a great in depth look at the C# language. Most importantly it answered a lot of my questions about elements introduced in C# 3.0, and taught me things I didn't know about C# 1.0. If you're looking for information on the following items, then this book is definitely for you.

• Expression
• IQueryable
• IQueryProvider
• Lamba's
• Type Inferencing

Thanks JP for recommending this book!

Here are a few gems that I picked from this book.

Delegates

"You rarely see an explicit call to Delegate.Combine in C# code - usually the + and += operators are used."

          var x = new EventHandler(delegate {
}); var y = new EventHandler(delegate {
}); x += y; x = x + y;// same as above x = (EventHandler) Delegate.Combine(x,
y);// same as above

Static vs Dynamic Typing

"C# is statically typed: each variable is of a particular type, and that type is known at compile time. The alternate to static typing is dynamic typing, which can take a variety of guises. "

Explicit vs. Implicit Typing

"The distinction between explicit typing and implicit typing is only relevant in statically typed languages. With explicitly typing, the type of every variable must be explicitly stated in the declaration. Implicit typing allows the compiler to infer the type of the variable based on its use."

Covariant vs. Incovariant

          object[] stuff = new
string[]{"blah"}; //
valid and is an example of covariance List<object>
more_stuff = new List<string>();//
invalid and is an example of incovariance

Fluent Interfaces

Jon, the author, mentions a blog post by Anders Noras on Planning a fluent interface

Here's an example of a fluent interface for building menu's that I've been playing with.

CreateA.MenuItem()
.Named("&Close")
.BelongsTo(MenuGroups.File) .CanBeClickedWhen(m
=> task.IsThereAProtocolSelected()) .WhenClickedExecute(closeCommand) .Build();

Readability

"When it comes to getting the broad sweep of code, what is required is 'readability of results' - I want to know what the code does, but I don't care how it does it right now."

There's a lot of information on IQueryables, Expression Trees, and other goodness in this book. This is a great book and definitely worth reading, especially if you're as interested in the C# language as I am.

Last week I finished reading...

The 7 Habits of Highly Effective People by Stephen R. Covey Read more about this book...

I really enjoyed this book, it's definitely worth taking the time to sit down and read. I realized a lot about myself as I read it. Hopefully you will too! Here are a few excerpts from the book that had an impact on me.

"Management is a bottom line focus: How can I best accomplish certain things? Leadership deals with the top line: What are the things I want to accomplish?"

"... envision a group of producers cutting their way through the jungle with machetes. They're the producers, the problem solvers. They're cutting through the undergrowth, clearing it out.

The managers are behind them, sharpening their machetes, writing policy and procedure manuals, holding muscle development programs, bringing in improved technologies and setting up working schedules and compensation programs for machete wielders.

The leader is the one who climbs the tallest tree, surveys the entire situation, and yells, 'Wrong Jungle!'"

"Work Centeredness. Work-centered people may become 'workaholics,' driving themselves to produce at the sacrifice of health, relationships, and other important areas of their lives. Their fundamental identity comes from their work - 'I'm a doctor', 'I'm a writer', 'I'm an actor.'

Because their identity and sense of self-worth are wrapped up in their work, their security is vulnerable to anything that happens to prevent them from continuing in it. Their guidance is a function of the demands of the work. Their wisdom and power come in the limited areas of their work, rendering them ineffective in other areas of life."

"There are times when neither the teacher nor the student knows for sure what's going to happen. In the beginning, there's a safe environment that enables people to be really open and to learn and to listen to each other's ideas. Then comes brainstorming, where the spirit of evaluation is subordinated to the spirit of creativity, imagining, and intellectual networking. Then an absolutely unusual phenomenon begins to take place. The entire class is transformed with the excitement of a new thrust, a new idea, a new direction that's hard to define, yet it's almost palpable to the people involved."

"Suppose you were to come upon someone in the woods working feverishly to saw down a tree.

'What are you doing?' you ask.

'Can't you see?' comes the impatient reply. 'I'm sawing down this tree.'

'You look exhausted!' you exclaim. 'How long have you been at it?'

'Over five hours,' he returns, 'and I'm beat! This is hard work.'

'Well, why don't you take a break for a few minutes and sharpen that saw?' you inquire. 'I'm sure it would go a lot faster.'

'I don't have time to sharpen the saw,' then man says emphatically. 'I'm too busy sawing!'"

"Principles are natural laws that are external to us and that ultimately control the consequences of our actions. Values are internal and subjective and represent that which we feel strongest about in guiding our behavior."

I'm currently reading...

The 7 Habits of Highly Effective People by Stephen R. Covey Read more about this title...

I came across a paragraph that stuck out for me, and just wanted to share it:

"If you don't let a teacher know at what level you are -- by asking a questions, or revealing your ignorance - you will not learn or grow. You cannot pretend for long, for you will eventually be found out. Admission of ignorance is often the first step in our education."

This was immediately followed by the next powerful statement.

"Thoreau taught, 'How can we remember our ignorance, which our growth requires, when we are using our knowledge all the time?'"

Note to self, "be more ignorant..." *giggle* Have a great day!

I'm currently reading...

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman Read more about this book...

(I'm actually reading the 2nd edition)

This is a good book. It started off really boring... really boring! I picked up this book as an introduction to object oriented programming, and it started off with a lot of talk on UML, documentation and the Rational Unified Process. But then I got to chapter 16... "GRASP: Designing Objects with Responsibilities".

Here's an excerpt that I enjoyed!

"Perhaps the most common mistake when creating a domain model is to represent something as an attribute when it should have been a concept. A rule of thumb to help prevent this mistake is:

If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute."

Here's a definition for a Domain Model...

"The Domain Model provides a visual dictionary of the domain vocabulary and concepts from which to draw inspiration for the naming of some things in the software design."

Chapter 16 is great so far, it talks about how to decompose responsibilities for objects using an acronym (I'm not a fan of acronyms) called GRASP. GRASP stands for General Responsibility Assignment Software Patterns.

Craig goes on to talk about the five different patterns of GRASP. They are:

• Information Expert: the class that has the information necessary to fulfill the responsibility.
• Creator: a class that has the responsibility to create an instance of another class.
• High Cohesion: increase the measure of how strongly related and focused the responsibilities of an element are.
• Low Coupling: decrease the amount a class is connected to, has knowledge of, or relies on other elements.
• Controller: a class with the responsibility of receiving or handling a system event message.

A great book to read is...

Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts Read more about this title...

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

"The first time you do something, you just do it. The second time you something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."

Introduce Local Extension: A server class you are using needs several additional methods, but you can't modify the class.

Create a new class that contains these extra methods. Make this extension class a subclass or a wrapper of the original.

E.g From this...

          public
          interface
          IController{ void Execute();
} publicclassController : IController { protectedvoid RenderView(string name, object data){ //...
note that this is a protected method  } publicvoid Execute(){ //...  }
}

To this...

          public
          interface
          IViewRenderer{ void Render<T>(string name,
T data); } publicclassLocalExtensionController : Controller, IViewRenderer { publicvoid Render<T>(string name,
T data){ RenderView(name, data); } }

Replace Conditional with Polymorphism: You have a conditional that chooses different behavior depending on the type of an object.

Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.

E.g From this...

          public
          class
          Bird{ public Bird(BirdType type){
_type = type; } publicdouble GetSpeed(){ switch(_type){ caseBirdType.EUROPEAN: return 5; caseBirdType.AFRICAN: return 10; caseBirdType.NORWEGIAN_BLUE: return 20;
} thrownewArgumentException();
} privateBirdType _type;
} publicenumBirdType{
EUROPEAN, AFRICAN, NORWEGIAN_BLUE }

To this...

          public
          interface
          IBird{ double GetSpeed();
} publicclassEuropeanBird : IBird { publicdouble GetSpeed(){ return 5;
} } publicclassAfricanBird : IBird { publicdouble GetSpeed()
{ return 10; } } publicclassNorwegianBlueBird : IBird { publicdouble GetSpeed()
{ return 20; } } 

A couple of months ago I finished reading...

xUnit Test Patterns: Refactoring Test Code (The Addison-Wesley Signature Series) by Gerard Meszaros Read more about this book...

This was a thick book, that discusses unit test smells, unit test refactorings, unit test patterns... and just about anything else related to unit testing. Here's a little of what I've learned from this book...

Defect Localization

"Mistakes happen! Of course, some mistakes are much more expensive to prevent than to fix. Suppose a bug does slip through somehow and shows up in the Integration Build. If our unit test are fairly small (i.e., we test only a single behavior in each one), we should be able to pinpoint the bug quickly based on which test fails. This specificity is one of the major advantages that unit tests enjoy over customer tests. The customer tests tell us that some behavior expected by the customer isn't working; the unit tests tell us why. We call this phenomenon Defect Localization. If a customer test fails but no unit tests fail, it indicates a Missing Unit Test."

Tests as Documentation

"Without automated tests, we would need to pore over the SUT code trying to answer the question, 'What should be the result if ...?' With automated tests, we simply use the corresponding Tests as Documentation; they tell us what the result should be. If we want to know how the system does something, we can turn on the debugger, run the test, and single-step through the code to see how it works. In this sense, the automated tests act as a form of documentation for the SUT."

"When it is not important for something to be seen in the test method, it is important that it not be seen in the test method!"

Test Doubles

A test double is any object or component that we install in place of the real component for the express purpose of running a test. Depending on the reason why we are using it, a Test Double can behave in one of four ways.

• Dummy Object: a object that is passed to the SUT as an argument but is never actually used.
• Test Stub: an object that replaces a real component on that the SUT depends on so that different inputs can by applied against the SUT.
• Test Spy: an object that can act as an observation point for the indirect outputs of the SUT.
• Mock Object: an object that replaces a real component that the SUT depends on to test the and verify indirect outputs.
• Fake Object: an object that replaces the functionality of the real SUT dependency with an alternate implementation that provides the same functionality.

Strict vs Loose

Mock objects come in two basic flavors:

• Strict Mock: fails the test if incorrect calls are received.
• Loose (lenient) Mock: fails if expected calls are not received, but is lenient if additional calls are received.

Need-Driven Development

"This 'outside-in' approach to writing and testing software combines the conceptual elegance of the traditional 'top-down' approach to writing code with modern TDD techniques supported by Mock Objects. It allows us to build and test the software layer by layer, starting at the outermost layer before we have implemented the lower layers."

Test Smells

"Developers Not Writing Tests may be caused by an overly aggressive development schedule, supervisors who tell developers not to 'waste time writing tests,' or developers who do not have the skills to write tests. Other potential causes might include an imposed design that is not conducive to testing or a test environment that leads to Fragile Tests. Finally, this problem could result from Lost Tests - tests that exist but are not included in the All Tests Suite used by developers during check-in or by the automated build tool."

"Another productivity-sapping smell is Frequent Debugging. Automated unit tests should obviate the need to use a debugger in all but rare cases, because the set of tests that are failing should make it obvious why the failure is occurring. Frequent Debugging is a sign that the unit tests are lacking in coverage or are trying to test to much functionality at once."

Fragile Test: "A test fails to compile or run when the SUT is changed in ways that do not affect the part the is exercising... Fragile tests increase the cost of test maintenance by forcing us to visit many more tests each time we modify the functionality of the system or the fixture."

This headache is typical if you're working with strict mock objects. I experienced this pain when working on a project using NMock. I couldn't find a clean separation between strict and loose mocks using NMock. There was only the concept of Strict Mocks and Stubs.

Slow Tests: "The tests take too long to run... They reduce the productivity of the person running the test. Instead, the developers wait until the next coffee break or another interruption before running them. Or, whenever they run the tests, they walk around and chat with other team members..."

The main disadvantages of using Fit are described here:

• The test scenarios need to be very well understood before we can build the Fit Fixture. We then need to translate each test's logic into a tabular representation; this isn't always a good fit.
• The tests need to employ the same SUT interaction logic in each test. To run several different styles of tests, we would probably have to build one or more different fixtures for each style of test. Building a new fixture is typically more complex than writing a few Test Methods.
• Fit tests aren't normally integrated into developers' regression tests that are run via xUnit. Instead, these test must be run separately - which introduces the possibility that they will not be run at each check-in.

Pull

"A concept from lean manufacturing that states that things should be produced only once a real demand for them exists. In a 'pull system,' upstream assembly lines produce only enough products to replace the items withdrawn from the pool that buffers them from the downstream assembly lines. In software development, this idea can be translated as follows: 'We should only write methods that have already been called by other software and only handle those cases that the other software actually needs.' This approach avoids speculation and the writing of unnecessary software, which is one of software development's key forms of inventory (which is considered waste in lean systems)."

I'm just about finished reading...

Agile Web Development with Rails, 2nd Edition by Dave Thomas, David Hansson, Leon Breedt, Mike Clark, James Duncan Davidson, Justin Gehtland, Andreas Schwarz Read more about this book...

This book focuses on the Ruby on Rails framework for developing web applications. It touches very lightly on the Ruby language itself, but mostly talks about things like Model View Controller, Active Record, Action Pack and how it's implemented in RoR's. The book starts off with a light primer on what MVC is, which I enjoyed, then moves on to how to install RoR, then jumps right into building a quick application using RoR. I enjoyed the discussion Testing and the concept of Migrations.

Before jumping right in to chapter one I quickly read through the first Appendix titled "Introduction to Ruby", which helped a little bit, but I probably would have done better if I had first read a book just on the Ruby language. I think I would have found it more interesting as well. There were times in the book where it got so deep into the nitty gritty details of the RoR framework that I just completely lost interest. I choose to read this book to get some high level ideas, but I wasn't as interested in the tiny details of the framework. There's tonnes of great ideas in this book, that I recognize being adopted quite a bit in the .NET community. Migrations and MVC being a couple of my favorites.

Here's a few excerpts that I enjoyed from this book...

Convention over Configuration

"Rails gives you lots of opportunities to override this basic workflow ... As it stands, our story illustrates convention over configuration, one of the fundamental parts of the philosophy of Rails. By providing convenient defaults and by applying certain conventions, Rails applications are typically written using little or no external configuration - things just knit themselves together in a natural way."

Migrations

"Over the years, developers have come up with ways of dealing with this issue. One scheme is to keep the Data Definition Language (DDL) statements that define the schema in source form under version control. Whenever you change the schema, you edit this file to reflect the changes. You then drop your development database and re-create the schema from scratch by applying your DDL. If you need to roll back a week, the application code and the DDL that you check out from the version control system are in step: when you re-create the schema from the DDL, your database will have gone back in time.

Except... because you drop the database every time you apply the DDL, you lose any data in your development database. Wouldn't it be more convenient to be able to apply only those changes that are necessary to move a database from version X to version Y? this is exactly what Rails migrations let you do."

E.g. 001_create_products.rb

class CreateProducts < ActiveRecord:Migration
    def self.up
        create_table :products do |t|
            t.column :title,        :string
            t.column :description    :text
            t.column :image_url        :string
        end
    end
    def self.down
        drop_table :products
    end
end

Pragmatic Ajax-ification

"In the old days, browsers were treated as really dumb devices. When you wrote a browser-based application, you'd send stuff down to the browser and then forget about that session. At some point, the user would fill in some form fields or click a hyperlink, and your application would get woken up by an incoming request. It would render a complete page back to the user, and the whole tedious process would start afresh...

Whenever you work with AJAX, it's good to start with the non-AJAX version of the application and then gradually introduce AJAX features."

No REST For The Wicked

"REST stands for REpresentational State Transfer, which is basically meaningless. What it really means is that you use HTTP verbs (GET, POST, DELETE, and so on) to send requests and responses between applications."

Performance Testing

"Testing isn't just about whether something does what it should. We might also want to know whether it does it fast enough.

Before we get to deep into this, here's a warning. Most applications perform just fine most of the time, and when they do start to get slow, it's often in ways we would never have anticipated. For this reason, it's normally a bad idea to focus on performance early in development. Instead, we recommend using performance testing in two scenarios, both late in the development process."

Statement Modifiers

"Ruby statement modifiers are a useful shortcut if the body of an if or while statement is just a single expression. Simply write the expression, followed by if or while and the condition."

The following is valid Ruby syntax:

puts "Danger, Will Robinson" if radiation > 3000

I would love to express the following C# syntax....

          public
          void AddLicense(ILicense license){ if(license.IsValid()){
licenseRepository.Add(license); } }

Like this...

          public
          void AddLicense(ILicense license){
licenseRepository.Add(license).If(license.IsValid()); }

I'm still reading...

Effective Java(TM) Programming Language Guide (The Java Series) by Joshua Bloch Read more about this book...

Here's a few quotes from the book, that I found interesting:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald E. Knuth

"Don't sacrifice sound architectural principles for performance. Strive to write good programs rather than fast ones. If a good program is not fast enough, its architecture will allow it to be optimized. Good programs embody the principle of information hiding: Where possible, they localize design decisions within individual modules, so individual decisions can be changed without affecting the remainder of the system."

A typical example of pre-mature optimization is thinking about "database calls" when working up in a UI layer. These are two completely separate architectural layers and should be developed without "optimization" constraints in mind.

For example:

"...we have to check if its a post back, to make sure we don't make another database hit. If we retrieve the contents of the page each time the page is requested that's going to be another database hit."

Relax... there are lots of techniques (lazy loading, identity map...) to improve performance if it's an issue. But optimizing the UI for database performance is weak, and will more than likely cause you to build a crippled UI layer before even hitting the lower layers.

"Often attempted optimizations have no measurable effect on performance; sometimes they make it worse."

If we take the above example, if you're constantly "optimizing" for database performance be weary of what it's costing you. E.g... ViewState, extra conditional code that's sooo freakin' impossible to understand, that no dev wants to come back and touch that code.

It can be pointless to try to find solutions to a problem that doesn't exist.

I'm currently reading...

Effective Java(TM) Programming Language Guide (The Java Series) by Joshua Bloch Read more about this book...

I thought I would share en excerpt that I read this morning on the bus... it's about my favorite topic: Implementation Inheritance.

"Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software. It is safe to use inheritance within a package, where the subclass and the superclass implementation are under the control of the same programmers. It is also safe to use inheritance when extending classes specifically designed and documented for extension. Inheriting from ordinary concrete classes across package boundaries, however, is dangerous. As a reminder, this book uses the word 'inheritance' to mean 'implementation inheritance' (when one class extends another). The problems discussed in this item do not apply to interface inheritance (when a class implements an interface or where one interface extends another)."

"Unlike method invocation, inheritance breaks encapsulation. In other words, a subclass depends on the implementation details of its superclass for its proper function."

I recently finished reading...

C# 3.0 in a Nutshell: A Desktop Quick Reference (In a Nutshell (O'Reilly)) by Joseph Albahari, Ben Albahari Read more about this title...

My desire to read this book was to understand what new language features C# 3.0 brings to the table. This book started to explain the C# language right from the very beginning up until now. So some of it was a great refresher and some of it was quite boring. It not only covers the new language features but covers several areas of the framework class libraries and new lib's that came with the .NET 3.5 stack.

I was hoping to find my coverage on the new language features to see different usages for things like extension methods and lambda's to try to get a sense for what I like and don't like. So far I'm not really a fan of the new query comprehension syntax. It's to SQL-ish for me... I prefer working directly against methods. But I might have to give it some time... enough ranting here's some of the things I've learned.

Lambda Expressions

There's tonnes, and tonnes of discussion on this topic right now. I love how it's so much cleaner, and less verbose then anonymous delegates, but I see potential room for abuse. IMHO seeing lambda's tossed around all over your code base is no better then over using anonymous delegates. I love the new ideas that lambda's bring though...

"A lambda expression is an unnamed method written in place of a delegate instance. The compiler immediately converts the lambda expression to either:

• A delegate instance.
• An expression tree, of type Expression<T>, representing the code inside the lambda expression in a traversable object model. This allows the lambda expression to be interpreted later at runtime..." - C# 3.0 in a Nutshell

I love the idea of building up an expression tree of delegates that chain together to solve an equation. One of the ideas I'm working on is understanding how to leverage an expression tree of lambdas to solve trivial mathematical equations. Then possible traversing through the structure with a visitor to build out a display friendly version of the equation.

WPF

"The benefits of WPF are as follows:

• It supports sophisticated graphics, such as arbitrary transformations, 3D rendering, and true transparency.
• Its primary measurement unit is not pixel-based, so applications display correctly in any DPI
• It has extensive dynamic layout support, which means you can localize any application without danger of elements overlapping.
• Rendering uses DirectX and is fast, taking good advantage of graphics hardware acceleration.
• User interfaces can be described declaratively in XAML files that can be maintained independently of the "code-behind" files - this helps to separate appearance from functionality." - C# 3.0 in a Nutshell

WCF

"WCF is the communication infrastructure new to Framework 3.0. WCF is flexible and configurable enough to make both of its predecessors - Remoting and (.ASMX) Web Services - mostly redundant." - C# 3.0 in a Nutshell

XML

"If you're dealing with data that's originated from or destined for an XML file, XmlConvert (the System.Xml namespace) provides the most suitable methods for formatting and parsing. The methods in XmlConvert handle the nuances of XML formatting without needing special format strings." - C# 3.0 in a Nutshell

Iterators

"The compiler, upon parsing the yield return statement, writes 'behind the scenes,' a hidden nested enumerator class, and then refactors GetEnumerator to instantiate and return that class. Iterators are powerful and simple" - C# 3.0 in a Nutshell

Hash Tables

"Its underlying hashtable works by converting each element' key into an integer hashcode - a pseudo unique value - and then applying an algorithm to convert the hashcode into a hash key. This hash key is used internally to determine which 'bucket' an entry belongs to. If the bucket contains more than one value, a linear search is performed on the bucket. A hashtable typically starts out maintaining a 1:1 ration of buckets to values, meaning that each bucket contains only one value. However, as more items are added to the hashtable, the load factor dynamically increases, in a manner designed to optimize insertion and retrieval performance as well as memory requirements." - C# 3.0 in a Nutshell

Serialization

"The data contract serializer is the newest and the most versatile of the three serializatoin engines and is used by WCF. The serializer is particularly strong in two scenarios:

• When exchanging information through standards-compliant messaging protocols
• When you need high-version tolerance plus the option of preserving object references."

C# 3.0 in a Nutshell

Threading

"A Mutex is like a C# lock, but it can work across multiple processes. In other words, Mutex can be computer-wide as well as application-wide" - C# 3.0 in a Nutshell

"A Semaphore is like a nightclub: it has a certain capacity, enforced by a bouncer. Once it's full, no more people can enter and a queue build up outside. Then, for each person that leaves, one person enters from the head of the queue." - C# 3.0 in a Nutshell

"The Thread class provides GetData and SetData methods for storing nontransient isolated data in 'slots' whose values persist between method calls." - C# 3.0 in a Nutshell

I just finished reading...

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) by Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides Read more about this title...

It's about time I read this book... This catalog contains 23 patterns with examples in C++. I enjoyed reading this book. I found at times that my mind started to drift off, but then there were moments when I would forget where I was and miss my bus stop. (Ok one moment!)

I enjoyed reading the discussion on OO more then anything else in this book. The examples are a little dated but for it's time the catalog is awesome. Although I've been wanting to read this book for a while I preferred "Head First Design Patterns", mostly because it was easy to read. (I call it the comic book for dev's)

As usual, here are some quotes from the book that I really enjoyed.

"When an abstraction can have one of several possible implementations, the usual way to accommodate them is to use inheritance. An abstract class defines the interface to the abstraction, and concrete subclasses implement it in different ways. But this approach isn't always flexible enough. Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend and reuse abstractions and implementations independently."

"Studies of expert programmers for conventional languages have shown that knowledge and experience isn't organized simply around syntax but in larger conceptual structures such as algorithms, data structures and idioms, and plans for fulfilling a particular goal. Designers probably don't think about the notation they're using for recording the design as much as they try to match the current design situation against plans, algorithms, data structures, and idioms they have learned in the past."

"These design patterns can also make you a better designer. They provide solutions to common problems. If you work with object-oriented systems long enough, you'll probably learn these design patters on your own. But reading the book will help you learn them much faster. Learning these patterns will help a novice act more like an expert."

"To continue to evolve, the software must be reorganized in a process known as refactoring. This is the phase in which frameworks often emerge. Refactoring involves tearing apart classes into special- and general-purpose components, moving operations up or down the class hierarchy, and rationalizing the interfaces of classes. This consolidation phase produces many new kinds of objects, often by decomposing existing objects and using object composition instead of inheritance. Hence black-box reuse replaces white-box reuse. The continual need to satisfy more requirements along with the need for more reuse propels object-oriented software through repeated phases of expansion and consolidation - expansion as new requirements are satisfied, and consolidation as the software becomes more general."

I've got a beef with enums. When I see them, I cringe... which is quite different from my days in C, where I couldn't live without enums and structs. That's another story...

"Flyweight: Use sharing to support large numbers of fine-grained objects efficiently" - Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) by Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides Read more about this title...

Why do some of us quickly jump to enums? In procedural languages it makes sense. It's giving a type code a human readable meaning. So instead of having to stare at type code 1, everywhere you can use State.Acknowledgement, which is a lot easier to understand ... what does 1 mean again?

But in an OO language, I feel dirty when I see enums. The argument of using it for bitwise operations and the Flags attribute is weak. Create a composite!

    [Flags] publicenumDigits {
Zero = 0x00, One = 0x01, Two = 0x02, Three = 0x03, Four = 0x04, Five = 0x05, Six =
0x06, Seven = 0x07, Eight = 0x08, Nine = 0x09 }

    [Test] publicvoid Should_be_equal_to_2_digits()
{ Digits digits = Digits.Six
| Digits.One; Assert.IsTrue( Digits.Six
== (digits & Digits.Six) ); Assert.IsTrue( Digits.One
== (digits & Digits.One) ); }

Weak... do you really want to use a bitwise & to check if a certain digit is enabled. I don't. I'm going to use the following 2 tests to squash the enum into a first class component, with some smarts to it.

        [Test] publicvoid should_be_able_to_add_a_single_digit()
{ INumberBuilder builder = CreateSUT(
); builder.Add( Digits.One ); Assert.AreEqual( newNumber(
1 ), builder.Build( ) ); } [Test] publicvoid should_be_able_to_form_a_number_with_more_than_one_digit()
{ INumberBuilder builder = CreateSUT(
); builder.Add( Digits.One ); builder.Add( Digits.Nine
); Assert.AreEqual( newNumber(
19 ), builder.Build( ) ); }

My current NumberBuilder implementation looks like this (it sucks but it works):

          public
          class
          NumberBuilder : INumberBuilder { publicvoid Add( Digits digit
) { numberBeingBuilt += Convert.ToString( Convert.ToInt32(
digit ) ); } publicINumber Build()
{ returnnewNumber( Convert.ToInt32(
numberBeingBuilt ) ); } privatestring numberBeingBuilt;
}

I'm going to start off by creating some Flyweights.

          public
          class
          Digits { publicstaticreadonlyIDigit Eight
= newDigit(
8 ); publicstaticreadonlyIDigit Five
= newDigit(
5 ); publicstaticreadonlyIDigit Four
= newDigit(
4 ); publicstaticreadonlyIDigit Nine
= newDigit(
9 ); publicstaticreadonlyIDigit One
= newDigit(
1 ); publicstaticreadonlyIDigit Seven
= newDigit(
7 ); publicstaticreadonlyIDigit Six
= newDigit(
6 ); publicstaticreadonlyIDigit Three
= newDigit(
3 ); publicstaticreadonlyIDigit Two
= newDigit(
2 ); publicstaticreadonlyIDigit Zero
= newDigit(
0 ); publicclassDigit : IDigit { public Digit( int digitToRepresent
) { _digitToRepresent = digitToRepresent; } publicoverridestring ToString()
{ return _digitToRepresent.ToString( ); } privatereadonlyint _digitToRepresent;
} }

My compiler is telling me that the Add method on my builder currently accepts a parameter of type "Digits", so I'm going to change the signature to accept a parameter of type IDigit.

          public
          interface
          INumberBuilder { void Add( Digits digit
); INumber Build(); }

To...

          public
          interface
          INumberBuilder { void Add( IDigit digit
); INumber Build(); }

Let's update the NumberBuilder implementation to:

          public
          class
          NumberBuilder : INumberBuilder { public NumberBuilder()
{ _digitsOfNumberBeingBuilt = newList< IDigit >(
); } publicvoid Add( IDigit digit
) { _digitsOfNumberBeingBuilt.Add( digit ); } publicINumber Build()
{ returnnewNumber(
CreateIntegerFrom( _digitsOfNumberBeingBuilt ) ); } privateint CreateIntegerFrom( IEnumerable< IDigit >
digitsOfNumberBeingBuilt ) { StringBuilder builder
= newStringBuilder(
); foreach ( IDigit digit in digitsOfNumberBeingBuilt
) { builder.Append( digit ); } returnConvert.ToInt32(
builder.ToString( ) ); } privateIList< IDigit >
_digitsOfNumberBeingBuilt; }

I run the tests and they pass, sweet. But I'm not happy with the current implementation, so I look for other potential refactorings. I decide to forward the digit to append right to the number, the number can take care of how to append the digit, rather then having the builder doing so. The builder now looks like:

          public
          class
          NumberBuilder : INumberBuilder { public NumberBuilder()
{ _numberBeingBuilt = newNumber(
0 ); } publicvoid Append( IDigit digit
) { _numberBeingBuilt = _numberBeingBuilt.Append( digit ); } publicINumber Build()
{ return _numberBeingBuilt; } privateINumber _numberBeingBuilt;
}

And Number looks like:

          public
          class
          Number : INumber, IEquatable< Number >
{ public Number() : this(
0 ) {} public Number( int numberToRepresent
) { _numberToRepresent = numberToRepresent; } publicINumber Append( IDigit digit
) { returnnewNumber(
( _numberToRepresent*10 ) + digit.Value( ) ); } publicbool Equals( Number number
) { if ( number == null )
{ returnfalse;
} return _numberToRepresent == number._numberToRepresent;
} publicoverridestring ToString()
{ return _numberToRepresent.ToString( );
} publicoverridebool Equals( object obj
) { if ( ReferenceEquals( this,
obj ) ) { returntrue;
} return Equals( obj asNumber );
} publicoverrideint GetHashCode()
{ return _numberToRepresent; } privatereadonlyint _numberToRepresent;
}

To wrap this up, Number aggregates digits, the enum got dropped and was replaced by a class. There's still more refactorings that can occur, but the point is that a full blown component is much easier to extend then an enum...

For more info check out "Replace Type Code with Class" from...

Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts Read more about this title...

 Soure:

• Before
• After

This month I read...

Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts Read more about this title...

This book is awesome and a must read for anyone who enjoys the art of refactoring as much as I do. The examples are crystal clear and the way the refactorings are done step by step makes it so much more understandable.

Here are a few excerpts that I enjoyed from this book.

"The problem with copying and pasting code comes when you have to change it later. If you are writing a program that you don't expect to change, then cut and paste is fine. If the program is long lived and likely to change, then cut and paste is a menace."

I've got to agree and disagree with the above statement. I think anytime you find yourself copying and pasting is a clear sign of duplication which should be improved. Removing duplication should be something we all strive for, and remember that inheritance is not the only way to remove duplication. Proper object composition, delegation and generics are all great ways to remove duplicate code.

Replace conditional with Polymorphism has to be by far one of my favorite refactorings. If you're seeing if-else statements scattered throughout your code base that's a smell. Switch's are no better... (booo switches...)

"Is renaming worth the effort? Absolutely. Good code  should communicate what it is doing clearly, and variable names are a key to clear code. Never be afraid to change the names of things to improve clarity."

Amen, brother! Thank goodness for tools like Resharper and Rhino.Mocks. On my current project we're using NMock2 and I got burned several times doing a Rename Method because of the string literals used in NMock tests... My advice is just use Rhino Mocks... please... for my sake!

"You write code that tells the computer what to do, and it responds by doing exactly what you tell it. In time you close the gap between what you want it to do and what you tell it to do. Programming in this mode is all about saying exactly what you want. But there is another use of your source code. Someone will try to read your code in a few months' time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important."

"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."

I often heard the term "smell" used as a way to describe something funky in a code base or team but I had no idea where the term came from... until know!

"If it stinks, change it." - Gradma Beck, discussing child-rearing philosophy

The chapter on code smells is awesome, it's offers a catalog of code smells like:

• Duplicate Code
• Long Methods
• Large Classes
• Long Parameter Lists
• Divergent Changes
• Shotgun Surgery
• Feature Envy
• Data Clumps
• Primitive Obsession
• Switch Statements
• Parallel Inheritance Hierarchies
• Lazy Class
• Speculative Generality - "Oh, I think we need the ability to do this kind of thing someday."
• Temporary Fields
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with Different Interfaces
• Incomplete Library Classes
• Data Classes
• Refused Bequest - "Subclasses get to inherit the methods and data of their parents. But what if they don't want or need what they are given?"
• Comments

If you only read one chapter in this book, I suggest Chapter 3. "Bad Smells in Code". I really like how Resharper uses the same refactoring names as those mentioned in this book. Anyway's, what are you waiting for go read this book.

This month I read...

Hackers and Painters: Big Ideas from the Computer Age by Paul Graham Read more about this title...

This was not what I expected, but then again I wasn't really sure what I expected. But I liked it, the first chapter kind of caught me off guard, but some of the analogies and comparisons make a lot of sense. You can tell that Mr. Paul Graham sure is a thinker!

Here are a few excerpts from the book that I found enjoyable:

"Big companies win by sucking less than other big companies."

"You learn to paint mostly by doing it. Ditto for hacking. Most hackers don't learn to hack by taking college courses in programming. They learn by writing programs of their own at age thirteen. Even in college classes, you learn to hack mostly by hacking."

"Maybe it would be good for hackers to act more like painters, and regularly start over from scratch, instead of continuing to work for years on one project, and trying to incorporate all their later ideas as revisions."

"If I could get people to remember just one quote about programming, it would be the one at the beginning of Structure and Interpretation of Computer Programs.

Programs should be written for people to read, and only incidentally for machines to execute."

"When you catch bugs early, you also get fewer compound bugs. Compound bugs are two separate bugs that interact: you trip going downstairs, and when you reach for the handrail it comes off in your hand."

"Mistakes are natural. Instead of treating them as disasters, make them easy to acknowledge and easy to fix. Leonardo more or less invented the sketch, as a way to make drawing bear a greater weight of exploration. Open source software has fewer bugs because it admits the possibility of bugs."

"Of all tyrannies, a tyranny exercised for the good of its victims may be the most oppressive. - C.S. Lewis"

"One of my first drawing teachers told me: if you're bored when you're drawing something, the drawing will look boring."

"Indeed, there is even a saying among painters: 'A painting is never finished. You just stop working on it.'"

There is so much great content in this book that just provokes thought. I highly encourage you to go check it out, it's definitely worth reading and re-reading.

One of the books I've read this month is....

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck, Cynthia Andres Read more about this title...

I really enjoyed reading this book. It paints a picture of what an ideal XP team can look like and talks about the principals, practices and values of XP. I'd like to share some excerpts from the book that really stuck out and hand an impact on me.

"If you have six weeks to get a project done, the only thing you can control is your own behavior. Will you get six weeks' worth of work done or less? you can't control others' expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not my job to "manage" someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly."

One of the things I learned about myself is that I hate being late. This isn't a great trait to have in the world of software development. When I'm handed a deadline I become so eager to meet it that in the process of racing to the deadline quality is compromised. I can't control deadlines or others expectations but I can control my own behavior and if I work consistently as hard as I can without letting go of quality.

"I chose practices for XP because they meet both business and personal needs. There are other human needs; such as rest, exercise, and socialization; that don't need to be met in the work environment. Time away from the team gives each individual more energy and perspective to bring back to the team. Limiting work hours allows time for these other human needs and enhances each person's contributions while he is with the team."

It sucks how XP and Agile have become buzzwords in the industry that mean more to the marketing department then to the software developers. I've said it before and I'll say it again...

"You aren't doing Agile. YOU ARE AGILE!"

"Part of the challenge of team software development is balancing the needs of the individual with the needs of the team. The team's needs may meet your own long-term individual goals, so are worth some amount of sacrifice. Always sacrificing your own needs for the team's doesn't work. If I need privacy, I am responsible for find a ways to get my need met in a way that doesn't hurt the team. The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together."

You've got to sacrifice something, regardless of context you're talking about, in order to succeed. What's important is deciding on what you're willing to sacrifice in order to get closer to your end goals. I have found that pushing the people outside of their comfort zone a little bit not only helped me in growing but also the team as a whole. I also learned that it's important to slow down and reflect. The up and down rhythm of an XP team is balanced by the different members of a team, and with trust it's much easier to maintain that balance.

E.G. Team member A might be a hardcore, heads down, must punch out code as efficiently as possible. Team member B may be more of a let's take it a little slower and sit back and think about the problem at hand kind of guy. With trust the two team members will be able to develop a rhythm that keeps the project going at a sustainable pace without sacrificing quality.

"I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve."

Test-driven development/design rather then design in your head driven code. The test is a clear statement of truth. It documents the design that would otherwise be locked up in your head and is very black of white about whether or not the subject under test satisfies the test specification or behavior that is expected. If the team is not disciplined even the best of the best XP teams can forget about the principals behind the practices, and stop following the practices. One of the most important things about unit tests is the early feedback. I want to know as soon as possible when a component in the system is not behaving as expected. By waiting for QA to pick out bugs, then log a bug, then assign a developer to look at the bug does not deliver early feedback, I consider this waste! It's a vicious cycle that can be reduced greatly.

"The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?"

Out of all the chapters in this book I think chapter 3 is my favorite. It's titled "Values, Principles, and Practices", and to me it speaks the loudest of what is XP and why would we want to consider using it as a methodology for building and delivering software.

I highly recommend this book!

I just finished reading...

Programming .NET Components, 2nd Edition by Juval Lowy Read more about this title...

This was a pretty sweet read, I think this along with CLR via C# work well with one another. This book goes into a little more depth on threading and issues with concurrency. As well the chapters on remoting are long and full of tonnes of information. Way more then this guy could absorb after an initial read. I have so much to learn about remoting.

This book starts right fr gooom the beginning. What is a component?

".. a component is a .NET class. For example, this is a .NET component:

          public
          class
          MyClass { publicstring GetMessage()
{ return"Hello";
} }"

I think one of my favorite chapters in this book was on "Interface-Based Programming" and talks about the importance of separating interface from implementation.

"Interface Factoring: When you factor an interface, always think in terms of reusable elements. In a component-oriented application, the basic unit of reuse is the interface."

"... proper interface-factoring results in more specialized, loosely coupled, fine-tuned, and reusable interfaces, and subsequently, those benefits apply to the system as well. In general, interface factoring results in interfaces with fewer members."

Another benefit, in my opinion, to interfaces is for learning a system. By checking out the interfaces defined in a subsystem you can get a flavor for what services are offered by each component. It's much easier to look at the interface contract to see the operations it performs then having to scan through concrete types. I equate this to header files in C. If I look at the header file I can see what operations are available from each library. I don't need to know how it was implemented, just where to find it.

"Windows Forms base classes make extensive use of ISynchronizeInvoke. The control class relies on underlying Windows messages and a message-processing loop (the message pump) to process them. The message loop must have thread affinity, because messages to a window are delivered only to the thread that created that window."

Juval shares many different helper classes for getting around some of the more trickier areas of .NET development, like threading, events, remoting and even how to use a mutex to only allow a single instance of a class to run.

          internal
          static
          class
          Program {
[STAThread] privatestaticvoid Main()
{ if ( IsFirstInstance( ) ) { Application.ApplicationExit
+= OnApplicationExit( ); Application.Run( newForm1(
) ); } } privatestaticbool IsFirstInstance()
{ _mutex = newMutex( false, Assembly.GetEntryAssembly(
).FullName ); bool owned = _mutex.WaitOne( TimeSpan.Zero, false ); return owned;
} privatestaticEventHandler OnApplicationExit()
{ returndelegate {
_mutex.ReleaseMutex( ); _mutex.Close( ); }; } privatestaticMutex _mutex;
}

I'd like to talk to you for a moment about my man The Event Aggregator. (Homeboy's been tossin' events for years!)

Martin Fowler defines the Event Aggregator as:

"Channel events from multiple objects into a single object to simplify registration for clients." - Martin Fowler

But he's so much more then that! This pattern comes in handy in state-ful environments, so.. hello WinForms/WPF. Sorry ASP.NET!

What this guy does is creates a single channel to find out what's going on and to raise events. Through the event aggregator you can subscribe to known events in the system as well as raise known events in the system.

Some examples for system wide events are Save, Loading, Shutdown. You can also create concepts for layer specific event aggregators that target certain layers of a system. For example UI only.

          public
          class
          ApplicationEvents { privatestaticreadonlyIEventAggregator aggregator; publicstaticreadonlyIEvent Save
= newEventRaiser( "Save" ); publicstaticreadonlyIEvent Loading
= newEventRaiser( "Loading" ); static ApplicationEvents(
) { aggregator = newEventAggregator(
); aggregator.Register( Save ); aggregator.Register( Loading ); } publicstaticvoid Raise( IEvent eventToRaise
) { aggregator.RaiseEvent( eventToRaise ); } publicstaticvoid SubscribeTo( IEvent eventToSubscribeTo, EventHandler handler
) { aggregator.AddHandler( eventToSubscribeTo.Name, handler ); } }

The ApplicationEvents becomes the central point for raising and subscribing to known application wide events. Type can be coupled to the aggregator but not to each other.

Let's start with the concept of a named event. An event is really nothing more then a delegate. In .NET there are 2 delegate signatures that are used for all events. The generic and non generic version of the EventHandler delegate. (Read More... )

A named event is an event with a name. He might look something like this guy?

    internalclassEventRaiser : IEvent {
        public EventRaiser( string name ) {
            _name = name;
            _handlers = newList< EventHandler >( );
        }

        publicstring Name {
            get { return _name; }
        }

        publicvoid Add( EventHandler handler ) {
            _handlers.Add( handler );
        }

        publicvoid Raise( ) {
            Raise( null, null );
        }

        publicvoid Raise( object sender, EventArgs data ) {
            foreach ( EventHandler handler in _handlers ) {
                if ( handler != null ) {
                    handler( sender, data );
                }
            }           
        }

        privatereadonlystring _name;
        privatereadonlyIList< EventHandler > _handlers;
    }

Underneath the hood it's the aggregator that's maintaining references to all the types that have subscribed to events.

          public
          class
          EventAggregator : IEventAggregator { public EventAggregator(
) { _events = newDictionary< string, IEvent >(
); } publicvoid Register( string eventName
) { Register( newEventRaiser(
eventName ) ); } publicvoid Register( IEvent eventToAdd
) { EnsureEventHasntBeenRegistered( eventToAdd ); _events.Add( eventToAdd.Name, eventToAdd
); } publicvoid AddHandler( string eventName, EventHandler handler
) { RetrieveEvent( eventName ).Add( handler ); } publicvoid RaiseEvent( string withEventName
) { RaiseEvent< EventArgs >( withEventName, null, EventArgs.Empty
); } publicvoid RaiseEvent( IEvent eventToRaise
) { RaiseEvent< EventArgs >( eventToRaise.Name, null, EventArgs.Empty
); } publicvoid RaiseEvent<
T >( string withEventName, object sender,
T data ) where T : EventArgs {
RetrieveEvent( withEventName ).Raise( sender, data ); } privateIEvent RetrieveEvent( string eventName
) { if ( _events.ContainsKey( eventName )
) { return _events[ eventName ]; } thrownewArgumentNullException(
eventName, "The Event Has Not Been Registered." );
} privatevoid EnsureEventHasntBeenRegistered( IEvent eventToAdd
) { if ( _events.ContainsKey( eventToAdd.Name
) ) { thrownewArgumentException( "Event
name has already been registered", eventToAdd.Name ); } } privatereadonlyIDictionary< string, IEvent >
_events; }

The concept is similar to Juval Lowy's EventHelper class defined in...

Programming .NET Components, 2nd Edition by Juval Lowy Read more about this title...

This week while I'm at home on holidays, I've been reading...

Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series) by Martin Fowler Read more about this title...

This book is amazing, I could probably read it over and over again. The patterns that it presents makes a lot of sense, the actual implementations and examples could probably re-vamped but I'm finding that it's a great starter to trying to understand the concepts.

So today I'm trying to grok this concept of the "IDENTITY MAP". The book defines it as:

"Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them."

I put together a quick implementation that I'm using for an assignment I'm writing for school. I'm creating repositories that have 2 dependencies. First dependency is a Data Mapper (not to be confused with a Mapper) and the second is an Identity Map.

As objects are requested from the repository, the repository is checking the identity map to see if an instance has been loaded, if it has it's immediately returned to the caller. If the object is not in the map the repository leverages the data mapper to load the object, then adds it to the map and returns it to the caller.

The Data Mapper is defined as:

"A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself." - PoEAA

I created a Layer Supertype to register objects in the map. The Domain Layer Super type demands that domain objects had an ID. The ID is what's getting used to load and register objects into the map.

The Layer Supertype is defined as:

"A type that acts as a the supertype for all types in it's layer." - PoEAA

The Domain Layer Super Type.

          public
          interface
          IDomainObject { long ID();
}

My actual implementation of the identity map looks like this...

          public
          class
          IdentityMap<
T > : IIdentityMap< T > where T
: IDomainObject { public IdentityMap()
{ _items = newList<
T >( ); } publicvoid Add(
T domainObject ) { EnsureObjectHasNotAlreadyBeenAdded( domainObject ); _items.Add(
domainObject ); } public T FindObjectWithIdOf( long idOfObjectToFind
) { foreach ( T item in _items
) { if ( item.ID( ).Equals( idOfObjectToFind
) ) { return item; } } returndefault(
T ); } privatevoid EnsureObjectHasNotAlreadyBeenAdded(
T domainObject ) { if ( ContainsObjectWithIdOf(
domainObject.ID( ) ) ) { thrownewObjectAlreadyAddedToIdentityMapException(
domainObject ); } } privatereadonlyIList<
T > _items; }

One of the benefits I like about the Identity Map is that it acts as an in memory cache for objects loaded from the database. This reduces the number of trips to and from the persistence store.

Source Code

On Thursday I finished reading...

Working Effectively with Legacy Code (Robert C. Martin Series) by Michael Feathers Read more about this title...

This was a pretty sweet read, but I think I would have gained more value from it if I were currently working on a legacy code base. (Please Don't read that as... "I want to work on a legacy code base.")

This book is loaded with a catalog of refactorings to improve the design of existing code and get it under a test harness. Below is a list of some of the quotes from the book that I stuck out for me...

"The Legacy Code Change Algorithm

1. Identify change points.
2. Find test points.
3. Break dependencies
4. Write tests.
5. Make changes and refactor.

Over time, tested areas of the code base surface like islands rising out of the ocean."

"Mock objects are fakes that perform assertions internally."

"...it is better to depend on interfaces or abstract classes than it is to depend on concrete classes. When you depend on less volatile things, you minimize the chance that particular changes will trigger massive recompilation."

"The heuristics for identifying responsibilities can really help you dig in and find new abstractions in old classes, but they are just tricks. The way to really get better at identification is to read more. Read books about design patterns. More important, read other people's code. Look at open-source projects, and just take some time to browse and see how other people do things. Pay attention to how classes are named and the correspondence between class names and the names of methods. Over time, you'll get better at identifying hidden responsibilities, and you'll just start to see them when you browse unfamiliar code."

"... when I first thought about becoming a programmer, I was really captivated by stories about super-smart programmers, those guys and gals who could keep the state of an entire system in their heads, write correct code on the fly, and know immediately whether some change was right or wrong...

Holding on to a lot of state mentally can be useful, but it doesn't really make us better at decision-making. At this point in my career, I think I'm a much better programmer than I used to be, even though I know less about the details of each language I work in."

"When interfaces were first introduced in languages, some people started naming interfaces by placing and "I" before the name of the class they were gleaned from...

The advantage to this sort of naming is that you don't really have to think about the name when you the extraction. The disadvantage is that you end up with a lot of code that has to know whether it is dealing with an interface. Ideally, it shouldn't care one way or another."

When I moved my DasBlog on to GoDaddy I found that my captcha controls (comment view and email view) were no longer showing. In the event log I was reading the following exception...

I'm paying for the cheapest possible plan i could find on GoDaddy which was the Economy Plan, I'm not sure if this following step is necessary if you're paying for a virtual dedicated host.

"System.TypeInitializationException: The type initializer for 'Gdip' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'gdiplus.dll':"

DasBlog doesn't ship with "Gdiplus.dll" so you'll have to download it and drop it into the bin directory.

Thanks for your help, Mr. Justice!

While I'm at it, I should drop a plug for...

The Money Book for the Young, Fabulous & Broke by Suze Orman Read more about this title...

I'm currently reading...

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans Read more about this title...

It's really as good as they say it is! And it's got me thinking... I really enjoy reading a book that makes me think, I sometimes prefer reading tech books that only give you concepts to think about. It's up to you to understand those concepts then find a way to implement them when you see their use is necessary. There's a lot of great concepts that came from this book, and after seeing them out in the wild in episodes of DNRTV and source code buried in svn repositories it's all starting to make sense...

• Entities: An object defined primarily by its identity is called an Entity.
• Value Objects: An object that describes some characteristic or attribute but carries no concept of identity.
• Aggregates: A cluster of associated objects that are treated as a unit for the purpose of data changes.
• Repositories: A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.
• Services: An operation offered as an interface that stands alone in the model, with no encapsulated state.
• Specifications: A predicate that determines if an object does or does not satisfy some criteria.

*Note: the definitions above are right out of the glossary.

The toughest part to grasp and seems to be the underlying theme of this book is "The Ubiquitous Language". The tough part is not grasping the "concept" but rather the implementation. The concept makes a lot of sense, but how you can practically apply it is a separate story. One that I think takes experience through trial and error. Time will tell...

Go buy this book, I know I will... until then thank you Mr. Adam! (just in case I can't I put it on my wish list for Santa, he always pulls through!)

After reading through some examples on specifications and reading through JP's example, this sparked some ideas in my mind. So I hacked together some code and came up with this. Let's say I've got a bank of questions, and that each question is part of a category, and I want to be able to search through the bank of questions...

[Test]
publicvoid Should_Return_3_Questions_That_Are_Not_Math(
) { IEnumerable< IQuestion >
matches = CreateSut( ).FindAllWhere( Question.IsIn( Any.Category
).But( Not.In( Category.Math
) ) ); Assert.AreEqual( 3, GetCountFor(
matches ) ); }

Notice the use of "But", I wonder if this will catch on...

Basically I started looking into creating specification for boolean operations, with a slightly different take from what the book offered and inspired by JP and Ayende. I'm not sure it's the most elegant interface, but I really wanted to be able to make the client code as readable as possible.

What I ended up with was types like "Is", "Not", "And" & "Or". I'm not sure I'm completely happy with the end product, but I see potential for extending this further, and the best part is how readable the code seems to be. I think that excites me more then anything else... I think I'm just starting to understand this concept of the "fluent" interface. Not truly implementing it well, seems to be difficult, but fun!

Here's what my Question type turned in too...

          public
          class
          Question : IQuestion { public Question( ICategory category
) { _category = category; } publicICategory Category
{ get { return _category;
} } publicstaticISpecification< IQuestion >
IsIn( ICategory category ) { returnIs.In(
category ); } publicstaticISpecification< IQuestion >
IsNotIn( ICategory category ) { returnNot.In(
category ); } privatereadonlyICategory _category;
} 

The Is type looks like...

          public
          class
          Is { publicstaticISpecification< IQuestion >
In( ICategory category ) { returnnewSpecification< IQuestion >( delegate( IQuestion question
) { return category.Equals( question.Category
); } ); } } 

And the "Not" type looks like...

          public
          class
          Not { publicstaticISpecification< IQuestion >
In( ICategory category ) { returnnewSpecification< IQuestion >( delegate( IQuestion question
) { return !category.Equals( question.Category
); } ); } } 

To me it still seems that the "Not" and "Is" types shouldn't be responsible for returning the specification, and that responsibility should belong to the Question, but I'm just not sure... and it's getting rather late so I should head to bed.

Source is attached!

1. You quickly deliver release 1.0 of a system, but with junky code.

2. You attempt to deliver release 2.0 of the system, but the junky code slows you down.

3. As you attempt to deliver future releases, you go slower and slower as the junky code multiplies, until people lose faith in the system, the programmers and even the process that got everyone into this position.

I read it from...

Refactoring to Patterns (The Addison-Wesley Signature Series) by Joshua Kerievsky Read more about this title...

So recently I started reading...

Gandhi An Autobiography: The Story of My Experiments With Truth by Mohandas Karamchand (Mahatma) Gandhi, Mahadev H. Desai Read more about this title...

And I realized how little I knew about Mahatma Gandhi, although just about everyone knows the name. Very few know the story, and I was definitely one of those.

I can't really believe how much this man has endured in his life, I'm only about half way through the book, but he's experienced so much in his life. I really think that it's the experiences in life help shape who we become, and the more we experience the better we become.

Here's one quote from the book that stuck out for me... (so far)

"It has always been a mystery to me how men can feel themselves honoured by the humiliation of their fellow beings." - Mahatma Gandhi

I finished reading CLR via C# about a week ago. If you haven't read this book and enjoy writing C#, you ought to go out right now and get yourself a copy. (I have yet to purchase a copy for myself, but lucky for me my good ol' pal Mr. Adam lent me his copy.) This book is amazing, I would have to say that my favorite chapters were on delegates and events. This is seriously a great book.

"When the C# compiler sees the delegate keyword used wherever a reference to a delegate object is expected, the compiler automatically defines a new private method in the class... This new method is called an anonymous method because the compiler creates the name of the method for you automatically, and normally, you wouldn't know it's name." - Jeffrey Richter, CLR via C#

So the below anonymous method would actually get compiled out to a full blown method, with a name given to it by the compiler.

          return
          delegate(T
x, T y) { return -comparison(x, y); };

Did you know that you can control event registration and un-registration?

          public
          class
          EventAggregator<
T > where T : EventArgs { public EventAggregator(
) { _lock = newobject(
); } publiceventEventHandler<
T > NewEvent { add { lock (
_lock ) { _newEvent += value; } } remove { lock (
_lock ) { _newEvent -= value; } } } publicvoid RaiseEvent(
T data ) { _newEvent.Invoke( this, data );
} privatereadonlyobject _lock; privateEventHandler<
T > _newEvent; }

I don't know about you but the above code blew my mind! "add", "remove"... whoa! (poof... the sound of my mind blowing up!)

I am seriously looking forward the 3rd edition, where I hope Jeffrey Richter talks about the new additions to the C# compiler in the .NET Framework 3.5. My goodness what are you still doing sitting there... go by this book...

CLR via C#, Second Edition (Pro Developer) by Jeffrey Richter Read more about this title...

I recently came across a problem, and I thought I would try to flex some of my developer muscle to try to solve it. The problem reads as follows:

Basic sales tax is applicable at a rate of 10% on all goods, except books,
food, and medical products that are exempt. Import duty is an additional
sales tax applicable on all imported goods at a rate of 5%, with no
exemptions.

When I purchase items I receive a receipt which lists the name of all the
items and their price (including tax), finishing with the total cost of the
items, and the total amounts of sales taxes paid.  The rounding rules for
sales tax are that for a tax rate of n%, a shelf price of p contains
(np/100 rounded up to the nearest 0.05) amount of sales tax.

Write an application that prints out the receipt details for these shopping
baskets...
INPUT:_

Input 1:
1 book at 12.49
1 music CD at 14.99
1 chocolate bar at 0.85

Input 2:
1 imported box of chocolates at 10.00
1 imported bottle of perfume at 47.50

Input 3:
1 imported bottle of perfume at 27.99
1 bottle of perfume at 18.99
1 packet of headache pills at 9.75
1 box of imported chocolates at 11.25

OUTPUT

Output 1:
1 book : 12.49
1 music CD: 16.49
1 chocolate bar: 0.85
Sales Taxes: 1.50
Total: 29.83

Output 2:
1 imported box of chocolates: 10.50
1 imported bottle of perfume: 54.65
Sales Taxes: 7.65
Total: 65.15

Output 3:
1 imported bottle of perfume: 32.19
1 bottle of perfume: 20.89
1 packet of headache pills: 9.75
1 imported box of chocolates: 11.85
Sales Taxes: 6.70
Total: 74.68
==========

To solve this problem I used a composite to calculate taxes. The "TaxComposite" type allows you to bundle several different taxes all in one type. So when calculating taxes, the calculation with iterate through all the taxes and add the calculated tax and return the total value.

          public
          class
          TaxComposite : ITax { public TaxComposite( paramsITax[]
taxes ) : this( newList< ITax >(
taxes ) ) {} public TaxComposite( IEnumerable< ITax >
taxes ) { _taxes = newList< ITax >(
taxes ); _amount = CalculateAmount( ); _type = CalculateType( ); } publicdouble Amount
{ get { return _amount;
} } publicTaxTypes Type
{ get { return _type;
} } publicIMoney CalculateTaxFor( IMoney price
) { return CalculateTaxFor( price, RoundingDelegateFactory.RoundToNearestTenCents
); } publicIMoney CalculateTaxFor( IMoney price, RoundingStrategy round
) { IMoney total = newMoney(
); Summary( delegate( ITax tax
) { total = total.Add( tax.CalculateTaxFor( price, round ) ); } ); return total;
} privatedouble CalculateAmount(
) { double amount = 0d; Summary( delegate( ITax tax
) { amount += tax.Amount; } ); return amount;
} privateTaxTypes CalculateType(
) { TaxTypes type = TaxTypes.None;
Summary( delegate( ITax tax
) { type = type | tax.Type; } ); return type;
} privatevoid Summary( Action< ITax >
toDo ) { foreach ( ITax tax in _taxes
) { toDo( tax ); } } privatereadonlyIList< ITax >
_taxes; privatereadonlydouble _amount; privatereadonlyTaxTypes _type;
}

"The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly." - Head First Design Patterns

I used a TaxFactory type to construct the TaxComposite type which gathers all the taxes that match a specified predicate and injects it into the TaxComposite constructor. It looks like...

          public
          static
          class
          TaxFactory { publicstaticITax Create( TaxTypes forTaxes
) { returnnewTaxComposite( Taxes.FindBy( delegate( ITax tax
) { return ( tax.Type & forTaxes )
== tax.Type; } ) ); }

The tax type is an enum that uses the flags attribute so that I can enable different bits for different taxes.

    [Flags] publicenumTaxTypes {
None = 0x00, Sales = 0x01, Import = 0x02 }

Taxes is a static type that contains different types of taxes. The FindBy method allows for different strategies to be passed into to gather different types of taxes based on different critera. The above example returns all the taxes that are enabled in the "forTaxes" argument. FindBy is defined like...

          public
          static
          IEnumerable< ITax >
FindBy( Predicate< ITax >
condition ) { foreach ( ITax tax in taxes
) { if ( condition( tax ) ) { yieldreturn tax;
} } }

I'm not sure if this is the most flexible design, but if i need to make changes to tax rates I can do that in one spot. The only catch is that it requires a re-compile to take a effect. In a full blown implementation I may want to consider using a "service" to retrieve the tax rates. Also, in this implementation in order to add new taxes I have to added it too 2 different locations. The first is the TaxTypes enum and the second is the Taxes static holder class. This leaves a bit of a smell...

Head First Design Patterns (Head First) by Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra Read more about this title...

If you take a look at the following line, you will probably recognize it as the signature for an event handler.

          public
          void Handler( object sender, EventArgs e
) {

The reason why event handlers are defined with this signature is because it matches the signature of the EventHandler delegate which looks like this:

          public
          delegate
          void
          EventHandler(object sender, EventArgs e);

So when you're registering an event handler to an event. You're adding a delegate to the internal list of delegates. (Think of a type safe array of function pointers.) So when the event is raised, each method in the list of delegates is raised, in the same order as they were registered in.

The following line:

container.MyEvent += newPlayingWithEventHandlers( Console.Out.WriteLine
).Handler;

Expands out to something like this...

          PlayingWithEventHandlers handlers
= newPlayingWithEventHandlers( Console.Out.WriteLine
); MulticastDelegate multicastDelegate
= newMulticastDelegate(
handlers, "Handler" );

You'll find that the MulticastDelegate constructor is protected so this code wont actually compile. Also, the event delegate is combining the newly added delegate that is registering for the event.

The following example uses 3 different delegates defined in the .NET Framework.

          //public delegate void
EventHandler(object sender, EventArgs e); 
          //public
delegate void TimerCallback(object state); 
          //public
delegate void Action<T>(T obj); 
          public
          class
          PlayingWithEventHandlers { privatereadonlyAction< string >
_action; public PlayingWithEventHandlers( Action< string >
action ) { _action = action; } publicvoid Handler( object sender, EventArgs e
) { _action( ( string )sender ); } } publicclassMyEventContainer { privateTimer _timer; public MyEventContainer(
) { _timer = newTimer( delegate( object state
) { MyEvent.Invoke( state, EventArgs.Empty
); }, "Tick", 0, 5000 ); } publiceventEventHandler MyEvent;
} publicclassBootstrap { publicstaticvoid Main(
) { MyEventContainer container = newMyEventContainer(
); container.MyEvent += newPlayingWithEventHandlers( Console.Out.WriteLine
).Handler; Console.In.ReadLine( );
} }

One of the benefits of using delegates that you can inline an anonymous delegate. The above line where the an instance of the Timer class is constructed could be re-written like...

_timer = newTimer( delegate {
MyEvent.Invoke( "Tick", EventArgs.Empty
); }, null, 0, 5000 );

The TimerCallBack's input parameter "state" is still passed to the delegate but the C# compiler allows for this shorthand which ignores the input parameter. The same code could also be re-written as...

          public MyEventContainer(
) { _timer = newTimer(
TimerClickHandler, "Tick", 0, 5000 );
} publicvoid TimerClickHandler( object state
) { MyEvent.Invoke( state, EventArgs.Empty
); }

This version creates a new method called "TimerClickHandler" that matches the "TimerCallback" delegate signature. Delegates can be quite fun... almost as fun as tables of function pointers in C.

For more information check out...

CLR via C#, Second Edition (Pro Developer) by Jeffrey Richter Read more about this title...

The Open-Closed Principle (OCP): Classes should be open for extension, and closed for modification.

The Don't Repeat Yourself Principle (DRY): Avoid duplicate code by abstracting out things that are common and placing those things in a single location.

The Single Responsibility Principle (SRP): Every object in your system should have a single responsibility, and all the objects services should be focused carrying out that single responsibility.

The Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. (The LSP is all about well-designed inheritance.)

The Hollywood Principle: Don't call us, we'll call you.

The Law of Demeter (The principle of least knowledge): Only talk to your immediate friends.

Delegation is when you hand over the responsibility for a particular task to another class or method.

Composition allows you to use behavior from a family of other classes, and to change that behavior at runtime.

Aggregation is when one class is used as part of another class, but still exists outside of that other class.

Encapsulate what varies.

Favor composition over inheritance.

Program to interfaces, not implementations.

Strive for loosely coupled designs between objects that interact.

Depend on abstractions. Do not depend on concrete classes.

Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D (Head First) by Brett D. McLaughlin, Gary Pollice, Dave West Read more about this title...

On my ride home from work Friday evening I finished reading...

The Greatness Guide: Powerful Secrets for Getting to World Class by Robin Sharma Read more about this title...

This was an excellent read! I just couldn't put it down after I first cracked it open. My boss at work popped by my desk on Wednesday, and handed me the book. She said that I would probably enjoy it! I did! Thanks Leanne!

The chapters are short and sweet, which makes it so easy to just pick up and read a chapter here and there. I wanted to share some of the insights from this book, but I highly encourage you to go out and read it yourself.

When I was growing up my father once told me: "Cut back on your rent or cut back on what you spend on food but never worry about investing money in a good book."

I really enjoy reading books. It really is like having a conversation with all sorts of great minds and views of the world! I'm really looking forward to one day being able to look back and think about all the wonderful books I've studied. I've learned so much from such a simple act, and teaching someone to read truly is precious.

"Not one of the uber-successful people I've worked with as a leadership coach got there without outworking everyone around them."

One of the other things that Robin mentioned in his book was that the price of discipline is not as painful as the price of regret. It's absolutely important to work heard to get ahead and for a sense of accomplishment. Feeling good about where you are, because of how hard you've worked is great!

"Faced an uphill battle: an aggressive enemy, brutal disease and scarce resources. As they marched inland to do battle, Cortes ordered one of his lieutenants back to the beach with a single instruction: "Burn our boats.""

Don't allow failure to be an option. Sometimes when dealing with all to difficult situations it's to easy to look for the backdoor out. But by changing your thinking so that you don't allow failure to be an option, you allow yourself to succeed. I also think this applied to being faithful and loyal to those you care about. It seems these days, it's so normal for partners to cheat on one another. Think ahead and don't allow yourself to be caught up in the moment.

"You need to practice to get to your greatness. Athletes know this so very well. Why does it seem so foreign to the rest of us?"

Duh! So schedule time to practice! In Jr. High and High School I had a friend who was a super athlete, he had accomplished more before 7 am then the regular teenager, including myself. He got it!

"If you eat three times a day you'll be fed. But if you read three times a day you'll be wise." - Shimon Peres

For some reason this quote spoke to me. It was silly how straight forward and simple this thought is, but it makes darn good sense!

"Study hip hop artists... You'll learn all you need to learn about taking a brand to the top of the mountain."

I'm a fan of hip hop, so any plug for it makes me smile!

I've downloaded every episode of Robin's podcast and found time each morning to listen to one episode each morning. I found that it's been a great way to start my day. I just hope he continues to publish more episodes.

This Wednesday, September, 12, 2007 I will be attending a private presentation by Robin Sharma here in Calgary. I'm really looking forward to the presentation!

To demo how the Factory Method and Abstract Factory patterns work I've put together an example in C#. For this example I've got 2 different Banks, CIBC, and Royal Bank. Each bank offers a chequing and savings account. Through the use of the Factory Method and Abstract Factory, the sample shows you how to create different types of bank accounts.

"The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." - Head First Design Patterns

IBank has a single method called "GetAccountFactory()" that returns a IBankAccountFactory. This allows types that implement the interface to specify what type of bank account factory to construct and return.

          public
          interface
          IBank { string Name
{ get; } IBankAccountFactory GetAccountFactory(
); }

So CIBC implementation of IBank will return a CIBCBankAccountFactory.

          public
          class
          CibcBank : Bank, IBank { public CibcBank(
) : base( "CIBC" )
{} publicoverrideIBankAccountFactory GetAccountFactory(
) { returnnewCibcBankAccountFactory(
); } }

"The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes." - Head First Design Patterns

IBankAccountFactory is an abstract factory for creating different types of bank accounts. In my provided example you'll see that the IBankAccountFactory has two methods defined in it, both of which return an IBankAccount:

• CreateChequingAccount()
• CreateSavingsAccount()

          public
          interface
          IBankAccountFactory { IBankAccount CreateChequingAccount(
); IBankAccount CreateSavingsAccount(
); }

To create a CIBC chequing account, the client code might look something like this:

          IBank bank
= newCibcBank(
); IBankAccountFactory factory = bank.GetAccountFactory(
); IBankAccount chequingAccount = factory.CreateChequingAccount(
);

To create a Royal Bank chequing account, the client code might look something like this:

          IBank bank
= newRoyalBank(
); IBankAccountFactory factory = bank.GetAccountFactory(
); IBankAccount chequingAccount = factory.CreateChequingAccount(
);

Head First Design Patterns (Head First) by Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra Read more about this title...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

The XP Values

• Communication: Most desirable is face to face communication where we can talk, respond, gesture and draw on a whiteboard. Talking = good, documents = bad!
• Simplicity: Focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.
• Feedback: Developers give and get feedback from pair programming, from automated tests, continuous integration. Customers are part of the team even sitting in the same space with the developers, and provide feedback through constant interaction with the team, and through acceptance tests. 
• Courage: They have courage to refactor their code, proceed with an overall master architecture.

The Principles of XP

• Rapid Feedback: Constantly sending and receiving feedback, and responding to it.
• Assuming Simplicity: Favor simplicity and attempt to create a simple solution before evolving to a complex one.
• Incremental Change: Improve the software through small, incremental changes.
• Embracing Change: Developers are able to adapt and accommodate change.
• Doing Quality Work: Insist that the software consistently exhibits the highest level of quality workmanship.

I'm still fascinated by the Agile XP methodology. So when I came across the overview of XP in the Appendix of...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

I had to read on. Here's what I learned:

Roles

• The XP customer role is responsible for writing stories, prioritizing stories, and writing and executing tests that demonstrate that stories were developed as expected.
• The XP programmer role encompasses a broad range of technical skills. XP projects tend not to draw distinctions between programmers, designers, DBA's and so on.
• XP teams benefit for the use of an XP coach and possibly a project manager. The coach is responsible for monitoring the team's use of the XP practices and gently nudging them back on track when they stray.

The 12 Practices

Small Releases

Project progress in a series of iterations, which are typically 1 to 3 weeks long. Features are fully delivered within a single iteration.

The Planning Game

• This is the name for release and iteration planning where developers and customers collaborate to make predictions about the future.
• Prior to planning, the customer has written user stories on note cards and developers have estimated the cost of magnitude of each story and have written the estimate on the story card.

Refactoring

• Refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior.
• XP advocates constant attention to refactoring. Whenever a programmer makes a change to code that should be refactored, she is required to refactor it.
• She's not encouraged to refactor it; she's required to refactor it.
• Instead of spending time upfront thinking through a system in advance of coding it, and therefore taking guesses at some aspects of its behavior, XP systems are refactored and kept in a state that perfectly meets known, implemented requirements.

Testing

• The developers write automated unit tests.
• The customers write acceptance tests.
• In test-driven development, tests are written before the code. Developers follow a short cycle of test-code-test-code... No operational code may be written except in response to a failing test.

Pair Programming

• Refers to 2 programmers sharing one computer and 2 brains to write code. One programmer types the code, the second is watching the code develop and thinking more broadly about the code.
• This leads to lower defect counts, less code is written to solve the same problem, problems being solved more quickly, more people understand each piece of code, an increase in developer satisfaction.
• It requires discipline to refactor every time you notice poorly structured code.

Sustainable Pace

• The believe is that an XP team moving at a consistent but brisk pace will achieve more over a period of time than will a team working at a pace they cannot sustain over a long period of time.
• It is up to the team to determine their sustained pace.
• A team will typically devote around 6 hours per day to pairing and spend the remainder of the day in other activities.
• An XP coach is responsible for monitoring the team for burnout.

Team Code Ownership

• It's common in non-XP teams for individuals to "own" portions of a systems code. This leads to comments like "We can't change the billing source code until Eli gets back from vacation."
• All code is owned by everyone.
• Pairs are expected to change code they didn't write.
• A strong suite of unit tests ensures that changes do not introduce unanticipated side effects.

Coding Standard

• XP teams collectively own their source code, so it's important to follow a coding standard.
• A small, close-knit team may be able to get by without a written, formalized coding standard.

Simple Design

• Pursue a goal of having the simplest possible design that delivers the features a customer needs.
• The operational code and the test code fully convey the programmers intent.
• There is no duplicate code.
• The system uses the least number of classes.
• The system uses the least number of methods.

Metaphor

• Quest for simple design by finding a metaphor that can be used for the whole system. The metaphor describes how they think about the system.
• E.g. "The system is like a chalkboard and various parts of the system can write on the chalkboard. When a user is done with the system she can either save the contents of the chalkboard or erase them."

Continuous Integration

• Code is integrated continuously.
• A developer completes a small change, he checks the change into source control, where the CI box initiates a full build. When the build is finished a full set of unit tests are run. If any tests fail, the developer is notified by email and told about the failure.
• Integration problems are fixed one at a time in extremely small batches as soon as they occur.

On-Site Customer

•  The customer is expected to sit with and be part of the development team. The customer writes the stories and the acceptance tests and is also available to answer questions as they arise.
• If the customer is not on site, delays will disrupt the predictable progress of the XP team.

Last night I finished reading...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

It was a nice quick and dirty read, to get my feet wet in the world of applying user stories. I really prefer working with user stories as opposed to full blown system requirements specifications. Although, a typical SRS is much thicker then a set of user stories, I think more information is delivered through user stories because it done so piece by piece. As you require the information, it's your responsibility to gather it.

I want to share some of my favorite quotes from the book.

"Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she's comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions. Once participants become comfortable that their ideas will simply be noted, not debated, at this point they will contribute more readily."

I have to admit that at my first story writing workshop I didn't say much. It was kind of a foreign concept to me and I worried about getting shot down by the other developers if I mentioned a story idea. I felt like there was a good chance that would occur because the rest of the team felt they had a similar vision of how the product would look and feel before and discussion had even begun. I later realized that they did indeed want to hear my story ideas, but it just took some time getting used to the culture of the team.

"When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users' minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user. In general, developers do not have marketing backgrounds that allow them to understand the relative value of features, they do not have the same amount of customer contact as salespeople, they are not domain experts, and so on."

I know as a developer that there are many times where I know how I would like a piece of software to work. Because it would work well for me, but ultimately that's not always going to work best for the end user. It's difficult to put yourselves in someone else's shoe to try to think like they would. It's much easier to just ask, instead of making a design decision, implementing it then later having them tell you that's not what they wanted.

"Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers."

Wow... I had no idea. Right now we're writing the user stories...

"In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you're not responsible for something you can't be blamed for it when it fails, yet there's usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases. They'll fall back on statements such as "It's not my problem that you can't complete everything by the deadline, figure out a way to do it."

This seems to happen more often then not. I think when someone because slightly hostile, it's usually because of their own insecurities. But reading the above statement just helped me to realize to think about what they're going through. Who's grilling them, and how can I help so that they're are happy with the software but it also makes them look good to their peers.

"The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change it's class." - Head First Design Pattern

Head First Design Patterns (Head First) by Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra Read more about this title...

Let's say I've got a point of sale terminal used for processing financial transactions. Let's say that at any given time the terminal can be in 1 of 6 states. Those states are:

• Idle State: During this state an idle message is displayed on the screen of the POS terminal.
• Card Swiped State: The terminal enters this state when a card is swiped.
• Amount Entered State: The terminal enters this state when the transaction amount is entered.
• PIN Entered State: The terminal enters this state when the customer enters their PIN.
• Processing Transaction State: The terminal enters this state when it connects to a financial processor to process the transaction.
• Transaction Approved State: The terminal enters this state when the transaction has been process and has been approved.
• Transaction Rejected State: The terminal enters this state when the transaction was processed but was rejected.

Let's pretend the following is the client code that will use the point of sale terminal to process transactions.

          IPosTerminal terminal
= newPosTerminal(
); terminal.SwipeCard( "6278080000008205" );
terminal.EnterAmount( 99.99 ); terminal.EnterPin( "8012" );
terminal.ProcessTransaction( ); terminal.PrintReceipt( );

When the PosTerminal is first constructed it is immediate put into an Idle State which displays an idle message to screen. The PosTerminal has a property of type IState that all the concrete state types implement.

As actions are performed against the PosTerminal, they are delegated to the current state.

          public
          void SwipeCard( string cardNumber
) { _currentState.SwipeCard( cardNumber ); } publicvoid EnterAmount( double amount
) { _currentState.EnterAmount( amount ); } publicvoid EnterPin( string pin
) { _currentState.EnterPin( pin ); } publicvoid AuthorizeTransaction(
) { _currentState.ProcessTransaction( ); } publicvoid PrintReceipt(
) { _currentState.PrintReceipt( ); } publicvoid ProcessTransaction(
) { _currentState.ProcessTransaction( ); }

publicvoid SwipeCard( string cardNumber
) { _terminal.Transaction = newPosTransaction(
); _terminal.Transaction.Date = DateTime.Now;
_terminal.Transaction.CardNumber = cardNumber; _terminal.CurrentState = newCardSwipedState(
_terminal ); } publicvoid EnterAmount( double amount
) { Console.Out.WriteLine( "Please
swipe a card first." ); } 

...

With the state pattern you can re-order states and alter the implementation of a state with out having to change the subject of the state.

"The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces." - Head First Design Patterns

Head First Design Patterns (Head First) by Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra Read more about this title...

If you're trying to build a presentation layer that is platform agnostic, you might turn to adapters for simple UI controls. For example in ASP.NET there is a drop down list control, and in Win Forms there is the Combo Box control.

A quick an easy adapter to the two controls might look like:

          public
          interface
          IDropDownListAdapter { void BindTo( IEnumerable< IDropDownListItem >
pairs ); IDropDownListItem SelectedItem
{ get; } }

Each drop down list item might look like:

          public
          interface
          IDropDownListItem { string Text
{ get; } string Value
{ get; } }

A concrete implementation for a Win Forms application might look like:

          public
          class
          DesktopDropDownList : IDropDownListAdapter { public DesktopDropDownList( ComboBox dropDown
) { _dropDown = dropDown; _pairs = newDictionary< string, IDropDownListItem >(
); } publicvoid BindTo( IEnumerable< IDropDownListItem >
pairs ) { if ( pairs != null )
{ _pairs = newDictionary< string, IDropDownListItem >(
); foreach ( IDropDownListItem pair in pairs
) { _dropDown.Items.Add( pair.Text ); _pairs.Add( pair.Text, pair ); } _dropDown.SelectedIndex
= 0; } } publicIDropDownListItem SelectedItem
{ get { return !string.IsNullOrEmpty(
_dropDown.Text ) ? _pairs[ _dropDown.Text ] : null;
} } privateComboBox _dropDown; privateIDictionary< string, IDropDownListItem >
_pairs; }

A concrete implementation for a ASP.NET application might look like:

          public
          class
          WebDropDownList : IDropDownListAdapter { public WebDropDownList( DropDownList dropDown
) { _dropDown = dropDown; } publicvoid BindTo( IEnumerable< IDropDownListItem >
pairs ) { if ( pairs != null )
{ foreach ( IDropDownListItem pair in pairs
) { _dropDown.Items.Add( newListItem(
pair.Text, pair.Value ) ); } } } publicIDropDownListItem SelectedItem
{ get { returnnewDropDownListItem(
_dropDown.SelectedItem.Text, _dropDown.SelectedItem.Value ); } } privateDropDownList _dropDown;
}

And voila... we can write a presentation layer that binds data to an IDropDownListAdapter, without having to be specific to WinForms, ASP.NET, WPF, Silverlight etc.

          public Presenter( IView view
) { _view = view; } publicvoid Initialize(
) { IList< IDropDownListItem >
items = newList< IDropDownListItem >(
); items.Add( newDropDownListItem( "Yes", "1" )
); items.Add( newDropDownListItem( "No", "2" )
); _view.AreYouHappy.BindTo( items ); }

"Every craftsman starts his or her journey with a basic set of good-quality tools. A woodworker might need rules, gauges, a couple of saws, some good planes, fine chisels, drills and braces, mallets, and clamps. These tools will be lovingly chosen, will be built to last, will perform specific jobs with little overlap with other tools, and, perhaps most importantly, will feel right in the budding woodworker's hands."

I read the above paragraph from the pragmatic programmer, and thought it made a lot of sense. My appreciation for tools continues to grow, and grow. And as I learn to use different tools, I find different sorts of productivity gains.

Some of the tools I use:

• ReSharper
• MbUnit (recently switched from NUnit)
• NAnt
• Reflector
• Snippet Compiler
• Doxygen
• Launchy
• TrueCrypt
• Hamachi
• Notepad++
• FxCop

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas Read more about this title...

I think Martin Fowlers description of optimistic and pessimistic locking is excellent. So excellent that I had to share...

"Let's suppose that Martin and David both want to edit the Customer file at the same time. With optimistic locking both of them can make a copy of the file and edit it freely. If David is the first to finish, he can check in his work without trouble. The concurrency control kicks in when Martin tries to commit his changes. At this point the source code control system detects a conflict between Martin's changes and David's changes. Martin's commit is rejected and it's up to him to figure out how to deal with the situation. With pessimistic locking whoever checks out the file first prevents anyone else from editing it. So if Martin is first to check out, David can't work with the file until Martin is finished with it and commits his changes." - Martin Fowler : PoEAA

SVN of course uses optimistic locking and Microsoft Visual Source Safe uses pessimistic locking. I've become a huge fan of SVN recently, and since we started using it here at work, I feel like I've become more productive. Gone are the days when I would hear "Can you check in the project, I need to add a file.", "Where's <enter name>? He's not in today? But he's got a file checked out that I need."

Patterns of Enterprise Application Architecture by Martin Fowler Read more about this title...

"A process is a, usually heavyweight, execution context that provides a lot of isolation for the internal data it works on. A thread is a lighter-weight active agent that's set up so that multiple threads can operate in a single process. " - Martin Fowler : PoEAA

Patterns of Enterprise Application Architecture by Martin Fowler Read more about this title...

In geometry, when two lines are orthogonal if they meet at right angles, such as the axes on a Cartesian plain. Move along one of the axes, and your position projected onto the other doesn't change.

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others.

In a well-designed system, the database code will be orthogonal to the user interface; you can change the interface without affecting the database, and swap databases without changing the interface.

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas Read more about this title...