标签：#web

Most SaaS products do not need a “crypto payment button.” They need a payment module. That distinction matters. A button can redirect a customer to a payment page. A module has to know which user is paying, which workspace should be upgraded, which plan should become active, when access should expire, how failed or expired payments should be handled, how support can inspect payment status, and how finance can export records later. That is where developers can build a serious product. A Crypto Payment Module for SaaS Apps is a reusable layer that lets SaaS builders add crypto payments without building the whole payment lifecycle from scratch. In this article, I will use OxaPay as the example crypto payment infrastructure because its documentation exposes the primitives needed for this kind of module: invoice generation, white-label payments, static addresses, webhooks, payment information, payment history, SDKs for PHP, Python and Laravel, and automation integrations. This is not a “get rich with crypto APIs” article. It is a practical blueprint for developers who want to build something SaaS founders, indie hackers, agencies, and product teams may actually pay for. The core idea A Crypto Payment Module gives SaaS apps a production-ready way to accept crypto payments and translate payment events into SaaS account states. Instead of selling this: I can integrate crypto payments into your app. You sell this: I can give your SaaS a reusable crypto billing module with invoices, payment status tracking, webhook verification, plan activation, grace periods, admin tools, and payment history sync. That is a much stronger offer. A SaaS founder does not only care that a payment happened. They care that the right account is upgraded, the right plan is applied, the right billing period is extended, the right user sees the right status, and the support team can understand what happened when something goes wrong. That is what your module should solve. Why this is a real developer

Modern development teams use CI/CD pipelines, automated testing, feature flags, and AI-assisted coding to release new functionality multiple times per week. Yet despite all of these improvements, one part of the delivery process often remains surprisingly inefficient: website feedback. Clients still send screenshots through email. Designers leave comments in Slack. QA engineers create tickets manually. Developers spend time figuring out where an issue actually occurred before they can even begin fixing it. As AI becomes increasingly integrated into software development, another technology is beginning to reshape this workflow: the Model Context Protocol (MCP) . Rather than treating website feedback as disconnected conversations, MCP makes it possible for AI systems to understand the context surrounding a reported issue, helping development teams reduce unnecessary back-and-forth and resolve problems faster. Why Website QA Still Creates Bottlenecks Most website review processes haven't changed much over the past decade. Someone spots an issue, takes a screenshot, writes a short description, and sends it to a developer. The developer then has to answer a familiar set of questions. Which page? Which browser? Which screen size? Can you reproduce it? What exactly were you clicking? The actual bug may only take a few minutes to fix, but understanding the issue can consume considerably more time. As websites become increasingly dynamic, reproducing reported problems becomes even more difficult. Personalization, authentication, browser differences, JavaScript frameworks, and responsive layouts all introduce variables that aren't captured in a simple screenshot. Why Context Matters More Than Ever AI coding assistants have dramatically improved developer productivity. However, AI is only as useful as the context it receives. If an assistant only receives a vague message such as: "The button doesn't work." there is very little it can do. Now compare that with a report containi

I'm excited to share that I'll be speaking at React Day Berlin 2026 this December! My talk How I Brought React Into a Preact Form Engine: A Production Bridge Pattern I'll walk through how we integrated React into an existing Preact-based form engine in production — the bridge pattern we used, the trade-offs, and what I'd do differently next time. Duration: up to 20 minutes Dates: December 4 & 7, 2026 Format: remote or in-person (TBD) Join me (free stream access) You can register through my speaker badge and get partial free access to watch the stream: 👉 My React Day Berlin 2026 badge Speaker page: reactday.berlin/#person-sam-abaasi ReactDayBerlin #react #preact #javascript #webdev See you there!

