Let Me Explain Myself…

Like this. No, Wait... Maybe Like That? a.k.a. The Domain Translation Unlock

2026-07-11T12:00:00+00:00

I have this idea for a tattoo I’ve been thinking about for quite some time—maybe 3 years. I know what the essence of it is:

It’s a visual representation of an audio frame
From the song Telegraph Road
A specific guitar sequence
Likely black ink
It will be smallish, I’d say 1.5–2.5 cm
It will peek out from behind one of my ears

Yeah. If you’re reading this description, I bet you’re imagining something. You might think “this is cool” or maybe “meh”. Regardless, I’d bet good money that it’s not what I’m imagining.

So, over the years I’ve tried to capture that frame using an o-scope, a spectrogram, or guitar tabs. I described this to different people, and even tried to draw it. The outcome never looked the way I wanted or imagined. But why? I know what I want, I even have a vague mental image of it, and yet I cannot produce it.

Why is that?

Well, obviously, I am not an artist, so I can’t draw it. I’m not an audio engineer, so I don’t know how to generate the right spectrogram—or if a spectrogram is even the right visual. I’m not a guitarist, so finding the exact tab is guesswork. Real blockers. My imagination is locked behind a vocabulary and skillset I don’t have: those are simply not my domains.

You know what domain I do inhabit? Software engineering.

Disclaimer

This post is not about a novel approach for how to use AI; it’s not even an out-of-the-ordinary use case. Here I am merely pointing to what AI allows us—people—to solve in our day-to-day issues.

Let’s unlock this

If I can’t produce a quality drawing, maybe I can PoC this—produce various versions of my idea and see what feels right to me. Once I have a couple of versions I like, I can show them to an actual artist and get their feedback. But at that point, the only person I need to excite is me—hey, I will have it permanently on my skin.

Basically, I am going to use AI to map from my domain (software engineering) to other domains (audio engineering and sketching).

Plan

Here is my plan to generate some options:

Get a digital file (MP3) of the song. Luckily, I own the CD (yes, I linked to Wikipedia’s CD because I have no idea how young you are), so ripping that is easy.
Use AI to understand the technical parts:
how to read an audio file into a buffer
how to extract audio metadata
do I need FFT, or maybe raw PCM?
what TypeScript (I arbitrarily pick TypeScript for my work here) library can help me with that?
what are my options for audio visualization?
Use AI to design (plan) the technical execution of the POC tool:
1. UX for pinpointing the data frame
2. UX for switching between different visualizations
3. How to adjust each visualization
4. UX for freezing/exporting a frame
Use AI to implement the tool

The Unlock

Before the days of AI, searching, planning, and summarizing the different tools and options would take hours or days. Obviously, I also had low confidence that I would know what to search for—how to translate what I need into a search query.

And so such an endeavor—yes, I use exactly that word—would have been intimidating: do I have the time? Can I really do this? Is my TypeScript proficiency enough? Do I even know if I explored the right audio visualization options? Did I process the audio correctly? Do I have the focus to go over all the options and research them? Etc. Frankly, I would postpone this or give up. I would just not do it.

AI unlocks my imagination by acting as a domain translator—mapping my words to the correct audio-engineering domain and performing a well-focused search.

Not only does AI speed things up, or serve as the best search tool we’ve ever invented; the tools around AI are structured in a way to keep context! I can give the Agent something to work on and come back later when I have time to focus. The details will be there: our conversation history, the details it found, the questions I asked, the breakdowns it produced, and the decisions I made. All there.

Anecdotal benefit

A quick side note: normally, manually building something in an unfamiliar domain ends in frustration, or me falling in love with my code just because I spent hours writing it. AI entirely removes that friction. Because generating and discarding ideas costs almost nothing, I can follow Rule #9 of the Ten Rules of Performance—to write it and rewrite it. I can quickly cycle through iterations until I find the perfect visual to hand off to a professional, and simply throw the code away when I’m done.

Did I do it?

So, I told you a story, but have I followed through? Was I unlocked?

Technical research

Okay, let’s prompt Gemini to help us with that:

Explain how to extract audio frames (or raw audio buffers) from an MP3 file using standard modern web capabilities and tools.
Also, give me a very short technical review of what is the data in the audio buffer.

Complement this by finding a TypeScript library that can do the following audio functions:
- extract frequency values or amplitudes from an audio frame
- support various frame frequency representations
- review the various audio visual representations available and what each shows

Give me a basic flow of using this TS library, and very short code examples (with a lot of comments).

My goal is to experiment with different ways of 2D visualization using web canvas.

I am a seasoned coder, I have a good grasp of TypeScript, but I am not an audio engineer and I know very little about audio formats.

Good. First, Gemini told me it’s a “fantastic project”. That’s nice blushing.

Then, Gemini gave me some really good pointers:

We should use Web Audio API which can decode MP3, with a simple pipeline:

Fetch the MP3 binary -> Convert to an ArrayBuffer -> Decode into PCM samples inside an AudioBuffer.

It also gave me a code snippet:

const audioCtx = new (window.AudioContext || (window as any).webkitAudioContext)();

async function getRawAudioBuffer(mp3Url: string): Promise<AudioBuffer> {
  const response = await fetch(mp3Url);
  const fileArrayBuffer = await response.arrayBuffer();
  
  const decodedBuffer = await audioCtx.decodeAudioData(fileArrayBuffer);
  return decodedBuffer;
}

Pretty nice. It’s a pure plumbing snippet, just to get me off the ground quickly.

Gemini was also nice enough to give me a crash course on what AudioBuffer and PCM (Pulse Code Modulation) audio are. Look at that, now I feel less awkward with technical audio jargon. It continues to talk about rms (Root Mean Square), amplitudeSpectrum, powerSpectrum, chroma, etc.—giving me novice technical descriptions for audio concepts. These gave names to the vague ideas floating around in my head—translating an aesthetic itch into concrete signal-processing vocabulary.

It then introduces meyda as the gold-standard for audio feature extraction in JS, and gives me a code example of how to use it.

This phase was so quick: one prompt, a couple of follow-ups, and my ability to express my requirements in a technical sense has grown. I was unlocked in minutes, whereas a previous (non-AI) iteration would have taken me an evening at the least.

To be continued

That was fun. I can pause now, knowing that all the context — summary, links, follow-ups — is still there in the chat session. Next up: brainstorming and prototyping an audio visualizer, along with a UI for tweaking the visuals.

TTYL.

No! We don't use that here! a.k.a. Making AI Coding NP-Complete

2026-01-31T12:00:00+00:00

We’ve all been there. You ask your shiny new AI Agent to “add a user profile endpoint,” and it generates 50 lines of pristine, bug-free, idiomatic Python.

And you hate it.

It’s not that the code is wrong. It compiles. It runs. It passes tests. But it’s… wrong.

“We don’t use FastAPI dependency injection like that; we use our own ServiceContainer.”
“Why is there a raw SQL query? We have a strict LegacyQueryFramework wrapper for that.”
“Please don’t introduce a new utility for date formatting; use TimeUtils.”

So you write a comment. Then you edit the prompt. Then you update that massive AGENTS.md file that is rapidly becoming a novel. You are stuck in a loop of teaching the same lessons over and over again.

LLMs are incredible coders. But they are terrible employees — they forget.

They don’t know “how things are done around here.” And trying to teach them by shoving more and more context into the prompt is a losing battle.

I think we’re approaching this the wrong way. We’re trying to solve an NP-Hard problem, when we should be solving an NP-Complete one.

The Theory: Why Generation is NP-Hard

In computational complexity theory, NP-Hard problems are those where finding a solution is extremely difficult. NP-Complete problems are a special subset where finding the solution is hard, but verifying a proposed solution is efficient (polynomial time).

(Note: I’m using these terms loosely as a metaphor—the analogy isn’t mathematically precise, but the intuition holds.)

Think about coding in that context.

Code Generation is NP-Hard. When you ask an Agent to “write code that fits our organization’s standards,” you are asking it to search an infinite space of possible syntaxes, libraries, and architectural patterns to find the one specific combination that matches your organization’s unwritten rules. To do this successfully, the Agent needs perfect knowledge of your entire codebase, your history, and your personal preferences. That is a massive search problem. Not only that, but the Agent may find many different solutions that are all correct given the current context, but none of them are “good enough” - they all fail to meet the organization’s actual, ever-evolving standards.

Code Verification is P (Polynomial Time). But if I show you a piece of code, you can instantly say: “No, don’t use GraphQL here, use LegacyQueryFramework.” Verifying if a solution fits expectations is cheap. You don’t need to know how to write the perfect code to know that the current code is wrong.

Author’s Note: I’m simplifying here. Verifying deep logical correctness or security properties is still incredibly hard (often undecidable). But verifying “Style” and “Local Constraints”—which is what most code review nitpicks are about—is almost always computationally cheap. You scan, you spot the pattern, you flag it.

The essence of an NP-Complete problem is that finding a solution is hard, but verifying a solution is easy. Coding is NP-Complete.

Right now, we are asking our Agents to be perfect Generators. We are overloading them with context hoping they can “solve” the Style Problem in one shot.

We should stop doing that. We should assume the Generation will be imperfect, and focus on building a really fast, really smart Verifier.

Enter The “Reviewer” Model

Imagine a new architecture for AI coding. Instead of one massive “Do-It-All” model, we have two:

The Writer: A capable, general-purpose frontier model. It knows Python, it knows logic, it knows how to solve problems. It doesn’t know your specific internal style quirks, and that’s okay.
The Reviewer: A small, specialized model (e.g., a fine-tuned Gemma 2B or 7B). It might not be smart enough to write complex logic, but it has been fine-tuned on one thing: Your Code Reviews.

The workflow changes from “Prompt -> Code” to a loop:

Writer generates a plan/code.
Reviewer looks at it. It doesn’t check for bugs, code syntax, format, etc. (we have other tools for that). It checks for Taste.
Reviewer says: “This looks 3/10. Re-direct: We prefer to chain JavaScript promises here.”
Writer updates the code.
Reviewer says: “8/10. Good enough.”

The Reviewer doesn’t need to know the right answer. It just needs to know that the current answer is wrong, and point the Writer in the right direction. We are effectively reducing the problem complexity: The Writer provides the raw intelligence; the Reviewer provides the constraints.

The “Secret Sauce”: Living Memory

“But wait,” you ask, “Don’t I still have to train this Reviewer? Isn’t that just AGENTS.md with extra steps?”

No. Because you shouldn’t be writing rules. You should just be doing your job.

We can harvest the training data for this Reviewer automatically from the “Exhaust” of your engineering org.

Data Mining the “Taste”:

The “Squash & Merge” Delta: When an Agent opens a PR, and a developer eventually merges it, the difference between the Agent’s original code and the final merged code is pure gold. It is a labeled dataset of “What the Model wanted” vs. “What the Org wanted.”
The Comment Thread: Every time a senior engineer comments “Please use logger instead of print,” that is a negative training example for print and a positive signal for logger.
IDE Shadowing: In a “Copilot” setting, if the AI suggests code and the user immediately backspaces and retypes it, that is a strong negative signal.
Direct Feedback: When you explicitly correct the Agent in chat, that is high-quality data. We could even add simple reaction emojis (👍/👎) to every Agent reply to gather “Taste” signals with zero friction.

We can feed this stream of stylistic preferences into a small model. This creates a Living Memory of the organization’s taste. It evolves as you evolve. If you stop using LegacyQueryFramework and switch to GraphQL, the training data shifts, the Reviewer updates, and the Agents follow suit—without anyone updating a markdown file.

Of course, this isn’t magic. “Garbage In, Garbage Out” still applies. You can’t just feed raw git logs into a model; you need to filter for “clean” commits, successful merges, and ignore the chaotic “fix typo” churn. But automating data curation is still infinitely more scalable than manually writing rules.

The Logistics: Can We Actually Do This?

“Fine-tuning a model” sounds expensive and scary. It used to be. Today, it’s a weekend project.

Here is the napkin math for building your organization’s reviewer:

1. The Data

You don’t need “Big Data.” For a specialized classifier like this (Binary: “Good/Bad” or Classification: “Pass/Refactor”), you can see results with as few as 1,000 - 5,000 examples.

Source: Your existing PR history.
Labeling: Automated scripts (e.g., “accepted without comments” vs “commented on”).

2. The Model

(as of January 2026—this list will likely be outdated soon) You don’t need GPT-4. You need something small, fast, and verify-capable.

Gemma 2B / 7B: Google’s open models are excellent for this. The 2B version is tiny enough to run on almost any modern laptop.
Phi-3-mini: Microsoft’s 3.8B model packs a punch way above its weight class.
Llama 3 8B: A bit heavier, but widely supported and very capable as a generalized “Judge”.

