Neural Network - Part 2 is coming

First of all: I'm Sorry about by short blogpost from march 2018 about Neural Networks.

It is the second most-read post I've ever done and it has nearly no information in it...

It is part of my FDK - and normally I do not share this code - but perhaps I will do it this time.

If I have some samples to show I will come back to the topic.

Is wrong always bad?

In software development, there are often (too) many ways you can solve a goal.

But how do I find the right way?

Perhaps you saw this approach in other sourcecode or at a conference. You downloaded the code from Bitbucket or GitHub... Perhaps you found it in a book…

I often heard:

- It's the Microsoft way - they know how to do things - don't question this.
- This is a pattern - you have to do it by the book - more intelligent people have hammered this in stone

or the other side

- don't use this - it's part of the language, but do not use this (With, FreeAndNIL, Goto)

Who is able to decide what is right or wrong and if it is "marked" as wrong is it so bad to use or do it this way?

Is it really so, that out there are only a very few who set the rules? Yes I think so. I call them Book writers or "Head of the Team". Do not get me wrong - these guys are very talented, and they know how to do things. And for our Delphi?

The count for  "Head of the Team" is much smaller than on C, C++ or C#. (btw. from my point of view, all other languages do not count, especially if they do not result in CPU binary code)

But what if you do it in another way, what if you like to do it "called wrong" and what if your way is a better way for you? 

My Answer is: Then do it this way.

If your code is still: Readable, maintainable, stable and testable. Compile it, ship it and earn you money. 

Why should I do things only by the rule book? - But wait… Perhaps another developer doesn't understand your way and could not use your source or library. Yes, you can write it in your documentation and answer RTFM.

For a good library or component, there is no need to look into the documentation. Is it so? If yes we are all using stuff the is build decades ago… And yes we do, and we're dealing with this every day.

You like a small example? OK, find the bug:

var

  i : integer;

  d : TDateTime;

begin

   D := now;

   i :=0;

   while i < 30 do

     begin

       incDay(d);

       inc(i);

     end;

end;

From my point of view - it is a bug - but the answer is "We don't want to cause problems to existing code" - bug-report closed. So we still have to look at the documentation. I would have been so happy if they have used this answer at implementing Unicode as default into the compiler.

If you are working with a team or writing code that is used by many other developers you have to do things as your audience would expect it. OK... I agree.

But I often like to do things my way because it is - from my point of view - the better way. That's why I have my own MVVP 2.5 Pattern, my FluidCreator or Fluent-Creator, my own Binding and not the visual live binding, do things in code and not in the object inspector, create a database with a creation pattern, have a wrapper for FireDac, a wrapper for AppTheathering, a wrapper for Bluetooth, a wrapper for Streams, a wrapper for exception handling, many wrapper to do threading, IDictionary and normally everything thread-safe…

Perhaps one time in the future - I like to do this since 20 years - I will write a book about this and become part of the "Book writers"...

We will see…

But first I had to travel to a planet with a slower rotation speed!

Where to do the Synchronisation?

While designing a new class/function there are some thoughts to do.

1. Could it be useful to others?
2. Could I use it in other Apps?
3. Could it be useful to have it as TWhatever<T>?

So if one of 1-3 is true - I have a new class/function in one FDK-Unit or perhaps a new Unit at all.

The next thing is: Where would I like to execute this stuff - Main-thread or Background? If the answer is Background the next question is how! With existing threads or a new one? Should the User just place it into a TTask.Run?

Threading is a big part of the FDK and there are 14 Units at the moment dealing with threading. Some of them using a basic thread implementation from another unit, some implementing their own Threads because of special needs.

So for this blog post lets assume background operation, but every background execution has some point of the interface into the Main-Thread. And here comes the question:

Where to do the synchronization? 

Let's have a little example:

Procedure Button1Click(Sender : TObject)

var

  LMemoText : String;

begin

  Button1.Enabled := false;

  TAsync

  {} .Await( Procedure

               begin

                 LMemoText := THTTPRead.URL(SomeURL); 

               end )

  {} .Execute( Procedure

                 begin

                   Memo1.Lines.Text := LMemoText;

                   Button1.Enabled := true;

                 end );   

end;

So the Await procedure is running in a thread, that's why I set a string and not directly the memo. The Execute procedure is called in MainThread to handle UI-Stuff. So the synchronization is handled internally. It could be different... But this is the common usage of this TAsync. I Could write it so: 

Procedure Button1Click(Sender : TObject)

begin
  Button1.Enabled := false;

  TAsync

  {} .Await( Procedure

             var 

               LMemoText : String;

             begin

               LMemoText := THTTPRead.URL(SomeURL);

               TThread.Queue(NIL,Procedure 

                 begin

                   Memo1.Lines.Text := LMemoText;

                 end);

              end )

  {} .Execute( Procedure

                 begin

                   Button1.Enabled := true;

                 end );   

