Tuesday, May 6, 2014

Support and how it should work.

During our XE to XE6 upgrade project, we felt it was time to redo our build process.

We are using FinalBuilder and ContinuaCI produced by VSoft Technologies in Canberra, Australia.

During the process we ran into some minor bugs, in the product.    We also had some major and minor feature requests.

Anytime I ran into one of these, I would shoot off an email to the product support email address.  

Sending an email to them would result in a automatic Ticket Number response email from the FogBugz software they are using.   I don't know much about FogBugz, but as customer I love the interaction and being able to see the status of the emailed ticket at any time.

Then after sending the email, I would then leave for the day,  the next morning I would come in and have a response to my ticket.

What made me happy about these responses was most of the time they contained a link to a build with a fix to the problem I was experiencing.     If I had made a minor feature request, that commonly was also implemented in the same time period.     For major feature requests, I was informed that the request was placed on the list to implement, some times with follow up questions to ensure they knew what I was asking for.

Typical response time for a bug fix: < 24 hours.
Longest I remember waiting on a bug fix < 2 weeks.

As a customer I have never felt my opinion or bug was under valued or should be discounted because of some other mitigating factor.    A behavior I commonly get from other companies.

I could be getting lucky with my requests, but I highly doubt it as we have seen this behavior several times over the years we have been using their products.   I am sure sooner or later something nasty will come up that will take longer, but I know it won't just be sidelined, it will be worked on, and I will be kept informed of what is going on.

My point is, VSoft Technologies really has support covered.   I wish other companies, I work with had that level of support.

Friday, April 18, 2014

XE6 - New Look and Feel

One of the first things long time Delphi Developers may notice about XE6 is that it has new look and feel.

One thing I have learned over the years is that when you change the user interface in any way you will get a divergent number of opinions.    My opinion of this change is simple:   I like it.

I have made two similar screenshots of XE5 and XE6, so you can compare the differences.

Wednesday, April 16, 2014

Delphi XE6 - Easy to upgrade

Delphi XE6 was just released yesterday!   My team of 10 Delphi Developers has been moving fast.

Several Open Source Libraries that my team uses have been updated to support XE6.  

We were able to internally update our commercial libraries such as TMS, SmartInspect, Envision, RichView, FastReports and few others because we did not want to wait.    The latest version of FinalBuilder already supports XE6 so that made our build easy.

We now have our primary application working with XE6.   It was quite easy to do.    

