Saturday, February 27, 2021

Delphi 10.4.2 - What is your current Hardware for Development?

Well, this is of course not related to this newest version of Delphi, it's the right question for every Developer, but with every new version of Delphi, this topic is back on the table. If you're looking for my opinion on 10.4.2 - please just scroll down!

Declaimer: This is not related to Embarcaderos specifications of minimum requirements, this is "just" my point of view.


Let's start with a little example:

If you were a carpenter, would you buy a jigsaw from the hardware store for 49.95 or would you have a high-end circular saw table that can do everything you need?

If you have to cut down an entire forest, you wouldn't use a handsaw, but a chainsaw, would you?

Is it possible that your 3D printer cost more than the laptop on which you "work"? 

I just read a question about the new IDE: "If I press a key and the LSP has to update, I can hear my Laptop-Fan is ramping up... 

Laptop? Really? Are you kidding me... 

There are some Laptops out there, you can probably use...But for this price, you better buy a third Monitor.

Ok, If my system is mining in the background and I'm watching a Video while loaded up 3 VM with different IDE's sometimes I hear the fans of my watercooler spin a little bit faster. Just joking, minding on the GPU is stupid.

Your Workstation is your main tool for work, yes I call it Workstation, Powerhouse, whatever... If you call it "My PC" and you are not able to run the latest AAA games on it. Buy a new one!

After 35 years of Development here is my list of NO-GOS (in unsorted order):

  1. Use a non-SSD Harddrive or an SSD attached via USB.
  2. Not installed the latest OS
  3. less RAM than 16MB
  4. Screen resolution less than 1920x1080
  5. Only one Monitor.
  6. Not using a VM
  7. Using a non-standard keyboard. (perhaps you can work on a Laptop keyboard I could not)
  8. Not using a Source-Code-Management System (svn, git, mercurial)
  9. Firemonkey App development without my FDK... ;-)
So what are my recommendations you ask?
  1. I would never want to develop without a VM again. So: Use a VM. I like VMware, there are some issues with it but overall it runs perfectly. Using a VM set the bar for a good system a little bit higher! But having auto-snapshots every hour and be able to revert the installation back to a working copy if you have installed something stupid or your installation just broke down is worth it.
  2. Your CPU should have a core-count that is double as high as you would like to have in your windows system. I prefer 4 cores so with hyperthreading you have 8 logical cores in my windows. That's why my CPU has 8 cores with 16 logical cores. 4 for the VM and 4 for the Host. I'm an Intel-Fan-Boy, never tried AMD. My colleague has bought a board with the latest AMD CPU and he has so many problems...
  3. Use 3 Screens. 
    1. Center screen for the IDE. 
    2. Left screen for the undocked the Objectinstpector and structure view. 
    3. Right Screen for the program group and the component palette. 
    4. My Line for breaking up the source line is not at 80 anymore, it's on 160!
    5. While debugging, place your program on the right screen (program group not shown). 
    6. Most of the time when doing boring stuff I put my OI docked at the left side of the IDE on the center screen because I switch my left screen to my Host for watching YouTube videos or other stuff...

  4. If you want the "same speed" inside a VM that you would expect from your main system, Harddisk and RAM performance is the key.
    1. I've installed 64GB of RAM so I can start 3 VM's with 16GB and still have 16GB left for the host system. Or any other combination. 
    2. Perhaps you think: RAM-Speed is not so important. I did not test this and perhaps high-speed RAM has a not-so-big impact on your system. I prefer RAM modules that are recommended by the Mainboard Manufacture and often higher speeds come with a huge impact on the price.  But this looks not so bad compared to the rest of the world.


    3. On the Drive-Side there is no room for low-cost at all! Maximum performance is the key to a smooth-running VM because the VM is often very disk intence.
      1. You get the best performance with an M.2 Drive. If you combine 2 or 4 of these high-speed M.2 to a RAID 0 stripe-set you are pretty close to the maximum speed your bus could handle.
      2. Never ever use your VM on a Harddrive or a single SSD connected to a SATA connector. I had SSD failures in a RAID 10 and this saved my installation.
      3. For Backup I have a RAID 10 of 4 SSD's and a RAID 5 with 3 M.2! Here is the trick: I use the hourly auto-backup of VMWare. That's fine. From time to time I shutdown my VM and copy it (1,6 TB) from a RAID 0 (4 x M.2) to to the RAID 5. This is the best performance I could get. After a few minutes, I can restart my VM and then copy the files for this RAID over USB C 3.1 Gen II to an M2. in a fan-cooled external housing. With this, I get the maximum performance USB could handle. I really would like to have a Thunderbolt connection (should double the speed), but the card I bought was not working and I have no spare slot on my Mainboard. 

  5. I know some people prefer Air-Cooled systems. But I'm using a custom loop for so many years now and the only problem I had once was because my soft tubes are getting old and one fitting was leaking. My System runs quiet, always below 50° C (often below 45° C) and with adding a little bit of water from time to time I had no maintenance to do. (Yes, I just use water, not any colorful additive or even distilled water) That's why I have no little particles clocking up my block. With my last CPU/Mainboard update I installed a new reservoir (the old Plexiglass had got some cracks) and switched to a new pump (just in case). This was the only maintenance in 10 years. 
  6. Install a really good graphics card. Perhaps not so important for VCL developers, but as FMX uses the GPU to render, you'll get the speed you've never seen before with VCL.
  7. For the App development, I'm using a Mac-Mini. Ok, I switched out the hard drive and installed an SSD. (I really should test a macOS-VM sometime). 
  8. And similar to point 9 of my no-gos - use my FDK for your FMX, VCL, and App-Development on the mobile platforms.

