The problem: a job enqueue three conditionals deep

Somewhere inside converting a lead into a subscription plan, there’s a helper called enqueueInvoiceRequest. You don’t get to it directly — you get to it by going through convertProduct, which is itself dispatched to from a product-type switch one layer up, and even once you’re inside it you still have to clear a legacy-plan early return, a brand check, an invoice-count guard, and a null check on a webhook request ID before the enqueue itself ever runs:

// server/src/services/lead-conversion/plan/index.ts
if (attributes.brandId === BRAND_ID.acme) {
  await enqueueInvoiceRequest({ plan, trx });
}

// ...inside enqueueInvoiceRequest:
if (inboundWebhookRequestId) {
  // We need to wait for the transaction to commit before we can add the item to the queue
  attachToExecutionPromise(trx, "invoice-enqueue", async () => {
    await invoiceQueue.addItem({
      type: "create-invoice",
      inboundWebhookRequestId,
      planId: plan.id,
    });
  });
}

That comment — “we need to wait for the transaction to commit” — is the whole problem in one line. The enqueue can’t run inside the transaction, because the transaction might still roll back and there’s no un-enqueueing a job. It also can’t run synchronously right after trx.commit(), because nothing at this depth of the call stack has a reference to “right after commit” — it’s three function calls and four conditionals away from whoever actually owns the transaction and decides when it commits.

Why executionPromise, and what we didn’t do instead

Objection’s Transaction exposes executionPromise, which resolves once the transaction settles — commit or rollback, either way. Attaching to it with .then() gives you exactly the guarantee you need at exactly the point in the code where you need it, no matter how deep that point is:

trx.executionPromise.then(fn);

That’s the entire mechanism. No return value has to travel back up through enqueueInvoiceRequest → convertProduct → the product-dispatch switch → whatever called that, just to tell the transaction’s owner “also run this once you’re done.” Every intermediate function stays exactly as it is.

We did consider the alternatives, briefly:

• Thread the deferred action back out through the return value, and let the code that actually owns the transaction run it after commit. This is the “correct” version in some abstract sense — no fire-and-forget, no ambient coupling to a transaction object passed four calls deep. It’s also a real cost: every function between the enqueue and the transaction’s owner would need its return type widened to carry “oh, and also run this afterwards,” purely to plumb one job dispatch through call sites that have nothing to do with it. Given that we had multiple use cases like this it just didn’t make sense.
• Just delay it. Fire the job on a setTimeout a few hundred milliseconds after the write, on the assumption the transaction will have committed by then. This isn’t a guarantee, it’s a bet — one that gets worse under load, not better, since a slow commit and a fast timer are exactly the conditions you’d expect during the traffic spike you most need this to be correct for.

executionPromise won on both counts: it’s precise (it resolves on the actual event, not a guess about timing), and it’s local (the code that needs the deferral is the only code that has to know about it).

The CI failure that got worse, not better

The trouble is that “fire-and-forget” and “test suite” don’t get along. The first sign of it was a commit back in April with an admirably honest message: “Add a executionPromise callback has made test more flakey” — the fix at the time was a global Mocha hook that stubbed the relevant client, wrapped its deferred callback in a 2-second timeout, and collected any errors to re-throw in a global afterEach. It made the symptom quieter without doing anything about the cause: a callback that isn’t awaited by anything can still be running, or about to run, after the test that triggered it has already finished and moved on.

It didn’t go away. It got worse, and predictably so, once we started rolling out transaction-based test isolation more broadly — every test now ran inside its own transaction that got rolled back at the end. That’s a good change on its own merits, but it also changed where a callback firing “late” actually landed: instead of writing to an already-cleaned-up database, it wrote straight into whatever other test happened to have its own transaction open at that exact moment, silently adding a row to whatever that test was counting, a row that wasn’t part of a transaction, and wouldn’t get rolled back. Small suites rarely lined up that unluckily. Running the full suite did, as a handful of count assertions that failed for no reason anyone could reproduce in isolation.

