I'm lucky to be in a role where I get to speak with a huge number of people. From CxOs and founders to fellow board members to practitioners from a very wide variety of industries, companies, and disciplines. This enables me to spot patterns. One thing I hear consistently: everyone thinks they are behind when it comes to AI.

But digging in one level deeper, I'm seeing something more interesting inside many organizations: AI adoption is becoming K-shaped

AI isn't just increasing productivity. It's increasing the variance in productivity between engineers.

Some engineers are enthusiastic adopters. Even if they haven't gone full gas town, they have mature harnesses set up, have adopted AI into most facets of their work, and are seeing real productivity gains. They're starting to trust the output, and as a result are fundamentally changing how they work.

Some engineers on the other hand have been very slow to adopt, or are not adopting at all.

What’s striking is that I see this pattern across a wide variety of organizations. Startups, large tech companies, traditional enterprises... almost everywhere outside AI-native companies. The divide often appears within the same team.

Some of the hesitation is understandable. I often hear valid concerns around topics like environmental impact. Sometimes it's fear, uncertainty, doubt. Many are skeptical of the output itself.

But I don’t think those factors fully explain what’s happening. I've talked to people who share those concerns but are still huge adopters, and others who have none of those concerns but still avoid using AI in their work. Company culture and seniority do not appear to be consistent factors.

Part of it comes down to mental plasticity and curiosity, sure. Change can be uncomfortable. But I think there's something deeper going on.

For many engineers, it comes down to how they think about coding itself and what impact that has on their identity.

For some people, and I am very much in this camp, coding has always been about outcomes. It's about solving a problem and building something useful. Code is a tool. We're builders.

For builders, coding agents have been an amazing accelerant. They allow us to move faster, try more ideas, and get more things into the world. As I said in a previous post, I'm having more fun than I've had in a long time.

But for others, code is a craft.

Writing clean, elegant code or honing an algorithm is part of who they are. Thinking deeply about implementation details is where they find joy. These engineers are artisans.

For this group, AI agents aren't just a productivity tool. In some ways they are literally destroying the part of coding artisans find joy in.

A builder looks at a project coded mostly (completely?) by an AI agent and says: "Look how fast I was able to solve this problem"

An artisan looks at the same project and says: "Sure, but look at the logic in this part of the code, and what is happening on line 181??"

I'm not sure what the future holds. The current range of plausible outcomes seems very wide. But the coding agent is not going back in the box. Software development has been changed forever, and it's very likely we're only getting started.

Do artisans adapt, finding joy in the architecture and systems they design for agents to implement? Will they prefer to use their skills in other industries or occupations?

Is AI creating a Builder-Artisan divide in software engineering? I'm genuinely not sure.

But the growing divide in how engineers are approaching AI feels like a conversation worth having. AI may not replace engineers, but it may change which engineers thrive.

What I do know is that we're in this together.

--jeremy

In my first post, I talked about why I built A Million Pixels. As I mentioned here, one of the most common questions I got after the launch was: what stack is this built on and who made those decisions? This post answers those questions.

Some context: The idea was mine, with no AI involved in the equation. The overwhelming majority of the code was written with agentic coding tools (primarily Claude Code and Codex). The stack reflects decisions made solely by me, mostly by the agent, or collaboratively. That last bit feels a little weird to write. I can cover the agentic workflow in detail in a future post if it's interesting to readers.

The Life of a Pixel

Here's a simplified view of the architecture:

                         ┌─────────────┐
                         │   Browser   │
                         │  (PixiJS)   │
                         └──────┬──────┘
                                │
                         ┌──────▼──────┐
                         │   Vercel    │
                         │  Next.js 16 │
                         └──┬───┬───┬──┘
                            │   │   │
              ┌─────────────┤   │   ├─────────────┐
              │             │   │   │             │
       ┌──────▼──────┐ ┌───▼───▼───▼───┐ ┌───────▼──────┐
       │   Stripe    │ │   Supabase    │ │  Replicate   │
       │  Checkout   │ │  (Postgres)   │ │  (AI Images) │
       └─────────────┘ └───────────────┘ └──────────────┘
                            │   │   │
              ┌─────────────┤   │   ├─────────────┐
              │             │   │   │             │
       ┌──────▼──────┐ ┌───▼───▼───┐  ┌──────────▼──┐
       │  Upstash    │ │  OpenAI   │  │ Cloudflare  │
       │   Redis     │ │ Moderation│  │     R2      │
       └─────────────┘ └───────────┘  └─────────────┘

Payment → generation → moderation → storage → canvas. That's the core loop. Everything else supports it.

The Stack at a Glance

Now let's dig into each one.

Hosting & Deployment

Vercel

