zabil

There more things in a pull request other that just reviews. It can run a build pipeline and give feedback, provision test instances to run quick tests.

It can also be used to add context and have a conversation around the why's before merging. And yeah while it's not the main purpose we've caught a lot of bugs too just from the statically reviewing code.

I switched from Claude code to the GitHub copilot app recently. Since our repositories are hosted on GitHub I find the copilot app better integrated for the PR workflow with PR management available in the app. I don’t think I miss any of the features of Claude code I never thought I would make the switch but copilot upped the game.

Also it became very hard to convince management to keep both Claude code and GitHub Copilot enterprise licenses.

I am learning music. I used codex to create a native metronome app, a circle of fifths app, a practice journal app. I try to build a native app alternatives.

I have no plans of publishing them or making the open source, so it will not be a part of this metric. I believe others are doing this too.

After watching a few seasons of traitors (UK) I feel none of these techniques work and may even end up accusing the wrong person.

The show had former detectives and police folks failing miserably. It just boils down to evidence.

I have a slight dislike for JSON+REST for API's.

The design overhead involved in determining the correct URL and HTTP method adds a layer of subjectivity to the design and bike shedding arguments.

I’m not a huge fan of Protobuf/GRPC either, if there’s a better alternative I believe RPC is the right approach for exposing APIs.

I don’t think it’s bad on its own, but from my experience, the rollout can be messy and lock people out. Aadhaar in India had long registration queues, biometric issues, and banks making it mandatory. Even in the UK, the digital residency permit switch caused issues at border control.

It’s hard not to be overwhelmed by the Sagrada Família — it feels less like a building and more like a living organism stretching toward the sky. Makes Barcelona along all that it already offers a beautiful city to visit.

I also feel the tragedy behind its beauty. From what I've read, Gaudí dedicated later part of his life completely to it and he died poor and unrecognised, hit by a tram and mistaken for a beggar.

Not a fan of the new Safari design. I used to like it for its compact and minimalist look, but now the address bar and tab bar feel like they take up more space than they should.

In my experience, Page Objects sound neat in theory but end up as a leaky abstraction: they mix UI details with test logic, duplicate flows, and make even trivial UI changes ripple through dozens of files. What I’ve seen is indirection that hides test intent and bloats maintenance.

I also find them very developer-centric — testers get forced into upfront design work that doesn’t fit how they naturally test, and many struggle with it. I’ve had better results by expressing behavior directly and keeping UI concerns thin, instead of using a wrapper around page structure.

Part of this is on developers. Refactoring is fine, but too often it turns into yak-shaving and nothing ships. The approach usually works: refactor in small steps and tie it to a feature so it’s testable and adds value.

Does anybody have tips on how to invalidate a wallet address response if it's intercepted and modified like this?

Surprisingly, no. I make a list know the aisles, pick stuff. But it’s not the same case on the web.

I’ve noticed that every time I open a browser to use the web version of an app, I get distracted and end up browsing unrelated stuff.

Switching to a standalone app helps me avoid that — fewer distractions, less wasted time. I’ve tried breaking the habit, but this is one reason I still prefer desktop version of the website.

Used trunk-based dev a lot. Not a fan. It sounds good on paper, but in practice, it gets messy fast and code quality is hard to maintain, especially when teams are remote.

What actually works is trunk-based deployments — keep main always deployable, and ship from there. Simple.

PRs, are underrated. They’re great for sharing context. You get inline comments, CI runs, you can test stuff in isolation by spinning up infra, and teammates actually see what’s changing.

Stacked diffs make juggling multiple PRs manageable. And yeah, PR reviews can slow you down, but honestly, I think that's a plus. Slowing down just enough to have another human look at the code pays off more often than not.

One thing I really appreciated during the peak years of working with XSLT was how much I learned about XPath. Once it clicks, it’s surprisingly intuitive and powerful. I don’t use XSLT much these days, but I still find myself using XPath occasionally. It’s one of those tools—once you understand it, it sticks with you.

Love this app, saw a guide using this app on an early morning birdsong walk—gave it a try and it's really good. Very accurate and super easy to use.

I think a lot of serious bird enthusiasts use this in the UK.