Reframing executionPromise as a background job, not a callback

The thing that actually unlocked the fix was stepping back from “this is a callback attached to a transaction” and treating it as what it really is: background job execution, deferred past a boundary the test environment doesn’t otherwise care about. Once it’s framed that way, the fix looks exactly like how you’d handle any other job queue in tests — don’t run it for real, capture it, and let the test decide if and when to run it:

export const attachToExecutionPromise = (
  trx: Transaction,
  description: string,
  fn: () => Promise<void>,
): void => {
  if (ENV.NODE_ENV === "test") {
    capturedCallbacks.push({ description, fn });
    return;
  }

  trx.executionPromise.then(fn);
};

Under test, nothing fires unawaited and nothing can outlive the test that triggered it — the callback just sits in an array until something asks for it by name, or the next test’s beforeEach clears it out. A test that cares can pull its own callback out with getCapturedExecutionPromiseCallback('invoice-enqueue') and run it deliberately, on its own schedule, same as it would call any other job handler directly.

It wasn’t a total, clean victory, though — worth saying, since that’s the more honest version of this story. One integration test, after adopting this fix, still leaked a row into unrelated tests at full-suite scale, from somewhere in the same request flow that this fix didn’t reach. We had a custom patch for it until we figure out a proper fix, and a comment saying as much, rather than a triumphant “and then everything was fine.” Sometimes the honest state of a fix is “this part’s solved, that part’s still open,” and it’s better to write that down than to pretend otherwise.

The full source — attachToExecutionPromise(), the capture/flush test helpers, and the wiring into the test suite — is up in the complete code reference, if you want the whole thing rather than the excerpts above.

I’m not always the best at leaving well enough alone. For years our test suite cleaned up after itself with all the elegance of a toddler tidying a bedroom by sweeping everything under the rug: when needed, we called clearDatabase() and truncated every table. Simple. Confident. Wrong, not in the dramatic “everything’s on fire” sense, but a slow death by a thousand cuts — one that had apparently crept up to failing around 50% of test runs by the time I found out, which someone mentioned to me only once I was already elbow-deep in replacing it.

The problem we’d been living with

clearDatabase() had been there so long it had achieved a sort of tenure — untouchable, load-bearing, the kind of code nobody wants to be the one who breaks. Previous attempts had pruned the easy wins, but the mountain still loomed. It “worked,” in the sense that the tests mostly ran and mostly went green, which is a very low bar we had somehow decided was good enough. As the suite grew into the thousands of tests, two things kept nagging at me, each more embarrassing than the last:

• It didn’t actually guarantee isolation — it just looked like it did. clearDatabase() only ran when called, which is a generous way of saying it ran whenever someone remembered to call it. Two tests in the same describe regularly depended on each other’s leftovers, and in fact plenty of tests had come to depend on exactly that — meaning they couldn’t be run in isolation without falling over, which rather defeats the point of calling it “isolation” in the first place.
• And that’s exactly what caused the flakiness. Because isolation only ever existed on paper, whether a test passed depended on what had run before it, in what order, and under what conditions — which is a fancy way of saying it was basically luck. Locally, with everyone running a handful of files at a time, that luck mostly held. Under CI, with the full suite running in whatever order and however much parallelism it decided to use that day, the luck ran out — and because nothing about this was subtle, a single test’s hidden dependency on another test’s leftovers would cheerfully cascade into a dozen unrelated failures, none of which had anything to do with the code actually being tested.

That last one is the kind of bug that quietly kills trust in your own test suite. A red build that’s “probably nothing, just re-run it” is worse than no test suite at all — at least an empty suite doesn’t lie to you. Eventually nobody looks at red builds anymore, and at that point you don’t have a safety net, you have a very expensive gut feeling.

Reaching for a feature that was already there

This didn’t start as “let’s rewrite how the test suite cleans up.” It started as a bug hunt — the cascade failures above needed a root cause, and the obvious first move was to see whether anyone else had already solved this. They had: Postgres transactions, rolled back instead of committed, are a well-known pattern for exactly this problem, and there’s an existing library for it — pg-transactional-tests — that wraps each test in a transaction against the pg package directly.

