Ankur Sheel

WordXplorer Update 11

Thu, 05 Feb 2026 00:00:00 GMT

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

Level Up Your Pull Requests: The Value of Individual Commits

Mon, 27 Nov 2023 00:00:00 GMT

This is an edited version of an article I originally wrote for the internal blog at Atlassian.

As a Pull Request(PR) reviewer, my main goal is to be as confident as possible about the outcomes once the PR gets merged. To accomplish this, I want to be able to answer 3 questions:

Do these changes fulfil the requirements?
Do these changes improve the current state?
Could these changes potentially lead to an incident?

Achieving a high level of confidence often proves challenging when dealing with a PR that consists of a single commit with a large diff.

If you've ever received such a PR, you've likely stared at it, wondering where to begin. This confusion is often followed by your decision to set it aside for later, only to be reminded by the author again.

What if I told you that this issue could be resolved with a minor adjustment in the way we create a PR?

Split the commit into small individual commits that make logical sense.

The key is to ensure that each commit makes sense on its own and represents a single logical change.

Why should you opt for multiple commits instead of a single large commit?

Some might argue that they review all PRs as one comprehensive diff; therefore, spending time creating smaller commits is a waste of time.

Leaving apart the fact that having smaller commits does not preclude reviewing a PR as a single diff, breaking down even a small PR into multiple, well-structured commits is still beneficial.

Clear and Understandable History

Multiple small commits create a clear and understandable history.

Just as we aim to follow the single responsibility principle in programming, we should also apply it to our commits.

Each commit should represent a single logical change. This makes it easier for any team member to understand the thought process and the steps taken to arrive at the final code.

It's similar to reading a well-structured book versus a convoluted, rambling essay.

See “What to Split into its own commit” below.

Improve Debugging and Trouble-shooting Efficiency

Small commits come to the rescue when bugs creep into the system.

With large commits, finding the issue is like searching for a needle in a haystack. However, with small commits, since each commit represents a single logical change, it's much easier to pinpoint the offending code.

Small commits also work well with tools like git-bisect, making the debugging process more efficient and less time-consuming.

Increase Code Review Efficiency

Multiple commits make code review more manageable and effective.

Reviewers can focus on a single small change at a time, ensuring a more thorough review and reducing the likelihood of overlooking potential issues. It also eases the cognitive load on the reviewer, as they don't have to grasp many changes at once, enabling them to provide more insightful feedback.

Faster Reviews

Well-structured commits provide reviewers with natural stopping points.

If it's a large PR, the reviewer will have to block a chunk of time to review it. But, with individual commits, they might be able to look at the PR in shorter blocks, leading to a faster turnaround time.

Promote Work Transparency

Multiple commits offer a transparent view of the work progress. Each commit denotes a step forward, indicating productivity and makes it easy to get preliminary reviews on WIPs.

This ability to get feedback early means that you spend less time going in the wrong direction for too long and avoid expensive rewrites.

Minimises Risk

Multiple commits help minimise the risk associated with losing work.

You always have a saved version to revert to if something goes awry. This is particularly helpful when introducing new features or making significant changes.

Enable PR Splitting

Having individual (logical unit) commits will naturally contribute to the ability to split PRs.

Reduce Annotation Needs

Smaller, well-structured commits also diminish the necessity for annotating a PR with comments to help reviewers understand it better.

Once you have commits that are logical units, it becomes easier to write commit messages that are clear and specific. This allows the reviewer to understand the progression of the changes and sometimes can offer clarity as to why certain changes in the PR were made.

Example

Note: I have blurred out the images since the code and the commit messages itself are not important.

First, Which is more straightforward to understand - A single commit message saying "fixed XYZ errors" or this commit history?

Unsurprisingly, I prefer the split commit history.

Next, compare and see which diff is simpler to review.

Note: Its the same block of code seen as combined diff view vs commit view.

Personally, even with the code blurred, I can sense that the 2nd diff is going to be easy to reason about.

It's also easy to see that although the PR might have a large diff, the actual change is relatively small.

