Depending on who you ask you will likely get one of two answers.  If you are talking with a data guy, he will say to start with the database.  If you are dealing with a visual guy, he will say to start with the UI.  Historically, I did a conglomeration of those two ideas, creating both the UI and the database at the same time, letting the two drive each other.  But I'm weird, I'm a visual/data guy.

Lately though, I've started to thing about a third approach.  Starting in the middle.  No UI, no database, just the data classes.  This approach has been spurred on buy a couple of things.  Namely, test driven development (TDD), design patterns, and domain driven design.

TDD really is the glue that allows all of this to happen.  I can start in the middle because I can run the code in the middle any time I want.  I just have to write a test.  No having to wade through multiple layers of UI to test out some small chunk ok UI is a great productivity gain for me.

Next is design patterns.  This is what gives you a reference for how to approach your code.  That said, this isn't about making everything absolutely perfect from the get go, but it is nice to know where you are going to made your comprises early on.

But all of that does not explain where I begin.  That is where Domain Driven Design (DDD) kicks in.  For those not familiar with the concept, you can read up on wikipedia, buy The Book, or buy one of the various other references.   One of the concepts in DDD (I'm still reading the book) is setting up something called a ubiquitous language.

The ubiquitous language is actually trying to solve a problem that I have seen happen on many projects I've been apart of (but not always my fault).  At some point there is a linguistic difference between the nouns that the customer uses and the nouns that the programmers use.  By focusing on the language first, you are attempting to head that off at the pass.

These nouns consist of your domain classes and your tables and columns, they move everywhere...but not always consistently.  Consistency does matter.  Inconsistency is what leads to rather confusing conversations with people and everyone scratching their heads about "what just happened".  So, this is the middle that I start with.

But before you start...

One of the other guys in the group was an actual data guy.  The systems he has written worked with more data than yours does.  Trust me on that.  Historically, his biggest consideration was data input speed.  I don't think I would start in the middle if that was my biggest concern.  In that case you do start with the database, you tune for speed.  You also don't use as many domain classes, and you tend to throw away your ORM solution and just hit the database layer directly via Ado.Net.

But lets face it, that doesn't happen very often.  Most business applications aren't going to touch what the architecture can take.  It is amazing how many horribly written applications with very inefficient code run just fine.  Most of my speed issues could be solved by indexing tables and changing generic lists to generic dictionaries (more on that later).  Architect your applications for how they are going to be used.  Most of my web applications have a max usage of 100 simultaneous users.  If the data access is slightly slower I'll take that hit for programmer efficiency.  If you are designing Amazon.com, you code for through-put.

OK, someone is going to disagree with this...I can already feel it.  Please take a moment to register your displeasure in the comments.  I would love to hear it.

I think you have to write DTO's for any sort of long term Enterprise 'system of systems' solution. I fought this for some time, but since moving to an Assembler/DTO I much enjoy the freedom of being able to easily tweak my DTO "snapshot" of the aggregate root I am working with. Maintaining them is very little overhead.

I tend to think of the DTO as a message, a value object. This is necessary because once an entity leaves the boundary it can no longer function within its original meaning. Its methods may be intended to only run within a given context, which is not the same once on another tier. (Things like lazy loading are a good example) Once the DTO/Message arrives to the caller, it very well may (and probably should) be translated/assembled into another model which can represent its new semantics.

Some other advantages of DTO w/ Assembler or Builder:
-Can explicitly control the depth of the graph/tree you are serializing.
-Can flatten out the data where needed
-Can return significantly less data (maybe you only need 3 fields instead of 15)
-Not tightly coupled between remote boundaries (this could be a mess when working with a large team)
-Interoperable

I wrote a post a while back showing a way to 'templatize' the process. My current implementations are much different with LINQ now, but maybe it could stimulate some ideas for whomever.

The next thing I would like to do is remove the assembler altogether. By flagging fields with attributes or using config to specify a mapping, I could then feed dynamic methods and run a translation/builder strategy.

I know there are concerns about writing and maintaining assembler and DTO, but to me this is the least of the worry, a more challenging scenario would be the UnitOfWork (How to you intended to track remote state, concurrency etc) How about versioning? performance? scala.. well ilities in general?

These kinds of problems lead one from Request/Response, Patterns of Enterprise Architecture & DDD to a Pub/Sub Message Bus - Enterprise Integration Patterns & DDDD.

And to think all you want to do is send some frickin entities to a remote client  :)

   1: public class CustomerBuilder

   2: {

   3:     public String _firstName = "Homer";

   4:     public String _lastName = "Simpson";

   5:         

   6:     public CustomerBuilder WithFirstName(String firstName)

   7:     {

   8:         _firstName = firstName;

   9:         return this;    

  10:     }

  11:  

  12:     public CustomerBuilder WithLastName(String lastName)

  13:     {

  14:         _lastName = lastName;

  15:         return this;

  16:     }

  17:         

  18:     public Customer Build()

  19:     {

  20:         return new Customer(_firstName, _lastName);    

  21:     }

  22: }

