awesome-readme VS minio-py

About user-statistician

The user-statistician GitHub Action can generate an SVG with a detailed summary of your activity on GitHub. It is mentioned in the tools section of the awesome README awesome list. The SVG it generates includes general information about you (e.g., year you joined, number of followers, number you are following, most starred repository, etc), information about your repositories (e.g., numbers of stars and forks, etc), information about your contributions (e.g., numbers of commits, issues, PRs, etc), and the distribution of languages within your public repositories.

If you really want a stellar README.md take a look at some of the examples in awesome-readme for inspiration!

Awesome README - A collection of high-quality READMEs from a variety of projects, organized by topic. https://github.com/matiassingers/awesome-readme

Provide a succinct and comprehensive README: readers of your personal project will always start with the README to know where to begin. The goal of the README is to provide the reader an understanding of the business problem you are trying to solve, how your solution goes about solving it (solution architecture diagram), and how to get started and run your code. There are plenty of great README examples here: https://github.com/matiassingers/awesome-readme

About user-statistician

Recently, the user-statistician GitHub Action was added to the tools section of Awesome README, which is an Awesome List that includes a curated collection of examples of Awesome READMEs from open source projects, as well as tools enabling creating Awesome READMEs. The Awesome README list is a great place to go if you are looking for ideas for how to improve the READMEs of your open source projects. The Awesome README list covers READMEs more generally, but the tools section includes a few tools focused on Profile READMEs, in addition to many tools for project READMEs more generally. The user-statistician GitHub Action is in the Tools Section.

Python

Alternatively you could look into presigned urls which can also be done in python.

The program is running a SQL query against a remote file. This example in MinIO docs demonstrates reading from the response stream. So far, so good.

>So far your instinct as product designer/manager/engineer might be to take what customers say they want at face value.

That would be the worst way to go about building anything. Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.

The question then becomes how does someone who generally knows how to build the right things build the bare minimum feature, the original question and title of the post, given the constraints on time and resources cited in the first paragraphs.

One can do several things. For example, writing the description and code examples for a yet to be library and shop it around, see if it makes sense, then write the library.

That's what I did for example with this library: https://pypi.org/project/bmc after shopping it around here: https://github.com/minio/minio-py/issues/829#issuecomment-65...

I also do that for internal tools, libraries, SDKs. I'll send client code around and see if it makes sense to engineers. I also had non engineers who never coded use libraries to do something useful. I just give them a laptop and docs and see how they use the thing. If they can do it, I know programmers can.

To get back to the original problem, prioritizing can lead towards minimal features. We have a section called "Instances" in our issue templates. If a feature issue does not have several instances where the problem manifested for several people, we just won't do it. We need concrete examples of a problem being frequent and expensive / high impact (loss of work, or prevents work in the first place).

For example, I'll look at the analytics for our internal platform and see that my colleague who we built the thing for is not using it. Why, we ask. It turns out the Docker images are too large and take a lot of time. He loses patience. They contain several libraries that he does need.

We built a minimal image that can get him to start after 30 seconds instead of 2 minutes, and we saw usage increase.

Yesterday, I saw he was giving a demo using his local environement, not the product. I'll ask why. What's wrong. What sucks. Why did he use his laptop instead of the platform.

The general sentiment of the article is sound. Always observe, ask questions, look for the underlying problems and how frequently they happen, how expensive they are (as in what are they doing to solve that, is there someone working on it, does it cost opportunities, etc)

I used to write libraries and have non-technical people who never programmed follow the documentation and use them. My reference point is that if they could do it, then programmers will have no trouble doing it.

The next best thing is writing the doc before the actual code, and have others look at it and see if it makes sense, then I'd write the code that makes that possible.[0]

- [0]: https://github.com/minio/minio-py/issues/829#issuecomment-65...

Yes. A case of it working well: https://github.com/minio/minio-py/issues/829

I found this issue for a problem I had with MinIO. I wrote a prototype: docs first and screencast on how the API would be. I then asked the other user if they had implemented it and if the API I was thinking about would suit them as it suited me. MinIO's CTO replied that it was the correct usage, but that it was not on the roadmap, which is understandable.

I then started implementing the actual commands I needed first (host, ls, etc). Some time later, someone tweeted at us and asked how they could use the library. I then put it on PyPI (Python Package Index). I checked upon that person recently and they told be they've been using it for months without a problem. The other person also had commented and said they've been using it.

https://pypistats.org/packages/bmc

It's a really, really, small library for a niche need, also asked people for feedback here: https://news.ycombinator.com/item?id=26540342

Now I'm getting feature requests on that issue, but I'll soon do it properly in a repo to make it easier for people.

Thank you for these points. I agree. It's one of those tools that, if you have that problem, you know exactly why you need it.

This solves this issue: https://github.com/minio/minio-py/issues/829. MinIO is an S3 compatible object storage software. https://min.io/

Thanks again.

We use it in anger at Splitgraph [0] to let people upload/download datasets and Postgres table snapshots (instead of storing them directly in S3).

Pros:

* Less platform-dependent. By self-managing it, we can also run deploys to GCP / Azure / Scaleway / other providers without writing a separate adapter for e.g. Azure Blob Storage.

* Python API [1] much more pleasant to use than boto3 (and can speak to normal S3). It doesn't do everything that boto3 does, but it supports everything we need (e.g. pre-signed URLs).

* minio server itself supports a large chunk of S3's functionality (e.g. SELECT API / AssumeRole / bucket versioning)

* Don't pay per request and for egress: this was a big deal since people might want to download large amounts of data from us (or make a bunch of small requests to download/upload a subset of data).

Cons:

* Have to manage own infrastructure. We run it on managed VMs so it's semi-managed, but we still have to provision block storage, set up backup policies etc.

* In a similar vein, scaling and availability all have to be DIY [2]. We haven't run into situations yet where Minio would be the bottleneck, but it might be something to keep in mind.

* Obviously not as seamless: you don't get things like Glacier or integration with other IAM.

[0] https://www.splitgraph.com/

[1] https://github.com/minio/minio-py

[2] https://docs.min.io/docs/distributed-minio-quickstart-guide....