If it were really cold, I could imagine wanting the Kindle to be on a bedside stand, and reading lying on the side with both hands under the covers. But this seems a really niche use-cae.

It's the built-in page turning buttons that I miss. I dislike swiping (sometimes I don't swipe far enough) or having to touch a specific area of a page. Clear clicky buttons are so much nicer, especially for one-handed use. At least my phone has volume buttons I can use to page through books.

I used to think pages are just an unnecessary analog legacy. However, many of us who work a lot with texts have visual memories, and remember where on a page a given thing was said. Even the difference between left and right pages can help with remembering the content.

That said, I like the way that a scrolling text gives a finer-grained bookmark than a whole page: you can align the next part to read with the top of the screen and go away and come back to it.

It's probably a bit faster to put a finger on a physical page, flip back keeping the finger in place, and then return to the finger than to set a bookmark, flip back, return to bookmark, and then delete the now no-longer needed bookmark.

It wouldn't be hard to make a UI for this use case, though, that is just as good. Maybe you hold a corner, and it creates a temporary bookmark. Now you can flip back and forth at your leisure, while having a semi-transparent "Return" button, and when you click that button you go back to where you were, and the temporary bookmark disappears. (There may be a better workflow, but that's what occurred to me on the spur of the moment.)

In hotter climates, there is a lot of overlap between when the sun shines and when you need air conditioning. Where I live, with July daily high temperatures averaging 36C, air conditioning is a very large chunk of the electric budget.

"I do wonder, though, if a person is watching a streaming movie for entertainment, why speed it up?"

Use case: You have an appointment to go to in 2 hrs and the movie (less credits) is 2 hrs 5 min. You will barely if at all notice the 4% speed up, but you'll be able to finish in the time slot available.

I used to think WinDVD's feature where you specify the time at which you need to finish watching was really cool, though I never ended up using it.

It's not likely that insurance positively requires counting steps, but insurance companies sometimes have fitness rewards programs for logging exercise, etc. For instance, I get up to $400 (on a prepaid credit card) a year for such things as going to the gym, logging exercise, logging book reading (good for mental health?), filling out a health questionnaire. My previous insurance had prizes for exercise--i got a watch, two game controllers, headphones, etc. Faking the fitness data, though, would be basically stealing.

If there are literally no deductions, then the tax is on gross revenues rather than on profits, and that's just not feasible for people running businesses whose profit margin is small, or who have significant costs associated with their employment (e.g., rideshare drivers need to keep up a motor vehicle).

So, at the very least one needs deductions for the expenses that were spent to gain the revenues. But now a lot of complications come back. Do we allow expenses to get carried over? And what exactly counts as an expense? Some jobs require a uniform and some jobs just require looking business-like--do both types of clothes count as a deductible expense or only one? Say, you travel for business. Do you get to deduct the full cost of food when traveling on business or the cost of food when traveling minus how much it would cost to eat at home (and how do you calculate the latter)? Do you cap the cost of the food you can deduct? You probably should be able to deduct the cost of entertaining clients. But what counts as entertaining clients and what is just having fun with people who happen to be clients? Or you buy a painting to put in your office. Is it there for you to enjoy, or is there "a business purpose" for it, say to impress clients with your taste.

And, anyway, what is income? If someone gives you a gift, that's just a gift, not something you earned. But what if they give you the gift because they were impressed with how nice you were on your job or how smart you are. Now it's a tip or a prize. What if instead of giving you money, they give you a meal? If that counts as income, then do you tax that based on the retail price or the price it costs them to give it to you? And if it doesn't count as income, we have a giant loophole where you can be paid in kind instead of in money.

I am afraid that any system will raise a ton of questions, and now we need tax lawyers. Sure, we can reduce how many we need. But it will still have complications.