It didn’t fit us. The library assumes a fairly clean hook structure — transaction opens, test runs, transaction rolls back — and our suite doesn’t play by those rules. We have describe blocks with real database writes happening in before(), not just beforeEach(), which a purely per-test wrapper would either miss entirely or roll back at the wrong time. And in more places than I’d like to admit, tests were quietly relying on state a previous test had left behind — which a library built around strict per-test isolation would break in ways that looked like the library’s fault, not ours.

So more of this was failure than success at first: the off-the-shelf fix didn’t fit our shape of problem, and untangling why it didn’t fit taught us more about the suite’s hidden assumptions than the fix itself ever did. What we ended up building — transactionPerTest() and transactionPerDescribe() — is the same core idea as that library, just built to cope with our before()-heavy, occasionally state-sharing suite instead of assuming a cleaner one.

transactionPerTest() now wraps every it() globally via beforeEach/afterEach. In the common case, you don’t call anything yourself — you just write a normal, independent test, and the rollback happens for free underneath you.

That sentence undersells how much work it took to get there. But — as with most “just use the database properly” fixes — the real story is in the edge cases it surfaced once it was actually running against our suite.

Edge case one: a before() that runs before any transaction exists

This one cost us a real, silently-leaking row before we understood it.

transactionPerTest() opens and rolls back its transaction from beforeEach/afterEach, which Mocha runs per test. A describe-level before() runs once, and — crucially — runs before the first beforeEach of that suite fires. Which means: if a before() writes to the database directly, and nothing further up the chain has already opened a transaction, that write goes straight to the real connection. There’s no transaction for afterEach to roll back, so the row just… stays. Forever, or until someone notices.

// ❌ Leaks a real, permanent row — before() runs before any
// per-test transaction exists, so this insert is never rolled back.
describe("LpaCase#willsuiteStatus", () => {
  let lpaCase: LpaCase;

  before(async () => {
    lpaCase = await lpaCaseFactory({ status: "in_progress" });
  });

  it("returns the mapped status for in_progress", () => {
    expect(lpaCase.willsuiteStatus).to.equal("IN_PROGRESS");
  });
});

The fix is transactionPerDescribe(), called as the first line of the block, so its own before() opens a transaction before the fixture-creating before() gets a chance to run (Mocha runs before() hooks outside-in, so this ordering is guaranteed):

// ✅ transactionPerDescribe()'s before() runs first, so the fixture
// is created inside a transaction and rolled back once the describe finishes.
describe("LpaCase#willsuiteStatus", () => {
  transactionPerDescribe();

  let lpaCase: LpaCase;

  before(async () => {
    lpaCase = await lpaCaseFactory({ status: "in_progress" });
  });

  it("returns the mapped status for in_progress", () => {
    expect(lpaCase.willsuiteStatus).to.equal("IN_PROGRESS");
  });
});

By default this doesn’t remove per-test isolation, either — the global per-test wrapping just becomes a nested savepoint on top of the describe’s transaction, so individual tests still can’t leak into each other. It only changes where the shared fixture setup lives. There’s an opt-in flag, skipIndividualTransaction, that removes that per-test nesting entirely and lets tests deliberately share state — but that reintroduces exactly the ordering-dependent fragility we were trying to get rid of, so it’s a deliberate, rare choice, not a default.

We didn’t just write this down and hope people remembered — a before() leaking a real row was exactly the kind of thing everyone agrees is bad and then does anyway six months later, so there’s now a custom ESLint rule (require-transaction-wrapper-for-before) that flags any describe-level before() without transactionPerDescribe() or skipTransactionWrapping() somewhere in its own or an ancestor describe. A before() that never touches the database can opt out with a plain disable comment — but by default, the lint rule assumes guilty until proven innocent.

Edge case two: when a test needs a real, aborted transaction

