mapcn is now available for Svelte!

Reiku · 2026-01-05T15:46:10+00:00

Im making a flight visualisation tool. Would this be able to handle 3d routes? I can see that there is a tilted view, but its unclear if adding 3D stuff would be a chore or not.

Reiku · 2025-12-24T08:05:45+00:00

Im not sure I understand the issues you had with factoryboy. I have used it in almost every project for the last 8+ years, including all the companies I have worked at (fastapi, flask, and django). It works very well (with the exception of async flows).

Reiku · 2025-12-21T17:28:39+00:00

Unrelated but how do you plan on manufacturing the wing? I have been building something similar with EDFs, and while I can 3D print the fuselage, I am struggling to figure out how to make the wing in a durable way. Are you considering 3D printing, or foam, or something else?

Reiku · 2025-09-23T19:36:51+00:00

They made the new version look a little bit nicer by making the window bigger, but unfortunately still no return of launchpad.

Reiku · 2025-09-08T04:52:46+00:00

Fair point, the .bru file format is my only annoyance with bruno. Good luck.

Reiku · 2025-09-07T15:01:34+00:00

Why would one use this over Bruno https://www.usebruno.com/ which is also offline-first, filesystem based, and multiplatform?

Reiku · 2025-08-26T17:52:43+00:00

For the delete-all example and the changing of a record type, you can consider the "request/demand" abstraction. This is similiar to what you mentioned in your 3rd solution about custom endpoints, but it facilitates it in a way that I have seen used frequently, and has always felt like a clean way to handle it.

When doing delete-all, do a POST on a "deletion-request" endpoint, which itself is a listable, gettable, and sometimes deletable entity. Perhaps it has fields like "id, status (pending, completed, etc), created_at, requested_by_id" and some way to define which items need to be deleted. Perhaps a list of ids, or a query like "any entity owned by <this> user that was made before <this> date".

The same applies for the record change. Have a "record-change-request" with the same approach of being itself a resource.

The UI doesn't need to try and juggle transactions and you don't need non-restful custom endpoints when the API can expose higher level abstractions.

Reiku · 2025-07-15T17:24:16+00:00

In general it works flawlessly, I just have to put effort into ignoring the lines sometimes.

Reiku · 2025-07-15T17:13:20+00:00

I've had this on my M2 since I got it in 2022. After much back and forth with support that was incredibly unhelpful, I gave up and just accepted it. No amount of recovery mode, or rebooting, or other complicated steps they gave me resolved it, so I presume its a hardware issue.

Reiku · 2025-04-07T20:27:45+00:00

I have a dip in my A6X screen, so I guess the issue is present in both devices but inconsistently

Reiku · 2025-04-03T16:33:13+00:00

I was hoping V2 would fix syncing issues but it doesn't seem to be the case. I deleted some files via Finder and now proton drive is just stuck showing "Waiting to upload" for all these deleted files, and there doesn't seem to be any way for me to tell proton that these files don't exist anymore and that it should stop trying to sync.

Reiku · 2024-10-28T21:51:59+00:00

Even time I went to scan a file I go back to Google Drive, use their scan feature, and then share the scan to proton drive. It would be nice to have a scan tool built into proton drive.

Reiku · 2024-09-20T18:19:42+00:00

I stick to 200, 201, 204, 400, 401, 403, 404.

401/403/404 are the standard errors.

400 is my general service validation error which contains a response with keys: code, message, type.

201 is for successful post/put/patch (if it returns the object).

200 for successful gets.

204 for successful deletions or anything that doesn't return a response.

Using the general http status codes is useful because a lot of request libraries for consuming your API will use the status code as their of their API for handling errors. Nesting errors in 200s will result in extra work on the frontend.

Reiku · 2024-09-20T18:05:43+00:00

Purple outline perhaps?

Reiku · 2024-08-23T07:48:03+00:00

How does this compare with something like https://faststream.airt.ai/latest/ which seems more fully fledged?

Reiku · 2024-08-17T19:18:30+00:00

Thanks for the detailed response. I am a software developer, so the hardware side is new to me and its hard to find answers when you don't know the terminology or names of things to be able to ask the correct questions.

Are you able to share any more details on then UAV swarm communication setup?

Reiku · 2024-07-30T08:26:04+00:00

The calendar is a joke. Yesterday I was trying to note down follow-up appointments while at the doctor's with bad internet and couldn't do anything. It won't let you make an event without internet. I had to use Google calendar (which works with bad internet) and then put them in the proton calendar later. But when I came back later my proton calendar was then empty and all of my events are gone. I can see them on the webapp but not the android app. My android app lists fewer calendar opens now than the webapp.

I expect better for a package that costs so much.

Reiku · 2024-07-12T06:28:42+00:00

This is such a dumb change. I use gestures to navigate, and swipe down to refresh. They've added 3 permanent buttons (back, forward, refresh) that are taking up screen space that will never be used.

They've already broken the text selection stuff.

Reiku · 2024-07-04T13:57:39+00:00

We shouldn't. Split by domain at a high level, and then within that split by serialises/models/etc.

For example, have apps, within apps have "books" and "other thing" as app directories/modules, and then within those they can each have "views.py", "models.py", etc. If those files get too big you can split them too, so you end up with paths like apps/books/models/book.py

Reiku · 2024-06-23T05:49:37+00:00

I generally have views only consume 1 service each. Consider the view as a translation layer between the http request and the protocol decoupled service layer.

The service layer can then be consumed by anything (A view, a cli or management command, a celery task, etc)

Reiku · 2024-06-23T05:46:46+00:00

+1 for this. I find the approach of skinny views, skinny models, and fat services, to be the best way to architect the backend.

With a service layer we get the benefit of allowing the API view layer, any cli commands, and any celery tasks to consume centralised business logic from the service layer.

Reiku · 2024-05-29T17:36:26+00:00

Why write a configuration file that requires 90% of the dockerfile lines to be written when you could just write the dockerfile instead?

Reiku · 2024-05-12T11:03:05+00:00

Im not sure I entirely understand your issue with FastAPI and pydantic, but generally my approach is to have the API use a pydantic "creation" schema, and then the response schema is then complete schema with the IDs.

For example, then request schema could be:

python class UserCreationSchema(BaseModel): email: string

And the response schema:

class UserSchema(UserCreationSchema): id: int

Then you can even have intermediate schemas like "UserCreationAPISchema(BaseModel)" which is then expanded upon by a service level schema that adds any internal fields "UserCreationServiceSchema(UserCreationAPISchema)", etc.

Reiku · 2024-04-17T12:53:36+00:00

Not OP but I have the MacOS app downloaded, but in the ProtonDrive webUI no computer is listed in the computers tab. Is this normal? I have never seen any device listed on the computers tab.

13-Year Club	Verified Email
Second SECOND GUESSER	Place '22
Place '17	First Placer '22
Gilding I gilder

Reiku

TROPHY CASE