What to Split into its own commit

Hopefully, by now, you are convinced that individual commits are beneficial.

But you might be wondering how to split a single giant commit into smaller ones.

Many types of changes should be split into separate commits. Dare I say that some of them should be their own PR?

In general, changes belong to two different types of classes:

Refactoring
- These changes are very low risk especially since most IDE’s come with automated refactoring tools.
Behavioural
- These changes require more careful reviews.

The key to breaking up a single commit into smaller commits is identifying the parts needed to deliver a ticket. Some of the more common ones include:

Refactoring
Reformatting
Deleting unused code
Test improvements
Introduction of feature flags
Functional changes
Adding Observability

Let's focus on the "Introduction of Feature Flags" as an example.

First make the change easy, then make the easy change

Kent Beck

When working on a ticket, the first step usually involves duplicating existing code and placing it behind a feature flag. This duplication should be its own commit, allowing the reviewer to focus on what has changed in the subsequent commits.

Remember, you can always squash/reorder commits using interactive rebase (git rebase -i) or cherry pick (git cherry-pick) to make a cohesive story before putting up your changes for review.

Questions

Q: Shouldn't the refactorings be their own PR?

Ideally, Yes. But, it might not be possible if you work on a legacy monolith with a considerable build time. It becomes essential to balance complexity and speed.

In this case, combining the refactoring commits into the PR made more sense. If the refactorings were more complex or had a lot of changes, it would be better to split them into their own PR.

Q: Is `fix typo in variable name` too granular?

In the above screenshot, some might argue that the "fix typo in variable name" commit should be grouped into another commit as it is too granular.

However, having it as a separate commit is valuable as it is a refactoring rather than a functional change. It allows the reviewer to quickly identify this as just a typo fix.

If it was in response to a PR review comment, having it as its own commit makes it easier for the reviewer to check that their comment has been addressed.

Q: What can you understand from “fix typo in variable name” or “rename variable and add some comments”?

Both these commits signal to the reviewer that these are not behavioural changes.

This does not mean that the reviewer should not review these commits, but it lets the reviewer know that it should not take too much cognitive load to review.

Shouldn't we have smaller PR's not smaller commits?

Yes, it would be better to have smaller PRs.

But, if your team is used to reviewing everything as 1 giant diff, it can be hard to get approval if you split a PR into smaller PRs. It can be hard for people to accept that a lot of those PRs on their own probably wont provide value but also won’t break things due to being disabled through feature flags or for other reasons.

Breaking a PR with one large commit into smaller individual commits that make logical sense provides a nice stepping stone to be able to split into smaller PR's. It is an relatively easier way to build that muscle.

Q: Isn't the PR the smallest unit to understand why a change is being made, so individual commits are useless?

In an ideal world, yes. But, it's easy to fall into the trap of making multiple changes in the same PR because it takes so much time to deploy a PR to production. Having individual commits gives us a nice balance between complexity and speed.

Taking the analogy of an article, it's like saying we don't need to have sub-headings because the essay must be consumed as one unit. The subheadings/commits make it easier to consume.

If you want your PRs to be one single commit on merge, it can be achieved by enabling squash commits on merge. After getting approval, you can also use interactive rebase to squash the commits manually.

I would still strongly suggest that there is value in keeping the individual commits (as long as each commit is a logical unit) so that you can use tools like git bisect or even eyeball the commit messages to make it easier to find the underlying culprit. Alternatively, you can merge each commit as an individual PR.

Q: Is there a middle ground between having a single commit and “too many” small ones?

Yes. You can go overboard with too many small commits, and a balance needs to be achieved.

Having smaller commits doesn't mean that you show every step or that the commits should reflect the edit history. Each commit should make logical sense on its own.

I have addressed this with the “What to split” section.

Q: Isn't it problematic to review individual commits, given they can often be part of the developer's journey of changing their mind, refactoring, and gaining insights?

Smaller commits doesn't mean you show every step; each commit should be a logical unit that provides value in production. Otherwise, it's just cruft.

