标签：#EV

Ever felt like the Next.js App Router is a super cool superpower, but sometimes it feels like we accidentally left a few things behind during the setup? It happens to the best of us! Building with the App Router is incredibly powerful, giving us server first capabilities and an asik developer experience. Yet, with great power comes a few hidden quirks that often sneak past our radar until runtime. Let's dive deep and spot those common pitfalls together, making sure our Next.js apps run smoother than a freshly brewed cup of coffee. The Great Divide Understanding Client versus Server Components One of the biggest paradigm shifts with the App Router is the clear distinction between Client and Server Components. This isn't just a fancy label it dictates where your code runs and what it can access. Forgetting this fundamental difference is a top contender for unexpected errors. Server Components by Default We often forget that, by default, all components in the App Router are Server Components. This is awesome because it means zero client side JavaScript for many parts of our UI, leading to blazing fast initial loads and better SEO. Server Components can directly access server resources like databases, file systems, or environment variables without exposing them to the browser. They run once on the server, generate HTML, and send it to the client. When 'use client' Becomes Our Best Friend The 'use client' directive is like waving a flag saying, "Hey, this component needs to run in the browser!" We use it when a component relies on browser specific APIs like window or document , handles user interaction like click events, or uses React Hooks such as useState or useEffect . The common mistake here is forgetting to add 'use client' to components that need interactivity, leading to build errors or hydration mismatches when the server rendered HTML doesn't quite match what the client expects. We might also accidentally try to import a server side utility into a client compone

Most remote job listings are ghosts — already filled, never opened, or posted just to farm résumés. As a developer, that annoyed me enough to solve it with code instead of complaining about it on X . So I built Remoty.work , which grades every listing A–F on how likely it is to be real . Here's how the detection actually works under the hood. The problem, from an engineering angle Job boards are an endless scrape loop. Board A scrapes Board B, which scraped Board C. The same dead listing propagates across a dozen sites, and none of them verify anything. There's no signal for "is this real," so the noise compounds until every board looks identical. I didn't want to build board number thirteen in that loop. I wanted a layer on top that answers one question every listing should have to: is anyone actually going to read my application? The architecture Everything runs on a single VPS — Postgres, scrapers, and the scoring jobs, supervised on a schedule. Deliberately boring. High level: Ingestion: scheduled scrapers pull from source boards and company ATS feeds into Postgres. Each raw listing is deduplicated by a fingerprint (title + company + normalized URL) so the same job reposted across five boards collapses into one row with a repost_count . Scoring engine: every listing gets a ghost-risk score from a handful of signals, then mapped to an A–F grade so it's human-readable, not a black-box number. The "rant" signal: I cross-reference what people say about companies in places like r/recruitinghell and hiring threads. That's where the truth about a company's hiring leaks out, and it turns out to be a strong predictor. Agents: I use DeepSeek to classify and summarize the messy text job descriptions, company chatter. DeepSeek because running this over thousands of listings every night on GPT-4-class models would have killed the unit economics before I had a single user. One infra detail I didn't expect to spend a weekend on: the frontend is on Cloudflare's edge, but the ed

I've been using TablePlus for years. It's good — but the connection limits on older licences drove me mad, and most alternatives are either Electron apps or haven't been updated since 2019. So I built my own. What is Stratum? Stratum is a native macOS database GUI — written in Swift, not wrapped in Electron. It connects to MySQL, MariaDB, PostgreSQL, and SQLite. What made me actually build it Three things: 1. Connection limits. TablePlus caps connections on older licences. Stratum has none. 2. Electron alternatives. Beekeeper Studio is good but it's an Electron app. On a Mac, that matters. 3. The MySQL setup friction. Most tools require you to install extra dependencies. Stratum connects natively — no brew install, no extra setup. What it does Table browser with inline editing — add, edit, delete rows without SQL Server-side pagination — stays fast on tables with 100k+ rows Query editor with schema-aware autocomplete Visual schema designer — create tables, add columns without writing DDL Full SQL export — DROP + CREATE + batched INSERTs iCloud sync for connections and snippets Laravel Valet auto-detection Import connections from TablePlus in one click SSH tunnelling The tech Built with SwiftUI and Swift 6. The PostgreSQL driver uses PostgresNIO. The MySQL driver implements the MySQL wire protocol directly over Network.framework — no Homebrew dependency, works inside the App Sandbox. Where it is now Currently in free beta. One-time purchase planned for the Mac App Store — no subscription. → stratum.mwn-digital.uk Happy to answer questions about how it's built.