sure https://gauge.org and https://taiko.dev

I’ve had some moderate success with a couple of open-source projects, and I get where you’re coming from. Promotion is hard work, especially if you’re used to just building.

Here’s what worked for me:

Start with a solid project page – Focus on making your plugin polished easy to install and use via a project page. Good docs and instructions also drives search to your plugin organically.

Create useful content – Blog posts, guides, or even short articles that explain how and why you built the plugin something like behind the scenes. People read this stuff.

Use GitHub topics – Tag your repo well. People browse topics and trending pages. This is actually how one of our projects started getting noticed.

Submit to awesome lists – there are “awesome” lists related to IntelliJ plugins Java dev tools, AI tools send a PR to add your project. It’s a great way to get visibility among the right audience.

Be genuinely helpful in your niche – If your plugin helps with a common pain (e.g. repetitive Java boilerplate), hang out in relevant forums or threads (like here, Reddit, etc.). When you help someone, they’ll often check out your work.

See how it all goes and know when to move on, Good luck with your plugin.

I didn't "get it" the first go round.

Same here—I missed it the first time around and found it pretty weird when I finally watched it.

But on a recent trip to the Lake District, we ended up visiting a bunch of the filming spots, including the infamous telephone box in Bampton (still around and in good condition).

That kind of changed how I saw the movie—it started to feel more like a bunch of odd little vignettes, each with its own strange charm. My partner and her family are big fans and talk about it all the time, so it’s slowly grown on me. Definitely not a “one sitting” kind of film.

You’ll find people in every hobby who are more into the gear than the actual activity

Honestly, that’s part of the fun for some of us, even early on. I’ve been playing guitar for a while now, and while I enjoy it, the repetitive nature can sometimes get dull. Exploring new gear and chasing different tones has been my way of breaking through those ruts.

Yes, it’s expensive and it eats into practice time — no doubt. But some of us are just wired to enjoy the experimentation. I eventually found a setup I really like, but I don’t regret going through the gear phase. It kept things exciting and helped me stay connected to the hobby.

Like others mentioned, this is mostly an ethnic Kazakh tradition, not something specific to Kyrgyzstan. I visited the eagle festival in Ölgii (Mongolia) a year ago, a teenage girl won. They represent their village. There were a lot of participants, and the event ran long. It’s clearly grown in popularity, especially thanks to tourism, and doesn’t seem like a fading tradition anymore.

Yeah, I’ve spent some time building IntelliJ plugins, and honestly, the authoring experience has some real limitations. It’s not the easiest platform to work with, especially when it comes to writing automated tests. That might be part of the reason why their or any third-party AI plugins don’t feel as smooth as the ones on VS Code.

Bangalore

I recently moved to London(been a few years) and love the city, but the cost of living is extremely high—whether it’s dining out, attending concerts, going to the theatre, or especially paying rent.

A large portion of my salary goes toward rent and utilities. Fortunately, I work in tech, but I often wonder how others even manage.

Workplace conversations revolve around how expensive everything is and sharing tips on saving money. It’s definitely a source of anxiety.

The network effect is strong, but it’s not unbeatable.

History has shown that new social platforms can thrive despite the “everyone is already there” argument—Facebook vs MySpace, Insta, TikTok et al.

I can’t predict how openspot will turn out, but I hope it or anything else doesn’t get caught up in the network effect narrative.

I enjoy the taste of hops and personally, I find zero version better than their alcoholic counterparts, not sure everyone else feels like that.

I wonder why it took the market so long to boom in this segment. Nice to see other recommendations.

I visit Knepp a few times a year. There’s a great circular loop you can walk, and I’ve seen plenty of trees with stork nests—an amazing sight to see firsthand.

We do this. We deploy on commit to main and use the commit SHA for versioning. So squash merges makes it easier to know which commit caused a bug or bisect. This work well for our PR based workflows. If required the PR can be used as reference for un-squashed commits.

Because coding assistants depend on the baselined code they are trained on for their suggestions?

I don't believe they offer creative solutions, just a faster way to refer. So it's still the responsibility of developers bring their creativity to the process.

Never seen a broken website on safari. Like others mentioned anything specific?