I'm not exactly sure what they got so right that I switched so easily. Here's my favourite stuff:

• The front-and-centre search bar is nice. The suggestions in the bar are useful.
• The vertical tabs and folders layout is something I didn't expect to love, but I can see people disliking it too. I know it isn't new-new, but the implementation is excellent. The folder implementation is awesome.
• Split views come in handy a lot more than I thought they would.
• The ability to quickly switch between "spaces" is awesome. Another not-totally-new thing which is done so well that it feels new.
• Little Arc, a minimal window version of the browser, is a really nice lightweight accompaniment to the primary browser when you only need to quickly peek at a link from within another app.
• Autoarchive saves me from myself. I rarely even remember what it cleared away. I don't need to see what I mistakenly thought was relevant yesterday. If I can't remember it today, it doesn't matter. Get rid of it. Thanks, Arc.
• It looks great. It's minimal without sacrificing anything at all. That's hard to do. They have some talented people working there.

Maybe it's the sum of all of these parts. I think what impresses me most is how intuitive and easy these features were to find despite the UI being fairly trimmed back by default. I didn't need to dig deep, I haven't had to wonder how to do anything, and when I've encountered new features I didn't need to think too hard to start using them. They're bringing fresh form and function to a stale software category.

Something else that inspires a lot of confidence and appreciation is how hard they work on it. Updates are frequent, and they're often meaningful updates. They communicate clearly. It's a browser that feels like someone cares about it. It isn't a utility manufactured exclusively to get people to use Google Search.

I don't often like software enough to write about it, but here I am. What an awesome take on the web browser. I hope they succeed and keep at it.

If you're an arc user and you think YouTube shorts are trash like I do, here's a great "boost" from the Browser Company themselves: No YouTube Shorts Plz.

These days I do most of my benchmarking in Go and Rust because it's implemented in their standard libraries so well; there's no reason not to do it. I'm not as diligent when it comes to TypeScript, so I wanted to revisit that old benchmark and try to devise a convention I'd actually use, regardless of which runtime I'm using.

Vitest offers an experimental bench command (which would be great to use because I use Vitest all the time) but it's fairly unstable still and uses tinybench under the hood, which I'm not as happy with as mitata. Deno and Bun have integrated mitata into their standard library which is great to see, but I don't typically use them. So, I'm going to set up a bare bones solution without any special tooling or conventions.

Caveats

It looks like mitata hasn't been updated for a while now, and while it's stable and works very well, there are some things some people might believe should be ironed out. There are some relatively basic features that would be great to see, like a reporter API or a timeout argument for groups or single benchmarks. Even so, it's well-featured for how simple and nice it is to use, and I'm not going to let that get in the way.

Although people tend to be resistant to the idea, each of these features can be implemented in a benchmark running abstraction, and my impression is that this might be what the creator of mitata thinks is the correct solution.

Setup

package.json

I like to write tests to ensure what I'm benchmarking is working properly and as expected, so I'm including Vitest; you can feel free to exclude it. I'm also including prettier out of habit and it's safe to leave out as well.

To run the benchmarks which will be written in TypeScript, I'm using typescript, glob, and ts-node:

{
  ...
  "scripts": {
    "build": "tsc --p tsconfig.build.json",
    "test": "vitest --reporter=verbose",
    "benchmark": "ts-node scripts/benchmark.ts",

  },
  "devDependencies": {
    "glob": "^10.2.7",
    "mitata": "^0.1.6",
    "prettier": "^2.8.8",
    "ts-node": "^10.9.1",
    "typescript": "^5.1.3",
    "vitest": "^0.32.2"
  }
}

tsconfig.json

The TypeScript configuration is typical except for a ts-node entry. This is used to modify the compilation for running scripts with ts-node, which we don't necessarily have to do for this example but under real-world circumstances I expect you would. Likely the most modern feature you need is top-level await, making it so you can await the run function exported from mitata. You can learn more about this ts-node convention here. I've also added a specific secondary config for builds, which avoids compiling any benchmarking or test files and provides an output destination:

{
  "compilerOptions": {
    "module": "es2022",
    "moduleResolution": "node",
    "target": "es2017"
  },
  "include": ["src"],

  "ts-node": {
    "esm": true,
    "experimentalSpecifierResolution": "node",
    "compilerOptions": {
      "module": "es2022",
      "target": "es2022"
    }
  }
}

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./javascript"
  },
  "exclude": ["**/*.test.ts", "**/*.bench.ts"]
}