I built Commit Cron , a small GitHub Actions experiment that creates one automated commit every day. The project updates a text file with the latest execution time, commits the change using the github-actions[bot] account, and pushes it back to the repository. View the project on GitHub: Commit Cron How It Works The workflow runs every day at 10:00 AM Asia/Manila time. on : schedule : - cron : " 0 10 * * *" timezone : " Asia/Manila" workflow_dispatch : The workflow_dispatch trigger also lets me run the workflow manually from the GitHub Actions tab. The workflow checks out the repository, creates the bot directory when needed, and updates bot/last-run.txt : mkdir -p bot printf "Last automatic update: %s \n " \ " $( TZ = Asia/Manila date '+%Y-%m-%d %H:%M:%S %:z (Asia/Manila)' ) " \ > bot/last-run.txt The file contains a timestamp similar to: Last automatic update: 2026-07-17 10:03:24 +08:00 (Asia/Manila) After updating the file, the workflow configures the GitHub Actions bot identity and creates the commit: git config user.name "github-actions[bot]" git config user.email \ "41898282+github-actions[bot]@users.noreply.github.com" git add bot/last-run.txt git commit -m "chore: daily automated update" Before pushing, it pulls the latest branch changes with rebase: git pull --rebase origin " ${ GITHUB_REF_NAME } " git push origin "HEAD: ${ GITHUB_REF_NAME } " This helps prevent the push from failing when another commit is added while the workflow is running. Repository Structure . ├── .github/ │ └── workflows/ │ └── daily-commit.yml ├── bot/ │ └── last-run.txt ├── LICENSE └── README.md Why I Built It Commit Cron is a small demonstration of: Scheduled GitHub Actions workflows Manual workflow triggers Automated file updates Bot-generated Git commits Repository write permissions using GITHUB_TOKEN The workflow uses: permissions : contents : write This allows the built-in GitHub token to push the generated commit. Important Note The automated commits only confirm that the work

Most "I built a home SOC" posts show you the pretty dashboard and stop there. This one is about what happened after the dashboard loaded — because that's where the real learning was. 🖥️ The setup Three Mac Minis, one control machine, all Ubuntu. Mac Mini 1 runs the Wazuh manager, indexer, and dashboard — the security monitoring core. Mac Mini 2 handles AWS IAM permission scanning (Cloudsplaining, ScoutSuite). Mac Mini 3 is a documentation hub plus a custom vulnerability-intelligence pipeline pulling from the NVD API and NIST's CPRT compliance framework data. A fourth machine, my daily driver, orchestrates all three over SSH. Today's goal: get every machine reporting into Wazuh, so I'd have real, fleet-wide visibility — not just a single monitored box. 🐛 Bug #1: the silent feed stall After installing the Wazuh agent on Mac Mini 3, vulnerability scanning just... sat there. The log showed Initiating update feed process and then nothing. No error, no timeout, no progress. I ruled things out methodically: DNS resolved fine, curl could reach Wazuh's CTI feed endpoint and complete a full TLS handshake, disk space was nowhere close to full, and there were no stale lock files sitting around. Every individual piece of the pipeline worked in isolation — but the feed download itself never completed. The actual fix: upgrade Wazuh from 4.14.5 to 4.14.6. A newer point release fixed whatever was silently stalling the content-updater module. Once upgraded, the feed downloaded, decompressed, and the scanner came alive within minutes. Lesson: when every individual network/system check passes but a specific module still won't progress, check for a version-specific bug before going deeper down the debugging rabbit hole. 🔒 Bug #2: locking myself out with fail2ban Mid-troubleshooting, my control machine's SSH connection to Mac Mini 3 started getting flatly refused — no prompt, no error, just Connection refused. Ping worked fine. Every other port responded. Just port 22, silently dead. fai

