HN user
hnchat:KgFSVAzP8f0I8GMEOQ7U
https://github.com/icodeforlove
Yea but when using promises with async/await its very beautiful.
await asyncFuncOne();
await asyncFuncTwo();
If they don't have X-Frame-Options the attacker can also just use a 1x1 iframe on a popular website or shitty ad network to trigger that page to load
I don't know if I agree with this.
Even with paper ballot we still have to trust the people/devices counting the votes.
As an American citizen theres no website I can go to and check my vote. How do I know it was even counted, or properly registered.
Yeah, but its a pain in the butt to iterate when doing that, especially when you just want to dump off clipboard, or drag & drop.
Also wanted an excuse to play with a few browser features :P.
This was made to make playing with Data URI's much easier.
I find myself often needing a quick way to generate a Data URI when playing with files on jsfiddle, or codepen (due to CORS). So I thought it would be nice to have a website that locally stores those files.
This was thrown together in a couple of hours (using react/mobx), and inspired by [0] "The XSS Game By Google post". It turned out that quite a few people didn't know that you could use URI's for things that were not images.
If you have any suggestions feel free to voice them :)
I made this because I was getting upset with the lack of a solid solution that did everything.
It locally stores the files as well, click on the hamburger menu to see them.
- drag & drop
- manual upload
- paste
- custom file creation
- local storage
Oh, awesome. Hopefully they drastically reduce it.
They are charging us too much for time!
We need the gates foundation to donate a billion, that should get us 31 years on the clock.
Awe, hey we end up with more than a empty hole! What about all of the dead code!
Also those jobs wont be around that long. Every year we have quite a bit of progress on Self-Driving Cars.
Seems like in chrome you can go much higher!
Here is a example of 5M
data:text/html,<script>window.location='data:text/html,<!--'+new Array(5000001).join('a')+'!--><script>document.documentElement.innerHTML=window.location.protocol+\':\'+String(window.location).length;</'+'script>';</script>
You can store MASSIVE amounts of data in these things. It also seems to eventually break the url display and reverts to about:blank. It still retains protocol integrity though.
I did
data:text/javascript;base64,YWxlcnQoMSk=
data:text/html,<script>alert(window.location)</script>
We currently just rent a few big boxes on OVH, and manage them via Rancher.
You should checkout ranchers channel for some videos: https://www.youtube.com/channel/UCh5Xtp82q8wjijP8npkVTBA
It's mind-blowing that they offer this for free, considering the impact it has.
Because theres no perfect solution at the moment we have opted for a 4 disk setup, and mirror them all using ZFS. We also do 10 minute snapshots, and incremental snapshot backups (to S3).
Feels safe enough for our needs. Before this we didn't have 10 minute snapshots of all our data so this has actually allowed us to recover from dev errors as well (if they were to happen).
We do have our DB running in a container + mounted volumes that use the above configuration.
We have been using Rancher as well... It allowed us to move away from DO and AWS. Now most of our infra is from OVH :).
It's been smooth sailing.
Because of massive costs savings we were able to just reinvest it in our own redundancy. Also 12-factor apps are pretty damn resilient.
Yep thats what it looks like.
So the take away is Go is better at handling massive amounts of open outgoing network calls.
In Node.js you want to restrict this to prevent the server from choking. If they did that I bet performance would be very similar.
I would like to know more about the implementation.
I have had node do 12000 requests a minute with no problem (on a single core). In this case they had 4 two core boxes, so they needed each one to at least perform 42 requests a second under max load.
I want to know more :)
This could have been solved with a simple addition of another queue.
Don't spawn off heavy requests without a throttle / queue, or else you will overload your single core.
We normally don't think about this because most requests are just tiny queries / small http requests.
Not really understanding the down votes (maybe the double question mark??), but oh well.
This is a valid comment considering that the EC2 instance mentioned is a 2 core box, and there is a possibly that the node implementation didn't take advantage of both cores.
- Go has multi-core support out of the box
- Node.js has to be shown a little love, and has limitations. But this would have been a great use-case for Cluster.
If the Node implementation was using all cores, then I wouldn't have asked this question. As it stands I don't really know what we are comparing even with all the graphs.
Also we are still missing a little info on how they handled the requests. When you have a endpoint on a node server that is not a simple one, it is best to queue those before handling them (yes a additional queue). This prevents the process from choking because it just opened up NNN requests to S3.
Most developers are not working with hundreds of HEAVY requests a minute, but in Node.js this usually has to be handled with care, and does not work out of the box.
But if you want to pick up a shinier hammer then Go for it.
No mention of Cluster??
The email verification was easy when they provided gravatar ids, which used to just be MD5(email).
Doesn't github already make majority of this data public? With the exception of emails... Previously they used gravatar hashes which allowed email brute forcing (since removed). Then they also were not omitting emails from commit messages.
We also should remember that most react apps are single page apps, and usually this .js file is aggressively cached on a CDN. Most interactions are close to instant.
Server-side rendering fixes the issue of time to first pixel. I think we don't really need to worry about a 10KB bump, especially considering how many websites are serving ads to mobile which are sending over MUCH MORE DATA.
I have been traveling around to many 3rd world countries, and when I hit a website thats loading a little slow you know what I do? I wait for it to finish loading, or I refresh. One of the biggest things a site can do to improve speed is picking a good CDN (Cloudflare).
Its not just something me, and you disagree on. I would say it's me, plus a good amount of other, and also most browsers.
If the browser is locked over X seconds it will actually tell you that the script is unresponsive, and ask if it should stop it. But you can of course work around this, and disable it in your browser of choice (http://www.reginout.com/nflp/fix-unresponsive-script-error-i...). Or you could just use a webworker, and not lock the UI.
Good catch.
From my experience though there is a small overhead in terms of workers, also the message cost. But still even if it was 300% slower it's justified because it is unacceptable to lock the browser.
Too many commenters here are coming from the backend, or desktop software where they already have a UI thread. I ask these commenters a simple question, when is the last time you saw your browser freeze? If that doesn't happen often then the devs are doing many things like this to keep that experience enjoyable. Web is it own kind of beast in terms of development, the biggest concern is perceived responsiveness. We get to write off async delays when using webworkers (and similar methods) because users are already used to network requests taking time.
Life before WebWorkers was fun :). Another way was to create multiple iframes, and use a form of hacky message passing to use more cores, but i think this may have depended on the browser implementation.
In response to your last comment, you should check out https://github.com/icodeforlove/task.js. It will do that and much more.
If you wanted to go crazy you can use transferables to get around the memory copy cost. It would be a fun experiment to figure out at what point does it make sense to use multiple workers considering the initial cost of worker distribution.
2.8 seconds is locking the browser
3.3 seconds is not locking browser
When dealing with web it is unacceptable to lock the browser. Also with core / worker distribution you may be able to make the worker approach faster :).
For anyone that is interested in easily using WebWorkers for this sort of work please check out task.js (https://github.com/icodeforlove/task.js).
It allows you to send a pure function with provided arguments to a autoscaling WebWorker pool.
Heres a similar demo (http://s.codepen.io/icodeforlove/debug/ZOjBBB , you can bring all cores to 100% usage)
But for this specific scenario it could have been coded like this using task.js (vs http://afshinm.github.io/50k/worker.js which is not reusable)
// mentioned sort function (close to exact code from site)
function bubbleSort(a) {
var swapped;
do {
swapped = false;
for (var i=0; i < a.length-1; i++) {
if (a[i] > a[i+1]) {
var temp = a[i];
a[i] = a[i+1];
a[i+1] = temp;
swapped = true;
}
}
} while (swapped);
return a;
}
// turn the function into a worker task
const bubbleSortAsync = task.wrap(bubbleSort);
// this now runs in a autoscaling worker pool (first run includes worker initialization time)
console.time('BubbleSort Worker');
bubbleSortAsync([9,1,2,3]).then(sortedArray => {
console.timeEnd('BubbleSort Worker');
}, error => { /* this is extra credit, yes we can handle worker errors */ });
The web has really came a long way, this kind of stuff is extremely useful, for instance you could use it when processing pixel data for a 10MP image with a RGBA array of 40M. In that scenario the work can be spread across all cores, and blows away the alternate approach of just locking the UI. In that case if you were using task.js you would just chunk the work, and use a async control flow library like bluebird.
// in this situation all cores would be at 100% without locking the UI
let processedPixels = await Promise.map(chunks, processPixelChunkAsync);