Amazon.com Widgets Nick Hodges | A man's got to know his limitations

Loop Less with IEnumerable and Spring for Delphi

By Nick at January 06, 2013 19:57
Filed Under: Delphi, Software Development

I rave about the Delphi Spring Framework.  But I think my attention to the Dependency Injection Framework – which is only part of it -- has made you guys think that the two are synonymous.  Not true – Spring4D is more than just a Dependency Injection container.  In fact, there is a wealth of other stuff to be found in Spring4D.

Inspired by this StackOverflow question and a thread in the newsgroups, I thought that I’d write an article about a very powerful but not so well known (apparently) feature of Spring4D – IEnumerable<T> and the accompanying container interfaces and classes.

So the StackOverflow question basically asks this: How do I find out the maximum value of an integer in TList<integer>?

Well, the first thing you might do is use a for loop to check each item, and save each one as it gets larger.  Or if you were really tricky, you’d use a for…in statement to find it.  That’s the “straight-up” way to do it.

But that isn’t the real answer to the StackOverflow question.  The real answer is this:

program ListEnumerableDemo;

{$APPTYPE CONSOLE}

{$R *.res}

uses 
    System.SysUtils 
  , Spring.Collections;

var 
  List: IList<Integer>; 
  Enumerable: IEnumerable<integer>;

begin 
  try 
    List := TCollections.CreateList<integer>; 
    List.AddRange([1,6,2,9,54,3,2,7,9,1]);

    Enumerable := List; 
    WriteLn(Enumerable.Max); 
    ReadLn; 
  except 
    on E: Exception do 
      Writeln(E.ClassName, ': ', E.Message); 
  end; 
end. 

 

Now that looks quite a bit different than the code you were thinking of, I’ll bet.   There doesn’t even appear to be any looping going on at all.  There is in the background, but it’s all been abstracted away for you.  You want the maximum value to be found in the list?  Just ask for it.  Cool.

The key part above, of course, is the use of two things.  First, the IList<T> – an interface to a generic list – and secondly, the IEnumerable<T>.  Both of these types are provided by the Delphi Spring Framework.  Both are defined in the Spring.Collections.pas unit.  That unit contains a complete group of collection interfaces – IList<T>, IStack<T> ICollection<T>, etc. – as well as the definition of IEnumerable<T>. 

I’d recommend that you consider using Spring.Collections.pas instead of the Generics.Collections.pas unit which comes with Delphi.  First, it exposes all of the collection types as interfaces, and you should know by now that you should be coding against interfaces and not implementations.  Secondly, each of the types supports the IEnumerable<T> interface, meaning you have the power of this great interface on all of your collections.

We’ll tackle those two things in order.

Spring Collections

The Spring.Collections.pas unit is all you need in your uses clause to avail yourself of all that the Spring collections library provides.  The unit includes the following interfaces along with a class to provide easy access to implementations of these interfaces:

Interface Description
ICollection<T> A Collection is a group of items in no particular order.  You can't insert items into a specific location in a collection, only add or remove them.  A collection can’t be sorted because it has no order.
IList<T> A list is a group of items in a particular order.  Items can be sorted and inserted in particular locations.
IDictionary<TKey, TValue> A dictionary is a data structure that allows you to “look up” items.  Each entry takes a key and a value, and values can be looked up by asking for it via the item’s key.  This is a useful data structure, as any type can be uses as the index, and any type can be stored for lookup.
IStack<T> A stack is a First In, Last Out data structure. Think of a spring-loaded stack of plates at the cafeteria – you “push” plates onto the stack, and then “pop” them off in reverse order.
IQueue<T> A queue is a First In, First Out data structure.  Think of an ordinary line that you wait in, or a tube in which items are inserted at one end and taken out on the other.
ISet<T> A set is a data structure involving membership.  Items are either in the set or out.  A set’s methods allow you to determine the intersection, union, or overlap with any other container.

 

All of these types should be familiar to you – if not, you can certainly read up on them via Google.  The important part is that they are all generic (though there are non-generic types with store TValue as well) and they all implement IEnumerable<T>.

The unit also provides a class called TCollections which has nothing but class methods that return instances of the types listed above.  These methods act as proxies for the constructors of the implementing types.  You can create your own instances if you like, but for the most part, TCollections will do the job of getting an implementation of whatever container interface you want.  For instance, if you want to get a hold of a dictionary, you can do the following:

program ListEnumerableDemo;

{$APPTYPE CONSOLE}

{$R *.res}

uses 
    System.SysUtils 
  , Spring.Collections;

var 
  List: IList<Integer>; 
  Enumerable: IEnumerable<integer>;

begin 
  try 
    List := TCollections.CreateList<integer>; 
    List.AddRange([1,6,2,9,54,3,2,7,9,1]);

    Enumerable := List; 
    WriteLn(Enumerable.Max); 
    ReadLn; 
  except 
    on E: Exception do 
      Writeln(E.ClassName, ': ', E.Message); 
  end; 
end. 

The example above uses TCollections.CreateList<integer> to get an implementation of the IList<T> interface.

The implementations are all in units named Spring.Collections.Stack.pas and the like, but the Spring.Collections.pas unit exposes almost everything you need, and so as a rule, you should only need it in your uses clauses to take advantage of these powerful containers.

 

IEnumerable<T>

Those of you who also use .Net are familiar with IEnumerable already, but perhaps you didn't know that the same power was available to you in your Delphi code.  For those of you not familiar, you are in for a treat.

The IEnumerable<T> interface is implemented by all of the classes discussed in the previous section, and so any of them can be accessed as an IEnumerable<T>. 

Here is the declaration of IEnumerable<T>:

IEnumerable<T> = interface(IEnumerable)
    function GetEnumerator: IEnumerator<T>;
    function AsObject: TObject;
    function TryGetFirst(out value: T): Boolean;
    function TryGetLast(out value: T): Boolean;
    function First: T; overload;
    function First(const predicate: TPredicate<T>): T; overload;
    function FirstOrDefault: T; overload;
    function FirstOrDefault(const defaultValue: T): T; overload;
    function FirstOrDefault(const predicate: TPredicate<T>): T; overload;
    function Last: T; overload;
    function Last(const predicate: TPredicate<T>): T; overload;
    function LastOrDefault: T; overload;
    function LastOrDefault(const defaultValue: T): T; overload;
    function LastOrDefault(const predicate: TPredicate<T>): T; overload;
    function Single: T; overload;
    function Single(const predicate: TPredicate<T>): T; overload;
    function SingleOrDefault: T; overload;
    function SingleOrDefault(const predicate: TPredicate<T>): T; overload;
    function ElementAt(index: Integer): T;
    function ElementAtOrDefault(index: Integer): T;
    function All(const predicate: TPredicate<T>): Boolean;
    function Any(const predicate: TPredicate<T>): Boolean;
    function Contains(const item: T): Boolean; overload;
    function Contains(const item: T; const comparer: IEqualityComparer<T>): Boolean; overload;
    function Min: T;
    function Max: T;
    function Where(const predicate: TPredicate<T>): IEnumerable<T>;
    function Skip(count: Integer): IEnumerable<T>;
    function SkipWhile(const predicate: TPredicate<T>): IEnumerable<T>; overload;
    function SkipWhile(const predicate: TFunc<T, Integer, Boolean>): IEnumerable<T>; overload;
    function Take(count: Integer): IEnumerable<T>;
    function TakeWhile(const predicate: TPredicate<T>): IEnumerable<T>; overload;
    function TakeWhile(const predicate: TFunc<T, Integer, Boolean>): IEnumerable<T>; overload;
    function Concat(const collection: IEnumerable<T>): IEnumerable<T>;
    function Reversed: IEnumerable<T>;
    procedure ForEach(const action: TAction<T>); overload;
    procedure ForEach(const action: TActionProc<T>); overload;
    procedure ForEach(const action: TActionMethod<T>); overload;
    function EqualsTo(const collection: IEnumerable<T>): Boolean; overload;
    function EqualsTo(const collection: IEnumerable<T>; const comparer: IEqualityComparer<T>): Boolean; overload;
    function ToArray: TArray<T>;
    function ToList: IList<T>;
    function ToSet: ISet<T>;
    function GetCount: Integer;
    function GetIsEmpty: Boolean;
    property Count: Integer read GetCount;
    property IsEmpty: Boolean read GetIsEmpty;
  end;

