Archive for July, 2009

hcOPF now supports Advantage Database Server

Wednesday, July 22nd, 2009

I started my development career writing medical billing software for a small company started by one man who saw the need for some software, taught himself Clipper Summer’87 and filled that need.  He grew the company to two full-time developers, but never managed to make the jump into Windows development.  He managed to sell the DOS products long after DOS was no longer the pre-eminent operating system.  For those of you not familiar with Clipper, it’s an XBase product that uses enhanced DBase type DBF files.  We had some speed and corruption issues because at that time machines weren’t as fast, and networks were not nearly as reliable.  We used Advantage Server for Novell to solve these issues.  I was always really impressed with the speed and robustness of their software, but always thought it had a limited shelf life as the XBase developers would either evolve or die off.  I was wrong.  Sybase now owns them, and the engine has grown up to be a database with lots of impressive features.  Check them out at #mce_temp_url#.

For those developers using Advantage, you can now use Advantage with hcOPF.  I had to re-write the hcADS unit since the DAL interfaces had changed since the initial version was written years go.  It’s not as well tested as other DAL layers, and you may find hcOPF doesn’t support all the datatypes now available in Advantage, but it’s functional.

How Delphi Developers Sabotage Delphi’s Future

Monday, July 20th, 2009

I was recently reminded why I dislike TDataSets so much while working on a new client project.  The project is written in Delphi 5 by a developer who was relatively new to Delphi and object oriented programming from what I am told.  The program was developed over a long period, and “evolved” like all applications evolve.  The original developer moved on, and was replaced by a number of remote developers.  Kudos to the company for trying a more modern day approach; distributed development (a topic for another day).

As with many RAD development projects, the application suffers from three major problems:

1) developers jumped into code immediately before addressing design issues

2) business logic is scattered throughout both the form and datamodule code, often with duplication and there is no seperation of data access logic from the UI forms (so much for the single responsibility principle).

3) there is hardly a stitch of documentation in the code, and there are no requirement documents to be had.

The result, it a spiderweb of code.  It’s almost impossible to modify portions of it without introducing bugs, and it takes forever to get a thorough understanding of what the code is doing and when.  There is not even a consistent use of DataSet events like OnBeforePost vs. MasterFields etc for Master-Detail relationships.  Reports are dynamically firing queries to perform lookups on ID columns.  There is no concern for how hard they are pounding the database.  On top of that, they’re using a TDataSet descendant to talk to a proprietary database which means they are so tightly coupled to that database that changing down the road will be a nightmare.  I’ve seen this problem before with paradox tables and lower end RDBMS products that simply did not scale to the clients needs in the future.

Time and time again, I see the same problem biting companies, and reflecting poorly on Delphi as a product and Delphi programmers as a whole.  Companies seem to errantly think that paying a junior developer $20/hr. is saving them money compared to a senior developer who may cost twice as much.  What they don’t seem to understand is the unmaintainable mess they get with junior staff.  It’s usually at that point that the company decides if they have to invest a whole bunch of effort in the Delphi product they would be better off to find a junior .NET developer and re-write the product using a better technology.  The technology was never the problem.  

Now personally, I like many things about .NET, but I don’t consider it to be necessarily better than Delphi.  It’s just another tool in the toolkit, and the results a company gets has more to do with their selection of the programmer who wields the tool.  I still like Delphi because it produces such lean EXEs, has no run-time to distribute, and no delays loading assemblies or jitting code.  For some applications, it just makes more sense.

It’s just really unfortunate that Delphi provides only a RAD framework based on the dataset.  Of course .NET has an even more powerful TDataSet like object, but the .NET community has leveraged the Open Source world including the Java projects and you have an explosion of OPF/ORM options.  The movement towards agile methodologies incorporating various frameworks such as unit tests, mocking, and business objects/ORMs is much more prevalent in the .NET space.  Perhaps if the Delphi community had more activity in these areas, Delphi would be seen as a more cutting edge technology.  It would be even better if more Delphi developers actually used such practices.

The next time before you start dropping datasets onto a datamodule, think about your options.  If you want the application to be around 5 years from now, and Delphi work to be available, think about using an ORM to isolate the application from the database, and encapsulate the data you’re using.  Extend the benefits of OOP to your data, and future changes will be much easier to make.  Look at the frameworks available for Delphi for free.  Even if you’re using an older version of Delphi, there are still lots of options available.  Now, one of those options is hcOPF.  In order to use it on my latest project, I back ported it from Delphi 7 to to Delphi 5.  You will find a Compiler folder with projects for Delphi 5 and 7.  Eventually I will create one for D2007 as well, and hope that others “fill in the blanks” since those are the only versions I am currently using.