3. The Method

(Disclaimer: I am not an expert in fine-tuning, so take this as a high-level overview) You won’t retrain the whole model. You will use PEFT (Parameter-Efficient Fine-Tuning) techniques:

LoRA (Low-Rank Adaptation): Freezes the big model and trains tiny “adapter” layers.
QLoRA: Does the above but with 4-bit quantization, allowing you to train on a single consumer GPU (like an NVIDIA T4 or RTX 4090).

4. The Cost

Training: On a cloud GPU (e.g., T4 on Google Colab or AWS), a fine-tuning run for a small dataset takes <1 hour. Estimated cost: <$5. That’s cheap enough to do re-training every week.
Serving: Serving a small model like Gemma or Llama 3B on a cloud provider costs roughly $0.02–$0.10 per 1M tokens (based on Together AI pricing). Compared to GPT-4o input costs (~$2.50/1M tokens), it’s negligible.

It is cheaper to run a custom-trained 2B parameter verification model than to jam 50k tokens of “Rules” into every GPT-4 prompt.

The Knowledge Trap: Why Your Reviewer Doesn’t Need a Library Card

The primary critique of fine-tuning—that it is a “leaky” and inefficient way to inject factual knowledge compared to RAG—actually reinforces the Reviewer/Writer split. The theory remains robust because it shifts the objective of fine-tuning from Data Storage to Behavioral Alignment.

1. Taste is a Pattern, Not a Fact

Fine-tuning is notoriously poor at “memorizing” specific, isolated facts (like a new API endpoint name), but it is exceptionally good at Domain Adaptation. “Taste” (organizational style, architectural preferences, idiomatic patterns) is a statistical distribution, not a lookup table. The Reviewer doesn’t need to be an encyclopedia; it needs to be a Filter that recognizes the “shape” of acceptable code.

2. Training on the “Direction,” Not the “State”

While RAG pulls from the current state of a codebase (which is often messy or full of legacy “noise”), the Reviewer is fine-tuned on the Diffs—the “Exhaust” of the PR process.

This allows the Reviewer to learn the vector of improvement (e.g., “We are moving away from X and toward Y”).
Because it learns the correction rather than the static fact, the inherent “lossiness” of fine-tuning becomes an advantage: it ignores the noise of the codebase and focuses on the signal of the organization’s evolution.

3. Decoupling “The Brain” from “The Conscience”

The Fine-Tuning Knowledge Gap only breaks a model if that model is expected to be the sole source of truth. In the Reviewer Architecture:

The Writer (Frontier Model) uses its massive scale and RAG to handle the NP-Hard Generation and factual knowledge.
The Reviewer (Small Fine-Tuned Model) handles the Verification.

By separating these concerns, the fact that a 2B parameter model isn’t a great “database” doesn’t matter—it only needs to be a great judge.

Prior Art: It’s Not Just Theory

This isn’t just a fun thought experiment. The biggest players in AI and Tech are already validating pieces of this puzzle.

1. The “Reviewer” Architecture Works (Google & Microsoft)

Google deployed a model trained purely on resolving code review comments. It focuses on the “cleanup” phase—predicting the edit needed to satisfy a human reviewer—and achieved a 50%+ acceptance rate.
Microsoft released CodeReviewer, a model pre-trained on the interaction of code reviews (Code Change → Review Comment). It proved that a model trained on diffs and comments beats a generic large model at spotting errors.

2. The Data Strategy Works (Meta & LIMA)

Meta fine-tuned Llama on 64,000 internal <Review Comment, Patch> pairs (MetaMateCR). Their fine-tuned model outperformed GPT-4o by 9 percentage points—proving that your own data beats a bigger generic model.
LIMA (arXiv:2305.11206) showed that even 1,000 carefully curated examples can produce competitive results, reinforcing that you don’t need “Big Data”—you need clean data.

3. The Future is Reward Engineering (DeepSeek)

DeepSeek-R1 (released Jan 2025) pioneered using large-scale Reinforcement Learning to force a model to “pause and verify” its own output (Technical Report). This is the logical endpoint of our Reviewer: training the “Taste” directly into the model’s reward function.

A New Kind of Feedback Loop

We are currently stuck in a local maximum of “Prompt Engineering”—trying to craft the perfect set of instructions to get the perfect result.

We need to move to Reward Engineering. We need to accept that “Taste” is hard to describe but easy to recognize. By building specialized models that act as automated Code Reviewers, we can finally scale the most unscalable part of software engineering: our culture.

We don’t need generic speed; we need specific taste. It’s time to clone our team’s DNA.

Faster Builds Without Owning Code a.k.a. I Don't Know Rust, But AI Does

2026-01-18T12:00:00+00:00

We software engineers are creatures of habit. We have our comfortable pair of slippers: the languages we know by heart. For me, and for many of my colleagues, those languages are TypeScript, Python, Java, etc.

We use these languages for everything. Not just for the app code, but for the glue that holds our build system together. In our Bazel setup, we have dozens of little helper tools: generators, linters, formatters, and transpilers.

But comfort comes with a tax.

The “Node.js Tax”

Let’s look at a specific example: generating .d.ts Declaration files for our TypeScript packages.

We have a custom tool for this. It’s written in TypeScript, runs on Node.js, and uses swc under the hood. It’s a great tool. It’s readable, easy to modify, and by human standards, it’s fast. It takes about 750ms to process an average-sized package.

750ms. That sounds fine, right?

But we have tens of thousands of packages. And in a build system like Bazel, those milliseconds add up. Every time we spin up a Node.js process, we pay a startup penalty. We pay for the single-threaded nature of the event loop - even if we use async I/O operations.

To make this truly fast—we’re talking single-digit milliseconds in most cases and ~100ms on the big ones—we would need to move to a native language. Something like Rust. We could use specific crates (like oxc, the Oxidation Compiler) directly as libraries, bypassing the process-spawning overhead and utilizing true multi-threading.

But here is the friction: I don’t know Rust. And none of my teammates know Rust.

At least, not well enough to write a production-grade, highly optimized build tool from scratch. And honestly? I don’t want to learn it just for this one 50-line script. So, we stuck with the slow, comfortable Node.js tool.

Well… until now.

From “Coder” to “Agent Manager”

We need to fundamentally shift how we view our role in the codebase.

For decades, we have been the authors of every line of code. If we didn’t write it, we didn’t own it. If we didn’t understand the syntax, we couldn’t maintain it.

This implementation constraint is now gone. We should evolve into AI-Agent Managers.

We don’t need to know exactly how every non-critical, non-proprietary piece of code is implemented.

AI is excellent at parsing code. It can explain what a snippet does better than most original authors.
AI is excellent at pattern matching. It can look at an existing tool and say, “I will write a Rust version that behaves exactly like this.”

The “secret sauce” of our company isn’t in how we invoke a TypeScript compiler. That’s generic code. It doesn’t need to be “ours.” It just needs to work.

Letting AI Write the Rust

So, I tried an experiment. I took our dts-emit tool and I gave it to an AI Coding Agent.

I didn’t write a single line of Rust. I didn’t worry about the borrow checker. I simply described the behavior I wanted and the constraints (must use oxc, must be a CLI, must match the arguments of the old tool).

The result? rust_oxc_dts_emit.

Development Time to POC: ~30 minutes*.
- Caveat: I already had a full, battle-tested TypeScript implementation to reference, some Rust examples in the codebase, and lots of real-world test cases.
My Rust Knowledge Required: Zero.
Performance: The new tool runs on average in around 200ms. Moreover, it runs in single-digit milliseconds on single-file packages!
Additional time to productize and document: A couple of hours.

That is a ~3.5x speedup on average!

# Before (Node.js + swc) - 200 typescript files
time node dts-emit src/
# 780ms

# After (Rust-based + oxc) - same 200 typescript files
time rust_oxc_dts_emit src/
# 215ms

By moving from a “spawning a Node process” model to a “native binary using a library” model, we obliterated the overhead. And because the AI handled the implementation, the “cost” of using a language I don’t know was effectively zero.

Identifying Candidates: It’s Not Just About Rust

While Rust was the right choice for this specific task due to the oxc library, the principle applies to any language that offers better performance or safety for the job at hand. You might choose Go for a network service, or a pre-compiled Python binary for a complex data task.

How do you spot a candidate for an AI-rewrite?

The “Glue” Script: Look for scripts that primarily move data between other tools. If they are just subprocess.call wrappers, they can be rewritten in a faster, safer language.
The “Slow but Simple”: Tools that take noticeable time (100ms+) but do something logically simple (like generating files, parsing JSON, or checking file existence).
The “Black Box”: Legacy scripts that everyone is afraid to touch. Since you don’t understand them anyway, having an AI rewrite them in a modern, strictly-typed language often increases maintainability because the AI will add types and structure that the original lacked.
No Secret Sauce: Code that relies purely on public logic or open-source libraries. If it contains complex, proprietary business logic, you might want to keep it in a language you can debug manually.

Maintenance: The “Context Window”

The immediate question I get is: “But what happens when it breaks? You don’t know Rust!”

This is where the Agent Manager mindset kicks in.

When it breaks, I don’t open the code and try to debug memory leaks. I copy the error message, paste it to my Agent, and say: “Fix this.”

But for this to work reliably, we need to change how we document.

In this new world, the README.md is not just for humans. It is the Context Window for the next Agent. We MUST have the AI document the tool meticulously:

Usage instructions.
Design decisions (why oxc? why this crate?).
Known edge cases.

This documentation ensures that when the next Agent picks up the task 6 months from now, it has the full context needed to maintain the code, even if the human “manager” has forgotten everything about it.

Why This Matters: The Scale of Trust

The implications go beyond just saving a few milliseconds on a build script.

Right now, we are comfortable delegating these small, isolated scripts. They are easy to verify: input in.json, output out.rs. We can treat them as black boxes because the scope of failure is limited to a single build step.

But this is just the training ground.

As our confidence in AI Agents grows and their capabilities improve, the definition of “manageable code” will expand. Today it’s a 50-line build tool. Tomorrow it might be a non-critical microservice, or a complex validation library.

We are training ourselves to be Managers on the small stuff so we are ready for the big stuff. We are learning how to specify behavior rather than implementation, how to verify outcomes rather than syntax, and how to maintain systems we didn’t build.

Side Note: This Has Happened Before - kinda

This transition might feel unnatural to us software developers. We pride ourselves on knowing exactly how our tools and systems work. But giving up intimate knowledge of implementation details is exactly what happens in every mature engineering discipline as complexity scales. A few examples:

Hardware Engineering (High-Level Synthesis): Engineers write behavioral code, and the tool synthesizes the cycle-accurate Register-Transfer Level (RTL). The engineer owns the behavior; the tool owns the implementation.
Mechanical Engineering (Generative Design): Engineers define the physical constraints (materials, load-bearing points, boundaries), and the software iterates to find the optimal structure. The engineer owns the requirements; the software owns the how.

While these tools strictly handle implementation mechanics (with no decision-making), the underlying shift is similar: intimate knowledge of the low-level code is not that important.

Conclusion

We have unlocked a new category of software in our build pipeline: High-Performance, Low-Maintenance, AI-Owned Utilities.

We no longer have to choose between “fast” and “readable.” We can have both. We just have to be willing to let go of the idea that we need to write the code ourselves.

So, look at your package.json scripts. Look at those slow Python glue scripts. What are you keeping around just because it’s comfortable?

It’s time to evolve. Fire your inner Node.js expert and hire an AI Agent manager. Start with the small tools, build your confidence, and watch your build times drop. The future of development isn’t just about writing code—it’s about knowing which code you shouldn’t be writing at all.

CI/CD at AnySoftKeyboard Part 2 aka Ship It!

2025-11-09T12:00:00+00:00

In Part 1 of this series, we discussed how Continuous Integration (CI) at AnySoftKeyboard ensures that our main branch is always in a healthy, shippable state. Through rigorous testing, static analysis, and code style checks, we gain the confidence that our code is robust and ready for prime time.

But what good is a perfectly integrated codebase if it never reaches our users? This is where Continuous Deployment (CD) comes into play. In this second part, we’ll dive into how AnySoftKeyboard automates the process of getting our application from our main and release branches directly into the hands of our users.

Why Continuous Deployment? The Need for Speed and Feedback

The primary goal of Continuous Deployment is to make the release process routine, reliable, and, most importantly, fast. Instead of infrequent, high-stress “release days,” CD allows us to deliver value to users continuously.

For AnySoftKeyboard, this means:

