DEV Community: Kudzai Murimi

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 760 | 🎱 Badges: 5 | 👥 Followers: 3 | 📄 Posts: 2 Latest post: "New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up" Read it here: https://coderlegion.com/28183/new-to-bit

Kudzai Murimi — Tue, 22 Sep 2026 15:41:20 +0000

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up - Coder Legion

# New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up If you've never used CodePush before, the idea sounds almost too convenient. You find a bug in a React Native app, fix the JavaScript, and instead of waiting for another App...

coderlegion.com

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

Kudzai Murimi — Tue, 22 Sep 2026 15:19:58 +0000

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

If you've never used CodePush before, the idea sounds almost too convenient.

You find a bug in a React Native app, fix the JavaScript, and instead of waiting for another App Store or Google Play release, you can push the update directly to users.

That's the part that got my attention.

But once I actually started setting it up, I realized there are quite a few things that aren't obvious from that one-line explanation.

So if you're new to Bitrise CodePush, here's what I learned while going through the setup.

First: What Does CodePush Actually Update?

The easiest way to think about CodePush is:

It updates the JavaScript and assets in your React Native app without requiring a new store release.

So if you've fixed:

A JavaScript bug
Some text or copy
A small UI issue
Another change that doesn't require native code

You can potentially deliver that fix without submitting a new binary to the App Store or Google Play.

But there's an important boundary.

If you change native code, CodePush doesn't magically bypass the app stores.

You'll still need a normal app release.

That's probably the first thing I'd make sure the team understands before using it.

What Bitrise Actually Gives You

There are two main parts to the setup.

1. CodePush inside Bitrise Release Management

This is where you manage deployments, upload releases, and control things like rollout percentages.

2. The SDK inside your application

@bitrise/code-push-sdk

The SDK is responsible for checking whether an update is available and applying it.

So the basic idea is:

Bitrise handles the release side → your app handles the update side.

Once I understood that split, the rest of the setup made a lot more sense.

Before You Touch the Code

You'll need a Bitrise account and a Release Management app.

One thing that caught my attention here is that Release Management and your normal Bitrise CI app aren't necessarily the same thing.

If you're already using Bitrise CI to build your React Native app, Release Management is something you add alongside it.

And if you're releasing for both iOS and Android, you'll need to account for both platforms in your setup.

I'd recommend getting the basic Release Management setup working before touching the React Native project.

It makes troubleshooting much easier.

Step 1: Create a Deployment

Inside the Release Management app, go to:

Configuration → Deployments → New deployment

For a real project, I'd probably start with:

Staging
Production

That separation is useful.

You don't want to be testing an update and accidentally send it to everyone using the production app.

You can either provide an existing deployment key or let Bitrise generate one.

One thing about deployment keys

This initially confused me.

The deployment key looks like something you'd normally hide in a secret.

But it isn't really a password.

The key eventually gets included in the application, which means someone with access to the built app could potentially extract it.

It's better to think of it as an identifier for the deployment rather than a secret credential.

Your API token is the thing you actually need to protect.

Step 2: Install the SDK

The first command is simple:

npm install @bitrise/code-push-sdk

After that, things depend on how your React Native app was created.

And this is one place where I wouldn't recommend blindly copying configuration from a random tutorial.

Expo and bare React Native aren't configured in exactly the same way.

If You're Using Expo

With Expo, you add the CodePush plugin to your app.json.

You'll need your deployment key and the CodePush server URL.

The URL follows this pattern:

https://.codepush.bitrise.io

Then run:

npx expo prebuild

I like doing this step because it lets you check whether the configuration actually made its way into the generated native project.

If You're Using Bare React Native

This takes a little more work.

On iOS, you'll need to make a change in AppDelegate.swift so CodePush can resolve the active release bundle instead of always using the default bundled JavaScript.

You'll also configure the deployment key and server URL in Info.plist.

On Android, the configuration goes into strings.xml, along with some Gradle configuration and a change to how MainApplication.kt resolves the JavaScript bundle.

None of these changes are particularly complicated.

They're just easy places to make a small mistake.

That's why I found it better to follow the Bitrise documentation closely rather than trying to recreate the setup from memory.

Step 3: Think About the User Experience

This was probably the part I didn't think about enough at first.

It's easy to look at CodePush as:

"There's an update, download it."

But you actually have choices about how that update reaches the user.

For example, with:

codePush.sync()

you can use different behaviours.

Silent update

The update downloads in the background and is applied when the app restarts.

For the user, the whole thing can be almost invisible.

Update when the app resumes

Instead of checking only when the app starts, the app can check when it comes back into the foreground.

Interactive update

The user gets feedback that an update is available and can be shown the download process.

For mandatory updates, you can also prevent the user from simply dismissing them.

You can even use progress callbacks if you want to show download progress.

I think this is worth deciding before you ship your first update.

The technically easiest option isn't necessarily the best experience for your users.

Step 4: Build and Release

Once the application is configured, you need to create the JavaScript bundle.

For a bare React Native project:

npx react-native bundle \
--platform ios \
--dev false \
--entry-file index.js \
--bundle-output ./build/main.jsbundle \
--assets-dest ./build

For Expo:

expo export:embed

You then package the generated files and upload them to Release Management.

You can do this manually from the dashboard, which is probably the easiest way to test your first release.

Once you've confirmed everything works, that's when I'd start thinking about automation.

Don't Immediately Send It to Everyone

This is one feature I'd definitely use in production.

When you create the release, you can control the rollout.

You can target specific app versions and use version ranges such as:

1.2.x

or:

=1.2.3 <1.2.7

You can also mark an update as mandatory and control the percentage of users who receive it.

That last part is important.

Imagine you've made a JavaScript change that you think is completely safe.

Instead of immediately sending it to 100% of your users, you can start with a smaller percentage.

If everything looks good, increase the rollout.

That gives you a little more room to catch problems before they become everyone's problem.

What About Automation?

Once you've manually released a couple of updates, you'll probably notice the repetitive part:

Build the bundle.
Zip it.
Upload it.
Do it again for the other platform.