That’s a lot of cool stuff, right?  Many of the methods here are pretty clear -- it's pretty obvious what the Min and Max methods do. But some of the others are a bit trickier.  You can get all of the items.  You can get the First and Last items.  You can get the first x number of items.  You can get the items back out as a List, an Array, or a Set.  And most powerfully, you can get any particular group of the items out using a predicate.

Predicates

What is a predicate?  A predicate is an anonymous function (or any function, really, but in our case it is an anonymous function) that takes a single const parameter of the type in question and returns True or False.

 TPredicate<T> = reference to function(const value: T): Boolean;

It is used with some of the methods of IEnumerable<T> to answer this simple question:  In or out?  If the predicate is true, then the individual item is “in”, or included.  If it is “out”, then the predicate will return False.  So if you want to get all the items in a list strings that contain the letter ‘z’, then you can do the following:

function ContainsLetterZ: IEnumerable<string>;
var
  List: IList<string>;
begin
  List := TCollections.CreateList<string>;
  List.AddRange(['zoo', 'park', 'city', 'town', 'museum', 'jazz festival']);

  Result := List.Where(function(const aString: string): Boolean
                     begin
                       Result := Pos('z', aString) > 0;
                     end);
end;

The above uses the Where method to determine items that should be returned as part of a new IEnumerable<string>.  The above is saying “return to me an enumerable item where all the strings in the list have ‘z’ in them.”

You can do similar things with the TakeWhile method, which returns items from the start of the list as long as the predicate is True, and stops once the predicate is False.   You can determine if a given container has or doesn’t have a given element.  You can Skip over a given number of elements and take the rest.  You can use a predicate to SkipWhile a certain thing is true, and then return the rest once the predicate returns True  Basically, once you have a reference to a collection or any IEnumerable<T> instance, you can get out of it pretty much anything you want.

Something to consider:  If you have a nicely composed class that includes a private IList<T> which gets exposed through proxy methods, then you might want to expose access to the items via a property of type IEnumerable<T> instead of exposing the actual list itself.

And the real power gets unleashed with the very powerful ForEach methods.  Folks have always pined for the lovely ForEach since the days of Borland Pascal’s old TCollection object, and now it’s back in full force, leveraging the power of anonymous methods.  Thus, you can have a collection and do what you please with the items.  Here is a simple example of just outputting them to the console window, but you can have your TAction<T> do anything at all that you like for each (sorry) element in the container.

procedure SimpleForEachDemo;
var
  List: IList<integer>;
  Action: TAction<integer>;
  i: Integer;
begin
  Action := procedure(const aInt: integer) begin Writeln(Format('This number is: %d', [aInt])); end;

  List := TCollections.CreateList<integer>;
  for i := 1 to 10 do
  begin
    List.Add(Random(100));
  end;

  List.ForEach(Action);
end;

So, basically you have a lot of untapped power there in Spring.Collections.pas, eh?  The use of IEnumerable<T> and predicates ought to transform your code and change the way you look for things in lists and collections.  If you aren’t using these powerful tools yet, I strongly recommend that you add them to your tool chest.

I’ve written a pretty thorough example application for IEnumerable<T> and put it up on BitBucket.  I also have some pretty simple examples showing predicates at work.

Remember, the Delphi Spring Framework is more than a Dependency Injection container.  And there’s more to it than the container classes as well.  I strongly recommend that you start treating Spring4D like part of the Delphi Runtime Library.  Heck, I wish Embarcadero would do just that.

Flotsam and Jetsam #72

By Nick at January 04, 2013 20:21
Filed Under: Delphi, Flotsam and Jetsam, Software Development
  • Am I weird?  One of the first things I do when I install Delphi is to turn off Brace Matching and Line Highlighting.  I find both of these features incredibly distracting, particularly the Brace Highlighting, which makes it impossible to see where the caret is in the text. 
  • This article by Hal Berenson should make interesting reading for Delphi folks interested in the economics of development tool vending and the business models around them.  Delphi isn’t mentioned, but it does discuss the changing business model of Visual Studio from within Microsoft and how Adobe’s tool business put pressure on MS and actually changed how they did business.  MS’s  Interesting stuff.
  • I love Twitter and try to tweet pretty frequently (I’d be honored if you followed me).  One of the fun part of tweeting is seeing the creative and interesting use of hashtags.   One current hashtag that is going around and that is of interest to us Delphi developers is #code2012.  In it, folks are putting the names of the languages that they coded in during the past year.  Someone has a nice graphic that shows the relative popularity – and Delphi isn’t doing too badly.  I just tweeted to help make that Delphi circle just a little bigger.  Winking smile
  • Holy cow, I feel like I did when Buffy ended – stunned and saddened.   Žarko Gajić is moving on from his position as the guide for About.Com Delphi.  Žarko has been doing that job for 15 years, and I’m willing to bet that his site is as common a search result as any in the community.  Well done, Žarko, and good luck in your future, Delphi-related endeavors.  And hey, the door is open – anyone willing to step into Žarko’s shoes?

Comments should work

By Nick at December 28, 2012 09:14
Filed Under: Delphi

Sorry for the confusion -- comments should work now.  Thanks to Chris Timmons for pointing out the problem.

Flotsam and Jetsam #71

By Nick at December 26, 2012 10:40
Filed Under: Delphi, Flotsam and Jetsam, General, Software Development
  • I’ve shamelessly tweeted it a couple of times, and I’ll promote it here as well – I’ve created a Bookstore page here containing a list of books that I think are must-reads for all developers.  What books would you add to the list?
  • Have you upgraded to Delphi XE3 yet? If you haven't, please do.
  • Okay, I need some advice:  I want to learn a functional programming language, but which one?  Clojure?  Haskell? F#?  What? 
  • I need some more advice:  I have a good working knowledge of SQL and SQL Server.  But I’m going to need to become a SQL Server 2008 expert in the coming months.  Can any of you fine people recommend the best book or other resource for going from the basics to really being a guru?  Again, I’m looking specifically at T-SQL and SQL Server itself.

Rock-n-Roll Leadership

By Nick at December 09, 2012 20:03
Filed Under: Leadership

Who ever knew that the great .38 Special held the secret to a good leadership viewpoint?

Just hold on loosely
But don't let her go
If you cling too tightly
You're gonna lose control

Hold on Loosely” by .38 Special

That simple lyric holds a valuable viewpoint for leaders. The song, of course, is about a girl.  But imagine you are holding a small bird in your hand.  If you hold the bird too tightly, you’ll crush it.  If you hold the bird too loosely, it will escape. But if you hold it just right, not too loosely and not too tightly, then the bird will stay in your hand, and maybe even feel safe.  And if you focus on it, it’s probably not too hard to figure out just the right amount of pressure to keep the bird in your grasp.

It’s the same way with leadership.  One of the toughest decisions leaders make is how much control to exert over their people.  It’s a delicate balance.  Both too much and too little can cause difficulties and cause you to lose your team.  Finding just the right amount of control is a large challenge. 

The tendency of many leaders is to “cling too tightly”.  They tend to want to have close control over their people.  They want to make sure every little detail is taken care of, setting rules, procedures, and processes for every little thing to ensure that things never get out of control.  They view their people as merely cogs in machine, and thus give them little autonomy to make decision, innovate, improvise, and otherwise come up with their own solutions.  They make every decision, ensuring (in their minds) that things are going perfectly.

There is a word for this – micro-management.  No one ever thinks that they are being a micro-manager.  In my experience, the more a leader micro-manages, the more he thinks he isn’t.  Micro-managers tend to think that they are providing leadership because it’s needed, because their team can’t be trusted, or, sadly, because they think that their team is simply incompetent to do the job.  Or perhaps they feel that they have to be involved in order to get the credit.

Whatever the reason, a leader who clings too tightly is being ineffective and usually has a negative effect on her team.  People feel the lack of trust, and that’s demoralizing.  Teams that are given little autonomy soon lose their desire to improve and find better ways to do things.  When their leader has all the answers and always knows what is best, why even try?