Swatch’s latest MoonSwatch is the Mission to the Moon 1969, a limited-edition model with components crafted from Omega’s 18K Moonshine Gold. To get one, you'll have to join a lottery.

Why this matters Let’s be real — most of us don’t struggle because we “can’t code”. We struggle because: we waste time on repetitive tasks we get stuck on small bugs we context-switch too much we overthink simple problems That’s where AI actually helps. Not as a replacement — but as a performance multiplier . 🤖 First, what AI is actually good at AI is not magic. But it’s really good at: generating boilerplate explaining errors suggesting improvements summarizing docs speeding up repetitive work 👉 Basically: saving your mental energy ⚡ 1. Write code faster (without burning out) Instead of writing everything from scratch: // prompt idea " create a custom React hook for localStorage " You get a solid starting point instantly. 👉 You still review it 👉 You still understand it 👉 But you don’t waste time writing boilerplate 🐞 2. Debug faster Instead of Googling for 20 minutes: Error: Cannot read property 'map' of undefined You ask AI: 👉 It explains the issue 👉 suggests fixes 👉 shows edge cases Example mindset shift Before: search → open 5 tabs → read → test → maybe fix Now: ask → get explanation → apply → move on 🧠 3. Learn way faster AI is like having a senior dev on demand. You can ask: “Explain React Server Components simply” “When should I use memo?” “What’s wrong with this pattern?” 👉 Instant explanations 👉 Real examples 👉 No fluff 🔄 4. Automate boring tasks Things you shouldn’t waste time on: writing regex generating types creating repetitive components converting data formats 👉 AI handles these in seconds 📚 5. Write better documentation Most devs hate writing docs. AI helps you: generate README files write comments document APIs 👉 Your project becomes easier to understand 👉 Your team moves faster 🧩 6. Break down complex problems Instead of getting stuck: "build a dashboard with auth, charts, and API integration" Ask AI to break it down: 👉 smaller steps 👉 clear structure 👉 less overwhelm ⚡ 7. Stay focused (this is underrated) Biggest hidden benefit: 👉 less context swi

Every TypeORM project I've worked on grows the same few dangerous lines. I got tired of catching them by hand, so I wrote a linter that does it for me. I was reviewing a pull request a while back and nearly scrolled past this line: await manager . query ( `SELECT * FROM users WHERE id = ${ req . params . id } ` ); Looks fine at a glance. It's a SQL injection hole. The id comes off the request and lands directly in the query string. The thing that bugged me is that I only caught it because I happened to be reading carefully on that line, that day. Review catches this sort of thing a lot of the time. "A lot of the time" is how these end up in production. It's usually not only injection either. The same projects tend to collect a few other habits: synchronize: true in a data source config. It rewrites your schema on startup and can drop a column on the next deploy. A QueryBuilder delete() or update() that hits .execute() with no .where() . Forget that one line and you've changed every row in the table. Three or four writes in one function, none in a transaction, so if the second throws you're left with half-written data. On multi-tenant apps, a query that forgets the tenant filter. That's how one customer sees another customer's data. None of these really need a person to catch them. They're mechanical. A linter can do it on every commit. So I built one. eslint-plugin-typeorm-enterprise npm install --save-dev eslint eslint-plugin-typeorm-enterprise // eslint.config.js const typeormEnterprise = require ( ' eslint-plugin-typeorm-enterprise ' ); module . exports = [ typeormEnterprise . configs . recommended ]; Now those patterns are lint errors. Ten rules today, split into configs ( recommended , strict , performance , multiTenant ): raw SQL, interpolated and concatenated SQL, unsafe QueryBuilder deletes, EntityManager raw queries, writes outside a transaction, tenant scoping, and a nudge to stop counting rows when you only need to know one exists. Two things I was picky

