标签：#webdev

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. Okay so here's a fun one for you. Imagine you invent the thing that eventually becomes the substrate for Google, Facebook, Amazon, your bank, your ex's Instagram, and every cursed cookie consent banner known to man. Now imagine you had the legal right to charge a licensing fee for it. Like, a reasonable one. A cent per page load, say. You would never have to work again. Your great-great-grandchildren would never have to work again. You'd be sipping something expensive on a boat named after a HTTP status code. Tim Berners-Lee looked at that exact opportunity in 1993 and said, essentially, "nah, you guys keep it." This has been rattling around in my head for days, so let's talk about it properly, with all the nerdy details. The web almost lost to a gopher (literally) Berners-Lee built the World Wide Web in 1989 at CERN, laid out in a proposal called Information Management: A Proposal , mostly so physicists could stop emailing each other giant papers and just... link to things. Wild concept, I know. But here's the part people forget: the Web wasn't the obvious winner in the early 90s. It had a genuine rival called Gopher , built at the University of Minnesota, and for a while Gopher was winning. It was simpler, it was faster on the slow modems of the era, and it had a head start in adoption among universities and libraries. Then in February 1993, the University of Minnesota did something that, in hindsight, ranks among the great unforced errors in computing history: they announced they'd start charging licensing fees for commercial use of Gopher server software. Reasonable-sounding at the time (they needed to fund development), catastrophic in practice. The developer community, which had spent years contributing code for free on the assumption

People are starting to coin the term ADLC or Agentic Development Lifecycle. A lot of this seems to be combining two things: Day-to-day software engineering has completely changed from a process perspective Bottlenecks in the traditional SDLC are starting to show I don't think we need yet another acronym, but let's talk about how things are changing in general and what some of the bottlenecks are. We don't work on a single task anymore One of the overarching changes, leading to an explosion in lines of code, merge requests and more, is that the cost of software engineering has dramatically decreased. So much so that all of us can now do the job of multiple engineers without hiring them. As part of this change, our daily workflows have changed completely. We no longer open an IDE and work on a single task, start to finish. Instead, our roles have become a lot more exploratory and, quite frankly, fun. My workflow, for example, has shifted towards opening multiple chat sessions, often separate threads on the same topic. I get to spar like some sort of boxer with AI over a few variations of how I've been looking at the same problem. After a while, I'll start to narrow that down to one or two threads containing the desired architecture or strategy to solve the goal. From that point, I'm running this smaller set of agents end-to-end with validation criteria until a passing merge request is opened for each. Running this same process in parallel across 3-4 topics leads to 8-10 merge requests within a day . And because this process has become so easy, these merge requests are often meaty. Not just one-liners. Previously, you'd dedicate your day to working on a particular problem over a longer horizon, whereas now the amount of output (whether it's valuable output or not) has dramatically increased. If you frame software engineering as problem solving, where most problems contain local minima, not absolute minima (a metaphor about gradient descent) , then the really fun part i

The first collaboration model in CodeVerse was convincing in exactly the way a local demo needs to be convincing. Open two tabs. Join the same room. Type in one editor. Watch the other editor update. Then ask one unpleasant question: what happens when those two sockets land on different server instances? The answer was that the room stopped being a room. Each process had its own memory, its own presence list, and its own idea of the current files. A restart erased state. A reconnect could create a second identity. A load balancer could turn a working demo into two isolated conversations. This article is about the work that followed: moving CodeVerse from synchronized tabs to a collaboration path I could test across processes, recover after disconnects, and describe without pretending a local benchmark was a production capacity claim. The real boundary was not Socket.IO Socket.IO made connection handling and room fan-out approachable, but it did not decide where truth lived. That distinction matters. A room name inside one Socket.IO process is a routing convenience, not durable shared state. Once I wanted multiple application instances, I needed separate answers for four kinds of information: Document state — the convergent contents of every file. Room policy — organizer identity, edit permissions, active file, and revision. Presence — which sockets are here now, on which instance, with which effective role. Durability — what survives Redis expiry, application restarts, or a longer period of inactivity. CodeVerse now uses Yjs for convergent document updates, Redis for live distributed room state and pub/sub, and Supabase for durable room snapshots and membership data. Socket.IO remains the transport and fan-out layer. That separation was more important than any individual library choice. Redis does three different jobs It is easy to say “I added Redis” and leave the architecture vague. In CodeVerse, Redis has three explicit responsibilities. 1. Cross-instance fan-out

