Home › Meeting Summary › Adam’s May 2020 Meeting Summary

Adam’s May 2020 Meeting Summary

Posted on Posted in Meeting Summary

Agenda

  • Test Driven Delphi Development (TDDD) – Jens Fudge
  • Developing a TMS Stack Application – Russell Weetch

Adam’s Summary

News

Delphi Developer Group May Meeting

Our third on-line meeting and final Zoho meeting.

Zoho has been “OK but not great”, itself a useful learning.

We will switch to either Zoom or Anymeeting for the next event. Rob Lambden suggested https://meet.jit.si/, which I have never heard of.

Members with suggestions for other / better meeting platforms please tag them to this post.

Slack of the day is here:
https://app.slack.com/client/TGWNPDL15/C013NE1CJ0L/thread/CV6CYF74Z-1584381478.086600
(I am not sure how public this URL is, if you are not a member, I expect it may not let you in, if so please contact Jason).

Pete Sykes drew our attention to:
https://blogs.windows.com/windowsdeveloper/2020/05/12/start-developing-on-windows-10-version-2004-today/
which gives details of (exciting) new Win10 stuff.

Jason opened up with news related to Delphi 10.4. This release seems to be sub-titled “Vanquishing of the Red Squiggles”, although laughably over-restrictive Embarcadero beta-testing contract-terms have made it impossible to undertake any useful discussion about this in the group, it now seems that we will be getting a separately threaded IDE debugger/code analysizer in this release, which is extremely good news.

Jason has not had much time working with 10.4, but thinks most of the improvements in 10.4 seem to be IDE enhancements, building on good improvements in 10.3. I think most group members are sighing with relief and saying “about time, more please.”

Jens Fudge spoke on Unit Testing.

He outlined the operation of both DUnit and DUnitX in the IDE. This was a really valuable comparison of the feature-sets of the two systems, together with an introduction to concepts relevant to testing such as mocks, fakes, stubs, connascence and dependency injection.

I do not use Unit Testing and found it really interesting to hear a clear use-case explanation. My main take-away was unit testing clearly has a role for thorough testing of logical parts of my program (rather than UI), and that it can also have a value in helping with wrapping tests around portions of code that are old and not well understood by a programming team in large organisations.

There was a really good, spirited discussion about the drawbacks of the testing methodology after the talk. Specifically pointing out that the mantra of “write your tests first” is just plain wrong in some programming situations. Will Watts made the point that if a programmer is wrestling with a problem: refactoring, writing and re-writing classes, juggling code, the restriction of pre-written tests can impose a damaging overhead. Jens countered that the action of explicitly thinking through the testing requirement is itself valuable but agreed that use-cases vary. It was a moment when I really wished we were in a face-to-face meeting as we could have talked in a lot more depth and detail (and continued the talk in the bar afterwards!)

Jens also brought up Model View ViewModel and Spring4D briefly and discussed Ranorex as a (somewhat costly) UI testing framework. I feel that a good number of members would like to find a decent UI testing tool. If anyone knows of a good one, do add comments about it.

Russell Weetch spoke about Aurelius and TMS’s web-data-framework.

Aurelius is an interesting and strange beast, and I am not sure I really got my head around it completely during the talk.

I think it is a relational object mapping framework, which allows programmers to define classes in code for all their business-objects (Customer, Order etc., etc.) with all the fields, lists, lookups, enumerations and relationships. Aurelius (or is it some other part of the TMS web-data framework: XData, or Sparkle, I am not sure?) will then generate the data-structures you have defined in code, and build the mechanisms to push this data up and down the HTTP pipe to and from your application.

The output is a back-end database coupled to a system to deliver end-point JSON that can be read by JSON consuming applications.

Members immediately fell on the product with key questions:

How bloody hard is it to master? Russell said that he has put in about 2 person-months of learning so far, and now feels he can build applications for in-house use. He feels it might take him 4 – 6 more months to really become confident. This feels like quite a big investment for a tool, even one as vast and powerful as the Aurelius/XData/Sparkle stack.

How flexible is it? i.e. can it be made to work with my way of programming, or do I have to switch round to working “the Aurelius way”. Russell seemed to think that you really need to use it the way it expects to be used, so perhaps it won’t work for everyone, but pointed out that he hasn’t used it long enough to really be sure.

Jason pointed out that a Brazilian TMS staff member offers a training course which is not too expensive and might short-cut the learning curve.

Ian Hamilton pointed out that if you write systems like Aurelius that include extensive writing of business-object classes it can save a lot of time, but not all of us work that way.