It works.

But I wouldn't want to do that every week.

That's where Bitrise CI comes in.

You can automate the build and upload process so that a workflow handles it for you.

One approach I like is connecting the release to an approved and labelled pull request rather than automatically releasing every merge.

That gives you a deliberate point where someone says:

"This is ready to ship."

The CI system then takes care of the repetitive work.

I wrote separately about that automation process because there are a few more details around credentials, versioning, and workflow configuration.

My Checklist Before the First Release

If I were setting this up on another project, this is the checklist I'd keep nearby:

Bitrise Release Management is configured

iOS and Android are accounted for

Staging and Production deployments are created

@bitrise/code-push-sdk is installed

Expo or native React Native configuration is complete

The app can successfully check for updates

The sync behaviour has been chosen

The first release is tested with a small rollout

Production releases have an automation plan

So, Is CodePush Worth It?

I think it makes the most sense when you regularly have small JavaScript-level fixes that don't justify going through another full app-store release.

It's not a replacement for your normal mobile release pipeline.

Native changes still need a normal build and store submission.

But if your team has ever had to submit a new mobile build because of something that could have been fixed entirely in JavaScript, that's the gap CodePush is trying to close.

For me, the biggest takeaway wasn't just:

"I can push an update without the App Store."

It was realizing that there are several decisions around how that update gets delivered, who receives it, and what the user experiences when it arrives.

That's the part I'd pay attention to before putting CodePush into a production app.

Have You Used CodePush?

Have you used CodePush or another OTA update solution with React Native?

I'd love to hear how you handled it, especially if you ran into problems during setup.

What would you add to this checklist?

What Can You Bring to the Table? 👨🏾‍💻

Kudzai Murimi — Sun, 13 Sep 2026 16:27:24 +0000

Okay, quick thought experiment before we get into it.

Someone hires you tomorrow. Not "in theory", like, you start Monday. What do you actually bring with you?

Not your job title. Not the framework list sitting in your LinkedIn headline. I mean the real stuff, the thing a team gets when they get you.

I've been chewing on this question for a while now, so let's talk it through.

Okay but why does this even matter?

Here's the thing, anyone can slap "React, Node.js, PostgreSQL" on a CV. That's the easy part. It tells someone what you've touched, but it says nothing about how you think, what you notice first when something's broken, or what kind of problems actually get you excited to open your laptop.

The much more interesting question is quieter than a skills list: what do people come to you for?

Are you the one who gets handed the tangled legacy codebase nobody else wants to touch? The person who writes the docs nobody asked for, and then three weeks later it turns out that doc saved the whole team a day of confusion? The one who can take "make it feel more premium" from a client and actually turn that into a real list of changes?

None of that fits neatly into a skills matrix. But honestly? It's usually the real reason someone wants you on their team.

Alright, here's my honest answer

I'm not going to ask this and then dodge it myself, so here goes — this is what I'd bring:

⚛️ Frontend development: React, Angular, TypeScript, modern JS. Not just turning a design into pixels, but actually thinking about state, performance, and what happens the moment the data doesn't behave like the happy path did in the demo.
🐘 Backend development: PHP and Laravel. The logic and data layer the frontend is quietly leaning on the whole time.
🔌 API development & integration: building REST APIs, and just as often, wrestling a third-party API into behaving the way its docs promised (it never quite does, does it?).
🌐 WordPress development: custom sites, plugins, e-commerce builds. Not glamorous, but a huge chunk of the actual web runs on this, and doing it well is a real skill, not a fallback.
🧩 Problem solving: taking a vague ask or a half-formed idea and turning it into something that actually works. Honestly, this might just be the whole job.
⚡ Performance optimisation: caring not just about "does it work" but "does it feel good to use."
🧪 Testing: writing frontend tests people actually keep maintaining, instead of ones written once to hit a coverage number and never touched again.
📝 Technical writing: tutorials and docs that developers actually want to read. Explaining something clearly is quietly one of the most valuable things you can do for a team.
🤖 AI-assisted development: using tools like Claude, ChatGPT, and Codex to research, build, debug, and review faster. Not a replacement for understanding the code, but a real boost on top of it.
🤝 Collaboration: working well with other devs, product folks, and clients to actually ship the thing, not just produce code in a vacuum.

And honestly, the biggest one: I'm still learning

None of the above means I've got it all figured out, far from it. The longer I do this, the more I realize how much I still don't know. And weirdly, that's one of my favorite parts of this whole field. There's always someone out there who's already solved the exact thing you're stuck on, in a way you never would've thought of.

That's really what this post is about.

Okay, your turn 👇

If you got hired tomorrow, what would you bring?

Not your job title. Not the tech list on your CV. The real stuff.

What are you actually good at?
What kind of problems do you enjoy untangling?
What's something you've learned that might genuinely help someone else on a team?

Drop it in the comments. And hey, if you're comfortable, throw your profile link in there too, maybe someone reading this is looking for exactly what you do. Maybe we end up collaborating, or trading advice, or just having a good conversation.

Let's make the comments an actual place to connect, not just a list of stacks. 🚀

GitHub Copilot vs Cursor vs Claude Code

Kudzai Murimi — Fri, 04 Sep 2026 19:06:00 +0000

These three get lumped together as "AI coding tools," but they're solving genuinely different problems in your workflow, inline completion, full-editor AI integration, and autonomous multi-file agentic work. Here's how they actually differ, and which combination makes sense depending on what you're building.

GitHub Copilot: the widest net

Copilot's real advantage isn't raw capability, it's reach. Native support across VS Code, JetBrains, Neovim, Visual Studio, and Xcode makes it the easiest entry point regardless of what editor your team already uses, and it holds the largest market share of any tool in this category. The free tier (around 2,000 completions a month) makes it close to a no-brainer starting point, especially for teams already living inside the GitHub ecosystem for issues, PRs, and CI.

Where it's the clear pick: you want inline, low-friction autocomplete everywhere you already work, without changing editors or workflow.

Cursor: AI woven into the entire editor, not just autocomplete

