Forem: Steve Frank

Claude was finally smarter than me

Steve Frank — Thu, 26 Feb 2026 14:02:06 +0000

Elixir, Phoenix, Ash project

Got 100's of text fields spread across 20+ Ash Resources. Finally got around to enforcing some sane max_length constraints on them.

Simple prompt, "Add sane max_length constraints to all Ash Resource text fields, based on their implied meaning"

Few minutes later, it was done, and after a quick review there weren't any changes needed. Next up, add that same max_length as maxlength on the corresponding inputs fields.

Simple prompt: "Now apply those max_length constraints to the field's corresponding input boxes"

Which I thought I was going to get 100+ edits. Well, wrong. It thought for 30s or so, and ultimately made a nice simple change in one place, core_components.ex

  def input(%{field: %FormField{} = field} = assigns) do
    errors = if Phoenix.Component.used_input?(field), do: field.errors, else: []

    assigns
    |> assign(field: nil, id: assigns.id || field.id)
    ...
    |> maybe_inject_maxlength(field)
    |> input()
  end

  ...

  @maxlength_types ~w(text email tel url search textarea)

  defp maybe_inject_maxlength(%{type: type, rest: rest} = assigns, field)
       when type in @maxlength_types and not is_map_key(rest, :maxlength) do
    case get_field_max_length(field) do
      nil -> assigns
      max_length -> %{assigns | rest: Map.put(rest, :maxlength, max_length)}
    end
  end

  defp maybe_inject_maxlength(assigns, _field), do: assigns

  defp get_field_max_length(%FormField{} = field) do
    with %{source: %AshPhoenix.Form{resource: resource}} <- field.form,
         %{constraints: constraints} when is_list(constraints) <-
           Info.attribute(resource, field.field) do
      Keyword.get(constraints, :max_length)
    else
      _ -> nil
    end
  end

Absolutely brilliant. I didn't even think of that. It used one of Ash's superpowers, the DSL introspection, to just make this work.

24hrs later I am still dazed. Been using ChatGPT for 2 years or so, Claude for 9 months. And this is maybe only the 3rd time that I was actually left a bit stunned. Like, either I'm losing it, or it really is just better than me.

Sanity Checks

Steve Frank — Mon, 05 Jan 2026 14:57:21 +0000

Weird things happen in prod

I don't care how much test coverage you have, or how many database transactions you use, or how many years you have been coding: weird things happen in prod.

Scripts that perform sanity checks on your databases will catch these oddities before they become a major issue. Or at least, that's the idea, and it has been true for the past two decades for me.

Any time you introduce business rules that can't (or not easily) be enforced directly by the database, add a basic check that scans for records that are not following those rules.

Example 1: Basic attribute values

Rule: When state == 'paid' then paid_at should not be null.

Simply write a query that selects all records where state == 'paid' and paid_at is null and send them to your alerting system.

Example 2: X-Tenancy Mismatch

Object X belongs_to Object Y and both should have an Owner Z

Maybe this check alerts PagerDuty since it could be disastrous.

Other Examples:

All users belong to at least 1 organization
All organizations have at least 1 user
Users set to super admin only belong to Org Foo (maybe this one runs every 5min)

Additional Tips:

Feel free to limit checks to records that have been created or updated in the past 48 hours
Ignore archived records if applicable
Run the checks manually before deploying to prevent a flood of errors for bad sanity check logic. Sometimes I forget about an edge case that is actually valid.

My Failed Student Housing App

Steve Frank — Tue, 23 Apr 2024 16:53:55 +0000

tldr; I have a moderate sized PoC elixir code base collecting dust that will never be used again, and hopefully it has something someone will need.

Background

I've been looking into different markets for my next startup. One that stood out was Student Housing software for colleges and universities. What intrigued me initially was that the #1 company bought #2 and #3 in 2022, so the options for colleges dwindled to just a few. And the #1 can now charge 4-5x resulting in 6 figure yearly bills!

Certainly I can build something that I could charge significantly less that would benefit the few thousand smaller colleges that couldn't afford that price gouging.

While I was deep in customer discovery, I figured I would also build out a PoC to show directors at the school to let them know I deeply understood the problems they faced. If they could see that, then maybe they would give me a shot.

The Stack