But holding on too loosely can have a similar effect.  If a team feels that their leader can’t make decisions or is wishy-washy, then they feel adrift and unsure.  No one likes a ship captain who doesn’t know where the ship should be going.  And a ship that is headed nowhere will surely get there.  Not making any decisions is no better than making all the decisions.

The trick or course, is to hold with just the right amount of pressure.  Good leaders find that perfect balance between control and chaos.  They let their team decide how to accomplish tasks within general guidelines.  They encourage improvisation and innovation in a search for better ways of doing things.  They know that there are some things that need to be done a certain way, but that there are many things that don’t.  They trust their team to get things done their own way. They know that if a team member gets credit, it reflects positively on their leadership. 

In general, they hold just tightly enough to keep things in control.  They let team members make decisions.  They recognize that mistakes will be made and that daring to do something different is a feature, not a bug.  They make decisions when the team needs a decision, and they delegate decisions as much as possible.  They recognize that they have a tendency to “squeeze to tightly” and thus, when in doubt, tend to err on the side of holding too loosely.  They understand that autonomy and self-direction are very satisfying, and do everything they can to provide that to their team. 

Just as a good veterinarian knows how to hold a bird with the right amount of pressure, a good leader knows the precise amount of control to exert over his team.

Blast from the Past: Developers and Economics

By Nick at December 04, 2012 20:45
Filed Under: Software Development, Delphi

Here's another article from my series at CodeFez -- and here's the response that Steve Teixeira wrote to it.  The comments on both are a pretty interesting discussion.

I never cease to be amazed at how little the average developer knows about economics. I mean, I don't claim to be an expert, but I have taken a college class or two and read up on the basics. Even just understanding the basics, though, gives one surprising insight into why things happen the way they do in the marketplace.

For instance, we are in the process of hiring a new developer at my company. We figured out what qualifications we were looking for and determined about how much salary we wanted to pay. It quickly become apparent, however, that we weren't offering a high enough salary to attract the caliber of candidates we wanted. So what I did was to go on the newsgroups and start whining about not being able to find any good Delphi programmers. Okay, no, I didn't really do that. What we did, of course, was to increase the salary that we were offering. Simple supply and demand issue: There wasn't enough of a supply of good Delphi programmers at the price we wanted to pay, so the solution is to be willing to pay more – a no-brainer decision, really. Once we did that, we found that we have been able to find plenty of valuable candidates. Simple economics.

One common area that I see developers totally misunderstand is that of Delphi pricing. One thing you learn in Economics 101 is that the vast majority of companies are “price searchers”. That is, they are constantly searching for a price that will maximize their profits. (Some companies, mainly producers of commodities, are “price takers”. That is, they take whatever price is offered. Farmers are a good example. A corn farmer can only sell his corn at market price. If he asks for more, the market will simply buy corn from another farmer that will take the offered price). Borland is definitely a price searcher. They can set their prices as they please, and will do so to maximize profit. Of course, the market will respond to any particular price by demanding a certain number of units at that price. Price searchers are constantly adjusting prices to maximize the amount of money they make.

Note that they don't set price to maximize revenue, but rather profit. The cost of goods sold is a factor here as is the cost of simply having customers. Sometimes a company will actually price a product in order to limit the number of customers they have in order to maximize profits as sometimes having additional customers causes decreased profits. (That may be a bit counter-intuitive, but think of a product that has high production and support costs.) So for example, sometimes doubling your price can increase profits even though it drastically reduces sales. If doubling the price cuts the number of customers you have in half, but also cuts your production and support costs in half as well, your profit increases. (This is a very simple example, and it is actually hopelessly more complicated than that, but you hopefully get the basic idea).

So Borland, having learned from years of experience and copious sales data, is quite aware of what effect various prices have on sales. No doubt by now they have a pretty good idea what price will maximize their profits and how price changes will effect sales.

Where it gets really interesting is pricing outside of the United States. Europe, of example, is a completely different market than the US. Taxes, the demand curve, and the number of potential customers are all different. Borland clearly believes that they need to – and can – charge more in Europe than in the US. The price difference is not related to the exchange rate between the Euro and the Dollar; it has everything to do with maximizing profits. Clearly Borland believes that a higher price in Europe – again, a completely different market – will mean higher profits. That's why Delphi costs more in Europe. I suppose Europeans could view this as “price gouging”, but in reality, it's just the market signaling to Borland that it will bear a higher price than will the American market. Simple economics.

Another economic blunder that developers frequently make is ignoring economies of scale. Borland is a big company that is publicly traded. Many Delphi developers work in small, private companies. Borland has legal obligations, overhead costs, and market demands that most little-shop developers don't even know about, much less take into consideration. Borland's main competition is one of the largest corporations in the world. Borland faces investors who expect a return. Borland has to deal with major entities in the media that can write things that can have profound effects on Borland's business. All of this combines to make running Borland a complex and difficult task that most of us simply don't comprehend.

So I love it when a developer posts in the newsgroups something like this: “Borland should just hire two college students to go through and fix all the Delphi bugs in Quality Central.” Well, that sounds great, but is clearly isn't that simple. First, fixing bugs in a big product like Delphi is no small, trivial task. Finding people with the talent and skill to do Delphi bug-fixing isn't easy. And they certainly aren't going to be cheap. The notion that some college interns can do it is quite naïve. The economic blunder comes, though, in thinking that the cost of fixing all those bugs is merely the salary of a couple of developers. First, employees aren't cheap, no matter who you hire. Human capital is by far the most costly – and valuable – part of doing business. Secondly, I don't know what your development process is like, but bug fixing at Borland is more than a guy hacking out some code. Every fix has to be extensively tested for efficacy and correctness, and then the whole product has to be regression tested to ensure that any given fix doesn't actually break something else. Fixes need to be incorporated into shipping product and distributed to existing customers. The documentation needs to be updated. And who know what else needs to be done? The point is this: the costs of things that many people think are small are in fact much larger than the average developer appears to realize.

The economics of running a business like Borland isn't something about which I claim to be an expert. But I do know that I don't know enough to be able to claim to know better than Borland. Something to consider before you fire off a post in the newsgroups that starts out “Borland ought to just....”

Blast from the Past: My Plans for DevCo

By Nick at December 03, 2012 19:30
Filed Under: Delphi, Blast from the Past

Now here is a true Blast from the Past from March 8, 2006 during the early days of "DevCo".  This one ought to provoke some discussion.  What of this list has actually come to pass? 

Joe Mele tossed his name out there as the potential CEO of DevCo.  Well, I'll throw my hat in the ring as well.  And not only that, I'm here and now putting out my official plan of action for my reign as the leader of the premier development tools company.

My plan is divided into three different courses of action:  What I'd do immediately, what I'd look into doing, and wild-ass ideas.

Here's what I'd do for sure right away, no questions asked:

  • Put a full page ad in every issue of SDTimes -- I've asked about this before.  I can't understand why Borland hasn't been doing this all along.
  • Put the help in a Moderated Wiki -- As I understand it, this is in the works,  but it really needs to happen.  We all together can build a better help file than the Delphi Docs Team.  No offense to them, but it's a big job.
  • Release a "Delphi for .Net SDK". -- This totally needs to happen.  The lack of a public compiler is killing the third-party Delphi market.  Just killing it. 
  • Double, no Triple, no QUADRUPLE the budget for what is now BDN -- BDN will be even more important to DevCo.  It's totally underfunded now. As the CEO of DevCo, I'd fix this right away.
  • Double, no Triple, no QUADRUPLE the size of the documentation team. -- Somebody is going to have to manage all this inputs that we community members put into the Help Wiki.
  • Provide a competitive upgrade price from any other development tool -- How are you going to woo VB6 developers without a competitive upgrade?
  • Give every person in the company, all the way down to the cleaning crew, a copy of The ClueTrain Manifesto -- Oh man, this really, really, really needs to happen.  Could there be a company that was less ClueTrain-ish that Borland?
  • Plan, and announce as soon as possible, the new, improved, exciting DevCon -- Get the faithful together as soon as possible.

