GTRxShock

Существенные грабли, которые очень важно осознать - PHP синхронный, в целом, язык, а JS, в целом, асинхронный. Поэтому тут многие подходы из PHP либо работают плохо, либо не работают вообще.

Чтобы эффективно писать на JS нужно осознать прелести функционального и асинхронного подхода, научиться мыслить коллбеками и не гадить в глобальное пространство.

Еще нужно осознать, что в JS всё (ну или почти всё) есть объект, а, так же, как работает прототипное наследование и замыкания, как работает так называемый Event Loop в совокупности с Call Stack.

Научиться мыслить цепочками вызовов т.к. многие методы в JS поддерживают chaining. Например

const s = '1234567890';
const onlyEvens = s.split('').filter(e => (+e % 2) !== 0).join('');

или даже так

const onlyEvens = '1234567890'.split('').filter(e => (+e % 2) !== 0).join('');

причем во втором случае имеет место быть неявное преобразование строки к объекту, т.к. у самого скаляра строки нет методов.

Вообще мне хорошо мозги на место поставил курс по ES v5 Javascript: Understanding Weird Parts ну или примерно то же самое но на русском у ZORAX. У Кантора тоже все великолепно разложено по полочкам, но он просто жесть какой нудный (имхо).

А потом просто очень много практики, лично я тупо решал всё подряд на кодварс.

А еще чтобы лучше что-то понять, начни объяснять это другим. :) Я так однажды замыкания объяснил кому-то, что аж сам понял... :D

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

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

Про надёжность могу посоветовать два шикарных букваря:

Крис Клирфилд и Андраш Тилчик - "Неуязвимость"

Майкл Нейгард - "Release it!"

Крейг Уоллс - Spring в действии
Шефер, Хо, Харроп - Spring 4 для профессионалов

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.

Это не ооп, ты просто собрал функции и засунул их в класс. Типа такого надо:

class User (){
    construct ()
   save() {
       return ajax-запрос
   }
}
class List () {
  this._list = []
  consruct(id) {
  }
  addItem(user)
  render () {
      doucment.getElemntBy(id).innerHtml = ''
      this._list.forEach(user => {
         // добавление новой строки
     })
  }
   
  fetcList () {
     return аяк-запрос.then(users => {
        this._lsit = []
         users.forEachv(user => {
             this.addItem(user)
        })
    })
   }
}
new Subsriber {
  action,
  cb
}
class Emitter {
    this._evts = []
    subsctibe(action, cb) {
       this.evts.push(new Subsriber (action, cb))
    }
    emit(action, value) {
        this.evts.forEach({action} => {
       if (act === action) {
           cb(value)
       }
     })
    }
}
class Form (){
  consruct(id, emmiter) {
    doucment.getElemntBy(id).addEventListener('sumbit', () => this.onSubmit)
  }
  addElement(elem) {
     this.elements.push(el)
   }
  onSubmit () {
      const user = new User()
      for (let elem of this.elements) {
          user[elem.name] = elem.value
     }
     user.save().then(добавленный юзер => {
           this.emmiter.emit('submit', user)
     })
  }
  }

  render () {
      doucment.getElemntBy(id).innerHtml = ''
      this.elements.forEach(elem => {
         doucment.getElemntBy(id).insertBefore(elem)
     })
  }
}
// инициализация этого говна
const list = new List(listId)
const emmiter = new Emiiter()
const form = new Form(formId, emmiter)
form.addElement(document.createElemnt('input'))

// теперь отрисовка
form.render()
list.render()

// подписываемся на события формы
emmiter.subscribt('sumbit', user => {
    list.addItem(user)
    if (не грузим с сервера) {
      // перерисуем
         list.render()
    } else {
        // перерисуем
         list.fetchList().then(() => ist.render())
     }
})

1. Вы инкапсулируете модуль Form, но при этом он зависит от глобальных переменных, а не получает нужные параметры при создании экземпляра.
2. Сам объект Form это ни что иное, как наглядная демонстрация антипаттерна God Object . Почему, не имеющий никакого отношения к форме, список является ее частью остается загадкой. Как и то почему в модуле инкапсулировано состояние приложения.
3. Насчет аргумента "e" уже не раз написали. Насколько я понимаю, вы видели на просторах интернета, что так часто называют аргумент функции, но, видимо, не поняли почему. Один аргумент имеет говорящее название user, но и оно вводит в заблуждение, так как на вход ожидается массив пользователей.
4. Почему не использованы возможности ES6 остается загадкой.
5. Попробуйте сами догадаться, что не так с этим отрывком кода.

users.push(this.user);

