Andrea Baccega's Blog

Opus vs r/AskElectronics: 1-0 for the humans

Mon, 04 May 2026 00:00:00 GMT

A few years ago I started building eNSPanel, an open-source custom PCB replacement for the Sonoff NSPanel. Each revision got a little better. Around the sixth or seventh revision I wanted to clean up the thermal management and finally call the design done.

Then my son was born and I stopped sleeping. The board sat in a drawer for months.

The chip that wouldn't behave

When I came back to it, the same regulator was still cooking. The ST1S10PHR step-down was drawing absurd current and heating like a stove the instant I powered the board. Output rail flat. No oscillation, no soft recovery, just heat.

A day taking orders from Opus

So I did what people do in 2026. I gave the schematic, the layout, every measurement, and the datasheet to Claude Opus and started debugging with it. Claude as the debugger, me as the manual labor.

We went all day.

Cut this trace. Replace those caps. Swap the chip, it might be a counterfeit. Bridge here. Lift this pin. Measure pin 3 to ground again. Now pin 7. Now pin 1. Try a different input voltage. Add a pulldown. Remove the pulldown. Replace the chip again.

I did all of it. I have the flux burns to prove it. By the evening I had eight dead ST1S10PHR samples, a board that looked like a battlefield, and the exact same symptom I had at 9am.

Ten minutes on Reddit

Out of options, I dumped everything into a r/AskElectronics post: schematic, layout, every measurement. I added the now-traditional disclaimer: "I even asked AI, but it didn't tell me anything valuable."

Reddit moderation held the post for a while. Ten minutes after it went live, I had the answer.

A user named Ard-War, flair "Electron Herder", looked at the schematic and asked exactly one question:

"Why is there 4μ7 across VIN and SW? I'm surprised it wasn't outright going in flames with that."

A 4.7µF capacitor I had wired straight between VIN and the switching node. Every cycle, the chip was effectively shorting its own switching pin to the input rail. His follow-up read like a sentence you only write after years next to these parts:

"microfarads with microohm ESR is really in smokes and fires category."

One question. No new component. No exotic measurement. A schematic review by someone who has laid out hundreds of buck converters and would never have placed a cap there in the first place.

I removed the offending cap, fixed the layout, populated a fresh chip, and the rail came up clean. I posted "Thanks IT works" and the redesigned schematic. Ard-War reviewed that one too. Production ready.

Expertise is the guardrail

The takeaway is not "LLMs are bad". I use them every day, and on text problems they are extraordinary. The point is narrower, and, for me, important.

For hardware, Opus was happy to give me a confident, plausible, completely useless plan for an entire day. Not because it was lying, but because the failure mode was a switching-regulator layout error: a domain where the priors are very specific, the failure modes are visual, and the right answer usually comes from someone who has stared at a hundred buck-converter layouts.

If you are an expert in what you are asking the model to do, an LLM is an amplifier. You steer, it accelerates, and your existing knowledge keeps it from walking you off a cliff.

If you are not, and the domain is unforgiving, you can spend a full day executing a sequence of expensive, irreversible moves that lead nowhere, and never even realize you are off the map.

I am no EE. I am a software engineer who solders. That gap does not show up on any benchmark I have seen.

I lost a day and eight chips. Reddit cost me one post and a "Thanks IT works".

For the kind of problems I usually solve, the model is winning by a mile. For this one, the model wasn't even close.

1-0.

Text is the New Binary

Mon, 27 Apr 2026 00:00:00 GMT

In April 2026, Andrej Karpathy published a GitHub gist. Not code. Not a library. A markdown document describing a pattern: an LLM-maintained folder of wiki pages that compounds across sessions and beats RAG. Right at the top, he tells you exactly what kind of artifact it is:

"This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you."

Andrej Karpathy, LLM Wiki

Within weeks: tutorials, v2 forks, "beyond RAG" think-pieces, dozens of open-source implementations. People are running this software. The artifact is prose. There's no npm install, no version, no test suite. You read the gist, you instruct your agent, your agent builds you a wiki.

I'm running it too. That's a binary.

The Reframe

Code is what you write. A binary is what you ship: the thing users actually execute. Software used to ship as compiled artifacts with contracts: function signatures, exit codes, semver, reproducible builds. A growing class now ships as text meant to be interpreted by someone else's LLM at runtime. No types. No version pin (which model? which context window? which mood?). No tests in the old sense. Just words and trust.

Text is shipped. Text is executed. Text is the binary.

Even the Installation is Text

For decades, the "installation" section of a README was one of two things: a shell command, or a config file. npm install foo. curl … | bash. docker pull. A deterministic instruction the human (or CI) executes verbatim.

Now look at the install for awesome-agent-skills, an April 2026 directory of skills for Claude, Codex, and Copilot:

"paste the raw SKILL.md URL in a new conversation. […] That's it. No installation. No configuration. No coding required."

awesome-agent-skills

Read that again. The install command is a sentence in English: "paste the raw SKILL.md URL in a new conversation." There's no script. There's no package. There's a markdown file at a URL, and a paragraph telling you to hand the URL to your agent, which then reads the markdown and figures out the rest. The install instruction is prose; what it points to is prose; what the prose configures is the agent's behavior at runtime. It's prose all the way down.

Karpathy's gist is the same shape: "copy paste this to your own LLM Agent" is the install command. So is every CLAUDE.md and every AGENTS.md, now a Linux Foundation standard adopted across 60,000+ projects[^1]: project configuration shipped as prose, no installer required. GitHub even shipped gh skill install[^2] in April 2026, a first-class CLI command for installing markdown files.

This isn't a fad. It's a real engineering shift, with reasons:

Forkability. Edit a paragraph, you have a v2.
Model evolution. The same prose gets sharper as the agent does.
Personalization at runtime. Don't like something about Karpathy's gist? Add a line to your prompt. Specific need your team has? Just tell the agent. Every reader of the same prose gets their own build, shaped by what they say next. No binary can do that.

The Format is Markdown

Notice how everything in the previous section is markdown. Karpathy's gist, AGENTS.md, SKILL.md, the blog post you're reading. That's not an accident; it's becoming the substrate.

In February 2026, Cloudflare shipped Markdown for Agents:

"Markdown has quickly become the lingua franca for agents and AI systems as a whole."

Cloudflare, Introducing Markdown for Agents

Any site behind Cloudflare can now serve a markdown version of itself when the request includes Accept: text/markdown. Claude Code and OpenCode already send that header. Cloudflare's own measurement: a blog post costs 16,180 tokens as HTML, 3,150 as markdown. An 80% reduction. The web is starting to translate itself.

If text is the new binary, markdown is its instruction set.

When the App Is the File

The escalation continues. If installation is prose and the format is markdown, entire products start collapsing into markdown files.

