If you’ve got a couple of VMs, then trimming them occasionally will help with storage management on the host. Disk files (like VDI and VMDK images) will grow over time if the VM was configured to expand the disk as needed – but they will never shrink on their own.
This was tested on a Windows 10 VM managed by VirtualBox, the starting file size was over 40GB, as it had been used for various roles and grown over time.
For me, the bare minimum when it comes to app configuration in Qlik Sense or QlikView is:
– Setting paths and libs for use in data load script
– Setting “boilerplate” variables – e.g. the number/date/currency/etc formats
– Setting HidePrefix, SearchIndex and other app-specific behaviours
– Setting Product or Customer specific settings for consumption in the UI
In a multi-product/customer setup (see this previous post about deployment frameworks for context) where we follow common standards for names and folder structures we can streamline this configuration to reduce the maintenance and deployment burden.
In the absence of a source control system like SVN or GIT, a quick and easy way of capturing changes in a app is to update a version control tab before passing the app back to other developers, or onto testers.
This is a very low-tech solution, but the format below works well in shared environments. The first two tabs of your application should be:
– Version (explain the app and list changes you’ve made)
– Config (set the configuration values like paths, dates, etc used in your application’s data load and UI)
Any environment with more than on developer will quickly lose consistency of attributes across the environment. Agreeing standards as part of developer onboarding, and validating these before app acceptance is very important.
An example set of naming conventions is discussed below. This assumes a common directory structure similar to a Qlik Deployment Framework (QDF) model.
The example below follows a concept of one common container (for data and files which aren’t app specific), and a hierarchy of product (one or more applications developed for a specific purpose) followed by customer (a standalone version of those applications, loaded with different data).
The resulting directory structure is therefore Root > Product > Customer.
On Demand App Generation (ODAG) was an approach introduced in Qlik Sense 3.0 to use the Qlik Analytic Platform (QAP) APIs to create Qlik Sense applications for very large or frequently changing data sets.
Domo is a cloud visualisation tool that offers a wealth of connectors (400+ according to their website) and a simple learning curve.
I thought I’d have a go connecting to the same google analytics account as I did with Qlik Cloud a while ago. This will be using the Domo free tier, which you can use to share up to 50 cards at the time of writing.
I have an installation of the 3arcade script that’s still in the wild, and decided it was time to update it to work with PHP 5.6 (at least).
These changes fix:
– a row 0 error in play.php linked to deprecated functions
– deprecation of the ereg_replace function through use of intval
– deprecation of the mysql_connect function (and future deprecation of mysql* functions) through use of PDO
– consistency of database connection and query errors with a variable in the config file