Bits, Chips and Everything Tech

I’ve officially crossed a line: I’m addicted to vibe coding. Not the lazy kind. Not the “let the AI do everything while I dissolve into the couch like a forgotten penny.” I mean the kind where you’re building faster, thinking sharper, and finishing side projects that used to sit in the graveyard of half-started repos. And the tool that kicked this into overdrive for me? Happy — a mobile + web client that lets you run and control Claude Code or Codex from anywhere , with end-to-end encryption and a clean “just works” setup. GitHub This is the piece I didn’t know I was missing: plan anywhere. Why this changes the side-project equation Side projects don’t fail because we’re not smart. They fail because life eats the schedule. You get your best idea: while walking the dog in bed after a long day out on the town when your brain suddenly decides to be brilliant And then the idea evaporates because your laptop isn’t open, your environment isn’t ready, or your energy win...

 I didn’t expect my infrastructure choices to teach me anything about human relationships. Then I started living in Kubernetes-land long enough to notice a weird truth: Good systems and good relationships fail for the same reasons—and succeed for the same ones. This is not a rigorous scientific claim. This is a developer’s field notes from the strange little overlap between love and distributed systems. 1. Clear boundaries prevent chaos Kubernetes is obsessed with boundaries. Namespaces, RBAC, network policies—everything is designed around the idea that you shouldn’t casually wander into places you don’t belong. Relationships work that way too. Healthy connections don’t happen because there are no boundaries. They happen because boundaries are clear, respected, and negotiated with care. Ambiguity is where systems and hearts both start throwing exceptions. 2. Least privilege is kindness In software, least privilege is a safety measure. In relationships, it’s also kindness...

I used to think security was the part of the project you add when you’re done building the real thing. Like sprinkles. Or a seatbelt you buckle right before the crash. Now I think security is closer to care. Not the performative kind. The quiet, boring, deeply meaningful kind. When you build something people trust with their private lives—especially anything touching intimacy, relationships, or identity—you’re not just shipping features. You’re creating a space where humans are allowed to be soft without consequences. That’s a big deal. And it’s why I’ve started thinking of security as a kind of love language in software. It’s how you communicate: “I considered your worst day.” “I protected you when you weren’t thinking about it.” “I didn’t assume you’d read the fine print.” The shift The mindset change wasn’t a single epiphany. It was a slow accumulation of “oh wow, that would be awful.” A leaked token isn’t just a bug. It’s someone’s trust evaporating. A sloppy audit ...

I wanted to share something I built. I managed to connect SWE-agent with my self-hosted GitLab so that Issues can drive automation—and I think it’s kind of cool. (Currently, it isn’t directly supported in SWE-Agent, but there is an issue ( https://github.com/SWE-agent/SWE-agent/issues/760 ) on GitHub to add support. Why wait? ^_^) I’ve been tinkering with SWE-agent in the homelab while between roles. SWE-agent doesn’t natively support GitLab, but that wasn’t going to stop me—I wired it into my self-hosted GitLab instance so Issues drive the automation end-to-end. The Flow I Built 1. Start with an Issue. When I create an Issue, I describe the task in plain language. For example: “create `/taylor-swift` route that responds with JSON key lucky=13.” 2. Label the intent. Add the label `run:swe` and tag the model (in my case: `model:qwen3-coder-30b-a3b-instruct` from LM Studio). There is also a label swe:in-progress so that the pipeline does not pick up in-progress issues. If the pipeline ne...

This guide is a pragmatic, production-minded checklist and how-to for hardening a SvelteKit landing site so it’s discoverable by search engines, understandable by AI crawlers, and delightful on modern devices. It includes file locations, example contents, and verification steps. Everything here works even if you only have a single landing page today. Branding note: this document uses a fictional brand (“Example Store”) and domain (example.com). Replace these with your own values when you implement. Quick To-Do Checklist • Serve a real XML sitemap at /sitemap.xml and reference it in robots.txt. • Add a lightweight, server-rendered /search?q=… endpoint (backs JSON-LD SearchAction). • Place ai.txt (allow/deny AI crawlers) and .well-known/security.txt (vuln-reporting). • Wire canonical Open Graph/Twitter tags and og.png for social previews. • Add platform icons (apple-touch-icon.png, safari-pinned-tab.svg) and site.webmanifest. • Harden app.html with meta theme-color (light/dark), color-sc...

This “what it is + how to” cheat‑sheet rounds up the patterns you see at big shops—implemented simply with Svelte, vanilla HTML, Tailwind, and daisyUI. 1) Skeleton Screens What it is: Placeholder UI that mimics the final layout while data loads. Reduces perceived wait time and layout shift. When to use: Lists, profile cards, dashboards, anywhere remote data drives the view. <!-- Svelte: skeleton component --> <!-- src/lib/SkeletonCard.svelte --> <script> export let rows = 2; </script> <div class="flex gap-3 items-start">   <div class="skeleton w-12 h-12 rounded-lg"></div>   <div class="flex-1">     {#each Array(rows) as _}       <div class="skeleton h-3 my-2"></div>     {/each}   </div> </div> <style>   /* If not using daisyUI .skeleton class, a minimal fallback: */   .skeleton { background: #e6e6e6; border-radius: .5rem; }   @media (prefers-redu...