SVGs don’t support perspective transforms like CSS (or at least they’re not guaranteed to work in image viewers), so we need a way to simulate this perspective transformation without creating a massive SVG. It’s easy to draw the box below, you can just project the face of each side of the cube into a polygon, but mapping the texture to that perspective transform isn’t natively possible!

So SVGs don’t support perspective transforms, what do they support? SVGs support this nice little transform called an affine transform. This 6 number transform is what you get when you do transform: matrix(a,b,c,d,e,f) in CSS. They are super useful for 2D transformations, like panning/scaling/dragging, but can’t really project into 3d.

How can we approximate the transform? Here are some ideas I mulled over that could achieve a good result:

• Redraw the image with the distortion. This is potentially expensive and means that we can’t use SVGs as the images without converting them to bitmaps. It also means that things might look “fuzzy”

• Ray trace everything! By projecting a ray to compute each pixel for the image, I could get a very conventional 3d renderer. This doesn’t achieve my goal of lightweight SVGs though

• Subdivide the image and project each subdivision in the most locally-correct affine transformation. Use projected polygon clip paths to cut off the edges of regions.

I was really curious how the last bullet point could work, and I could think of no other ideas that didn’t require rasterization. So with OpenAI O3’s help I implemented it into the vanilla Typescript 3D renderer. To test it, we’re going to project a checkerboard pattern onto a cube.

Ok here’s our starting point, 2 subdivisions, the 2 checkboard images with affine transformations.

Oof, looks like it has some kind of bulge, let’s see it with 4 subdivisions!

Looks a bit rough (literally, it looks like it is not a flat surface). Let’s keep going!

Alright let’s go to the end, we want it to look flat!!

At around 512 images, it’s really hard to tell the difference. Awesome! We did image projection without any rasterization! Here’s an animated version that incorporates a fix from an HN commenter (thanks Masterjun!)

Now for the exciting part: The SVG isn’t that big! Because we can use the `defs` of the SVG to avoid repeating the image, we only need to define each clip path!

Here’s a table of the file size as you increase subdivisions. I _think_ some differences in the matrix calculation account for the somewhat weird scaling.

The math is fun but in the age of AI, below our pay-grade! You can check out the full source code here!

I’m excited to flesh out this 3D renderer because 3D SVGs can make great artifacts on GitHub, we want to make it so that people can easily review changes to circuit boards made with tscircuit in pull requests.

I hope you enjoyed this neat little 3D trick! Back to coding…

Edit: A fine HN user found a bug in the projection (thank you Masterjun and badmintonbaseba!) the code now correctly finds the subdivided triangle’s affine transformations properly!

Here’s how it works:

1. Create or copy a virtual database each time you test an endpoint

2. Fixture the system from the outside, making all the API calls a user would make (e.g. signing up, creating a Foo)

3. Reproduce the bug/behavior you want to test

Theses tests make for excellent regression tests, but if you’re able to get the configuration above to work quickly and in parallel (trust me, you can!!) then they’re also incredible for new feature development.

The Perfect Test

Why is this the perfect test?

• We’re using the API exactly like a customer

• We’ve encapsulated common steps into fixture functions

• Every test has the same import getTestServer and doesn’t require understanding any internal workings of the server

The thing I love about this pattern is the code your customers/users are using becomes the same code you use to test. You don’t have any “special access” to the insides of your services for tests, which dramatically simplifies how complex the test suite is.

Many people will cheat and put fixture.db as a database client because let’s face it, your database probably has some weird legacy data you have to emulate for some tests. In those cases you might have tweaks or insertions as part of your test. If you’re feeling very lazy with fakes, you can use “internal access hacks” to get around e.g. email verification. A little bit of that is good, a lot of it is very bad!

Setting up your tests

Let’s go through setting up these tests very simply. First let’s get a postgres instance running in the background, passwordless for simplicity:

docker run -d --rm -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust postgres:16

We’ll create all of our virtual databases inside this instance. I like the passwordless version because it requires no setup and is unopinionated, so your test suite can just grab onto postgres at port 5432 without any configuration.

Next let’s write our getTestServer function. This should be the only function that tests need to run!

And that’s basically it! In our fixture we:

• Create our temporary virtual database

• Create a database client for our application

