Yeah, whilst git was more popular than mercurial, I still think mercurial would have won if bitbucket had a better UI.
It's interesting to me that the only thing that made me vastly prefer using Github over bitbucket is that Github prioritised showing the readme over showing the source tree. Such a little thing, but it made all the difference.
Ambiguity increasingly feels like the crux of estimation. By that I mean the extent to which you have a clear idea of what needs to be done before you start the work.
I do a lot of fussy UI finesse work, which on the surface are small changes, so people are tempted to give them small estimates. But they often take a while because you’re really learning what needs to be done as you’re doing it.
On the other end of the spectrum I’ve seen tickets that are very large in terms of the magnitude of the change, but very well specified and understood — so don’t actually take that long (the biggest bottleneck seems to be the need to break down the work into reviewable units).
In the LLM age, I think the ambiguity angle is going to much more apparent, as the raw size of the change becomes even less of an input into how long it takes.
I mean, the use of GraphQL for third party APIs has always been questionable wisdom. I’m about a big a GraphQL fan as it gets, but I’ve always come down on the side of being very skeptical that it’s suitable for anything beyond its primary use case — serving the needs of 1st-party UI clients.
It is still a major problem, yes. Interestingly, if you go back to the talks that introduced GraphQL, much of the motivation wasn’t about solving overfetching (they kinda assumed you were already doing that because it was at the peak of mobile app wave), but solving the organisational and technical issues with existing solutions.
As someone who’s used GraphQL since mid-2015, if you haven’t used GraphQL with Relay you probably haven’t experienced GraphQL in a way that truly exploits its strengths.
I say probably because in the last ~year Apollo shipped functionality (fragment masking) that brings it closer.
I stand by my oft-repeated statement that I don’t use Relay because I need a React GraphQL client, I use GraphQL because I really want to use Relay.
The irony is that I have a lot of grievances about Relay, it’s just that even with 10 years of alternatives, I still keep coming back to it.
For me it’s really about the component-level experience.
* Relatively fine-grained re-rendering out of the box because you don’t pass the entire query response down the tree. useFragment is akin to a redux selector
* Plays nicely with suspense and the defer fragment, deferring a component subtree is very intuitive
* mutation updaters defined inline rather than in centralised config. This ended up being more important than expected, but having lived the reality of global cache config with our existing urql setup at my current job, I’m convinced the Relay approach is better.
* Useful helpers for pagination, refetchable fragments, etc
* No massive up-front representation of the entire schema needed to make the cache work properly. Each query/fragment has its own codegenned file that contains all the information needed to write to the cache efficiently. But because they’re distributed across the codebase, it plays well with bundle size for individual screens.
* Guardrails against reuse of fragments thanks to the eslint plugin. Fragments are written to define the data contract for individual components or functions, so there’s no need to share them around. Our existing urql codebase has a lot of “god fragments” which are very incredibly painful to work with.
Recent versions of Apollo have some of these things, but only Relay has the full suite. It’s really about trying to get the exact data a component needs with as little performance overhead as possible. It’s not perfect — it has some quite esoteric advanced parts and the documentation still sucks, but I haven’t yet found anything better.
I did. I really wanted to like it. I think it broke due to something I was doing with fragments or splitting up code in my monorepo. I may give it a shot again, from first principles it is a better approach.
I'm always reminded of snap, crackle and pop (https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...) for this topic. Essentially it's not enough to just have continuous acceleration, you have to ease into it (low snap), you can probably go into further derivatives for ultra smoothness but maybe not worth it?
As your link says, acceleration is 2nd derivative of position, so rate of change of acceleration is 3rd derivative, often called jolt. As you say, you want acceleration to vary slowly, so it's low jolt that you want.
Snap (or jounce), crackle and pop are 4th/5th/6th derivative. They're probably less of a problem.
Oops, that's what I meant to say! So much for my correction.
I actually heard, many years ago, the higher derivatives referred to as "jerk" (3rd, as you said), "jolt" (4th) and "jounce" (5th). But that contradicts the Wikipedia article that says "jounce" is 4th derivative.
It can help because the higher derivatives also tend to promote vibrations in the system, but I doubt it'd be perceptible by people. I have heard of 5th-order smooth curves being used for very sensitive structures, like the movement of big observatory telescopes.
To me, the really impressive thing about Blender is that it now has a pretty good UI. I'm pretty snobby about the GUI apps I install, and Blender is probably the only professional-level (as in professional users) open source tool that feels pretty good to use on a Mac. In the early days it was pretty rough, but it's rare to see open source software UI consistently improve like this.
On aesthetics, it definitely beats out Lightroom Classic, which is a closed-source paid tool (sidenote: I really miss Aperture).
It's interesting to me that the only thing that made me vastly prefer using Github over bitbucket is that Github prioritised showing the readme over showing the source tree. Such a little thing, but it made all the difference.
reply