The site looks great! I only have one comment: it'd be nice to get an idea of which solution is the most efficient, and it'd be REALLY nice to be able to sort solutions by speed.
Where did you get this info? I'm not doubting you; I just find it crazy that they have offices in over 40 countries[1], but only allow app submissions from developers in 32 countries.
Sligthly related to the part you find crazy, Google has their main European HQ in Ireland, basically because of the very low corporate taxes here, but guess what? It's impossible to buy a Nexus on Google Play from Ireland. If you try you get this message:
--
Sorry! Devices on Google Play is not available in your country yet.
We're working to bring devices to more countries as quickly as possible.
Please check back again soon.
--
They say they're working on it. But that's just a lie. This message has been there for at least the last two years (probably a lot more) and nothing has changed. And we're not talking about a small country in the middle of nowhere. Ireland is part of the the European Union. And they not only have offices here but their main European HQ. They just don't care at all.
Tell me about it. Or they do silly things like release sub-par Chromebooks to the Canadian market every other release, with the Canadian multilingual keyboard layouts nobody likes (because of the short enter key), and I have to ship and forward US models to get decent devices with the non-standard yet US english layout I want. (I say non-standard because they already changed the control key and caps lock, so they could care about localizing the keyboard improvements to other layouts, but they don't. Apple does.) Of course, I suppose I've the "advantage" of living so close to the US (2 hours drive) that I can go and pick up the latest devices from a US shipping address. But I shouldn't have to.
Edit: To be clear, this is a list of countries which can publish paid apps in the Play Store. The list of countries which can publish free apps is of course significantly larger.
Can you elaborate on this? I'm looking for you to clarify which other dynamic languages would be considered less risky in this specific application and why.
Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security.
However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong.
Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
>Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security.
Yes like Ruby and Active Records SQL injection debacle where Github was pwned and the developers din't seem to care?
I can't argue that PHP is better than other languages, but holding it to f*ck ups from over 5+ years ago, most of which have been fixed, is a low.
If you can find something vulnerable within this open source coded, then I happy to hear you out and would prefer that than your unregistered paranoia.
Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
>Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
Well, the vast majority of people would not consult the documentation for register_globals when it was the default. Sure, it's deprecated now, but... what the hell, who thought it was a good idea in the first place? Oh yeah, the same people who built PHP as a hack designed for a very specific purpose that grew out of proportion too quickly.
> Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner.
The Active Record stuff was a vulnerability in a LIBRARY. The register_globals stuff was a vulnerability in THE CORE LANGUAGE. Those are two very, very different things. Also, it's a bug rather than a design decision.
>Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
I encourage as many people as I can to contribute to open source. I also consider myself an experienced software developer, so I feel like it is my responsibility to educate people and prevent them from shooting themselves in the foot. PHP makes it very easy to do this.
Genuinely curious, how would you implement something like a cron web interface? Certainly it would require you to have a program execute a shell command upon some HTTP request. Granted this project focuses on displaying data but there are many, many serious web libraries that execute commands on the server depending on what the person is trying to do.
Think of all the libraries that are just abstraction layers to imagemagick or ffmpeg. Do you really think there no legitimite use case for executing commands via some web program?
The libraries that are abstraction layers to imagemagick or ffmpeg are, in fact, that: libraries. There is a very critical distinction between a library/module and a command-line wrapper. Your programming language probably has a module that exposes the imagemagick API. However, this doesn't mean that it uses shell commands for anything; it just exposes the functions to your programming language of choice.
I wrote the backend and processing system for a website[1] that deals with converting files, and incidentally uses imagemagick and ffmpeg, amongst other things. You'll notice that everything that that calls external programs is handled very carefully. One example of this careful handling is that all of the commands that can be executed are in a single file[2], and very easy to think about. Compare that to OP's software, where there are multiple commands scattered across different files. Also, although this is a bit harder to see superficially, but no HTTP request triggers any external program call directly. This is by design.
Coming back to your question,
>Genuinely curious, how would you implement something like a cron web interface? Certainly it would require you to have a program execute a shell command upon some HTTP request.
You set up a cron job[3] that gathers the data and stores it somewhere like a database, or even a file. The idea here is that you have a strictly one-way flow of data, which prevents a large number of attacks (register_globals is the easiest)
[3] Or a daemon, whatever; the point is that the website can only communicate with it through a specific channel with a very small attack surface (i.e a UNIX socket where the messages are very limited), whereas doing it on the script that generates the website exposes a very large attack surface
Kind of like there's Sphinx fulltext indexing and Sphinx doc generation lib for python and CMU's sphinx speech recognition/generation framework, you have to specify which but google seems ok with them.
my father used to watch that movie at least once a month, usually with a bourbon in his hand, and alway a shit-eating grin on his face. i'm positive he wishes he could have been a mountain man when he 'grew up'.
any chance you could avoid using the XHR to load content for the downloadable version?
i get this error in chrome:
XMLHttpRequest cannot load file://localhost/Users/damion/Downloads/jqapi-latest/navigation.html. Origin null is not allowed by Access-Control-Allow-Origin.
in the meantime i've been using chrome as my browser, and safari as my dedicated jqapi renderer.
