Improvement as Taylor and friends have commented

[srph]

http://www.laravelpodcast.com/episodes/10458-episode-25-taylor-swift-is-a-baller around 18:00~. Any thoughts on this?

[buonzz]

I just would like to clarify few things in here:

1. The concept of "right way" in this site in particular is bounded in these context:

• right way of finding resources for learning laravel, from very beginner to advance. Instead of hopping through multiple blogs and threads etc. this will collect the best and "right" resources in your fingertips as voted out by the community.
• this site doesn't tries to define a "one true way", but instead, presents a list of scenarios that users usually encounter in production use. and then, let the contributors ( the community ) share the way on how they dealt with it. Note the emphasis in "production", the way on how the "right thing" is decided is by looking at the actual experiences of people who had successfully solved it, categorize it in series of scenarios. So at the end of the day, instead of one true way, you have this mapping of best practices for particular scenarios.

example:
best practices for: LAMP stack, Windows-based servers, Shared hosting, Cloud deployments etc

Another thing to define "Right way" is to point out the bad practices that we usualy see in production use, and put a corresponding warning to prevent that from happening. One example of that is the security implementations of using "composer update" in the production servers for a Laravel application (see more at http://blog.naderman.de/2014/02/17/replace-conflict-forks-explained/)
This are some clear-cut best practices, that once pointed out could save many organizations from falling in common loopholes.

1. This site doesn't meant to limit people from doing what they want.

The fact that a person goes in this site, means he is at some level of uncertainty on how to implement something.
This resource is neither mentioned in the offical doc and only way for him to get to this resource is if someone gave this to him
or he is purposedly seeking for best practices. That being said, there is an implied willingness to give up his own method and learn something new. Which basically means we are not limiting his choices but rather providing him a resource which he is seeking already.

If it happen to he see he has a better way than what is indicated in the site, instead of keeping it for himself, he should send a PR so it could be shared to the community and that is how this site will evolve.

1. Unlike PHP The Right Way on which standards is decided by a group of people, one clarification here is this is a crowd-sourced project

That means, community decides what is the best practices, rather than a specific group of people.
If anyone see someone put a bad practice in the site, they are free to send a PR or open an issue for it to be corrected.
We will then decide it by having them voted in the issue. Me as the author of the site, is a mere facilitator, I don't intend to solely decide what goes in the site. Anybody could send a PR to add a specific area or use-case so that it can be reviewed by the community.

In fact, efforts has been made so that the Laravel team have an admin access to the repository, so that their team or anyone they authorized can modify things that they think is not appropriate. Same is true with other contributors who is willing to share their best practices.

1. The site cannot be shaped by personality of person who writes it. Because we are trying to collect what are those different personality, and provide different ways on how to handle those use-cases.

As I had mentioned, instead of one true way, our aim is to list out as many scenarios as possible and provide suggestions on how to deal with that particular scenario.
I would say, instead of being shaped by personlity of the person, it would be shaped by real-life use cases in the production servers.
That is why I'm encouraging people who had implemented laravel to jump in and contribute.

1. "to put up best practices (a this versus that) seems to be a bad thing"

I don't see it that way, specially if you are mentioning at which particular situation it is applicable and which it should be not.
Specially if the best practices came up from the community itself, rather than a group of people.
We are just a mere medium on which the community can place their best practices, instead of us giving them how to do a particular task.

1. This is not just for beginners

At present state, yes it might be. But as soon as contributors chimes in, it will be filled up with more advanced use cases.
There are long term plans of including snippets, large case deployment scenario, BigData, Shared hosting setup, and all other use-cases.

1. renaming the domain to laraverbeginner?

Im sorry, but I might not want to do that, since as I had indicated in the vision of the project. This site is meant to guide users from beginners to DevOps, then down to the level of Enterprise-level implementation. Throughout the time, there will be sections that covers higher level things, which make it will inappropriate if we mark this site as for "beginners only"

future contents roadmaps are:

• getting users grasp in high level overview what is Laravel and quickly find resources as quick as possible
• Scalability Concerns and Deployment Strategies
• Different ways to approach the project, like BDD, TDD and DDD, present use-cases and define scenarios on when those are feasible
• Laravel in BigData and Cloud Computing
• DevOps and Laravel
• Laravel for Scrum Team / Agile Development
• Laravel and Shared Hosting concerns - how to deal with that
• Laravel and NoSQL technologies
• Lumen and HATOEAS for RESTful JSON APIs
• ElasticSearch and DataMining with Laravel
• Managing large-scale deployment of Laravel sites using Puppet
• Polygot Persistence in Laravel

as you can see, those topics once included doesn't falls into the niche of beginners.
And I repeat, rather than basing in ideologies and personal preferences, we are planning to extract those from people who had been doing it successfully in real production servers. As a result, it is something industry-proven, economical and feasible in the end-users point of view - thus the term right way, since it somehow achieves the goal of the organization who chose to use it to achieve their goal.

As always and promised, there is no plan to monetize this site in anyway, through ads or by any means. This is to prevent any outside organization to influence its contents by flagging any commercial products and imposing their own ideologies in attempt to drive users to be inclined into particular product. Should there any commercial product, there should be always a free counterpart so that end-user has freedom to choose and evaluate it for themselves. It should be driven by community and will be always see to it that the best interests of the community is always favored.

[srph]

Pretty busy now, but it's good to hear you have some plans.

[ISTPdev]

right way of finding resources for learning laravel, from very beginner to advance. Instead of hopping through multiple blogs and threads etc.

So basically "recommended best practices" which implies "optional"

this will collect the best and "right" resources in your fingertips as voted out by the community.

Best practices don't have a "right way". Because per definition it's merely a suggestion. Right way implies that it's not optional. Because if it's not right... it's wrong.

this site doesn't tries to define a "one true way", but instead, presents a list of scenarios that users usually encounter in production use. and then, let the contributors ( the community ) share the way on how they dealt with it.

So basically like PSR? Except your name implies there is a right and wrong way, while PSR literally stands for Proposing a Standards Recommendation

Another thing to define "Right way" is to point out the bad practices that we usualy see in production use, and put a corresponding warning to prevent that from happening. One example of that is the security implementations of using "composer update" in the production servers for a Laravel application (see more at http://blog.naderman.de/2014/02/17/replace-conflict-forks-explained/)
This are some clear-cut best practices, that once pointed out could save many organizations from falling in common loopholes.

So basically Composer The Right Way? Such a poor example, no leg to stand on you have. Try again.

This site doesn't meant to limit people from doing what they want.

No apparently only confuse people with it's name like PHP The Right Way did with it's over sensationalized name.

The fact that a person goes in this site, means he is at some level of uncertainty on how to implement something.
This resource is neither mentioned in the offical doc and only way for him to get to this resource is if someone gave this to him
or he is purposedly seeking for best practices. That being said, there is an implied willingness to give up his own method and learn something new. Which basically means we are not limiting his choices but rather providing him a resource which he is seeking already.

Not really, beginners don't go looking for best practices because they don't even understand it. Someone gave it to them which means they didn't choose it. Or maybe some people use SEO and sensationalize it which makes it go all the way up in Google.

If it happen to he see he has a better way than what is indicated in the site, instead of keeping it for himself, he should send a PR so it could be shared to the community and that is how this site will evolve.

Do you see a pattern in the way you're talking? We don't have to do jack shit even if we know a better way. You should really ask things like this nicely instead of saying what people should and shouldn't do. It seems to be a recurring theme here.

Unlike PHP The Right Way on which standards is decided by a group of people, one clarification here is this is a crowd-sourced project

Aha, something I can agree with. Still my beef is not with the authors of PHP The Right Way, but the majority hivemind mentality that just follows them which is pretty hard to go up against. If I didn't know any better I would say you'd wanted to create an even bigger hivemind with the Laravel community behind you.

As I had mentioned, instead of one true way, our aim is to list out as many scenarios as possible and provide suggestions on how to deal with that particular scenario.
I would say, instead of being shaped by personlity of the person, it would be shaped by real-life use cases in the production servers.
That is why I'm encouraging people who had implemented laravel to jump in and contribute.

You're contradicting yourself again, you're repeating yourself, and i'm pretty sure you also made a spelling mistake.

as you can see, those topics once included doesn't falls into the niche of beginners.
And I repeat, rather than basing in ideologies and personal preferences, we are planning to extract those from people who had been doing it successfully in real production servers. As a result, it is something industry-proven, economical and feasible in the end-users point of view - thus the term right way, since it somehow achieves the goal of the organization who chose to use it to achieve their goal.

Wait what? Rather then basing in ideologies and personal preferences (of what your own?) you will base it on people who... wait... didn't just just say you weren't going to do that? But now you are just community driven. Dafaq. #contradiction

As always and promised, there is no plan to monetize this site in anyway, through ads or by any means. This is to prevent any outside organization to influence its contents by flagging any commercial products and imposing their own ideologies in attempt to drive users to be inclined into particular product.

Makes sense, uhmu.... go on.

Should there any commercial product, there should be always a free counterpart so that end-user has freedom to choose and evaluate it for themselves.

Oh god here we go again. So much contradiction. I'm really having a field day here. First you say no commercial products then you say should there be one there should always be a free alternative (which isn't always possible).

Not only do I believe this is completely counter-intuitive with PHP: The Right Way and you blatantly copy/paste the entire site, all of it's repos, formats and following it's exact same trajectory to hop on it's partially sensationalized name but you're also contradicting yourself constantly and you don't even seem to understand the words you're speaking, let alone know how to spell them.

I didn't 100% agree with everything in PHP The Right Way, but at least I trusted Josh Lockhart and Phil Sturgeon. They know what they'r talking about. They'v built frameworks. It seems to me you're only hopping on these two hype trains to create your own.

[assertchris]

@Blaxus Your tone is very aggressive. You don't have to agree with the purpose or direction of this effort. That's fine. The way you are addressing this is guaranteed not to get the result you want. I suggest trying a different tone. You may not want to, and that's also fine. If you can't be constructive or respectful, please leave.

[buonzz]

@Blaxus thank you for the feedbacks. first thing is i apologize for the spelling or grammatical mistakes as i haven't really had a a chance to proof-read it properly.

i think the term "right" in here is taken very shallow in its context. For example, given a very basic scenario,

"I have a very small laravel application that only caters for a small amount of users, there is only one developer involved in the process and there is no future plans to grow"

so for those cases, the developer might get overwhelmed by things if he had fully implemented full blown repository patterns, SOLID principles etc, given that he is solely working in the project. So the question is, there "right" way is a relative value depending in the situation at hand.

the example might be a little bit weak, but let me exxagerate it a bit
"is killing a people right or wrong? " - the answer is, depending in the situation. if its for self-defense and you're life is threatened, it is not wrong to kill the enemy.

But the bottomline here is, instead of having developers do the guesswork and do the digging their selves, cant you just tell them "how did you handled this particular scenario"

Its not like PSR, since PSR is very focused in language itself, while this site tends to something bigger like use-case scenarios. PSR is more of "no matter what situation you are in, i recommend you do this in your codes"

what I don't see in your point is the things on which i'm contradicting myself. Like topics about
"we don't one true way" and "we would like to get PR from people who successfully implemented it in real use cases". I think the point is straightforward -- if you have mere idea, and haven't tested it in real-life use-cases, then it is not a good candidate content to be put in the site.

then about the community-driven -- the community we are referring to here is the real people who had been using it, since they are the one who is most likely encountering this issue. I don't see a contradiction in there.

there mere fact that we are addressing the podcast feedbacks, your suggestions about the context of this site, is what is meant to fuel this site. there are great points you had raised in here and i really appreciate that.

What I just only noticed though is more of your feedback is targeted toward me, like the way how I constructed my thought process and even my sentences, even comparing me to Josh and Phil --- I appreciate that, since that would improve me as an individual, but this site is not about improving myself but rather about the laravel community itself, so lets try to not lose our focus in here.

you are vey right that Phil and Josh has way better things knew than me, I'm not even a dedicated PHP dev at all, as I'm mostly doing scrum master functions. But the thing is, like any people in the community, I'm entitled as well to my own suggestions like anybody else. And it is not like I have total control of what goes in this site, you had voted out the idea that some of my points are not valid, but then have you suggested anything better?

lets try to be constructive and think first how we could help the community and don't get carried away with our emotions with the fact that some average laravel user had came up with the idea of putting a site. Like what I've said, it is not like I'm not getting something of out this as i rarely do write codes and I'm more of project management nowadays. This has been up since January, and I'm not sure why people rushed in like a storm over the past week.

What I only did not like are non-constructive criticism that is being targeted towards me -- afaik, I own the domain and I'm living in a democratic country, so I'm legally entitled for freedom of speech specially If i'm not doing harm to other people.

I waive the right that you can correct things that is relating to best practices about laravel.
but actions that questions the existence of the domain and site in-general violates my freedom of speech and expression.

like anyone who is interested in contributing to this site, I'm entitled to my opinions as well, and you have the same equal "rights" technically to correct things relating to laravel things. So I had taken some of your points and really appreciate that you had spent time writing/reading this thread.

[srph]

Found that a bit aggressive as well, @assertchris.

One thing I thought about the future of this project is how to properly write good code by putting to good use what the framework has to offer. Not a literal "The Right Way". And like the author has mentioned, the existing information in the project is crowd-sourced. Everybody is free to contribute as this is an open-source project. It's a fairly young project.

Good work from the author, by the way 👍.

I just had the chance to properly read everything here, and opening this issue was a stupid thing. I'm closing this (again) as it's been addressed before further comments became irrelevant.

[ISTPdev]

I wish to apologize for kind of attacking @buonzz the way that I did. I just got a little carried away. I was trying to prove a point, But ultimately I never enjoy debates like this. So I'm not going ending it here.

I could debate the semantics of how you wrongly formulated something all day. But ultimately I'm not really against what you guys are trying to accomplish. I just have a problem with the name.

You all say that this is a community effort then why don't we just put it to a vote and be done with it?
Let the majority of the Laravel community decide.

My suggestion for a new name would be Laravel Best Practices just to clarify, that's not my vote, it's merely a suggestion since the prospect of not having a new name could influence the votes.

[srph]

Opening this because I'm interested in the idea. Or maybe let's start another issue to freshen the exact subject?

[buonzz]

sure, im open to the idea. i had opened another issue for this on #18
lets continue in that issue and close this one out.