Drop it or Squash it.

If the author changes their mind, how does that commit provide value to the reviewer or the system in production? The author should be using interactive rebase to squash or drop those commits before putting them up for review.

Q: Do you have any suggestions for preparing atomic commits?

Proper planning and upfront thinking of how to break the PR helps, but it is not always possible. I use interactive rebase, cherry-picking and changesets in IntelliJ liberally.

If this is something you are interested in knowing more about, let me know in the comments.

Q: What about making changes based on review comments?

Every review should be a snapshot.

Once a reviewer has reviewed your PR, you should not be making changes to commits that have been reviewed.

The (new) commits that you make to address the review comments should follow the same rules as above.

Writing a commit message like "address PR feedback" and then dumping all the requested changes in 1 commit is not helpful. TBH, even I have been guilty of doing this at times.

You dont want the reviewer to have to revisit the commits that they have already reviewed but you also want to make it easy for them to ensure that their comments have been addressed correctly.

I prefer to prefix such commits with CR:.

In Conclusion

It’s the author’s responsibility to make the code review easy for the reviewer.

While it may seem tedious to make frequent small commits and tempting to wait until all the work is completed, the advantages of small commits are significant.

However, remember that the size of a commit will depend on the context and the nature of the change.

The key is to ensure that each commit makes sense on its own and represents a single logical change.

Breaking a PR with one large commit into smaller individual commits that make logical sense provides a nice stepping stone to be able to split into smaller PR's.

Is there any reason why we shouldn't be putting in the effort to make smaller commits and writing better commit messages?

Unity CI/CD Demystified: Part 4: Deploying WebGL Builds to GitHub Pages

Wed, 07 Aug 2024 00:00:00 GMT

In Part 1, we finished the setup to start creating our CI/CD pipeline.

In Part 2, we created a workflow to run our automated tests based on some trigger events.

In Part 3, we created a reusable workflow to build the Unity project for various platforms.

In part 4, we will use our reusable workflow to deploy a WebGL build to GitHub Pages.

Start by updating your .github/workflows/main.yml file.

Job 1: Building for WebGL

This job uses our reusable workflow to generate the files needed for hosting the game on a web server.

buildForWebGL:
  name: Build for WebGL
  needs: test
  if: |
    github.event_name == 'pull_request' 
    || github.event.action == 'published' 
    || (contains(github.event.inputs.release_platform, 'release') 
          && contains(github.event.inputs.release_platform, 'web'))
  uses: ./.github/workflows/buildWithLinux.yml
  with:
    platform: WebGL
    secrets:
      UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
      UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
      UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}

needs: This step depends on the successful completion of the test job, added in Part 2.
if: Defines the conditions for this job to run.
- push to the main branch or creating a pull request against it.
- GitHub release.
- Manually trigger the workflow with the 'release' and 'web' parameters in the release_platform field.
uses:Call the reusable workflow from Part 3 with the necessary parameters, setting the platform to WebGL.

Job 2: Deploying to GitHub Pages

This job copies the WebGL artifact to the correct location for GitHub Pages. Once copied, it triggers a GitHub Pages deployment.

deployToGitHubPages:
  name: Deploy to GitHub Pages
  runs-on: ubuntu-latest
  needs: buildForWebGL
  if: |
    github.event_name == 'pull_request' 
    || github.event.action == 'published' 
    || (contains(github.event.inputs.release_platform, 'release') 
          && contains(github.event.inputs.release_platform, 'web'))
  steps:
    - name: Echo Build Version
      run: echo ${{ needs.buildForWebGL.outputs.buildVersion }}

    - name: Checkout Repository
      uses: actions/checkout@v4
      with:
        fetch-depth: 1
        lfs: false

    - name: Download WebGL Artifact
      uses: actions/download-artifact@v4
      with:
        name: build-WebGL
        path: build/WebGL

    - name: Deploy to GitHub Pages
      uses: JamesIves/github-pages-deploy-action@v4
      with:
        folder: build/WebGL/WebGL
        commit-message: Deploy
        single-commit: true

    - name: Cleanup to avoid storage limit
      uses: geekyeggo/delete-artifact@v5
      if: always()
      with:
        name: build-WebGL
        failOnError: false

