fiokoden

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.

This needs to be flooded with legit sounding cases to dilute it out of existence.

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.

>> 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.

But damn, the idea of letting people take drugs for nothing more than pleasure really doesn't sit well with a lot of people.

But the most important thing in the US is paying less tax, right?

So don't complain when there's no money to pay for services.

RDS is serverful not serverless.

Lotus Notes was first. Distributed, replicated key value store.

Actually I'm not right: http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.h...

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?

I'll write tests when the product makes money.

Premature optimization.

Cause it's fun.

Could you explain more please about what you mean?

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.

But why?

What use is this to anyone?

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?

I wonder if techcrunch could do more somehow to connect Startup Alley participants to its online traffic flow. No idea how, just germ of an idea.

What do you mean about cloud flare article?

It might be free now.... I seem to recall reading somewhere.

Grim.

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.

And now you're implementing SMP in application. Zero chance of doing that as well as the Linux or bsd kernel.

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

Wrong. Cracking the app does not give you access to the VM host. These apps are running in a VM. There's no relationship at all between cracking the app and cracking VM host.

How can any performance gain match the benefits of running on a tuned SMP kernel?

What exactly happens with SMP with this sort of application?