I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?
I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?
You didn’t even describe how it’s on the website.
I would use the webbrowser/Firefox save page functionality.
Or open the webbrowser dev tools and document.querySelectorAll('img')
and get the URLs from it and use those.
Or Page info media tab.
Or dev tools network tab. To identify and use the image web requests.
Or use Nushell with query module enabled, and http get query html.
Or my own C# until.
But I suspect there’s Auth in play, so the only easy access is within the browser session?
Earlier this week for a character range.
/edit: Now I remember. For setting up a new entry in Jenkins CI build failure analysis - identifying the build failure cause in the log.
Seemed verbose, overengineered, unnecessary framework introducing complexity. I didn’t see a strong use case for it, maybe for a lack of an obvious one or my understanding of it.
It also didn’t leave a strong impression. I had to look at the site and goal/description to remember.
Maybe some niche data handlers and implementors have use for it. But a Wikimedia project seems overblown for that.
I have not used it though. I’m open to being shown and corrected.
What conclusion did you come to?
He’s gonna live a long life. Until we know pi.
I really like Calendar Versioning CalVer.
Gives so much more meaning to version numbers. Immediately obvious how old, and from when.
Nobody knows when Firefox 97 released. If it were 22.2
you’d know it’s from February 2022.
It doesn’t conflict with semver either. You can use y.M.<release>
. (I would prefer using yy.MM.
but leading 0 is not semver.)
In my Firefox I get a NS_BINDING_ABORTED
error on the Google Fonts font request.
And they didn’t specify a font fallback, only their external web font. It would have worked if they had added monospace
as a fallback.
Ignoring secondary email addresses, what was my primary [onlineaccount] E-Mail address has changed four times.
Nested CSS obscures complexity
An interesting point. Something I will take with me for observation and consideration.
Maybe sometimes it’s worth despite it and other times not.
extending the list
Seems like a valid formalization.
I think a or a few counter-examples would go a long way though.
The “rectangle” probably isn’t supposed to be this messy?
generate 32-char-pw -> “Must not be longer than 20” 🤨
generate 32-char-pw -> “you must include a specific special character” 🤨
below 10 characters is truly atrocious - and thankfully rare
Are you saying “don’t use a synthetic key, you ain’t gonna need it”?
People regularly change email addresses. Listing that as an example is a particularly bad example in my opinion.
many2one: so in this relationship you will have more than one record in one table which matches to only one record in another table. something like A <-- B. where (<–) is foreign key relationship. so B will have a column which will be mapped to more than one record of A.
no, the other way around
When B has a foreign key to A, many B records may relate to one A record. That’s the many2one part.
The fact that different B records can point to different A records is irrelevant to that.
one2many: same as many2one but instead now the foreign key constrain will look something like A --> B.
It’s the same, mirrored. Or mirrored interpretation / representation to be more specific. (No logical change.)
If you had B --> A for many2one, then the foreign key relationship is still B --> A. But if you want to represent it from A perspective, you can say one2many - even though A does not hold the foreign keys.
In relational database schemata, using foreign keys on a column means the definition order is always one to one, and only through querying for the shared id will you identify the many.
many2many: this one is interesting because this relationship doesn’t make use of foreign key directly. to have this relationship between A and B you have to make a third database something like AB_rel. AB_rel will hold values of primary key of A and also primary key of B. so that way we can map those two using AB_rel table.
Notably, we still make use of foreign keys. But because one record does not necessarily have only one FK value we don’t store it in a column but have to save it in a separate table.
This association table AB_rel will then hold the foreign keys to both sides.
When something hits you in the face you turn blue. This essentially hits you in the face, and matches that color.
I don’t have multi-user library maintenance experience in particular, but
I think a library with multiple users has to have a particular consideration for them.
I think “keeping all users in sync” is a hard ask that will likely cause conflict and frustration (on both sides). I don’t know your company or project landscape though. Just as a general, most common expectation.
So between your two alternatives, I guess it’s more of point 1? I don’t think it should be “rapidly develop” though. I’m more thinking doing mindful “isolated” lib development with feedback channels, somewhat predictable planning, and documented release/upgrade changes.
If you’re not doing mindful thorough release management, the “saved” effort will likely land elsewhere, and may very well be much higher.
Quite elaborate but also very interesting read on git and version control history.