The Benchmarking Script

I've created a ./scripts directory with a file called benchmark.ts. This file uses glob to find all of our benchmarks and execute them:

import { glob } from 'glob';
import * as path from 'path';

const executeFile = async (file: string) => {
  const absolutePath = path.resolve(file);
  return await import(absolutePath).then((module) => module);
};

try {
  const files = await glob('**/*.bench.ts');

  for (const file of files) {
    await executeFile(file);
  }
} catch (e) {
  console.error(e);
}

This is rudimentary at this point, but it's loaded with potential. Although mitata always outputs results to stdout for you to view in the terminal, you'll see later that it also provides a way for us to read and, if we choose to, write results from the benchmarks here.

Writing a Benchmark

This part is satisfyingly easy. In its most basic form, all you need to do is end a file's name with .bench.ts, wrap what you're measuring in bench() and then run() it:

import { run, bench } from 'mitata';

const helloTemplate = (name: string) => `hello ${name}!`;
const helloConcat = (name: string) => 'hello ' + name;

bench('hello (template string)', () => helloTemplate('world'));
bench('hello (concatenation)', () => helloConcat('world'));

await run();

Now we can use the bench script from package.json to run this benchmark:

$ yarn bench

benchmark                    time (avg)             (min … max)       p75       p99      p995
--------------------------------------------------------------- -----------------------------
hello (template string)  434.19 ps/iter  (284.9 ps … 902.06 ns)  366.8 ps   1.56 ns   2.27 ns
hello (concatenation)      7.62 ns/iter   (5.85 ns … 190.93 ns)   7.45 ns  20.89 ns  31.52 ns

run's Options

In the example above I'm using run with no options passed in, but there are several to choose from:

export function run(options?: {
  avg?: boolean,
  colors?: boolean,
  min_max?: boolean,
  collect?: boolean,
  percentiles?: boolean,
  json?: number | boolean,
}): Promise<Report>;

Note: I haven't figured out how collect does anything meaningfully different, but the rest are fairly straight forward.

run's Return Value

You might have noticed run returns a Promise<Report>; the report object looks like this:

interface Report {
  cpu: string;
  runtime: string;

  benchmarks: {
    name: string;
    time: number;
    fn: () => any;
    async: boolean;
    warmup: boolean;
    baseline: boolean;
    group: string | null;

    error?: {
      stack: string;
      message: string;
    };

    stats?: {
      n: number;
      avg: number;
      min: number;
      max: number;
      p75: number;
      p99: number;
      p995: number;
      p999: number;
      jit: number[];
    };
  }[];
}

The Report object struck me as the perfect way to store data about benchmarks after they complete. While the run's results will always output to stdout, you can use that as feedback while the actual results are piped into files for later use.

I haven't quite figured out how I want to use the reports yet, but I'd love to create a convention for identifying functions and their changes over time, and tracking their performance along with each diff. This could help point out major performance improvements or degradations during pull requests or other stages of development, but it wouldn't require any special effort from developers — you'd just need to write the benchmarks.

Benchmarking sumTwoLargestNumbers

Like the example above, this is about as easy. I'm starting with the two implementations I had in my post from 2017:

export type TwoOrMoreNumbers = [number, number, ...number[]];

/**
 * Sums the two largest numbers in an array of numbers with an O(n) algorithm.
 */
export const sumTwoLargestNumbers = (numbers: TwoOrMoreNumbers): number => {
  let largest: number, secondLargest: number;
  const length = numbers.length;

  if (length < 2) {
    throw new Error('Expected an array with at least 2 elements.');
  }

  // Assign our starting values
  largest = numbers[0];
  secondLargest = numbers[1];

  // Ensure we're starting with largest and secondLargest properly arranged
  if (largest < secondLargest) {
    largest = numbers[1];
    secondLargest = numbers[0];
  }

  // Loop through the numbers
  for (let i = 2; i < length; i++) {
    // If the new number is greater than largest, assign it to largest and
    // pass largest's value to secondLargest.
    if (numbers[i] > largest) {
      secondLargest = largest;
      largest = numbers[i];
    }
    // If the new number isn't greater than largest, check if it's still
    // greater than secondLargest.
    else if (numbers[i] > secondLargest) {
      secondLargest = numbers[i];
    }
  }

  return largest + secondLargest;
};