This fluent builder class can then be used this way:

   1: Customer customer = new CustomerBuilder()

   2:     .WithFirstName("Homer")

   3:     .WithLastName("Simpson")

   4:     .Build();

A while ago, Greg Young started a series of blog posts on DDDD (Distributed Domain-Driven Design), which I can highly recommend. Make sure to catch up now you still can because I think that he has a lot of stuff coming up, which I'm really looking forward to.

Anyhow, Greg had a couple of posts on fluent builders, which you can read here, here and here. I noticed an interesting approach in the way that the target object is built. Here is an example of this approach:

   1: public class CustomerBuilder

   2: {

   3:     public String _firstName = "Homer";

   4:     public String _lastName = "Simpson";

   5:         

   6:     public CustomerBuilder WithFirstName(String firstName)

   7:     {

   8:         _firstName = firstName;

   9:         return this;    

  10:     }

  11:  

  12:     public CustomerBuilder WithLastName(String lastName)

  13:     {

  14:         _lastName = lastName;

  15:         return this;

  16:     }

  17:         

  18:     public Customer Build()

  19:     {

  20:         return new Customer(_firstName, _lastName);    

  21:     }

  22:  

  23:     public static implicit operator Customer(

  24:         CustomerBuilder builder) 

  25:     {  

  26:         return builder.Build()    

  27:     } 

  28: }

which results in the following usage:

   1: Customer customer = new CustomerBuilder()

   2:     .WithFirstName("Homer")

   3:     .WithLastName("Simpson");

So, here's a list of the 23 Gang of Four patterns, along with when I'd use the name of the pattern in the implementation.  Unless I didn't want to, and then I wouldn't.  Feel free to agree with this list, unless you don't care to.

Creational Patterns

Abstract Factory - After consideration, I have to say that I call my factories Factory, unless they're Repositories, Data Access Layers, DAOs, or something else.  But most of the time, Factory.  Because this would just be wrong:

public class FooCreatorMakerThingy { ... }

Builder - Hmm, another noun. Guess I'd use this one too, for the same reason as Abstract Factory. Most of the time. 

Factory Method - I probably would not call my Factory Methods "GetFooFactoryMethod()" because that just looks weird.   Maybe if we verbify the noun:

public Foo FactorialMethodizeFoo() {...}

Nope, that's still dumb.

Prototype - "Specify the kinds of objects to create using a prototypical instance..." So we don't care that the class is a "Prototype," but we do care about the "kind of object" part.  So don't name your prototypical classes "FooPrototype."  (Unless you just want to.)

Singleton - Somebody have a case where it makes sense to name your Singleton "Singleton"?  I can't come up with one.  Anyway, you shouldn't be using singletons anymore anyway.  :)

Structural Patterns

Adapter - Adapters are pretty much called Adapters.  Except when they're called Wrappers.  So you can use this name too.

Bridge - I wouldn't label a participant in a bridge pattern "FooBridge," unless I was trying to impress on an interview test or something.  And even then, that's a bad idea.  "Ohh, look, I know a complicated design pattern!  Lookitme!"  So don't call your bridges Bridges. 

Composite - "One of the goals of the Composite  pattern is to make clients unaware of the specific Leaf or Composite classes they're using."  So you don't want to point out that Composites are in play, that breaks the suspension of disbelief for your audience.  Or something.  Anyway Composites get used all over the place, if we had to label them all then it'd be FooComposite, BarComposite, TreeComposite, EverythingComposite, and what's the fun in that.

