Я отнёс их к скриптам. Потому что они запускают свои сценарии непосредственно на серверах, на которые делается установка.
В этом смысле, они подвержены тем же проблемам. Хотя, конечно, они лучше справляются с задачей, чем самописные shell скрипты.
Если вы о возможности сравнить два образа, то такого нет. Образы — это бинарные файлы. Неясно как их сравнивать.
Здесь логичнее хранить Dockerfile в какой-то системе контроля версий.
Из него всегда можно сделать образ. И тут история изменний будет прозрачна.
Это зависит от моих целей. Прямо сейчас я скажу, что не заинтересован делать проект на таких условиях.
А вот 14 лет назад, когда мы с парой друзей начинали свой бизнес я отвечал иначе. Я соглашался на любые условия, потому что для меня жизненно важно было иметь заказчиков. Любых. Хороших тогда у меня не было.
Только не говорите мне, что он этого не потерпит, уйдёт к другому. Не уйдёт. Потерпит..
Кто-то потерпит, кто-то уйдёт.
Когда вам нет смысла цепляться за любого заказчика любой ценой, это для вас неважно. Уйдёт так уйдёт.
Очень удобно всё свалить на горе-заказчика.
Если вы о «мыши плакали, кололись, но продолжали есть кактус», то соглашусь. Но бывает и такая ситуация: «Здесь и сейчас мне нужен этот заказчик и я буду играть по его правилам. Как только ситуация позволит, я это изменю.»
Не все заказчики это понимают. Иногда в ход идёт вот такая двойка:
1) «Соображения моего бизнеса требуют, чтобы мы показали первую версию в след. понедельник. На качество пофиг. Не успеем — проекта не будет.»
2) «Так всё же уже работает, осталось только пофиксить баги. Вот вам на это ещё два дня — я щедрый»
Разумеется, правильно будет не работать с такими. Но не у всех и не всегда есть выбор.
Все же есть какой-то размер проекта, где TDD избыточен. Крайний случай — я пишу одноразовый скрипт на перле, который выброшу после обработки одного текстового файла. В скрипте 5 строк.
А вот где граница между таким случаем и проектами, где TDD полезен каждый определяет по собственному опыту.
Для меня граница проходит примерно по проекту размером в человекомесяц, писанному одним человеком и без перспектив развития.
Возможности, конечно, были ниже. Но вот какого-то драматического скачка, в развитии именно IDE, делающего какие-то книги устарешими, на мой взгляд, за последние 15 лет не было. Рефакторинг уже был, хотя и гораздо слабее.
Хорошее API — это такое, которое удобно использовать и практично реализовывать. TDD помогает в первом аспекте и не помогает во втором. В этом моя мысль.
TDD не отменяет необходимости думать о реализации. Он лишь заставлет думать и об удобстве исрользования.
Важны оба аспекта. TDD помогает в одном. Вы критикуете его за то, что не помогает во втором. Но ведь он — не серебряная пуля, чтобы решать абсолютно все проблемы.
Только на маленьких проектах. На долгоживущих получается более медленный старт, и здесь расходы выше. Но потом они «отбиваются» за счет сохранения постоянной скорости разработки новых версий. В проекте без TDD функция расходов на внесение измнений от времени обычно становится экспоненциальной.
Здесь должен быть тонкий момент при разблокировки горутины, которая висит на нескольких каналах.
Когда в один из каналов придут данные, нужно каким-то образом одной атомарной операцией убрать горутину из recvq всех каналов, которые она слушала. lock какого-либо канала для этого использовать нельзя.
Интересно, как это делается.
У нас еще не было релиза. Поэтому такие смелые.
Но плюсы ощутимы. Кроме решения проблемы gc оно еще и процессора есть примерно на 35-30% меньше, чем 1.6
Сам файл вместо 6.5мб весит 4.5 (хотя последнее и не важно для нас)
Кстати, тут есть не понятный момент. Пусть у меня есть select, который читает из двух каналов.
Default части нет.
Как это работает? Мы ведь не можем заблокировать горутину на одном из каналов (вдруг сообщение придёт в другой?)
Неужели оно бесконечно проверяет оба канала неблокируя совсем? Вряд ли же.
Обновил go в своей многопользовательской игре (сервер).
Результат — примерно на 30% меньше ест процессорного времени.
И, главное, теперь можно не отключать GC! Его работа больше не тормозит игру.
Это очень, очень здорово!
Вы хотите, чтобы из Go сделали Java? Так java уже есть.
В Go ООП присутствует, хотя и переомысленный и довольно специфический.
Кстати, довольно удобный на практике.
В этом смысле, они подвержены тем же проблемам. Хотя, конечно, они лучше справляются с задачей, чем самописные shell скрипты.
Здесь логичнее хранить Dockerfile в какой-то системе контроля версий.
Из него всегда можно сделать образ. И тут история изменний будет прозрачна.
Это зависит от моих целей. Прямо сейчас я скажу, что не заинтересован делать проект на таких условиях.
А вот 14 лет назад, когда мы с парой друзей начинали свой бизнес я отвечал иначе. Я соглашался на любые условия, потому что для меня жизненно важно было иметь заказчиков. Любых. Хороших тогда у меня не было.
Кто-то потерпит, кто-то уйдёт.
Когда вам нет смысла цепляться за любого заказчика любой ценой, это для вас неважно. Уйдёт так уйдёт.
Если вы о «мыши плакали, кололись, но продолжали есть кактус», то соглашусь. Но бывает и такая ситуация: «Здесь и сейчас мне нужен этот заказчик и я буду играть по его правилам. Как только ситуация позволит, я это изменю.»
Он полагается на своё «профессиональное» чутье :)
У меня, к счастью, больше нет таких заказчиков.
Когда были, то приходилось тратить до 70% времени на переговоры.
Моя мысль не в том, что это правильно. А в том, что часто TDD и другие полезные практики не используются под давлением таких вот горе-заказчиков.
1) «Соображения моего бизнеса требуют, чтобы мы показали первую версию в след. понедельник. На качество пофиг. Не успеем — проекта не будет.»
2) «Так всё же уже работает, осталось только пофиксить баги. Вот вам на это ещё два дня — я щедрый»
Разумеется, правильно будет не работать с такими. Но не у всех и не всегда есть выбор.
А вот где граница между таким случаем и проектами, где TDD полезен каждый определяет по собственному опыту.
Для меня граница проходит примерно по проекту размером в человекомесяц, писанному одним человеком и без перспектив развития.
Важны оба аспекта. TDD помогает в одном. Вы критикуете его за то, что не помогает во втором. Но ведь он — не серебряная пуля, чтобы решать абсолютно все проблемы.
Только на маленьких проектах. На долгоживущих получается более медленный старт, и здесь расходы выше. Но потом они «отбиваются» за счет сохранения постоянной скорости разработки новых версий. В проекте без TDD функция расходов на внесение измнений от времени обычно становится экспоненциальной.
Когда в один из каналов придут данные, нужно каким-то образом одной атомарной операцией убрать горутину из recvq всех каналов, которые она слушала. lock какого-либо канала для этого использовать нельзя.
Интересно, как это делается.
Но плюсы ощутимы. Кроме решения проблемы gc оно еще и процессора есть примерно на 35-30% меньше, чем 1.6
Сам файл вместо 6.5мб весит 4.5 (хотя последнее и не важно для нас)
Теперь его не отключаем, ибо он и так незаметен.
Default части нет.
Как это работает? Мы ведь не можем заблокировать горутину на одном из каналов (вдруг сообщение придёт в другой?)
Неужели оно бесконечно проверяет оба канала неблокируя совсем? Вряд ли же.
Результат — примерно на 30% меньше ест процессорного времени.
И, главное, теперь можно не отключать GC! Его работа больше не тормозит игру.
Это очень, очень здорово!
В Go ООП присутствует, хотя и переомысленный и довольно специфический.
Кстати, довольно удобный на практике.