This is the first decision I made, as it impacted so many other decisions. I considered Railway, Render and Vercel. They all looked compelling. In the end, Render and Railway looked more like the infra platforms I've used in the past, so I went with Vercel. I've since delpoyed apps on both Railway and Render, and both are solid. You should decide based on the strengths of each platform vs your needs (ie. Choose Vercel you're building a frontend-heavy site or using Next.js. Choose Railway if you need a fast, simple backend deployment and quick DB setup. Choose Render if you have a traditional full-stack app requiring a persistent server and want predictable costs.)

Vercel is the company behind Next.js, and the deployment experience reflects that. Push to a branch, get a preview deployment. Merge to main, get a production deployment. The developer experience really is great. Serverless functions, edge middleware, image optimization, and cron jobs are all built in.

Alternatives considered: Railway, Render

Core Framework

Next.js 16, React 19, TypeScript, Tailwind CSS 4, shadcn/ui

Next.js was the obvious choice for a project like this once I decided on Vercel. Server Components by default, the App Router, API routes, and middleware all in one framework. React 19 brings Server Actions and improved streaming, which simplify a lot of the data flow.

TypeScript was a collaborative choice, although one of the the Agents said using it "is non-negotiable for anything beyond a toy project. When you're collaborating with AI agents that generate a lot of code, type safety acts as a persistent guardrail. The compiler catches mistakes that neither you nor the agent noticed." What's interesting about this is that until I added an explict line about types to my CLAUDE.md and AGENTS.md, they constantly used "any".

Tailwind CSS 4 paired with shadcn/ui, was completely chosen by the Agents.

Alternatives considered: Remix, SvelteKit. Both are fine options, but once I decided on Vercel a lot of this just fell into place.

Database

Supabase (PostgreSQL with Row-Level Security)

Supabase gives you a managed Postgres database with a great developer experience: auto-generated REST APIs via PostgREST, real-time subscriptions, and built-in auth. I use it as a straightforward database — no ORMs, just the Supabase client with typed queries.

Row-Level Security (RLS) means the database itself enforces access rules. Even if you screw up an API route, the database won't return data the caller shouldn't see. It's defense in depth, and it's one of Supabase's strongest selling points.

Migrations are forward-only and backward-compatible by design. Every schema change has to work with both the current and previous code version, because code deploys can roll back but migrations can't. This is a discipline worth adopting early. Migrations are automatically handled by the CI/CD pipeline.

Alternatives considered: PlanetScale, Neon, raw Postgres. I've been looking for an excuse to trying Supabase in earnest and this was it.

Cache

Upstash Redis

Upstash provides serverless Redis, and has native Vercel integration. It's used for rate limiting, caching (including AI embedding results), and cross-instance coordination for things like circuit breaker state.

The per-request pricing model means you're not paying for idle connections. For a project with variable traffic, this matters more than you'd think.

Alternatives considered: Vercel KV (which is actually Upstash under the hood), Momento, DynamoDB. Upstash directly gives you the most control and the best pricing transparency. The Vercel 1 click made the decision for me.

Payments

Stripe Checkout

Stripe Checkout is a hosted payment page that handles the entire purchase flow. You redirect the user to Stripe, they pay, and you get a webhook when it's done.

For a project like this where the purchase flow is straightforward (select a block, pay $1/pixel, get an image), Checkout is ideal. It's PCI compliant by default, handles international payment methods, and the webhook model makes the backend integration clean and idempotent.

The Stripe API version is pinned to match the SDK's type definitions. This is a small thing, but it prevents subtle runtime bugs from API version drift.

Alternatives considered: I just chose Stripe, it's what I know. I works. It has great docs.

AI Image Generation

Replicate (SDXL, Flux 2 Pro)

This is the core of the product. A user writes a prompt, and an AI model generates a unique image for their block on the canvas.

I use Replicate as the inference provider because it gives you access to multiple models through a single API. The site currently supports two models — SDXL and Flux 2 Pro — with model selection driven by feature flags. This lets me A/B test different models and roll out new ones without code changes.

The generation flow is asynchronous: the API kicks off a prediction, and Replicate sends a webhook when it's complete. This decouples the user-facing request from the potentially slow generation step.

Alternatives considered: Running models directly on GPU instances (too expensive and complex to manage), DALL-E (good but less model flexibility), Midjourney (no API at the time I started building). This was a collaborative choice, as it was not an area I had much experience.

AI Embeddings

OpenAI (text-embedding-3-small)

Every prompt submitted to the site gets an embedding — a 1536-dimensional vector that captures the semantic meaning of the text. This powers semantic search and content discovery across blocks.

I chose text-embedding-3-small for the balance of quality and cost. Embeddings are cached in Redis with a content-addressed key (SHA256 of normalized text), so duplicate or near-duplicate prompts don't generate redundant API calls.

Alternatives considered: Cohere Embed, Voyage AI, open-source models via Hugging Face. I was already using OpenAI for moderation, so it didn't seem worth adding another service to the equation for this.

Content Moderation

OpenAI Moderation + Sightengine + Google Web Risk

Moderation is a three-layer system, because no single service catches everything, and I've learned the importance of automated moderation the hardway with LinuxQuestions.org.

1. Text moderation — OpenAI's moderation endpoint analyzes every prompt before image generation begins. It's fast, cheap, and catches the obvious stuff.
2. Image moderation — After an image is generated, Sightengine runs computer vision analysis across multiple categories (nudity, violence, etc.). Text moderation alone isn't enough because the same prompt can produce very different images depending on the model and seed.
3. URL safety — Any user-submitted URLs are checked against Google Web Risk to prevent phishing and malware links.

On top of these, there's a pattern-based detection layer for common jailbreak and prompt injection attempts. When detected, these route to manual review rather than auto-rejection — defense in depth without punishing false positives.

Each external moderation service has its own circuit breaker with exponential backoff. When a service degrades, new requests route to manual review instead of blocking users or silently skipping moderation. Circuit breaker state is persisted in Redis so it's coordinated across all serverless instances. I probably went overboard here, but again... lessons learned.

Alternatives considered: AWS Rekognition, Azure Content Safety, building everything with OpenAI's vision models. The multi-provider approach adds complexity but significantly reduces the risk of any single point of failure in moderation.

Object Storage

Cloudflare R2

Generated images need to live somewhere, and Cloudflare R2 is S3-compatible storage with zero egress fees. That last part is the key differentiator — for a site that serves a lot of images, egress costs on S3 or GCS add up fast.

The integration uses the standard AWS S3 SDK pointed at R2's endpoint. If I ever need to migrate to S3 or another S3-compatible service, the code changes are minimal.

NOTE: While I don't use the main Cloudflare service for A Million Pixels, they do donate the service to LQ and honestly the site wouldn't be viable at this point without it.

Alternatives considered: AWS S3, Vercel Blob, Supabase Storage. R2 won on cost (zero egress) and S3 compatibility.

Email

Resend + React Email

Resend handles transactional email — purchase confirmations, moderation notifications, and other emails. The standout feature is that email templates are written as React components using React Email, which means they live in the same codebase and use the same component patterns as the rest of the app.

If you've ever tried to maintain HTML email templates, you know how painful it is. React Email makes it dramatically better.

Alternatives considered: SendGrid, Postmark, AWS SES. Resend's developer experience and the React Email integration put it ahead for a project where I wanted to move fast. I've used most of the others, and Resend has been solid.

Canvas Rendering

PixiJS 8

The heart of the user experience is a 1000×1000 pixel canvas that renders all purchased blocks. That's potentially a million pixels of dynamically loaded, zoomable, pannable content. The DOM can't handle that — you need a WebGL renderer.

PixiJS is the most mature 2D WebGL rendering library. Version 8 brought a new architecture with better performance and a smaller bundle size. It handles the rendering loop, viewport management, and texture loading, while React manages the UI around the canvas. This was mostly decided by the Agents.

Alternatives considered: HTML Canvas 2D API (too slow at this scale), Three.js (overkill for 2D), Konva (not as performant for this use case).

Bot Protection

BotId + Cloudflare Turnstile

Two layers of bot protection that complement each other:

Cloudflare Turnstile is a CAPTCHA alternative that runs as a non-interactive challenge — users don't have to click anything or solve puzzles. It's verified server-side before any purchase is processed.

BotId provides client-side bot detection with browser fingerprinting. It catches automated browsers and headless clients that might bypass Turnstile.

Together they make it significantly harder for bots to abuse the purchase and generation flow without degrading the experience for real users. Have I mentioned lessons learned running LQ?

Alternatives considered: reCAPTCHA (worse UX), hCaptcha, building custom fingerprinting (too much effort for diminishing returns).

Authentication

GitHub OAuth via Supabase Auth

Authentication is only required for one flow: applying for AI credits. The site uses GitHub OAuth through Supabase Auth, which means users sign in with their GitHub account, and Supabase handles the token management, session refresh, and PKCE flow.

GitHub was chosen as the sole OAuth provider because the credit application is aimed at developers. It also allows deduplication — each GitHub account can only submit one application, and it's a reasonable check the submitted is human (for now?).

Alternatives considered: Google OAuth, email magic links, Clerk, Auth0. GitHub OAuth is the simplest option that serves the actual user base and had orthogonal benefits.

Observability

Datadog (APM, RUM, Logs, LLMObs) + OpenTelemetry

Observability is one of those things that's easy to skip in a side project and then regret when something breaks at 2 AM. This project is instrumented more thoroughly than most production apps. I work at Datadog and in a previous role had a terrible on-call life. You can see how I made a lot of these decisions.

• APM — Distributed tracing across all API routes and external service calls, powered by dd-trace and OpenTelemetry.
• RUM — Real User Monitoring captures frontend performance, errors, and user sessions in the browser.
• Logs — Structured logging with automatic PII redaction, shipped to Datadog for correlation with traces.
• LLMObs — Datadog's LLM Observability tracks every AI call (moderation, generation, embeddings) with input/output, latency, and cost.
• Monitors and SLOs — Defined as code and synced to Datadog via scripts, so alerting configuration lives in the repo alongside the application code.
• Feature Flags - Feature flags control which AI model is used for generation and are used for A/B testing UI variants.

OpenTelemetry provides the instrumentation standard, and dd-trace handles the Datadog-specific export. The Next.js instrumentation hook initializes both in a separate webpack bundle from the application code, which is a pattern worth understanding if you're doing Obervability on Vercel in Next.js — module-level singletons aren't shared across bundles... and this took me longer than I'd like to admit to debug.

Alternatives considered: :|

CI/CD

GitHub Actions

The CI pipeline runs on every push and PR, with parallel jobs for linting, type checking, unit tests, integration tests, the production build, and end-to-end tests (Playwright across Chromium and Firefox). Coverage reports and build size reports are posted as PR comments automatically.

There are separate workflows for production releases (with automated rollback on failure), security scanning (npm audit, CodeQL SAST, secrets detection), and dependency updates via Dependabot.

The key philosophy: CI should catch everything that matters, and the pipeline should be fast enough that you never skip it. Parallel job execution keeps the total wall time reasonable.

Alternatives considered: CircleCI, Jenkins... just kidding. Actions may not be super reliable, but they're an easy choice for a project like this.

Blog

MDX via next-mdx-remote

You're reading this on it. Blog posts are MDX files — Markdown with JSX support — processed by next-mdx-remote and rendered as Server Components. Frontmatter is validated with Zod, syntax highlighting uses Shiki via rehype-pretty-code, and posts support custom components like callouts and captioned images.

Posts are statically generated at build time, include Schema.org structured data for SEO, and have an auto-generated RSS feed. It's a simple setup, but it's everything you need for a technical blog without reaching for a CMS. There's even an Obsidian plugin to automate the post scaffolding.

Alternatives considered: None really, I use Markdown and MDX for a lot and didn't see a reason to get fancy here.

Wrapping Up

That's the full stack. It's a lot of pieces, but each one was chosen deliberately and (mostly) for the right reasons. Some of these choices will change over time as the project evolves or as better tools emerge.

If you read the first post, you know this project is about building in public. That extends to the technical decisions too. You can see where I have operational scars. Not everything here is perfect, and I expect to revisit some of these choices. When I do, I'll write about it.

If you have questions about any of these technologies or how they fit together, use the contact form to reach out. And if you haven't already — go claim a block and add your prompt to the canvas.

--jeremy

With that, I'm launching JeremyG.dev. I've migrated all old posts for posterity, and I hope to post more than once every 6 years. The industry is moving faster than it has in a long time, and there has never been a better time to share and learn together.

--jeremy

I've spent two decades helping technical people learn from each other and using a growth mindset to help companies earn durable trust with engineers.

I specialize in scaling technical, credibility-driven organizations that operate as both brand builders and business accelerants.

Currently: VP, Technical Community and Open Source @Datadog | CNCF and OpenSSF Governing Board Member | Founder, LinuxQuestions.org | More

Writing

I just started writing again. Stay tuned.

Projects

• LinuxQuestions.org
• A Million Pixels
• Pirate Weather Extension
• Wyndo - Find the best weather window

Regular listeners will know that I'm a big fan of the Pixel line of phones (and was a Nexus fan before that). The unadulterated bloatware-free Android experience really is top notch. That said, for the first time since the Pixel 1, I decided to skip the Pixel 4 for a variety of reasons. There were just too many things about it I didn't like. The Pixel 5 got me back on board though, and I've had it for a few weeks now. So, what do I think?

On paper, the Pixel 5 seems a bit; if not disappointing then underwhelming. It sports a 6-inch OLED display with 90Hz refresh rate and a bezel-less design. It has wireless charging, fingerprint unlock, and is IP68 dust and waterproof. The phone ships with 8G of memory and 128G of storage. All good so far, you may be thinking. But eschewing a flagship SoC for the Snapdragon 765G resulted in Google taking quite a bit of flak. So did including the same main camera as the previous generation Pixel, and shipping with two front facing cameras instead of three. What's clear to me is that, at $699 Google decided to stop playing the one thousand dollar and up flagship game. They got back to basics; and it's surprisingly good.

While the display is 6 inches vs the 5.5 inches of my previous Pixel 3, the phone is almost identical in size due to the lack of abezel. What isn't even close to identical in size though is the battery - 2915 mAh vs 4080 mAh. The difference is night and day; and by that I mean come nighttime you'll actually still have a charge. The phone is aluminum but with a resin coating that I quite like. It's grippier than glass and isn't as much of a fingerprint magnet as many newer phones. Gone is the facial unlock and Soli that never quite panned out. As for the supposed slow SoC, for me it's been more than sufficient. If you're a very serious gamer or obsessed with benchmarks, you may notice a difference. I'm a pretty heavy users of my phone though, and I don't.

So - what's the bottom line? There's nothing groundbreaking or mesmerizing about Pixel 5's design... or about the Pixel 5 in general. At $699, this should be a phone of trade-offs and compromises. Ars ran a review titled "Google spends its bill-of-materials budget unwisely". But I think they missed the mark. Google managed to add 2GB ram, double the default storage to 128gb, increase battery by 50% and still make the phone $200 cheaper. It's a near perfect BoM if it wasn't for mmWave. I'm guessing they made some kind of deal with Verizon, but adding $50-100 to the phone makes very little sense for something almost no one will use.

Despite the mid-tier chipset, running an unfettered version of Android means the chip isn't bogged down and lets the Pixel 5 deliver an Android experience that feels just as fast as it does on phones with much faster chips. The massive battery life is a game changer, and the device just feels right in your hands. While I've always had a quote unquote flagship phone and this one really isn't… It feels like one. A bit to my surprise, it's a great phone. The Pixel is back.

Between LinuxQuestions, Datadog, consulting, Bad Voltage, Opensource.com, Linux Fund, and the other online activities I partake in, I'm in my office a lot. And while I try to be active when I'm not in my office, there's substantial research coming out that indicates long period of sitting are bad for your body irrespective of how much exercise you otherwise get. Enter a standing desk.

Before moving on to the review, I should note: While most studies agree that sitting for long periods of time is bad for you, there is still ongoing research on whether standing undoes that damage. That's not to say a standing desk isn't beneficial, but keep in mind there is not enough evidence yet from quality studies to prove exactly how beneficial.

On to the desk. While a variety of adjustable standing desks are available, after considerable research I ended selecting the Jarvis Bamboo from Fully. The desk comes in seven sizes with either rectangle and contour tops. I went with the 60"x30" contour combination. From there you you choose from an assortment of accessories including programmable memory adjustment, wire management , and CPU holders. Once you make your selection, the desk is sent out the next day via ground shipping and will arrive in two boxes.

The first box I opened had nothing but the desktop. You immediately notice how high quality the harvested bamboo is. It's sturdy but not too heavy and has a look I really like. The other box had the frame and all other components. Assembly was straight forward and took roughly thirty minutes, including attaching the optional CPU holder and my existing monitor arms. The wire management option is nice, but not custom built for the desk. I went with the programmable memory and as a $35 upgrade I'd consider it a must if you're going go with an adjustable height desk. It has 4 programmable options, which make the perfect height for standing or sitting a single click every time.

Once assembled I quickly put the desk to use. It's reasonably quiet considering it supports lifting 350 pounds and it extremely stable at all heights I tested. I've found myself standing roughly 20-25% of the time and it's been an improvement for not only my health, but for my workflow. At around $600 as I spec'd it out, it's not cheap, but when you couple how often I'm at my desk with the fact that this desk should easily last over a decade it seems like a small price to pay.

So, what's the Bad Voltage verdict? If you're looking for an adjustable height standing desk, I highly recommend the Jarvis Bamboo. I've been using it for over a month now and I would not want to go back to a traditional desk. If you’re committed to a standing routine, but you already own a standard-height desk you like, or the price of a fully adjustable desk is just too much, options such as the Ergo Desktop Kangaroo Pro Junior or Varidesk may be worth a look. Either way, I can also recommend the Topo mini mat, which I've found extremely comfortable.

You may have noticed this review is a bit lighter on details than most of mine are. This was very much by design. There are a ton of high quality in-depth reviews available for the Jarvis, and other variable height options, so there isn't a lot I can add. What I'd like to know is, what the rest of the Bad Voltage team thinks about the concept and work-flow of a standing desk, their opinion on buying a new fully adjustable desk vs using something like a Varidesk, and whether making either purchase is something they'd consider.

--jeremy

Brewing beer is a complex and subtle mix of art and science. As a fan of both craft beer and technology, when I stumbled upon the Pico by PicoBrew I was intrigued. For those not familiar with the Pico, it's a device that semi-automatically brews 5 liters of fresh craft beer at home in about 2 hours using grain and hop PicoPaks from dozens of breweries worldwide. From well known beers such as Dead Guy Ale from Rogue and Brew Free or Die from 21st Amendment, to niche beers from small local breweries scattered around the world that are unlikely to be available outside their direct locale, the selection is good and still growing rapidly. You're also able to create your own beer from scratch via the Freestyle option that lets you choose a base style and then customize with around a dozen grain options, a half dozen hop varieties and the optional ability to dry hop.

The Pico guides you through the first few brewing steps over the course of roughly two hours, however like with any home brew, you need to wait between a few days and up to a couple of weeks for your beer to ferment and carbonate. I've heard it described as the Keurig of beer, but I don't think that's an apt characterization. Making beer with the Pico is somewhere between traditional home brewing and and a K-Cup type experience, which InBev claims to be working on incidentally. With that in mind, on to the actual device.

The Pico is a fairly large device, measuring 16" x 12" x 14" and weighing in at 24 pounds. That may make it a difficult to accommodate for some. As the initial shipment comes with a PicoPak, a brewing keg, a dispensing keg, and quite a few accessories the delivery box is massive. Once you unpack everything initial setup is a breeze. Simply plug in the device, connect it to your wifi, and then associate it with your Pico account. The only thing left is the initial rinse, which is automated, and cleaning/sanitizing all the accessories and kegs. As with traditional home brewing, you better get used to cleaning and sanitizing as there is a lot of it involved. If you were expecting to hit a button, get beer, and be done let me allay you of that idea right now.

With everything gleaming and sanitary you're ready for your first brew. The first part of the brewing process involves inserting the PicoPak into the main step filter. Each PicoPak is automatically recognized by the device and comes with a Hops Pak and a Grain Pak. From there you connect the brewing keg, which uses standard ball lock connectors, add some distilled water and start the process. For most recipes you can adjust the ABV (alcohol content) and IBU (bitterness), but nothing else. While the on-screen directions are usually clear, I recommend keeping the manual handy for the first couple batches. Roughly two very noisy hours later you have the smell of fresh bread in the air and brewed wort in your keg. You can track the progress of your brew, in real-time, online. Follow the cleaning and sanitizing instructions on the device and let the wort cool to the correct brewing temperature, which is noted on the Pak. From there you pitch your yeast, watch the airlock bubble for between a few days and a couple weeks, then rack the beer into either the serving keg or your kegerator system. While they offer a method to "fast ferment" your wort, I recommend sticking with the standard fermentation process. You can carbonate the beer with the priming sugar that comes with the PicoPak or force carbonate using the included adapter. You now have fresh homemade beer.

How is that beer? I've brewed a few different styles from multiple breweries and the results have been mixed. My initial brew was a Buffalo Sweat Stout and it came out really good. In fact, some people that tried it didn't believe I brewed it at home. On the other end of the spectrum, the Dead Guy Ale tasted off to the point of being almost undrinkable. As I brew more recipes from additional breweries I am curious to see which experience becomes the norm. Unfortunately I haven't had a chance to try the Freestyle option yet, but I plan to very soon and will update with results when I do.

Note that new Pico devices also ship with a sous vide adapter. My Pico did not, but the company has stated they plan to ship the adapter to everyone eventually. Looking at the instructions, however, it's much more complicated than a traditional sous vide. It's pretty clear the company was committed to including the functionality because it was promised in their kickstarter, and they should be commended for this. It may be a decent way to test whether you like cooking sous vide, but if you're serious about it I suspect you'll want a proper setup sooner than later. I still use the Anova I reviewed in an previous episode and recommend it.

So, what's the Bad Voltage verdict? At $799 the device is a fair bit more expensive than a traditional home brew setup. While it automates much of the process, there is still quite a bit of manual cleaning, sanitizing, and other work that must be done and the "beer in two hour" pitch is a little disingenuous. PicoPaks run between $19-$29, which translates to around $10-15 per growler of beer. It will be interesting to see how many breweries come on board and how consistent the end result is. So far the company has been very receptive to feedback and seem genuinely interested in listening to customers and improving the product, so I'm encouraged. PicoBrew deserves credit for making the brewing process simpler and removing some variables without making it much less authentic. I suspect if you really enjoy craft beer and live somewhere a good variety of it is difficult to procure, the device could be a compelling purchase. I also suspect many will consider it far too expensive, too complicated, and too inconsistent to justify the cost or effort involved. Note the company also makes a device called the Zymatic which is a true all-grain brewing appliance that is almost akin to a miniaturized commercial brewery. At $2,000 it's a major investment but it also comes with the ability to sell PicoPaks in the BrewMarkepace, so may be an option for those looking to break into commercial brewing.

UPDATE: After recording the show I contacted PicoBrew with the following question: "If PicoBrew were to fail as a company, would the device be rendered useless? The fact that you cannot add your own ingredients to a pak would seem to indicate this is the case. Am I missing something? Thanks."

They once again responded extremely quickly (under thirty minutes) with the following: "You are not missing anything and that is a quite valid concern. To alleviate this concern, we can promise two things:

1. We're not going anywhere.  We have a quite solid business plan and a quite large purse to keep us going for many years to come.
2. If we were to go out of business, we would make sure our customers, those who trust and support us, are not screwed in our passing.  We would release all software surrounding our products and let the community build themselves a working server to support their appliances as well as release how to build your own Pak."

--jeremy

• [00:03:12] In the news this week: Vizio get fined $2.2m for secretly collecting everything you watch on their TVs and lying about it, police use someone's pacemaker data to help prove that they committed arson, Uber hire a NASA person and start talking about flying taxis, and Streetmap lose their appeal after suing Google for unfairly pushing their own map product
• [00:17:00] In honour of our special guest being @film_girl on Twitter, we've put together a list of "the good, the bad, and the ugly" in film: films that are really great, secretly great, and idiosyncratically terrible
• [00:39:30] Jeremy reviews the Pico Brew, a device for brewing your own beer easily without having to buy all the glassware and a forty foot mash tun
• [00:56:35] Is there actually a space for a successful "third player" in mobile phones? Microsoft, Ubuntu, Sailfish, Palm, RIM, all have foundered in pursuit of this market. And if there's no space for it in phones, who will shift the market to some new _type_ of product, and what will that product be?

Also, Bad Voltage are returning to SCALE in Pasadena in March for a live show! With free food and an open bar, and the 80s nerd rocker band the Spazmatics, the show's gonna be great. Buy your SCaLE tickets now!

Listen to 2×3: And Those Who Dig

From the Bad Voltage site: Every two weeks Bad Voltage delivers an amusing take on technology, Open Source, politics, music, and anything else we think is interesting, as well as interviews and reviews. Do note that Bad Voltage is in no way related to LinuxQuestions.org, and unlike LQ it will be decidedly NSFW. That said, head over to the Bad Voltage website, take a listen and let us know what you think.

Stuart Langridge, Jono Bacon, and myself present Bad Voltage, your fortnightly recommended dose of vitamins and minerals. Featuring a still virulently ill Jono, the uttering of the phrase “FreeBSD” in these hallowed halls, and:

• [00:02:26] In the news this week, the Guardian wrongly declare WhatsApp to have a “back door” and get huge pushback from security experts demanding a retraction, Google is big enough to develop a trusted hardware solution for internal use only and isn’t going to sell it, possibly heralding a new era of hardware that nobody will be able to buy, and Facebook are doing something with VR thus confirming one of Jono’s predictions and he almost dies of smugness
• [00:13:00] We review the ACPAD, which calls itself “the electronic orchestra for your guitar” after its successful Kickstarter; what’s it all about?
• [00:27:30] Is ChromeOS “desktop Linux”? We asked this question in the last show, and it’s a bigger one than we might think. If it is, do Chromebook successes count as “the year of the Linux desktop”? If it isn’t, is it a threat? A rival or a friend? Should we buy a Chromebook?
• [00:50:07] People are using the GPL less and permissive licenses more; this isn’t just a feeling, it’s confirmed by research. Why is this? Is it a problem? And do we think that anyone should care?

Also, Bad Voltage are returning to SCALE in Pasadena in March for a live show! Keep your ears open for more details, and buy your SCALE tickets now!

Listen to 2×2: Failed to Capture

From the Bad Voltage site: Every two weeks Bad Voltage delivers an amusing take on technology, Open Source, politics, music, and anything else we think is interesting, as well as interviews and reviews. Do note that Bad Voltage is in no way related to LinuxQuestions.org, and unlike LQ it will be decidedly NSFW. That said, head over to the Bad Voltage website, take a listen and let us know what you think.

Listen to 1×80: The Two-Percenters

--jeremy

From the Bad Voltage site: Every two weeks Bad Voltage delivers an amusing take on technology, Open Source, politics, music, and anything else we think is interesting, as well as interviews and reviews. Do note that Bad Voltage is in no way related to LinuxQuestions.org, and unlike LQ it will be decidedly NSFW. That said, head over to the Bad Voltage website, take a listen and let us know what you think.

• 00:02:01 Google have long been a player in the chat or IM ecosystem. But just lately their approach in this area seems to be getting more and more confused. What's the deal, big G? You've got Allo and Duo and GTalk and Hangouts... what's the end goal here?

• 00:24:33 Open sourcing your hardware. Kyle from OpenMYR, who are currently kickstartering wifi-controllable motors1, asks the BV team: are we doing the right thing, publishing the hardware source for our creations? When's the right time to open your hardware: before it exists, after it exists, or never? We look into the question and give some thoughts

Listen to 1×77: Wax Cylinder Coming Soon

–jeremy

From the Bad Voltage site: Every two weeks Bad Voltage delivers an amusing take on technology, Open Source, politics, music, and anything else we think is interesting, as well as interviews and reviews. Do note that Bad Voltage is in no way related to LinuxQuestions.org, and unlike LQ it will be decidedly NSFW. That said, head over to the Bad Voltage website, take a listen and let us know what you think.

The first system I have running is Philips Hue. Based on the low-power, wireless mesh network zigbee standard this system requires a hub to operate. The Hue line offers a wide variety of options, including standard lights, accent lights, spot lights, light strips, integrated switches and more. Setup is a breeze and while the stock app could be more intuitive the large number of 3rd party applications and integrations more than make up for that. The bulbs are bright and color saturation is acceptable. One down side to this option is that it's on the pricier end of the spectrum.

The second system I have running is LifX. Based on traditional wifi, no additional hub is needed. The LifX line is limited to standard white and color bulbs. Setup is once again a breeze and the stock app is intuitive and full featured. It includes some nice touches such as cool effects baked into the app that you can only get with Hue by using 3rd party apps. The number of 3rd party integrations isn't as large as Hue, but has been growing steadily recently. The bulbs have the greatest brightness and color saturation of any smart bulb I've seen. The price of LifX bulbs are comparable to Hue.

Depending on your needs and design requirements, I'd recommend both systems. There are less expensive options from GE, Wink, WeMo, Cree and others but I've never used them so cannot comment on how they compare. With that brief intro out of the way let's get to the first question my co-presenters had. Are smart bulbs a good idea? Let me give you a few examples of how I use the bulbs and then we'll get the discussion going from there. First, on the more practical side I have a bunch of automations setup that make my home safer and more convenient. Open the front door when it's dark outside and my living room lights go on. Open the basement door and the basement lights go on (which is especially handy while doing laundry). Next, as I have Redshift adjust the color temperature of my screens at night, the lights in my office also adjust to reduce the amount of blue light as it get later. Lastly, on the less practical side, when my favorite team scores a touchdown various lights in my house flash the team colors. So, fellow presenters, what do you think?

Turn in tomorrow to hear what my fellow presenters think. In the mean time, what is your opinion on smart bulbs?

--jeremy

The 45mm device comes with the same size 1.37" display (including flat tire) as the Gen 2, but the AnyLight Hybrid display makes it easily readable even in sunny conditions. The silicone strap comes in Black, White, and Flame Orange but as it's part of a unibody construction it is not changeable. While many reviewers have found the strap to be a lint magnet, after over a month of use I did not find that to be an issue. The device has an optical heart rate monitor, barometric altimeter, accelerometer, ambient light sensor, gyroscope and a 300mAh battery. Like the Gen 2, it is IP67 dust and water resistant.

Moving on to using the device, I found the construction to be solid and the watch comfortable to wear even during long runs. Most popular running apps have Android Wear support at this point, although I've found most (I regularly use both Strava and Endomondo and extensively tested Runtastic, Runkeeper, Map My Run, and Ghostracer) have at least one annoying issue that needs to be addressed before being a true competitor to dedicated running watches. The platform also seems to be a bit temperamental, which resulted in me missing out on data points for a couple interesting runs. For example, the data for my Boilermaker run (a 15k) shows over an hour of activity but a distance traveled of zero. That particular issue seems to related to a known bug with Endomondo and Wear devices that have GPS. On the note of the GPS, I found it to be roughly as accurate as my phone GPS, although getting a lock takes substantially longer. It's less useful than I hoped though, as using the GPS and active display means the battery life isn't sufficient for longer runs. The device has 4GB of internal memory which you can play music from, although I did not test this feature. I found the heart rate monitor to be accurate enough to be useful and a nice addition to my running metrics.

So, what's the verdict? Although the Moto 360 Sport lacks more advanced features such as cadence and VO2 max, it's a very capable device. For shorter runs it will allow you to leave the smartphone at home, and for long runs being able to see stats during your run while being able to move your phone from an armband to a pouch makes for a more enjoyable experience. The display really is top notch. With the original MSRP of $299 already marked down to $199 it's a device I would have tacitly recommended now and as the platform matures I could have seen that turn into a much stronger recommendation. I was definitely looking forward to the second iteration of the device.

Enter Motorola Support

Unfortunately after 47 days of use, the device rebooted while I was running then shut off. Once I got home and put it on the charger it went into a boot loop. I did some research online and found out some other people had a similar issue. While most weren't able to fix their device, I found one suggestion that involved completely draining the battery then charging it overnight. This worked a single time, but during the next run the device shut off and further research and troubleshooting were not able to resuscitate it. I was a little bummed, but these things happen with electronic devices and I went to the Motorola support site to start the RMA process. This is where the experience gets unfortunate and things did not start out well.

I tried multiple times to begin the process online, but received the following error: "100-02. Oops!!!" After that error persisted for a few days, I finally called support. Unfortunately support was not able to verify the serial number on my device, despite multiple attempts which included me sending them a photo of the sticker affixed to the box which contains both the SKU and serial number. After some back and forth I ask for an RMA despite the serial number issue, as the device comes with a year warranty and has not been out for even close to a year yet. I understand they have legitimate reasons for needing the serial number, but they can get that off the device once they have it. In this context, it's not needed to validate warranty coverage. The rep said they could not proceed without a "scanned copy of the receipt", despite me pointing out that 100% of Moto 360 Sports have to be in warranty. I also explained that as this is 2016 I purchased the device online and do not have a receipt to scan. After some additional back and forth, on August 2nd I send them a screenshot of the online order, while also pointing out this is a pretty silly thing to have to do. At this point I just want to get the process moving.

On August 4th I get a response saying: "In regards the replacement/repair process, we get an error from the system, in that case we opened a VHD ticket which is going to have a resolution within 24 to 48 business hours"

On August 8th, I get an update: "I wanted to let you know that I am following up your case, and that I have not received confirmation that the VHD ticket has been solved, but I already verified with the team in charge of it, they told me they are working on it."

At this point I reach out to @Moto_support, but am told: "Please follow up with us via email". I also now note that I am using this device to write a review for a site that gets quite a bit of traffic, hoping that will help expedite things. It does not.

On August 10th, I get an additional update: "I am contacting you to provide you updates about the VHD ticket submitted, it is still being worked by the team in charge." It's now been over a week since I initially opened a ticket with the support rep.

On August 11th the VHD issue is solved. They want me to ship them the device so they can evaluate it and then either repair or replace it, or give them $25 for the "Advanced Exchange program". I explain that after over a week of waiting, the fee on the AE program should be waived and a device should be sent ASAP. They eventually agree. Via the email ticket I give them all contact information as requested. Shortly after I get a voice mail from Motorola with no callback number and no email contact info that ends with "just email us back, okay". I guess this means reply to the ticket, which I do.

On the 12th, I get a call from Motorola. They now say the fee cannot be waived because the system will not let this happen, but it can be refunded after the fact. I point out that this directly contradicts what was previous said by them. They persist. I eventually capitulate and give them my credit card information. The experience at this point is getting really frustrating and taking up far too much time (believe it or not, this is just an overview of the event which included quite a few calls and back-and-forth emails over trivial issue and re-re-re-confirming information). I get an RMA email while I am still on the phone with the rep, which is encouraging. I just want to run and I now think a new device is on the way. I am sorely mistaken.

A short time later I get an email saying the credit card is "invalid". We confirmed the number on the phone three times; it is not invalid. During the next call I note that it's odd that the card would be invalid as I received an RMA. I am told: "even though you received shipping labels or tracking numbers, the system sends the emails automatically, that is why you received them, but in the system they did not go through". This makes no sense, but I give my credit card details again. I get another RMA while on the phone, but notice that it's for the incorrect device (a Moto 360 Gen 2, not a Moto 360 Sport). Looking back, the first RMA was also for the incorrect device. It is explained to me that this is normal and not an issue. A couple hours later I am told that my credit card was now declined. I have used this exact card before and after the RMA and the card is nowhere near its limit. I call the credit card company. There have been zero attempts from Motorola and zero declined transactions for the day. I am now starting to lose my patience.

On the next call I explain that the number is correct and the card has not been declined. They suggest I try to submit the request online again. I get the same "100-02. Oops!!!" error. I point out how ridiculous this is getting. The rep now suggests that I use a different serial number than the one that is on the box. This does not seem normal. Using the new serial number does get me past the previous error, however, and may explain the incorrect device issue. I now get a credit card error. I point out that it's odd that the system never asks for a CVV, but they don't seem to know what I am referring to. I try the online system again with a new card. One that has a zero balance and that I rarely use. This time I am met with success. They double check the system and everything looks good. Hooray!

Except, no. On the 15th I get an email: "I am contacting you to provide you updates about your case, I was checking it, and I found that unfortunately the order is cancel for invalid or missing Credit Card number". I explain that this is odd even for this increasingly odd situation as I now not only have a 3rd RMA, which has been confirmed by Motorola, but a tracking number from FedEx. Surely the tracking number means a replacement device is on the way. I am told: "You have received FedEx shipping confirmation because shipping information and credit card information are being processed by a different systems." I check my credit card statement and I have two pending transactions for different amounts:

Aug 12, 2016 MOTOROLA MOBILITY LLC $244.68
Aug 12, 2016 MOTOROLA MOBILITY LLC $250.86

They now ask for a "bank statement". I tell them in no uncertain terms that they are not getting one and am now starting to lose my temper. They ask me to submit the request again from scratch. I point out how absurd this entire interaction has been and also note that the Fed Ex tracking number they gave shows that something has actually shipped. Between that and the pending charges, I think their system is incorrect and the third RMA has been processed. They do not agree. They also do not have an explanation for the multiple charges for different amounts, neither of which they see on their end.

On the 16th they touch base on the ticket. I respond with: "To confirm: All RMA's have failed in some way and nothing has shipped, despite me receiving a tracking number. Is that correct?"

I received the following response on August 17th: "That is correct all RMA's have failed, and nothing has been shipped despite the tracking numbers you received." I also received a package from Motorola. Containing a Motorola DROID phone. A PHONE! I can't even begin to fathom how that's even possible, considering the packing list actually says "MOTO3602SPORT - MOTO 360 (2ND GEN)" on it. I called my credit card company again, and at no time were any transactions declined. They do see both pending transactions from "MOTOROLA MOBILITY LLC" but "they are set to fall off your account because they were never finalized by the merchant". Once they are no longer pending, I figure the phone is a gift and I plan to see if the Moto 360 Sport will blend. The DROID is a Verizon model, if anyone knows a charity in need please contact me. In the mean time, I'm in the market for an Android Wear running watch.

Based on the above experience I must unfortunately recommend avoiding all Motorola products at this time, which is a shame. The outrageously bad support is a large blemish on a company that is putting out solid quality products. I still think the Moto 360 Gen 2 is one of the best Android Wear watches currently available. In fact, I've purchased the device for family and friends and it's been very well received. Quite a few people have told me they purchased one based on my review and the feedback has been positive. I like the Moto 360 Sport and some of the phones look very nice. That said, the support experience above was so terrible, the Motorola internal systems are so broken and the issues so systemic in nature that I would not feel right if one single person had to go through the above based on a recommendation I have made. So, at least for now, keep away. Far.Away. And Motorola Support, please get your act together.

Note: Any text in quotes above are a direct copy/paste of the interaction. Luckily I have much of this in writing or on voice mails, but some did take place on the phone. Happy to provide supporting details if so desired. I have reached out and it appears I am not alone in this kind of experience with Motorola Support.

UPDATE: They are now mysteriously able to see that the RMA "went through, and I can see the device arrived to your home". The rep also added: "I will ask you to send us the device since with the Advance Exchange submitted a hold has been put on the card you used, if you do not send us back the device the hold will become a charge." which is in direct opposition to the statement I have in writing from the 17th that confirms there are no holds on my card. Let it sink in for a minute that the system they use is so bad, they don't actually know if they are billing you or not.

UPDATE (August 19th): Someone from the "Executive Customer Relations" team (which based on the email address appears to be part of the office of the CEO) reached out to me. They included a tracking label to overnight the phone to them and said they would overnight me the correct watch as soon as they received the phone. So, progress. I had the phone to FedEx within an hour, and noted it would be a show of good faith for them to overnight me the watch now, since the issue has been going on for roughly three weeks already and we're getting to the weekend. They responded, and insinuated they could do so but would not as a result of something I said in this post (the comment about the phone being a gift). My response: "Considering the show of good faith I made by having the package at Fed Ex within an hour of receiving your email AND the fact that we are on week three of this absolutely terrible customer experience AND the fact that I provided proof of shipping AND the fact that we're on a weekend boundary that will cause another delay, I'm hoping you decide to ship something out ASAP". I also included a photo of the Fed Ex receipt. They never responded, which is pretty disappointing and seems for lack of a better word...vindictive. I guess I'll now be running at LinuxCon with no Moto 360 Sport. I also made it clear that this is no longer about me getting a working device. The readers, listeners and conference-goers that I have recommended Motorola products to or whom have seen me wear the device on stage and have made a purchase as a result deserve to know the systemic issues I encountered are being addressed. They completely ignored that part of my email but I will work to get it addressed. Stay tuned for further updates.

UPDATE (August 20th): After posting the previous update I also sent a very frank email to the Executive Customer Relations team. They had received the phone at this point and responded saying they decided to send me a new Moto 360 Sport via Saturday deliver, which I just received. Hopefully this marks the end of my particular issue. On to the broader issue, they said "We have completed a deep dive on your case and sent off coaching and feedback to ensure this does not occur in the future", which is encouraging. I've responded noting that the technical system they use should really be evaluated, as the number of cascading failures just should not be possible (remember: the system allowed for the creation of an RMA when one doesn't exist, showed one card as declined when my credit card company confirms it was not, put two holds for different amounts on a second card but then canceled the RMA while somehow still sending out a device, which then ended up being the incorrect device.  The billing issues are especially worrisome and it looks doubly bad when a tech company has this many technical failures). It is my hope based on their response that they will look into the failures and hopefully other people will not have to go through an experience similar to the one I have.