Hacker News new | ask | show | jobs
by tessierashpool 1695 days ago
hi! I made Fork Freshness. that alternative is much faster, but it relies on the `pushed_at` attribute from the GitHub REST API. I was unable to find documentation for that attribute, but I rejected the GraphQL equivalent, `pushedAt`, because if Dependabot pushes to an otherwise dead repo with a PR to auto-update some dependency, `pushedAt` treats that as recent work. I didn't want to write a robot which chased another robot around in a circle, so Fork Freshness instead uses its own much more labor-intensive system. it's much slower, but I believe it's also more accurate.

I wrote that up here, in a fairly gigantic blog post:

https://gilesbowkett.com/blog/2021/08/15/fork-freshness-proj...

that blog post also explains why I based the UI around Twitter. TLDR: fun experiment. re the question of making the UI work in a different way, TLDR: maybe.

part of the experiment was just to see how far I could get without creating a User model. but since Fork Freshness does a relatively slow analysis, I wanted to use an asynchronous UI. I'm not married to it, though, I could see good arguments for setting it up to work differently.

edit: btw, thanks for the discussion re my project! I'm late for a concert and travelling tomorrow morning but I can't wait to dig into these comments some more.

2 comments

Cool project. Going to fire a tweet now, as I’m interested in one particular repo.

Same problem as stated here, repo owner moved on. Thankfully a few people have contributor access on the main repo so it hasn’t died yet. But I’m likely to go awol on it in the next few months and there’s no clear second in command to hand it to.

I’ve also been working with the GitHub api this weekend and I was wondering how pushed_at and updated_at were differentiated. Good to know re: dependabot

> I wrote that up here, in a fairly gigantic blog post:

That blog post is the same link for this thread.

> without creating a User model

A User model isn't necessary if you don't require login to use your tool.

> My theory now is that whichever ActiveRecord model is closest to the UI will grow huge as it comes to incorporate a comprehensive catalog of user interactions. It's an interesting question, but it's also a topic for another time.

User preferences, settings, interaction history, whatever can be stored in different models. The User model can be slim.

Good to know. It seemed odd to include details about the framework. The tool could've been written in Django, Angular, React, etc.