Decorator - I think in general people don't label their Decorators Decorators.  I'm sure there's a counter-example to this, but all of the Stream- and Xml-handling classes I can think of don't point out that they are Decorators.  You'd probably want to stick to more descriptive names, like ASCIIStreamReader instead of cluttering things up with ASCIIStreamDecorator.  We're not decorating the stream (in a literal sense), we're reading it. 

Façade - Don't call your Façade "FooFaçade," that's just silly.  Besides, its too much work to type that cedille into the editor if you're using an ignorant American keyboard.

Flyweight - This is another pattern where we're going to disguise what's going on inside, in order to simplify the client's usage and make better use of resources.  No reason to flaunt to the client that we're low on resources, because that's a personal and private matter - times are tough all over, and there's no shame in struggling a little bit, and hey who could have predicted that the sub-prime loan market was going to ... anyway, back to patterns.   Don't call your Flyweights Flyweights, unless what you're modeling is actually a Flyweight, and then thats OK.

Proxy - This one is standard terminology.  So Proxy's ok.

Behavioral Patterns (or "MAN this book has a lot of pages in it..")

Chain of Responsibility - Don't even think of naming a class ChainOfResponsibility.  Even with ReSharper, who'd want to have to type that?

Command - Another convenient noun.  Ok, you can create Commands. 

Interpreter - This is another pattern that doesn't have one identifying class that you could label "The Interpreter."  But you might create a Façade, and call that class Interpreter.  I'm not sure if naming one pattern after another is OK or not.  Makes my head hurt. 

Iterator - Another convenient noun.  Iterate away!  Not that you'll have to worry too much about naming classes with this pattern if you use C#, Java, C++ or pretty much any other modern language, since this pattern is built-in.

Mediator - This pattern promotes loose coupling, most of the time I'd call what it does a "Controller," or what's being Mediated is more on a service level, so perhaps the word "Service" would end up in the name.  Can't say I've ever called a class specifically "FooMediator", but I suppose I don't have a problem with it if you want to do that.

Memento - This pattern captures and externalizes an object's state.  So I think I'd call something like it "State" before "Memento," since it's fewer letters to type.  Besides, I had to see that movie twice before I really appreciated it. 

Ok, that was just lame, sorry.

Observer - Oh, you mean like an Event?  Or more like a delegate?  :)

State - I'd call my implementation of this pattern "Memento," just to confuse you.  That's just how I roll.

Strategy - This is another pattern that it seems like we use all the time, without having to give it a fancy Ivory Tower name.  As someone pointed out (sorry I lost the reference to who said that) Microsoft calls all their Strategy implementations Providers now anyway.  Rather than label something a "Strategy" I'd probably just say what the thing does: "CryptographicProvider."

Template Method - Yet another pattern where there's no obvious place to hang the name off of, so don't try to force it in there and impress your coworkers with how smart you are.  We know, you're a Design Pattern God, no need to brag about it.

Visitor - Hmm, not sure where I stand on this one.  I have used this pattern where I've named a visitor "SqlGeneratingVisitor."  But maybe that was a mistake?  So how about we just declare this one "Free Parking," and you can do what you want.

So, there you go.  A bunch of design patterns, summarized into one neat page.  Now you're ready to ace that interview! 

disclaimer: I make no guarantees that any or all of the information will not harm you in a technical interview, and if repeating this to an interview board gets your removed from the building by security, its not my fault.  This information comes without warantees or conditions of any kind, and you probably shouldn't have bothered reading it..

Good thing MS has exposed a set of interfaces and abstract classes in System.Web.UI for us to implement our own IHierarchicalDataSource and HierarchicalDataSourceView and IHierarchicalEnumerable and then IHierarchyData... geesh.

Data? So let's see here, in order to bind our model to the tree control it needs to implement an interface in System.Web.UI? Well that's just not going to happen, so its time for some Elegant Code.

Story:

Dude, as a software developer, needs to create a custom implementation of IHierarchicalDataSource, and the rest of its parts, so that he can bind a list of objects to a tree control in asp.net

• Use existing model to bind to tree control
• Must be able to reuse data source for future models
• Model must not contain a reference to System.Web.UI

In order to setup our model to address the acceptance criteria we are going to use an interface with a self-referencing generic declaration, where the type will specify itself as the concrete type. This will let us create a nice generic hierarchical model to pass into our datasource without resorting to any sort of base class.

