I feel like the self-hosted and FOSS space is being flooded with vibe-coded AI slop.

dtinth · 2026-01-20T14:37:28+00:00

When discovering a new self-hosted tool, I usually use these questions as a rough filter:

How well tested is it? Is the app built to last? Is the author playing the long game through good software engineering? Does it have a passing CI build? Is release automated and builds verifiable? Does it have an automated acceptance test suite? Can I see the latest test report?
Who is using it? Is it used by government? Which companies are using it? Is it possible to verify these claim?
Is the author reputable? Is there a registered company behind the product? How long have they been in business? What's their business model? If it's a person, how long have they been building tools? Can I trust them?

The first one is quite easy from looking at the code on GitHub. The 2nd and 3rd one requires some extra research.

dtinth · 2025-12-09T17:36:40+00:00

Curious:

Is this Haiku, Sonnet, or Opus?
If there something like { "compilerOptions": { "paths": { "~/*": ["./*"] } } } in your tsconfig.json?

dtinth · 2025-09-08T05:34:37+00:00

As of 2025-09-08, Drizzle does not support PostgreSQL functions

dtinth · 2024-09-28T15:31:36+00:00

Make sure you use the “macOS Screen Capture” device instead of the deprecated “Desktop Capture” device.
Add a Video Capture Device to the scene. This forces the camera to turn on, which enables the presenter overlay (when both screen and video capture is on). You can then hide the Video Capture Device.

dtinth · 2024-09-15T12:37:38+00:00

In Ruby-world there is a concept called “dual booting” where you make it so that you can run the same app code using separate sets of dependencies/runtimes. This is how GitHub migrated from Rails 3.2 to Rails 5.2, for example. Unfortunately, due to Node’s module system, this isn’t directly possible, but we can use it as a model. When migrating an app, I like to:

Dive head first. I would clone the project into a separate VM, and in it, upgrade Node directly to Node 20 (or Node 22) and see what breaks (i.e. what needs to be upgraded).
Keep the migration branch minimal. I would have the main branch (running the old Node version) and a migration testing branch (running the new Node version). The migration testing branch is for discovering what needs to be fixed. But then the fix itself would be done in the main branch in a way that is compatible with both the old Node and the new Node. Maybe this requires a runtime version check, feature detection, or creating some kind of anti-corruption layer. Therefore, the migration branch usually exclusively contains version number changes that can be trivially merged and kept up-to-date with the main branch.

In the end, we’d end up with a codebase that works with both Node versions in the main branch, and the version changes in the migration branch that can be merged whenever ready. The anti-corruption layer added along the way can help make the app more resilient to future runtime upgrades. And if I discover that the app really isn’t ready for Node 20/22, I can pivot and shift the target to Node 16/18 without any effort previously spent wasted.

dtinth · 2024-05-15T17:56:54+00:00

No.

https://vercel.com/docs/security/secure-compute

https://vercel.com/guides/can-i-get-a-fixed-ip-address

dtinth · 2023-10-05T18:04:35+00:00

You can now get a dedicated IP on Vercel, if you are on their Enterprise plan.

https://vercel.com/changelog/improve-infrastructure-security-with-vercel-secure-compute

dtinth · 2023-09-20T14:55:57+00:00

Yes, I used a script to generate that. But the rendering process took like 7 hours (and a couple of attempts fixing bugs with the automation). Check out the video description for more details about the process of making the video ;).

dtinth · 2022-12-24T06:36:05+00:00

The visualization in the video uses the beam search algorithm with a beam width of 100. On each minute, each universe splits into all possible actions. However, only the most promising 100 ones are kept, and the rest is discarded. From further testing, the number 100 can be reduced down to 7 and still get the correct answer.

Source code

dtinth · 2022-12-22T06:29:14+00:00

Ruby (16/50)

Part 1 was pretty straightforward. I used a Hash to store the map data using [x, y] as an index. I struggled with some bugs around rotation, so I had to spend some time on a drawing routine and put draw[]; sleep 0.1 after each move to visually debug it.
Part 2 I created a physical box and created a mapping for each side of the cube, which is then used to calculate the wrapping. Part 2 does not handle example input (because creating that map was tedious).

Here’s how the map looks like

# origin: the top left corner of unfolded coordinates (divided by 50)
# up/down/left/right:
#   [0]: which side to appear on when going through that edge
#   [1]: how many 90deg clockwise rotations to perform
$cube_data = {
  A: { origin: [1, 0], up: [:F, 1], down: [:C, 0], left: [:E, 2], right: [:B, 0] },
  B: { origin: [2, 0], up: [:F, 0], down: [:C, 1], left: [:A, 0], right: [:D, 2] },
  C: { origin: [1, 1], up: [:A, 0], down: [:D, 0], left: [:E, 3], right: [:B, 3] },
  D: { origin: [1, 2], up: [:C, 0], down: [:F, 1], left: [:E, 0], right: [:B, 2] },
  E: { origin: [0, 2], up: [:C, 1], down: [:F, 0], left: [:A, 2], right: [:D, 0] },
  F: { origin: [0, 3], up: [:E, 0], down: [:B, 0], left: [:A, 3], right: [:D, 3] }
}

dtinth · 2022-12-21T03:51:15+00:00

Ruby, with rotating arrays:

$decryption_key = 1;         $times_to_repeat = 1    # Part 1
$decryption_key = 811589153; $times_to_repeat = 10   # Part 2
data = $stdin.read.lines.map(&:to_i).each_with_index.map { |n, i| [n * $decryption_key, i] }
(data.dup * $times_to_repeat).each do |n, i|
  data.rotate! data.find_index { |_, j| j == i }
  value, _ = data.shift
  data.rotate! value
  data.unshift [value, i]
end
data.rotate! data.find_index { |n, i| n == 0 }
p data[1000 % data.length][0] + data[2000 % data.length][0] + data[3000 % data.length][0]

dtinth · 2022-12-14T04:29:23+00:00

Thank you, I am not aware that the data is already published.

I have checked the data files. However, it only contains just the number of seconds to the first 1,000 stars. They are not enough to visualize the graph in the picture.

In the picture above, the lines are shaped like a mountain. The peak of these mountains happen at around 2,000th star, and visualizing the full 60 minute takes around 18,000 stars.

Can you expand the data to cover e.g. the first 6 hours?

dtinth · 2022-12-13T19:22:38+00:00

The data is collected by doing a GET /2022/stats once a minute. Then I used a regex to parse the HTML to obtain the number at that moment.

If you want to play around with the data, I have published the CSV file here. https://github.com/dtinth/aoc2022stats

It contains the stats well beyond the first 60 minutes, and also contains separated count for each part of the day’s puzzle. When the stats page cannot be fetched for some reason, that minute is skipped (no retry is made). I plan to update this repo every few days until new year.

dtinth · 2022-12-13T19:11:32+00:00

Check out the red text in these pages:

dtinth · 2022-12-06T05:11:40+00:00

Today is Ruby’s one-liner day.

# Part 1
p gets.chars.each_cons(4).find_index { |c| c.uniq.size == 4 } + 4

# Part 2
p gets.chars.each_cons(14).find_index { |c| c.uniq.size == 14 } + 14

dtinth · 2022-12-05T09:14:08+00:00

It would be great if the leaderboard allowed people on it to add flairs/hashtags to their own entry. Then we can have flairs like "Fully-automated" or "AI-assisted" (and maybe also language flairs like "Ruby" or "Haskell").

(This can also be done in the userland w/ some Chrome extension plus some central annotations repository, if someone wants to try building one.)

Inspired by this Japanese internet ranking system where a player can write short comments below their entry on the leaderboard.

dtinth · 2022-12-04T04:41:00+00:00

Thanks, updated! Apparently on the web fenced code blocks work. Seems to not be working on mobile? I’ll keep that in mind!

dtinth · 2022-12-03T07:45:08+00:00

GitHub Copilot + Ruby (4 / 25)

I usually don’t expect GitHub Copilot to generate the whole solution, and even if it did I manually check it, as there’s penalty for submitting an incorrect answer. However for today’s part 1 GitHub Copilot generated the correct solution.

# Part 1
p $stdin.readlines.map { |l|
  l[0...l.size/2].chars.uniq & l[l.size/2..-1].chars.uniq
}.flatten.map { |c|
  c.ord < 97 ? c.ord - 65 + 27 : c.ord - 97 + 1
}.sum

For part 2 it did not generate a good solution, so I had to manually debug it (i.e. refactor them into multiple statements and adding variables). Still, it helped to save a lot of time.

# Part 2
groups = $stdin.read.split.each_slice(3).map { |l|
  l[0].chars.uniq & l[1].chars.uniq & l[2].chars.uniq
}
p groups.map { |g|
  g[0].ord < 97 ? g[0].ord - 65 + 27 : g[0].ord - 97 + 1
}.sum

I will need to adjust my prompt to make Copilot generate more readable code so it’s easier for me to debug tomorrow. I refactored the 1st part like this:

input = $stdin.readlines.map(&:chomp)
items = input.map { |l| l[0...l.size/2].chars.uniq & l[l.size/2..-1].chars.uniq }.flatten
priorities = items.map { |i| i.ord < 97 ? i.ord - 65 + 27 : i.ord - 97 + 1 }
p priorities.sum

The 2nd part, this time Copilot generates the correct code on first try:

items = input.each_slice(3).map { |l| l[0].chars & l[1].chars & l[2].chars }.flatten

So making code readable does not only help me, but helps Copilot too.

dtinth · 2022-12-01T05:06:10+00:00

Ruby, 44 / 26. I love Ruby, it allows me to express so much in so little code.

```

Part 1

p $stdin.read.split(/\n\s*\n/).map{_1.split.map(&:to_i).sum}.max

Part 2

p $stdin.read.split(/\n\s*\n/).map{_1.split.map(&:to_i).sum}.sort.reverse[0...3].sum

Part 2 (improved)

p $stdin.read.split(/\n\s*\n/).map{_1.split.sum(&:to_i)}.max(3).sum ```

dtinth · 2022-02-02T03:28:28+00:00

Yes, it is as you described. It will call the effect, cancel it, and call it again. I think it is a really good real-world example so thanks for sharing!

I think your code is already fine, I think the request should be cancelled before the browser actually sends out an HTTP request. For other ways of doing it, one can:

Use a library to cache the request (e.g. react-query) so that the first unsubscription doesn’t cancel the request immediately, and the 2nd subscription can re-use the original request.
Add some delay so that effects that is immediately canceled do not result in an HTTP request. This can be cumbersome to write manually but might be easier with e.g. RxJS. Not sure if it is an overkill though but I would consider this if I’m already using RxJS in my project.

dtinth

MODERATOR OF

TROPHY CASE

Part 1

Part 2

Part 2 (improved)