beduin01

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

Вместо использования include для небольших фрагментов HTML, лучше использовать встроенные стили и структуры кода для более легкой читаемости и поддержки. Если вам нужно использовать include для больших блоков кода, таких как шаблоны или компоненты, рассмотрите возможность использования препроцессоров, таких как Handlebars или Jade, которые позволяют вам управлять и структурировать ваш код.

Похоже на то, что hare run не нравятся виндовые концы строк (CR/LF). Можно использовать утилиту dos2unix для приведения концов строк в понятный hare вид (LF).

websocket по умолчанию не работает в режиме запрос-ответ. это именно возможность быстро отправлять события на вторую половину приложения. то есть как правило отправляется название события и его данные payload.
отправка события не всегда предполагает необходимость ответа, как правило отправка клиентом события на сервер порождает события для других клиентов.
rest при желании можно завернуть, но это будет именно rest поверх websocket, а не rest-websocket. то есть отправляете сообщение содержащее метод, endpoint, params, id_request(для того чтобы сопоставить ответ с запросом на клиенет) и тд. в вебсокет а на сервере это все разбирать и роутить.
для нового проекта смысла в этом конечно мало, можно проще сделать, а семантичность тут ни к чему. для старого проекта можно сделать чтобы не переписывать всю бизнес логику проекта, а просто сделать ф-ю которая аналогично fetch/axios делает аналогичные запросы только через websocket.
воспринимайте websocket как систему обмена сообщениями(событиями), а не запрос-ответ.

Главная идея принципа инверсии зависимостей "детали зависят от абстракций, но не абстракции от деталей".
В приведенном вами примере класс Main зависит от всего: от интерфейса INumberOperation и от обоих классов NumberOperation1, NumberOperation2. То есть тут принцип инверсии зависимостей вообще не работает. Никак.

Проявляется же он в следующем примере. Пусть у меня есть некая абстрактная логика "прочитай число, выполни над ним операцию, запиши результат". Эта абстрактная логика (потому она и абстрактная) ничего не должна знать ни откуда она читает число, ни какую операцию над ним выполняет, ни куда и как записывает результат. Таким образом, у нас есть модуль, состоящий из

interface NumberInput {
  int read();
}
interface NumberProcessor {
  int process(int a);
}
interface NumberOutput {
  void write(int a);
}
class Processor {
  private final NumberInput input;  
  private final NumberProcessor processor;
  private final NumberOutput output;

  public Processor(NumberInput input, NumberProcessor processor, NumberOutput output) {
    this.input = input;
    this.processor = processor;
    this.output = output;
  }

  void process() {
    output.write(processor.process(input.read()));
  }
}

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

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

Этот принцип очень хорошо объяснен в книге Р.Мартина "Чистая архитектура", по крайней мере у меня все встало на свои места именно после прочтения этой книги.

SELECT 
	ru_name 
FROM "tokens" 
JOIN regions ON regions.id = any (tokens.regions)
WHERE user_id = 5 ;

PostgreSQL fiddle here

with reg_ids as (
  select unnest(regions) reg_id
  from tokens where user_id = 5
) select regions.*
from reg_ids
join regions on regions.id = reg_id;

One more fiddle

Начнём с того, что Лисп не функциональный. Тем, кто приходит в Лисп из мира императивных языков может так казаться, но я пришел в Лисп после Хаскела и я тебе точно говорю, Лисп - не функциональный.
Теперь по теме - оба языка крайне интересны и способны взорвать мозг, но Хаскел вставляет сильнее, он действительно заумный и изобилует супер-дупер новыми изощренными технологиями программирования (Аппликативные функторы, комбинаторы, монады, ленивые вычисления), но что тебе действительно взорвёт мозг - это чистота языка (нельзя совершать побочные эффекты т.е. не напишешь в консоль где хочешь, не присвоишь значение переменной), отсутствие циклов и декларативность (ты не пишешь "как", а пишешь "что" представляет из себя задача). Но это только в начале. Когда освоишься, оказывается, что Хаскел очень выразителен и краток. Но есть у него и минусы - он очень сложен, ОЧЕНЬ. Серьезно, даже через пол года, у тебя по-прежнему будут проблемы. Уверен, 95% хаскелистов не объяснят в подробности, как работает Hello world на хаскеле, который выглядит так:

main::IO ()
main = do
putStrLn "Hello world!"