Faster Feedback from Alpha and Beta Users: By deploying frequently to our Alpha and Beta channels, we get new features and bug fixes into the hands of our most engaged users almost immediately. This rapid feedback loop is invaluable for validating new functionality, identifying regressions, and ensuring a high-quality user experience before a wider release.
Quick Delivery of Features and Fixes: When a critical bug is found or a highly anticipated feature is ready, CD enables us to push it out to users with minimal delay, maximizing impact and user satisfaction.
Reduced Risk: Each deployment is a small, incremental change, making it easier to identify and roll back issues if they arise, compared to large, infrequent releases.

Our Deployment Triggers: Different Cadences for Different Audiences

AnySoftKeyboard employs a multi-channel deployment strategy, each with its own trigger and audience, allowing us to balance rapid iteration with stability.

Alpha Channel (The Cutting Edge)

Metric: Deployment to Alpha takes approximately 15 minutes from merge to Play Store.
Pointer: The Alpha deployment is kicked off by the checks.yml workflow, which runs on every push to the main branch. After all checks pass, it triggers a deployment request.
Snippet: This process is defined in .github/workflows/checks.yml. The workflow triggers on a push to main, and if all checks pass, the final deploy-request job is executed to initiate the Alpha deployment.

Beta Channel (The Weekly Digest)

Pointer: The Beta promotion is handled by a scheduled workflow that runs daily, but the promotion itself is gated to only happen on Wednesdays.
Snippet: The schedule is defined in .github/workflows/deployment_promote.yml:

# In .github/workflows/deployment_promote.yml
on:
    schedule:
    - cron: '04 04 * * *' # Runs daily at 04:04 UTC

This workflow triggers our custom deployment tool, which contains the gating logic in js/github_deployments/deployment_config.ts. The promoteOnWednesday function ensures the promotion to the Beta channel only proceeds when the job runs on a Wednesday.

Stable Channel (The Official Release)

Metric: Our stable rollout completes over 5 days: 10% → 20% → 50% → 100%.
Pointer: The Stable release process is triggered not by a Git tag, but by a push to a specifically named branch, like release-branch-ime-v1.12-r1. This kicks off a time-based, gradual rollout.
Snippet: The checks.yml workflow is also configured to run on pushes to release branches, as seen in the same file:

# In .github/workflows/checks.yml
on:
    push:
    branches:
        - 'release-branch-*-v*.*-r*'

Our deployment script then uses a regular expression (/^release-branch-ime-.*$/) in js/github_deployments/deployment_config.ts to identify this as a Production release, which begins the automated, multi-day staged rollout.

The Brains of the Operation: Our `github_deployments` Tool

While GitHub Actions define the “when” of our deployments, the “what” and “how” are orchestrated by a custom, in-house TypeScript tool located at js/github_deployments. This command-line tool, executed via Bazel, acts as the central brain for our entire CD process.

Its primary responsibilities are:

Interpreting Triggers: It consumes the branch name (e.g., main, release-branch-...) and determines which deployment configuration to use (Alpha, Beta, or Production).
Calculating Rollout Steps: For our time-based rollouts, it calculates the current day of the release and selects the correct rollout percentage from a predefined array.
Interacting with the GitHub API: It creates the official deployment events using the GitHub API, which in turn trigger the deploy.yml workflow. It’s also used to report the status back to GitHub.

For example, when the checks.yml workflow runs on a main branch push, it executes the following command:

# This command is wrapped in our .github/actions/deploy-request action
bazel run //js/github_deployments -- deploy \
  --refname="main" \
  --deployMode="force_new" \
  # ... other parameters

This command tells our tool to create a new “Alpha” deployment. This layer of abstraction allows us to keep our deployment logic in well-tested TypeScript code, rather than in complex and hard-to-maintain YAML files.

Executing the Release: The Magic of Automation

Regardless of the trigger, the actual process of building, signing, and publishing the application is entirely automated. Once a deployment is triggered, a dedicated GitHub Actions workflow takes over.

This workflow executes a series of scripts that perform all the necessary steps:

Building the Application: The latest code is compiled and packaged into an Android App Bundle (.aab).
Secure Signing: Signing keys and API credentials, stored as encrypted GitHub Secrets, are injected at build time. The App Bundle is then cryptographically signed using these credentials to ensure its authenticity and integrity.
Publishing to Google Play: The signed App Bundle is uploaded to the Google Play Store. This entire process is handled via programmatic API calls to the Google Play publishing APIs, powered by the gradle-play-publisher plugin. This eliminates manual uploads, reduces human error, and ensures a consistent, reliable deployment every time.

The key here is that no human intervention is required for these steps. The automation handles everything, from compiling the code to interacting with the Play Store’s backend.

Closing the Loop: Visibility and Supporting Tools

An automated deployment process is only effective if it provides clear visibility into its status. For AnySoftKeyboard, various tools and mechanisms are in place to provide this feedback directly within our development workflow.

Deployment Status Updates: We use our github_deployments tool to communicate with the GitHub Deployments API. The same tool that initiates a deployment is also called at various stages within the main deploy.yml workflow to report back the status. For example, as soon as a deployment begins, we run the following command to set the status to “in progress”:

# In .github/workflows/deploy.yml
bazel run //js/github_deployments -- status \
    --deployment-id="$" \
    --state=in_progress

This immediately updates the deployment status in the GitHub UI, providing real-time feedback.

Automated GitHub Releases: After a successful deployment to the Google Play Store, a dedicated post_deployment job in our deploy.yml workflow handles the creation of a public-facing GitHub Release. Interestingly, this is a two-step process. When the stable rollout first begins (at 10%), we use the popular softprops/action-gh-release action to create a Pre-release.

# In .github/workflows/deploy.yml
- name: Create GitHub Pre-Release
  if: endsWith(needs.deploy.outputs.deployment_environment, '_010')
  uses: softprops/action-gh-release@v2.4.1
  with:
    prerelease: true
    # ... other parameters

Once the rollout successfully completes and reaches 100% of users, a later step in the same job updates the release, removing the “pre-release” flag. This ensures the official release notes are only marked as “Latest” when the deployment is fully complete.

# In .github/workflows/deploy.yml
- name: Update GitHub Release to Stable
    if: endsWith(needs.deploy.outputs.deployment_environment, '_100')
    run: gh release edit "$" --prerelease=false

These mechanisms ensure that while the deployment itself is automated, the development team remains fully informed and can quickly react to any issues.

To be continued…

In the next and final part of this series, we’ll explore the “Complimenting Workflows” that support our core CI/CD pipeline. These include other automation tasks that enhance developer experience, maintain code quality, and ensure the overall health of the AnySoftKeyboard project. Stay tuned!

My LLM Tooling Doctrine: The Unix Philosophy for Local AI

2025-11-08T12:00:00+00:00

I’ve been building a lot of small LLM-powered CLI tools for about a year now. These are tiny utilities, each with a very specific job: reviewing my git diff, generating a commit message, or answering quick shell command questions.

My terminal is full of these “micro-tools.”

This is a deliberate choice. It’s a move away from the clunky, do-it-all monoliths and a full embrace of a philosophy that’s been battle-tested for decades: the Unix philosophy.

But Why Not Just Use an LLM Agent/Bot?

I know what you’re thinking. “Why build a CLI tool at all? I’ll just ask Gemini, ChatGPT, or my Claude Code Agent.”

And you’re right. For exploratory, conversational, or complex one-off tasks, those tools are fantastic. I use them every day.

But I’m talking about repeatable, automated, in-terminal workflows. The kind of stuff I do 50 times a day.

When I’m deep in my terminal, I want to stay in my terminal. Switching to a browser tab or an IDE-specific chat panel is a context switch. It’s friction.

Let’s look at the “code review” task:

The AI Chat Bot Flow:

Realize I want a review.
Run git diff.
Copy the output.
Alt-Tab to my browser.
Find the right Gemini/ChatGPT tab.
Paste the code.
Type the prompt: “Please review this git diff, focusing on…”
Wait for the response.
Read it, then Alt-Tab back to my code.

That’s 9 steps, and it pulled me completely out of my flow.

The Specialized CLI Tool Flow:

Run ai-review.

This is the entire philosophy. The specialized tool isn’t trying to be a general-purpose brain. It’s an ergonomic, zero-friction extension of your existing CLI workflow.

Why Monolithic AI CLI Tools Feel Wrong

Once we’ve established why a CLI tool is the right fit for these tasks, there’s a fundamental design choice to make: should it be a single, monolithic tool, or a collection of small, specialized ones?

The “one big tool” approach has serious flaws. The tool is either a jack-of-all-trades with a million confusing flags (ai-tool --task=review --target=file.js), or it has a “smart” prompt-router that tries (and often fails) to guess what you want.

Worst of all, it puts the burden of context on you, the user. You have to manually copy-paste your code, your diff, or your error message. It’s dumb.

The Beauty of Specialized LLM Tools

This is where the Unix philosophy comes in: make each program do one thing well.

When you build small, separate tools, magical things happen.

Implicit, “Smart” Context: This is the killer feature. A specialized tool knows its job, so it can fetch its own context.
- ai-review (my code-review tool) doesn’t need me to pipe a diff. It just runs git diff itself.
- ai-gc (commit-message) runs git diff –staged automatically.
- ai-pr (PR title/desc) knows to run git diff main… to see the whole branch, then pushes to GitHub and creates a PR. The tool feels smart, not because the LLM is a genius, but because the tool itself is a good assistant.
Perfectly Tuned Prompts: You can’t use the same system prompt to review code and to generate a commit message. One needs to be a critical engineer, the other a concise technical writer. By splitting them, each tool has a small, highly-optimized prompt that does its one job perfectly. No prompt-routing, no “you are a helpful assistant” fluff.
Reliable, Focused Evaluation: This is a huge engineering win. When a tool has one job, it’s so much easier to evaluate. I can build a specific, high-quality test set for ai-gc (commit messages) and another for ai-review (code review). I’m not trying to test a massive, do-it-all prompt; I’m testing a small, focused one, which makes it easier to measure quality and prevent regressions.
Simplicity (UX): The user experience is just… clean. You want a commit message? Type ai-gc. You want a review? Type ai-review. No flags, no sub-commands, no cognitive overhead.

The Critical Base a.k.a. Don’t Repeat Yourself

This all sounds great, but what about the maintenance nightmare of having 15 different tools? How do you manage API keys, model selection, and updates?

This is the most important part: you must build a base implementation.

I have a single, local llm-cli-utils library. Every micro-tool is just a 20-line script that imports this base. The base library handles all the boring, critical stuff:

API Key Retrieval: It knows exactly where to find the OPENAI_API_KEY (or any other key) from the environment or a config file. No need to hardcode keys in every script.
LLM Framework Abstraction: The base library handles the actual API call (using langchain, litellm, or just raw openai-python). If I want to add a new model provider, I change it in one place, and all tools get the upgrade instantly. This also means I can easily choose different models—like gpt-4o for power and haiku-4.5 for speed—matching the right model to the job.
Interaction Helpers: This is where the magic happens. The base library has helpers for common tasks like parsing model output, handling streaming responses, and even managing conversation history for more complex interactions. This keeps the individual tool scripts clean and focused on their specific logic.

My Family of Tools: What I’ve Built and How I Integrate Them

Here’s an extra detail on how I build these. I don’t just dump them all into ~/bin. I put them where they make the most sense.

For Git-centric tasks, I create simple binaries like ai-review and ai-pr. To make them feel like native Git commands, I name them git-ai-review and git-ai-pr and place them in my PATH. Git automatically discovers and executes them as sub-commands, so I can run git ai-review and it just works. This gives me the best of both worlds: a simple, independent binary that can also be used as a native Git command, which is a huge win for discoverability and ergonomics.
For general tasks, I build standalone commands. My “quick question” tool is just qq. Since qq has no concept of a repository, it wouldn’t make sense as a git sub-command. Instead, it lives in the standard shell, right next to grep and ls.

This division is part of the same philosophy: design your tool for its specific job, and that includes its “home” on the command line.

Here’s a peek at my local ~/bin directory:

qq: Quick question. qq "how to find files modified in the last 2 days"
ai-review: Code review for the current git diff.
ai-gc: Git commit message for staged files.
ai-pr: Generate a PR title and description from the current branch’s diff, then pushes to GitHub and creates a PR.
ai-conflict-fix: Takes a file with git conflict markers (<<<<<) and attempts a clean merge.

Each one is simple, fast, and does one thing. And the list is growing! Here are some ideas for other tools I’m thinking of building:

ai-doc-gen: Scopes to a function or class and writes its docstring.
ai-test-gen: Scopes to a file or function and stubs out unit tests.
ai-fix-types: Fix/add types to Python and TypeScript code.
ai-fix-text: Typo/grammar/syntax fixer given a file (fixes variables names and comments, warn on classes and functions since those might be APIs).
ai-log-analyzer: Takes a log file and summarizes the errors.

The possibilities are endless. The key is to identify a repetitive task and build a small, focused tool to automate it.

This is the way. You get the beautiful UX of small, specialized tools and the maintenance sanity of a single, shared core.

By embracing the Unix philosophy, you can build a suite of AI-powered tools that are simple, powerful, and a joy to use. Stop building all-in-one AI behemoths. Start building small, sharp, Unix-style tools.

LLM Evaluations a.k.a. How We Avoid Wat-Did-You-Say Moments

2025-08-29T12:00:00+00:00

A few weeks ago, I had the pleasure of presenting at an AI-Camp event hosted at the Asana office in NYC. The topic was “LLM Evaluations: How we ensure AI tools produce consistent quality.” I wanted to share some of the key takeaways from that presentation here.

You can find the slides from the presentation here.

The Problem with Evaluating LLMs

We all know how to test traditional software. We write unit tests, integration tests, and end-to-end tests. These tests are deterministic, objective, and easy to run. However, LLMs are not like traditional software. They are:

Not deterministic: The same input can produce different outputs.
Not objective: It’s hard to define a single “correct” output.
Quite a lift to run: Evaluating LLMs can be time-consuming and resource-intensive.

So, how do we ensure the quality of our LLM-based tools?

AI as a Judge

One solution we’ve found effective at Asana is using an “AI as a Judge.” Instead of asking humans to evaluate every output of our internal AI tool, z chat, we use another AI to do the judging. This approach has several advantages:

Easy to scale: We can run evaluations on a large number of examples without human intervention.
Consistent: While not deterministic, the judge is very consistent when using the same model, prompt, and questions.
Easy to automate: We can easily integrate this into our CI/CD pipeline.

This approach is similar to what’s being used in AI Studio and other places in the industry.

OpenEvals and LangChain

To implement our AI Judge, we use OpenEvals, a framework from LangChain that helps us write evaluations for AI applications. With OpenEvals, we can define criteria for correctness, conciseness, and other quality metrics, and then use an LLM to score the output of our z chat tool.

Here’s a simplified look at our evaluation flow:

We have a set of evaluation data, which includes questions and criteria for correct answers.
For each question, our simulator calls z chat to get a response.
The response, along with the criteria and a judging prompt, is sent to our AI Judge.
The judge provides a grade, which we use to score the quality of the z chat response.

Findings and Next Steps

We currently have 32 evaluation cases and are seeing a response score of around 72% and a document retrieval score of 90%. This process has helped us identify several issues, such as missing ownership data and test cases that were failing despite the data being available to the LLM. We’ve also been able to improve our system’s prompt to get better results.

This is an ongoing process, and we’re continuously adding new evaluation cases and refining our prompts and models to improve the quality of our AI tools.

If you’re working with LLMs, I highly recommend setting up an evaluation framework. It’s a great way to ensure the quality and consistency of your AI applications.

CI/CD at AnySoftKeyboard Part 1 aka Is it ready to ship?

2020-03-30T20:03:30+00:00

Recently, I’ve merged several AnySoftKeyboard repositories into a monorepo - I’m a believer in the monorepo process. During that process, I also refined the Continuous Integration (CI)/Continuous Deployment (CD) process and wanted to give an overview of the process and the logic behind that.

This is the first of three parts:

Continuous Integration, aka CI.
Continuous Deployment, aka CD.
Complimenting workflows.

Process

The CI/CD flow in AnySoftKeyboard starts when a pull request is submitted. Then, a series of checks are run, the code is reviewed, the pull request is merged, the checks are run again on the main branch, and finally, the changes are deployed to users.

The first five steps are the CI part, and the last is the CD part.

Why CI - Continuous Integration

Continuous Integration is pretty much an industry-standard, and well-accepted. In essence, for every commit (or a set of commits, e.g., a pull request), we run unit-tests, static-analysis tools, and code-style verifications. These checks will ensure three things:

You are confident that your change did not break anything - hence you do not need to check every possible scenario and use case.
The next developer who picks up your changes gets a healthy, readable, and working code, feeling confident that they can start working on their code-change.
With some confidence, any feature and use case are still working for end-users.

You’ll notice that the keyword here is confidence. Continuous Integration gives us confidence that the HEAD commit of main is valid and working as intended.

Pull Requests

Every change will be proposed as a pull request. The system will then perform the following:

Assigning all relevant code-owners as reviewers according to the CODEOWNERS file. Assigning is done automatically by GitHub.
Running all checks. Defined in the checks workflow.
Block merging until checks pass and code-review approved. This is configured in the protected branch setting in the repository settings page.

Checks

Checks are what make us confident that our code works and does not break any existing functionality is still working as before this proposed code change. Several types of checks run on each code-change.

Tests

The most common check that we run is unit-tests. Essentially, unit-tests will verify that distinct pieces of code are doing what they are supposed to do correctly. For example, a test could verify that a Dictionary implementation can look up words and find typos.

We also run integration-tests, which ensure that different parts of the codebase work with each other as intended. For example, a test that given a user interaction with the keyboard view a specific text is printed in the Android’s text box.

We write tests in two main cases:

New functionality that we want to verify that is doing what we wanted: for each possible input category (or for each internal code branch), we have a test.
A bug fix that we want to verify that it won’t regress. These types of tests provide us with the most confidence in our code.

Note that tests cover the behavior of the code, and only the branches we individually coded in the test. So, of course, this is not complete.

Static-Analysis

Even if your code works under typical use-cases and all tests pass, it does not mean it is correct. Static-Analysis tools can search your codebase for common programming issues. Such issues could be an incorrect use of an external API or assuming something is not null when it could.

In AnySoftKeyboard, we use:

Error-Prone, with an Android-specific configuration. Error-Prone is a fast checker that can find many Java-related code smells. It is widely popular and actively maintained.
Lint with an AnySoftKeyboard-specific configuration. Lint is the gold-standard in Android-centric code and resources static-analysis. It is well-known and actively maintained.
checkstyle with an AnySoftKeyboard-specific configuration. Another well-known Java code analysis. We use it to find illegal/undesirable code usage and files.
Google-Java-Format. This tool ensures that the code style across the codebase is defined well and maintained. It also supports automatic formatting, so win-win.

Of course, many other tools can be used. A few notable mentions:

PMD.
FindBugs/SpotBugs. FindBugs seems to be dead, so maybe use SpotBugs, if interested.
Mutation-Testing.

For us, we decided to focus on a few, very popular and fast, static-analysis to reduce the complexity of the check suite and the requirements from the developers.

Cache

A side-note. A lot is going on here; compiling production code, debug code and tests, running tests, and several tools on top of that code. This process could be slow, both in the CI environment and in the local developer environment. To that end, it is crucial to pick a build system and tools that support caching (that is, do not execute actions if the input has not changed) and configure them correctly. Luckily, Gradle has an excellent caching mechanism (as long as your system is not too complicated): it will cache compilation steps and test runs. Error-Prone is running inside the compilation step, so we get caching for free here. Lint also has an excellent caching mechanism, relying on Gradle’s caching mechanism.

Another benefit of caching is that faster feedback makes developers happier. Like, much much happier.

Persistent Cache

