Shields: Last Discussed on Stack Overflow Badge Proposal

[bui1]

:clipboard: Description
This badge is for repositories hosted on Github to demonstrate if the API/Service/Library etc. has
recent community support. Often times I'm picking a library that is outdated or
suggests that many contributors are not following anymore.
A dynamic badge to show the last date of the library has been talked about on a popular Q&A site, Stack Overflow would be helpful!
An example would be as below,

:link: Data
We can get the data via the StackExchange API using the StackOverflow parameters.
This does require an application key that can be thrown in together with the API url
for example, https://api.stackexchange.com/2.2/questions?order=desc&sort=creation&site=stackoverflow&tagged=SOMELIBNAME&key=apikey

Documentation: https://api.stackexchange.com/docs

I am also happy to try implementing this badge and make a PR to Shields!

[paulmelnikow]

Nice idea!

Other possibilities: questions in the last year, or questions in the last month. I think those figures would convey a better sense of the amount of activity, because the metric would be less sensitive to a single outlier question. Let's discuss and pin down the design.

Would be great to have your help to implement this! Our stackexchange badge is written using our legacy API and needs to be ported to a BaseJsonService subclass. The service also needs tests; it's one of relatively few at this point which doesn't have them. If you're up for it, what I'd suggest is doing a port of the existing functionality first, and adding the new badge in round 2.

We don't have any specific written guidance on porting, though there is a tutorial which shows how new-style badges work, and lots of PRs which have rewritten other badges. Here's one I did recently: #2252.

[bui1]

@paulmelnikow Those are also good suggestions especially with your point regarding the outliers.
Would something like this design be more suitable?

In terms of figuring out what to do next to make sure i'm understanding correctly

• Port existing Stack Exchange badge into the new BaseJsonService subclass
• Write new tests for said badge above
• Add new proposed badge?

[paulmelnikow]

Or a bit more concisely:

Yea! That's a good course of action. The best place to start is the tests – you can write tests for the old badge first, and we can even get them reviewed in a separate PR. It gives you something to test the rewrite against. And then, yea! You can add the new proposed badge in the last step.

[bui1]

Having some issues while porting StackExchange legacy to BaseJson and posting it here!

Writing the StackExchange endpoint handle function, although it is runnable i'm unable to get the data returned from this.__requestJson and even tried printing it right after but doesn't print anything to the console.
The API url is correct, my query parameters are fine. Not sure if my problems lies within the schema or elsewhere and am open to suggestions of where to look next.

In summary,
expected: requestJson return data should be some object containing numbers
actual: returning nothing? Unable to determine also the type of data response

This badge image is what I get overall

[paulmelnikow]

unparseable json response means you're getting back an HTTP response that isn't JSON. It suggests the endpoint isn't quite right.

You can use npm run test:services:trace or TRACE_SERVICES=true npm start and you'll get copious debugging output from BaseService. I bet that will help you find the error.

Another suggestion: start with a loose schema (Joi.any()), and add the validation once you get the basic thing working. 😀

[chris48s]

You might have already worked it out, but I suspect you are hitting this: https://meta.stackexchange.com/questions/284416/the-stack-exchange-api-appears-to-ignore-accept-encoding-this-breaks-curl

The same thing is happening with request (which is used as the underlying HTTP client). It isn't expecting a gzipped response, but the SE API is sending one anyway. I haven't looked into it any further than than that, but have a look at the request docs: https://github.com/request/request/blob/master/README.md#requestoptions-callback - I suspect if you set gzip: true it will work :)

[bui1]

@chris48s Yep I got it figured out! It definitely was weird to be seeing a non-JSON response being returned back but at least now I learned something new 👍