https://xitter.cf/t.co/DQK7ghrHdm
Portola Valley
Joined August 2009
- Tweets615
- Following211
- Followers6.2K
- Likes767
I've been hooked on Queens puzzles for the last few months, and as a side project built a solver for them: github.com/dschafer/qsolve.
It does basic image recognition to read games in from various sites, especially from linkedin.com/games/queens (the original as far as I know). It also picks up in-progress games as well, which is useful for getting a hint on hard puzzles.
Dan Schafer retweeted
We are now Cult.Repo. The original creators behind the iconic Open Source documentaries (@vuejs, @reactjs, @GraphQL) are back together! Honeypot is now called @CultRepo and is independently-owned.
We are on a mission to document the complete history of every major open source language ever created.
With 250K subscribers and over 15M views, we're building on our foundation as creators of the acclaimed Open Source Origin Story documentary format.
Coming in 2025: @ThePSF, @vite_js documentaries and much more.
Our independence is core to our mission. We believe the human stories behind open source deserve authentic, in-depth storytelling.
Our new model is powered directly by:
- Community support from viewers
- Sponsorships from organizations that champion open source
This transition represents our commitment to independent, meaningful tech storytelling that honours the collaborative spirit of open source itself.
I'm ready to share a side project I've been working on: footballpace.com. It uses historical data to see how typical soccer champions perform in each match; then uses that to generate strength of schedule–aware tables, and to show the difficulty of upcoming matches.
The source code is at github.com/dschafer/football…. It's hosted on @vercel with a @nextjs / @reactjs front-end, and a @dagster data pipeline.
This tweet by @zeeg points out a valid obstacle towards the adoption of GraphQL — but a surmountable one, in my view. There are two major things needed to overcome this concern. (continued below)
But this tradeoff is right in a lot of use cases... and when it is, the benefits of GraphQL can be massive, which is why so many folks are using it and happy with it.
(and if someone wanted to build/has built that tooling I mentioned, they'd make a lot of GraphQL users happy)
Just saw the follow-up at xitter.cf/zeeg/status/1721383299… — such tooling helps with high-traffic use cases, but not external ones.
You *can* use GraphQL for high-traffic external APIs (as GitHub demonstrates)... but "most of you shouldn't be using it" is spot on advice for that use case
