I'm looking at the documentation, but I find nowhere an information for setting a global variable. We know that the Cloud functions are stateless code snippets, but I want somehow to integrate a global variable which can be changed by an action, read by another one and remain with the last state (true/false).
Is there any way for achieving such functionality?
Function invocations are stateless, so that means there are no global variables. As stated in the comments, you could utilize a database to store state information.
Since you only want to avoid calling an API too often and not have a database, the only other option I see is to modify the action parameters. Utilizing the Cloud Functions API you could update the action itself and switch a parameter from false to true. I would not recommend it.
Related
I'm still learning Flutter and trying to understand best practices.
One of them seems to be that global variables are bad, and recommends using something like Provider instead.
In my case, I have a bunch of settings that are read from the back end when the app first starts. The variables in globals.dart are assigned values on startup, and then don't change after being assigned.
int maxLoginAttempts...
String welcomeMessage...
...
My confusion comes from the fact that most people who've asked this question (that I have found, sorry if I missed a post somewhere) are creating variables whose value may change as the application is used. I can understand something like Provider and ChangeNotifier would work well for that.
But in my case the values are assigned once - and don't change thereafter - they're only read.
So are globals still bad in my case?
In your case no provider/state management is needed if you are just assigning some value to global variable and and its value change does not require widget rebuild.
I'm currently working on a module in PowerShell which uses a standard REST API in the background. For that, I wrote a Connect-Server cmdlet that retrieves an auth key for later calls.
My question is: Is there any best practice regarding sharing the data with other cmdlets? I know I could easily just return it from the Connect function and pass it to the following cmdlet, but that's not what I'm looking for.
Until now, I've been using global variables for that exchange of data. But as I've read in some best practice guidelines you should try not to pollute the global scope.
Other solutions I've seen use Get and Set cmdlets, but I don't think that's the best PowerShell way of doing it.
So are there any other ways of solving that?
The normal way is to return data from one cmdlet and store it either in a variable or forward it to the pipeline. Another way of sharing data might be serializing (ConverTo-Json, ConvertTo-Csv, ...) it to a file (located in e.g. $env:TEMP, or created via New-Temporaryfile), and deserializing it back again in another cmdlet (at cost of DISK I/O). Personally I'm always the result in a variable for lather usage and inject it in the next cmdlet (or use the pipeline).
Using global variables is not the best idea since you don't know on which parameters your cmdlet/function depends on.
So as the guys at PoshCode stated, the best way to do such a thing is using a variable in script scope as this is available for all cmdlets in the module but not visible for users.
Is it possible to get the values for custom variables being used in the build? I know they can be dumped to the console output as per what this example describe. But still want to find an easier way to archive it.
http://www.codewrecks.com/blog/index.php/2017/08/04/dump-all-environment-variables-during-a-tfs-vsts-build/
There isn’t the easier way then the way you provided to retrieve build variables, the value of variable can be changed during the build time (Logging Command), so it’s better to retrieve the variable at the end of the build (the way you provided).
Note, the secret variables can’t be output as general text.
My rules in a drl file will return 1 or more String values back to the calling program.
Right now the way I do that is via global variables as below
global java.util.List<String> statuses;
The calling program will pass it an empty ArrayList() and within my rules, I'll add the String values into the List. Finally, my calling program will retrieve the statuses list that might contain zero or many String items in the list as below
session.getGlobal("statuses")
But in the drools user guide, it said that it's not recommended that rules should change values of the global variables.
Are global variables the best way to return values back to the calling program? If not, what's the best way please? I have to deal with concurrency in my web application as well so I'm looking for the best way to return values back to the calling program for concurrency as well.
Thanks
There is nothing wrong with changing the value of a global variable in the code within the consequence ("right hand side") of a rule. What you describe is one of standard use cases for globals.
What the author of the Drools user guide (please add the exact reference!) meant is that changes of a global that is used in the condition ("left hand side") of a rule are not considered in the (re-)evaluation of these conditions. Therefore, this is to be avoided.
As for concurrency: Use a properly synchronized List object as a global.
This is the problem:
Create a class and set the access to be private for some of the properties or methods.
Use the doc command for the created class. This will auto-generate documentation from your comments and show it in the built-in help browser.
doc classname
The problem is that documentation for the private properties and methods is not shown in the help browser. Is there any way to overcome this problem?
So I spent like 10 minutes using the debugger, jumping from one function to the next, tracing the execution path of a simple doc MyClass call.
Eventually it lead me to the following file:
fullfile(toolboxdir('matlab'),'helptools','+helpUtils','isAccessible.m')
This function is called during the process of generating documentation for a class to determine if the class elements (including methods, properties, and events) are publicly accessible and non-hidden. This information is used later on to "cull" the elements.
So if you are willing to modify MATLAB's internal functions, and you want the docs to always show all methods and properties regardless of their scope, just rewrite the function to say:
function b = isAccessible(classElement, elementKeyword)
b = true;
return
% ... some more code we'll never reach!
end
Of course, don't forget to make a backup of the file in case you changed your mind later :)
(on recent Windows, you'll need to perform this step with administrative privileges)
As a test, take the sample class defined in this page and run doc someClass. The result:
This behaviour is by design - the auto-generated documentation is intended for users of the class, who would only be able to access the public properties and methods.
There's no way that I'm aware of to change this behaviour.
You could try:
Use an alternative system of auto-generating documentation such as this from the MATLAB Central File Exchange (which I believe will document all properties, not just public).
Implement your own doc command. Your doc command should accept exactly the same inputs as the built-in doc command, detect if its inputs correspond to your class/methods/properties etc, and if so display their documentation, otherwise pass its inputs straight through to the built-in doc. Make sure your command is ahead of the built-in on the path.