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

61–70 of 89 posts

Re: Best practices in modern web projects

#61

Post by kylequest »

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

Being able to open source code without compromising any credentials is a great goal, but using environment variables doesn't really accomplish it UNLESS your code only runs on a PaaS, which will always supply all of your app's env vars, but it's unrealistic for a number of reasons.

First, there'll be extra vars that your PaaS won't fully manage, so you'll have to keep track of them yourself and then later configure the PaaS environment, so your app can access them. Second, for non-PaaS applications/deployments you still need to manage the environment variables.

The variables don't magically appear by themselves :-) They need to be stored somewhere... This "somewhere" is likely to be the git repo (for the app), so you are back to square one on this.

Re: Best practices in modern web projects

#62

Post by buffportion »

chrisweekly wrote: post #54
buffportion wrote: post #51

Earlier quoted context omitted.

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.

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.

Re: Best practices in modern web projects

#63

Post by Demiurge »

numbsafari wrote: post #47
Demiurge wrote: post #36

Earlier quoted context omitted.

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…

That makes sense, thanks :)

Re: Best practices in modern web projects

#64

Post by didip »

Arkadir wrote: post #58

Honest question: what are the benefits of using environment variables over having an actual configuration file (that is obviously not added to version control) ?

Heroku & Docker.

But most importantly, it lends to dynamic configuration when using etcd or zookeeper.

Re: Best practices in modern web projects

#65

Post by angersock »

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 a masterful troll, right?

...please?

Re: Best practices in modern web projects

#66

Post by buffportion »

angersock wrote: post #65
buffportion wrote: post #51

Earlier quoted context omitted.

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 a masterful troll, right? ...please?

I appreciate the backhanded compliment but my intentions are pure :-)

Re: Best practices in modern web projects

#67

Post by sanderjd »

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 really like having code review persisted right there in the repository. I often go back and look at discussions on old pull requests to figure out why we decided to do something one way or another. It's even "higher resolution" than commit messages (which should also be good).

Re: Best practices in modern web projects

#68

Post by IgorPartola »

jaegerpicker wrote: post #59
IgorPartola wrote: post #55

Earlier quoted context omitted.

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…

In my original comment I mentioned a setup with a two person team. You know exactly who is reviewing or not reviewing your code in this setup: the other person. The two of you cannot possibly produce so many feature branches that you don't remember your own code that has not yet been reviewed.

If the PR method works for your team, that's great. In my experience, it leads to more friction and the reasons to implement it are usually "best practices" articles like TFA, not actual needs of the team.

Re: Best practices in modern web projects

#69

Post by IgorPartola »

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.

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 test/deploy process, fixing it again, pushing again, getting another error, etc. But you probably want to, you know, ship the product.

Having said that, if your workflow actually resulted in you writing better code faster and you ended up shipping earlier and making more money, I'd love to read about it.

Re: Best practices in modern web projects

#70

Post by IgorPartola »

Arkadir wrote: post #58

Honest question: what are the benefits of using environment variables over having an actual configuration file (that is obviously not added to version control) ?

Unless your environment demands it, it doesn't matter. In fact, it can be a bit of a pain in the ass to implement on your own, if you are not using Heroku or some such. The main point there is to not put secrets into your git repo. How you accomplish that for the most part doesn't matter.
Post reply on HN