I find it's fairly rare for me to come across a scene where I really want a square image, but I do occasionally shoot with my square format 120 film TLR camera (Yashica 12), and I have had cases where the composition works out nicely in that format. But it's relatively rare. People are not square while landscapes tend to look better in, umm, landscape orientation. Maybe if I shot 1:1 format more I would see the world a bit differently and find more compositions that work well in it.

There were interchangeable lens medium format cameras with 1:1 aspect ratio on 120 film. As for digital, the Hasselblad X2D is 4:3.

It depends on the user and the use case. High brightness makes the pupils contract, and the smaller eye aperture results in better-focused images given my middle-aged eyes. This is only an issue for close-up screens for me. Likewise, high brightness makes it easier to use the screen with sunlight, and that issue does come up for our living room TV for several hours of the day.

While I can tie my shoes, I am always annoyed at having to do it. It seems like a really outdated and inconvenient technology. But electronics isn't the solution. I wish the shoes I like to wear were available in hook-and-loop. (There is, admittedly, the issue that hook-and-loop eventually wears out. But I expect it isn't that hard to cut the seam from an old hook-and-loop fastener and glue in a new one with Shoe Goo. Probably doesn't actually take much longer than to replace a lace.) It's always a delight how fast I can put on and take off my hook-and-loop rock climbing shoes.

There are a few athletic applications where the precision fit of laces (including some climbing shoes) is nice, but generally I don't see the point.

It's not uncommon to have to exceed the speed limit to safely enter a highway, or to allow someone else to enter the highway.

grid.length and grid[0].length are not calls, but fetches of values from a field in an array object, I assume. Moreover, because these are native objects, I assume the bytecode compiler is really good at dealing with them efficiently.

I don't know that grid.length is going to be any less efficient than assigning it somewhere to a field in the underlying object (whatever object all these methods sit in) and then fetching it from that field.

grid[0].length is a bit less efficient because you have one more level of pointer indirection than if you just have a field in the underlying object. But it's such a common thing in java code for two-dimensional arrays that it wouldn't surprise me if the bytecode compiler had some special case optimization for it.

Moreover, if you were to assign the two dimensions to fields in the underlying object, say numRows and numCols, then you would have to make sure that if some method in the class ever changes what grid points to, it also updates numRows and numCols. I could easily see bugs due to forgetting to do this. It seems better stylistically to just keep all this data encapsulated in grid.

Now, what does bother me in the code are the repeated calls to getRow() and getCol() methods. Maybe these are just getters that the bytecode compiler will optimize away into field fetches, but it just hurts me to see repeated calls, and if someone revises the Location code (which we are not provided with?) in a way that makes getRow() and getCol() more expensive, the code will suddenly get unexpectedly less efficient.

I am even more bothered by getNextLoc() where we have two expensive heap allocations (with consequent garbage collections) for Location objects even though in any execution path only one of the two Location objects gets used. There are multiple ways to optimize this to use only one heap allocation. The easiest is probably to have an if-else-if ladder, executing col++ or row++ as needed, and ending with return new Location(row,col).

But at least it means that there is no clear benefit. I dislike ethanol, plus the stuff is expensive (due to taxes), but there was a time when the research was pointing in the other direction, and I was regretfully thinking I might need to introduce some into my diet, maybe diluted into various things drunk over the course of a day. But the current research makes me able to avoid alcohol without feeling guilty.

Well, if you add a case to a thinner phone, the combined package will likely be thinner than adding a case to a thicker phone. So there may still be a slight benefit.

By the way, what seems to me to be silly is having phones that are *mostly* thin, but with camera lenses sticking out. One could keep the same maximum thickness (i.e., the thickness at the point of the lenses) and yet have a lot more battery volume. There is pretty much zero benefit from the phone being PARTLY thinner. The case still has to protect the thickest part (i.e., the lens point), the thickest part still has to fit into a tight pocket, and a non-uniform profile is harder to move in and out of pockets, and requires recalibration for digital-level type apps. (When I got my current phone, I "had" to write an xposed module to compensate the accelerometer for the lens bump.)