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

41–50 of 89 posts

Re: Best practices in modern web projects

#41

Post by kylequest »

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 anybody from putting them in a shell script that gets committed to git...

Re: Best practices in modern web projects

#42

Post by ape4 »

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.

Re: Best practices in modern web projects

#43

Post by pmichaud »

Nexialist wrote: post #29

The "12 Factor App" manifesto http://12factor.net/ is in the same vein as this, perhaps a bit more in-depth. I like the idea of these guides generally. I think it'd be more valuable if they linked to example production code that followed the principles however, since there's no substitute for the real thing. Come to think of it, I've never seen anybody write up any kind of index of (for example) Github projects that…

I like that idea too, but I suspect that there are pretty much zero non-trivial projects that actually follow best practices like these consistently. Maybe I'm wrong.

Re: Best practices in modern web projects

#44

Post by jammycakes »

collyw wrote: 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…

The fact of the matter is that love it or hate it, Git is now the most widely used VCS on the market in corporate settings (see e.g. http://www.itjobswatch.co.uk/). More importantly though, it is also the de facto standard for version control -- the lingua franca of source code management, communication and collaboration. Subversion and TFS still have significant market share, but everything else has pretty much fallen off a cliff in the past couple of years.

Also, many of Git's most powerful features have nothing to do with being distributed. Easy branching and merging, private versioning, bisect, rewritable changesets, stash, and the ability to cherry-pick individual changes within a file to commit, back out or stash could all theoretically be built into a centralised system.

Re: Best practices in modern web projects

#45

Post by numbsafari »

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.

Look at CloudFront from AWS. CloudFiles from Rackspace used to also include built-in (no additional charge) distribution over Akamai as well, though it had limitations on the number of purges you could do, I think.

Re: Best practices in modern web projects

#46

Post by owenversteeg »

I disagree with "Keep the master branch deployable at all times." Both my CSS framework Min (http://minfwk.com) and several other popular GitHub projects use the strategy of 'only use one branch, and use tags to mark stable versions'.

Min's only branch (gh-pages, so we can serve the site with GitHub) is usually "unstable" (in the sense that a CSS framework can be unstable.) If someone wants a stable release, that's what Git's tag system is for.

Re: Best practices in modern web projects

#47

Post by numbsafari »

Demiurge wrote: post #36
vukers wrote: post #28

Earlier quoted context omitted.

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?

Not sure about the down mod, but I think the point of the OP is to address projects that have the goal of driving a "startup" business.

In addition, with mobile, getting rid of any network latency you can is going to help.

In general, though, I think you are right to ask the fundamental question. That said, it's something a lot of people end up needing anyway and it helps if you design for it up front.

tl;dr - If you're building a low-volume site, the OP probably doesn't apply to you.

Re: Best practices in modern web projects

#48

Post by awj »

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.

Meh, it doesn't have to be friction. If the goal is to ensure your other team member sees the changes you're making before they're merged in a pull request both accomplishes that and gives you both a place to put some notes related to that process.

I think you're ascribing too much ceremony to this. It's useful to have something written down for any discussion about these changes, and a pull request is as good of a place as any for that. Plus it ensures everything is all set up to merge once you're both satisfied with the changes.

Re: Best practices in modern web projects

#49

Post by hoggle »

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.

We are a trusting team and don't do pull requests with our closed source repos either.

To avert chaos it's much better to have an orderly branching model in place e.g. feature branches! My fellow partners made us go all "git flow" last year and the result has been a really tidy and satisfying workflow:

http://nvie.com/posts/a-successful-git-branching-model/

Atlassian's SourceTree also helps us with maintaining "the flow":

http://www.sourcetreeapp.com

https://www.atlassian.com/git/workflows

Git extensions and screencast on how to setup on OSX:

https://github.com/nvie/gitflow

http://build-podcast.com/git-flow/

Re: Best practices in modern web projects

#50

Post by awj »

owenversteeg wrote: post #46

I disagree with "Keep the master branch deployable at all times." Both my CSS framework Min ( http://minfwk.com ) and several other popular GitHub projects use the strategy of 'only use one branch, and use tags to mark stable versions'. Min's only branch (gh-pages, so we can serve the site with GitHub) is usually "unstable" (in the sense that a CSS framework can be unstable.) If someone wants a stable release, that's…

I think the idea is sound, but the reasoning isn't. Keeping master deployable at all times forces breaking changes off into feature branches so unrelated pieces of functionality can't interfere with each other's release schedules.

Keeping master deployable for bug fixes doesn't make sense to me, though. Are you going to deploy new features sitting in master because something else had a bug? Just go look up the last release tag, make your bug fixes there, then merge them into master.

I've been bitten too many times by unstable features holding up releases on master (both my features and other team member's). Feature branches do a wonderful job of solving this and the required merge back into master gives you a nudge to prevent scope creep.

Post reply on HN