Every Angular application I have worked on in the last few years had the same three kinds of state: URL state — the page number, the active filter, the selected tab. Client state — what the user typed, what is expanded, what is selected. Server state — the thing you fetched, and everything that can go wrong while fetching it. And every application handled them three completely different ways. ActivatedRoute and a Router.navigate call for the first. Signals or a store for the second. A service returning an Observable , plus a loading boolean, plus an error field, plus a subscribe somewhere, for the third. None of that is wrong. It is just that the glue between them is written by hand, in every app, every time. And the glue is where the bugs live. This article is about the specific piece of that problem I could not let go of, and about the toolkit I ended up building around it. It is called craft-ng , it is in beta, and I would genuinely rather have your objections than your stars. The code I kept running into Here is the shape. I should be honest: I did not write much of it myself — I had a drawer of RxJS helpers that hid most of it. But I have read it in a lot of codebases, reviewed it in a lot of pull requests, and inherited it in a lot of projects. That turned out to matter more, because a helper that only I understand is not a solution to anything. @ Injectable () export class TaskListService { private http = inject ( HttpClient ); tasks = signal < Task [] > ([]); isLoading = signal ( false ); error = signal < string | null > ( null ); load ( done : boolean ) { this . isLoading . set ( true ); this . error . set ( null ); this . http . get < Task [] > ( `/api/tasks?done= ${ done } ` ). subscribe ({ next : ( tasks ) => { this . tasks . set ( tasks ); this . isLoading . set ( false ); }, error : ( err ) => { this . error . set ( ' Something went wrong ' ); this . isLoading . set ( false ); }, }); } } Four fields, one method, and roughly six ways to get it subtly wr

The people who make open source work aren't just the ones writing code. Some of them write the words that make the code make sense. I spent years assuming open source was a closed door. Every time I opened GitHub, I felt like I'd wandered into a conversation being held in a language I hadn't studied. Pull requests, forks, issues tagged with words like "good first issue" that somehow still felt intimidating. I closed the tab more times than I can count, convinced that space belonged to people who could write functions, not people who could write sentences. It took me longer than I'd like to admit to realize how wrong that assumption was. The myth that keeps people out Open source has a branding problem, and it's an ironic one for a movement built on collaboration. The public image is almost entirely code: commits, merges, terminals, lines of syntax scrolling past on a dark screen. That image is accurate, but it's incomplete. It leaves out the writers who make a tool's documentation actually usable. It leaves out the designers who turn a clunky interface into something people want to use. It leaves out the community managers who keep a project from imploding when a disagreement gets heated. It leaves out the translators, the testers, the people who write the first draft of a README at 11pm because nobody else got around to it. If you've stayed away from open source because you don't code, you've been kept out by a myth, not a rule. What non-developers actually do in these projects Documentation is the most obvious entry point, and it's also one of the most needed. A huge number of open source projects are built by people who are excellent engineers and mediocre explainers. That's not a criticism, it's just a different skill. Someone can write brilliant code and still produce a setup guide that only makes sense to the person who wrote it. Projects need people who can sit with a piece of software as a genuine beginner would, notice where the instructions fall apart, and

I am testing my first automated end to end social media post automation system. which is created using the free tools. But it is very efficient and productive. i can use this thing in future posting on various platforms to tell people about my learning's and update about me. Tools : Make.com = I use this tool to mainly automate my system it include flow how things works and system is linked. Hashnode = I use this as a central blog and article publishing tool other tools is connected with it so content links is properly distributed. Google Ai Studio = I use this to integrate the ai in between this whole process which just do small job to add the engaging hook and the tags for the reach Buffer = I use to connect X (twitter) with this Because Make.com remove the platform X (twitter) to His integration. After the policy change of the platform. Dev.to = I use this to improve SEO of my post over the google search engine. Challenges : I cannot integrate the github actions with the hashnode becuase this feature is become paid on hashnode. May be in future i can do this thing using self written yml file, i am guessing Not sure will this 100 % work or not. Twitter integration as i described early that twitter integration is not present in the make.com so i use the another tool Buffer. The limits calculation, Their was a limits on each tools for their specific use case so i have to intentionally calculate them properly. Even the free tear of the twitter which is X is few hundreds words that's why i have to limit the text of the post, which is hook only, The threads creation i don't think it will be their in this tools which i am using, i will definitely find it if their. Solutions : Simply use other Way if this way is closed, use different tool for twitter May be in future i create yml file for the github actions but for now i am directly writing on hashnode. The dev.to does not provide feature of direct posting it save your cycle into draft so you have to manually click on pu

