130 karma · joined November 1, 2019
- protocol itself is quite nuanced, like iirc requests with Authorization (or some other) headers don't obide by usual rules, and again for developer it's just an arbitrary convoluted set of rules, if they don't grasp the problematics
- backend and frontend should work in unison to have correctly configured cors, but as we know, devs hate communicating with each other
you can't pick up c++ from the docs and the language itself is a monstrosity, and for that you must have book explaining why do you have 30 types of pointers, golang in the meantime have excellent official guide, and you don't really need any book
I didn't manage to find a way to update existing session layout when the layout config changed, only to recreate it, which is super boresome when you tinkering with plugin config that is embedded in layout config.
Resurrected sessions needs to be restored manually via somewhat lagging session manager, there's no cli api for that, in general when you need something to be done in another session, you can't.
The only good built-in feature I found is stacking layout showing running command in pane, but I delegate it to tabs in niri now.
Overall I would say if you're long time tmux user, switching to zellij isn't worth it. If you're new to concept of terminal emulators, zellij is much more friendlier, and I'm sure plugins would mature, docs would improve.
not quite what you desire, but certainly better than plain syntax highlight
also juggling branches doesn't scale beyond single repo, use worktrees instead
I can't help but think golang is at best in beta version now, and it's too bad companies picked it up (even without generics, lol)
Although most elixir code I've worked with was written by guys coming from ruby/java, and they just couldn't resist abusing macros for emulating inheritance, or overusing macros per se, once you switch your mind and clean that shit up, elixir is more maintainable than golang, for example (working for go company now). It has more tools to manage complexity and boilerplate, while nearly all golang code is complex/boilerplate itself.
allocating a literal third of space to a self-rated list of skills is kinda bad move, it might seem like you're trying to be honest but to me it speaks ego problems, and that you're too focused on tools instead of solving problems at hand. I would much rather prefer having skills/tech used listed together with each job
imo the most important info on resume is
1. work experience (pet projects/contributions to open source if you're big nerdo)
2. location/timezone
3. name and contacts