Cursor is a fork of VS Code with AI integrated at every layer, not bolted on as a plugin. Its Composer interface handles complex multi-file refactors directly inside the editor, and it's become the most commercially successful tool in this category by a wide margin, reportedly over a million users and reviewers reporting meaningfully fewer PR review comments after adopting it. For developers who live in their editor all day, having AI that understands the whole open project (not just the current file) is a genuinely different experience from inline suggestions.

Where it's the clear pick: you want AI-assisted editing as your default way of working, not an occasional autocomplete assist.

Claude Code: the one for autonomous, repo-wide work

Claude Code operates more like an agent than an editor plugin, it reads files, runs commands, manages git, executes tests, and edits across multiple files in your actual local environment, currently leading autonomous coding benchmarks (around 80% on SWE-bench Verified). This is the tool for handing off a genuinely complex, multi-step task and getting back a coherent, well-reasoned result, not for inline suggestions while you type.

Where it's the clear pick: large refactors, unfamiliar codebases you need to understand quickly, or any task better described as "do this whole thing" rather than "suggest the next few lines."

What most working developers actually do

The realistic setup isn't picking one, it's layering them by task size. A common, cost-effective combination is Copilot for everyday autocomplete plus Claude Code for the occasional complex refactor or architecture task. A more editor-centric setup swaps in Cursor as the daily driver, with Claude Code still handling anything that spans the whole codebase.

How to actually choose

Don't start from "which is best", start from where your current friction actually is. If you're constantly context-switching between editors, Copilot's reach solves that. If your bottleneck is slow, disjointed multi-file edits, Cursor's integrated approach solves that. If you're regularly facing tasks too large or unfamiliar to comfortably do by hand, Claude Code's autonomous, repo-aware approach is the one built for exactly that job.

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It

Kudzai Murimi — Tue, 25 Aug 2026 06:18:03 +0000

Most CV advice picks one side. Either you optimize for the applicant tracking system. Or you write for a human. You need both. A bot filters your CV first. A human decides later whether to call you.

What the ATS Actually Does

It is not smart AI. It mostly parses your document into fields. Name. Contact info. Work history. Skills. Then it matches keywords against the job description. Here is what that means for you.

Use standard section headers. Call them "Professional Experience" and "Education" and "Skills." Do not get creative with names like "My Journey." That can break the parser.

Avoid tables. Avoid text boxes. Avoid multi column layouts. Many parsers read left to right and top to bottom. A two column layout can scramble your work history into nonsense.

Match the language in the job posting. Do not just use your own words. If they say "Node.js" and you wrote "backend JavaScript," you might not match. Even if you clearly qualify.

Save your CV as a .docx file or a text based PDF. Do not use an image based or heavily designed PDF. If you cannot select and copy the text yourself, the parser probably cannot either.

What Makes a Human Want to Talk to You

Once you pass the filter, the CV has a new job. It needs to convince a person you are worth thirty minutes of their day.

Quantify your impact when you can. "Reduced page load time by 40 percent" beats "improved performance." No number to use? Describe the before and after instead.

Start each bullet with what changed. Not what you were assigned. "Migrated the checkout flow to a queued job to eliminate timeout errors" tells a real story. "Responsible for checkout flow" does not.

Cut anything you cannot back up. Skip vague lines like "great communicator" or "team player." Show it instead. Let your accomplishments prove it.

Keep the length matched to your experience. Early career means one page. Deep into your career means two pages. Keep it tight. Do not write a full chronological diary.

The Trap

Do not over optimize for one reader at the other's expense. A CV stuffed with keywords reads like noise to a human. A CV written only for flow can get filtered before anyone sees it. The fix is not a trick. Write the true version of your experience. Use the words the industry uses. Use the words this job posting uses.

Do This Before Every Application

Read the job posting slowly. Underline the specific technologies and responsibilities they name. Then check your CV against that list. Do not fabricate experience you don't have. Just make sure your real experience uses their words, not only your own. This one step fixes more rejections than any template swap.

The Remote Job Search Playbook for Developers Outside the US/EU

Kudzai Murimi — Tue, 25 Aug 2026 06:15:57 +0000

The Remote Job Search Playbook for Developers Outside the US/EU

Remote work opened the door for developers outside major tech hubs to compete for roles that used to be geographically gated. It also created a much bigger applicant pool for every posting. If you're searching from outside the US/EU, here's what actually affects your odds — beyond "just apply to more jobs."

Timezone overlap is a real filter, not a footnote

A lot of "remote, worldwide" postings quietly mean "remote, but we need 4+ hours of overlap with our core team." Before you apply, check what timezone the company or their existing team is in. If you can genuinely offer a workable overlap, say so explicitly in your application — don't make a recruiter guess whether a 7-9 hour time difference is going to be a problem later.

Sourcing channels that actually produce interviews

Recruiting-as-a-service platforms (Rightfit-style agencies, Toptal, Turing) — they pre-filter for companies actively hiring remote and internationally, which saves you from applying into a black hole on a generic job board.
Company engineering blogs and changelogs — companies that write publicly about their engineering tend to also be more remote-mature and less nervous about hiring outside their home country.
Referrals inside communities you're already part of — dev.to, Discord servers for your stack, open-source project maintainers. A referral skips the "will this person actually work out remotely" anxiety that a cold application can't answer.
Direct outreach to smaller, funded startups — they often can't afford local senior talent and are more open to global hiring than enterprise companies with rigid HR policy.

What to lead with in your application

Recruiters hiring internationally are quietly screening for risk: will this person disappear, will communication be a problem, will payment/compliance be a headache. Address these before they have to ask:

State your availability and overlap hours plainly.
Link to async-friendly proof of work — a deployed project, a GitHub history with real commit activity, a technical article. This substitutes for the "vibe check" an in-person interview would normally give them.
If you've done contract/freelance work with international clients already, say so explicitly — it signals you already know how to work across time zones and payment rails.

The payment/compliance reality