In 2015, "track what I eat today" required someone to build you an app: a developer, a designer, a backend, an App Store listing. Months of work, thousands of dollars. In 2026, it's a sentence to an agent. No download, no onboarding, no app.

Karpathy frames this arc as Software 3.0[^3]: code (1.0) → learned weights (2.0) → prompts (3.0). One-shot work doesn't even need an artifact: you say what you want and the agent does it. Recurring work gets a markdown file so you don't re-explain. Only the rest still wants code. People are already shipping "skill graphs": folders of interlinked markdown that teach an LLM how to think about a domain, sold not as a SaaS but as a folder you own. "Apps gave phones superpowers; skills give AI agents expertise."[^4]

This won't replace every app. It will replace the long tail whose only real value was encoding a workflow. Personalization stretches the tail further: when generating a custom version for one user is cheap, the market for one-size-fits-all SaaS shrinks[^5]. That tail is enormous.

The Paradox Karpathy Spotted

Here's the irony hiding inside Karpathy's own gist. The whole thesis of the LLM Wiki is a critique of how today's RAG systems handle knowledge:

"the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. […] The knowledge is compiled once and then kept current, not re-derived on every query."

Andrej Karpathy, LLM Wiki

But "text as binary" is structurally identical to RAG. The agent re-interprets the same prose every time: every CLAUDE.md loaded into a new session, every SKILL.md matched against a prompt and read into context. The same critique that pushes Karpathy beyond RAG will eventually push us beyond text-as-binary for the workloads where re-derivation is too expensive: high frequency, low margin, regulated, audited.

That's the real shape of the next few years. We're in an exuberant phase. Text-as-binary is shipping into places it'll eventually retreat from. Try debugging an agent that decided to skip a step in your workflow, or auditing a refund issued because a CLAUDE.md said "be helpful." Meanwhile the deterministic binary is still sitting in places it'll eventually cede: every workflow that's 80% similar to one you support but not exactly.

The fight is loud because the equilibrium hasn't arrived yet. Both approaches are oversold and underspecified at the boundary. That's a temporary condition.

Where the Line Lands

A heuristic:

Text wins when the surface area is infinite and correctness is fuzzy.
Code wins when the contract is auditable, the bill is real, or re-derivation is too expensive.

Most production systems will need both: text at the edges (interpretation, dispatch), code in the core (execution, money, security). The interesting engineering of the next five years isn't picking sides. It's finding where the line falls for your specific problem.

This blog is a worked example. You're reading prose: a markdown file in a src/content/blog/ folder, compiled to HTML by Astro at build time. Text at the edge (the writing), deterministic code at the core (the build pipeline). No LLM mediating the runtime. The line falls there. For my CLAUDE.md, it falls somewhere else. For Karpathy's gist, somewhere else again.

Karpathy himself flags this in the closing of the gist:

"The document's only job is to communicate the pattern. Your LLM can figure out the rest."

Andrej Karpathy, LLM Wiki

That sentence is doing two things at once. It's a confession that the artifact has limits. And it's a bet that, for this workload, the limits are worth the leverage. Both can be true. That's where the line will eventually land, not on text or code, but on which one carries the leverage worth its limits, for the problem in front of you.

[^1]: AGENTS.md was originally popularized by OpenAI's Codex CLI and was donated to the Linux Foundation's Agentic AI Foundation in December 2025 as one of three founding projects (alongside Anthropic's Model Context Protocol and Block's goose). Adopted across 60,000+ open-source projects and agent frameworks.

[^2]: GitHub's gh skill install changelog, April 16, 2026.

[^3]: Andrej Karpathy, "Software 3.0," YC AI Startup School keynote, 2025. Latent Space transcript and discussion.

[^4]: From "AI Skills Are the New Apps", OpenClaw, 2026.

[^5]: Software ETFs fell roughly 30% in early 2026, with Salesforce, Adobe, and ServiceNow each off 25-30%. Analysts are calling it "AI eating software." See Fortune's coverage of the SaaSpocalypse and a16z's "Notes on AI Apps in 2026".

Why I Switched to a Split Keyboard (and Why You Should Too)

Thu, 29 Jan 2026 00:00:00 GMT

I've been typing on traditional keyboards for over 25 years. Thousands of hours, millions of keystrokes, all on a layout that was designed to slow you down. Back in 2024, I took the leap and got to build a Temper split keyboard. Here's why... and why you might want to follow.

Meet QWERTY: The Accidental Standard

Let's start with a question most of us never ask: why are the keys on your keyboard arranged the way they are?

The QWERTY layout was patented in 1878 by Christopher Latham Sholes[^2], the inventor of the first commercially successful typewriter. The popular story is that the layout was designed to prevent mechanical typebars from jamming by placing commonly used letter pairs far apart. Whether that's the full truth or a simplification, one thing is certain: QWERTY was designed for a mechanical constraint that hasn't existed for over a century.

When computers replaced typewriters, nobody questioned the keyboard layout. It was already the standard. Billions of people learned to type on QWERTY, and the network effect[^1] made it nearly impossible to displace. We've been collectively carrying the baggage of 1870s engineering ever since.

Alternative layouts like Dvorak (1936) and Colemak (2006) have tried to optimize for finger movement and comfort, but adoption remains tiny. The real problem, though, isn't just the layout ... it's the shape of the keyboard itself (and more)...

The Problem With Traditional Keyboards

Take a look at your hands right now. Let them rest naturally in front of you.

Notice something? Your hands aren't parallel. They're angled slightly outward. Your fingers don't all reach the same distance. Your thumbs are the strongest digits you have, yet on a traditional keyboard they share a single oversized spacebar.

A standard keyboard forces you into an unnatural position:

Ulnar deviation: Your wrists bend outward to align your fingers with the parallel key rows. Do this for 8 hours a day, and you're on the express lane to RSI[^3].
Pronation: Your forearms rotate inward so your palms face down, compressing the nerves and tendons in your wrists.
Thumb waste: Your two most dexterous fingers are relegated to hitting one key each (spacebar and maybe Alt).
Pinky overload: Modifiers like Shift, Ctrl, and Enter are all assigned to your weakest finger.

I didn't think much about any of this until life forced my hand... literally. When my baby was born, he wouldn't sleep unless he was resting on my or my wife's chest. Any parent who's been through this knows: you're pinned to the couch or chair for hours, one arm cradling a sleeping newborn, desperately trying not to move.

I had to keep working on projects and a traditional keyboard was out of the question (see above). But with a split keyboard, I could place each half on either side of me, type with my hands in whatever position the baby allowed, and still get some work done during those long naps. That's what pushed me to finally make the switch!

Why Now?