• Inject the database client into our server

  • A lot of times this is just a middleware that sets req.db, then whatever middleware normally sets up your database just grabs req.db if it’s available

• Clean up the test database

Real world example of get-test-server.ts

Talking to External Services (spoiler: use fakes!)

Most people will object to this pattern on the basis that external services are slow. This is absolutely true, which is why you should spin up a fake version of each dependent external service.

This does not mean mocking. You should write a dedicated lightweight module-server (a fake) that can be externally spun up and actually contains business logic. It should live independently of your codebase and only use in-memory data (i.e. it should be really fast). It’s critical that your fake encapsulates your knowledge of the external service. If there’s a bug or quirk of the external service, encode that knowledge into your fake. We’ve built fakes for many external services at this point, and even created a typescript framework for quickly building API server-modules called winterspec. Here’s an example of how you would fixture a test with a fake:

Most SDKs (including the stripe SDK) support replacing the their base API url because they use it for their own testing!

Here’s a conversation I’ve had a million times, but time and time again Engineer 1 comes around that fakes are an incredible pattern for external services. Every company should use these, even if they don’t adopt this database pattern.

Engineer 1: You’re not testing against the real thing! It won’t be as robust!!!

Engineer 2: Actually it’s better than the real thing, because we can simulate scenarios that aren’t easily replicable with the real API, such as downtime or weird errors we see in our production logs!

Engineer 1: That may be so, but the lift of building a fake is a lot! How can we justify the cost?

Engineer 2: The upfront cost of building fakes is high, but the long term benefit is extremely high. We’ll be able to re-use these fakes whenever we integrate against the external service again, and we can easily create E2E tests and have a fast test suite!

Good APIs are generally simple & understandable by design, so they’re generally easy to emulate if you’re not concerned about optimization and scaling.

Fakes: The Upfront Costs

To implement this kind of outside-in testing, you’ll almost always need to implement the following fakes for whatever services you’re using, which will require a deeper understanding of each service than you probably wanted to get- but it’s worth it!

• Email Service - however you’re sending emails, e.g. sendgrid

  • Easiest- you might have already done this one

• Auth Service - Auth0, Clerk etc.

  • These are both the most difficult and highest ROI fakes- someone should really open-source fakes for these!

• Payments - Stripe etc.

  • Also one of the most painful because there’s a lot of logic around computing money- but it’s worth it. Don’t trust Stripe’s test mode, it’s still too slow and difficult to fixture for parallel tests!

• Redis, AWS Services, SQS etc.

  • A lot of people shy away from implementing these because they return binary or XML from endpoints. If you’re pressed on time, implement a fake for the client, not the web service. This means instead of writing a redis service, you would just implement client.get(“mykey”) and client.put(“mykey”, “val”). You can then inject your new client in your server middleware.

I’ll write more on fakes in the future- they’re not really the main point of this article!

Making it fast to create new databases

I’ve scaled/seen this pattern scaled to many thousands of tests that can run in under 3 minutes. Here are tips to make it faster:

• Instead of migrating each time, migrate a “template database” at the beginning of your test run, then use CREATE DATABASE testdb TEMPLATE template0;

  • There is a really cool module called ava-postgres we built at Seam that automatically handles starting postgres and doing templating automagically with one getTestDatabase call. I still can’t believe Max was able to pull this off!

• I’ve never found port-binding to be too slow, but it can be problematic with a lot of tests if you run out of ports. I think you should always bind your main API but you can sometimes get away with exporting a fetch function from your external service fake, then replacing the fetch/request client inside of your SDK clients. No port bind!

• If you’ve implemented outside-in testing without cheating, you can use load-balancing techniques to run your tests on lambdas or firecracker VMs. This is how you get a test suite with 10,000+ tests to run in under a minute on CI. The basic technique for this:

  • Deploy a preview of the new version of your server such that a request can be configured to use a different database, e.g. using a header TestDatabaseName

  • Have getTestServer return the serverUrl to the external server, and insert a unique TestDatabaseName for each test server returned

  • This technique works particularly well for people who use postgres for everything including job queues and keystores

Conclusion Paragraphs are dumb!

Hope you enjoyed learning about this pattern. I wrote this to link people to because I’ve probably implemented this pattern across 100+ repos and every time people onboard they’re scratching their head wondering why our tests are so uniquely simple.

