Freeman

Методом подбора и внимательного исследования стаковерфлоу, получилось что-то вроде такого:

1. Нужно в миграцию добавить

   django.contrib.postgres.operations.TrigramExtension()

   
   
2. Нужно для каждого поля создать индекс (на примере name)

   django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(Upper('name'), name='gin_trgm_ops')))

   
   

Это капец как неочевидно, но для поиска по icontains работает именно так. Сорян, что потревожил сообщество.

Существуют стандартные файловые форматы для хранения ЭЦП ключей. Для RSA, PGP и прочее.
Это текстовые файлы оформленные соотв образом и хранящие внутри себя закодированный
в Base64 ключ. Это то что касается публичной части криптографии там где важно оповестить
как можно больше респонентов и где нужна открытость. Я также видел аналогичные XML-форматы
в эпоху SOAP. Но они как-то не особо популярны. Они скорее часть SOAP чем криптографии.

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

Что еще. Для этой-же симметрички может быть полезен padding. Это специальное оформление
последнего блока шифро-текста. Чтоб подбить вариативный размер файла под размер кратный
блоку. Например если вы решили шифровать через AES-256 то вам нужен блок в 256 бит
и алгоритм паддинга для хвостового блока. Padding известен и его методы описаны в wiki.
Берите перебирайте. Который совпадет - тот и ваш. Вот. Паддинг - это не файловый формат
а просто инженерный трюк чтоб уйти от блоков или прийти к блокам.

Все зависит от планируемых размеров (пределы) базы данных, т.е. количества данных, которые необходимо индексировать. Если нужно считанные десятки тысяч сайтов отслеживать, хватит абсолютно любой sql базы данных, миллионы страниц и fulltext индексы хоть postgres хоть mysql хоть самописные на файлах (пока индексы влезают в оперативную память).

Проблемы начинаются когда индексы не влезают в оперативную память, когда база данных расползается по кластеру или когда скоростей интернет провайдера уже не хватает для прохода обновления базы поисковой системы и данные в поиске становятся неактуальными. Начиная с какого то (большого) объема данных, простого поиска по ключевым словам уже будет недостаточно. А чего стоят алгоритмы ранжирования (сортировки результата), ведь на любой запрос у тебя будет больше чем десяток страниц результатов. Потом борьба с сеошниками, фейковыми зонами интернета (когда сайты генерируют терабайты мусорных данных, и узнаешь ты про них когда место на диске кончится или процент их содержания в индексе превысит половину), интеллектуальная интерпретация данных (с этого в принципе нужно начинать, когда страница должна восприниматься не как просто текстовый документ, а набор информационных зон, их важность (реклама, навигация или статья), разделение (несколько статей на странице), проблема динамического интернета (благодаря 15-летним инструкциям люди до сих пор делают сайты в виде ленты с постраничной навигацией с конца, когда 10-ая страница уже завтра будет показывать не те статьи что были вчера) и вообще javascript в частности и тьма тьмущая других проблем.

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

yt-dlp -f xxx https://yyy --get-url
полученную ссылку читаешь только заголовки
curl -L -I http://zzzz | grep Last-Modified:
там будет несколько редиректов, дата последнего скорее всего искомая

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0 3545k    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Last-Modified: Wed, 02 May 2007 10:26:10 GMT
Last-Modified: Wed, 02 May 2007 10:26:10 GMT
Last-Modified: Wed, 02 May 2007 10:26:10 GMT
Last-Modified: Fri, 03 Feb 2023 04:08:16 GMT

как минимум для разных форматов она разная

FAR manager или, на худой конец, Total Commander.
В обоих есть функция сравнения папок.
Процесс выглядит примерно так:
1. выбираете на левой панели одну папку, на правой панели другую папку, запускаете сравнение;
2. если обнаружены отличия, то заходите внутрь отличающихся папок слева и справа и повторяете сравнение и т.д., пока не увидите конкретные отличающиеся файлы или с одной стороны файл, а с другой стороны его отсутствие;
3. после всех ручных синхронизаций делаете контрольное сравнение.

Ещё можно использовать утилиты для автоматической синхронизации указанных папок - RSync, Robocopy, SyncThing и т.п. Но не предложил именно их в первую очередь из уважения к паранойе на тему утраты файлов (а то при неправильной настройке можно и не в ту сторону синхронизировать). Если вручную синхронизировать спокойнее, то FAR или TC, а когда вручную надоест, тогда уж можно автоматизировать.

Как создать свой язык программирования?

Точно так же, как и любую другую программу: сначала спроектировать, а потом реализовать.

Без другого языка программирования! Полностью с нуля.

В самом низу находится машинный код. Выглядит примерно вот так:
08 04 83 fa 08 04 83 fb 08 04 83 fd 08 04 84 00
У каждого процессора есть свой набор инструкций, которые кодируются машинным кодом. Открываем справочник и пишем нужный код для нужной ОС/железа. Ничего сложного, правда же? =)

Ведь как-то создали первый ЯП.

Достаточно почитать историю появления первых ЭВМ. Они представляли из себя набор переключателей отдельных битов, которые позже эволюционировали в перфокарты, которые в свою очередь представляли из себя прообраз современных исполняемых файлов. С увеличением количества доступных команд, усложнением техники и появлением накопителей программы так же становились все сложнее и сложнее: поэтому решили упростить запись и придумали первый ассемблер. Дальнейшее развитие привело к появлению первого ЯП высокого уровня и далее более высокие уровни абстракции, используя которые сегодня пишутся все программы.

Так что в вашем случае вам надо пройти весь этот путь самостоятельно. Примерно так:

1. На машинном коде реализовать минимальный ассемблер
   
2. Используя свой минимальный ассемблер реализовать простейший компилятор этого ассемблера
   
3. Расширить компилятор ассемблера до стандартного набора инструкций
   
4. На ассемблере реализовать транслятор и компилятор ЯП высокого уровня
   
5. Реализовать необходимый набор инструкций для написания компилятора этого же ЯП
   
6. Написать этот самый компилятор своего ЯП на нём же и далее уже скомпилировать первую самостоятельную версию своего ЯП без использования других ЯП
   

В том же, в каком и в 2022-м.

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

На английском есть специализированный сайт codereview@stackexchange, при наличии языка это идеальный вариант.

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

Самый надёжный способ получить code-review, это завести два аккаунта. С одного задать вопрос, "как сделать то-то", а с другого - запостить код, который это делает. И тут же набегут советчики, рассказать, что в этом коде неправильно.