Frederik Handberg

I hope to get the `app_state.db` completely up and running today, but it’s going to require a bit of work. I need to implement the following: - Create and update Spaces - Switch between current Space - Pull recently opened Spaces in chronological order to make a list in UI - Reopen the latest Space when launching app Most of the tasks also require building the UI. Maybe I can even start working on `cache.db` today as well, but it’s more important to get a really solid solution implemented for `app_state.db`. I did the database queries yesterday using the Swift package called `GRDB`:

GitHub

GitHub - groue/GRDB.swift: A toolkit for SQLite databases, with a focus on application development

A toolkit for SQLite databases, with a focus on application development - groue/GRDB.swift

View quoted note →

After having used a bunch of LLM models, this is my conclusion: - Gemini 3 Thinking for brainstorming - Claude Sonnet 4.5 for programming View quoted note →

I think perhaps having two databases would be preferable: - `app_state.db`: It stores data such as which Spaces are currently added to the app and where they are located on the disk. Will also include a table of recently opened Spaces - this will be used to show a list in the UI. - `cache.db`: This database is disposable and is just used for mirroring. The app will scan the Space folder to rebuild the database. The local files are always the source of truth, but having the `cache.db` database allows for very efficient indexing. #dev View quoted note →

The easy route would be to just store everything in the SQLite database, but I really do prefer the approach of having local files. I think the right choice is going to be a hybrid approach where the app uses both local files and a database, but I need to find the right balance... There should be an app database storing 'Spaces' with their names and icons/images. This database will be stored inside the app directory, and it will therefore be device-specific. This means, each device will have its own local database. This creates a bit of a problem in terms of continuity because of no global database that's hosted in the cloud. Imagine the following scenario: - The user bookmarks a note on their Mac. - Now the user opens the iOS app, but the bookmark is not to be found. The bookmark will not appear automatically, because as already mentioned, each device has its own local database. Luckily, there is another way to do it that solves the problem of continuity. I could simply use hidden folders inside the space folder. Then the local database will just mirror the information found in the files located in the hidden `.space/` folder. The folder structure could be something like: ``` /Documents/My_Project_Space/ ├── .space/ │ ├── settings.json (spaceName, icon/image, bookmarks, recentNotes, ...) │ └── history/ │ └── F0B35EEF/ (Folder named by note ID) │ ├── 20260112_1000.json │ └── 20260112_1045.json ├── assets/ │ └── some_image.png ├── Work_Notes/ │ └── meeting_jan_12.json └── some_other_note.json ``` The local files should always be the source of truth, while the database is there mirroring for performance. If the user types a character in a note, the local DB should be updated and immediately refresh the UI, this should take <1ms, so the user sees the change instantly. Then after, the app triggers a background task to write the updated JSON to the disk. I'm still in the process of figuring out the best architecture before beginning implementation, but I think I'm starting to have a pretty good idea of how to best do this. #dev #app View quoted note →

Gemini 3 Thinking is really good at brainstorming implementation architectures for my notes app. I'm trying to decide how I want to store notes. Currently, I have an approach of using a local JSON-file for each note document, but I _need_ a local SQLite database for version control and other features. Technically, I don't really need the database for version control, as I could have a `/.history/[note-id]` folder and then store each version of the note, but this is not efficient at all. It increases disk usage like crazy compared to the database-approach. #dev

Interesting blog post, but Nostr should have been mentioned in "Connecting with friends on the Web"

A Website To End All Websites | Henry From Online

How to win the war for the soul of the internet, and build the Web We Want.

Can confirm 👍 View quoted note →

My first #sewing project has begun! I’m starting out with sewing a basic t-shirt. I’m very nervous about how it’s gonna fit. I should probably just have done an oversized tee, but instead I’m going for a fitted style. I’m regretting that decision now 😂

Single-vehicle accident on Bollervej in Horsens. A passenger car lost control and crashed upside down in a field. #press

Here are some of the tasks I need to complete for the notes app I’m building… #dev **Save the state of line numbers in a code block:** Line numbers in code blocks can be controlled via a toggle to show or hide them. The state should be saved so that if hiding the line numbers for a specific code block, it should be saved to the JSON structure. **Add a shortcut to easily insert a new block:** Need a shortcut to insert a new text block. Could be `Cmd+Enter` to insert below and `Cmd+Shift+Enter` to insert above the currently selected or focused block. **Automatically focus a newly added block:** After adding a new block, it should automatically be focused and the caret should be positioned in the new block, so that the user can begin typing immediately. **Clicking enter on empty list item:** When clicking enter in an empty list item, it should be converted to a normal text block. It’s the same behavior as when clicking backspace in an empty list item. **Highlight heading button in outline:** Placing the caret in a heading or the blocks below, should highlight the corresponding heading in the outline of the right sidebar.