# Continuous Integration
Source: https://jan.pizza/ci



While there is an industry-standard set of CI steps that are universally good (which usually includes tests, linting, type checks, and running a build), I think there are a few more that are worth considering.

# 1. Review by an LLM

From my experience, using a custom Claude Opus-based reviewer is really beneficial. It is definitely not a replacement for human review, but it provides great assistance.

I've seen many cases where LLMs spotted tiny mistakes that would otherwise go unnoticed by my co-workers.

## Dangers & Trade-offs

* Merging a PR can get really prolonged by playing ping-pong with an LLM reviewer that seems to have completely different ideas every time --compared to a typical developer who usually leaves the most important suggestions in the first comment.
* A lot of suggestions might be irrelevant, but you might notice developers still pasting the LLM's suggestion directly into their LLM coding tool ;)

# 2. Database migrations

Code that doesn't build shouldn't be merged. It breaks deployments and local development.

But so do faulty migrations on a `main/development` branch!

# 3. Preview Deployments

I think they're really beneficial because of how they impact quality assurance.

Without them, a lot of unrelated PRs are usually merged into the development/staging environment, and every so often, they are checked by a QA person and a PM.

And if other developers want to check the changes before approving a PR, they have to do things like stashing/committing their current work, switching to the branch, and running tasks like migrations or package installs.

Even when it only takes 1-2 minutes, I think it is enough of a barrier to demotivate other developers from verifying PR changes.

But with Preview Deployments, the change can be tested by stakeholders before even getting merged into dev!

# 4. For the JS ecosystem: [Fallow](https://docs.fallow.tools/)

1. Preventing dead code & duplication.
2. High code complexity detection.
3. Respecting React client/server boundaries.

# 5. Anything else that can be automated

Software development is a high-margin industry. I hope your company isn't too cheap with its CI/CD budget.


# Revolut Pockets
Source: https://jan.pizza/finances-with-revolut-and-wise



## Managing subscriptions in a smart way

Revolut allows you to create pockets. Then, you can configure a card to use money only from this specific pocket.

This way, you can granularly manage your subscriptions, and add money to pockets only when you want the subscription to renew.

Additionally, you can set pockets to specific currency to have most optimal conversion fees.

# My current setup

1. **Paying online**: Virtual Disposable Card
2. **Trials**: Pocket with no funds.
3. **GitHub Sponshorships:** Pocket with funds added for next few months.
4. **Cursor & Gemini**: Pocket with funds enough for next month.
5. **Gym:** Pocket with no funds. Adding money only when I'm sure I will go there next month.
6. **Mobile Service:** Pocket with funds enough for next month.

When I get any other subscription, I create new pocket. I request virtual cards when I can, because monthly limit is 4.


# Introduction
Source: https://jan.pizza/index

Hi and thanks for stopping by! Here's few facts about me

<Card title="Work" icon="suitcase">
  Since 2021, I work as a Software Engineer — TypeScript • Node.js • React
</Card>

<Card title="League of Legends" icon="sparkles">
  Peak TOP 0.10% player — S15 • Master 300 LP • EUW
</Card>

<Card title="Japan" icon="location-dot">
  I was born in **Zielona Góra, Poland**. Currently live with my wife in **Tokyo.**
</Card>

<Card title="Veganism" icon="cow">
  5 years ago I decided to stop consuming animal products. Sometimes, with friends, I do street outreach to talk about it with other people.
</Card>


# Protecting from Supply-Chain Attacks
Source: https://jan.pizza/supply-chain-protection



I recommend enforcing use of [AikidoSec/safe-chain](https://github.com/AikidoSec/safe-chain) (or similar tools) in developers' setups, as well as in CI/CD.

While configuration of minimum release date per project is becoming globally available config for most package managers, I still believe this solution is more optimal, as it reduces the risk of compromising developers in your team way more.