mayton2019

Можно попробовать на Prolog написать. Правила (rules) известны. А в качестве утверждений - просто
проверить что существуют ли целые числа которые удовлетворяют всем rules.

Слабый нынче геймдевелопер пошел. Пипка - это такой себе менеджер пакетов для питона. Как чоколядка для Виндовс.

Вот тут можно скачать https://www.python.org/downloads/ или тут https://pip.pypa.io/en/stable/installation/

Но вангую что на этом твои приключения только начнуться.

Ты его и для admin неоптимально сделал. Зачем 7 раз переписывать каждый документ. Вот будет у тебя база в 100 Гб - значит перепишешь почти терабайт.

Сделай

UPDATE wp_posts SET post_content = REPLACE(REPLACE(.... (post_content, '<pre><code>', '</code></pre>', '').......))))

сайт падает, в логах ничего

Так не бывает. Если OOM киллер срубает процесс то где-то об этом остается след.
Поищи в syslog, в сообщениях D-bus, в логах Апача, в логах Редиски или ПХП.

Ох инженеры пошли совсем никудышние.

Заходи в cmd. И делай

c:
cd \
cd Users
cd "Пользователь"
cd "PycharmProjects"
cd "pythonProject1"

Вот на каком-то фолдере ты увидишь несоотвествие.

Импортируй первую базу во вторую. А потом вторую в первую.

Ну любой API который работает с metadata из курсора - всегда выдаст тебе колонки именно в том порядке
как и выдает фактический запрос. Для JDBC там была своя процедура https://www.baeldung.com/jdbc-database-metadata

Да и даже еслиб ты не знал про метадату - можно просто выбрать запрос который выдает 1 строку и взать из него типы полей тоже через какой- то API (JDBC/ODBC).

Тут читается не техническая а организационная проблема.

Не очень понятно но попробую дать совет.

Вот ты говоришь что требуется в 10 конфигах сделать изменения.
Какие? Они - взаимосвязаны? - Это должен быть 1 коммит в git.
Эти все изменения должны быть просмотрены глазами хотя-бы несколькими людьми.
Если цена изменения дорого стоит (инфраструктура) то по любому должна
быть бригада девопсов. Они - страхуют друг друга от случайной ошибки.
Если ты будешь брать на себя падения датацентров - то очень скоро
станешь пациентом кардиолога. Бери коллег для подстраховки.

Константы и зависимости - надо объявлять отдельно. Чтоб если меняется hostname
или имя свойства - то это должно быть ровно одно изменение. Как поддержать
константы в конфигах - я щас не помню но была куча всяких штук... толи Puppet
толи Ansible вобщем поищи сам. Я думаю таких много конфигураторов.

Когда несколько environments то на проекте создается просто несколько фолдеров типа

/dev
/qa
/uat

и в каждом фолдере лежит полностью сконфигурированная и оттестированная
копия всех конфигов. Переключение между env тоже должны происходит
изменением ровно 1 свойства.

Если внутри конфигов есть некая базовая конфигурация которая очень похожа
(прототип) то сделайте аналог COC (Convention Over Configuration). Пускай
прототип будет всегда. А наследники dev, qa, uat будут просто изменять
дельту. Пароль поменялся - в конфиге-наследнике - лежит ровно 1 строчка с паролем.
Других строк - не надо. Потому что они наследуются от прототипа.

Как технически реализовать COC - я не скажу. Это надо обсуждать. Я это делал
на Java проектах но это как-бы идея "на подумать". На проектах у меня были
*.properis файлы и эту конвенцию было реализовать несложно. С ЯМЛ ами я не делал.
Ну думаю что это возможно. Почему нет?

Интересно. Вот тут пишут про похожий инцедент https://stackoverflow.com/questions/24019868/utf8-...

Ну если открыть описание API то там достаточно четко описано.

Object
 +- Writer (Abstract class for writing to character streams.)
     +- OutputStreamWriter (An OutputStreamWriter is a bridge 
          |                 from character streams to byte streams)
          +- FileWriter (Writes text to character files using a default buffer size.)

Последний - буферизированный.

Докер здесь непричем. Это проблема вашего прикладного софта. Софт видит любые папки через volumes.
Да-да и изменения тоже видит. Тестируйте этот пункт. Все должно работать как и слокальным диском.

В тексте вопроса написано много чепухи. Java может использовать внешнюю память. Кажется еще
в Java 8 для Apache Ignite (и других NoSQL систем) были попытки использовать неуправлямую
память через ByteBuffer. История где-то об этом сохранилась я думаю.

Начиная с JDK-14 (могу ошибаться) завезли Foreign Memory API который оперирует с памятью
более продвинуто.

По поводу

в Java не надо следить за памятью

- неправда. Следить за памятью надо всегда. Иногда это делает разработчик (для С/C++)
а иногда это делает GC или умные механизмы borrow-checker (Rust).
Если не следить то долго работающие процессы пожирают всю память ОС
до тех пор пока не будут убиты через ОС OOM killer. Возможно под слежением
имелись в виду накладные расходы на работу GC? Но эта проблема специфична
только для приложений которые активно делают new и переживают хотя-бы одну
эпоху. Кроме того в Java есть несколько разных GC которые просто обнуляют
все тезисы например 2000х годов и обсуждать их надо уже совсем как другие
алгоритмы которые имеют другие свойства. Грубо говоря знания по GC очень
сильно устарели после G1, Shennandoh e.t.c. Нужно учить заново всё.

прикладной код Java - заменить на “прикладной код движка Java”

