620 karma · joined July 27, 2010
But usually when I reach for a queuing system, it's because I want to decouple a part of the architecture. And in that case, it's probably better to use a dedicated queueing system instead of postgres.
I wonder if the two cases are conflated in a lot of online discussion.
Very well done.
- 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 <!DOCTYPE> 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!
As it says, at some point there was an attempt to standardise the length of a metre in terms of a pendulum's length; which related it directly to g through Pi.
I can imagine a common space of inspiration there.
I never really lost my love for programming, but twenty years in the n-th commercial project in the more common languages (plus a front end based in whatever combination of JS frameworks is the new flavour) really ground a lot of the original creative joy out of it for me. The interesting bits got too easy and the hard bits got more uninteresting.
Elixir is a breath of fresh air; it's purely functional so it requires thinking a bit differently, but it's accessible enough to start easily and pretty enough that it's not a soup of parentheses (looking at you, lisps). It's practical and well suported enough to build a wide variety useful things, and very good at concurrency.
It's what I really wanted Ruby to feel like.