A practical workflow for turning release artifacts into an accurate, reviewable SaaS product demo without inventing product details. Shipping a feature and explaining it are different kinds of work. The code may have tests and a clean deployment path. The material needed to explain the feature is scattered across tickets, release notes, draft docs, screenshots, and a rushed screen recording. Consider a fictional SaaS team releasing workspace permissions. The feature adds Owner, Editor, and Viewer roles, plus a log of permission changes. By release day, most inputs already exist. The challenge is turning them into one accurate product demo without asking the workflow to guess. Treat release material as a versioned input bundle, then review the script and storyboard before generating video. Why shipping the feature is easier than explaining it Engineers and product managers see the feature as a diff. Viewers do not. A ticket might say "enforce role checks at the workspace boundary," while a customer needs to know where to choose Viewer and what that person can access. That translation is where demos drift. A script can inherit an internal name, skip a prerequisite, show an old label, or turn a planned benefit into a shipped claim. Set one rule before starting: the video cannot introduce a product fact that is absent from the release bundle. Every UI action must also map to the released build. Build a release-to-video source bundle Store the material in a release-specific folder with the release tag or build date. Give each input an owner who can resolve conflicts. Input What it contributes Owner Release note Shipped scope and exclusions Product manager Audience and job One viewer and the task they need to complete Product or PMM Approved claims Language the team can defend Product and legal, if needed Help-center draft Prerequisites, steps, and edge cases Docs or customer education Three current screenshots Exact labels and important UI states Designer or feature owne

AI is moving fast, and it feels like there's a new concept to learn every week. In an effort to actually understand this whole new world instead of just skimming past it, I've been writing ELI5 articles breaking down concepts that show up constantly in AI conversations but rarely get explained simply. This time, a term that gets thrown around a lot without much explanation: the context window. AI 101 Recap The context window is the total number of input and output tokens an LLM can consider while generating a response. Your prompt, the conversation history, and even the model's response all share that same "budget" of tokens. As a conversation with an LLM grows longer, more tokens live in this window. So far so good. Every AI model has a limit on how many tokens it can hold in its "working memory" at once. So the interesting part with the context window is what happens when you reach these limits. Why are there limits? There are several reasons models have context window limits. Processing more tokens requires more memory and computation, making every request slower and more expensive. On top of that, today's models struggle to use very long contexts effectively. They naturally pay more attention to the beginning and end of a conversation than the middle ("lost in the middle" problem). The Amnesia Problem An AI model has no persistent memory between conversations. Within a long conversation, it only sees whatever still fits inside its context window. Think of it as a sliding window: as new messages come in, older ones eventually slide out and are no longer visible to the model. This is why a long conversation can feel like the model has "forgotten" something you told it early on. It doesn't actually forget, it just no longer has access to that part of the conversation, unless the product you're using has built something extra on top to handle it. How RAG helps RAG (retrieval-augmented generation) sounds technical, but the idea is simple: look it up before you answer

Over the last 14+ years, I've been working with the Microsoft technology stack, designing and delivering enterprise applications for procurement, inventory management, warehouse operations, and EPOS systems. As a Tech Lead, I've worked on projects involving: Procurement & Purchase Order Management Inventory & Warehouse Management EPOS integrations Accounting integrations REST APIs & Microservices Azure cloud solutions Performance optimization and secure application design While enterprise software has always been my primary focus, I've recently been expanding my work with Next.js, React, and TypeScript by building browser-based productivity tools. One of my goals is to build applications that are fast, privacy-friendly, and solve real business problems directly in the browser whenever possible. Some of the tools I've been building include: YAML Studio for Kubernetes, Docker Compose, GitHub Actions, Azure DevOps, Helm, Prometheus, and Grafana configuration generation. JSON ↔ Excel Converter with support for nested JSON, multi-sheet exports, and parent-child relationships. Multilingual OCR for business documents. PDF to Excel with structured table extraction. JSON Formatter & Validator. CSV, Excel, and other data conversion tools. One thing I've learned while building document-processing tools is that file conversion is the easy part. The real challenge is preserving document structure—detecting tables, handling multi-line descriptions, reconstructing wrapped product codes, and generating output that users can actually work with instead of spending time cleaning it up. My experience in procurement has made this especially interesting because Purchase Orders, Delivery Notes, Goods Receipts, and Invoices all have different layouts and business rules. Building reliable tools requires understanding both the technology and the business process behind the documents. Alongside application development, I'm also continuing to strengthen my DevOps knowledge with Docker, Azure D

