Rockford Lhotka

 Monday, November 1, 2010

Halloween is over, so it is time to quit being scared and get back to reality.

This is, perhaps, easier for me, because my wife and I attended the Rally to Restore Sanity and/or Fear over the weekend. There’s nothing like being surrounded by 200,000+ sane people on a beautiful afternoon in Washington DC to refresh your spirit and appreciation for the true strength of America (and I think humanity in general).

Of course while we were enjoying great music, comedy and an inspirational speech by Jon Stewart, the Microsoft developer world was turning itself inside out with the hyperbole generated by last week’s PDC conference and some less than thoroughly explained remarks made by Bob Muglia in an interview.

My reaction, perhaps tempered by hours of restoring sanity, was relatively simple:

  1. Microsoft (and BobMu) clearly didn’t intend to gut their entire client-side development community
  2. Therefore this is just a (perhaps big) PR mistake, nothing more
  3. Therefore it is best to just wait for Microsoft to correct the mistake with clarification

I feel justified in that reaction, since we now have clarification from BobMu and SteveB:

Other Microsoft Silverlight bloggers, such as Tim Heuer, are starting to blog as well, so I’m sure there’ll be further reinforcement and refinement of these top-level responses. And I would expect to see continuing movement on the part of Microsoft and its product groups to prove their ongoing top-level commitment to Silverlight and the whole idea of a Microsoft-based smart-client experience.

I think what happened is this: at least in the US we’re just a day away from a big election. For weeks (months?) we’ve been bombarded with messages of fear and hatred from political candidates, political action committees and cable news channels. It is very challenging to maintain a positive or even moderate outlook on life itself when you are continually inundated (unless you never watch television or listen to the radio or go to your mailbox) by these vile messages from every side for weeks or months on end.

It is no surprise to me that the developers, at least in the US, fell right into the same fear/hatred mindset with the (clearly incongruous) information about Silverlight – everyone’s mind is already primed for a fight-or-flight response. Confusion leads instantly to fear, which (as we all know) leads to the dark side.

After tomorrow, the election will be over, along with the fear/hate ads. By the time our brain chemistry has returned to normal, the newly elected politicians will be well down the path of corporate-sponsored corruption and life will continue.

In the meantime, at least we now know (again) that Silverlight has a bright future as the smart client development tool of choice for Windows, the Mac, Windows Phone and other devices.

Monday, November 1, 2010 1:27:32 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, October 27, 2010

The first WP7 app built by Magenic is now in the WP7 app marketplace: GuestList.

This app allows you to easily check in attendees at an event, using EventBrite as the backend service. You create your event in EventBrite, users register through their web site, and as they arrive at your event you get the attendee list on your phone, and easily check them in right there.

Chris Williams (Microsoft MVP and author of an upcoming WP7 developer book) did the development on this project, with assistance from Donn Felker (author of a similar app for Droid). Anthony Handley (from our Magenic Studios group) created the user experience flow and look and feel.

Very exciting stuff!

Wednesday, October 27, 2010 2:25:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

In the past week I’ve had a couple people mention that CSLA .NET is ‘heavyweight’. Both times it was in regard to the fact that CSLA 4 now works on WP7.

I think the train of thought is that CSLA 4 supports .NET and Silverlight, but that phones are so … small. How can this translate?

But I’ve had people suggest that CSLA is too heavyweight for small to medium app development on Windows too.

As you can probably guess, I don’t usually think about CSLA as being ‘heavyweight’, and I feel comfortable using it for small, medium and large apps, and even on the phone. However, the question bears some thought – hence this blog post.

I think there are perhaps three things to consider:

  1. Assembly size
  2. Runtime footprint
  3. Conceptual surface area

CSLA is a small framework in terms of assembly size – weighing in at around 300k (slightly more for .NET, less for SL and WP7). This is smaller than many UI component libraries or other frameworks in general, so I feel pretty good about the lightweight nature of the actual assemblies.

