5 ms·

Unrelated, but I am happy I managed to avoid using any kind of DB in my last few small projects. User authentication? Hard code my credentials, and SSO for use

by dobin 4y ago

Unrelated, but I am happy I managed to avoid using any kind of DB in my last few small projects. User authentication? Hard code my credentials, and SSO for users. I dont want to store user accounts (als gets rid of all this password mail and reset stuff). Storing small amounts of data from users? Pickle it to files. Caching data? Keep it in-memory, retrieve it again when server restarts. Need to keep some data? Pickle it all 10 minutes and on sig-int. Saving so much time and nerves to not having to handle SQL, relations, foreign keys, docker-compose and all the other things.

datalopers 4y ago
And this is why I don’t hire Python devs for anything related to web.
- dvngnt_ 4y ago
  why.
  - semicolon_storm 4y ago
    What happens when the program crashes in the middle of writing the data to disk? Now all the data you wanted to store is corrupted.
    - neurostimulant 4y ago
      You see, before you overwrite the actual file with the new content, you should wrote the new content in a separate temporary file first. That way, when your app detect corrupted files on startup due to power loss, you can program your app to look for the temporary files and write them to the main files if they pass your data validation. ... and before long, you'll reinvent database servers but shittier.
  - btilly 4y ago
    In this case, bragging about the steps taken to produce a strictly worse solution because the dev didn't want to learn what should be a basic dev skill. That said, criticizing all Python developers with this brush was very unfair.
- zepolen 4y ago
  Just the web? :D
  - datalopers 4y ago
    True, they’re a risk in most areas. Responsible for more technical debt than a scrum master.
    - zepolen 4y ago
      But hey it got done in half the time! So what if you need Xanax to change a feature.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
btilly 4y ago
What is your actual objection to databases? SQL is a skill, and not a hard one. Develop it once, and its availability becomes a benefit. Relations are trivial once you have the skill of SQL. Foreign keys are entirely optional sanity checks. Ignore them. SQLite comes built in to all your favorite languages, and no need for docker-compose. And all the other things, like letting the database protect you from race conditions, recovering from crashes and the like, are good.
- arpa 4y ago
  Ignore sanity checks, best advice ever!
  - btilly 4y ago
    If a person is struggling with the basics, "you must learn all the things at once" isn't great advice. Reduce scope. Also foreign keys are a mixed bag. See https://stackoverflow.com/a/83393/585411 https://stackoverflow.com/a/83393/585411 for some of the pluses and minuses. I've seen very experienced people in significant projects go both was on the value of foreign keys. And a lot of the complications are more of a barrier for people who are just learning. I've personally been on both sides of this fence.
    - deleted 4y ago
      [deleted]
    - arpa 4y ago
      I'm afraid imma have to disagree with ya here dude
      - btilly 4y ago
        Care to offer any arguments beyond it being your opinion? For the record, I first encountered arguments against foreign keys around 20 years ago from a VERY experienced Oracle DBA. He knew what he was talking about, and had actually written some of the courses that Oracle used to certify DBAs. He pointed out that our transactional database for our high volume website was already pushing the limits of what our hardware could do. Maintaining unnecessary indexes or integrity constraints was going to take our database down. Since then I've kept track. And found that the benefits versus downsides are more finely balanced than I would have guessed.
divan 4y ago
Comments like yours makes me happy. I once gave a lightning talk [1] in the same vein describing project that would be typical REST/API/Cloud/App setup and ended up being just a mobile app with not servers whatsoever. Just by carefully inspecting your data, unique requirements and asymmetries, tech stack can be drastically changed and unsual trade-offs can be taken. [1] https://divan.dev/talks/2019/golangparis/NoSystem.pdf https://divan.dev/talks/2019/golangparis/NoSystem.pdf
- dobin 4y ago
  Nice. Rare writes are indeed a good indicator. Its liberating to be able to focus only on the code. I am a big fan of KISS. Serverless, or better no-server?, is this pushed to the extreme.
arpa 4y ago
Filesystem is just another key-value database when you think about it.

by dobin 4y ago

datalopers 4y ago

And this is why I don’t hire Python devs for anything related to web.

dvngnt_ 4y ago
why.
- semicolon_storm 4y ago
  What happens when the program crashes in the middle of writing the data to disk? Now all the data you wanted to store is corrupted.
  - neurostimulant 4y ago
    You see, before you overwrite the actual file with the new content, you should wrote the new content in a separate temporary file first. That way, when your app detect corrupted files on startup due to power loss, you can program your app to look for the temporary files and write them to the main files if they pass your data validation. ... and before long, you'll reinvent database servers but shittier.
- btilly 4y ago
  In this case, bragging about the steps taken to produce a strictly worse solution because the dev didn't want to learn what should be a basic dev skill. That said, criticizing all Python developers with this brush was very unfair.
zepolen 4y ago
Just the web? :D
- datalopers 4y ago
  True, they’re a risk in most areas. Responsible for more technical debt than a scrum master.
  - zepolen 4y ago
    But hey it got done in half the time! So what if you need Xanax to change a feature.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

btilly 4y ago

What is your actual objection to databases? SQL is a skill, and not a hard one. Develop it once, and its availability becomes a benefit. Relations are trivial once you have the skill of SQL. Foreign keys are entirely optional sanity checks. Ignore them. SQLite comes built in to all your favorite languages, and no need for docker-compose. And all the other things, like letting the database protect you from race conditions, recovering from crashes and the like, are good.

arpa 4y ago
Ignore sanity checks, best advice ever!
- btilly 4y ago
  If a person is struggling with the basics, "you must learn all the things at once" isn't great advice. Reduce scope. Also foreign keys are a mixed bag. See https://stackoverflow.com/a/83393/585411 https://stackoverflow.com/a/83393/585411 for some of the pluses and minuses. I've seen very experienced people in significant projects go both was on the value of foreign keys. And a lot of the complications are more of a barrier for people who are just learning. I've personally been on both sides of this fence.
  - deleted 4y ago
    [deleted]
  - arpa 4y ago
    I'm afraid imma have to disagree with ya here dude
    - btilly 4y ago
      Care to offer any arguments beyond it being your opinion? For the record, I first encountered arguments against foreign keys around 20 years ago from a VERY experienced Oracle DBA. He knew what he was talking about, and had actually written some of the courses that Oracle used to certify DBAs. He pointed out that our transactional database for our high volume website was already pushing the limits of what our hardware could do. Maintaining unnecessary indexes or integrity constraints was going to take our database down. Since then I've kept track. And found that the benefits versus downsides are more finely balanced than I would have guessed.

divan 4y ago

Comments like yours makes me happy. I once gave a lightning talk [1] in the same vein describing project that would be typical REST/API/Cloud/App setup and ended up being just a mobile app with not servers whatsoever. Just by carefully inspecting your data, unique requirements and asymmetries, tech stack can be drastically changed and unsual trade-offs can be taken. [1] https://divan.dev/talks/2019/golangparis/NoSystem.pdf https://divan.dev/talks/2019/golangparis/NoSystem.pdf

dobin 4y ago
Nice. Rare writes are indeed a good indicator. Its liberating to be able to focus only on the code. I am a big fan of KISS. Serverless, or better no-server?, is this pushed to the extreme.

arpa 4y ago

Filesystem is just another key-value database when you think about it.