STRML

Now it's in the PHD, backdated to 11:37:00 UTC-6. How could it take an hour to even admit that an issue exists? We have alerts set on this but they're useless when this late.

Seeing it in eu-west-1 as well. Even the dashboard won't load. Shame on AWS for still reporting this as up; what use is a Personal Health Dashboard if it's to AWS's advantage not to report issues?

It's not just us-east-1! They're being extremely dishonest with the green checkmarks. We can't even load the s3 console for other regions. I would post a screenshot, but Imgur is hosed by this too.

We've been watching the ETF with interest. To gauge market sentiment, we launched an ETF approval binary contract (https://www.bitmex.com/app/trade/COIN_BH17). COIN_BH17 saw a jump from 35% to nearly 50% today. Optimism on the ETF is rising.

To my sibling: the issue is that people can and do consider Flexible SSL "good enough", when it really isn't. It gets you the green lock and the warm fuzzies, but the page just isn't secure. A false sense of security is worse than no security, because no security at least is glaringly obvious.

In this case, perhaps mutability is the real problem. Array#filter is quite fast in JS and never mutates the array.

On hidpi screens they're emulated pixels, not hardware pixels (pretty much for this reason).

The new API looks quite a bit like the API we've been running in React-Router-Component since 2014 (https://github.com/STRML/react-router-component).

Of course, RRC is not as battle-tested as React-Router; it's more of a "works for us" project I took over from @andreypopp as we had already committed to the router before React-Router became stable. And given the many backcompat-breaking changes to React-Router, it seems to have been a good idea.

React-Router does great work though; RRC doesn't even pretend to do React Native and the Environment selection we do have (pathname, pushstate, etc) isn't quite as nice. RRC also can't do some of the more interesting features, like Recursive Routes. All of the children of the router have to be `<Location>` objects.

Edit: React-Router's docs are awesome! Nice work @ryanflorence.

Just wanted to say, you and the team are an inspiration. The CLJS community's work goes a long way toward making web applications - dare I say it - reliable - and fun to code too.

Congrats on this great release. We're all looking forward to what comes next!

This would be great - and the measurements used to do this throttling could be used to populate that data!

React is in the business of limiting its API surface, not increasing it. I think they have done a great job of it - libraries like this should exist in userland.

This is where batched rendering really comes in handy. For example:

https://gist.github.com/STRML/cc368c46c2d7de8679196e69ddbcae...

The key is, even in your case (with price alerts), you'll still want to tick occasionally, thus the `FORCE_TICK_INTERVAL`.

React's own batching is smart enough to merge the work. For example, before the next tick, one component calls setState() 20 times, another calls it once. Only one rerender will actually be done.

Some more discussion on rAF batching here: https://github.com/petehunt/react-raf-batching/issues/8

Yeah - that's a really great trick! You can also get this somewhat "for free" by batching updates on `requestAnimationFrame`, which never fires when unfocused.

https://www.npmjs.com/package/visibility is a nice little package that encapsulates some of the browser compat issues, if you have out-of-date clients.

It depends on what you're doing. If you split up tasks and interleaves them (such as: process a few items, stop, set another timer, process a few more), actual CPU% throttling would be better. It would be easier to have certain timers take priority, such as heartbeat responses or notifications.

To whoever downvoted this: I am the author of the post above, and in response I've removed the JS-centric layout.

It's different because it can't just slow down a running task.

Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

Oh, it's awful, I agree. This is the nicest layout but the JS is terrible.

I've reverted to a plain-HTML layout.

Clearly; yet it is encouraging that CREST finally ended up online.

That's pretty sad, especially for an agency that must have a certain amount of technical competence for their day-to-day.

This could be easily solved by releasing all documents and a list of their hashes simultaneously.

That hit me pretty acutely today when upgrading. Restarting slack took 15 seconds and pegged all 4 (8 logical!) cores. Why should a chat app ever do that?

I get that a billion dollars doesn't buy what it used to, but it really ought to buy native apps on at least all the major platforms.

That's assuming a 1.5s reaction time. Surely that's quite slow and accounts for the bulk of the difference.

That's not necessarily true. I work on BitMEX, and we offer quarterly futures contracts that don't have holding fees. Today, with the price movement, they've been even trading at a discount to spot.

> Somewhere have to start the transition