These are the things I'd look in to doing.  I wouldn't necessary do them, but I'd throw them out there and look seriously at them:

  • Find a way to aggressively pursue VB6 developers -- The field is still rich for the sowing. How can we get to these guys?
  • Look into the right way to release a Standard/Personal/Free version of Delphi - This is hard.  Sell a low end version, and people buy it instead of the more expensive versions.  Don't have a low end, and you don't get students, hobbyists, and other new folks on board.  There has to be a way to solve this.
  • Look into instituting a subscription selling model -- Smooth out the development cycle and the revenues.
  • Sell licenses (not boxes, just licenses) of any version of Delphi -- There are folks out there using older versions of Delphi, and DevCo should make it easy to expand the size of their development team.  Or, put another way, if people want to buy something you have, sell it to them.
  • Revitalize and release NDatastore -- This product would simply rock, and the entire .Net development world would buy it, not just Delphi users.
  • Open up "DevCo Press", using on-demand printing technology -- On-Demand printing will keep costs way down, make keeping multiple titles available, and allow for more esoteric topics to be available. 
  • Institute an Affiliate program, allowing people to sell Delphi from their websites -- the more folks selling and promoting Delphi the better. 
  • Look at harnessing the power of the community
    • Club DevCo -- figure out ways for folks to earn points by being good community members.  Points can earn free stuff.
    • Free marketing materials to anyone who asks -- put together a package the ordinary folks can use to promote Delphi.  Give it to anyone who asks.
    • Free bumper stickers and other swag -- get the word out ASAP.
  • Look into buying/merging with/closely partnering with FinalBuilder, AutomatedQA, Altova, Modelmaker and Castalia -- These folks make products that Delphi developers want.
  • Add syntax highlighters for Ruby and Python for starters -- These to languages are just getting too popular to ignore
  • Release a VS.NET version of ECO - ECO is awesome technology.  Consider letting the VS.NET guys in on it.  They'll pay.  ;-)

Here are a few ideas that are really out there, but worth at least thinking about:

  • Integrating a VB6 personality into BDS -- why not?  That would be one way to get them involved.
  • Create a personality for Javascript/AJAX development -- This is getting hotter and hotter everyday.  Someone will do this first.  It ought to be DevCo.
  • Add a personality for Python and/or Ruby -- Do this after the AJAX personality.

Just a few thoughts for the new CEO, whoever it ends up being.  Smile

Blast From the Past: Stuff that Bugs Me

By Nick at November 30, 2012 08:03
Filed Under: General, Blast from the Past, Delphi

I don't know what I ate on April 1, 2006, but apparently it didn't sit well.

  1. Message boxes that ask a Yes/No question, but give you Ok/Cancel buttons.   I mean, come on. If you are asking a "Yes or No" question, how tough is it to tell the dialog to have Yes and No buttons? Not tough at all, that's how tough it is.
  2. Ok buttons that are enabled when a dialog is not properly filled in.   This is basic User Interface design. If pushing a button will result in an error message, don't let the user push the button.
  3. Non-sizable dialogs.  Argh. This one drives me nuts. It's especially galling when there's a list box or something that is so small you feel like you are looking at it through a straw.
  4. Dialogs that don't remember their size and position. Related to the previous item. Sometimes a dialog is too small, and when I size it, I want it to stay sized. Sometimes it blocks stuff I want to see. It should stay where I put it, not where the developer thinks it should go.
  5. Windows that insist on putting themselves in front when I am doing something else. This is absolutely, unequivocally the most irritating thing about Windows. It bugs me more and more each day.  I decide what I am looking at, not some shareware programmer from Wisconsin. If I am typing or otherwise working in a Window, no other application should ever be able to steal the focus, unless it's warning me that my house is on fire or something equally serious. 
  6. File directory trees the size of postage stamps. Related to the issue above. Ever get one of those slightly older applications that won't let you size the directory lookup tree? With ever expanding hard drives and increasingly complex file directory structures, looking at your hard drive through a fixed size treeview that's only 150 pixels square feels like being shoved in the trunk of a Yugo.
  7. Crappy error messages, especially when they are sentences and don't end in a period. "List index out of bounds". Great -- which list? The name or even type of the list is known. Tell us! "Error 332322". This isn't a problem because I have, of course, memorized all the error codes for your application. What's wrong with "In the DoSomething method, the length of the input from the name edit box is too short.  It needs to be at least five characters."  Feel free to write a novel in your error messages. Believe me, no one will complain.
  8. CAPSLOCK keys. The person who thought putting the CAPSLOCK key above the SHIFT key and right below the TAB key should be rubbed vigorously with rough sandpaper and then placed in a bathtub full of lemon juice.
  9. Unnecessary modal dialog boxes that I have to click when it doesn't make any difference. I love these. "You've done something really stupid. Press Ok to continue". Great. Thanks. I couldn't have made it through the day without that totally, utterly meaningless and pointless message.
  10. Dialog boxes that have the negative answer on the left and the positive answer on the right. OK buttons go on the left. Cancel buttons go on the right. Don't put the Delete button on the left and the Approve button on the right. It's a gross violation of the laws of nature.

Blast from the Past: Why You Should Choose Delphi

By Nick at November 29, 2012 09:01
Filed Under: Delphi, Blast from the Past

Another classic for the Blast from the Past file, this time from CodeFez on November 27, 2004.  Eight years is a long time for Delphi to be dying.  Winking smile

 

People are always asking “Why would I use Delphi when I can use C#? Why would I go with Borland's tool when Visual Studio and clearly closed the gap?” I think that is totally the wrong question to ask. The real question is “Why should I be using C# when I could be using Delphi?”. Here's some of the reasons why the latter is the real question to be asking:

    Delphi is easier to read. Delphi thankfully isn't a C-language descendant and so it doesn't use the ugly, horrible to read C-like syntax of say C# or Java. It uses easy to read works like 'begin' and 'end' instead of hard to read symbols like '{' and '}'. It uses a readable, sensible syntax in 'for' loops. It requires that you declare variables before you use them, ensuring that the definition and type of variables are easy to determine. It forces you to declare classes and routines in the interface section of a unit, making for much easier analysis of already written code.

    You already know Delphi – if you are currently a Delphi developer, Delphi has you covered in .Net. There isn't a single thing that can be done by other tools in .Net that you can't do in Delphi.

    Delphi has better data access. The BDP – Borland Data Provider -- provides a much cleaner and well designed interface to ADO.NET than the FCL does. The FCL doesn't provide enough abstraction over ADO.NET to even provide a single set of components to access data with ADO.NET. Access to Oracle and SQL Server require completely different sets of components and types, making providing a single-source, common front end to data impossible. The BDP, on the other hand provides that single interface, even provides components that allow you to mix data from differing databases into a single dataset. Other languages and tools don't even pretend to provide this advantage.

    Delphi is cross-platform. Delphi code can be cross-platform between .Net and Win32. Code bases can, with a bit of work, even be used in those two platforms plusLinux. Delphi is the only .Net language that provides that level of compatibility between Win32 and .Net.

    Delphi can expose .Net functionality without COM/Interop – this is an unsung feature of Delphi. Want your Win32 applications to have access to encryption? Regular expressions? Anything else in the FCL? Delphi can provide it without COM.

    Delphi can link .Net code into your EXE – Delphi provides the ability to link code into a single EXE instead of having to worry about deploying all the right assemblies in all the right places.

    Delphi handles and names events the right way. Is there anything more confusing in the .Net framework that delegates and how they are used to handle events? No, there isn't. Delphi handles this all the right way, hiding the silly, confusing way .Net does it. Instead of the confusing C# syntax, Delphi uses the model that has been proven for over ten years. Need to add an event to a component? Delphi does it clearly and simply – like it does everything.

    Delphi does IDisposable correctly. -- Only slightly less confusing than delegates is the concept of IDisposable. Do I call Dispose? Do I need to? How do I know? As long as you follow the time-test method of calling Free on any object you create that doesn't have an owner, you'll be fine in .Net. If Dispose needs to be called, Delphi will call it. If not, it won't. No more guesswork, and your code will even be compatible on the Win32 side of things.

    Delphi has been doing “Avalon” for ten years. The hot new thing over at MS is “Avalon”. Avalon is a system for storing properties and information about forms and objects in a text file separate from the silly InitializeComponents call in your code. Sound familiar? Yeah, thought so. (Side note: Partial classes crack me up. Only Microsoft could invent a “feature” solely for the purpose of making up for a gross shortcoming in their language.)

    Delphi has datamodules. Is there a bigger oversight in all of the FCL than the lack of a datamodule-like class? Sure, you can 'simulate' datamodules, but it's a poor simulation at best. Put your database controls in a datamodule, and add the datamodule's unit to your uses clause and the Object Inspector is smart enough to see the components in the datamodule when looking at another form or whatever. Datamodules let you decouple data access and other abstract concepts from the user interface of your application. In other words, datamodules rock, and other tools and don't have them.

    Delphi's third-party market is way more mature than the .Net market in general. Sure, there are tons of components out there in the .Net market. But Delphi component builders have been at this for a decade, and have the years of experience needed to build excellent components the right way. Are you going to try to tell me that Ray Konopka and the DevExpress folks don't have it all over the johnny-come-lately folks that have been building components for a year or two?

    ECO II – Delphi has a mature, existing, shipping model driven architecture that is written by people who truly understand object-oriented programming. Microsoft doesn't. They have some thoughts and ideas outlined on a web-site somewhere and promises of functionality that they don't even really understand yet. Delphi is light-years ahead in this area, and there is no reason to believe that they won't stay that way.

    Borland's ALM solutions are here now, not “in the vaporware pipeline”.Microsoft is touting Team System or whatever they are calling it. Sounds great and all, but of course Borland is selling that technology right now, not just talking about it..