When people hear about a new project scaffolding tool, one of the first questions they ask is: "Can I choose React Query or TanStack Query?" "What about pnpm instead of Bun?" "Can I use ESLint instead of Biome?" "Can I choose Radix instead of Base UI?" "Can I skip Tailwind?" These are reasonable questions. In fact, I asked myself the same ones while building create-notils . My first instinct was to make everything configurable. The more I thought about it, the more I realized I was about to build something I didn't actually want to use. The Configuration Trap Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library. Eventually the CLI starts looking like this: ? Which package manager? ❯ npm pnpm yarn bun ? Which CSS framework? ? Which ORM? ? Which auth library? ? Which formatter? ? Which icon library? ? Which deployment target? It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features. I Built the Tool I Wanted to Use One thing I've learned from building side projects is this: the first user should always be yourself. Every project I start today uses almost exactly the same stack: Next.js 16 React 19 Bun Tailwind CSS v4 shadcn/ui Base UI Biome TypeScript Turborepo (when needed) I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have. npx create-notils my-app A few seconds later, I'm writing features instead of answering prompts. Opinionated Doesn't Mean Closed There's an important distinction between opinionated and restrictive . Some tools hide their implementation behind abstraction

Hoi hoi! I'm @nyaomaru, a frontend engineer. Thanks to my daily Duolingo streak, Dutch is finally...

Headline: Zod 4 is a rewrite of the TypeScript-first schema validation library, released as the stable major in 2025. Four changes hit my code directly: string formats moved to top-level functions ( z.email() instead of z.string().email() ), the four error options collapsed into one error parameter, error formatting moved to standalone helpers ( z.flattenError , z.treeifyError , z.prettifyError ), and .strict() / .passthrough() became z.strictObject() / z.looseObject() . The deprecated Zod 3 APIs still work with warnings, so I migrated incrementally. Key takeaways Zod 4 is the stable major of the TypeScript-first schema validator, released in 2025; it requires TypeScript 5.5 or newer. String formats are now top-level tree-shakeable functions — z.email() , z.uuid() , z.url() — and z.string().email() is deprecated but still works. A single error parameter replaces Zod 3's message , invalid_type_error , required_error , and errorMap . Error formatting moved to z.flattenError (form fields), z.treeifyError (nested), and z.prettifyError (human-readable string). The zod/mini build exposes the same validators through a functional, tree-shakeable API; z.infer , .parse() , and .safeParse() did not change. I reach for Zod on almost every project to validate untrusted input at the boundary — request bodies, form data, environment variables, API responses. Zod 4 changed enough of the surface that a mechanical upgrade tripped a handful of files, so I mapped exactly what moved. What actually changed in Zod 4? Zod 4 is a ground-up rewrite of the TypeScript-first schema validation library, released as the stable major in 2025. The headline is performance: the Zod team's release notes report large reductions in TypeScript compiler instantiations and faster runtime parsing, which matters most in large codebases where schema types dominate type-check time. Four API changes touched my code directly — string formats moved to top-level functions, the four error options collapsed into one,