namespace POC.Common
{
    public interface IModelWithHierarchy<T>
    {
        string Name { get; set; }
        T Parent { get; set; }
        List<T> Children { get; set; }
    }
}

The UI part of criteria is now a bit more tricky because the HierarchicalDataSourceView expects a IHierarchicalEnumerable datasource which contains IHierarchyData. Said IHierarchyData != IModelWithHierarchy<T>.  Luckily someone else has already figured this one out for us. We need an adapter.

To instantiate our HierarchyData adapter objects we will use an extension method and linq 'Select' to convert our datasource IEnumerable<T> of IModelWithHierarchy<T> 's to an IHierarchicalEnumerable of IHierarchyData.

namespace POC.Web.HierarchyExtensions
{
    public static class HierarchyConverter
    {
        public static HierarchicalModelList
            ToHierarchicalModelList<T>(this IEnumerable<T> modelWithHierarchy)
            where T : IModelWithHierarchy<T>
        {
            return new HierarchicalModelList(
                modelWithHierarchy.Select(m => new HierarchyData<T>(m) as IHierarchyData));
        }
    }
}

I am not going to bore you with the implementation details of the HierarachyData<T> adapter and the .net abstractions, but have dropped the source code here if your interested. The end result:

TreeView1.DataSource = new HierarchicalModelDataSource<Category> { DataSource = Categories };
TreeView1.DataBind();
TreeView1.CollapseAll();

Story complete! 

So let me state for the record: today's elegant code is tomorrow's drivel.  Don't feel bad, many writers have the same problems.  What was super amazing back in the day is now rubbish or near unreadable.  I am thinking of the Victorian writing that Hemingway usurped, and now Hemingway himself is almost unreadable (to me anyway).  Tastes change with the times.  That is a simple fact.

So what can you do about this?  As I say that old writing sucks to read (read Washington Irvine lately?), great works of literature still abound (for instance, Hemingway is still a great writer -- even if I prefer Tolkien) .  So take some notes from them, and from other crafts in looking for the answer.  If you want a cliff notes version of what this is going to tell you, it is this: you must always push yourself to get better.

1. Find a good teacher.  Nothing is better than sitting at the feet of a master who can nudge you along in the right direction.  While early mistakes can often be corrected easily with a little bit of guidance, after they have had some time to fester all bets are off.  I believe a fare number of "Anit-patterns" were created by self taught developers (find SQL Ejaculation on this site). 
2. Read.   Good writer are first good readers.  Start with Code Complete, move into a good Patterns book, get MSDN Magazine, find some bloggers your like, but keep moving.  You will NEVER be done reading.  I imagine that even Martin Fowler has a "to read" booklist a mile long.
3. Read code.   There are a plethora of open source project just waiting to be read -- do so.  This is the single best way to expand your coding repertoire, find things your language can do that you didn't even know about..   Scott Hanselman has recently popularized this idea, and I thank him for it.
4. Practice.  This means writing small applications at home.  You get an idea that you want to try out -- do it.  I don't mean you have to write finished applications, just have some exploring time.  I remember talking with an 80 year old master woodworker (he lives down the street from me), who was telling me how many time he would practice making dovetail joints before he felt competent.  It was years worth.
5. Pay Attention.  Being good at anything really amounts to that.  And don't just pay attention when reading, writing, or talking about code.  Inspiration come from everywhere, any good artist will tell you that.  Pay attention when you cook, when you work on the car, when you are wood working, playing an instrument, whatever it is that you do.  This will help you in the end, event if it is just learning the amount of dedication it really takes to become good at something.
6. Beware of preferences.  Any time I hear someone start a statement with "I prefer code to ..." you know things are going downhill.  If you find someone who cares more about how your code is formatted then how it is written you have found yourself in a mess.  More importantly, beware of them in yourself.   Having code style standard is important, but it isn't worth loosing sleep over.  This also pertains to inheritance, patterns, use of particular classes (e.g. always using the generic list class in C# when a Dictionary would be better). 
7. No Sacred Cows. Believe no single source of information.  This means not thinking that Microsoft, Sun, IBM, Richard Stallman, or anyone else will have all of the correct answers.  Apply the scientific method and do some research, experiment, and question the authority.   There should be no sacred cows in programming.
8. Talk with others.  Join a user group, show up every now and then, heckle the presenter, and -maybe- speak.  You want a broad range of people who you can talk to and bounce ideas off of.  This will help you from becoming that crazy guy in the corner who vehemently states that all your code should be in one file.  Having a mentor (mentioned earlier) is great, but having people around to push you from multiple directions is also good.
9. Learn languages.  This gets back to the "read code" idea. Make that multiple types of languages as well.  If you know C# or Java and SQL, learn Python or Ruby, get really good at JavaScript.  If you want something really out there, learn MDX.  This is also a repertoire thing.  Seeing how other languages work will make you rethink your ideas about what your current code, in whatever languages you are working in, should look like.
10. Keep Thinking!!!  That is possibly the most important point.  Keep thinking.  Don't just evaluate something once and never return, go back and reevaluate. Did the technique work?  How could it have been better?   The idea is continual improvement.
11. Switch jobs every now and then.  When I announced I was leaving my first programming job out of college, the VP of R&D had me sit down with him and talk.  He wasn't trying to keep me (he knew I was moving to be closer to family), he wanted to give me some advice.  He told me to change jobs every three years.  After you have been with a place for three years you have probably learned everything you are going to learn and it time to move on.  This doesn't mean changing companies either.  I've been with the same company now for four years, but I've had three different jobs.  If you have been writing commercial applications, become a consultant - or vise-versa, become a test engineer, expand your boundaries.  Again, this is about pushing yourself to be better.
12. Have a Hobby. But don't ask about me, I have too many.   Creating software is about creating things.  So I suggest picking a hobby that involves creating something.  Popular hobbies amongst programmers I know include: cooking, music, woodworking, beer making, and BBQ (which is different than cooking).  But don't discount sports (golf is always popular), computer games, and board games.  Anything that promotes the development of skill levels can't be a bad thing.