The runtime footprint is more meaningful though, especially if we’re talking about the phone. It is a little hard to analyze this, because it varies a lot depending on what parts of CSLA you use.

The most resource-intensive feature is the ability to undo changes to an object graph, because that triggers a snapshot of the object graph – obviously consuming memory. Fortunately this feature is entirely optional, and on the phone it is not clear you’d implement the type of Cancel button this feature is designed to support. Fortunately, if you don’t use this feature then it doesn’t consume resources.

The other primary area of resource consumption is where business rules are associated with domain object types. This can get intense for applications with lots and lots of business rules, and objects with lots and lots of properties. However, the phone has serious UI limitations due to screen size, and it is pretty unrealistic to think that you are going to allow a user to edit an object with 100 properties via a single form on the phone…

Of course if you did decide to create a scrolling edit form so a user could interact with a big object like this, it doesn’t really matter if you use CSLA or not – you are going to have a lot of code to implement the business logic and hook it into your object so the logic runs as properties change, etc.

There’s this theory I have, that software has an analogy to the Conservation of Energy Principle (which says you can neither create nor destroy energy). You can neither create nor destroy the minimum logic necessary to solve a business problem. In other words, if your business problem requires lots of properties with lots of rules, you need those properties and rules – regardless of which technology or framework you are using.

The CSLA 4 business rule system is quite spare – lightweight – at least given the functionality it provides in terms of running rules as properties change and tracking the results of those rules for display to the user.

The conceptual surface area topic is quite meaningful to me – for any framework or tool or pattern. Developers have a lot to keep track of – all the knowledge about their business, their personal lives, their relationships with co-workers, their development platform, the operating system they use, their network topography, how to interact with their IT department, multiple programming languages, multiple UI technologies, etc. Everything I just listed, and more, comes with a lot of concepts – conceptual surface area.

Go pick up a new technology. How do you learn to use it? You start by learning the concepts of the technology, and (hopefully) relating those concepts to things you already know. Either by comparison or contrast or analogy. Technologies with few concepts (or few new concepts) are easy to pick up – which is why it is easy to switch between C# and VB – they are virtually identical in most respects. But it is harder to switch from Windows Forms to Web Forms, because there are deep and important conceptual differences at the technology, architecture and platform levels.

I think large conceptual surface areas are counterproductive. Which is why, while I love patterns in general, I think good frameworks use complex patterns behind the scenes, and avoid (as much as possible) the requirement that every developer internalize every pattern. Patterns are a major avenue for conceptual surface area bloat.

CSLA has a fairly large conceptual surface area. Larger than I’d like, but as small as I’ve been able to maintain. CSLA 4 is, I think, the best so far, in that it pretty much requires a specific syntax for class and property implementations – and you have to learn that – but it abstracts the vast majority of what’s going on behind that syntax, which reduces the surface area compared to older versions of the framework.

Still, when people ask me what’s going to be the hardest part of getting up to speed with CSLA, my answer is that there are two things:

  1. Domain-driven, behavior-focused object design
  2. Learning the concepts and coding practices to use the framework itself

The first point is what it is. That has less to do with CSLA than with the challenges learning good OOD/OOP in general. Generally speaking, most devs don’t do OO design, and those that try tend to create object models that are data-focused, not behavior-focused. It is the fault of tooling and a matter of education I think. So it becomes an area of serious ramp-up before you can really leverage CSLA.

The second point is an area where CSLA could be considered ‘heavyweight’ – in its basic usage it is pretty easy (I think), but as you dive deeper and deeper, it turns out there are a lot of concepts that support advanced scenarios. You can use CSLA to create simple apps, and it can be helpful; but it also supports extremely sophisticated enterprise app scenarios and they obviously have a lot more complexity.

I can easily see where someone tasked with building a small to mid-size app, and who’s not already familiar with CSLA, would find CSLA very counter-productive in the short-term. I think they’d find it valuable in the long-term because it would simplify their maintenance burden, but that can be hard to appreciate during initial development.