Modern AI UX — chat panels, tool-calling agents, assistants that remember context and even suggest your next step — has lived in JavaScript SaaS for years. The Java enterprise stack has been left doing it the hard way. TabForge AI closes that gap . It's a complete platform for building AI-powered web apps on Jakarta EE + PrimeFaces — from the multi-tab UI shell down to a clean, provider-agnostic AI layer. Library, live demo, starter project, and a drop-in UI template — all shipped. Here's the whole thing, top to bottom. ## 1. Tabs as annotated beans — DynTabs You describe a tab; the framework handles opening, closing, lifecycle, and state. Each open tab gets its own isolated CDI bean via a custom @TabScoped scope. @Named @TabScoped @DynTab ( name = "OrdersDynTab" , uniqueIdentifier = "Orders" , title = "Orders" , includePage = "/WEB-INF/orders.xhtml" , trackActivity = true ) public class OrdersBean extends BaseDyntabCdiBean { // open the same tab twice → two independent instances } java No manual navigation, no page-state juggling. Open a tab, get a bean; close it, it's gone. A clean AI layer — EasyAI One fluent entry point over LangChain4j. Chat, tools, agents, and structured extraction — provider-agnostic, so the model behind it is a config detail. // A typed assistant with a business service exposed as tools OrdersAssistant ai = EasyAI . assistant ( OrdersAssistant . class ) . withTools ( orderService ) . build (); String reply = ai . ask ( "cancel order ORD-002" ); You opt methods in as tools explicitly — no accidental exposure: @EasyTool ( "Cancels an active order" ) public String cancelOrder ( String orderId ) { ... } Deterministic pipelines — flow() Agents are powerful but unpredictable. When you want a repeatable, testable process, flow() lets you own the steps and call the model only at the edges that actually need language: EasyAI . flow () . step ( "understand" , ctx -> EasyAI . extract ( OrderRequest . class ). from ( ctx . inputText ())) . step ( "check

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . 🍩 Inspiration I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything. The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay. That's how Donut Panic was born. 🎬 Demo Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate. 🛠️ Journey No JavaScript is driving the donut — :has() is Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label> s wired to hidden inputs. No click handlers, no state management — the checkbox is the state. JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine. Building the donut from the inside out The donut itself is layered rings, not a single flat shape: A base dough circle with a radial gradient doing double duty as both c

Cybersecurity is entering a new phase. This is because security teams are facing more and more complex problems and threats that are moving faster. To help defenders respond more effectively, OpenAI has introduced GPT-5.6-Cyber, a special model designed for advanced cybersecurity tasks. The model supports authorized security research, vulnerability discovery, and other defensive workflows. The Daybreak program is showing how specialized AI tools can improve modern cybersecurity by working together with human security experts. Quick overview GPT-5.6-Cyber is a specialized model for authorized cybersecurity work. It is available through OpenAI’s Daybreak Red access for approved defenders. OpenAI reports a 95% completion rate on its internal advanced cybersecurity evaluation. The model helped researchers uncover vulnerabilities in Chrome’s V8 JavaScript engine. Controlled access, monitoring, and human oversight remain important for safe deployment. What Is GPT-5.6-Cyber? GPT-5.6-Cyber is OpenAI’s cybersecurity-specific model, available through Daybreak Red. Built on GPT-5.6 Sol, it is trained to improve performance on specialized cybersecurity tasks such as finding zero-day vulnerabilities and developing exploit chains, while reducing refusals for certain higher-risk, dual-use cyber tasks. Daybreak has two access tiers: Daybreak Blue provides approved defenders with frontier general-purpose models such as GPT-5.6 Sol, with safeguards tailored to authorized defensive security work. Daybreak Red provides purpose-trained cybersecurity models for authorized vulnerability research, exploit validation, and security testing. This approach reflects a significant shift toward security tools designed for professional cybersecurity environments rather than unrestricted public use. The goal is clear: to help trusted defenders investigate vulnerabilities, analyze potential threats, and respond to security incidents more effectively while keeping access controlled. According to Open

