Delphi-losophy

A Lover of Delphic Wisdom

The Definition of a Gentleman

Posted on by nickhodges@gmail.com

The True Gentleman is the man whose conduct proceeds from good will and an acute sense of propriety, and whose self-control is equal to all emergencies; who does not make the poor man conscious of his poverty, the obscure man of his obscurity, or any man of his inferiority or deformity; who is himself humbled if necessity compels him to humble another; who does not flatter wealth, cringe before power, or boast of his own possessions or achievements; who speaks with frankness but always with sincerity and sympathy; whose deed follows his word; who thinks of the rights and feelings of others, rather than his own; and who appears well in any company, a man with whom honor is sacred and virtue safe.

– John Walter Wayland

Flotsam and Jetsam #106

Posted on by nickhodges@gmail.com
  • Number 10 with a bullet!
  • As you may have noticed on my LinkedIn Profile, I am once again an employee at Gateway Ticketing.  This time around, I am a Senior Software Developer, meaning I am full-time Delphi Developer.  I’m delighted to be back in the new beautiful building that Gateway has built.  I’m also pleased to have shaved an hour off of my commute each way.  I enjoyed my time at Veeva Systems, but the prospect of returning to Gateway and reducing my commute was just too much to resist.
  • Why did Borland fail?  Danny Thorpe gave an answer on Quora, and it is being discussed on Hacker News.
  • The inestimable Julian Bucknall has released is well-known EZDSL data structure library at GitHub.  Thanks, Julian!
  • Book Update:  As many of you know, I’m working on a new book called, naturally, “More Coding in Delphi” and I thought I’d give you an update on it.  The whole book is written, and it’s going to be a little longer than “Coding in Delphi”.  It’s now in that really hard stage where you have to read it and read it and update it and change the demos and fix things and do all the millions of little things that it takes to finish things up.  In other words it’s in the “The last 20% takes 80% of the time” mode.  But don’t worry, as I type this I’m sitting at Burger King getting ready to plow into things and “git ‘er done”. 

Review: FixInsight

Posted on by nickhodges@gmail.com

A confession:  I was given a free license to review FixInsight.

A summation:  I really like it.  It’s in a category tool that I think most Delphi developers don’t take advantage of. 

A statement:  It’s not as powerful as Delphi’s Code Audits, but it is more usable.  I presume that Roman Yankovsky will continue to improve it and eventually it will cover as many rules as Code Audits does.  Start using static analysis today, one way or another.

Full Comments:   FixInsight is a static code analysis tool.  A static tool is one that examines the code itself, apart from any runtime environment.  It uses a parser – in this case, a fork of Jacob Thurman’s Pascal Parser – to examine the code and apply a set of rules against the result.  Those rules can point to questionable constructs in your code that may be bugs or other problems.  You can use static analysis to enforce formatting rules,  find places where coding conventions have not been followed, and to enforce specific coding techniques.  The compiler will do a lot of this kind of thing for you, but there are certain things that the compiler won’t see that

FixInsight does all of this for you in the IDE.  Once installed, it provides a menu item that brings up the following dialog:

image

From here, you can select or unselect the Conventions or Warnings that you want to verify.  Some of the Conventions and Warnings can be configured as shown above where you can set the maximum number of variables that will be allowed in a given method on the right side of the window.

Conventions are things that “should” be done a certain way; they might be described as enforcing a certain coding “style”.  For instance, Convention C107 ensures that all private field variables in a class start with ‘F’, a long time Delphi convention. 

Warnings are coding constructs that “look suspicious”.  Things like a destructor without an inherited call, or the dreaded “Empty EXCEPT block” – that is, things that are likely just wrong code and that could cause problems in the execution of your code.    A warning basically says “Something doesn’t look right here and you should take a close look to make sure that all is well and correct”.

Running Fix Insight operates much like the compiler and produces Convention and Warning messages in – Surprise!  — the Message Pane:

image 

If you double click on one of the items, it take you to the spot in your code where the problem occurs.   Nice.