On the other hand, for someone familiar with CSLA it is a lot harder to build even simple apps without the framework, because you end up re-solving problems CSLA already solved. Every time I go to build an app without CSLA it is so frustrating, because I end up re-implementing all this stuff that I know is already there for the taking if I could only use CSLA…

.NET is great – but it is a general-purpose framework – so while it gives you all the tools to do almost anything, it is up to you (or another framework) to fill in the gaps between the bits and pieces in an elegant way so you can get down to the business of writing business code. So while CSLA has a non-trivial conceptual surface area where it solves these problems – you’ll have to solve them anyway because they exist and must be solved.

In summary, from an assembly size and runtime size perspective, I don’t think CSLA is heavyweight – which is why it works nicely on WP7. But from a conceptual surface area perspective, I think there’s an argument to be made that CSLA is a very comprehensive framework, and has the heavyweight depth that comes along with that designation.

Wednesday, October 27, 2010 9:58:30 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, October 22, 2010

I would like to call out the amazing help I’ve had in getting the 4.1 beta out the door.

Jonny Bekkum is responsible for nearly all the non-WP7 changes in this release, with the exception of ASP.NET MVC.

Gary Brandt has really taken ownership of the ASP.NET MVC functionality provided by CSLA 4, and has made some really nice improvements, and perhaps most importantly has provided a good sample app (Samples\Net\cs\CslaMVC).

Justin Chase put a huge amount of work into updating UnitDriven for WP7 and getting most of the CSLA .NET unit tests running in WP7. This included fighting with some WP7 bugs, and perhaps even a Visual Studio debugger bug.

Without the substantial contributions of these individuals 4.1 wouldn’t be where it is!

Of course the framework wouldn’t continue to improve without the continuing support and suggestions from the CSLA .NET community on http://forums.lhotka.net – thank you to everyone who posts, your contributions are invaluable. I hope people continue to provide such high quality interactions via the forum.

Friday, October 22, 2010 1:54:36 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I am pleased to announce the first beta release of CSLA 4 version 4.1 with support for Windows Phone 7, and continuing support for .NET 4 and Silverlight 4.

Download CSLA 4 version 4.1.0 here

With this release, it is now possible to write a single business layer composed of business domain objects that run unchanged on a WP7 device, in Silverlight, on a Windows client, on Windows Server and on Windows Azure.

The samples download includes Samples\Net\cs\SimpleNTier, which does implement the following interfaces over one common business layer:

  • Windows Phone
  • WPF
  • Silverlight
  • ASP.NET MVC

Of course this is just the first beta release, so there’s more work to be done. At the same time, we have completed the vast majority of the effort, and it is quite possible to build WP7 applications using this beta.

As with all CSLA releases, this one does include some bug fixes and enhancements to other parts of the framework. Please see the change log for a list of all changes. Enhancement highlights include:

  • Add ability to get a consolidated list of broken rules for an object graph
  • New BackgroundWorker component that automatically initializes background threads with the current principal and culture from the UI thread
  • TriggerAction provides better debugging information, following the lead of many Microsoft XAML controls
  • and much more…

In related news, UnitDriven has also been updated to support WP7, and provides a pretty comprehensive unit test runner and framework for WP7 code. CSLA uses UnitDriven for its automated testing, but UnitDriven can be used for any application on .NET, Silverlight or WP7.

Similarly, Bxf (Basic XAML Framework) has been updated to support WP7, thereby providing a common MVVM framework for WPF, Silverlight and WP7 UI development efforts. Some CSLA sample apps use Bxf, but Bxf can be used for any application, including those that don’t involve CSLA at all.

Bxf | CSLA .NET | Silverlight | Web | Windows Azure | WP7 | WPF
Friday, October 22, 2010 1:35:18 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, October 15, 2010

Over the past 14 years of building and maintaining the CSLA framework I’ve tried several source control technologies and strategies. My current technology is Subversion and I have a branching and tagging strategy with which I’ve been very happy. So I thought I’d share how this works.

