Дмитрий Бурнашев

Но до создания калькулятора так и не дошёл.

Не похоже на любовь к программированию.

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

То есть основ программирования вы не знаете. Ясно.

...с чего начать?

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

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

wx - это страх, ужас, старье, трэш и угар. Он пытается любую систему превратить в венду (точнее, в пародию на MFC). Где вы только его выкопали? Закопайте обратно и не трогайте.

Qt на лицензии LGPL неплох.

1) Работает. И на макоси работает, и на андроиде работает, и на вебе работает, причем двумя способами.
2) Нетушки, учите английский. Если упираться и требовать доку на русском, 99.99% современного айти пройдет мимо вас. Ладно, в случае с Qt есть книжки Шлее
3) Он там есть

Самое простое - nginx отдаёт статику. На больших объёмах делать это через Ноду неэффективно.
Посложнее - nginx позволяет управлять ходом запроса. Например, редиректить на https.
Ещё сложнее - можно настроить nginx, чтобы он умно балансировал запросы между несколькими бэкендами и автоматом блокировал слишком частые попытки подключения.

Nginx очень хорошо в промышленных масштабах делает определённую часть работы, связанной с http-запросом, поэтому ему эту часть работы и делегируют.

https://www.prisma.io/

Писать код так, чтобы он сам себя документировал.
Давать осмысленные имена переменным и функциям, пусть длиннее, зато читабельнее.
Почитать про архитектуру, паттерны.
Рекомендую "Чистый код" Р. Мартин. Там эта тема поднимается.

Работал с Nuxt в сумме примерно в течение года. Написал свой блог на нем (довольно большой), вот он на гитхабе: https://github.com/iliyaZelenko/blog-frontend

Недостатки которые заметил:

1) Он долго запускается при `nuxt dev` (мой блог запускается за 3-5 минут) и HMR обновляется в среднем 1-5 секунд (порой и дольше), даже если обновил просто template. Это больше всего напрягает.

2) После изменения кода, иногда папка `.nuxt` генерируется с ошибкой, приходится менять любую строчку в исходниках проекта чтобы опять запустить генерацию или порой полностью перезапускать Nuxt. Такая проблема была замечена не на всех проектах.

3) Бывает проблематично использовать модули которые не идут сразу на сервере и на клиенте, но это больше проблема SSR. Еще порой хочется получить сам nuxt контекст где store, router, плагины, но это нельзя сделать в некоторых местах, обычно эта проблема на клиенте. Например, на клиенте в store где state еще нет свойства window.$nuxt, нельзя обратится к плагину универсальных куков cookie-universal-nuxt и взять из куков значение и записать в state, а по другому к контексту nuxt не обратится. Store тяжело получить в самом store, порой это нужно.

4) Когда с ним использовал TypeScript, то иногда nuxt выдавал что типа (обычно интерфейса) не существует или другие ошибки типов, но этих ошибок на самом деле не было. Единственный выход — заново запускать nuxt dev и долго ждать, порой эта проблема возникала по несколько раз в течении 20 минут, приходилось перезапускать несколько раз.

В моем блоге мне почти всегда нужно было Dependecy Injection чтобы внедрять разные модули, но они были не доступны в `asyncData`, там нет this, пришлось получать прямо из контейнера. Пример кода:

const CategoryRepository = serviceContainer.get<CategoryRepositoryInterface>(TYPES.CategoryRepositoryInterface)

Взят от сюда.

Вообще вместе с vue-class-component нельзя использовать конструктор чтобы внедрять там зависимости, я использовал inversify для DI, но чтобы оно работало vue-class-component пришлось использовать костыль с vue-inversify-decorator (костыльный способ от разработчиков vue-class-component исправить эту проблему), писать `@Provide(container)` в layouts/default.vue (лучшего места не нашел к сожалениию, это тоже минус). Как было бы удобно если внедрил зависимости в конструктор и они сразу есть во всем компоненте и в `asyncData`.

Хочу изучить next (react) чтобы было с чем сравнить.

Как хранить исходники вместе или раздельно по разным репозиториям? Какие плюсы и минусы каждого способа?

Мне кажется тут вопрос не столько в "плюсах и минусах" сколько в здравом смысле. Мне не совсем понятно, что в конечном счёте означает "бекенд на python, фронтэнд на angular". Это два независимых проекта, способных работать автономно друг от друга и "общаться", например, через API, разработка которых происходит параллельно и независимо друг от друга, при этом какие-либо части проектов не пересекаются между собой (например, куски HTML/CSS/JS/etc кода не копируются в бекенд-часть)? Если так - то крайне логично разделить это на два отдельных репозитория, т.к. это по сути два разных проекта, связанных между собой весьма косвенно. Если же у Вас проекты имеют более прочную связь между собой или степень контаминации исходного кода выше той, что я описал ранее - то это один проект и дробить его на множество репозиториев, лично я смысла не вижу никакого (а то мы так дойдём до "давайте хранить HTML-код в одном репозитории, CSS в дургом, JS в третьем и т.д.).

P.S. Обычно, такие вещи разъясняет штатный тимлид, а не коллеги по форуму :)

