TPersistent.com

If you’re a new developer and you’re wondering what development tool to adopt you have to decide what pond you want to play in. Don’t be suckered by the vendor offering free conferences, and trial development tools. Don’t “go with the flow” and choose the most popular tool because no one ever got fired for choosing it. If you do, it doesn’t say much for your critical thinking capabilities. You will be competeing with every Tom, Dick and Harry out there who is doing the exact same thing. There may be plenty of jobs, but the pay rates are driven down by the market. If you have mobility and travelling around the world appeals to you, then consider a small technology pond. One like Delphi, that is a pleasure to work with, and has a devoted following. Employers are finding it more difficult to acquire qualified staff, and are willing to offer more to good candidates and do more to retain them. You can work throughout the world for good rates, when going with a more mainstream technology, employers will choose local resources. It’s also becoming more common place to telecommute, if that is your goal.

Now don’t get me wrong, I am not saying bet your livelihood on a niche technology. I am saying position yourself with technologies (note the pluralization) so you can maximize the revenue generated from their use. That generally happens on the bleeding edge, and the twilight years. Talk to any Cobol developer about the kind of money you can make on a technology in it’s twilight years. Talk to any SAP consultant about the kind of money they make in a niche technology, and then ask your average .NET developer about the rates they get. Talk to any Objective C developer who made a fortune on the iPhone boom. Get the picture?

As a developer you should know at least two languages you can make a living with. This mitigates the risk of one of them being a niche technology, and protects you from shorter term market fluctuations. The exposure to different techniques also makes you a better developer. Today, choosing a mobile platform is likely as important as choosing a web platform was 10 years ago. As technologies converge, it’s important to have exposure to both web and desktop. Picking a platform that supports both reduces the number of languages and technologies you have to be fluent with.

Delphi offers a long history of backwards compatibility, and significant popularity (read lots of code to maintain). It’s community members are often as zealous as Apple fans and are very helpful to newies. Delphi offers many of the same features as newer languages, and has support for web, mobile and desktop to varying degrees. If FireMonkey and Embarcadero’s mobile efforts succeed, developers could experience “bleeding edge” type results in what would otherwise be a product’s twilight years.

As a niche product, or if you are an aspiring ISV, I think Delphi is worth serious consideration.

Just thought I would shout out to all my readers in California who ranked #1 amongst all the US states for visitors to TPersistent, and was the major cause for the US pushing Brazil out of the top spot it’s held for some time.

If any of the EMBT dev team is responsible for the increased numbers, I would like to thank them for their work on my favorite dev tool.  Delphi has come a long way since EMBT acquired it, and although many of my posts might be considered negative, I truly appreciate their efforts.  Especially as of late, since some of my QC items seem to be progressing.  In fact, I reported a new QC item (113570) on March 11th and it was fixed on the 13th.  It doesn’t get any better than that!

If you consider yourself a developer with principles, then consider this;  the use of TDataSet descendants violates the principle of Encapsulation that is foundational to OOP.

Why?  Well the moment you drop a dataset onto a form and use an event handler, that form is now tied to that dataset.  You might think the fix is to use a datamodule - great idea!  The moment you reference the datamodule from your form, the two are tied inextricably together.  All you have really accomplished is not cluttering up the form with data access components, and introducing the requirement to reference the datamodule in every data related line of code, or start using the dreaded with and lose the ability to mouse hover to inspect code values.  If you think you have separated your data access layer (DAL) from your UI, you have - but only visually.  Want proof? Just try to change your DAL components without changing any behaviors in your forms, or one line of form code.

What are the benefits of OOP?  If you don’t know, then perhaps you’re still writing procedural code.  Delphi’s RAD approach to database development encourages writing such code.  Just because a framework uses objects or components doesn’t mean you have to write object oriented code.  There are 3 pieces to the PIE when it comes to OOP: Polymorphism, Inheritance, and Encapsulation.  Encapsulation enables developers to modify an object in the system without introducing side effects (read code breakage) as long as they don’t change the class interface.  Encapsulation is required to write maintainable code.  No one can remember all the details of a system even if they wrote it, so without encapsulation, breakage is inevitable.

