tlarkworthy

It's here for Google https://accounts.google.com/.well-known/openid-configuration

Here for Microsoft https://login.microsoftonline.com/common/v2.0/.well-known/op...

I was just researching graph representations. I would have used dictionaries for edges and nodes indexed by their IDs.. because that representation is json-merge patchable, which is useful for specifying atomic bulk graph operations.

I use uptime robot connected to a serverless function, with the great property it can notify me of outages on top of being a scheduled http call. I think the first 50 are free!

https://uptimerobot.com/

GitHub actions are another option

The opening paragraph says "we have a good product". No, you have a good device, it's not the same thing. Maybe he thinks org ineffeciency is about not covering enough product use cases but the other parts of the post suggest focus on technical characteristics as the metric to measure success. Obviously he is way smarter than me so what do I know but that's what I see.

Seems a little off to be calling out perf metrics when the whole system hasn't found product-market fit yet

There is no undefined value in JSON. (Of course ommitting something is like an undefined)

https://stackoverflow.com/questions/13796751/json-undefined-...

I tried VR on an airplane and movements of the cabin affect the in game world in extremely weird ways. You can't use VR under acceleration presently, it messes the stabilization up.

It's very easy to cause in the ORM because by default a chain of SELECTs may ready different committed data unless you add row level locks like FOR SHARE . In a horizontally scaled backend you need these locks usually, but it takes scanning the DB log to figure out how to get them in the right place.

You can't effectively use an ORM without detailed knowledge of the generated output unfortunately. It does not add locks for you, so it's probably just wrong in prod when horizontally scaled and requests span multiple statements.

It's time to stop working in tech for tech's sake and actually solve problems in other domains using computers as a tool-for-thought not as a business process support system.

Unfortunately the host header is spoofable

DCA reduces variance in your returns for a slightly lower rate of return. It's a risk reducer with a clear derivation. You exchange expected performance for reduced variance in outcome. That's useful, you can plan better with reduced variance.

https://www.financialplanningassociation.org/article/journal...

Off topic but is there a good way of running wasi on browser?

The vast contribution to greenhouse gases is well established though, so a preference to white meat is meaningful

Supabase has distributes consistency issues and not suitable for multiplay/offline first. I am annoyed at firebase for real technical reasons like Firebase auth can delay page load by several seconds. So the real alt to firebase (on web) is replicache IMHO

"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat." -- Roosevelt

I am suprised the author has such a low opinion of optimism. After internalising Roosevelt I have actively tried to temper cynical thought when interacting with others. It's easy to throw stones and find fault but its much more powerful to be in the driving seat of change (which innately requires optimism)

NoSQL is like simple assignment to storage and one layer of obvious indexing. Its lower level, and therefore much faster and predictable because there is no query planner guessing how to assemble things.

Tuning SQL on the other hand is a guessing game with the query planner. You can express a lot more but 1% of those expressions could down your DB.

I like both, but if you want performance NoSQL is the winner.

They get paid while sleeping so a good wage adds up fast

I have YouTube premium. Everytime my kids get exposed to even age appropriate àds it generates attraction to crap. Even in magazines for kids. So I just keep ads out of their system and they seem happier and more internally satisfied

The imports are chunk reuse. Each notebook is an es6 module you can import from any npm package.json You don't need to export it as documentation, it is executable documentation which is better, though you can print it if you want. The footer backs up the source to github

Your stuck on Knuth's definition of literate programming but this is better than that

No it's a very good stat, I think they mean measure after 52 weeks, and note they exclude self published books, it's the crème and still suffers from huge Pareto (as expected)

What about this https://observablehq.com/@tomlarkworthy/redis-backend-1

I use an invisible firebase anonymous login for public rate limiting.

I have an open source example using openai https://observablehq.com/@tomlarkworthy/tarot-backend

It's this data-led uncritical thinking that destroyed facebook

ycombinator startup school disagrees and says it's one of the two CRITICAL things founders must have a hand in.

Of course you need to interpret it but its incredibly important and I do not think you really know what you are talking about.

https://www.ycombinator.com/library/6g-how-to-talk-to-users

Almost all the major fails I have seen in my career have been some derivative of not understanding your users.

I am pretty sure it's a deliberate inside joke from expertsexchange days of yore

No I think it is still bad in isolation as it's prone to group think and you lose the chance to exploit experience generated globally which may be unique and irreplaceable.

At Firebase we sometimes pondered the feasibility of a SQL version, but the semantics of SQL seem littered with semantic footguns that don't lend themselves to offline, secure, scalable and event driven distributed applications. We know everybody wanted better query expressivity but delivering that in a mobile friendly, clienside, secure package was very difficult to see the path to.

tripletstore/datalog actually seems like a decent compromise between SQL and no-SQL that could actually work out! Awesome idea!

This is to minimize the round trips, I think a saner solution is have content served from many edge locations nearer the user so the impact of a roundtrip is so much less. Consumers and business users definitely want jazzy websites and 14kb is not able to do much.

Yeah but that often casts the net too wide and catches expected 3rd party internal logic or catches the exception too high and you lose the local context.