Maybe that's a thing, but here's a video of a pet beaver making a "dam" out of stuffies and other household objects.
355 karma · joined August 18, 2015
+Automated testing (much newer?)
2022 Prius Prime sales: 5353
2022 Ferrari sales: 4922
A Ferrari rare car is not the solution to anything. Last I heard the waitlist on the Rav4 prime was years long here in Canada.
https://insideevs.com/news/676057/us-toyota-plugin-car-sales...
To give a really grotesque example, there is an country run by autocrats that carelessly unleashed a plague on the world because they prioritized their self image over taking descisive action to prevent an epidemic.
I imagine it's preventable since the ISS and other large orbiters stay functional forever.
https://learn.microsoft.com/en-us/windows/win32/stg/structur...
I've only ever called them brackets.
Re: Composability
You can generate something like the WHERE clause of a query in a function and return it alone (rather than as a SELECT query) or even combine it with another WHERE.
e.g. In SA the "select" and "where" portions aren't tightly coupled.
Re: Expressivity
Right now you can easily build up ef.core queries by chaining IQueryable.Where, which is nice but you can only do that for selects and something like OR conditions are difficult to implement.
e.g. in SA you can just pass a list of predicates to the or_() function.
e.g. in SA you can build a WHERE clause and then pass the same clause to a select or a bulk operation.
This means we will probably never get: 1. Ability to pull non entity types out of the database without a whole lot of boilerplate. See the bizarre obstinacy here: https://github.com/dotnet/efcore/issues/10753
2. Any kind of bulk insert/delete/update ability. It's been a "to do" for years now.
3. Much better query composability.
Basically their response is to just use raw SQL for anything that isn't a unit-of-work feature. They're missing a lot of benefits that a ORM could provide when they say that.
The ef.core team feels like a lot of rejects that were stack ranked out to their own team. I know that is mean to say, but they iterate extremely slowly compared to teams like asp.net .core, visual studio code, c# language group, f# language group.
https://www.visualcapitalist.com/all-the-biomass-of-earth-in...
https://www.rogers.com/mobility/network-coverage-map?icid=R_...
Most of my province (BC) is not covered. They cover the urban areas and some wider areas along highways in plateau regions. Where is this burdensome coverage that is keeping them expensive?
I wish we had been stricter with international travel so that we could have had less restrictions at home.
Just curious as a Canadian.
Do SQLAlchemy users appreciate how lucky they are? I generally prefer to use c#/.net but the 3 Microsoft ORMs (linq-to-sql, ef, ef.core) are all half baked. I don't know much about ActiveRecord, Django or other ORMs.
I wish I could have this sort of feature set and dynamic abilities that I get in sqlalchemy on the .net side. I say that as someone who loves SQL but appreciates the conveniences of a powerful ORM.
Firebug played a huge role in removing the shroud around javascript and making it approachable to a lot of people, helping them introspect others code, and improving their own code quality. After it, javascript became a beast you could tame rather than a source of endless frustration.
I couldn't find a way to create synonyms, is this possible?
Is it also possible to control typo sensitivity like algolia? e.g. min chars for 1 typo, min chars for 2 typos.
The curation features looks handy, but I haven't tried it yet.
Install and config was a breeze which is appreciated.
I hope it takes off for you. Nice work.
I think the new plan makes sense if you're selling to sites with purchase intent, but for searching knowledgebases it seems like it's way too expensive -- the value per search just isn't there. Especially when using instant searching and counting each slightly debounced keystroke as a search.