needs: This job depends on the successful completion of the buildForWebGL job.
if: It follows the same conditions as the buildForWebGL job.

Next, we have a series of steps:

Echo Build Version: Prints the build version generated by the buildForWebGL job.
Checkout Repository: Checks out the code repository.
Download WebGL Artifact: Get the build-WebGL artifact produced by the buildForWebGL job and put it into the build/WebGL directory.
Deploy to GitHub Pages: Deploy the contents of the build/WebGL/WebGL folder to GitHub Pages.
Cleanup to avoid storage limit: Delete the build-WebGL artifact.

Setting up Github Pages

Once the workflow for a WebGL build is triggered, a gh_pages branch will be created. Now you can setup Github pages to showcase your game.

In the repository on GitHub, navigate to Settings -> Pages.

Set the source to Deploy from a branch and set the branch to gh-pages

Conclusion

In this part, we deployed our Unity Project to Github pages. Next, we will generate certificates for iOS deployments.

References

2023 - Q3 Retrospective

Mon, 30 Oct 2023 00:00:00 GMT

At the start of the quarter, I laid out some high-level personal goals. Here’s how I did against those goals.

Goal: Publish 3 blog posts

Result: I published 4 posts

How it went: SUCCESS

I published 4 posts.

I also refreshed an old post

Should I Rent Or Buy a House?

Goal: Publish 3 book summaries

Result: I didnt finish even a single book summary

How it went: FAILURE

I need to take out time to write a book summary a month. Maybe I should have spent some time on book summaries instead of the 4th post.

Goal: Explore ideas for a new game

Result: I settled on creating a Wordle for Kids and reached out to a few people to gauge interest.

How it went: MEH

I created a MVP for a 4 letter wordle clone. I shared a form on social media to gauge interest for a Wordle for Kids game. Although, I did not get as many responses as I would have liked, it was enough to validate that people are interested in having an app that has kid appropriate 4 letter words.

Goals for next month

Publish 3 blog posts on ankursheel.com
Publish 3 book summaries on discoveriesinbookland.com
Get WordXplorer in the hands of beta testers and get the 1st release out
Get 10 more responses to the WordXplorer form
Lose 5 kgs
25 consecutive pushups
50 consecutive squats

Unity CI/CD Demystified: Part 3: Build with Linux

Wed, 07 Aug 2024 00:00:00 GMT

In Part 1, we finished the setup to start creating our CI/CD pipeline.

In Part 2, we created a workflow to run our automated tests based on some trigger events.

In Part 3, we will create a reusable workflow to build the Unity project for various platforms.

The jobs in this workflow will run on a Linux VM.

Why Linux?

Its the cheapest box. As we will see in later posts, different platforms need a different OS for deployment. I am looking at you iOS.

Creating a new workflow definition .github/workflows/buildWithLinux.yml:

Defining the Workflow

name: Build with Linux  
on:  
  workflow_call:   
    inputs:   
      platform:  
        required: true  
        type: string  
      secrets:  
        UNITY_EMAIL:  
          required: true  
        UNITY_PASSWORD:  
          required: true  
        UNITY_LICENSE:  
          required: true  
    outputs:  
      buildVersion:  
        value: ${{ jobs.buildWithLinux.outputs.buildVersion }}

on: Specify the events that trigger the workflow.
- workflow_call: Set the workflow to be called from other workflows.
- inputs: Values passed in from the caller workflow .
  - platform: Platform for which the Unity project should be built.
- secrets: Secrets passed in from the caller workflow.
- outputs: Data to pass back to the caller workflow.
  - buildVersion: The version generated by the job.

The Linux Build Job