Anything else?

hmm... I'm still on D2007 with my main application. (Not finding the time to fix all the Unicode warnings). But the old compiler is also able to compile more than 2. Mio. LOC in under 16 seconds for a full build.
 
Perhaps you call my recommendations overkill, I call it: Best bang for the bug... I spend so many hours at my workstation and I have no time to wait for something to finish. That's why I want the best performance you can buy. (For a reasonable amount of money).

I love the statement about electric cars from the best rally driver of the world Walter Röhl: 
I'm too old and I don't have enough time left to wait at the loading dock. (Translated)

In my case: I'm too old to wait for the compiler. If I currently working in a unit to implement something and I have to take a look into a different unit (normally I have too many open units, often more than 20), it is faster to hit compile and let the compiler find the position I am working on, then to search for the unit or ever do a text-search inside the same unit... ;-)

So - don't complain that something is too slow, beef up your system!

If EMBT tries to speed up the IDE and the compiler at the same time, we will get a faster and faster development environment or at least a constant speed as the possibility grows.

Back to 10.4.2


In my tests 10.4.2 is faster than 10.4.1 and 10.3.3. There is of course an impact now many components you have installed and how long your search path is. Also, there are differences when compiling inside the IDE or using the external compile or MSBuild.

Besides the numbers, the IDE feels snappier and there is a lot less flicker (or nearly/no flicker anymore). There is a little loading screen, popping up when the IDE is loading units. You can disable this, but for the first time you get a notification of what the IDE is doing - I love it.

There is also this new feature of the LSP. You know the old red wriggling lines below errors that were wrong in most cases! With the new settings, you could switch to different lines or dotted lines that also could have different colors. Blue, Yellow, and Red for "not used", "hint" and "error"... My first reaction to this was...

Why on earth did they do this?

But while using this feature for some days - I love it - you can faster correct your mistakes or change a var name because you misspelled it.  This allows you to develop faster, believe me.

Overall it feels better - yes there are still some little bugs in the IDE - we all know, but I can live with the new version!

And as always:
We hope for the next version (10.5) and that the little bug gets fixed!

So long, have fun with the new version.


Posted by at 6 comments:

Friday, February 5, 2021

My road to a useable MVVM Pattern implementation for Delphi!

If you read my blog regularly, the MVVM topic will be nothing new to you.

But please take your time and fill out my new survey, thanks for that, of course, even if you visit my blog for the first time. I would love it if you can also be part of this survey. 

If you are a first-time-reader... Welcome to my blog. Please read the other posts about my #D.MVVM implementation. As you can see, this subject is not new to me and my knowledge has, of course, improved over the years. (I hope, I'm right with this statement)



Here are the links to my other MVVM-related blog-posts in reverse order:

There was a blogpost from Oct. 2019 with the question: How long does it take to develop a "complete MVVM framework for Delphi. (Link above) the answer is: Not long if you take shortcuts or too long if you are a single developer with no help. But I won't cry, because my goal was not to do it the easy way.

If you do not make it down to the end:
Here is the link to my new survey!
But perhaps you want to know why I've created a new one? ;-) 


