- Start in ask mode - "I'm planning on doing X to achieve Y; are there any alternative approaches? What problems might I run into?"

- Chat for a bit and get the high level approach, switch to plan mode and ask for a nicely formatted plan

- What's kicked out is already in the rough shape of the discussion so far, so it's a case of following a nicely formatted doc through and highlighting sections of text and asking for clarification or changes

- Hitting "build" and then reviewing what's been done

For a new service I might spend an hour in ask/plan mode - but then it gets 95% of the build itself right first time.

Do you do the same with different results, or is there a different stack/methodology you go through?

Don't think about how hard it is to migrate a VM to a new provider. Think about how hard it is to:

* Get procurement to sign off on a new vendor

* Guarantee that your ISO compliance standards can be met under the new regime

* Make sure that GDPR requirements are met during any data transfer process to the satisfaction of your legal team

* Get the old infrastructure team and the new infrastructure team coordinated enough to be able to plan a migration without downtime

* Mollify the consultants that the CEO's friend said he should hire

* Analyse the migration plan to death to derisk it while at the same time be unable to actually evaluate it small scale due to the points above

I wonder if I'll get to feel the same about golden eagles soon too.

- Zustand exposes itself as a hook.

- MobX does that observer-wrapper thing

- Snapstate instead has an explicit writing step (`scoped()`) at the bottom of a component

If so, I really quite like that. Kudos!

`pip install x` then installs inside your pyenv and gives you a tool available in your shell

- Scales well from simple configuration and workflows to more complex multiboard views/custom fields/layouts per issue type etc

- Good OOTB integration with common CI/CD - see PRs, deploys etc from each ticket

- Good (adequate?) integration with their wiki in Confluence

- JQL for being able to do custom reporting tooling (get me all issues transitioned to X status in this time period)

Things that frustrate me:

- Complexity/UI around configuration

- Very poor kanban metrics reporting

Rose tinted glasses perhaps, but I remember it as a very straightforward and consistent UI that provided great feedback, was snappy and did everything I needed. Up to and including little hints for power users like underlining shortcut letters for the & key.

My spelling is often horrendous and I know it - but almost every dev I know of prefers to copy and paste anything that might be misspelled just because it's easier than taking the risk.

Similarly - how does does this get anywhere near causing a production outage?

I'd be tempted to view this as a blessing in disguise; this person sounds like they'll trip up more often than the rest, but if one individual can cause a production outage with spelling mistakes something's gone awry with your processes elsewhere. You have an opportunity to fix whatever that is now.

A triangle by definition is guaranteed to be co-planer; three vertices must describe a single flat plane. This means every triangle has a single normal vector across it, which is useful for calculating angles to lighting or the camera.

It's also very easy to interpolate points on the surface of a triangle, which is good for texture mapping (and many other things).

It's also easy to work out if a line or volume intersects a triangle or not.

Because they're the simplest possible representation of a surface in 3D, the individual calculations per triangle are small (and more parallelisable as a result).

Having the model trained on how to construct triangles (rather than blobbly points) means that we're closer to a "take photos of a scene, process them automatically, and walk around them in a game engine" style pipeline.

> The majority of developers are unacquainted with features such as processing instructions and entity expansions that XML inherited from SGML. At best they know about from experience with HTML but they are not aware that a document type definition (DTD) can generate an HTTP request or load a file from the file system.

I was one of them!