Widgets May 2011

Flotsam and Jetsam #33

By Nick at May 20, 2011 09:01
Filed Under: Flotsam and Jetsam

A Note on Delphi Open Source Licensing

By Nick at May 12, 2011 14:29
Filed Under: Delphi, Software Development, TechBiz

I love open source code.  I love the notion of sharing and working together for the betterment of a community. I love the free stuff that I can use because of the generosity of open source developers. 

Open source development often can be bogged down by licensing decisions.  I don’t know how many bits have been spilled arguing over the exact meaning the Lesser GNU Public License (LGPL), or whether the GNU Public License (GPL) is one step away from a socialist worker’s paradise or not, but surely it’s a lot of bits. 

Well, I’m going to spill a few more.

I totally get the GPL – I respect it, and I laud the folks that do work on GPL-based projects.  They are really giving away for free (as in speech) their work to others.  Linux exists because of the GPL. I get why the license exists. I understand the whole “Free Beer/Free Speech” thing.   Some amazing, awesome things exist because of the GPL.  It’s all good.


The GPL is completely incompatible with commercial software.  Totally, utterly, and completely incompatible.  If you use GPL source code in your commercial application, you are obligated to release your entire application as a GPL Open Source project.  Everything.  Obviously, if you sell your software, you very likely don’t want to do that.  (I recognize that there are folks that will, and more power to them…..).

Now, Delphi is a development tool used by a whole lot of businesses – businesses that are likely not to want to make their source code available under the GPL.  And so open source projects that are aimed at Delphi developers make a very limiting decision if they release their code under the GPL.  A Delphi library of code with the GPL attached to it will severely limit the number of Delphi  users that can or will use that library. 

Many of the popular open source libraries for Delphi use a much less restrictive license.  All the Turbopower code was released under the Mozilla Public License (MPL) which is much less restrictive, only requiring you to share any changes you make to the MPL project itself.  Others use the Apache License which is very permissive.  But some do use the GPL.

Now, I’m going to give some advice to those folks who publish Delphi source code under the GPL:  Issue it under an alternative license – one that businesses can handle.  I’d recommend MPL at the most strict end of the spectrum.  We are going to start using the Delphi Spring Framework, and that is licensed under the very friendly Apache license.  I’d love to use the Emballo framework as well – particularly for the Mock object classes, but it is licensed under the GPL, and so we really can’t touch it. A project like the Emballo project is also available for use under the LGPL and worth considering.

The GPL is great – it works well in the Linux world and where other open source development tools reign supreme.  But for more commercial-based eco-systems like Delphi, a business-friendly license is much more in order. 

Flotsam and Jetsam #32

By Nick at May 12, 2011 13:28
Filed Under: Flotsam and Jetsam, Software Development
  • “We put our faith in Apple and they screwed us”  Just another reason why Apple always seems to rub me the wrong way.  Don’t get me wrong -- I think Apple should be able to do what they want when it comes to this type of thing – but I don’t have to like it.
  • I confess to being guilty of this in my blog, but no more, I promise.
  • Have you had this problem? You are working on a website and local testing/debugging is a hassle because you have to move from page to page filling in valid information, and it takes huge amounts of time and you cringe when you have to do it?  Our team here at Gateway has started to use iMacro.  It’s a FireFox that lets you record events on a given website and run them with the click of a button.  This is saving our guys tons and tons of time.  Highly recommended.
  • And yet another way that you can support the fine work we do here at – you can join DropBox as my referral.  It’s completely free for the first 2GB. Yes, I am well aware that this appeal is utterly shameless.  In addition, I give the DropBox folks full marks for marketing – they basically have a zero-dollar advertising budget.

Getting Giddy with Dependency Injection and Delphi Spring #2 - The Law of Demeter

By Nick at May 11, 2011 09:07
Filed Under: Delphi, Software Development


Okay, I keep digging into the Delphi Spring Framework and I keep finding cool stuff you can do, so I can hardly wait to write all these articles.  Seriously, this is a mind-expanding experience.

First, though, I need to talk about some general topics.  There are a few things that need to be accepted and understood before Dependency Injection can really sink in.  (And again, I want to point  out that I’m deeply indebted to Misko Hevery of Google for a lot of this material.)

The Law of Demeter (LoD)

First topic -- the Law of Demeter.   What exactly is the Law of Demeter?  The strict definition goes like this:

Law Of Demeter

A method of an object may only call methods of:

  1. The object itself.
  2. An argument of the method.
  3. Any object created within the method.
  4. Any direct properties/fields of the object.

That’s a bit formal, so here’s a “real world” example:

Let’s say you go into a store.  You buy a bunch of stuff, and the total is $25.  When you go to pay, what do you do?  If you are believer in the Law of Demeter, then you pull out your wallet and give the $25 to the clerk – just the money, nothing more.