Our code base is over 2 million lines of code.    We have 178 Packages (all have been converted)  We have 650+ DPR, several of these have been converted.   Finishing all of the secondary applications (DPR's) right now, and expect to have our conversion complete in the next 3 weeks. 

This has been a VERY EASY upgrade.   We were upgrading from Delphi XE.

I had some headaches with the license registration, but once you get past that the product works well.

Monday, February 17, 2014

pfSense - Network Performance

I am lucky enough to live in an area where I can get a fiber connection to my home.
I pay for 100 GB and 100 GB down.   However, I was never able to achieve this performance levels.   About a year ago I took a bandwidth speed test.    This is what I was able to get get.   My wife was on the phone (VOIP) at the time and my kids were watching Netflix.    So I had competing traffic.

At home I have been using a Dlink 665 Router for a long time, and it worked for my needs.

But then I wanted to do the following
  •  Block all DNS Query traffic that is not going to "Approved" DNS Servers.
  •  VPN into my home network.
  •  Monitor bandwidth by device on my network.
I have been researching options on what could provide provide these, including:
  • Devices
  • Aftermarket firmware for existing devices.
  • Using Linux or FreeBSD and spending hours configuring it.
After not having much luck finding something that would meet my needs, in my price range.
asked a co-worker what he used.     He pointed me to pfSense.    

pfSense is a Open Source Firewall based on FreeBSD.

I add a second NIC to an older spare machine I had.   Then I installed pfSense, it was a very easy to install.   I had it running with the base configuration, a few minutes after inserting the CD and starting the install.   

I then spent a few hours to get it configured as desired, but it was really easy.    Most of the time was spend readdressing my home network, as I desired a more structured ip address layout compared to random undocumented method that I had before.

I expected to get the features I was after, but one took me by surprise.
I noticed our connection seemed much faster than before.

So I took another speed test,  I had my son watch Netflix like he was before.


Granted lots of things could have changed in a years time.    So some of the differences may not be attributable to pfSense.     However, I am not about to install the Dlink 665 again to find out out the true differences.

But since I noticed the improvement, without the speed test, I thought I should post a glowing review of pfSense.     All of the features I wanted have been working really well, and it has more feature than I will ever need, allowing me to expand to meet my needs.

If you need need a better firewall at the your home or office.   It's worth looking into pfSense.

Monday, December 30, 2013

DUnitX and my plans

I have been a big fan of using unit testing frameworks.   I use both DUnit and DUnitX for my Delphi tests.

I am right now contributing to DUnitX as I see it as the future framework of choice for Delphi Developers.

I just wanted to talk in public about some of work I have going on around DUnitX.   My goal is simple to get feedback from the Delphi community.

IDE Expert

It is really easy to setup a test project and test fixtures with DUnitX, but I thought it could be easier.

So I created a new Delphi Open Tools Expert that does the following:

  • File | New | Other | Delphi Projects | DUnitX Project
    • Creates a new DPR/DPROJ
    • DPR Source is modeled after the DUnitX example unit tests.
    • Base Project Search Path set to $(DUnitX)
    • Optionally creates a Test Unit
  • File | New | Other | Delphi Files | DUnitx Unit
    • Creates new Delphi unit
    • Adds   DUnitX.TestFramework to uses
    • Creates a new class with correct attributes, you get to specify class name
    • Optionally creates Setup and TearDown methods
    • Optionally creates Sample Test Methods.
    • Registers the TestFixture in the initialization section.
Basically it's not much, but it provides a framework to reduce your time to get to writing actual test code.    I am nearly done with this code, I wrote most of it during the Christmas Break.   Hopefully in the next week I can finish this.  It's going to take some time, as I have to build a machine with Delphi 2010 through XE5 on it to test this functionality as I only have XE and XE5 installed right now.

To see the current state of the code check out this expert branch
Update:  Code is now part of the master branch on the Main Project

Data Driven Test Cases

The potential to have data driven test cases is the main reason why I started looking at DUnitX.   
  TMyTestObject = class(TObject)
    procedure Setup;
    procedure TearDown;
    // Sample Methods
    // Simple single Test
    procedure Test1;
    // Test with TestCase Atribute to supply parameters.
    procedure Test2(const AValue1 : Integer;const AValue2 : Integer);

The method Test2 above shows up as two different tests, the first time it's called with 1 and  and second time it's called with 3 and 4.

I recently made a change to underlying structure of the code. First I created a new record called TestCaseInfo followed by two new abstract attribute classes

   ///    Internal Structure used for those implementing CustomTestCase or
   ///    CustomTestCaseSource descendants.
   TestCaseInfo = record
     ///    Name of the Test Case
     Name : string;
     ///    Values that will be passed to the method being tested.
     Values : TValueArray;

  TestCaseInfoArray = array of TestCaseInfo;

  ///   Base class for all Test Case Attributes.   
  ///   Class is abstract and should never be, used to annotate a class as a
  ///   attribute.   Instead use a descendant, that implements the GetCaseInfo
  ///   method.
  CustomTestCaseAttribute = class abstract(TCustomAttribute)
    function GetCaseInfo : TestCaseInfo;  virtual; abstract;
    property CaseInfo : TestCaseInfo read GetCaseInfo;

  ///   Base class for all Test Case Source Attributes.   
  ///     Class is abstract and should never be, used to annotate a class as a
  ///     attribute.   Instead use a descendant, that implements the
  ///     GetCaseInfoArray method.    
  ///     Note: If a method is annotated with a decendant of
  ///     TestCaseSourceAttribute and returns an empty TestCaseInfoArray, then
  ///     no test will be shown for the method.
  CustomTestCaseSourceAttribute = class abstract(TCustomAttribute)
    function GetCaseInfoArray : TestCaseInfoArray; virtual; abstract;
    property CaseInfoArray : TestCaseInfoArray read GetCaseInfoArray;

With these two classes, I changed TestCaseAttribute to descend from CustomTestCaseAttribute.   
Then I changed the architecture to create a Test based on the TestCaseInfo record structure, that is obtained by either the CaseInfo or the CaseInfoArray properties of the abstract classes.

This little change provides for some really nice functionality, for example I have working sample that uses FireDAC to provide the values to my tests method

  FireDacTestCaseAttribute = class(CustomTestCaseSourceAttribute)
    FTestName : String;
    FConnectionName : String;
    FSelectStatement : String;
    function GetCaseInfoArray : TestCaseInfoArray; override;
    constructor Create(const ATestName : String;const AConnectionName : String; const ASelectStatement : String);

  // Which then can be used like this:
 [FireDacTestCase('TestName','MyDBConn','select strVal, IntVal from Table');
 procedure MyTestMethod(AValue1 : String; AValue2 : Integer);

// Right now the test come out names 'TestName1', 'TestName2', 'TestName3' although that will 
// change before I commit my code to allow specifying values.  

//Most likely passing the TValuesArray with a Format call on testName like this:

 [FireDacTestCase('TestName%0:s%1:s','MyDBConn','select strVal, IntVal from Table');
 procedure MyTestMethod(AValue1 : String; AValue2 : Integer);

This attribute is not in the DUnitX.TestFramework.pas to avoiding creating dependencies on those that don't use this functionality.       This needs quite a bit of work before it's polished enough for general use, but it's what I am working on next after the expert is submitted as a pull request.  

Note: Since FireDac changed it's naming, I believe it might be XE4 or XE5 specific.

Repeat Attribute

DUnitX defines a RepeatAttribute that is currently not implemented.    I made an attempt at implementing it, and I don't like it.    If anyone has better idea, I would be happy to entertain it.

Otherwise, I have some small improvements I think I will make and will submit it again.

My implementation can be found in Pull Request #26  which won't auto merge due another change being implemented first,  but can be viewed in a working state in my RepeatAttribute branch.

Future Plans

Things I want see in a Unit Testing framework is vast, I not sure what I will start on next but here are some areas I am considering with no preference on order.  Note: this is not a road map as some may never be done (at least by me)

  • Test Categories similar to NUnit as I have 10k+ of DUnit tests currently and categories might make it easier to group run on the ones I am interested in.
  • VCL and Firemonkey  GUI Runner
    • Understands and can filter on categories
    • Quick Filter by name
    • Run all or specified tests
    • Simplify the DUnitX project source and make easier to select which runner is used.
      • VCL
      • Firemonkey
      • Console
  • Something similar to GUITesting.pas found in DUnit
  • Load and run tests stored in BPLs.
  • Data Driven Tests Enhancements
    • dbExpress
    • CSV Test Case Source
    • XML Test Case Source
    • TestCaseSource Attribute
      • IOC looks up the Test Case Source Builder Interface
      • Other Sources implement Test Case Builder Interface and Register it in IOC Container.
  • Remote Test Framework
    • Think mobile, tests are on the device the runner is on your development machine.
    • Think Test Farm, multiple machines, with different configurations all running tests.
  • Implement TestInOwnThreadAttribute 
  • Find better way to test new functionality in DUnitX.

Thank you

And last but not least I would like to thank Vincent Parrett and his team for the set of great tools he as produced for the Delphi community.

I use the following:
  • FinalBuilder - Build Automation Tool - Commercial - Well worth the price!!!!
  • ContinuaCI - Build Server - Commercial - Free single for a single build server/agent.
  • DUnitX - Unit Testing Framework - Open Source
  • Delphi-Mocks - Mocking Framework - Open Source
  • DUnit-XML - DUnit XML output in NUnit Style - Open Source
There is more Open Source he has produced all listed on GitHub.

Tuesday, October 8, 2013

CodeRage - Next Week

Next week is CodeRage, I am looking forward to speaking again.

I have two sessions:

  • A VCL Developers Guide to Firemonkey
    • October 15, 2013 @ 8:00 AM PDT
    • This session is for those VCL developers who want to learn Firemonkey but have never taken a dive in.   Designed to help these developers save time by addressing the difference in a quick and easy way.
  • Responsive Delphi Design
    • October 16, 2013 @ 1:00 PM PDT
    • Now with mobile developer we are faced with multiple form factors (Device Sizes).  How do we create a single application that looks good on each form factor you
Attendance is FREE and online, all you need to do is Register before the 15th.

Friday, August 9, 2013

Getting ready for Android

Android support in Delphi is on the Roadmap and is expected in the fall.   Although I have a Mac and an IPad, I have an Android Phone.   I was not as excited for the XE4 (iOS support) release as I am about Android support.

I have some thoughts on Android that I want to share...

Market Share

Overall I see a greater number of Android devices, in fact we have 5 Android based devices in my home and only 1 iOS device.  Market studies that I have read vary, but shows in some cases a 50-50 market
and in other it shows that Android has a greater market share.   Regardless the possibility of using Delphi to write a single application that can target both is very exciting.

Android Versions

Android currently has shipped 7 different, Major product releases. These are separated by different code names.     Unlike iOS where most of the users are using the latest version.   Knowing this code names will make your life easier as they are referenced in documentation, blog posts, articles, etc...

The 3 most popular (as of July 8, 2013):
Gingerbread  - 34.1%
Ice Cream Sandwich - 23.3%
Jelly Bean  - 37.9%

Full details on the break down of each code name are market share can be found on the developer.android.com site.   Another good tidbit from this site is the various screen resolutions and
form factors you will see when targeting android.


Distribution is not locked down like the iOS market.
You can distribute you applications in several different ways including
-Google Play Store
-Amazon App Store
-Download from you own site

Design of your application
I love to hear customers talk about just moving an existing windows application to Windows.   After talking with them, they quickly realize that the form factor and touch interface requires a redesign to the look and feel of an application.     For example, most VCL Delphi Applications I have seen contain a Grid.   I rarely see such anything like that on mobile platforms.   To help with this mind set switch I would recommend reading a couple of Design Guidelines.

A bit about the internals of Android

At the heart of Android is the Linux Kernel (Version 3.x since Ice Cream Sandwich release).
On top of the Kernel sits the Dalvik Virtual Machine which runs Java Byte Code.

So when it comes to development you have two targeting options.  
  1. Native - Runs at the Linux Kernel Level
  2. Java Byte Code - Runs in the Dalvik Virtual Machine
Since Delphi is using LLVM for the Android Compiler, applications running will be targeting native.
Java has history of being able to interop between native compiled code, it uses a technology called JNI.
I  suspect that Delphi will have some easy way to do JNI since several of the android libraries are based in Dalvik.

Now it's time to wait and see what Delphi's Android support will really shape up to be.