September Update

Hello! Nat here, with another update from the StoryTime team.

If you are reading this, you can log in and take a look at StoryTime yourself right now. Note that in this version of the app the backlogs and stories you make are public!

If you want to use StoryTime for real and need a private workspace, let's talk, or if you want to use us but we're still missing something you need, let's talk: Send us an e-mail at team@storytime.team

This Month

• Fixed a bug where renaming the backlog would cause the backlog name to appear twice. (Fun fact about Phoenix LiveView, the technology that drives most of our web interface: Even if 2 elements aren't ever on the screen at the same time, all components need to have unique IDs, because the ID is how LiveView tells if it's successfully removed the component.)
• Updated Favicons and sharing previews. Now if you send someone a link to StoryTime on social media or your messaging service of choice, it should appear with a snazzy purple preview card. Let us know if this looks goofy anywhere!
• Mostly finished reorganizing the story cards. There's still some detail work to clean up.
• Fixed some interaction issues with scrolling and drag-and-drop, especially for moving stories between the stories and drafts areas.

Next Month

• Fixing some issues still remaining with story card layout. e.g. when stories are open the state buttons and the titles don't line up nicely, in some screen sizes the Copy Link button gets very wide.
• sharing URLs. Right now backlogs are accessible at /live_backlogs which is a little too implementation-y for a long term URL. We're currently planning on replacing this with /rooms.
• Some bugs with handling markers (which should probably be called "milestones.")

Investing in Testing

Something that isn't visible to ya'll but I thought would be fun to share: We've also been putting some work into making it very easy to run on our local developer workstations.

Because we use Stytch, and the local version of StoryTime expects to be logged in through Stytch's test environment, we need some Stytch environment variables set to start up. We store those environment variables in a shared 1Password vault, so in theory our direnv script can just load everything up when you start a new terminal session in the working directory, and then mix phx.new Just Works.

(If you've never used direnv you need to check out that link. It will change your life for real.)

#!/usr/bin/env/bash

set -euo pipefail

export STYTCH_PROJECT=$(op item get "Stytch" --fields "project_id" --reveal)
export STYTCH_SECRET=$(op item get "Stytch" --fields "secret" --reveal)

In practice there are several ways that this can go wrong. It's easy to install direnv without actually setting the shell hook up correctly, and the op command itself can fail in various ways. So in storytime/config/dev.exs we added this validation for that env var.

  case System.get_env("STYTCH_SECRET") do
    nil ->
      raise """
      environment variable STYTCH_SECRET is missing.
      You can get this from your Stytch dashboard at https://stytch.com/dashboard

      This should be automatically loaded from `op` by the .envrc

      Try running `op whoami` to check whether op is working correctly

      If it is, you probably need to finish setting up the direnv shell hook:
      https://direnv.net/docs/hook.html
      """

Under some conditions we also provide more detailed information about fixing the issue.

None of this is rocket science or anything but I bring it up because I think most teams underinvest in being able to set up arbitrary test environments. On many teams I've worked with it was basically impossible for anyone who wasn't a developer working on that specific team to set up their own instance of the application. I've seen teams record videos with instructions for how to set up the test environment instead of writing scripts.

Anyone who isn't a developer on that specific team ends up doing all their testing in a shared staging environment, and often ends up being dependent on developers to set up scenarios or fix that environment.

Investing in letting everyone run the application locally, even without detailed technical knowledge of the application, feels like more work in the short term, but it reduces the number of dependencies within the team.

More soon--

Nat, Coby, and Jesse