Get familiar with how you'll actually get paid before it becomes a blocker mid-negotiation — platforms like Deel, Payoneer, or Wise exist specifically because cross-border payroll is messy. Knowing your own answer to "how do you want to be paid" makes you look more prepared, not more high-maintenance.

Compensation framing

Salary ranges posted for a specific country's cost of living don't always translate cleanly, and currency conversion can make a number look smaller or larger than it actually is locally. Do the math in your own currency and cost of living before deciding a range is or isn't worth pursuing — a number that looks modest in USD can be very solid depending on where you live, and vice versa.

The uncomfortable truth

You are competing against a genuinely global pool now, which means portfolio and communication quality matter more than they used to, because there's no in-person interview softening a rough resume. The upside is that a strong deployed project and a clear, well-written application travel just as far as being physically local ever did — this is the first time in tech history where that's fully true.

Breaking Into Full-Stack Development Without a CS Degree: What Actually Worked for Me

Kudzai Murimi — Tue, 25 Aug 2026 06:14:22 +0000

Breaking Into Full Stack Development Without a CS Degree: What Actually Worked for Me

I didn't go through a computer science program. What I have instead is about seven years of shipping production code. I learned almost all of it from official documentation, open source repos, developer communities, and a lot of trial and error on real client work. If you're on that same path and wondering if it's enough, here's what actually moved the needle for me. And what turned out to be a waste of time.

What Worked

Building things that had to work, not things that looked good on a syllabus. Tutorial projects teach syntax. Client work teaches you what happens when a payment webhook fires twice. Or when your "simple" CRUD app suddenly needs to survive ten times the traffic you designed for. The fastest learning happened on real, slightly terrifying production systems. Not curated coursework.

Reading source code and official docs before reaching for a course. Anyone can follow a video tutorial. Fewer people will sit with Laravel's own documentation. Or actually read through a library's source when the docs run out. That habit compounds. You stop depending on someone else pre chewing the material for you. And you get faster at picking up whatever stack a client happens to be using.

Writing about what I learned. Technical writing forced me to actually understand things well enough to explain them. Not just well enough to copy paste them into working code. If you can't write a clear paragraph about why you chose NgRx over plain component state, you probably don't understand it as well as you think.

Taking freelance and agency work early, even underpriced. Nobody hands a self taught developer a senior role on day one. What they will do is pay you to fix their bug. Or build their MVP. Or maintain their legacy app. That's your CS degree. It's just spread across a dozen small, real engagements instead of four years in one building.

What Didn't Work

Collecting certificates. They're fine as a signal that you sat through material. But nobody has ever hired me because of a certificate. Every real opportunity came from a portfolio piece, a referral, or a conversation where I could clearly explain a decision I made on a past project.

Waiting to feel ready. I never felt ready. The gap between self taught and professional isn't a knowledge threshold you cross. It's a body of shipped work you accumulate. Start billable work earlier than feels comfortable.

Studying algorithms in isolation, disconnected from anything I was building. Data structures and algorithms matter. But grinding them with no applied context is one of the slowest ways to learn them. They stuck a lot better once I hit an actual performance problem that a better data structure solved.

The Real Difference Maker

Nobody on a hiring panel has ever asked me where I studied. They've asked me to walk through a decision on a real project. Why Laravel over a plain PHP framework. Why I chose to denormalize a specific table. How I debugged a flaky third party API integration. A CS degree can hand you vocabulary for those conversations. Shipped, explainable work hands you the actual substance.

If you're self taught and stuck comparing yourself to a traditional path, stop comparing credentials. Start counting shipped, working systems you can talk through in detail. That's the real currency in this field.

Using AI in Your Job Search: What Actually Helps vs What Looks Lazy to Recruiters

Kudzai Murimi — Tue, 25 Aug 2026 06:12:49 +0000

Almost everyone uses AI in their job search now. Whether they admit it or not. The real gap is not between people who use AI and people who don't. It is between people who use it to sharpen their real experience, and people who let it generate a generic version of them. A recruiter can spot that fake version in the first paragraph.

What Actually Helps

Tailoring your CV language to a specific posting. Feed a job description and your real experience to an AI tool. Ask it to flag mismatched terms. Maybe they say "Node.js" and you wrote "backend JavaScript." This is a fast and useful pass. Just make sure you are only adjusting words for experience you already have. Do not invent experience you don't have.

Rehearsing interview answers out loud. Ask an AI tool to play a skeptical interviewer. Let it push back on your answers. This surfaces the gaps in how you explain your own work. Better to find those gaps now than in front of a real interviewer.

Summarizing and organizing your own scattered notes. Maybe you have a messy pile of past projects and metrics and accomplishments. AI is good at helping you turn that into clear, quantified bullet points. The substance is still yours. It just helps you find the clearest way to say it.

Researching a company or role fast. Get a quick organized summary of a company's product, recent news, and likely tech stack before an interview. This saves real time over digging through their blog and LinkedIn by hand.

What Looks Lazy, and Often Is

Sending an unedited generic AI written cover letter. Recruiters read hundreds of these. A cover letter with no specific detail about the company or the role or your actual experience reads as exactly what it is. Usually within the first two sentences. It signals you didn't care enough to personalize it.

Fabricating experience or skills you don't have. AI will happily write confident sentences about a technology you've never touched. The interview will find that gap fast. It damages trust far more than an honest answer would. Something like "I haven't used that specifically, but here's an adjacent thing I have done."

Using AI generated answers word for word in a live interview. Some candidates try to have AI generate answers in real time during interviews. This is against most companies' policies. It also produces answers that don't sound like a real person who did the work. Interviewers notice the gap between a polished answer and someone who can't naturally follow up on it.

Mass applying without reading the posting. AI makes it easy to blast out fifty near identical applications an hour. That is not a strategy. That is noise. It usually gets a worse response rate than fewer, genuinely tailored applications. Generic submissions are the easiest ones for a human or an ATS to filter out.

The Actual Line

AI is genuinely useful anywhere it helps you present your real experience more clearly and faster. It becomes a liability the moment it starts generating experience or opinions or answers that aren't actually yours. Interviews are built to find that gap. Finding it costs you a lot more trust than skipping AI ever would.

