Fengol

Не могу связать вот это

Затем создаю папку mocks и несколько файлов в ней (a.php, b.php) и затем
> git add .
> git commit -m "add mocks"

И вот это

При чем если в новой ветки новые файлы были в игноре, то именно они попадают в ветку от которой она была создан

Так они в игноре или вы их комитили ?

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

А если вы добавили папку в коммит и закомитили (можно посмотреть в ченжлоге к комиту), то она должна пропасть как только вы переключитесь на исходный бранч

QML по дефолту на GPU. С версии 5.8 можно на CPU рендерить. Почитайте про scene graph, там всё очень подробно расписано.

Разница есть и она очевидна, развею несколько ваших мифов:
1. Нет единого каталога всех проектов, их нельзя найти в гугле или получить каким-либо другим путём.
2. Вы не можете найти какого-либо пользователя и посмотреть его проекты.\

Но вот какие минусы есть у бесплатного плана:
1. Вы не можете поставить пароль на проект, и вашу ссылку могут передавать из рук в руки.
2. Если вы передали ссылку на "прототип", заказчик получает ссылку и на исходник.
3. Вы не можете контролировать количество пользователей, которые могут просматривать ваш проект, имея ссылку - на него могут зайти все, и все могут получить ссылку на исходник, и потом скопировать ее к себе.

У платной версии есть полный контроль за доступом к вашим исходникам, в этом есть большой плюс.

Если вы поделитесь ссылкой на проект, то да.
По умолчанию.
Но есть возможность закрыть публичный доступ.
Нажмите кнопку share — там можно запретить просмотр по ссылке.

У меня бесплатный тариф. проверил со второго аккаунта.
Закрытый файл отдает ошибку 404.

Не спец в rxjs, но можно попробовать такое:

const stream = of(0,1,2,3);
const yourMagicCondition = x => x === 2;
const interrupter = stream.pipe(
  filter(yourMagicCondition),
  take(1),
);

stream.pipe(
  takeUntil(interrupter),
  merge(interrupter),
);

Делай раз

Делай два

Бесконечно растущие массивы это плохо, потому что вы его храните в документе. При каждом увеличении массива, документ не будет умещаться в то же самое место на диске, поэтому монга перенесёт его полностью в новое место. Для этого ей понадобиться прочитать все эти миллионы элементов массива, добавить к нему один и записать. И так каждый раз. В итоге вместо записи несколько новых байт на диск монге придётся считывать мегабайты/гигабайты и записывать их на диск заново в новом месте. Это ни разу не оптимально. Я уже не говорю про то что рано или поздно документ станет настолько большим, что его невозможно будет прочитать/обновить.

Collection.find({
    $or: [
        {
            "type": "a",
            "target.a": { $gt: 5, $lt: 10 }
        },
        {
            "type": "b",
            "target.b": { $in: ['a', 'b', 'c'] }
        }]
})

Marvel.aggregate( [
  {$group: {_id : {name : '$name', type:'$type'}}},
  {$project : {name: '$_id.name', type: '$_id.type', _id : 0}}
], function (err, result) {
        if (err) {
            console.log(err);
        } else {
            console.log(result);
        }
    });

Тут все зависит от ситуации. На счёт производительности я так понял вы уже разобрались. БД не такие тупые, чтобы все 100 лямов записей перебирать в поиске нужной. Даже в этом случае, хранение в массиве вам никак бы не помогло, так как данные все равно пришлось бы вытягивать из другой коллекции. Только в этом случае выборка получилась бы гораздо сложнее и медленнее.

Чтобы ответить на свой вопрос, подумайте, как бы вы вытянули из БД книги издательства, в которых более 100 страниц, если бы хранили в массиве? Это первый момент.

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

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

В примере рассмотрена связь one to many, когда к примеру одно издательство имеет много книг, а книга только одно издательство. Но есть связь many to many. Например, рецепт имеет много ингридентов, а каждый ингридиент привязан ко многим рецептам. В этом случае в nosql как раз нужно использовать массив.