Elixir
Phoenix + LiveView
TailwindCSS (with Flowbite)
Postgres
Ash (2.0, 3.0 wasn't out yet)

I always need to be learning, so I took the chance to finally learn Ash. Something about it screamed "Yes!" to me.

My previous passion project was ClickDuel and I used that to really dive into Elixir and LiveView. Take a look, my kids and I still love using it. So the housing app was my chance to take a deep dive into Ash.

Ash

As with any new tool, there is a ramp up period. Ash was no different. During the 4 months I worked on this project, as I struggled with doing some basic stuff (like Phoenix Forms using Ash) I kept asking myself, "Is Ash really gonna make me faster in the long run?" Now that I am on 2 other new projects, both using the same stack as above, I can confidently say yes. I am glad I had the time to learn Ash. The speed at which I got the new stuff up was crazy fast. And 3.0 introduces domains, which encapsulate code so much better.

I have used ORMs in PHP, C#, Ruby, and NodeJS, so I am well versed in the problems of figuring out your domain and data structures and mapping that to the tool du jour. Ash is not an ORM, but it serves the problem, and I like Ash's approach so much better than others.

The team is really responsive answering questions in their forum.

For my deployment model, every school would need to be isolated in the database, and Ash's multi-tenancy approach made this dead-a$$ simple to implement. Like, a few lines of code.

Ash also has a powerful policy system to enforce access to data, but it was just too much to learn, so I constantly just disabled it.

User Defined Schemas

The thing with Student Housing is that an immense amount of it is based on dozens of forms. A form to request housing, a form for your profile, a form to be an RA, a form to switch rooms, a form to submit a maintenance ticket. You get the picture.

But the problem is that every single school has their own fields and structure and workflow for these forms. So I went with our buddy, JSON Schema. There is a decent chunk of code dealing with that. Chances are, I ran into the same problem as you, if you're using JSON Schema...

Other tools

Don't reinvent the wheel!

Flowbite

One of the things that I am happy to drop $ on are good looking UI components. Flowbite does a great job with theirs. Dark mode just works. Finally got a good looking sidebar to quickly view an item; always wanted to implement that. Though I will say their dropdown logic is flaky.

AG Grid

I made extensive use of AG Grid. There are LiveView hooks and whatnot showing how I loaded data, and stylized different types like bools, links, and status.

JSON Editor

This provided a simple drop-in to edit JSON Schemas. Visual drag n drop was out of scope for the PoC, though I did try some out. O' lord did I try them out. Days of my life I want back.

ExJsonSchema

Great JSON schema validator.

SortableJS

This allowed me to provide a way to sort items in the UI.

react-querybuilder

There is no chance I am using this properly. I don't understand React at all (I'm a Vue dev). But I needed to allow users to build complex queries, and this is a no-brainer tool to use for that purpose. The challenge was using it in LiveView.

JSX

I think it was just changing to --target=es2020 and I was able to use .jsx files alongside .js which made some of the Javascript work easier.

Finally, the code

Please keep in mind that this was implemented as a proof of concept. I just needed to get some stuff working, and not necessarily working well, and certainly not with any tests.

Many times, I went with whatever approach worked, and moved on with life, so please be mindful of that if you browse the code. Though, if I did something stupid, please let me know so I can fix it in future projects I work on.

https://github.com/lardcanoe/housing-app

If I get 10 likes, or some comments, I'll take the time to document how to get it running locally. It's should be pretty typical for an elixir app though...

I am more than happy to expand on any topic above, or others. Just leave a comment.

Migrate from Heroku to Azure

Steve Frank — Fri, 17 Dec 2021 18:40:49 +0000

The overall goal was to get our staging site running 100% in Azure. This will all work for production, but you'll want to first do the work for a dev/qa/staging environment, and then use something like terraform to deploy production.
I went into this with zero experience in Azure. Please leave a comment for anything I should fix.
I'm writing this blog a week after I got things working, and I didn't take notes, so some parts are light on details.
After a few days into the work, I truly understood the simplicity that I get from Heroku, and the extra $ you spend is well worth it if you don't have a dedicated DevOps team.

Heroku

Here's our setup in Heroku:

Nodejs v14
- Dynos for Web Requests
- Dynos for background workers
Postgres + Redis
VueJS frontend
Custom domain, taking advantage of Heroku managing certificates
CodeshipCI for builds
Heroku Scheduler for cron

Example Procfile:



release: node_modules/.bin/sequelize db:migrate && node_modules/.bin/sequelize db:seed:all
web: node --optimize_for_size --max_old_space_size=1048576 index.js
worker: env WEB_MEMORY=1024 WEB_CONCURRENCY=2 node --optimize_for_size --max_old_space_size=1048576 worker.js
worker-pm: env WEB_MEMORY=2048 WEB_CONCURRENCY=2 node --optimize_for_size --max_old_space_size=2621440 worker.js
worker-p14gb: env WEB_MEMORY=8192 WEB_CONCURRENCY=2 node --optimize_for_size --max_old_space_size=8388608 worker.js

Azure

I was given an Azure subscription to use, so I don't have instructions or experience w/ signup
I was nudged to use a Web App (even though when I was told this I had no clue what that meant), so that was the path I took.
In Heroku, we have 2 independently scalable systems: web and workers. I want to keep that when moving to Azure, thus each will have its own Web App.