jobs:  
  
  buildWithLinux:  
    name: Build in Linux for ${{ inputs.platform }}  
    runs-on: ubuntu-latest  
    outputs:  
      buildVersion: ${{ steps.build.outputs.buildVersion }}  
      steps:  
      - name: Checkout Repository  
        uses: actions/checkout@v4  
        with:  
          fetch-depth: 0  
          lfs: true  
  
      - name: Cache Library  
        uses: actions/cache@v4 
        with:  
          path: Library  
          key: Library-build-${{ inputs.platform }}  
          restore-keys: |  
            Library-build-${{ inputs.platform }}
            Library-    

      - name: Build Unity Project  
        id: build  
        uses: game-ci/unity-builder@v4  
        env:  
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}  
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}  
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}  
        with:  
          targetPlatform: ${{ inputs.platform }}  
  
      - name: Upload Build  
        uses: actions/upload-artifact@v4  
        with:  
          name: build-${{ inputs.platform }}  
          path: build/${{ inputs.platform }}

Here's a breakdown of what's happening in this job:

outputs: Data we want to return back to the caller workflow.
- buildVersion: Version generated by the Builder in the build step below.
steps: This section contains a series of steps to be executed for this job.
- Checkout Repository: Check out the code
  - fetch-depth: Get only the last commit of the branch.
  - lfs: Download files tracked by LFS.
- Cache Library: Cache the "Library" directory, to make subsequent runs faster. The key is unique to each platform.
- Build Unity Project: Build the Unity project for the target platform.
- Upload Build: Upload the built Unity project as an artifact so that it can be downloaded in later jobs.

Conclusion

In this part, we created a reusable workflow to build the Unity project for different platforms. Next, we will use this workflow to build and deploy a WebGL build to GitHub pages.

Happy building!

References

WordXplorer #2: TestFlight Approved, New Colors & Instructions

Mon, 16 Oct 2023 00:00:00 GMT

You can see all the related updates here

I am thrilled to share some updates for the wordxplorer game! 🎉

🚀 Testflight Approval

The first version with around 25 words has received the green light for TestFlight! If you registered as beta tester for iOS, watch your inbox for those invites - they're coming soon! 📬 . If you didnt, you can register by filling the form

🌈 Updated Colors

I have revamped the colors! Let me know if you have any suggestions on better colors. Share your ideas with me! 🎨

📜 Instructions Page

I have added a new instructions page at the start of the game for people who are new to Wordle.📘

🔮 What's Next

A public Trello board for the roadmap, so beta testers can vote on what they would like to see next.
More Words

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

Unity CI/CD Demystified: Part 2: Trigger Events and Running Tests

Wed, 07 Aug 2024 00:00:00 GMT

In Part 1, we finished the setup to start creating our CI/CD pipeline.

In Part 2, we will create a workflow to run our automated tests based on some trigger events.

Update .gitignore

Before you create your workflow, you need to ignore the files generated by GameCI. Update the .gitignore file with these lines:

/[Aa]rtifacts/
/[Cc]odeCoverage/

Setting the Trigger Events

Now, you need to define when your pipeline should trigger.

Create .github/workflows/main.yml and add the following workflow definition:

name: Test, Build, and Deploy with GameCI
on:
  push:
    branches:
      - main
    paths:
      - 'Assets/**'
      - 'Packages/**'
      - 'ProjectSettings/**'
  pull_request:
    types:
      - opened
      - synchronize
    branches:
      - main
    paths:
      - 'Assets/**'
      - 'Packages/**'
      - 'ProjectSettings/**'
      - '.github/workflows/**'
  release:
    types:
      — published
  workflow_dispatch:
    inputs:
      release_platform:
        description: 'release [ios, web, testflight]'
        required: false
        default: 'release '
jobs:

A lot is going on here, so let's break it down:

on: Specify the events that trigger the workflow.
- push -> branches : push event to the "main" branch
  - paths: filter to only changes that happen in the Unity project or the workflows.
- pull_request -> types: pull request is opened or updated against the "main" branch.
  - paths: filter to only changes that happen in the Unity project or the workflows. (Same as the push event).