end;

But in this example the synchronization is done twice...

Back to the question: Is the internal synchronization of the Execute part a good idea? In the example I think yes. 

Sometimes internal synchronization could be a bad idea especially if TThread.Synchronize is used and not Queue but in the next example even Queue did not help, and here is the reason:

Normally I would do any HTTP related things with a callback, but for this example I like to show a Modal-Call of an Async function, just for Demonstration.

Procedure THTTPRead.URL(Const AURL : String) : String;

var

  LEvent : TEvent;

  LResult : String;

begin

  LEvent := TEvent.Create(NIL,true,false,'');

  

  try 

    THTTPTAsync.URL(AURL, Procedure (Const AResult : String)

      begin

        LResult := AResult; 

        LEvent.SetEvent;  

      end);

    LEvent.Wait;

  finally

    LEvent.Free;

  end; 

  Result := LResult;

end;

Don't do this ;-) but if, then hope that the Result procedure is not called in a TThread.Queue, because this would be a dead-lock. If you have a Threaded or Async Class/Function use it always as it was designed for. 

On the other hand, I hate to put in a TThread.Queue in every Call-Back that's why I often design an optional parameter.

THTTPTAsync.URL(AURL, Procedure (Const AResult : String)

  begin

    _Result := AResult; 

    LEvent.SetEvent;  

  end,false); // false = no sync

For better code reading perhaps rename the call like

THTTPTAsync.URL_NoSync(AURL, Procedure (Const AResult : String)

  begin

    // Whatever

  end);

or

THTTPTAsync.URL(AURL, Procedure (Const AResult : String)

  begin

    // Whatever

  end,TSync.No); // TSync = (Yes,No);

Honestly, I mostly just use a boolean, but I'll put it on my list for refactoring.

So with this approach, I have the best of both...

App-Development, Cloud-Server and distribution to multi clients!

Cloud-Database.. (And many more...)

OK - It's just a computer at another location - so what is this blog post about?

It's about the next step form my last blogpost: Database and Server synchronization.

In many conversations with other developers, most of them want to build a mobile app that is kind of an Access Point to the data used by one or more  PC-Application(s).

At first - no Form from the Desktop App should be taken into the mobile App!

Designing a mobile App with a "smaller" UI, to achieve some of the basic functionalities that are necessary to handle the data, is not a big deal. If you are new to FMX, it just takes a while.

So how could you overcome the problem of not reinventing the wheel and perhaps reuse the work for the next App, too?

BTW: Thank you for reading my blog… This blogpost is again just for advertising my Firemonkey Development Kit. ;-)  (sorry, linked post -  is not translated, yet)

Best practice for the development of libraries like my FDK is as always: "Eat Your Own Dog Food".

And I can promise  -  I eat it every day! It saves me a lot of time and things are always easier.

The next version of the FDK would have some new plugins.

1. Simple ORM
   Just create a class with some Field-Attributes and you'll get a Database with a Table to store the Fields. (nested Tables are also supported, for multi entries like 1-n Bank accounts or 1-n communication - subtables )
2. CRUD IO
   You like the easy CREATE / READ / UPDATE / DELETE access of your data. Set some Class-Attributes and use the simple ORM model to build your application.
   An Easy SQL-Producer is included.
3. MVVM 2.5
   How to Access the Data? Just bind (in Code) the View to your ViewModel/Model (CRUD->ORM) class and you can easily display the Class from (1) on your View.
4. All your Events - PropertyChanged - are auto-connected with one line of code. You can multi-connect data to 1-n UI-Fields. Data->View, View-Data and Bidirectional, with optional converter functions. There is no need for a special UI-Component and there is nothing to drop onto your form. As described in this post.
5. Async Await
   Perhaps you know Async Await from C# - I have a "lite" Version for UI/Async/Threading tasks included.
6. Async Threading Command Queue
   The Threaded-Command Queue is for SQLite/Embedded Databases that can only handle one Thread/Connection at the time. Define your Data-Access-needs and just call them by Name. The Queue will handle all your calls one after another - or if you have some important stuff to do, you can call it prioritized.
7. JSONStore-Server
   A "just use it" Unit to store every data you like in JSON Format on your server database.
8. REST-JSONStore-Client
   To handle the JSONStore Server-Side you get the Units to handle all transfers/updates/locking/rebuild features to do your data-exchange with the Server or/and multi Clients. Of course, this module has the Async Threading Commands for the module (6) included doing everything in the background.

So what is the deal? My goal for mobile App creation was:
Create your UI - create your Classes - just set some Bindings and Field-Attributes. Nothing to drop on your form and nothing to set in the object-inspector!

Just write some uses and have fun...