Embarcadero Conference 2019 in Brazil: Meet the NFC-e Issuer in the Cloud

On October 22nd, 2019, there will be another edition of Embarcadero Conference. It’s the biggest Delphi event of the world, and happens in São Paulo, Brazil. There are hundreds of attendants.

In this edition, just like last year, there will be seven simultaneous sessions, all happening in the same auditorium. You choose which session to listen by selecting the audio channel in your headphones. The full session list is available in the site of the event.

With som many sessions happening at the same time, you get even anxious to choose which want to watch. But if there is one that you cannot miss, it’s this one we are going to suggest.

Our speaker, Wagner Landgraf, will be presenting the session “Anatomy NFC-e issuer in the cloud (REST API). Oh yes, we are recommending our own session. But that’s just a coincidence, it will be very interesting, believe me!

Why “in the cloud”?

Ok, let’s anticipate some content here. Why of the reasons is the “why”. NFC-e is a legal digital document in Brazil, and when we issue such a document in the cloud, we have several advantages compared to the issuing of the same document in a local desktop or mobile application:

  • One single and centralized place to configure the issuing environment (installation of certificates, configuration of cryptography libraries, etc.)
  • Minimizes the risk of problems and support cost: you don’t have to configure hundreds of client environments
  • Much easier system update and maintenance: you also don’t need to manage all the clients.
  • You can issue NFC-e from any platform (from a desktop Windows application, a mobile application, or even from Rasperry PI, who knows?). All you need is internet connection and HTTP communication on that platform.
  • It’s easier to develop clients in other platforms. No need to be able to port and compile several 3rd party libraries needed for the document issuing, like ACBr, FastReport, FortesReport, cryptography dlls or tools, etc.

Can you disclose a little bit more?

To give you a tease of what will be presented, here are some screenshots of the API that we will show and explain at the event:

Not only that…

This will be a really interesting session. There will be an additional surprise that for sure will be very interesting for all those who work with Delphi and deal with such legal Brazilian documents. That’s just the beginning… See you at Embarcadero Conference 2019!

Databases inside Delphi Ecosystem: Webinar

On October 10, Softacom is holding a webinar on “Databases inside RAD Studio & Delphi ecosystem. Migration process (legacy to up-to-date, to another RDBMS), data layer architecture (ORM), data access architecture (REST API)”.

Speakers

Wagner Landgraf from landgraf.dev will be one of the speakers, talking about how database access evolved in Delphi since the early versions, Object Relational Mapping (TMS Aurelius), REST API Servers (TMS XData) and remote database access (TMS RemoteDB).

Serge Pilko

Serge Pilko

Embarcadero MVP & CEO of Softacom – Enterprise digital transformation & software modernization services expert

Wagner Landgraf

Wagner Landgraf

CEO of landgraf.dev / TMS Software Partner / TMS Business Product Manager

Bruno Fierens

Bruno Fierens

Embarcadero MVP & CEO of TMS Software – Main player as Delphi and C ++ Builder 3rd party vendor

What will you learn

For CEO / Owner / CTO / IT – Director / Product Manager:

  • Up-to-date Delphi solutions and frameworks for communications with databases;
  • Pitfalls of migration to up-to date or another type of RDBMS;
  • Cutting-edge Delphi-related solutions and practices for RDBMS;
  • Arguments, why you have to use Delphi and RAD Studio for your multi-tier applications;

For Developers and Technical Specialists:

  • Best practices for developing data access layers for RAD Studio projects;
  • How to use ORM for Delphi projects;
  • How to develop REST API server as DB facade;
  • Insights, tips and tricks for the app developers from the first mouth of DB tools and DB framework developers;

Webinar Highlights:

  • Most popular data access patterns 10-15 years ago and today;
  • Pitfalls of migration legacy versions of RDBMS to up-to-date versions;
  • Pros and cons of migration to ORM instead of using regular practices;
  • ORM for Delphi ─ TMS Aurelius from TMS Software. Pros and cons of the solution;
  • Pros and cons of migration to REST API instead of using “classic” DB access;
  • REST API server for Delphi ─ RAD server. Pros and cons.

For webinar attendees only!

Don’t miss a chance to get your discount promo code for EKON conference and 10% discount for new TMS Software licenses.

Registration

Registration link: https://www.softacom.com/en_softacom_october_webinar

5 Reasons to Use Inline Variables in Delphi

Inline variables declaration is a feature introduced in Delphi Rio 10.3. What is it?

In short, it is the possibility to declare a variable in any line of your code. That is, you can declare a variable this way, within the begin..end block:

procedure Test;
begin
  var I: Integer;
  I := 22;
  ShowMessage (I.ToString);
end;

A lot of people already understood how this feature works, but did not understand why it is interesting. In this article, I will show you this new feature with a focus on the advantages it brings.

1. Organizes your code

The variable is only accessible from the point it is declared. For many people this better organizes the code in a large method, because it is possible to know better where that variable is being used. Consider the following code:

procedure Test;
var 
  A, B, C, D, E: Integer;
  Found, Done, Excluded: Boolean;
  Text: string;
begin
   // many
   // lines
   // of
   // code
end;

It may be confusing to know where all of these variables are used, when they are being initialized, if it has been set a value before, etc. In the following code, we know that the Text variable, for example, does not exist at the beginning of the code, and that it is only used at the end. No code changed its value bfore that part of the code:

procedure Test;
begin
   var A, C: Integer;
   // We cannot use Text here
   // lines
   // of
   // code
   
   var Text: string;
   // Text can only be used here
end;

2. Minimize bugs

Have you ever done something like this:

procedure Test;
var I: Integer;
begin
  for I := 0 to Count - 1 do
    Process;
  DoSomethingWithI(I);
end;

That is, using the for variable after the loop is finished. This is not safe, and although the compiler raises a warning for this, many people ignore it. By declaring the for variable inline, it will be only valid inside the for, and using it outside the block will result in a compilation error:

procedure Test;
begin
  for var I: Integer := 0 to Count - 1 do
    Process;
  DoSomethingWithI(I); // Compile error!!!
end;

The benefit from the code above comes from the fact that the scope of the variable is limited to the block in which they are declared. That minimizes the chance of errors. For example, suppose you have a code like this:

procedure Test;
var I: Integer;
begin
  I := CalculateSomething;
  Persist(I);
  // many lines below...
  Log(I);
end;

Then you eventually need to refactor the code in a way that the first part only executes under a specified condition. You think that variable I is only being used there, and do something like this:

procedure Test;
var I: Integer;
begin
  if Condition then
  begin
    I := CalculateSomething;
    Persist(I);
  end;
  // many lines below...
  Log(I);
end;

There, you forgot the last line and maybe the value of I is not what you expect. Changing the scope of your variable to the block will generate compilation errors if the variable is used outside the block, which will show you the problem immediately, so you can make a decision:

procedure Test;
begin
  if Condition then
  begin
    var I: Integer;
    I := CalculateSomething;
    Persist(I);
  end;
  // many lines below...
  Log(I); // Compile error!
end;

3. Less typing

Who does not want more productivity? If you can type a bit less to declare a variable, why not? You can now declare and initialize a variable at the same time:

procedure Test;
begin
  var I: Integer := 22; 
  ShowMessage (I.ToString);
end;

But not only that. There is also type inference, which means that in most cases you do not need to include the variable type when declaring it. Just initialize the variable with a value and Delphi will know the variable type.

Looks like it’s not a big deal? Imagine a case where the variable type is using heavy generics:

procedure NewTest;
var
  MyDictionary: TObjectDictionary<string, TObjectList<TMyAmazingClass>>;
  Pair: TPair<string, TObjectList<TMyAmazingClass>>;
  List: TObjectList<TMyAmazingClass>;
begin
  MyDictionary := TObjectDictionary<string, TObjectList<TMyAmazingClass>>.Create;
  MyDictionary.Add('one', CreateList);
  Pair := MyDictionary.ExtractPair('one');
  List := Pair.Value;
  ShowMessage(List.Count.ToString);
end;

Using inline variable and type inference, you can rewrite the code this way:

procedure NewTest;
begin
  var MyDictionary := TObjectDictionary<string, TObjectList<TMyAmazingClass>>.Create;
  MyDictionary.Add('one', CreateList);
  var Pair := MyDictionary.ExtractPair('one');
  var List := Pair.Value;
  ShowMessage(List.Count.ToString);
end;

Better, isn’t it?

4. Increases performance

The fact that the variables belong to a more limited scope (within a begin..end block) can even increase code performance!

You can see more details in this excelent article: Inline Variables can increase performance. In summary: the variable will initialized only if the code execution enters the block, and finalized only upon block exit. In this code, for example:

procedure TestInlineVars(const ACondition: Boolean);
begin
  // BEFORE
  if (ACondition) then
  begin
    var S := 'Inline String';
    var I: IInterface := TInterfacedObject.Create;
    var F: TFoo;
    F.S := 'Managed Record';
  end;
  // AFTER
end;

Variables S, I and F are managed types (string, interface and record). The compiler automatically adds initialization and finalization code for them.

If you call TestInlineVars procedure a million times, it will have a big impact. However with the code above, the variables will only be initialized if ACondition is true and the block is actually executed. Less unnecessary code being executed.

5. Makes it easier to use conditional directives

This feature can help even in small things. This article brought my attention: Unexpected Benefit of Inline Variables: Conditional Blocks.

If you use compiler directives where you declare and use different variables for each situation, you have also wrap variable declarations around a compiler directive as well:

procedure DoesSomething;
var
  {$IFDEF CASE1}
  var1: Integer;
  {$ENDIF}
  {$IFDEF CASE2}
  var2: Integer;
  {$ENDIF
begin
  {$IFDEF CASE1}
  // use var1
  {$ENDIF}
  {$IFDEF CASE2}
  // use var2
  {$ENDIF}
end;

Boring, huh? In my opinion this is easier:

procedure DoesSomething;
begin
  {$IFDEF CASE1}
  var1: Integer;
  // use var1
  {$ENDIF}
  {$IFDEF CASE2}
  var2: Integer;
  // use var2
  {$ENDIF}
end;

I believe that inline variables still brings other subtle benefits in specific situations that are not listed here. If you can think of any other benefit, leave your comment. If you do not agree and you think inline variables are not good news for Delphi, leave your comment as well. Just do not forget one thing: if you didn’t like it, simply don’t use it!

What I liked about Delphi/Rad Studio 10.3.2 update

Embarcadero has just released a new Delphi Rio version (which means also Rad Studio and C++ Builder): version 10.3.2. It’s a minor update – meaning product codename is still “Rio”, and it’s binary (DCU) compatible with previous 10.3.1 version.

Why then, an article about a minor update? Usually minor updates contain just bug fixes and small improvements, however it’s not the case of this one. I will mention here two improvements that I personally found significant. It’s also worth mentioning that Embarcadero has recently published the updated Rad Studio roadmap – May 2019 which lists the probable new improvements in upcoming major versions. Now to the improvements in this release:

macOS 64-bit support

Delphi 10.3.2 finally supports macOS 64-bit platform. If you develop macOS applications with Delphi, you know how much this is important.

Apple has been planning moving all macOS applications to 64-bit for years and informing users and developers that 32-bit macOS applications will be deprecated soon. And the time has come. When using macOS Mojave and trying to run 32-bit applications (the ones built with Delphi until 10.3.1, for example), users are receiving the following message:

App is not optimized for your Mac and needs to be updated

I would say that your application wouldn’t give much confidence to the user, do you agree? And, finally, in next macOS release, macOS Catalina (10.15), 32-bit applications will simply not work anymore.

Thus, if you develop (or intend to develop) macOS applications with Delphi, it’s a relief to know that you won’t have those problems anymore: just build 64-bit macOS applications and everything is going to be alright!

IDE stability and performance

Another improvement that is worth mentioning is the significant improvement in IDE stability and performance. First Delphi Rio version brought us a refreshed IDE, with dark theme and more modern visual. But there were also issues: flickering, strange visual “effects”, slowness, the screen was redrawn several times when you resized the window, among other things.

That was significantly improved in this new update. If you are already using previous Delphi Rio 10.3 or 10.3.1, I believe you will notice the difference, with a smoother and snappier IDE in this regard.

Delphi Rio 10.3.2 is already available! There are many other improvements besides the ones mentioned above. If you are already using this new update, leave a comment telling what do you think about it!

What are memory leaks and what are their consequences?

A memory leak happens when your application allocates a space in memory and never frees it again.

How memory leaks happen in Delphi

In a Delphi application, memory spaces are allocated and released all the time. This is often done automatically by the compiler or by the RTL – for example, when allocating variables of primitive types, parameters that are passed to functions, etc. – and we usually do not have to worry about it.

However, there are many cases where we allocate memory manually. Instantiating an object is one of them:

Obj: = TMyObject.Create;

The code above will allocate a memory space and the Obj variable will point to the address of allocated memory space. To release it, you can use the Free method:

Obj.Free;

If the developer forgets to call the Free method, the memory space associated with the object is never released. We have a memory leak.

Consequences of memory leaks

You may wonder: "What’s the problem? I’ve seen this happen in my application and I’ve never had any practical problems!"

Actually, we often don’t see issues when there are just a few memory leaks, and the consequences also depend on the type of applications:

Client applications (desktop or mobile)

In general, in desktop or mobile applications, the consequences are not very serious. In current operating systems, the memory allocated by the application is generally released when the application is terminated, so as not to cause system instability.

Even so, if your application generates a lot of memory leaks, there may be some problems, caused by excessive memory usage:

  • Slow application and/or system: Disk access may be necessary to get around the memory shortage.

  • Application abrupt closing: The operating system may force application termination due to excessive memory usage. This is more common in mobile applications.

  • Application bugs: Application code that allocates memory can start to crash and cause bugs.

Server Applications

When talking about server applications, the problem gets worse. That’s because ideally you will never close the server – you want it to run "forever" without needing to restart it.

The consequences are almost the same as the ones for desktop applications, but since the server application theoretically should never close, any small memory leak will have consequences in the future. The memory will slowly be consumed over days, weeks, months, and your server performance will degrade, bugs will appear and eventually the server will stop working.

Avoiding Memory Leaks

There are techniques and tools to help you detect and remove memory leaks from your application. This will be covered in future posts.

What about you? Have you ever had issues in your application caused by memory leaks? Do you consider detecting and removing memory leaks a low-priority task compared to other more important things to worry about in your code? Leave a comment!