Let's collect - one more time - my goals:

  1. The framework must be as fast as possible. (My goal is - it is supposed to be the fastest MVVM framework available for Delphi.)
  2. The development time should not be significantly longer than using the RAD-Approach. At best, the development time should be shorter, comparing to a non MVVM, but not "everything in the Form unit" - development.
  3. Everything that could be done in a background thread should be done in a background thread.
  4. Support for FMX and VCL. Including the "special needs" for the FMX UI.
  5. It must definitely run on ALL platforms.
  6. 100% Unit-Test-able of your Application. (Switch for disabling the background thread to do a better Unit-Testing).
  7. Mockup's for View-Components to test the Binding of your App.
  8. A nice Wizard should be installed into the IDE to create a new VCL or FMX-MVVM Application. This Wizard should be changeable over an Ini-File to make a User-Configuration without recompiling the Wizard-DLL.
  9. One central binding point (Composition.Root) 
  10. If you are an FDK-User (My Firemonkey-Development-Kit) the framework should work streamless as a plugin, with all the benefits of my ORM-Lite, threading, or Client-Server units.
  11. No need for special components. (Components must work without an extension)
  12. Open to User-Implementation for non-standard components.
  13. The View (Form) should not have a single line of code. Or should not need any code-behind...
  14. Visual Livebindings must not be used.
  15. A developer who has NEVER dealt with MVVM has to get along with my framework IMMEDIATELY.
  16. A good developer who has already used MVVM should find his way around immediately. (Except for some things that I have implemented differently than MS).
  17. We are Delphi-Developer - If we are doing MVVM differently than our C# friends - that's fine!
  18. Views must be able to be composed of any number of sub-Views (frames) without writing a single line of code for them. (Sub-Views must be interchangeable for special requirements)
  19. It must also be possible for a sub-View to be a ViewPort3D (FMX-Only). Full support of 3D objects from the ViewModel will be another thing for further investigation. This could be very interesting for Game-Development, but that is completely another topic.
  20. User-Level and flagged Menu-System with auto Action-Binding.
  21. Multiple View for a ViewModel, also with sub-View/ViewModel Binding.
  22. Conventions over definitions.
    1. This is especially true for automatic binding by naming convention. Example: Name: TEdit should auto bind to the fName: TProperty<String> or to a normal property Name: String. The Binding is connected to the Text-Property of the TEdit Component and the OnChange and OnChangeTracking (FMX Only) event should update the ViewModel.
    2. User-defined naming convention... Bind Name:TEdit to fEdNameField : TProperty<String>
    3. Global naming rules and also naming rules by TypeInfo.
    4. Overwrite any predefined rule with an attribute.
  23. Multi-Binding to different properties.
    1. Example: Save: TButton.OnClick -> Procedure DoSave
    2. Save :TButton.Enabled -> fCanSave : TProperty<boolean> or Property CanSave : boolean
    3. Fone : TCombobox.Items -> fFoneItems : TListProperty<String>.
    4. Also user-defined naming: "Can"+Save;"Do"+Save could be changed to: e.G.: -> "CheckFor"+Save;"Execute"+Save.
  24. Optimal performance on ".Strings";".Items";".Lines" - never ever send the complete list on a single change. A virtual created adapter must take care of the updates. (e.G. for a single changed line in a Memo of 10.000 lines it is a nogo to update the Text-Property of the Memo.)
  25. Data-Verification on Property-Level to check the fields inside the ViewModel.
  26. Listview and Listbox special treatment for FMX.
  27. A data model for VCL Grids - The FMX Grid already has a data model.
  28. A not so easy implementation of an MVVM-Treeview. (Perhaps not in the Beta)
  29. Complete logging of all internal functions should be possible. (Only for the Plugin Version)
  30. Error messages that are normally written in English must be able to be translated by an external language file.

The MVVM-Pattern has the Model included in the Pattern-Naming, but actually, the Model is not really a part of the Pattern. But in my case:

  1. Only if the Framework supports the transfer of all the collected data from the ViewModel to the Model, my goal of: "As fast as RAD Development" is possible. 
  2. The Framework must have a Datacontext that can make the transfer from the ViewModel to the Model, and back.
  3. The Datacontext should be able to convert, combine and separate fields as they are transferred back and forth.
  4. The Model should directly work as an ORM or REST-full Web interface. 
  5. As an FDK-Plugin it should also work with my Client-Server-REST-Units.

So far so good...

There is light at the end of the development tunnel! I'm really happy with the actual implementation. I think I have done all the necessary improvements for the first version. and - as always - I would have programmed the framework even if I wasn't planning to offer it commercially. Of course, programming is a bit different when the source code is handed over to other developers. Certainly, I could have made a lot of things more static or simpler.

And now?

There will be a Beta-Version and an Early-Bird-Order! But maybe this time I should do an Alpha -Version too - if I can find developers interested in helping me finish the release version.

But how and why?

After years of development - only in my spare time, of course - perhaps I've done something wrong, perhaps I should rename a method or change params of a function. Whatever... I don't want to make breaking changes from Beta to Release.

I know - some of you - are waiting for the release of my Framework, but besides the old survey, I don't know how many Developers would still like to be part of the Alpha or Beta-Team. (or even would like to buy my #D.MVVM-Framework). (Old survey filled by 177 Users).
I've talked to some of these developers and they can't wait to get started with my framework. (I'm super happy to hear that, of course).

A comment in advance from René Höger:
"Is a lot of information! Those who have dealt with this, I think will be hot on it! I don't know what your feedback is so far, but I think this could be a milestone. When I think of all my old applications! But maybe I am biased because I have already received an introduction into your framework!" 

💖 Thanx René!

Perhaps I need to write some kind of NDA contract (never done before). One thing I want to avoid, after all these hours, is to find my Source-Code as a zip on a hacker site.

Before I could start the Alpha-Phase, I have to:
  1. Open up a ticket system or some kind of bulletin board?
  2. Perhaps a discord server?
  3. Perhaps a slack group?
  4. Think about how to collect User-contributions...
  5. Think about contribution benefits?
  6. Late or discount payment for Alpha & Beta users? 
How do I distinguish between a developer who "just" wants to see cool source code and a developer who wants to actively contribute to the framework? Maybe I should just assume the best and trust that Delphi developers are all super nice people who are interested in using this technology. I think I'll stick with that idea or a very little "fee" just to check if the developer really wants it? Perhaps some kind of reward system?

If you've made it down here - Thanx for reading and please be so kind and fill out my survey!


Posted by at No comments:
Subscribe to: Posts (Atom)