/**
 * Sums the two largest numbers in an array of numbers using an n*log(n) algorithm (picking from quicksort).
 */
export const sumTwoLargestNumbersSort = (numbers: TwoOrMoreNumbers): number => {
  // Is the array long enough to sum?
  if (numbers.length < 2) {
    throw new TypeError('Expected an array with at least 2 elements.');
  }

  // Sort the array large -> small
  numbers = numbers.sort(function (a, b) {
    return b - a;
  });

  return numbers[0] + numbers[1];
};

Then to write the benchmarks, I'm grouping each assessment with both implementations run with the same data:

import { run, bench, group } from 'mitata';

import {
  TwoOrMoreNumbers,
  sumTwoLargestNumbers,
  sumTwoLargestNumbersSort,
} from './index';

const randomNumber = () => Math.floor(Math.random() * 40);
const makeArrayOfLength = (length: number): TwoOrMoreNumbers => [
  1,
  2,
  ...Array.from({ length }, randomNumber),
];

const smallArray = makeArrayOfLength(3);
const mediumArray = makeArrayOfLength(100);
const largeArray = makeArrayOfLength(1000);

group('sumTwoLargestNumbers: Small arrays', () => {
  bench('for loop', () => sumTwoLargestNumbers(smallArray));
  bench('sort and pick', () => sumTwoLargestNumbersSort(smallArray));
});

group('sumTwoLargestNumbers: Medium arrays', () => {
  bench('for loop', () => sumTwoLargestNumbers(mediumArray));
  bench('sort and pick', () => sumTwoLargestNumbersSort(mediumArray));
});

group('sumTwoLargestNumbers: Large arrays', () => {
  bench('for loop', () => sumTwoLargestNumbers(largeArray));
  bench('sort and pick', () => sumTwoLargestNumbersSort(largeArray));
});

await run();

Now we can run our benchmarking script and see the results:

$ yarn benchmark
yarn run v1.22.19
$ ts-node scripts/benchmark.ts
cpu: Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz
runtime: node v18.16.0 (x64-darwin)

benchmark          time (avg)             (min … max)       p75       p99      p995
----------------------------------------------------- -----------------------------
• sumTwoLargestNumbers: Small arrays
----------------------------------------------------- -----------------------------
for loop         8.37 ns/iter   (6.97 ns … 285.34 ns)   8.38 ns  22.48 ns  34.41 ns
sort and pick  254.06 ns/iter   (182.44 ns … 1.36 µs) 265.35 ns  590.1 ns 604.48 ns

summary for sumTwoLargestNumbers: Small arrays
  for loop
   30.36x faster than sort and pick

• sumTwoLargestNumbers: Medium arrays
----------------------------------------------------- -----------------------------
for loop       221.24 ns/iter   (178.14 ns … 2.25 µs) 215.12 ns 603.46 ns 752.25 ns
sort and pick    2.41 µs/iter     (2.13 µs … 3.33 µs)   2.57 µs   3.33 µs   3.33 µs

summary for sumTwoLargestNumbers: Medium arrays
  for loop
   10.88x faster than sort and pick

• sumTwoLargestNumbers: Large arrays
----------------------------------------------------- -----------------------------
for loop         1.92 µs/iter     (1.79 µs … 2.82 µs)   1.93 µs   2.82 µs   2.82 µs
sort and pick   20.91 µs/iter    (17.04 µs … 1.45 ms)  21.34 µs  41.15 µs  66.25 µs

summary for sumTwoLargestNumbers: Large arrays
  for loop
   10.89x faster than sort and pick
✨  Done in 6.94s.

Incredible, right? What a huge difference between the two. The difference is smaller than it was 6 years ago, and my best guess at this point is that it's due to JIT optimizations.

Wrapping Up

mitata seems great so far. There are a few quality of life features I'd like to see, such as quieting it's writing to console.log — sometimes I'd like to take over there, outputting what I want to see instead. Even so, in a pinch it's still possible to either a) ignore default outputs or b) write your outputs to a file and pipe mitata's outputs into the void. Given how simple and effective it is, I'm really happy with it as it is.

In the future I'll hopefully write a bit about building around mitata to create useful tools for tracking performance over time, but I'll need to put some thought into making that useful and portable.