My CSLA .NET development team is distributed, with contributors to CSLA in various regions of the US and as far away as Norway. And my user base is truly global, with people using the code (and presumably looking at the repository) from countries in every corner of the planet.

I use Subversion primarily because it is “free as in beer”. In many ways I’d rather use TFS, but since I expose my repository to the world via svn clients and the web (and since CSLA is a free, open-source framework) TFS is completely out of reach financially.

The thing is though, if I used TFS I’d almost certainly use it the same way I’m using svn today. The lessons I’ve learned over the years about maintaining numerous releases, building major new versions and reducing administrative and developer complexity should generally apply to any source control technology.

Top level folders

My top level folder structure organizes each project.

image

No branching or tagging at this level. I tried that years ago, and it was a mess, because the branches and tags often don’t operate at the project level (because projects often have multiple components), so there’s a mismatch – the top level folders contain projects, but the branches/tags often contain components – and that’s confusing.

I know I could have a different repository for each project. And for more narrowly focused authorization access to the projects that would be nice. But in my case I want to expose all these projects externally via svn and web clients, so having the projects within a single repository makes my administration burden quite manageable. And I think it makes the repository easier to consume as an end-user, because there’s this one URI that provides access to the entire history of CSLA .NET.

You can see some “legacy projects” in this structure. Things like csla1-x or samples are really just places where I’ve dumped very old code, or code from some of the ways I no longer use svn. I don’t want to lose that history, but at the same time it wasn’t realistic to try and fit that older code into the way I currently organize the code.

Normally you’d look at core (the current code) or other comparatively live projects like n2, vb or ce.

Project folder structure

Within each project folder I have trunk, branches and tags.

image

This keeps each project isolated and reduces confusion within the repository.

Within the trunk I have the folders of my project. In the current trunk I’ve organized the CSLA 4 content into some high level areas.

image

At one point in the past I had the Samples as a separate project, rather than a folder within a project. That was a problem though, because the samples need to version along with the actual project source. They are dependent on the source. The same is true of the support files and setup project (and hopefully soon the NuPack project).

Basically what I’m doing is keeping all related content together within a project to avoid version mismatch issues (such as having samples versioning independent from the framework they demonstrate).

Tagging

I use tagging for releases. When I release a version of the framework, I create a tag that includes everything from trunk at the point of release.

image

The way svn prefers to think about tags is as a read-only snapshot of a point in time. That is perfect for a release, since it really is a snapshot in time. This is incredibly valuable because it means the code for any given release can always be easily discovered.

I wasn’t always so disciplined about this, and the results were bad. People would report issues with a version of the code and I wasn’t always able to see or even find that version. Nor was it possible to do change comparisons between versions. Having an easily discoverable and accessible snapshot of each version is invaluable.

Branching

I have used branching for different reasons:

  • Long-term maintenance of a point release (like 3.8)
  • Fixing bugs in an old release (where old is more than 1 release prior to current)
  • Creating major new versions of the code
  • Supporting experimental or research efforts that may or may not ever merge into the trunk
  • Creating alternate versions of the framework (like the N2 or VB versions)

image

Not all those reasons turn out to be good ones… Specifically, I no longer use branching to create alternate versions of the framework. Efforts like N2 or the VB version of the framework are now top level projects. While I might use “branching” to create those top level projects, I don’t maintain that code here in the branches folder of the core. The reason is that those projects take on a life of their own, and need their own branching and tagging – because they version and release independently.

However, I find that the long term maintenance of a point release is a perfect use for a branch. So you can see the branch for V3-8-x for example, which was created when I started working on CSLA 4 in the trunk.

In fact that’s an important point. In the past, when I started a major new version, I’d start that work in a branch and then merge back into trunk. While that technically works, the merge process is really painful. So I now keep trunk as being the future-looking code – including major new versions. In other words, whenever I start working on CSLA 4.5 (or whatever) that work will occur in the trunk, and before I start that work I’ll create a V4-0-x branch where I’ll be able to keep working on the then-current version.

