Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by Cynddl on Friday June 16, 2017 @06:27AM
(#14567792)
Despite the title, the article raises an interesting point: why do we prefer new code, with less features, to old but robust projects.
> Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons of questions and answers on StackOverflow and Quora.
I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by insulanian on Friday June 16, 2017 @06:52AM
(#14567888)
Old last commit date could mean two things:
1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it.
2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future.
I think it would help if maintainers would state the "completeness" in the README file.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by kuzimoto on Friday June 16, 2017 @09:58AM
(#14568996)
I think most of the time I just assume it's #1 and then check into the issues to see the number/severity of the current problems and if any important things are being neglected.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by tracker1 on Friday June 16, 2017 @05:21PM
(#14572736)
I find that additionally (presuming github or similar) that looking through for any recent issues helps a lot... npm download rate is another metric for comparison. Thouse some obscure bits may not see so many downloads at all.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by allengeorge on Friday June 16, 2017 @07:41AM
(#14568087)
Maybe because we're swayed by superficial, yet impactful choices: the use of a "modern-looking webpage with a visually-attractive theme", the use of the latest technologies - or at least those the community is talking about, buzz around the project, etc.
I realize it's tedious, but even older projects could do with periodic updates to tutorials, documentation, webpage updates and outreach to draw new interest from the community.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by lostcolony on Friday June 16, 2017 @08:46AM
(#14568379)
"It may be stable, but is it pleasant?" to use, to develop with, etc. That matters. There is definitely a goldilocks zone for libraries/frameworks, where they're mature enough to be reasonable to use in production, but still recent enough to not require a lot of effort to bring up to date.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by _asummers on Friday June 16, 2017 @09:10AM
(#14568525)
At work, we've been using Elixir. Because of the Erlang interop, I find myself looking at a lot of Erlang code that hasn't really had any reason to be touched in years. It's really bizarre seeing a project with no commits in the last few years and having to decide if it's abandoned or feature complete.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by crdoconnor on Friday June 16, 2017 @10:25AM
(#14569255)
>I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
I do it because of code rot. The environment you will surround the project with (runtimes, libraries, frameworks) has often changed enough in 2-4 years to render it unusuable.
Additionally a recent commit implies regular maintenance which implies that if you report it will get fixed.
Also, projects are often abandoned because there is a clearly better version out there.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by dleslie on Friday June 16, 2017 @10:25AM
(#14569257)
Old last commit isn't a good metric for health; particularly for projects that don't go anywhere near hardware. There's plenty of time-tested and popular C libraries that only _very_ rarely see a patch suggestion, let alone a commit.
Check the mailing lists and forums; and look around for projects that depend on it.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by petee on Friday June 16, 2017 @04:16PM
(#14572314)
I always assumed stars were just a form of bookmarking for me to find projects again easily, since there is no other method than 'watching', which results in too much info
This new project is quite nice and definitely a step up from mine.
Also wanted to mention that there is a CLI version of the visualizer at https://github.com/sheerun/graphqlviz for when you want to quickly visualize a GraphQL endpoint for documentation purposes, etc. Keep up the good work!
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by nerdponx on Friday June 16, 2017 @10:14AM
(#14569146)
But after looking at the source code we found a fatal flaw in this tool: it used Graphviz — a decades old tool written in plain C and compiled to unreadable JavaScript using Emscripten.
Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by ryandrake on Friday June 16, 2017 @12:04PM
(#14570116)
"Decades old" often means that it is mature, has relatively few bugs, and is not going to soon go through some major API-breaking re-architecture just because the maintainer wants to experiment with a new framework-of-the-week. "Written in plain C" means I will likely be able to call/integrate it into my project with little fuss. These are both things to actively look for when browsing for open source libraries.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by diggan on Friday June 16, 2017 @08:39AM
(#14568340)
Ignoring the fact that Github Stars are a aweful metric for anything else than vanity, "More bells and whistles" feels like a terrible advice and you should much more focus on a "easy-to-get-started" readme with just the minimal amount of beels and whistles to effectively communicate what your thing is really about.
Re:How we got 1,500 GitHub stars by mixing time-tested techn...
by nerdponx on Friday June 16, 2017 @10:57AM
(#14569550)
Search engines rank sites (in part) according to the number of other sites that link to them. Wikipedia is ranked very highly in Google largely because many, many sites link to Wikipedia.
The PageRank algorithm to compute these kinds of rankings was one of Google's early innovations, and was the secret to its initial dominance over the early-2000s search engine market.
> Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons of questions and answers on StackOverflow and Quora.
I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it.
2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future.
I think it would help if maintainers would state the "completeness" in the README file.
- 0.x = version in some beta/alpha/unstable state
- 1.x = version in somewhat stable/complete state
Word of mouth and some good old experimentation seem to be your best options for identifying solid tooling.
I realize it's tedious, but even older projects could do with periodic updates to tutorials, documentation, webpage updates and outreach to draw new interest from the community.
I do it because of code rot. The environment you will surround the project with (runtimes, libraries, frameworks) has often changed enough in 2-4 years to render it unusuable.
Additionally a recent commit implies regular maintenance which implies that if you report it will get fixed.
Also, projects are often abandoned because there is a clearly better version out there.
Check the mailing lists and forums; and look around for projects that depend on it.
Making GitHub stars ultimately meaningless, if they ever meaned anything.
This new project is quite nice and definitely a step up from mine.
Also wanted to mention that there is a CLI version of the visualizer at https://github.com/sheerun/graphqlviz for when you want to quickly visualize a GraphQL endpoint for documentation purposes, etc. Keep up the good work!
Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".
The PageRank algorithm to compute these kinds of rankings was one of Google's early innovations, and was the secret to its initial dominance over the early-2000s search engine market.