nevinera

Well, there's more information out and it seems pretty.. damning. I wasn't convinced by "power grab", but "economic pressure from our sole remaining major sponsor" is _way_ more believable, and the chain is events is getting fairly clear. Check out Joel's explanation for a coherent delve into the events: https://joel.drapper.me/p/rubygems-takeover/

Now I just have to hope the fallout from this includes a less centralized replacement for the tools I'm used to - I haven't found anything solid yet, but I imagine andre will be examining this problem space with rv now.

Well.. "legal liability" is kind of complex topic. Usually what really matters isn't "what the courts will actually determine if such a case is brought" it's "how much will it cost to prove that lack of liability, and what is the risk that we are wrong?". I also don't believe that such an organization is liable for anything beyond negligence, but whether the lack of an action constitutes negligence is .. well, one can rarely be totally confident in the outcome of that kind of proceeding.

The (mostly PR) explanation they produced seems to express roughly the same thing I was guessing though: https://rubycentral.org/news/strengthening-the-stewardship-o...

I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors?

I'm not sure how anyone familiar with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)

I used the models with a good workflow, but found them less than helpful. But I think that if I worked in a less expressive language I'd be very enthusiastic.

Aye. It's not the smartphone that's the problem, it's the async notifications pulling you into social media traps.

I dropped those apps about 8 years ago, but started to do most of my _reading_ on my phone - when I pick up my phone and habitually open something now, it's a book of some sort. It's a good idea to have something to replace habits with, if possible.

DRY is _not a best practice_. Repetition is a "code smell" - it often suggests a missing abstraction that would allow for code reuse (what sort of abstraction depends on the language and context), but "blindly-drying" is in my experience the _single most frequent mistake_ made my mid-to-senior engineers.

My experience is mostly in Ruby though, so I'm not sure how well it generalizes here :-)

These types of posts are .. well thought-out, and usually posted by someone with relevant education. But they are not reviewed documents or journal articles, and you can _tell_ when someone is mixing in a lot of their own educated guessing with the research they've done. Which is the case here.

He probably wasn't intending it to be taken as authoritative source, but that's how most people will _read_ something like this after running into it on the front page of HN. And most of this is just.. guesswork.

First ran into this on persistent servers, where the deployed instance knew branch names github had long forgotten about.. Someone pushed a branch named "bugfix", and `git fetch` started erroring.

You get even _more_ interesting problems if part of your team has case-insensitive file-systems!

Indeed, if I were running that site, I would now implement the ability to turn on intentional non-randomness for _specific people_, and begin embedding messages in the sequences of comics, or selecting the same two comics 28 times in a row on occasion. Heck, stick the referrer in the session and give everyone coming in from _that blog post_ wildly divergent randomness characteristics :-)

While I don't really _disagree_ with any of this, I want to raise a point from the other direction - it's possible (and for some of us, absolutely necessary) to build software such that holding a large "structure of thoughts and possibilities" in your head is not required.

I find myself largely incapable of doing so, open-plan office or not, and have compensated by adopting development approaches that break problems down in consistent enough ways (into small enough pieces) that the structures I have to pick up and put down are never all that complex. Which is good, because they fall out of my head just all the time. ADHD, a very poor memory for detail, and a role that has me responsible for juggling many tasks concurrently would _destroy_ my productivity if this article were universal truth.

Don't get me wrong, I _hate_ working in an open-plan office. But the impact it has on my output is not because the interruptions affect my flow, it's because the constant social contact stresses the heck out of me >.<

I gained the most from gobase.org, just clicking through professional games. The tool you can review/replay games with lets you try to guess the next move - just let them play the first 10-15 moves and then start guessing. Don't spend a ton of time thinking, just _guess_. Guess over and over, and if you don't guess the move after 5-10 tries, have it tell you, try for a few seconds to understand why that might be a good move, and continue.

You should totally do the tactics and puzzles that you can find (that same site has a bunch), but there's a lot more strategic recognition and pattern-matching in go than chess.

I'm also interested to hear if there are better tools though in the last .. Christ, twenty years? I'm old now -.-