Так что все зависит от ситуации. Иногда даже лучше не делать отдельную коллекцию, а записывать документ целиком в массиве, как в первом примере из ссылки.

Индексы в MongoDB, представляю собой, в целом, то же самое, что и индексы в другой базе данных. Вместо перебора большой коллекции целиком, мы перебираем индекс, который гораздо проще запихать в память и работать с ним. Помимо прочего, индексы в отличии от самих данных, более нормализованы для поиска/сравнения значений.

Тут про индексы PostgreSQL, но аналогичным же образом, индексы работают во всех БД, с которыми приходилось работать мне.

После того, как поймете общее назначение индексов, можно будет легко найти интересующую Вас информацию по конкретному типу индексов в конкретной БД.

что происходит, когда мы их объявляем

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

Можно ли объявлять много индексов в коллекции?

Можно, но чем больше индексов - тем больше данные будут занимать на диске.

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

а где там написано, что Монга будет

искать сотню книг, пренадлежащих одному автору, из миллиарда

?

пример вообще об уменьшении избыточности
ну а ответ там же по ссылке

// ...
var UserSchema = new Schema({
  name: String,
  email: {type: String, lowercase: true},
  contracts: [{
    type: Schema.Types.ObjectId,
    ref: 'Contract'
  }]
});

module.exports = mongoose.model('User', UserSchema);

// ...
User.findOne({
    _id: userId
  }, '-salt -hashedPassword')
    .populate('contracts')
    .exec(function(err, user) { // don't ever give out the password or salt
      if (err) return next(err);
      if (!user) return res.json(401);
        // user.contracts.forEach(function(contract, index){ console.log(index, contract); });
        res.json(user);
      });

Разница мизерная.
Можно даже самим провести тесты и сравнить, сколько времени уходит на компиляцию запросов. У меня этот оверхед составляет примерно 5-6ms. Если использовать persisted queries и не валидировать запросы, то этой разницы почти нет.
Давно использую graphql в проде, и какой-то ощутимой нагрузки это не добавляет.
Но все зависит от сценария использования. Если есть сценарии, где важно все сделать быстро, то тут конечно обычный REST.
Dataloader можно и нужно использовать, но он увеличивает время разработки. Есть проекты, где важно все сделать быстро, с graphql это намного проще.

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

git checkout --orphan newbranch
git reset
git commit --allow-empty -m "init"

Будет создана новая ветка newbranch, независимая от текущих веток и с 1 пустым коммитом.

По разному.

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

Например, у меня был заказ на разработку интерфейса для 3D-принтера, где решено было в качестве экрана и панели управления использовать простой планшет Android, который вклеивали внутрь корпуса принтера.

Также разумно использовать планшет как панель управления, скажем, для "умного дома" на небольших тиражах.

Даже автомобилестроители при их больших тиражах зачастую предпочитают решения на базе Android или WinCE для своих мультимедийных систем. Например, Андроид им нужен, чтобы не заморачиваться со стеком Bluetooth и заиметь сразу же готовый GUI.

Если же вопрос не стоит в организации графического интерфейса пользователя но нужен сетевой стек, то может использоваться Linux/BSD/пр.

Впрочем, Linux может использоваться и для GUI. Но для этого должны быть возможности:
Большая серия.
Или особые требования по энергопотреблению невысокому (Андроид, все же, сравнительно много кушает).

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

А еще бывают, что у управляемого оборудования есть жесточайшие требования по real-time.

Тогда может быть использована полноценная специализированная real-time ОС, способная подгружать модуля, так и операционная система намертво сшиваемая с прикладной программой (правильнее было бы назвать ОС в данном случае библиотекой для доступа к железу, но исторически повелось, что ее называют ОС). Иногда для жесткого real-time практикуют без ОС вообще.

Гуглите QNX, RTOS.

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

Языки высокого уровня - это все что не ассемблер.

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

Например, тот же язык высокого уровня Си вполне себе дает уровень доступа к железу на уровне сопоставимом с ассемблером

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