PWV Portfolio Feed

I’ll DM! 😁

"The new atuin desktop app is quickly creeping into the tools I will use daily moving forward. So so good!"

we're getting there 🐢🚀

Random sentry errors suck but the “omg someone is using the thing right now” is nice 🤣

So TL;DR; we are passionate about our goal. We are building a company because we want to continue doing this for as long as we can and explore new ideas. So being slow is actually a feature, not a bug.

From the business perspective, this might seem like nonsensical. I’ve heard a handful of times that we could be doing more, or we’ve been thrown money to act as influencers of others, but we don’t like that. We are running a marathon, and we’ll reap the rewards down the line.

Because of that, Tuist is a very human project. We support the community and developers that show up without expecting anything back. We like working with unheard voices and empowering them to spread their ideas. We do all of this because we have passion for what we do.

I like to think that non-programmers with AI who code stuff are now programmers. I don't think so much about the counter-factual about what they wouldn't have been able to do without AI

When it comes to the open source Swift ecosystem, Apple seems to rather invest in enabling solutions like the registry without having to write and maintain their own official server.

We'd love if you gave it a try! 😌

We doubt this will be implemented by Apple – but of course, we can't rule it out. They would need to rebuild both our registry and the Swift Package Index or rely on it as we do. That we find unlikely.

Running this command will mark the migration as having been rolled back in the `_prisma_migrations` table.

Then we can go ahead and apply any fixes that are necessary to avoid getting into the failed migration state and move forward from there.

To handle failed migrations, one option we have is to roll the migration back.

To do this, we use `prisma migrate resolve` with the `--rolled-back` flag.

There are a lot of different reasons why a migration might fail to apply. 

Perhaps we have added a `unique` constraint on a field where duplicates already exist in the database.

Or perhaps we try to modify some tables with foreign key constraints.

📜 This table has the history of migrations that have been run and what state they ended up in.

In the happy path, we get a migration that applies without issue.

But what happens if a migration fails to apply? In that case, we need to use `prisma migrate resolve`.

We have a migrations folder that keeps the history of changes to our database schema and has the SQL files for replaying all the changes to come to the current shape of the database.

But there's another spot where migrations are tracked: the `_prisma_migrations` table.

`prisma migrate deploy` is what we want to have run along with our app deployments so that any pending migrations get applied to our target databases. 

👉 This is typically not a command that you'll work with much in local development.

We generally use `prisma migrate dev` when we're in development working against our local (or remote) development database.

When we want to deploy our changes to production, we use another command in our CI/CD or deployment pipelines:

This command will do the following:

✅ Add a new migration file in the `prisma/migrations` directory
✅ Execute the SQL in the generated file to apply the change to the database

Let's say we are starting out with a brand new app and a fresh database.

We've got our first model and now we want to turn this into a table in our database.

We also want to have a SQL file that produces this change.

We can get these two steps done in a single command