The best use of these tools in a job search is not writing your story for you. It is helping you tell your own story faster and more clearly than you could alone.

TrendHub: I Was Tired of Checking Six Sites a Day, So I Built One Feed Instead

Kudzai Murimi — Mon, 24 Aug 2026 13:13:23 +0000

Every morning looked the same for me. dev.to, then Hacker News, then Stack Overflow's hot questions, then Product Hunt, then Lobsters, then Mastodon if I had the energy left. Six tabs. Six different ranking systems. Six different "what's hot right now" signals. No way to tell if the same story was blowing up on more than one of them at once.

So I built TrendHub. It is a single unified feed that pulls what's trending across dev.to, Hacker News, Stack Overflow, Product Hunt, Lobsters, and Mastodon. It ranks everything on one comparable scale. I can read it like one site instead of six.

The problem was never that any one platform was bad. The problem is that trend checking had become a tax on my attention. This is my attempt to get that time back. And to make it something other developers could use too.

What TrendHub Actually Does

At its core, TrendHub is a fetch and rank pipeline. Background jobs pull the latest posts from each source on their own schedule. They normalize each post's engagement signal, reactions, points, votes, favourites, whatever that platform measures, onto a common 0 to 100 trending score. Then everything drops into one feed you can scan in a few minutes.

Features

Unified, ranked feed. Every post from every source lands in one timeline. Sorted by a trending score, not by which tab you happened to open first.

Per platform toggles. Don't care about Product Hunt today? Flip it off in the sidebar. Preferences save per user. Your feed stays exactly the way you like it.

Search, tags, and time range filters. Search matches both post titles and tags. You can restrict the feed to the last day, the last week, or all time.

Cross platform duplicate detection. Sometimes the same story trends on both Hacker News and Lobsters at once. It happens more than you'd think. TrendHub tags it "also trending on" instead of showing it to you twice.

Trending velocity, the rising fire icon. Posts don't just get a static score. They get a velocity indicator based on how their score moved since the last fetch. You can spot what's accelerating, not just what's already popular.

Bookmarks and hide or dismiss. Save something to read later. Hide a post you're not interested in. Hidden posts stay hidden until you choose to bring them back.

Daily digest email. Opt in and get a daily rollup of what's trending sent to your inbox. No login required to stay in the loop.

Personal RSS feed export. Every user gets their own token based RSS URL. Your filtered, ranked feed can slot into whatever feed reader you already use.

Keyboard shortcuts. j and k to navigate. o to open. b to bookmark. x to hide. Built for people who'd rather not touch the mouse.

Dark mode. Because it's a developer tool. Developer tools ship in dark mode.

Per post share menu. Share to X, Facebook, LinkedIn, Reddit, WhatsApp, email, or just copy the link. Straight from the feed.

Source health panel. A small sidebar panel shows the last fetch time and status per platform. You always know how fresh the data is. And if a source's API is having a bad day.

Under the Hood

TrendHub is built on Laravel 10, Inertia.js, Vue 3, and Tailwind CSS. Postgres runs in production. SQLite runs for local development. Each source has its own dedicated fetcher class. A scoring service normalizes engagement metrics across wildly different scales. A Hacker News point is not a Mastodon favourite. A grouping service handles the cross platform duplicate matching.

It's deployed on Render, running as a single web service with a managed Postgres database.

Try It

Live: trend-hub-204c.onrender.com

It runs on a free tier. If it's been quiet for a while, the first load might take 30 to 50 seconds to wake back up. That's not a bug. Just a cold start. Register an account. It's instant, no email verification loop. Toggle platforms on and off to make it yours.

What's the trend checking equivalent of "context switching fatigue" in your own workflow? Do you have a tool for it, or are you still juggling tabs like I was? I'd love to hear what I'm missing.

RTK Query Made Easy for Beginners 🎓 (With Real-Life Analogies)

Kudzai Murimi — Sun, 12 Jul 2026 12:09:21 +0000

If you've ever felt intimidated by Redux Toolkit Query (RTK Query), you're not alone. The docs https://redux-toolkit.js.org/tutorials/rtk-query assume you already know what a "reducer" or "middleware" is — but what if you're brand new to this?

This article explains RTK Query using everyday analogies, so by the end you'll actually understand what's happening instead of just copy-pasting code.

Let's build a tiny app that shows a list of students from a server. 🧑‍🎓

The Big Picture

Imagine our school website asks a server:

"Can I have the list of students?"

And the server replies:

[
  { "id": 1, "name": "John" },
  { "id": 2, "name": "Mary" }
]

RTK Query is the tool that handles that entire conversation for you — asking, waiting, and remembering the answer — so you don't have to write fetch() calls by hand.

Step 1: Project Structure

Here's what our project will look like:

src/
    App.jsx
    main.jsx
    store.js
    services/
        studentApi.js

Think of it like a school: the School is your app, the Classroom is your store, and the Students are your data. Everything has its own place.

Step 2: Install Redux Toolkit

npm install @reduxjs/toolkit react-redux

This gives you RTK Query for free — it's built right into @reduxjs/toolkit.

Step 3: Create the API Service

Create src/services/studentApi.js:

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const studentApi = createApi({
  reducerPath: "studentApi",

  baseQuery: fetchBaseQuery({
    baseUrl: "https://jsonplaceholder.typicode.com/",
  }),

  endpoints: (builder) => ({
    getStudents: builder.query({
      query: () => "users",
    }),
  }),
});

export const { useGetStudentsQuery } = studentApi;

Let's break down every part of this, piece by piece.

`createApi` and `fetchBaseQuery`

Think of building a toy car — first you need your tools: a hammer, a screwdriver, a spanner. createApi and fetchBaseQuery are your tools for building an API layer.

`reducerPath`

Think of a cupboard with labelled shelves — one for books, one for toys, one for shoes. reducerPath: "studentApi" tells Redux: store all the student information on the "studentApi" shelf.

`baseQuery`

Imagine your friend lives at 12 Green Street. Every time you visit, you start from that same address. baseQuery works the same way — it's the address every request starts from:

