A tip for code generation.  When reading through various patterns based development books, working on my current gig, and just trying to make code more readable without adding too much headache, I’ve stumbled on a few tips.

1. Name those entities!  Instead of “Address” or “User” you would then have AddressEntity or UserEntity.  This is very helpful when you are using domain objects at a higher layer than your entity objects.  It is also helpful in the case of a WCF Facade layer that steps back through via reflection to find what entities it needs to get for data contract purposes!- In the code generation properties there is a IncludeUnitTests property.  As in regular code as in generated code, if you can have tests, have them!  There is a choice between NUnit and VSTS tests even, so it isn’t like there are test framework conflicts!

Well, that’s it for today.  Just a few ideas to keep locked away for future use.  For now, published via car #402 on Sounder Train #1501, I’m diving back into my code.

As anyone in the software industry knows, especially those that use the latest and greatest, having an up to date and powerful toolkit is vital for the job.  Without a good personal toolkit a developer can be rendered almost useless or at least lost a huge amount of value.  In my efforts to stay above par with my toolkit I made another surfing expedition out on the ole’ world wide web for latest tools.

One of the framework type tools that I wanted to check up on, especially with all the patterns based development that I’ve been working on lately, was the WCSF, or to “de-acrynomize” it, the Web Client Software Factory.  For more information on the WCSF check out the Wiki on Composite Clients.  WCSF helps out when the various layers are broken out between Model-View-Controller, UI and Business Layer, or other such pattern paradigms.  It provides a framework in which to build up architecture.

The second major item to pick up, even if you intend to only use one or two elements at first, is the Enterprise Library.  Currently the version out is the Enterprise Library May 2007 version 3.1.  Awesome parts of this library that I’ve had the fortune of using recently include policy injection, if you haven’t heard or seen this in action, you owe it to yourself to check it out!  Policy Injection ROCKS!

Two other tools, which could be considered a tool, are the Guidance Automation Toolkit and the Guidance Automation Extensions.  These installs set the development environment up with some pretty snazzy help documents and predefined templates for use with the WCSF or SCSF (SCSF == Smart Client Software Factory).  These pieces, along with the WCSF, will probably start aging rapidly when Avalon and the respective tools start hitting prime time.  But for now, prime time is WCSF, SCSF, and the Guidance tools.

The biggest kicker of recent time are the WF (Workflow Foundation), WCF (Windows Communication Foundation), and WPF Extensions for Visual Studio 2005.  For now those of us that are still using Visual Studio 2005 (Which I would assume is about 99% of .NET 2.0 or 3.0 technology development) definitely need these extensions for 3.0 work.  Trust me on this, 3.0 is full of great additions, if you aren’t, start using it.

To summarize my latest toolkit:  (Do a search for any of these acronyms on MSDN and you’ll have the download)

• WCSF – Web Client Software Factory- Enterprise Library May 2007 (3.1)- Guidance Automation Toolkit and Extensions (GAT & GAX)- .NET 3.0 Extensions (WF – WCF/WPF) for Visual Studio 2005

So a lot of things are going on in my life at the moment, causing any travel that I need to take outside of the north western US to be very difficult.  One event coming up that is driving me crazy, because I’d really like to go, is the QCon Event down in San Francisco.  They have Martin Fowler, Kent Beck, Dan Pritchett (eBay Architect), Eric Meijer (Creater, LINQ), P. Rosedale (Creator of Second Life), and many others that are going to speak.  The problem is, it is during the work week on the days of the 7th, 8th, and 9th.

I’m contemplating footing my own tab, asking for days off, and going anyway.

Some of the tracks that I REALLY want to jump into are “Challenges in Agile (and how to overcome them)“, “Architecture Quality“, “Architectures you’ve always wondered about (Linked-in, Yahoo!, eBay, Second Life, and others)“, and of course “Bleeding Edge .NET“.  I’m not even sure that the schedule would allow, but I REALLY want to catch every session.  As soon as I get the battle figured out, if I get to go, I’ll definitely have an entry or fifteen zillion to blog about from the conference.  If anyone else out there is going, shoot me an e-mail and maybe we could meet up!

I had a kind of epiphany about “figuring out” a solution to a problem versus “making” a solution to a problem.  Let’s break out the two a little bit just so I’m not rambling to the world without some context.

What I stumbled into thought about is the “figuring out” a solution is done when there is not solution that is currently known.  Figuring out the problem, knowing it intimately, then through a bit of analysis and possibly discussion a solution is found to a problem.

With the concept of “making” I had the idea that a solution exists, someone is assigned the problem, and then the solution is then applied to the problem.

These two ideals kind of struck me as a division of labor compared to a scientific labor.  One is a matter of planning and training, the other is a matter of empirical knowledge and application of scientific principal to resolve a problem.  Of course, in software development often the scientific principal is nothing more than a barrage of trial and error processes strung together.

One of the things that I wanted to do as soon as I was struck by my epiphany was segment people into the respective two concepts.  After some more thought though, I realized, that no one specifically fits into one or the other type of concept.  Someone might fit more into a “figuring out” paradigm more than a “making” solution thought process, but a person might have to wear both hats, or change back and forth during the course of a career.

There is however the application of these conceptual task delineations that could be made of particular tasks within a problem.  Let’s compare a game production company versus building an enterprise application.

To provide example take a look at a game production company.  There are many problems there that haven’t been resolved.  There are crude inroads to certain tasks, but for the most part the game development process is done via the “figuring out” solution method.

On the other side of this scenario is the enterprise application expertise.  Most of the problems that need resolved in enterprise development need nothing more than a “making” the solution expert.  The enterprise environment has been thoroughly thought about in many aspects and entire suites of tools and software are available.  There is of course the “business problem” that could require a bit of “figuring out” solution approaches, but the core of enterprise development is practically a tried and true art now.

I’m done with my little epiphany now and am heading to a day full of intense unit, integration, and general test coding.  Cheers!

The Microsoft Windows SDK Blog is an awesome way to keep up with the SDK.  If you haven’t downloaded the SDK get over there post haste and get r’ done!

The latest SDK for Vista (VS 05) is a must have.  With the WCF, WF, and other tools and their respective “designers” and such it’s priceless.  So if you haven’t got the idea, GO CHECK IT OUT!

In addition to that make sure to keep reading the .NET 3.0 Framework netfx3 site.

  Have a rolling good Sunday!