Postgres aborts an entire transaction on any query error — not just the failing query. Every later query on that connection fails with “current transaction is aborted” until something rolls back, in full or to a savepoint. A try/catch around the failing query doesn’t save you from this on its own.

That’s a real problem once every test is already running inside an ambient transaction: a test that deliberately triggers and recovers from a DB-level error (say, a unique constraint violation) can take down every query that runs afterwards in that test, or worse, in a later one on the same connection.

The fix, runInSavepoint(), runs the risky call inside its own nested savepoint on top of whatever transaction is already active, and only rolls back that, leaving the ambient transaction healthy:

try {
  await runInSavepoint(() =>
    Country.query().insert({ id: duplicateId, name: "Second", code: "ZZ-D2" }),
  );
} catch (error) {
  // the savepoint was rolled back, not the ambient (per-test) transaction —
  // so this query still works instead of failing with
  // "current transaction is aborted"
  expect(await Country.query().findOne({ code: "ZZ-D1" })).to.exist;
}

It’s not just a testing trick, either — it’s the same pattern our production code already uses to catch a constraint violation mid-request without taking the whole request down.

For the handful of cases where none of this is enough — tests that need real, independent transactions racing each other (proving row locking works, for instance) — there’s skipTransactionWrapping(reason), which opts a block out entirely and falls back to a clearDatabase() safety net once it finishes. It’s the escape hatch, not the default, and it comes with a mandatory reason so nobody has to reverse-engineer why a block needed it six months later.

Edge case three: everything happens at the same instant

A smaller but more insidious one: rows created in the same test do end up with an identical createdAt, because Postgres’s now() is fixed for the whole transaction rather than the wall clock. Depending on where the ambiguity actually bites, the fix is either a monotonic nextCreatedAt() in the factory, a real id-based tie-breaker in production code where the id is a reliable insertion-order surrogate, or — usually the right call — just asserting on the row’s id instead of its position in an array. Not exotic, just another place the old truncate-based setup had been quietly hiding an assumption.

What I’d tell past me

The tempting version of this story is “we replaced a flaky thing with a reliable thing.” The more honest version is that the replacement exposed assumptions our tests had been quietly making for years — about ordering, about hook timing, about what “isolated” actually meant — that a full table wipe had been papering over the whole time.

None of the fixes above were exotic. A monotonic counter. A documented hook-ordering gotcha. A savepoint instead of a full rollback. The hard part wasn’t the Postgres feature — it was noticing where our tests had been relying on clearDatabase()’s side effects without anyone writing that reliance down anywhere. If there’s a lesson in here, it’s the same one I keep relearning: the “obviously safe” cleanup step is usually hiding a few assumptions that are worth writing down before you rip it out, not after.

The rabbit at the bottom of the hole

Here’s the bit I keep coming back to. Partway through this, we hit a test that only ever failed once it was running inside a transaction — never before, never in isolation, only as part of the wider suite, only with rollback-based isolation switched on. That’s about as unhelpful a signal as a test can give you: the thing you just built to make failures more honest was itself producing one, and it wasn’t obvious whether the bug was in the test, the production code, or the new transaction plumbing.

It turned out to be a real bug — a genuine race in how state was shared between two things that used to be accidentally separated by clearDatabase()’s side effects, and were now sharing a transaction that made the collision visible for the first time. Not a bug in the new approach; a bug the new approach finally had the honesty to show us. I’m not entirely sure why that felt like such a big reveal at the time — it’s “a test caught a real bug,” which is the whole point of a test suite — but it did. Maybe because it was proof the whole exercise hadn’t just moved the flakiness somewhere else.

That’s the tree-and-rabbit of the title, really: VS Code’s worktrees meant this didn’t have to be my whole week to be worth chasing. I could spin the investigation off into its own worktree, on its own branch, and let it run as a side task while I stayed on my actual tickets in the main checkout — the kind of thing that, on paper, could have swallowed weeks of focus: a root-cause investigation, a rejected library, three edge cases, and a bug hiding under all of it. It still needed hand-holding, and it still went wrong more than once along the way — but that’s what experience (and git revert) is for. In practice it stayed a contained side quest of a couple of days, running alongside everything else, without taking the rest of the work off track. Whatever else I take from this, that’s the part worth remembering: the rabbit hole didn’t need to become the whole week.