Feel free to take a look at the code on github.

accounts-base and accounts-ui are awesome packages that happen to make a heap of assumptions about how you're going to reason about your user's authentication and session management using a system called Accounts. That's alright though, because accounts-uiisn't necessarily intended to be the de facto way to provide access to the API of Accounts. It's there to get newcomers started, to help more experienced developers quickly prototype their ideas, and probably only occasionally remain a permanent fixture of the UI.

Here's a look at how we can replace the functionality of accounts-uiwith custom behaviours and appearances.

Get Your Packages

Before you can get going with this, you'll need to ensure you've pulled in both accounts-base and accounts-password. To do that, start up your terminal, change directories to your meteor project, and run these commands:

meteor add accounts-base

meteor add accounts-password

These are all you need for an impressive and comprehensive accounts management system in your app.

Meteor.loginWithPassword()

Logging in with a username/email and password is the most common way your user will interact with Accounts. It's straight forward and relatively easy to interact with. These are the steps we'll need to take to get it working:

1. Provide a form for the user.
2. Set up a listener for the form's submit event.
3. Collect the form values as arguments for loginWithPassword().

When calling loginWithPassword, you provide two, or optionally 3 arguments. First is the email or username, then the password. Finally you can provide a callback to handle the result of the login attempt.

The following examples assume you're using the iron:router package for the routing behaviours, but it isn't required - The Accounts system is totally decoupled from your application logic.

Step 1: Build the Template

To get started, we just need a template. Given you can literally put this anywhere in a meteor app, do whatever suits you here. I keep my accounts and authentication-related files in client/accounts/. You can style this template any way you'd like - It has no bearing on the functionality.

<!-- client/accounts/login.html -->

<template name="Login">
    <form id="login">
        <label for="login-username">User Name</label>
        <input type="text" id="login-username">

        <label for="login-password">Password</label>
        <input type="password" id="login-password">

        <input type="submit" value="Login">

        <p id="form-messages"></p>
    </form>
</template>

Step 2: Set Up The Event

Once our template is present, Meteor's ready to listen to events inside of it. We can follow the Meteor convention here and drop the event into the Template.Login.events hash.

/* client/accounts/login.js */

Template.Login.events({
    'submit #login': function(event, template) {
        // Log in logic
    });

    return false;
});

Step 3: Provide the Authentication Logic

What will our event do? Not much, really - Accounts does most of the heavy lifting here.

1. First we collect our username and password data from the form.
2. Then we call Meteor.loginWithPassword() with our credentials and a callback.
3. Inside of that callback we determine if the user authenticated and respond accordingly.

/* client/accounts/login.js */

Template.Login.events({
    'submit #login': function(event, template) {
        // 1. Collect the username and password from the form
        var username = template.find('#login-username').value,
            password = template.find('#login-password').value;

        // 2. Attempt to login.
        Meteor.loginWithPassword(username, password, function(error) {
            // 3. Handle the response
            if (Meteor.user()) {
                // Redirect the user to where they're loggin into. Here, Router.go uses
                // the iron:router package.
                Router.go('dashboard');
            } else {
                // If no user resulted from the attempt, an error variable will be available
                // in this callback. We can output the error to the user here.
                var message = "There was an error logging in: <strong>" + error.reason + "</strong>";

                template.find('#form-messages').html(message);
            }

            return;
        });

        return false;
    }
});

error.reason provides a string clarifying the reason for the error, i.e. 'User not found' or 'Incorrect password'.

So now what if your user wants to log out?

Meteor.logout()

This works predictably - It logs out the user currently associated with the client's session. My approach here was to listen on the entire site's layout for the click of any element with the class logout, and upon logging out, redirect to the login page. In the callback you provide, a Meteor.Error() object will be present if there was an error, so you can handle that condition if you'd like to.

As a side note, this is how you can set a default layout for your templates using iron:router which makes setting events or helpers a lot more DRY.

/* client/routes/router.js */

// Set a default layout template for all routes.
Router.configure({
  layoutTemplate: 'Layout'
});

// As opposed to explicitly setting it with each route...
Router.route('/my/route', function () {
  this.layout('Layout');
  this.render('MyPage');
}, {
  name: 'my.page'
});