There's never been a better time to invest in your typing setup. With the rise of AI-powered tools like Claude, ChatGPT, and Copilot, prompts are the new code. The quality of what you type directly shapes the quality of what you get back. Typing well, fast, accurately, and comfortably, matters more than ever.

"But what about voice input?" you might ask. Tools like WisprFlow and other speech-to-text solutions are impressive, but they don't work everywhere. In an open office, on a train, during your kid's quiet hours, in a library, or when you're discussing anything sensitive or proprietary you can't just speak out loud. The keyboard remains your most reliable, private, and universal input device.

And if you're going to rely on a keyboard for the foreseeable future, it makes sense to use one that's actually designed for human hands. At ~100 WPM, you're already faster than 97% of all typists — and a split keyboard can get you there (also non-split keyaboards :))

Why Split?

A split keyboard addresses these issues by design:

Image credit: Boardsource

Natural hand position

Each half of the keyboard can be placed and eventually angled independently, so your wrists stay straight. No more ulnar deviation. You can even tent the halves (angle them upward) to reduce pronation.

Thumb clusters

Instead of wasting your thumbs on a spacebar, split keyboards give them a cluster of keys with different actions. Your strongest fingers finally pulling their weight.

Columnar stagger

Traditional keyboards have rows staggered horizontally, a leftover from typewriter mechanics. Split keyboards typically use columnar stagger, where keys are aligned vertically and offset to match the natural length of each finger. It feels weird for about a day, then it feels right.

Image credit: Keyboards Expert

Fewer keys, more layers

The Temper has significantly fewer keys than a traditional keyboard. At first this sounds like a downside, but it means your fingers never leave the home row[^4]. Everything is accessible through something called layers... Think of it like holding Shift to get capital letters, but expanded to give you numbers, symbols, navigation, and function keys all within finger's reach.

Programmability

Every key does exactly what you want. With firmware like ZMK, you can define tap-hold behaviors (tap a key for one thing, hold it for another), combos, macros, and multiple layers. Your keyboard adapts to you, not the other way around.

For my Temper, I went with Miryoku... an ergonomic, minimal, orthogonal, and universal keyboard layout designed for 3x5 column keyboards with 3 thumb keys per hand (36 keys total). Miryoku gives you a well-thought-out set of layers out of the box: navigation, mouse emulation, numbers, symbols, function keys, and media controls. You don't have to design your own layout from scratch. It's a great starting point, and you can always tweak it to your liking later.

Obviously, being a developer i needed a tweak here and there so i customized for my own needs over time. In case you're curious you can find my firmware here.

My Experience With the Temper & Miryoku

The Temper is a minimal, low-profile split keyboard. It's not for everyone... you need to solder. But that's part of the charm. You understand every component of the tool you use every day and gives you the knowledge on how to eventually fix it yourself.

Here's what my first few weeks looked like:

Day 1-3: Absolute chaos. My typing speed dropped from ~100 WPM to roughly 15 WPM. I kept reaching for keys that weren't there. Every muscle memory shortcut was broken. I questioned every life decision that led me to this point.

Day 4-7: Something started clicking. Literal keys, but also neural pathways. I stopped looking at the keyboard. The columnar layout started making sense. My thumbs were learning their new responsibilities.

Week 3: I was back to ~80 WPM.

Taking the Leap of Faith

If you're considering making the switch, here's my practical advice:

1. Commit to it

The biggest mistake is keeping your old keyboard around "just in case." You'll always fall back to it when deadlines hit, and you'll never build the muscle memory.

2. Start with a typing tutor

Use keybr.com for 15-20 minutes each morning. Focus on accuracy, not speed. Speed comes naturally once the patterns are burned in. I came so obsessed with speed that keybr became a game for me.

4. Go all in

If you also want to change layout (Eg go from QWERTY to DVORAK), do it at the same time. You'll be extremely frustrated at first but you don't have to re-learn after.

5. Be patient with yourself

Your productivity will tank temporarily. Plan for it. Don't start during a critical project sprint. But know that the dip is temporary, and what's on the other side is worth it.

6. Join the community

The mechanical keyboard and ergonomic keyboard communities are incredibly welcoming. Subreddits like r/ErgoMechKeyboards, Discord servers, and forums are full of people who've gone through exactly what you're experiencing.

Unexpected Perks

Beyond the ergonomics and the typing experience, there are some surprisingly practical benefits to a split keyboard that nobody talks about:

Coffee goes in the middle. With two keyboard halves spread apart, there's a natural spot right in the center of your desk for your coffee or tea. This might sound trivial, but think about how many times you've knocked over a mug while reaching across a traditional keyboard. With a split layout, your beverage sits safely between the halves, well away from your arm's sweeping path. I haven't spilled a drink on my desk since making the switch (well I shouldn't but I got some skills and can manage to mess up anyways).
Baby-compatible. As I mentioned, a split keyboard lets you type in positions that would be impossible with a standard board. Each half can go wherever your hands happen to be — on armrests, on either side of a sleeping baby, on the couch.
Desk real estate. A mouse, a notepad, a tablet. There's suddenly room for things in the middle of your workspace that a full-width keyboard used to occupy.
Portable ergonomics. You can take your split keyboard halves to different locations and set them up ergonomically wherever you go. Being small allows to be carried easily without eating up too much space in your bag.

And some cons

Well, nothing is perfect. Apart from the learning curve you just cannot go back after using a split keyboard. This means that when asked help from a fellow coworker or friend on their computer you will be at a disadvantage and will feel stress :).

But bare with me... after a while you will get used to it and will be able to switch back and forth with some practice.

Is It Worth It?

I'll be honest: the switch is painful. There's no sugarcoating the first week. But if you spend significant hours typing every day, investing in how you interface with your computer is one of the highest-leverage improvements you can make.

I am now faster than when I was using a standard keyboard. My typing feels more intentional. And there's something deeply satisfying about using a tool that was designed around human anatomy rather than 150-year-old mechanical constraints.

The QWERTY keyboard served us well. But it's 2026, and we can do better.

[^2]: U.S. Patent No. 207,559 — "Improvement in Type-Writing Machines," granted to Christopher Latham Sholes on August 27, 1878. This patent contains the first documented appearance of the QWERTY keyboard layout. You can view it on Google Patents.

[^3]: Repetitive Strain Injury (RSI) is a broad term for pain and damage caused by repetitive movements and sustained awkward postures. Research shows that keyboard use involving rapid, repetitive movements and static loading — such as holding wrists and shoulders in the same position for extended periods — is a significant contributing factor. A scoping review on upper limb RSI prevention found that ergonomic equipment, particularly adapted keyboards, was among the most studied intervention strategies. See also Pascarelli & Quilter's pathomechanics study on keyboard RSI for a detailed look at the mechanisms involved.