The full source for everything above — the transaction wrapper, the savepoint helper, the monotonic timestamp helper, and the ESLint rule — is up in the complete code reference, if you want to see it rather than take my word for it.

According to the dropbox documentation it is to do with namespaces. It is also possible to override this behavious and set you namespace to be the root folder, giving you full access via the API that we get from the web interface. It’s not that hard, you just need to set a header and off you go.

Well, almost, first of all the dropbox_api gem will need to merge my PR, giving access to the root_info - this is needed to determine the root namespace_id.

Then set the additional header via the built-in middleware stack within the gem:

client = DropboxApi::Client.new("VofXAX8D...")

namespace_id = client.get_current_account.root_info.root_namespace_id

client.middleware.prepend do |connection|
  connection.headers['Dropbox-API-Path-Root'] = "{\".tag\": \"namespace_id\", \"namespace_id\": \"#{namespace_id}\"}"
end

Hopefully this will help someone out there.

This is dependant on having your Dropbox App correctly configured with the necessary permissions.

At first everything was fine, but then he was diagnosed with reflux followed by a milk intolerance, looking back it’s hard to know what was true, the only thing for sure was that the doctors didn’t know. As he grew, so did our expectations, we had made friends at NCT and each parent was taking it in turns to boast about their childs latest achivements, but it never felt like we had much to say. By 8 months it was clear that Harry was behind, at 11 he had his first seizure, by 12 month we had a diagnosis, FoxG1.

And with that our expectations changed, it went from thoughts of taking him to play his first rugby game, to getting excited by each little achiveement he managed. It meant sharing in his joy, be it the first time he managed to put a bell off his round-about in his mouth (this took 4 months of trying), or his belly giggles whenever I take him on a swing.

Harry is not a normal child, but he does have the ability to brighten the lives of everyone that he meets and for that I think he is as special as they come. :)

There was recently a requirement to get a copy of a Elasticsearch (ES) dump onto our local machines, Due to the amount of data, and the way it was being indexed, it would have taken around 8 days to regenerate the data locally. We could have improved the performance on this by re-writing the indexing process to using the bulk endpoint, however as this code was untested, and we were in the process of decommissioning it the download seemed like a better solution.

Heroku is normally pretty good at giving you access to your data (see the Postgres snapshot download facility in the CLI). This is not the case of the ES data, you do have the facility to create snapshots, but these are stored on a S3 cluster that you can’t get access to, you can restore the snapshots, but only to other Heroku instances, so how do you go about getting a download?

The solution it turns out is pretty easy, you need to setup an additional snapshot repository, pointed at a s3 bucket that you have permission to download from. The below outlines the steps to get this setup and then downloaded.

1. Get access to the Elastcisearch instance.

This is actually pretty easy. Log into Heroku, access the ES Addon and under ‘Application’ there is a copy endpoint button.

This only gives you the URL and port, which isn’t super useful as it is password protected. I was able to retrieve the username (default elastic username) and password from the Heroku settings, but this may vary depending on your setup. Alternatively you can reset the password, be careful if you are doing this on a production system as you easy lock you main application out.

2. Get a storage location

As I mention at the top of this article we will be using s3 to store the snapshot, so you will need a bucket in the desired region (we will talk more about regions below), and I would suggest it should be password protected.

Once you have these details you are good to proceed to connecting the repository

3. Setting up the repository

This can be done using a PUT request to the ES system

URL:
<es_host>/_snapshot/<repository_name>?verify=false&pretty

BODY:
{
  "type": "s3",
  "settings": {
    "bucket": <bucket_name>,
    "region": <region>,
    "access_key": <access_key>,
    "secret_key": <secret_key>,
    "compress": "true",
    "base_path": "es_snapshots/"
  }
}