FixInsight also includes a command line tool for inclusion in a continuous integration process.  In fact, I’d recommend this be the main way you use it.  It can be used to fail a build that finds code in your repository that doesn’t conform to your definition of “clean” code. 

You can tell FixInsight to ignore chunks of your code via the _FIXINSIGHT_ compiler directive.

The documentation is quite nice, with each rule clearly explained, though I found that FixInsight’s descriptions are very easy to understand, and you shouldn’t have any trouble figuring out what it is trying to tell you. 

Here’s how I recommend you use FixInsight:

  1. Establish a set of Conventions and Warnings that you want to enforce.
  2. Use the IDE tooling to ensure that your code conforms to those rules and that you never check in code that violates any of your rules
  3. Run the command line tool as part of your continuous integration process, and break the build if any checked in code violates your rules

Do that, and it will go a long way towards keeping your codebase clean and tidy.

You can download a trial version of FixInsight here

I presume that Roman will add more Conventions and Warnings to future versions — there’s a lot of room here to do some very cool things.

Bottom Line:  FixInsight is a fine entry into the Delphi Third-party market.  Whether you decide to use it or Delphi’s own tool, you should be including static code analysis into daily routine and your continuous integration.

Flotsam and Jetsam #105

Posted on by nickhodges@gmail.com

Complete Martin Harvey’s Multithreading Article Online

Posted on by nickhodges@gmail.com

Threading in Delphi, or in any other tool for that matter, is difficult.  There are a lot of good resources out there for Delphi developers, but perhaps none better than Martin Harvey’s “Multi-threading: The Delphi Way”.  There is a copy of it here —  http://thaddy.co.uk/threads/ – but sadly it doesn’t include the graphics and the code. 

Well, I was working on the TThread chapter for my new book, and guess what I happened across on my hard drive?  The entire copy of Harvey’s work, including the graphics and the code samples.  I have no idea how I came to have it, but I do.  I thought it would be worth posting in its entirety, so I did:

http://www.nickhodges.com/MultiThreadingInDelphi/ToC.html

It’s all there – graphics, code samples, and text.  I hope I’m not violating any intellectual property rights in posting it.  I certainly am grateful to Mr. Harvey for his work.  If I am doing wrong here, please let me know and I’ll take it down. I’d hate to have to do that, though. 

Otherwise, there it is as a valuable resource for the Delphi community.  I hope it is helpful to someone.

Flotsam and Jetsam #104

Posted on by nickhodges@gmail.com
  • Stefan chastises me for making another one of my pronouncements on “evil” programming techniques.  I admit to a bit of hyperbole, but it’s not without a point.  The argument against my pronouncements is that the wise and judicious use of these so-called “evil” features or techniques is good.  I don’t agree.  I think that if a “feature” has the ability to be *easily* abused, then it should be avoided.  For instance, some make the argument that there places where the `with` statement makes sense.  Well, my counter argument to that is if you allow the `with` statement in a few places, it’s very easy to use it in just a few more places, and then the next thing you know, your code is full of `with` statements.  It’s a slippery slope that you should never start down.  The same is true for nested procedures.  Sure, there might be places where they “make sense”, but if you allow them in one place, what is to stop a junior programmer from getting the wrong idea and go crazy with them?  This is especially true for features that simply need not be used at all – such as `with` and nested procedures.  You can write beautiful code without them, so why risk sliding down the slope?  Better to ban their use altogether.  (Cue the “Then why don’t we all just use assembler” comments in 3..2…1….)
  • I’m a big user and proponent of the Spring for Delphi framework. If you are, too, then you might consider donating to the project.  The website now has a PayPal donate button.
  • I recommend that you give a very careful read to Marco’s post about what was going on at the Microsoft BUILD conference last week.  Lots of interesting stuff there for us Delphi developers, both in the Windows and cross-platform realms.
  • Torry.net is for sale.  Hat tip to Olaf Hess in the non-tech group for this piece of information.

Flotsam and Jetsam #103

Posted on by nickhodges@gmail.com

Flotsam and Jetsam #102

