Learned something similar on a previous job. Prefix it with "#must", "#should", "#could", "#would".
We've also extended it with some other things that you may want to comment, but are not necessarily actionable. "#wont", "#idea", "#tip", "#question", "#risk", are pretty much self-explanatory.
"#fun": an ugly workaround that could've worked; some funny situation that the change could cause; ...
"#domain-knowledge"/"#debrief": really nice if you are working with people that are more junior, or not that familiar with this codebase in particular. May help other reviewers understand better why the author made certain decisions.
A nice "trick" is to declare your enum column on the database as a string, and your enum in the code as a hash with string values. So you can have self-explained data saved onto the database, and all the niceties Rails gives you from the enum.
The actual browser bookmarks, with stuff that has proven itself useful and I end up searching for it at least a handful of times a year.
Notion Web Clipper to dump everything else on a "need to organize" file on Notion.
A couple times a month I go into the "need to organize" file, read anything that was there as a "read later" and remove them, simply remove anything that looking back doesnt seem like will be useful on the next year, and move everything else and then categorize/add tags to a "useful links" file also on Notion.
I've used the mobile app on Android, it wasn't a joy (it still lacks some polishing), but it was certainly VERY straightforward.
Personally I don't have lots of stuff to file, but I did everything under 1 hour, while still discovering how to use the app and learning a bunch of taxes nomenclature.
Can`t access it from Brazil...
```
The owner of this website (deliveroo.engineering) has banned the country or region your IP address is in (BR) from accessing this website.
```
https://i.imgur.com/TyDkmzc.png?1
Wow, never felt so connected to a hn reply. This is so similar to my experiences using PyQt, so it probably describes the experience of a lot of other devs out there.
We made a MVP using Electron but had to ditch it because of performance issues. PyQt seems like the best alternative, but the pain points you described were hard obstacles in the beginning.
* We gave up on making Omaha work, after some wasted weeks, and are using pywinsparkle to autoupdate on windows.
* The QSS feels buggy all around, the "border-radius" property is one of the simplest examples of that.
Would greatly appreciate some open-source solutions, examples or simply some blog posts of best-practices and how you are managing these pain points. :)
Learned something similar on a previous job. Prefix it with "#must", "#should", "#could", "#would".
We've also extended it with some other things that you may want to comment, but are not necessarily actionable. "#wont", "#idea", "#tip", "#question", "#risk", are pretty much self-explanatory.
"#fun": an ugly workaround that could've worked; some funny situation that the change could cause; ...
"#domain-knowledge"/"#debrief": really nice if you are working with people that are more junior, or not that familiar with this codebase in particular. May help other reviewers understand better why the author made certain decisions.