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

Best practices in modern web projects

blog.arvidandersson.se

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Best practices in modern web projects

#51

Post by buffportion »

IgorPartola wrote: post #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.

Or don't use branches at all. Develop on trunk/master with continuous integration. It reduces work-in-progress, exposes conflicts sooner and has a host of other knock-on benefits.

Re: Best practices in modern web projects

#52

Post by njharman »

kylequest wrote: post #41

I wouldn't call the part about configurations (in the post and in the 12 factor app reference) a best practice. Using environment variables is a hack that has negative side effects including security side effects. This statement is just silly: "A good goal is that the application can be open sourced at any time without compromising any credentials." It's silly because the use of environment variables doesn't prevent…

You're reversing the "goal" and "practice". It's not that Environment Vars allow you to "open source / credentials".

It's (goal) "be able to open source any time without compromising any credentials". One method (practice), use Environment Vars. Evars being a poor choice in your and somewhat my opinion, does not translate into the goal being poor. It's a laudable goal.

Re: Best practices in modern web projects

#53

Post by jaegerpicker »

IgorPartola wrote: post #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.

I couldn't disagree with this more. Pull requests provide a quick and relatively pain less code review tool. Unless you are suggesting that code review is a bad practice, which in that case I'm pretty well dumb founded as I think it's a requirement for intelligent modern development.

Re: Best practices in modern web projects

#54

Post by chrisweekly »

buffportion wrote: post #51
IgorPartola wrote: post #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.

Or don't use branches at all. Develop on trunk/master with continuous integration. It reduces work-in-progress, exposes conflicts sooner and has a host of other knock-on benefits.

To 'CI' [per se] I say "yes, of course." It's a best practice. But it is not a substitute for branching! I want to choose when I'm exposed to conflicts. "Sooner" is usually -- but not always -- "better". Summary: strong disagreement on this radical approach.

Re: Best practices in modern web projects

#55

Post by IgorPartola »

jaegerpicker wrote: post #53
IgorPartola wrote: post #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.

I couldn't disagree with this more. Pull requests provide a quick and relatively pain less code review tool. Unless you are suggesting that code review is a bad practice, which in that case I'm pretty well dumb founded as I think it's a requirement for intelligent modern development.

They are a great tool for when you don't have any other way to communicate with the other developers. Code reviews are a great practice, and we all should do more of them. I do it when I get an email like "hey, could you review my code in feature-branch-xyz before I merge it?" It's less friction than doing GitHub-proprietary pull requests, and involves much less pompousness.

Re: Best practices in modern web projects

#56

Post by rpedela »

Demiurge wrote: post #21

>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?

I personally don't find much use for a CDN when dealing with a typical website's CSS, JS, images until you have very large traffic. You can concat and minify your CSS and JS files, and add a cache control header to all static content. That should be good enough until you get very large traffic.

But like anything, it depends on the use case. If the product is primarily a file server like Dropbox then maybe using a CDN early makes sense. Or your smallish number of users are spread across the world might be another use case.

Re: Best practices in modern web projects

#57

Post by dllthomas »

eropple wrote: post #38
IgorPartola wrote: post #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.

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.

And helps make sure people are familiar with more of the code.

Re: Best practices in modern web projects

#59

Post by jaegerpicker »

IgorPartola wrote: post #55
jaegerpicker wrote: post #53

Earlier quoted context omitted.

I couldn't disagree with this more. Pull requests provide a quick and relatively pain less code review tool. Unless you are suggesting that code review is a bad practice, which in that case I'm pretty well dumb founded as I think it's a requirement for intelligent modern development.

They are a great tool for when you don't have any other way to communicate with the other developers. Code reviews are a great practice, and we all should do more of them. I do it when I get an email like "hey, could you review my code in feature-branch-xyz before I merge it?" It's less friction than doing GitHub-proprietary pull requests, and involves much less pompousness.

I guess different environments lead to different flows being better but managing code reviews via email sound really horrible to me. There is no good way to track who has actually reviewed the code, no easy way to annotate the code, and no easy way to give the code a seal of approval. Both Bitbucket and github provide good methods that are easily tracked for this. It' one thing to send an email saying please look at this code but It's much more difficult to track who on that email has done the review and who approves the code.

We use feature branches and issue pull requests/code reviews from those feature branches in BitBucket and it's been a universally well received tool and definitely increased the quality of our code reviews and overall code base.

Post reply on HN