Posted on by nickhodges@gmail.com
  • Wallace and Gromit run on Delphi.
  •  I of course want you to buy my book, but I have been doing research for my next book and am thus reading sections of Delphi XE2 Foundations.  I can’t recommend this book enough.  It’s a tour de force for Delphi and the RTL.  I know how hard it is to write a book, and I can’t imagine how much work this one took.  It’s excellent, and I highly recommend it (after you buy my book, of course….).  Don’t be put off by “XE2” in the title, this is a great book for all Delphi developers.  Kudos to Chris Rolliston.
  • I’ve never really gotten into Quora, but it seems like a pretty cool site which has somehow managed to produce quality questions and answers without all the spam and other nonsense that often attends such a site.  Here’s a Quora question about Delphi that many of you might like to answer and/or read about.
  • Yesterday, I tweeted the following:  “Of all the types of reviews out there, the  ‘I couldn’t understand it so it must really suck, 1 star’ reviews are my favorite.” In researching my book, I’ve been re-reading Dependency Injection in .NET
     by Mark Seemann.  I looked up the book on Amazon, and was astonished to find that someone had given this amazing and enlightening book a 1-star review.  Some people, I swear.  This review is more along the lines of what the book deserves.
  • Correction:  Apparently, it was Borland C++ 3.0 that was the big box with the handle.  Thanks for the correction from Jeroen Pluimers, who also found a picture. (You have to scroll down a bit, but it’s there…)
  • A Clarification:  Two points to make on my last post about subscriptions.  First, it wasn’t about EMBT, but rather the software industry in general. Second, the point wasn’t “Software subscriptions are great!”, but rather “The industry is moving to subscriptions, and here’s why”.  Many folks seemed to believe I was arguing the former.  Perhaps I was just inarticulate.  Sorry for any confusion.

You are going to pay for bug fixes. And you’re going to like it.

Posted on by nickhodges@gmail.com

The day is coming when you are going to have to pay to get bug fixes.  You won’t like it at first, but that is the way things are heading.  And you should like it.

I can remember the day when software came with free support.  You had a problem, you called up the company and spoke to a tech support representative who would help you with your problem.  For free.  For hours if need be.  It was expected.  Of course a company should support a product that they sold.  If it wasn’t easy to use or didn’t work right, they need to make good on it. 

You might, at this point, see where this is going.

Then, of course, economics caught up with the marketplace, and companies began to charge for support, sometimes upwards of $100 an hour. People didn’t like it at first.  But even that became uneconomical as the internet appeared, and people stopped paying for support when they could get free support on the internet.

I can remember the day when software came with a stack of manuals, sometimes two feet high.  Anyone remember the Borland C++ 4.0 box? It was so big it had a handle built into it.  (I looked for a picture of it, but couldn’t find a good one…)  Of course the company should supply physical documentation with their product!

Then, of course, economics caught up with the marketplace, and companies couldn’t afford to ship all that paper with the product, and the documentation became digital and shipped with the DVD.  Hard copy documentation fell by the wayside.  People didn’t like it at first.

I can remember the day when software came on DVD’s, and when you ordered a new version of your favorite software package, they mailed you a DVD with a nice case.  (Shoot, I can remember when they mailed you 3.5” floppies, but that’s another story.) Of course the company should send you a physical copy of the software.  You paid for it, damn it, and you should get a disc! 

Then, of course, economics caught up with the marketplace, and now, you don’t even get that DVD.  Instead, you get a download link for an ISO file and you burn your own DVD if you want a physical backup. Or you just download an installer.  More likely you simply stored the software file on a backup hard drive or, now, in the cloud.  People didn’t like it at first.

You definitely should see where this is headed now. 

Pretty soon now, we’ll all be looking back on the day when you actually bought a stand-alone license for your software, and you got bug-fix updates with that single purchase.  Of course a company should give bug-fixes for free – the product should work right in the first place, and so why should I have to pay to get bug fixes?

But the economics of that are going to catch up with everyone, and soon companies are going to stop selling licenses and start selling only subscriptions.  And in order to get updates – including bug fix updates — you will have to have a subscription.  People won’t like it at first. 