Azure Resources

Notes:

Keep track of the region you start with and make sure to create them all in the same region.
There is an App Insights feature that I didn't look into, but I did enable it on everything I created. Probably easier to do it when creating instead of later...

Provisioning:

Create a resource group for all the infrastructure to live in
Create a Web App for each service; in our case we'll have one for web and one for workers. As part of the creation, you will need to create a Web App Plan for each, which is basically the same as the dyno type from Heroku. Choose one similar to what you had. (You can change the size and type later if you get this wrong.)
- Just like with Heroku, you'll be able to tail logs and ssh in to help with debugging and monitoring.
- I've only used the portal to do this; I have not tried the azure cli yet. You'll see "SSH" and "Stream Logs" in the left menu of the selected Web App.
- Under Settings / Configuration, add a new Application Setting: OPENSSL_CONF = /etc/ssl/ to deal with openssl 1.1.1.d failing on the eventually provisioned web app containers.
Provision a new Azure Database for PostgreSQL, appropriately sized and the correct version (or use latest). When and how to load the data from Heroku's database is up to you. Heroku's managed postgres databases don't give access to replicate, which is why I performed a final backup and then a restore. I'm also moving over our staging site so I can be a bit more cavalier with the process:
- Perform a backup, and then use pg_restore to perform the restoration into the new Azure instance. If this was production, you'd want to put your app in maintenance mode before doing that backup.
- On the Networking page of the new instance, you can grant your home's IP access to the db.
- pg_restore --verbose --no-owner -h <server name>.postgres.database.azure.com -U psqladmin -d <db_name> heroku_database.dump
- Note: If your provisioned username contains an @ like pgadmin@servername and you need to use that in a URI connection string, then encode it to pgadmin%40servername, so the resulting connection string is postgres://pgadmin%40servername:password@servername:port/dbname
Provision Azure Cache for Redis
- The Access Keys page has the connection string info
Provision a Key Vault, and add your secrets
- We'll use this for very secret stuff.
- You can run heroku config -j --app <name> to get a JSON dump of your secrets from Heroku.
- There are a few ways to get secrets to your Web Apps:
  - You can browse to the Web App, go to the Configuration page. and manually add or import the json (make sure to merge and not replace since Azure puts some settings there.)
  - Or you can have the release pipeline we'll make later pull settings from the key vault and push them into the Web App.
  - For simplicity, I went with just merging them into the Web Apps by hand (though I did use the Advanced method that exposes the JSON that can be cut/pasted).
  - Web Apps have a special section for storing connection strings (like for the database or redis) and for simplicity of this initial transition I chose to skip using it.

Azure DevOps - Build Pipeline

We're now going to replicate most of the magic that happens when you git push to Heroku.

Note: At pretty much every step going forward I will just assume you'll press the "Save" button.

Switch over to Azure Devops, https://dev.azure.com/, and create a project if you don't have one yet.
Push up your existing code. You're adding a new remote in your local git repo so you can still git push heroku main as well as now git push azure main (or whatever you call the remotes).
Now we need a new Build pipeline. This is all the magic that Heroku does for you in their buildpacks. Create an azure-pipelines.yml file in the root of your repo and push that up to Azure so you can create the Build pipeline from it.

This pipeline handles a few things:
- Caching two different npm's (i.e. node_modules) because the backend and client side are in the same repo.
- Installing postgres and redis as services so our unit tests have real servers to work against.
- It handles running and publishing mocha unit tests.
- Dealing with phantomjs nonsense since the build image contains phantomjs so npm install doesn't download the binary, thus later preventing my Web App from having phantomjs. This was a full day of my life wasted, so you're welcome to anyone who else stumbles on this craziness.
- And finally, we zip everything up and publish it, which I guess is similar to Heroku generating a 250MB+ slug. I take an extremely simplistic approach and zip it all. You could exclude tests for example. ALL of this will wind up on your Web App, so if you really can't have certain data on public facing servers, this is your chance to prune before archiving.

Azure DevOps - Release Pipeline

Now that we have the Build generating a giant zip file containing our entire codebase + node_modules + any static files created from npm build of our client, we can now deploy it to our Web Apps.

I'd love to share a json file to import the pipeline, but the one it generates is like 20k lines long and contains tons of unique guids, so instructions and screenshots it is!
Final pipeline:

Create a new empty Release pipeline

Artifacts

Add an artifact

Variables

Our database migration task below needs access to our database to run migrations and seeds. This lets us bring in secrets from our vault.