TL;DR — Events in Fitz LiveViews carry data three ways: a click payload ( data-flv-value-* ) tags a button with the value it should send; a form submit ( data-flv-submit ) reads the form's named inputs; and a live value ( @input / @change ) delivers a control's current value in payload["value"] . All three land in the same place — a payload map your handler reads. This post builds a live name list (add / remove / count) that runs both server-rendered and as WebAssembly. (Part 3 of the FitzLiveViews series.) Parts 1 and 2 covered the pitch and the counter. A counter only reads +1 / -1 — no data flows in . Real UIs take input: text, selections, form fields. Here's how that data reaches your handlers. The payload Every event handler has a payload in scope — a Map<Str, Str> . The three mechanisms below all fill it; your handler reads it with payload["key"] (guard with payload.has("key") ): 1. Click payload — a button that carries a value Tag any element with data-flv-value-<key>="{expr}" , and when a data-flv-click on it (or an ancestor) fires, that value rides along: <button data-flv-click= "remove" data-flv-value-item= "{it}" > × </button> event remove () { if ( payload . has ( " item " )) { let target = payload [ " item " ] names = names . filter ( fn ( it ) => it != target ) } } The delete button knows which row it is because the row's value is stamped on it. No IDs threaded through a callback, no closure capture. 2. Form submit — the whole form at once data-flv-submit="handler" on a <form> reads each named input into the payload on submit; data-flv-clear resets a field afterward: <form data-flv-submit= "add" > <input name= "item" placeholder= "Add a name" data-flv-clear /> <button type= "submit" > Add </button> </form> event add () { if ( payload . has ( " item " )) { let n = payload [ " item " ] if ( n != "" ) { names . push ( n ) } } } payload["item"] is the input's value at submit time. No preventDefault , no FormData , no fetch . 3. Live value — @input / @chang

Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the...

A free AI visibility score is auditable only when you can inspect the prompt, engine, raw answer, date, and denominator. Treat the score as a test result, not a property of your brand. This tutorial builds a six-check control you can run by hand, store as plain data, and compare with any tool's output. The workflow takes three buyer questions, runs them in two AI surfaces, and records the six answers without trying to force agreement. It will not estimate your entire market. It will tell you whether a dashboard's headline number has enough evidence to be investigated. What does an AI visibility score measure? An AI visibility score usually summarizes brand presence across a defined set of generated answers. That definition contains the trap: the question set is part of the metric. So are the engine panel, run date, session state, retrieval mode, and rule used to count a “hit.” Remove those inputs and the number is not reproducible. Imagine a tool asks three questions in two engines. That creates six cells. If your brand appears in two cells, the simple presence result is: presence = brand_present_cells / total_cells presence = 2 / 6 presence = 0.333... = 33.3% The arithmetic is trivial. The evidence is not. A different tool can ask five different questions in three engines and produce a different score without contradicting the first run. The two tools measured different grids. Keep the unit explicit: “present in two of six generated answers on this date” is defensible. “Our AI visibility is 33” is incomplete. Which evidence fields should you require? Require five fields for every result: prompt, engine, raw answer, timestamp, and counting rule. Use a sixth field for cited sources when the surface exposes them. A source-only appearance and a prose mention can signal different problems, so do not merge them silently. Here is one real saved result from Webappski's public 14 June 2026 tracker report: { "run_date" : "2026-06-14" , "prompt" : "beste Answer Engine Optimiz

Why a live payment is not a release test The riskiest way to test a SaaS checkout is to make a real payment to yourself. It feels reassuring: the live checkout opened, the card worked, the webhook fired and the refund came back. But that proof mixes engineering QA with revenue evidence. Three different proofs A cleaner billing release process separates three questions: Does billing behave correctly? Test payment, refund, webhook and subscription edge cases in a Stripe sandbox. Is production configured correctly? Verify the live price, currency, checkout destination, webhook configuration and deployed revision without moving money. Did a customer pay? Treat a genuine live transaction as customer activity and revenue evidence, not as an engineering fixture. Stripe documents sandboxes as isolated testing environments and separates sandbox credentials from live credentials. The practical lesson is broader than Stripe: operational proof and commercial proof should not share the same transaction. A useful boundary Use this sequence: Sandbox QA → read-only production verification → genuine customer payment . It keeps release evidence, reconciliation and revenue numbers easier to interpret. We recently tightened the same boundary in VendorOS. That does not prove live customer revenue; it is a workflow lesson about keeping evidence categories separate. If your release process still requires a live self-payment, ask which part of the verification can become read-only. Sources: Stripe Sandboxes Stripe API keys Stripe testing VendorOS release boundary

