Author of Node modules, the Node Tuts screencast and some books. Co-founder and partner of The Node Firm, Organizer of LXJS, Platform Developer @ CrowdProcess, developer @ BrowserSwarm and hacking on a super secret project with @dscape.
@pgte, we are talking every day on how to actually make this module battle tested enough for teams to use in production. We certainly believe this knockout hack proved it can be done and this technique needs to happen in the mainstream.
This is the official repo https://github.com/diurnalist/dynosrc, we have decided until the competition we will not be accepting pull requests so the perception of our hack isn't altered. We feel this is a way to "lock in" the code during the competition to remain fair to other entries who can't / didn't open source their project outside of the walls of the knockout servers. This is all to say expect LOTS of activity on this repo once the competition is over.
Any feedback to go with the low votes?
Interesting and cool experiment, but not very useful IMO. Relies on remote central service making it more vulnerable to code injection and latency. This is basically an emscripten compile server and a code injector. As I said, interesting experiment, but I'd like to see a 100% client thing... :).
Yes a client side Emscripten is definitely the next step. This is just a demo of the whole idea. Anyway, thanks for checking it out!
It is not for the general public, it is for developers who will be writing the scripts. If a developer decides to do "process.exit()" and it works as expected, his goal is accomplished, but I wonder why anyone would want to do it.
I assume, you are referring to the "Internal Server Error" message as the server being shut down. If yes, it does not shut down the server, it just a 500 response caused by an undefined variable, you can do the same even with "lul.wut()".
we put a dummy user to add traffic . our app will clear data after 15 min. after u add a traffic it will appear in ur current location.please scroll map to appear traffic.
Thanks for the input. Bar charts vs lines are a toss up. Ultimately, the user would be able to configure the look and feel of the charting.
Thanks for reporting issues, currently it is fixed, but I don't think it's fair to deploy after end of challenge, but I will release proper version with richer feature set by the end of this week to another host.