Gradle will store its cache on disk (there is an option to use remote cache, under a specified path. Gradle is using this disk cache in sequential runs to skip actions that have run in the past. This state is called warm cache - skipping a step because you already have the result of it in the cache.

Keeping your local cache warm, is easy, and happens as you build locally. But, on CI, it’s a bit harder since every time you run a job on CI, you will get a different machine, one that does not have any cache related to your build. Run checks without cache means much slower checks.

Since we are using Github Workflows, we can specify where is our cache is located, how to identify its version, etc. See our checks-workflow configuration for details.

For AnySoftKeyboard, running the PR checks without cached can take up to 20 minutes, while about 8 minutes with the cache warmed.

Docker

Caching relies on the assumption that if the input is the same, the action will produce the same output. This assumption is true only if: The inputs are defined correctly. The action only uses the inputs to produce the output. If both these guidelines apply, then the action is defined as hermetic.

As a rule, Gradle is not a hermetic build system (bazel, for example, is), but it does an outstanding job nonetheless.

To reduce the chances of a misbehaving action, we’ll use Docker in CI, so Gradle will have the same environment during its execution. Same Java, same bash, same SDK, same NDK, etc.

We are using an image that is built explicitly for AnySoftKeyboard. This image uses Java10 (this helps ErrorProne run faster), has the required SDK, NDK and build-tools all preinstalled and ready to go. Check out the Dockerfile for this image and the CI build script on GitHub.

As a side note, I would mention that it’s pretty easy to create a custom image and store it in on Docker Hub.

To be continued

What will happen to our pull request? How will it be integrated into the main branch? And, how will it reach end-users? Stay tuned for the next parts.

Bazel and Gradle Co-exist a.k.a. Can't we all just get along?

2016-01-05T11:32:00+00:00

After reviewing Buck in a previous post, it was time to check out Bazel. Bazel is the open-source version of Google’s internal Blaze build system (and for the record, Buck was inspired by Blaze).
I’m going to have a few posts about Bazel in the journy to convert a project into Bazel from Gradle.

Why

Well, given you have an existing Android project; it is probably being built with Gradle. It’s working, it’s stable, and it has all kind of neccesery tasks you are depending on. Which make converting to Bazel (or any other build system) quite a block.
So let’s try to have our project support both Bazel and Gradle at the same time.

Pre-requisites

For our posts, let’s say that we have an awesome Android app - currently built using Gradle - that we want to convert to Bazel. We’ll use this git repo for our posts, and here is the app’s initial state (simple Android app, built with Gradle).

The Problem

Bazel two type of files that define the build:

WORKSPACE - which defines the global build properties (like SDK path), and defines external repos (libraries) which can be used in our build.
BUILD - which defines a module in our build, and how to build it. A module can be a library, content, or binary (our app).

Well, Gradle default build output folder is called build, and on some OSes (I’m looking at you, MacOSX), the filesystem can be set (or default) to be case-insensitive. This introduces the issue of Gradle-Bazel: both require a file-system object named build. This is, of course, not an issue for Linux, but it is an issue for MacOSX.

What to do?

Unlike Bazel, Gradle is very configurable: we’ll just tell Gradle to use a different folder name for its build outputs. This is done by adding buildDir = 'gen_build' to our build.gradle file, and revising the .gitignore settings.

Here is the commit that fixes this for our awesome demo app.

Maven and Support Library Artifacts in Buck a.k.a. Wait, It Doesn't Have Full Dependency Resolution Support!?

2015-11-06T11:32:00+00:00

Buck is Facebook’s super fast build system. How fast? Up to 7.5 times. That was intriging enough to get me to try it out, and immediately realizing that the platform is not complete.. One of the features missing is proper and complete support for Maven remote artifacts (aar and jar) and locally hosted Support Library artifacts.

Remote Maven Artifacts

So, Buck does support Maven artifacts in a rule called remote_file, which can fetch files remotely, process them and make them available to the code-base. For example, if you want com.google.guava:guava:18.0 dependency you’ll create a remote_file rule like this: and depend on it in one of your targets:

Replace jar with aar if you want to fetch aar libraries.

The `maven` rule

This works, but wouldn’t it be easier and more friendly if you could import artifacts as easily as Gradle allows?
Based on zserge work, here’s a simple way to achieve exactly that. First, create a DEFS file in your project’s root folder, and add mavensha1 and maven functions to it: Second, import the DEFS file to you project, but add the import code to the .buckconfig file: This will make maven rule available to every BUCK file. So, now you can simply depend on the rule in your target, like this:

It doesn’t matter if the artifact is an AAR or a JAR, this maven rule will fetch either!

The Support Library case

For some reason (legal? distribution?), the support library is not available in Maven Central and instead, Google directly place it under your SDK folder ([SDK folder root]/extras/android/m2repository/). That does not help the mvn: prefix to find it.. The only safe way to make this work is by manually copying the AAR file from there to a folder in your project (Buck will not allow to reference a file outside the project’s folder structure).

The `android_support_library` rule

First, add another rule to the DEFS file we defined above: Then copy the libraries you need in your project to a locale folder inside your project (lets say libs). Create a BUCK file in that folder and import the support libraries: Now you have targets you can depend on when creating Android app:

Conclusion

This is an amazing build platform! So fast, and so explicit to define and makes complete sense. The problem is that if you are to use it, you kinda giving up on Gradle, or any other (Bazel?) build system. The reason is that Facebook has its own idea of how an Android project is built, and how the relations between libraries and modules are defined. For example, you will not longer have resource merging, resource overwriting, or R constant values. Aligning with Buck’s paradigm might turn out to be a very costly operation, and will definetly will not be compatible with Gradle, meaning you will not be able to run both build systems on the same codebase.

Auto-Generate Version Name a.k.a. It Is So Boring Incrementing Build, Let Git Do It

2015-04-13T20:52:00+00:00

0.0.1, 0.0.2, 0.1.0, 0.1.1, 0.1.3,…. I’m super lazy, and I get bored really quickly with repeating tasks. So, whenever I can offload something to a script, I just do it.
One such offloading I’ve done lately, is versioning the APK.

So, I’ve created a very simple Groovy plugin for Gradle, which will calculate the version-code and version-name based on the count of commits in the git repo. It’s is not the brightest method, but it is so damn simple, it has to work.. Right?

Plugin

Gradle can be extended using Groovy plugins (under the buildSrc folder). We’ll use that to provide two static methods to our build.gradle file: This file should be saved as [project root]/buildSrc/src/main/groovy/versionbuilder/VersionBuilder.groovy

API

This is will give you two public static methods which you can use:

buildGitVersionNumber - Returns an integer which can be used as your project’s versionCode.
buildGitVersionName - Returns a major.minor.build string which can be used as project’s versionName. Change the plugin’s code, if you prefer a different template for versioning.

Example

To use those methods, in your build.gradle file:

Configuring

You probably noticed two constants in plugin’s code:

GIT_COMMIT_COUNT_NORMALIZE - Use this to subtract a constant from the commits count. Use this to set the initial versionCode as close as possible to your current versionCode.
GIT_COMMIT_COUNT_MINOR_NORMALIZE - you’ll probably want to reset your build versioning every time you bump minor or major.

Things will just work from now on! No need to figure versions anymore, what a profit, ah?

Tabs to Spaces in a GIT repo a.k.a If everyone is Doing It, I'm Doing It Too

2015-04-11T13:52:00+00:00

I work on a few projects right now, some using the Android code-style and some their own. This is very confusing, and always causes problems when pushing a commit for merge.

I’m trying to consolidate all the projects into Android’s code-style. Specifically, no-tabs and 4 spaces indents.

Game Plan

Going over all the files and changing the tabs to spaces is, of course, not an options. More over, we do not want our name on every single git blame code line! So, we’ll need to convert all the tabs to spaces, ensure all indentation is 4 spaces, and re-write history to hide it.

Prerequisites

Linux or Mac OSX machine. If you know how to do it under Windows, please leave a comment.
You’ll need git push -f permission to the remote repo. That’s the only way to re-write history.
expand should be installed on you machine

Switching Tabs to 4 Spaces

find . -name '*.java' ! -type d -exec bash -c 'expand -t 4 "$0" > /tmp/e && mv /tmp/e "$0"' {} \;

Here’s what we are doing with that command:

find all the Java files in the repo.
On each file, execute expand (using bash) which will convert tab characters to 4 spaces, and save into a temporary file.
The move the temporary file to overwrite the original file.
If you also want to convert your XML files to spaces, then run the same command with *.xml filter.

Commit the Changes

git add .
git commit -m "converting tabs to spaces"
Now, we have a commit in our local git repo that holds all the changes. Let’s get the hash for the commit using git rev-parse HEAD. For our example, let’s say it is 0867e54002195d16dbfb69076d1df2d8b1f83e6f.

Re-write git History

git filter-branch --tree-filter 'git diff-tree --name-only --diff-filter=AM -r --no-commit-id 0867e54002195d16dbfb69076d1df2d8b1f83e6f' HEAD
This is the cool part: hiding all the evidence that you made the switch. This will ensure that when developers check git blame on a file, the tabs->spaces changes will not show.
This takes a very long time to run. The bigger the repo the longer it will take.

Force push to master

git push -f origin master
Pushing to the remote repo (be it origin or upstream).

Possible Problems

filter-branch creates a new, revised, branch in your git repo. This means a few things:
the size of your repo may be doubled!
hash of the commits in your history will be changed! This means that if you have a link to a specific commit, this link might be dead after this process. The reason for that is that if git sees that nothing is pointing to a specific commit, it will garbage collect it.
A simple way to fix that, is to use tag, and annotate the commit prior to starting this process.
Applying the filter-branch may fail (“Cannot create a new backup.”) because of an existing backup in your refs folder. Delete those with rm -rf .git/refs/original/refs/heads/master from the root of your repo.
If you get ! [rejected] master -> master (non-fast-forward) when pushing the changes to your git repo, it means that you do not have force push permissions in the git repo. Talk to the owner.
Previous tags are kept, and are pointing to the original commit, not the revised one. So we are not completely rewriting history.

Migrating to Robolectric v3 a.k.a Just Work, Dear God, Just Work!

2015-04-09T13:52:00+00:00

Robolectric has reach a big milestone recently: V3-rc2, so it was time to upgrade all my personal projects.

With the new release, the team has introduced new concepts and new APIs (and removed and renamed others). In most cases, I find the new API and structure much more readable, and generally like it.
But as a long time user of Robolectric, it also means that I have a lot of code to refactor.

Note: all code in this post is Public Domain as described in CC0.

First, to make things clear, if it wasn’t worth the hassle, I would not upgrade to v3, but this new version comes with a lot of nice improvements and Robolectric, in general, is awesome beyond words.

Second, let’s get to the migration guide:

Gradle stuff

You no longer need the Robolectric Gradle plugin. So just remove classpath 'org.robolectric:robolectric-gradle-plugin' from build.gradle.
Some developers had used a hack to get Robolectric tests navigable in Android Studio: and/or You don’t need those anymore.

Any specific Robolectric settings should also be removed, since we are not using the Robolectric Gradle Plugin anymore. Remove this:

With Android Gradle Plugin v1.1.0 there is a built-in support for unit-test (using mockableAndroidJar), so we no longer need to setup Robolectric as androidTestCompile.
Change androidTestCompile('org.robolectric:robolectric:2.4') to testCompile 'org.robolectric:robolectric:3.0-rc2'
DO NOT USE com.squareup:fest-android:1.0.8. If you have it in your testCompile be sure to remove it. There is a conflict between it and Robolectric which causes all Fragment/Activity related unit-tests to fail with NoSuchMethodError.
If you have to use com.squareup:fest-android:1.0.8, then remove support-v4 from it:

TestRunner

You have probably used @RunWith(RobolectricTestRunner.class) in your classes. Switch to RobolectricGradleTestRunner, but also add a @Config annotation, and point to your app’s BuildConfig class: This is enough, but I opted to a different approach: a custom test-runner that sets the Robolectric configuration: This test-runner will set the app’s SDK level to 21 (since Robolectric does not support anything higher than that, right now), and will set the constants value to the app’s BuildConfig class.

API and Behavioral Changes

Entry Points

Robolectric.application does not exist anymore. From now on use RuntimeEnvironment.application.
Robolectric.shadowOf() does not exist anymore. From now on use Shadows.shadowOf().
Robolectric.getShadowApplication() does not exist anymore. From now on use ShadowApplication.getInstance().

Activity life-cycle management

Robolectric lets you manage the life cycle of the activity using it’s ActivityController. This is still there, but there are two additions:

ActivityController.postCreate() was added.
ActivityController now has a new setup method which is a shorthand for create().start().postCreate(null).resume().visible().get().
and another shorthand was added Robolectric.setupActivity(Class<T extends Activity>).

Quite useful.

Add-On Modules

Robolectric was broken up to modules; the main library will only include Shadows for the main Android framework classes, and anything else (support library, maps, etc) is served as an Add-On Module.
I don’t have much to say about that, other than: if you want a Shadow of a class that is part of an external library (for example, support-v4’s LocalBroadcastManager), be sure to include the right Add-On (for example testCompile 'org.robolectric:shadows-support-v4'). You can access the Shadow using the Add-On’s specific Shadows entry-point (for completeness: org.robolectric.support.v4.Shadows).

Missing stuff

This is what I’ve found so far:

IntentFilter will not do equals correctly anymore. I guess that this is due to some cleanup, which resulted in Shadows to be removed. I used a new static method to calculate match: I use Mockito a lot and needed a Matcher too.

Replaced stuff

This is what I’ve found so far:

TestCursor was replaced with RoboCursor, which is an improved version of it. This is a great addition.
UI Thread is now called ForegroundScheduler, which means that Robolectric.runUiThreadTasksIncludingDelayedTasks() is now called Robolectric.flushForegroundScheduler();

Other

This is what I’ve found so far:

Time now respects the default time-zone! So make sure you set it correctly in your unit-tests (most probably in the @Before method): Also, note that Time is Deprecated with API-22, so you might want to refactor to use GregorianCalendar. But, no pressure.
Robolectric now supports API level 21! This means that if you assumed in your tests that you are running on an API level 18 (which was the highest/default API level for Robolectric v2.4), this is no longer the case! The default API level is 21!
@Config(emulateSdk = 18) or @Config(qualifiers = "v19") are your best friends there. And don’t forget to add the missing unit-test for API levels higher than that.
Since the robolectric gradle closure is removed, any special Java related configuration (e.g., maxHeapSize) should be moved to android->testOptions->unitTests.all closure. Something like this:

Please share your tips and tricks for migrating in the comments! I’ll update this post as things coming in

Multiple API Level APK Release a.k.a I'm Done With Legacy

2013-12-10T10:29:00+00:00

Up until recently, AnySoftKeyboard was supporting Android devices all the way back to 1.5 in a single APK. Mostly, it worked fine, and I was able to use FrankenRobot to utilize higher API levels features successfully. But there was a cost.

TL; DR;, you can check out this screen-shot, which explains a lot.

Android 1.5 can not support the Support Library (which includes the Fragment support), and Android 1.6 till 2.0 can not support the App-Compact library (which includes the ActionBar), so providing a single APK for all devices had it cost: no modern UI/UX.

Separating

After reading what Google has to say (read it, it is very good background) about it, I’ve decided to separate the App by API level: API 3, API 4-6, and API 7+. Why this separation:

API 3 - Android v1.5

Devices still running Android 1.5 are very old. They are very limited on internal storage, RAM and CPU power. I’ve decided to create a special build for those phones: minimal resources (just MDPI), just ARM jni, and removed all code that does not support this API level. I was able to reduce the size of the APK from 3.2MB to 2.1MB, which is very helpful for owners of those devices.

This is the AndroidManifest file for this build:

API 4-6 - Android v1.6-v2.0

These devices are usually much better. But due to OS limitations, they can not support modern UI language (like the ActionBar). So, here, I’ve decided to also create a separate build for these API levels. Again, reduced set of resources (MDPI and HDPI), a few more jni libs, and reduced set of functionality (e.g., no voice input).

This is the AndroidManifest file for this build:

API 7+ - Android v2.1

This API level supports all the required support library, and usually, those devices are very strong.

This is the AndroidManifest file for this build:

Things to Note

You’ll notice that for an higher API level, there is an higher versionCode:

First APK is for android:minSdkVersion="3", and has android:versionCode="112".
Second APK is for android:minSdkVersion="4", and has android:versionCode="113".
Third APK is for android:minSdkVersion="7", and has android:versionCode="114".

This is required in case the user’s device will get an OS upgrade that requires an APK for an higher API level, e.g., say your HTC G1 is running Android 1.5, and then, one glory morning, you are pushed with an OS upgrade to Android 1.6, prior to the OS upgrade, you have be given android:versionCode="112", but after the OS upgrade, this version is no longer compatible with your device. Don’t worry, Play Store to the rescue! It will automatically update your APK to android:versionCode="113". And since it needs to update your APK, it is required the that new APK will have a higher versionCode. Got it?

Play Store Configuration

After you have your APKs built, each with its own android:minSdkVersion and android:maxSdkVersion, you can upload them to the Play Store. You should see something like this:

How’s that for A picture is worth 37.5 tweets!!

Good luck.

Branding the EdgeEffect aka Hit the Wall with Your Own Color

2013-12-09T13:07:00+00:00

Lately, I’ve become sort of branding obsessed; colors, font sizes and types, UI language, they all seem so important to me, I can hardly look at an App these days without pulling on my hairs and scream “God, oh God, why would they use inconsistent, non-brand colors!” Ya, but that’s my problem. Your is another: how to brand the EdgeEffect glow, ah?

TL;DR; Use the gist here.

It is usually pretty easy to change colors, sizes, etc. for widgets which are in your App’s real estate (e.i., not the OS’s chrome: notification bar icons, for example), but, weird as it sounds, Android does not provide any method to change (or brand) the hitting-the-wall feedback glow effect in its widget (ListView, GridView, ScrollView, etc.), and will only use the OS’s color. This even gets weirder, when Android 2.3 has a green edge-effect, while Android 3+ uses a blueish (Holo) color, and KitKat (v4.4) uses a gray glow effect (ironic fact: Android team changed the colors of the chrome in KitKat to a nuetral gray color, so it will not collide with your branding, although, a gray Edge-Effect inside your App’s UI is clearly colliding, IMHO).

The Cause

The EdgeEffect class uses a Drawable resource (an OS’s resource, not yours, hint, hint, Google), which provides the glow effect, this resource is loaded internally by the EdgeEffect class:

And the size of the glow (how much the user over-pulled the list) is calculated during draw(Canvas) call:

There is no way to change the drawable resource (hint one, Google.), or apply a filter on the drawable (hint two, Google.). A shame.

Solution - Hacker style

What can be done? I’m going to hack my way into branding this drawable. I’ll take advantage of the fact that the Drawable instance is shared, and not mutate (which makes sense, right?) and I’ll load that Drawable in my code, and apply a filter on it:

What just happened?

The name of the glow resource has never changed in Android’s history (so far), (line 1) so I’ll get its identification, (line 2) load the Drawable, which is shared instance across my Application, thus the same one EdgeEffect is using, (line 3) and apply a MULTIPLY filter on it, with the brand’s color.

What about the overscroll_edge resource

The edge-effect is broken to two drawables: the glow (overscroll_glow), and the edge (overscroll_edge). This method allows the EdgeEffect class to stretch just the glow, and keep the edge crisp. To brand the edge (you’ll probably want to do that too), use this revised method, which brand both the glow and the edge:

Pitfalls

Android may decide to change the name of the resource, in which case you’ll need to change the call to getIdentifier
The shared instance may be unloaded from memory, so remember to call the brandGlowEffect after each creation of EdgeEffect (after creation of ListView, GridView, ScrollView, or your own instance of EdgeEffect), best place will be in the Activity’s onCreate, right after setting the layout.
I’ll emphasis the first point (since this is the core of the hack, and it’s a reflection kind of solution, thus dangerous): make sure this method works on the target Android version you had in mind. I take no responsibility!

Branding - The Technical Challenge

An App should be useful, easy to use, effective, beautiful, stable. It should also be unique, and represent its creator. This is where Branding comes in - a way to express and show yourself in the App UI: colors, Type-face and font sizes, language, behavior, icons and graphics, etc.

I’ll try to post more about this subject, but not from a marketing, design, or decision (reason) standpoint. Instead I’ll show you how, technically, to brand your App. E.g., in this post I’ve shown how to change the color of Android’s build-in Edge-Effect, you can use this method to change the glow color to your brand’s main (or secondary) color! What ever that color maybe (which is a design decision).

Android Memory Leaks OR Different Ways to Leak

2013-02-10T12:00:00+00:00

A few weeks ago I released version 85 of AnySoftKeyboard and soon after, crash reports started to hit my email box. It usually happens - mostly because I forget to test a feature, or just because the specific device decided it is time to crash (it happens, really! The floor is crooked). But this time, all the crashes were of the same nature, and were many, about 5-10 a day.
The crashes were due to OutOfMemoryError (a.k.a, OOM), which usually means a memory leak in Android (why? Unlike a desktop, an Android device has very little heap to play with and leaking will fill that little space quickly), I started to look for them.

TL;DR: If I was able to recreate this crash on my devices, I would have find the cause immediately, and just fix the 6th cause in this list. But, I wasn't able to reproduce it (why? later on that), and it took me some time to understand that the reporting users want me to fix it, and are willing to help!

Cause 1: Context Leak

The most common leak in Android is the Context leak (here is a great explanation). Although all the examples are talking about Activity leaking, a Service (which AnySoftKeyboard is) has the same problems as Activity in that regard.

Solution

It's a no-brainer, but tedious: where ever I used a Context object, I made sure that instance is the Application's Context - getApplicationContext().

Cause 2: The Handler Leak OR the Inner Class

The inner-class (a.k.a. nested classes) in Java has an implicit property where it keeps a reference to its outer class, this is why you can call outer-class's functions in the inner-class scope. As long as the Handler is alive, so is the outer-class, and in my case - the whole Input Method Service, which in turn holds the entire tree!
One thing to note, once there are no messages in the Handler's loop, it will go out of reference in the Main Looper, and if there are no other references to it, well, it will be collected, with its implicit outer-class. So what is the problem? you may ask, and you are right. The problem is that some of the messages are delayed (or just still in queue), and as long as there is a message in the queue, the Handler will not be collected, so even if the OS will decide to kill AnySoftKeyboard (say, orientation change) and create a new one, the old one is still in memory, and we have two full trees at the same time. Maybe not for long, but enough time to cause OOM on some devices.

Solution

Very simple: gone over all the inner-classes I had (including the Handlers) and made sure they are static classes, and if they required a reference to the the outer-class, I used WeakReference:

In the code snippet above, I used a WeakReference field to keep a pointer to the main AnySoftKeyboard instance. By using this pattern I was able to call methods of AnySoftKeyboard, but also made sure I was not keeping AnySoftKeyboard from being garbage-collected if needed.
Do remember that if using this pattern it is required to check that the weak reference is still pointing to something (e.g., not null).

Cause 3: The Drawable Callback

Most of the Drawables I use are not attached to Views, but some are, and since I keep reference to the drawables objects, this was still a possible leak. Why? The drawable requires that its client (usually a View) will implement the Drawable.Callback interface, which is used by the Drawable to perform animation related tasks. So, if the View is removed from the window/activity, but Drawable is still referenced, then the View is still referenced too, and will not be garbage-collected.

Solution

I explicitly unbind the drawables when the keyboard's View is no longer needed: This was, actually, not required in my case since the only reference to the Drawable was the View which is the Callback for the Drawable.
Commit (look for changes in AnyKeyboardBaseView.java).

Cause 4: The External Context

This is special for AnySoftKeyboard, most apps do not reference to an external package's Context, but since AnySoftKeyboard supports external packages (i.e., language packs, themes, etc.), I was keeping a reference to that external Context always: let's say you use three languages (not very rare or the users of AnySoftKeyboard), and want to use the Ice Cream Sandwich theme, you'll end up with four external Context objects sitting around in AnySoftKeyboard heap. This is quite a waste, since most of the time I use the external Context only once or twice!

Solution

I moved the external from an explicit reference, to a WeakReference, and added the package's name to class's fields so I'll be able to create the context if needed.
Commit.

Cause 5: The Too Large Objects

Key background, Shift, Control, Enter, Space, Tab, Cancel, Globe, Microphone, Settings, Arrows and more. All these are Drawables which were loaded into the keyboard View, and were kept in memory. About 15 of them, and some with various states (like the Enter key, which has a Normal, Search, Done, Go, etc states, each a full drawable). That's not a leak, but it is still a lot of memory for some devices - HTC Desire will not allow more than 32MB of heap, for example.

Solution

I created a DrawableBuilder class which have all the information required to get the drawable. This way, if the layout does not use a specific icon, it will not be loaded into memory.
Commit.

Cause 6: The Database Connection

After I fixed all the issues above, the app was still crashing on some devices. I had no idea where to look anymore, I was sure there was a leak, and it very elusive, maybe even vendor specific (although the crashes came from many vendors, and various OS versions), so I added to the UncaughtExceptionHandler a code that check of the thrown Exception type, and if it is OutOfMemoryError, I asked the framework do create a memory dump:
I found the leak easily using Eclipse Memory Analyzer (a.k.a, MAT): the leak was a Database Connection Transport, and a huge one, each such transport used 0.5MB (for that user - since he had a large user-dictionary), and it leaked every time the user switched language! It was leaking due to a race-condition.

The Race Condition

When a dictionary is created, it loads its words list using an AsyncTask (so it wont hold up the UI thread), but when the list is long and the device is slow, the dictionary's close method (which is called when the language changes) may be called before the loading is done, hence not closing anything!

So, if it happens always why haven't I recreated it on my devices? Some flavors (Samsung devices and CyanogenMod) could handle that release automatically (there is a finalizer in Java, you know), and they did. Some vendors did not. I had a Samsung, a Motorola and a device running CyanogenMod. Moreover, my devices are fast just enough, and used a small words list. Bummer, ah? Ya..

Solution

Just closed the database connection: by ensuring the related functions use monitors.
Commit and commit.

The End

v95

In App Purchase Verification using PHP OR Making sure you ain't getting ripped off, PHP style!

2012-03-01T12:00:00+00:00

At SpeakingPal we offer our apps for free, and provide customers ways to extend content availability via in-app purchase.

In our case, in-app purchase is build from two parts: the first, is the client's integration with the device's apps services (AppStore in iOS, Market in Android), the second is the server-side verification of the in-app receipt, avoiding trickery of the client's app.

Client-side code samples are in abundance, and usually are very well documented (well, of course, the OS vendor wants to get paid, no?). But the other side, the server-side, is not well documented and lack samples, although considered a best-practice.

Android

Android dev-site suggests making the in-app verification at the server-side as safer, but does not provide any code sample.
Google method of in-app verification is via digital signatures verification: You provide a nonce, they give you a receipt with that nonce prefixed and a RSA-SHA1 signature on that text. The key used for signing is defined in your Market developer console. With that public key, the signed receipt and the signature, you can verify that the receipt is real, that is, produced by the Market service.

Verifying an RSA-SHA1 signature is simple in PHP, but tricky. Here is a working code:

iOS

Apple went with something else; verifying the AppStore receipt is done by asking iTunes' servers whether a receipt is real: after in-app is done, device's AppStore service gives you a base64 encoded receipt, which you'll send to iTunes' servers, and get a json response about the validity of the receipt. Here's a snippet:

PayPal

PayPal actually provide all the information you need, in several programming languages, i.e., IPN verification. I see no reason to paste here snippets.

Enjoy!

Font Metrics in Java OR How, the hell, Should I Position This Font?!

2011-12-19T12:00:00+00:00

I'm working on a new feature for AnySoftKeyboard, where it will 'hint' the user about what lays behind long-pressing a key.

I've decided that the best UX I can provide, is to draw a small character, at the bottom-right corner of the key, showing the long-press output, or "..." in case there are lots of them. It will probably look like this:

So, I had to figure out how to position the character there. Java/Android provides a nice service called FontMetrics, which provide general metrics on the font, like what is the tallest glyph (character), lowest glyph, etc.

Since the hint is very small, I had to make sure the position is precised. So I've dived into the definitions of those metrics, and their values, and cooked up a small Android app which visualizing the metrics, and since an image is worth 37.5 tweets, I give you a screenshot:

Here is FontMetrics in layman lingo:

baseline: the base of your font drawing. Your text will be drawn ABOVE this X.
top: the maximum distance above the baseline for the tallest glyph. Since it is ABOVE the baseline, it is a negative value!
ascent: this is the recommended space above the baseline you should make for a line of this text. Again, above the baseline, so negative.
descent: this is the recommended space below the baseline you should keep for text, since some characters (e.g, y) are drawn some below the baseline.
bottom: this is the lowest glyph space below the baseline.
leading: I haven't included that in the image (or the app) since it is usually 0. But, to make the post complete, leading is the recommended extra space to add between two line of text. I think that the reason that it is usually defined as none, is because bottom (or top) takes care of the extra space needed.

Fingerpainting app for Hagar OR Multitouch sample code

2011-08-03T12:00:00+00:00

In preparation for a five hours flight with my year and a half daughter Hagar, I thought of all kind of toys I could bring along so the confined space wont drive her nuts; I brought a dull (a.k.a Julia), and a toy stroller for Julia (fun fact: in the UK, stroller is called 'pushchair') , some books, and a rattle. I also wanted to bring papers and crayons for her to paint with, but didn't want to totally vandalize the airplane :)

So, what better than a fingerpainting app for Android to play with while on the flight?

A free, fun, simple and multi-touch supporting app in the Market is not an easy thing to find, and after noticing that Google provides sample code for such app, I decided to build one by myself.

It took an hour to improve Google's sample code to include multi-touch. And about five minutes of Hagar's playing with it to notice that I had a bug there! I didn't handle the pointers ID correctly. Fixing wasn't too difficult, and pretty much straight-forward, but I wanted to share it, mostly because non of the posts I found about multi-touch noted it.

Technical stuff*

*For simplicity, I'm only talking about API 8.
Android's MotionEvent will be delivered to the onTouchEvent function on event Up, Down, and Move events; where Up and Down will provide information about the relevant pointer only, and Move will provide information about ALL active pointers. In other words, when you get a MotionEvent.ACTION_DOWN, MotionEvent.ACTION_POINTER_DOWN, MotionEvent.ACTION_UP, MotionEvent.ACTION_POINTER_UP action from getActionMasked function you should only handle the specific pointer (given by getActionIndex) , and when you get a MotionEvent.ACTION_MOVE action, you should handle ALL pointers in the event. Also, it is important to notice that each pointer has an index (the index of the pointer in the event's data list - this may change!), and an ID (which will not change for the life time of touch point).