In a typical TDataSet based application, a central datamodule is used and datasets are filtered dynamically to meet specific needs throughout an application.  With the use of data aware controls, the current record of a dataset becomes a significant state to maintain across different forms.  Using field and dataset events further complicates the code base, scattering business logic throughout forms, requiring all methods to be aware of the events used, and why, as well as preserving the call chain if they need to tap into an event.  In short, it leads to an unmaintainable spider web of undocumented dependencies.

Think you are never going to change your DAL so what does it matter?  I guess that means no more Delphi updates for you….

While the information available regarding the AnyDAC acquisition is pretty sparse, I find it worrysome.  Perhaps I’m alone on this, but why does a company acquire a competing technology?  I can think of a couple of reasons: 1) the technology is better than what they currently have, or 2) the company that owns the technology is more progressive and so acquiring them early enough prevents having to compete with, and quite possibly lose to them later.  Otherwise, licensing it is a viable option depending on its intended usage.

Marco in his announcement stated that AnyDAC is “considered the best data access library for Delphi”, and “its [dbExpress] features set remained very stable since it was introduced, and the transition to dbExpress IV started in Delphi 2009, was never fully completed.”  I interpret this last statement as an indication that dbExpress has not continued to evolve, and was never completed in over 4 years.  That is a little disturbing since EMBT sells their additional drivers as part of the Enterprise SKU which commands a large price tag.  It’s also scarey in that Delphi’s popularity was largely due to it’s ability to produce first class client/server applications, and then later distributed database applications.  If EMBT fell behind in such core functionality, to the point where they had to buy a third party product to keep pace, what does that say about their direction?  It’s also concerning that the AnyDAC acquisition might very well mean a change to the EULA in the next release due to the additional cost, and the deprecation of DBX.  I’m sure other EMBT partners such as DevArt are thrilled!

Add to that, the acquiring company is apparently suffering financially, raising it’s prices in the new year, laying off staff, etc, and it really makes you wonder why in January they were negotiating a deal with DA-Soft to purchase DA-Soft’s primary product.  The last time this happened they acquired a flaming ape.

I suppose time will tell what this means to the Delphi community.  I personally don’t see it as a positive.  If I wanted to use AnyDAC, all I had to do was buy it.  Now I will very likely be paying for it (Kind of like the “free” HTML Builder 5 you get with Delphi), whether I want it or not, and there is no telling what the customer service, and development direction of Any DAC will be like in the future.  As part of EMBT, it will become EMBT’s.

Whenever I take on a new maintenance project I find that sometimes form names do not adhere to a standard naming convention, or it takes a while to get accustomed to the one used.  For that reason, if you encounter a bug, or behaviour that is not desired when running an application outside of the IDE, it is often difficult to figure out what form is active when the error occurs.

An old school way to answer this question is to use Spy++ to get the window class name, which for Delphi forms is the Delphi class name.  Since Spy++ is a Microsoft VC++ application and tool, it doesn’t come with Delphi so I always have to get it from another source.  I recently found this location with multiple versions.  Guess I’m not the only one who still uses this tool!

I delayed publishing this post as I contemplated the wisdom of doing so, but 2012 has been a big year for Delphi, so I thought I would review the events of the year and make my predictions for 2013 even if it’s the last day of January rather than the first.

Corporate

One of the biggest news items was of course Marco Cantu joining EMBT as a Delphi Product Manager. Sadly, this was not the only staff change at EMBT. Barry Kelly among others, decided to leave EMBT, and there were anonymous reports of lay-offs, and a large degree of employee dissatisfaction including no raises for employees since EMBT acquired CodeGear, as well as hiring of junior engineers in economically advantageous areas of the globe.

