Productivity tips

Productivity is a highly subjective topic. What makes one person productive might not work for another. However, that doesn't mean that sharing your own experience is not useful for other people. If some of the following tips don't work for you, that is perfectly fine.😃 No distractions Nothing kills productivity as much as being distracted all the time: kids, coworkers, bosses, cats, dogs, social media, ... While you cannot always eliminate the source of distraction, you can minimize its impact (at least sometimes). When you know up front that you are going to be distracted, doing highly focused work will be frustrating and totally unproductive. At such times, it is more productive to do some tasks where being distracted will not harm the process as much. At least you will be able to do some work, as opposed to not doing it at all, or doing it poorly. Getting into the Zone Not all distractions come from the outside. If your own state of mind is not in the right place, pus

Are generics slow?

In the TCoffeeAndCode session about "Code Profiling, Optimization, Performance, and Memory Leaks", it has been mentioned that generics are slow. However, no specific details were given, and this topic deserves to be explained in more detail before people start indiscriminately removing generics from their codebases, hoping to gain some speed. You can watch the session replay at: (minute 56) How generics work In order to understand how generics can impact speed, we need to know how generics work under the hood and why they are useful. The simplest way to explain generics is to imagine you have some particular code you need to run on different types. And to achieve that, you copy-paste the code and replace one type with another and nothing else. This is how generics work in C++, where they are not called generics, but templates. Instead of you having to copy-paste code and replace types, the compiler does that for you. Generic c

Virtual methods in Delphi

Virtual methods enable subtype polymorphism - in other words, they allow implementing different behavior in descendant classes. That means if you have a base TShape class with a virtual Paint method, and several descendant classes like TRectangle , TCircle and TTriangle , then each of those subclasses can implement a different Paint method to appropriately paint itself. You can call the Paint method on any shape instance without needing to know which kind it is, and it will be correctly painted. Static vs dynamic dispatch Virtual methods can achieve polymorphism via a mechanism called dynamic dispatching at runtime, while non-virtual methods will be statically dispatched (bound) during compilation. Polymorphism cannot be achieved by statically bound methods—in other words, when you call a statically bound method, you will call the same implementation for all descendant classes. Static dispatching means that the compiler will resolve the method address at compile time, and will

Building better serialization

The "When in Rome, do as the Romans do" blog post series used serialization as an example of what happens when applying inappropriate coding patterns for some language. It demonstrated how field-based serialization does not fit well in Delphi, and how published-property-based serialization is more appropriate. But it also briefly covered some poor serialization practices, that are not language-specific. For instance, attribute-based configuration is widely used across various languages and serialization frameworks, and for the same reasons such a configuration style is a poor practice in Delphi, it is a poor practice in any other language. Knowing what constitutes a good serialization framework is important regardless of whether you are assessing an existing framework or building your own. While this article approaches serialization from a Delphi point of view, the listed principles are valid in—and can be applied to—any language. Configuration and attribute based seriali

When in Rome, do as the Romans do - Part III

In Delphi, properties can be backed by simple fields, but they can also have getter and setter functions that can be vital to the proper functioning of a class. They can contain additional initialization code, protect the consistency of the object's data, prevent invalid input... Photo: Gary Todd from Xinzheng, China, PDM-owner, via Wikimedia Commons, As you might guess, field-based serialization does not call the appropriate getters and setters, and can cause runtime malfunctions. On the other hand, property-based serialization calls getters and setters if any exist. This is another thing to consider when using REST.Json , which uses field serialization instead of property serialization. REST.JSON ignores property setters

TCoffeeAndCode: Threading and Concurrency Replay

Did you miss the TCoffeeAndCode session on "All about threading and concurrency"?  The webinar replay is now available!  Hosted by Jim McKeeth and his guests: Frank Lauter, Primož Gabrijelčič, Olaf Monien, Kelver Merlotti and Dalija Prasnikar.

Mastering Delphi Memory Management Webinar Replay

In case you missed the live session, webinar replay Mastering Delphi Memory Management where I am answering your questions about memory management is available on YouTube.  Book intro by Neven Prasnikar Jr. followed by a recording of live Q&A chat hosted by Jim McKeeth. Webinar replay: Book info: Thank you all for joining live session and watching!