Live data from Hacker News

Best practices in modern web projects

blog.arvidandersson.se

31–40 of 89 posts

Re: Best practices in modern web projects

#31
post #26
post #16

Earlier quoted context omitted.

Yes, but I would guess that non distributed would suit 90% of use cases. I imagine most software is still developed in one physical location.

Your imagination ignores days where you WFH (like I am right now), it ignores remote workers, it ignores work while traveling, it ignores outsourcing, it ignores open source development. But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be . That's why it's good.

He's not ignoring anything; he said non-distributed would handle 90% of use cases and that's probably somewhat true. Saying hey I'm one of those 10% isn't a rebuttal to what he said.

Re: Best practices in modern web projects

#32
post #9

No idea how this is getting so many points. There's absolutely nothing of any practical interest here. Use version control and documentation... End of post. I'd say these are more industry standard practices than leading edge.

There will always be a new freshman class. Every year, someone joins HN (or the community at large) knowing next to nothing. We should welcome those people, not make them feel bad for being new.

Yep. HN wants to avoid eternal Septembers; occasional Septembers are fine though.

Re: Best practices in modern web projects

#33
post #4

"Git First of all, use git for version control. It is modern, works great and the majority of developers are either comfortable in using it or want to start using it. Its a pain in the arse to learn, overcomplicated for 90% of the cases it is used in. How many people actually need a distributed version control." (I use Git. It is powerful and useful, but the justification for using it in the article isn't really grea…

It's easier to find other people who know git that who know mercurial.

Re: Best practices in modern web projects

#34
Ugh. Pull requests again? OK, look, unless your team is so large that you can't effectively communicate otherwise, pull requests are just friction. Use feature branches, then merge them when they are ready. Trying to pretend like your two person team is a huge open source project with many distributed part-time and full-time developers is cargo cult at its worst.

Re: Best practices in modern web projects

#35
post #12
post #5

Earlier quoted context omitted.

I'm not sure about that; I feel like I got a lot from the article without following the links.

This didn't cover anything useful it just said what everyone was already aware of, the only useful part was the links. Everything else was like saying to spread butter on toast use a butter knife.

I would be surprised how many people don't use a butter knife ;-) But I agree - way to abstract.

Re: Best practices in modern web projects

#36
post #28

>Serve these through a CDN that is optimised for serving static files to ensure high transfer speeds and therefore increased user happiness. I was not aware this was that common or even considered always the best practice. Is this really the best practice for any website? How exactly is a CDN more optimized than nginx on a dedicated server with 1GB connection?

At a minimum, a CDN automatically caches and serves content from multiple servers globally.

Is it worth it if you have a US specific website that doesn't get that many users (~3 sessions at once)?

Also, another website I administer has a lot of user uploaded content that's constantly changing. I've not dealt with a CDN before, so I don't know how CDN helps with that? I think only a fraction of the data is static in this case.

PS Why the hell would someone downmod my honest question?

Re: Best practices in modern web projects

#37
post #26

Earlier quoted context omitted.

Your imagination ignores days where you WFH (like I am right now), it ignores remote workers, it ignores work while traveling, it ignores outsourcing, it ignores open source development. But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be . That's why it's good.

He's not ignoring anything; he said non-distributed would handle 90% of use cases and that's probably somewhat true. Saying hey I'm one of those 10% isn't a rebuttal to what he said.

I definitely want to see some substantiation that everything I just enumerated is less than 10% of software development, by whatever metrics he wants: number of projects, lines of code, whatever.

Re: Best practices in modern web projects

#38

Ugh. Pull requests again? OK, look, unless your team is so large that you can't effectively communicate otherwise, pull requests are just friction. Use feature branches, then merge them when they are ready. Trying to pretend like your two person team is a huge open source project with many distributed part-time and full-time developers is cargo cult at its worst.

While I'm often lazy about this, I think that there are advantages to doing this with this once your team is over just a solo developer. Encouraging your fellow developers to read (and at least understand, if not internalize) your code has some bus-proofing to it, and I don't think it's that much friction if done well.

Re: Best practices in modern web projects

#40

>Serve these through a CDN that is optimised for serving static files to ensure high transfer speeds and therefore increased user happiness. I was not aware this was that common or even considered always the best practice. Is this really the best practice for any website? How exactly is a CDN more optimized than nginx on a dedicated server with 1GB connection?

The very nature of the kind of content you're serving over a CDN seems to indicate that unless you're extremely high traffic, the benefits are few: most of your clients are going to grab the static content from you once at a cost of a few hundred extra ms, and then rarely need it again.

I think having CDN as a basic requirement for all projects is... ill-considered. Remember, using a CDN is giving away data about your users' browsing practices without their consent.

Post reply on HN