Doing it with a camera/computer requires identifying the objects that need to be drawn in "Piranesi Perspective". The mathematics of laying out the objects is quite simple, but rendering a raster image into a view such that the key objects have this perspective probably isn't possible. You would need to vectorize the image in a general way. I don't know the state of the art in that field, but it sure seems hard.
I think the confusion may be whether you're talking about the queries or the engine. I think this change to the engine/parser would be backwards compatible because old queries will still work on the new engine. A change to the queries in a codebase to include trailing commas would not be backwards compatible because it won't work on older parsers. It seems clear to me that the change discussed here is the engine, hence it should properly be characterized as "backwards compatible".
"Single HTML file" sets up an expectation to me that it is (1) browser based and (2) client-side only. In other words, you can just open the file and start going without setting up a server, setting up a database, installing anything, or even having internet access. The last is not technically required but I think it is implied. It does not imply anything about the length of the file or the presence of client-side scripting.
I think GP is a great comment with a poor example, because I agree that the resulting images in my mind are quite different, but they don't inherently have to be due to the order things are described in.
OP understands that, the quote says that the "the infinitude of real numbers is next largest to that of natural numbers", which makes it sound like it is next largest as in second largest as in less large as in lower cardinality. So it seems backwards. Maybe the quote means "next largest" as in larger.
Everything you say makes sense, with the exception of your expectation not to pay extra for an unusual order (for that cafe). Consider if I asked for my salad to be roasted, and balked at a surcharge on the grounds that they also have roasted brussel sprouts! I don't think it's up to you to decide what orders fit into their flow and which cost extra. I'm glad you found the places that will make the coffee the you like.
In general, I agree with you, and for the record, I'm in favor of general restrictions or limitations on social media for children. At the same, I want to add that I was not allowed to watch violent cartoons or play violent video games as a kid in the 90s. I felt left out on the playground when I didn't know how to play X-Men or Power Rangers or whatever. But in retrospect it was fine. I'm not sure the social isolation factor in particular is as dire as you claim.
This is interesting. The study you cite and quote is about a transfer of money from "naive" credit card consumers to "sophisticated" credit card consumers, which correlates to "poor to rich", "less educated to more educated", etc. I'm even more interested in the transfer that occurs from both cash and non-reward-card consumers to specifically reward-card users.
I tend to think that this isn't inherent to institutions (or individuals), but rather that institutions that have this behavior tend to grow and last, whereas institutions that do not stay small and eventually disappear. A kind of survivorship bias.
In this case, it's not just sound vibrations but vibrations that you can feel in your house and bed! Truly difficult. Double or staggered stud walls really help.
I think it's much better because the teacher doesn't have to match guesses to students. For example, for each student the odds are 30/100, roughly one in three. And any duplicates can be matched by a single guess.
No, because I think microwaves heat in a very different way from radiant heat gain (or loss) such as in an oven or this chiller you're talking about. The internal water is heated directly.
Fortunately the list of "bad" code features attributed to each group is listed clearly. The title simply needs to read "Bad scientist code beats bad programmer code", or "A list of bad practices that programmers often think are good".
In part I agree, but I want to add that what makes a third place isn't just the kind of place it is (gym, library) but the design and attitude. So these kinds of places may be numerous but that doesn't automatically make them actual third places.
I'd guess you aren't seeing the build quality issues as frequently because you replace your phone more often. Three phones on six years sounds like a lot to me
There are other features about a piece of homework than how the handwriting appears. Is the content high quality? Did he learn? Did he do it efficiently? Did he enjoy doing it? Is it well-designed or beautiful in other ways? Etc. Your kid can feel pride about these other features of his work, some of which may be mutually exclusive with high quality handwriting! Selecting the handwriting as high priority is somewhat arbitrary on your part. I'd be concerned that you're overlooking other arguably more important signals of pride and joy in your kid's work by focusing on this one.
If you want your kid to practice high quality craftsmanship, to feel pride in a job well-done, let him choose another craft where the quality is inherently relevant, like woodworking or sewing (or calligraphy)!
.
A second angle. Imagine you are trying to learn to write code and someone insisted you use a difficult keyboard: each key is a different size, they're spaced out across the desk facing different directions. (Or, say, insisted you use punch cards). You'll surely have a harder time learning to code!
This doesn't make sense to me. You make it sound like a rosy cooperative relationship where advertisers want to follow the rules and regulators just haven't made them. Even so, regulation isn't "complete control" in any way. It seems more like the advertisers are always going to try to make the advertisements as effective as possible while toeing the letter of the law as closely as possible and ignoring the spirit of the law completely. What are you actually trying to say here?
I agree that mvvc sounds exactly right, but there is still the question of whether the view model is created in the back end (which is what the article is advocating) or in the front end (which is what you have to do if the back end serves the model like a general use API).
The MVC or mvvc or whatever paradigm is somewhat orthogonal to the technical back end/front end.
I think if the back end provides generic fields and the front end acts as an independent consumer of the API, then you essentially have two apps each with their own entire MVC (or whatever paradigm you are using), one on the front end and one on the back end. So I wouldn't quite say that "the view is more washed out across the stack" but that you have two views (and two models).
MVVM definitely came to mind as I was writing my comment. The model is clearly in the back end, the view clearly in the front, and the view model contains the explicit link between companyName and pageTitle and can live in either. Here the suggestion is to put it in the backend and serve it as JSON.
Yeah. This is suggesting to me that the "model" live in the back-end obviously and the "view" is separated across the front-end and back-end. I think that does sound more straightforward for many cases. So working on the "view" requires being not exactly a "full-stack" engineer but at least being able to make changes both on your front-end part of the view that makes API calls and back-end part of the view that serves them. I think that makes sense. You can still have fully "back-end" developers that handle the database and actual server, and fully "front-end" developers that handle ui design and content.
This and the article strike me initially as completely wrong, which makes it very interesting. I still want a clear separation between the "model" and the "view", and I guess I tend to assume that this corresponds to the front-end and back-end. Maybe that's a poor assumption.
What I see here is that the "view" is split across the front-end and the back-end. Or in other words, the back-end contains both the model and the JSON API as a view. I think this is what is meant by "I suggest you stop treating your frontend as some generic API client, and start treating it as a half of your app."
I still want a clean separation between the model, e.g. companyName, and the view, e.g. pageTitle. Somewhere, there needs to be the explicit logic (in the back-end part of the view) that says that the the pageTitle for page A is the companyName. It's okay for many different views to "reuse" fields from the model, but each view should have its own front-end and back-end components. That the view is split across a front-end/back-end divide through the nature of the web-stack doesn't change the fact that each view should remain distinct from the other views.
So I can agree in the sense that the alternative where you create a general-purpose JSON API as a model and view in the back-end, and then essentially code up an additional model and view for each front-end page/element with logic to convert the API data into the necessary content is a waste of time.