Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Sunday, February 12, 2006

Every now and then someone asks what tools I use to write books and articles.

 

I write in Word. Typically the publisher provides a specific template with styles that are to be used, so when they get to the last stage and need to do layout they can easily change the styles to get the proper appearance on the printed page.

 

Graphics, figures and screen-shots are, I find, the most frustrating part of the process in many ways. I use Snagit for capturing screen images into TIFF files, which isn’t too bad. But for creating other graphics I use a combination of Visio, PowerPoint, Corel Draw, MS Paint, screen shots and Snagit – along with Acrobat and (more recently) PDF Converter to generate PDF docs containing the figures. Not being graphically oriented, I find the whole process arcane and frustrating – especially as I’ve often had to redo figures a couple times because they are “blurry” or something – typically due to various resolution issues.

 

As an aside, this is what scares me about WPF (Avalon), since all of us programmers are going to be forced to learn all this arcane graphics stuff just to be competent at even basic application development. Personally I think that this could derail WPF adoption overall – at least until a large set of stock, good-looking, controls come into being from either Microsoft or third parties.

 

Microsoft seems to have this deluded idea that business sponsors are going to pay for graphic designers to build the UI – which I think is highly unlikely, given that they typically won’t even pay for decent testing… Who’d pay to make it pretty when they won’t even pay to make sure it actually works?!?

 

But back to the tools.

 

All the writing is done in Word. The final stage of reviewing however, occurs in PDF form. The publisher does the final layout, resulting in a PDF which will ultimately be sent to the printer. But I have to go through each chapter in PDF form to catch any final issues (typos, graphics issues, etc). I annotate the PDF files and send them back, so the layout people can make the changes and recreate the PDF.

 

I also use Microsoft Project. Not for the writing itself, but to schedule the process. Before committing to a writing schedule I create a project of my life. I put fixed-date tasks for all my travel, client commitments, vacations and anything else that I know will consume time during the writing process. Then I put in floating tasks for every chapter and have Project level my life (so to speak). This gives me at least a reasonable projection of how many calendar days it will take to do each chapter.

 

That’s pretty much it :)

Sunday, February 12, 2006 9:09:42 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Tuesday, February 07, 2006

A few people have asked how the book is coming along, so here’s an update.

 

I touch each chapter a minimum of four times: to write it (AU), to revise it based on tech review comments (TR), to revise it based on copyedit questions (CE) and to do a final review after layout/typesetting (TS).

 

I am writing both the VB and C# books “concurrently”. What this really means is that I’m writing the book with one language, then skimming back through to change all language keywords, code blocks and diagrams to match the other language.

 

To practice what I preach (which is that you should be competent, if not fluent, in at least two languages) I am doing the book in C# and then converting to VB. It takes around 8 hours per chapter to do that conversion, 12 if there are a lot of diagrams to convert (code is easy – the damn graphics are the hard part…).

 

So, here’s the status as of this evening:

 

Chapter

C#

VB

Cover

AU done

-

Front matter

AU done

-

1

TS done

TR done

2

TS done

AU

3

TS done

AU

4

TS

-

5

CE done

-

6

CE done

-

7

CE done

-

8

CE done

-

9

CE done

-

10

CE done

-

11

TR done

-

12

TR done

-

 

People have also asked how much I expect the CSLA .NET 2.0 public beta code to change between now and the book’s release at the end of March. Chapters 2-5 cover the framework, and as you can see those chapters are into the final editing stages. As such, I certainly don’t anticipate much change.

 

While I’ve made every effort to keep the VB and C# code in sync, there may be minor tweaks to the code as I roll through the VB chapters 2-5. But I’ve used both in projects and at conferences like VS Live last week, and both pass my unit tests, so those changes should be cosmetic, not functional.

 

In other words, the beta is pretty darn close to the final code that’ll be provided for download with the book.

Tuesday, February 07, 2006 9:05:15 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
 Thursday, February 02, 2006

It is fairly common for people to focus so much on the CSLA .NET “feature list” that they forget that the purpose of the framework is merely to enable the implementation of good OO designs. Many times I’ll get questions or comments asking why CSLA .NET “only” supports certain types of objects, and why it doesn’t support others.

 

The thing is, CSLA .NET doesn't dictate your object model. All it does is enable a set of 10 or so stereotypes (in CSLA .NET 2.0), providing base classes to simplify the implementation of those stereotypes:

 

·         Editable root

·         Editable child

·         Editable root collection

·         Editable child collection

·         Read-only root

·         Read-only child

·         Read-only root collection

·         Read-only child collection

·         Name-value list

·         Command

·         Process

 

CSLA .NET provides base classes to minimize the code a business developer must write to implement this set of common stereotypes. But the fact is that most systems will have objects that fit into other stereotypes, and that's great! CSLA .NET doesn’t stop you from implementing those objects, and it may help you.

 

If you have objects that don’t fit the stereotypes listed above, you may still find that specific CSLA .NET features are useful. For instance, if your object must move between the client and application server, the data portal is extremely valuable. This is true even for objects that don’t actually use “data” (as in a database), but may have other reasons for moving between client and server. In other cases, an object may benefit from the Security functionality in CSLA .NET, such as authorization.

 

The point is that you can pick and choose the features that are of use for your particular object stereotype. If you’ll be creating multiple objects that fit this new stereotype, I recommend creating your own base class to support their creation (not necessarily by altering the Csla project itself, as that complicates updates). As much as possible, I’ve tried to keep the framework open so you can extend it by creating your own base classes – either from scratch, or inheriting from something like Csla.Core.BusinessBase, or Csla.Core.ReadOnlyBindingList.

 

The key point, is that you should develop your object model based on behavioral object design principles. Then you should determine how (and if) those objects map into the existing CSLA .NET stereotypes, thus identifying where you can leverage the pre-existing base classes and tap into the functionality they provide. For objects that simply don’t fit into one of these stereotypes you can decide what (if any) CSLA .NET functionality those objects should use and you can go from there.

 

In short, the starting point should be your object model, not the “feature list” of CSLA .NET itself.

Thursday, February 02, 2006 2:06:08 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
July, 2014 (2)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In