GitHub Star History Graph(star-history.com) |
GitHub Star History Graph(star-history.com) |
But projects I work with daily, I don't need to star them to remember they exits, like React or Webpack.
Just to share a trick, you can also use markdown to embed a live star history chart to your GitHub README. e.g.
## Star History
[ and how TiBD factors in and would be used. All obvious links for TiBD go direct to a signup page which I don't want to fill without some understanding/validation of the service I'm signing up for. Removing the path of this signup page, in an attempt to go to the root URL to learn more, then takes me to an Auth0 access page. I appreciate I may not be your target market, but just giving my view of someone thinking "This looks cool, how much would it cost to have a customized version of this?"
https://github.com/dtolnay/star-history
Here is a side-by-side comparison of graphs generated by star-history.com vs my tool: https://github.com/dtolnay/star-history/issues/8
You can distinguish a lot finer structure in my graph: coinciding with individual blog posts with not as much reach as something on Hacker News front page. That structure is almost entirely concealed in star-history.com by the cartoony graphs.
It was on the HN homepage for about 5 hours yesterday, never higher than about 25. The initial jump on the 25th was some attention on Twitter. Also the HN link was to the website, not the GitHub. I imagine if it had been a link to the repository the stars would be higher.
The idea being that people who starred your repo who themselves have tons of stars are likely "better" in that they are likely to be experienced, intelligent users, and not bots.
Edit: the code in question[2].
[1]: https://docs.github.com/en/rest/activity/starring#custom-med...
[2]: https://github.com/bytebase/star-history/blob/c8c66678db8015...
[0] https://github.com/bytebase/star-history/tree/main/packages/...
<shameless-plug> We also show the GitHub star history, alongside npm download history, issue and PR stats on Openbase: https://openbase.com/js/react/insights </shameless-plug>
Does not work. Only JavaScript top list work for me.
Before you incorporate someone's Github library into your own project, you want to know some things. Is it secure? Is it well-maintained? Is there an active userbase to help with support? Stars are one indicator of this.
In OctoSQL[0] I'm literally just sending JSON files with coarse information about 1. invocations of the CLI, 2. features used in these invocations, to a VM on DigitalOcean (with a 10-line server receiving them and writing to a JSON file - which I can then process using OctoSQL itself).
Thanks to this I knew that until recently most of what I had were stars, not actual usage, and could also see how the big rewrite I released in January (and the following updates) made a lot of people start actually using it since. Very nice feeling :)
All telemetry logic in OctoSQL is actually contained in a single short file[1].
PS: Keep in mind that https requests take a long time, as they need to do a few roundtrips for the TLS handshake. Don't do that on every invocation if you have latency-sensitive invocations. I.e. in OctoSQL I'm only sending aggregated telemetry data every 10 invocations (as well as on the very first one).
[0]:https://github.com/cube2222/octosql
[1]:https://github.com/cube2222/octosql/blob/main/telemetry/tele...
Also agree with you about telemetry. We send some minimal telemetry in Robusta (also easily disabled) and it's been a big help for us as a project.
First time I posted an early naive version of my string lib, the thread became a deluge of 500+ reactions and constructive advice. Subsequent submissions with a much better work got me depressed.
You may want to consider mentioning it in the README.md as well and alongside any example/default configuration you generate indicating the default state and setting to disable it, especially if it's only output the first time it writes the telemetry history.
(1) you're collecting data where if it was public, people would be outraged. That's spying.
(2) you believe the data is anonymous and valuable, but only you / your group should benefit from the insights it provides. You're afraid someone else is going to 'take your ideas' and execute them better than you can.
Point 1 is ethically wrong, in my view. Point 2 is not ethically wrong, but IMO means what you are just trying to run a monopoly on an idea. That's fine, people do it all the time, especially companies - but I think this is wrong for the progress of humanity overall and I dislike it.
The easier way is to assume all signals emitted by your computer are being consumed somewhere (Hey CIA friends!) and not emit anything you don't want detected.
Public analytics therefore help ensure and demonstrate your analytics are ethical.
There's not a lot of us, but we're definitely out here.
- 69% of respondents love React, 31% dread React
- 25% of developers who are not using React would like to use it (1st place among web frameworks)
I recall one year there were SO MANY people saying that they loved Rust (enough to make it the most loved language in the survey) but the number of people who answered that they were actually using Rust was far, far smaller. something like 10% of the number of people who claim to love it have ever used it for any purpose.
I think someone could easily cherry pick results from this survey to back any opinion they have, completely independent of any actual "truth."
Because that's exactly the context in which I'm quoting it :)
> something like 10% of the number of people who claim to love it have ever used it for any purpose
"Loved" specifically measures what fraction of people currently using the technology say they desire to continue using it next year. In the survey there is no such thing as non-users claiming to love it.
people respond to surveys according to what they want the survey results to be, and not how things actually are.