It's an awkward space - requiring us to pay them to put our profiles there is the main way to keep the content valuable/accurate.. but while that's fairly typical for hirers, it'd feel scammy to job-seekers.

I think there's room for such a service, but growing it into a viable model would be a real project, and probably not a distraction a business would want to take on except as a pivot.

I don't disagree with you a bit! Science should be doubted in the correct ways, and for appropriate reasons, that's one of the main things I come to HN comments for. My issue with the OP was with his reasons - anecdotes about your children and personal opinions about the world might _trigger_ doubts, but they aren't good reasons to base those doubts on.

Oh I have no problem with doubting the study (I definitely doubt its conclusions myself, since I don't think "screen time" is a meaningfully monolithic concept to study in the first place, without even getting into the details of the methodology). But there are good ways to doubt and bad ways, and "this study is junk because my kids misbehave more when they watch TV" is far on the wrong end.

If you'd like to analyze their approaches to call the study 'dubious', I won't argue with you (it is; they are not strong ones). But making that assertion solely on the position that your personal observations of your own children disagree puts you in the same category as my wife's friend that rejects vaccines because her mom took one and still got covid. That's not how individual observations interact with science.

And of course, talking about all of this as if 'screen time' is all the same is _insane_. Anyone that thinks watching youtubers screech at each other for hours is equivalent (for the purposes of mental development) to watching an adapted Broadway musical has not put any thought into the topic, and that's entirely setting aside the topic of interactive vs passive entertainment being lumped together..

But hopefully the strategy of "just let the kids blend it all together and hope it washes out in the statistics" is a good enough method -.-

When science doesn't match your personal observations, that doesn't make the science wrong. It also doesn't make your personal observations wrong - it usually (in my experience) means that you're measuring/observing different things (assuming you're reasonably intelligent, which I am doing). In this case, "cognitive development and well being" are complex concepts that probably do not map exactly (or maybe even grossly) between their definitions in the study and their experiential meanings in your head.

My personal observation is that "screen time" is not the problem, but lack of interaction _is_ - letting the kids be in front of a screen for two hours doesn't cause a problem, but letting that be an excuse not to spend time with them or interact with them (which is when it usually ends up happening in large quantities) does. Essentially - you need to control the other variables to understand what's really going on; excessive screen time is generally a symptom and not a cause.

If on average 100% of cases involve a company that is paying for an arbitration lawyer and even 80% of cases involve an individual that is paying for an arbitration lawyer (which I _highly doubt_, though I couldn't quickly find numbers), the net result in the long term is not that "20% of individuals get a negative outcome", it's far worse.

This article is talking about the net effect, which is that the fact that there _is_ asymmetry means that arbitrators have an interest in _being_ biased against the individual, which means that even if you are paying for an arbitration lawyer, they are simply ruling out the _most_ biased firms, while the corporate arbitration lawyer is ruling out the _least_ biased firms. Think natural-selection, rather than game theory.

Most likely they're referring to the ability for a contract to include terms that remove your right to legal recourse.

Operationalize transparency to build alignment

Hold up there, I can't drink that fast.

I'm sure there's a substantial population that this redesign was successful for, but it's nobody I've talked to.

I can no longer tell which of my slacks has pending messages at a glance, and my actually important channels' notifications are hidden in a sea of irrelevant ones when they used to be the only attention-attractors on the interface. I gather that you think the list of people and channels is just one aspect of your lovely platform, and we should use the other interfaces like "DMs" and "Reactions" too, but .. that list is the core of your interface, please stop hiding it every time I do anything.

Eh, I think a lot more of it is caused by optimism than RDD - people who haven't _tried to do it_ look at the mess they've got, and they can see that if it were divided into domain-based services it would be less of a mess.

And the process seems almost straightforward until you _actually try to do it_, and find out that it's actually fractally difficult - by that point you've committed your organization and your reputation to the task, and "hey, that was a mistake, oops" _after_ you've sunk that kind of organizational resources into such a project is a kind of professional suicide.

I don't think I'm overlooking any major ones, but we are probably working in quite different types of systems - I'm not aware of any type of static verification I'd use in a rails application that would affect _architecture_ in a meaningful way (unless I would write quite terrifying code without the verifier I suppose).

I'm not sure about the tests - it depends on what you'd consider an impact possibly; I've been trained by my context to design code to be decomposable in a way that _is_ easily testable, but I'm not sure that is really an 'impact of the tests' (and I'm fairly confident that it makes the abstractions less complex instead of more).

Would you mind explaining what you mean in more detail?

Well, partly that was a mistaken impression because I thought that your comment was also from vrosas. But I think there's enough in there to assess your attitude toward code-review at least a _bit_:

They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no customers? It's fine, in fact it's ideal.

12 engineers churning out code with no code-review at all? That'll produce velocity, for sure. It'll also produce not just an unmaintainable mess, but an interesting experiment, in which you get to find out which of your engineers are socially capable enough to initiate technical communication independently and construct technical rapport _without_ that process helping them to do so. Hope none of them hold strong technical opinions that clash!

That process sounds fine to me, especially in a context with either good integration coverage or low downtime cost.

to “ream” someone for merging without deploying is incredibly immature and uncreative.

I'd agree, but I _highly_ doubt that description was an accurate one. Read through the other comments by the same person and you'll get a picture of their personality pretty quickly.

It's likely that there was already an ongoing conflict either in general or specifically between them about this issue. They probably got a moderately harsh comment to the effect of "hey, you're expected to wait for code-reviews now, knock it off"

Right! What I'm fundamentally saying is that the majority of orgs trying to adopt SOA are doing it for the wrong reasons, and will deeply regret it. In general, the "right way" to adopt SOA is to extract services one at a time because you have to, to solve various problems you've encountered (scaling problems, technical problems, stability issues), and then realize that you are in fact currently using a service-oriented architecture, and have been for several years.

Hm. I think maybe you're using "system" to mean a different thing than I am? I thinking of "the system" as the thing that is executing in production - it provides the business behavior we are trying to provide; there is a larger "system" surrounding it, that includes the processes and engineers, and the CI/CD pipelines - it too has an "architecture", and _that_ architecture gets (moderately) more complex when you add CI/CD. Is that where our communication is clashing?

Because the complexity of that outer system is also important, but there are a few very major differences between the two that are probably too obvious to belabor. But in general, architectural complexity in the inner system costs a lot more than it does in the outer system, because it's both higher churn (development practices change much slower than most products) and higher risk (taking production systems offline is much less permissible than freezing deployments)

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers.

Your attitude towards code-review on the other hand is one I've seen before several times, and I was glad when each of those people were fired.

Did you mean to reply to somebody else? I'm a huge believer in automated testing, and if I said something that can be interpreted otherwise I'd like to clarify it.

Can you explain the salient distinction between a "technical" versus "architectural" solution? Candidly, I'm not convinced that there is one.

Not concisely in the general case, but in this case the difference is fairly straightforward - CI/CD doesn't affect the structure of your executing application at all, only the surrounding context. I don't want to spend the hours it would take to characterize architecture as distinct from implementation, but the vast number of textbooks on the topic all generally agree that there is one, though they draw the lines in slightly different places.

I think what you're saying amounts to,

Very much no - my point is about the process of implementation. The services.. _do_ enforce boundaries, but the boundaries they enforce may not be good ones.

In order to successfully extract services from a monolith, you have to go through a process that includes finding and creating those domain boundaries for the domain being extracted. If it's your first time, you might be doing that implicitly and without realizing it's what you're doing, but under the hood it's the bulk of the mental effort.

The part where you actually _introduce a service_ can be anywhere from a tenth to half of the work (that fraction varies a lot by technical stack and depending on how coupled the domain in question is to the central behavioral tangle in the monolith), but by the time you've gotten the domain boundary created you've _already solved_ the original problem. Now you're facing a trade of "extract this well-factored domain out to a separate service application, to prevent its now-clear boundaries from being violated in the future". And I contend that that's a trade that should rarely be made.