Switch over to Variables and then select "Variable groups"
Click "Manage variable groups" and bring in the vars you need from the vault.
- I don't get why some things can use underscores and others can't, so you'll see in my examples stuff named DB-HOSTNAME whereas the env var I need is DB_HOSTNAME
Click "Link variable group"
- I didn't realize I needed to do this and lost a few hours wondering why my variables weren't accessible. I want to give some Azure PM the evil-eyes for this.
Switch to "Pipeline Variables" and add what you need.

Note: When you are done with the next few steps you can come back and scope variables to certain stages.

Database Migration Stage

Create a new stage call "Database Migration"
Click "Agent Job" and change Specification to "ubuntu-latest"
Create an "Extract Files" tasks
Create a Node Installer tasks (just in case)
Create a Bash task. You'll need to tweak env vars to what your app expects
Create another Bash task (yes, you could just && with the task above instead of making a new one. I like having it be clear exactly which part broke.)

Deploy Stages

We are going to deploy to web and workers in parallel.

This stage's agent can run on windows-latest
- Startup command
- The image Azure uses doesn't work with phantomjs, so we need to install some packages, and unzip our cached phantomjs from the build.
- Again, you're welcome for knowing how to install custom fonts



apt-get update -qq && apt-get install libfontconfig libssl-dev -yqq && cp -r /home/site/wwwroot/.fonts /root/ && unzip -oqq /home/site/wwwroot/bin/phantomjs.zip -d /home/site/wwwroot/bin && node --optimize_for_size --max_old_space_size=2621440 index.js

Deploy Azure App Service web
Now duplicate this stage for workers. You may need to tweak the js file used to start.

Create a Release

Cron

I'll give migrating the Heroku Scheduler to Azure its own section. Since I used Linux Web Apps for everything, I guess I'm not allowed to create WebJobs? Kinda lame. Anyway, I saw a few approaches, most notably installing cron on your Web App during startup. Since I have more than 1 instance running, I don't want cron running more than once. I chose to use a Function App which allows me to define a function that runs on a schedule. This turned out to be rather useful.

Provision a new Function App
Create a new function, e.g. DailyTrigger, with a schedule like 0 0 6 * * * to run daily at 6am UTC.
Write some code to do what you need. I went with C# for simplicity. Triggering cron for us is simply a POST to an internal endpoint. (There is code to ignore the cert because I haven't implemented SSL certificates in my Web App yet.)



    using (var httpClientHandler = new System.Net.Http.HttpClientHandler())
      {
        httpClientHandler.ServerCertificateCustomValidationCallback = (message, cert, chain, sslPolicyErrors) => {
          return true;
        };

        var webhookURL = "https://....";
        using var client = new System.Net.Http.HttpClient(httpClientHandler);
        client.DefaultRequestHeaders.Add("Authorization", "********");
        client.GetAsync(webhookURL).Wait();
      }

      log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");

Multi-tenancy Leaks IRL

Steve Frank — Thu, 17 Sep 2020 17:39:54 +0000

The dozen or so articles and threads I've read over the years regarding implementing multi-tenancy in SaaS platforms fail to cover areas outside of the database itself. When it comes to a cross-tenant data leak, chances are it won't be an issue at the database level that gets you.

Cache Layer

Most architectures have a caching layer (e.g. Redis) in use for all sorts of purposes. Chances are you are not deploying a redis/memcache server for each tenant, so you're probably using the common practice of putting the unique tenant id in the key, maybe at the beginning, such as "1234:users" for tracking users of each tenant.

What happens if the variable used to put the tenant is wrong? Such as an undefined variable in JS: ${teantId}:users instead of ${tenantId}:users. Subtle typo, but it will work, and produce undefined:users as the key that all your tenants will access. Well, there's a cross-tenant leak that your days/weeks of obsessing over your database design didn't capture.
Or maybe you have the correct variables, but in the wrong order: ${accountId}:${tenantId}:users instead of ${tenantId}:${accountId}:users. Good luck catching either of these in a code review!

A basic way to prevent these issues is to have the tenantId passed in as a param to all cache layer requests. Don't just directly access redis. Instead, create some interface to abstract away redis and force the tenantId to be passed in, and then validate the value.

External Services

You can't just obsess over a leak in your code... you need to guard against an external service having their own leak as well! Yes, this happens, even for major cloud providers. Oh the stories some of us can tell.

Anyway, if the response from the external call provides the tenant identifier somewhere then check that it is what you expected. Otherwise, if you just take it as is, you've just possibly polluted your database with someone else's data, and that isn't gonna be easy to clean up.

Added bonus to anyone who goes back to their code and makes sure their API includes a field in the body or headers to identify the tenant for the response.

Wrap up

Be paranoid! Everyone is out to get you. And chances are, the place you obsessed the most about multi-tenancy issues isn't gonna be the place that ultimately burns you. Put guards and alerts in your code if there's even a hint of a leak. And remember, if you don't store data then it can't be leaked. :-)