[^4]: The home row is the middle row of letter keys on a keyboard — the row where your fingers naturally rest. On a QWERTY keyboard, that's A-S-D-F for the left hand and J-K-L-; for the right hand. Touch typists are trained to always return their fingers to this row between keystrokes. On a well-designed split keyboard, almost every key you need is reachable without moving your fingers away from this position.

[^1]: The network effect is a phenomenon where a product or technology becomes more valuable as more people use it. In the case of QWERTY, the more people who learned to type on it, the more typewriters and later computers were manufactured with that layout, which in turn meant more people learned QWERTY — creating a self-reinforcing cycle that made switching to a better layout economically and socially impractical.

AI (almost) solved my toddler sleep issues

Sat, 10 Jan 2026 00:00:00 GMT

It was 3 AM. Again. My toddler was screaming, I was running on fumes, and somewhere between the fourth lullaby and the fifth trip to his room, I thought: "There has to be a better way."

Spoiler: there was. After trying various traditional methods without much success, I decided to turn to AI for help.

TL;DR: I combined Frigate (AI-powered video surveillance), a custom CNN model, and Babybuddy to automatically track my toddler's sleep patterns. The model detects not just if he's in bed, but whether he's lying down or sitting up—all in ~15ms with 99%+ accuracy.

The problem

Our toddler was having trouble sleeping through the night. He would wake up multiple times, cry, and have difficulty falling back asleep. This was taking a toll on our entire family, as we were all exhausted from the constant interruptions.

20-30% of toddlers experience sleep disturbances.[^1] In Western countries like the United States, Canada, and Australia, approximately 25% of parents report their babies or toddlers have sleep troubles[^2].

A survey of 1,300+ parents found that parents lose approximately 1,000+ hours of sleep in the first year alone[^3]. That's over a month of sleepless nights!

[^1]: Montgomery P, Dunne D. (2007). "Sleep disorders in children". BMJ Clinical Evidence. 2007:2304. PMC2943792 [^2]: Mindell JA, Sadeh A, Wiegand B, How TH, Goh DYT. (2010). "Cross-cultural differences in infant and toddler sleep". Sleep Medicine. 11(3):274-80. DOI:10.1016/j.sleep.2009.04.012 [^3]: Snuz Sleep Survey (2022). Survey of 1,300+ UK parents found 70% lose an average of 3 hours' sleep per night in their baby's first year (~1,095 hours annually). Source

The Canonical solution

We read books, consulted pediatricians, and tried various sleep training methods. While some of these approaches provided temporary relief, the underlying issues persisted.

As a last resort we decided to try one of what felt to be a big scam... Sleep consultants. We hired not 1 but 2 sleep consultants who provided us with a structured plan to help our toddler develop better sleep habits. The consultant advertised their methods as "tailored to your child's needs" and "based on the latest research in child development." while in reality we spent about 1000$ to receive very well known generic advice that we could have found online (or already read in books).

So we were back to square one, feeling frustrated and desperate for a solution.

If you can't measure it, you can't improve it

Before our child was born, I'd already installed Babybuddy, an open source baby tracking web application, to track feedings, diaper changes, sleep, and other activities.

The picture above shows the sleep patterns of our toddler over some weeks. We could see the frequent awakenings and the total sleep duration.

Tools like this allowed us to collect data on our toddler's sleep patterns, which we could then analyze to identify potential issues.

Unfortunately, when you are a sleep deprived parent, you don't have the time nor the energy to analyze data nor to update it regularly.

Enter AI

During a particularly rough night, I stumbled upon an article discussing the use of AI in healthcare and parenting. This sparked an idea: what if we could leverage AI to track automatically our toddler's sleep patterns and then eventually provide personalized recommendations?

After all, AI has been successfully used in various domains to analyze complex data and provide insights.

Anyone familiar with the self-hosting community knows that Frigate is the go-to open source solution for local AI-powered video surveillance. It uses TensorFlow Lite models to perform real-time object detection on video streams from IP cameras.

I already had an ip-camera installed in the toddler's room for monitoring purposes already hooked into Frigate. So I decided to explore whether I could use Frigate's AI capabilities to monitor my toddler's sleep patterns.

What does Frigate offer?

Well, frigate is not meant to be used for sleep tracking, so I had to get creative. Frigate has APIs that allow you to access detected objects and events. I set up Frigate to monitor the video feed from the toddler's room and configured properly to record up to 24h of footage.

This gave me access to raw training data (the camera frames) I could use for later. Frigate also provides insights about movement in the room, which I could use to infer sleep patterns such as deep & light sleep.

What I (and mommy) want

For our son to sleep through the night!!

I would like to have:

Sleep patterns properly populated into babybuddy automatically
More insights about sleep quality (eg: number of awakenings, total sleep time, sleep efficiency, etc.)
Recommendations to improve sleep based on the data collected

The plan

So the idea was:

Use current homelab systems such as Frigate, BabyBuddy, Home Assistant
Build multiple AI models to analyze the video feed from the toddler's room
Feed in data automatically into babybuddy
Provide actionable daily insights based on the data collected
Keep everything local-only to preserve privacy

Implementation

I had Claude write for me a script to download past 24h images at 5s interval to have some training data for the CNN model it was going to help me build. To refine data I always used claude to perform tedious tasks like download the footage, extract frames, label them, etc.

YoLOv8 + Transfer Learning

We used YOLOv8 as the base architecture for the CNN model. It's a state-of-the-art object detection model that is both fast and accurate, making it suitable for real-time applications with low inference time like this.

We used a technique called transfer learning[^transfer-learning], where we took a pre-trained YOLOv8 model and fine-tuned it on our specific dataset of toddler sleep images. This approach significantly reduces the amount of data and training time required to achieve good performance.

Two main classifiers were needed:

Presence classifier:

empty - no toddler in bed
baby_alone - toddler alone in bed
baby_with_adult - toddler with adult in bed (likely mommy trying to soothe him back to sleep)

Posture classifier (only when baby_alone):

lying_down
sitting_up

I then proceed to label some of the frames keeping classes as balanced as possible.[^classimbalance]

[^classimbalance]: Buda M, Maki A, Mazurowski MA. (2018). "A systematic study of the class imbalance problem in convolutional neural networks". Neural Networks. 106:249-259. DOI:10.1016/j.neunet.2018.07.011 [^transfer-learning]: Ribani R, Marengoni M. (2019). "A Survey of Transfer Learning for Convolutional Neural Networks". 32nd SIBGRAPI Conference on Graphics, Patterns and Images Tutorials. pp. 47-57. DOI:10.1109/SIBGRAPI-T.2019.00010