This works great is your bucket is in us-east-1 which is teh default, but what is you need to store the data in a different region? While you can set the region in the above PUT, you can only set the AWS URL in the client settings in the elastcisearch.yaml file on the server - that we don’t have access to and can’t change. Reading the docs shows that this is actually set at a client level, and due to data laws if you are running in you ES cluster in Europe then any backups must also be stored in Europe, so it must be possible to connect to a eu-west-1 bucket. But how?

I am using a tool call Elasticvue to manage my ES indicies, using this I can connect to the ES host using the details we got above. In the repository screen I could see the existing repository and but hovering over the settings I was able to get the client they are using for eu-west-1.

So updating the body of the above PUT request to also set the client:

    "client:" <client_id>

I can now connect to eu-west-1 buckets.

4. Creating the snapshot

I used Elasticvue to do this as well, it was simply a matter of clicking ‘create snapshot’ for the new repository and then waiting for it to finish - about 10min.

5. Restoring the snapshot

You could do this by connecting to the same s3 bucket with your local ES instance and then doing a snapshot restore, however I never managed to get this to work, and it actually turned out to be much easier to use the AWS CLI to download the folder locally and then do a snapshot restore

aws s3 sync s3://<bucket_name>/ <local_path>

And that is it you should now have a copy of you ES indicies on your local machine. </local_path></bucket_name></client_id></secret_key></access_key></bucket_name></repository_name></es_host>

I recently been building a card game, and my first thjought was that carding each card individually would quickly exceed the DB row limit (currently 10,000) and bring down the application. To avoid this I stored the cards as a JSON blob on a single game object. This approach is measn that I would need to deserailise the game state, update and the serialize it again for every update, this might(?) be fine if I only have a single playing in the game, for a multiplayer game this would quickly become a bottleneck and result in slow response times

The initial solution

Storing card ownership in a redis DB, this would be super quick way to manage card locking adn avoid hitting the DB.

This approach has a number of issues:

• Redis locking is a pain
• ID selection is difficult, especially when you don’t have a card ID fro the front-end, but instead just a location key.
• How do you release a locks? what happens if the user refreshes while holding a card?
• How do you avoid sync issues between redis and the postgres DB
• I would need a background worker to actually perform events later and sync the redis data back into postgres

Not only that, it was hard to reason about, difficult to tests for and would add a large amount of complexity to the core of the backend, something that is never a good thing at the start of a project.

The easy solution

While thinking over the problems I was having with the redis solution I satrted to think about why I wasn’t just using the postgres DB to do my locking. After all postgres is pretty good at locking, it has a number of feature to deal with different lockjing scenarios. In fact the only reason I wasn’t using it was the row limit, so I has a look at my current usage, 10 rows…

If I assumed each game would need around 100 cards, then I could have 100 games before I actually hit the row limit. It was at this point I realised I has made a mistake. I was optimising against an issue that didn’t currently exist, and if I was careful with my implementation it would potentially be thousands of games before it was an issues.

With that in mind I update the application to store each card in the DB, this means that eadch player can update game cards simultaneously. It: * Solved the locking problems as I could just releasing any card I currently holding - with a simple update query - before I selected a new card. * Was easy to reason about and test, which was a big win over the redis solution. * allowed updated in request instaed of needing a back ground wokrer, as it only has to update simple card objects instead of a shared global state.

I still have the card state on the game object, this allows games which have been completed (or where no-one has made a move in a while) to be archived. These chnages mean I would require around 100 simultaneous games in process before I reached the DB limit.

Conclusions

I guess the key point here is that optimising is great, but if it isn’t a requirement right now, then you are most likely just making your code more complex without any gain, and in some cases you could even be dooming your project to fail. This is an easy pitfall to run into and can be hard to recognise from the inside, but once you do it is often clear where you went wrong. The best way to guard against this to watch out of smells in your code, as good design will (as a general rule) lead to simple code that is easy to understand.

