Also Excel: I have no idea what “2021-02-11T16:26:18.056Z” is. Totally stumped. Better throw it in the general category.
1 Like
its in quotes so its obviously a string
Excel was NoSQL before it was cool, except the scalability part.
1 Like
In non-April Fools datetime news, Python still can’t natively handle dates from the first 2/3rds of recorded human history. Kinda seems like a bit of fail for a general purpose language.
Try telling Excel that via CSV that w/o winding up with double quotes around your data.
God JavaScript is such trash.
maybe don’t use a numerical operator on non numbers
A lot of shops, mostly fortune 500 types only started using python as a programming language for services/ml work and it was already at v3. As a result the v2-3 incompatibilities didn’t matter as much.
I rarely average more than a commit a day. Average commit is 5-15 files, 50-100 loc.
Each commit is a testable delta change in what the app/library does (or tries to be at any rate)
1 Like
Ordering is not an inherently numeric operation and there’s a perfectly obvious and correct way to sort a list of numbers, but if you want to be really strict and avoid confusion, I could totally dig it being an error to try to compare two arrays. But it’s pretty galling for JS to be like “lol I have no idea how to compare two lists of numbers,” and then to convert the lists of numbers into strings, which it then interprets as a sequence of code points (i.e., A LIST OF NUMBERS), and is like “finally, something I can compare, JavaScript saves the day again!” and come up with sometimes right sometimes wrong answers.
The greater than symbol is not about ordering, its a comparison expression, if you need ordering in a list use [].sort and correctly use the appropriate type operators. No one should expect something used exclusively on one type to work at all well on a completely different type. Is 'z' > 'a'?. Is {hello: 'world'} > {}?
It should almost certainly just throw typeerror but it doesn’t though because it was made in 2 weeks by a stupid bigot and now can’t really be changed due to it potentially breaking old websites. TC39 in their infinite wisdom has decided against breaking changes, which is equal parts amusing and irritating.
The solution here is: maybe don’t use a numerical operator on non numbers.
I didn’t anything know about the guy who wrote javascript. He’s added anti-mask, anti-quarantine, anti-fauci to his repertoire.
Kinda nervous about the Friday after next.
“They’re looking for someone with strong coding chops”
Coding chops = instant trashcan.
I’ve gotten in some big twitter arguments with him. He’s a typical Zero Hedge Rogan Bro who thinks science and govt is all a big conspiracy.
I’m considering a very weird git flow. It would make my life much easier than the alternatives, and I can’t think of a reason why it wouldn’t work. I’m interested in what everyone thinks.
Basically we have 3 websites, and could be up to 7, which all share a lot of common code - authentication, user profile management, admin features. I’ve come up with a way to break it out using react themes that I really like. Everything site-specific goes in a “sites” folder. This is the react app directory structure:
Right now only Alumni is going live. MyGiving is on an older architecture. But I’d like to pull it in to this repo after alumni is stable. Donate is just an SSO redirect at the moment. But we may have a bunch more of those - which is why I like using themes - the cost to add a new site is very low.
When I do pull the live MyGiving site into this repo, I’d like to be able to deploy Alumni and MyGiving separately - to reduce risk.
The standard way to do this would be to factor out all the common code into a lib, then pull that lib in to each site repo. I’ve done that, it works. But it’s a lot of overhead to make sure devs have the latest lib, and factor the code so the lib is neatly contained. Also the lib would be like 80% of the codebase right now.
I was thinking - what if I do a branch structure like this:
So any development still happens in the trunk, which affects all sites. Or at least new stuff is merged back into the trunk after going live.
But to deploy, you’d push to one of the live branches. At least that way you don’t have to worry about breaking the other two sites. You can work out the kinks on the site you’re developing. Then the next time you need to change one of the other sites, the new shared code will be in the trunk branch.
Is this crazy?
I think it’s superior and it’s what we use at work – one big repo for everything.
I want to know when a change in lib breaks a site right now, not in the distant future. Suddenly the answer to questions like “which version of xyz are we using” is always latest.
To make it work though, each site needs tests for any features of lib they depend on (and you have to pass them to commit). That way when working on lib breaks a site, the lib dev knows and has to fix it. If it breaks and there was no test, then it moves to the site dev to fix.
Do you use “sibling” branches like this to deploy sites separately?
One downside I guess is that you have the problem that some sites will likely be deployed rarely and so their branches will get stale and things that break an individual rarely released site might not be found for quite some time.
That’s probably fine (there’s no perfect strategy) but something to be aware of. As ChipsAhoy said you need pretty decent testing.
There’s a world where it’s better to just always deploy every site and have good tests/monitoring/release process to quickly detect and revert if there are any issues. I don’t know your scale but I suspect that’s overkill right now.
I have a theory question. I have a quantity of widgets with different colours and shapes, let’s say. They have to undergo a transformation process to be stored in my database. Some parts of the transformation are substantially the same and some are radically different depending on the colour and shape. For the different parts, my class that handles the transformation recruits a special class implementing the required interface. Back in the 1940s when I cut my teeth I’d just use a factory for this. I’m unsure how to work this into a DI graph. Ideas?