Random Thoughts on the Passing Scene #135

• Phew – okay, been a while.  I was “on the road” last week.  Thanks to all the great folks that showed up in Philadelphia, Raleigh, and Minneapolis for my road show.  I hope I was able to convey the great stuff in the latest version of RAD Studio.  (Don’t forget to use your “special codes” to get at 20% discount on purchases. They expire soon.)  It was great to get out again and meet with customers, developers, etc.  Thanks to everyone who helped out with getting the events going.  It was fun, and I even got to spend the weekend with my parents in Minneapolis.  Great times.
• Developer Express has been a long time partner and provider of outstanding VCL components.  I know that many of you use their stuff rather faithfully.  I know that early every year they have a meeting to plan out what they will be up to for the coming year.  This year, long-time community member and DevExpress guy Richard Morris is asking for input from the DevExpress VCL customer base.  This is a great opportunity to give some feedback to a company that loves to hear from you.
• Here’s a curious phrase, or at least one that has become curious over the past few years:  “Online help”.  What does that mean to you today?  Today, it means to me “Help that is on the internet somewhere, and that I can look at with a browser”.  But of course, say, fifteen years ago, it mean “Help that is on my hard drive and connected via the F1 key”.  I think if you say the phrase now, the former definition is what people will understand it to mean.  So that begs a question:  What should we call help that is on your hard drive?  "Local help”?  Anyone have any ideas?
• Marco is offering a nice special on his two latest books.  These are the same books that many of you got as part of your Delphi/RAD Studio purchase, but if you haven’t gotten them yet, now is the time to buy.  Marco’s books are always good, and these two are particularly good for folks moving to the new versions. 
• And finally, I am thankful for many things on this Thanksgiving day here in the US – my family, my friends, my freedom.  I’m also thankful to the Delphi community and to all of our customers that make it possible.

Share This | Email this page to a friend

posted @ Thu, 26 Nov 2009 07:28:44 +0000 by Nick Hodges

Happy Thanksgiving (U.S.A) and time for analysis for the Survey

Hello All,

A while back I asked the community to fill out the 2010 Delphi Survey and the response has been GREAT!  Over 2500 responses so far!!!  If you have not filled out the survey, please take some time (it is a very long survey) and fill it out or at least the questions that matter to you.  Survey takers can fill it out over a period of time as long as they use the same computer, it will hold the position.

Survey can be found here:  http://www.surveymonkey.com/s.aspx?sm=XrKr27_2bmLfybzGzZi_2brsBQ_3d_3d

One of the things that Tim and I wanted to do this time around is share some of the findings with the community.  One of the things I was interested in was exposure to features, did the average community member know about X feature, if yes, did they know how to use it, did they use it, or was it not use… and for me the most important answer… I need educated on that feature.

So a lot of the questions have that as an option; "I need educated" and here are some early results of the top 10 things the community needs education on:

10.  Sync Edit
09.  VCL Designer Guidelines
08.  Unit Testing Wizard
07.  UML Class Modeling
06.  UML Visualization
05.  Static Code Audits
04.  Static Code Metrics
03.  XML Binding Wizard
02.  Live Templates

01.  REFACTORING!

So I will work with Tim to see if we can get a few Educational Webinars scheduled that go over these areas.  There are a few that we can put together and make an hour and a few that we may have to split up.

Please if you have not filled out the survey, give us your feedback.  Let me know what you think of the topics, there are many other that we could also do.

Mike

More to come…

Share This | Email this page to a friend

posted @ Wed, 25 Nov 2009 17:25:44 +0000 by Michael Rozlog

Delphi Tour stops in Sacramento and Los Angeles

Your truly will be in Sacramento on 12/2 and in Los Angeles on 12/3. Please follow the links for all the details. Please tell all your friends and co-workers to register in advance so that we can have enough PIZZA for you all!

In other news, Michael Rozlog (Delphi Product Manager) will be in Atlanta on 12/1 and in Miami on 12/2. Please see those links for details and registration as well.

Thanks, and Happy Turkey Day!

Share This | Email this page to a friend

posted @ Wed, 25 Nov 2009 17:04:34 +0000 by Anders Ohlsson

Debugging Direct2D

posted @ Tue, 24 Nov 2009 11:40:00 +0000 by Chris Bensen

On the road! Atlanta and Miami

All,

I’m going to be on the road the 1st week of December doing the Delphi Roadshow in both Atlanta and Miami.

If you have time, come out and heckle me, and ask your questions, I would love to see you there!

Mike

Date:   12/1/2009
Time:   6:00-8:00pm
Setup:  5:00pm
Location:
Atlanta-Fulton Public Library Central Library
1 Margaret Mitchell Square NW
Atlanta, GA 30303-1089
Map to location: http://tinyurl.com/ydoducn

Date:   12/2/2009
Time:   6:00-8:00pm
Setup:  5:00pm
Location:
Doubletree Miami Mart/Airport Hotel
711 N.W. 72nd Avenue
Miami, Florida, USA 33126
Map to location: http://tinyurl.com/y8qbd6j

Share This | Email this page to a friend

posted @ Tue, 24 Nov 2009 19:33:26 +0000 by Michael Rozlog

Using Delphi "Unit Aliases" to aid in unit testing