const index = arr.findIndex(n => n.id === id);
if (index !== -1) {
  arr.splice(index, 1);
}

или, если нужен новый массив:

const newArr = arr.filter(n => n.id !== id);

Если же id имеют не уникальные значения, то создание нового массива остаётся без изменений, а модификация существующего может выглядеть так:

for (let i = arr.length; i--;) {
  if (arr[i].id === id) {
    arr.splice(i, 1);
  }
}

или так (да, reduceRight используется не совсем по назначения, как и оператор &&):

arr.reduceRight((_, n, i, a) => n.id === id && a.splice(i, 1), null);

или так:

let countDeleted = 0;

for (let i = 0; i < arr.length; i++) {
  arr[i - countDeleted] = arr[i];
  countDeleted += arr[i].id === id;
}

arr.length -= countDeleted;

или так:

arr.splice(0, arr.length, ...arr.filter(n => n.id !== id));

Расскажите плиз о технологии, и чем развёрнутей, тем лучше.

Вот захотел ты сделать сайт SPA или PWA с любимой тебе вёрсткой на базе Twitter Bootstrap и любимой библиотеки Vue. Сверстал. Поповеры не появляются, дропдауны не выпадают, модалки не открыватся, формы не валидируются, клики не работают.

Оригинальный Twitter Bootstrap имеет поддержку интерактивных элементов на Javascript. Реализовано это на библиотеке jQuery. Если делаешь на Vue, придётся подключать ещё и jQuery, что лишняя библиотека на 100+ килобайт, что, конечно, не катастрофа (пока ты не на мобилке).

Vue работает с состояниями привязывает данные к отображению, а jQuery работает с DOM и событиями. Это вопрос производительности. Работа JQuery начитается когда загружен и распарсен JS и HTML. Работа Vue начинается в тот момент, когда загружен и распарсен JS, то есть чуть раньше. jQuery модифицирует DOM на лету, перестраивая текущий документ. Vue работает с shadow DOM, а затем подсовывает уже готовую интерактивную страницу в пустой документ, что быстрее (разница в секунды на десктопе, десятки секунд на м...).

Vue реализует компонентную парадигму. Куски страницы являются изолированными кусочками кода (HTML CSS JS), которые цепляются между собой динамически, а обмениваются данными через аттрибуты и события. Предположим, что вы решили следовать компонентной парадигме, тогда согласно вот такому примеру нужно будет увязать самостоятельно все интерактивные компоненты. Компонента-кнопка. Компонента-поле ввода. Компонента-форма. Компонента-контейнер. Получается около 50 компонент. Для некоторых надо будет написать логику на jQuery. Если посмотреть на код jQuery этих микрокомпонент, то он окажется несложный, его вполне можно переписать на Vue. Ну там класс заменить или клик отработать. Когда от кода jQuery не останется следа, его можно будет из проекта удалить.

И вот получается Bootstrap-Vue

На компоненты побили. От Jquery избавились. Написано в единой парадигме. Работает быстрее.

Добавляем тот факт, что в Vue можно не импортировать компоненты, которые не нужны (например, я не работаю с дропдаунами и модальным окнами) и код становится меньше, грузится быстрее, работает быстрее.

Так же будет Не лишним оценить технологию: плюсы, минусы, стоит ли вообще с этим работать ...

Это сам изучай и сравнивай. Навыки и опыт воздушно-капельным и через Internet не передаётся

SourceTree

KeePass + KeeFox (для Firefox)
Работаю с этим тандемом уже несколько лет. У них довольно гибкие возможности.

Начнём с того, что 500 шт. каждые 5 с - это 100 запросов в секунду. Прокси будут баниться очень быстро при подобном трафике.

Далее, получение данных мегабыстро имеет смысл в автоматизированных системах торгов на фондовой бирже, а если это в телеграм человеку сливать, то он в любом случае будет реагировать намного медленнее этих 5 секунд. И зачем тогда так часто опрашивать? Если опрашивать с интервалом в 3 секунды, то товары будут приходить с опозданием в среднем 13 минут, максимум 25 минут, что для многих задач вполне приемлемо.

Советую поговорить с заказчиком ещё раз на тему того, что именно ему нужно.

1) Либы вместе с бинарником
2) Сборка под версию из репозитория системы
3) Статическая сборка