HN user

t00

72 karma
Posts0
Comments52
View on HN
No posts found.
How I estimate work 6 months ago

We do similar but sprints are somewhat flexible, more like versions. We chuck the features we want from the top of most needed, split into stories and estimate like you mentioned using brainstorming between devs and QA. Estimation happens by relatively comparing complexity of each new story compared to previously implemented stories, conservativy picking average one up if there is variance in estimates. QA is involved to determine how long it will take to test the feature or sometimes what uncertainty is there if this is even possible automatically.

In the end we have stable developer velocity metric and a really close estimate for each new version.

As much as I agree with app deployment headaches, apps provide something a website cannot (except PWA) - ability to do stuff offline, log and register data which can be uploaded when connection is re-established. When talking about user experience - launching the app, selecting new -> quote -> entering details -> save -> locking the phone without worrying or waiting, knowing that it will eventually get uploaded, is much more convenient than walking with the phone around the property to get better reception to even load the new quote page.

UX matters, and user does not care if the native wrapper or 500kB of js is there or not, as long as the job is done conveniently and fast.

Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.

That is a really good advice, copying data everywhere makes only sense if the data will be mutated. I only wonder why, why C-style strings were invented with 0 termination instead of varint prefix, this would have saved so much copying and so many bugs knowing the string length upfront.

I have exactly opposite experience, Delphi was awful UI, verbose language experience, with hops and tricks and a ton of Win32 rendering to do simple controls like a ComboBox with checkboxes. Yet the community was brilliant, always helpful and SO questions answered the same day!

Both Apple and Android (stock) are candidates for anti-monopoly regulations regarding the limited, vendor locked backup API.

Enforcing choice of the backup solution would solve the problem of rogue countries like the UK meddling with privacy and security.

Like the browser choice, backup provider choice can end up being enforced, likely by the EU as they have a good history of breaking up vendor lock-ins.

Possibly an information/lobby campaign can be started and endorsed by some major online storage providers?

There are examples of cat and cp using io_uring. What are the chances of having io_uring utilised by standard commands to improve overall Linux performance? I presume GNU utils are not Linux specific hence such commands are programmed for a generic *nix.

Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.

In Kagi example search results I found some results being considerably not relevant to the search query. Is it like an option "discover" which can be disabled? Headphones search returned a MacOS app when searching on a phone. Does actual search vary reaults based on device user-agent class or platform?

TLDR: Use tools like sqlc (GO), dapper (.net) etc to hydrate and check syntax using already validated SQL, instead of being limited to ORM quirks and narrowed down query syntax.

But...

The actual main problem of ORM is not just ORM but a multi-layered translation of target language query code

  - to internal target language database schema modeled from/to a db schema
  - then to SQL syntax
  - then to wire request to db
  - then to SQL validator in db
  - then to internal database query planner targeting relevant schema elements
  - then to raw index/hash/scan executors
You see the picture? If the database schema wire protocol could only be converted to the target language objects without SQL translation sitting in the middle, query would run optimally and with up-to-date statistics to query planner.

Think of WASM-like protocol (as opposed to JS) to which queries are compiled in the client and passed to the db.

It has been done before on a basic key-value wire protocols and to an extent on graph databases with json requests. Structured relational data is making this hard to do as one would need to have up-to-date db stats in the client along with all index details to run an optimal query.

On the other hand, compiling this:

  db.Posts.Get(p => (p.Authors.Includes(a => a.IsBoss))
    ? { Date: p.Date, Bosses: p.Authors = p.Authors.Filter(a => a.IsBoss), Groups: p.Groups.OrderBy(x =>   x.Name).Top(5) }
    : { Date: p.ModifyDate, Bosses: null, Groups: p.EmployeeGroups.First() }
  )
Into SQL would be close to impossible in an optimal way. Alternatively, with schema access in the client it, one could write internal db "assembly language" procedure for looking up using indexes, conditional querying and spitting out binary result for minimal effort hydration.

Just an idea, I am not aware of similar client query planner solutions available.

One example of selection is a matter dominance over antimatter. Standard model shows many heavier muons and fermions are unstable yet in different conditions these might be dominant.

Obviously from our observed laws perspective we can find (we did not yet) reasons for such preferences yet changing conditions (time, matter density, energy, velocity, gravity) can potentially influence preferred laws and states of matter. Think of superconductivity, how is it even possible that there is no resistance in electron flow, we only make use of this phenomena without understanding the theory behind it.

I am looking forward for the book, just a tiny glympse of different perspective can influence a series of new inventions.