Ankur Sheel

WordXplorer Update 14

Fri, 03 Jul 2026 00:00:00 GMT

You can see all the related updates here

New Theme: Animals - 24 New Levels

The biggest change is a brand-new theme with 24 new levels.

I wanted the game to keep growing in a way that still feels approachable for kids, so this update adds a fresh set of words themed around animals.

Level Selection Screen	Game Screen

Clearer UI and Friendlier Copy

I also updated some of the text and buttons in the game.

The old text just felt way too verbose. The instructions, notifications, and hint copy should now be clearer and easier to understand. Since WordXplorer is aimed at younger players, I want the wording to be simple, helpful, and friendly.

I also updated buttons like Submit and Delete so the main actions are easier to understand at a glance.

Before	After

Cleaner MonoBehaviours

Behind the scenes, I spent most of my time making the Unity MonoBehaviour classes leaner and moving the actual logic into plain C# classes.

By decoupling the game's core rules from Unity's engine architecture, I was finally able to write proper unit tests for the logic.

This was a calulated trade-off. I could have worked on some more features that would be more visible. But having tests gives me immense confidence when making future updates, knowing a tiny change won't accidentally break three other things in the process.

What's Next

Next up is adding a menu screen to the game and possibly some more sound effects. If you have any suggestions for features or improvements that you would like to see immediately, please let me know.

Become a Beta Tester

Want to help catch bugs before they reach the public? I’d love your help. Simply send me a screenshot of your app review, and I’ll add you to the beta team. As a thank you, I’ll also give you a free copy of the app to share with a friend!

Get WordXplorer

WordXplorer is available on the iOS App Store and Google Play Store.

Want to try before you buy? Check out the web demo here.

Thank you for being part of this journey. Stay tuned for more updates!

Defining Good: Why Your Engineering Team Needs Testing Guidelines

Tue, 09 Jun 2026 00:00:00 GMT

Whenever I join a new team, unless there are written guidelines, every person has a different opinion on what good tests look like. The codebase ends up inconsistent and the same debates cycle endlessly till everyone gives up.

And lets be honest, some engineers still write tests just to tick a checkbox and meet a requirement.

It’s not that we don't know how to write tests. It's that we’ve never actually agreed on what good means for our team.

While guidelines might sound like unnecessary bureaucracy, in practice they offer a lot of advantages:

They reduce cognitive load for both authors and reviewers by providing a clear set of standards to lean on and reference.
They ensure long-term readability, making it easy to pick up a test someone else wrote six months ago and actually understand what it's doing.
They speed up writing by eliminating the endless micro-decisions that don’t actually add value.
They make your codebase AI-friendly. Hand these guidelines over to an AI coding agent, and it will write tests exactly how you expect them.

I highly recommend every team come up with their own. These are mine. While they have been sourced from the many companies I have worked at, I have also adapted them heavily for my personal projects. Feel free to use them as a starting point or adopt them wholesale.

Disclaimer: No mock objects or QA engineers were harmed in the making of these guidelines. If you are deeply emotionally attached to HappyPath as a test name, please consult your local reviewer before reading further.

Core Testing Philosophies

Test Both Sides of Your Feature Flags

Always write tests for both the flag-off path and the flag-on path. If testing the flag off scenario is too difficult, document exactly why, note what is missing, and make sure to manually test the scenario.

Optimize for Readability over DRY

A good test suite should read like a Lego instruction manual. Every step is laid out sequentially, is self-contained, and is completely obvious.

When someone navigates to a test to understand how a piece of code is supposed to behave, they should be able to figure it out quickly. A little duplication in tests is a small price to pay if it makes the intention obvious.

Think of your test suite as executable documentation.

Test names should convey the behaviour

A test name like GetUser_HappyPath tells me nothing. What is the happy path? What does success look like? Unless I look at the test body and the underlying implementation, I have no idea what it is doing.

Better names express the state and the expected outcome:

GetUser_HappyPath → CanRetrieveUserById
GetUser_ReturnsError → WhenUserNotFoundReturnsNotFoundError

I have written about this in more detail at A better naming convention for unit tests

Keep Flag Logic Out of Parameterized Tests

It is incredibly difficult to convey what a test is actually doing when you rely on boolean parameters to toggle flags inside the test cases. Keep flag paths in separate, explicitly named tests instead.

Since you will eventually delete the flag-off path, it is perfectly fine to add a _FlagOff suffix to the test that will eventually be removed.

Structure every test as Arrange → Act → Assert

Each test should have one setup phase, one action, and one set of assertions. If you find yourself doing Arrange → Act → Assert → Act → Assert, you have two tests trying to live inside one. Split them up.

Leave Private Methods Alone

Private methods are implementation details. You should test the public methods that call them.

The rare exception to this rule is when testing a highly specific, complex internal behaviour. An example of this is when I wanted to test batching logic for a SQL query with pagination. Since the batch was a constant of 10,000, testing it via the public method would have been extremely painful.

No branching in tests

An if statement inside a test makes it harder to understand and significantly harder to debug when it fails. Instead, pull the shared code into a helper method and write two separate, clean tests.

Avoid spies

Needing a spy is usually a design smell.

A spy wraps a real object and lets you verify which calls were made on it. Using one suggests your code is doing something internally that isn't represented by a clean interface.

The right fix is almost always to extract that dependency and inject it as a mock or test double instead. However, if you are working in a legacy codebase and can't easily restructure the code, use the spy but leave a comment explaining why. This forces you to articulate why there was no better option and saves the next developer from wondering why it's there.

Use test doubles in integration tests, not mocks

Integration tests verify that your components work together correctly. When you mock a dependency, you replace real behaviour with a scripted response. If your assumptions about how that dependency behaves are wrong, your tests will pass while production breaks.

Fakes and stubs actually implement the behaviour, just in a simpler way. For example, a fake email service that stores sent emails in memory still behaves like an actual email service.

I have written about the different options at Stubs vs Mocks vs Fakes vs Spy.

Setup

Keep Setup Code Relevant to the Assertion

If setup code is unrelated to what you are asserting in a specific test, move it into a helper method. Parameterise your helper methods so it is immediately clear what is unique about the current test.

However, if removing the setup from the test body altogether makes the test harder to follow, keep it inline.

var user = CreateValidUser(id: "invalidId");

userService.Validate(user);

Start from the minimum for database-dependent tests

For tests that rely on the database being in a specific state, start from the minimum setup required for the application to run, and build up the state directly inside the test. This keeps dependencies explicit and prevents a change in shared test data from breaking tests.

Assertions

Assert one concept per test

Asserting one concept does not mean you are restricted to a single assertion line. A test called CanRetrieveUserById can comfortably assert on multiple returned fields:

var user = userService.GetUser();

Assert.Equal("id", user.Id);
Assert.Equal("name", user.Name);

What it shouldn't do is also verify that an underlying analytics service was called during the retrieval. That is a separate concept and should live in its own test.

Assert on properties, not object equality

When you assert on object equality, you are at the mercy of how Equals is overridden on that class.. You're trusting that whoever wrote it checked every field you care about.

Asserting on properties directly means your test is explicit about what it actually cares about. When it fails, you know exactly which field is wrong.

Avoid this:

var expected = new User
{
    Id = "id",
    Name = "name"
};

var user = userService.GetUser();

Assert.Equal(expected, response);

Do this instead:

csharp

var user = userService.GetUser();

Assert.Equal("id", user.Id);
Assert.Equal("name", user.Name);

Exception: If you want to catch the case where someone adds a new field and forgets to handle it, create an explicit AllFieldsAreSetCorrectly test and use object equality there intentionally.

Use `Assert.Multiple` for multiple assertions

If a test has multiple assertions and fails, you want to see all the failures at once, not just the first one that blocked the run.

xUnit 3 has Assert.Multiple and Assert.MultipleAsync built in for this. For older versions, I put together xUnitHelpers, a small NuGet package with helpers I I found myself writing from scratch on almost every project.

Verify what matters, ignore what doesn't

If your code delegates an important, state-changing call to a mocked dependency, verify it explicitly. But avoid verifying every single interaction or assertion on unrelated dependencies. It only makes your tests brittle.

A starting point, not a finish line

I'm not suggesting you adopt these exact guidelines wholesale. Every team has different constraints, languages, and codebases.

But next time a code review devolves into a circular argument about test names or assertion styles, ask yourself:

Is the real problem just that nobody ever wrote the expectations down?

Pick a starting point, document it, and iterate. The goal isn’t a perfect document on day one. It’s simply having a shared standard to point to.

Note that these are guidelines, not rigid rules. Treat your guidelines as a living document, and update them as your team learns and evolves.

What is one rule on this list you disagree with, or one guideline your team swears by that I missed? Let's discuss in the comments below!

Startup versus Big Tech: The Good, the Bad, and the Ugly

Wed, 22 Apr 2026 00:00:00 GMT

I’ve spent about two decades bouncing between startups, Big Tech, and everything in between. Recently, someone early in their engineering career asked me which path they should take.

My answer was the same as it is for most engineering questions: it depends but this is what I would do.

Both environments have completely different dynamics. They reward different styles and need different skills to be successful.

Here’s my honest take on the good, the bad, and the "ugly" of both.

And if you just want to know what I’d personally do, you can scroll to the end. But I'd urge you to actually figure out what works for you.

The stage of business determines what game you are playing in the first place: what the job will be like, who will be successful in it, and the mix of risk and reward you are accepting. So start there.

Dan Hock

Startups: The Good

Ready or Not: You learn fast

There is no - I don't know how to do that.

Startups are amazing places to learn a lot of different things quickly. Because the company is small, there usually aren't specialized teams to hand things off to.