@Override
    public boolean onTouchEvent(MotionEvent event) {

    	switch (event.getActionMasked()) {

        case MotionEvent.ACTION_DOWN:
        case MotionEvent.ACTION_POINTER_DOWN:
        	touch_start(event.getX(event.getActionIndex()), event.getY(event.getActionIndex()), event.getPointerId(event.getActionIndex()));
            invalidate();
            break;

        case MotionEvent.ACTION_MOVE:
        	for(int pointerIndex=0; pointerIndex<event.getPointerCount(); pointerIndex++)
        	{
        		final int pointerId = event.getPointerId(pointerIndex);
        		float pointerX = event.getX(pointerIndex);
                float pointerY = event.getY(pointerIndex);
                
                touch_move(pointerX, pointerY, pointerId);
                invalidate();
        	}
            break;

        case MotionEvent.ACTION_UP:
        case MotionEvent.ACTION_POINTER_UP:
            touch_up(event.getPointerId(event.getActionIndex()));
            invalidate();
            break;
    	}
        
        return true;
    }

In the code above:

On ACTION_DOWN: I created a new Path object associated with the pointer's ID (event.getPointerId(event.getActionIndex()))
On ACTION_MOVE: I added a path point for ALL pointers.
On ACTION_UP: I removed the pointer (by its ID) from the tracked pointers map.

