576 karma · joined November 3, 2014
My name is Kevin, and I am a cybersecurity developer and penetration tester for an ISP, developing tools such as DDoS Mitigation solutions, security evaluation tooling, vulnerability management tools, and much more. I enjoy building complex projects comprised of front end, back end, and various integrations, as it pushes me to stretch my design, programming, and architecture skills.
The thoughts and opinions I express on Hacker News are my own, and I look forward to having great discussions with the community.
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
2. PL/Python: language-specific procedural language
https://www.postgresql.org/docs/10/plpython.html
Essentially, this (as I understand it) is highlighting the ways that Postgres can expose data from outside of its default table structure context via these types of functions.
With that said, code reviews only work, in my experience, if team members are strong communicators. Understanding each other, empathizing with issues, and being collaborative rather than tearing people down is critical.
Code reviews are a “we” activity not a “your” and “my” activity.
While it’s fine to feel sorry that they weren’t exposed to it, I wouldn’t personally say I feel sorry as I find it hinders people’s willingness to ask for help. Invite questions don’t make people feel bad for not knowing something you or I may think is obvious. We all were beginners at some point.
I feel code quality is important, not because of future state and optimization but a strong architecture will facilitate other engineers learning, which is critical. For example, not all engineers have learned design patterns like the strategy design pattern or observer, etc (see https://refactoring.guru/design-patterns/catalog for great examples) where a little guidance can save them a lot of pain.
With that said, I understand we all bring different skills to the table. Some people love making every linter pass while others could care less and some actively hate it. This is fine, we just need to respect each other enough to try to build on each other’s strengths and support each other where we’re weaker.
TLDR: Rather than saying it’s fine to write “bad” code, say don’t let code quality intimidate you, and be willing to try. You can always refactor later and you’ll learn as you go.
In hindsight I wonder if it’s just experience in the experience that has led to this differing experience or if the products are actually meaningfully different in their configuration and behavior that this is consistent for others.
Thanks for sharing, this made me feel better that I had so many issues with alternatives.
https://pydantic-docs.helpmanual.io/usage/schema/#field-cust...
On the other hand, python’s packaging system is such a mess, I’m not sure the alternative / replacement is actually better. I wish the ecosystem could do better here and had an easy way for people who want to help improve this to do so.
https://docs.python.org/3/library/os.html#os.EX_OK
I put together an enumeration to make it cross platform:
https://gist.github.com/kkirsche/2adb8c94794048ec30736b8fe5f...