I do cross-merging while working on major releases, especially early in the process when the code is still very similar. For example, while I was building CSLA 4 people would report issues with 3.8. So I’d fix the issue in 3.8 and then merge that fix from the 3.8 branch into trunk. That was easy, because trunk started out exactly the same. Over time however, that becomes increasingly difficult because the trunk diverges more from any given branch, and eventually such cross-merging becomes (in my experience) too difficult and it is easier to manually do the bug fix in both places (if appropriate).

Today almost all work is done in trunk, because the primary focus is on CSLA 4. At the same time, there are occasional bug fixes or changes made to 3.8, which of course occur in the V3-8-x branch. And when I do a release of 3.8.x that still results in a new tag for that release – with that tag created off the branch.

In some extremely rare cases, I might end up doing a bug fix for an older release (like 3.6 or something). While this is really unlikely, it can happen, and in such a case I’d create a branch off the tag (the snapshot of the release) to make that fix. And when that update is released, I’d create a tag off that branch for the release.

In summary, for branching I always end up with a branch to maintain the current code every time the trunk becomes focused on a major future release. I sometimes create a branch to fix a bug in an old release. And I sometimes create a branch to do some experimental or research work – to see “what if I did something crazy” without affecting any mainstream efforts.

I no longer use branching to create alternate versions of the framework, or to create major new versions. The drawbacks to using branching in those cases, specifically in terms of complexity and/or merging issues, is just too high.

This particular approach to folder structures, tagging and branching may not apply to all scenarios, but it has absolutely made maintenance of CSLA .NET easier and better over the past several years.

Friday, October 15, 2010 10:39:57 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, October 8, 2010

Every now and then someone asks me for some content they can use in a high level or executive presentation about CSLA .NET. Here’s a PDF with the slides I’ve been using for CSLA 4.

The first slide lays out the high level goals I keep in mind when building the framework.

image

The second slide provides a brief history of the framework. I use this to establish that CSLA has been around for a very long time, much longer than the vast majority of open source tools and frameworks for .NET (or most other platforms).

image

The third slide is more tactical, showing a high level list of features provided by the framework. What’s interesting about this list, is that the primary reason most people use the framework is that it provides such rich data binding support, but my original motivation was the concept of mobile objects. But as servers have become so powerful over the past 14 years that feature has actually become less important to a lot of people.

image