And I'm stopping there.  This is my beginner's guide to how to become the writer elegant code.  If you have others you think I missed, add them too the comments.

I am sure everyone will be blogging about all the great sessions they attended at code camp. I enjoyed all of the presentations I attended, and I am excited to explore some new material.

I want to share a few thoughts on my presentation dealing with Model-View-Presenter in ASP.NET after listening to Scott Hanselman's session on the ASP.NET MVC Project. I may have the percentage incorrect, but Scott mentioned something like it is predicted that only 10% of the ASP.NET community currently using Web Forms will adopt and use the MVC framework. The MVC framework is an addition to ASP.NET, it is not a replacement. What this means is that Model-View-Presenter will still be a viable pattern to implement with your ASP.NET applications, and it is not going away. ASP.NET Web Forms will not be going away either.

Use MVP to get your third party controls under test. Use MVP to provide that separation of concerns in your legacy applications. Use it entirely or in conjunction with the MVC framework. It is all about testability. Glenn Block presented on the Web Client Software Factory, and what pattern does this implement? Model-View-Presenter.

I am providing my presentation and source code (3.67 MB) from my talk on MVP. It will be available via the Boise Code Camp site as well.

Again, thank the many individuals and their families who sacrificed their time to bring to the local community this years code camp.

Around the office's water cooler on Monday, I will be able to say, "and this one time, at code camp..."

So, here's a list of the 23 Gang of Four patterns, along with when I'd use the name of the pattern in the implementation.  Unless I didn't want to, and then I wouldn't.  Feel free to agree with this list, unless you don't care to.

Creational Patterns

Abstract Factory - After consideration, I have to say that I call my factories Factory, unless they're Repositories, Data Access Layers, DAOs, or something else.  But most of the time, Factory.  Because this would just be wrong:

public class FooCreatorMakerThingy { ... }

Builder - Hmm, another noun. Guess I'd use this one too, for the same reason as Abstract Factory. Most of the time. 

Factory Method - I probably would not call my Factory Methods "GetFooFactoryMethod()" because that just looks weird.   Maybe if we verbify the noun:

public Foo FactorialMethodizeFoo() {...}

Nope, that's still dumb.

Prototype - "Specify the kinds of objects to create using a prototypical instance..." So we don't care that the class is a "Prototype," but we do care about the "kind of object" part.  So don't name your prototypical classes "FooPrototype."  (Unless you just want to.)

Singleton - Somebody have a case where it makes sense to name your Singleton "Singleton"?  I can't come up with one.  Anyway, you shouldn't be using singletons anymore anyway.  :)