If you’re interested in fakes or have written similar patterns, I’d love to chat, DM me on twitter!

“Hacking distribution” is different than a “growth hack”. When you “hack distribution” you’ve essentially found a “growth hack” that now has a barrier to entry (nobody else can do it) that can sustainably funnel users to your product. Many startups only need to hack distribution once, but may need to execute many growth hacks to achieve a single distribution hack. This was absolutely the case with CollegeAI

Before I take you on this adventure I should say that CollegeAI is in a maintenance state and has been for years. I doubt any of this works anymore, but at the time this one distribution hack worked to get us 100,000+ students yearly. I should also say that all the screenshots here were created/edited to reflect approximately what I was seeing at the time, but since this strategy was executed in 2017 not 2024 a lot of things have changed- Quora was huge, SEO generated content was just taking off etc.

The search for a growth hack

I discovered the “chanceme” strategy on the 44th page of the google search console for “CollegeAI”. We had barely any website traffic so it was basically one person who somehow got a result containing CollegeAI for the term “chance me harvard”. It was super deep in the search results- so deep most of the search terms didn’t make sense.

I googled “chance me harvard” to see what this person might have been searching for, and found a nascent subreddit where people were discussing their chances to get into College.

Reading through this subreddit, I found a trend where people would give a bunch of their high school stats and ask what their chances were. Most of the answers were subjective like “You’ve got pretty good odds” or “Definitely look into safety schools” but there was something unsatisfying about an answer like that for someone who loves data and analysis. I wanted to do better.

My first idea was to create a bot account called “collegechancebot” that would output a fairly objective probability based on the bell curve distributions of scores and class position, this was data we already had. We built a simple function that took a bunch of scores, high school GPA etc. into a calculator and spit out an approximate probability. I would then manually respond on most the posts:

This got a bit of traffic but because the subreddit was super nascent, this was totally unsustainable. There had to be a better way. I wanted to own the search traffic for anyone searching “chance me XXX”, but for that we needed backlinks.

Quora

Quora was huge in 2017, especially for this “chance me” phenomenon. We wanted to somehow link back to CollegeAI, but we wouldn’t have been allowed to spam our website on every answer (in fact our marketing intern tried this and was banned from Quora). Still we wanted a way to be able to use Quora as a channel and answer the hundreds of questions that looked like this:

I liked to use data in my responses, and realized if I gave an extremely thorough answer, I could link back to CollegeAI by citing my data or background. This was good, but the great answers took a long time to write and moderators would still interpret it as spam. Moreover, it didn’t actually get anybody to click into it.

We were building a lot of tools around our core value proposition of guessing where students would go to college, and while we were building those algorithms and cleaning our data, we often looked at different admission graphs for schools. At the time many colleges didn’t release their SAT score acceptance distribution, so we were looking into ways of approximately deriving that data from other factors.

Eventually we had some graphs that we thought would be interesting to students so we made collegeai.com/chanceme, which was a website that took in various scores and output helpful graphs for understanding where you fit in the distribution of applying students.

We then realized that we write very short answers, then cite these graphs with a link. Suddenly we could write very short answers that were both helpful and gave us a backlink.

The answers would vary wildly in popularity and we would answer other questions (answering Quora/Stack Overflow is good practice for understanding your audience) but it was a great growth hack to get our chanceme page off the ground.

Distribution Achieved

After that CollegeAI blew up on google and we had hundreds of sign ups to our main service daily. I don’t have many records from 2017/2018 because it was my first startup and I was pretty sloppy- but the data below from 2023 shows that the distribution hack was incredibly enduring- 6 years later we’re still getting 100k visitors from our work.

Distribution is half the battle

Ultimately CollegeAI failed because we didn’t figure out a good way to monetize this audience, and lacked a lot of focus committing to a single product. My takeaway is that distribution is a very difficult problem and half the puzzle for a startup, but the other half- building a great product and getting product-market or… product-monetization fit- is just a critical.

Hopefully it’s also pretty clear that we weren’t spamming all over the internet and hoping something would go viral. We had a methodology that centered on helping students where they were and tried to create a ton of value for all of our growth hacks. Finding areas where people are underserved is a great way to hack and own a niche.

Subscribe now