You jump in where needed, even when you don't have a clue what you're doing.

At First AML, I touched everything: backend systems, developer tooling, processes, just whatever needed to be done. That kind of environment broadens your expertise incredibly fast.

Visible Impact

Startups are flat. You can influence the direction of the product, push back on decisions, and see the result of your work in the hands of real users quickly.

You know everyone.

Startups are tight-knit in a way that larger organisations can't replicate. It’s easier to feel a personal connection when you aren't just Employee #10,402.

Startups: The Bad

Learning is Self Directed

The flip side of "you learn fast" is that there's often nobody to learn from. When you're stuck, you're mostly stuck alone. No senior engineer who's solved this exact problem before, no internal documentation, no established way of doing things. No mentors. You can pick up bad habits without realizing it.

Compensation is… aspirational

Startup Equity is Monopoly Money

Base salaries are lower. Bonuses are rare. Stock options sound exciting until you realise that you need an IPO to see any of it.

Most exercise windows are short enough that leaving early means walking away from everything that you are "promised". You have no control over dilution or what kind of exit the company pursues.

Startups: The Ugly

Money Problems

Several startups I worked at had payroll problems. Salaries were delayed for months on end.

Holidays were cancelled because of a deadline that had to be met or the company would fold. It wasn't pretty.

Most of them fail

This is not a hot take. Startups fail. The earlier they are in the lifecycle, the higher the risk. You can do everything right and still find yourself out of a job because the runway ran out.

You might have little to show when the company folds.

Big Tech: The good

Career rocket fuel

Having a big name on your CV opens doors before a recruiter even looks at your skills. Your skills and expertise is assumed.

You learn a different kind of discipline

Big Tech teaches a different kind of engineering: depth, rigor, and long‑term thinking.

At Atlassian, the scale alone was an education. Established practices, specialized teams, engineers who’d solved hard problems before.

I learnt how to build systems that survive millions of users and thousands of edge cases. You learn how to plan and how to operate inside a complex ecosystem where different teams have their own roadmaps and commitments.

The money

Money is not the limiting factor.

Big Tech pays pays extremely well. Base salaries are high, bonuses are common, and equity is actually worth something. Perks feel unreal.

If financial independence or having shiny things is a goal, this environment makes it a lot easier.

Big Tech: The Bad

A small cog in a big machine

It can be genuinely hard to see how your work connects to anything that matters. You can ship something used by millions and still feel that you didn't move the needle.

Everything takes longer

A straightforward change can take days. Stakeholder approvals, code reviews, teams in different time zones who own different parts of the system all contribute. You will spend a non-trivial amount of your career waiting.

Growth can plateau

Progress isn’t always tied to ability.

You can be the best engineer on your team and still find that the path forward is unclear.

Big Tech: The Ugly

Performance reviews create strange incentive

Doing work that results in a great performance review is not always the same as doing work that best helps the company.

Individual impact is what gets measured, which makes it genuinely difficult to do work that benefits the broader organisation without also making sure it's visible enough to count for you personally.

Doing great work that benefits the company but doesn't "look" like a big individual win can actually hurt your career.

In the most pathological companies, work is created primarily so that someone more senior can demonstrate impact and get promoted, not because it's the right thing to build.

Switching Directions

The pay cut might be hard, but the loss of structure is harder.

The common path is startup to Big Tech, not the other way around. Big Tech teaches you how to build at scale with lots of support. Startups need scrappiness, breadth, and comfort with chaos. Big tech skills don’t always transfer cleanly.

What would I do?

If I were early in my career and had both options, I would take Big Tech.

You can always leave for a startup later. You can't go back and add the name to your CV.

While it wasn't exactly "Big Tech", this is why I joined Perot Systems after graduating. It signaled to future employers that I had the skills to be hired by a recognizable company. It was a stamp of approval.

A year later, I left to follow my passion - making games. I took a massive pay cut and joined a games company. Not a startup in the purest sense, but it had all the same problems: a tiny engineering team and constant payroll issues.

I could take that risk because I had Perot Systems on my CV. It provided me with a safety net and derisked that decision for me.

So which should you choose?

If you're early in your career and havent worked for a recognizable company yet, take the opportunity when it comes. It makes every future job hunt easier.

But don't stay so long that you forget how to hustle. They are called golden handcuffs for a reason. I know people who stayed so long they now struggle to move anywhere else except for maybe another big company.

Once you have some experience, optimize for learning over compensation.

The environments where you're slightly out of your depth are usually the ones that move your career forward fastest.

I grew more and learnt more things at First AML than anywhere else.

Conclusion

The sweet spot is somewhere between understanding the discipline of a large organisation and still being able to build something from scratch.

Where are you in your journey, and which way are you leaning right now? Do you prefer the stability of a big company or the excitement of wearing ten different hats at a startup? Or are you just there for the free snacks?

WordXplorer Update 13: Updated Flip Animation

Thu, 02 Apr 2026 00:00:00 GMT

You can see all the related updates here

Flip Animation Overhaul

I updated the flip animation to make it a pop a bit more. You can see for yourself and tell me waht you think.

Before	After

Code Cleanup and Unity Upgrade

I upgraded to Unity 6.3 to keep the engine current and to get the free AI credits. I am not sure what I did wrong but I was unable to get the AI credits to work.

I also removed some tech debt to make it easier to add tests and updated Github Actions to use macos-26 to stop a Apple warning related to Xcode.

What's Next

I had some UX and copy improvements ready to go but ran out of free GitHub Actions minutes before I could ship them. They'll be in the April update.

Become a Beta Tester

Get WordXplorer

WordXplorer is available on the iOS App Store and Google Play Store.

Want to try before you buy? Check out the web demo here.

Thank you for being part of this journey. Stay tuned for more updates!

Rolling Your Own Dependency Injection in Unity

Tue, 24 Mar 2026 00:00:00 GMT

Unity codebases have a way of turning into spaghetti. Every system talks to every other system through singletons and magic strings, and it never gets better with time. When I came back to Unity to build WordXplorer, I knew what I wanted: clean dependency injection, testable classes, no hidden dependencies. The problem was that while I'd used DI in .NET Core apps, I'd never seen it in a Unity project.

By the end of this, you'll have a setup where plain C# classes get proper constructor injection, MonoBehaviours register themselves automatically, and the whole thing initialises lazily without a bootstrapper. It ends up feeling a lot like any other .NET Core app which is exactly the point.

The Alternatives (And Why They Fall Short)

Before getting into the solution, it’s worth looking at what most Unity developers do instead. Spoilers: it’s not great.

Drag-and-Drop in the Editor

The simplest way to connect objects is to expose a private serialised field and drag the reference in the Inspector. This is convenient, especially for artists and designers who can wire up behaviours without touching code. But it's a lot of manual effort and doesn't scale. And none of it is easily testable because you can't run a unit test against a scene.

Querying the Scene

You can find objects at runtime in a few ways: by name, by tag, or by type.

Finding by name or tag relies on magic strings. Rename something in the hierarchy and the code breaks. The worst part is you only find out at runtime.

Finding by type is better because it's at least type-safe. But it's still a global scene query, it's slow, and it gives you no way to swap in a different implementation for testing.

Singletons

Most Unity tutorials reach for singletons, and they are better than the two options above. But in practice, singletons cause three problems that compound as the project grows.

Global state: Every singleton is effectively a global variable. Any class can reach in and modify it at any time, from anywhere. Reasoning about what changed, and when, becomes increasingly difficult. You can manage this if you're diligent — but diligence has a way of slipping when you're in a rush and just need to ship.

Hidden dependencies: When a class accesses a singleton directly, that dependency is invisible from the outside. You can't tell what a class needs just by looking at its constructor or its interface. The only way to find out is to read the implementation.

(Un)testability: Singeltons make writing automated tests hard. If a class depends on a concrete singleton, you can't swap it out for a fake in a test. You could test with the real thing, but only if it has no side effects and doesn't depend on other singletons. In practice, it usually does.

Unity-Specific DI Frameworks

There are frameworks built specifically for Unity DI like Zenject and VContainer. Both are heavy frameworks with their own learning curve. I find them too bloated for my purposes, but they might be a viable option.

To be honest, I really didnt look too much into them. I might just be reinventing the wheel here.

What is Dependency Injection?

DI (Dependency Injection) is a technique in OOP where instead of a class creating its own dependencies, you pass them in from the outside.

So instead of this:

public class GameManager
{
    private AudioManager _audio = new AudioManager();
}

You do this:

public class GameManager
{
    private IAudioManager _audio;

    public GameManager(IAudioManager audio)
    {
        _audio = audio;
    }
}

Now GameManager doesn’t care if it gets a real AudioManager or a mock for testing. A DI container automates the wiring and resolves them wherever they're needed.

Why Does Unity Make DI Awkward?

Two things get in the way in Unity.

First, MonoBehaviours can't be newed up. Unity owns their lifecycle by calling Awake, Start, Update, and so on. You can't pass dependencies through a constructor the normal way.

Second, there's no single entry point. A .NET console app has Main. An ASP.NET app has Program.cs. But Unity has scenes, objects, and an initialization order you don't fully control. Scenes can also be loaded and unloaded, which means objects might not always be present when the container is first created, or might be destroyed after they've already been registered.

You might think these two constraints would be a showstopper. They're not. But they do require a slightly different approach.

The Solution

Step 1: Add the NuGet Packages

Download the following DLLs from NuGet and drop them into your Assets/Plugins folder:

Microsoft.Extensions.DependencyInjection.dll
Microsoft.Extensions.DependencyInjection.Abstractions.dll