Это вообще невозможно прокомментировать т.к. идет жонглирование терминами без
определений. Что такое движок в данном случае - непонятно?

В любом случае тебе надо звать в студию этого загадочного Романа и не плодить свои домыслы.

Нет необходимости отслеживать состояние сразу всех 2х миллионов. В старых 2д играх слешерах 90х например уровни тоже были очень богатые на количество enemies но их не нужно было обрабатывать и хранить всех сразу. По сути игрок видел view-port размером с экран и игровому движку нужно было активировать рождение объектов-персонажей почти у границы экрана. Когда персонаж покидал экран - его можно было либо удалить либо поставить на паузу. Этим пользовались почти все движки и экономили ресурсы.

Если речь идет допустим о клеточных автоматах - то там тоже есть свои оптимизации. Можно расчитывать эпохи параллельно используя опции параллелизма железа например. Или объединять близко стоящие кластеры клеток и обабатывать отдельно чтобы предотвратить расчет всего экрана. Тут нет предела совершенству. Можно брать такие индексы как Q-Tree/R-Tree для быстрого трекинга этих областей.

В некоторых играх типа Age Of Empires или Cossacks можно было рассматривать в качестве единицы расчета не каждого пехотинца или всадника а целые фаланги. Этим пользовались особенно когда боевые
единицы ходили в построении.

Вобщем игровые движки - это не симуляторы физики. Это - скорее очень хитрая иллюзия. И талант геймразработчика как раз и состоит в том чтобы игроку казалось что он видит миллион объектов а с точки
зрения игрового алгоритма - это будет просто один прямоугольник из целых чисел или каких-то других
объектов.

Для сетевого оборудования был режим транка когда несколько сетевух объединялись в одно логическое устройство и пакеты раздавались по принципу четный-нечетный например. Но это очень low-level и очень жестко ограничивало и характеристики канала и сами железки. Я не конфигурил это никогда но знакомые сетевики делали.

Идея объединять Wifi с проводным соединением мне непонятна. Что сделать со ошибками? Мы имеем по теории надежности более слабую схему где сильно зависит все от качества эфира например. Эфир вокруг Wifi всегда шумит ошибками и скорость плавает. Тоесть мы надежное кабельное устройство объединяем с крайне ненадежным. Что это будет? В какой части стека это можно вставить? IP? Кадры? Прикладной уровень?
Как их чередовать?

Я вспомниаю протокол SCTP. Он вроде бы создавался для таких двух-интерфейсных соединений.
Но как он работает?
Кто когда-то его использовал? Поделитесь информацией.

Тут нужно копнуть в историю и почитать для чего JavaScript созадавался. Какие цели и задачи перед ним ставились. Почитайте это интересно. И в части Lisp в браузерах - тоже.

Что такое вообще ООП применительно к теории и к конкретному языку? На сегодняшний день не существует канонической реализации ООП. Грубо говоря ни один язык не может претендовать на трушное ООП. Хотя другие ООП (класса строго типизированных) просто вводят больше ограничений на компилляцию
и рантайм запрещая на ходу менять тип объекта или внедрять в него новые методы и перегружать существующие.

JavaScript является таким себе податливым пластилином который разрешает очень многое делать
с объектами и именно это является объектом критики. Прототипирование вместо наследования и прочее.
JavaScript насколько я знаю расширяет спецификацию и все таки вводит понятие класса. Ключевое
слово есть. Это хорошо. Это его приближает к ООП и дает возможность больше проводить параллели с back-end например.

Есть языковые надстройки (транспилляторы) типа type-script которые вводят некий повышенный уровень
строгости по отношению к типам. Но Runtime насколько я понимаю по прежнему остается либеральным.

Вообще тема чистоты ООП - это достаточно трольная тема особенно на собеседованиях. Теоретики до сих
пор не могут посчитать сколько же свойств нужно для описания ООП. Там вроде как 3 свойства было или 4.
До сих пор нед единого трактования термина инкапсуляция.

Поэтому всех религоизных фанатиков ООП надо слать к чорту. А на собеседовании отвечать очень обтекаемо
и с отсылкой на всяких Кентов Беков и Фаулеров и Дядек Бобов. Пускай они там друг с другом договоряться
о терминологии а потом уж мы подтянемся.

Задача имеет мало практического смысла. WSL создавался для Windows пользователей чтоб дать им хоть какую-то возможность тестировать и использовать Linux софт без особой нагрузки.

И WSL работает на стеке docker, а hyper-v это насколько я понимаю полноценная виртуальная машина. Стеки технологий достаточно разные? Или я ошибаюсь?

И что такого ценного в этом образе что его нельзя перенести в контейнеризацию?

Как лучше реализовать логику получения данных. Получить все данные за один запрос, хранить их и на основе выбора пользователя, фильтровать и выводить нужные ему данные.

Делай как тебе проще код писать. Наперед ни один архитектор не знает как лучше. Улучшение - это процесс итеративный. Но сначала тебе нужно поймать какой-то инцедент. Например performance issue. И уже начиная от этого улучшать.

Пока у тебя такого инцедента нет - делай максимально простой код и это будет правильное решение.

Я-бы попросил переделать текст договора. На момент подписания мне должны быть ясны все реквизиты. Фамилии, условия, сумма и вдруг вы подкладываете какой-то непонятный хеш. Мы же не про хеши договаривались.

Далее. Ты говоришь - в "случае чего" - доказать. Доказательство скорее всего будет происходить в суде. Суд призовет эксперта. А он будет рассматривать не какие-то хеши а как раз именно ваши чертежи и модели и прочее. Так как именно это будет звучать в главном вопросе.