thundermuffin

No, the game's Java version's official title post-Microsoft acquisition of Mojang is Minecraft: Java Edition.

I hadn't paid much attention to their $5 deal, so I looked it up out of curiosity.

It's the same food but in smaller portions, which sounds more appealing to me. I wish more places had appropriately sized & priced portions of food instead of "here's 2500 calories and a drink with enough sugar to give you diabetes for $10".

Sometimes I get random cravings for certain fast foods, but I always feel like a sucker when I opt to get less food but pay almost the exact same. The idea of getting the bigger sizes of fast food and reheating leftovers makes my stomach churn a little, though, haha.

The largest difference is everyone who joins would be editing the code like it's a Google Doc instead of having a read-only view of the host's screen; you still end up having to join some kind of voice chat (unless maybe there's an IDE VOIP integration I don't know about in some of these tools!). I haven't used this specifically, so I can't say how well it pulls it off.

However, from the few times I've used VS Live Share, it has been helpful being able to join into someone's coding session and pair with their code directly. Both of us being able to highlight and tweak lines as we're talking did wonders to remove the "add x, no, sorry, not there, the next line/parameter/<item I referenced too vaguely>" or "show me y, now z, wait, go back to y" song and dance routines.

It's not necessarily a game changer for the way every person or team works, but as someone who has an easier time forming a mental model of everything happening when I'm "in" the code, there have been times I think it's saved a lot of back-and-forth compared to a traditional screen share.

In my unqualified opinion, I would think having an iCloud account tied to the device that the person in possession of said device doesn't own shows "clear and compelling testimony or documentation to the contrary [of them being the rightful/current owner]". Although, I can see how others might argue it proves nothing; in the end, neither side is probably 100% correct in all of the scenarios, and it's all up to interpretation.

All I know for sure is I can say I'm glad I'm not a lawyer!

Maybe I'm misunderstanding your comment, but I'm reading it as saying if I can show I bought it at one point in time, then nothing else should matter, and they should unlock it for me. But I believe I must be missing something, because that proof of purchase doesn't necessarily prove it's my laptop after it's been locked by someone else's iCloud account.

For instance, I've given family my old laptops, and they setup their accounts after they take ownership of the device. The way I interpret your comment with regards to my scenario is that Apple should disregard the fact it is locked to their iCloud account and unlock it for me, because I can prove I was the original purchaser - even if they accidentally left it at my home or I steal it from their home.

Is that what you meant, that if I can give Apple a receipt then I am the de facto owner no matter what? Or am I just way off base?

I started with Vue then moved into React, and I do enjoy how much closer it feels to JS/TS. There's a few of areas where I think React is definitely simpler than it was with Vue 2.x and shudder at how I probably used to have to do things to truly do it "the Vue way" (and there are parts I miss like the built-in, easy slots).

However, I think Vue's dev tooling is way more developer friendly than React's. They probably end up mostly equivalent in how they let you find performance issues or debug states, but I've never been able to understand why React's devtooling just feels half-finished in comparison.

I guess Vue spoiled me a bunch in how approachable its UI was. It may be me misremembering, but I also remember it not hanging or erroring nearly as much as React's devtooling.

It isn't necessarily a "problem", but I personally am a fan of keeping simple use cases as simple as possible. In my eyes, bringing the syntax to barebones makes it easier to read and more maintainable for these ultra simple use cases (for instance this 3x3 equally sized grid).

    grid-rows: 3;
    grid-columns: 3;

Is it an excruciating pain to need to currently type repeat(3, 1fr)? Nope, not at all, and I'd gladly do it if my team wanted to plain CSS or SASS, but to me that statement doesn't feel nearly as succinct or (dare I say) elegant as other areas of CSS, such as:

    margin: 2rem;
    padding: 1rem 0.5rem;

What I meant by variable sized rows & columns was to keep the rest of the spec as close as possible to what it is now, but layered on top of my suggested simpler syntax from above. That way if I wanted to do something that isn't just n equal-sized columns, I could just write out

    grid-template-columns: 1fr 2fr 1fr;

and it would work as CSS grid currently does. It's the best of both worlds!