The new EULA agreement for XE2 included changes prohibiting the use of DBX drivers (EMBT’s and third party) for accessing remote databases in the Pro version of Delphi. These “proposed” changes were leaked to the community, and the agreement was subsequently changed to exclude the new restrictions.

With the release of FireMonkey (FMX) on Sept. 1, 2011 it’s been over a year that FireMonkey has been out in the wild. The introduction of FireMonkey heralded the deprecation of the VCL despite numerous enhancements, it’s clear that EMBT is betting the future expansion of the Delphi/BCB market on FMX.

Desktop

Since FMX was released, there have been two major component vendors providing support for FMX; TMS and FastReports. Delphi XE3 has also been released with an updated version of FireMonkey (FM^2). With third party advanced grid and reporting capabilities, FMX now has a sufficient tool set to author cross platform desktop applications for LOB (Line Of Business) applications.

Many of the technical blog articles on FMX have been quite critical of its implementation and lack of completeness in the version 1.0 release even in the desktop space.  Some of these deficiencies have been addressed in version 2, but the framework is still maturing, and the latest feedback on FM^2 by those deep diving the technology is not extremely positive.

Mobile

In the mobile space, several applications were authored and accepted into the Apple App Store using XE2 with FMX before FMX support for iOS was removed in the subsequent release (XE3). Users who bought XE2 for iOS were left with a discontinued version of the framework and development tool, with no clear indication what the future held for them. These early adopters were then required to pay to upgrade to XE3 for the privilege of beta testing the up-coming Mobile Studio, in order to ascertain what their migration path would look like, and whether they should continue to support EMBT’s efforts in the mobile space.

The Future?

With the layoffs/departures from EMBT, as well as delayed compiler releases it appears the decision to bet the farm on FireMonkey is not paying off yet, and even EMBT employees may no longer believe in the strategy. This is further validated by the attempted EULA change which would have required Pro users to buy a higher priced SKU, and the 10% price hike in the new year.

I think EMBT has bitten off more than they can chew. Trying to implement a cross platform UI framework is a major endeavor with minimal payback (development tool licenses only), and lots of competition. There are free frameworks out there, and ones that have been around for a long time. Creating a framework specific to the Delphi/BCB tool set immediately limits its market, and dramatically increases the code base that EMBT has to maintain. From what I can see, they are already challenged in that respect (just look at the number and age of QC reports). It’s been over a year since FireMonkey was released, and the adoption rate appears to be minimal if you look at the available components and applications based on FMX.

IMHO, the writing is on the wall.  Expect to pay more for Delphi/BCB licenses while EMBT pours their revenue into FMX to develop the market.   Expect to wait longer for bug fixes and suffer from longer startup times due to increased anti-piracy efforts. I would also expect that the Android and Linux support will be even later than indicated as EMBT focuses on the Mac/iOS platforms trying to get traction in one of the most appealing market segments for Delphi developers.

As unfortunate as it may be, I believe that FMX will continue to flounder and that’s why you don’t see vendors like Developer Express, or Raize porting their VCL products, and even after over a year the monkey is hardly on fire.  FMX will likely become a niche framework, used by some developers for XPlatform support and 3D development, while the number of developers moving to different languages and tools for new development continues to escalate.  Certainly the release of mobile studio will be a pivotal event for the future of FMX, and therefore Delphi.

It’s been several years since I used datasets for anything other than quickly displaying the results of a SQL Query or Proc.  Recently I have been reminded why I dislike the TDataSet based RAD development approach so much.

If you’ve ever done a DBX conversion you would know that DBX maps datetime database columns to TSQLTimeStampFields instead of TDateTimeFields.  If your datasets use persistent TFields, which is typically the case so developers can make use of TField events to provide formatting, and validation, then you’re in for a treat!  All the persistent TFields have to be removed so new ones can be generated at design-time using DBX to ensure the right field types are used.  Of course you don’t want to remove any additional TField descendants created at design-time that are not in the dataset, so it might be necessary to go through each one to determine if the TField originates from the underlying dataset (using FieldKind may not be enough).