* When a project first starts, CI/CD pipelines are usually simple. * Build the application. Run a few tests. Deploy somewhere. Done. Then six months pass. Another test gets added. Then another deployment step. A security scan. Performance tests. Notifications. More environments. Before long, a pipeline that once took five minutes now takes forty-five. I've seen this happen more than once, and it's rarely because Azure DevOps is the problem. It's usually because nobody ever stops to ask one simple question: Does this step still belong here? Everything Ends Up in the Same Pipeline One of the most common mistakes I see is trying to make a single pipeline do everything. Every Pull Request ends up running: Every unit test Every API test Hundreds of UI tests Security scans Deployment steps Report generation The result? Developers wait longer for feedback, releases become slower, and people eventually start ignoring failed pipelines because they happen too often. Fast Feedback Wins Not every test needs to run on every commit. A better approach is to think about the purpose of each pipeline. For a Pull Request, I want answers quickly. That usually means: Build the application Run unit tests Run a small smoke test suite Stop if something important fails Everything else can happen later. Long-running regression tests, cross-browser testing and other expensive checks are often better suited to scheduled or nightly pipelines. Pipelines Should Evolve A pipeline isn't something you build once and forget about. Every few months it's worth reviewing it. Ask yourself: Which step takes the longest? Which tests fail most often? Are there any tasks nobody remembers adding? Are we getting useful feedback, or just more output? Removing unnecessary work is just as valuable as adding new automation. Final Thoughts Azure DevOps is an incredibly powerful platform, but even the best tools become frustrating if they're overloaded with unnecessary work. The goal isn't to build the biggest pipel

From Zero to a Working EKS Pipeline: Terraform, Ansible, and GitLab CI/CD (and Everything That Broke Along the Way) I recently built an end-to-end deployment pipeline on AWS EKS using Terraform for infrastructure, Ansible for configuration, and GitLab CI/CD to tie it all together. On paper, that sentence sounds clean. In practice, it took several rounds of "why is this failing" before it actually worked. This post is not a "here's how EKS works" tutorial. There are plenty of those. This is the version with the failures left in, the quota limits, the IAM permission walls, the pods that wouldn't schedule, and the resources that refused to die. If you're building something similar, I'm hoping this saves you a few hours of confused Googling. Repo: gitlab.com/nenyeonyema/terraform-eks-ansible-cicd What I Was Building The goal was a full IaC-driven pipeline: Terraform to provision the EKS cluster and supporting AWS infrastructure (VPC, node groups, IAM roles) Ansible to handle configuration tasks on top of the provisioned infrastructure GitLab CI/CD to automate the whole thing — plan, apply, configure, deploy — on every push Simple enough in theory. Four separate blockers said otherwise. Blocker #1: Free Tier ASG Restrictions The first wall I hit was with the Auto Scaling Group for my EKS node group. AWS Free Tier limits how much compute you can provision, and my initial node group sizing quietly ran into those limits — the kind of failure that doesn't always throw an obvious, single-line error. Fix: I resized the node group to stay within Free Tier boundaries and got explicit about instance types and desired/min/max capacity in Terraform, instead of leaving Auto Scaling to make assumptions I couldn't afford. Lesson: If you're building on Free Tier, hardcode your capacity expectations early. Don't let the defaults surprise you later. Blocker #2: EKS Private Endpoint Access By default, EKS clusters can be configured with private-only API server endpoint access. That's grea

