Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 12/30/18 in all areas

  1. A while ago, after my post on Known IDE Packages in Delphi I wrote a the KnownIdePackagesManager tool which lists those packages, allows to disable and enable some of them and also set the package description for those packages that don’t have a meaningful description. Today, I updated the tool to support Delphi 10.3 Rio. https://blog.dummzeuch.de/knownidepackagesmanager-tool/
  2. That's excellent, thanks Andrea. Hope you're feeling better and had a nice christmas break. Regards Stuart
  3. Arnaud Bouchez

    log file policies

    Here is what we usually do: Store logs in a dedicated folder, with proper read policy. -> especially under Unix, all background daemons run with a dedicated user, and the log files have chmod 640 to restrain read access. Always run the logs in Verbose mode, even on production, unless the execution environment is really constrained. (you never know what will happen, and detailed logs is a need for proper investigation, especially on production) -> you need a logging solution which is fast, and can log dozen MB/s with no performance penalty (e.g. our SynLog.pas unit writes in a background thread) Rotate logs to keep history as long as possible -> SynLog.pas has built-in SynLZ-compression of the logs for very fast and efficient rotation Never log passwords, or such sensitive information. -> password are always stored and persisted in salted + hashed form - but when transmitted as parameters, or as settings, they should be encrypted - even a naive encryption may be enough like with a TSynPersistentWithPassword class from SynCommons.pas -> more generally, sensitive information should be handled in memory with strong cryptography, e.g. via our cross-platform CryptDataForCurrentUser() from SynCrypto.pas Have a way to hide unexpected content, when log is automated. -> in mORMot.pas, you can register some sensitive types which parameters will be logged as "***" during SOA automated logging of calls. Ensure all those policies are always setup by default, and on all supported platforms -> today, we should ensure that Linux execution should be not weaker than Windows as a target (and it is easy to make executable safer under Linux) Optionally use a third-party SaaS solution to store your logs in the long term, with proper encryption and search abilities -> like https://livemon.com - server-side written in object pascal 🙂 Most of it is available out-of-the-box in http://mormot.net
  4. Hey, good idea: https://github.com/DelphiPraxis/The-Drag-and-Drop-Component-Suite-for-Delphi
  5. haentschman

    DIMOWA® SQL Resource Creator

    Hi all... A tool that manages the resource strings according to the tutorial mentioned in the german link (https://www.delphipraxis.net/49505-sql-dateien-als-resource-einbinden.html). This is another way to manage SQL statements. The SQL are stored in separate files in a folder structure in the project. SQL can be tested in the preferred DBMS editor. Important: SQL Statements OUTSIDE of the Sourcecode (pas, dfm) in resources *.res. (without SQL.Add; SQL.Add; SQL.Add... ) * Online update if you want * User defined color scheme * Administration Projects * Administration SQL for multiple databases * Management of the status of SQL in the network (colleagues) * Administration of any folders for SQL * Handling like you know it from an editor * Partial string search * the projects / ini are stored in the user directory ! (see todo) Tips 1. create the base folder for all SQL 2. creation of subfolders for project-specific SQL 3. a namespace for the SQL is imho important. (reasonable order and search) Todo: * The project XML stored in your project folder (better for version controls systems) * Partial string search in all SQL files * a smaller encyption standard for version controls systems * English version > 100 users DOWNLOAD > 5MB: http://www.dimowa.com/downloads/dSRG/Setups/dSRGSetup14.zip Lizenz: Freeware for one DBMS Manual: Manual.pdf GUI: Resource clear text: Resource encrypted: Splash:
  6. Dalija Prasnikar

    Delphi 10.3 and supported version of Android

    There are two API levels in manifest (actually, there is another one, but not important) - minSdkVersion and targetSdkVesrion minSdkVersion marks minimum API required by application and it will not run on Android devices with API lower than specified targetSdkVersion marks highest supported API level by application - that means Android will not use any compatibility mode when running on devices with specified or lower API. If you run application on device with higher API level, OS will use compatibility mode for newly introduced API features. Tokyo 10.2.3 (and previous versions) by default had both API levels set to 14. Rio 10.3 changed that and minimum API level is now 19 and target is 26. That means devices with Android version lover that 19 will no longer be able to run applications built with Rio. Conclusion: Delphi application compiled with Rio can by default run on any device with API 19 or higher.
×