HN user

fiokoden

49 karma
Posts9
Comments57
View on HN

Just never use Google for building applications.

They have invested heavily over the lifetime of the company in avoiding providing support. That reputation can never be revived.

Google does not have direct customer support in its DNA, it has the opposite, whatever that is.

They have not demonstrated relentless commitment to being available to resolve issues, and nothing matters more than this if you've bet your company on their platform.

If something goes really wrong. Amazon has your back and you'll find someone who'll listen who has the power to resolve it. Google, you're stuffed. If you've built you're business around that thing that went wrong, well time for regret.

Stripe has dropped its key advantage.

It started out with outstanding software support for the most popular platforms but now it doesn't.

Develop an application in ReactJs? Stripe hand wave: ahh go build your own solution or use some third party thing somewhere over there in "the community, sure you can trust it".....whatever, we're busy, and ReactJs, hmmm haven't heard of that.

My understanding is that overuse is one of the primary reasons health spending is so high in most countries.

No data to back it up, might be wrong.

I can tell you I absolutely loathe pouring money into health insurers to prop up an overused and wasteful system. I'd much rather something like this personal account idea.

The key idea I see here is that instead of dumping money into insurers, you have your own government mandated "health savings account".

People would be far less likely to overuse health services if they felt they were paying personally.

That's a powerful idea.

A Decade of Dynamo 9 years ago

> we do find ourselves sometimes implementing relational DB functionality at the application level to compensate for Dynamo DB's "flexibility."

Yep, this is A-grade crazy, and exactly my point. I would question if it's "sometimes", or "actually almost all the time, now that we think about it, there's not much that we CAN do with DynamoDB without writing application level database functionality."

What a joke.

Surely this has completely destroyed the value of this software.

Hard to imagine any good software written by HP anyway.

Don't they employ lowest cost programmers? Heck the probably designed it using UML or something silly like that, with hundreds of business analysts and vast numbers of stakeholder meetings all working to reach consensus, before getting all those lowest cost programmers to try to write what they think the spec might mean - all truly inspired software is written this way.

Doesn't this shake your certainty about how bad other drugs are?

I mean if this drug was bad enough to go to prison for the last 50 years, but now it's not, what about others?

A Decade of Dynamo 9 years ago

I don't know why amazon is so taken with Dynamodb. I find it to be incredibly unintuitive and lacking real world application, requiring applications to perform gymnastics to work with it.

I read your blog post nice read. With respect I suggest your product is too narrow.... space in salons is a very small target user base. I'm not surprised you didn't get much traffic or sign ups from SU Battlefield.... probably no one watching owns a salon or is a beautician.

Humble suggestion is to pivot to a new or revised idea.

How is your traction right now?

The real risk is that NK will nuke the Pacific Ocean, under the illusion that people/countries won't care much.

Remains to be seen but I think that will be seen as an attack on the world, not on no-one.

Which is to say, DIY symmetric multiprocessing, or BYO kernel code in-application.

I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel.

In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM