Вы перешли от тестирования поведения к тестированию реализации
В публичное API тестируемого типа вылезли ручки связанные с тестированием
Не вылезли, опять же, они там были. Если держаться в рамках статьи.
В примере разве сказано, что у нас есть неэкспортированные методы, которые мы сделали экспортированными? Нет. Получается, что у нас были уже экспортированные методы. Значит они уже с тестами.
А отсюда получается, что если надо сделать дополнительные методы, которые по какому-то стечению обстоятельств среди прочего вызывают другие экспортированные методы, но не изолировать эти вызовы, то мы получим тестирование одного через другое. Другими словами тестировать A, B, C через D, когда тесты для A, B, C уже есть. И вот это – неправильно и хрупко.
забыть сделать вызов через .this
Как это можно забыть, если вы этот вызов изолируете и ожидаете вызов в тесте?
Хуже всего, что Вы предлагаете это решение как паттерн
Даже в мыслях не было.
Ну и в целом, да, я согласен вот с этим вот всем, что плохо, когда вы выносите на верх, тестируете детали реализации, про то, что надо хорошо рефакторить, правильно разделять и бла-бла.
Но эта статья не про это.
Эта статья про изоляцию вложенных вызовов. Это про приём избавляющий от проблем, когда вы имеете на руках вложенные вызовы.
Ну как бы да, но это не то же самое, что управление кластером. Вот (не совсем в курсе как у кубернейтс) в режиме роя, докер имеет менеджер ноды, которые раздают таски шедулеру для изменения стейта роя. Вот это больше похоже на оркестрацию. Нежели compose, который скорее инструмент, что бы не не делать много «docker run ...» и «docker volume/network create ...» ручками.
Всё нет времени разобраться с кубернейтс. Скажите, как вам этот инструмент? Намного сложней сварма при реальной эксплуатации? Хочется простоты и полного понимания того, что происходит с кластером. Поэтому изначально был выбран сварм. Но вижу много хороших отзывов о кубернейтс и всё не могу для себя решить, стоит ли присмотреться.
Вот еще один мало обсуждаемый аспект (как мне показалось). Как же контейнерам подключать данные? Ведь информация же должна быть не убиваемой. Ну и вот одно из решений — подключение NFS в контейнеры. Этот вариант кажется хорош со всех сторон. Но вот какого-то простого how to нет. На docker-compose в основном примеры. А как же это сделать на docker swarm примеров мало. Может даже не так уж и мало, но авторы статей вываливают кучу опций монтирования, которые малопонятны для простых обывателей.
Тема интересная и новым людям моск иногда взрывает. Ибо репликаций одного контейнера может быть много, а может это и глобальный контейнер. И как это провернуть если система работает на 20 физических машинах например? В общем, неплохо было бы статью про то как сделать это сначала на compose, а потом безболезненно перенести на swarm.
А еще, сервисы должны быть готовы, что другие сервисы могут быть еще не готовы или внезапно упали в произвольном количестве. Об этом вроде Фаулер писал.
Надо было наверно еще рассказать как из локальных сборок (используя docker-compose) потом всё перенести на прод, на swarm например. А еще лучше, как это сделать используя, например, Jenkins Blue Ocean (ибо тоже создан для облегчения понимания), как тестить сборки и получать вывод в дженкинсе же. Тогда наверно смысла было бы больше. Хотя, это наверно на книжку материала.
Статья выглядит как некоторые современные фильмы. Только вроде всё начинается и тут уже титры… Рассчитывал прочитать еще и рассказ про то, как же всё было изменено в этой компании.
А вы alt+tab пробовали? :) На маке есть еще жест свайп 3 пальца вверх и получаем обзор (как когда в гноме тыкаешь мышью в левый верхний угол). Есть еще жест 3 пальца свайпом влево/впрово – это когда надо меж столами переключаться. Короче, если у вас не было опыта работы на 13'' маке, то вынужден констатировать, что, вероятно, проблемы надуманные. Ну а если пробовали или вам надо много прям окошек мониторить одновременно, то конечно да, это может стать проблемой, но тут, вероятно опять же, вы как-то не очень верно организовали рабочий процесс. Человек не может одновременно за многими окошками следить, такчто, есть ли смысл заграмождать место?
Сначала у меня был lenovo g550. В целом он мне очень нравился. Особенно нравилось то, что он был именно мой, а не тот, которым пользовались и родители тоже. По сравнению со стационарником (проц помню amd64 был), он мне аццки нравился. Со временем, игрушки он тянуть перестал, да и переход с win xp на 7 прошел у меня не очень гладко. Пришлось поднапрячься и приобрести что-то более крутое. Это был lenovo g770. И вот тут я начал понимать разницу. Что более высокое разрешение экрана лучше, что более крутой проц (core 2 duo vs core i3) это экономит время, что островная клавиатура как-то ощущается лучше и наверно что-то еще. В то время я начал заниматься linux и более серьезно погрузился в web-разработку. Но аццкие размеры g770 убивали всякое желание куда-то выбираться с этим монстром. Поэтому использовался он практически как стационарник. Заряда хватало на 2 1/2 часа. Кароче далеко не уйдешь. И вот после лет 3-4 начало формироваться мое представление о идеальном компьютере. Компактный, прочный, с высоченным разрешением (не более 15'' по диагоняли), неумирающей батареей, качественной клавой (с подсветкой), здоровенным тачпадом и каким-нить юниксом под капотом. И тут я понял, что мечтаю о макбуке. Собственно уже почти год сижу на macbook pro 13'' (MacBook Pro (13-inch, 2016, Two Thunderbolt 3 ports), 2 GHz Intel Core i5, 8 ГБ 1867 MHz LPDDR3, Intel Iris Graphics 540 1536 МБ). Даже не представляю себе, как можно работать на чем-то другом. Помимо эргономики и выдающейся жизни батареи (около 10 часов и 8ми часов в режиме интенсивного использования) тут os x, 320dpi (если не ошибаюсь) и это на 13'' экране! (в лупу пиксель не увидишь!) Офигительный тачпад, четкая клава. И это вышло относительно недорого, около 119 тысяч. У меня этот мак окупился уже раз 5-7 наверно. Работаю с удовольствием и перестал париться на счет железа и софта вообще. Ну и еще момент, что при переезде с убунты надо было чем-то заменить keepass. Самым лучшим кандидатом был выбран 1password, который обошелся в 4500+ рублей. Но это единственная прога, которую я купил не для работы (ну и для работы тоже) за свой счет. Решил не скупиться за безопасность логинов/паролей. Не могу сказать правильно ли я сделал. Весь остальной софт либо хорош тот что в комплекте, либо есть порты под мак типа vlc, transmission и т.д.
«нарушение принципа единственной ответственности»
Вебсокет сервер при методе, который я описываю, продолжает выполнять 1 роль – быть тупой шиной и перегонять данные от бэкенда к клиентам.
«парсингом вывода»
Это делают процессы, которые он запускает
«и перезапуском упавших процессов»
По этой де логике можно сказать, что, да, мы нарушаем принцип единой ответственности ибо сервер реагирует не только на ondata, но и на onopen, onclose, onerror, вызывает методы контроллеров при событиях…
Либо мы не понимаем друг-друга, либо вы – знатные тролли, господа :)
Вы же знаете, что подключаете? Скрипт, который вы написали или сторонняя программа через обертку? В любом случае, не стоит конечно подключать что-то абсолютно не имея представления о том что там идет в вывод…
На счет ошибок: еще есть stderr.
На счет выпадения скрипта полностью. Есть возможность сделать так:
$process->on('exit', function($exitCode, $termSignal) use ($process) {
$process->start($server->loop);
// или через фабрику
});
А в целом конечно лучше через обертку запускать (хотя это тоже под большим вопросом), которая сама будет там ответственна за перезапуск отвалившихся частей.
Полагаю, лучше всё это на практике потестить.
В общем, суть не в том, что делает сам процесс, а в методе подключения реакции на данные в сервер. Мы изначально не разделили понятия. Я говорю про то, как подключить данные, а не как получать, когда они придут.
На один ли меньше? Надо «подключить» к петле промис/контекст/корутину/елду или как там называется абстракция которую запрограммировали разработчики, что бы подключить реакцию на данные из сокета… В общем не меньше. Подключать придется. Но можно изучать как подключать каждое что там надо подключить или 1 метод. Поэтому я и считаю, что это проще/меньше теории и универсальней.
С одной стороны вы правы, что надо знать «модуль» реакта, но в моем примере минус исчислимый – один, а в вашем примере, количество минусов может варьироваться в зависимости от того, что надо подключать к петле событий, тоесть:
— Теория/абстракции несравнимо проще (либо промисы/контексты/корутины/елды/ватева, либо in/out/err выхлоп процесса)
— Универсальность: можно подключить программу на любом языке, которая являться может чем угодно
Невероятно, до рашен it дошел temporal 🎉😀
Примеры для PHP SDK https://github.com/temporalio/samples-php
Выдохните уже ))
Вы тут тучи сгущаете. Я про приём изоляции, а вы уже про уход сотрудников из-за повышенной сложности.
Какой-то это перегиб как по мне.
Да нет, всё верно. 🙂
Не вылезли, опять же, они там были. Если держаться в рамках статьи.
В примере разве сказано, что у нас есть неэкспортированные методы, которые мы сделали экспортированными? Нет. Получается, что у нас были уже экспортированные методы. Значит они уже с тестами.
А отсюда получается, что если надо сделать дополнительные методы, которые по какому-то стечению обстоятельств среди прочего вызывают другие экспортированные методы, но не изолировать эти вызовы, то мы получим тестирование одного через другое. Другими словами тестировать A, B, C через D, когда тесты для A, B, C уже есть. И вот это – неправильно и хрупко.
Как это можно забыть, если вы этот вызов изолируете и ожидаете вызов в тесте?
Даже в мыслях не было.
Ну и в целом, да, я согласен вот с этим вот всем, что плохо, когда вы выносите на верх, тестируете детали реализации, про то, что надо хорошо рефакторить, правильно разделять и бла-бла.
Но эта статья не про это.
Эта статья про изоляцию вложенных вызовов. Это про приём избавляющий от проблем, когда вы имеете на руках вложенные вызовы.
Вот именно. Да.
А Temporal никто даже и не вспомнил почему-то... 🤷♂️
Всё нет времени разобраться с кубернейтс. Скажите, как вам этот инструмент? Намного сложней сварма при реальной эксплуатации? Хочется простоты и полного понимания того, что происходит с кластером. Поэтому изначально был выбран сварм. Но вижу много хороших отзывов о кубернейтс и всё не могу для себя решить, стоит ли присмотреться.
Тема интересная и новым людям моск иногда взрывает. Ибо репликаций одного контейнера может быть много, а может это и глобальный контейнер. И как это провернуть если система работает на 20 физических машинах например? В общем, неплохо было бы статью про то как сделать это сначала на compose, а потом безболезненно перенести на swarm.
Вебсокет сервер при методе, который я описываю, продолжает выполнять 1 роль – быть тупой шиной и перегонять данные от бэкенда к клиентам.
«парсингом вывода»
Это делают процессы, которые он запускает
«и перезапуском упавших процессов»
По этой де логике можно сказать, что, да, мы нарушаем принцип единой ответственности ибо сервер реагирует не только на ondata, но и на onopen, onclose, onerror, вызывает методы контроллеров при событиях…
Либо мы не понимаем друг-друга, либо вы – знатные тролли, господа :)
На счет ошибок: еще есть stderr.
На счет выпадения скрипта полностью. Есть возможность сделать так:
$process->on('exit', function($exitCode, $termSignal) use ($process) {
$process->start($server->loop);
// или через фабрику
});
А в целом конечно лучше через обертку запускать (хотя это тоже под большим вопросом), которая сама будет там ответственна за перезапуск отвалившихся частей.
Полагаю, лучше всё это на практике потестить.
И какая разница, звОним мы или звонИм? Дозваниваемся же…
— Теория/абстракции несравнимо проще (либо промисы/контексты/корутины/елды/ватева, либо in/out/err выхлоп процесса)
— Универсальность: можно подключить программу на любом языке, которая являться может чем угодно
Мне кажется или мы про Яблоки vs. Апельсины? :)