Once we've done that, we can set a Template.Layout.events method which handles all clicks of an anchor with the class logout. It can go in the navigation, in a dropdown menu, within some help text, whatever you like so long as the page uses the correct layout. If you choose to make logging out specific to a template, you can use the exact same code within a different template's events hash.

/* client/layout/events.js */

Template.Layout.events({
  'click a.logout': function() {
    Meteor.logout(function() {
      // Redirect to login
      Router.go('/login');
    });

    return;
  }
});

That is the most basic interaction with Accounts, but there's plenty more you can do. Up until this point, all of the examples make the assumption your application already has users. But what if you don't? How do you go about creating users, or creating a custom convention for creating users?

Creating Users with Accounts.createUser()

This feature is slightly more nuanced than the previous ones. Its behaviour isn't consistent across the client and server, so the context of execution matters. It also allows quite a few callbacks to help with things like validation or altering the user before sending the data to the server.

On the Client

When you create a user on the client, Meteor will automatically log you in as that user. If you've used accounts-ui, you probably noticed that the 'Create account' link on {{> loginButtons}} which provides a 'Password (again)' field will immediately log you in as that user once you submit the form. Because of this behaviour, it requires a username anda password so the user can authenticate immediately, and then authenticate again at a later date.

The idea here is that in the most basic use case, someone can arrive at your app, enter credentials, and start using the app immediately as an authenticated user. There are options available to tailor that process, though. Accounts has support for verification emails for example, or you can implement your own approval process.

On the Server

The server is less strict and doesn't require a password. This can be set arbitrarily at a later date using Accounts.setPassword(userId, newPassword). You can also allow a user to choose their own password at a later date by triggering Accounts.sendEnrollmentEmail(userId), which is highly configurable... But I won't go into that here.

Creation from the Client

In my own case, I only needed to create users from the client using a form which covered the minimum requirements and provided an optional form for a user profile. Similar to authenticating, all we need here is:

1. A template with a form
2. A listener for the template's form submission event
3. Logic to use the form data with Accounts.createUser()

Step 1: The Template and Form

This template has a form with a field for the username, email, password, and profile values. Yours could be just about anything - The profile object in Accounts doesn't really care what exists there, and validation is entirely up to you.

<!-- client/accounts/create-user.html -->

<template name="CreateUser">
  <form id="create-user">

    <fieldset>
      <legend>Credentials</legend>
      <label for="create-user-username">User Name</label>
      <input type="text" id="create-user-username" placeholder="SteamDonkey2014">

      <label for="create-user-email">Email</label>
      <input type="text" id="create-user-email" placeholder="you@domain.tld">

      <label for="create-user-password">Password</label>
      <input type="password" id="create-user-password" placeholder="Password">

      <label for="create-user-password-confirm">Confirm Password</label>
      <input type="password" id="create-user-password-confirm" placeholder="Confirm Password">
    </fieldset>

    <fieldset>
      <legend>Profile (Optional)</legend>
      <label for="create-user-name">Name</label>
      <input type="text" id="create-user-name">

      <label for="create-user-astro">Astrological Symbol</label>
      <input type="text" id="create-user-astro">

      <label for="create-user-newsletter">Subscribe to Newsletter</label>
      <input type="checkbox" id="create-user-newsletter">
    </fieldset>

    <input type="submit" value="Sign Up!">
  </form>
</template>

Step 2: Event Prep

Like before, setting up the event is simple.

/* client/accounts/users.js */

Template.CreateUser.events({
  'submit #create-user': function(event, template) {
      // Code goes here
    });

    return false;
  }
});

Step 3: Event Logic

We'll need a bit of boilerplate to get the data from the form, but once we've done that we're ready to fire off the data and see what happens. If your data is good and the user is created, you should be logged in as the user you just created.

/* client/accounts/users.js */

Template.CreateUser.events({
  'submit #create-user': function(event, template) {
    var user;

    // Collect data and validate it.

    // You can go about getting your data from the form any way you choose, but
    // in the end you want something formatted like so:
    user = {
      username: formUsername,
      password: formPassword,
      email: formEmail,
      profile: {
        name: formName,
        // etc...
      }
    }

    // Post the user to the server for creation
    Accounts.createUser(user, function (error) {
      if (error) {
        // :(
        console.log(error);
      }
    });

    return false;
  }
});

