generalk · HackerTrans

10개월 전discuss

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

10개월 전discuss

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.

generalk

10개월 전discuss

Wait, what?

A maintainer of RubyGems was forcibly removed from the RubyGems GitHub org — which was renamed to Ruby Central — along with every other maintainer. Then access was restored, then revoked again. There was no explanation, no communication, and no understandable reasoning for this.

And still! If there is an "official" statement, I can't find one on https://rubycentral.org/.

This wildly transcends "issues with both internal and external communication" or "we're just a bunch of makers who can't be expected to be good at organization or communication" (to highly paraphrase TFA). This is an absolutely disastrous breach of the community's trust.

generalk

10개월 전discuss

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.

generalk

4년 전discuss

  > 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.

generalk

4년 전discuss

+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.

generalk

6년 전discuss

I would definitely love to see a setting for "if this one-lane back road route saves me less than ten minutes, just take me on the big main street."

comments