stats
pg_stat_monitor
Our great sponsors
stats | pg_stat_monitor | |
---|---|---|
1 | 1 | |
62 | 423 | |
- | 3.1% | |
8.1 | 7.7 | |
about 1 month ago | 5 days ago | |
Perl | Perl | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
stats
-
I ****Ing Hate Science
> do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult.
I don't think you are incorrect, but I think a lot of the aspirants behind ESE just want to have a better sense of what works and what doesn't; I'd even welcome negative results! The current state of things is to read 100 opinionated people and their blog posts. And given enough time, you'll encounter someone who swears that after drinking their morning coffee and jumping on one foot for 1 min, they enter a VRChat standup with their team and hit max flow. There's just so little knowledge right now about what works and what doesn't that I'd welcome more clarity, especially negative results.
> As a result, academic research into productivity can be difficult to generalize
I think defects are what we should measure for, not productivity because of the subjectivity of measuring productivity. But even measuring defects is complicated. The best way I see to measure defects is to ask a Team Under Test to document bugs that they encounter along with resolution times, but this is not only expensive, but something I doubt most corporations will be willing to share outside of their walls. Perhaps open source projects can try to store this data, like curl's stats [1].
[1]: https://github.com/curl/stats
pg_stat_monitor
-
Recap Monthly Percona Developer Meetup Hacktoberfest
Our next project is percona/pg_stat_monitor, a Query Performance Monitoring tool for PostgreSQL. The maintainer is Ibrar Ahmed, Sr. Software Engineer (PostgreSQL). The primary area to contribute is the releases. If there are contributions with ideas on improving the information provided for pg_stat_monitor, they are welcome. The issues are defined in Jira.
What are some alternatives?
strava - source code of my Strava API app: Excel import and export of activities, written in Perl 5
percona-docker - Collection of Dockerfiles for Percona software. See individual directories for more details.
PDL-Graphics-Gnuplot - Gnuplot-based plotting backend for PDL
mongodb_exporter - A Prometheus exporter for MongoDB including sharding, replication and storage engines
draco - Draco is a script to convert reddit thread to Org document
Hacktoberfest2023 - About Make your Pull Request on Hacktoberfest 2023. Don't forget to spread love and if you like give us a ⭐️
pmm - Percona Monitoring and Management: an open source database monitoring, observability and management tool
percona-server-mongodb-operator - Percona Operator for MongoDB
os-autoinst-distri-opensuse - os-autoinst test cases for openSUSE
postgresqltuner - Simple script to analyse your PostgreSQL database configuration, and give tuning advice
postgrest - REST API for any Postgres database
perl-App-perlmv