I have a FreeSwtich solution running on Linux with quite a lot of configuration scripts written in javascript.
The problem is that we need to write and read files; which javascript normally doesn't support.
I tried the SpiderMonkey File Object but it doesn't work and has been marked as obsolete..
The setup is a bit special; there is really only one dial plan with one javascript handling the call initially. Depending on a number of parameters the call is then 'handed over' to one of 20 or so Javascripts dynamically included. It is actually a data base lookup that returns the name of the script to run.
So looking for other options if there are any? Rewriting the entire thing in LUA is an option of course but to keep the current structure that would mean rewriting a lot of javascripts. Unless someone can think of a magic way to call LUA script from javascript?
There's a bunch of various programming languages supported by FreeSWITCH: Perl, Python, Lua, Ruby. Take whatever suits you better :)
You can provide those files via an HTTP interface and fetch them from your Javascript scripts.
You can also fetch them as BLOB objects from your SQL database.
But this whole setup seems like a lot of CPU work for every call, so I wonder if performance is not already an issue.
Related
I've got a simple Javascript application with a JSON API. Currently it runs in the client, but I'd like to move it from the client to the server. I am accustomed to learning new platforms, but in this case, my time is very limited - so I need to find the absolute simplest way possible.
This should be an easy task, but all I'm finding are solutions that are way overcomplicated:
The application is currently hosted on an extremely basic server. Node.js is not available, and I do not have install privileges. I'll eventually move it to a different server, but I really don't know what will be available there.
Many solutions require installing and running a standalone server. Really? Just to evaluate Javascript server-side and spit out some data?
I can run Python and PHP, and I see that it's possible to call Javascript from inside a Python or PHP script. However, the specific Python solution that I've found also require installing some Python support via pip or easy-install, so probably not an option. Also, this just feels overcomplicated, and I'm concerned about setting myself up for errors such as data conversion or permissions, etc.
Any help?
#Quentin is correct. There is no way to run javascript on a server without a javascript interpreter on the server.
Node.js is not only the most robust and widely used one, it's also the simplest. It is certainly possible to write your own javascript interpreter in PHP or Python, but that would be much more complicated than using Node.js.
Try really hard to find a server solution that allows you to use Node. In the end, it's going to save you (and any other stakeholders interested in the project) a lot of time and money.
I'm new to JavaScript.
How should I split my functions across external scripts? What is considered good practice? should all my functions be crammed into one external .js file or should I group like functions together?
I would guess more files mean more HTTP requests to obtain the script and that could slow down performance? However more files keep things organized: for example, onload.js initializes things on load, data.js retrieves data from the server, ui.js refer to UI handlers...
What's the pros advice on this?
Thanks!
As Pointy mentioned, you should try a tool. Try Grunt of Brunch, both are meant to help you in the build process, and you can configure them to combine all your files when you are ready for prod (also, minify, etc), while keeping separate files when you are developing.
When releasing a product, you generally want as little HTTP requests as possible to load a page (Hence image sprites, for example)
So I'd suggest concatenating your .js's for release, but keeping them separated in a way that works well for you, during development.
Keep in mind that if you "use strict", concatenating scripts might be a source of errors.
(more info on js strict mode here)
It depends on the size, count of your scripts and how many of them you use at any time.
Many performance good practices claim (and there's good logic in this) that it's good to inline your JavaScript if it's small enough. This leads to lower count of HTTP requests but it also prevents the browser from caching the JavaScript so you should be very careful. That's why there're a practices even to inline your images (using base64 encoding) in some special cases (for example look at Bing.com, all their JavaScript is inline).
If you have a lot of JavaScript files and you're using just a little part of them at any time (not only as count but as size) you can load them asynchronously (for example using require.js). But this will require a lot of changes in your application design if you haven't considered it at the beginning (and also make your application complexity bigger).
There are practices even to cache your CSS/JavaScript into the localStorage. For further information you can read the Web Performance Daybook
So let's make something like a short retrospection.
If you have your JavaScript inline this will reduce the first load of the page. The inline JavaScript won't be cached by the browser so every next load of your page will be slower that if you have used external files.
If you are using different external files make sure that you're using all of them or at least big part of them because you can have redundant HTTP requests for files which actually are unnecessary loaded. This will lead to better organization of your code but probably greater load time (still don't forget the browser cache which will help you).
To put everything in at single file will reduce your HTTP requests but you'll have one big file which will block your page loading (if you're using synchronous loading of the JS file) until the file have been loaded completely. In such case I can recommend you to put this big file in the end of the body.
For performance tracking you can use tools like YSlow.
When I think about good practice, then I think of MVC patterns. One might argue if this is the way to go in development, but many people use it to structure what the want to achieve. Usually it is not advisable to use MVC at all if the project is just too small - just like creating a full C++ windows app if you just needed a simple C program with a for loop.
In any case, MVC or MV* in javascript will help you structure your code to the extent that all the actions are part of the controllers, while object properties are just stored in the model. The views then are just for showing purposes and are rendered for the user via special requests or rendinering engines. When I stared using MV*, I stared with BackboneJS and the Guide "Developing BackboneJS Applications" from Addy Osmani. Of course there are a multitude of other frameworks that you can use to structure your code. They can be found on the TodoMVC website.
What you can also do is derive your own structure from their apps and then use the directory structure for your development (but without the MV* framework).
I do not agree to your concern that using such a structure lead to more files, which mean more HTTP requests. Of course this is true during development, BUT remember, the user should get a performance enhanced (i.e. compiled) and minified version as a script. Therefore even if you are developing in such an organized way, it makes more sense to minify/uglify and compile your scripts with closure compiler from Google.
This question is mainly for security purposes. I need to know if it is possible to view by any means (plugins, programmatically or whatever) a list of all variables and their values in a gwt application compiled to javascript.
Let's say I have a variable x created by gwt in its normal deployment mode.... let's just ignore how did the value get there... Can the user somehow get to know that there is a var called x and its value...
Please note that I am not looking for software engineering best practices, the question is over simplified so that we get to the point. I know that I should not have anything sensitive on the client on the first place... but please let's just skip that since the case is a much bigger story...
Thanks a lot..
Short awnser... yes..
GWT compiles to javascript and obfuscates everything, that said, all information is available from the compiled source if one knows what to look for. If someone succeeds in injecting a simple script tag into your application, they can simple retreive all scripts through XMLHttpRequest and parse them as text. No matter how obfuscated, it's theoretically possible to get what you want from any javascript source. If you can see it in the raw script file, it's attainable, doesn't really matter if it's locked away in anonymous closures or whatnot, any JS security mechanism can be circumvented.
Main condition is to get control of the page (script injection).
To quote yourself: " I know that I should not have anything sensitive on the client on the first place..."
If it's worth hacking, people will try it.
GWT code is compiled to javascript. So ultimately user can use javascript introspection to discover all objects and their properties.
Short answer - No, not unless you know what you are looking for.
GWT compiler does something called as cross-compiling, it transforms java code into java script/ECMA script. The mapping between a variable in java to that in generated script is not straight forward. The language semantics are not the same; the compiler tries to optimize and generates obfuscated JS (to reduce the size). You can tweak this to certain extent by passing arguments at compile time (by setting PRETTY). This still does not guarantee a one on one mapping.
On different quote, even decompiled java code does not look like the original source. ( thats' the complexity of the problem)
There are numerous log files that I have to review daily for my job. Several good parsers already exist for these log files but I have yet to find exactly what I want. Well, who could make something more tailored to you than you, right?
The reason I am using JavaScript (other than the fact that I already know it) is because it's portable (no need to install anything) but at the same time cross-platform accessible. Before I invest too much time in this, is this a terrible method of accomplishing my goal?
The input will be entered into a text file, delimited by [x] and the values will be put into an array to make accessing these values faster than pulling the static content.
Any special formatting (numbers, dates, etc) will be dealt with before putting the value in the array to prevent a function from repeating this step every time it is used.
These logs may contain 100k+ lines which will be a lot for the browser to handle. However, each line doesn't contain a ton of information.
I have written some of it already, but with even 10,000 lines it's starting to run slow and I don't know if it's because I wasn't efficient enough or if this just cannot be effectively done. I'm thinking this is because all the data is in one giant table. I'd probably be better off paginating it, but that is less than desirable.
Question 1: Is there anything I failed to mention that I should consider?
Question 2: Would you recommend a better alternative?
Question 3: (A bit off topic, so feel free to ignore). Instead of copy/pasting the input, I would like to 'open' the log file but as far as I know JavaScript cannot do this (for security reasons). Can this be accomplished with a input="file" without actually having a server to upload to? I don't know how SSJS works, but it appears that I underestimated the limitations of JavaScript.
I understand this is a bit vague, but I'm trying to keep you all from having to read a book to answer my question. Let me know if I should include additional details. Thanks!
I think JavaScript is an "ok" choice for this. Using a scripting language to parse log files for personal use is a perfectly sane decision.
However, I would NOT use a browser for this. Web browsers place limitations on how long a bit of javascript can run, or on how many instructions it is allowed to run, or both. If you exceed these limits, you'll get something like this:
Since you'll be working with a large amount of data, I suspect you're going to hit this sooner or later. This can be avoided by clever use of setTimeout, or potentially with web workers, but that will add complexity to your project. This is probably not what you want.
Be aware that JavaScript can run outside of browsers as well. For instance, Windows comes with the Windows Script Host. This will let you run JavaScript from the command prompt, without needing a browser. You won't get the "Script too long" error. As an added bonus, you will have full access to the file system, and the ability to pass command-line arguments to your code.
Good luck and happy coding!
To answer your top question in bold: No, it is not a terrible idea.
If JS is the only language you know, you want to avoid setting up any dependencies, and you want to stay platform-independent... JavaScript seems like a good fit for your particular case.
As a more general rule, I would never use JS as a language to write a desktop app. Especially not for doing a task like log parsing. There are many other languages which are much better suited to this type of problem, like Python, Scala, VB, etc. I mention Python and Scala because of their script-like behaviour and minimal setup requirements. Python also has very similar syntax to JS so it might be easier to pick up then other languages. VB (or any .NET language) would work too if you have a Visual Studio license because of it's easy to use GUI builder if that suits your needs better.
My suggested approach: use an existing framework. There are hundreds, if not thousands of log parsers out there which handle all sorts of use-cases and different formats of logs that you should be able to find something close to what you need. It may just take a little more effort than Google'ing "Log Parsers" to find one that works. If you can't find one that suits your exact needs and you are willing to spend time making your own, you should use that time instead to contribute to one of the existing ones which are open source. Extending an existing code base should always be considered before trying to re-invent the wheel for the 10th gillion time.
Given your invariants "javascript, cross-platform, browser ui, as fast as possible" I would consider this approach:
Use command line scripts (windows: JScript; linux: ?) to parse log files and store 'clean'/relevant data in a SQLite Database (fall back: any decent scripting language can do this, the ready made/specialized tools may be used too)
Use the SQLite Manager addon to do your data mining with SQL
If (2) gets clumsy - use the SQLite Manager code base to 'make something more tailored'
Considering your comment:
For Windows-only work you can use the VS Express edition to write an app in C#, VB.NET, C++/CLI, F#, or even (kind of) Javascript (Silverlight). If you want to stick to 'classic' Javascript and a browser, write a .HTA application (full access to the local machine) and use ADO data(base) access and try to get the (old) DataGrid/Flexgrid controls (they may be installed already; search the registry).
A lot of questions have been asked and answered about running server-side javascript on Google App Engine, but all of the answers deal with Java instances in order to make use of Java-based JS interpreters like Rhino, Rhino for Webapps, etc.
Is there any way to execute server-side javascript code on a Python GAE instance? I'm thinking something exactly along the lines of pyv8, but with support for App Engine (which I guess would mean a pure python implementation of the interpreter).
The only solution I can come up with at the moment is to use some sort of gross hack to run a Java and Python GAE instance side-by-side (via different versions) so they can both talk to the same datastore, let the Java instance host the JS code, and use an API to talk back'n'forth. Not very appealing.
No need to get into all the "this is unnecessary, you shouldn't be doing this" discussion -- I know this isn't ideal and I'm simply curious if it can be done.
As far as I can find: No
I've done a bit of searching, but it seems that nobody has tried to implement a pure Python Javascript engine, and I can't blame them: it would be a huge amount of work for very few use cases (unfortunately, yours is one of those). A couple of projects—Grailbrowser and Pybrowser—have Python code to render HTML, so might one day aim to run javascript, but it's not even started, and neither of them look in active development.
The most likely way it would ever happen is if Google were to offer the Parrot VM (which can run various dynamic languages) on Appengine. That's a cool idea, but I'm not holding my breath.
What might work is to run Jython (and Rhino) in a Java instance. Of course, then you'd have to get to any App services through the Java API, not the Python one, which would be ugly.
Actually, it can indeed be done, using either AppEngineJs or ESXX:
http://www.appenginejs.org/
http://esxx.blogspot.com/2009/06/esxx-on-google-app-engine.html
I am currently trying to solvevthe same problem with PyJON
http://code.google.com/p/pyjon/
Seems to be a pure Python JavaScrit parser an interpreter.