I've found OpenAPI is very poor for more dynamic resource-based APIs where the mechanics of interactions between the resources is standard but the resources themselves differ, e.g. a JSONAPI API. Does anyone know of tooling that more accurately fits that use case? I have hand rolled (well, generated) JSON Schemas in the past and published those, but that felt unsatisfying and too ad hoc.
Technical debt is risk. Just like in financial systems, taking on SOME risk is how you make money, but you need to measure it and minimize it and be prepared for if the risks taken all end unfavorably. This product risk (see also dependency risk) is intertwined with the combined risk of other projects going on, whether they're public relations risk, technical risk, staff risk, etc. and taking on too much risk means you have too many flipped coins in the air to count on them all landing favorably for you, even if they're weighted.
Another thing worth noting is that company success doesn't mean you're more easily able to pay off the debt like you would your mortgage. In fact the opposite may be true and it may limit future earnings if it bites you in the wrong place.
It's also possible that all the fixes for this were declined by management in the interest of time. If you have a system you can quickly patch suboptimally to get the larger fire lowered, I can see the decision being made to do so. That's clearly irresponsible on management if that choice was made, considering the problem they were dealing with at the time, but if the decision is between "not finishing" and "these few systems still have bugs", I can rationalize it.
The limits of tools only expose themselves when they're being stretched in ways the authors did not intend. Good tools have enough escape hatches to get you by those moments, and the bad ones break down entirely.
Is this tree special in being receptive to this technique, or is this broadly applicable to other trees/plants that are having trouble fertilizing for whatever reason?
In X, you san use xsetroot. I have a few scripts to grab weather and time, and put these in my DWM status bar, refreshing every minute. Obviously this has a bit more eye candy but if you use Linux, you can approximate this pretty easily.
Charitably, there's (e.g.) accessibility issues that need to be addressed on "new" features like the menus, and they need to be sure they're not going to be reamed for the new feature in the same way they are for this. Also testing. Several weeks is still high but not ridiculous.
My (entirely speculation) suspicion is that the old editor had a lot of tech debt, that the team was excited to delete, and since they're now having to put it back, having to make it compatible with the new editor.
I wrote the Dialyzer pretty printer for Elixir, and I had to jump through myriad hoops to get that to play nicely, and I still do not have it 100% working in all cases yet, though there's way fewer bugs reported these days.
As far as I know, yes. Elixir sends its own internal logs through it, and some of the Erlang libraries have begun making it optional recently. I don't include lager on purpose in any of my Elixir projects, for what it's worth.
The missing part of the explanation (imo), at least the part that helps me explain it in my own brain, is said but not explicit. Imagine the actual mechanics of Monty opening the doors, one by one, and when he gets to that 223,205 door as stated, he skips it, and keeps skipping it. Why _that_ door? What makes it special? I don't think expanding the number of doors without that bit of intuition gives you much.
The pricing makes it seem like it's meant more for the couple dozen to couple hundred unit buildings than 7. With 7, you know your neighbors for the most part. With 25, you probably don't, so I imagine theft goes up much more quickly.
This is the place where (mentioned elsewhere in this thread) things like issue tracker links and other context can and _should_ go if you're using something like CC.
I would rather shorten the standard tags around it than have to shorten the 80 char short commit message. Typically tooling allows you to add your own tags (e.g. imp: for improvement) so you could add feature, but I find myself needing those extra few characters more often than not
This is the way to think about it. It's concise enough and has tooling in enough languages to where generating the changelog from the commit messages is just a CI step, but it doesn't offer much more. I like and have used Conventional Commits for several years, but the goal is just tooling around telling others what changed outside of reading the git log, e.g. PMs who want an HTML artifact.
I'm showing my youth here, but this is a legitimate question. Isn't call waiting just a thing that exists on the line? Did phones used to have a switch to toggle that? And what was the harm in keeping it on? When I had dial up, I don't recall having to consider call waiting.
I'd buy this if Apple didn't start doing USB-C on their computers 3-4 years ago, If USB-C isn't where you want to go as Apple, fine, but be consistent across the product lines.