I have a question. I used vs code for python and I used some extensions for python like the python extension from microsoft. I currently want to use vs code for html,css and javascript. Does the pythons extensions affect my work in other languages and html and css? Do I need to disable them?
No. Extensions for languages are usually associated with a file type (.py, .css, etc.).
If the extentions you want to install in vscode dont depened on each other they will have seperated inner routines and frameworks. So no "collisions" or anything like that. In case of python you can have different environments per projects which can be tricky to handle. To learn more about that have a look at pyvenv or virtual environment.
It will have no effect, you don't need to disable it, because the extension only runs if you use a file format with .py
If your files are separated with their respective file type names attached (i.e. .css, .scss, .sass, .html, .py) the extensions designed for Python would theoretically only affect the Python files. If it's a really bad extension with low reviews maybe it would have a bug, but this is highly doubtful if you stick to highly-rated plugins. Simple.
No, they will not anithing. Because they are build to execute just with python files then any file that doesn't have (.py) at the end it will not be affected.
Related
I have a file, source.php, that contains Javascript after the closing PHP tag. Is there a way to make Visual Studio Code do syntax highlighting/completion on the Javascript code. It currently only highlights the PHP code.
It'd be great if settings.json supported something like the following:
"files.associations": {
"source.php": ["javascript", "php"]
}
No, this is not possible without writing your own VSCode extension to understands the combined file
For syntax highlighting, you'd need to define a new grammar that combines the php and javascript grammars.
Completions are even more complicated. You need a language server / extension that can understand the new combined document. How our html server handles script blocks is probably the best example of this: https://github.com/Microsoft/vscode/blob/master/extensions/html/server/src/modes/javascriptMode.ts
This extension could help.
One Dark Theme
It is based in this Git Repo : https://github.com/atom/one-dark-syntax
I have searched far and wide for a way to compile my .hta file (and resources) to a .exe file.
There are plenty of applications that claim to be able to do this - but they have not worked for this application - which is a mixture of javascript and VB.
Simply, (and naively,) I don't want people looking at / screwing with the code. Any suggestions or solutions would be greatly appreciated.
EDIT: Of course, I understand that javascript and VB are not "compilable" since they are interpreted languages. I am just looking for a way to truly hide the source.
HTAEdit, which comes bundled with VBSedit, does not truly hide the hta code. At run time, it extracts the original hta file to a subdirectory in %temp% and passes it off to mshta.exe to execute. The converted exe's created by VBSedit don't seem to do this as far as I can tell.
Try using VBSedit, it definitely works for converting both vbs and hta to exe
You can "compile to exe" by simply wrapping the HTA into an executable which knows how to setup the HTA context/window.
The most trivial approach (which sounds like ExeScript) is to simply extract the HTA/resources first and then execute them. One could theoretically do this without temporary files by injecting data into a running IE context, but the task becomes more difficult. The internal JS may or may not be obfuscated and the wrapper may or may not add an additional layer of obfuscation/"encryption". (PayMo, and I am sure there are others, uses a wrapped context approach to distribute a single runnable exe).
If protecting "intellectual property" is the goal, hire a good lawyer :-)
I'm not sure about compiling to an exe - but if you minify & obfuscate your source code, unless you've got something incredibly valuable, it'd be a huge job to reverse-engineer.
http://developer.yahoo.com/yui/compressor/
Good luck.
You don't need a compiler, you need an encryptor/decryptor, like my project (under construction), the CFS project (Cryptographica File Security).
My clue is to create VBScript or JScript file for HTA to be dynamically spawned by. So you compile not HTA, but the script. This approach meets your security requirements much better than HTA packed to SFX.
Prepare the resources first - import to HTA all external files: scripts, stylesheets, and images (base64-encoded), to make your HTA standalone app. Then create eg VBScript file, and copy all HTML content from your HTA to the string variable in the script, replacing new line and tab symbols to " & vbCrLf & " and " & vbTab & ". Add code to create HTA window dynamically, .write() that string variable to the window's document, and quit script.
Note that Window_OnLoad() may not work properly due to pushing the content to window, that was already loaded.
Then just encrypt your completed VBScript to exe (using true encrypting utility, eg Primal Script 2012, ExeScript, VbsEdit or ScriptCryptor). And change icon with PE Explorer.
All that will take some time, but it is worth doing.
UPD: Here is an example of prepared script by the link.
So we're writing a full-text search framework MongoDb. MongoDB is pretty much javascript-native, so we wrote the javascript library first, and it works.
Now I'm trying to write a python framework for it, which will be partially in python, but partially use those same stored javascript functions - the javascript functions are an intrinsic part of the library. On the other hand, the javascript framework does not depend on python. since they are pretty intertwined it seems like it's worthwhile keeping them in the same repository.
I'm trying to work out a way of structuring the whole project to give the javascript and python frameworks equal status (maybe a ruby driver or whatever in the future?), but still allow the python library to install nicely.
Currently it looks like this: (simplified a little)
javascript/jstest/test1.js
javascript/mongo-fulltext/search.js
javascript/mongo-fulltext/util.js
python/docs/indext.rst
python/tests/search_test.py
python/tests/__init__.py
python/mongofulltextsearch/__init__.py
python/mongofulltextsearch/mongo_search.py
python/mongofulltextsearch/util.py
python/setup.py
I've skipped out a few files for simplicity, but you get the general idea; it' a pretty much standard python project... except that it depends critcally ona whole bunch of javascript which is stored in a sibling directory tree.
What's the preferred setup for dealing with this kind of thing when it comes to setuptools? I can work out how to use package_data etc to install data files that live inside my python project as per the setuptools docs.
The problem is if i want to use setuptools to install stuff, including the javascript files from outside the python code tree, and then also access them in a consistent way when I'm developing the python code and when it is easy_installed to someone's site.
Is that supported behaviour for setuptools? Should i be using paver or distutils2 or Distribute or something? (basic distutils is not an option; the whole reason I'm doing this is to enable requirements tracking) How should i be reading the contents of those files into python scripts?
The short answer is that none of the Python distribution tools is going to do what you want, the exact way you want it. Even if you use distutils' data_files feature, you're still going to have to have your javascript files copied into your Python project directory (i.e., somewhere under the same directory as your setup.py.)
Given that, you might as well just copy the .js files to your package (i.e. alongside mongofulltextsearch/init.py) as part of your build process, and use package_data or include_package_data=True.
(Or alternatively, you could possibly use symlinks, externals, or some such, if your revision control system supports those. I believe that when building source distributions, the Python distribution tools convert symlinks to real files. At least, you could give that a try.)
I work on front end development and am looking to find a solution for working with javaScript between (non compressed and multiple files) development environment and (compressed and combined files) live environment.
I have found a solution with CSS which means that I only need to include one global CSS file with imports, then we combine and compress those imports when deploying to a live environment. This means that we don't have to toggle adding references in to the head for dev and live.
Any ideas on a similar solution for JavaScipt?
Thanks
Dave
If you are using jQuery it's really easy to include external Javascript files from within Javascript which is basically what you described you did with CSS.
Read up on jQuery getScript()
You can use Charles Web debugging proxy. Or smth similar.
Charles allows to give any local file instead of any url. So you can give your browser your local JS file instead of live JS. Thus you will be able to test JS or CSS changes without showing them to your users.
I use ESC to merge and compress all the independant JavaScripts to a central one, and have it run as a 'post build' task.
For Visual Studio I wrote a small console application I wrote (like ESC as someone mentioned) that is used as a post-build event. It's simple but automates the job you're describing by:
Taking a list of filenames as its arguments
Compressing each one using Crockford's JS compressor
Combining the output into one .js file
Then in the site project, the file is loaded from a resource, and a toggle is performed in a class
List<string> files = new List<string>();
#if DEBUG
files.Add("MyNamespace.Javascript.script1.js");
files.Add("MyNamespace.Javascript.script2.js");
#else
files.Add("MyNamespace.Javascript.Live.js"); // single file
#endif
// ScriptManager.Register them
You could also enable GZIP compression on the JS files for even faster load times. If you're not using the Microsoft dev environment then I'll delete this.
Thanks for all your responses. I have come up with a solution which uses some of your ideas.
i have a global js file which has a list of files to include and when run during dev just writes the script links to the page.
Then included in the deployment process is a script which parses the global js file, looks up which files it is linking together, combines and compresses them in to one global js file.
This means that I don't need any server side code during the process which makes things easier to maintain across a team of freelance front end devs.
i'll post the final bunch of code when it's ready on my blog.
I don't know how your dev environment looks like but you could put all the script tags into one file for development and have another for production that has the script tag for your one single file. For example: development_js.extension and production_js.extension.
Then it's just a matter of either using server-side include or some build tool to merge the correct file into your HTML file.
Do you have a step in your deployment process that minifies JS? Do you have any sort of preprocessor for your JavaScript that allows you to leave in comments and console.logs and then have them automatically stripped out? Is your JavaScript machine generated by GWT or Script#? Do you use ANT or another tool to automate deployment?
I see a lot of JavaScript that looks like it comes right out of the editor, complete with lots of white space and comments. How much of that is due to not caring about the state of the deployed code, and how much is due to the spirit of the open web?
I usually check it out with JSLint to make sure it is bug-free, then pack it/encode it with YUI compressor.
My steps include:
I write Javascript using TextMate with the Javascript Tools bundle installed. This JSLint's my files on every save and notifies me when errors occur.
I use Sprockets to automatically concatenate my various Javascript files.
I run the resulting concatenation through jsmin to generate a minified version.
I end up with a concatenated lib.js file and a minified lib.min.js file. One I use for development, one for production. TextMate commands help automate it all.
I'm still looking for a good solution to actually (unit) test my scripts.
Check out YUI Compressor its a console app that you can use to minify (strip out comments, whitespace etc..) and also obfuscate your javascript files.
JSMin it from Douglas Crockford. We've got it hooked up as a macro in Studio as well as a post build item for some of our larger projects
FWIW, here's an interesting mini-benchmark on various ways you can minimize your Javascript source:
http://www.ericmmartin.com/comparison-of-javascript-compression-methods/
In short:
gzip compression in HTTP protocol really makes a difference (although you need to pay a CPU cost at the server side)
minification (removal of whitespace/comments, change of variable names etc.) also helps, and if you want best result, use it together with gzip compression
js-based decompressors are most likely useless - while you might get smaller size, the CPU overhead on the client is significant.
For one of our products, we concatenate all Javascript files together (most files are used on most pages, so this makes sense for us) and use Javascript::Minifier. This has given us a pretty nice speed boost.
A lot of it is probably due to not caring about people that might be viewing your pages on slower machines with slower connections and assuming that everyone has a 50Mbps line and three Gigs of RAM.
We are minifying our (hand-written + plugins, jQuery, etc.) JS as a part of the build process in .NET environment. No preprocessor, this is something we should definitely be doing once time permits.
P.S. By the way, we're not using console.log, as this will break IE. Instead we have a simple wrapper function, something like:
function log(stuff) {
if (window.console && window.console.log) {
console.log(stuff);
}
};
I have a PHP script that does it on the server side and keeps a cache of whatever it pulls from the source folder(s).
One word- packer
Light a candle, whisper a prayer against IE6 errors, and click "go". Does that count? :)
I don't minify my own javascript code since text tends to gzip/compress well.
I would minify a very large (say > 100 kb) javascript library (but then again I probably would not want to be using such a large library (or just ship what i use)).
I tend to believe that a lot of the javascript-minification is (in reality) done to achieve some sort of (futile) obfuscation of javascript code instead of the proclaimed end-user performance gain.
There's also a .NET port of YUI Compressor which allows you to:-
intergrate the minification/file combining into Visual Studio post-build events
intergrate into a TFS Build (including CI)
if you wish to just use the dll's in your own code (eg. on the fly minification).
I thought I would share my approach to js deployments. Have a look at this blog post:
http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx
This also includes code to compile (using google's closure compiler) at runtime (when needed).
Thanks Guido