I wonder if it is possible to disable webpack folder in inspect, so users cant see my source code?
And if it's not possible, can users change it and run it?
Most commonly such a structured view is available only in development environment.
When the code is shipped to production environment it's normally minimized & bundled into one or several files which already makes it quite hard to read.
If you want to "hide" it from the user even further, you can use code obfuscation tools (you will likely need to pay for them) or move sensitive parts of your code to serverland.
Generally speaking, the only bulletproof way to hide the code from your users is never ship it to their browsers.
Whether the code is obfuscated or not, the user is alway able to change it & run. Obfuscation just makes it significantly more difficult.
There is a solution, you can try this in the "vue.config.js"
module.exports = {
productionSourceMap: true,
}
This option will tell Webpack to exclude the source code. Could be a solution for you.
Cheers
having the same issue here.
The Original Source files are NOT even close to the Server its running on and i tried multiple, independent Pcs now and everytime it showns me the full original source code in the Source list in chrome.
I dont really mind "showing" the source code but what annoys me is that this way people can literally steal the source and built the exact software on their own and it exposed stuff about my pc like directory of stuff, my full name (due to windows username), etc.
Related
Where do you store your old classes and files, which you don't longer use in a current project?
I have quite a few classes and files, which are no longer required, but which I would like to keep somewhere in case I need to reuse some of the code later.
Currently, I am just copying and pasting the code in a tool called Code Collector Pro.
However, since this seems not to be the most elegant way of storing old code, I would like to ask you: How do you save your old code?
If you are talking about handy snippets of code that you might use often I store them in Xcode's Code Snippet Library (just drag selected code in to create a snippet.)
Generally though, I delete unused code. If I need it again it will be in my version control system.
I would definitely use a version control system (I'm most familiar with Subversion, but am getting into Git now). If this is code that's worth keeping around then it's code you'll likely use and modify in multiple projects over time. You'll want to be able to review the history of your changes, compare how you used it differently in project A vs. project B, and maintain notes to help refresh your memory and to help in keyword searching when you're trying to find that bit of code you remember using two years ago.
You can set up repositories however makes sense for your work - by project, by code type, etc.
I'm not familiar with Code Collector Pro - if it works as a GUI for a version control system, it may be fine for what you're doing.
I'm trying to get DOH testing working for my company's upcoming platform, but I can't figure out the right combination of paths. Our file structure looks like this:
/dojo15
/release
/dojo
/dojo
dojo.js
dojoExt.js
/dojo
dojo.js
/util
/doh
/js
mainLib.js
/tests
base.js
This was created by our contractors, so unfortunately there are some things I have to figure out as I'm going along.
The "release" directory is what is used on our pages.
The "util" directory doesn't exist in our release directory. (I'd like to avoid having to make a copy of it there.)
I'm not entirely sure what they did with dojoExt.js there, but it seems to be required. I was able to make a simple "hello world" sort of test, but once I did dojo.require(js.mainLib), I got an error that dojo.behavior.add is not a method. So it seems to be they made a stripped-down dojo.js and put other required code in dojoExt.js.
My guess is that DOH is using the dojo in dojo15/dojo, but I need to include dojo15/release/dojo/dojo/dojoExt.js. I've tried every combination of dojoUrl, testModule, registerModulePath I can think of...also saw "boot" and "path" from other SE questions, even though I can't see in runner.html where they would even be used, but I tried throwing them in to see if they'd magically help anyway.
At the moment I don't really have the option to move code around, so I'm hoping to work this out with files where they currently are.
Did you try the bits I suggested over at a related question? We use the bits I detailed there to pull together a completely custom layout of dojo + util. Take a look at both boot and dojoUrl. I think it's runner.js that does most of the cunning stuff, rather than runner.html.
Is the problem that you can't arrange for dojoExt.js to get loaded? How does your other code arrange for it to get loaded? Is tests/base.js your test module?
Does anyone know of an existing solution to help write tests for a NSIS script?
The motivation is the benefit of knowing whether modifying an existing installation script breaks it or has undesired side effects.
Unfortunately, I think the answer to your question depends at least partially on what you need to verify.
If all you are worried about is that the installation copies the right file(s) to the right places, sets the correct registry information etc., then almost any unit testing tool would probably meet your needs. I'd probably use something like RSpec2, or Cucumber, but that's because I am somewhat familiar with Ruby and like the fact that it would be an xcopy deployment if the scripts needed to be run on another machine. I also like the idea of using a BDD-based solution because the use of a domain-specific language that is very close to readable text would mean that others could more easily understand, and if necessary modify, the test specification when necessary.
If, however you are concerned about the user experience (what progress messages are shown, etc.) then I'm not sure that the tests you would need could be as easily expressed... or at least not without a certain level of pain.
Good Luck! Don't forget to let other people here know when/if you find a solution you like.
Check out Pavonis.
With Pavonis you can compile your NSIS script and get the output of any errors and warnings.
Another solution would be AutoIT.
You can compile your install using Jenkins and the NSIS command line compiler, set up an AutoIT test script and have Jenkins run the test.
Cloud App has this neat feature wherein it automatically uploads new screenshots as they are added to the Desktop. Any ideas how this is done?
You can do similar things yourself without much in the way of programming. In OSX, you can configure "Folder Actions" to run a script, for example, when a new item appears in a folder, including the Desktop. You can then use the script to do whatever you want with the new files.
This article at TUAW includes an example of uploading files to a web server when they hit a particular folder.
So, basically, the answer is "Folder Actions", or "something's keeping an eye on the folder and sending notifications", at some level. Whether Cloud App uses Folder Actions or watches the folder itself at a lower level, using FSEvents/NSWorkspace, or the kqueue mechanisms (for which there's a nice wrapper class called UKKQueue, if I remember correctly -- don't know how current my knowledge is on that one though!) is another matter...
You could implement this at several different levels, depending on the outcome you want, how you want to design whatever it is you're actually doing, and even what kind of filesystem you're targeting. Fundamentally, in Cocoa/Objective C, I think you probably want to start looking at FSEvents.
Once you've got notifications of the file changes, I'd probably use something like ConnectionKit to do the uploading -- any library at all, really, that means you don't have to bother with the sockets level yourself -- but again, there's a lot of different ways.
Depends, really, what level you're looking to solve the problem at, and whether you want to build something for other people or get something working for yourself. If I just wanted to bash something together for myself, I could probably have something cobbled together using Coda's Transmit app, and Folder Actions, or maybe Hazel, and a minimal bit of Applescript, in a half-hour at most, that would do the job well enough for me...
I am not sure what you are asking for exactly. If you are asking for a way to take a screenshot programmatically in MacOSX, I suggest you have a look at the "screencapture" command (in the terminal, type "man screencapture" for doc).
If you want to do it the "hard" way, you should look at this.
About 2 months ago I overtook building proccess in current company. Even though I don't have much knowledge of it, I was the only with enough time, so I didn't have much choice.
Situation is not that good, and I would like to do following:
Labeling files in SourceSafe with version (example ProjectName PV 1.2)
GetFiles from SourceSafe to specific directory
Build vb6/c++/c# projects(yes, there are all kinds of them)
Build InstallShield setups
This is for now partly done using batch scripts(one for labeling and getting, one for building, etc..). So when building start I pretty much have babysit it.
Good part of this code could be reused.
Any recommendations on how to do it better? One big problem is whole bunch of dependencies between projects. Also labeling has to increment version and if necessary change PV to EV.
I would like to minimize user interaction as much as possible. One click on one build script(Spolsky is god) and all is done, no need to increment version, to set where to get files and similar stuff.
Is the batch scripting best way to go? Should I do some functionality with msbuild. Are there any other options?
Specific code is not need, for now I just need a way how to improve it, even though it wouldn't hurt.
Tnx,
Marko
Since you already have a build system (even though some of it currently "manual"), whatever you do, don't start over from scratch.
(1) Make sure you have a test machine (or Virtual Machine) on which to work. Thus you can make changes and improvements without having to worry about breaking anything.
(2) Put all of your build scripts and tools in version control, not just the source code. Then as you make changes, see if they work. If they do, then save them to version control. If they don't, then roll them back.
(3) Choose one area to work on at a time. Don't try to do everything at once. Going from a lot of manual work to "one-click" will take time no matter what build system you're working with.
Sounds like you want a continuous integration solution, like CC.Net. It has configuration options to do all the things you want and a great community to answer questions.
Also, batch scripting is probably not a good option. Sophisticated build and integration tools will let you feed parameters into the build and create different builds for different environments (test, production, etc.). Batch scripting will involve a lot of hand-coding and glue.