ravirajx7
Joined 11 years ago
Joined 11 years ago
I no longer feel joy in reading things as almost most of the writing seem same and pale to me as if everyone is putting thoughts in the same way.
Having your own way of writing always felt personal in which you expressed your feelings most of the time.
The most sad part for me is I no longer am able to understand someone's true feelings (which anyway was hard to express in writing as articulation is hard).
We see it being used from our favourite sports person in their retirement post or from someone who has lost their loved ones or someone who just got their first job and it's just sad that we no longer can have that old pre AI days back again.
The idea is to hook into Bitbucket PR webhooks so that whenever a PR is raised on any repo, Jenkins spins up an isolated job that acts as an automated code reviewer. That job would pull the base branch and the feature branch, compute the diff, and use that as input for an AI-based review step. The prompt would ask the reviewer to behave like a senior engineer or architect, follow common industry review standards, and return structured feedback - explicitly separating must-have issues from nice-to-have improvements.
The output would be generated as markdown and posted back to the PR, either as a comment or some attached artifact, so it’s visible alongside human review. The intent isn’t to replace human reviewers, but to catch obvious issues early and reduce review load.
What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness. I’m also concerned about failure modes - for example, noisy or overconfident comments, review fatigue, or teams starting to trust automated feedback more than they should.
If you’ve tried something like this with Bitbucket/Jenkins, or think this is fundamentally a bad idea, I’d really like to hear why. I’m especially interested in practical lessons.
Like many others, I started with C. It taught me the basics - memory, pointers, writing data structures from scratch - but most of the time it felt like I was just trying not to break things. Solving problems became more about handling the language than understanding the logic.
Then I came across Java, and something just clicked. It felt structured, readable, and intentional. Almost like reading good English. For the first time, I could focus on the actual problem instead of building the tools to solve it. Collections, built-in libraries, and a reliable runtime made coding feel productive, not just painful.
Even now, years later, Java still feels like home. It’s not perfect, but it gave me the space to learn, grow, and build things that last. I really appreciated this article - it captures that quiet strength Java has, and the care so many people have put into making it better over time. It reminded me why I still enjoy writing Java after all these years.
Local shops were quoting ₹25,000–₹30,000 (roughly $300–$360), which he just couldn’t afford. Then a friend told him about Nehru Place. He sent the laptop there through someone he knew, and the repair only cost him around ₹5,000–₹10,000 ($60–$120). Way more reasonable.
He was glad to get it fixed without spending a lot but it does make you wonder how reliable those reused parts are. Like, how long is it gonna hold up before something else goes wrong?
Curious to know from the people who have read a lots and lots of text or books or watched movies.
Voracious reader.
Twitter: twitter.com/ravirajx7
Portfolio: https://rjx7.com
Blog: https://blog.rjx7.com
Email: raviraj(dot)x7(at)gmail(dot)com
meet.hn/city/in-Ranchi