выглядит не сложно, но вот что скрывается под водой: все вычисления происходят в монаде IO т.к. только в ней разрешены побочные эффекты. Побочный эффект (действие ввода-вывода) выполняется только тогда, когда вернётся в main т.к. побочные эффекты разрешены только в main (поэтому и только в монаде IO т.к. main возвращает IO () ). Что такое IO ()? Это как бы список действий, которые туда запихиваются и объединяются в цепочку, чтобы быть последовательными (вне монады порядок выполнения твоих инструкций не определён, счастливого дебага). Эти действия на самом деле не выполняются сразу, а представляют из себя "обещание" сделать это действие, которое реализуется как только что-то уже действующее не затребует результат, в нашем случае это консоль... в общем и это только верхушка айсберга, я еще про типы не говорил, про извлечение и упаковку в монаду, про отображения множеств, карринг и тд.
В общем хаскел это интересно, но очень сложно. Даже если не пообломаешь зубы, у тебя очень долго будут проблемы с дебагом, с пониманием всяких астральных техник, которые плодятся день и ночь, вроде стрелок или линз. Да и понять чужой код на хаскеле часто очень сложно, потому что каждый считает, что просто обязан применить все заумные штуки, которые он знает, ведь разве не для этого он учил хаскел? А ведь потом люди будут читать это...
Теперь пара слов о Лиспе - тут у меня меньше опыта, но идея такая - это программируемый язык программирования. Кроме того, что в нём есть макросы - специальные инструменты, чтобы писать программу которая напишет программу, так и сам язык представляет из себя синтаксическое дерево в своём первозданном виде, что открывает безграничные возможности в метапрограммировании. В общем идея такая - этот язык в умелых руках становится абсолютно чем захочешь. Нравится хаскел и ФП? Отлично, сейчас реализуем. Хочешь ленивые вычисления? На! Хочешь классы? Вот! Хочешь логическое программирование? Держи! При всём этом язык крайне прост, может даже проще Си.
Так, что я тебе посоветую? Наверное, начинай с Хаскела - он тащит за собой огромную теоретическую базу и целый арсенал таких приёмов программирования, которые тебе и не снились. Выучишь, освоишься - подумай о лиспе. Но! Тебе в любом случае нужно будет ставить Emacs - это самая лучшая среда для этих обоих языков, а Emacs конфигурируется на Emacs Lisp, так что у тебя будет возможность на него посмотреть. Посмотри видео по емаксу https://www.youtube.com/playlist?list=PLECBtie1W1t... (там и про Emacs Lisp есть глава), потом качаешь "Хаскел во имя добра" и "О хаскел по-человечески" и читаешь их параллельно - в первой хорошее мягкое введение, а во второй практика - она нужна сразу, чтобы хотябы знать, как создать проект с помощью cabal и собрать его, а то Липовача пол книги в интерпретаторе сидит.

значит узкое место почти наверняка диск.

Пальцем в небо, файловая система на которой таблеспейсы лежат какая? случайно не cow (btrfs/zfs/xfs)? с ними отвратительно работают базы данных, так как частые записи в файл генерируют сильную фрагментацию. В этом случае перед тяжелой обработкой хотя бы дефрагментируй файлы базы и отключи cow фичу на таблеспейсах

неплохим тюнингом может оказаться (на выбор):
* разместить базу в ram диске (буквально, залить на сервер в облаке, обработать данные, залить назад, работая напрямую с таблеспейсами, но версия софта должна совпадать до последней цифры)
* разместить базу целиком на ssd (даже если это будет потребительский и дешевый)
* добавить в систему ssd кеш для hdd с помощью например bcache (включенный на запись), правда для линейной обработки базы это может дать мало пользы, но вообще это неплохой способ на порядок поднять производительность за дешево (в одном месте я использовал фичу virtualbox со снапшотами в файл, есть и у kvm, когда последующие записи шли не на исходный образ а на другой диск, и он ssd)
* разместить таблеспейс для индексов (а может и каждую таблицу отдельно) на другом физическом устройстве (hdd, ssd или даже в ram), требования к размеру тут обычно низкие, ключевое слово - исключить последовательные чтения/записи на одно устройство.
* разместить журнал (например ext4) на ssd диск (хватит пары гигабайт) или по хардкору даже отключить его (очень опасно, можно получить кашу из данных при сбое питания, но как временное решение пока идет долгая операция, при наличии всех бакапов, оправдано) - наименьшая оптимизация, но при частых мелких записях это заметно

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

Второе определит, хватит ли тебе sql баз данных (они лучше подходят для фильтраций и анализа чем документоориентированные) либо придется искать узкоспециализированные решения, в т.ч. графовые бд.

Первое же определит, особенно если данных очень мало, может ли самостоятельная работа в оперативной памяти в своем приложении, быть более эффективной? Дело в том что 99% причин, почему в мире люди наработали столько не простых инструментов - это большое количество данных и высокие требования по многопользовательскому доступу к ним, если оба этих пункта исключить, то гораздо удобнее нетипичный анализ проводить в своей программе, удерживая данные в оперативной памяти (а база данных используется исключительно как отказоустойчивое хранилище).

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

p.s. json это значит для контроля над целостностью, индексации и поиска придется городить свои надстройки, с другой стороны это освобождает руки от непреднамеренного усложнения хранилища там где это не требуется, в общем осторожностью нужно подходить к этому, это не плохо и не хорошо, это просто еще один способ со своими плюсами и минусами

Вопрос в заголовке и вопрос в описании - два совершенно разных вопроса.

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

попробуйте так

select count(*) from 
(select * from some_table limit 1000) a

const point = { latitude: lat, longtitude: lon };
const closest = arr.reduce((closest, n) => {
  const d = sphericalDistance(point, n);
  return d < closest[1] ? [ n, d ] : closest;
}, [ null, Infinity ])[0];


function sphericalDistance(p1, p2) {
  // https://en.wikipedia.org/wiki/Great-circle_distance
}

https://ru.vuejs.org/v2/guide/