One challenge was the camera angle: it's mounted almost top-down above the bed. While this made presence detection trivial, distinguishing between sitting_up and lying_down turned out to be surprisingly tricky from above, a sitting toddler doesn't look that different from a lying one (to the AI "eye"). This required collecting significantly more training samples for the posture classifier than I initially expected.

After only a couple of training iterations, the models were already achieving >99% accuracy on the validation set.

Connecting the dots

With the classifier working reliably, I had Claude build a simple web interface so I could monitor the predictions from my phone during critical moments—like bedtime. This let me validate the model's accuracy in real-time.

The next step was to connect everything to BabyBuddy's APIs, automatically logging sleep data without any manual input.

Provided the necessary API endpoints and authentication details, Claude generated the code to push sleep data into BabyBuddy based on the model's predictions.

Fighting feature creep

Once the basic system was working, my brain started doing what engineer brains do:

"I should use the audio profile from the camera to detect crying..."

"Wait, why don't I use the motion data from Frigate to detect restlessness?"

"Oh wow, I could even add a sensor in Home Assistant to track room temperature and correlate it with sleep quality!"

I had to stop myself. The simple classifier was already solving the problem. Every additional feature meant more complexity, more things to break, and more time spent tinkering instead of sleeping.

Sometimes good enough really is good enough.

Results

No more manual logging

The system now runs 24/7, quietly logging every sleep event to BabyBuddy with minute-level precision. I don't even check the dashboard anymore each morning. When we need to, we just ask Claude to summarize the night using the BabyBuddy APIs, and we get a clear picture of how things went.

Before this, my wife and I would often disagree on how many times our toddler woke up—was it three times or four? Did that 2am crying spell last five minutes or twenty? These fuzzy memories led to unreliable data, which made it impossible to spot patterns or make informed decisions about naps and bedtime.

Hidden insights

The system also answered questions we couldn't even ask before:

Was he awake but silent, hoping to go unnoticed?
How long did he sit there before the crying started?

These are things parents simply can't know without continuous monitoring. Turns out, sometimes he'd be awake for 10-15 minutes before making a sound—information that changed how we thought about his sleep patterns entirely.

The uncomfortable truth

The data revealed something important: we were part of the problem.

The visualizations showed us patterns we hadn't noticed... how our decisions sometimes made things worse, not better. Our toddler still doesn't sleep through the night every time (sigh), but the improvement over the past few weeks has been undeniable. We're making data-driven adjustments instead of guessing, and it's working.

Of course AI alone did not solve our toddler's sleep issues—we did. But having accurate data made it way easier to identify what worked and what didn't.

Conclusion

This project started as a sleep-deprived experiment and turned into something genuinely useful. By combining off-the-shelf tools like Frigate and BabyBuddy with a custom-trained model and Claude as my coding assistant, I built a fully automated sleep tracking system in just a few days prompts.

Would I recommend this approach? If you're comfortable with self-hosting and have a camera already set up, absolutely. The time investment paid for itself within the first week of not having to manually log anything.

Turns out, the best parenting tool is one that works while you're too tired to think.

eNSPanel: Building a Better Smart Home Touch Panel

Sun, 04 Jan 2026 00:00:00 GMT

The Sonoff NSPanel is an affordable smart home touch panel that includes a capacitive display, two physical buttons, a buzzer, two relays, and WiFi/Bluetooth connectivity. It's a compelling device at its price point, but the stock firmware and hardware have significant limitations. That's why I created eNSPanel — a custom PCB replacement that addresses these constraints while adding powerful new capabilities.

And here's the custom eNSPanel PCB that replaces the original internals:

Why Replace the Original PCB?

The original NSPanel hardware presents several challenges:

Limited memory — The stock ESP32 module lacks sufficient memory for advanced ESPHome features, making TFT uploads problematic
No presence detection — You can't trigger automations based on room occupancy
No voice capabilities — No microphone for voice assistant integration
No extensibility — The closed design prevents adding custom sensors or modules

What eNSPanel Offers

The custom PCB maintains full compatibility with the original NSPanel enclosure while introducing substantial upgrades:

Upgraded ESP32-S3 Module

The heart of the upgrade is the ESP32-S3-WROOM-1-N16R8 module. This provides:

16MB flash and 8MB PSRAM
Sufficient memory for on-device wake word detection
Better processing power for complex automations
Full ESPHome compatibility without memory constraints

LD2410 Presence Sensor

The board integrates an LD2410 mmWave radar sensor for true presence detection. Unlike PIR sensors that only detect movement, mmWave radar can detect stationary occupants — perfect for triggering automations when someone is sitting still in a room.

Built-in Microphone

With the ESP32-S3's PSRAM, the eNSPanel supports on-device wake word recognition. Say "Hey Jarvis" (or configure your preferred wake word), and trigger your voice assistant without cloud dependencies. This enables distributed voice control throughout your home.

Modular Daughter Board System

Perhaps the most interesting design decision is the mother-daughter board architecture. The main PCB exposes 6 GPIO pins plus 5V and 3.3V power through a 10-pin connector. This allows you to create custom expansion boards:

Add a ZigBee coordinator
Include a speaker for audio feedback
Integrate additional sensors
Connect any peripheral your project requires

The daughter board constraints are well-defined: max 34.6×51.4mm, max 1.6mm thickness, with specific clearances documented for enclosure compatibility.

Design Philosophy

All enhanced features are optional. Don't need presence detection? Skip the LD2410. Don't want voice control? Omit the microphone. The base PCB maintains all original NSPanel functionality — display, buzzer, thermistor, buttons, and relays — so you can start simple and expand later.

The PCB dimensions (under 100×100mm) were intentionally chosen to qualify for manufacturing discounts at most PCB fabrication houses, keeping costs reasonable.

Getting Started

The project repository includes:

Gerber files — Ready to upload to JLCPCB, PCBWay, or your preferred manufacturer
3D models — For visualizing the build and checking enclosure fit
ESPHome configurations — Modular YAML files for each component (display, buzzer, presence sensor, microphone, etc.)
Nextion display files — Custom HMI for the touch interface
Complete documentation — From ordering PCBs through soldering and firmware flashing

Technical Highlights

The ESPHome configuration is split into logical modules:

# Core configuration
packages:
  core: !include esphome/core.yaml
  buzzer: !include esphome/buzzer.yaml
  nextion: !include esphome/nextion.yaml
  ld2410: !include esphome/ld2410.yaml      # Optional
  microphone: !include esphome/microphone.yaml  # Optional

For voice assistant functionality, the configuration leverages ESPHome's micro_wake_word component:

micro_wake_word:
  model: hey_jarvis
  on_wake_word_detected:
    - voice_assistant.start:

When the wake word is detected, the system plays an acknowledgment tone and initiates the voice assistant pipeline — all processed locally on the ESP32-S3.

Who Is This For?