Notes:

Always reference a pointer to its ID! Index is only used for retrieving pointer information (like its X, Y coordinates) from the MotionEvent object.
Up and Down actions should be used to start/stop tracking code (I'm using it to create a Path object and to associate a color to the pointer)
Move action's object contain information about ALL active pointers. You can get the count of active pointers using the getPointerCount function. You should iterate ALL active pointers since Android will not tell you which pointer has moved, and furthermore, the event will be called at a regular intervals, so sometimes you may notice that there are no changes in the pointers' coordinates and some times more than one pointer will have new coordinates.

Epilogue

As always, you can find my code at github account.

My Boxee Remote OR How Cool is Open Source!

2011-07-12T12:00:00+00:00

For the last year I've been using Boxee as my media center application, and it rulez!!11! I encourage you all to try it out. But this is not the point of this post. I'm going to talk about remote controlling Boxee.

My Boxee is installed on a Linux machine, and I controlled it with Supware's Boxee Remote, a simple gesture based remote control: swipes (navigating) or a tap (select). As you can understand, you don't need to look at the remote UI, or to remember where each action button is located on the UI: just swipe! And with Boxee exceptional UI/UX the whole experience has totally won the WAF!

For a few months everything went great. Some remote crashes from time to time, but all in all, it was good. And then my curious side got the best of me: I found out that Supware's remote is actually open-sourced, which was the incentive to start hacking it. I fixed a few issues, and added some too and sent a patch to Supware. But it was not integrated very well, mostly because the guy had a new daughter (CONGRATS!), and had very little time to play with a working project.

Open Source rulez!

How hard is it to write my own Boxee remote? Not so much!
I took Supware's code for reference, browsed Boxee's official iPhone remote control code, browsed XBMC code and API and read Boxee remote API.
Coded for a few hours (took base64 code from iharder), and that's it! I have my own version!

Features

Automatically detecting your Boxee server
Navigate via swipe gestures
Selecting via tapping
Running media poster as remote background
Media control buttons (just for fun)
Notification icon when media is playing (showing media title, and allow quick return to the remote activity upon clicking it)
Pausing running media upon phone call
And probably more!

Currently, this remote App is not published to the Market here. It is available at my Github account.

Backward compatibility in Android OR How I made a 2.2 Android APK run under 1.5!

2011-04-27T12:00:00+00:00

Update: I've refined the process, and produced an Android jar which can be used in your project to achieve the resource-qualifier based injection! Check it out at FrankenRobot project page!.

As the the maintainer of AnySoftKeyboard, I'm obligated to create a product which works flawlessly on various Android OS versions, starting with 1.5, and to provide advanced features as the underlying OS provides. Luckily, the Android platform provides several ways to create products which are backward compatible, e.g., custom resources per API version and Java's reflection.

In this post I'll show how backward compatibility is done in AnySoftKeyboard, and how advanced features like multi-touch, Backup Agent, Contacts dictionary, and more, are consumed without crashing the application due to ClassNotFoundException or NoSuchMethodException.

Overview

The main Android feature I use for achieving backward compatibility, is the ability to provide API level specific resources, along with a nifty software engineering (a.k.a, object oriented programming). Java's reflection is also used, but scarcely.

Practice

Contacts dictionary checkbox

The ability to query the contacts list in Android was introduced in version 2 (a.k.a API Level 5), so I wanted to limit its settings in devices with API Level 3 (OS 1.5) and 4 (OS 1.6).
This was done by providing a specific dictionary settings layout file for devices running API 5 (where the 'Contacts dictionary' checkbox is enabled) and a different layout file for devices running API 4 or 3 (where the 'Contacts dictionary' checkbox is disabled, and marked off).

In the image above, you see two folders, one for API 4 and the other for API 5. When inflating the Dictionary Settings layout, the file 'prefs_dictionaries.xml' is searched. Android will locate the best match starting with the device's API level, and then searching for lower API levels, so, if my device is API 6, Android will look for 'prefs_dictionaries.xml' under layout-v6 and since it is not there, it will look under layout-v5. In my case, it will stop there since the file was found, but if it wasn't there, it would have continue the search. In API 4 devices, it will start with layout-v4 folder.

In API 4 'prefs_dictionaries.xml' I've disabled the dictionary by including this XML layout:

<CheckBoxPreference
		android:key="@string/settings_key_use_contacts_dictionary"
		android:title="@string/use_contacts_dictionary"
		android:persistent="true"
		android:defaultValue="false"
		android:summaryOn="@string/use_contacts_dictionary_not_supported_summary"
		android:summaryOff="@string/use_contacts_dictionary_not_supported_summary"
		android:clickable="false" android:selectable="false" android:enabled="false"/>

While in API 5 'prefs_dictionaries.xml' I've enabled it with this XML layout:

<CheckBoxPreference
		android:key="@string/settings_key_use_contacts_dictionary"
		android:title="@string/use_contacts_dictionary"
		android:persistent="true"
		android:defaultValue="@bool/settings_default_contacts_dictionary"
		android:summaryOn="@string/use_contacts_dictionary_on_summary"
		android:summaryOff="@string/use_contacts_dictionary_off_summary"/>

Keyboard view

The Keyboard View is the main UI and input object in AnySoftKeyboard: in some Android versions it should provide multitouch capabilities, in some should not, in some it should query the motion events in one way, in others in a different way.
To get this done, I've used a nifty trick: I use the Android's resources tree decision mechanism (the same mechanism I used in the dictionary settings layout inflation) to create an object which encapsulate the required behavior. The difference in behavior are:

Multitouch capability detection.
MotionEvent query functions.
and GestureDetector creation.

These functions are grouped together using the DeviceSpecific interface. API levels 3, 5, 7 and 8 require different behavior, so I created four classes which implement that interface. The concrete class is created by inflating a API level specific layout, which I called FactoryView, and then calling a factory method in that view:
Here is a simple class diagram to explain what I mean:

My resources tree looks like this:

The device_specific.xml file inflates the required FactoryView, which in turn used to create the concrete DeviceSpecific instance.
This inflation is done in the application onCreate method, which ensures that the DeviceSpecific instance exists before anything requires it.
Upon request for a layout inflation, Android will search for the most suitable layout, e.g., if I'm running under Android 1.5, which is API level 3, Android will first look for the requested layout under the folder 'layout-v3', and if it finds it there, it will load it, if not, it will search for it under 'layout'. If I'm running Android 2.2, it will search for the layout under the folder 'layout-v8', then 'layout-v7' and so on, till the default folder.
Each of those layout files points to a different class, e.g., 'layout-v8/device_specific.xml' points to 'com.anysoftkeyboard.devicespecific.FactoryView_V8':

<com.anysoftkeyboard.devicespecific.FactoryView_V8
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:id="@+id/DeviceSpecific"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        />

FactoryView_V8 instantize DeviceSpecific_V8 which includes code conforms to API level 8. What did I achieve from this? The ability to use higher API level MotionEvent methods, and query functions! The higher the level, the more functionality I can use. In v3 I can only get X,Y and event type (up, down, move, etc) while in v8 I can also get pointer ID, better multitouch capability detection and more.

Note that I haven't used ANY Java's reflection methods, or lazy loading technics (which are implementation specific!). I find my method to be much more elegant.

Tap sound

In AnySoftKeyboard, the user can select enabling click sound upon pressing a key (this option is off by default). Upon a key press, the keyboard will take the sound level of the system, and use it to produce the click sound.
In pre-Eclair times, the sound leel was [0..8], while in post-Eclair it is [0..1]. To support this API change, I query the OS for its API Level, and performs the necessary calculation according to the API level:

//pre-eclair
// volume is between 0..8 (float)
//eclair
// volume is between 0..1 (float)
if (Workarounds.getApiLevel() >= 5)
{
	fxVolume = ((float)volume)/((float)maxVolume);
}
else
{
	fxVolume = 8*((float)volume)/((float)maxVolume);
}

That's it.

Conclusion

By leveraging on Android's API Level specific resource mechanism, I was able to easily provide a keyboard for Android devices running 1.5 up to 2.2 or higher with no ugly reflection code (which may break), and no lazy loading technics (which may not work in some optimized Java implementations), and still use advance system functions as the OS provides.
You can always see the source code of AnySoftKeyboard here.

Notes

Android 1.5 and 1.6 only match resources with this qualifier when it exactly matches the platform version. This is a known issue.
Providing density specific resources (i.e., drawable-hdpi) is not supported in Android 1.5, so make sure you provide the default too (i.e., drawable). The default resources are considered as mdpi, normal qualifiers.

Good luck.

Creating videos for Android devices

2011-04-05T12:00:00+00:00

Encoding the perfect video for mobile devices is always hard: you want a small sized file, with high quality, and a codec which will work on all devices, no matter how fragmented the platform is.

Android supports a very nice set of video and audio formats. We see that support for H264 and AAC is available in all Android versions, but with some limitations: H264 is only supported in baseline profile and AAC is supported in MP4 container, and while testing we encountered some more limitations, like inability to play DCT-DECIMATTION encoded files.
I want to share the FFMpeg encoding configuration which worked for us.

FFMpeg configuration

We used H264, 20fps, 200kbps baseline profile, and AAC single channel 32kbps. 2 passes encoding was used.

Preset files

FFMpeg supports preset files to help removing the endless flags from the command line:
First pass preset file (named 'libx264-android_firstpass.ffpreset')

coder=1
flags=+loop
cmp=+chroma
partitions=+parti8x8+parti4x4+partp8x8+partb8x8
me_method=dia
subq=2
me_range=16
g=250
keyint_min=25
sc_threshold=40
i_qfactor=0.71
b_strategy=1
qcomp=0.6
qmin=10
qmax=51
qdiff=4
bf=0
refs=1
directpred=1
trellis=0
flags2=-bpyramid-mixed_refs-wpred-dct8x8-fastpskip
wpredp=0
rc_lookahead=30

Second pass preset file (named 'libx264-android_baseline.ffpreset')

coder=0
flags=+loop
cmp=+chroma
partitions=+parti8x8+parti4x4+partp8x8+partb8x8
me_method=dia
subq=2
me_range=16
g=250
keyint_min=25
sc_threshold=40
i_qfactor=0.71
b_strategy=1
qcomp=0.6
qmin=10
qmax=51
qdiff=4
bf=0
refs=1
directpred=1
trellis=0
flags2=-bpyramid-mixed_refs-wpred-dct8x8-fastpskip
wpredp=0
rc_lookahead=30

Encoding

From FFMpeg folder run the following command for the first pass:

bin\ffmpeg -i source_video_file.avi -vcodec libx264 -r 20 -s 320x240 -b 220k -bt 240k -pass 1 -fpre presets\libx264-android_firstpass.ffpreset -y -an NUL.mp4

For the second pass (and actual encoding):

bin\ffmpeg -i source_video_file.avi -strict experimental -acodec aac -ar 16000 -ab 32k -ac 1 -vcodec libx264 -r 20 -s 320x240 -b 220k -bt 240k -pass 2 -fpre presets\libx264-android_baseline.ffpreset -y target_video_file.mp4

Notes

The FFMpeg version I used has experimental support for AAC, so I used the -strict experimental flag in the second pass
I know that some versions of FFMpeg do not accept the -fpre option to specify the preset file, and requires -vpre

presets

android_baseline

presets\libx264-android_baseline.ffpreset

If you want to stream these video files, you'll need to add hints tracks. MP4Creator is a great tool that can add those hint tranks. Don't forget to add hints for both the video track and the audio track.
If you see this warning in FFMpeg conversion: "Incompatible pixel format 'bgr24' for codec 'libx264', auto-selecting format 'yuv420p'", then IT WONT WORK IN ANDROID! I noticed this warning when editing video files with Camtasia. Switching to Piviti fixed the issue.

Android resources and device fragmentation

2011-03-17T12:00:00+00:00

With all those Android devices out there, as a developer you bound to encounter one that is really annoying.

The ZiiO 7" is such: It is an Android 2.1 tablet with a 'large', 'long', 'mdpi' resources qualifiers, which makes it an odd device. Most tablets are marked as 'large', 'hdpi', so they use the same resources (specifically, drawables) as other Android hdpi devices.

Naive solution

To make the UI look good, the ZiiO7 requires some of the hdpi drawables and some of the mdpi resources, so the only way to do it is by creating a new folder in the application resources folder named 'drawable-large-mdpi', and copy there the mdpi or hdpi images.

This is nice, but since we also want to support 'large-hdpi', and since Android has a very strict "How Android Finds the Best-matching Resource", it means that we also need to create 'drawable-large-hdpi' folder to handle hdpi tables (like the Samsung Tab) - which will result in a huge APK, due to resources duplication, and a maintenance nightmare when revisiting the icons. We don't want that nightmare, right?

The best solution I found

After looking around, I noticed the resource alias option in Android aapt mechanism. Basically, I can make a resource reference to another resource by providing an XML instead of PNG file. The XML will be of type 'bitmap' and will point to a real drawable:

<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/icon_ca" />

or, if the image is a 9 patch, you should use:

<?xml version="1.0" encoding="utf-8"?>
<nine-patch xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/image_ca" />

How to

I wanted to have the images in 'drawable-large-hdpi' and 'drawable-large-mdpi' are the same as in 'drawable-hdpi':

In the 'drawable-hdpi' I'll rename all the files to [real_resource_name]_hdpi.png and move them to 'drawable-nodpi' folder. It is important to move them to the nodpi folder, since we do not want Android resize them.
Create a new XML file named [real_resource_name].xml with the alias text mention above. Remember that it needs to point to the renamed file! In our example '[real_resource_name]_hdpi.png'
Copy the newly created XML file to 'drawable-hdpi', 'drawable-large-hdpi' and 'drawable-large-mdpi' folders.
Run you application to see that it all works. You might want to delete some of the resource, or point them to a different resource. I, for instance, wanted that some of the images ZiiO7 uses are mdpi.

Why it is not perfect

This is the part I hate most about this solution - now I'm required to provide drawables based on the size of the screen, where in a perfect world, I would provide images based on the screen density, and the layouts should change based on the screen size...

Dynamic Copyright Year Text

2011-01-02T12:00:00+00:00

Have you remembered to changed the copyright text?

Well, I didn't. So now I have this code in the company's website footer:

<?php echo date("Y",time());?>

Fuck the CPU cycles.

I've been a bad boy

2010-12-16T12:00:00+00:00

We release our software in a few days. And in the last cycle of tests, all kind of bugs are surfacing up. And we are tight, real tight - our release date was two weeks ago.

No time to fix bugs, no time to switch to a different technology, no time to re-design classes: we need to ship the software! Like real artists.

So, I hacked network code to make a 3rd party code work properly, I kept unrelated code in classes just so their inheriting classes could use it, I 'Spaghetti-ed' the hell out of my code just to quickly implement a requirement.

All-in-all, I've been a bad boy. But sometimes a software developer has to be. I'm not proud of it, but if we want to release, we need to make it work.

Easy on the eye MD5-generated signature*

2010-11-26T12:00:00+00:00

At my work, we employ light-weighted content licensing by applying MD5 over a crafted string. MD5 is quite long, and includes letters and digits, or example: MD5("The quick brown fox jumps over the lazy dog.") = e4d909c290d0fb1ca068ffaddf22cbd0 Since most of our users are using mobile devices, we wanted to make it easy:

only alphabets - so the user will not be required to switch layouts (alphabet<->numbers)
all uppercase - so it will be easy to read, and clear.
replace the letter O - so the user will not confuse it with the digit zero.

How safe is it? Well, as I see it, we still get 16 in the power of 10 permutations (A..P ten times), which are very nicely distributed, the Birthday Paradox does not apply here (since the hash is not used to 'hide' the source, but to 'certify' the source. I think...), and it is very easy on the users' eye. So we have an MD5 string (e.g. 37aa53dc03fd0a18617bda509c243012), and we want to get a human readable, type-able string (e.g. JNAALJDCGJ). Here is the PHP code we used (I take not responsibility for any MD5 or this code limitations!):

function md5_shrinking($md5_signature)
{
	//the input of this function is an MD5 hex (easily created with PHP's function md5($string) )
	//actually, it doesn't have to be MD5 string. It can be anything from a random number
	//to SHA1 to a specially crafted string/
	//I want to do this:
	// 37aa53dc03fd0a18617bda509c243012 -> JNAALJDCGJ
	//sub-stringing to 10: easier on users
	$trimmed_md5 = substr($md5_signature, 0, 10);
	//upper-case so users will read it easily
	$upper_trimmed_md5 = strtoupper($trimmed_md5);
	//converting the digits to alphabets. And I'm going to convert to letters after F (no doubles with
	//HEX A-F letters.
	$regex_trimmed_md5 = preg_replace('/(\d)/e', 'chr(\\1+71)', $upper_trimmed_md5);
	//And converting the letter O to X, so users will not confuse it with zero
	$regex_trimmed_md5 = preg_replace('/(O)/', 'X', $regex_trimmed_md5);
	return $regex_trimmed_md5;
}

Security issues:

Append a salt string to your MD5 input! It will make you feel safer :)
Make sure you understand the MD5 and this function limitations, and see if they are acceptable for your purpose (as mentioned above - I take no responsibility!)
The sub-stringing increases the chances of collisions. This is the cost you'll pay for a human readable/type-able string.
I ONLY think that the Birthday Paradox does not apply here, but I'm no mathematician. It could be.