I’m not sure if this is due to me being new to React and everyone just knows how to do this, or (and this seems unlikley) the only people who write react blogs are actually those who are building a tasks list application and so don’t need this functionality. What I will say is that once you understand how to use the hooks to pull data in it is actually extremely easy, which again makes me ask why this isn’t covered more widely.

So how did I do it:

Create a component to track interest in updates and poll the backend for updates:

let cardsByStack = {};
let watchers = {};

// allow registering to receive updates
export const watch = (stackId, watchMethod) => {
  watchers[stackId] = watchers[stackId] || [];
  watchers[stackId].push(watchMethod);

  watchMethod(cardsByStack[stackId]);
}

// allow deregistering to receive updates
export const unWatch = (stackId, watchMethod) => {
  watchers[stackId] = watchers[stackId].filter(watcher => watcher !== watchMethod);
}

// do an update
export const pollForAddedCards = () => {
  let stack_id, cards = ...

  cardsByStack[stack_id].push(card);

  watchers[stackId].forEach(watchMethod => watchMethod(cards[stackId]));
}

setInterval(pollForAddedCards, 1000)

Registor interest in update, with the ability to update the local state:

import React, { useState, useEffect } from "react"
import {addEvent, updateCard, watch, unWatch} from '../state/CardState';

const CardStack = (props) => {
  const [cards, setCards] = useState();

  ....

  useEffect(() => {
    let watchCallback = (cards) => { setCards(cards) }

    watch(props.stackId, watchCallback)
    return () => { unWatch(props.stackId, watchCallback) }
  });
}

So how does this all work….

useEffect is the important thing here. Calling it without a second property means the code inside is run when the component loads/unloads, this allows me to pass the state modifier funtion setCard into the non React view hierarchy part of my application (called CardState here), where it can be called (and trigger view updates) asyncronously. Once you have understoof this, it is quite easy to receive updates from external sources.

WARNING: This is demonstrating how you trigger render updates from external parts of your code - i.e. using setTimeout to poll the server for updates from other players - with just react hooks. This is done by using module variable to store what is essentially global state, and while this works I would recommend against it for anything that have more than 1 global state. You are instead better off using one of the existing libraries like: * redux * reactn * recoil

Solution 1

    pieces = 70904 * 100
    players = 473

    played_pieces = [0, 1]
    i = 1
    player = -1
    result = Hash.new {|h,k| h[k] = 0}

    (pieces + 1).times do |piece|
      player = player >= players ? 1 : player + 1
      next if piece < 2

      if piece % 23 != 0
        i += 1
        i -= played_pieces.size if i >= played_pieces.size
        played_pieces = played_pieces[0..i] + [piece] + played_pieces[i+1..-1]
        i += 1
      else
        i -= 7
        i += played_pieces.size if i < 0
        result[player] = result[player] + piece + played_pieces[i]

        if i == 0
          print 'x'
          played_pieces = played_pieces[1..-1]
        else
          played_pieces = played_pieces[0..i-1] + played_pieces[i+1..-1]
        end
      end
    end

    puts result.values.sort.last

Solution 2

    pieces = 70904 * 100
    players = 473

    class Node
      attr_accessor :p, :n
      attr_reader :value

      def initialize(p, n, value)
        @p = p
        @n = n
        @value = value
      end

      def prev(c=7)
        c == 1 ? p : p.prev(c-1)
      end

      def insert(value)
        self.n.p = self.n = Node.new(self, n, value)
      end

      def remove
        p.n = n
        n.p = p
        [self.n, value]
      end
    end

    n0 = Node.new(nil, nil, 0)
    n1 = Node.new(n0, n0, 1)
    n0.n = n0.p = n1

    c = n1
    player = -1
    result = Hash.new {|h,k| h[k] = 0}

    (pieces + 1).times do |t|
      player = player >= players ? 1 : player + 1
      next if t < 2

      if t % 23 != 0
        c = c.n.insert(t)
      else
        c, remove_value = c.prev.remove
        result[player] = result[player] + t + remove_value
      end
    end

    puts r.values.sort.last

