Live data from Hacker News

Best Practices Are Not Always the Best

blog.bloomca.me

51–60 of 61 posts

Re: Best Practices Are Not Always the Best

#51
post #32
post #29

Earlier quoted context omitted.

Serious question... why would any other approach be exempt from the problems you stated?

Nothing is exempt, some things are far less fragile than others though.

But are also significantly slower and consume hundreds of times more memory, and will still break with the first little change in the DOM tree on the path that you rely on - which smart regexps can sometimes handle. For instance if you're looking just for a title and a price of a single product (common requirement for spiders), you can extract that with regexp without caring about the html page at all, just pick the and something that looks like a dollar value. I had spiders like that kept working after a full redesign of the site where even the platform was moved from WP to Magento. No DOM parser could handle that, plus they would be too slow in the first place. You need to pick the right tools for the job, everything else is BS...

Re: Best Practices Are Not Always the Best

#52

you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…

Please consider putting in the effort to capitalise the start of sentences properly, and possibly split up your post into multiple paragraphs.

Whether you like it or not, I and many others instinctively use grammar, spelling and punctuation as a signal about the mind behind the post. Plus, it makes your post easier to read - posts that aren't just a continuous flow of text with no break are easier to read.

My point is - there is an easy way to give your post a greater chance of influencing the thinking more people.

Re: Best Practices Are Not Always the Best

#54

Earlier quoted context omitted.

When I was young, I was asked to print some address labels, so I wrote a quick super-short BASIC program to parse a specific file, right now, today, and got those labels printed. Made all sorts of assumptions, but it didn't matter, because it was a static file, and nothing could ever change in it. Three or four years later, I was having lunch with the guy I'd done that for when he got a phone call. Turns out they wer…

What lesson was that? From my perspective, this other guy was using a program outside of its design spec. That can be fine, but such a thing is prone to the problem of safe assumptions suddenly not being safe. You wrote the program for the problem you needed it for, and for which, it worked fine. Unless part of the problem at the time was "we expect to use this program for a couple years", there is no reason to make…

"right now, today" and "that specific file"

Code designed to be used once has a habit of sticking around.

Re: Best Practices Are Not Always the Best

#55
post #13

you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…

Oh man this brings back memories. I learned golang for/during a performance coding competition. It was extremely frustrating asking questions about unsafe, pointer casting, and other nuts and bolts in golang-nuts and the irc channel. People were flat out refusing to answer very straight forward questions because "what are you trying to do", "that's not safe", "you shouldn't have to do that". Other fun times; trying t…

There was a discussion earlier in life about how Django didn't support prepared statements. I didn't believe this, as no ORM I've ever used didn't use prepared statements by default. I asked around, trying to verify this claim. I got "what are you trying to do?" I'm trying to find out if Django's ORM uses prepared statements by default. Outside of that one ticket in Google search results (I'm not tuned into that ecosystem, so I can't discern if it's reliable proof or not), it seems like nobody really knows.

Re: Best Practices Are Not Always the Best

#56

you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…

I might end up writing react code at any random time in my future, I'm currently curious on how one would do the equivalent of "VueJS component computed properties" in React.

Re: Best Practices Are Not Always the Best

#57
post #54

Earlier quoted context omitted.

What lesson was that? From my perspective, this other guy was using a program outside of its design spec. That can be fine, but such a thing is prone to the problem of safe assumptions suddenly not being safe. You wrote the program for the problem you needed it for, and for which, it worked fine. Unless part of the problem at the time was "we expect to use this program for a couple years", there is no reason to make…

"right now, today" and "that specific file" Code designed to be used once has a habit of sticking around.

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Re: Best Practices Are Not Always the Best

#58
post #57
post #54

Earlier quoted context omitted.

"right now, today" and "that specific file" Code designed to be used once has a habit of sticking around.

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

There is premature optimization and then there is not being stupid. Using one of the 10,000 XML/HTML parsers to get to v0.01 takes about as long on average and avoid ridiculous problems.

The only thing regex has going for it is you might already know it. But, this is one of those time when learning something is worth it.

PS: XP is doing a depth first search, which can be EXtreamly wasteful.

Re: Best Practices Are Not Always the Best

#59
One benefit of best practices is standardizing the way things are done. I have worked on project where the original developer had invented a "thin models fat controllers" philosophy for Django (best practices are fat models thin controllers). What a mess that was.....

Re: Best Practices Are Not Always the Best

#60

you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…

I work on a lot of less-usual stuff. Kiosks, signage display drivers, interactive games running on touch screen walls, etc.

I quite frequently run into the problem of the answer to something simply being "that's not best practice", "that's insecure" or even "that's user-hostile".

I don't /care/. This is getting installed on a Raspberry Pi and installed inside of a touchscreen coffee table and towed across the country. It doesn't matter that this non-internet-connected device may be vulnerable to other websites accessing its webcam. It doesn't matter that hiding scrollbars and cursors is normally user-hostile.

Go ahead and make the point that it's not best practice, insecure, or user-hostile... But don't make that your entire answer.

Post reply on HN