I Built a Cinematic Developer Portfolio Instead of a Traditional One — Here’s What I Learned Most developer portfolios follow the same structure: About. Skills. Projects. Contact. There is nothing wrong with that. But when I started rebuilding mine, I wanted it to feel less like a collection of sections and more like an experience . So what started as a simple portfolio redesign slowly turned into a cinematic, interactive developer portfolio built around my journey as a Software Engineer and AI Developer . 🌐 Live Portfolio: https://pavan-sai-portfolio-xi.vercel.app The Idea I wanted the visitor to feel like they were entering a story rather than opening another resume website. The final experience includes: A cinematic opening sequence A custom soundtrack Full-screen scene-based navigation Animated video backgrounds Project showcases and case studies A personal journey timeline Responsive mobile layouts A cinematic closing scene Smooth transitions between sections The overall visual direction is built around: Black + Champagne Gold + Cinematic Lighting The Portfolio Flow The experience follows a sequence: Intro → Pavan Sai → Hero → About → Skills → Projects → Journey → Contact → Closing Credits Instead of normal vertical scrolling, the main portfolio behaves more like a sequence of scenes. Visitors move through the experience using navigation controls. Project case studies are separate and can scroll normally because they contain more detailed technical information. The Projects Some of the projects featured in the portfolio include: DevPilot AI An AI-powered DevOps incident recovery platform focused on detecting failures, diagnosing issues and helping recover production systems. ROCmPorter Agent An AI-assisted CUDA-to-AMD ROCm migration tool that analyzes repositories, identifies CUDA dependencies and helps generate migration changes. HunarHub A local skilled-worker discovery and service marketplace platform. I also showcase other engineering, AI and full-stack pro

WordPress sitelerinde hız problemi yaşandığında genellikle ilk refleks bir cache eklentisi kurmak oluyor. Bazen gerçekten fark yaratıyor, bazen de PageSpeed puanı biraz yükselmesine rağmen site hâlâ yavaş hissettiriyor. Bunun nedeni WordPress performansının tek bir ayardan oluşmaması. Hosting, tema, eklentiler, görseller, JavaScript dosyaları ve veritabanı aynı anda sayfanın yüklenme süresini etkileyebiliyor. Bu nedenle bir siteyi hızlandırmaya başlamadan önce asıl problemin nerede olduğunu bulmak gerekiyor. WordPress projelerinde sık karşılaştığım 7 performans hatasını aşağıda topladım. Gereğinden büyük görseller kullanmak En sık karşılaştığım problemlerden biri bu. Sayfada 700 piksel genişliğinde görüntülenecek bir görselin 4000-5000 piksel olarak yüklenmesi oldukça yaygın. Özellikle yüksek çözünürlüklü stok fotoğraflar doğrudan WordPress'e yüklendiğinde tek bir görsel birkaç megabayta ulaşabiliyor. Bu da özellikle mobil bağlantılarda ciddi yük oluşturuyor. Görselleri yüklemeden önce kullanılacağı alana uygun boyuta getirmek, sıkıştırmak ve mümkün olduğunda WebP veya AVIF gibi modern formatları tercih etmek önemli. Ancak yalnızca dosya formatını değiştirmek yeterli değil. 4000 piksel genişliğindeki bir görseli WebP'ye çevirmek, görselin gereğinden büyük olduğu gerçeğini değiştirmiyor. Her problemi cache eklentisiyle çözmeye çalışmak Cache WordPress performansında önemli bir yere sahip. Fakat cache eklentisi kurmak her hız problemini ortadan kaldırmaz. Sunucu geç cevap veriyorsa, çok fazla JavaScript çalışıyorsa veya veritabanında ağır sorgular varsa cache yalnızca problemin bir bölümünü gizleyebilir. Ayrıca aynı anda birden fazla optimizasyon eklentisi kullanmak da başka sorunlara yol açabiliyor. Örneğin bir eklentide JavaScript erteleme, başka bir eklentide tekrar JavaScript optimizasyonu ve hosting panelinde üçüncü bir optimizasyon sistemi açıldığında hangi ayarın ne yaptığını takip etmek zorlaşıyor. Ben mümkün olduğunca tek bir ana cache sistemi üzerinden ilerl

