Извините, но качество публикации откровенно низкое.
В первом же абзаце речь от первого лица, мужского рода, опубликовано от имени JuliaRezvykh с соответствующей аватаркой. Со второго же абзаца переход к «мы»… Ни пролога, ни кавычек, думай что хочешь. Ах да, после прочтения можно узнать что автор другой человек.
Далее обороты вроде «в районе 2006 года», пропуск слов, из-за чего страдает смысл («Мало кто может позволить сразу купить квартиру...») и вот это вот всё.
А смысловая нагрузка сводится к «анализируйте, прежде чем принимать важные решения».
Я знаю, что об опечатках и подобном принято сообщать в личных сообщениях, а не комментариях, но корпоративный блог — это не личная блогозапись, а публичный информационный канал компании. И тут несколько другие ожидания к качеству. Я ничего не знаю про конкретно данную компанию и чем она занимается. Меня печалит сама тенденция, что Хабр в последнее время заполнен подобными публикациями: информационная ценность низкая, тематика притянута, текст никто не вычитывал.
В классической войне делается как:
— по конвенциям разным нельзя бомбить гражданские и гуманитарные объекты.
Где бы теперь разместить секретные стратегические объекты?
Правильно, под больницами-детсадами-etc. И это вовсе не обязательно афишировать. Главное в случае попадания в гражданский/гуманитарный объект на поверхности поднимать вой, чтобы неповадно было и быстро заметать следы.
Проецируем такой подход на информационную войну: профит!
При этом объекты служащие прикрытием могут и не догадываться об опасном соседстве.
Финансовые институты блокируют. Я вот сегодня думал, глядя на рекламу карты «Мир» в метро. А на фига?
А вот возьмут и до Visa с Master card доберутся. С них станется.
Большой проблемы нет. И сложность, которую приходиться держать в уме есть всегда.
Тот же LoggerAwareTrait из PSR я использую, и лучшего решения не могу придумать.
Проблемы могут быть когда в трейте размещается реализация какого-нибудь бизнесового интерфейса. Трейт не знает какой интерфейс он реализует. И интерфейс не знает о том какие трейты его реализуют.
Вот эта неявность при рефакторинге или ревью кода может доставлять неудобства. Со всеми вытекающими: Когнитивная нагрузка, риски ошибиться, отсутствие подсказок ide, сложность статического анализа и рефлексии, дополнительные условия или соглашения в подводных тестах трейты же тоже надо тестировать, но стоит решить как...
То что надо держать что-то в уме и есть проблема — повышение когнитивной нагрузки, и вероятность ошибки при несоблюдении соглашений.
У интерфейса нет зависимости от контекста, неявного состояния, модификаторов доступа к методам и магии позднего статического связывания — нет и соответствующих проблем.
Это не значит, что нельзя спроектировать плохую систему используя интерфейсы. Но это разные уровни
— косяки дизайна на уровне программных интерфейсов
— и сложность и побочные эффекты появляющиеся из-за реализации опирающейся на «не рекомендуемые» шаблоны проектирования.
И чем больше логики в коде вынесено на интерфейсный уровень, тем может быть проще такая система в поддержке. Если про сферических коней в вакууме.
Напоминает решение проблемы, которые мы создали себе сами, начав использовать трейты.
Используя композицию не пришлось бы искать компромиссы — абстрактные классы были бы в интерфейсах, имплементация в классах, а трейты — выглядят лишней сущностей здесь.
Трейты плохи тем, что в них не очевиден контекст, в котором они исполняются. При классическом наследовании, не множественном, эта проблема тоже есть, но не так явно выражена.
В общем, композиция предпочтительнее наследования. Как раз композиция естественным путём подталкивает нас использовать интерфейсы между объектами. Наследование классов — нет, оно толкает к связности на основе реализации.
Есть такая категория фридансеров, которые пропадают внезапно, взяв заказ. И не выходят на связь.
Может этот сценарий тоже часто из-за выгорания происходит?
UID хостового пользователя в моей практике приходится использовать при запуске команд, в основном сборки приложения и разных кодогенераторов, dev tools. Чтобы артефакты, которые оказываются в файловой системе хоста и внутри проекта принадлежали пользователю (разработчику).
В runtime внутри контейнера с приложением как правило используется root, либо служебный пользователь приложения, как он определён вендором образа.
Смотрел Bitbucket Pipelines в конце 2017. Сыровато было. Конкретнее — подвела интеграция с docker, хотя аналогичные задачи решал без проблем на travis и gitlab-ci.
Круто что делитесь в таком формате: Тезисно, с ссылкам и выводами.
Спасибо.
Но идея не дурна.
В первом же абзаце речь от первого лица, мужского рода, опубликовано от имени JuliaRezvykh с соответствующей аватаркой. Со второго же абзаца переход к «мы»… Ни пролога, ни кавычек, думай что хочешь. Ах да, после прочтения можно узнать что автор другой человек.
Далее обороты вроде «в районе 2006 года», пропуск слов, из-за чего страдает смысл («Мало кто может позволить сразу купить квартиру...») и вот это вот всё.
А смысловая нагрузка сводится к «анализируйте, прежде чем принимать важные решения».
Я знаю, что об опечатках и подобном принято сообщать в личных сообщениях, а не комментариях, но корпоративный блог — это не личная блогозапись, а публичный информационный канал компании. И тут несколько другие ожидания к качеству. Я ничего не знаю про конкретно данную компанию и чем она занимается. Меня печалит сама тенденция, что Хабр в последнее время заполнен подобными публикациями: информационная ценность низкая, тематика притянута, текст никто не вычитывал.
— по конвенциям разным нельзя бомбить гражданские и гуманитарные объекты.
Где бы теперь разместить секретные стратегические объекты?
Правильно, под больницами-детсадами-etc. И это вовсе не обязательно афишировать. Главное в случае попадания в гражданский/гуманитарный объект на поверхности поднимать вой, чтобы неповадно было и быстро заметать следы.
Проецируем такой подход на информационную войну: профит!
При этом объекты служащие прикрытием могут и не догадываться об опасном соседстве.
Предлагалось на хабре же, пару лет назад, в комментариях к статье на тему блокировок, LinkidIn, что-ли…
Финансовые институты блокируют. Я вот сегодня думал, глядя на рекламу карты «Мир» в метро. А на фига?
А вот возьмут и до Visa с Master card доберутся. С них станется.
В 17-ом тоже так думали. К 37-ому за всем доехали.
Большой проблемы нет. И сложность, которую приходиться держать в уме есть всегда.
Тот же LoggerAwareTrait из PSR я использую, и лучшего решения не могу придумать.
Проблемы могут быть когда в трейте размещается реализация какого-нибудь бизнесового интерфейса. Трейт не знает какой интерфейс он реализует. И интерфейс не знает о том какие трейты его реализуют.
Вот эта неявность при рефакторинге или ревью кода может доставлять неудобства. Со всеми вытекающими: Когнитивная нагрузка, риски ошибиться, отсутствие подсказок ide, сложность статического анализа и рефлексии, дополнительные условия или соглашения в подводных тестах трейты же тоже надо тестировать, но стоит решить как...
У интерфейса нет зависимости от контекста, неявного состояния, модификаторов доступа к методам и магии позднего статического связывания — нет и соответствующих проблем.
Это не значит, что нельзя спроектировать плохую систему используя интерфейсы. Но это разные уровни
— косяки дизайна на уровне программных интерфейсов
— и сложность и побочные эффекты появляющиеся из-за реализации опирающейся на «не рекомендуемые» шаблоны проектирования.
И чем больше логики в коде вынесено на интерфейсный уровень, тем может быть проще такая система в поддержке. Если про сферических коней в вакууме.
Используя композицию не пришлось бы искать компромиссы — абстрактные классы были бы в интерфейсах, имплементация в классах, а трейты — выглядят лишней сущностей здесь.
Два года не такой большой срок...
А пруф можно?
Трейты плохи тем, что в них не очевиден контекст, в котором они исполняются. При классическом наследовании, не множественном, эта проблема тоже есть, но не так явно выражена.
В общем, композиция предпочтительнее наследования. Как раз композиция естественным путём подталкивает нас использовать интерфейсы между объектами. Наследование классов — нет, оно толкает к связности на основе реализации.
Есть такая категория фридансеров, которые пропадают внезапно, взяв заказ. И не выходят на связь.
Может этот сценарий тоже часто из-за выгорания происходит?
«Счас» — у вас и в тексте так...
В runtime внутри контейнера с приложением как правило используется root, либо служебный пользователь приложения, как он определён вендором образа.