Why do I have two solution to a single problem? The puzzle had a significant increase in the problem space (factor of 100), this highlighted a significant performance bug in the solution. The performance was so bad that I was above to write and run the second solution before the first had completed. The issue with the first solution was that as the problem space increased it took increasingly longer to find a solution. the.

This was an exercise in fun, but it is wtill possible to learn something from it, as you can easily encounter similar problems in your day job. Your approach does matter, and it should be geared to the solution. By this I mean my initial approach was the best solution to the initial problem as it was quite easy to write and array storage made sense. The second solution using a linked list is more complicated, using a custom data storeage object, and while the code itself is in some ways simplier, the ideas behind it are more coplicated and would have been overengineered for the initial problem.

I wonder what more junior developers would make of this problem and how they would overcome the inherit failure of the simple (Array based storage) solution? For that matter I wonder how most seniors would tackle this problem?

One of the biggest mistaskes that you can make when doing this is to start a conversation using the wrong level of detail and forgetting to give the audiance context before they start. using the correct laguage is important as talking about low level implementation details is unlikely to help you project manager understand the issue.

However starting a conversation without first setting the context will only ever will only result in a miscommunication, no matter how good you explain the problem.

For example if I start by saying something like

Editing the hosts file make it impossible to retrieve the real data to cache so instead we are going to use proxy domain names

It is unlikely anyone will understand why this is important, so what is the solution to this?

For me it is laying out some background to the problem first, basically just explaining what issue I have encountered and why it matters to me:

I want to remove external dependancies from the cucumber tests

I can then start talking about my requirments and what I plan to do, this should start with high levels informatioon, going into detail if appropriate.

We want this to automatically cache the response, as a results we have the following approaches…

This ensures whoever I am conversing with understands why we are having this conversation before I start giving details or asking questions.

As I said at the start I don’t always communicate successfully, but I find tools like this ensure I succeed more regularly that I did previously.

I’m hopeful, that I can do this more and more on future jobs as working from home can be a real joy, and anyone who has the opportunity should definitely take it.

That is not to say it is all rainbows. As with any perk, it is important that you don’t abuse it or it may just be taken away, so here are my recommendations for anyone looking to WFH.

Don’t’ forget to socialize

We all do this at work, be it at the coffee machine, over lunch or just with the person next to you. This is an important part of your day as it helps you relax before continuing with your work. As such make sure you have time for your family during the day, as (most likely) they are happy to have you home to talk to as well.

Just be sure that you also ensure your family know that you are home to work or perform odd jobs aroud the house.

Have a work plan

It is never wise to start work without having a plan for the day. This is doubly true when you are WFH as you can’t just turn to your boss/colleagues to discuss what is next. This is becoming less of a problems as most teams have some form of task online board and you can just pick up the next task.

It is still a good idea to have agreed the next day’s work before you leave the office, especially if you are likely to be working away for multiple days or about to start/finish a major piece of work.

Keep in touch

If your teams are used to remote work, or even if they aren’t, there is a good chance you will use some form of chat to communicate within the team. This is especially important when you are working from home as it the easiest form of communication for you and the team, even if it is just letting everyone know that you have gone to lunch.

Be productive

This is an important one.

Keep in mind that not every day can (or even has to) be super productive, some days are just slow. However, it is important to remember you are being employed to do a job and if your boss/co-workers lose faith in you performing that job while WFH, you will soon find that WFH days are a thing of the past.

Not every day can be super productive

Sure I already mentioned this in the last point. But I want to raise it again, as just because you are working towards your goals, doesn’t mean you will be super productive. This is fine, you just need to be clearly communicating any blockers and ensuring you ask for help when you can.

It is also important to make yourself available if other in the team have questions for you.

Your not alone

Well maybe you are, but you can still use any number of tools to work collaboratory with your colleagues in the office (or even their house if they are also WFH). While it may take some getting used to pairing remotely is definitely possible, some people even prefer it.