And that is just scratching the surface.  You'll probably add even more reasons right here in the comments. Personally, I can't understand why anyone would ever choose C# or VB.NET over Delphi.

How about you?

Blast from the Past: Delphi Books and the Publishing Market

By Nick at November 27, 2012 11:21
Filed Under: Delphi, TechBiz

Yet another Blast from the Past.  This one was originally posted on May 2, 2006 and is another one that holds true six and a half years later.   It's fun to note that the number of Delphi books out there appears to be increasing as it becomes easier to publish and the bookstore becomes practically the last place you'll go to get a Delphi book.

I'm nearing the end of a pretty big project at a client very near our office.  I've been going in ever day full-time for the past few months.  I've really enjoyed working there, as the folks are nice, the development process is very professional and quite good, and the camaraderie quite enjoyable.

Now that the project is winding down, I've had a chance to actually do a bit more visiting and kibitzing with the folks there about general topics concerning development (plus various forays into the Civil War, American Idol, etc.)  The topic of Delphi books came up, and one of the guys, Randy, made a good point.  He noted that the reason that there aren't that many Delphi books out there is that there doesn't need to be that many good Delphi books out there.

The books that are out there are complete, comprehensive, and well done.  For instance, there are really two books out there right now for Delphi:  Delphi for .NET Developer's Guide by Xavier Pacheco, and Mastering Borland Delphi 2005 by Marco Cantu. Once you've bought one (or both) of these books, you've got pretty much everything you need.  Xavier's book covers pretty much everything you need to develop in Delphi for .Net, and Marco's book covers both .Net and Win32 development.  If you have Marco's book, for instance, you really don't need any other books.

Another factor in limiting the market for Delphi books is that Delphi is a mature product.  It's users are to a large degree familiar with the language and the tool, and thus the demand for books that cover the basics is limited.  There just aren't that many folks out there that need to buy a book about Delphi anymore.  (Now, we can argue that we all need to figure out a way to increase the number of folks that want to buy books, but that is another blog post.) And since there are so many facets to Delphi, any book on an advanced topic would be of limited interest.  And for topics like ASP.NET, there are so many C#/VB.NET based books out there, the content of which is 99.9% useful to a Delphi developer, that there's little reason for a publisher to go to the effort of putting out, say, an "ASP.NET for Delphi Developers" book -- as much as I'd like to see such a thing.

In addition, the presence of resources like http://groups.google.com makes finding answers to questions and problems easy.  It's a rare day indeed when I can find an answer to a question using the newsgroup archives.  This is an invaluable resource, when you stop to think about it.  Shoot, just Peter Below's responses alone are worth their weight in gold.  Smile  It might very well be that the excellent support received in the newsgroups has limited the market for Delphi books as well.

The bottom line, it seems to me, is that there aren't that many Delphi books out there because we just don't need that many Delphi books.

So what is the future of Delphi books?  I think it's with something like lulu.com.  Lulu.com couldn't be easier -- you send them a PDF, and then they'll print out a real book whenever someone pays for one.  No muss, no fuss.  Basically you are 100% in charge of the PDF, and you get 80% of the selling price. Someone like Ray Konopka, who sells his class Delphi Component Development book online as a PDF, would be perfect for something like this.  You want to publish your own Delphi book?  There you go.  The size of the audience matters not.  You want to buy a book?  Encourage authors to use a service like Lulu.com to publish their materials.  Heck, publish one yourself.  The overhead costs seem quite small, and overall, it seems pathetically smart and simple.

I suspect that services like lulu.com will florish and only get better and cheaper.  The stack of Delphi books at your local Borders (weird -- that link basicall goes to amazon.com...) might not be that tall, but the amount of information available to Delphi developers is still staggering.  I've never been a big believer in the "books on the shelf equals market strength" theory -- at least in the sense that I think Delphi's market strength is much, much stronger than one might conclude from a trip to Barnes & Noble.  Delphi book publishing need not be dead, it just needs to shift to a new way of doing business.

Blast from the Past: Takes One to Know One

By Nick at November 25, 2012 22:15
Filed Under: Delphi, Leadership, Software Development, TechBiz

This one is a Blast from the Past -- I originally wrote and posted it on December 15, 2005 -- but it is as true today as it was then.  I even considered palming it off as fresh material. Smile

It's a standard Dilbert joke that managers are idiots.  One doesn't have to hang around programmers too long to find out that many of them work for managers that don't have a clue about developing software and thus make many a nutty decision based on profound ignorance.  Plenty of  Delphi fans have had a boss that follows the "Nobody ever got fired for choosing Microsoft Development tools" rule and choose Visual Basic as a corporate standard. <shudder>  And the old adage states that programmers make crappy managers.

So, I guess, based on the above, it's impossible for someone to be a good manager of programmers.  If one doesn't know anything about programming and has never been a programmer, then apparently, he will suck as a manager.  And if one has been a programmer, and is so good at it that he gets promoted to be a manager, he,too, will suck as a manager.  Sounds like a lose/lose situation all around --   programmers doomed to a life of sucky supervisors.

Well, I'm not buying it.  Surely somewhere, somebody is managing programmers well.  Somebody has to be leading folks to build some of the insanely good software projects that are going on out there.  So, what does it take to manage programmers well?  Good question.  I'd say that such skills and capabilities exist.  I'd also say that they are, sadly, in relatively short supply.  Too many Dilbert strips end up on too many cubicles in software development shops.

