ajanuary
If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.
For my money, this is the key point that people miss.
A test I like to use for whether two things are actually or just incidentally related is to think about “if I repeat this, and then change one but not the other, what breaks?”
Often the answer is that something will break. If I repeat how a compound id “<foo>-<bar>” is constructed when I insert the key and lookup, if I change the insert to “<foo>::<bar>” but not the lookup, then I’m not going to be able to find anything. If I have some complicated domain logic I duplicate, and fix a bug in one place but not the other, then I’ve still got a bug but now probably harder to track down. In these cases the duplication has introduced risk. And I need to weigh that risk against the cost of introducing an abstraction.
If I have a unit test `insert(id=1234); item = fetch(id=1234); assert item is not nil`, if I change one id but not the other, the test will fail.
But if I have two separate unit tests, and both happen to use the same id 1234, if I change one but not the other, absolutely nothing breaks. They aren’t actually related, they’re just incidentally the same.
* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.
* Some people don’t have their email on the device they want to log in on.
Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)
But having it only perform the same action would make things nicer.
These took me basically no time at all to find. Are you looking for something else for partial application?
I very much appreciate the attempt to reframe it positively. But personally, if I win the lottery, I’m still doing a handover. The key thing with “hit by a bus” is, no matter what your personality, you don’t have any time to prepare. Thats why you’ve got to get the information out there today. Unfortunately I’ve yet to find a positive spin that has those same connotations.
version.txt
1.0.0
CHANGELOG
# 1.0.0
* Initial release
changelogs/add-foobar-api.md
minor: Add a new API call `foobar`
changelogs/improve-baz-perf.md
patch: Improve the performance of the `baz` API call
In the changelog compilation step it works out that the largest scope is minor, so the version of the next release is bumped from 1.0.0 to 1.1.0, and you end up with: version.txt
1.1.0
CHANGELOG
# 1.1.0
* Add a new API call `foobar`
* Improve the performance of the `baz` API call
# 1.0.0
* Initial release
It works great, especially for large teams. You don't end up with lots of merge conflicts on the CHANGELOG file. The people writing the change get to describe the scope of the change (and that can be reviewed in the PR), rather than the person doing the release having to guess from the descriptions. Developers never have to worry about whether someone else has already bumped the version number or not.And python that Ruby doesn’t have: :: for slices @ for decorators
And for the symbols that they both share, subjectively, a lot of them are used for often in Ruby.
But to cover a couple of verses quoted in point 2, just in case it is helpful for people trying to combat people wielding these to attack them:
Ezekiel 16:50 - It's not clear that the toevah in Ezekiel is a sexual sin. Just because it is used in that way in some places is to ignore all the places it isn't. The point of Ezekiel 16:49-50 is that the sin of Sodom was inhospitality. If it should be interpreted as a sexual sin, there is nothing to say it is specifically sodomy [1]. It can easily be argued the sexual sin is the attempted rape of angels.
Jude 1:7 - Similarly, there isn't anything here that identifies it as sodomy rather than rape.
Countering the others, though, I think _does_ require letting go of univocality and infallibility.
[1] Homosexuality isn't really a concept at this time. Instead of attraction, they focus on acts and power.
When I’m reading the `maxItems` property from it, I know it’s an integer. Why do I need the document author to also tell me it’s an integer?
For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point. `config.getInt("maxItems")`.
Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted.
By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues.
While tailwind lets you write your styles in the same _location_ as the style attribute, it allows you to restrict what _values_ you can use. You can set up a colour palette so that when you say `class="red"`, it's the shade of red that you (or your designer) picked, and your colleague can't decide to pick a slightly different shade for their component.