welearnednothng

But it's only a dark pattern in the right (wrong?) context, no? For instance, my webmail has infinite scroll and it's damn convenient. Yet, I never find myself mindlessly scrolling through my mail. It doesn't increase the time I spend on the site... quite the opposite.

Likewise, I swear Google was playing with infinite scroll in their search results recently, where I didn't have to hit next to see the next page of results. Same result for me - it was convenient and I didn't find myself spending more time looking for/at search results.

But when the context is addictive content, infinite scroll is always there to spoon feed you one more helping.

More often than not, infinite scroll isn't actually the UX pattern you're looking for. But on occasion, it does make sense. However, when combined with insidious content, a dark pattern it does become.

I'm sorry for your loss. I had a similar experience in the US. In my case, a doctor flatly contributed the (impending) death a byproduct of COVID. All tests prior to COVID were positive and pointed to many more years ahead.

I'm not certain, but I suspect something was lost in the handoff to the hospice care company where they just didn't have the history and I assume they were the ones that reported the COD. Not certain about this. I plan on looking to see if there's anyway to have this retroactively updated, but I'm not optimistic.

This is one of the things I miss about Perforce - every merge was effectively a squash merge, but the branch was still there, just not visible by default (if I remember correctly). It was the best of both worlds - you keep a complete audit trail, but it was out of the way and didn’t interfere with your day to day view of the commit log. Moreover, there was never any discussion on merge strategies as there was just the one way to do it.

On top of that, they had some amazing tools for aiding in audits when you needed them.

I’m not suggesting we all switch to Perforce! But I do miss that aspect of it.

Apple isn't in the habit of treating end of life or soon to be replaced products in this way, so it raised some eyebrows.

MacRumors got a follow up from Apple confirming that it has been discontinued. I suspect with the upcoming performance of the Apple silicon, lines between an iMac and iMac Pro were about to get blurry... but that's just a hunch.

From MacRumors: "We've since confirmed with Apple that when supplies run out, the iMac Pro will no longer be available whatsoever. Apple says the latest 27-inch iMac introduced in August is the preferred choice for the vast majority of pro iMac users, and said customers who need even more performance and expandability can choose the Mac Pro."

This is sound advice that I can definitely get behind. However anecdotally it's not what I've observed to be true. In my above mentioned example, the people with the most and strongest relationships throughout the org were not the most upwardly mobile, nor was there a correlation with positive attitude.

Rather, aligning yourself with the correct (choose wisely) new executive and being a yes-person even to things that you know might have long-lasting negative impacts on the company (and thus your peers) was too often the winning strategy. Even then, it's navigating a political minefield, and one misstep could spell disaster.

The approach tends to put personal gain ahead of the well being of the company. I've seen too many people get ahead by setting vast fires and then walking away. That's not something I can get behind.

I was at Disney for almost a decade (possibly at the division ultimately responsible for Disney+, but I’m not positive - it’s hard to keep up with all of the changes and renaming) and this is 100% what I observed there. Over and over.

The ineptitude of the decisions that resulted from this were often hard to believe. And getting ahead was really a matter of getting in good with a new exec long enough to put you in a good position to move upwards to a different part of the company (or elsewhere).

They almost certainly render two frames at a time. Thus bringing the render time down to only 100+ years per film.

I ran (self-hosted) TeamCity at a division of Disney for years with hundreds of projects across teams with lots of complex dependencies. To this day (though I haven't kept up as much in recent years), it's far and away the most powerful CI system I've ever used. Rock solid stability, to boot. And it's only become better and better over the years.

Does that mean it's right for every job? Not at all. Sometimes you just need simple and accessible. Things like CircleCI or Travis or Heroku's CI. But not Jenkins. I put Jenkins into the same category as TeamCity, and it falls far short.

If you've outgrown some of the other options and need really powerful CI, I can't recommend TeamCity enough.

Wouldn’t that be wonderful? Over 20 years of really solid experience here doing some awesome stuff for recognizable employers. I’ve had the exact experiences as the author.

One recent interview run by ex-FUAANG folks started with a non-trivial take home that represented their actual business. I come in, am told it’s one of the best they’ve seen. Which was great, because I was genuinely proud of it. Now let’s find all of the combinations on a boggle board. Which wasn’t even the worst of it.

So far, that’s been pretty par for the course for me. It’s been discouraging.

I haven't had to upgrade to 6, so it's a bummer to hear it's so painful. On a fresh Rails 6 project built with "--webpack=stimulus", I haven't had to muck with Webpack (on two ongoing products and a handful of experimental/toy codebases) and Stimulus has been just a delight. Everything more or less "just works".

I empathize with everything you're saying here, but I do humbly disagree. I've experienced exactly what you're talking about, and it's a nightmare. Frankly, I think the Rails codebase itself even suffers from an over use of concerns that can make figuring out where functionality comes from very frustrating at times.

That said, concerns are mixins, and mixins are, in the simplest of terms, more or less multiple inheritance. That's powerful stuff, and powerful stuff in the wrong hands (which includes every hand that'll touch it, not just the author!) will always get you in trouble. That could be the motto for Rails itself - powerful stuff, but in the wrong hands it'll get you into trouble!