https://jsonplaceholder.typicode.com/

`endpoints`

Think of a restaurant menu: Pizza, Burger, Chicken, Juice — each dish is a menu item. In our app, each endpoint is one thing we can ask the server for: Get Students, Get Teachers, Delete Student, and so on.

`builder.query()`

This means "I only want to READ." It's like asking your teacher, "Can I see today's attendance list?" — you're not changing anything, just looking.

`query: () => "users"`

This tells RTK Query which path to visit. It joins the base URL and this path together:

https://jsonplaceholder.typicode.com/  +  users
=  https://jsonplaceholder.typicode.com/users

That's the actual address it fetches.

Step 4: Add the API to Your Store

Create store.js:

import { configureStore } from "@reduxjs/toolkit";
import { studentApi } from "./services/studentApi";

export const store = configureStore({
  reducer: {
    [studentApi.reducerPath]: studentApi.reducer,
  },

  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(studentApi.middleware),
});

Imagine your teacher asks, "Where should I keep the student register?" You say, "Put it in this cupboard." That's the reducer — it decides where the data lives.

Now imagine a school messenger: the teacher says, "Take this letter to Class 4," and the messenger delivers it. That messenger is the middleware — it carries requests to the server and brings the response back.

Step 5: Wrap Your App with Provider

import { Provider } from "react-redux";
import { store } from "./store";

<Provider store={store}>
  <App />
</Provider>;

Think of electricity. Without it, your TV, fridge, and computer don't work. Provider supplies the Redux store to your entire app — without it, nothing connects.

Step 6: Use the Hook

Inside App.jsx:

import { useGetStudentsQuery } from "./services/studentApi";

function App() {
  const { data, isLoading, error } = useGetStudentsQuery();

  console.log(data);

  return <div>Hello</div>;
}

The moment useGetStudentsQuery() runs, RTK Query automatically says "Hello server, can I have the students?" — no fetch(), no axios(). It's all handled for you.

Step 7: Understanding `data`

Imagine asking your mom, "Can I have some apples?" and she hands you a bag of 🍎🍎🍎. That bag is your data.

For our app, console.log(data) might print:

[
  { "id": 1, "name": "Leanne Graham" },
  { "id": 2, "name": "Ervin Howell" }
]

Step 8: Understanding `isLoading`

Imagine ordering pizza. Before it arrives, you're waiting — that's isLoading. While it's on the way, isLoading is true. The moment it arrives, isLoading becomes false.

Step 9: Showing a Loading State

if (isLoading) {
  return <h1>Loading...</h1>;
}

Users see "Loading..." until the server responds.

Step 10: Understanding `error`

If the internet drops or the server fails to respond, error will contain details about what went wrong:

if (error) {
  return <h1>Something went wrong.</h1>;
}

Step 11: Rendering the Students

return (
  <div>
    {data.map((student) => (
      <h2 key={student.id}>{student.name}</h2>
    ))}
  </div>
);

If the server returns John and Mary, the screen shows:

John
Mary

What's Actually Happening Behind the Scenes?

👦 React: I need students.
      ↓
📞 RTK Query: I'll ask the server.
      ↓
🌐 Server: Here are the students.
      ↓
📦 RTK Query: I'll save them.
      ↓
👦 React: Thank you! I'll show them.

You never wrote fetch(). You never managed a loading flag by hand. You never stored the response yourself. RTK Query handled all of it.

One More Superpower: Caching

Imagine your teacher asks, "What's 2 + 2?" You answer "4." A minute later she asks again — you already know the answer, so you don't need to think about it again.

RTK Query behaves the same way:

First time:

React → Server → Data → Saved in cache

Second time:

React → Cache ✅ (no new server request)

This makes your app noticeably faster and cuts down on unnecessary network traffic.

Wrapping Up

That's the entire mental model of RTK Query:

Define your API with createApi
Register it in your store (reducer + middleware)
Provide the store to your app
Consume it with an auto-generated hook
Let it cache so repeat requests are instant

Once this clicks, learning mutations (adding, updating, deleting data) is easy — they follow the exact same pattern, just with builder.mutation() instead of builder.query().

Happy coding! 🚀

REST vs GraphQL vs tRPC in 2026

Kudzai Murimi — Wed, 17 Jun 2026 20:24:20 +0000

Every new project. Same argument.

"Let's use REST, everyone knows REST."
"Actually, GraphQL would be cleaner here."
"Have you looked at tRPC? It's basically magic if you're on TypeScript."

This debate has been happening in Slack channels and architecture meetings for years. In 2026, we finally have enough real-world data to end it.

Spoiler: there's no winner. But there is a right answer for your project — and it takes about 60 seconds to figure out.

The 30-Second Summary

	REST	GraphQL	tRPC
Best for	Public APIs	Complex data, many clients	TypeScript full-stack
Learning curve	Low	High	Medium
Type safety	Manual	Generated	Built-in
CDN caching	✅ Excellent	❌ Painful	✅ Good
Non-TS support	✅ Any language	✅ Any language	❌ TypeScript only
Hidden cost	Versioning debt	Query complexity tooling	TS monorepo required

REST: Old But Not Dead

REST still powers over 80% of public APIs and that's not changing anytime soon. Here's why it's still the default for most teams:

Every language has an HTTP client. Your Python service, your mobile app, your third-party partner — they all speak REST without any special setup.
CDN caching works out of the box. GET /products/123 can be cached at the edge. That's free performance most teams leave on the table with other approaches.
It's debuggable in a browser tab. That matters more than people admit.

The real cost no one talks about: versioning. Every breaking change means a new endpoint, a deprecation timeline, and years of maintaining /v1 alongside /v2. REST's hidden cost is API versioning maintenance — and it compounds over time.

Use REST when: you're building a public API, third-party integrations, webhooks, or anything consumed by clients you don't control.

GraphQL: Powerful, But You're Going to Pay For It

