Live data from Hacker News

We lost 54k GitHub stars

httpie.io

591–600 of 697 posts

Re: We lost 54k GitHub stars

#591
Imagine this in any other profession, oh I put gold in the trash but the trash bin did not inform me that I was pouring such important thing there, or why the disposal vehicle not stopped me after detecting such valuable content?

Re: We lost 54k GitHub stars

#592
post #573

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.” It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and…

Warnings are vastly less useful than making such activities less dangerous. If you feel something needs get giant flashing warning messages perhaps make it reversible for a week.

I don't know for sure but I think in some jurisdictions "hang on to this data you told me to delete for another week" would be a non-starter.

Re: We lost 54k GitHub stars

#593
post #534
post #508

Contrarian opinion here. While things can always be better the Github UX is good enough here. I am reminded of an old phrase: “A bad workman always blames his tools.” At some point you just need to accept responsibility for your actions and stop blaming others.

Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause. Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.

They didn't say so, but 100% they copy-pasted the name from the prompt. I always do. They didn't type manually it in a way that would help them catch the error. That's a big reason that "enter this thing: ______" isn't foolproof. Perhaps it should at least be made unselectable.

Re: We lost 54k GitHub stars

#594
post #437

Earlier quoted context omitted.

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale). Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years). This particular problem is a textbook candidate for Command Pattern. The problem of un…

I'm in the process of creating an MVC framework and was curious about the other architectures you mentioned. This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ): > Rails still is a great way to get a prototype demo, or minimum viable product online in…

I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.

He has a great article (2014), old, on why you may not want to build that framework at all[2] too:

> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.

Another great source are the books, and/or youtube channel by Dave Farley[3]

What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.

In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:

> also due to the strong coupling of database interaction and application logic,

This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.

It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:

> Tackling Complexity in the Heart of Software

This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.

So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.

Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.

[1] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g

[2] https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...

[3] https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g (his books are promoted on this channel)

[4] https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...

[5] https://martinfowler.com/bliki/DomainDrivenDesign.html

Re: We lost 54k GitHub stars

#595
GitHub became more a social platform rather than just a code repository and it let you build up a community - I can't argue with that. But it's a large commercial company that doesn't really care about you. Now, when it's microsoft, more so than ever. I'd never trust my data to a company like that. Last time I trusted Google I lost all (decade worth of) email. I worked in a company that WOULD sometimes make devs manually scrap user data from the database when it was our fault or users were somewhat important, but that's more like exception to the rule.

Re: We lost 54k GitHub stars

#596

Earlier quoted context omitted.

I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e…

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

> I don't know what else GitHub could do to prevent this.

The article describes exactly what else they could do, including example screenshots from another app that does it.

Re: We lost 54k GitHub stars

#597
post #437

Earlier quoted context omitted.

Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale). Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years). This particular problem is a textbook candidate for Command Pattern. The problem of un…

https://github.com/rubysherpas/paranoia is enough to solve problems at very large scales. There is nothing about Rails or MVC preventing someone from doing this. This is a very common design principle for all kind of ERP and BPM systems: don't ever delete anything.

First: soft-delete really doesn't need a library. Paranoia is nice, but almost all of the code and complexity in that gem is to support multiple versions of rails and to let you configure that gem.

DIY in this case really is very simple. And far more flexible, performant even, and future-proof.

(I've worked on a project where two full-time devs spent days upgrading this gem; this is over 6 years ago). And a few months ago, I worked on a project where they had more code to configure, patch and work around paranoia, than any DIY ever did. My even simpler DIY version not only used 50% of the code we had to override the gem before, it allowed for some custom work that we could not do before.

And no: even DIY ain't as simple as you make it seem. Practical issue, that I encountered last year even, was where their "soft delete" was making state-machines very tough. Because in a FSM, "deleted" wants to be state, like anything else. But the "generic soft-delete" conflicts with that. So the project had both. And some fugly glue-code to sync between the FSM and the soft-delete and vice-versa. No suprise that this broke occasionally, making data re-available that people thought gone.

Re: We lost 54k GitHub stars

#598

Earlier quoted context omitted.

I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e…

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

This kind of attitude is how bad products get made.

Re: We lost 54k GitHub stars

#599
post #585

Earlier quoted context omitted.

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

I don’t see the need for moralizing. They took responsibility, and offered GitHub money to help. They aren’t leaning in heavily to blame Github here. It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further. Calling them careless is also unjustified. They made a mental error processing the info…

Honestly, they are blaming Github here. They included a whole "Lessons" section, which are complaints about Github's UI, then database design, then community support. I don't think we should be making fun of them for accidentally privating their repo, but I absolutely laughed at

>The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.

Re: We lost 54k GitHub stars

#600

Earlier quoted context omitted.

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

Funny thing is that I have never typed in a repo to delete. I always just copy/paste from the message. It's probably what the repo owner did. Perhaps Github should generate an image instead of using text that can be copied. That way they could help mitigate the copy/paste problem.

This would be an accessibility regression.
Post reply on HN