But no, you are a scofflaw and fear not the deep coupling of your wallet to other people and thus you think the Law of Demeter is for weaker men, so you pull out your wallet and hand the whole thing over to the clerk and let her decide what to do for the payment. 

Lady at Cash Register

Sure, you intended to pay with cash, but instead the clerk takes your wallet, uses a credit card to pay for the stuff, drops your library card on the floor, runs your BuyMore loyalty card through a degaussing machine, and draws a moustache on the picture of your wife.  You paid for the stuff, but wow, what a mess!

That’s why you should follow the Law of Demeter in a nutshell.  It’s basic premise is that you should only hand over (and on the other side, only ask for) exactly what you need to hand over (or ask for).  Things should be linked together with as thin a string as possible.  The Venn diagram illustrating the connections between classes should have as small an overlap as can be managed.  In this example, you might not even want the clerk to know you have a wallet, right?

Or in another example, you wouldn’t give the paperboy your wallet or let him search around your house for spare change.

A Coding Example

So for instance, in code, you may have a Transaction class that needs a form of payment to be completed.  And hey, look! The Customer class has different Forms of Payment, so you pass a Customer to the Transaction.  Sure, at first all is well, because you are very careful and all you do is grab the Form of Payment from the customer and use it.  What could possibly go wrong?


But a few months pass, and that (cough, cough) “less experienced” developer comes along and says “Hey look! Here’s a Customer object!  I think I’ll change his address here instead of over there!” and all heck breaks loose.   Pretty soon, you are fixing a bug in the Transaction class and Customer data changes.  You fix a Customer bug and access violations start flying when you try to commit transactions to the database.  The next thing you know, changing a Customer address is sending major cash bonuses to your office cleaning service, and before you know it, there is no end to the havoc reeked by that little Customer object innocently sitting in the Transaction class.

The right thing to do, of course, is to simply pass the Form of Payment itself, or better yet, forget the Form of Payment and pass in just the money itself in some form.  The idea is that your classes should ask for a little as possible, and refuse to accept more than they need.    If you have code like this --


-- that is, code that seems to drill down deep into a class hierarchy -- then you probably deserve a ticket from the cops for breaking the Law of Demeter.  You’ve gone searching down a rabbit hole for something that you should have just asked for to start with.

The classic quote is “Only talk to your friends, and never talk to strangers”. “Mind your own business” comes to mind as well. 

Or let’s put it in even starker terms:  Pretend that every class you write is a pristine clean room with no germs, dirt, or any other yucky stuff in it – and that you plan on keeping it that way.  Are you going to let some delivery guy who just tramped through a horse barn while sneezing because of the ebola virus just walk  into your room and hand you a package? Heck no!  You are going to make him shower, scrub, de-sanitize, purify, and otherwise delouse himself before entering.  Heck, you should probably make this guy put on some sort of bio-hazard suit on before you let him in.  Or even better still, don’t let him in at all, and only let him pass in whatever he’s trying to give you via some secure slot in the door. 

That’s how you should be treating any outsider class that want’s to sneak in to the current class.

Law of Demeter in Delphi

Delphi and the Law of Demeter can be good friends.  Here are some pointers to help out in your Delphi code:

  • Limit the number of units in your uses clauses.  If you have a long list of items in your uses clause, it is a strong indication that things are tightly linked together.
  • Limit the scope of your uses clauses.  If you can put an item in the uses clause of the implementation, do so. 
  • Use strict private and strict protected.  This will limit you from the temptation to make classes “friends” of each other in the same unit.
  • As noted above, anytime you have a chain of “dotted” properties in a single line, you should examine this for violations of LoD.
  • Anytime you are creating a lot of temporary object, this might indicate un-necessary dependencies.
  • Check your constructors – if they are creating a lot of things or taking a lot of other classes as parameters, then the same thing applies:  the possibility of too much coupling.

Note that these aren’t iron-clad rules, but rather suggestions of examination and consideration. It need not become “a Dot Counting Exercise.”  The idea is to reduce coupling and thus limit the damage any one modification can have on the system as a whole.


Following the Law of Demeter is a key to creating clean, easier to maintain code.  Once you get that down, you’ll also find that you are writing code that is easy to test.  Next time, we’ll take a look at why it’s important to write testable code. 

Flotsam and Jetsam #31

