Станислав Макаров

ICANN периодически проводит рассмотрение заявок на регистрацию доменов верхнего уровня. Стоимость такого домена порядка $200000 плюс отчисления от продаж поддоменов. Кроме этого вы должны создать и поддерживать инфраструктуру для обслуживания домена.

Напиши на Хабр годную статью и прилепи опрос в конце

EntityReturn - более общий тип относительно Entity, поэтому в EntityReturn можно передавать объекты Entity.

Ошибку про лишнее поле будет показывать, если ты передаешь в EntityReturn литерал с лишними полями:

const entitie: EntityReturn = {
    id: "1",
    filename: ""
};

Переменные надо инициализировать. Без инициализации в них лежит мусор.

Лучшие практики, это что наружу смотрит API которое и обрабатывает поступающие запросы. Никто в здравом уме не выставляет базу на мороз.

Рекурсия нужна при обработке иерархических данных. Например - обойти файлы и каталоги
в файловой системе и выполнить какое-то действие. Или действие с условием. Например если
в текущем фолдере есть фолдер .git - то выполнить какой-то git script.

Рекурсия может понадобиться при работе с документами XML/JSon (шаблон composer). И хотя
в некоторых API рекурсия может быть частично скрыта за языками XPath/JSonPath тем не меннее
ее рекурсивная природа остается налицо. Кроме того если вам достался узкий API типа DomDocument
без поисковых диалектов - то обойти его можно на любом ЯП с рекурсивной функцией.

Рекурсия нужна при парсинге сайтов. Это вобщем просто более расширенная трактовка работы с файловой
системой. Если Url-s это как-бы файлы в web пространстве и они имеют ссылки друг на друга - то вы
можете рекурсией это все обходить.

Рекурсия почти всегда нужна при работе с графами. Берите любой алгорим на теорию графов и я готов
спорить что 99% он будет содержать рекурсию.

Все настольные игры (шахматы-шашки) в основе своего алгоритма альфа-бета поиска с отсечениями и
BWF базируются на рекурсии.

Сам запрос:

Узнайте про PostGIS

Как вообще тестируют нагрузку на БД?

Устраивают DDOS атаку

Не нужно пизать в БД лишнюю логику и лишние ограничения.
У вас с БД работает какой-то софт, например бэкенд. Там и делайте валидаторы данных. В случае пола раньше можно было 1 и 0 удобно хранить и всё было абсолютно интуитивно и понятно, а русскую букву в качестве индекса держать неудобно и неправильно. Во-первых, она в UTF-8, наверняка, что уже как-то изврат для бинарного поля.
Во-вторых, при локализации проблемы могут быть в логах надо юникодовую экранировку читать, если что... в общем либо международное F\M, либо кодами и 1\0 для мнемонического запоминания очень удобно. Вот угадайте что есть что и почему.=)

Но по нынешним временам за такую бинарность могут и засудить=) Не иначе нужна целая таблица гендеров небинарных с названиями, описаниями и локализацией. Да ещё и меняться она будет со временем, а потом при импортах мапить надо одну таблицу полов на другую=).
Шутки шутками, а 0\1 и тут хорошо лягут. Просто идентификаторы такие будут синтетические.

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

Ответ: на надо валидировать значения такого рода полей на уровне БД. Делайте так, чтобы нельзя было ввести неверно на уровне ввода данных от пользователя, и дополнительно валидируйте в бэкенде.

С изучения информатики и устройства вычислительной техники. Ну а далее уже можно выбирать что-то из современных ЯП: https://roadmap.sh/computer-science
В целом же, написание кода - лишь одна из частей процесса разработки ПО. Так же рекомендую поставить какую-нибудь игру с редактором карт и освоить его. Например классику: WarCraft 3, StarCraft, HoMM 3.5/4 - легендарные игры, популярность которых обусловлена именно игровыми редакторами и которые смогли пройти сквозь целые эпохи. Возможность самому что-то сделать и поиграть - очень неплохо мотивирует к освоению редакторов и желанию разобраться как оно все работает )

Лао-цзы: «путь в тысячу ли начинается с первого шага»
Брюс Ли: "Я не боюсь того, кто изучает 10,000 различных ударов. Я боюсь того, кто изучает один удар 10,000 раз"
Повторение результата из раза в раз с сохранением того же качества это удел профессионалов. Поэтому много мелких однотипных проектов это даже хорошо, с минимальными усилиями вы нарабатываете будущую клиентскую базу людей которым вы помогаете сейчас и которые будут знать к кому обратиться в будущем. Через 10 лет ваши друзья разбегутся кто куда, станут семейными и откроют бизнес, а в нашей стране очень ценят работу "специалиста по знакомству", но помните любая работа должна быть оплачена и не стоит делать её бесплатно или со скидкой просто потому что знакомые, людей которые захотят вас использовать будет много. Просто примите это как правило.
И еще, все великие начинали с того что брали за основу чьи то наработки и использовали их в своей работе. Поэтому не бойтесь использовать сторонние инструменты, я не говорю вам воровать, но на первых этапах направления которое вы выберете использовать чужое - ок.
Деньги, второстепенное оно приходит с опытом само, не стоит сильно акцентировать внимание на том чтобы заработать миллионы, поверьте это не то что вы хотите на самом деле.
Пока вы молодой, ищите себя в разных направлениях, не бойтесь рисковать и менять работу чтобы к 30 годам уже точно определиться с направлением которое вам близко к душе а не потому что "там больше платят".

И вот еще видео для мотивации.
https://youtu.be/w0Mc2CFxFyE

В силу некоторых обстоятельств не могу идти работать full-time

Тогда никак. Серьëзная разработка = командная разработка. Да и рост без команды очень медленный и ограниченный.

Так устроен индекс. Он строится в первую очередь по первым символам и в последнюю по последним.
Если вы подменяете % начало, то индекс просто не будет работать.
Разделите ФИО на отдельные компоненты и сделайте отдельный индекс для имени, тогжа ваш кейс будет быстрее работать.
У вас же фактически происходит полный перебор базы без индекса.

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

Rust достаточно стабильный и популярный, чтобы начать с ним работать.
По геймдеву - в принципе все нужные низкоуровневые библиотеки для работы с графикой там уже есть. Да и движки свои понемногу да появляются.
Пример из тех, что сейчас активно развиваются - bevy, на нём уже можно делать не очень сложные игры, да и просто как образец он тоже интересный: во главе угла стоит модульность и ECS.