Worth noting is that if you have validation requirements beyond what Meteor enforces and you aren't performing validation before triggering createUser, you can run validation logic before a user is created using Accounts.validateNewUser(). If you return true from this method, Meteor will proceed with trying to create the user. If you return false, the process is aborted and Accounts.createUser() will return in the optional callback with an error. You can set the error reason by throwing your own Meteor.Error(), like so:

/* client/validation/user.js */

// Validate new users
Accounts.validateNewUser(function (user) {
  // Ensure user name is long enough
  if (user.username.length < 5) {
    throw new Meteor.Error(403, 'Your username needs at least 5 characters');
  }

  var passwordTest = new RegExp("(?=.{6,}).*", "g");
  if (passwordTest.test(user.password) == false) {
    throw new Meteor.Error(403, 'Your password is too weak!');
  }

  return true;
});

Remember error.reason in the login process? This is how you access your custom messages when throwing errors in Meteor.Error. If you'd like, you can let Meteor generate a default error by simply calling Meteor.Error with no arguments.

Finally, if you want to do work on users before they're persisted to the database, there's another Accounts method called onCreateUser()which allows you to push the user object through a callback before it hits the server. It also allows you to throw an error to abort creation, but its purpose isn't validation, so if errors occur they should be for other reasons.

What's Next?

To really round this out, we still need a couple of things. Users should be able to reset their passwords and recover their passwords for convenience and security.

Reset a Forgotten Password

I'll assume by now that you're comfortable with Meteor conventions and I'll outline these tasks quickly, showing the templates and then corresponding code.

<!-- client/accounts/forgot-reset-password.html -->

<template name="RecoverPassword">
  {{#if resetPassword}}
    <form id="set-new-password">
      <label for="new-password">New Password</label>
      <input type="text" id="new-password" placeholder="Try not to forget this one.">

      <input type="submit" value="Set New Password">

      <p id="form-messages"></p>
    </form>
  {{else}}
    <form id="forgot-password">
      <label for="user-email">Email</label>
      <input type="text" id="user-email" placeholder="Email">

      <input type="submit" value="Get Reset Password Instructions">

      <p id="form-messages"></p>
    </form>
  {{/if}}
</template>

Accounts.forgotPassword() only requires and email, so this template is dead simple. Once we've wired this thing up, Meteor will send an email to the given email address if it's valid.

/* client/accounts/recover-password.js */

// Ensure we have the token to pass into the template when it's present
if (Accounts._resetPasswordToken) {
  Session.set('resetPasswordToken', Accounts._resetPasswordToken);
}

Template.RecoverPassword.helpers({
  resetPassword: function() {
    return Session.get('resetPasswordToken');
  }
});

Template.RecoverPassword.events({
  'submit #forgot-password': function(event, template) {
    var email = template.find('#user-email'),
      message;

    // You will probably want more robust validation than this!
    if (email) {
      // This will send a link to the address which, upon clicking, prompts the
      user to enter a new password.
      Accounts.forgotPassword(email);
      message = 'Sent a reset password link to ' + email + '.';
    } else {
      message = 'Please enter a valid email address.'
    }

    // Inform the user.
    template.find('#form-messages').html(message);

    return false;
  },
  'submit #set-new-password': function (event, template) {
    // Proper decoupled validation would be much nicer than this
    var password = template.find('#new-password').value,
      passwordTest = new RegExp("(?=.{6,}).*", "g");

    // If the password is valid, we can reset it.
    if (passwordTest.test(password)) {
      Accounts.resetPassword(
        Session.get('resetPasswordToken'),
        password,
        function (error) {
          if (err) {
            template.find('#form-messages').html('There was a problem resetting your password.');
          } else {
            // Get rid of the token so the forms render properly when they come back.
            Session.set('resetPasswordToken', null);
          }
        })
      });
    } else {
      // Looks like they blew it
      template.find('#form-messages').html('Your password is too weak!');
    }

    return false;
  }
});

And there you have it - Password recovery. Finally, for routine password updates for users, it's as simple this:

<!-- client/accounts/change-password.html -->

<template name="ChangePassword">
    <form id="change-password">
        <label for="current-password">Current Password</label>
        <input type="text" id="current-password" placeholder="Current Password">

        <label for="new-password">New Password</label>
        <input type="text" id="new-password" placeholder="New Password">

        <label for="new-password-repeated">Repeat New Password</label>
        <input type="text" id="new-password-repeated" placeholder="Repeat New Password">

        <input type="submit" value="Update Password">

        <p id="form-messages"></p>
    </form>
