smilingcheater

Поменяйте записи в fstab - вместо /dev/sdx используйте uuid дисков.
Для просмотра значений uuid воспользуйтесь командой blkid.

https://wiki.archlinux.org/title/Fstab_(%D0%A0%D1%...

Вывести куда? В вашем примере не прописан сам вывод.
Также коллбэк в forEach некорректно построен, вы пытаетесь передать в качестве аргумента некий this.balance. Но в функцию вообще нельзя передать аргумент в таком виде. У forEach есть конкретная сигнатура

array.forEach((element, index, array) => {}) // 2 и 3 необязательные

Поэтому, по сути, должно выглядеть хотя бы так

array.forEach((element) => element.balance.startsWith("$1") && console.log(element.balance))

Также можно деструктурировать, вытащив стразу свойство balance через фигурные скобки:

array.forEach(({ balance }) => balance.startsWith("$1") && console.log(balance))

Если же вам нужно получить именно отфильтрованный массив, состоящий из юзеров, чей баланс меньше 2k, то вместо forEach нужно использовать filter, возвращая результат его работы:

function findBalance (array) {
  return array.filter(({ balance }) => balance.startsWith("$1"))
}
console.log(findBalance(users))

А вообще хранить числа (в т.ч. денежные суммы) в виде строк - это чрезвычайно плохая идея. Лучше распилить свойство balance на два других свойства:

// Вместо
{ balance: "$1,000.57" }

// Сделать так
{
  balanceAmount: 1000.57,
  balanceCurrency: '$'
}

// Или так
{
  balance: {
    amount: 1000.57,
    currency: '$'
  }
}

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

const balance = {
   amount: 1768.67,
   currency: '$'
}
console.log(`${balance.currency}${balance.amount.toLocaleString('en-EN')}`);

А совсем уж по уму будет вот так:

const balance = {
  amount: 1768.67,
  currency: 'USD'
}
console.log(balance.amount.toLocaleString('en-EN', { style: 'currency', currency: balance.currency }));

Почему csv iterator не записывает все, хотя должен?

Нет, не должен. Итератор не должен ничего записывать, он интератор. Итератор итерирует. Всё.

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

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

query = """variables_loaded[variables_iterator]['0']""" ##, так далее

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

При всех ваших ошибках в постановке вопроса нам тут уже не ясно, может быть у вас вообще нет работающего кода, который что-то записывет из CSV в БД, а то, что вы думаете он, якобы, запсывает, уже и так есть в БД, а вы просто этого не понимаете! Ну как не понимаете, что проблема может быть в SQL-запросе, поэтому его не приводите, как не понимаете, что проблема может быть в индексах и структуре БД, поэтому не приводите её структуры, как не понимаете, что проблема может быть в данных (они могут повторяься в разных строках CSV), а вы и не приводите все данные, и не говорите, что убедились, что они не повторяются!

execute_query(connection, query)

В-третьих, вы оставляете за скобками код выполнения SQL-запроса. Мы не знаем что это за код, может быть там вы тупо try-except'ом задавили все возможные ошибки и сами, фактически, отказались от того, чтобы БД вам объяснила в чем проблема. Может быть это вообе пустая функция внутри, или она неправильно обернута каким-нибудь декоратором, который ей не дает работать, а вы просто видите в БД одни и те же данные, и думаете. что они каждый раз туда заливаются вновь вот этим неработающим вообще кодом.

Как нам судить обо всём этом букете гипотетических пробелм, если вы старательно все улики замели под ковер? Для чего вы это сделали?

Так а в чем проблема-то? Это ж школьная программа?
Точка А у вас есть, точка B тоже. Берёте вектор AB - это вектор B минус вектор A.
Нормируете его до единичного. Для этого нужно вектор AB разделить на модуль (длину) этого вектора. AB/|AB| - это вектор направления на точку, над которой надо поставить камеру.
Осталось этот единичный веткор умножить на необходимое вам расстояние. В вашем случае это 5: AB/|AB|*5
Также моэно вычслить и положение камеры. Допустим камера в точке X и ее координат мы не знаем, но знаем высоту камеры, а значит и вектор CX = (0,0,4), если высоту камеры мы решили взять равной 4.
Итого: X=B+AB/|AB|*5+CX
где:
X - искомый вектор координат камеры;
B - вектор координат точки B;
A - вектор координат точки A;
AB = B-A -- вектор, равный разности векторов B и A;
|AB| -- длина вектора AB, то есть его модуль;
CX - вектор, указывающий на камеру относительно точки C, например (0,0,4);

Можно сразу все вектора сделать трехмерными и делать все вычисления в них.

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

Сколько людей - столько мнений. Не стоит прям вообще всех слушать, кто высказывает какие-то "гениальные" откровения. Даже внутри крупных фреймворков многие вещи реализованы по разному, и каждый считает что именно так надо, и никак иначе. Думаю автор статьи просто искал дешевого хайпа, на практике никто так не делает. Контроллер по сути не модель, а управляющая конструкция, в ней нормально внутреннее ветвление на методы. С таким же успехом можно решить что для модели нужно 4 репозитория, на каждое действие CRUD...

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

Не надо ничего хранить - у вас все данные для такого вывода уже есть. Один простой запрос

select * from news order by (id > ИД_ТЕКУЩЕЙ НОВОСТИ) desc, id limit 5;

сделает вам ровно то что вы хотите - 5 следующих новостей, у самой последней новости выведет 5 первых.

З.Ы. Но и это решение так себе.