By removing every single legacy port long before there's anywhere near ubiquitous USB-C? Even USB-C cables themselves are more commonly sold as USB-A to USB-C. I love having usable DisplayPort/Thunderbolt, HDMI, and USB-A on my 2013 rMBP - I never need a dongle. If I went to a 2016, I'd need at least 3, every day.

> Prioritising thinness and weight over everything else

Battery life is certainly not the same, and the lack of a 16GB option or a faster processor is a well-missed loss.

How useful is that, really, considering you couldn't possibly use a Yubikey to configure disk encryption? Unless you actually put the unlock key on the Yubikey somehow (I've never heard of someone attempting or succeeding at that), anyone with physical access - which is what this is intended to protect against - could still wreak all kinds of havoc with disk access.

It's certainly easier and may even be safer (in the case of a malfunction, which has happened on OSX) to just use a longer password.

Seems pretty nice. A few things I'd like to see:

1. We should be able to configure this for a few/all branches (including PRs) and have conditional build tasks based on branch.

2. We need be able to access resources inside a VPC.

3. Turnkey chat integrations would be nice, but it's not a big deal to just curl.

4. We need a way to execute actions on failure.

And it doesn't look good for any of those.

t2 instances notoriously throttle way down to 10% if your workload is too consistent. The full performance is quite good from the 2.40 GHz E2676 v3, but at 10% it's worse than a Raspberry Pi. And this will always hit you at the worst time (when under load).

As for the SSDs, they're just GP2 storage, which is an order of magnitude slower than DO and nearly 2 orders of magnitude slower than Joyent Triton.

So AWS is providing a seriously inferior product here, but it's under the AWS umbrella and peers with the rest of their services. The question is: will the target market care about any of AWS's other services enough to make the inferior $/perf worthwhile, and will they integrate easily enough for the average developer to use them?

It doesn't appear that Lightsail actually allows hooking up data volumes. This is a surprising regression considering AWS basically invented it, and a major downside compared to DO.

So network-attached storage for Lightsail is upside for AWS, but all downside for the customer.

It's just an artifact of network-attached storage.

Many competitors just use local storage, which comes with its own serious downsides for the company and customer. DigitalOcean just recently launched its Volumes service, but it's very limited compared to EBS, and not nearly as fast as its local SSDs.

EBS is generally fine but I would really enjoy the option to have ~40GB local SSDs for caching (but I suppose you can always grab an r3/r4 and cache in memory if that's your bag).

The best cloud I/O perf I've seen, bar none, comes from Joyent's Triton containers. Beats even DO by 3-4x. Beyond that you need to go bare-metal.

Re: VPC peering, the blog gets into more detail. I tried it out, worked great. Simple egress. https://aws.amazon.com/blogs/aws/amazon-lightsail-the-power-...

A compelling product. The dashboard looks great. They even replaced the confusing term "user data" with "launch script", but they fall back into it later. SSH in-browser is great too and can be bookmarked/opened in a fullscreen tab. Uploading (instead of pasting) your SSH pubkey is a bit annoying.

The docs appear to say you can add these to a VPC but I don't see how to do it.

They don't say the SSD storage is local, so I'm sure it's not.

A few runs with `fio` confirms this is EBS GP2 or slower:

The bench: "fio --name=randrw --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=4G --rw=randrw --rwmixread=75 --gtod_reduce=1"

Lightsail $5:

  read : io=3071.7MB, bw=9199.7KB/s, iops=2299, runt=341902msec
  write: io=1024.4MB, bw=3067.1KB/s, iops=766, runt=341902msec

DigitalOcean $5:

  read : io=3071.7MB, bw=242700KB/s, iops=60674, runt= 12960msec
  write: io=1024.4MB, bw=80935KB/s, iops=20233, runt= 12960msec

More than an order of magnitude difference in the storage subsystems.

These appear to just be t2.nano instances (CPU perf is good, E5-2676 v3 @ 2.40 GHz, http://browser.primatelabs.com/geekbench3/8164581).

For advanced users, there isn't much compelling here to make up for the administration overhead. It's a little cheaper than a similar-spec t2.nano (roughly $4.75 on-demand + $3 for a 30GB SSD). The real win is egress cost; you can transfer EC2->Lightsail for free. 1TB of egress would be nearly $90 on EC2, but is only $5 on Lightsail.

In other news, EC2 egress pricing is obviously ridiculous.