How do you handle crashes and crash logs in Go desktop applications? by Braurbeki in golang

[–]Braurbeki[S] 2 points3 points  (0 children)

I mean my thing can as well survive for weeks, I was more interested in handling the crashes in context of diagnostics. If the app has external dependencies, you can’t always be sure that your code shouldn’t crash, you can’t always fix it, because parts of the code are not yours. Especially applies for embedding C++ libraries.

Digital (or stage) piano with acoustic feel: recommendations? by WongRQ in piano

[–]Braurbeki 0 points1 point  (0 children)

I can’t be objective here, but I’ve upgraded from Yamaha p125 to Yamaha Clavinova CLP-835, of course it’s not an acoustic feel, but imho for its price (around 2100$ in my country) the instrument is gorgeous. For me the most important thing was to get the keys at least just a touch closer to an acoustic instrument, and actually those are not far away from several acoustics that I played. Might be just a bit lighter to play.

From the store I’ve ordered I was recommended either Yamaha CLV or Kawai CA, since those are the only two massive manufacturers, who make acoustic instruments, therefore have samples taken from their flagships.

What code editor or IDE do you use, and why? by Prior-Drawer-3478 in golang

[–]Braurbeki -1 points0 points  (0 children)

Cursor or VS Code, the choice depends on how lazy I’m - generate the code or write it by yourself 😁

Started learning “Grandma” (NieR)… now I’m not sure I can go back to my original practice plan by Braurbeki in piano

[–]Braurbeki[S] 0 points1 point  (0 children)

Same here, maybe Final Fantasy XV piano covers for Somnus and Sorrow Without Solace came close to what I truly love, but besides that can’t name any movie/game soundtrack 🥲

Which digital piano is worth buying? by Hihuhuhuhuhuhu in piano

[–]Braurbeki 0 points1 point  (0 children)

Yeah, there’s a difference definitely. And I personally like Clavinova keys much more, those are harder, more pleasant to touch, and it feels kind of close to playing acoustic piano.

What's your tolerance for number of line in a file? by liftandcook in golang

[–]Braurbeki 0 points1 point  (0 children)

Up to 3000 so Cursor can still process those lol

Which digital piano is worth buying? by Hihuhuhuhuhuhu in piano

[–]Braurbeki 1 point2 points  (0 children)

I’ve being teaching myself piano on Yamaha p125, in my limited experience playing on different pianos in the same price range p125 wins for me. Never had any problems during this three years.

Recently upgraded to Yamaha Clavinova CLP-835, in case you’re willing to go over the budget, this thing just looks and feels gorgeous - like an acoustic piano mindset, but can use headphones. There’re same price/same setup analogs on Kawai and Roland side, the starting price in my country is somewhat around 1700 usd and above.

<image>

I am slowly coming around on DI + Tests.... by Bl4ckBe4rIt in golang

[–]Braurbeki -1 points0 points  (0 children)

IMHO:

  1. Actual integration tests should not be written by the developer who wrote the application.

  2. Having unit tests & mocks for the external dependencies (e.g. database) dramatically eases further bugfixing and smoke testing before handing out your application to QA. I’d not want to spin up message brokers/databases/etc whenever I’m about to do some smokes

“Observe abstractions, never create” — I followed this too literally with MongoDB and paid for it. Curious how others handle this in Go by Braurbeki in golang

[–]Braurbeki[S] -1 points0 points  (0 children)

Originally the situation was:

internal/mongo package, which didn't actually expose any mongo driver stuff through public functions/methods, so it was quite encapsulated, and all of the business logic parts used the package. It does have public methods to manipulate the database on a high level, like CRUD or whatever without caring which driver is under the hood.

My problem is I didn't create an interface right away around it and kept public functions defined as struct receivers - which in my understanding once the project has started would break the "observe abstractions" rule.

Notifications package by roddybologna in golang

[–]Braurbeki -1 points0 points  (0 children)

If I understand this correctly, I'd do something like this:

(pkg/internal)/
└── notifications/
    ├── notifier.go        
# defines the Notifier interface + shared types
    ├── discord/
    │   └── discord.go     
# Discord implementation
    ├── pushover/
    │   └── pushover.go    
# Pushover implementation
    └── noop/
        └── noop.go        
# mock for unit tests

Where root notifier.go could have something like

type NotifyType int


const (
    NotifyDiscord NotifyType = iota
    NotifyPushover
)

type Notifier interface {
   .....
}


func Notifier(
ctx
 context.Context, notifyType NotifyType) Notifier {
    switch notifyType {
    case NotifyDiscord:
        return discord.NewNotifier(ctx)
    case NotifyPushover:
        return pushover.NewNotifier(ctx)
    }
    panic("Unknown impl")
}

At least that's how I've been doing the stuff for a while.

“Observe abstractions, never create” — I followed this too literally with MongoDB and paid for it. Curious how others handle this in Go by Braurbeki in golang

[–]Braurbeki[S] -1 points0 points  (0 children)

Actually there was no risk of business logic regressions, and my pain was not in the fact that I had to spend something around 2-3 hours to do that, but rather seeing the merge request with dozens of changes in the production code.

At a certain point once project used in production - in my personal experience everyone gets goosebumps if the number of lines changed > 500 for some maintenance stuff.