753 karma · joined November 10, 2020
Mainly working with Databases and the Web.
Contact: contact-hn (at) hartenfeller.dev
From an efficiency standpoint it would be way better when devs run this once and not every visitor.
[1] https://docs.oracle.com/en/database/oracle/oracle-database/2... [2] https://blogs.oracle.com/developers/post/creating-a-graphql-...
I also like Svelte which uses it's own language and needs transpilation. I think that's key to elegance as JS was not really designed to control layout, style and logic all at once.
They do a good job about it and want to share it so they publish their story. Now people from other companies read this and think that this is now state of the art and they also should do this. But they don't even have the same issues.
I work with a Low Code framework from Oracle (APEX) that literally runs in the database and serves web apps. Want a report and form on a table? Click create new app and xreate page, select the table, customize labels, maybe move things around, maybe change an item from type text field to select list with another query and done in 5 minutes. With lost update detection, easy authorization control, automatic validations for your table constraints, etc. You can still code data processing procedures but why reinvent the wheel for another web UI?
People just choose to overengineer backend apps that only 50 people use...
More about my experience on my blog: https://hartenfeller.dev/blog/testing-claude-code
If you just copy classes and don't care to understand them, it's a different story of course.
My guess is that the attacker figured out or used the default password for the superuser. A quick lookup reveals that a pg superuser can create extension and run some system commands.
I think the takeaway here is that the pg image should autogenerate a strong password or not start unless the user defines a strong one. Currently it just runs with "postgres" as the default username and password.
But if both are fine there is no way that any native code will be faster than a database. No network latency, set operations, index usage, etc. DBs have all the the info to make data access fast.
The problem being complex is the issue. SQL is a standard, condensed, extremely performant, actually testable, and logical language. Sure, not anybody can instantly maintain it but that would be the same as if it was a lot of lines and functions in Java. The more lines the more risk for bugs.
I also love how deep SQL goes. And that makes totally sense. It powers the world of data since 40+ years so of course people asked for niche features. One of my favorite is the model clause in Oracle with which you can implement multidimensional arrays. A friend implemented Conway's game of life with it in way less lines you expect.
I trust Mullvad because it does security audits like this. And it stores no data and has a history of police showing up without any data compromised [1].
[1] https://mullvad.net/en/blog/mullvad-vpn-was-subject-to-a-sea...
Sounds like an effective solution. Even though some people might build a great application, but someday they might leave, and nobody knows how to administer this.
You can still write bad PL/SQL code, but at least everything is centralized and stored in a single database where you have an admin making sure that everything is fine. For other developers, it is straightforward to make small changes because 95% of the complexity just lies in the data model and the database code. You don't need to adapt to a specific infrastructure, frameworks and other dependencies, etc.
This is not the case. If you bind values with :ITEM_NAME and use compiled statements (never dynamic string concatenated ones with "execute immediate') there is no chance of SQL injection.
Additionally some experts say that the inflation was bigger in Europe because the governments didn't do investments with new debt.
I think this should be part of the language spec.