I've written about how to install NuGet packages in Unity in more detail. If you use assembly definitions, add references to these DLLs in the relevant assembly definition file.

Step 2: The DependencyHelper

DependencyHelper owns the DI container and acts as the resolution point for both plain C# services and MonoBehaviours.

public sealed class DependencyHelper
{
    private static readonly Dictionary<Type, object> _injectedMonoBehaviours = new();
    private static readonly Lazy<DependencyHelper> _lazy =
        new(() => _instance ?? new DependencyHelper());
    private static DependencyHelper _instance;
    private static ServiceProvider _serviceProvider;

    private DependencyHelper()
    {
        var serviceCollection = new ServiceCollection();
        ServiceRegistry.RegisterServices(serviceCollection);
        _serviceProvider = serviceCollection.BuildServiceProvider();
        _instance = this;
    }

    public static void Register(object instance)
    {
        _injectedMonoBehaviours[instance.GetType()] = instance;
    }

    public static T GetInjectedMonoBehaviour<T>() where T : class
        => _injectedMonoBehaviours[typeof(T)] as T;

    public static T GetRequiredService<T>() where T : class
    {
        _ = _lazy.Value; // ensures the container is built on first call
        return _serviceProvider.GetRequiredService<T>();
    }
}

Register: called automatically by InjectableMonoBehaviour.Awake to store the live MonoBehaviour instance.
GetInjectedMonoBehaviour: used inside ServiceRegistry to wire a MonoBehaviour into the container by fetching the stored instance.
GetRequiredService: how everything else resolves dependencies. Throws if the service isn't registered.
The Lazy factory ensures the container is built exactly once, on the first call to GetRequiredService. The _instance check means there is only ever one container instance.

Step 3: Inherit from InjectableMonoBehaviour

Next, we need a way to add MonoBehaviours to the DI container

InjectableMonoBehaviour is a base class that MonoBehaviours inherit from, which registers them with the container when they wake up.

Any MonoBehaviour that needs to be resolvable by the container should extend this:

public class InjectableMonoBehaviour : MonoBehaviour
{
    protected virtual void Awake()
    {
        DependencyHelper.Register(this);
    }
}

When Unity calls Awake, the MonoBehaviour registers itself by type. That's it. The container can now hand out a reference to this instance when something asks for it.

Step 4: The Service Registry

This is where you tell the container what goes where.

public static class ServiceRegistry
{
    public static void RegisterServices(IServiceCollection serviceCollection)
    {
        // Plain C# service
        serviceCollection.AddTransient<ILevelSaveDataService, LevelSaveDataService>();

        // MonoBehaviour
        serviceCollection.AddTransient<IAudioManager>(
            _ => DependencyHelper.GetInjectedMonoBehaviour<AudioManager>());
    }
}

Plain C# services register normally. MonoBehaviours are different - they use a lambda to defer the lookup until the instance is actually needed, by which point Unity will have called Awake on the MonoBehaviour and registered it.

Step 5: Watch the Lifecycle Order

This is the part that will bite you if you're not paying attention.

Unity calls Awake on scripts in an arbitrary order. If you try to resolve a dependency in Awake, you might run before that dependency has even registered itself. If that happens, you will get a KeyNotFoundException at runtime.

We know that Start is called after Awake, so the rule is simple:

Always resolve and use dependencies in Start, not Awake.

This also has the added benefit of resolving the dependency only once.

public class LevelSaveDataManager : MonoBehaviour
{
    private ILevelSaveDataService _levelSaveDataService;

    private void Start()
    {
        _levelSaveDataService = DependencyHelper.GetRequiredService<ILevelSaveDataService>();
    }
}

The same caveat applies across scenes. If a scene transition destroys and recreates MonoBehaviours, they re-register themselves in their new Awake. The container's service registrations stay intact - those lambdas always pull the current live instance. But if you're holding a cached reference somewhere and the MonoBehaviour was destroyed, that reference is stale. Be deliberate about when you resolve.

Isn't This the Service Locator Anti-Pattern?

Yes. I know. I'm not thrilled about it either.

The criticism is legitimate: when a class calls DependencyHelper.GetRequiredService<T>() directly, its dependencies are hidden. You can't tell from the constructor what it needs. Testing becomes harder because you have to know to configure the locator before running any test.

But Unity’s lifecycle leaves us with very few "clean" options.

Constructor injection requires that you control object creation.

In Unity, you don't. MonoBehaviours are created by the engine, attached to GameObjects, and initialised through Awake and Start. There's no constructor call you can intercept to inject dependencies the clean way.

I think the Service Locator is a small price to pay given all the other alternatives. We can minimize the damage by treating MonoBehaviours as a "thin" layer. They handle the Unity stuff (input, rendering), and delegate all the actual logic to injected plain C# classes.

As you saw in Step 5, LevelSaveDataManager is the thin MonoBehaviour — it knows when to load. ILevelSaveDataService is the plain C# class where all the loading logic lives, fully testable without a running scene.

Was It Worth It?

If you've worked on .NET Core apps, you already know most of what's here. Unity just requires a small amount of extra wiring to account for its lifecycle. Once that's in place, you can mostly forget it's there.

What are your experiences with DI in Unity? Have you gone the Zenject route, or are you still living with singletons? I'm curious what you are doing? Let me know in the comments.

WordXplorer Update 12: Demo Build & Teacher Feedback

Tue, 17 Mar 2026 00:00:00 GMT

You can see all the related updates here

Automated Screenshot Capture

Updating the WordXplorer store listings has been a tedious affair. Previously, I had to manually capture screenshots for every device size, which made it difficult to keep visuals up to date as the game improved.

To solve this, I wrote a series of custom Unity Editor scripts to automate the process. These scripts programmatically trigger high-resolution renders for every required form factor and automatically apply a branded banner to each shot.

Before	After

Teacher Approved Feedback

I’ve been working toward getting the "Teacher Approved" badge on the Google Play Store. While the app was previously approved, Google has identified two specific areas I need to address to maintain that status: Text Volume and Replayability.

I'm currently brainstorming ideas to address these two concerns and ensure the game gets approved again.

Demo Build Updates

I’ve updated the web demo to include all themes and levels available in the paid version. While active play is still limited to the first six levels, users can now browse the full library of content.

My goal is to ensure players see the full scope of the game before purchasing, so they know exactly how much content they are getting in the full version.

What's Next?

I’m currently prioritizing which features to add next - there were quite a few that were cut from the initial release to get the game into your hands faster. I'm looking forward to bringing those back into the roadmap.

Get WordXplorer

WordXplorer is available on the iOS App Store and Google Play Store.

Become a Beta Tester

Try the Demo

Want to try before you buy? Check out the web demo here.

Thank you for being part of this journey. Stay tuned for more updates!

WordXplorer Update 11: New Theme

Thu, 05 Feb 2026 00:00:00 GMT

You can see all the related updates here

New Theme

Remember when I asked you which theme should come next?

Well, you voted. And here it is.

I've added a brand-new theme with 24 levels focusing on body parts.

Hands, feet, eyes – the classics and a few tricky ones. It's the kind of vocabulary that actually helps kids describe their world.

Level Selection Screen	Game Screen

Dynamic Backgrounds

Some of the more eagle eyed readers might have noticed that the background is a little different in the above 2 screen shots.

There are no more generic bubbles. No more one-size-fits-all backgrounds. The backgrounds now change based on the theme.

If you're playing the Things We Eat theme, you see food. If you're in Body Parts, you see... well, you know. It sounds simple, and it is. But, it gives kids an instant visual clue about what the theme is.

To be honest, this works best on a tablet where you can really see the new elements.

On a phone? It's more subtle – due to the lack of screen space. But if kids need a reminder of the theme, the hint screen has them covered.

Before	After

Beta Testers Save the Day

Before I released this update to everyone, the beta testers found a couple of nasty bugs.

One was particularly gnarly: if you completed the last level and then tried to click "next level," the game would crash. When you reopened it, the level selection screen would be completely borked.

I'm so glad we caught it before release.

If that had made it to a paying user? Ooof. That would have sucked.

Want to Be a Beta Tester?

