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.

It's worth noting that while the article is coming from Square, this is an official Ruby project and is "Ruby 3’s new language for type signatures".

https://github.com/ruby/rbs

So, threads and instances are two very different things. They both use memory, though threads use far, far less memory - just like in other languages where you would use threads for concurrency. When Ruby's GIL is waiting on I/O, it allows other threads to do their work. Per the first link, from the author of Puma:

"The reason for that is waiting on IO (talking to a DB, etc) will allow another thread to run"

The threads don't run in parallel, but they do run concurrently. While this isn't the panacea of performance, it does work well with many web apps which tend to be I/O bound (waiting for a database or remote service). So to your original of "Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances" - an HTTP request or SQL query will, in fact, allow other threads to execute while waiting for a response meaning you can rely on threads, rather than instances, and maintain a very low memory footprint.

If you like Ruby but want true multi-threading and parallelism, I'd highly recommend taking a look at JRuby (https://www.jruby.org). Those guys have done an incredible job with it.

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.

This is not correct. When Ruby is doing I/O such as this is the only time it’s not blocking. This is due to Ruby, not specific to Rails.

Here are a few references: https://github.com/puma/puma/issues/1003 https://thoughtbot.com/blog/untangling-ruby-threads

I can relate to much of what you're saying. This seems to be the common trapping of modern society - everyone must be happy and care about the same things. I'm not professionally qualified on the subject, but my vote is embrace it - but also try to understand it.

For instance, find a therapist to talk with. Don't feel like you need to settle for the first one you find, find one that feels right to you. It could be that there are deep rooted thoughts or emotions that actually are unhealthy that you may want to get to the bottom of. The goal here isn't change, it's understanding... and through understanding, determine if there's anything you'd like to change or even embrace. For example, I tend to focus on the negatives and everything wrong with the world. I realized I picked these behaviors up from my mother which not only allows me to be more aware of my behavior, but also helps me gently guide conversations with her away from being so negative and help her find positive things in her life.

Psychedelics often come up in these conversations, as well. I know many people whom see their experiences with psychedelics as turning points for them. There's plenty out research out there on the subject that I won't rehash here. If you choose to go down this route, I'd suggest doing your own research and if it seems like something you'd like to try do so in a safe place with one or more persons you feel safe around. Preferably, have an experienced "guide" there with you.

Lastly, I've been digging into the subject of gratitude for awhile now - both giving and receiving. There's a lot of research indicating it can be quite powerful. I tend to focus on the negative and everything that's wrong with the world (or my job, or my partner). Sometimes, just setting aside time to stop and think about something or someone you're grateful for (and especially communicating that) can do wonders. This isn't about not having or getting rid of pessimistic thoughts - it's about finding conscious space for appreciation, which can help balance things out or just help find some sparks of joy that might otherwise get drowned out by the negativity.

We're all on our own journey. Embrace who you are and try to take in the sights along the way.

In ‘94 (if not earlier), I was drinking lattes at a mom and pop coffee shop in a tiny town in the Midwest. And at another indie coffee shop at the nearest major university campus. That place was open 24 hours and busy at all hours. I didn’t even know what Starbucks was, but I sure knew lattes and cappuccinos.

So yeah, lattes in ‘94 in a major college town seems totally plausible.

I randomly happened upon this while traveling in Japan several years back. I didn't know anything about it when I came across it, so it was quite the treat. Honestly, the photos and videos don't do it justice.

Nonetheless, here's a video I took of it in action: https://www.youtube.com/watch?v=LF0iYFvkrEU

Hey! I just saw this and thought I'd follow up for posterity's sake in case anyone else came across this.

This gets into how we want to define "diffing", but I would say no, no there's not any diffing on the body, manual or otherwise. Per the linked section:

"Before each render, Turbolinks matches all permanent elements by id and transfers them from the original page to the new page, preserving their data and event listeners."

So, at no point is it attempting to determine a difference between two pages. Instead, it simply queries for appropriately tagged elements (from the source code, 'this.bodyElement.querySelectorAll("[id][data-turbolinks-permanent]') and copies those over to the next page.

Thus, it's declarative rather than algorithmic and not what I would consider "diffing" at all. In this context, the parent to my comment stated it's "still having to diff just like react/vdom", which certainly isn't the case.

Cheers!

Disclosure: I've had an architect title for nearly a decade.

I actually don't think half a day is nearly enough. BUT I also don't think that this needs to happen every week. Sometimes, there are periods of exploration and discovery - whether it be with new technology, new approaches within the company, or coming up with some more grand long-term vision to align the tech org towards.

