При работе с таймаутами в распределенных системах еще возникает вот такая коллизия:
Есть сервис, который выполняет какие-то операции и вызывает другой сервис. Этот сервис тоже выполняет операции и вызывает сервис. Наконец, последний сервис просто что-то делает. У каждой операции в пайплайне есть свой таймаут, например 10 секунд. Если собственные операции каждого сервиса будут работать по 4 секунды, то на гейтвее может случиться ошибка таймаута, хотя каждый сервис отработал за корректное время. Вы как-то решаете подобные проблемы?
В core вроде как вызовы .Result и .Wait() не могут приводить к дедлокам, насколько мне известно. Хотя, конечно, ничто не мешает в этом примере заавейтить результат.
Поправьте меня, если я ошибаюсь? Есть ли какие-то другие подводные камни, кроме тех что исчезли с уходом контекста синхронизации?
Но разве для ранчера не нужна чуть ли не 16.04 или вообще своя сборка ядро+докер? Что если мне хочется 19+ версию убунты (если честно, не уверен, зачем)?
Еще добавлю свои пять копеек. Допустим, на вашем ресурсе пользователям доступна кастомная верстка с возможностью добавлять «спойлеры». Вы предоставляете контент по API в виде html, чтобы ускорить отображение (пусть даже с какой-то конфигурацией). Теперь у вас есть выбор — либо использовать checkbox для того чтобы открывать/закрывать содержимое, либо вешать listener на документ, чтобы подгружаемые по xhr спойлеры сразу работали. Притом если по какой-то причине исполнение js прервется до навешивания этого слушателя, то спойлеры вообще не будут работать.
Ну и, понятное дело, что если вы используете какой-нибудь react или vue — в вашу сторону за такие «навешивания» будут коситься.
Нативное решение для достаточно популярного элемента интерфейса — это всегда лучше чем пусть и проверенные временем костыли.
Выразить-то совершенно запросто можно, выражение — это соглашение. Любая инъекция, в образе которой содержится число 256, будет являться валидной, нет?
There's another way to solve the default ports problem without using the «UseUrls» method:
In we can put the environment variable right in the dockerfile like CMD ASPNETCORE_URLS=http://*:$PORT dotnet myapp.dll
У меня очень много знакомых психологов, они говорят что последнее время на учёбу к ним (например в «гармонию») стали приходить программисты в большом количестве. Насколько я успел понять, на том же б17 их тоже немало (по обе стороны).
Я научился слепой печати по ночам играя в Warcraft III. Свет приходилось тушить, чтобы родители не погнали из-за компьютера, старый компьютерный стол (с выезжающей полкой под клавиатуру) был сконструирован так, что на клавиатуру ложилась густейшая тень. Когда я начал программировать, как-то само собой оказалось, что я бодренько печатаю вслепую. Спасибо Blizzard за успешную карьеру программиста!
А «цену» тикета кто определяет? Разработчик может отказаться от задачи, если не согласен с её ценой?
Может быть, я морально не готов к этой прорывной идее или неправильно понял посыл статьи — но это все звучит как описание очередной галеры с небезызвестного сайта на домене .it — и менеджер-евангелист, который, разумеется, может писать код сутки напролёт, и невероятный контроль на рабочем месте (про игру престолов нельзя говорить, линтер пишет код за тебя, потому что менеджер для себя решил что никто не умеет писать код [как ему нравится]), неопределенная зарплата по тайным kpi.
Два года в vuejs. Начинал с первой версии. Я три с половиной года назад писал spa на второй версии. Или у товарища так себе с актуализацией технологии, или статья морально устарела.
Я стараюсь использовать VerifyNoOtherCalls только когда используются какие-то внешние зависимости, которые чаще всего приводят к проблемам — базы данных здесь в приоритете, так что репозитории, по-моему, лучше как-то контроллировать.
Если возникнет необходимость дважды вызывать репозиторий, то тогда конечно придется этот тест переписывать, но по-моему лучше держать архитектуру такой, чтобы этого не случалось, если есть возможность.
По поводу структуры — предпочитаю не повторять структуру неймспейсов из тестируемого проекта, вместо этого просто держу все в папках с названиями классов, а внутри делю по тестовым классам по методам или даже подметодам. В случае с примером выше, можно даже целый тестовый класс назвать AuthenticationService.AuthenticateWithCorrectTokenShould. Критерия по разделению строго нет, просто слежу за тем, чтобы тестовые классы не становились слишком жирными. Для этого еще отдельно обращаю внимание на неиспользуемые зависимости, стараюсь, чтобы их было поменьше. Это, как мне кажется, помогает придерживаться SRP, а в итоге вместо обычных для индустрии медиаторов типа CommentaryService, где сложена вся логика работы с комментариями, у меня есть CreateCommentaryService, DeleteCommentaryService, LikeCommentaryService и ReplyCommentaryService. Все классы строго отвечают за бизнес-процессы, очень легко покрываются тестами, которые даже не всегда надо разносить по разным файлам (как можно понять по названиям, в них редко бывает больше одного метода).
Пока вроде бы устраивает, что получается. В основном даже не в самих тестах, а в том, как меняется код, чтобы повысить свою тестабильность.
Есть сервис, который выполняет какие-то операции и вызывает другой сервис. Этот сервис тоже выполняет операции и вызывает сервис. Наконец, последний сервис просто что-то делает. У каждой операции в пайплайне есть свой таймаут, например 10 секунд. Если собственные операции каждого сервиса будут работать по 4 секунды, то на гейтвее может случиться ошибка таймаута, хотя каждый сервис отработал за корректное время. Вы как-то решаете подобные проблемы?
Поправьте меня, если я ошибаюсь? Есть ли какие-то другие подводные камни, кроме тех что исчезли с уходом контекста синхронизации?
Ну можно сделать в любом случае some?.method?.call(some, args);
Хотя выглядит не особо. Но выше пишут, что в стандарте есть более элегантное решение.
Мы все держим за вас кулачки. Вебасм в президенты!
Это радует, а то на моей последней попытке падал старт etcd ноды под 18.04 и на форуме ответили дескать так и нужно.
Ну и, понятное дело, что если вы используете какой-нибудь react или vue — в вашу сторону за такие «навешивания» будут коситься.
Нативное решение для достаточно популярного элемента интерфейса — это всегда лучше чем пусть и проверенные временем костыли.
In we can put the environment variable right in the dockerfile like
CMD ASPNETCORE_URLS=http://*:$PORT dotnet myapp.dllМожет быть, я морально не готов к этой прорывной идее или неправильно понял посыл статьи — но это все звучит как описание очередной галеры с небезызвестного сайта на домене .it — и менеджер-евангелист, который, разумеется, может писать код сутки напролёт, и невероятный контроль на рабочем месте (про игру престолов нельзя говорить, линтер пишет код за тебя, потому что менеджер для себя решил что никто не умеет писать код [как ему нравится]), неопределенная зарплата по тайным kpi.
Если возникнет необходимость дважды вызывать репозиторий, то тогда конечно придется этот тест переписывать, но по-моему лучше держать архитектуру такой, чтобы этого не случалось, если есть возможность.
По поводу структуры — предпочитаю не повторять структуру неймспейсов из тестируемого проекта, вместо этого просто держу все в папках с названиями классов, а внутри делю по тестовым классам по методам или даже подметодам. В случае с примером выше, можно даже целый тестовый класс назвать AuthenticationService.AuthenticateWithCorrectTokenShould. Критерия по разделению строго нет, просто слежу за тем, чтобы тестовые классы не становились слишком жирными. Для этого еще отдельно обращаю внимание на неиспользуемые зависимости, стараюсь, чтобы их было поменьше. Это, как мне кажется, помогает придерживаться SRP, а в итоге вместо обычных для индустрии медиаторов типа CommentaryService, где сложена вся логика работы с комментариями, у меня есть CreateCommentaryService, DeleteCommentaryService, LikeCommentaryService и ReplyCommentaryService. Все классы строго отвечают за бизнес-процессы, очень легко покрываются тестами, которые даже не всегда надо разносить по разным файлам (как можно понять по названиям, в них редко бывает больше одного метода).
Пока вроде бы устраивает, что получается. В основном даже не в самих тестах, а в том, как меняется код, чтобы повысить свою тестабильность.