Jump to content

Arnaud Bouchez

  • Content Count

  • Joined

  • Last visited

  • Days Won


Arnaud Bouchez last won the day on July 22

Arnaud Bouchez had the most liked content!

Community Reputation

80 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Arnaud Bouchez

    JSON as a way to save information in Firebird

    For a regular SQL DB, I would use a BLOB SUB_TYPE TEXT field, to store the JSON content. Then duplicate some JSON fields in a dedicated stand-alone SQL field (e.g. a "id" or "name" JSON field into regular table.id or table.name fields in addition to the table.json main field), for easy query - with an index if speed is mandatory. So, start with JSON only (and a key field), then maybe add some dedicated SQL fields for easier query, if necessary. side note: I would rather use SQLite3 or PostgreSQL for efficiently storing JSON content: both have efficient built-in support. Or a "JSON native" database like MongoDB.
  2. Arnaud Bouchez

    Good practices with nested methods

    I don't agree - don't add new private methods. It is not SOLID. Try to keep the class definition small and readable. Rather add a hidden object or class in your implementation section.
  3. Arnaud Bouchez

    Recommended Cryptographic Library

    Our Open-Source https://github.com/synopse/mORMot/blob/master/SynCrypto.pas has almost all that you require. About performance, it is the only one in the Delphi area using AES-NI and optimized SSE3/SSE4.2 assembly - as far as I know. So it should blow alternatives. It is cross-compiler (Delphi and FPC) and cross-platform (Windows, Linux, BSD... thanks to FPC). For elliptical curves, see its sibbling https://github.com/synopse/mORMot/blob/master/SynEcc.pas It supports only secp256r1 but it is feature complete (e.g. simple CA management) and fast (1 ms to create a key pair, 0.4 ms to sign or verify on x86-64) - also cross-platform and cross-compiler. See the documentation at https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_187 Both are highly maintained, and used on production since years. They don't require any external dll (like OpenSSL) which tends to be a maintenance nightmare on Windows.
  4. Arnaud Bouchez

    Good practices with nested methods

    Yes, @Bill Meyer is right: do not put the nested functions part of the main class. It would break SOLID principles for sure - at least the single responsibility. Always favor composition in OOP. About refactoring and breaking huge functions, you could take a look at those slides: Following these proposals, for code refactoring, I would move the code into dedicated records with methods (or classes).
  5. Arnaud Bouchez

    Firebird Encryption options

    Switch to a n-Tier architecure is the way to go. Keep the database locally on your server computer (or network), then use regular REST/JSON over secure HTTPS for the communication with clients. HTTPS will be much easier to secure and scale than forcing encryption with the database driver. Certificate management is a difficult think to do - I have seen so many solutions running fine... until a certificate becomes obsolete. 😉 We usually use a nginx server as reverse proxy, with https://letsencrypt.org/ certificate management.
  6. Arnaud Bouchez

    Good practices with nested methods

    A quick and simple rule would be to define only mandatory variables as shared for the nested procedures, i.e. above them. That is, try to keep all variables of the main block in the lower part of the code, just before the main block. Just as you did. From my experiment, nested functions are fine if there is only 1 (or 2) of them. Once I reach the number of 2/3 nested functions, I usually define a private record type, with proper methods. It is kept private in the implementation section of the unit. The trick of using a record with methods, and not a class, allows to allocate it on the stack in the main method, with no try..finally Free block. It is much cleaner (more SOLID), and also much more extendable. The main benefit is that it is re-usable: you could reuse some code, in another function. Last but not least, you have the possibility to add a unitary test method, and browse easier the code in your IDE.
  7. Arnaud Bouchez

    With's the deal with "With"?

    with SomeUnitName do doesn't compile on my Delphi 10.3 (nor FPC). Compiler complains with [dcc64 Error] Test.dpr(200): E2029 '.' expected but 'DO' found
  8. Arnaud Bouchez

    With's the deal with "With"?

    @Bill Meyer Is with UnitA, UnitB do even suppose to compile?
  9. Arnaud Bouchez

    With's the deal with "With"?

    What is sure with "with" discussion is that it is a trolling subject in the Delphi community since decade(s). For instance, the topic is about "with" in general, and that @Yaron stated that the IDE debugger has troubles with it. TRect came as a true problem about "with" - I do agree with Stefan. But problem came from Embarcadero, not taking into account existing code base. Just like ARC, or the AnsiStrings... Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar, that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. I like "with" - when properly used for two-liners code - as I wrote. It is a clean way of writing code, "making it easier to read" as wrote Yaron. Similarly, I like "object" more than "record with methods", since it allows easy inheritance - when using high-performance code with pointers and pre-allocated memory buffers/arrays. Of course, with only static methods. This was just my 2 cents, to introduce another POV into the discussion. Nothing is totally black nor white.
  10. Arnaud Bouchez

    With's the deal with "With"?

    Breaking compatibility by adding properties is very likely to break code... My assumption is that you use and maintain your own classes. This was not my point. I didn't mean CarWheel for sure. Wheel, Engine and Drive are fine. a, b and x aren't. And I wouldn't use "with" over two TCar instances, or two classes with a Wheel property. But it would have sense, say e.g. to write something like: with currentCar do CarInfo.Caption := format('Engine %s with %d wheel(s)', [Engine.ModelName, Wheel.Count]); My point was that "As everything powerful can be armful when misused, I like "with", when it is not over-abused". If the "with" scope is small enough to be obvious and safe, fine. Otherwise, use local variables.
  11. Arnaud Bouchez

    With's the deal with "With"?

    As everything powerful can be armful when misused, I like "with", when it is not over-abused. For instance, I like "with", when it has only several lines of scopes. It does make sense to me, when used for a single line. Otherwise, I switch to an implicit local variable: asm generation would be the very same. If you think "with" should be avoided due to its implicit context switch, I guess next step would be to force using self.foo for class properties... just like the $this->foo of Php... what a progress! 🙂 I am against any new warning at compiler level. And if you are confused by with someclass do x := a * b and don't know to which class a, b, or x belongs to, it is time renaming the properties/functions to something more explicit!
  12. Arnaud Bouchez

    Relaxed JSON

    From the relaxed JSON website: I still don't get what a "JSON number" is - from its json.org definition, it is any kind of number with none to any decimals...
  13. Arnaud Bouchez

    Relaxed JSON

    The worse about Relaxed JSON is that it is not reversible. It may change the values. For instance, { number: 1.0 } will become { number: 1 } which is not the same. So for an exchange format, I would never use Relaxed JSON. For a settings local file, edited via vim or nano - why not? but as @David Heffernan stated, YAML (or TOML) sounds like better candidates.
  14. Arnaud Bouchez

    Relaxed JSON

    The mORMot parser supports "extended JSON", as used with MongoDB: field names can be without quotes. It follows in fact the JavaScript object declaration syntax. Internally - between mORMot client and server - it will use it to slightly reduce size and enhance performance. For regular clients (e.g. JavaScript), it will server standard JSON with quoted field names. As @Lars Fosdal states, a rigid format seems better when exchanging data between heterogeneous ends.
  15. Arnaud Bouchez

    General mobile app <-> REST design question

    List of ingredients are stored in at least two MicroServices: the "Pizzaiolo" service (which prepare the pizza) and the "accounting" service (which take into account the ingredients stock, and order them if needed). You may put the list of ingredients in the "Menu" MicroService... if you want to generate an accurate menu. Each service may need additional information: the Pizzaiolo would need to have the weight of each ingredient per kind of pizza, the accounting service may have delivery information, and the menu just need the name...