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

71–80 of 89 posts

Re: Best practices in modern web projects

#71

Post by jordo37 »

ape4 wrote: post #42
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?

Is there an entry level CDN. Enter your credit card and get access, upload files and go. For a few bucks a month.

Fastly can easily be setup on top of s3 and we have been super happy with their basic layout and then their advanced features as we needed more (ssl content delivery, selective purging, etc)

Re: Best practices in modern web projects

#72

Post by buffportion »

IgorPartola wrote: post #69
buffportion wrote: post #62

Earlier quoted context omitted.

I don't consider not-branching to be a radical approach. If you are using branches you really aren't doing CI, because you aren't integrating continuously.

So there are projects where I don't branch: ones where I am the only committer, and there are no features. For example, my puppet manifests for all the servers I manage. It either works, or I roll it back. However, feature branches are just multi-stage commits. Sure you can invest hours of your life setting up CI, then writing code, not testing it locally before pushing it to master, getting an obscure error from the…

"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]"

Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process.

The trick is that you have to be able to push to master without breaking it, which is scary to many developers and usually requires a shift in thinking. How do I do large refactorings? (you don't - do many small refactorings instead). How do I add a half-finished feature? (break the feature into many smaller features, use feature toggles, etc.)

Re: Best practices in modern web projects

#73

Post by auxbuss »

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.

This is my preferred method too. But a lot of developers struggle with the discipline of small, discrete, incremental changes, plus the dependence on solid testing skills. It also requires a culture that can support it. No blame, in particular.

However, if you have a team that is comfortable working this way -- and is only occasionally breaking things; it happens -- then it is a wonderfully creative, frictionless, and flexible way to develop.

Re: Best practices in modern web projects

#74

Post by IgorPartola »

buffportion wrote: post #72
IgorPartola wrote: post #69

Earlier quoted context omitted.

So there are projects where I don't branch: ones where I am the only committer, and there are no features. For example, my puppet manifests for all the servers I manage. It either works, or I roll it back. However, feature branches are just multi-stage commits. Sure you can invest hours of your life setting up CI, then writing code, not testing it locally before pushing it to master, getting an obscure error from the…

"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]" Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process. The trick is that you have to be able to push to master without breaking it, which is scary to…

Of course. And this relies on your CI system having 100% unit and system test coverage, including testing external API's, CSS bugs, browser compatibility, etc. Are you certain that your system does that? More importantly, are you certain that investing the time into testing that your checkout button is not covered up by some random element due to a missing ";" character in your CSS file or a missing 0 in the width percentage value will eventually pay off? It should be scary to push to master if you hold master to be deployable at all times. Unit/system testing or not, you will never have guaranteed test coverage, and even if you try to get to it, you will spend infinitely more time doing that, than doing a reasonable amount of unit/system automated testing + good human QA.

Re: Best practices in modern web projects

#75

Post by chris_mahan »

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.

That's what we do.

Works well.

Break the build, all stops, and we huddle and fix it.

Sort of like the andon cord in toyota factories.

Re: Best practices in modern web projects

#76

Post by gnaritas »

eropple wrote: post #37
gnaritas wrote: post #31

Earlier quoted context omitted.

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.

Those things don't require distributed source control; they simply require remote access. Substantiation simply isn't necessary, you haven't given scenarios that demand distribution and you can't, because honestly there aren't any. Distributed source control is a preference, a style, not a necessity. Central repositories with remote access handle all of those use cases. Other than perhaps the Linux kernel, there's very little software that can't be written just fine with remote works and centralized repositories.

Re: Best practices in modern web projects

#77

Post by Lockyy »

parham wrote: post #12
csbrooks wrote: 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.

>just said what everyone was already aware of

What you mean is it just said what you were already aware of.

Not everyone does know all of these things, a list of things with generalised statements along with links to more detailed information is incredibly useful to someone who is just getting into the field, which I guess is exactly who this article is aimed at.

Re: Best practices in modern web projects

#78

Post by buffportion »

IgorPartola wrote: post #74
buffportion wrote: post #72

Earlier quoted context omitted.

"Sure you can invest hours of your life setting up CI, then writing code, not testing it locally[...]" Maybe I've misunderstood, but why aren't you testing it locally? With trunk based development you make your changes, run a local build and push if it passes. Everyone (including any CI servers) runs the same build process. The trick is that you have to be able to push to master without breaking it, which is scary to…

Of course. And this relies on your CI system having 100% unit and system test coverage, including testing external API's, CSS bugs, browser compatibility, etc. Are you certain that your system does that? More importantly, are you certain that investing the time into testing that your checkout button is not covered up by some random element due to a missing ";" character in your CSS file or a missing 0 in the width pe…

That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.

Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.

Re: Best practices in modern web projects

#79

Post by joshuacc »

buffportion wrote: post #62
chrisweekly wrote: post #54

Earlier quoted context omitted.

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.

I don't consider not-branching to be a radical approach. If you are using branches you really aren't doing CI, because you aren't integrating continuously.

> If you are using branches you really aren't doing CI, because you aren't integrating continuously.

Perhaps this is just a terminology issue, but I strongly disagree with this. You can always merge/rebase the latest version of master into your feature branch.

Re: Best practices in modern web projects

#80

Post by eropple »

gnaritas wrote: post #76
eropple wrote: post #37

Earlier quoted context omitted.

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.

Those things don't require distributed source control; they simply require remote access. Substantiation simply isn't necessary, you haven't given scenarios that demand distribution and you can't, because honestly there aren't any. Distributed source control is a preference, a style, not a necessity. Central repositories with remote access handle all of those use cases. Other than perhaps the Linux kernel, there's ve…

- Central repositories handle me working from a coffee shop with spotty wi-fi. No, I am not going to wait to commit until I get home, because I want a set of commits as I go so I can revert if I screw up.

- Central repositories handle me working on a plane. Same thing.

- Central repositories handle your Chinese subsidiary being constrained to a slow and spotty pipe (they actually exported our tree with git-svn and used git on their end--this was at a NASDAQ company, it's not like anyone was cheaping out, it was the best available).

That you are willing to work around the deficiencies of centralization does not mean they are not deficient. Don't be ridiculous.

Post reply on HN