If you're interested in helping me catch bugs before they reach everyone else, I'd love to have you on board. All you need to do is send me a screenshot of a review (to prove you've got the app). That's it. As an added bonus, I will give you a free copy of the app to give to your friends.

Level Button Updates

Before the level selection screen, the level buttons were just random colors. They looked colorful but didn't give a clear indication of what level is completed and which one is newly unlocked. Now the level buttons can only have 1 of 3 colors - depending on the level status.

Before	After

What's Next?

I'm adding a proper menu screen. It's not flashy – just polish and table stakes. Things that I had cut for the intial release.

More updates coming soon. Can't wait to share what's next.

Get WordXplorer

WordXplorer is available on the iOS App Store and Google Play store.

Want to try before you buy? Check out our web demo

Thank you for being a part of this journey with me! I'm eager to hear your thoughts and feedback. Stay tuned for more updates!

WordXplorer One Year In: Am I a Millionaire Yet?

Tue, 13 Jan 2026 00:00:00 GMT

It's been just over a year since I released WordXplorer - a Wordle-inspired game for kids built in Unity. Available on the App Store and Play Store, this has been an interesting adventure.

The million-dollar question that is on everyone's mind:

Are you a millionaire yet?

Not quite. But I've crossed a few items off my impossible list.

Most importantly, I've validated that people are willing to pay for something I've built. And that feels good.

In this post, I'll share WordXplorer's performance over the past year, the feedback I've received, and the lessons learned along the way.

A Little Backstory

In June 2024, I started working on a prototype of a Wordle-like game for my daughter. She loved trying to do the New York Times Wordle with us, but it was (at times) just too hard for her. It was also not very enticing for a kid. Greys and black are not the most kid-friendly colours.

Thinking that other kids might want to play along with their Wordle-loving parents, I decided to make it into a paid app and announced a release date of December 1st in early November 2024. I priced it at USD 3.99 - roughly the cost of a coffee.

What went right

My daughter still plays it

Seeing my daughter play and enjoy something I built for her - that never gets old. That's why I started this whole thing. She's the 1st tester for all the changes I make and always has some good feedback for me. She's quick to tell me when a word is too hard or when she spots a bug I missed.

Including my daughter, I still have 1-4 other active users on any given day.

Getting help early on

My artistic chops are average at best (and that's me being extremely generous). Getting Manjari to help me with the non-engineering side of things was one of the best decisions I made.

Even though we are both extremely busy with work and syncs across the timezones were (and still are) challenging, having someone else to shoulder some of the load and talk through ideas made it a lot easier.

The game also looks significantly better than I had made in the prototype phase. See for yourself.

Before	After

GitHub actions and CI/CD

One of the first things I did was set up GitHub actions to run automated tests on every merge to the master branch. I also set up workflows to deploy to the web and app stores.

Since I don't have a Mac, this made deploying to the iOS App Store much cheaper and easier. I could trigger a deployment at any time. On PRs, I had test builds on the web using Netlify's branch deploy feature. Best of all, I could work in parallel on my local machine while it was building (which took upwards of 20 minutes).

Pre-orders

I started the App Store pre-order process early. It let me navigate the approval process and work out most of the kinks before the December 1st launch day.

One thing I learned during pre-order: I can't use "Wordle" in the app description or screenshots which kinda sucks since the game is essentially "Wordle For Kids" and would have been the easiest way to get people to buy it.

Imagine being ready to launch and then hearing from the App Store ~~gods~~ reviewers that "Wordle" is not allowed in the description or screenshots and having to delay the launch by a few weeks.

Making hard calls to ship

When I announced December 1st as the launch date, there was so much to be done.

It was fine when it was a free game that I made for my daughter, but a paid app for strangers is a totally different ball game. Deciding which features to cut for launch wasn't easy, but I had to ship, so I made the hard calls.

Too many side projects die in "just one more feature" hell.

Looking back, it was the right call even though I knew 30 levels wasn't enough and I didn't have all the polish. I had to get it out on time.

Validation

I didn't go viral. I didn't make life-changing money. But people paid real money for something I built. That's something.

Friends and family bought it initially - that's expected.

But then someone else bought it. A complete stranger who had no obligation to support me. It was proof that someone out there thought what I built was worth paying for.

If you're sitting on a side project, waiting for it to be "perfect" before launching - just ship it. Shipping something you know is not finished is scary, but you should still do it. You will learn a lot.

Natural break patterns

The average session is around 3 minutes. That's roughly one to two levels, which means most kids play, complete a level or two, and then leave the app to do something else.

Some kids binge multiple levels and go up to 30 minutes, but the typical pattern is short sessions.

This is great since I didn't want kids getting hooked and be on the screen for hours on end. And since most users have completed all 30 levels, they have clearly come back to play the levels.

The average user has spent about 1 hour on the app total.

What went wrong, aka lessons learned

Pre-orders are great (if you actually promote them)

The pre-order strategy was smart for working out the kinks with App Store approval. But not promoting it ~~widely~~ at all? That was dumb.

I fell into the classical engineer's mistake:

Build it, and they will come.

I didn't publicise the pre-order beyond some posts on this blog. A few days before launch, I directly messaged friends and family, which resulted in a grand total of 4 pre-orders. Two of those were later cancelled.

Yeah. Not exactly a viral launch.

Part of it was discomfort with self-promotion. Part of it was simply not knowing where to start.

If you're going to offer a pre-order, be sure to let people know about it.

Google's requirements

Google requires 12 people to actively play your game for 10 days before you can even release an app to the store.

And if it's a paid app then they have to buy it to even test it. It's unclear if they have to buy it again when the app store listing goes live, so to be safe I just made it free for a week so that people could download it without having to pay. Unfortunately promo codes just didn't work for this.

Not just install it - actively play it for 10 days. I didn't know what would happen if someone quit after 2 days or didn't play every day, so I added 15 people to be safe. Getting friends and family to commit to playing for 10 days straight was challenging.

It's a significant hurdle that slowed down the Android launch. It also meant people who otherwise might have bought the game got it for free.

I gave 12 promo codes on iOS as a thank you for providing early feedback.

The kicker: promo code users can't leave reviews on the App Store. These were my most supportive users - the ones who would have left positive reviews - and the platform prevented them from doing so.

Even though I didnt know this at the time, I would have still given the promo codes.

Android refunds

Android allows refunds within 2 hours of purchase, no questions asked. Out of the 20 orders I got, I had 17 refunds. Ouch.

When I first saw them, I was confused. The game wasn't broken, so what went wrong?

My best guess? A combination of things:

Most people refunded within 15 minutes, so they probably didn't like the look of it or bought it by mistake.
Maybe some played longer and felt 30 levels wasn't enough content for the price.
The description and screenshots might not have communicated what the game actually is and the lack of polish probably didn't help either.

The frustrating part? No feedback. Just money taken back. If they'd told me why they didn't like it, I could have fixed it for them or future users.

Procrastination

Most people have completed all 30 levels. I didn't realise how hard it would be to add a new theme and how much work it would entail. Some of my previous architectural decisions came back to haunt me.

After the Android release in July 2025, the project was put on the back burner for six months. Not because of work and life (though that was a factor). I was procrastinating because building new themes felt too hard. Everything was stuffed into MonoBehaviours with very few abstractions. This made it nearly impossible to write automated tests, and adding features meant testing everything every time I made a change.

Eventually, I bit the bullet and refactored the level selection screen/system and added automated tests. It took over a month. But it gave me confidence to make changes in that area without breaking everything.

One negative review

I also got one negative review. It seemed the person didn't understand how the game worked, and it didn't meet their expectations. That stung, but it was valuable feedback. Probably, if they were on Android, they would have just gotten a refund.

Based on that review, I updated the description and made the instructions a lot clearer.

Show me the money numbers

Let's talk numbers.

I built this on nights and weekends with help from Manjari.

Total cost: About NZD 550 (dev accounts, IDE, etc).
Total proceeds: About NZD 110 (after Apple's and Google's cut but before taxes, etc)

Forget "retirement money", this is not even "cover your costs money".

iOS:

Total Downloads: 29
Total Orders: 17
Total Revenue: NZD 127
Proceeds (after Apple's cut): NZD 98

Android (launched July 2025):

Total Downloads: 35
Total Orders: 20, but 17 refunds :(
Total Revenue: NZD 22
Proceeds (after Google's cut): NZD 17

Monthly breakdown:

Date	iOS Units	Android Units
Nov 2024	1	0
Dec 2024	9	0
Jan 2025	4	0
Mar 2025	1	0
May 2025	1	0
Jul 2025	0	1
Aug 2025	0	1
Sep 2025	0	1
Dec 2025	1	0
Total	17	3

Most sales happened in the first month (no surprise), but I still got sporadic purchases throughout the year. iOS went completely silent from Jul to Nov - probably because I did no marketing and very few updates.

Geographic Distribution:

Territory	iOS Sales/Total Downloads	Android Sales/Total Downloads
India	8/13	1/8
United States	7/9	2/10
New Zealand	0/5	0/2
Australia	1/1	0/1
Canada	1/1	0/0
United Kingdom	0/0	0/1

Unsuprisingly, most downloads came from India, USA and New Zealand - those areas are where I focused my (minimal) outreach and gave out promo codes. The download from Canada was unexpected. I didn't speak to anyone there.

Nearly half of my downloads came from organic App Store search. Not bad for zero marketing efforts.

Someone even discovered the game in December 2025, a full year after its launch. I only found out from my monthly report, but that was a nice surprise. Even though I don't know what they were searching for, I am glad they bought it.

Shipped improvements

Even though updates have been sporadic, watching my daughter play and looking at the analytics showed me what needed fixing. Some of the highlights from the past year:

Contextual hints: Kids were getting stuck. I added clues that unlock as they play, helping them think about the word differently without giving away the answer. Analytics show that this is a very popular feature.
Save progress: Kids would start a level, leave, and have to start over. Before I added hints, some of them, including my daughter, would quit the level after attempt 6, and restart it essentially having unlimited tries to figure out the word. Kids are smart, and they will find ways to ~~break your game~~ game the system. Saving their progress not only closed this loophole but also allowed them to take breaks and pick up where they left off.
Web demo: In response to the refunds, low purchase volume, and negative feedback, I added a web demo a few months ago so people can try it before committing to buy. I still don't know if it has made any difference.
Squashing all the bugs.

What's Next?

Now that I've refactored some of the code, I can actually add content without spending hours clicking through the screens. I still need to refactor the main game screen though :(

New theme dropping in February - body parts. It's already in active testing and I'm working out the kinks.

I'm also going to be adding the things that make it feel like a complete game, not just a prototype that shipped: proper menus, settings, polish. The stuff I cut to hit that December 1st deadline.

I've figured out a sustainable schedule with a plan to write an update post every month. In fact, one has already gone out in January.

So… Was It Worth It?

Yes. Not because I made a ton of money (I didn't). Not because I have thousands of users (I don't).

Eventually, this might actually be profitable. Even now I can claim some of the expenses to reduce my tax burden.

But even if it never makes me a ton of money, I crossed items off my bucket list, got a creative outlet from professional work, and got to see my daughter play something I built for her. You can't put a price tag on that.

Sitting on a side project that's "almost ready"? Ship it. I'd love to hear what happens.

Lost money on something you built but would do it again? Tell me about it.

Want to be a beta tester and get updates earlier? Let me know!

Get WordXplorer

Want to try before you buy? Check out the web demo

WordXplorer Update 10 : Fireworks, Levels, Polish

Tue, 06 Jan 2026 00:00:00 GMT

You can see all the related updates here

It’s been a while since I wrote an update on this blog.

Not because there were no update. Well, for some time that was true. You know work and life and all that. But the good news is that I have finally figured out a sustainable schedule, and updates have been going out in the app/Play Store. However, they didn't feel "blog-worthy." And let's be honest: once you miss one update, it’s surprisingly easy to miss the next one too.

Anyway, here’s what’s changed.

More fireworks

I added more fireworks on level completion.

It sounds trivial when I write it out like that. But you can never have too many fireworks.

Scene transitions

I also added scene transitions between screens.

This is another one of those trivial changes. But, it makes the game feel less like a collection of screens and more like... well, a game.

Level select now opens at your highest unlocked level

The level selection screen now opens on the page with your highest unlocked level.

This is mostly just convenience (less clicking is always a win). This wasnt so much of an issue when it was just 3 screens but as I add themes and more levels to the game, this will make it much easier to navigate.

6 more levels

Since there are 12 levels on the level selection screen, ensuring each theme has a multiple of 12 levels makes the transitions much smoother. It's a little design hack that's going to make it much easier to add themes. But, you get 6 more levels while you wait for the next update.

Behind the scenes: refactoring + automated tests

Alongside the visible changes, I’ve been refactoring the code and adding automated tests to make themes possible without turning every future change into a risky one.

There was a point where I realised I was spending more time manually clicking through the app to make sure I hadn't broken anything than I was actually building new features. You know the drill: change one line of code, spend 20 minutes tapping screens to ensure everything still works.

It was exhausting. And frankly, it was boring. And worst of all, it was leading me to procrastinate.

Automated tests give me the confidence to move fast without that constant fear that I'm breaking something. If you’ve ever maintained a side project alone, you probably know exactly what I mean.

What theme should I build next?

I’ve been promising this for a while, and it’s finally (almost) here. I’ve made nearly all the changes needed to support more themes. I am just testing it out before I release it to everyone.

The frontrunner for me right now is body parts. It feels like a good “kid vocabulary” theme, and I think it could lead to levels that are fun without being too hard.

But, I need your help. If you were picking a theme, what would you want to see?

Body parts
Animals
Nature
Sports
Transportation
In the house
Action words
Something else

What would you pick (and why)?

Get WordXplorer

WordXplorer is available on the iOS App Store

Want to try before you buy? Check out our web demo

Thank you for being a part of this journey with me! I'm eager to hear your thoughts and feedback. Stay tuned for more updates!

Story Points Aren't the Problem

Sat, 26 Jul 2025 00:00:00 GMT

Like many developers, I hate story pointing.

It feels like I’ve wasted years of my life in sprint planning sessions that spiral into arguments over whether something is a 2 or a 3. I’ve also sat through too many sprint planning sessions watching teams treat story points as time estimates, and walk away with no more clarity than when they started.

It all feels likes a performance that gives ~~management~~ everyone a false sense of control.

In fact, some people just do away with story points altogether, and I get it. I was once in that camp too.

But, what I if told you

story points aren't the problem.

I’ve noticed three common mistakes that make story points and the whole sprint planning exercise feel like a giant waste of time. Let's see what they are and how we can fix them to make story-pointing not suck.

Mistake #1: Treating Story Points as a Proxy for Time

How often have you heard this in a sprint planning session -

This should take 1 week, so… five story points?

That’s not how story points work. They’re not about time.

A 3-point story might take one day or more than a week. I know you dont want to hear it but it doesn't matter.

Story points should reflect the complexity of the task.

Here’s a better way to think about them:

1 Point

Potential Traits: No unknowns, low risk, minimal code changes.

Examples

Adding logs to existing code
Trivial changes behind a feature flag
Cleaning up a simple feature flag
Mechanical refactoring

2 Points

Potential Traits: Low risk, some minor unknowns, small test updates.

Examples

Simple changes behind a feature flag
Creating a new dashboard with existing data
Cleaning up a complex feature flag

3 Points

Potential Traits: Some unknowns, moderate risk, might require coordination with others.

Examples

Fixing a bug with a known root cause
New functionality that can be feature flagged cleanly
Work that involves coordination with another developer

5 Points

Potential traits: Some unknowns, large code changes, lots of new tests, external dependencies

Examples

Technical investigation for new features or bugs
Work that's difficult to feature flag
Cross-team coordination

These are good candidates to split into smaller tickets once the investigation is done.

8 Points

Potential traits: Many unknowns, risky changes, hard to estimate confidently.

If you’re estimating something at 8 points, you probably need a spike first. Timebox it, then use what you’ve learned to create smaller, pointable stories.

Note: You can download the full sized infographic from Printable Infographic

Mistake #2: Estimating in Isolation

Ever had a product owner or a tech lead show up to planning with stories already estimated?

Estimation is a team sport. Different people catch different risks, assumptions, and edge cases. Getting everyone involved builds shared understanding and better team cohesion.

The number matters less than the conversation.

Here’s what to do:

The feature lead fleshes out the ticket ahead of planning.
They give a 30-second overview during the session and answer questions.
- No need to dive into every detail - but enough for the team to understand the why, the approach, and have the confidence to estimate complexity.
Then use Planning Poker to uncover different perspectives.

Mistake #3: Arguing Over 2 vs 3 Points

You know the moment. One person says it’s a 2. Another insists it’s a 3. Suddenly, you’re 20 minutes deep into a conversation that doesn’t matter.

You’re optimizing for precision in a system designed for approximation.

That’s not just wasteful — it completely misses the point (pun unintended).

Timebox these debates. If you can't agree in 1-2 minutes, pick the higher number and move on. It's not worth derailing the whole session.

However, if there’s a big delta — say, someone thinks it’s a 2 and someone else thinks it’s a 5 — that is worth unpacking. Someone’s probably missing something.

Final Thoughts

Story points aren't about precision. They're about shared clarity.

Used well, they build shared context. Used poorly, they fuel endless debates.

So next time you're estimating ask yourself:

Do we actually understand the scope, complexity, and purpose of this work?

If the answer’s yes, the number doesn't matter.

What’s your biggest frustration with story points — and how have you worked around it?

Drop a comment and send this to someone who’s still fighting over 2 vs 3.

WordXplorer Update #9: Save your guesses

Sun, 08 Jun 2025 00:00:00 GMT

You can see all the related updates here

Save your guesses

Your guesses are now saved, letting you take as long as you need to solve each level without starting over.

When you return to a level, you’ll see all your previous guesses, allowing you to continue right where you left off. Once you successfully complete a level, all your guesses for that puzzle will be cleared, giving you a fresh start when you decide to replay it.

Here's how it works in action:

Bug Fixes

I've resolved the issue where the keyboard colour changed to white after moving to the next level.
I've also fixed the problem where the latest level showed up as locked when you went back to the level selection screen after finishing a level.

Get WordXplorer

WordXplorer is available on the iOS App Store

Want to try before you buy? Check out our web demo

Thank you for being a part of this journey with me! I'm eager to hear your thoughts and feedback. Stay tuned for more updates!

WordXplorer Update #8: New Hint System

Sat, 10 May 2025 00:00:00 GMT

You can see all the related updates here

New Hint System

We're excited to introduce our new hint system! This feature helps players when they're stuck, making the game more accessible while still maintaining the challenge.

The hint system provides contextual clues about the word.

Here's how the hints look when locked and unlocked:

The hint popup at the start of the game, showing all hints are locked	The hint popup after 2 hints have been unlocked, showing the available clues

And here's how it works in action:

These clues help kids think about the word in a different way, making the game both educational and fun. They can use them strategically to learn and improve their word-solving skills.

Get WordXplorer

WordXplorer is available on the iOS App Store

Want to try before you buy? Check out our web demo

Thank you for being a part of this journey with me! I'm eager to hear your thoughts and feedback. Stay tuned for more updates!

Offset vs Cursor Based Pagination

Mon, 07 Apr 2025 00:00:00 GMT

Introduction

SQL pagination helps manage large datasets by breaking them into smaller, more manageable chunks called 'pages.' It prevents overwhelming applications by retrieving data one page at a time, ensuring smoother performance and a better user experience.

In this article, I'll discuss two primary SQL pagination methods—offset and cursor-based—and explore an advanced technique for efficiently handling large datasets, highlighting their specific use cases and benefits.

Offset Pagination

Offset pagination involves skipping a specified number of rows and then taking a fixed number of rows, allowing for flexible data retrieval.

Example

Here's a typical query using offset pagination:

SELECT *         
FROM product        
WHERE category = 1        
ORDER BY id         
LIMIT @pageSize         
OFFSET $offset;

The LIMIT clause defines how many rows to return, while OFFSET skips a specified number of rows. ORDER BY ensures results are consistent.

Typically, pageSize and offset are set based on user input or application logic to control pagination dynamically. For example, if pageSize is 100 and offset is 200, the query retrieves rows 200-300.

Advantages

Offset pagination allows you to jump directly to a specific set of records, which is useful for applications requiring quick access to specific data or "go to page X" functionality. For instance, you can easily access a specific range like 3000-3100.

It is easier to implement, making it useful for smaller systems or static datasets like blog archives or product lists.

Disadvantages

Offset pagination requires scanning all preceding rows to find the starting point. This can be inefficient and slow as the dataset grows. Performance degrades with larger datasets, as scanning more rows leads to slower response times.

For example, in a query like SELECT * FROM product ORDER BY id LIMIT 100 OFFSET 100000, Postgres scans and discards 100,000 rows even though only 100 are needed.

While offset-based pagination is common in legacy systems, its utility in modern systems may be limited compared to cursor-based pagination.

Cursor-based Pagination

Unlike offset pagination, cursor-based pagination fetches results using a unique identifier (or a combination of columns), avoiding the need to skip rows.

Example

Here's how you might implement cursor-based pagination:

SELECT *         
FROM product         
WHERE id > $lastId        
    AND category = 1        
ORDER BY id         
LIMIT $pageSize;

Notice that, unlike the previous example, this query doesn't use OFFSET. Instead, we keep track of the id of the last record retrieved from the previous page and use it in the WHERE clause to fetch the next set of records.

To maintain reliable pagination, it's essential to ensure the cursor column is unique and immutable, as changes could disrupt the order of results. A good candidate is a primary key ID or a CreatedTimestamp column.

Advantages

Cursor-based pagination is generally more efficient, as it avoids scanning and discarding rows. Instead, it directly jumps to records based on the cursor value. This approach remains efficient even for large offsets because the database can quickly use an index on the cursor column to find the starting point.

Cursor-based pagination provides stable results even if new records are inserted or deleted between page requests. Each page contains the expected set of records based on the cursor value.

Disadvantages

Cursor-based pagination requires sequential page traversal and is more complex to implement because you must track the cursor value in your application code. This might be less convenient for users who want to navigate directly to a specific page.

Note: However, we can avoid the need for sequential page traversal by using PageInfo/PageCursor in GraphQL.

We need to be mindful of IDOR (Insecure Direct Object References). If IDs are sensitive, we should encrypt cursor values with a random salt.

It can become quite complex if you need extra features like sorting on multiple columns, etc.

Advanced Cursor Pagination Techniques

When dealing with extremely large datasets, an advanced cursor-based technique can further optimise performance.

In my experience using the basic cursor-based example on a table with 163 million rows, where only 300K rows met the WHERE clause criteria, the query timed out even with a LIMIT of 1000. This occurred because the query had to scan too many rows before finding 1000 that matched the criteria.

Now, you might wonder why it would need to scan so many rows if you have an index. The index's benefit is that it lets the database quickly locate the starting point. Imagine that the first record is in row 1. Now, the second record is after 1 million rows. To reach the limit of 1000, at least 1 million rows will need to be scanned. Even though there is an index, it can (and probably will) result in a timeout because it requires scanning many non-matching rows to find the ones that match.

In such scenarios, it's crucial to limit the number of rows scanned during each query execution. This can be achieved by adding a constraint that ensures efficient data retrieval, even if the LIMIT is not fully met.

Example

Here's an updated query:

SELECT *         
FROM product         
WHERE id > $lastId        
    AND id <= $clampId        
    AND category = 1        
ORDER BY id         
LIMIT $pageSize;

The clampId serves as an upper boundary, calculated as lastId plus a predefined range, to limit the number of rows scanned per query execution.

For instance, if lastId is 1000 and the scan limit is 10,000 rows, set clampId to 11,000. The LIMIT remains 1,000, ensuring immediate return if 1,000 matches are found or scanning at most 10,000 rows.

By clamping the range, we can significantly reduce query execution time, making it feasible to handle large datasets without overwhelming the system.

Using Non-sequential Identifiers

While in the examples, the id is assumed to be numeric and sequential, it doesn't need to be to implement cursor-based pagination. We can, for instance, combine multiple fields, e.g., <last_updated_at> for sorting and <last_id> as a UUID to get the last item on the current page.

SELECT *       
FROM product      
WHERE (last_updated_at < $lastUpdatedAt)      
 OR (last_updated_at = $lastUpdatedAt AND last_id > $lastId)      
ORDER BY last_updated_at DESC, last_id      
LIMIT $pageSize;

Conclusion

Choosing the right pagination approach ensures optimal application performance and user satisfaction, regardless of dataset size.

While offset pagination is simpler to implement, it suffers from significant performance degradation at scale. In contrast, cursor pagination maintains consistent performance regardless of page depth.

However, offset-based pagination allows us to arbitrarily jump to any page. With cursor pagination, we have to traverse pages sequentially or use more complex techniques.

The choice between these two approaches ultimately depends on your use case. Choose cursor pagination for high-performance needs with large datasets. Opt for offset pagination when dataset size is manageable, and random page navigation is required.

WordXplorer #7: New Video & Food Theme

Tue, 22 Oct 2024 00:00:00 GMT

You can see all the related updates here

I hope you’re having an awesome day! Since the last post, we’ve been hard at work, appeasing the Apple gods to ensure our game is ready for the App Store.

And guess what? I’m thrilled to announce that our game has been approved.

🎥 New Video Alert!

I am excited to share a sneak preview of our brand-new video. You can catch this exclusive glimpse on our product page. It’s a taste of the adventure that awaits!

🎨 Exciting New Theme

To make things fun and engaging for kids, we’ve decided to theme the words around “Food Items.” There are a few reasons we have chosen this theme as the first one.

We can easily create 25-30 exciting levels for launch.
Kids are familiar with food items and having all words around this central theme should make it easy for them to get started.
Most importantly, we believe this theme will be a hit with children.

💰 Special Preorder Pricing

You can preorder the game for just USD 3.99. Apple will use this base price and adjust it for your region.

Remember, once we launch on December 1st, the price will increase to USD 4.99. So, why wait? Secure your copy now!

🛒 How to Preorder

Pre-ordering is simple and ensures you’re among the first to experience the game:

Visit the game’s product page on the App Store.
Click on the “Preorder” button.
Follow the prompts to complete your preorder. By pre-ordering, you lock in the special price and guarantee immediate access on launch day!

Rest assured, you will only be charged once the game officially launches on December 1st. And if you change your mind(I hope you don’t), you can cancel your preorder anytime before launch without penalty.

For more details, feel free to check out Apple’s Preorder documentation.

📱 Google Play Progress

Exciting news for our Android fans! I have a working proof of concept for the game on Android devices.

While bringing the game to Google Play is definitely on our radar, our primary focus is ensuring a smooth and successful launch on the App Store.

Rest assured, expanding to Android is part of our plans. We appreciate your patience and support as we prioritise the App Store release. Stay tuned for more updates!

🕹️ Last Chance for Playable Build

This is your final opportunity to check out the latest update to our Playable Web Build or TestFlight build. Your feedback would mean the world to us! If you’re eager to have the full experience, just let me know, and I’ll send you a TestFlight invite immediately. 😊

🚀 What’s Next

With a hard deadline in sight, we’re focused on adding those final touches to the game. We’re also building out the concept of theming levels into the gameplay to ensure a smooth experience for launch day. I am also trying to get in the Apple Small Business program to reduce the percentage of commission that they charge.

Know someone who’d love to try the game before its official release? ~~Share this form with them—they’ll thank you!! ✨~~

Update 26th December 2024: You can now download the game.

Does your child have a favourite four-letter food they’d love to see in WordXplorer? Let me know, and I’ll do my best to add it to the game!

Thank you for joining us on this journey. I can’t wait for you to dive into the game and share your thoughts!

Fun with (Feature) Flags

Fri, 06 Sep 2024 00:00:00 GMT

Feature flags give developers the ability to turn features on or off without deploying new code. This flexibility is key for managing the release of new features while allowing for controlled and incremental deployments.

I still have conversations with several teams that are using development methods that don’t include feature flags. Some of them want to move to feature flags but are unsure how to start while others have never heard of them or don't think it's worth adopting.

Let’s explore how feature flags work, and their pros and cons compared to some other approaches.

Note: This is loosely based on a presentation I had given at FirstAML.

Other Approaches

Before diving into feature flags, let’s look at some ~~traditional~~ ahem alternative approaches I’ve seen teams use.

To better understand the differences, let’s consider a scenario where you’re working on a new feature that will allow users to edit the title of their uploaded documents.

This feature requires changes to the frontend, backend, and database and can be broken down into several tasks:

Update the database schema to store the new title.
Update the backend API to accept the new title.
Update the backend to save the new title.
Add an audit trail for the updates.
Update the backend to return the new title.
Update the frontend to display the new title.
Update the frontend to allow users to edit the title.
Add validation to the backend to ensure the new title is valid.
Add validation to the frontend to ensure the new title is valid.

Approach 1: Feature Branches

A long, long time ago, when SVN was a thing (and even much later) most teams used Feature Branches to manage new features. Typically, each feature would be developed on a separate branch, tested, and then merged into the main branch.

In our example, you would create a branch for the new title feature, and each task would be developed on this branch. Once all tasks are complete, the branch would be merged into main.

Feature branches were popular because they were straightforward to use and possibly because that was the best we had at that time. They still work well for small-scale projects.

However, in larger teams, feature branches can create technical debt. Tasks may overlap, and keeping branches in sync becomes more challenging, slowing down the development process.

Here are some other downsides:

Since code in feature branches must be fully completed before merging, it often leads to large, complex pull requests with significant changes.
Common changes like the same typo being fixed in two different branches can cause conflicts.
Working on features in separate branches can hinder collaboration.
Rolling a change back is difficult due to the intertwined nature of multiple features in the main branch.
Moving on to a new feature before the previous one is merged can result in forgotten branches and ToDo's.
As branches are long-lived and diverge over time, refactoring becomes challenging.
Continuous Integration/Continuous Deployment (CI/CD) becomes difficult due to the fragmented nature of feature branches.

Most teams I know start by using feature branches when they are just 1 or 2 developers. But as the team grows, managing multiple branches becomes increasingly complex, leading to merge conflicts and lower productivity.

Alternative 2: Git Flow

An evolution of feature branches is Git Flow, a branching model I’ve also used with success for certain projects.

Git Flow uses two main branches (main and develop). Feature branches are created off develop, and once a feature is stable, it is merged into develop. When develop is stable, it is merged into main, which is always production-ready. A release branch is created from main for each release and hotfix branches are created to fix production issues.

In our example, you would create one or more feature branches off develop for the new title feature. Once the feature is complete, it would be merged into develop. When develop is stable, it would be merged into main.

Git Flow offers several advantages compared to Feature Branches.

It ensures the main branch remains stable and production-ready, aiding in scheduled release cycles.
It supports different versions, useful for desktop and mobile apps requiring hotfixes or patches.
It works well for Waterfall or Waterfall-Pretending-to-be-Agile methodologies.

But it’s not without its downsides.

Merge conflicts can still occur in the develop branch.
Multiple features might be coupled together, preventing the release of any feature until all are complete.
Continuous Deployment (CD) becomes challenging as it requires all features in the develop branch to be stable before merging into main.

In my experience, Git Flow is less effective for SaaS and applications where supporting older versions isn’t necessary.

Feature Flags

With feature flags, you can deploy code at any time, keeping features behind a switch that you control. This enables a smoother, more flexible development and release process.

In its simplest form, a boolean flag determines whether a feature is active or not. This flag can be toggled on or off without redeploying the code.

Pros of Feature Flags

Production code closely mirrors the development version, reducing integration issues.
Allows for smaller, isolated changes to be merged, minimizing merge conflict risks.
Features can be released in line with marketing or launch timelines.
Smaller pull requests make bug fixes easier, with more confidence in the changes.
They allow for A/B testing and canary releases, where a feature is gradually rolled out to a subset of users.
It acts as a kill switch, allowing you to quickly turn off a feature if it causes issues in production.
Turning a feature on for users carries low risk since it has already been thoroughly tested in a controlled environment.
Shipping the features to users is a trivial config change.
Easy to sunset features
Frontend and backend teams can work in parallel since the feature is not live until the flag is activated.

Cons of Feature Flags

While feature flags offer many benefits, they come with their own set of challenges:

The codebase accumulates immediate technical debt with numerous if-else statements and duplicated code paths.
You have to test both the flag-on and flag-off paths.
You have to remember to remove the flag and associated code once the feature is fully deployed.
Inter-dependencies between flags can lead to complex configurations.
Feature flags on the client side may reveal in-development features.
It is difficult to apply flags for specific users for changes available before login.
Managing feature flags at scale can become complex, particularly when dealing with numerous flags across different environments and user segments. Effective management requires robust tooling and practices to keep configurations organized and manageable. However, tools like LaunchDarkly can streamline this process, making it easy to track and control your flags.

When to Use Feature Flags

Alright, let's play a little game. I'll list a few scenarios, and you tell me if you should use feature flags or not...

Low risk minor bug fix
Copy changes
New Feature
Adding functionality to an existing feature
Removing a feature
Refactor

This was a trick question.

Feature flags are your safety net for almost every scenario above.

The only exception is refactoring — where your automated tests should catch any issue. You are writing tests right?

Feature Flags in Practice

To use feature flags, start with a configuration per environment that defines the flags and their state. This could be a simple JSON file or a more complex system like LaunchDarkly.

Here’s a basic config example in JSON:

{
  "FeatureFlags": {
    "feature1": {
      "enabled": true
    },
    "feature2": {
      "enabled": false
    }
  }
}

Having a JSON configuration file per environment, allows you to define and manage feature flags across different environments. By toggling the enabled status, you can control feature visibility and rollout without redeploying code.

Initially, the flag would be off in all environments - dev, QA and prod. This allows you to develop the feature in isolation.

The code has if-else statements to check if the feature is enabled or not.

// Check if the feature flag is enabled before executing new logic
if(_featureFlagProvider.IsFeatureEnabled(AvailableFlags.Feature1))
{
    // new logic
}
else
{
    // old logic
}

Note: Developing while the feature is on the dev environment can impact other devs.

Once the feature is ready, you can turn the flag on in the dev and test environment for QA testing without exposing it to end users.

After thorough testing, you can activate the feature flag in production. The feature is now live, but since it was already tested in a controlled environment, the risk is minimal.

Finally, after the feature has been successfully deployed, and you’re confident it’s stable, it’s important to remove the feature flag and any associated code to prevent technical debt.

In our example, you would create a feature flag for the new title feature. Each task would be developed behind a feature flag in isolated branches. As each task is completed, it would be merged into the main branch. Once all tasks are complete, the feature flag would be turned on in the test environment for QA testing. After thorough testing, the feature flag would be activated in production, making the feature live.

Best Practices with Feature Flags

While embracing duplication might seem counterintuitive, it’s crucial for managing feature flags effectively. This is not the time to worry about keeping your code DRY. Duplication makes it easier to remove flags later.
Optimize for removal. Code reviews of feature flag removal should be trivial and the reviewer should be just seeing deleted code.
Define flags with enums or other types rather than strings to simplify management.
Set up a process to regularly audit and remove outdated flags.
Maintain a shared configuration for flags affecting both backend (BE) and frontend (FE) teams.
Allow turning flags on/off using a FE widget tied to a user.
Consider creating tools to manage feature flags effectively. Automation can help with flag updates and removal.
- A widget that allows a developer/QA to toggle flags on/off just for themselves in dev/test environments is immensely useful.
- At FirstAML, I developed an open-source helper app that simplified updating feature flag files from the console.
Abstract the feature flag logic from the rest of the codebase to simplify future changes

Removal Strategies

Old feature flags can clutter your codebase and create headaches down the line. By implementing strategic removal practices, you can keep your code clean and efficient.

Here are a few strategies to consider:

Add a removal task when you introduce a feature flag.
Add expiration dates to feature flags that either fail a test once expired or alert the team without failing.
Limit the number of active feature flags in the system so that before adding a new one you have to clean up an older one.

Conclusion: Are Feature Flags Right for You?

Feature flags are a powerful tool that should be present in every modern teams toolkit. They offer flexibility, reduce risk, and allow for a more controlled release process. Despite their challenges, they provide significant benefits that often outweigh the drawbacks.

Feature flags can be particularly advantageous for larger teams or projects with multiple stages of development. For smaller teams or projects, they help manage risk and allow for more flexible deployment strategies, reducing the chances of introducing bugs into production.

When I joined FirstAML, (even though we were just 2 developers at the time) one of the first things I built was a basic feature flag system. This allowed us to test features in isolation, minimizing risks and enhancing our development process by enabling more controlled releases. They’re not just for big teams — they’re for anyone who values agility and controlled risk.

If you’re not already using feature flags, I highly recommend exploring them. They can be a game-changer for your development process, enabling you to release features with confidence and control.

For further reading, check out Martin Fowler’s article on feature toggles.

WordXplorer #6: New Look, Major Fixes & App Store News

Mon, 02 Sep 2024 00:00:00 GMT

You can see all the related updates here

Since we last spoke, it’s been full steam ahead with bug fixes and getting the game ready for the App Store! We’re thrilled to be just around the corner from giving your kids a fun and educational experience they’ll love!"

New Name and Icon

The name of the game has been updated from wordwhiz to WordXplorer.

We’ve replaced the generic grey boxes with a vibrant, colorful icon that better reflects the fun and educational nature of WordXplorer.

Bugfixes

Kids are great testers; they always manage to do things you’d never expect. So, what did they discover this time?

Previously, pressing keyboard keys while a popup was displayed could cause issues, as you couldn’t see the word you were entering. We’ve now disabled the keyboard when a popup is shown to prevent this.
You could also press keyboard keys after completing a level, but before starting the next. This led to unintended effects, like having a prefilled row when the new level started. The keyboard is now disabled when the level is complete.
That was not the only problem when a level ended. Did you know, you could press the Next Level button before the popup finished? Unsurprisingly, this caused issues. Now, the next level button only appears after the popup has fully disappeared. It also lets the kids enjoy the fireworks for a tad more time.

We also fixed feedback about the Next Level button not being centered on the iPad.

These fixes ensure that your gameplay is smooth and frustration-free, with no more accidental key presses or misaligned buttons on the iPad, making your experience more enjoyable.

Infrastructural changes

To generate TestFlight and web builds, I have been using a combination of GitHub Actions, GameCI, and Fastlane.

I’m excited to share that we’re now able to create builds ready for the App Store release. We’re making solid progress and are committed to delivering the final version of the game soon.

Fastlane can update the App Store metadata, but I haven’t managed to get it working yet. It’s on my list to figure out. For now, we are manually updating the metadata in the portal. This isn’t ideal, but it is a minor issue that won’t affect our overall progress.

Updating Metadata for the App Store

To get the game ready for the App Store, a lot of metadata needs to be added. This includes the app name, subtitle, and a description.

We also need to upload at least three screenshots for various device form factors.

Here's a sneak preview

These may end up in the final version, but we are not sure yet.

Submitting for review

Once we updated all the metadata, we decided to submit the game for an App Store review. The intention was not to get the current version released but to ensure we can go through the approval process and be ready when the final version is prepared.

We’ve encountered some challenges with Apple's approval process, but we're addressing them head-on.

The 1st hurdle was related to analytics and data capturing. This has been easy enough to address as we are not capturing any PII, and the data that we capture for analytics is aggregated so we don't know anything about any specific individual.

The next challenge we’re facing is Apple’s concern with our use of "Wordle" in the metadata and screenshots. Apple has guidelines to prevent copycat games and apparently using the Wordle goes against it. This was unexpected as we could see other games in the app store using Wordle. The plan is to resolve this by updating the metadata to remove any references to "Wordle" and providing a small blurb of why it's not just a copy.

Hopefully, with the changes we’re making, Apple will see that our game is unique and far from a copycat.

What's Next

Aside from getting a build that adheres to Apple’s guidelines and squashing bugs, we’re working on determining the price point and considering the option of preorders.

Based on survey feedback, we’re leaning towards a price point of NZD 5.99 / USD 2.99 / INR 299 for approximately 20-25 levels.

We’re also contemplating theming the words in the game. Two themes we’re considering are food and animals. If we proceed with this, we plan to release one theme now and the other later. Do you have a preference for which theme we should choose first?

Playable Build

We’re excited for you to test out the Playable Web Build. Share your feedback, and if you want the full experience, just ask for a TestFlight invite—I’ll send it over right away!. 😊

Know someone who’d love to try the game before its official release? ~~Share this form with them—they’ll thank you!! ✨~~

Update 26th December 2024: You can now download the game.

Does your child have a favourite word they’d love to see in WordXplorer? Let me know, and I’ll do my best to add it to the game!

Thank you for being a part of this journey with me! I’m eager to hear your thoughts and feedback. Stay tuned for more updates!

WordXplorer #5: UI Refresh

Mon, 19 Aug 2024 00:00:00 GMT

You can see all the related updates here

Here's whats new since the last update

Updated game screen

The main game screen now has more negative space, giving it a cleaner look. However, this change means the keyboard buttons are smaller. Give it a try and let me know how it feels!

Before	After

Improved Popups

Popups are no longer boring grey rectangles. They now match the color scheme of the rest of the game, making everything look more cohesive.

Enhanced Fireworks

Last time, I added support for fireworks, but they were a bit hard to see. Now, the screen dims after you complete a level, so the fireworks really stand out. With explosive sound effects, it creates a much better experience!

Before	After

Privacy Policy

To prepare the game for the App Store, I needed a privacy policy. Luckily, I’m not capturing any personal information, so it was easy to create one using ChatGPT. If you’re interested, you can check it out here

Playable Build

~~Test it out by going to Playable Web Build and let me know what you think about the game so far. The TestFlight app is still the best way to play, so let me know if you want an invitation. 😊~~

Update 26th December 2024: You can now download the game.

Does your child have a favourite word they’d love to see in the game? Let me know, and I might add it!

Thank you all for your support and patience. Stay tuned for more updates!

WordXplorer #4: Levels, Fireworks & Fresh New Look

Mon, 05 Aug 2024 00:00:00 GMT

You can see all the related updates here

It's been a while since the last update, and I wanted to tell you what's been happening. I wanted to get this game out by now, but life events got in the way.

What happened

The partnership that I had for the first game ended. This meant I had to setup new accounts for various third-party services and redo some of the infrastructural work, which took some time.

After your feedback and some live playtests, it was clear that the game needed something more. Without someone else to help, I was getting overwhelmed with my day job and all the things that needed to be done for wordxplorer. Thankfully, my cousin Manjari stepped in to help with the creative side of things.

What's New

Color Matters

Let's face it: The original colours weren't very appealing. The first thing Manjari changed after joining was updating the colours. But don't take my word for it, see for yourself:

Before	After

Fireworks

Previously, when you found the right word, there was no celebration - just a plain popup that quickly disappeared. Now, there are fireworks and explosions to celebrate your victory.

Deterministic Levels

The random word selection felt like playing the lottery. Now, there are levels and they are locked! After you complete one, the next one is unlocked, providing a sense of progress. Plus, your progress is saved, so you don’t have to start from Level 1 every time.

Web Build

For those who didn’t want to install TestFlight or were not on an Apple device, you can now try the game on your browser. The TestFlight app is still the best way to play, so let me know if you want an invite. 😊

~~Test it out by going to Playable Web Build and let me know what you think about the game so far.~~

Update 26th December 2024: You can now download the game.

Does your child have a favourite word they’d love to see in the game? Let me know, and I might add it!

Thank you all for your support and patience. Stay tuned for more updates!

Verifying Method Calls within a class using Mockito Spies

Mon, 05 Aug 2024 00:00:00 GMT

in order to get confidence, when one method calls another within the same class with just 1 or more additional parameters, we could write the same test for both the methods. This would lead to a lot of duplicated tests and a cluttered test suite.

However, Mockito spies can help us in this scenario.

Scenario

You want to write tests for a class that contains two public methods, one of which is essentially overloading the other and calling it without adding any additional logic.

Here's a simplified example to illustrate this:

public class Service {
    public int getTotalPrice(int quantity) {
        // some other code like error checking, etc
        return 5 * quantity;
        
    }

    public int getTotalPrice() {
        return getTotalPrice(1);
    }
}

In the above example, the getTotalPrice() method without parameters calls the overloaded getTotalPrice(int quantity) method, supplying a default value.

Enter the World of Spies

Here's where Mockito spies come into the picture.

A spy acts as a wrapper around a real object, allowing us to override specific methods with mock behaviour while leaving others intact. You can use this functionality to verify the invocation of an actual method on an object.

Let's see how you can simplify your tests by using Mockito spies

public class MyTests {
    @Test
    public void test() {
        Service spy = Mockito.spy(new Service());
        spy.getTotalPrice();
        verify(spy).getTotalPrice(1);
    }

    // more tests that test `getTotalPrice(int quantity)`
}

Let's break this down:

Service spy = Mockito.spy(new Service()): Create a spy object for Service.
spy.getTotalPrice(): Invoke the getTotalPrice method on the spy object.
verify(spy).getTotalPrice(1): Verify that the overloaded method is invoked on the spy object.

If the overloaded method is not called, then the test would fail, alerting us to a potential issue.

Conclusion

Testing every possible combination of method calls, not only consumes valuable time but also clutters your test suite with redundant tests.

Mockito spies offer a solution to this problem, allowing you to verify method interactions directly, thus focusing on the behavior rather than the implementation.

However, it's essential to use Mockito spies judiciously. Spies should primarily be used when you're testing a class's external behavior and its interactions with other classes or methods within itself. Overusing spies can lead to tests that are overly focused on the internal workings of a class, potentially making your tests brittle and less focused on the actual outcomes.

Happy testing, and may your code always perform as intended, both now and in the future.

WordXplorer #3: 100 Words, Help Button & Roadmap

Sat, 03 Feb 2024 00:00:00 GMT

You can see all the related updates here

Those of you who downloaded the 1st early access version might have noticed an update in the test flight app over the holidays 🎉

🚀 More Words, More Fun

I am thrilled to announce that the game now boasts a whopping 100 words! 📬

📜 Introducing the Help Button

Say goodbye to confusion! Explore the newly added Help Button right on the game screen. No need to restart the app — clarify the colour's meanings and game rules instantly

📬 Public Roadmap Unveiled

Your voice matters! Check out the new public roadmap, your hub for suggesting and voting on new features.

🔮 What's Next

This marks the final free version. We will soon be on the app store as a paid game.

Update 26th December 2024: You can now download the game.

Does your child have a favorite word they would like to see in the game? Let me know

Ankur Sheel

WordXplorer Update 14

New Theme: Animals - 24 New Levels

Clearer UI and Friendlier Copy

Cleaner MonoBehaviours

What's Next

Become a Beta Tester

Get WordXplorer

Defining Good: Why Your Engineering Team Needs Testing Guidelines

Core Testing Philosophies

Test Both Sides of Your Feature Flags

Optimize for Readability over DRY

Test names should convey the behaviour

Keep Flag Logic Out of Parameterized Tests

Structure every test as Arrange → Act → Assert

Leave Private Methods Alone

No branching in tests

Avoid spies

Use test doubles in integration tests, not mocks

Setup

Keep Setup Code Relevant to the Assertion

Start from the minimum for database-dependent tests

Assertions

Assert one concept per test

Assert on properties, not object equality

Use Assert.Multiple for multiple assertions

Verify what matters, ignore what doesn't

A starting point, not a finish line

Startup versus Big Tech: The Good, the Bad, and the Ugly

Startups: The Good

Ready or Not: You learn fast

Visible Impact

You know everyone.

Startups: The Bad

Learning is Self Directed

Compensation is… aspirational

Startups: The Ugly

Money Problems

Most of them fail

Big Tech: The good

Career rocket fuel

You learn a different kind of discipline

The money

Big Tech: The Bad

A small cog in a big machine

Everything takes longer

Growth can plateau

Big Tech: The Ugly

Performance reviews create strange incentive

Switching Directions

What would I do?

So which should you choose?

Conclusion

WordXplorer Update 13: Updated Flip Animation

Flip Animation Overhaul

Code Cleanup and Unity Upgrade

What's Next

Become a Beta Tester

Get WordXplorer

Rolling Your Own Dependency Injection in Unity

The Alternatives (And Why They Fall Short)

Drag-and-Drop in the Editor

Querying the Scene

Singletons

Unity-Specific DI Frameworks

What is Dependency Injection?

Why Does Unity Make DI Awkward?

The Solution

Step 1: Add the NuGet Packages

Step 2: The DependencyHelper

Step 3: Inherit from InjectableMonoBehaviour

Step 4: The Service Registry

Step 5: Watch the Lifecycle Order

Isn't This the Service Locator Anti-Pattern?

Was It Worth It?

WordXplorer Update 12: Demo Build & Teacher Feedback

Automated Screenshot Capture

Teacher Approved Feedback

Demo Build Updates

What's Next?

Use `Assert.Multiple` for multiple assertions