Structural Patterns

Adapter - Adapters are pretty much called Adapters.  Except when they're called Wrappers.  So you can use this name too.

Bridge - I wouldn't label a participant in a bridge pattern "FooBridge," unless I was trying to impress on an interview test or something.  And even then, that's a bad idea.  "Ohh, look, I know a complicated design pattern!  Lookitme!"  So don't call your bridges Bridges. 

Composite - "One of the goals of the Composite  pattern is to make clients unaware of the specific Leaf or Composite classes they're using."  So you don't want to point out that Composites are in play, that breaks the suspension of disbelief for your audience.  Or something.  Anyway Composites get used all over the place, if we had to label them all then it'd be FooComposite, BarComposite, TreeComposite, EverythingComposite, and what's the fun in that.

Decorator - I think in general people don't label their Decorators Decorators.  I'm sure there's a counter-example to this, but all of the Stream- and Xml-handling classes I can think of don't point out that they are Decorators.  You'd probably want to stick to more descriptive names, like ASCIIStreamReader instead of cluttering things up with ASCIIStreamDecorator.  We're not decorating the stream (in a literal sense), we're reading it. 

Façade - Don't call your Façade "FooFaçade," that's just silly.  Besides, its too much work to type that cedille into the editor if you're using an ignorant American keyboard.

Flyweight - This is another pattern where we're going to disguise what's going on inside, in order to simplify the client's usage and make better use of resources.  No reason to flaunt to the client that we're low on resources, because that's a personal and private matter - times are tough all over, and there's no shame in struggling a little bit, and hey who could have predicted that the sub-prime loan market was going to ... anyway, back to patterns.   Don't call your Flyweights Flyweights, unless what you're modeling is actually a Flyweight, and then thats OK.

Proxy - This one is standard terminology.  So Proxy's ok.

Behavioral Patterns (or "MAN this book has a lot of pages in it..")

Chain of Responsibility - Don't even think of naming a class ChainOfResponsibility.  Even with ReSharper, who'd want to have to type that?

Command - Another convenient noun.  Ok, you can create Commands. 

Interpreter - This is another pattern that doesn't have one identifying class that you could label "The Interpreter."  But you might create a Façade, and call that class Interpreter.  I'm not sure if naming one pattern after another is OK or not.  Makes my head hurt. 

Iterator - Another convenient noun.  Iterate away!  Not that you'll have to worry too much about naming classes with this pattern if you use C#, Java, C++ or pretty much any other modern language, since this pattern is built-in.

Mediator - This pattern promotes loose coupling, most of the time I'd call what it does a "Controller," or what's being Mediated is more on a service level, so perhaps the word "Service" would end up in the name.  Can't say I've ever called a class specifically "FooMediator", but I suppose I don't have a problem with it if you want to do that.

Memento - This pattern captures and externalizes an object's state.  So I think I'd call something like it "State" before "Memento," since it's fewer letters to type.  Besides, I had to see that movie twice before I really appreciated it. 

Ok, that was just lame, sorry.

Observer - Oh, you mean like an Event?  Or more like a delegate?  :)

State - I'd call my implementation of this pattern "Memento," just to confuse you.  That's just how I roll.

Strategy - This is another pattern that it seems like we use all the time, without having to give it a fancy Ivory Tower name.  As someone pointed out (sorry I lost the reference to who said that) Microsoft calls all their Strategy implementations Providers now anyway.  Rather than label something a "Strategy" I'd probably just say what the thing does: "CryptographicProvider."

Template Method - Yet another pattern where there's no obvious place to hang the name off of, so don't try to force it in there and impress your coworkers with how smart you are.  We know, you're a Design Pattern God, no need to brag about it.

Visitor - Hmm, not sure where I stand on this one.  I have used this pattern where I've named a visitor "SqlGeneratingVisitor."  But maybe that was a mistake?  So how about we just declare this one "Free Parking," and you can do what you want.

So, there you go.  A bunch of design patterns, summarized into one neat page.  Now you're ready to ace that interview! 

disclaimer: I make no guarantees that any or all of the information will not harm you in a technical interview, and if repeating this to an interview board gets your removed from the building by security, its not my fault.  This information comes without warantees or conditions of any kind, and you probably shouldn't have bothered reading it..