A birth-chart form looks simple: ask for a date, time, and place, then calculate. The interface may be simple. The input is not. 1992-11-01 01:30 does not identify one universal instant. It is a wall-clock reading that only becomes meaningful after you resolve the place, the historical time-zone rule, and any daylight-saving transition. If the time is unknown, inventing a convenient default can create chart features that were never supported by the user’s data. I ran into these problems while building AstroZen , a Next.js application that calculates a BaZi Four Pillars chart and a Western natal chart before generating an optional interpretation. The most important architectural decision was this: Calculation is an evidence pipeline. Interpretation is a separate layer. This post explains the calculation pipeline, the failure modes I had to remove, and why “unknown” must remain unknown. 1. A city name is not a coordinate Early prototypes often use a short city list or a default coordinate. That works for a layout demo, but it is not acceptable once location affects the result. Names are ambiguous: Paris can mean France or Texas. Springfield needs a state or region. Country abbreviations come in several forms. A valid city must resolve to both coordinates and a time-zone identifier. AstroZen sends the submitted city to Open-Meteo’s geocoding service, then scores the returned candidates against the requested country and optional region hint. It keeps the following structured result: type ResolvedPlace = { name : string ; region : string | null ; country : string ; countryCode : string ; latitude : number ; longitude : number ; timeZone : string ; // IANA, for example "Europe/Madrid" }; Candidate selection considers exact city-name matches, country matches, an optional region hint, and population as a small tie-breaker. Population never replaces the country check. The more important rule is what happens when resolution fails: if ( ! selected || ! countryMatches ( selecte

I shipped a Next.js 16 app on Cloudflare Workers via OpenNext. Not a demo. A real product with streaming chat, server components, D1 at the edge, and anonymous user sessions. Here is what broke, what barely worked, and what turned out to be surprisingly fine. The stack Next.js 16.2 (App Router) @opennextjs/cloudflare 1.19 D1 for SQLite at the edge Streaming chat via the AI binding (DeepSeek-V3 through a Workers proxy) React 19 Tailwind CSS 4 No auth wall, no OAuth, no database on the origin The site runs a few thousand sessions a week across ~30 persona pages, blog posts, guides, and learning content. Most pages are statically generated. The chat interaction is server-rendered components with streaming responses. What worked surprisingly well Static generation and ISR Pages, blogs, guides, persona pages — everything that does not need user-specific rendering — runs as static HTML at deploy time. Next.js 16 with generateStaticParams and fetch caching worked without modification. OpenNext handles the Cloudflare output format. The build step produces something Workers can serve. Revalidations are limited to Workers' cache API, but since most content changes at deploy time, I never hit that limit in production. The one caveat: revalidateTag() does not work the same way in a Workers runtime. Tags are Node.js memory constructs, and Workers are stateless. If you depend on tag-based revalidation for content updates, you need to either trigger deploys or accept stale-while-revalidate behavior from the CDN. D1 at the edge D1 was the least surprising part of the stack. SQL queries from Next.js route handlers feel like calling a regular database. Sessions store in D1, messages store in D1, and the latency is low enough that restoring a full chat thread from 30 messages takes under 200ms cold. The only sharp edge: D1 connections count against your Worker's concurrent request limit in development. With Next.js making its own fetch calls for compilation, I hit the D1 connection ce

My LLM bill kept growing, so I did what seemed obvious: I looked for a cheaper model. That helped a little, but it didn't explain why the bill was growing. The dashboard could tell me how many tokens the application used. It couldn't tell me what those tokens were doing. Were they coming from chat? Document summaries? Background classification? An agent retrying the same tool call? I was trying to optimize a total without knowing which product feature created it. The useful unit wasn't tokens per model . It was tokens per feature . Model-level totals hid the real problem A provider dashboard usually groups usage by model, API key, project, or time period. That is useful for billing, but not always for product decisions. Imagine an application with four LLM-powered features: interactive chat document summarization support-ticket classification an agent that prepares weekly reports If the bill increases by 30%, the model name doesn't explain which feature changed. Maybe chat traffic grew. Maybe summarization started sending entire documents instead of selected sections. Maybe the classifier received a much larger system prompt. Maybe the report agent retried after tool failures and generated the same plan several times. Those problems require completely different fixes. Switching every request to a cheaper model would reduce the bill, but it could also hide the engineering mistake. Tag every request with a feature I started giving every LLM call a small amount of application context: const context = { feature : " document_summary " , operation : " initial_summary " , customer_tier : " pro " }; The model provider doesn't need these fields. They belong in the application's usage record. I avoid using individual user IDs as the primary grouping dimension. For cost analysis, a product feature, workflow, or operation is normally more useful and creates fewer privacy problems. A practical record looks like this: { "timestamp" : "2026-07-22T03:12:48.201Z" , "feature" : "docu

Solving the context-window puzzle for book-length AI translation. At LectuLibre, we set out to build a service that translates entire books using large language models. The idea is simple: upload an EPUB or PDF, choose a language, and receive a polished translation. But behind the scenes, translating a hundred-thousand-word novel with LLMs isn't straightforward. The core challenge is context — LLMs have limited context windows, and books are long. Simply chopping the text into chunks and feeding each one independently leads to incoherent output. Character names change, pronouns lose referents, and tone veers wildly. Here’s how we solved that with a chunking strategy that preserves context, and the Python code that makes it tick. The Problem: Long Documents vs. Short Context Windows Modern LLMs like Claude 3 Opus can handle 200,000 tokens of context, while DeepSeek-V2 offers 128,000 tokens. That’s a lot — but a 50,000-word English novel translates to roughly 67,000 tokens (using Claude’s tokenizer). That just fits, but what about a 150,000-word fantasy epic? Even when it fits, sending an entire book in one prompt is costly, slow, and often degrades attention quality on long texts. The prevailing approach is to chunk the document. Naive chunking — say, splitting by a fixed token count — creates hard boundaries. One chunk ends, another begins, and the LLM has no idea what happened before. The result reads like a patchwork of isolated translations. We needed a method that gives each chunk enough surrounding context without exceeding token limits or breaking the bank. Our Approach: Sliding Window + Context Retrieval via Embeddings We adopted a two‑pronged strategy: Overlapping chunks : each chunk shares some sentences with the previous one, so the LLM can transition smoothly. Injected context : for every chunk, we retrieve and prepend the most relevant previous chunks, determined by embedding similarity. This way, the model always has a sense of what’s happening before a

alright let me be real with you for a second i've been building production systems for a few years now, mostly backend with node and nestjs, react and next on top, and the one thing that always drove me absolutely crazy was how performance content online just doesn't respect your time you google "how to optimize react rendering" and you get a medium article with 47 claps that shows you useMemo on a counter app you google "how to optimize node performance" and you get a 2019 blog post that tells you to use async await neither of them has real numbers, neither of them shows you how to actually FIND the problem before you start fixing things, and absolutely none of them connect the frontend and backend story together so i spent the last few months building it myself what i built it's called frontend-backend-performance-mastery and it's structured across 6 levels, each level has a frontend folder (react, next.js, typescript) and a backend folder (node, express, nestjs), and every single folder follows the exact same 3-file structure detect.md — how to find the problem, what to look for, what tools to use, before you even open devtools fix.md — the actual fix, with a before and after, when to apply it, and just as important when NOT to apply it project/ — a fully runnable code example, npm install and npm run dev and you're looking at real numbers on your screen, not a screenshot from someone's laptop from 2021 the 6 levels level 01 — fundamentals: web vitals, profiling, baselines, benchmarking with clinic.js and autocannon level 02 — rendering: ssr vs csr vs ssg, react fiber internals, hydration, response streaming, fast-json-stringify level 03 — caching: react query, swr, service workers, redis, cache-aside pattern, cdn and http headers level 04 — database and api: n+1 queries, cursor pagination that stays fast at 10 million rows, dataloader, query optimization, indexes level 05 — advanced: wasm in next.js, worker threads, piscina, bull queue, grpc, node streams, code

I built PunFiction: 1-Star Travel Reviews , a free daily web puzzle where you guess world landmarks by deciphering unhinged travel reviews from confused travelers. Tech Stack: Vanilla JS, CSS, HTML, GitHub Pages, MongoDB Atlas The Concept The internet can feel like it's literally overflowing with consumer complaints. I decided to take that negative energy and turn it into a 2-minute daily browser game for your morning coffee break. The Game Loop: Read an absurd 1-star review of a famous world landmark. Decipher the rhyming pun clues to guess the destination. Solving the puzzle unlocks an illustrated cartoon postcard and a sassy reply from the landmark 'manager'. The Tech Stack I wanted PunFiction to feel lightweight and lightning fast. Vanilla JavaScript: No React, Vue, or Svelte. Pure DOM manipulation and client-side logic. Zero Dependencies: No npm install spiral, no build-step headaches, and zero third-party scripts. No Accounts: Daily state, win streaks, and game progress live in localStorage. MongoDB Atlas: Light backend for aggregate puzzle stats (success rates, guess counts, no PII stored). Hosted on GitHub Pages: Static asset delivery via CDN. Give It a Spin If you like wordplay, geography, or just laughing at terrible tourist complaints, give today's daily puzzle a shot: 👉 Play PunFiction: 1-Star Travel Reviews I’d love to hear your thoughts on the UX, the game feel, or your take on building lightweight web games. Drop your feedback (or your worst pun) in the comments!

Most “WordPress to Next.js” tutorials show you how to fetch posts from the WP REST API and render them in the App Router. That’s the easy 20%. The 80% that actually decides whether your organic traffic survives is everything around the content: your URLs, your redirects, your metadata, your sitemap, and your images. Get those wrong and you’ll watch impressions fall off a cliff two weeks after launch, right when everyone assumes the migration “went fine.” This guide is the checklist I wish every team ran before flipping DNS. It’s framework-accurate for the Next.js App Router, and it works whether your new backend is headless WordPress, a headless CMS, or flat files. The one rule that saves rankings Every decision in a migration comes back to a single principle: Nothing about how Google already sees your pages should change, except the parts you deliberately improve. Google ranks specific URLs based on their content, their metadata, and the links pointing to them. A migration is dangerous precisely because it’s tempting to change all three at once: new URLs, a “cleaner” content structure, redesigned templates. Do that and you’ve thrown away the signals every ranking is built on. The safe path is boring: same URLs, same content, same meta, just a faster, modern frontend underneath. Step 1: Inventory everything before you touch anything You cannot preserve what you haven’t captured. Before writing a line of Next.js, you need a complete, structured snapshot of the live site: every published URL, its rendered content, its SEO metadata, its images, and its internal links. This inventory becomes the source of truth for your redirect map, your generateMetadata , and your sitemap. This is the step most guides wave away with “export your content from WordPress.” In reality it’s where migrations break, because the default WordPress export (WXR) gives you raw post content, not the rendered HTML your page builder actually outputs, and it drops most of the SEO fields you need. If

A few weeks ago I wrote about describing your site once so any AI can use it. Since then the thing I was hand-waving at ("agents will check out for users") stopped being hypothetical. OpenAI shipped ACP and Google shipped AP2, and they solve the same problem in almost opposite ways. I implemented the merchant side of both. Here are the field notes, because the differences aren't obvious until you're in them. The 30-second version ACP (Agentic Commerce Protocol, OpenAI + Stripe) is session-based. The agent drives a live checkout session on your server, like a headless cart. It powers ChatGPT's Instant Checkout. AP2 (Agent Payments Protocol, Google) is mandate-based. Your store signs a "here is the cart and the price" object; the buyer's agent signs a "I authorize this" object. It leans on verifiable credentials and now the FIDO Alliance. Same goal. Completely different shape. ACP: a checkout session you don't own the UI for ACP is five REST endpoints and a state machine. The agent creates a session, updates it (address, shipping, coupon), and completes it: POST /checkout_sessions create from line items POST /checkout_sessions/:id update (address, shipping, discounts) POST /checkout_sessions/:id/complete pay What you return is a CheckoutSession: line items, live shipping options, and totals broken out (subtotal, discount, fulfillment, tax, total). Money is integer minor units (330 = $3.30). Payment completes when the agent hands you a Shared Payment Token and you charge it through Stripe. The card never touches the agent. The mental model: it's your existing checkout, minus the browser. AP2: sign the cart, don't run the session AP2 has no session. The agent sends you an Intent Mandate ("a red basketball shoe, under $120"). You price it and return a Cart Mandate you have cryptographically signed: { "contents" : { /* a W 3 C PaymentRequest: items , total , currency */ }, "merchant_authorization" : "<RS256 JWT>" // iss , sub , aud , exp , jti , cart_hash } That JWT is a

The bug reports all sounded the same. "It disconnected again." No error, no warning, nothing on screen to explain it. Someone would open a GitHub issue, start a planning-poker vote, then stop to actually read the thing they were estimating. Thirty seconds later they'd look back and the room had quietly gone still. Other people's votes weren't showing up, and their own weren't reaching the room. It had simply stopped, without a word. If you've ever built anything real on Chrome's Manifest V3, you can probably guess where this is going. The socket didn't drop because the network hiccupped. It dropped because Chrome reached over and killed the process it was living in. This is the story of that bug, and what it actually takes to keep a WebSocket alive inside a Manifest V3 extension. TL;DR: Manifest V3 runs your background code in a service worker that Chrome terminates after ~30s idle. If your WebSocket lives there, it dies with it, silently. The fix is three parts: a heartbeat so extension activity keeps the worker awake, auto-reconnect that pulls a fresh snapshot so drops are invisible, and a try/catch around every port message because the worker can die between your null-check and the call. Why the socket doesn't live where you'd expect First, some context on how the extension is wired, because it explains why this bug was even possible. It puts a button on GitHub issues and boards. Click it, and a live planning-poker room opens right there in the page. Votes flow over a WebSocket to a Cloudflare Durable Object that owns the room's state. Standard real-time stuff. The obvious place to open that socket is the content script, the code injected into the GitHub page. That's where the UI lives, so why not open the socket right next to it? Firefox is why not. A content script runs in the page's world, which means it inherits the page's Content Security Policy. GitHub ships a strict connect-src , and Firefox enforces it against content scripts. Try to open wss://… from the

When a learner finishes a course they want a certificate that behaves like a document: something they can print at full quality, attach to a job application and that an employer can check is genuine. In this tutorial you'll build exactly that in Laravel: a Blade-designed certificate rendered as a vector PDF, with a QR code that resolves to a verification page and an email that delivers it automatically. This post originally appeared on Accreditly as How to generate verifiable PDF certificates in Laravel . Keep the design in Blade The certificate is an ordinary Blade view. Everything lives in one file, styles inline, so the markup you preview in the browser is exactly what gets rendered. If you want a designed starting point rather than a blank page, the certificate of completion template is a good base to adapt. {{-- resources/views/certificates/template.blade.php --}} <!doctype html> <html> <head> <meta charset="utf-8"> <style> body { font-family: Georgia, serif; color: #1a2233; margin: 0; } .certificate { padding: 60px; border: 6px double #b28a2f; margin: 24px; text-align: center; } .heading { font-size: 15px; letter-spacing: 4px; text-transform: uppercase; color: #b28a2f; } h1 { font-size: 44px; margin: 24px 0 8px; } .course { font-size: 22px; margin: 4px 0 28px; } .issued { font-size: 15px; color: #5a6478; } .qr { margin-top: 36px; } .verify-url { font-size: 12px; color: #5a6478; } </style> </head> <body> <div class="certificate"> <p class="heading">Certificate of Completion</p> <h1>{{ $certificate->user->name }}</h1> <p class="course">has completed {{ $certificate->course }}</p> <p class="issued">Issued {{ $certificate->issued_at->format('j F Y') }}</p> <div class="qr"> {!! QrCode::size(110)->generate(route('certificates.verify', $certificate)) !!} </div> <p class="verify-url">{{ route('certificates.verify', $certificate) }}</p> </div> </body> </html> Two things are doing quiet work here. The design flows like a document rather than being pinned to fixed pixel

Your resume tells people what you’ve done. Your GitHub shows what you’ve built. But your personal website tells people who you are. When I started learning web development, I believed that a good resume and a few GitHub repositories were enough. Like many students, I spent countless hours building projects, solving coding problems, and learning new technologies. Every new project felt like a milestone, yet all of them remained scattered across different platforms. A recruiter would have to open my resume, visit my GitHub, search for my LinkedIn profile, and perhaps never even discover the articles I had written or the experiments I had built. That made me realise something important. Developers need a place on the internet that they truly own. Not another profile. Not another social media account. A place that represents their identity, work, and journey. That’s what a personal website becomes. More Than Just a Portfolio Many people hear the words personal website and immediately think of a portfolio with a few screenshots and a contact form. A great developer website goes much further. It answers questions before anyone has to ask them. Who are you? What technologies do you enjoy working with? What problems have you solved? What kind of developer are you becoming? What have you learned recently? How can someone reach you? Instead of forcing visitors to jump across five different platforms, everything exists in one carefully designed experience. Your Name Deserves a Home Every developer works hard to build projects. Very few work equally hard to build their own identity. When someone searches your name, what should they find? Ideally, the very first result should be something you completely control. A website with your own domain isn’t just another webpage. It’s your digital home. Unlike social platforms, algorithms cannot redesign your identity overnight. You decide what visitors see first. You decide which projects matter. You decide how your story is told. Resume