- release -> publish: publish a release.
- workflow_dispatch: manually trigger the workflow using the GitHub Actions interface.
  - input -> release_platform: input to specify the platform. Add the default text to "release" so that there is less typing.

Building and Running Tests

Next, add a new job to build and run the Unity project tests

jobs:

  test:
    name: Build and Run Tests
    runs-on: ubuntu-latest
    steps:
      # Checkout with lfs
      - name: Checkout Repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 1
          lfs: true

      - name: Cache Library
        uses: actions/cache@v4
        with:
          path: Library
          key: Library-test-${{ hashFiles('Assets/**') }}
          restore-keys: |
            Library-test-${{ hashFiles('Assets/**') }}
            Library-test

      - name: Run Tests
        uses: game-ci/unity-test-runner@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          githubToken: ${{ secrets.GITHUB_TOKEN }}

Now, let's look at whats happening in this job:

runs-on: The job should run on an lates Ubuntu-based runner.
steps: The steps to execute for this job.
- Checkout Repository: Check out the code
  - fetch-depth: Get only the last commit of the branch.
  - lfs: Download files tracked by LFS.
- Cache Library: Cache the "Library" directory, to make subsequent runs faster.
- Run Tests: Runs the Unity tests.
  - env: Set the environment variables
  - with -> githubToken: Set the GITHUB_TOKEN from the secrets to report the test results.

Set Workflow Permissions

To view test results as part of the Github Status check, you need to provide write permissions to the workflow

Go to Settings > Actions > General > Workflow permissions and choose Read and write permissions.

Preparing the Project

If the project builds in the editor but fails when you run the workflow, its likely because of missing packages.

Luckily, its a simple fix.

Verify Packages

Ensure that these entries are present in packages/manifest.json:

com.unity.2d.sprite
com.unity.inputsystem
com.unity.test-framework
com.unity.textmeshpro

If any of these packages are missing, add them using the Unity Package Manager. Remember to commit the changes in packages/manifest.json and packages/package-lock.json.

Conclusion

In this part, we set up the trigger events for the workflow and added a job to build and run tests. Next, we will add a job to build the project for different platforms.

Ankur Sheel

WordXplorer Update 11

New Theme

Dynamic Backgrounds

Beta Testers Save the Day

Want to Be a Beta Tester?

Level Button Updates

What's Next?

Get WordXplorer

WordXplorer One Year In: Am I a Millionaire Yet?

A Little Backstory

What went right

My daughter still plays it

Getting help early on

GitHub actions and CI/CD

Pre-orders

Making hard calls to ship

Validation

Natural break patterns

What went wrong, aka lessons learned

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

Google's requirements

Promo codes

Android refunds

Procrastination

One negative review

Show me the money numbers

Shipped improvements

What's Next?

So… Was It Worth It?

Get WordXplorer

WordXplorer Update 10 : Fireworks, Levels, Polish

More fireworks

Scene transitions

Level select now opens at your highest unlocked level

6 more levels

Behind the scenes: refactoring + automated tests

What theme should I build next?

Get WordXplorer

Story Points Aren't the Problem

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

1 Point

2 Points

3 Points

5 Points

8 Points

Mistake #2: Estimating in Isolation

Mistake #3: Arguing Over 2 vs 3 Points

Final Thoughts

WordXplorer Update #9: Save your guesses

Save your guesses

Bug Fixes

Get WordXplorer

WordXplorer Update #8: New Hint System

New Hint System

Get WordXplorer

Offset vs Cursor Based Pagination

Introduction

Offset Pagination

Example

Advantages

Disadvantages

Cursor-based Pagination

Example

Advantages

Disadvantages

Advanced Cursor Pagination Techniques

Example

Using Non-sequential Identifiers

Conclusion

WordXplorer #7: New Video & Food Theme

🎥 New Video Alert!

🎨 Exciting New Theme

💰 Special Preorder Pricing

🛒 How to Preorder

📱 Google Play Progress

🕹️ Last Chance for Playable Build

🚀 What’s Next

Fun with (Feature) Flags

Other Approaches

Q: Is `fix typo in variable name` too granular?