generalk

I saw that. The title did not make me think it was related. But fair enough.

It sure fucking is bonkers.

Ruby Central as an organization touts that it is responsible for RubyGems. Assuming this narrative is accurate, they needed to get agreements in place with contributors to appease some funding partners.

This shit happens. Especially as an open-source project started by one dude in 2009 turns into critical infrastructure managed by a 501(c)(3) non-profit.

That they failed so fucking spectacularly speaks incredibly poorly of their board.

It does not, for me.

Given that access was cut, then restored, then cut again, then days, then someone finally says "hey were were going to lose critical funding" makes it seem like a post-facto excuse for a hostile takeover.

And the whole "oh, well, we're bad at comms" makes it sound even worse!

Which is the whole crux of the issue. At no point in any of this did Ruby Central do anything reasonable. The they tried to explain that their unreasonable actions were reasonable, if you only knew the things they knew, which they were for some reason unable to tell people until just now.

Could it be true? Sure, absolutely.

Does it seem reasonable at the moment? Hell no.

Folks did this plenty prior to Electron, either by using cross-platform GUI toolkits (GTK and Qt both run on Windows, Java's been doing this forever with Swing and JavaFX, etc), or by writing GUIs for multiple toolkits/OSes that work with the same/similar core application logic.

Electron makes it easier to build cross-platform apps, and certainly cheaper, but it's not like it's the only way to do it.

Of course, and I can't fault Microsoft for that, even if (having been on the bad end of a similar acquisition and IT merge) it sucks for GitHub.

My point was: GitHub as an organization didn't choose Teams willingly, and are still paying for Slack and only using Teams for video conferencing. Of all the explanations of why that might be, the easiest to land on is "because Teams just isn't that good."

Bingo. Nearly impossible for our staff to do their jobs and not discuss something considered PHI.

Regardless of what you think of Teams -- I myself have had nothing but poor experiences over 2.5 years of using it daily -- it's telling that Microsoft has to require folks to use Teams.

I'm sure this is just Microsoft unifying everyone on the same comms platform, but seriously, I don't know anyone who chooses Teams.

I know non-tech folks who chose Outlook 365 because of familiarity and then end up on Teams because it's free, but there's a difference between "I chose an email/identity platform that I know and I guess I'll use its chat app too" and "I evaluated team chat offerings and Teams is our top pick."

Hell, at my most recent company (which was founded on O365 before I arrived) I replaced Teams chat interface with self-hosted Mattermost (Slack's HIPAA-compliant tier is way too expensive for a startup) and it was roundly loved. We did still lean on Teams for its video chat, because most of our non-tech staff know how to schedule and join video meetings, but even then the top complaint I got was from folks on Windows laptops whose Teams plugin for Outlook somehow got corrupted (or something?) and suddenly Outlook's Teams integration was gone.

Just an awful product all around -- said with no offense meant to the team building it.

_Update_: I now notice the text "for the sole purpose of video conferencing" which lines up with my use case, but still -- of all the video apps I put Teams down with Webex as "bottom of the barrel choices" due to the constant performance and functionality issues.

Oh no, the stuff I put in quotes was not Robbi speaking during the hand, but my imagining of what Neganeau would have sounded like in his typical confident chattery thinking aloud.

> Right but chasing what - she can't beat J8, QJ, KQ, any high flush draw.

Fair, there are definitely semi-bluffs that beat J4 here, and of course if Garret had a made hand she's toast.

There's also (and I think she says this at some point, "purely a bluff-catcher" IIRC) tons of pure air bluffs that J4 beats.

I simply do not understand the stance that if a poker player makes a call with a crap hand that turns out to be good, and then holds up, that she must be cheating. Not for nothing, but I have never heard such accusations leveled at a male player like this.

> If you're questioning someone's credibility, you can't really go with their own story about what happened as a reason to exonerate them.

I am not questioning her credibility.

Because there is no reason to.

The only reason anyone thinks she might be cheating is because her heads-up opponent angrily accused her of it. Not even after a bad beat! After his hand, which was never ever the best hand of the two, failed to make any of its draws over a river that was run twice.

I question the credibility of the accusation. Garret has every reason to accuse his opponent of cheating, especially given that he successfully intimidated Robbi into returning his chips, which to me is just insane.

Why the conversation isn't "poker player doesn't catch his outs, demands his money back" is beyond me.

  > Say, initially you were told "if I click this button the status should  
  > update to complete", you write the test, you implement the code, rinse and 
  > repeat until a demo. During the demo, you discover that actually they'd 
  > rather the button become a slider, and it shouldn't say Complete when it's 
  > pressed, it should show a percent as you pull it more and more. Now, all the 
  > extra care you did to make sure the initial implementation was correct turns 
  > out to be useless.

Sure, this happens. You work on a thing, put it in front of the folks who asked for it, and they realize they wanted something slightly different. Or they just plain don't want the thing at all.

This is an issue that's solved by something like Agile (frequent and regular stakeholder review, short cycle time) and has little to do with whether or not you've written tests first and let them guide your implementation; wrote the tests after the implementation was finished; or just simply chucked automated testing in the trash.

Either way, you've gotta make some unexpected changes. For me, I've really liked having the tests guide my implementation. Using your example, I may need to have a "percent complete" concept, which I'll only implement when a test fails because I don't have it, and I'll implement it by doing the simplest thing to get it to pass. If I approach it directly and hack something together I run the risk of overcomplicating the implementation based on what I imagine I'll need.

I don't have an opinion on how anyone else approaches writing complex systems, but I know what's worked for me and what hasn't.

+1 on "well defined spec" -- a lot of Healthcare integrations are specified as "here's the requests, ensure your system responds like this" and being able to put those in a test suite and know where you're at is invaluable!

But TDD is fantastic for growing software as well! I managed to save an otherwise doomed project by rigorously sticking to TDD (and its close cousin Behavior Driven Development.)

It sounds like you're expecting that the entire test suite ought to be written up front? The way I've had success is to write a single test, watch it fail, fix the failure as quickly as possible, repeat, and then once the test passes fix up whatever junk I wrote so I don't hate it in a month. Red, Green, Refactor.

If you combine that with frequent stakeholder review, you're golden. This way you're never sitting on a huge pile of unimplemented tests; nor are you writing tests for parts of the software you don't need. For example from that project: week one was the core business logic setup. Normally I'd have dove into users/permissions, soft deletes, auditing, all that as part of basic setup. But this way, I started with basic tests: "If I go to this page I should see these details;" "If I click this button the status should update to Complete." Nowhere do those tests ask about users, so we don't have them. Focus remains on what we told people we'd have done.

I know not everyone works that way, but damn if the results didn't make me a firm believer.

  > tl;dr I can't understand getting mad at the Internet for being the Internet 
  > in 2022, it will never get better, if anything it will only get worse [...]

If I may provide an alternate tl;dr to your comment: "People are being absolute rude, disrespectful assholes; which is absolutely fine. Ron Gilbert asked for this abuse by making things. The real issue is that he disabled comments on his own blog, where people should be firmly allowed and encouraged to shit on his work."