The future is already here for many software tools.  Adobe sells only subscriptions for their highly popular graphics tools.  Office 365 is sold as a subscription.  And if you own either of those, you are – surprise! – paying for bug fixes.  This is a trend.  Microsoft and Adobe are not small software vendors.  You will see more and more software tools being sold this way.  It’s inevitable, as economics and the marketplace do their thing and technology enables new business models.

A pause for some thoughts:

  • It’s a silly thing to believe that the complex software that you buy should be bug free.  No non-trivial software is bug-free.  All software is buggy.  Everyone knows this.  Developers, in particular, should know this.  Yet people still argue that the product should be bug-free and that they should be entitled to free bug fixes because they “paid for a product that should work out of the box”.  Well, I hate to break it to you, but no software “works right out of the box” and there is nothing that developers can do about it.  I’ll say it again:  all non-trivial software has bugs and there’s nothing to be done about that.
  • Even brilliant developers develop code with bugs in it.  Even a clairvoyant QA team won’t find all the bugs. 
  • All software development requires intense human labor.  Bug fixing requires intense human labor. Companies cannot afford to do things for free.   Good developers and QA people are not cheap. 
  • Thus, as we saw with free support, documentation, and DVD’s, something has to give.  And that something is the notion of “buying a single, stand-alone license” for your software.  It’s going to go away.  Software companies are slaves to the marketplace just like every other business in the marketplace, and they are being driven to a subscription model just like they were driven away from free and then paid support, as well as stacks of paper for documentation and DVDs for software distribution.

People won’t like this at first.  But they should. 

First, the overall cost of a subscription will be less than purchasing upgrades.  Subscription fees have so far proven to be a remarkably good deal.

Companies will have vastly more flexibility to add features on a more frequent basis rather than in yearly (or longer) upgrade cycles.  Companies that sell only subscriptions can also talk more freely about their future plans because – and I am mentioning this with great trepidation – they won’t have revenue recognition issues with regard to future-looking statements.

And yes, companies will be more motivated to fix bugs – perhaps even bugs in previous versions.  Because they will have a steady stream of revenue and because they will be off the “one big release” mentality, they will have more leeway to fix bugs.  Because they can bring features to market sooner than they might have before, they can spread the pressure of releasing new features over longer, less focused periods of time.  Removing shipping pressure increases quality. 

Some will argue that a subscription model incentivizes companies to care less about quality.  This is nonsense.  It will incentivize them to care more about quality, because there will be no more excuse not to increase quality.  If quality doesn’t increase, people won’t renew their subscriptions.  And companies will be very, very interested in renewed subscriptions.  Low quality will not be a good business model while providing subscriptions.  Since feature pressure will be reduced, quality can become more prominent.

Yeah, people won’t like this change.  You are probably firing up the comment dialog box as I type this.  But I think we all see the benefit of free internet support like StackOverflow, online documentation like wikis, and software downloads that get you your software immediately.  Those were changes that we didn’t like at the time, but that we see the value in now.

And so it will be with software subscriptions.  So, yes, you are in essence “paying for bug fixes”.  But bug fixing is both inevitable and costly.  However, you’ll also be getting more frequent updates, more frequent new features, higher quality, and more openness about the future.  You’ll always have the latest and greatest version of your software package.

Who doesn’t want that?

Fun Code of the Day #1

Posted on by nickhodges@gmail.com 
unit uEnumConverter;

interface

type
  TEnum = record
  public
    class function AsString<T>(aEnum: T): string; static;
    class function AsInteger<T>(aEnum: T): Integer; static;
  end;

implementation

uses
      TypInfo
    ;

{ TEnum }

class function TEnum.AsString<T>(aEnum: T): string;
begin
  Result := GetEnumName(TypeInfo(T), AsInteger(aEnum));
end;

class function TEnum.AsInteger<T>(aEnum: T): Integer;
begin
  case Sizeof(T) of
    1: Result := pByte(@aEnum)^;
    2: Result := pWord(@aEnum)^;
    4: Result := pCardinal(@aEnum)^;
  end;
end;

end.