Doc Avid Mornington

Github != Git

That’s how you talk?

If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.

The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.

I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.

Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.

Thanks for sharing this, it’s quite interesting. I found a Wikipedia article on it: https://en.m.wikipedia.org/wiki/Unary_numeral_system

Apparently, as you did suggest, “base 1” is a name that is used, but is somewhat a misnomer.

The article mentions that Church encoding is a kind of unary notation, which I would not have thought of, but I guess it is.

Enjoyable little rabbit-hole to zap my productivity for the day.

You seem to have missed the important phrase “in source code”, as well as the entire second part of my comment discussing that runtime functions that parse user input are different.

At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”. Conflating that with “this value does not exist” is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means “explicit omission”, but that isn’t the case. Null means a variety of subtly different things in different contexts. It’s perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.

Closer to tally marks without clustering

Who calls it that? Who even uses that enough to have given it a name? Seems completely pointless…

It’s been a long time, but I’m pretty sure C treats a leading zero as octal in source code. PHP and Node definitely do. Yes, it’s a bad convention. It’s much worse if that’s being done by a runtime function that parses user input, though. I’m pretty sure I’ve seen that somewhere in the past, but no idea where. Doesn’t seem likely to be common.

What? Your colleague sounds like they may be struggling with some serious cognitive issues, they may want to see a doctor about that. As for me, I’ve been living with my brain my entire life, and have kept several different sleep schedules in that time, for one reason or another, including rigid adherence to a schedule you would certainly approve of, and at no time has the basic fact that my brain works better later in the day ever changed. Some people never learn that their own circumstances and experience are not universal. Maybe try not to be one of those people.

I am definitely not at my most productive at the start of the day.

It’s better to have useful comments. Long odds are that somebody who writes comments like this absolutely isn’t writing useful comments as well - in fact, I’m pretty sure I’ve never seen it happen. Comments like this increase cognitive overhead when reading code. Sure, I’d be happy to accept ten BS useless comments in exchange for also getting one good one, but that’s not the tradeoff in reality - it’s always six hundred garbage lines of comment in exchange for nothing at all. This kind of commenting usually isn’t the dev’s fault, though - somebody has told a junior dev that they need to comment thoroughly, without any real guidelines, and they’re just trying not to get fired or whatever.

Exactly. Dependency injection is good; if you need a framework to do it, you’re probably doing it wrong; if your framework is too magical, you’re probably not even doing it at all anymore.

Pretty sure they meant to not have review. Dropping peer review in favor of pair programming is a trendy idea these days. Heh, you might call it “pairs over peers”. I don’t agree with it, though. Pair programming is great, but two people, heads together, can easily get on a wavelength and miss the same things. It’s always valuable to have people who have never seen the new changes take a look. Also, peer review helps keep the whole team up to date on their knowledge of the code base, a seriously underrated benefit. But I will concede that trading peer review for pair programming is less wrong than giving up version control. Still wrong, but a lot less wrong.

The UCC I went to every Sunday of my childhood (Dad was the minister, so kinda had to go) would have a loaf of really good fresh bread. Some was cut up in cubes, to take neatly, or you could pull a hunk off the loaf if you liked. One side of the drinks tray had grape juice, the other had wine, again, your choice, although obviously when I was young, I didn’t reach for the wine in front of my mom. Little tiny snack was the best part of church.

Or gets promoted, and keeps moving on to new and bigger projects, leaving a trail of destruction, because all management sees is they close tickets faster than the people who are busy picking up the pieces behind them.

Emacs Magit is so much better than the CLI, and I don’t say that lightly. And it’s available on Linux.

I barely know Vim, I’m an Emacs guy. Every time I pair with a colleague using an IDE, I find myself having to exercise great restraint, and not complain about how slow and fussy everything they do is. When I’ve worked with skilled vimmers, I have to admit that they invoke the deep magic nearly as efficiently as I do. Hotkeys? Pshaw, child’s play.

the core ideas of religion are just about universal

Even just within Christianity, in the modern world, there are radical differences in the core ideas between sects. Across all religions, throughout history, the differences dwarf that.

It’s the details and names that vary

It’s not (see above), but if it were: the details count toward this as well. Just saying “meh, ignore the details” is cheating to get the answer you want.

You could describe religion as a connectedness to, and humbleness before the mystery of, the universe

How many religious people have you actually met, friend? I have known some whose views roughly fit that description, but most do not. In fact, I’d suggest that you could describe science that way. Religious people start with the belief, the box they want to put the universe in, and then insist that it must be, and attempt to adjust the facts to match their views - this is the farthest thing from humbleness before the mystery of the universe. Science tells us to put our preconceptions and expectations aside, and observe how the universe really functions - if we see facts that don’t match our current understanding, we adjust our understanding.

Saying that some projects, at some point in their lifecycle, don’t need certain things, is not saying that those things have no place. Also, if one can’t design a monolith that isn’t bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.

Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn’t have to change at all.