Армянское Радио, это если напряжение в сети от перегрузки не начнет куролесить.
Я не знаю как устроена электросеть вагона, поэтому рисковать бы не стал.
tr0st0, Ну откуда ж я знаю какое у вас реле и что написано в паспорте на него?
Посчитайте самостоятельно ток и напряжение с вашими резисторами. Я в ответе четко написал что резистор в коллекторное цепи требуется подобрать под ваши условия.
Закон Ома проходят в школе, а больше тут ничего и не надо.
tr0st0, Ну так посчитайте что у вас получается при открытом и закрытом транизисторе.
С таким резистором в эмиттере у вас получается делитель напряжения 102 Ом в верхнем плече и 1464 Ом в нижнем (откуда, кстати, такая точность? Это никак не ряд E24). Итого на выходе при открытом транзисторе будет ~19.6 В. А при закрытом ~21 В (и дальше все зависит от сопротивления нагрузки). Как-то не очень такой инвертор инвертирует, не находите?
Александр Кудрявцев, тогда тут такой вопрос: сервис будет вызывать вебхук даже если запись не изменилась?
Сервис А - изменили запись.
Он вызвал сервис Б - изменил данные там
Сервис Б вызывал сервис А - но данные в сервисе А и так уже актуальны
Будет ли сервис А вызывать вебхук, если данные не изменились?
Если будет - то придумывать что-нибудь на уровне сервиса-посредника. Например, чтобы он отслеживал-запоминал (сохранял в свою БД) какие хуки с какими данными пробежали и в случае такой ситуации (обновление данных совпадающее с тем, которое уже было. в пределах вот только что, нескольких минут) просто игнорировал вебхук, не пробрасывая его дальше.
В условиях одновременных запросов может не сработать - будут добавлены 2 записи с интервалом менее 24 часов. Как вариант - блокировать таблицу, но это такое себе...
Впрочем, до конца не понятно чего именно хочет добиться вопрошающий.
Dmitry Roo Видимо это особенности вашей MB. Потому как у меня Ryzen 1700 с чипсетом B350 - у модулей памяти разный CL (стоит 2х8 + 2х16 = 48 Гб). Все завелось и нормально работает. Вот скриншот из CPU-Z.
Jeff_Parker, на самом деле, когда читаешь эти книги имея опыт говнокодинга, то многое встает на свои места со звуком "ах тыж, блин! Где ты раньше был, когда я по этим граблям танцевал?"
Когда читаешь эти книги не имея такого опыта - часто возникает недоумение "ну зачем все так сложно? Я же могу сделать проще, быстрее и с таким же результатом". Но во втором случае тут важно понимать - "дядюшка Боб" очень опытный программист-практик (и остальные авторы популярных книг - тоже). И за его советами обязательно что-то стоит. И можно попробовать делать так как он рекомендует, просто в режиме "так надо". И по мере набора опыта тоже начнет появляться понимание - вот это решение мне облегчило жизнь здесь. Вот это здесь. Это может быть облегчит в будущем. А вот это я пока не понимаю... И постепенно придет опыт, начнется формирование вашего личного инструментария хороших практик. Какие-то вещи, предлагаемые авторами книг вы возьмете без изменений, какие-то подстроите под себя, под свой стиль, от каких-то откажетесь полностью. И это нормальный процесс.
Jeff_Parker, с архитектурой вопрос весьма непростой. И тут, как водится, две крайности:
1. "Как бог на душу положит". Ну то есть "что сейчас надо сделать - то и пишем. Через какое-то время (большое или малое - непринципиально) сопровождать это станет невозможно и придется "выкинуть и переписать с нуля". В принципе вполне пригодный подход, если речь идет о прототипе. Прототип - это некий демонстратор принципа, технологии, который всегда идет в мусорку после того как выполнил свою задачу.
2. Читая, хорошая, правильная архитектура. Тут я отправлю читать Р. Мартина - "Чистый код", "Чистая архитектура" и "Идеальный программист". Главный принцип хорошей архитектуры - это разделение на модули, каждый из которых выполняет какую-то свою задачу + изоляция этих модулей (взаимодействовать одни должны только через определенной API) + иерархия зависимостей (модули, содержащие абстрактную логику не должны зависеть от модулей содержащих детали реализации - "детали зависят от абстракций, но не абстракции от деталей") + покрытие тестами (в идеале TDD).
Главное преимущество хорошей архитектуры - система может развиваться долго и успешно.
Главный недостаток (с точки зрения бизнеса) - она небесплатна, это требует ресурсов на разработку и поддержание.
Истина, как всегда зависит от конкретных условий в которых вы работаете :)
Я не знаю как устроена электросеть вагона, поэтому рисковать бы не стал.