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

61–70 of 155 posts

Re: Things I learned after getting users

#61

Post by epgui »

ttymck wrote: post #60
jjoonathan wrote: post #53

Earlier quoted context omitted.

> bizarre aversion to applying the same learning effort to their ORM Oh, sure, instead of just learning SQL I'll just learn SQL, the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated, and then I'll commit a patch to the open source project to fix the undocumented internals and shepherd a custom depende…

How do I map my complex join into a list of structs with embedded associations? I'd probably need to write a good bit of code just to unmarshal the data, right? How are you doing this every time you write a new query?

Can you give an example?

Re: Things I learned after getting users

#62

Post by lmm »

jjoonathan wrote: post #53
lmm wrote: post #49

Earlier quoted context omitted.

> 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 OR…

> bizarre aversion to applying the same learning effort to their ORM Oh, sure, instead of just learning SQL I'll just learn SQL, the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated, and then I'll commit a patch to the open source project to fix the undocumented internals and shepherd a custom depende…

> the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated

ORMs are much less bad than SQL at that, IME. If the ORM generated a particular query there is usually documentation for why, often an option you can change. If the SQL engine decided not to use the right index for this query... tough, there's literally nothing you can do.

Re: Things I learned after getting users

#63

Post by epgui »

webnrrd2k wrote: post #55
lmm wrote: post #49

Earlier quoted context omitted.

> 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 OR…

Yes, both SQL and ORMs can give you problems, but I have seen far more serious, hard to diagnose trouble from ORMs than straight SQL. Learning straight SQL is far more transferable across databases than learning an ORM. There are reasons to have ORMs, for e.g. to keep a large code base consistent. It's useful for keeping relatively simple queries consistent across an ERP system, stuff like that. However, learning SQL…

I’m not sure I understand the consistency argument… Do you have an example, even if it’s just a silly one?

Re: Things I learned after getting users

#64

Post by lmm »

webnrrd2k wrote: post #55
lmm wrote: post #49

Earlier quoted context omitted.

> 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 OR…

Yes, both SQL and ORMs can give you problems, but I have seen far more serious, hard to diagnose trouble from ORMs than straight SQL. Learning straight SQL is far more transferable across databases than learning an ORM. There are reasons to have ORMs, for e.g. to keep a large code base consistent. It's useful for keeping relatively simple queries consistent across an ERP system, stuff like that. However, learning SQL…

> Learning straight SQL is far more transferable across databases than learning an ORM.

Not my experience. For example a recursive/tree query usually has one way to do it in an ORM, but three or four different ways to express it in SQL depending on the database, some of which seem like they're wilfully screwing you over (one popular database requires you to only write "WITH" and won't recognise "WITH RECURSIVE"; another requires you to write "WITH RECURSIVE", even though the error message it gives you when you only write "WITH" tells you that it knew exactly what you meant).

Re: Things I learned after getting users

#65

Post by perilunar »

avg_dev wrote: post #58
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…

> I said that's life > (That's life) > And as funny as it may seem > Some people get their kicks > Stomping on a dream > But I don't let it, let it get me down > Cause this fine old world, it keeps spinnin' around - That’s Life By Dean Kay and Kelly Gordon. Most famously recorded by Frank Sinatra.

https://youtu.be/TnlPtaPxXfc?t=36

Re: Things I learned after getting users

#66

Post by jjoonathan »

lmm wrote: post #62
jjoonathan wrote: post #53

Earlier quoted context omitted.

> bizarre aversion to applying the same learning effort to their ORM Oh, sure, instead of just learning SQL I'll just learn SQL, the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated, and then I'll commit a patch to the open source project to fix the undocumented internals and shepherd a custom depende…

> the ORM, the ORM's weird edge case features that actually support the SQL I want, the undocumented ORM internals that prevent the good query from actually being generated ORMs are much less bad than SQL at that, IME. If the ORM generated a particular query there is usually documentation for why, often an option you can change. If the SQL engine decided not to use the right index for this query... tough, there's lit…

"SQL is worse" is a nonsensical comparison. The problems of ORMs add to the problems of SQL and compound the problems of SQL, they do not substitute the problems of SQL.

I'm glad you found an ORM you like, but it seems we have very different experiences with ORMs.

Re: Things I learned after getting users

#67

Post by TulliusCicero »

I'm surprised that they're surprised about trolls. As someone who's been doing PC gaming a long time, I always assume there'll be people who just want to ruin things for everyone else. What they're attracted to is popularity, so the better you do, the more you'll have to deal with them (they tend to grow slightly superlinearly relative to overall user growth).

This is basically every game or internet forum that acquires even a little popularity: there will be some (few) people who just wanna ruin everything, and I'm always surprised by how many people are surprised by this even when they're the technically literate sort.

For example, some Japanese fighting game devs still try to count disconnects during a match as different from losses for someone's record. One guess as to what this encourages as far as player behavior goes.

Re: Things I learned after getting users

#68

Post by perilunar »

saurik wrote: post #28
cousin_it wrote: post #3

> some users have suggested pretty smart features that i've since implemented, like this back-to-top button to quickly get back to the top of the page To me all position:fixed elements (headers, footers, this back-to-top button, etc) feel like a kind of annoying dirt on the screen. Their absence is a big part of why I love the web 1.0 aesthetic.

My god yes. There is literally a key on a full keyboard dedicated to this function (Home), smaller keyboards have a chord for it (like Fn-Up), and "mobile" touchscreen UI has a global mechanism for this (on iOS: touching the status bar)... to plop down a position:fixed button on top of the content to make it even easier to access this feature that is already extremely easy to access is just gratuitous.

On MacOS Fn+left arrow = back to top, fn+up arrow = up one window.

Re: Things I learned after getting users

#69

Post by travisjungroth »

tetha wrote: post #50
akprasad wrote: post #42

Earlier quoted context omitted.

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.

There are two parts to the schema change, the table changes (migrations) and the code changes. I think the person you were replying to was asking about the code part. Every ORM I've used or looked at[0] does that automatically in the sense that you make a change to a model and all queries generated by that model will now have that change. Depending on the change they could break, but the point is the changes propagate. If you're not using an ORM and are just using string templates, this won't happen. There are query builders, too, which are sort of in between.

[0] Django, SQLAlchemy, Active Record, Piccolo, Tortoise, SQLModel, peewee

Re: Things I learned after getting users

#70

Post by scoofy »

I have a site that will likely need a denylist for usernames. Do you have any resources on implementing that? I mean, it sounds obvious how to do it, but if it's already been done, I'd rather just have a list to work from.
Post reply on HN