andrewingram

I used something similar for my Super Mario Maker 2 level viewer (eg https://www.smm2-viewer.com/courses/1HH-CJ8-KYF)

In the level data, the start/goal tiles (approx 10x10 blocks of solid ground under the player and goal) and slopes aren't represented by their tile offset in the level data -- whilst all other "ground" tiles are. Instead, for slopes you're only told the start and end coordinates, and they often overlap.

So to render the slopes correctly I had to work out all the rules for which tiles were allowed next to each other, and solve some ambiguity rules -- I figured out that shallow slopes take precedence over steep ones. Eventually I cracked it, but it took quite a week or so of iteration to figure it out.

I have a few parallel AI-authored side projects on the go that have quite different shapes, and I feel quite different things about each

1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.

2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.

3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.

I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.

I did a slightly less ambitious prototype a few weeks ago where I created added lazy loading of GCS files into the just-bash file-systems, as well as lots of other on-demand files. Was a lot of fun.

just-bash comes with Python installed, so in a way that's what this has done. I've used this for some prototypes with AI tools (via bash-tool), can't really productionise it in our current setup, but it worked very well and was undeniably pretty cool.

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’s no secret that RSC was at least partially an attempt to get close to what Relay offers but without requiring you adopt GraphQL.

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.

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.

Did my only ever podcast appearance about it a few years ago. Haven’t watched it myself because yikes, but people say it was pretty good https://youtu.be/aX60SmygzhY?si=J8rQF6Pe5RGdX1r8

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.

Oops, yeah you’re right!

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?

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

I always preferred Textile over Markdown for reasons like this, so was a little sad when Markdown won the popularity contest.

Precision platformers are generally _much_ easier with the d-pad. Since hitting some such parts in Silksong, I've exclusively switched over to it.

I also found the escape sequences in Ori to not be much fun at all. Though when I replayed both games a couple of months ago, somehow I did the sandworm on my first attempt -- which was a huge relief because that one induced so much rage on my first playthrough.

> so having two just because somebody wanted to optimize their resume was such a drag.

Does this actually happen a lot? Allowing for the fact that people would rarely admit to it just being about resume padding, I feel like just wanting to _use_ the thing is a far more common motivation for poorly rationalised technology choices.

These files also generally work in a nested fashion, like .gitignore and the like. So you want something that can be injected into the namespace of any directory in your project with relatively low likelihood of conflicts.

A few questions:

1. I can see there's an example of using it with React and Prosemirror, what's the gap to using it with Tiptap (for those who don't know, it's an abstraction on top of Prosemirror that aims to streamline the task of building editors)?

2. Is there any prior art or room in the design for supporting permissioned blocks of content _within_ a document? i.e things which some users aren't allowed to view (or edit)

Notably, if that TODO is turned into a ticket, there's a good chance it'll get triaged and eventually marked as cancelled/wontfix. Which is a perfectly reasonable thing to do when part of backlog management is saying no to things that'll never get prioritised. But, that work is still sitting there not done, and capturing that _somewhere_ has value, and alongside the code is about as context-rich as you can hope for.

I agree it has a good chance of catching up, but the difference in quality is pretty noticeable today. I'd much rather stick with vscode, because I hate all the subtle ways Cursor changes the UI; like taking over the keyboard shortcut for clearing the scrollback in the terminal. But I find it's pretty hard to use Copilot's tab completion after using Cursor for a while.

My take on Terminator is that the portrayal of a bleak late 80s / early 90s LA was a key component of what made the first two movies work. Bringing the Terminator antagonist into a setting in which there's already very little optimism about the future was a key part of the vibe. Subsequent movies have generally taken place in slightly brighter versions of the world, and have never felt right.

Ditto.

To me, one of the dirtiest words in dev <> designer interaction is "handoff". There's always a point in the lifecycle of any design tool where they start talking about it -- even if they quietly disagree with it in principle. My impression is that it normally happens when they're trying to acquire customers who (unfortunately) practice such dysfunctional team dynamics.

As a developer who designs, I've always found myself jumping between code and visual design tools; but rarely based on the current stage of the project and more often based on what kind of thinking I want to do. If I want to engage with the constraints I more often do it in code, if I want to explore tangents, I open up the design tool.

I’m curious why. I’d have concerns about the performance of this effect, but 44 lines of CSS to achieve a higher level of polish and, dare I say, craft, doesn’t seem like something to be dismissive of at review stage.

And as programmers, we inevitably spend most of our time dealing with these weird edge cases, because the stuff that makes sense is generally incorporated into our initial modelling and becomes a solved problem.

I don't work for Tiptap, but I'm curious as to what your expectations are here.

They're providing tools for integrating Tiptap with AI, including ones for reviewing suggested changes that come from LLMs. I don't really see something that Tiptap should be accepting liability for. As the developer working with Tiptap, I'd argue it's your responsibility to make sure (a) the prompts are giving generally good and useful output, and (b) that you incorporate any necessary UI to put a human in the loop of accepting the AI output. On the latter point, their AI Changes extension is one such example, but there are any number of ways of achieving this.

This feels like a cynical interpretation of Jacob's post.

I think it's perfectly reasonable for someone to want to retire with a feeling that their career was a net positive to society; and it can be very difficult to get that feeling when working in tech. So even if switching to being an EMT means his maximum individual impact is vastly reduced, it's far easier to make the claim that he's doing good.

If using tiptap as a collaborative editor, are the pending AI Changes (the red/green diff applied to the editor contents) visible to all users, or just the current one?

Ideally it's the latter, but it's non-obvious to me.

I worked with someone who left tech to become a nurse, so much respect for him. Loved working with him too.