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.)

I've done partial eclipse photography through welders glass, but the quality isn't nearly as good as through a thin solar filter.

Agreed. It is hard to tell the difference between a small fanny pack and a fat money belt. Presumably a money belt is a part of clothing. And as far as I know no airline has upper limits on how much clothing you can wear: why not two belts? (Just more to take off for security.)

Here's another interesting question. If I have an item hanging from carabiner from my backpack (say, a harness and climbing shoes, or a cushion in a bag), is that a separate item, or does it count as part of the backpack? Nobody's ever bothered me about this yet.

I suspect the item-based limits may be counterproductive. If it's a choice whether (a) I walk into the plane with laptop in hand and backpack on back or (b) I walk into the plane with laptop in backpack and then pull the laptop out when I reach my seat, surely option (b) slows down boarding a lot more. (I tend to pull a lot of stuff out for a flight--laptop, Kindle Fire, phone, maybe headphones, cushion, water, snack--and lately I've been trying a little harder to have more of that in hand as I walk down the aisle so I can get out of the way of people faster.)

I assume if you pull a fuse, you can get the same functionality.

I am not sure fogging is necessarily a sign of ineffectiveness. N95 respirators are designed to keep particles away from the user. On inhalation they press closer to the face if correctly fitted. But a leak on exhalation will not harm the user much (maybe a little will come in at the end of the exhalation?). And i assume the fogging is from exhalation.

I suspect a better sign of poor fit is if the mask material is failing to move in and out with breathing.

(None of this is based on actual research, just speculation.)

I skimmed the bill looking at what exceptions are or are not in place. It has exceptions for game consoles and alarm systems. (I can kind of understand the alarm systems: a repair manual might help a robber to disable the alarm system.)

I was initially worried because there was no explicit exemption for small production runs and one-off devices. If I am a hobbyist and I sell a device to a friend, surely I shouldn't be legally obligated to write up a repair manual and provide parts for 3-7 years! Fortunately, the bill seems to only apply to products "for which the manufacturer makes available tools, parts, and documentation to authorized repair providers". So it looks like a hobbyist escapes the provisions by simply not having any authorized repair providers. (But what if I promise the friend to whom I sold the device that I'll fix it if it breaks. Doesn't that make me an authorized repair provider?)

Skateboards and roller skates have even smaller wheels. :-)

According to cyclistshub.com, the average cycling speed for mid-intermediate to mid-advanced cyclists is 14.5-20mph, so the difference isn't big. I'm not a very good cyclist myself, and I tend to average 12-14 mph on pavement on my hybrid bike, so I expect I would be well within the scooter range on a road bike.