• Resolving unit dependencies.  Think of a case where a unit uses another unit just so it can access one symbol from that unit.  Assume that the used unit iteself uses many other units.  In order to build a test for the code in this unit, the compiler must resolve all used units.  Due the nature of the IDE source code, it’s very easy to get into a situation where a unit test ends up pulling in a very large number of source units that aren’t really needed for the test.
• Resolving IDE services accessed by the unit being tested.  Think of a case where a unit being tested uses a core IDE service to, say, display status in the IDE splash screen during startup, or to output a message to the IDE’s message view (just two of many possible examples).  Because the IDE isn’t running, it’s unlikely that these services would be available to the unit test.

There have been different approaches to overcoming these challenges, that those of us on the IDE team have taken when writing unit tests:

• Refactoring the unit being tested has helped in some of these cases.
• Another approach has been to litter the code being tested with {$IFDEF} or {$IFNDEF} directives so that only the code being tested is visible to the test.  Yes, I use the term "litter" because of its negative connotation –  using IFDEFS can compromise code readability and maintainability.  Also, any time you change code (even if to only add/remove IFDEFS), you risk breaking something (yes, this may be less of an issue, since you are, after all, changing code so you can write unit tests).
• A third approach, which is the subject of this post, is to provide a unit with stubs for the dependencies and then use the Delphi compiler’s Unit Alias feature when building the unit test.  A major benefit of this is that it allows you to test existing code without having to modify that code.

Take the over-simplified unit shown in this screenshot:

Let’s assume we want to write a unit test for TMyClass.DoSomething and that the OutputAMessage procedure 1) lives in a unit (MessageServices.pas) that pulls in a lot of extra units, and 2) requires UI that is not available while unit testing.  A simple way to write this test is to provide a unit which provides an implementation of "OutputAMessage".  Let’s call the unit TestStub:

Yes, you could use an IFDEF in Unit1’s uses clause to conditionally use either the MessageServices or TestStub unit.  But what if the unit being tested is more complex?  What if there are many functions/symbols/etc. living in spearate units that you want to provide a stub for?  What if the code uses a unit name in order to qualify a symbol (i.e. what if the code in Unit1.pas referenced "MessageServices.OutputAMessage" instead of just "OutputAMessage" in order to resolve a symbol ambiguity)?

Unit aliases allow you to address those concerns.  When compiling the unit test, if you define a Unit Alias of "MessageServices=TestStub", it will use the stubbed version in TestStub.pas.  When you build your main project, it will continue to use the real version in MessageServices.pas.  If you wanted to provide a single stub unit for multiple "real" units, you would just provide addtional aliases:  "MessageServices=TestStub;AnotherUnit=TestStub".  And due to the way Unit Aliases are implemented by the compiler, it will properly alias unit names used as scope qualifiers in the code.  As mentioned earlier, a great benefit of this approach is that you can test your existing units without having to modify them at all.

You can define Unit Aliases in the IDE using the Project | Options dialog.  In Delphi 2010, this option is on the "Delphi Compiler" page.  When building from the command line, the appropriate compiler switch is -A (i.e. -AMessageServices=TestStub).

While the compiler’s support for Unit Aliases was originally added to increase backwards compatibility and to ease migration when a new version of a unit has a different name than an older version, I have found the feature to be quite useful in helping to unit-test code that might otherwise not be easily tested.

Share This | Email this page to a friend

posted @ Tue, 24 Nov 2009 17:50:38 +0000 by Chris Hesik

Touch Demo

posted @ Tue, 24 Nov 2009 08:00:00 +0000 by Chris Bensen

More ways to get to Delphi’s Audits and Metrics

Ok, in Delphi 2010 there are now more ways to get to the static code Audits and Metrics.

When you are in you code, you can click the Project menu and select either QA Metrics… or QA Audits… menu items.

Or, you can click the Model View tab (beside Project Manager) and enable modeling (do some visualization it is fun!) and right-mouse click on the area you want to check (top-level, package level, file level) and select QA Metrics… or QA Audits… menu items.

Or, you can go into the Modeling surface and right-mouse click on the surface and select QA Metrics… or QA Audits from the context menu.

Many ways to get to the tools, great tools, have fun and give them a try…

Mike

More to come…

Share This | Email this page to a friend

posted @ Mon, 23 Nov 2009 17:19:17 +0000 by Michael Rozlog

Graphics vs Text : Picture superiority effect

posted @ Fri, 20 Nov 2009 14:41:00 +0000 by Kyle Hailey

Static Analysis - Metrics - Volumns

As many of you know, I really like Metrics and Audits for helping build better code.  One thing to remember when doing Metrics, make sure to compare apples to apples and not apple to oranges to steak!

Many metrics are based on the following:

• Methods; a sub routine of an object
• Objects;
• Classes;
• Files
• Lines

If you try to compare or make assumptions with metrics that focus on a Method level like Cyclomatic Complexity (CC) and try to relate that to Lines of Code (LOC), the observations are going to be off, really off!

Because having a high or low Cyclomatic complexity has nothing to really do with how many lines of code make up a class or file.  I could have a million lines of code and have a perfectly defined class that has very optimized methods and so Cyclomatic Complexity never gets above 8.

However, looking at Cyclomatic Complexity (CC) and working with Maximum Size of Operation (MSOO) can help determine if there are long methods that have high complexity, which then can be used to help determine a refactoring plan.

Always try to keep data grouped together.

Mike

More to come…

Share This | Email this page to a friend

posted @ Fri, 20 Nov 2009 17:06:18 +0000 by Michael Rozlog