*note: can be applied to any string.

A Tiny XmlWriter or Why Not to Use Java's XML Framework

2010-11-15T12:00:00+00:00

We are now at the final stages of releasing our first public version of SpeakingPal and go over content and finalize interfaces and data structures.

This can be a very tedious job: we find some kind of error in XML structures and content types, then go to fix this, just to realize we forgot something (this is how it is in a very small startup...) - then redefine the XML structures and try again. While at it, I try to be as lazy as possible and write dogfood kinda tools to do the work for me. This time, I wanted to write a small Java application (I use Java where others use scripting languages) for creating the required XML structures, but I couldn't remember how to use Java's very extensive XML framework, so I googled for "Java XmlWriter", and first came something I didn't expect: source code for a tiny XML files writer. I browsed over the code, and loved it immediately! It was short, and clear, and did almost everything I need.

So, I decided to use this code for my XML generating tool instead of using Java's XML framework, which, I'm sure, handles all the possible errors, and all the special escape codes, and every XML format you may want, etc, etc. The reasons I've decided to use this code and not Java's are:

It is beautiful: no really! It is so simple, and so small, and has 80% of the features you may need, and had a very straight-forward API, I just had to use it.
It is small: our company is creating client applications for Android, Symbian and Blackberry, all uses Java as a programming language, and all are mobile platforms which are low on resources.
It is fast: it doesn't do anything else but write XML nodes since it assumes you will not make structure/syntax errors while building your XML, and you will not try to add exotic data or characters.

For mobile platforms Simple+Small+Fast = GOOD! So, it may not the best for complex applications, but it is very good for resources-limited devices. Anyhow, here is the source code for you to also enjoy (as Henri's code, my code is also BSD licensed). I'm sure there are many other such tiny-xml-like classes. The source code I found was very out-dated. Henri Yandell (the original coder) has moved the source to Google Code and continued evolving the code (and many other projects). Jump over there to see if you might need something. I will :)

Hello world!

2010-11-10T12:00:00+00:00

` Welcome to WordPress. This is your first post. Edit or delete it, then start blogging! `

The text above (and post title) is an automatic post done by WordPress installation (the blogs application used in this site). I find it nice, as a programmer I mean: The first thing you learn in every programming language tutorial is how to create an “Hello world!” program (whether it teaches anything is questionable, especially in the smartphones area which requires way too many satellite files just to get started). Ok, to the point, I’m going to use this blog to share my experiences at my day job, my hobby, side projects, and to talk about solutions I find for all kind of computer related stuff (e.g. how to configure a decent MythTV machine), and possibly things I think are cool (in a geeky kinda way).

Let Me Explain Myself…

Like this. No, Wait... Maybe Like That? a.k.a. The Domain Translation Unlock

Why is that?

Disclaimer

Let’s unlock this

Plan

The Unlock

Anecdotal benefit

Did I do it?

Technical research

To be continued

No! We don't use that here! a.k.a. Making AI Coding NP-Complete

The Theory: Why Generation is NP-Hard

Enter The “Reviewer” Model

The “Secret Sauce”: Living Memory

The Logistics: Can We Actually Do This?

1. The Data

2. The Model

3. The Method

4. The Cost

The Knowledge Trap: Why Your Reviewer Doesn’t Need a Library Card

1. Taste is a Pattern, Not a Fact

2. Training on the “Direction,” Not the “State”

3. Decoupling “The Brain” from “The Conscience”

Prior Art: It’s Not Just Theory

1. The “Reviewer” Architecture Works (Google & Microsoft)

2. The Data Strategy Works (Meta & LIMA)

3. The Future is Reward Engineering (DeepSeek)

A New Kind of Feedback Loop

Faster Builds Without Owning Code a.k.a. I Don't Know Rust, But AI Does

The “Node.js Tax”

From “Coder” to “Agent Manager”

Letting AI Write the Rust

Identifying Candidates: It’s Not Just About Rust

Maintenance: The “Context Window”

Why This Matters: The Scale of Trust

Side Note: This Has Happened Before - kinda

Conclusion

CI/CD at AnySoftKeyboard Part 2 aka Ship It!

Why Continuous Deployment? The Need for Speed and Feedback

Our Deployment Triggers: Different Cadences for Different Audiences

Alpha Channel (The Cutting Edge)

Beta Channel (The Weekly Digest)

Stable Channel (The Official Release)

The Brains of the Operation: Our github_deployments Tool

Executing the Release: The Magic of Automation

Closing the Loop: Visibility and Supporting Tools

To be continued…

My LLM Tooling Doctrine: The Unix Philosophy for Local AI

But Why Not Just Use an LLM Agent/Bot?

The AI Chat Bot Flow:

The Specialized CLI Tool Flow:

Why Monolithic AI CLI Tools Feel Wrong

The Beauty of Specialized LLM Tools

The Critical Base a.k.a. Don’t Repeat Yourself

My Family of Tools: What I’ve Built and How I Integrate Them

LLM Evaluations a.k.a. How We Avoid Wat-Did-You-Say Moments

The Problem with Evaluating LLMs

AI as a Judge

OpenEvals and LangChain

Findings and Next Steps

CI/CD at AnySoftKeyboard Part 1 aka Is it ready to ship?

Process

Why CI - Continuous Integration

Pull Requests

Checks

Tests

Static-Analysis

Cache

Persistent Cache

Docker

To be continued

Bazel and Gradle Co-exist a.k.a. Can't we all just get along?

Why

Pre-requisites

The Problem

What to do?

Maven and Support Library Artifacts in Buck a.k.a. Wait, It Doesn't Have Full Dependency Resolution Support!?

Remote Maven Artifacts

The maven rule

The Brains of the Operation: Our `github_deployments` Tool

The `maven` rule

The `android_support_library` rule