Limiting OpenAI’s token usage isn’t merely desirable because it is cheaper and faster, but also because it increases the size of the overall context. OpenAI caps this at 8.000 tokens for most models with a possibility of up to 32.000 tokens (if you are lucky to get invited, presumably). I haven’t seen anybody offering 32K tokens computations nor showcasing it. So in the meantime optimizing the token usage makes even more sense.

While I was building aihelperbot.com I did what I imagine many developers do: I used an ORM for everything database related. I used ORM to handle migrations, define schemas, insert data, update data, select data, etc. I didn’t think much about it.

It was only later while building aihelperbot.com I started to wonder if I really needed an ORM? Using AI more and more I started to realize that I could do most of the things I did with an ORM directly with SQL. And that I often could do it quicker because I didn’t have to lookup ORM specific syntax. I could just write SQL queries directly.

I wanted to add markdown blog to my NextJS app. Initially I feared it would be a lot of work. But it turned out to be easy when using NextJS server side components, i.e. the appDir. This is the end result:

• blog overview
• blog post

To get started I added the scaffolding for the markdown blog to the appDir:

app/
├── posts/
│   ├── [slug]
│   │   ├── head.tsx
│   │   └── page.tsx
│   ├── head.tsx
│   ├── page.tsx
│   └── utils.ts

The routing logic behind the folder structure is the same used in the pages folder. The blog will be located on /posts and each blog post on /posts/[slug]. The page file in each folder is rendered only on the server and contains the markup for the page. The head files add <title> tags and a few other relevant meta tags.

What does it cost to host a small web app on Render vs Digitalocean with Render’s new pricing model? The tech stack:

• web app running Node.js
• database running Postgres (Render only support Postgres)

What initially made me move git18n and aihelperbot from DigitalOcean to Render was the price. Render’s new pricing model has made it more expensive than DigitalOcean albeit offering significantly less services and options. Render has always felt a bit rough and limited but for the lower price it was still a good deal. Now it’s not.

Render adopted a new pricing scheme for its services on 1st of January 2023. And like DigitalOcean they market it as “predictable pricing” however unlike DigitalOcean it isn’t simple anymore. Render now charges both for its services and per user. The specific user pricing then in turns depends on “group type”, e.g. individual, team or organization.

It is only a price increase while Render’s offerings remains the same. Or that is not exactly true as users in the “individual group” loose autoscaling, which is an important tool to keep cost low for indiehackers and small startups that experience jumps in traffic.

I was checking the performance of one of my web sites using Page Speed and noticed it complained about assets loading slowly as well as the initial response time from the server being a bit long (500ms-700ms range). My first thought was that it might be the database queries being too slow. I quickly ruled that out (they all took in the vicinity of a few milliseconds).

Then I noticed Stripe was loading on each page load. This only happened in production hence I didn’t noticed it while developing the site. I tried disabling “prefetch” on links to the pricing page but that didn’t help. Stripe library was still being loaded on every page load. Apparently NextJS bundles libraries in this fashion, so looked into dynamically loading Stripe.

I had no idea what would happen to me that day. It was my last day working for a client in Berlin. I came to the office to work and have a small goodbye party on the sunny terrace. This was the first time in the psychical office, before that I have, like almost everybody else, been working from home.

I had bought my laptop just a year before. It was the most expensive Macbook Pro 16" with 8 Intel CPU cores and it costed 3600 €. It was quite an investment. It was driven by the theoretical argument that if I save just 10 min a day it would, given my high salary, it would pay itself off. With an hourly rate of 100 €, 10 min is 16€ a day. That is 80 € a week and 320 € a month. Utilizing this argument, I am sure many would be forced to upgrade to the newest Macbooks with M1 cores. And likely again with the arrival of the improved M2 cores.

Sublime Editor is build for writing and reading code. However the urge to write down your thoughts on different matters might come and for this Sublime Editor offers excellent support. Both out of the box and with a few useful packages.

Opposite to coding, where concise code blocks and programing logic becomes more readable through highlighting and linting tools, writing is easier with fewer colors, larger text and line height.

Redux is a popular library used to manage global application state, at least the claim. Lots of developers struggle to understand what Redux does and how to use it properly. When saying global state most developers would intrinsically imagine a simple library lifting up individual states into a shared global object. This isn’t Redux. Although Redux is a small library (2kB, including dependencies), the documentation and the complimentary libraries required makes it comprehensive. For experienced and inaugurated developers redux.js.org it’s a well-written and detailed guide that covers every aspect of Redux, for others it’s opaque and overly complex. An complexity that is also increasing present in React and which the upcoming Svelte framework highlights.

It’s that time again where I have to prepare for job interviews. Since companies aren’t looking quirky originals, you need to learn what to say to look attractive. And have some answers to the common questions.

#### How do you approach complex problems?

There isn’t one approach since complex problems are different. Here are some common ones:

• structural/architectural problems as the application matures should be handled together with the team, since everyone has a stake in the app and should be heard. These problems arrives gradual and shouldn’t be handled with rash abstractions, but rather initial observance so that there is enough foundation to assess the problem on. Thus the problem will likely be fairly well known to team members before a meeting. Give some thoughts on possible solutions before, call a meeting and listen to input and solutions from team members.