> Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device.
When I have tried this I have encountered multiple problems, first that the Rust test framework requires std, making it convoluted writing test code – but when working around that using conditional compilation, I run into other things like the `esp-hal` depending on crates that won't compile on the host.
> "Then, in late June 2011 […] I faced a medical emergency requiring immediate surgery and a eight-week recovery period confined to bed. […] On July 1, 2011, HP launched the TouchPad tablet running WebOS 3.0 […] The launch was botched from the start. HP priced the TouchPad at $499 to compete directly with the iPad, but without the app ecosystem or marketing muscle to justify that premium. The device felt rushed to market, lacking the polish that could have helped it compete."
He claims to have been working with Palm closely for a year, yet he somehow must have missed how bad things were. The product was a week or two away from launch when he had to step away. To me it sounds like the bad decisions had already been made.
The big difference between Zeppelin and Jupyter is how you can easily build interactive notebooks with input fields, checkboxes, selects, etc. This is much closer to what I thought notebooks were going to evolve into back when I saw them the first time; Hypercard for the data engineer. Observable has kind of delivered that, but on the frontend. Jupyter seems to me to have gone down the path of code editor with cells, and Zeppelin unfortunately never got any traction.
I'm an AWS Solutions Architect and I was helping a customer with the same issue as in the article a couple of months ago.
What I found out when I researched it is that there is a subtle difference between using lifecycles to move objects to other storage classes and for deleting objects: deletions are not transitions, they are expirations – and expirations are free. I submitted a clarification to the S3 documentation and now it says "You are not charged for expiration or the storage time associated with an object that has expired." (https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecy...)
If you have objects in IA or Glacier there is a minimum duration you're charged for, but there will be no extra charges for expiring these objects.
> The problem is that most websites simply aren’t compliant. They choose to make a mockery of the law by offering a skewed choice: Typically a super simple opt-in (to hand them all your data) vs a highly confusing, frustrating, tedious opt-out (and sometimes even no reject option at all).
Like the Techcrunch site where this was published.
I was confused on most examples I got because they started in the middle of a block comment. That's clearly wrong, but was it an artefact of the presentation rather than the generation?
I help companies reduce their AWS bills, and do cloud migrations to AWS. This is well suited to being done remote, and I'd be happy to do a free video call to get an idea of your bill and what can be done – it's almost always possible to reduce your bill by a large chunk. I've been working with cost optimization in AWS for a couple of years, and with AWS for more than a decade.
We went through something similar a couple of years ago, when TLS wasn't as pervasive as it is today and at first focused mostly on minimising the response size – we were already using 204 No Content, but just like the OP we had headers we didn't need to send. In the end we deployed a custom compiled nginx that responded with "204 B" instead of "204 No Content" to shave off a few more bytes. It turned out none of the clients we tested with cared about the string part of the status, just that there was a string part.
When TLS started to become more common we realised the same thing as the OP, that the certificates we had were unnecessarily large and costed us a lot, so we switched to another vendor. When ACM came we were initially excited for the convenience it offered, but took a quick look but decided it would be too expensive to use for that part of our product.
Is anyone still seeing problems like this? I found duplicate entries in our Parquet CUR reports, but not in the CSV versions (we export both, for reasons). The duplicates were from 24 September beween 00:00 and 13:00 UTC and only for Usage and DiscountedUsage. Not limited to EC2, though, it was Redshift, CloudWatch, and a lot of other services too.
Great to hear that tag based auth is coming. I'm at a loss about how to use it without something like that. It looks like you either have to handle each instance individually (which makes no sense where AWS has been pushing auto scaling and spot instances for a decade – instances are ephemeral in our world), or have one rule that applies to everything in the account. To me, being able to limit access to groups of instances is a required feature.
On the Example Script page (https://iterm2.com/python-api/tutorial/example.html) it says that the script communicates with the application using websockets ("The underlying implementation uses Google protobuf and websockets"). This makes me think that it could support other languages and ways of scripting it in the future.
We've been running databases on ephemeral drives for many years, the key is using a database with good replication and failover.
I don't think you should trust your data to a single disk, whether or not it's a physical device in your own datacenter or an EBS in AWS. Everything fails eventually.
Excellent, thank you. It would be very good to have that information in the official documentation. I've wanted to refer to something like that for compliance reasons, for example.
i3 and f1 also have encrypted disks. I have found some references on blogs for this, but the only place I've seen it mentioned by AWS directly is in this presentation from re:Invent 2017: https://youtu.be/o9_4uGvbvnk?t=30m20s (at 30:25 the presenter mentions that the nitro cards "protect the underlying flash device and customer data through encryption").
Here's a different service I made that includes other regions, continously updated spot instance prices, and a few other nice features: http://ec2pricing.iconara.info/
> Where possible, and where it makes sense, you should try to test as much as possible on your host machine, not on the target device.
When I have tried this I have encountered multiple problems, first that the Rust test framework requires std, making it convoluted writing test code – but when working around that using conditional compilation, I run into other things like the `esp-hal` depending on crates that won't compile on the host.
What is the recommended way to test on the host?