- Заказчик гарантирует, что предоставляемые в соответствии с условиями настоящего Договора, Информационные материалы, не обременены требованиями третьих лиц, что Заказчик является обладателем исключительных прав на Информационные материалы и/или обладает всеми необходимыми разрешениями от авторов и иных правообладателей в отношении объектов интеллектуальной собственности, и объектов, входящих в состав произведений, а также в отношении первоначальных произведений (в случае, если произведение представляет собой переработку и/или перевод), причем такие разрешения никаким образом не должны ущемлять прав Исполнителя или затруднять использование произведения Исполнителем в соответствии с настоящим Договором.
- В случае предъявления Исполнителю претензий или исков по поводу нарушения им авторских и/или смежных прав третьих лиц в связи с использованием Информационных материалов, предоставленных Заказчиком, во исполнение условий настоящего Договора, Заказчик обязуется урегулировать такие претензии или предпринять иные необходимые действия, исключающие возникновение расходов и убытков у Исполнителя. А в случае возникновения расходов и убытков у Исполнителя, возместить их в полном объеме.
Может есть какой-то стандарт, о котором я не знаю?
(1) Make separate commits for logically separate changes.
Unless your patch is really trivial, you should not be sending
out a patch that was generated between your working tree and
your commit head. Instead, always make a commit with complete
commit message and generate a series of patches from your
repository. It is a good discipline.
Give an explanation for the change(s) that is detailed enough so
that people can judge if it is good thing to do, without reading
the actual patch text to determine how well the code does what
the explanation promises to do.
If your description starts to get too long, that's a sign that you
probably need to split up your commit to finer grained pieces.
That being said, patches which plainly describe the things that
help reviewers check the patch, and future maintainers understand
the code, are the most beautiful patches. Descriptions that summarise
the point in the subject well, and describe the motivation for the
change, the approach taken by the change, and if relevant how this
differs substantially from the prior version, are all good things
to have.
Make sure that you have tests for the bug you are fixing. See
t/README for guidance.
When adding a new feature, make sure that you have new tests to show
the feature triggers the new behaviour when it should, and to show the
feature does not trigger when it shouldn't. Also make sure that the
test suite passes after your commit. Do not forget to update the
documentation to describe the updated behaviour.
Speaking of the documentation, it is currently a liberal mixture of US
and UK English norms for spelling and grammar, which is somewhat
unfortunate. A huge patch that touches the files all over the place
only to correct the inconsistency is not welcome, though. Potential
clashes with other changes that can result from such a patch are not
worth it. We prefer to gradually reconcile the inconsistencies in
favor of US English, with small and easily digestible patches, as a
side effect of doing some other real work in the vicinity (e.g.
rewriting a paragraph for clarity, while turning en_UK spelling to
en_US). Obvious typographical fixes are much more welcomed ("teh ->
"the"), preferably submitted as independent patches separate from
other documentation changes.
Oh, another thing. We are picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
(2) Describe your changes well.
The first line of the commit message should be a short description (50
characters is the soft limit, see DISCUSSION in git-commit(1)), and
should skip the full stop. It is also conventional in most cases to
prefix the first line with "area: " where the area is a filename or
identifier for the general area of the code being modified, e.g.
. archive: ustar header checksum is computed unsigned
. git-cherry-pick.txt: clarify the use of revision range notation
If in doubt which identifier to use, run "git log --no-merges" on the
files you are modifying to see the current conventions.
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
with the current code without the change.
. justifies the way the change solves the problem, iow, why the
result with the change is better.
. alternate solutions considered but discarded, if any.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour. Try to make sure your explanation can be understood
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.
Или предложить уже действующей компании добавить функционал. Только тут снова появляется ряд вопросов, с идеи хочется получить финансовую выгоду.
// .env
BROADCAST_DRIVER=redis
// app/http/controllers/PostController.php
class PostController extends Controller
{
public function store(Request $request)
{
$post = Post::create($request);
Event::fire(new PostCreated($post));
return $post;
}
}
// app/events/PostCreated.php
class PostCreated extends Event implements ShouldBroadcast
{
use SerializesModels;
private $post;
public function __construct(Post $post)
{
$this->post = $post;
}
public function broadcastOn()
{
return [
'post_created',
];
}
public function broadcastAs()
{
return 'post_created';
}
public function broadcastWith()
{
return $this->post;
}
}
все языки хороши, каждый предназначен для своих целей...у всех свои минусы
все языки хороши, каждый предназначен для своих целей