</template>

You don't have to force the user to repeat their new password, but it's certainly a good idea. If anything it just prevents using the forgot password process again if they typed something wrong, at only a minor inconvenience. Finally, here's all we need to do to change it:

/* client/accounts/change-password.js */

Template.RecoverPassword.events({
    'submit #change-password': function(event, template) {
        var currentPassword,
            newPassword,
            newPasswordRepeated;

        currentPassword = template.find('#current-password');
        newPassword = template.find('#new-password');
        newPasswordRepeated = template.find('#new-password-repeated');

        // You will want to validate your passwords better than this
        if (newPassword !== newPasswordRepeated) {
            template.find('#form-messages').html("The new passwords don't match!");

            return false;
        }

        Accounts.changePassword(currentPassword, newPassword, function(error) {
            if (error) {
                message = 'There was an issue: ' + error.reason;
            } else {
                message = 'You reset your password!'
            }
        });

        // Inform the user.
        template.find('#form-messages').html(message);

        return false;
    }
});

Anyway, that's plenty to get your feet wet doing manual account management with Meteor. There's so much more you can do to customize your app, and the best way to find out how is reading the docs! With this foundation, the rest of it is a breeze.

The problem went a bit like this:

Write a function that efficiently takes an array of integers and returns the sum of the two largest integers in the array. The array can be made up of any valid integers, and the length is unknown (but could be very large).

The problem could be solved with either PHP or JavaScript, and I chose JavaScript.

My first thought was that this could be done two ways (that I know of) which I could implement properly in the test scenario. One is to sort the array in descending numeric order and pluck the top 2 elements. The other was to use a for loop to run through the array and continuously pull larger values until I hit the end and had the top 2 remaining. What's better, and why? What's the context of the usage cases? Does it need to scale?

Well, the problem states the arrays 'could be very large'. Since I had a (self imposed) time limit I decided to implement something:

• Concise
• Reasonably fast
• Easy to understand

This would be trivial using Array.prototype.sort().

The Initial Solution

/**
 * Sums the two largest numbers in an array of numbers.
 *
 * @param  {Array} numbers An Array of Numbers
 *
 * @return {Number}        The sum of the two largest Numbers
 */
function sumTwoLargestNumbers(numbers) {
    // Ensure the array is sorted large -> small
    numbers = numbers.sort(function (a, b) {
        return b - a;
    });

    return numbers[0] + numbers[1];
};

sumTwoLargestNumbers([20, 5, 13, 7, 200]);
// > 220

It's consice and clean, and it appears to work, so what's wrong with it? Well, I missed something pretty important:

return numbers[0] + numbers[1];

I'm adding numbers[0] and numbers[1] without ensuring those indexes will be there. That's an easy fix by adding a condition like so:

/**
 * Sums the two largest numbers in an array of numbers.
 *
 * @param  {Array}  numbers An Array of Numbers
 *
 * @return {Number}        The sum of the two largest Numbers
 */
function sumTwoLargestNumbers(numbers) {
    // Is the array long enough to sum?
    if (numbers.length < 2) {
      throw new Error('Expected an array with at least 2 elements.');
    }

    // Sort the array large -> small
    numbers = numbers.sort(function (a, b) {
        return b - a;
    });


    return numbers[0] + numbers[1];
};

sumTwoLargestNumbers([20, 5, 13, 7, 15]);
// > 35 (20 + 15)

sumTwoLargestNumbers([5]);
// > Error: Expected an array with at least 2 elements.

That seems better, but there's still another problem to address.

Inefficiency With Array.prototype.sort()

This appears to be a nice solution because it is, for the developer, highly practical to write, maintain, and use. If you'd only ever use this function on small arrays I think you could stick with it!

The thing is, being concise and easy to understand here is hiding a lot of algorithmic complexity. I haven't reduced the amount of work done by writing less code. Instead I've increased it by outsourcing the workload to a pretty heavy algorithm that isn't really intended to be used for this problem. It's doing work that the function doesn't imply it should do or even needs to do; sorting the array is pointless outside of convenience. This method only simplifies my job by offloading work to an algorithm which isn't doing the right work for our task. That seems like bad programming, and in the scope of this assessment, it is.