I'm also a frontend developer who has spent a pretty significant chunk of time studying CSS. Maybe I gave off the impression that I'm too incompetent to learn the latest features of the language and write them in plain CSS, but that wasn't what I meant. It is way more that I find little pleasure in writing CSS compared to other frontend responsibilities.

Am I happy and grateful that grid, container queries, and the rest of the new features exist? Yes, I am, and grid is one of the tools I reach for the most. In the end, I only had tiny things I wish could have been different about it after using it and realizing "rats, that syntax could have been made a tiny bit simpler for how I use it a lot of the time," or wishes for features that would just make life easier even if the current way of doing things is trivial.

Haha, you know what they say, different strokes for different folks! I didn't feel insulted in the slightest when our lead frontend developer suggested we give Tailwind a trial run. As a group, we were searching for a way to have consistency and a friendlier developer experience[0] throughout our many different projects & internal tools, but without having to bike shed with 10 different frontend developers or saddle someone with the responsibility of adding new CSS helpers as features rolled out (and the inevitable bike shedding that would happen every time). Some of my coworkers were upset about it because they prefer CSS and styling over JS and other frontend bits, but I think even the most fervent "vanilla CSS/SASS or nothing" holdout came around when she had to cover a project while someone was on vacation, and she found a level of consistency and naming that hadn't existed in our codebases.

--

[0] A couple of very old projects in a siloed team had a CSS guru building his own framework in SASS, but it's utility left a lot to be desired. In my opinion, you can't even place all of the blame on him, because his project was extremely standalone (and therefore had lulls when waiting for approvals and this was a way to pass the time and learn) and the company had very little guard rails to prevent this sort of thing. The combination of a small development team splintered between many different projects (no guidelines stating "this is how we are going to do this as a group" existed), everyone being overworked and burned out, and larger projects "winning" eyes of senior developers who held them to higher standards left him in a spot where I think he believed wholeheartedly that he was making a maintainable masterpiece that would end up being used in the rest of the projects when he finally finished it. Sadly, the framework never reached anything resembling a production-ready v1.0, but it did showcase some of his impressive knowledge of CSS.

Just want to preface this with this is all my opinion, and I know I'm not necessarily correct at all.

If I were given free reign, I would have tried to do some different naming for properties like grid-auto-rows/grid-auto-columns/grid-auto-flow. My internal way of thinking about how the first two control the height & width, respectively, don't line up with how I view the word "auto" in other places in CSS.

I also feel like there should have been a true shorthand for just creating an mxn grid. That's one of the biggest reasons I enjoy Tailwind because I can just say "grid grid-cols-3" and get a 3 column grid without me having to explicitly say I want them all even. I would have probably been naïve and made it work closer to the old column-count where giving it a unitless number and it makes it equal in the space; on top of that, I'd then layer the actual spec so you could do variable sized rows/columns.

The other thing I would have done would have been to focus time and effort on finding a way to easily reverse a grid. I know you can use the rtl/ltr hack to do it, and that grid being a 2-axis display method brings a lot of hard questions about "what does reversing a grid mean?". I know names could help here, but it just doesn't make sense in a CMS environment where editors can place as many or as few items in a grid as they want, so I can't just do "a b" -> "b a" based on media query, because there could be columns C through F, too, and I want them all reversed. Thankfully, this is mostly a mobile problem when they're stacked, so I can just switch to flexbox and column reverse, but still would've been nice to have an easier way to do this as the amount of SO posts I remember seeing for this indicated to me that folks did want this feature.

To answer why I don't use grid-template-areas often, I just don't find myself in a lot of situations where naming has made it easier. I guess I could do this kind of thing, but then everyone else is going to ask "where does a/b/c come from?", haha.

    "a a b b"
    "a a b b"
    "c c c c"

All of the CSS grid syntax craziness is one of the biggest reasons I was completely OK when our dev team adopted Tailwind. I am one of those devs who couldn't implement all of the CSS spec like @OJFord mentioned... but probably because I always forget what in the world all the options mean/are, haha!

I'm still rocking my Series 0 Milanese (but on a Series 5 watch), and I feel really lucky to only have lost a few arm hairs to the loop after your comment, haha. I wonder if they've changed something about their design or manufacturing over the years? It'd be interesting to get to see what this band looks like with each new generation to compare.