Once you’ve finished re-mapping all the TFields, you have to re-connect all the event handlers.  Hopefully, the original developers actually centralized all the database related code into datamodules, or you will be going through every form in the entire project.  Even re-connecting all the dataset TField handlers in the datamodules may be a treat if handlers were not shared across TFields of the same type.  For instance, if you use the OnSetText, OnGetText events to provide standard date formatting for TDateTimeFields using edit masks for input with a different format for displaying the date, you have to reconnect numerous handlers to each persistent TField event and the only way to tell if you have it right is GUI testing.  If you don’t get it right you will see errors from TField.SetAsString() with no idea what field is causing the exception.  The easiest way to actually find out is to put a breakpoint on the method, enable Debug DCUs, and generate the error through the UI.

In an application using domain objects with the MGM pattern for presentation, all the TField handlers would be replaced with mediators that perform the translation between the UI presentation layer and the database layer.  If you need to enhance the application to work with a variety of date formats, for instance, instead of locking it down to the corporate standard format which I see most often when using TField events, the enhancement would only involve a change in one place (the mediator).  It’s a much DRYer approach.  While using TField events doesn’t necessitate multiple handlers for the same purpose (one per TField type instance), not many developers think about consolidating such code across the application, and the result is a maintenance nightmare, especially if you ever think about changing the database layer.

Avoid vendor lock-in, even if you’re not thinking about changing your database, consider using an ORM, or even database application layer interfaces such as hcOPF’s IhcQuery and IhcStoredProc so changing your database layer doesn’t result in sleepless nights.  One “proposed” EULA change could have you swapping a database layer in a hurry

I got a very disturbing email tonight from a prominent EMBT team member who took exception to one of my comments.  Instead of addressing my comment on the same blog by replying to it, he instead sent me an unsolicited email which ended with the comment

Jon Stewart just called me and asked me to ask you: “when is Larry going to come down from b@11s$&t mountain?”

I found this to be a juvenile, completely irrelevant comment.  Besides that, the EMBT team member looks more like moses than I do, so it was confusing
Now I don’t know what you think of my opinions concerning Delphi or EMBT, but whether you agree with them or not, I would think you would probably expect as I do, that any EMBT representative would conduct themselves in a professional manner even if they disagree with the content of my posts, or my comments on a public website.  I would also expect that they address my comments in public where they were made, instead of sending me private emails and hiding behind a confidentiality signature stating:

CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

EMBT can regulate their corporate newsgroups anyway they see fit.  If speaking out means having my posting privileges suspended like Joanna Carter, so be it, but what does that say about a company when they are so worried about trying to control what people are saying, instead of listening to what they are saying and addressing the concerns?  Why does Developer Relations seem to be an extension of the marketing machine, instead of a department who works to establish and maintain good relations with the development community, EMBT’s customers?

I’m an adult, I can handle it when people have a different viewpoint.  I can even admit when I’m wrong if people with opposing viewpoints care to make a good counter argument. That’s what makes a community stronger.  If there was never a dissenting voice, then we would all be forever treated like cattle by our governments, and we would all have our individual needs as developers overlooked by companies trying to sell us what they’re marketing department dreamed up as products even if they’re half finished.  IOW, status quo.  We have a right and a responsibility if we care about something (in this case Delphi), to not just request what we want, but demand it until we’re heard, and a responsibility to back it up with our money.  Personally, I won’t buy another edition of Delphi until I get some of my top QC issues fixed.  I don’t understand why EMBT doesn’t employ bug bounties.  I contributed to Andreas Hausladen’s efforts because he actually fixed some of the performance issues I was facing in Delphi, even in something as old as Delphi 7 (among other releases).

Perhaps it’s for the best….Delphi interest here is declining, and when my current contract is finished, I can’t see continuing to bet my livelihood on a tool where fixing bugs, and providing positive customer interaction seems to be such a low priority.  I don’t need any more road apples in my inbox.