First, to be a good manager of programmers you have to be,well, a good manager.  That's easier than people think, really.  Here's my basic list of things one can do and not do to be a good manager:

  • Place the careers of the people that work for you above your own.  Never, ever, ever, ever, ever take a dump on an employee to make yourself look good to your boss.  Always let the boss take a dump on you instead of your employee. Take responsibility for everything bad that happens under your watch.  Dole out all the credit for good things that happen to your people.  If you have some bizarre, overwhelming need to impress and brown-nose your boss, let your employees make you look good.  It's your job to make your employees happy and productive.  It's not your job to get promoted.  (And do I need to say that if your employees are happy and motivated, then they'll do a good job, which means you are doing a good job?)
  • Place the needs of the employees over your own.  What's the quickest way for a Marine Corps officer to be considered the biggest jerk since Josef Stalin? Get in the chow line ahead of his Marines.  Officers don't eat until the troops do.  Take the same attitude, and your people will love you and work hard for you.  Give them the good computers.  Give them the good chairs.  Don't take a perk for yourself until they all have it.  Believe me -- they will notice this.  Another way to state this is don't ask your employees to do anything you yourself aren't willing to do. If you want your folks to work 12 hours a day, you need to be there 13 hours a day.
  • Recognize that your employees know what they are talking about and might actually know more about some things than you do.  (If they don't know what they are talking about and they don't know more about some things than you do,  then you need to get new employees).  If your employees seem to think that the WonderWidget is a much better solution to a problem than the SuperSprocket, then, hey,  maybe, just maybe, they are right.  Just because you read about the SuperSprocket in some magazine that takes $4.6 million dollars a year in advertising from SuperSprocket, Inc., doesn't mean that is the way to go. 
  • As a follow on to that, don't try to impress your employees with your knowledge.  Don't spout buzzwords unless you know what they mean. They probably are going to think that you are an idiot anyway, so feel free to appear to be ignorant about things that, well, you are ignorant about.  If you don't have a clue about what the best printer is for the needs of your team, then let the folks on your team that do know about such things choose the printer.  If you don't know the answer to something, say so.  The quickest way to be thought an idiot is to try to act like you know what you are talking about when you don't.
  • Manage yourself out of  a job.  The best managers are the ones that sit in their office all day surfing the internet because they've set things up so that their people can take care of everything and thus they don't have anything to do.  People love being the ones with the power, authority and skill to do the work. If you are in their shorts all day, making all the decisions, doing all the work, and taking all the credit, you will be a crappy manager.  Once you've managed yourself out of a job, then, besides surfing the net, you can spend all your time making things even better for your employees and protecting them from the foibles of your boss. 
  • Encourage your employees to tell you what is bugging them.  When I was running a 24/7 Intelligence Watch, I told my people that if they found a Dilbert cartoon that exactly described a stupid, irritating, or aggravating situation in our organization or something that I was doing that was "pointy-haired-boss-ish", they could bring it to me or put it on my desk anonymously.  If you are totally committed to the first two items on this list, they will come to you. If you aren't, they never will.  And if your employees aren't bringing issues and complaints and problems to you, then you have a big problem.
  • Reward your employees with what they want to be rewarded with.  Frankly, this is usually good old cash money. But if you can't do that,  perhaps they want better computers, a nicer desk chair, a day off, whatever.  If you want to reward someone, find out what they want and give it to them.  But please, PLEASE -- I'm begging you here -- do not call a big meeting and pass out a "Worker of the Week" award with some cheesy certificate ginned up with Microsoft Publisher.  When I was in the Navy and at a joint command, I had an Air Force Colonel that did this, and he was universally mocked and reviled for it. Everyone thought it was a joke.  No one wanted that silly certificate and everyone hoped and prayed that they wouldn't "win" the thing.  Those that did posted them like they post Dilbert cartoons on their cubicles -- sort of like a badge of "dishonor".

Now, that's all general stuff.  It applies to all managers, whether they lead a team of auto workers or a group of Delphi programmers.  What does it take to manage programmers well?

  • I think that to be a good manager of programmers, you have to be, or at least have been, a programmer yourself.  This goes against the conventional wisdom, I know, but I think that in order to understand the way programmers work, you really have to have done it yourself.  It's true that many programmers would make bad managers, but it doesn't follow that every programmer guarantees that one will be a bad manager.  Programming is one of those strange professions that mixes right- and left-brained skills.  To program well, you have to have an ordered, mathematically oriented mind, but at the same time you have to come up with artistic, creative solutions to puzzles and problems.  One really needs to be one to understand one.  Now the hard part here is that most programmers don't want to be managers. Alas -- a quandry there, eh?  Well, if you run across one thatdoes, don't hesitate to consider it.  If you are a programmer and want to be a manager, let your bosses know, they'll probably be happy to hear it.
  • Give programmers what they want:  challenging work, a quite place to do that work, a good fast computer, a good salary, and the opportunity to expand their skillset.  Don't be cheap on these things.  This may cost a bit more,but you'll make it back in spades.
  • To as large a degree as possible, let programmers choose the tools that they use.  I know, I know, this isn't always possible.  Sometimes those decisions are made above your pay grade.  But then again, if you use Delphi under the table to produce a solution twice as fast for half the cost, then maybe Delphi won't be under the table for long.  If one of your guys wants to try to build that new intranet application in Ruby On Rails, let him.  Why not? Who's going to know?  If it works and gets deployed early, it's likely that no one will care what tool or language was used to make it, and now you have a new skill in your quiver.
  • Be flexible.  Some programmers do their best work between 10:00pm and 04:00am.  Let them.  Some hate to wear ties, dress shirts, khakis, etc.  Don't make them.  Some are flat out nuts.  Let them be.  Nothing wrong with all of that as long as they produce good code, eh?

Okay, that's a pretty good list.  I've been on both sides of the fence, and as a consultant, I see all sorts of management types and methods.  I deal with programmers on a daily basis, and I are one myself, so I think I have a pretty good grip on what's going on from a lot of angles.  I'm sure you all will come up with more stuff and comment on it.  Please do.  After all, I'm not an expert on this stuff and I only write this to try to make you look good.  ;-)

Flotsam and Jetsam #70

By Nick at November 23, 2012 21:16
Filed Under: Flotsam and Jetsam, Delphi
  • Looks like Bjarne Stroustrup himself will be part of the C++ portion of CodeRage7.  That's quite a coup.
  • LeanTed now has its own URL:  http://www.leanted.com
  • Anyone out there know about TSynEdit?  Which is the "one true version" that I should be using?  I'm using this one:  http://sourceforge.net/apps/mediawiki/synedit/index.php?title=SynEdit_Home_Page but it seems like there are/might be other better/different versions out there.  Anyone have any advice or thoughts on the matter? Also, anyone know about what encoding it uses?  Can I change/set it? I confess I can't seem to figure that out....
  • Delphi is really popular in Brazil, and Roberto Schneiders is a new blogger from that lovely country.  He's written his first post about DataSnap.  Nice.
  • Cloud storage certainly is all the rage. As far as I can tell, I have storage in the following places: DropBox, BitCasa, Google Drive, SkyDrive, Asus Cloud Storage, and Amazon.  And probably some others I can't even remember.  Here's a business idea that I'm sure has already been done because I just thought of it:  Create an app that aggregates all those different chunks of space into a single drive.  That would be cool.
  • Everyone seems worried about Best Buy -- apparently they are all doomed and everything in the face of Amazon -- but I can tell you they didn't look doomed last night at midnight.  I was awake and decided to attend their Black Friday event at my local store, which started at midnight. (I had not intention of, and did not, buy anything...) The place was an absolute mad-house.  There was a *huge* line to get in when I arrive right at 12:00a, and they had a large maze set up in the store to keep people moving in the same direction.  I didn't notice any outrageous deals, but I can tell you that a lot of merchandise was available and a lot of it went out the door.  Plus it was fun -- great people watching.

Blast from the Past: Delphi may be the only choice you have

By Nick at November 22, 2012 10:08
Filed Under: Delphi, Software Development

Yet Another Blast  from the Past, this one from November 23, 2003.  This one is kind of moot now, as well, eh?

As frustrating as it is to us Delphi lovers, Delphi has always been a tough sell in corporate America -- not because Delphi isn't perfectly capable of performing any task that a corporate development team might throw at it, but mainly because many managers and decision makers aren't willing to take the perceived risk of investing in a non-Microsoft development solution. Borland has (rightly perhaps for a while in the past, but certainly not for a few years now) the reputation as being a bit on the edge financially, and so the safe, "nobody ever got fired..." decision has been to buy Microsoft. This will probably continue to be the case for some time, as Microsoft certainly will continue to be the a dominant company in the marketplace for the foreseeable future. However, I think the advent of the .Net Framework as the "platform of the future" and Microsoft's particular strategy for moving people to .Net both provide Borland and Delphi developers with a unique opportunity that actually makes Delphi the only safe development platform for a large number of projects that will be developed over the next few years.

Microsoft clearly wants us all to move to .Net, and frankly, I think we all should be happy to make that move. The .Net platform is really cool and really powerful. It provides a very capable and easily accessed framework (the Framework Class Library, or FCL) that is light-years ahead of the Win32 API. Microsoft actually seems to have finally figured out object-oriented programming. Once the actual framework becomes ubiquitous, or even the basis for the operating system itself , building, managing, and deploying applications will be much easier than it is now. I, for one, am eagerly looking forward to Delphi 8 for the .Net Framework and being able to develop applications with it.

Microsoft clearly wants you to move to the platform as well. They make it totally easy to download and install; every new operating system includes it, and they are on an all-out marketing campaign to raise awareness in the developer community in order to promote its use among software developers. The most interesting thing about all of their actions, though, is that they clearly want to force people to make the jump to .Net by pretty much cutting off existing development paths and by not providing a clear migration path for existing applications. It appears that the idea is to instill a bit of panic in their community of developers -- "Holy cow, we'd better get on this .Net bandwagon, or we are going to be left behind!"

Sadly, that is pretty much the case -- VB and C++ developers who don't migrate to .Net soon will be (are?) pretty much abandoned. Sure, there's "Managed C++", but what serious C++ developer would really want to use this neutered version of the language? VB6 developers are abandoned in the sense that VB.NET is so different from what they have done that it is pretty much a whole new language. Code written for VB6 simply won't compile in .Net. And of course, there were no existing C# projects before .Net was released. Therefore, if you are a Microsoft development shop, and you want to move to .Net, then you are pretty much talking about a complete rewrite of all of your Win32 code no matter what you were using to develop those applications. There simply is no easy migration path to .Net for your existing applications.

And that, of course, begs the question -- "What to do for a new application that needs to run on Win32 today, but that will eventually migrate to .Net sometime in the future?" This isn't an unreasonable question -- shoot, it is probably very common. There are certainly new development projects being started everyday, and .Net looms out on the horizon for all of them. It is also a question that is tough for Microsoft shops to answer. While the .Net Framework is readily available, it is certainly not ubiquitous, and there are plenty of machines out there in the corporate world, small businesses, and homes that can't even handle the .Net Framework and that won't be able to handle it for sometime yet. That means that Win32 may be the only option for new development. However, anyone starting new development today probably will want to be able to migrate that app to the .Net platform in the future. If you choose C++ or VB6 for the Win32 version, there simply is no easy way to migrate that application to .Net. Any Microsoft-based development solution for the Win32 platform today means pretty much a complete re-write for that application when it comes time to migrate it to .Net.

But hey, there is a solution -- a non-Microsoft one -- to this problem: Delphi. Delphi provides a powerful, fully-capable Win32 development platform, and with the VCL for .Net, a much, much smoother migration path for Win32 to .Net. And when you do move to .Net, Delphi 8 for the .Net Framework provides powerful tool that is a first class citizen in the .Net development world. If you are starting a new development project in Win32, and need to be able to move that project to the .Net framework some time in the future, then Delphi is your only real choice. Microsoft-only development organizations quite conspicuously have no similar choice. The VCL is cross-platform -- at least between Win32 and .Net. Applications build in Win32 using Delphi and the VCL should migrate relatively smoothly to the .Net platform today . VCL for .Net exists, and has been available to Delphi 7 owners via the Delphi for .Net Preview since last summer.

Now I am not at all claiming that the migration will be totally seamless -- you may need .Net version of third-party components, and if any of your code calls into the Win32 API directly, you'll need to update that. In addition, not all of the technologies that were in Delphi 7 will make it into Delphi 8, and certainly the presence of garbage collection in the .Net framework may affect the way your code works, but the migration is clearly not a complete rewrite as discussed above. Heck, at this year's Borland Conference, they compiled and ran in Delphi for .Net an application that was originally a demonstration application for Delphi 1 -- a 16-bit development tool! Can't get much more compatible than that.

This fact alone ought to be changing the way that developers and companies view Delphi. Delphi will drastically lower the overall total cost of a project by drastically reducing the time and effort needed to migrate a Win32 application that needs to be built today to the .Net framework tomorrow. Delphi doesn't lock you in to either Win32 or .Net and doesn't force you to move to .Net faster than you or your budget might want you to. Delaying the transition to .Net can also save money, as building applications in Win32 now for existing hardware can extend the life of that hardware rather than accelerating the hardware upgrades to run the .Net Framework.

Smart managers already know that they are stuck in a tough spot and smart Delphi developers will be quick to point out the advantages of using Delphi for new development. So if you have been looking for that silver bullet to convince your managers or your customers to use Delphi as the development tool for that upcoming project, you now have it.

Permalink|No Comments Yet|Login at the right or register with the site to add a comment.

Flotsam and Jetsam #69

By Nick at November 21, 2012 19:42
Filed Under: Flotsam and Jetsam, Delphi
  • I went to Philly Code Camp 2012.2 this past weekend.  It was a valuable use of time.  I learned a lot about Javascript (it has some unusual scoping rules) and ferreting out information about changes in databases (outer joins between old and new data can be revealing....).  In addition, I learned about a really cool add-in for most of the popular text editors called Zen Coding. It's pretty slick.  It makes writing HTML and CSS much easier.  For instance, type this:  html:5>head+body>div and then hit the hotkey for your editor and you get a nice template for an HTML five document, including the <head> and <body> tags, the DOCTYPE entry, and a <div> tag inside the body tag.  You can find out more about the extensive things you can do with it by watching this video, by reading this tutorial, and by looking at this cheat sheet.  Overall, another great code camp.
  • I completely forgot that I, along with Marc Hoffman, had the honor of being on .Net Rocks.  Cool!  It was great to see Carl and Richard at the .Net Rocks tour in Philly a couple of weeks ago.  They are really great, funny, smart guys, and they do a great job making development fun.
  • LeanTed now has basic support for table and crosslinks. The feature set is actually getting close to a 1.0 release.
  • All of the CodeRage 7 talks are online and available for viewing.  You can both download them and watch them on YouTube.  I like the YouTube part.  That's cool.
  • This video on MVVM and Delphi by Malcolm Groves of EMBT Australia is a must watch video.  This is how you should be building your applications from now on.  It's really made possible by Live Bindings.   You don't necessarily have to use the exact MVVM pattern than Malcolm shows here. He notes that an MVC or MVP pattern will do much the same thing, but we all really should be separating our concerns out so that we aren't coupling our code together. 

Blast from the Past: The Gaping Hole of Delphi

By Nick at November 21, 2012 07:56
Filed Under: Delphi, TechBiz

Another Blast from the Past. This one is mostly overtaken by events.  The sale of CodeGear makes the whole thing moot.  But I thought you might enjoy a trip down memory lane.  Things certainly have changed for the better.  This was originally published on January 6, 2006

 

Every situation, properly perceived, becomes an opportunity. ~ Helen Schucman

Yesterday I went on a sales call with two of the Borland sales reps for the region. Before hand, we met at a Dunn Brothers coffee shop to get our ducks in a row, talk about the client, etc. The meeting went well – the Borland guys are very knowledgeable, professional, and clearly know what they are doing and what they are talking about. The client could probably benefit from Borland's tools and hopefully there will be a deal done. I learned a lot about sales from the meeting. (Sales is not my strong point.)

The interesting part of the whole day was the epiphany I had while meeting with the Borland guys at the coffee shop. Sales guys are into revenue generating. They need to maximize the revenue that they get per hour of effort spent in getting revenue. That's their job. That's what Borland wants them to do, they are rewarded financially based on that, so naturally, that is what they do. I don't blame them. Opportunity costs are very real, and they have to choose where to expend their efforts.

If opportunity doesn't knock, build a door. ~ Milton Berle

The big thing I learned from the sales guys is that Delphi isn't even on their radar. They aren't given a commission on Delphi sales. That's frustrating. But here's the thing: even if they were given a commission on Delphi sales, I doubt very much that they'd sell much of it at all. Remember opportunity costs? Opportunity costs drive the salesmen to concentrate on the Fortune 100 to the Fortune 500 crowd, and the sad fact that we Delphi developers need to accept is that the market for Delphi amongst these large companies is very small. Those companies have probably already chosen their tools – either Java or Microsoft or some other open source solution – and while a concerted effort to sell Delphi into that market might work, the opportunity costs are just too high to make the effort worth it for a Borland Sales Representative. Delphi's traction is slim in that arena, but the traction for StarTeam, CaliberRM, and Together is very high. (Remember, it's all about revenue per man hour. Dollars per man-hour selling Delphi is pretty low. Dollars per man-hour for CaliberRM, StarTeam, and Together is pretty high. So, as a result, the Borland sales force doesn't sell Delphi and they do sell the enterprise products. This should not be a surprise.)

Let your hook always be cast; in the pool where you least expect it, there will be a fish. ~ Ovid

When we were at our TeamB conference in November, Boz Elloy basically said the same thing. He told us that “Fortune 100/500 companies don't want Delphi. It's a waste of time for us to try to sell it to them”. (My fellow TeamB'er Dave Nottage blogged about that meeting as well. For the record, Boz explicitly gave us permission to publicly discuss the meeting.) Boz drew a diagram with three levels: the “channel”, SMB, and Fortune 500. He basically said that they only try to sell Borland Core into the Fortune 500. (This is why you won't see Delphi having anything to do with Core. Core is Borland's Java platform, based on Eclipse, with perhaps some .Net mixed in, but only in the form of plug-ins to Visual Studio.Net) For the Small/Medium Business market, they offer Borland Developer Studio and the ALM solution. And the “channel” is sites like Programmer's Paradise that simply sell Delphi for Borland. For Borland, Delphi only really exists in the bottom two arenas. It simply doesn't exist in the highest bracket – but not to a level that would make the effort selling there worth it. (So, if you are a Delphi guy, and you hear stuff about “Borland Core”, just ignore it. I has nothing to do with you. Even though every fiber in your body screams out “Why isn't there anything about Delphi on the 'Core' pages!?!”, resist said temptation and simply let it all roll off your back. Core just isn't your deal. Now, when you hear “ALM”, your ears should definitely perk up, but Core? It's nothing to us Delphi guys. Let it go.)

Now, as I said, all this is very frustrating to a Delphi user. But if you step back for a minute, it makes perfect sense. Sales guys need to generate revenue, and so they spend their time doing that. Double the sales force won't alter this equation. It's purely a strange outcome resulting from the structure of Borland's product line. We Delphi dudes can bitch about this (and Lord knows we will), but the key thing is to get past the bitching, accept reality, and try to figure out a way to deal with this unfortunate situation.

In the middle of difficulty lies opportunity. ~ Albert Einstein

Okay, so I'm past the denial and anger stages (and I encourage all of you to get over the hump into acceptance as well), and ready to move on to trying to figure out what can be done to promote and expand Delphi. Every cloud has a silver lining. For every window that is closed, a door opens somewhere. In the middle of difficulty lies opportunity. (Someone stop me before I break my cliché meter). I really believe that there are any number of effective ways to market and sell Delphi given all of the limitations that we've already talked about.

The first thing to do is to examine the lay of the land. The thing that jumps out at me is this gaping hole that exists in the market. Delphi is sold almost exclusively in the channel. The folks that buy from the channel are, to a large degree, the little guys like us. We buy one, two, five copies for our development shop. If a medium-sized company wants to buy Delphi, they have to go to the channel as well. Unless they run into a Borland Partner that sells product, they won't get any personalized service. Delphi isn't sold into the Fortune 500 companies. But between the real little guys and the real big guys, there is this gaping hole where Delphi is useful and where lots of opportunities lay, but no one appears to be interested in taking advantage of these opportunities. These medium sized companies are ripe for the picking. I presume that many of them have modest development organizations. I presume that many are still evaluating .Net technologies. Many of them are using Visual Basic 6 – a product that has basically been abandoned by Microsoft. They know they need to make a move to newer technologies, but they aren't sure about it all. They aren't pleased with Microsoft, and would be willing to hear about products from a tools vendor that is almost compulsive about backwards compatibility and ensuring that old code can be moved forward. They might be interested in hearing about a company that is continuing to focus on RAD development in the Win32 space.

In addition, I also look out, and I see products flourishing that don't have any corporate backing (Think Ruby, Python, or Perl). These products are known and used, despite not being hawked by professional salesmen. How do they do it? They use the Internet. They use word of mouth. They use “guerilla marketing” techniques that cost very little and can reap large rewards. I see no reason why Delphi can't benefit in the same way.

Opportunities multiply as they are seized. ~ Sun Tzu

Here's an idea. Offer a free copy of Delphi Personal to any Visual Basic developer that will go on his blog and post a picture of himself holding a sign that says “I'm a VB developer and I want to try Delphi,” or witty variations thereon. If there is no Delphi Personal, send them a trial disk and a t-shirt. Something. Have them email their links to Borland so they can be posted on a webpage at www.borland.com. Get some buzz going on the VB community about Delphi – even if some of them get mad. Remind disgruntled VB developers that Borland has always and steadfastly promoted backwards compatibility and will never abandon them. The transition from VB 6 to Delphi isn't all that much harder than the transition from VB6 to VB.NET, so there has to be plenty of sales to be had in this arena. Give away a copy of Delphi Architect to the guy with the coolest, funniest, or most outrageous picture.

How about an affiliate program? If you click on the link in the upper right corner of this blog and buy a copy of FeedDemon, I get a kickback. Hence, I take every opportunity I can think of to mention the fact that if you click on this link and buy FeedDemon, I get a kickback. Good for me, good for FeedDemon. I'm also constantly hawking Amazon products as well. (Heck, I'd be a NetFlix affiliate, but they turned me down!) Now, wouldn't it be cool if we had a similar program for Delphi? Of course it would. You'd put a link on your blog, wouldn't you? Wouldn't you like to make a little cash selling the product that you love so much? Of course you would! Can you think of a reason why Borland shouldn't have such an affiliate program? I sure can't.