The final slide is a high level illustration of the types of organizations and applications that use CSLA .NET. You can get similar information on my web site (http://www.lhotka.net/cslanet/usage.aspx). I think the important thing to realize is that this framework is used all over the world, by organizations both big and small. For my part, I am honestly humbled by this reality – that amazingly talented people use CSLA to create some software that impacts people in many ways great and small.

image

Feel free to use this information if you find it valuable.

Thursday, October 7, 2010 11:02:45 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, September 30, 2010

Dunn Training is offering a three day hands-on CSLA .NET training class in Atlanta, November 8-10, 2010.csla_logo1_32

For more information, click here:
ttp://www.dunntraining.com/Training/schedule.htm

If you need CSLA .NET training, this is a great opportunity – check it out!

Thursday, September 30, 2010 5:47:37 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, September 2, 2010

I really enjoy working at Magenic – and that’s true even after 10 years.

We employ some really smart people, every one with passion for technology. Mostly .NET development of course, but also SharePoint, SQL Server, BizTalk Server and related technologies. And our Magenic Studios group has design skills (graphic, html/css and XAML), and a focus on usability, navigation and related skills.

We are hiring, especially in San Francisco and Boston, but also in Minneapolis, Chicago and Atlanta.

Are you a .NET developer? A XAML designer? An html/css designer? How about SharePoint development?

Consider applying for a consultant position at Magenic – it is a fun place to work with great people, often using cool technologies.

Thursday, September 2, 2010 2:58:38 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, September 1, 2010

The Microsoft Patterns and Practices group has a new guidance book out:

MSDN Library: Parallel Programming with Microsoft .NET

A printed version will be coming from O’Reilly

Parallel Programming with Microsoft® .NET

And there are code samples on CodePlex

Parallel Patterns CodePlex

Good stuff from the P&P group!

Wednesday, September 1, 2010 4:22:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Foundation 101/102 IASA Training will be hosted at Magenic Technologies on October 4th through October 8th.

The foundations coursework and certification expose candidates to the “awareness” level of the skills matrix, then takes the students through real-world application of those skills at the project level in a 4+ day series of workshops covering: a year lifecycles of business justification/selection of projects, creating the architecture, managing through delivery, and then maturing the engagement model of the architecture team.

Finally a full half-day is spent on preparation for the CITA-Foundation certification exam.

You can register for the course at IASA’s home site www.iasahome.org “Twin Cities” location.

Group discounts are available.

Course Rational

Heard of IASA and the Certified IT Architect – Professional (CITA-P) certification process? Interested in going through the process? Have you mapped your skill set and experience to the IASA Skills Matrix? This course will introduce you to the IASA skills matrix that is validated with the CITA-P certification. This 1 week course provides introduction to the IASA skills matrix and provides a self-analysis tool to evaluate current skill level against the IT Architect Body of Knowledge:

IT Architecture Body of Knowledge  (ITABoK)

Pillar 1: Business Technology

Pillar 2: IT Environment

Pillar 3: Quality Attributes

Pillar 4: Human Dynamics

Pillar 5: System Design

IASA

The IASA vision is Professionalization of IT architecture, and our model is built on proven methods that successful professions have taken historically (Doctors, Lawyers, Building Architects, etc.); our career path model and supporting education/certification come from practicing architects as a professional association, not from individuals in a back room. IASA has built a global community of over 60,000 in readership, and thousands of contributors from multiple countries, industries and specializations. From that community, we have built extensive and inclusive skills taxonomy and methods for teaching and evaluating the capabilities within the taxonomy.

www.iasahome.org

Wednesday, September 1, 2010 4:12:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Good news on the WP7 front:

Windows Phone 7 – Released To Manufacturing

And we know that the dev tools are planned for release in just a couple weeks – so this is all coming together fast.

Wednesday, September 1, 2010 2:47:02 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Lessons learned getting CSLA 4 to build and run in WP7.

  • Obviously WP7 is based on SL3, so SL4 specific code won’t work (which caused most of my initial build issues).
  • Human error plays a big role – I created several new projects for WP7, and even though they shared existing code files (via file linking), I forgot to set things like the assembly names and default namespaces – obviously that caused issues with serialization between client and server. Never underestimate the ability of the human to overlook simple things…
  • Don’t underestimate the impact of the tiny screen. While WP7 can run code from a full-screen app (the same business objects, etc), it is amazing how the need to fit into a tiny screen can impact the way you build your application!
  • VS10 doesn’t support signing assemblies, but you can do it by manually editing the csproj file.
  • VS10 doesn’t support resource files, but you can manually add a resx to the main project, then drag it into the Properties folder, then set the file’s properties (custom tool, etc) so it works correctly.
  • WP7 appears to throw different exceptions from .NET/SL for various things. There are a number of cases where I’m having to catch and rethrow exceptions to get the expected exception type – which is something I don’t need to do in .NET/SL. Since my unit tests often check for expected exceptions (testing failure conditions), I’m seeing a lot of these issues and having to tediously address them one by one.
  • VS10 crashes “for no reason” on some WP7 code. I have the same code in .NET, SL and WP7 and can walk through code in the debugger, but sometimes WP7 crashes Visual Studio – I assume this is due to the beta state of the tools.
Wednesday, September 1, 2010 12:24:12 PM (Central Standard Time, UTC-06:00)  #    Disclaimer