The project has been put on hold for now. We got stuck early in January when we couldn't get past a deeply entrenched component from a third party vendor that had gone belly up. With no access to source code (and we did try to find a way of getting it) - there was no option but looking at replacing the component. Unfortunately, the effort required to migrate to a new component have been estimated to be so comprehensive that a complete refactoring may turn out to be a better alternative.
It just goes to show the importance of ALWAYS, and I do mean ALWAYS getting ALL components with source code. Another repeat observation is the importance of decoupling your GUI from your datamodel and business logic. Keep your GUI stupid.
I'll post some generic observations about code changes at a later point in time - but right now I am sunk in other tasks.
Tuesday, March 10, 2009
Friday, December 12, 2008
Review: Framework Design Guidelines, 2nd Ed. by Krzysztof Cwalina and Brad Abrams
Subtitle: "Conventions, Idioms, and Patterns for Reusable .NET libraries". Highly relevant to Delphi Prism users, but you can very well eliminate that .NET part and apply this to writing libraries for Win32 using Delphi 2009 as well (or any prior Delphi version, for that matter).
When you write code with the intent of making it public and reusable, there are certain aspects of designing classes, interfaces, types and so forth, where we really need experience to come up with easy to understand and easy to use code. This book delivers 6 years worth of wisdom and experience from the .NET teams and we can all do well by picking their brains for reusable knowledge.
The book present a sensible set of lessons learned and goals to strive for. Without lecturing, and always exemplifying - we get a step by step journey through the different aspects of designing a framework. It is concisely written and easy to read, and it is not without humor.
The book is richly commented by the developers themselves, embellishing on the guidelines, sometimes including design regrets and mistakes made, and sometimes also hinting towards why you might want to break a guideline under certain conditions.
As Anders Hejlsberg write in the foreword: "The guidelines have served us well through three versions of the .NET Framework and numerous smaller projects, and they are guiding the development of the next generation of APIs for the Microsoft Windows operating system".
I won't delve into all the details of the content, but it covers the basics of how to design a framework by being roleplaying the consumer as well as testing it on your peers, good naming, type design, member design, extensibility, exceptions, as well as usage guidelines. It rounds off with a collection of common patterns such as aggregate components, async patterns, dependency properties, dispose pattern, factories, and many more. There is also a brief C# coding style convention section and a tutorial on using FxCop to enforce the framework design guidelines.
The book is not C# centric, but embellish the fact of .NET being a multi-lingual platform, and remind you to avoid certain constructs that may be too tightly bound to a specific language.
"Framework Design Guidelines (2nd Ed.)" by Krzysztof Cwalina and Brad Abrams (Addison-Wesley ISBN-13: 978-0-321-54561-9) falls under the collection of books that I wish I had available to read when I started out coding. Together with "Code Complete (2nd Ed.)" by Steve McConnell, it should be mandatory reading for every developer, regardless of language or development niche.
Highly recommended.
When you write code with the intent of making it public and reusable, there are certain aspects of designing classes, interfaces, types and so forth, where we really need experience to come up with easy to understand and easy to use code. This book delivers 6 years worth of wisdom and experience from the .NET teams and we can all do well by picking their brains for reusable knowledge.
The book present a sensible set of lessons learned and goals to strive for. Without lecturing, and always exemplifying - we get a step by step journey through the different aspects of designing a framework. It is concisely written and easy to read, and it is not without humor.
The book is richly commented by the developers themselves, embellishing on the guidelines, sometimes including design regrets and mistakes made, and sometimes also hinting towards why you might want to break a guideline under certain conditions.
As Anders Hejlsberg write in the foreword: "The guidelines have served us well through three versions of the .NET Framework and numerous smaller projects, and they are guiding the development of the next generation of APIs for the Microsoft Windows operating system".
I won't delve into all the details of the content, but it covers the basics of how to design a framework by being roleplaying the consumer as well as testing it on your peers, good naming, type design, member design, extensibility, exceptions, as well as usage guidelines. It rounds off with a collection of common patterns such as aggregate components, async patterns, dependency properties, dispose pattern, factories, and many more. There is also a brief C# coding style convention section and a tutorial on using FxCop to enforce the framework design guidelines.
The book is not C# centric, but embellish the fact of .NET being a multi-lingual platform, and remind you to avoid certain constructs that may be too tightly bound to a specific language.
"Framework Design Guidelines (2nd Ed.)" by Krzysztof Cwalina and Brad Abrams (Addison-Wesley ISBN-13: 978-0-321-54561-9) falls under the collection of books that I wish I had available to read when I started out coding. Together with "Code Complete (2nd Ed.)" by Steve McConnell, it should be mandatory reading for every developer, regardless of language or development niche.
Highly recommended.
Tuesday, November 18, 2008
Porting from D5 to D2009 - prologue
I have to admit I am looking forward to looking back at this project.
300.000+ lines of code, using numerous third party components, a sophisticated in-house ORB sitting on top of BDE with several designtime components, built-in version control for SQL statements and tight Oracle integration. Dozens of input forms and hundreds of reports.
I am not quite sure where to begin...
Should I convert to D2007 first, or go directly for D2009?
Advice would be appreciated.
300.000+ lines of code, using numerous third party components, a sophisticated in-house ORB sitting on top of BDE with several designtime components, built-in version control for SQL statements and tight Oracle integration. Dozens of input forms and hundreds of reports.
I am not quite sure where to begin...
Should I convert to D2007 first, or go directly for D2009?
Advice would be appreciated.
Subscribe to:
Posts (Atom)
Posts
