Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git...
For further actions, you may consider blocking this person and/or reporting abuse
Putting blog stats in the terminal sounds small, but it changes the habit loop. If the metric lives where you already work, you are more likely to notice patterns without opening a dashboard rabbit hole. The useful version is probably not more analytics, but fewer numbers surfaced at the moment they can affect what you write next.
Integrating blog stats directly into the terminal is a fantastic way to keep track of engagement without context switching. I have built similar CLI dashboards using bash and curl, and one tricky part I always run into is handling API rate limits gracefully when polling frequently. Have you considered using a local cache file with a timestamp to prevent hitting the dev.to API limits on every terminal refresh? It would make the script much more robust for daily use.
Excellent breakdown! What's your recommendation for someone just getting started?
Just play around with the basics, don't try to go for creativity, go for something which already exists understand how it works etc, then put creativity into it.
Really enjoyed this write-up. Using lh.table as a bridge instead of modifying the archived project was a clever approach, and the debugging stories (429 retries with jitter and the comma parsing issue) made for a fun read. It's a great example of adapting existing tools rather than reinventing them. Projects like CodeCan.net that focus on improving the developer workflow fit nicely alongside ideas like this. Thanks for sharing :))
Thanks bud