let lastUser = users[users.length - 1];

6. У вас почти все переменные в методах объявлены свойствами объекта, при том, что в этом нет никакой необходимости и это может стать причиной ошибок в дальнейшем. Почему не использованы локальные переменные остается загадкой.

вы б хоть пример входного и выходного текста привели.
https://regex101.com/r/JgQgsq/1

Найти другую работу

https://serversforhackers.com/

Псевдоэлементы в помощь:

Слушай, я понимаю, что ты хочешь, но, боюсь, здесь нет ответа.

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

Из того, что можно точно выделить:

1. Советы Горбунова. Школа у них чудовищная, но вот в советах очень много полезной информации. И, по-моему, они эти советы перенесли в формат электронных книг. Там и по интерфейсам темы и по академическому дизайну и много ответов на разные вопросы по копирайтингу/менеджменту/развитию. В общем, довольно ценный ресурс.

2. Школа Тильды. Это набор последовательных статей. Там описан в некоторой степени утопичный дизайн-процесс, но именно к такому процессу и нужно стремиться при работе в команде дизайна. Они рассказывают о дизайн-мышлении, о картах, персонажах и прочих ментальных инструментах. Это материал не для новичка, а для мидла скорее. Сейчас большинство крупных западных команд работает в +- подобном ключе.

3. Книга "Психбольница в руках пациентов". Классика. Читается как роман, ставит мозги на место сразу. Ты начинаешь решать задачи, а не рисовать пиксели.

Многие скажут, что нужно обязательно прочитать Тафти. Лично я читал его, но это невероятное занудство — более скучных книг нет на всей планете, наверное. Если ты хочешь быть прям как Бирман какой-нибудь — дотошным любителем схем, инфографики и вот этого всего, тогда это маст рид. Есть еще Раскин, который решил описать работу над интерфейсом в академическом стиле. Тоже считается некоей библией. По занудству находится примерно рядом с Тафти. Но мне кажется, что это примерно как учить английский язык по словарю.

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

И самое главное — научись верстать. Не просто понять базовые теги html, а по-настоящему. Чтобы твой код был почти готов уйти в продакшен. Ты откроешь для себя сторону дизайна, которая всегда оставалась в тени — то, как твой продукт реально работает, а не то, как ты себе это представляешь, глядя на картинку. Например, ребята из Apple всегда делают сотнями пенопластовые и пластиковые макеты для новых Айфонов, крутят их в руках, ходят с ними в карманах и т.д. Только так можно прочувствовать форму, понять изъяны и улучшить продукт. Картинка ничего не говорит о проекте, нужно уметь ее материализовать. В вебе с этим помогает верстка.

Упрощаю вопрос:
Я запланировал сделать это за две недели, но ошибся в оценке. Что делать?
Ответ на мой взгляд очевиден:
Извиниться, признать ошибку, сделать выводы. Все остальное (типа привлечение доп ресурсов, введение ночных смен и т.п.) это попытка прикрыть свою ошибку как менеджера за счет компании.

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 1-2 года планируется , около 150млн записей у основной сущности (продажа).

150 миллионов записей - это ерунда, а не высоконагруженное решение.
У меня 5 000 записей в секунду создается на довольно дохлом (что-то около 500 рублей в месяц стоит хостинг) сервере VDS/VPS
Два года? 150 миллионов - это за ... 9 часов.
И да, я не считаю это решение высоконагруженным.
Нагруженным - да.

то есть нужно максимально быстрое чтение этих данных

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

Если всё же нужны все данные сразу (ну какая-то общая статистика) - то на основании первичных данных выполняется агрегация (например, по ночам) и тогда отчеты будут строится вообще - мгновенно.

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

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

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

Это зависит от того что за данные.
Что именно за данные.

Сам пишу на mysql - потянет ли он такие объемы, на нормальном железе. Или нужно смотреть в сторону других БД?

MySQL довольно быстр.
Например, PostgreSQL более функционален. Но насчет скорости - не обязательно.

потянет ли он такие объемы, на нормальном железе

А в официальную документацию заглянуть?
https://dev.mysql.com/doc/refman/8.0/en/limits.html
150 млн. записей для современных СУБД и современных компьютеров (даже не на "нормальном железе") - это тьфу, а не нагрузка.

P.S.:
Для высоконагруженных систем формирования отчетов есть различные решения:

1. Предварительная (ночная) агрегация данных
   
2. Master-slave, где master только обновляет данные, а slave - только для отчетов.
   
3. Специализированные, заточенные под конкретный вид данных СУБД (InfluxDB, Redis-Tarantool-Aerospike, ClickHouse пр.)