My first exposure to concerns in Rails was a awful codebase for a well known company with massive classes that someone went on a weekend bender and shrunk down to less massive classes by introducing dozens of concerns. It made the classes _appear_ smaller, but they weren't actually. In reality, it was just hiding away much of the complexity and horrible decision making that made the code so hard to reason about and maintain and took things from bad to worse as a result.

That said, when you have a well architected code base to begin with (as in before you start introducing concerns) that has svelte classes with appropriate responsibilities, with shared logic broken out into "services" or whatnot, concerns can be a really nice way to share isolated functionality that can lead to cleaner classes without obfuscating what's going on. Quite the opposite - used well, they can tuck away (but not altogether hide) ancillary functionality allowing the meat of a method to be highlighted instead of drowned out by pre- and post-requisite behavior that might take up more LoC than the unique business logic of a given controller action thus obfuscating the functionality specific to that method.

On my current and previous project, concerns worked out great for the teams (which included junior devs) but were used sparingly and typically introduced by experienced devs. Also, taking a quick glance, it seems like Controller concerns are favored far more, and often involve calls to class-level ActionController methods such as rescue_from, overriding protect_from_forgery defaults, settings layouts, before_action, helper_method, etc. - things that you can't just tuck into a service class or method that gets called from the controller and would otherwise require someone remembering the correct combinations of code to sprinkle into a controller or creating a controller to inherit from (which isn't practically different from concerns but can paint you into a corner). They're also never used for the business logic of an action, only supporting functionality (again, pre- and post- requisite functionality or introducing class-level helper methods that can be reused).

All that being said, for a team that isn't confident in how to use concerns effectively, I'd also steer them away and guide them to consider alternative approaches. But at face value, I don't consider concerns an anti-pattern and have found that, when used appropriately, they can be a great tool in maintaining a clean codebase.

I was introduced to the idea of ghost kitchens a couple years ago. Initially, I was pretty keen on the idea. But at the time, we already had ghost kitchens operating in LA, and since then we've seen more open up. What have I not seen? Cheaper costs as a result. Now, delivery apps are flooded with a bunch of companies I've never heard of, I don't know if they're good, I don't know if I can trust them, and at the end of the day they're simply not cheaper for the consumer (one of the touted advantages).

I still think the idea has potential, and it sounded like Cloud Kitchens was genuinely doing some innovative stuff (I interviewed with them﹡), but I'm not convinced that potential will actually be realized. If the market shows it is willing to bear $X for some Nashville hot chicken, what motivation does an operator in a ghost kitchen have to undercut that rather than try to increase their razor thin margins?

At the end of the day, my excitement around the idea is around enabling entrepreneurial chefs, but it's sort of like a talent show - for every 1 great talent, there will be hundreds of less stellar entries, plus the inevitable business folks. It's an interesting idea, and it'll be interesting to see how it plays out over the coming years. That said, I'm more likely to support good brick and mortar companies that help build up the neighborhood community (especially in a city like LA that generally lacks a sense of community).

﹡They spent more time touting their FAANGU(ber) employees than selling the company and ultimately the in-person experience was one of my most loathed interview experiences. This was awhile ago, things could have improved since then.

I’ve never counted, but based on how many pods I’ve used and how many bags I’ve recycled, I’d have to guess around 100. Maybe more? I actually take my bag to the Nespresso store, so while it’s a fair point to raise about the overall efficiency of the recycling, I have to imagine the store is doing bulk shipments of pods off to the recycling plant which would help a bit.

I received my machine as a gift. I probably wouldn’t have kept it if it weren’t for their recycling program (it’s also not my main method for making coffee) - but you're right, it might just be platitudes.

It’s worth noting their recycling program also composts the used grounds.