mayton2019

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

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

Вот ты говоришь что требуется в 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. И уже начиная от этого улучшать.

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

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

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

Да можно. Это называется фасадом. Ограничение в single responsibility обычно относится к ООП и к классам.

Вообще если ты фрилансер и делаешь просто заказ чтоб отдать его с концами - то тебе безразлично что будет внутри. Главное чтоб ты понимал. А соглашения по декомпозиции кода на части появляются только как результат
коллективной работы над кодом. Тоесть ты должен спрашивать не qna, а свою команду как вам удобнее
разрабатывать код.

В унарном виде - это как цепочка единичек. Например число 5 будет.

_11111_

Справа и слева должен стоять blank sysmbol. Типа признак конца ленты чтоб было что проверять.

Тогда (5 mod 2) = 1

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

_1_

Это можно сделать поглощая пары соседних единичек. А для четного числа будет пустая лента. Тоесть остаток от деления равен нулю.

Ну вот такой алгоритм. Дальше надо делать конечный автомат который ищет пары единичек.

1) Вот тут иногда можно найти удаленные книжки

https://web.archive.org/

2) Если был известен MD4 или magnet link (hashcode) или еще какие-то хеши то тоже можно скачать.

Задача похожа на knapsack problem. Ее можно переформулировать как укладка вещей в рюкзаке с полным заполнением и с сохранением порядка вещей. Или еще как поиск всех сумм целых чисел 1,2,3 равных в сумме n.

Если представить тернарное дерево где childs - это соотвественно длины прыжков (веса) - тогда задача сводится к генерации всех возможных путей в тернарном дереве где длина пути равна n. У этого дерева будет много лишних ветвей которые можно сразу отбросить на этапе обхода если частичная сумма уже больше чем n.

Вобщем DFS.

предполагается нагрузка на сервис где-то рпс 70-100к

c
Это не большая нагрузка. Oracle лет 20 назад заявлял 500K транзакций в секунду по результатам бенчмарков.

Данную задачу также можно решать со стороны CQRS / Event Sourcing. Тоесть посто фиксировать события гео-позиции в журналы (они могут быть распределенные) а потом уже накатывать в БД. Здесь я предполагаю что вам не требуется реал-тайм. (За 10 секунд вашего технического лага человек все равно успеет убежать за горизонт) и накинтье еще от 1 секунды до допустим 30 секунд время на фиксацию в основной БД. И получается система вполне себе почти реального времени. И в то-же время вам будет лего выдержать всплески информации и ничего не потерять.

Ну... есть люди с разными особеностями зрения. Некоторые видят буквы. А некоторые даже печатный ровный шрифт не читают. Дислексия или что-то в этом роде.

Скорее всего у тебя просто особенность зрения или восприятия такая.

Для меня эта капча тоже тяжело читается. Но предпослений символ - скорее всего цифра 8.

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

Для выскоконагруженных интернет магазинов нет прямого доступа к категориям в БД.
Они (категории) кешируются на стороне приложения и NGinx.

Категории меняются редко. Ну вряд-ли в течение дня. Скорее всего на следующий день.
Поэтому форма хранения их в таблице должна выбираться из удобства внесения изменений.
Вот попробуйте Adjacency List. Самый первый и самый очевидный вариант.

И не надо быть перфекционистом и ковырять грязь из под ногтей. Просто потеряте кучу времени.