Leaderboard

The irony about this is that to build a RAD application you are using components that are by design loosely coupled and more or less easily testable in isolation. The issue starts with non-UI-related code written directly into UI control event handlers and accessing global states such as these global form variables. If one would write their RAD application also in a component-driven architecture, things would be way easier - but slapping code into event handlers is quick at first and a nightmare to maintain later.

I don't, but I know how to let the remote work find you: Answer questions on stackoverflow. Answer questions here. Participate in open-source projects. Of course, it helps immensely if you can do that within a narrow field of expertise (to minimize the competition) - or better than most. If you can stomach the self-promoting nonsense in the LinkedIn Delphi group you can also try posting there. I don't use it myself (as I wouldn't be able to behave). ...and start by changing your screen name. I assume your last name isn't 23668... If I wanted to I could live off the remote & freelance offers I get because my name comes up when clients google for info on some special tech they need help with.

Some libraries are not part of GetIt for obscure reasons within Embarcadero decision makers, e.g. our https://github.com/synopse/mORMot2/blob/master/src/crypt/mormot.crypt.core.pas which is probably the fastest AES library able to be statically linked, OpenSource with full source code, and highly maintained, on Delphi (and FPC). And before using AES in your project, ensure you understand its basics: - it is very easy to make something weak, so you need to know a little about today's best practices. - don't reinvent the wheel: if you want to transmit data, use TLS; if you want to store passwords in a DB, don't use encryption but salted hashes which can't be reversed; see if using OS level disk encryption (like BitLocker) is not a better approach; etc... - don't use direct/naive AES in your project, named ECB because it is weak https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB) - consider AES-CTR (or AES-GCM which also makes authentication) for instance. - there is also a need for 16-bytes padding of the encoded output - here Pkcs7 seems the de-facto standard. - something tricky is to create the 128-bit or 256-bit key: you need to have a strong derivation function, like PBKDF2 from human input or at least HMAC-SHA256 if you already have a secret key. - consider also asymmetric encryption: if you can use ECDHE derivation using public keys in your project, this is the way to go - it is much safer to share two public keys between peers and derivate a secret, than sharing a symmetric key, which can be leaked. - a proper IV filling is also essential: a common practice it to generate it from random, and put it at the beginning of the encrypted stream, or even better get this IV from some bits of the ECDHE derivation function. - in practice, AES with 128-bit is enough security for an application - it has more security that RSA-2048 certificates which are still used almost everywhere in the Internet. Our units allows all this, and much more.

Fresh code: https://github.com/VSoftTechnologies/DUnitX Typical code that we test with DUnitX: - value to string and string to value - lookup functions - generic classes - formatters as well as database integration tests (CRUD) How do you guys use it?

If Foo is reference counted type, then GetFoo will require hidden reference created to properly initialize reference counting, regardless of how DoSomethingWithFoo is declared. If it is declared as const that only means there will be no additional reference counting involved (_IntfCopy and _IntfClear) calls. Hidden reference is equivalent of the explicitly declared local variable. It is created when there is a need for holding a reference to something for calling _IntfCopy and _IntfClear methods. If there is already a reference (when passing parameter to some procedure where parameter is not declared as const) then there will be no hidden reference because _IntfCopy and _IntfClear can be called on that reference directly. Same principle applies not only for interface , but also for other reference counted types like strings and dynamic arrays, the only difference is in particular reference counting methods that will be called.

What you want to do is impossible in Delphi (without bringing bad coding practice like Application.ProcessMessages in the process) You cannot have function that will return the result of some asynchronous operation. Period. Asynchronous REST request has events that will run when request is successfully or unsuccessfully finished. In those events you can add logic that needs to run as the result of the operation. procedure TMainForm.ButtonClick(Sender: TObject); begin RESTRequest.ExecuteAsync( procedure begin Memo.Lines.Add(RESTResponse.Content); end, True, True, procedure(Error: TObject) begin Memo.Lines.Add(Exception(Error).Message); end); end; Another way, by running request in task or another thread uses similar approach. In such case you would transform your function into a procedure and pass callback (procedure, method or anonymous method) that will run within thread after the request is completed. If you need to run that code in the context of the main thread you can use TThread.Synchronize or TThread.Queue

Wrong test case. s.LastIndexOf('Hello', 38) will search starting from 38 to the left. That means in this string 'Hello how are you, Hello how are you, H'. First occurrences is at 19 so it "Works As Expected". I know this is not as other implementations but you must specify this in report if you want a change. And this change can brake old code so it must be strongly justified.

Among a few minor things it allows for a more declarative approach of writing tests by using attributes to provide the test data. In a classic DUnit test if you have to test an algorithm with 20 different value combinations you need to write 20 tests (either as different methods or by putting them into one test). However DUnit can be pimped to allow the same so you don't need to migrate (*) - since DUnit is kinda abandoned development wise Vincent decided to roll his own library instead of modifying and possibly cleaning up the code from DUnit which dates way back. (*) I did that way back even before DUnitX existed: https://stackoverflow.com/a/9006662/587106 and later also put that into a unit of Spring4D. As you can see in the screenshot you have multiple tests shown although there is only one method declared the extension takes care of producing them so you can run them individually (if for example certain data produces a failure) while you are fixing it. Another thing (which personally never bothered me much) is that with DUnitX you can write testcase classes without inheriting from a base class (this can also be done with an extension for DUnit - did it but never put it anywhere because it was not useful for me). The last thing that I remember is the fact that DUnitX can do is have fixture setup/teardown - they only run once even if there are multiple tests in the class - classic DUnit runs Setup/TearDown methods before and after every single test - guess what? You can also plug that onto DUnit. My personal opinion: do automated unit tests but it does not matter what framework you are using. I use DUnit with the before mentioned extensions and we do so at work because its powerful and compact. And regardless which one you are using - use them with TestInsight and make them part of your CI. 😉

Essentially all system wide methods are run through DUnitX now. This is how I know that RSP-15040 is still in Rio 10.3.1, I use that when anyone asks why I built my own string helper. Depending on complexity I use TestInsight while coding.