So from now on, I think I will restrict my blog posts to hcOPF and other technical issues, but don’t be surprised if that doesn’t last long.  I’m thinking about getting Oxygene because I’m more confident it will ship when promised, and provide the iOS, Android, OS/X, Linux, and Windows support including 64 bit EXEs which has yet to materialize in the Delphi world despite a rather catchy slogan of Delphi Everywhere. It’ll be like a breath of fresh air…

Normally, when you fix a bug in a particular section of code, you also look at other bug and enhancement reports related to that area to see if you can also fix those issues, or implement those enhancements.  Otherwise you’re judging one report in that area against the other in terms of frequency and severity to determine which ones get addressed.

That’s why it came as quite a shock that in XE3 QC items 104640 (B3 opened 4/6/2012), and 107227 (B2 opened 7/19/2012) were addressed in amongst numerous others in the IDE, IDE\Code Editor category, but other QC  items relating to Code Completion were not, including my own QC99381 (B1 opened 7/27/2011).  It’s shocking because, I run into this code completion bug on a daily basis where the issues that got fixed appear to be edge cases.  In fact 104640 has a lower severity than my report, and was opened long after mine.  I don’t know what prioritization algorithm EMBT uses, but I find it baffling!  So that’s one major release of Delphi later, with several updates, and 4 hot fixes.

Addressing all issues in a specific area all at once, in my experience, works best.  That’s because the developers get their head into the problems, and code.  This takes a while, and it’s been proven that having developers juggle multiple things either concurrently or in quick serial succession, makes them less productive.  It’s simply the power of focus.  It also makes testing an area thoroughly easier, especially if it requires manual testing, requiring less time from Q&A.

Apparently breaking functionality in one release doesn’t necessitate fixing it, even in a following release that developers have to pay for.  How do you feel about that practice?  If a bug is introduced in a release should it be fixed and provided in that release for free?  Where would you draw the line knowing software is never perfect?

If Marco Cantu is indeed the special guest at CodeRage 7, and the announcement is indeed that he is the new Delphi Product Manager, I hope he is empowered to change the way QC items are handled.  As a developer who actually uses the tool, perhaps he will also address the poor template support, re-factoring, code navigation, and remove the half baked useless “features” like the Object Inspector Description pane (I currently use his package to hide it), and complete others like Error Insight that could be more useful with less false positives.  Let me be the first to wish him well in that role if the commentor Inside Embarcadero is right.

Has anyone noticed that the Developer Edition of Interbase requires a regular restart?  I have a little invoicing program that I use on a daily basis, and the back end is IB.  I have an unlimited user license of an earlier version of IB, but I chose to install the latest version  of the Developer Edition of Interbase so I could evaluate it while working on hcOPF, and my invoicing program which used to be a demo project for hcOPF.

One would think that a Developer Edition of a product would be free of such annoying licensing restrictions because the better experience that a developer has with a product, the more likely they are to recommend it’s use in a production environment.  It’s also harder to develop when you’re constantly re-starting your machine. You don’t see such restrictions with MS SQL Server Express, and it has much better market penetration than Interbase.

One would almost think with the proposed EULA change, and the increased copy protection, that the revenue from Delphi is in decline, but in light of the Interbase re-start restriction, perhaps it’s just EMBT doesn’t trust it’s customers, or doesn’t trust developers in general, and makes it’s customers ‘bear the brunt’ of this distrust.

Apple no longer sells DRM music, and there are various other companies who have stopped using or reduced their anti-piracy efforts because it impeded their existing customers, and the public spoke out against such restrictions (remember the Sony Rootkit debacle?).  I hope EMBT changes their position on this issue soon.  For now, I am going to switch the back end of my invoicing program to SQLExpress.  One of the great things about an ORM is it doesn’t lock you into a a specific vendor’s database, and there are plenty of choices out there for databases these days!