A music generator such as Suno can give a creator a finished track. It does not automatically give them a finished music video. The usual next step is a toolchain: Export the song as an MP3. Use an image model such as Nano Banana to establish the artist, character, location, or visual style. Turn those references into individual video shots with a model such as Veo , Seedance , or another video generator. Route performance close-ups through a lip-sync-capable step when the singer needs to match the vocals. Prepare lyrics or an SRT file, then align captions with the song. Retry failed shots, choose the usable takes, match aspect ratios, place the original track, and compose the final timeline. Upload the exported MP4 somewhere the application can reliably deliver it. Modern multimodal models reduce parts of this work, but an application still has to own the workflow around them. A full song is longer than one generated shot. Character consistency can drift. One failed scene should not require restarting everything. Subtitle timing, task state, retries, cost evidence, and final delivery still need product code. I wanted to see what this integration would look like if the application only had to submit the source material and track one job. For the concrete implementation below, I used the BeatAPI Music Video API . At the simplest level, the application provides: one MP3, WAV, AAC, or M4A file; one to seven reference images; optional creative direction; optional lip-sync and subtitle controls; output format and quality settings. The API returns a task ID immediately and delivers a hosted MP4 when the workflow succeeds. The default path does not require the developer to review or edit a storyboard. Before: song -> reference images -> generated shots -> lip sync -> subtitle timing -> retries -> editing -> hosting Behind one workflow API: audio + reference images + controls -> one async task -> hosted MP4 By the end of the tutorial, you will have a backend flow that: uplo

If you've deployed your application on Render and noticed that emails are not being sent, you're definitely not the only one. I recently faced this issue while deploying my project: https://rizzzler.onrender.com After spending hours debugging my code, checking environment variables, testing SMTP credentials, and reading logs, I finally discovered the real cause: The hosting environment was restricting outbound SMTP connections, preventing my application from connecting to the mail server. To solve this, I moved the email-sending functionality to Google Cloud , where the SMTP connection worked correctly. This article explains how I diagnosed the issue, common mistakes to avoid, and the solution that worked for me. Symptoms You might experience one or more of the following: Password reset emails are never received. OTP emails aren't delivered. Email verification doesn't work. Nodemailer throws timeout errors. SMTP connection fails. Everything works on localhost but fails after deployment. Typical errors include: ETIMEDOUT ECONNREFUSED Connection timeout Greeting never received Step 1: Verify Your SMTP Credentials Before assuming the issue is with Render, verify your SMTP configuration. Check that the following are correct: SMTP Host SMTP Port Username Password Even one incorrect character can prevent emails from sending. Step 2: Check Environment Variables Ensure all required environment variables are configured in Render. Example: SMTP_HOST=smtp.example.com SMTP_PORT=587 SMTP_USER=your-email@example.com SMTP_PASS=your-password Also remember to: Restart your Render service after updating variables. Never hardcode credentials in your source code. Step 3: Test Locally If your application sends emails successfully on your local machine but fails only after deployment, your application code is probably not the problem. This is an important clue. Step 4: Read the Logs Open your Render logs and look for SMTP-related errors. Common messages include: ETIMEDOUT ECONNREFUSED Co

The electric L03 is looking to punch above its weight in style and tech as it launches in 60 countries worldwide.

You've probably registered a domain with Route53 or another popular registrar. You pick something...

A lot of platform teams face a problem: they build a lot of really cool stuff, and then their developers don't use it. Be visible to management, talk to stakeholders and listen to their problems, make your value measurable with metrics like DORA, create narratives, and show the hidden pain to make it personal: these are lessons that Lucas Hornung and Christian Matthaei presented. By Ben Linders

Projectors are adopting RGB backlighting, the hottest tech from the world of TVs. This large but vivid projector is a great option for summer movie nights.

I’m sick of “opt-out” toggles for automatically enabled generative AI features. It’s past time to make “opt in” the default setting for sensitive features.

What I learned at Zone01 Kisumu's IP training Introduction Yesterday, I attended an Intellectual Property training at Zone01 Kisumu, and it fundamentally changed how I think about the code I write. As developers, we spend countless hours building software, but how many of us truly understand the value of what we create,and how to protect it? In Kenya's rapidly growing tech ecosystem, understanding IP isn't just a legal nicety, it's a competitive advantage. Whether you're building an app, contributing to open source, or launching a startup, knowing your rights can mean the difference between owning your work and losing it. This article breaks down the essential IP frameworks every software developer should know. What is Intellectual Property in Software? Intellectual Property (IP) in software encompasses legal protections designed to safeguard the rights of creators and developers. The four primary types of IP protection relevant to software are: patents, copyrights, trademarks, and trade secrets . Copyright: Protecting Your Code Copyright is the most immediate form of protection for software developers. In Kenya, copyright protection arises automatically at the moment of creation,registration is not mandatory . This means that when you write code, you automatically own the copyright to that expression, provided the work is fixed in a tangible medium . However, a crucial distinction exists: copyright protects the expression of ideas, not the ideas themselves . This principle was reinforced in the Kenyan case of Solut Technology Limited v Safaricom Limited, where the court confirmed that without access to source code, it's difficult to prove infringement because the "expression" (the code itself) wasn't shared . Key Insight: Registering your copyright with KECOBO in Kenya provides prima facie evidence of ownership and can make enforcement faster if someone copies your work . Patents: Protecting Functionality While copyright protects the expression of code, patents pro

