Шаблонизатор есть, но его удобство оставляет желать лучшего. И внимание, спойлер. Статья в хабе «Кодобред». Именно так как я написал в статье, делать не надо ни в коем случае.
У меня есть подозрение, что таких «базовых знаний» нет у подовляющего большинства веб программистов. И при этом формально, «программирование» — основная сфера профессиональной деятельности.
Проблема с ЦНС не затронула умственную деятельность. Не все проблемы с ЦНС ведут к деградации умственных способностей, не говоря уже о том, что к ЦНС относится в том числе и спиной мозг и т.д.
Чтобы придумать теорию, нужно обладать незаурядными способностями, чтобы понять — нет.
Когда-то про теорию относительности говорили, что её понимают во всем мире два человека. К сожалению, всегда есть предел возможностей мышления как минимум в пределах одного индивида.
Сервис не тестируется из другого сервиса. Сервис тестируется из другого кода. В простейшем случае это могут быть bash скрипты с curl запросами внутри. И такая практика реально существует, примеры проектов\репозиториев сейчас с ходу не приведу.
В данном примере есть микросервис написанный на go, и автоматизированные тесты написанные на ruby. Сбоку добавлен mockserver, как альтернатива встроенным в языки мокам\стабам, т.к. в данном случае WebMock и иже с ним работать не будут.
WebMock работает только на уровни Ruby, MockServer запускается независимо. При этом если не хочется тянуть java можно найти аналоги.
Код тестов больше проверяемого кода — типичная картина, когда соотношение строк тестов к коду достигает 3:1. А в данном случае значительный объём кода теста занимает работа с MockServer, что легко выносится в отдельные файлы хелперы.
Выгода — при переписывание условного микросервиса с языка X на язык Y, код тестов и тестовый набор данных не теряется.
А как же отключить исполнение веб сервером uploaded файлов? Проверка расширений не имеет смысла, никто не мешает загрузить на сервер php скрипт с расширением jpg. А если стоит запрет на выполнение, то пусть хоть бинарник льют под видом картинки, место отъест да и только.
Без комбинирования, но с взаимодействием магии с окружением очень круто сделали в Dark Messian. Можно огненной магией поджигать многие вещи или даже стрелы, кидать заморозку под ноги врагу на которой он подскользнется (полный аналог магии subzero из МК), молнии сильнее бьют противников стоящих в воде и т.д.
Похожая система крафтинга предметов существует в игре Thea: The Awakening. Любые предметы разбираются на составные материалы. Есть всего несколько «рецептов» для брони и оружия. Для мечей например это только одноручный и двуручный вариант (примерно столько же для брони, луков, топоров и т.д.). Но каждый предмет состоит из первичного и вторичного материала. И комбинация этих компонентов даёт уникальный предмет. Можно например создать чисто мифриловый меч, или добавить как вторичный компонент кости дракона и получить чуть меньший показатель урона, но добавится высасывание жизни при атаке. Тоже самое касается брони, можно создать стальную кольчугу или легкую меховую шубу.
Может мои воспоминания уже достаточно спутанные, но в детском возрасте читал книжки данного автора (Норбекова) как научную фантастику, особенно запомнились «монахи», которые аки джедаи общаются телепатией и силой мысли поднимают огромные булыжники ради тренировок.
Не вижу причин, почему данные в логи должны сохранятся, разве что открывать на запись новый файл на начале каждой итерации, и закрывать в конце. Тогда будет 100% гарантия, и очень неудобная система записи.
У ОС есть механизмы гарантированной записи в файл, в правильной реализации логирования вы ничего не теряете. Для повышения производительности обычно используется файловый буфер на уровне ОС и именно он может потеряться при неожиданном завершении процесса. Но если вы вручную инициируете сброс буфера на диск, то почти гарантированно ничего не потеряете.
Случайно залезть в память системы можно как из Си так и из Delphi, но это скорее верно только для старых версий Windows. Разницы в этом моменте между Delphi и Cи нет.
Возможно вы простое не умеете готовить TCP/IP. Не являюсь специалистом, но некоторые утверждения касательно TCP вызывают сильные сомнения, например «шифрование» и «двойное подтверждение».
Что бы при падении клиента рвалось соединение, необходимо вручную отслеживать таймауты и сетевую активность, в ином случае сервер и клиент никогда не узнают, что соединение развалилось.
И небольшая демонстрация механизма pipes, ipc, и замена достаточно неудобного go шаблонизатора на более удобный
Когда-то про теорию относительности говорили, что её понимают во всем мире два человека. К сожалению, всегда есть предел возможностей мышления как минимум в пределах одного индивида.
В данном примере есть микросервис написанный на go, и автоматизированные тесты написанные на ruby. Сбоку добавлен mockserver, как альтернатива встроенным в языки мокам\стабам, т.к. в данном случае WebMock и иже с ним работать не будут.
Код тестов больше проверяемого кода — типичная картина, когда соотношение строк тестов к коду достигает 3:1. А в данном случае значительный объём кода теста занимает работа с MockServer, что легко выносится в отдельные файлы хелперы.
Выгода — при переписывание условного микросервиса с языка X на язык Y, код тестов и тестовый набор данных не теряется.
У ОС есть механизмы гарантированной записи в файл, в правильной реализации логирования вы ничего не теряете. Для повышения производительности обычно используется файловый буфер на уровне ОС и именно он может потеряться при неожиданном завершении процесса. Но если вы вручную инициируете сброс буфера на диск, то почти гарантированно ничего не потеряете.
Случайно залезть в память системы можно как из Си так и из Delphi, но это скорее верно только для старых версий Windows. Разницы в этом моменте между Delphi и Cи нет.
Что бы при падении клиента рвалось соединение, необходимо вручную отслеживать таймауты и сетевую активность, в ином случае сервер и клиент никогда не узнают, что соединение развалилось.