Видимо, слишком часто стали путать авторские и имущественные права. Часто автор по договору не имеет вообщи никакого права распространять своё творение.
> Не мне, не вам, а только автору решать, как распорядиться с этими самыми пресловутыми авторскими правами.
Не автору решать, а издателю. Если автор будет выпендривать, автор будет сидеть со своим гениальным творением с пустым кошельком, а если не будет выпендривать, то получить объедки с издательского стола.
Я полтора года ждал :) Ну то есть впервые поиграл в сталкера несколько месяцев назад, когда большую часть глюков вычистили. По дурости купил диск чистого неба, на середине забросил этот ужас.
Не так всё просто, вот у нас, например, один из проектов собирался часа три как минимум. А полный сеанс автотестов занимал часов десять. Разработчик, конечно, проверяет, что у него на машине оно собралось, но делать это в автоматическом режиме самоубийственно.
В юникоде это COMBINING SYMBOL, он изменяет предыдущий символ в строке. Например, си́мвол ударе́ния — это combining symbol. Их очень много, но не все они отрисованы/корректно реализованы во всех шрифтах. Поэтому полагаться на них можно только в очень ограниченных случаях.
Про тестирование. Проводить комплексное тестирование перед коммитом очень неправильный выбор, это занимает очень много времени. В идеале всё должно покрываться несколькими уровнями тестов: юнит-тесты, автотесты. И коммитить можно при успешном выполнении локальных юнит-тестов компонента. Естественно, юнит-тесты должны также проверять межкомпонентные связи.
Про ответственного. Тут согласен. Необходим какой-нибудь инструмент коллективного обсуждения коммитов, нечто вроде Code Collaborator. Коммит принимается в VCS исключительно после положительного завершения ревью. Эта схема может показаться медленной и затратной, но на практике всё не так страшно. Большинство разработчиков быстро втягиваются в процесс, а бонусом является бо́льший кодовый кругозор каждого разработчика.
Про комментарии. В комментарии к коммиту должен стоять номер ревью в системе обсуждения изменений, зависимые баги и краткое описание изменений. Этого вполне достаточно. Естественно, все средства работы (багзилла, коллаборатор) должны быть интегрированы с VCS.
Долго медитировал над словом «фиксация», признаюсь, впервые его встречаю в таком контексте, всегда было «закоммитить». Это официальный русскоязычный термин?
Её нет нестандартных размеров. Фирма, которая выпускает электробумажные экраны, клепает их все одного размера (грубо говоря), поэтому выпуск экранов другого размера вполне может оказаться ещё затратнее.
Не автору решать, а издателю. Если автор будет выпендривать, автор будет сидеть со своим гениальным творением с пустым кошельком, а если не будет выпендривать, то получить объедки с издательского стола.
Не существует.
Вот примеры:
ш̀ ш́ ш̂ ш̃ ш̄ ш̅ ш̆ ш̇ ш̋ ш̏ ш̐ ш̳ ш̴ ш̸ ш̷ ш̿ ш͝ ш͡ шͤ шͫ ш͚ шͭ ш⃞ ш⃟ ш⃠
Про ответственного. Тут согласен. Необходим какой-нибудь инструмент коллективного обсуждения коммитов, нечто вроде Code Collaborator. Коммит принимается в VCS исключительно после положительного завершения ревью. Эта схема может показаться медленной и затратной, но на практике всё не так страшно. Большинство разработчиков быстро втягиваются в процесс, а бонусом является бо́льший кодовый кругозор каждого разработчика.
Про комментарии. В комментарии к коммиту должен стоять номер ревью в системе обсуждения изменений, зависимые баги и краткое описание изменений. Этого вполне достаточно. Естественно, все средства работы (багзилла, коллаборатор) должны быть интегрированы с VCS.