Because in case there is still a call site which is making calls to deprecated APIs, your shopify app can get delisted.

Finding call sites for deprecated APIs can sometimes become challenging specially in large code bases involving multiple services.

In case a developer made a postman call to a deprecated API I guess that would still count as an invalid call and can lead to delisting.

In Shopify's defence they do start to give a warning about deprecated APIs way before but taking a strong action like delisting the app feels weird.

Maybe just making the existing APIs return an error citing deprecation would have been better ?

The surprising comparison#

One candidate who was a Python developer wrote something like this:

if (cell[0][0] == cell[1][1] == cell[2][2]):
    return Winner

At first I thought this was logically flawed. Since cell[x][y] contains characters ('-', 'X', or 'Y'), the expression True == cell[2][2] would return False in JavaScript.

Python's chained expressions#

However, Python handles this differently through chained expressions. Python transforms the above into:

if ((cell[0][0] == cell[1][1]) and (cell[1][1] == cell[2][2])):
    return Winner

The code is indeed correct. Python has yet another way to confuse us all.

Best thing is to find out yourself.

First thing is to quickly write boiler plates around random number generation using the cohere sonet model.

async def generate_random_number(till: int):
    temperature = random.random()
    message = await client.messages.create(
        model="claude-3-5-sonnet-20240620",
        max_tokens=1000,
        temperature=temperature,
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": f"Generate a random number between 1 to {till}"
                        + ". Answer in the json format {number: int} only answer a valid json",
                    }
                ],
            }
        ],
    )
    random_number = json.loads(message.content[0].text)
    return random_number.get("number")


async def generate_random_x_times(times: int, till: int) -> List[str]:
    tasks = [generate_random_number(till) for _ in range(times)]
    random_results = await asyncio.gather(*tasks)
    return random_results


def plot_histogram(random_numbers: List[int]):
    # plot the random_numbers

Results for numbers#

Now how random were the results ?

For a random number between 1 to 10000 (Cohere), the model is settling amongst predicting amongst a handful of numbers

still majority of the numbers are between 7300 - 7400 range.

Let us try reducing the upper limit to 1000.

What is interesting is that in this case even trying multiple times gave the same distribution.

For upper limit 100, the number is always 73 and for 10 the number is always 7.

Results for strings#

Now let us twist the experiment a little bit and ask Claude to pick a random string from a given set of 10 names.

RANDOM_NAMES = ["Olivia", "Liam", "Emma", "Noah", "Sophia", "James", "Isabella", "Benjamin", "Mia", "Elijah"]

I ran it couple of times, the results in case were different but still centered around the names which appear in the beginning of the list.

Some takeaways#

• The number is always 7 for a window of 1 to 10 and 73 for a window between 1 to 100.
• The number range is weirdly centered around the number 7. Maybe because of the training data ?
• While asked to choose randomly from a list, GPT is more probable to select from the starting of the list.

Follow up questions#

• Would prompt engineering help here ?
• How are the results with other models - though I guess the behaviour would be the same
• How much dollars did I burn while doing this ?

Making response objects extensible#

Rather than returning primitive types directly, wrap responses in objects:

// Option 1 - not extensible
class DbUser {
    name: string;
    age: number;
}
function getUser(id: string): DbUser

// Option 2 - extensible
class APIUserResponse {
    user: DbUser
}
function getUser(id: string): APIUserResponse

The second option sounds better as you can simply add error state / tasks in the UserResponse object without requiring frontend and backend refactoring.

Making requests extensible#

Rather than accumulating function parameters, use objects for request handling:

// Hard to read, hard to extend
getUser('1', false, none, true);

// Self-documenting, easy to extend
getUser({
    id: '1',
    includeDisabled: false,
    includeTasks: true
})

The second approach is significantly more readable and maintainable.

Key takeaway#

For critical functions which you feel will change a lot in the future best to avoid primitive types directly in params and use extensible objects. Primitive types lack extensibility, while context-dependent objects can provide it.

automation git:(singla/add_missing_model) x gitrecent
38 minutes ago  singla/add_missing_model
25 hours ago    singla/bug_fixes_21st
25 hours ago    singla/track_order_revamp

While the shortcut is useful, I was afraid that I might just forget it so why not make a simple utility which prints a random shortcut whenever a terminal session starts.

Step 1: Create a tips file#

Create a file ~/tips containing useful shortcuts:

• git ac for amending and committing
• git uc for adding and committing
• git pullff for pulling without the no-ff flag
• gitrecent for displaying recent branches
• Wellness reminders (Pomodoro timer, water breaks, walks)

Step 2: Add to your shell config#

Add this to your .bashrc or .zshrc:

tip=$(shuf ~/tips | head -n 1)
echo "Tip of the session: $tip"

Now every time you open a terminal, you get a random useful tip or shortcut. Simple but effective.