However, when you're out of discovery mode, you need to be in the weeds writing prolific code, feeling the impact (good or bad) of your decisions and course correcting as you go. Moreover, you need to see how other people are feeling about your decisions. At the end of the day, you're working in service of them, helping a team, teams, or the overall tech org to be successful, which in turn will (hopefully) help make the business successful. Often times when I hear disparaging stories about architects, they aren't fulfilling that tenet - either because they don't have the skill to do so or they believe everyone else just needs to keep up with their brilliance.

I've been in too many situations where once the "architecture" was done, the project was to be tossed to some engineers while I work full time on something else. Unless you have some awesome leads that are in lock step with the architect, then that is a recipe for disaster.

The last thing I'll say is that everyone writing code is an architect. You're inevitably making decisions about the way things will be built, no matter how small. Virtually all software has an architecture - but too often it's incidental architecture rather than intentional architecture. Make conscious decisions about your code, reflect on those decisions, and keep an open mind - whether you're just starting out or have decades of experience.

Hrmmm... we have very different experiences with Turbolinks. Maybe older versions were more like that, but v5 is definitely not. Turbolinks doesn't look at the page at a node level, it replaces the <body> tag outright for each visit. You may want to turn Turbolinks off for a specific link, or make a DOM element that holds some sort of JS-driven state permanent across page loads, but there's really not much you _can_ do on a node level and the times you do use those things are certainly the exception, not the rule.

Turbolinks merges the contents of <head>, but replaces the contents of <body> outright. No diffing on the body.

"During rendering, Turbolinks replaces the current <body> element outright and merges the contents of the <head> element. The JavaScript window and document objects, and the HTML <html> element, persist from one rendering to the next."

https://github.com/turbolinks/turbolinks#navigating-with-tur...

The title is misleading as it implies everything new in macOS, when the linked page is limited to human interface guidelines. Perhaps this should be retitled something like "What's new in MacOS Big Sur (UX|HIG|Human Interace Guidelines)"?

The CEO of Basecamp posted a response to all of this on they Hey website that I found to be an interesting take that I hadn't seen talked about elsewhere.

An all too brief summary is that customers coming in through the App Store are not your customers - they're Apple's, and you lose the ability to support them. That falls on Apple, and Apple will inevitably fall short of expectations.

Most recently, I spent several years at a subscription-based company. The size of their customer support dwarfed technology, operations (the company ships physical goods), and even sales. And without the 1,000+ hours/week of work by customer support, the company would have seen so much churn to have long ago been out of business. Yes, it would be great to have a situation where everything works perfectly, no customer ever has a problem (even when those problems are well outside of your control), and are 110% happy... but that's just not a reality for many companies.

https://hey.com/apple/iap/

It absolutely is. Turbolinks’ bad rap is from earlier days and was partially due to just a different JS landscape where certain patterns relied on a hard refresh to not have memory leaks as you change page, or other odd behaviors.

I was one of many devs that would always setup new Rails projects without Turbolinks. Last year, I started a new product at work with a slim team and an eye on simplifying our tech and processes. This included giving Turbolinks and Stimulus a try.

Long story short, it was simple and straightforward and has a notable impact on perceived performance after the initial page load. We had a great experience with it.

These days with Turbolinks 5 it’s quite straightforward. There are some gotchas, but the readme covers various edge cases pretty thoroughly.

Since that project, I’ve gone solo and am working on my own commercial endeavor - and while I’ve been building large scale SPAs since before they were called RIAs, my new product is sure enough using Turbolinks (+ Stimulus).

My understanding is that Turbolinks 6 is coming soon that should be better, still.

Glad to see this, congrats on the new release! I found Kiba at my last job while searching for code-based (rather than configuration-based) ETL libraries. I was impressed at its simplicity in expressing the core concepts of ETL and allowing each of those concepts to be easily implemented in classes that can be easily unit tested.

We easily wrote some custom sources and destinations for working with systems such as Zuora and it was smooth sailing (working with Kiba, that is.... working with Zuora, less so).

Keep up the great work!

If this is done right, this would be a fantastic asset. I read two of the articles and they seem quite well done and seemingly more objective than I'd expect on similar sites. I'm in the process of launching my own product, so all of the existing comparisons are relevant and appreciated.

One small problem: on my 10.5" iPad the table of contents are cut off and I can't even horizontal scroll them into view (despite the fact that the page does horizontal scroll). Even in landscape, the layout isn't quite right. The content itself is viewed no problem, though.

Kudos!