By Nick at May 10, 2011 08:30
Filed Under: Flotsam and Jetsam, Delphi
  • Interesting News Item of the Week:  Microsoft is buying Skype.  I’m a huge fan of Skype.  I like it best as an IM client, and as a teleconferencing system as well.  The creepy feeling you get when someone is on Skype in a conference room using a nice set of speakers takes some getting used to.  It’s a bout 342 times better than a POTS conferencing system.  Anyhoo – I’ll be curious to see if MS rewrites the currently-written-in-Delphi Windows clients and continues to support non-Windows clients as well. 
  • New Delphi Blog of the Week: Delphi Sorcery  and I’ll give him Cool Delphi Code of the Week as well. 
  • As you may have noticed, I’ve added one of those little tool bars to my posts that let’s you Like/Add/Tweet/whatever my postings.  I do this in a self-glorifying attempt to get you to broadcast my stuff more.  It was amazingly easy to do with AddThis.  I trust you all will take the hint. 
  • I thought this was pretty impressive.  How long can it be before everything is just a Javascript application running in a browser?  I’ve been saying for years that Javascript is to the browser what assembler is to the CPU.

I Have a New IDE Color Scheme……

By Nick at May 10, 2011 08:08
Filed Under: Delphi

I used a theme from the many found in the Delphi Theme Editor as a starting point, did a few tweaks, and ended up with my my new coloring scheme that I’ve called “ChocoCaramel”  What do you think?


What do you think?  Here’s the XML file from the Delphi Theme Editor if you want it.

ChocoCaramel.theme.xml (103.56 kb)

Getting Giddy with Dependency Injection and Delphi Spring #1

By Nick at May 09, 2011 14:13
Filed Under: Delphi, Software Development

I remember way back in the 90’s when I finally had “the light bulb” go on about object oriented programming.  You know “the light-bulb” I’m talking about  -- that moment when suddenly you get it and it all becomes clear and it all makes sense and you have this thrilling sense of understanding and one-ness with your code and the new concept.  It’s really fun.

For me and OOP it came in the middle of reading what is still my all-time favorite Pascal book, Borland PASCAL 7 Insider by Paul Cilwa.  I can still remember where I was sitting when suddenly it all came together in my brain.  It was very exciting.

And I was feeling that way again this week when I started doing Dependency Injection with the Delphi Spring Framework.  It really came to a head when I realized that I can create useful and powerful units that have no code in their interface sections. 

That’s right:  no code in the interface section. No uses clause, no code, no nothing.  Seriously – a unit that looks like this:

unit DoWhatever;


  // a whole bunch of cool code here and nowhere else


Yeah, you heard me – nothing.  And yeah, the cool code mentioned above works and is totally accessible.  That fact alone should give you pause – and give a clue into the power and coolness of what I’m talking about.  And yes, I’m still giddy about all this.

So, how does this happen you ask?  Well, it’s going to take a little while to explain – maybe even a few blog posts – so if you want to see this cool thing that’s got me all goose-pimply, you’ll have some to do some reading.

At the start, I want to say that I’m well aware that Java guys in particular have been doing this kind of thing for while, and that .net guys have been  as well.  That’s great. I know Delphi is a bit late to the party here, and I am too, but that doesn’t make it any less cool and it doesn’t make me any less giddy.  Winking smile

Okay, first, I’ll give you a few things to do.  To get the basic idea of where we’re going with all this,  I recommend that you read the seminal article by the inestimable Martin Fowler about Dependency Injection.  Understanding what Dependency Injection is  is key to all this cool stuff.  I’ll try to explain what Dependency Injection is in the first post, and then move on to the code itself.

Second, you’ll need at least Delphi 2010 and preferrably Delphi XE to do all this.  This stuff requires Parameterized Types (Generics) and you can only get that language feature from Delphi 2010 and above.

Third, you should go and download the Delphi Spring Framework from Google Code.   I recommend that you pull it using Subversion instead of grabbing the zip files as then you’ll be able to keep up more easily on this always improving project.  Get the code and start poking around, particularly in the Spring.DI.* units and the tests that go with it.  The TContainer class is really the heart of things, and so give that a close look.

And if you want some cool videos to watch that talk about a number general principles of how you can use dependency injection to make your code better, I’d recommend these three by Misko Hevery of Google:

And that ought to get you started thinking about some of the things you should be thinking about when doing Dependency Injection.

Next time I’ll give some samples of code and why this is all important.  And yes, I’ll likely be using a lot of the same material that Misko did.  Smile

My Old Blog is Back!

By Nick at May 04, 2011 00:39
Filed Under: Delphi, General

Hey, I’m delighted to note that my old Embarcadero blog is back online.  Thanks and kudos to David I who noticed that it was amiss and resurrected it.  He noted in a comment that the “archive” flag apparently didn’t mean what he thought it meant.  In any event, I’m very happy to have it back online.  Thanks, David I!

Flotsam and Jetsam #30

By Nick at May 03, 2011 05:00
Filed Under: Delphi, Flotsam and Jetsam

My Book

A Pithy Quote for You

"There is nothing so useless as doing efficiently that which should not be done at all."    –  Peter Drucker

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.