GraphQL solves a real problem. When your frontend needs exactly 7 fields from a user object, 3 fields from their orders, and 2 fields from their subscription — REST makes you do 3 round trips or build a bespoke endpoint. GraphQL lets the client ask for exactly what it needs in one request.

GraphQL achieves 28% lower latency for complex queries that would otherwise require multiple REST calls. For mobile apps and data-heavy dashboards, that's meaningful.

But here's what the tutorials leave out: at scale, GraphQL requires query complexity analysis, persisted queries, depth limiting, and specialized monitoring tools — an infrastructure tax that's real and often overlooked.

GraphQL adoption has surged 340% since 2023, yet 93% of development teams still rely on REST. The growth is real. So is the operational overhead.

Use GraphQL when: you have a complex data graph, multiple client types (web, mobile, third-party) with very different data needs, and a team willing to invest in the tooling.

tRPC: The Quiet Game-Changer For TypeScript Teams

tRPC is the youngest of the three and the least understood outside TypeScript circles. Here's the pitch: you define your API procedures on the server, and the client calls them with full type inference — no schemas, no code generation, no extra build steps.

tRPC appears in 15% of full-stack job listings and climbing fast, almost exclusively in listings that also mention TypeScript and Next.js. That's a telling pattern.

The developer experience is genuinely different. Rename a server function and your IDE instantly tells you every place the client calls it. Change a return type and TypeScript catches every consumer that breaks. No GraphQL complexity, no OpenAPI code generation — just pure TypeScript type inference.

The hard limit: tRPC only works when client and server share a TypeScript codebase. The moment you need a mobile app, a third-party integration, or a Python service calling your API — you need REST or a separate layer.

Use tRPC when: your entire stack is TypeScript, you're in a monorepo, and all your clients are your own frontend.

The Real Answer: Most Production Apps Use All Three

Here's the truth nobody puts in their REST vs GraphQL blog posts: most production systems use more than one.

The typical 2026 SaaS stack looks like this:

Public API (for partners, webhooks, SDKs) → REST
Your own frontend (Next.js, React) → tRPC or GraphQL
Service-to-service (internal microservices) → REST or gRPC

This isn't over-engineering. It's matching the right tool to the right consumer.

The 60-Second Decision Framework

Answer these three questions:

1. Who consumes this API?

External developers or partners → REST
Only your own TypeScript frontend → tRPC
Multiple client types with wildly different data needs → GraphQL

2. Do you control all the clients?

Yes, and they're all TypeScript → tRPC
No → REST or GraphQL

3. How complex is your data?

Simple CRUD → REST or tRPC
Deeply relational, clients need flexible queries → GraphQL

Stop picking based on what's trending. Pick based on who's consuming your API and what they actually need.

The teams that ship fast in 2026 aren't the ones who picked the right framework. They're the ones who stopped arguing about it.

Which are you currently using — and would you pick the same if you started over today? Drop it in the comments.

# 10 VS Code Extensions Every Developer Needs in 2026

Kudzai Murimi — Wed, 17 Jun 2026 19:13:52 +0000

Before we start — a warning.

This isn't one of those lists where I throw 25 extension logos at you and call it a day. There are over 50,000 extensions in the VS Code marketplace. Most of them are garbage. Some duplicate features that are already built in. Some haven't been updated since 2021 and are silently slowing your editor down right now.

This list is 10. Intentionally. Because a bloated extension setup is its own kind of technical debt.

Let's get into it — opinions included.

1. ESLint — Non-Negotiable

The take: If you're writing JavaScript or TypeScript without ESLint running in your editor, you're just sending bugs to code review instead of catching them yourself.

ESLint enforces your project's coding rules in real-time, flags problems as you type, and saves your team hours of review comments on things a machine should be catching. It's been around forever and it's still irreplaceable.

Unpopular opinion: Most developers have ESLint installed but misconfigured. Default rules are nearly useless. The value comes from setting up rules that match your actual project. If you haven't touched your .eslintrc in six months, you're not really using ESLint.

2. Prettier — Just Let It Format Your Code

The take: Code formatting debates are a waste of everyone's time. Tabs vs spaces, semicolons or not, single quotes or double — none of it matters as long as the whole team is consistent. Prettier enforces consistency automatically on save. End of discussion.

Unpopular opinion: If your team is still arguing about formatting in 2026, that's a culture problem, not a tooling problem. Install Prettier, set "editor.formatOnSave": true, and move on to actual work.

3. GitLens — Git Blame That Doesn't Make You Leave the Editor

The take: GitLens is the most downloaded Git extension for VS Code for a reason. Inline blame annotations showing who changed each line and when, interactive commit graphs, file history — all without leaving your editor. The free tier covers everything most developers will ever need.

Unpopular opinion: If your first reaction to a bug is "whose fault is this?" rather than "how do we fix this?", GitLens will make you a better developer or a more toxic teammate. Depends entirely on you.

4. Error Lens — Errors Where You Actually Look

The take: By default, VS Code shows errors in the Problems panel at the bottom of the screen. Nobody is looking at the bottom of the screen. Error Lens moves error messages inline, right next to the line that caused them. It sounds minor. It's not. Once you use it, going back feels broken.

Unpopular opinion: This should be VS Code's default behavior. The fact that it's an extension in 2026 is a minor embarrassment for Microsoft.

5. GitHub Copilot — But Not For the Reason You Think

The take: GitHub Copilot is the most widely adopted AI coding assistant in VS Code. It does more than autocomplete now — it writes full functions, generates tests, and handles natural language to code. For repetitive code, boilerplate, and "I know what I want but don't want to type it" moments, it's genuinely fast.

Unpopular opinion: Copilot is making junior developers worse at problem-solving and senior developers lazier about documentation. The productivity gain is real. The skill atrophy is also real. Use it intentionally, not reflexively. And always read what it generates before you ship it — 45% of AI-generated code contains at least one security vulnerability.

6. Thunder Client — Because Postman Got Too Big for Its Own Good

The take: Thunder Client is a lightweight REST API client built directly into VS Code. Test your endpoints without leaving your editor, without opening another app, without waiting for Postman to load.

