The problem with helm() function is that it does not respect pre- install/upgrade hooks of the services. However, the only usable replacement helm_resource() does not rebuild/republish images on local changes (because of it's notion of "remote" resource).
How to make service images to be rebuilt and republished when using helm_resource() automagically, just like the helm() did?
Related
I'm trying to figure out why Phoenix live reload works "most of the time" but not always.
My config.exs has:
# Watch static and templates for browser reloading.
config :bespoke_work, BespokeWork.Web.Endpoint,
live_reload: [
patterns: [
~r{priv/static/.*(js|css|png|jpeg|jpg|gif|svg)$},
~r{priv/gettext/.*(po)$},
~r{lib/bespoke_work/web/views/.*(ex)$},
~r{lib/bespoke_work/web/templates/.*(eex)$}
]
]
Whenever I edit one of the templates that ends in *.html.eex it usually works right away. But sometimes it does not. And when live reload doesn't work, no matter how many times I try to refresh the page / clear the cache or go salsa dancing, it just won't refresh the content.
My folder structure is like this:
/name/lib/name/web/templates/page
|-index.html.eex
|-menu.html.eex
|-module[1-5].html.eex
(there are five modules files, the first being module1.html.eex and so on)
Is the fact that the files are not directly under the templates folder a problem? (They're inside the templates/page folder)
The index.html is rendered inside the layout/app.html.eex layout and, inside the index file, there are calls to render the menu and the other modules.
Not sure what I am missing here.
I tried running mix phx.digest manually, it didn't made any difference (it is already being triggered whenever needed).
How can I fix this behavior?
Phoenix 1.3.0-rc.2
Phoenix Live Reload 1.0.8
Elixir 1.4.5
Erlang/OTP 20
Impaciência 10
I found the culprit: Spacemacs lock files.
As part of my workflow is working with Front-end specs, sometimes I need to adjust things by the pixel or make some other minor (and really fast) adjustment: as when you noticed you have a typo or something.
In those situations, what appears to happen is the following:
I switch to Spacemacs.
As soon as I start typing (switch to Evil Mode insert state), Spacemacs creates an lock file in the same directory.
Phoenix Live Reload notices the change in the directory and well, live reloads the code (which is still the same because the auto-save file is not used by the app).
When I save the altered file, usually right away, Live Reload was still refreshing the browser from the detected auto-save file creation.
Although I still can't understand why simply refreshing the screen (with Browser Cache disabled on Chrome) won't display the proper code.
Short version: see topic
Detailed version:
I want to use a specific 3rd party theme for Windows. I'm already using an open source solution which I've compiled myself to disable Window's restriction on Themes.
In the past, when using 3rd party theme related mods that come with DLLs (for example authui.dll for the login ui, or imageres.dll for modding system icons), I avoid using unknown DLLs by simply copying the unknown DLL's theme related resources (such as Bitmaps, Icon groups or UI scripts) unto it's virgin MS Dll counterpart. I call this resource grafting, where resource are changed but the executable elements of DLLs or exes are left alone.
Going back to the theme I want to install, I used sha256 hashing to determine that only aero.msstyles which is also modifiable by resource hacker. So I did the same thing I usually do and transferred resources from the third party theme to Window's own aero.msstyles. Problem is that I ran into a type of resource that I am unable to read or know the contents of. It's called VARIANT. From some experiments done in a VM, it seems to be some kind of binary UI script that resource hacker is unable to decompile. I usually like to be able to read any UI scripts that I transfer but I am unable to do so with this one.
Would this constitute any real security risks? Can UI scripts be side-loaded with some kind of exploit? Seems unlikely to me since the function of a theme file (msstyle) is to coordinate the appearance of the system UI but I don't know enough about the inner working of the whole theming system to be sure. I thought I'd get some other point of views before I take the theme out of the Virtual Machine.
I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.
vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.
There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.
To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.
Mind you, this doesn't answer the question I asked (can binary UI script resources in a theme carry mal-code) but it does solve my dilemma. Thought I'd share it.
I have a IReliableDictionary. Every time I remove the application and deploy it again, I expect that all the data will be erased.
But it looks like something persists on disk and the dictionary is able to load this data after redeploy. So when I try to AddAsync something after redeploy I get the ArgumentException with additional information key. Looks like I'm trying to insert already inserted key.
The name of the dictionary is the same and the whole cluster isn't redeployed, only application itself.
Is it a normal behavior? Because I can't insert a new value after redeploy and it seems logically incorrect.
Local dev cluster, SF version 2.1.163.
Make sure you're using the right deploy mode in Visual Studio. It has two ways to deploy applications locally:
Auto Upgrade
Remove
Remove will remove an application completely, removing all state, and then redeploy a new application.
Auto Upgrade will perform a rolling upgrade so that you don't lose state. This is handy when you're working on an application that needs to be loaded up with data to test it, so you don't lose all your test data every time you make a code change and run the application.
Right click on your application project and go to properties to set this:
We are in the process of switching our game from our own canvas page, to using the Unity integration on Facebook. However, during our development tests we have occasionally run into a problem where the webplayer binary gets loaded from the browser cache, even though a newer version was uploaded to the server.
Manually clearing the browser cache solves the problem, but that's not exactly a solution we want to present to our users all the time. Previously, when we embedded the unity object ourselves, we also passed in a ?version flag with the url, which would keep it up to date, but we can't exactly do that anymore with integration turned on, unless we manually update the binary location link in our app settings every time we do a build (Kind of a pain in the butt, since the rest of our build process is automated)
Is there any way around this?
Thanks.
We have exactly same problem and I can say only solution is to change the binary file name everytime you made a build but only for your production environment. Here is our solution:
We have development (sandbox mode)and production environment and one app for each one.
For development, we ran everything locally, we have buildpipeline that builds and copies the binary file to appropriate place with the same name always like MyGame.unity3d, and we have set our browsers not to cache anything, that solves the problem for testing.
For production, our buildpipeline constructs the binary name with:
YourGameNameMainVersion.SubVersion.TimeStamp like: MyGame0.3.1006-1004.unity3d and this one is manually set from facebook's app settings page in every build. But this is not a big problem as you won't want to make a new build more than once/twice a day for production.
We've found that all that needs to be done is to add "?version=xxxx"
This works, and perfectly fine. I do now, is only change version (?version=1.52) in main link:
<a href="http://cometoplaynow.com/Labyrinth3D/Labyrinth3D.html?version=1.52">
Have advantages using it:
Changing only 1 number - link is still the same (if people open game from your site)
Savings will stay as it was (if you change .unity3d you will lost PlayerPrefs).
Is anyone aware of a hybrid version control and synchronising system?
I'm currently a happy mercurial user, but my projects usually contain a mixture of files.
Most of these (code, documentation, ...) I want to be version-controlled. This is why I use mercurial.
However, on the rare occasion I have files that I would like to synchronise between my working copies, but not version control.
For example, I version control the code I write to do image processing. This code can produce a whole bunch of output images which I'd like to have synchronised so I don't have to remember to shuffle them around my various computers, but there's no point having these version controlled.
To clarify - I am aware of extension to mercurial such as bfiles and bigfiles, which are handy for my image example, but I was just wondering if anyone out there knows of alternative ways to handle this. I just want the one system that I can tell "version control all files except those ones, which should be synced but have no history".
cheers!
EDIT: I could do something like adding a hg marksync <filename> that added <filename> to a list of files to be synced, and then adding a hook to hg push/hg pull that would (say) run rsync (or whichever sync tool) in the background, but I wondered if there was a less hacky solution (I think bfiles/bigfiles do something along these lines anyway).
Version Control System (any) doesn't care about synchronization of
not versioned data
besides default pathes
If you want sync any files - use specially designed for this task tools: f.e. rsync
This code can produce a whole bunch of output images which I'd like to have synchronised
Is this DATA or part of your CODE?
If data: Keep out of your versioning system, just don't go there. If it is part of your code (like layout images) check it in. Those are the only ways which are the generally accepted.
A nice solution for the data would be syncing OR generating them. So you might add a step after deployment to a server: GenerateImages().
edit: In addition to the comment made by the thread starter:
If the images are data and you need to process them on a different system don't think about the version control for your code. It is unrelated. The steps which would make sense to me, in order of processing:
Start with updating your image code, check it in versioning. Then deploy (yes this is deployment) the updated code to the cruncher computer. Now code is done.
Then you have tasks which the number cruncher should handle. Like processing the images. So start that processing from either the cruncher itself (probably some queue happens there) or from a central dispatcher.
Then you have the results locally at the cruncher. Now something has to happen with that data, so that's also part of your software. Decide whether you want the cruncher to send them to some central storage, your workstation or another location. Let the software handle that. This is the most hard part as I read through your question. Many solutions are possible from just FTP/network transfers to specific storage solutions. Willing to help but need more info about the real issues, amounts, sizes etc. on these parts.
If the new updated version of the image processor makes the old generated images obsolete implement that also in your code, by for example attaching an attribute to the files generated, a seperate folder or another indication. That way you could request the cruncher after update to re-generate any obsolete files.