Finally, it would be great if, in addition to an affiliate program, it was fairly easy to become a value-added reseller (VAR) for Delphi. As a guy who's company tried to do this, I can tell you that it was really, really difficult to sell Borland products for Borland. We had to front the cash for all purchases, and deal with a maze of bureaucracy to get product delivered to customers. It sure would be nice if we simply had a vendor ID number that we could use to order product for our customers online. It sure would be nice if Borland recognized and knew the consultants that actively want to sell Borland products. It was way, way to hard for us to sell Borland products, and if it is one thing a company ought to do, is make it easy for your fanatical supporters to sell your products.

If a window of opportunity appears, don't pull down the shade. ~ Tom Peters

Delphi has a great opportunity to make a lot of traction in the current market. There is a big transition to .Net going on, and many, many organizations haven't yet made the move. Many, many organizations still want to do Win32 development, and Delphi is really the only path from Win32 to .Net, as well as the only RAD tool still actively supporting Win32. Opportunities are only valuable if they are seized, and as Sun Tzu noted, they multiply when they are seized.

The problem of course, is that Delphi is caught between two worlds. It's stuck somewhere in between the grassroots, individual developer market and the big money, big company enterprise market. Delphi's position inside Borland makes it a bit of a red-headed step child. I think the product needs more autonomy to thrive. (That's why the idea of Delphi being sold and becoming part of a separate company was pretty appealing to me.) Delphi's bright light all too often is left back in the garage, and it needs to be brought out and allowed to illuminate the marketplace. The mistake that Borland makes, I think, is in utterly ignoring this gaping hole. If you go to www.borland.com, the content will vary, but you'll almost always see information about Core and about items of interest to Enterprise-level decision makers. What you won't see is “Small/Medium Businesses Click Here” or something like that. There practically nothing there for them. If Delphi is going to be treated differently than the Core/Java offerings, then there at least ought to be a place on the Borland website where the people that Delphi/BDS/ALM is aimed towards can go and get information. Again, there's that gaping hole. The information may be there, but it isn't utterly obvious how to get to it.

Small opportunities are often the beginning of great enterprises. ~ Demosthenes

If there is one sure thing in the marketplace, it's that gaping holes will be filled with something by someone. Right now, it seems like that gaping hole left by Borland and Delphi is being filled by Visual Studio and Microsoft. Sure, Microsoft has a huge budget to market to these folks, but if ever in the history of free enterprise there was a time when you can go crazy and market a product with little or no cash, it's now. With the advent of the Internet and the shrinking world it creates, all bets are off. The opportunity is out there. What can Borland and the Delphi community do with it?

My Book

A Pithy Quote for You

"Never interrupt your enemy when he is making a mistake."    –  Napoleon Bonaparte

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.

Month List