I'm just starting to learn how to build an Action with Scenes and Intends. Very basic. I see that prompts can be defined in JSON. Is it possible to export the whole Action in JSON format for me to edit it outside of the UI? and then reimport it?
The idea is that if a have a very simple Action (with lots of scenes, but easy intends) I can define the whole action in a much simpler format and automatically create the JSON that could be imported. It would be much faster for me than defining each scene in the Actions Console.
Sort of.
You can use the gactions command line tool to export and import the configuration files. These completely represent the same things that you can edit using the web-based graphical editor.
However... these files are in YAML, not JSON. Semantically, they're identical, so you will still be able to create something that generates the files.
To download your configuration into the current directory you'd use the gactions pull command and specify your project ID with the --project-id parameter:
gactions pull --project-id some-project-4242
You'll see that the Scenes and Intents each have their own folders under custom where you'll be doing your editing.
Once you've made the changes, you can upload the configuration with
gactions push
(Note that you can't specify the project ID, since this is in one of the configuration files.)
You can then reload the test simulator and test your changes.
Related
I'm building a program that acts on files that it has to download from one of my company's servers. We have several million of these. For instance, my normal invocation could be:
python my_script.py file-id
And then my_script.py will go download file-id and do its work on it.
It's useful to be able to specify one fixed file to download and act on while I make changes to our code, but when it comes to testing at scale, I'll usually find out that maybe a dozen files couldn't be processed correctly, and I need to go and debug our program with it.
For this purpose, editing the settings.json file works, but it's kind of cumbersome that I have to change the parameter, save, run, and revert every time I just want to test a new input.
Is there a way that I pass an argument to a debug configuration as I start debugging, instead of having to change the settings.json file?
To write multiple feature files(.feature) and respective step definition(.rb) files for my current Calabash project directory. Here, My doubt is that
a. Do I need to create feature file manually by using text editor after default single feature file creation based on calabash cmd 'calabash-android gen'?
b. Should I use my IDE to add multiple feature file and step definition files into Project skeleton?(I'm using Visual Studio Code IDE)
a. For your first feature you can reuse the file that is created if you want to. After that you should create a new file for each feature you want to test.
When you execute the tests you will often only execute 1 feature test at a time while developing and perhaps only from a certain line number. So having the tests split in multiple fetaures works well.
You have probably read it but if not please take a look at the Github page.
b. You can create the files any way you want to. I normally copy an existing feature file through IDE and clean it. Personally I find JetBrains Rubymine to be a really good IDE for working with Calabash.
I'd like to run an external beautifier over my code that's open and replace the contents of the document with the output. Is there a plugin or something I can exploit to do this? I thought it would be a no-brainer under the formatter preferences, but it looks like you can only use internal templates.
One solution is the following:
Create an ant builder on your project. See this article about how to do that. The important things you should know after you read the article:
Add a new ant builder by right click on project and properties. See the implicit variables your ant script will have. The variables will contain one or more resource name and path. So be prepared for collections.
Filter the resouces in the "Build
options" tab. This is important,
since launching a JVM (or a new task
inside IDE JVM) for the change of
every file (filetype) is not so
fast. So filter resources to be
processed like this:
The third thing is to ask eclipse to refresh the resource after the script is run. Like this:
Set the target of the ant script to be run as automatic build (third option). You can set all the four anyway it will be ok:
Write your script. You will find the log of the ant script in console, and you may redirect the log into a file as well. You can see the option on the second picture. Start your script with an echoproperties tag to see what your script gets from eclipse.
I used such builders a lot, it works like it should. I like them. Good luck. Consider accepting your answers, 42 % is not too much :D
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.
I have recently come across the LESS Leaner CSS a template engine for CSS based on ruby. The idea sounded neat, but in practice we need to compile the program to get CSS. This is cumbersome as we make too many changes while working on CSS and for every edit we don't want to compile.
In Eclipse, there are "Save-Actions" but it handles only formatting changes.
Is there a way on saving the file in Eclipse, to call or trigger the compilation?
Its easy to do this in Vi or Emacs.
I think all you need is to define a custom Builder for your project. That way, you can run a program or an ant script whenever certain files change.
Right click on the project -> Properties -> Builders -> New
While the Builders are a good solution, keep in mind they only work when a build is issued - either using auto-build or using a manual build which is invoked, well, manually. If you are looking for something that will operate after a save, regardless of the auto-build state you will need to write a plugin which listens to resource changes in Eclipse.
You do that by creating a workspace change listener and installing it like that:
ResourcesPlugin.getWorkspace().addResourceChangeListener(
..., IResourceChangeEvent.POST_CHANGE);
I'm sure you can take it from here :-)