The eNSPanel is ideal if you:

Run Home Assistant with ESPHome
Want room-level presence detection
Desire local voice control without cloud dependencies
Need a platform you can extend and customize
Enjoy hardware projects and aren't afraid of SMD soldering

If you're comfortable ordering custom PCBs and doing surface-mount soldering (or using a reflow oven), this project transforms an inexpensive commercial device into a powerful smart home control point.

Conclusion

The Sonoff NSPanel provides excellent hardware at a low price, but its software and expansion options are limited. The eNSPanel project liberates that hardware, adding presence detection, voice capabilities, and infinite extensibility through the daughter board system — all while maintaining compatibility with the original enclosure.

Check out the GitHub repository and documentation to get started with your own build.

Adding a Footer to NavigationView in Android

Fri, 28 Aug 2015 00:00:00 GMT

Android's NavigationView simplifies creating navigation drawer menus, but it has a limitation: you can only add headers and menu items - no footer support.

Understanding the Internal Structure

NavigationView internally uses a ListView (specifically NavigationMenuView) to display menu items. Headers are added via ListView.addHeaderView().

The Solution

Since it's a ListView under the hood, we can use ListView.addFooterView():

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        NavigationView navigationView = findViewById(R.id.nav_view);

        // Get the internal ListView
        NavigationMenuView navMenuView = (NavigationMenuView)
            navigationView.getChildAt(0);

        // Create and add footer
        View footer = getLayoutInflater()
            .inflate(R.layout.nav_footer, navMenuView, false);

        navMenuView.addFooterView(footer);
    }
}

Important Caveat

This worked in early versions of the Support Library, but Google later replaced ListView with RecyclerView in NavigationMenuView (around version 23.1.1+).

For newer versions, you'll need a different approach:

Use a custom NavigationView implementation
Add the footer as the last menu item with custom styling
Use a completely custom navigation drawer layout

When to Use This

This workaround is useful for older projects or when you have specific version constraints. For new projects, consider designing your navigation without relying on internal implementation details.

Fixing Fragment Overlap in Android's Back Stack

Sun, 16 Aug 2015 00:00:00 GMT

Fragment overlap is one of those Android bugs that makes you question your sanity. Two fragments visible at the same time, stacked on top of each other. Here's what causes it and how to fix it.

The Scenario

You want to navigate A → B → C, but skip B from the back stack so pressing back from C returns directly to A.

The intuitive approach is to skip addToBackStack() on the B→C transaction:

// A → B (add to back stack)
fragmentManager.beginTransaction()
    .replace(R.id.container, fragmentB)
    .addToBackStack(null)
    .commit();

// B → C (skip back stack - THIS CAUSES PROBLEMS)
fragmentManager.beginTransaction()
    .replace(R.id.container, fragmentC)
    .commit();  // No addToBackStack()

Why This Breaks

When you press back from C, the fragment manager tries to reverse the last back stack entry. But that entry knows about A→B, not B→C.

The reverse operation attempts to:

