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

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

WebSQL, увы, стал deprecated еще до того как вышел из черновика. Браузеры тут же кинулись встраивать SQLite, а Oracle испугался и через Mozilla продавил, что браузерное хранилище должно быть key-value. Кое-где (скажем откровенно, в Chromium-based браузерах) до сих пор работает, но когда отвалится -- неизвестно.
У IndexedDB есть одно ярковыраженное преимущество перед localStorage: по умолчанию доступное место заметно больше. Остальное по вкусу, тем более что есть фасадные надстройки над всеми тремя типа localForage.

Если необходимо хранить статичные данные для браузерного расширения

Если это пользовательские настройки, то альтернатив chrome.storage нету. Если это данные необходимые для работу самому расширению (скажем, карты уровней для игры), то проще и логичнее держать это в, например, JSON.

Qt

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

Добрый день! Хотел посоветоваться с опытными бэкэнд программистами.
Встала задача создать высоконагруженный проект (Типо кассового решения). В базе данных через 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 пр.)
   

Веб-компоненты - обобщающее название нескольких технологий, позволяющих создавать собственные элементы с инкапсулированными структурой, стилями и поведением.
Т.е. вы создаёте один-два файла в какой-нибудь папочке, описываете в них разметку, стили и js-код и вызовом некоторых api-функций говорите браузеру - "вот мой собственный элемент с именем my-element, если встретишь тэг , то наполни его вот этим, стилизуй вот так и по событиям выполняй этот код".
Технологии, которые это позволяют постепенно появляются в браузерах, но как обычно не полностью и не везде. Нужны полифилы.

И да, веб-компонент мужского рода)

То как вы хотите определить массив называется VLA (массив переменной длины).
Эта шутка появилась только в C99 и выше. В С++ их нет.
Но даже и в программах на Си не все компиляторы их поддерживают, например в MSVC, по моему, до сих пор не реализовано. Правда микрософт и не заявляет о полной поддержке стандартов Си.

Так что в С++, как уже было сказано в комментариях, используйте либо динамические массивы, либо std::vector.

умный провинциал из Украины придумал антенну

Это сколько же лет этому провинциалу?
Учитывая тот факт, что антенна была изобретена в 1926году ему сейчас явно более ста лет, а он все на ютубе постит? Да еще и на Украину из Японии перебрался?
Мощный чувак.
Такие антенны в советское время делал каждый уважающий себя школьник для просмотра ТВ.
На данный момент это пожалуй самая распространенная в быту антенна.
Ее кстати зачастую называю по фамилии одного из создателей - антенна Яги.

Правда ли он атак работает как говорит автор?

Работает очень хорошо, если конечно изготовлена аккуратно и грамотно. Ну и про согласование не надо забывать.

Схема не совсем понятна

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

VisualBasic (тот, что .NET) почти ничем не отличается от C#, кроме синтаксиса. Есть даже конвертеры из одного языка в другой - пишете программу на VB, получаете на выходе C# (и наоборот). Но я не советую начинать с VB, так как это фактически мёртвый язык, несмотря на то, что в самом авторитетном рейтинге популярности языков программирования он выше C#. Причина тому - США. Там до сих пор активно нанимают VB-разработчиков, которым приходится поддерживать устаревший код. Особенно это касается банковского сектора. Платят за VB больше, но копаться в легаси - то ещё удовольствие.
В общем, учитывая, что оба языка - детища Microsoft, и что сама компания активно продвигает C#, лучше сразу начинать с него.

Наоборот: Makefile включает в себя шел. Грубо говоря это обертка над shell которая позволяет разбивать shell на блоки и указывать зависимости относительно разных блоков кода shell.

`gcc -c -o main.o main.c` - Эта команда ни как не относится к Makefile в чем конкретно вопрос?

И на сколько я помню, если просто вызвать make то выполнится Makefile из текущей директории, по этому пути и должны быть прописаны относительно текущей директории. Но есть возможность вызвать make указав где нужно искать Makefile но какие именно поведение будет тут я сказать не смогу =( никогда так не делал, надо смотреть.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

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

Нет разницы - оба варианта некорректные, таких JSON'ов не бывает.

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

R=G=B, поэтому можно брать любую компоненту,например, R.
Диапазон от 0 до 255.
Нормализуем: percent = 100.0 * (R / 255.0);