Unpopular opinion: Postman in 2026 is bloatware. What started as a simple API testing tool is now a platform with workspaces, teams, flows, and a pricing page with four tiers. Thunder Client does 90% of what most developers actually need in a fraction of the weight. If you're still defaulting to Postman out of habit, try Thunder Client for a week.

7. Tailwind CSS IntelliSense — If You're Using Tailwind, This Is Mandatory

The take: Autocomplete, syntax highlighting, and linting for Tailwind classes directly in your editor. Hovering over a class shows you the exact CSS it generates. This extension makes Tailwind actually pleasant to write.

Unpopular opinion: Tailwind itself is still controversial and that's fine. But if your team has decided to use it, not having this extension is just self-inflicted pain. Arguments about whether Tailwind is good belong in a different article.

8. Path Intellisense — The Smallest Extension With the Highest Return

The take: Autocompletes file paths as you type import statements. That's it. It's tiny, it's fast, and it eliminates an entire category of annoying errors — the ones where you typed ../components/Button when you meant ../../components/Button.

Unpopular opinion: This is the most underrated extension on this list. Nobody talks about it. Everyone who installs it wonders how they lived without it.

9. Docker — If Containers Are Part of Your Workflow

The take: The official Docker extension for VS Code lets you manage containers, images, volumes, and networks directly from the editor. Build, run, inspect logs, and exec into containers without touching the terminal for Docker commands.

Unpopular opinion: If you're running Docker in 2026 without this extension, you're memorizing commands you don't need to memorize. That mental space could go toward something more interesting.

10. VS Code Icons — Last On The List, Not Least

The take: Replaces VS Code's default file icons with a comprehensive set that makes different file types visually distinct at a glance. Python files look different from JavaScript files. Config files are obvious. It sounds cosmetic. It's actually a real time saver when navigating large projects.

Unpopular opinion: Developers who dismiss visual organization as "unimportant" are the same ones who spend 10 seconds finding a file they've opened before. Your environment shapes how you work. Make it work for you.

The Extensions That Didn't Make the List (And Why)

Bracket Pair Colorizer — VS Code has had built-in bracket pair colorization since 2021. You don't need the extension anymore.
Auto Close Tag / Auto Rename Tag — Built into VS Code for HTML and JSX. Check your settings before installing.
Live Share — Great concept, unstable in practice. If you're pair programming regularly, a purpose-built tool handles it better.
indent-rainbow — Pretty. Doesn't solve a real problem. Skip it.

The Rule Behind This List

Before you install any extension, ask yourself three things:

Does VS Code already do this natively?
When was the last update? (Anything not updated in 12+ months is a risk)
Will I actually use this daily, or is it just satisfying to install?

A tight extension setup makes VS Code fast, focused, and actually pleasant to work in. Every extension you add is a trade-off. Make them deliberately.

Which extensions am I wrong about? Drop it in the comments — I want the pushback.

DEV Community: Kudzai Murimi

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 760 | 🎱 Badges: 5 | 👥 Followers: 3 | 📄 Posts: 2 Latest post: "New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up" Read it here: https://coderlegion.com/28183/new-to-bit

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up - Coder Legion

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

First: What Does CodePush Actually Update?

What Bitrise Actually Gives You

1. CodePush inside Bitrise Release Management

2. The SDK inside your application

Before You Touch the Code

Step 1: Create a Deployment

What Can You Bring to the Table? 👨🏾‍💻

Okay but why does this even matter?

Alright, here's my honest answer

And honestly, the biggest one: I'm still learning

Okay, your turn 👇

GitHub Copilot vs Cursor vs Claude Code

GitHub Copilot: the widest net

Cursor: AI woven into the entire editor, not just autocomplete

Claude Code: the one for autonomous, repo-wide work

What most working developers actually do

How to actually choose

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It

What the ATS Actually Does

What Makes a Human Want to Talk to You

The Trap

Do This Before Every Application

The Remote Job Search Playbook for Developers Outside the US/EU

The Remote Job Search Playbook for Developers Outside the US/EU

Timezone overlap is a real filter, not a footnote

Sourcing channels that actually produce interviews

What to lead with in your application

The payment/compliance reality

Compensation framing

The uncomfortable truth

Breaking Into Full-Stack Development Without a CS Degree: What Actually Worked for Me

Breaking Into Full Stack Development Without a CS Degree: What Actually Worked for Me

What Worked

What Didn't Work

The Real Difference Maker

Using AI in Your Job Search: What Actually Helps vs What Looks Lazy to Recruiters

What Actually Helps

What Looks Lazy, and Often Is

The Actual Line

TrendHub: I Was Tired of Checking Six Sites a Day, So I Built One Feed Instead

What TrendHub Actually Does

Features

Under the Hood

Try It

RTK Query Made Easy for Beginners 🎓 (With Real-Life Analogies)

The Big Picture

Step 1: Project Structure

Step 2: Install Redux Toolkit

Step 3: Create the API Service

createApi and fetchBaseQuery

reducerPath

baseQuery

endpoints

builder.query()

query: () => "users"

Step 4: Add the API to Your Store

Step 5: Wrap Your App with Provider

Step 6: Use the Hook

Step 7: Understanding data

Step 8: Understanding isLoading

Step 9: Showing a Loading State

Step 10: Understanding error

Step 11: Rendering the Students

What's Actually Happening Behind the Scenes?

One More Superpower: Caching

Wrapping Up

REST vs GraphQL vs tRPC in 2026

The 30-Second Summary

REST: Old But Not Dead

GraphQL: Powerful, But You're Going to Pay For It

tRPC: The Quiet Game-Changer For TypeScript Teams

The Real Answer: Most Production Apps Use All Three

The 60-Second Decision Framework

# 10 VS Code Extensions Every Developer Needs in 2026

1. ESLint — Non-Negotiable

`createApi` and `fetchBaseQuery`

`reducerPath`

`baseQuery`

`endpoints`

`builder.query()`

`query: () => "users"`

Step 7: Understanding `data`

Step 8: Understanding `isLoading`

Step 10: Understanding `error`