A few years ago, a technical interview mostly tested one thing: can you write correct code, from memory, under pressure. That bar has quietly shifted — and a lot of developers preparing for interviews right now haven't fully clocked it. AI coding assistants are part of daily work at most companies now, from big IT services firms to small product teams. Interview panels have adjusted to that reality faster than most prep guides have. What's actually different now Interviewers care less about whether you can produce a function from scratch, and more about whether you understand what code is doing and why. It's increasingly common to be handed a piece of AI-generated code and asked to find the bug, justify a design decision, or optimize it — instead of writing something from zero on a whiteboard. Some companies go further and let you use AI tools during the technical round, then evaluate how well you direct the tool, verify its output, and catch its mistakes. The skill being tested has moved from "can you write code" to "can you reason clearly with code as your material." Three things I keep seeing candidates get wrong Treating a finished course or degree as the finish line. Completing a syllabus tells an employer you were exposed to concepts. It doesn't tell them you can apply those concepts to a messy, real-world problem — which is exactly what open-ended interview scenarios are designed to expose. Leaning on AI tools without understanding the output. Using an AI assistant while practicing at home is fine. The problem shows up when that habit surfaces in a live interview as an inability to explain your own solution. If you can't walk through why a piece of code works, a couple of follow-up questions will make that obvious fast. Underrating communication and debugging skills. As AI tools take on more initial code-writing, the human value shifts toward reviewing, debugging, and explaining decisions to teammates. Candidates who only practiced writing code — and never pr

Spent the week redesigning my portfolio’s blog layout and nuking thousands of stale notes in my Obsidian vault. Between the UI polish and some deep dives into libp2p DHT de-flaking, I pushed 36 commits and managed to delete almost 16,000 lines of clutter. TL;DR I’ve always believed that your digital space needs a good pruning every now and then to stay healthy. This week was the embodiment of that philosophy. I pushed 36 commits across four primary projects, resulting in over 23,000 additions and nearly 16,000 deletions. Most of that churn came from a massive redesign of my portfolio's blog and a long-overdue "fresh start" for my Obsidian vault. On the open-source side, I spent some quality time in the weeds of py-libp2p , chasing down flaky DHT tests and proposing better subnet diversity limits. What I Built Portfolio Redesign: The Typography Pivot My main focus this week was my portfolio. I’ve been feeling like the blog layout was getting a bit cluttered, so I opened and merged PR #15, which was all about "typographic hierarchy instead of decoration." I’m moving away from unnecessary borders and boxes and letting the type do the heavy lifting. I spent a lot of time in components/blog and app/blog refining the layout. I implemented borderless filter pills and full-width rows to give the content more room to breathe. One of the bigger technical shifts was moving the blog list to be fully server-rendered. It feels snappier, and it allowed me to implement more "honest" dates and better hover states on the rows. I also added a real focus ring for accessibility (because we’ve all been frustrated by keyboard navigation that feels like a guessing game). By the time I was done, I’d touched over 200 files in that repo alone. The Obsidian Purge I also took a metaphorical chainsaw to my obsidian-vault . I nuked nearly 10,000 lines of stale content. I removed entire directories for "Projects," "Rust," and "Backend" notes that were just gathering digital dust. It’s easy to let

Most "AI gift finders" are a search box with a chatbot glued on. I wanted to build something different — a quiz-driven gift recommender that ranks real Amazon products by who the recipient actually is , not just keywords. I call it GiftHive . In this post I'll walk through the architecture, the conversion tricks I learned shipping it, and the bits I'm proudest of. The Problem Picking gifts is emotionally expensive. You scroll Amazon for an hour, second-guess every option, and end up buying a gift card. Existing tools don't help because they optimize for keyword match , not recipient fit . GiftHive flips the input: instead of "show me gifts under $50", you answer a 30-second quiz about the person (relationship, interests, occasion, budget) and get a ranked shortlist with explanations of why each gift fits. Stack Next.js (App Router) — SSR for fast first paint, RSC for product data Tailwind CSS — design system + dark mode via CSS variables Cloudflare Pages — edge-deployed, free tier covers the traffic Amazon Associates — affiliate revenue model The Funnel The whole site is a 3-step conversion funnel: Landing page — exit-intent modal + social proof toasts prime the visitor Quiz — 30-second, one-question-per-screen flow, no login Results — ranked products with countdown bar and "X people found gifts this week" social proof Every step has a single primary CTA. The exit-intent modal is route-aware — it only fires on / and stays silent on /quiz and /results so it never interrupts the funnel mid-flow. That bug cost me ~15% of quiz completions before I caught it. Personalization Logic Each quiz answer maps to a vector of attributes (interests, style, budget, relationship). Products in the catalog have matching tags. Ranking is a weighted score: score = tag_overlap * w1 + budget_match * w2 + occasion_match * w3 No ML model needed — a few hundred products and clean tagging is enough to feel personal. Amazon Affiliate Integration Every product link runs through getAmazonUrl() w

I was watching The Mandalorian the other day when it struck me that I don't know Pedro Pascal, which...

Say "AI" in a room full of developers and a pecking order forms on its own. Python sits at the top,...