Пришел к такому выводу относительно написания юнит тестов - CPU-bound методы обычно идеально подходят под юнит тесты. Пример: хмл парсер с кучей corner-cases внутри. Генерим разные xml на входе, проверяем правильность объектов на выходе. Любые функции, которые хитро что-то высчитывают, регулярки там всякие. Такого кода обычно очень мало в большом проекте. Писать такие тесты даже где-то приятно. IO-bound ETL функции - аля "прочитай из базы - передай дальше в другой микросервис" (99% функционала в больших e-com компаниях) превращаются в бесполезные "the code I wrote is the code I wrote" проверки, которые просто дублируют всю логику. Такие тесты изматывают и угнетают, я их пишу исключительно для прохождения барьера по покрытию (в больших компаниях иначе не задеплоить свой код). Кстати, с появлением AI помощников появилась надежда, что наконец-то написание этих ваших тестов для IO ETL методов можно спихнуть на AI бота. Но пока чето не очень, именно такие тривиальные, казалось бы, методы chatgpt почему-то очень плохо пока умеет и получается корявенько.
Обожаю когда выбирают модную технологию (с непонятными подчеркиваниями в простейшем коде), тратят кучу времени на отключение основных фич типа GC, и в итоге счастливы, что избавились от С++
Как именно выбирается "самый быстрый" клиент для соединения? Например, если в графе сотни клиентов, и появляется новый клиент К, как ему подключиться к самому близкому для него (по rtt) клиенту в этом графе?
С rust-ом возникает другая проблема - большую часть времени тратишь на изучение "правильного обхода" ограничений, которые понатыканы буквально везде (а обходить их придется, если писать что-то более сложное чем hello world)
Для справки следовало бы указать, что в клауд гейминге используется исключительно WebRTC, и описать захват кадров из X11 доступными способами для передачи в любой поток.
Хотелось бы услышать мнение специалиста. Но насколько я знаю в аналоговых схемах с несколькими источниками питания, контур не обязан замыкаться на одном генераторе-источнике, контур образуется и между разными генераторами
Хотя если есть несколько электростанций и все они заземлены у вас во дворе, то получается что значение будет иметь и напряжение на каждой станции, выбрана будет та, у которой наибольшая разность потенциалов с вашей фазой
Хороший вопрос! Специалист больше расскажет здесь, но я предполагаю что на тот, к которому меньше сопротивление, т.е. физически ближайший заземленный провод ЛЭП.
Мы говорим про контур, а не про физическое местоположение электронов. Контур начинается и заканчивается на электростанции, ни в какую землю ток уходить не может, а возвращается через ближайшее заземление обратно на генератор.
Просто что ток течет от + к - и все. Про землю уже после того, как ученик четко осознает, что ЛЭП заземлены через каждые N метров и ток через "землю" утекает обратно на электростанцию (а не просто "в землю").
Кто вообще придумал детям в школе рассказывать про "ток уходит в землю"? Мне эта формулировка испортила все восприятие процесса, я реально думал, что земля сама по себе способна магически вытягивать ток.
Про локальный запуск не совсем понял вопрос - в контексте разработке нужен отладчик, с голым docker-compose из run.sh отлаживать из VSCode не получится (наверно как-то можно через ssh, но это и будет эмуляция devcontainer). Конечно, в проекте обычно есть Makefile с build-docker, run-docker, test и т.п., но внутри devcontainer все это становится не нужно. Когда-то заморачивался с гибридными Makefile-ами, которые по разному выполняются в зависимости откуда запущен make. Ворох скриптов сокращается, но главное, что единожды все настроив и закоммитив в репо, другой разработчик с VScode и devcontainer, склонировав проект, поднимет все в два клика и сможет сразу приступить к работе.
Пришел к такому выводу относительно написания юнит тестов - CPU-bound методы обычно идеально подходят под юнит тесты. Пример: хмл парсер с кучей corner-cases внутри. Генерим разные xml на входе, проверяем правильность объектов на выходе. Любые функции, которые хитро что-то высчитывают, регулярки там всякие. Такого кода обычно очень мало в большом проекте. Писать такие тесты даже где-то приятно.
IO-bound ETL функции - аля "прочитай из базы - передай дальше в другой микросервис" (99% функционала в больших e-com компаниях) превращаются в бесполезные "the code I wrote is the code I wrote" проверки, которые просто дублируют всю логику. Такие тесты изматывают и угнетают, я их пишу исключительно для прохождения барьера по покрытию (в больших компаниях иначе не задеплоить свой код).
Кстати, с появлением AI помощников появилась надежда, что наконец-то написание этих ваших тестов для IO ETL методов можно спихнуть на AI бота. Но пока чето не очень, именно такие тривиальные, казалось бы, методы chatgpt почему-то очень плохо пока умеет и получается корявенько.
&Dog::name;
У вас потерялся static?
Почему-то вспомнился миф про "640k ought to be enough for anybody"..
Обожаю когда выбирают модную технологию (с непонятными подчеркиваниями в простейшем коде), тратят кучу времени на отключение основных фич типа GC, и в итоге счастливы, что избавились от С++
Как именно выбирается "самый быстрый" клиент для соединения? Например, если в графе сотни клиентов, и появляется новый клиент К, как ему подключиться к самому близкому для него (по rtt) клиенту в этом графе?
Не соответствуют ли полученные графики характеристикам конденсаторов, установленных в цепочках питания памяти?
С rust-ом возникает другая проблема - большую часть времени тратишь на изучение "правильного обхода" ограничений, которые понатыканы буквально везде (а обходить их придется, если писать что-то более сложное чем hello world)
Для справки следовало бы указать, что в клауд гейминге используется исключительно WebRTC, и описать захват кадров из X11 доступными способами для передачи в любой поток.
Так куда все-таки уходит ток через заземление?
Может ли возникнуть замкнутый контур между разными генераторами тока?
Хотелось бы услышать мнение специалиста. Но насколько я знаю в аналоговых схемах с несколькими источниками питания, контур не обязан замыкаться на одном генераторе-источнике, контур образуется и между разными генераторами
Хотя если есть несколько электростанций и все они заземлены у вас во дворе, то получается что значение будет иметь и напряжение на каждой станции, выбрана будет та, у которой наибольшая разность потенциалов с вашей фазой
Хороший вопрос! Специалист больше расскажет здесь, но я предполагаю что на тот, к которому меньше сопротивление, т.е. физически ближайший заземленный провод ЛЭП.
Ну если передатчик вне пределов планеты не "заземлен" то и ток не потечет через "землю", заземлять принимающий контур бессмысленно в такой схеме
Мы говорим про контур, а не про физическое местоположение электронов. Контур начинается и заканчивается на электростанции, ни в какую землю ток уходить не может, а возвращается через ближайшее заземление обратно на генератор.
А куда они по вашему денутся?
Да нет же, земля просто играет роль проводника, а разность потенциалов возникает на источнике где-то на электростанции.
Просто что ток течет от + к - и все. Про землю уже после того, как ученик четко осознает, что ЛЭП заземлены через каждые N метров и ток через "землю" утекает обратно на электростанцию (а не просто "в землю").
Кто вообще придумал детям в школе рассказывать про "ток уходит в землю"? Мне эта формулировка испортила все восприятие процесса, я реально думал, что земля сама по себе способна магически вытягивать ток.
Про локальный запуск не совсем понял вопрос - в контексте разработке нужен отладчик, с голым docker-compose из run.sh отлаживать из VSCode не получится (наверно как-то можно через ssh, но это и будет эмуляция devcontainer). Конечно, в проекте обычно есть Makefile с build-docker, run-docker, test и т.п., но внутри devcontainer все это становится не нужно. Когда-то заморачивался с гибридными Makefile-ами, которые по разному выполняются в зависимости откуда запущен make.
Ворох скриптов сокращается, но главное, что единожды все настроив и закоммитив в репо, другой разработчик с VScode и devcontainer, склонировав проект, поднимет все в два клика и сможет сразу приступить к работе.