tmd83

While they do a ton of good work, they do love to claim everything was first invented by them.

This doesn't take away from what wondrous thing a designer can achieve. It's an enormously difficult thing to design something that's functional and pleasing and in some cases provide a mood (calm, fast, serious). This sort of bullshit from what I imagine uber expensive designs rebranding major corporations simply highlights the value and rarity of a good designer.

I'm curious were they ever serious about their craft? Or the pursuit of promotion and glory took away their original ethos or they drunk the cool aid so much that they actually believe what they are saying?

Now in terms of a little thing that's a major annoyance is the alarm. Android has this feature where upcoming alarms are shown as notifications which you can turn off (just the next one). I set multiple alarms for the morning so that if I shut off one I get another. Now if I wake up on the 1st alarm I will have the next 2 on notification that I can turn off. On iPhone I will keep having those alarm bells and turn them off (which can wake up my kids/wife) or disable them once I wakeup and I might end up forgetting to turn them on for the next day.

Now the freedom in terms of application or browser and extension!!! are obviously general problems.

I have only really found pyroscope.

This page shows event pattern available for both oss vs. cloud. The blog doesn't mention exactly how this is being which would be an interesting read but I understand if a secret sauce.

I recall quite a few years ago a standalone commercial & hosted tool for doing something like this just on logs for anomaly detection. Anyone has any reference for similar tools for working with direct log data (say from log files) or in a similar capacity like hypderdx (oss or commercial)

Is it marking something active on access or actually checking execution? On execution doesn't work for at least js payload on the other hand on access would add to noise say for an ls.

Seems like a JS frontend framework or a JS SSR is the only option for such use case. If SSR and API force a JS backend that leaves a lot of the benefit that other languages bring to the table and effectively limiting you to 1 (JS) or 2 (TS including) languages. Seems like a sad state of affair in that regard.

Needing Transactional semantics for jobs alongside an application operation makes a lot of simpler queue/tool choices difficult.

What's the solution to such a use case?

Do you care to comment on the smartwatch features or health monitoring one?

say password > mfa1 > mfa2 > done

and as each steps complete what's the next security steps for this particular user's configuration and simply allow just that transition. Once we are at the done state the authentication is marked as successful.

Not storing auth state in UI (regardless of any MVC concern) and allowing only a very narrow allowed state of transition seems like a trivial design choice. I assume google has no shortage of people for security focused design.

The UI stack being created together and dismissed rather than created/called on demand as state transition happens also seem a very wired design. Perhaps I don't understand the reason cause I'm not an android programmer.

For example I keep seeing auto-wait being talked about for Playwright but doesn't cypress have that too? It seems playwright has better browser support and multi-window/concurrency story and cypress have better built-in tools (like a test-runner UI).

Basically looking for recommendation for test-automation for an old complex app mostly written using server-side tech but has potential for react and such moving forward.

As for overhead of tracing I wanted roughly compare (obviously it depends on the application a lot) stacktrace sampling vs. tracing based one. Are they usually of similar overhead or say tracing is lighter?

I was thinking tail based sampling could be a lot more expensive because say a head based sampling is doing trace for 10% request whereas regardless of how many sample are kept a tail based one is dong 100% trace. So tracing overhead would be much higher right?

I'm not sure why head based sampling is being called accurate in your doc? Isn't it the least accurate in a sense that it's purely statistical and rare outlier like latency spike or error could be missed?

And yes obviously a tail based sampling has to be something like (trace 5% random request or 1 every five + any outlier that gets calculated based on the captured trace)/

The difference between old days of APM vs. tracing as I understand is two things.

1. Originally APM was single process and it was language aware, usually do sampling stacktrace to find where times are being taken and some very well know place to instrument for exact timing say response time or query time.

Tracers are more working by instrumenting methods of framework/servers/runtime at well known point and getting the timing. In man ways it's a lot more coarse as it might know of a hot loop that I have in my code. But it can trace very well with exact timing at framework boundary like web, cache, db etc.

2. The APM were primarily single process and couldn't really show a different service/process which doesn't work in a micro-service/distributed world.

The way I understand it is that Tracers would allow me to narrow down to the service/component very easily. Whether I can find out why that component is slow might not be as easy (not sure what granularity tracing happens inside a component).

I wonder if this understanding of mine is correct.

The second thing I am really unsure about is sampling and overhead. What's the usual overhead of a single tracing (I know it's variable) but generally are they more expensive at a single request level. Also do they usually sample and is there a good/recommend way to sample this. I forgot exactly who but (probably NewRelic) was saying they collect all traces (like every request?) and discard if they are not anomalous (to save on storage). But does that mean taking a trace is very cheap? And is that end of the request sampling decision something that's common or that's a totally unique capability some have.

I understand the point of the database client having access to to the database key and not the key to the secret vault. So in this case other secrets at the vault are essentially protected. But let's say I really have this one secret to protect in which case is the vault fairly pointless?

Is it essentially that if a client using KeyX for some purpose than a compromise of said client will essentially lead to KeyX and there's really no way to protect it?