Yes, and it does exactly what a launcher should do. It is not designed to show a dozen widgets spread over five workspaces.
Priced at 15 eurobucks (back in the day) it's the most expensive piece of Android software I have ever bought. I have felt no buyer's remorse whatsoever.
Edit: looks like the perpetual license costs EUR 40 nowadays.
I personally don't need a bunch of screens of widgets. I've got my first screen of the 17 apps I use the most, a clock/weather widget, and the app drawer button to bring up the (iconized) app list. On the second screen a have a widget for an app used to share pictures with friends.
Launchers are personal, so Niagara works for you that's great! But for my use having everything is a single column is a nightmare.
Every item in the single column can also be a widget, shortcut, or popup folder. I have the 5 top apps I use, then a popup folder that holds 4 I use less often. It works great, and I can get to/launch everything just using the thumb holding the phone.
My screen is pretty simple, 5 folders with icons, 10 other icons, one calendar widget, one weather widget. It’s what a homescreeen should do for me. Because not everyone is you.
Building is so much fun, probably my #1 favorite thing to do, but a bad company culture can ruin it. I love being a CTO so I can build and set the culture that keeps it fun.
1. You have a column on your objects you want secured as an LTREE[]
2. You add a GIST index on that column
The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA
When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc
In software engineering, "senior" or not usually means you can be trusted to take on certain problems vs. others.
In US primary school (an industry I've never worked in), this might be close to something like teacher, curriculum planner, assistant principal, principal, district supervisor, etc.
As you progress further in your field and hone your skills and knowledge, the scope and impact of your responsibilities should grow.
Remember what? That people have different preferences, workflows and methods of staying productive?
Someone voiced that they liked a certain tool for a certain feature and suddenly we are judging them for it? I like that people share their thoughts and opinions.
Remember this type of comment. Never let yourself fall into this type of thinking when trying to understand what your users want.
Instead of passing judgement on why someone values something, why not ask?
For example, if you were to ask me why I chose to keep using an IDE that I had spent years of my life building muscle memory using perhaps you would get a better understanding of the specific part of the lifecycle I was at when paying for software.
It's not that the git gui was the reason why I signed up for the software in the first place. The git gui was the last reason for me to not jump ship when switching to something like neovim or helix. This was during a time where LSP was becoming popular so refactoring tools and intellisense were finally getting better adoption outside of the JetBrains tooling. Most of this was achievable with editor du jour + lsp plugins, but the git ui was the one piece I hadn't personally solved outside of the JetBrains ecosystem.
This has been an interesting realization for me, seeing the LLM well poisoned by its poor understanding of hooks and effects has opened my eyes up to how much the average developer also doesn't understand these things.
2 data points and you're drawing a conclusion about an entire graduating class? For all we know, you might be experiencing a reality that you're company isn't able to attract great young talent.
Because if you have N connections in your pool you're going to have to execute LISTEN on all N, or else the connection pool needs to be LISTEN-aware so it can process async notifies by calling some registered callback.
I.e., the connection pool API has to be designed with this in mind.
For that matter connection pools also need to be designed with the ability to run code upon connecting to create TEMP schema elements because PG lacks GLOBAL TEMP.