Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I learned after getting users

basementcommunity.bearblog.dev

Post reply on HN
Print view View original

41–50 of 155 posts

Re: Things I learned after getting users

#41

Post by mcstempel »

> this worked for a little bit longer, but he proceeded to get on a VPN, and then another when i blocked that IP, then another when i blocked that IP, etc, etc.

Beyond VPNs, I've even seen attackers leverage residential IP networks which makes VPN detection ineffective as well [1]. If you ever need a more permanent identifier to ban users on, consider using a device/browser fingerprinting tool [2]. It helps avoid the whack-a-mole issue of more sophisticated attackers churning IPs/emails/user agents/etc.

[1] https://brightdata.com/proxy-types/residential-proxies [2] https://stytch.com/products/device-fingerprinting (I'm admittedly biased towards our solution as I work at Stytch)

Re: Things I learned after getting users

#42

Post by akprasad »

dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

If writing SQL directly, what process do you use to update your queries during schema changes? Do you rely on a test suite to catch errors then update queries by hand? Are you using compile-time checks through libraries like sqlx [1]?

[1]: https://github.com/launchbadge/sqlx

Re: Things I learned after getting users

#43

Post by nico »

econnors wrote: post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

Had a similar experience recently. A random person started repeatedly filling out contact forms for one of our clients. They were doing it manually, and they did it for several days straight until finally blocked.

It also left me wondering why that person would spend an hour or two each day for several days in a row, filling out online forms. What’s the motivation?

My suspicion is that the person doing it works at the company and was trying to mess with their systems. But I’ll never know for sure.

Re: Things I learned after getting users

#44

Post by jw1224 »

dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> I'm talking differences of a thousand fold in query load depending on how one expresses the ORM calls

That doesn’t sound like ORM… More like an N+1 problem. Eager-loading makes N+1 more likely with ORMs, but it’s easy to avoid when you know what to look for.

ORMs are designed to reduce querying, not increase it a thousand-fold :)

Re: Things I learned after getting users

#45

Post by chillfox »

dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

The core problem with ORMs is that you end up having to learn the ORM on top of learning SQL and the particular database. It ends up being like working with the database through an opaque indirect layer.

Re: Things I learned after getting users

#46

Post by willio58 »

akprasad wrote: post #42
dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

If writing SQL directly, what process do you use to update your queries during schema changes? Do you rely on a test suite to catch errors then update queries by hand? Are you using compile-time checks through libraries like sqlx [1]? [1]: https://github.com/launchbadge/sqlx

This is exactly why I find no solution fits all here. For me, I use an ORM as a catch-all and then for certain applications I manually write the queries. It's best of both worlds, and I know what components in my app have custom queries so I can test against them.

Re: Things I learned after getting users

#47

Post by droobles »

dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

What do you think of "micro ORMs" like knex.js, or Dapper for C#? I personally agree with you and my personal projects just use stored procedures, but these micro orms have always piqued my interest since they're just a SQL abstraction for building single queries.

Re: Things I learned after getting users

#48

Post by marcus_holmes »

econnors wrote: post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

Griefers. Some people get enjoyment from hurting/annoying others.

First time I bumped into this was in the DAOC MMORPG. Some players were deliberately annoying others, to the point of "wasting" their online time doing stupid shit that annoyed people. It really shocked me.

Thing is, there's lots of griefers in any online game. Which means there's lots of people out there in the real world who would do this if they could get away with it. Anonymity allows them to do this online with very little repercussion, so it shows how many there really are. But now every time I do an interview, or look at a rental, I'm thinking "is this person a griefer? are they going to enjoy making my life a misery?"

Re: Things I learned after getting users

#49

Post by lmm »

dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life.

Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM.

> I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my ORM code was in no way incorrect. I'm talking differences of a thousand fold in query load depending on how one expresses the ORM calls.

That kind of problem happens with regular SQL all the time, and the tools to test/investigate it are less available.

Re: Things I learned after getting users

#50

Post by tetha »

akprasad wrote: post #42
dahwolf wrote: post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

If writing SQL directly, what process do you use to update your queries during schema changes? Do you rely on a test suite to catch errors then update queries by hand? Are you using compile-time checks through libraries like sqlx [1]? [1]: https://github.com/launchbadge/sqlx

Sorry to butt heads there, but what ORM does automatically handle schema changes? I have so many teams with highly abstracted ORMs telling me that no-downtime schema changes are impossible, no matter how trivial the changes are, or would be in e.g. Hibernate.

And the only team capable of zero-downtime schema changes uses a minimal DSL to SQL lib.

Post reply on HN