Remove B (which isn't displayed!)
Re-add A

Result: Both A and C are visible simultaneously.

The Root Cause

The fragment manager maintains an internal list of fragments. When back stack operations reverse without proper tracking, fragments get duplicated in this list. Multiple fragments with the same container ID = overlap.

The Fix

Always add transactions to the back stack, then handle custom navigation logic manually:

// Always add to back stack
fragmentManager.beginTransaction()
    .replace(R.id.container, fragmentC)
    .addToBackStack("C")
    .commit();

// Handle custom back navigation
getSupportFragmentManager().addOnBackStackChangedListener(() -> {
    int count = fragmentManager.getBackStackEntryCount();
    if (count > 0) {
        String name = fragmentManager.getBackStackEntryAt(count - 1).getName();
        if ("B".equals(name)) {
            // Skip B, pop again
            fragmentManager.popBackStackImmediate();
        }
    }
});

Key Takeaway

Don't fight the fragment manager's internal state. Let it track everything, then use popBackStackImmediate() and listeners to implement custom navigation flows. Your fragments will thank you.

Detecting Phones, Tablets, and Google TV in Android

Fri, 24 Aug 2012 00:00:00 GMT

When building an Android app, you face a fundamental decision: create a single app version supporting multiple device types, or upload separate optimized versions to Google Play Store.

Single App vs Multiple Apps

Single App Approach:

✅ Less code to maintain
✅ Greater scalability
❌ Requires device-specific routing logic

Multiple App Approach:

✅ Google Play handles filtering upfront
❌ Bug fixes require multiple app updates

The Solution: Utility Methods

Google's IO Sched application provides an excellent example of the single-app approach. Here are the key utility methods for device detection:

public class UIUtils {

    public static boolean hasHoneycomb() {
        return Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB;
    }

    public static boolean isTablet(Context context) {
        return (context.getResources().getConfiguration().screenLayout
                & Configuration.SCREENLAYOUT_SIZE_MASK)
                >= Configuration.SCREENLAYOUT_SIZE_LARGE;
    }

    public static boolean isHoneycombTablet(Context context) {
        return hasHoneycomb() && isTablet(context);
    }

    public static boolean isGoogleTV(Context context) {
        return context.getPackageManager()
                .hasSystemFeature("com.google.android.tv");
    }
}

Practical Implementation

Using the Facade pattern, you can conditionally load different activities based on device type:

Intent intent;
if (UIUtils.isTablet(this)) {
    intent = new Intent(this, MapMultiPaneActivity.class);
} else {
    intent = new Intent(this, MapActivity.class);
}
startActivity(intent);

This approach lets you maintain a single codebase while still providing optimized experiences for different device form factors.

Credit

These utility methods are derived from Google's open-source IO Sched application code.

Android Form Validation with FormEditText

Sat, 26 May 2012 00:00:00 GMT

Input validation can be painful. Building forms in any technology is a boring and tedious job, yet it's one of the most common tasks in app development.

When implementing form validation, we typically face three critical concerns:

In-depth data validation - Ensuring the data format is correct
Mandatory fields checking - Making sure required fields aren't empty
Error presentation - Showing users what went wrong

Introducing FormEditText

To solve these pain points, I created an open-source library called FormEditText, available on GitHub.

The library enables developers to validate EditText fields through simple XML attributes, eliminating boilerplate validation code.

Basic Usage

First, define a custom namespace in your layout and add validation attributes:

<com.andreabaccega.widget.FormEditText
    android:id="@+id/email"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:inputType="textEmailAddress"
    app:testType="email"
    app:emptyAllowed="false" />

Validation Behavior

When you call validate() on a FormEditText:

Valid input: Returns true without additional action
Invalid input: Returns false and automatically displays an error message

Built-in Validators

The library includes validators for:

Email addresses
Phone numbers
Credit cards
IP addresses
Web URLs
Custom regex patterns
And more...

Try It Out

Source code on GitHub
Example application available on Google Play

The library has grown to over 1,400 stars on GitHub and continues to help Android developers build better forms.

Introducing Flatterizor: Storing Complex Objects in Databases

Wed, 09 May 2012 00:00:00 GMT

Standard PHP serialization fails when you need to store complex objects in a database AND query them with SQL. Enter Flatterizor.

The Problem

Imagine you have a user object with nested permissions:

$user = [
    'name' => 'John',
    'permissions' => [
        'can_read' => true,
        'can_write' => false,
        'can_delete' => true
    ]
];

Using serialize() produces output like:

a:2:{s:4:"name";s:4:"John";s:11:"permissions";a:3:{...}}

Now try to write a SQL query to find all users with can_write = true. Nearly impossible.

The Solution

Flatterizor converts complex objects into a normalized structure:

// Input
$user = ['name' => 'John', 'permissions' => ['can_write' => true]];

// Output: flattened key-value pairs
[
    ['path' => 'name', 'value' => 'John'],
    ['path' => 'permissions.can_write', 'value' => true]
]

Database Implementation

Create a table with path/value columns:

CREATE TABLE user_meta (
    user_id INT,
    name VARCHAR(255),  -- the property path
    val TEXT            -- the property value
);

Now you can easily query:

SELECT DISTINCT user_id FROM user_meta
WHERE name = 'permissions.can_write' AND val = '1';

Real-World Use Case

This library emerged from WordPress development needs. I had forms with ~30 fields that needed to be stored as post metadata while remaining searchable.

Instead of creating 30 separate meta keys, Flatterizor handles the complexity automatically while keeping everything queryable.

Get Started

Check out the GitHub repository for documentation and examples.

How to Backup Your Web Server with rsnapshot, rsync, and SSH

Mon, 23 Apr 2012 00:00:00 GMT

Backups become critical when data loss occurs or when you're hosting third-party information. Here's a battle-tested approach using rsnapshot, rsync, and SSH.

Key Questions to Answer First

Why? Data protection and minimizing potential losses
What? Configuration files (Apache, MySQL, Nginx), www directory, databases
Where? From same drive to geographically distributed servers
When? Depends on your data change frequency

Core Principles

The source server should not control backups - It should only expose data
Backup servers should pull, not receive pushes - Prevents compromised servers from accessing backups
Use existing, proven tools - Don't reinvent the wheel

Step 1: MySQL Backup Setup

Create a dedicated backup user with limited permissions:

GRANT SELECT, LOCK TABLES ON *.* TO 'backup'@'localhost' IDENTIFIED BY 'password';

Create a credentials file at ~/.my.cnf:

[mysqldump]
user=backup
password=yourpassword

Secure it:

chmod 700 ~/.my.cnf

Add to crontab for daily 1:10 AM backups:

10 1 * * * mysqldump --all-databases > /backup/mysql/$(date +\%Y\%m\%d).sql

Step 2: SSH Key Setup

Generate a dedicated key pair on the backup server:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/backup_key

On the source server, add the public key with restrictions:

# In ~/.ssh/authorized_keys
from="BACKUP_SERVER_IP",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAA...

Step 3: Rsnapshot Configuration

Install rsync on both servers, rsnapshot on the backup server.

Configure /etc/rsnapshot.conf (use tabs, not spaces!):

snapshot_root   /backup/snapshots/

retain  hourly  6
retain  daily   7
retain  weekly  4
retain  monthly 12

backup  backupper@source:/var/www/    www/
backup  backupper@source:/etc/        etc/
backup  backupper@source:/backup/mysql/   mysql/

Step 4: Sudoers for rsync

Allow the backup user to run rsync with elevated privileges:

# In /etc/sudoers
backupper ALL= NOPASSWD: /usr/bin/rsync

Why This Works

Incremental backups - Only changed files are transferred
Hard-link deduplication - Unchanged files don't consume extra space
Pull-based security - Compromised source can't delete backups
Proven tools - rsnapshot and rsync are battle-tested

This setup has protected my servers for years with minimal maintenance overhead.

Execute Code Only on First App Launch in Android

Thu, 12 Apr 2012 00:00:00 GMT

A common Android development challenge: executing code exclusively during an application's initial launch. A practical use case is displaying a tutorial or onboarding flow only when users first open the app.

The Solution

Leverage SharedPreferences to track whether the app has been launched before:

public class MainActivity extends Activity {

    private static final String PREFS_NAME = "MyPrefs";
    private static final String FIRST_LAUNCH_KEY = "firstLaunch";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        if (isFirstLaunch()) {
            // Your first-launch code here
            showTutorial();
            markFirstLaunchComplete();
        }
    }

    private boolean isFirstLaunch() {
        SharedPreferences prefs = getSharedPreferences(PREFS_NAME, MODE_PRIVATE);
        return prefs.getBoolean(FIRST_LAUNCH_KEY, true);
    }

    private void markFirstLaunchComplete() {
        SharedPreferences prefs = getSharedPreferences(PREFS_NAME, MODE_PRIVATE);
        prefs.edit()
             .putBoolean(FIRST_LAUNCH_KEY, false)
             .apply();
    }

    private void showTutorial() {
        // Display your onboarding UI
    }
}

How It Works

Check the SharedPreferences for a boolean flag
If the flag doesn't exist (or is true), it's the first launch
Run your initialization code
Set the flag to false to prevent future execution

Important Caveat

This approach resets when the app is uninstalled, since SharedPreferences data is cleared with the app. If you need persistence across installs, consider:

Storing the flag on a server
Using device identifiers (with appropriate privacy considerations)
Using Android's Backup API

For most use cases like tutorials and onboarding, resetting on reinstall is actually the desired behavior.

Password Reset: A Modern Design Pattern

Sat, 07 Apr 2012 00:00:00 GMT

Let's talk about password recovery mechanisms - specifically, why some old approaches are dangerous and what the modern best practice looks like.

The Bad Old Days

Insecure patterns from the past included:

Plain text storage - Allowing users to retrieve their original passwords
Symmetric encryption - Same problem, just with extra steps
Security questions - "What's your mother's maiden name?" (easily guessable or social-engineerable)

The Modern Approach: Password Reset

Instead of retrieving passwords, implement a secure reset flow:

The Process

User requests password reset via username or email
Application generates a unique, cryptographically random token
Token is stored in the database with an expiration timestamp
User receives an email with a reset link containing username and token
Application validates the request
User sets a new password

Validation Checklist

Before allowing a password reset, verify:

✅ Valid username/token pairing
✅ Token hasn't expired (typically 24-hour window)
✅ Token hasn't been previously used (one-time use)

