mayton2019

Более быстрый вариант

SELECT city.name
FROM city 
WHERE city.name 
       IN (SELECT ad_cars.city FROM ad_cars)

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

Тебе на самом деле выгоднее не делать select а сделать один раз процессинг таблицы
и декодировать поле baza один раз и сохранить его в другое поле.

Это кажется называется enrichment. Обогащение. Хранимой процедурой можно.

Да можно. Если речь идет например о том чтобы в HexEdit открыть сам HexEdit.
Но некоторые ОС в момент исполнения файла могут накладывать на него блокировку
поэтому редактировать его будет нельзя или перемещать тоже будет нельзя.

Симметричный шифр типа AES параметризируется многими настройками. В частности
- длина ключа и длина блока. Например 128, 192, 256
- вектором инициализации. Это что-то вроде виртуального первого блока. IV.
- режимом сцепления блоков (ECB, CFB, CBC ... e.t.c.) в данном случае исходник на Python явным образом нам указывает и режим ECB является вобщем-то самым плохим и нежелательным для нужд криптографии.
(на этот режим а в JS берется какое-то умолчание).
- если мы генерируем ключ на основе парольной фразы то нам должен быть известен этот метод. Это не
всегда преобразование символов в UTF-8. Могут быть нюансы.

Для выравнивания хвоста открытого текста по границе блока есть еще режимы padding-a.
Подозреваю что там - несколько вариантов может быть. Это - тоже надо прояснить.

Поэтому автор должен взять все параметры. Привести их к общему знаменателю и убрать все
defaults на явные параметры чтоб было все одинаково. Тогда и результат дешифрования будет
ожидаемый.

Если удаление произошло на MicroSD карточке то есть шанс восстановить известные форматы
файлов типа JPG, MP3 и прочее. Под ОС Linux есть несколько утилит которые умеют по сигнатурам
находить данные независимо от файловой системы и от статуса файла.

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

Предположительно это может реализовано в AntPathMatcher. Посмотри как там документация
описывает

https://docs.spring.io/spring-framework/docs/curre...

С точки зрения С++ есть команды new/delete которые управляют временем жизни долгоживущих
объектов. Таких как массивы примитивов и более сложные объекты из парадигмы ООП,

А для временных переменных внутри функции выгодно использовать стек. Их аллокация синхронна
с входом в функцию и деаллокация - return. Кроме того стек дает возможность вызвать функцию
из самой себя, таким образом создавая еще один сет таких-же п еременных (это нужно для рекурсии
тоесть для погружения в глубины деревьев и графов и прочих комбинаторных задач).

Если-бы мы эти временные переменные размещали в куче - то у нас возникла бы задача очень строгого
контроля над деаллокацией. Нужно было-б гарантировать что delete сработает за мгновение до return,
а это не всегда удобно в рамках С++ кода. И это может быть причиной сложных и трудноуловимых
ситуаций с memory leak. Это когда программа в состоянии покая как будто бы начинает подъедать память
кучи безо всяких видимых оснований. Это - проблема и с этим борются.

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

Xeon E5 2650 - это процессор серверного сегмента. У него много полезных фичей но для игр
он не годится. Играть на нем - это все равно что ездить на пикник на танке к примеру.

Возможно такое. Серверная JDK поставляется без UI компонентов. Так называемая headless-версия.

Проверить можно следующим тестом.

assertEquals(true, GraphicsEnvironment.isHeadless());

Обязательно ли нужно уметь их писать? Я думал, что Spring будет автоматически создавать их, а от нас будет требоваться создавать контроллеры, модели и т.п.

С точки зрения новых подходов к разработке backend (GraphQL) вообще нет смысла изучать
методы DEL/GET/PUT. Все будет заменяться на POST, который делает всю работу и в нем-же будут
коды ошибок и прочее.

С этой точки зрения сервлет является таким-себе странным рудиментом. Вроде он существует.
Обеспечивает команды HTTP-протокола. Но кому нужны эти все команды - непонятно?

Можете запрограммировать приложение с сервлетом типа превед-мир чтоб понять как оно
будет работать. Но вряд-ли в современном бизнес-программировани или промышленном
программировании от вас кто-то этого потребует.

По игровым технологиям тут нечего добавить. Все выглядит вполне себе норм.

По поводу Mongo. Я-бы предложил ее заменить на что-то другое. Монга хороша для проектов
где изначально не известна схема документа и надо грузить все что есть и как есть.
При этом через некоторое время есть риск получить просто свалку документов где никто
не знает схему данных. Или будет несколько параллельно живущих вариантов схем что
само по себе не лучше.

Если вы точно знаете схему (вы разрабатываете игру и весь игровой мир, инвентарь и локации)
то вы точно знаете что у вас будет где лежать. Вообще для игр лучше брать любую key-value
для которой есть API/ABI. Они все подходят.

Заблочить запись экрана технически невозможно. До тех пор пока пользователь глазами видит
содержание - его все таки можно записать. Продаются устройства для HDMI видеозахвата.
Геймеры часто их используют для записи своих "шедевров" прохождений и прочее.

Проверте что построен индекс по полю time_last_login

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

Поисковой индекс можно также шифровать как и контент.

Современные базы данных поддерживают симметричное шифрование.
Есть технологии для шифрования целых дисков (Veracrypt, Bitlocker).

Автор покажи что у тебя показывает
chcp
или
echo $LANG
И проверь что кодовая страница текстового файла совпадает с ожидаемым.
Вобщем это скорее всего и будет ответ на твой вопрос.

Я думаю что причин две.

Первое - это медленный рост быстрой оперативной памяти для видяшек.
Trident 512k была кажется у меня второй видяшкой. И цифры в конце пишут сколько было
у нее на борту. Вот. И чтобы удвоить разрешение по двум осям - память нужно умножить на 4.
Я думаю что на то время (1997 кажется) это было технически не возможно. Или дорого.

Вторая причина - ЭЛТ мониторы. У них разрашение было низкое. В топике
выше правильно писали - что это были почти телевизоры. И типичный телевизор 90х
(по стандарту Secam) имел заявленное число строк 625 а по горизонтали - там... сложно было точно посчитать.
Аналоговый сигнал ибо. А типичный монитор (у меня Samsung) был с заявленным разрешением в
паспорте 1024х768 пикселов но в этом режиме он как-то натужно работал и мерцал и
я чаще его использовал в 800х600 - там с кадрами было как-то для глаз приятнее.

Тоесть техника того времени не могла себе позволить скачкообразно поднять в 2 раза
разрешение (железная матрица внутри ЭЛТ) и техника не могла учетверить память на видяшках.

Уже в эпоху 4К и 8К мы наблюдаем рост разрешения но при этом оно тоже не удваивается
а просто умножается на коэффициентик. И это правильно потому что домашняя сеть
тоже не может поднять траф 4х чтобы вы смотрели спорт каналы в ультра-ХД или как-там его.

Ты думал что это функция которая исполняется каждый раз?

boolean y = x>=0;

А это просто переменная которая один раз присваивается и больше не меняется.
Вот поэтому цикл - бесконечный и приводит к ошибке индекса символа в строке.