Предложение пытается объединить вещи, которые стоят совершенно различных денег.
Стоимость распространения контента не идёт ни в какое сравнение с тем, сколько стоит этот контент создать. Компании с радостью согласяться отдавать весь контент самостоятельно и не заморачиваться с торрент-системами, если пользовать согласится за контент платить. Торрент-система в связке продавец-покупатель может выступать лишь как техническое средство доставки, и учитывать его в бизнес-модели как полноценного участника никто не собирается.
Довольно полезное, чтобы предотвратить заявление «я это не ломал», «само сломалось», «это никто не трогал» и т.д.
Если что-то не работает, то по умолчанию считается, что ответственен тот, в чьём коде произошла ошибка. Не важно при этом, кто его изменял на самом деле (потому что ответственный все эти изменения обязан отслеживать).
Иначе получается ситуация с ничейным кодом. Вроде у всего есть автор, а в целом никто ни за что не отвечает.
Вот для того, чтобы тестирование не занимало много времени, тесты должны быть автоматические. Например, у меня большинство тестов — это проверка работоспособности системы целиком (от логического начала и до конца), в процессе которого обязательно должна использоваться новая/исправленная функция. Во-первых, сама функция тестируется, во-вторых, тестируется работоспособность приложения с этой функцией. И времени занимает секунд 10-15.
Про комментарии к commit согласен, но я имел ввиду комментарии в коде :)
— тестирования необходимо комплексное (желательно — всё приложение, так как сломать можно что угодно), но быстрое. Таким образом, тестировать надо автоматическими тестами. Перед тем, как положить код в хранилище, надо провести как локальные тесты (на файл, который поменялся), так и комплексное, что не сломалась работа приложения.
— за каждый участок кода ( минимальная единица — файл ) должен быть ответственный. Именно он проверяет правильность кода после того, как туда положили все изменения, и до того, как его выдадут в отдел тестирования. И чтобы не отмазывался «это не моё изменение».
— комментарии к изменениям это здорово, но нельзя переусердствовать. В одной из компаний видел методологию разработки, когда каждое изменения оборачивалось в комментарии «begin/end commit 'name' date», старый код комментировался, новый писался. Из-за чего размер некоторых файлов доходил до 2-3 тысяч строк, состоящих из одних комментариев к изменениям. Лучше не писать комментарий вида «я поменял здесь это на это», а писать комментарий «здесь должно быть вот так, потому что...». Историю изменений всегда можно посмотреть в хранилище, для того оно и служит.
Существование торсионных полей в принципе не противоречит современным положениям физики. Одно из возможных решений одной из возможных математических формулировок законов Эйнштейна действительно допускает существование полей кручения.
Но!
Согласно расчётам в настоящий момент нам просто не хватит точности приборов, чтобы отследить существование таких полей. Недавно запускали спутник с целью проверить несколько гипотез, в том числе ОТО и существование торсионных полей. И если насчёт гравитации точность экспериментов оказалась «впритык» — даже немного меньше, чем требуется (поэтому результаты под вопросом), то для нахождения или опровержения существования торсионных полей нужно будет увеличить точность ещё на 5-6 порядков. То есть даже если они и есть, их влияние настолько мало, что современной наукой пока пренебрегается в рамках экспериментов.
И, разумеется, никаких торсионных генераторов, двигателей, детекторов и пр., и пр. наука не признаёт.
Некоторые замечания (на основе собственного опыта визуализации)
1. Следует отличать связи однонаправленные и двунаправленные, когда статья в свою очередь ссылается на исходную. Это можно было бы обозначить более жирной (или более короткой) линией.
2. Следует фильтровать ссылки на статьи, которые не являются статьями в полном смысле этого слова: например, статьи о годах. Они лишь «уводят» от темы.
3. При возможности лучше парсить самому статью, и, например, присваивать разный вес ссылкам в самой статье, и ссылкам из навигационных шаблонов.
4. Иногда полезно анализировать не одну статью и её «соседей», а, скажем, взять определённую категорию с подкатегориями.
Стоимость распространения контента не идёт ни в какое сравнение с тем, сколько стоит этот контент создать. Компании с радостью согласяться отдавать весь контент самостоятельно и не заморачиваться с торрент-системами, если пользовать согласится за контент платить. Торрент-система в связке продавец-покупатель может выступать лишь как техническое средство доставки, и учитывать его в бизнес-модели как полноценного участника никто не собирается.
А код может сломаться не только сам по себе, но и из-за изменений во внешних условиях — изменения в базе данных, немного другие входные данные, и т.д.
Если что-то не работает, то по умолчанию считается, что ответственен тот, в чьём коде произошла ошибка. Не важно при этом, кто его изменял на самом деле (потому что ответственный все эти изменения обязан отслеживать).
Иначе получается ситуация с ничейным кодом. Вроде у всего есть автор, а в целом никто ни за что не отвечает.
Про комментарии к commit согласен, но я имел ввиду комментарии в коде :)
— тестирования необходимо комплексное (желательно — всё приложение, так как сломать можно что угодно), но быстрое. Таким образом, тестировать надо автоматическими тестами. Перед тем, как положить код в хранилище, надо провести как локальные тесты (на файл, который поменялся), так и комплексное, что не сломалась работа приложения.
— за каждый участок кода ( минимальная единица — файл ) должен быть ответственный. Именно он проверяет правильность кода после того, как туда положили все изменения, и до того, как его выдадут в отдел тестирования. И чтобы не отмазывался «это не моё изменение».
— комментарии к изменениям это здорово, но нельзя переусердствовать. В одной из компаний видел методологию разработки, когда каждое изменения оборачивалось в комментарии «begin/end commit 'name' date», старый код комментировался, новый писался. Из-за чего размер некоторых файлов доходил до 2-3 тысяч строк, состоящих из одних комментариев к изменениям. Лучше не писать комментарий вида «я поменял здесь это на это», а писать комментарий «здесь должно быть вот так, потому что...». Историю изменений всегда можно посмотреть в хранилище, для того оно и служит.
en.wikipedia.org/wiki/Einstein-Cartan_theory
Experimental effects are too small to be observed at the present time
Существование торсионных полей в принципе не противоречит современным положениям физики. Одно из возможных решений одной из возможных математических формулировок законов Эйнштейна действительно допускает существование полей кручения.
Но!
Согласно расчётам в настоящий момент нам просто не хватит точности приборов, чтобы отследить существование таких полей. Недавно запускали спутник с целью проверить несколько гипотез, в том числе ОТО и существование торсионных полей. И если насчёт гравитации точность экспериментов оказалась «впритык» — даже немного меньше, чем требуется (поэтому результаты под вопросом), то для нахождения или опровержения существования торсионных полей нужно будет увеличить точность ещё на 5-6 порядков. То есть даже если они и есть, их влияние настолько мало, что современной наукой пока пренебрегается в рамках экспериментов.
И, разумеется, никаких торсионных генераторов, двигателей, детекторов и пр., и пр. наука не признаёт.
1. Следует отличать связи однонаправленные и двунаправленные, когда статья в свою очередь ссылается на исходную. Это можно было бы обозначить более жирной (или более короткой) линией.
2. Следует фильтровать ссылки на статьи, которые не являются статьями в полном смысле этого слова: например, статьи о годах. Они лишь «уводят» от темы.
3. При возможности лучше парсить самому статью, и, например, присваивать разный вес ссылкам в самой статье, и ссылкам из навигационных шаблонов.
4. Иногда полезно анализировать не одну статью и её «соседей», а, скажем, взять определённую категорию с подкатегориями.
5. Некоторые результаты визуализации в 3D можно посмотреть тут:
www.youtube.com/user/vlsergey
Некоторые компании, наоборот, сокращают наборы.