MCP for AWS Security Engineers: Build a Read-Only Security Hub Triage Agent For AWS-heavy security work, I would start with AWS Agent Toolkit for AWS and the managed AWS MCP Server , not a custom MCP server. The reason is practical. AWS now provides a managed MCP path that can connect AI coding agents to AWS documentation, AWS APIs, AWS skills, and existing IAM credentials. The Agent Toolkit also provides plugin-based setup for supported agents such as Claude Code and Codex. For security teams, that is the right starting point because the enforcement point remains AWS IAM, not the model. The initial operating model should be strict: Read-only first. No production write authority. No access to secrets. No raw customer PII or sensitive incident logs in prompt context. No automatic remediation. No AI-approved suppression, exception, merge, deploy, or risk acceptance. Human review and CI/CD remain the release authority. That is the same posture I would use for a governed Claude Code or Codex rollout: named identities, SSO, scoped credentials, default deny, tool approval, audit logs, and security evidence tied back to tickets, pull requests, CI logs, and cloud findings. What we are building This article walks through a practical security workflow: A read-only Security Hub triage assistant that helps a junior security engineer produce a daily or weekly findings summary, remediation backlog, and evidence pack without allowing the agent to modify AWS. The agent will be able to: Read AWS Security Hub findings. Group findings by account, severity, product, resource, and control. Explain why a finding matters. Draft remediation tickets. Draft a Slack-ready summary. Produce local markdown, CSV, and JSON evidence files. The agent will not be able to: Suppress findings. Archive findings. Mark findings resolved. Disable Security Hub standards. Modify IAM, S3, EC2, KMS, GuardDuty, Inspector, or Config. Deploy remediation. Run destructive scripts. Approve risk acceptance. This is no

I spent the last few months building a Chrome extension that detects HTML code blocks inside ChatGPT, Claude, and Gemini and lets you deploy them straight to a live URL. The "deploy" part turned out to be the easy 20%. The hard 80% was reliably watching three completely different, constantly-changing chat UIs without breaking every other week. Here's what actually taught me something. 1. MutationObserver is non-negotiable, but it will still lie to you None of these chat apps render the full response at once — they stream tokens in, which means the DOM you're watching is incomplete almost every time your observer fires. My first version tried to detect a finished <pre><code> block the moment it appeared. Result: I was grabbing HTML mid-stream, cut off halfway through a <div> . What actually worked was debouncing on DOM stability instead of DOM presence: let debounceTimer ; const observer = new MutationObserver (() => { clearTimeout ( debounceTimer ); debounceTimer = setTimeout ( scanForCodeBlocks , 600 ); }); observer . observe ( document . body , { childList : true , subtree : true }); 600ms of "nothing changed" turned out to be a much more reliable signal than "the tag now exists." Not elegant, but it works across all three sites' streaming speeds. 2. Every AI chat UI restructures its DOM without telling you ChatGPT, Claude, and Gemini all ship frequent frontend updates, and none of them are obligated to keep a stable class name for you to hook into. I initially selected code blocks by class name ( .language-html , .hljs , etc.) and had selectors silently break in production within two weeks of launch. What's held up better: matching on structural patterns instead of class names — a <pre> containing a <code> whose text content starts with <!DOCTYPE or <html . It's slower to write the first time, but it doesn't care what CSS class the framework decided to use this month. 3. "Detect the code" is easy. "Detect the right code" is the actual problem A single AI response