The Second Solution

Later in the day, the person who posed the initial test question asked why I chose sorting over using a for loop. I didn't have a great answer apart from what is overtly beneficial about the sort solution. It's easy, it's clean, and it works.

Needless to say it became pretty clear that I should reconsider my approach. I wasn't entirely wrong to choose sort, but I also wasn't right either. I needed a better answer and a better understanding of the problem. I sat down and wrote out the following for loop solution in around 20 minutes. My sorting function took a total of about 15, for comparison — not as much time saved as I would have guessed.

/**
 * Sums the two largest numbers in an array of numbers.
 *
 * @param  {Array}  numbers An Array of Numbers
 *
 * @return {Number}        The sum of the two largest Numbers
 */
function sumTwoLargestNumbers(numbers) {
    var largest,
        secondLargest,
        length = numbers.length,
        // Start i at 2 so we skip the first indexes we've already used for
        // largest and secondLargest
        i = 2;

    // Is the array long enough to sum?
    if (length < 2) {
        throw new Error('Expected an array with at least 2 elements.');
    }

    // Assign our starting values
    largest = numbers[0];
    secondlargest = numbers[1];

    // Ensure we're starting with largest and secondLargest properly arranged
    if (largest < secondLargest) {
        largest = numbers[1];
        secondLargest = numbers[0];
    }

    // Loop through the numbers
    for (let i = 0; i < length; i++) {
        // If the new number is greater than largest, assign it to largest and
        // pass largest's value to secondLargest.
        if (numbers[i] > largest) {
            secondLargest = largest;
            largest = numbers[i];
        }
        // If the new number isn't greater than largest, check if it's still
        // greater than secondLargest.
        else if (numbers[i] > secondLargest) {
            secondLargest = numbers[i];
        }
    }

    return largest + secondLargest;
};

sumTwoLargestNumbers([20, 5, 13, 7, 15]);
// > 35 (20 + 15)

sumTwoLargestNumbers([5]);
// > Error: Expected an array with at least 2 elements.

It turns out the code isn't that much larger or hard to read. My concerns about writing an excessively verbose solution were unfounded.

The logic from the top down is straight forward and we get the same behaviours as we did with sort. Now we also have the benefit of only looking at smaller numbers two times at most here: if (numbers[i] > largest), and then here: else if (numbers[i] > secondLargest). Our worst case scenario for performance is drastically better than the sort solution.

O(n) vs. O(n log n)

When we iterate through our array with a for loop, we have the benefit of knowing that if summing an array of 100 elements takes 5ms, then summing 500 elements should take something like 25ms. This is because the complexity of the task doesn't increase at all. Our work load has increased proportionally so if we have five times the work to do, we can expect our execution time to increase by around five times. This is O(n), and it's nice to have when possible.

When we use Array.prototype.sort(), we're passing the workload to the browser's implemented sorting algorithm. As I understand, most browsers use the merge sort algorithm which has a complexity of O(n log n). It's guaranteed to be significantly slower than using a for loop in my function.

What Are the Implications?

Unless this function is meant to sum relatively small sets of values, you shouldn't use the sort approach.

That's not to say native sorting is inherently slower than using for in all cases. In my case, it's only faster to use for because we're avoiding a so much unnecessary work by not sorting the rest of the array. All we do is continuously flip through our elements and remember the biggest ones we saw. That's a simple task. Sorting the entire list is not a simple task, on the other hand.

I'm sure the sort algorithm is implemented extremely well. It's just the wrong tool for the job.

Profiling Our Solutions

I decided to take my experiment to jsperf (now defunct 🫠) and see what the difference is. It's not a perfect test as it could be benefited by more samples and input variations... But its initial results are telling. The sort method is evidently ~97% slower.

With a smaller array, perhaps with 5 to 10 elements, we'd probably see results with it being closer to 65% slower. This is on account of the sort algorithm's workload not increasing proportionally as the for loop's workload does; the performance will decrease as the workload increases.

That's probably acceptable for small tasks in the client. But the test above uses only 816 elements - What if you needed to sum 10,000 elements this way, and you have to do it frequently? It's clear that the for loop would be essential for getting acceptable performance from this type of function.

Lesson Learned

Don't be afraid to get your hands dirty, even if the problem seems too simple to warrant a more complex solution. It's always worth considering or even pursuing other options.