HN user

takumo

105 karma
Posts1
Comments15
View on HN

Yes, this article is probably longer and fluffier than it needs to be but there are some real truths here.

Payments are one of the original service orientated architecture systems, in production your payment is processed by at least three or four parties each of which will call several systems or sub-systems to process a payment.

This method clearly works for Uber, who have a lot of payments going through their systems most of which are of a relatively small value. Dropping a payment and either asking the user to pay via a different option or simply writing off the revenue for a handful of transactions is probably workable for them.

I have the opposite, the number of transactions we process is relatively low, but the average value of these transactions is high, well in excess of 1000 USD. This leads to the following issue:

1. Screwing up a payment and asking the user to try again can be a big hit to user confidence. 2. We can't write off even a single payment/transaction, they're too high value to write-off. 3. Processing fees and refunds for making test transactions in production are too expensive. If a test costs more than $10 (to test in production we must test with production transaction values) that's going to rack up quickly.

Some of the gallery images are fantastic. Showing some really interesting, highly specialised applications that fill a very specific need in an exacting manner.

The motor winding and water supply modelling applications are especially interesting.

I think this idea makes some sense, in a mixed-traffic world where some vehicles are autonomous and others are not, some indication that a vehicle is driving autonomously is useful information to everyone around them. Additional situational information, provided it is not overly intrusive or overwhelming is generally beneficial.

As for the colour, clearly Mercedes requested Turquoise for brand reasons. I wonder if there is a better colour to be adopted as a standard? External indicator lights of any kind seem like something that needs to be standardised before we end up with a whole mess of different colours on the roads causing confusion.

It's true, car dealers "can't sell" EVs. Not because people don't want EVs, but because dealers either don't want to sell them, or don't know how to sell them.

I've owned 3 EVs since 2016 and I've been to franchise dealerships each time. I've been to dealerships both with and without dedicated or specially trained EV sales reps.

Sales reps who've not had any specific training on selling EVs, working in dealerships with no dedicated EV showroom space are _terrible_ at selling EVs IME. At best they're disinterested in making a sale, at worst they actively discourage you with all the common EV related FUD.

Showrooms with dedicated space to showcase EV product offerings, information about EVs and which have marketing material actively incentivising the benefits of an EV, also have sales reps who are knowledgeable, helpful, and actively seeking to close a sale.

Except its right there in the transcript. It used to be a self-service SaaS application, to enterprise sales. Nearly all features are gated behind an enterprise-sales "contact us" box with no transparency in pricing.

They're not selling to developers, they're selling to business executives, they give a nod to the fact developers are the end-user of this product, but all the material on the site is as executive-oriented as it gets. Listing other brands they've sold the product to, big stats about ROI and increased sales and revenue and "white-papers" which are really just fluff-pieces to hype up the product.

As a developer, I need to see transparent pricing up-front. It's no good telling me about features, APIs without a way to figure out what it'll cost because that cost might easily be orders-of-magnitude out of range. Look at the pricing for Algolia - $499/mo and you don't actually get any of the features that separate it from products like ElasticSearch which are available as open-source downloads or as a much cheaper hosted service. You get tooling to make integrating search easier than the open-source alternatives, but now you're bound to the tooling provided by that service and its capabilities, or writing your own tooling anyway.

Either give me a monthly cost I can use to determine if its worth suggesting a product, or give me usage-based pricing that lets me start out cheaply, and lets my bill grow as the value I gain from your product grows.

This is the case for many, if not most, modern/high-tech cars, especially EVs.

The on-board systems have become very tightly coupled, if not monolithic to the point where a broken info unit will prevent the car from starting.

I had the infotainment system replaced in my e-Golf a few weeks ago, it took two technicians three days to install and configure to work with all the car's on-board systems.

Edit: If I _had_ to guess, I’d say this is because the car industry (especially electric) has been pushing to innovate features so rapidly that the time hasn't been available to engineer, test and prove decoupled systems.

It doesn't mention it because it isn't really relevant. The international app is still being censored according to the same rules as the app in China.

It still prohibits users from discussing topics the CCP doesn't want brought up. (e.g. Tiananman Square, Falun Gong, organ harvesting, and Xinjiang)

The main differences are that outside of China you're not bound by their laws requiring users to sign up using their legal name and provide identification to prove as such. In addition to which people aren't being disappeared or arrested for their posts.

Looks very helpful, a shame that it has to rely on Selenium/ChromeDriver.

Very frustrating that AWS SSO has no API, especially when every other AWS product is offered API-first, it makes this feature so very difficult.

While there are other ways to manage access across multiple AWS accounts within an organization, none are nearly as fully-integrated as AWS SSO, with the ability to create users/groups and then assign their roles within accounts.

There are other methods, but I've yet to find something which can let users log in using directory credentials, see a list of all AWS accounts they have access to, and have one-click sign-in to those accounts.

That’s a good question.

I've had a bit of a look and it appears that the bulk of this is undertaken in the Trace Context specification itself.

The data passed back for a trace includes a reference to the trace’s location within a tree. The root node for this tree should (perhaps must) be generated server-side, and the client-side can only send traces which are children of the root-trace given by the server.

Specifically the `traceparent` data:

    traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

Where 00 is the format version, 0af7651916cd43dd8448eb211c80319c is the root trace ID given by the server and b7ad6b7169203331 is the ID of the direct parent of this trace.

While this doesn't prevent a malicious user from polluting a single trace, it does limit their scope to the root trace they've been given. It should then be possible to discard the entire trace, though I think identifying tampered traces could be difficult.

This is great, as the title says, this means that web applications can now have tracing across the whole stack, all within the same platform. Support for AWS X-Ray is great for me due to it’s very low cost at the small scale.

So far every tracing solution I've seen deals with _either_ server-side or client-side. Very few platforms support tracing across both.

Looks cool but really should mention early on that it doesn't use SDL or OpenGL to render the game but uses a specific feature of iTerm2 to render a series of images in the terminal, on other terminals it just shows a black screen.

Looking at the site, it appears to target other platforms like Facebook, Twitter and Instagram where videos are often viewed without sound, and which don't have built-in support for subtitles.