I am working on an iOS application that uses a pretty normal multi-environment deployment model. We have a QA, Prod, and "Dev" version of the app that all talk to their own corresponding backends. I am new to iOS development but am familiar with Node, Java, and a few other development environments.
The first thing I reached to for this problem was Environment Variables. I saw that XCode had a way to set environment variables in a Scheme and they could be read pretty easily. So I used 4 environment variables per environment to configure a few needed backend hosts. Everything seemed to be going fine until I realized that those environment variables seem to ONLY be available when running the app through XCode. Is that correct? Is there no way to configure environment variables that "bundle up" with an app? If so, the ability to configure environment variables at all seems like a footgun.
What I mean is, In a NodeJS or Java app, I can set a number of useful "necessary" configs like a backend hosts and use some approach to provide those values when running the app for real. It seems like in iOS / Swift, environment variables are only useful for development-time debugging settings? The asymmetry between what's available in XCode vs a "real" shipped app seems odd.
Is there a similar standard way that I can configure my app for multiple different environments that works on shipped applications and ideally just involves reading some value at runtime rather than using conditionals and/or using compiler flags or something?
You are correct. The Environment Variables are only meaningful when executing the Scheme in Xcode. Their primary use in that context is to activate debugging features that are not on all the time. For example, if you try to create a bitmap Core Graphics context (CGContext) with an invalid set of parameters, the debugger may tell you to set an environment variable to see additional debugging output from Core Graphics. Or you can set environment variables to turn on memory management debugging features.
When you are running an application on a server, the Unix framework in which the application is running is part of the "user experience". In that context it makes sense for the application to use things like environment variables.
As developers we understand that a mobile app is running inside a unix process, but that unix environment is mostly unavailable to us. A similar feature that is common to Unix apps is command line arguments. An iOS application on startup receives command line arguments (argc and argv) but there is no way specify those when the app is launched either.
There are a number of places you could include configuration information like that which you describe in your application. The most common that I can think of is to include the setting in the applications Info.plist. At runtime you could access the contents of the property list by fetching the main bundle and asking for it's infoDictionary:
let infoBundle = Bundle.main.infoDictionary
let mySetting = infoBundle["SomeSetting"]
When the application's info.plist is created, it DOES have access to the environment variables declared in the Scheme so you could put the environment variables in the scheme, reference them in the Info.plist, and retrieve them at runtime from the main bundle.
try Using FeatureFlags, maybe will help you, check this
https://medium.com/#rwbutler/feature-flags-a-b-testing-mvt-on-ios-718339ac7aa1
Related
We are using Pentaho Data Integration V7 working with multiple data origins with an Oracle DWH destiny.
We have stored all the connection access data in a parametrization table, let's call it : D_PARAM. All the connections are configured using parameters (${database_name} ... etc)
We have , at the begining of every job , a transformation with a "set variables" step which reads the right parameters from D_PARAM.
This all works fine, my problem is :
Every time we want to edit a single transformation, or in the development process of a new one , we can't use the paremetrized connections because the parameters haven't been setted. We need then to use "hardcoded" connections during the development process.
Is there a better way to manage this situation ? The idea of having the connections parametrized is to avoid errors and simplify the connections management, but if at the end we need both kind of connections.. I don't see them so useful.
There's not a simple answer, you could rotate your kettle.properties file to change default values, you keep all the values in the file:
D_PARAM = DBN
D_PARAM_DB1 = DB1
D_PARAM_DB2 = DB2
...
And just update the D_PARAM with the one you need from the different D_PARAM_DBN before starting PDI. It's a hassle to be constantly updating the kettle.properties file, but works out of the box.
You could also try working with environments, for this you would have to install a plugin available in Github: https://github.com/mattcasters/kettle-environment, it was created by a former PDI developer, and I don't know if it works with v7 version, it was updated to work with 8.2, but it would probably work with v7, to test it, you can install your PDI version on another directory on your PC and install there the plugin (and other additional plugins you have in your current installation), so you don't break your setup. This blog entry gives you details on how to use the environments: http://diethardsteiner.github.io/pdi/2018/12/16/Kettle-Environment.html
I don't know if the environments plugin would solve your problem, because you can't change the environment in the middle of a job, but for me, with the maitre script to use the environments when I program a job or transform, it's been easier to work with different projects/paths in my setup.
In Spoon you can click on the “Edit” menu and “Set environment variables”. It’ll list all variables currently in use and you can set their values. Then the transformation will use those values when you run.
Also works in Preview, but it’s somewhat buggy, it doesn’t always take updated values.
JupyterHub has various authentication methods, and the one I am using is the PAMAuthenticator, which basically means you log into the JupyterHub with your Linux userid and password.
However, environment variables that I create, like this (or for that matter in those set in my .bashrc), before running JupyterHub, do not get set within the user's JupyterLab session. As you can see they're available in the console, with or without the pipenv, and within python itself via os.getenv().
However in JupyterHub's spawned JupyterLab for my user (me):
This environment variable myname is not available even if I export it in a bash session from within JupyterLab as follows:
Now the documentation says I can customize user environments using a Docker container for each user, but this seems unnecessarily heavyweight. Is there an easier way of doing this?
If not, what is the easiest way to do this via Docker?
In the jupyterhub_config.py file, you may want to add the environment variables which you need using the c.Spawner.env_keep variable
c.Spawner.env_keep = ['PATH', 'PYTHONPATH', 'CONDA_ROOT', 'CONDA_DEFAULT_ENV', 'VIRTUAL_ENV', 'LANG', 'LC_ALL', 'JUPYTERHUB_SINGLEUSER_APP']
Additional information on all the different configurations are available at https://jupyterhub.readthedocs.io/en/stable/reference/config-reference.html
Unfortunately, unlike a single-user Jupyter notebook/lab, Jupyterhub is for a multi-user environment and the customization along with setting security is not some concrete area. They provide you some default settings and a ton of ways to customize the use, alas they provide only a handful amount of examples. You need to dig into documents, check for similarities to your use case, and make adjustments in a trial-error process.
Fortunately, other than using configuration files used to configure Jupyterhub and Jupyter notebook servers, namely jupyter_notebook_config.py and jupyterhub_config.py, we can use environment reading packages per user. This flexibility comes from the use of a programming language kernel.
But this needs being able to install new packages, having them already installed, or asking admins to install them on the current kernel.
Here is one way to use customized environment variables in the current workspace.
Create a new file and give a clear name to show it is an environment file. You can have as many different files as you need. Most production exercises use the .env name but jupyter will not list dot files in file view so avoid doing that. Also, be careful about quotes; sometimes you need them, sometimes you get errors depending on what library you use and where you use them.
test.env:
NAME="My Name"
TEST=This is test 42
Install and use your preferred environment file reader then read from the file(s) you want. you can use `pip install`` in the notebook when needed, just use it cautiously.
test.ipynb
#package already installed, so installation commented out
#%pip install python-environ
import environ
env = environ.Env()
env.read_env(env.str('ENV_PATH', 'test.env'))
NAME=env("NAME")
TEST=env("TEST")
print(NAME," : ",TEST)
If you are an admin of the hub, then beware of the use cases for libraries such that some may break your restrictions. So keep an eye on what permissions you give to your users. If you use custom docker images though, there should not be a leakage as they are already designed to be isolated from your system.
I'm new on this technology (studying for now) and I have a doubt on how to properly work with the Apps.
For example, I have an app-gateway with 2 instances (Traefik), and in there I'm using env variables like RESTRICTED_NETWORK_01 and RESTRICTED_NETWORK_02.
I want to replace de IP value of RESTRICTED_NETWORK_02 and apply the change without any impact to the gateway/redirect users service.
Should I just use the command:
cf set-env app-gateway RESTRICTED_NETWORK_02 [ipvalue]/24
then
cf restart-app-instance app-gateway 0
wait until the instance restarts and apply
cf restart-app-instance app-gateway 1
Is it the right steps I should follow for this situation?
Any help?
cf restart-app-instance app-gateway 0
This will probably not do what you want, at least not reliably. This command works by terminating your application instance, which then allows it to be restarted. It's typically useful if you have an app instance that's in a bad state but hasn't crashed or failed health checks (or for demos where you need to make an app crash).
In terms of env variables, it doesn't work so well. This is because the env variable changes you've made reside in Cloud Controller, but your application runs on the scheduler (Diego). The scheduler has a copy of data from the Cloud Controller that tells it how to run the app, including environment variables that should be set. The command you're referencing doesn't result in Cloud Controller updating the application definition that it has sent to the scheduler (Diego). It simply results in the process being terminated and restarted by the scheduler using the same definition.
Your mileage may vary on this one, as I've heard some reports of people saying that cf restart-app-instance works for updating env variables (I don't really see how it would, but I haven't investigated their claims either). You could try it and see, but the stories I've seen have typically ended with problems. tl-dr it doesn't consistently work.
To reliably update env variables, you need to use cf restart. This will restart all application instances.
What you should do to restart app instances without downtime is to use the cf restart --strategy=rolling option (available in version 7 of the cf cli). This will roll out the changes and so long as you have multiple application instances, should not result in downtime.
i am trying to store my api keys in a variable via the terminal but i am unsure why it is not saving/storing my api keys.
for example, in the terminal when i type the below:
export GMAIL_USERNAME="myname#gmail.com"
then when i type in env i can see the varaibale has been stored:
but when i restart my terminal the variable GMAIL_USERNAME="myname#gmail.com" is no longer there
could one tell me where i am going wrong? all i would like to do is
store in development my api secret keys in a variable. your help would
be much appreciated
While you can persist environment variables by adding them to a script that gets called on shell startup, that approach has a few problems.
The biggest problem is that they are available globally across your shell, and not scoped to a project.
What happens if you have another project, and want to use a different gmail account?
A better solution is using dotenv or direnv and set those environment variables for the current project only.
if i change hkey_current_user/environment/path in registry, get-env "PATH" doesn't reflect the new value unless I close rebol console and re_open it.
Environment variables are not the same things as Registry Keys.
Windows does consult particular registry keys when it is setting up the default environment a program gets when it launches from the shell. However, changing it won't inject those values into the environments of already running processes (in Rebol or any other program). Conversely, if you set things in the environment of a running program you won't see those changes reflected back into the registry.
If you want to read registry values, there is an API for that:
http://www.rebol.com/docs/sdk/registry.html
BUT rightly or wrongly: it is generally accepted (on every platform I've used) that one must exit a program and restart it in order to refresh environment variables from system settings. If you try and work around that, you may cause more complexity and confusion than anything else.