Why Not Send Auto-Generated Passwords?

Think about what happens if an attacker gains access to someone's email. They could:

Request password resets for various services
Search for "password" in the email archive
Access accounts using the auto-generated passwords found

By requiring users to actively set their new password on your site, you add an extra layer of protection.

Implementation Tips

CREATE TABLE password_resets (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    token VARCHAR(64) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    used_at TIMESTAMP NULL,
    expires_at TIMESTAMP NOT NULL
);

Always hash the token before storing it (just like passwords), and invalidate it immediately after use.

Preventing XSS While Allowing Some HTML Tags in PHP

Fri, 23 Mar 2012 00:00:00 GMT

PHP's strip_tags() function seems like an easy solution for allowing certain HTML elements while blocking others. But it has a dangerous flaw.

The Problem

strip_tags() accepts a second parameter to whitelist specific tags:

$clean = strip_tags($input, '<a><b><i>');

Looks safe, right? But what if the input contains:

<a href="javascript:alert('XSS')" onclick="stealCookies()">Click me</a>

The <a> tag is whitelisted, so it passes through - complete with its malicious attributes. strip_tags() removes tags, but preserves their attributes.

The Solution

If you don't need attributes, strip them entirely:

function strip_tags_with_attributes($string, $allowedTags) {
    // First, strip disallowed tags
    $string = strip_tags($string, $allowedTags);

    // Then remove all attributes from allowed tags
    return preg_replace('/<(\w+)[^>]*>/', '<$1>', $string);
}

// Usage
$input = '<a href="javascript:bad()" onclick="evil()">Link</a>';
$clean = strip_tags_with_attributes($input, '<a><b><i>');
// Result: <a>Link</a>

When This Isn't Enough

If you actually need to preserve safe attributes (like href for links), you need a proper HTML sanitizer:

HTMLPurifier - The gold standard for PHP
DOMDocument - Parse and whitelist specific attributes

Key Takeaway

strip_tags() alone is not safe enough when you're whitelisting tags. Always consider what attributes could slip through and either:

Remove all attributes (simple approach above)
Use a proper HTML sanitization library (complex but flexible)

Never trust user input, even when it appears to be sanitized.

Handling onChange Events on EditText in Android

Sat, 09 Oct 2010 00:00:00 GMT

If you're coming from web development, you might be looking for something similar to HTML/JavaScript's onChange event for Android's EditText widget. Here's how to implement real-time change detection.

Common Use Cases

Monitoring EditText changes is useful for:

Character count display - Showing users how many characters they've typed
Remaining characters - Like Twitter's character limit countdown
Live processing - Sending partial input to a server for autocomplete suggestions

The Solution: TextWatcher

Android provides the TextWatcher interface for monitoring text changes. Register it with your EditText using addTextChangedListener():

EditText editText = findViewById(R.id.et_text);
TextView charCount = findViewById(R.id.char_count);

editText.addTextChangedListener(new TextWatcher() {

    @Override
    public void afterTextChanged(Editable s) {
        // Called after the text has changed
        charCount.setText(String.format("%d characters", s.length()));
    }

    @Override
    public void beforeTextChanged(CharSequence s, int start, int count, int after) {
        // Called before the text is changed
    }

    @Override
    public void onTextChanged(CharSequence s, int start, int before, int count) {
        // Called as the text is being changed
    }
});

Which Callback to Use?

beforeTextChanged - Called before changes are applied. Useful for capturing the previous state.
onTextChanged - Called during the change. You get info about what's being added/removed.
afterTextChanged - Called after changes are complete. Best for most use cases like updating UI.

For simple scenarios like character counting, afterTextChanged is usually what you need. The Editable parameter gives you direct access to the current text content.

Android Root Certificate Authorities List

Thu, 23 Sep 2010 00:00:00 GMT

Ever wondered which Certificate Authorities are trusted by Android? Here's how to extract the root CA list from an Android device.

Prerequisites

Download the BouncyCastle provider JAR
Place it in $JAVA_HOME/lib/ext directory
Ensure $JAVA_HOME/bin is in your system PATH

Extracting the Certificates

Pull the certificate store from your device and extract the list:

# Pull the certificate store from the device
adb pull /system/etc/security/cacerts.bks cacerts.bks

# Extract certificate information
keytool -keystore cacerts.bks \
        -storetype BKS \
        -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
        -storepass changeit \
        -list -v >> certificates.txt

What You'll Find

Android 2.2 (Froyo) included 57 trusted certificate entries from authorities including:

VeriSign
DigiCert
Equifax
StartCom
GlobalSign
Thawte
GeoTrust
And many others from various countries

macOS Note

On macOS, you may need to use the full keytool command path:

/Library/Java/JavaVirtualMachines/jdk-X.X.jdk/Contents/Home/bin/keytool

Why This Matters

Understanding which CAs are trusted helps you:

Debug SSL/TLS certificate issues
Understand the security implications of your app's connections
Plan certificate pinning strategies

Adding Events to Google Calendar on Android

Mon, 09 Aug 2010 00:00:00 GMT

Google doesn't officially recommend using internal Calendar APIs, but sometimes there's no other way to achieve certain tasks. Here's how to add calendar events programmatically across different Android versions.

The Provider URI Challenge

The main challenge is that the Calendar content provider URI changed between Android versions:

Pre-Froyo (< 2.2): content://calendar/events
Froyo and above (≥ 2.2): content://com.android.calendar/events

The Solution

Here's a version-agnostic approach to adding calendar events:

private Uri getCalendarUri() {
    if (Build.VERSION.SDK_INT >= 8) {
        return Uri.parse("content://com.android.calendar/events");
    }
    return Uri.parse("content://calendar/events");
}

public void addCalendarEvent(String title, String description,
                              long startTime, long endTime) {
    ContentResolver cr = getContentResolver();
    ContentValues values = new ContentValues();

    values.put("calendar_id", 1);
    values.put("title", title);
    values.put("description", description);
    values.put("dtstart", startTime);
    values.put("dtend", endTime);
    values.put("eventTimezone", TimeZone.getDefault().getID());

    Uri eventUri = cr.insert(getCalendarUri(), values);

    if (eventUri != null) {
        Log.d("Calendar", "Event created: " + eventUri.toString());
    }
}

Required Permissions

Don't forget to add the calendar permissions to your AndroidManifest.xml:

<uses-permission android:name="android.permission.READ_CALENDAR" />
<uses-permission android:name="android.permission.WRITE_CALENDAR" />

Important Notes

This uses undocumented APIs that may change
Always check for null returns from insert()
Consider using the Calendar Intent for a more stable approach when user interaction is acceptable

The Intent-based approach is more reliable for user-facing features, but programmatic insertion is useful for background sync scenarios.