Konstantin Chuykov

Можно и не разделять код из репозитория по веткам. Концептуально звучит, что это модули зависимые от ядра. В мастере будут соседствовать все 4 модуля (включая ядро). Идея в том, что ядро проекта обычно надо держать в наиболее актуальном состоянии и только путем хранения по соседству этого можно добиться без проблем.

Решение через submodules потребует создания 3-х дополнительных репозиториев, а наличие отдельных веток может мешать, так как есть возможность забывать делать merge или cherry-pick изменений из мастера с ядром.

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

Безопасность это конечно хорошо, но шифровать данные в базе это уже слишком.
А как вы работать с ними собираетесь? Выборки делать? Индексы тоже шифровать?
Надо защищать базу от взлома, а не устраивать кашу внутри базы.

В соответствии с постановлением № 640 от 07.07.16 г., внесшим изменения в Классификатор основных средств, срок амортизации компьютера может устанавливаться от 2 лет 1 мес. до 3 лет. (25-36 мес.).

Дальше только на глазок)

Износ ПК идет по большей части в плане устаревания.
Обычно 5-6 лет и нужно менять. В некоторых случаях чаще.
Хотя железо еще будет работать как новое, просто толку от него не будет.
Поэтому нужно смотреть насколько соответствует текущая конфигурация ПК выполняемым задачам, хватает ли ресурсов, как скоро будет не хватать, есть ли возможность модернизации и оправданна ли она.

Как уже писали выше - чёткого метода нет.
Для начала надо понять что от Вас хотят.
Амортизацией для бухгалтерских целей занимается бухгалтерия. Это очень просто.
От Вас же, быть может, хотят финансовые планы по ремонту, модернизации и обновлению. Способов считать это много.
Однако что я посоветую сделать (один из способов, которые я придумал сам и делал):
1. Смотрите типовые наборы ПО.
2. Собираете системные требования этих наборов. Актуальные версии 7-5-3-1 лет назад.
3. (тут по идее надо было бы запросить планы по развитию бизнеса. масштабированию и графики шагов по захвату мира, но у вас таких, наверное, нет)
4. Экстраполируете графики роста системных требований на те же 1-3-5 лет вперёд.
5. после п.4 ваяете планы по устареванию оборудования. Упоминаете, что не учли планов по захвату мира и если вдруг выяснится, что надо всем поставить новое тяжёлое ПО - график будет неверным.
6. Лезете в инетики в поисках хоть какой статистики по отказу оборудования. Допустим, нашли что-то типа "десктопы Делл высоконадёжны, они отказывают лишь в 5% случаев в течении гарантийного периода". вот и цифра. Привязываетесь к ней или какой иной (это в любом случае будет несколько процентов, максимум 10). вот и план по аварийке. Можете запросить КП у каких-нибудь интеграторов на поддержание парка в актуальном состоянии. Они вам там и графики нарисуют, если что.
7. показываете, что Вы умный и беспокоитесь за кошелёк хозяина - предлагаете план экономии за счёт сохранения части комплектухи, перестановки компа условного дизайнера при обновлении условному кладовщику.

...вот как-то так.

Вообще есть серьёзная дисциплина как это делать правильно. Она есть и в ITIL, и в MOF и там это делается несколько иначе, чем я написал.

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

Это работа бухов, а не сисадмина.

Расчёт процента износа основного средства (ОС)
Для расчёта используются несколько показателей.
1) Первоначальная стоимость ОС - цена, за которую этот актив был приобретён.
2) Срок полезного использования - тот срок (обычно измеряется в годах), на протяжении которого это ОС планируется использоваться без серьёзного ухудшения его характеристик.
3) Амортизационные начисления - часть стоимости ОС, которая переносится на себестоимость.
Процент износа ОС рассчитывается по следующей формуле:
%износа = (амортизация / начальная стоимость ОС) * 100%.

Пример.
ПК был куплен за 100 000 рублей. Срок полезного использования 3 года, амортизация начисляется равномерно (линейным способом) один раз в месяц.
Предположим, с момента покупки этого оборудования прошло 2 года. Рассчитаем процент износа.
Амортизационные начисления = 0,66 * 100 000 руб. = 66 000 руб.
%износа = (66 000 руб. / 100 000 руб.) * 100% = 66%.
Таким образом, процент износа данного основного средства равен 66.

https://facebook.github.io/react-native/docs/getti... - и вперед.

p.s. Характеристики в духе "сложно" или "легко" не имеют смысла. Вам либо нужно либо нет.

Если пишешь один компонент - достаточно только react, когда пишешь два и более компонентов, удобнее будет использовать redux, чтобы обмениваться данными, между этими компонентами. react-router нужен если строишь веб приложение и не хочешь обновлять всю страницу, когда пользователь кликает по ссылке. (а просто меняешь содержимое страницы js'ом). Стандартными средствами можно обойтись для дебага в консоле =)

Я не понял вопроса.
React Native Packager автоматически подхватывает и компилит изменения.
На девайсе можно открыть developer menu (cmd + D на iOS, F2 на андроид). Там можно включить Live reload для автоматической перезагрузки приложения либо Hot Update для применения изменений без перезагрузки.

> его я в глаза не видел, и не помню
Никакой пароля Вы вспомнить не сможете, потому что его не было. Только ключ.
> Можно ли сбросить пароль, или еще что-то?!
И сбрасывать ничего не надо. И не надо разрешать доступ по ssh по паролю. Только по ключу.

Update Я не знаю что такое MongoHub и для чего оно Вам. Но если оно такое, что не умеет корректно использовать ssh с ключем, а жить без него Вы не можете, то прокиньте на инстанс туннель через ssh.

Как автор упомянутого сервера приложений, проясню ситуацию. Все остальные приведенные решения перестартовывают процессы. В лучшем случае они запускаются в режиме нескольких процессов (при помощи cluster или используя child_process) и перестартовывают дочерние процессы (worker), а родительский процесс (master) следит за изменениями и не перестартовывает. Это действительно дает нулевой даунтайм, что важно для продакшена, но не особо важно для разработки. А важно другое - удаляются из памяти все данные, все развернутое там состояние, закрываются соединения с БД, выгружаются библиотеки, да и все, что было проинициализировано при старте приложения, все полностью разрушится и перезагрузится. В Impress же подгружаются отдельные файлы, заменяя на лету в памяти предыдущий код. Это делается без eval, при помощи vm. При многочисленных изменениях он понимает, что меняется много файлов (например заливается новая версия приложения) ждет, когда эта активность прекратится, а потом обновит все одним махом. При частых изменениях одного и того же файла, может сложиться ситуация, когда в памяти будут параллельно находиться 2-3 копии одного кода. Дело в том, что в систему идет поток запросов, и старые запросы еще были запущены в момент, когда была предыдущая версия, и они не успели завершиться. Поэтому, нужно дождаться их завершения, а для новых уже можно использовать новую версию кода. Там есть еще много особенностей, о которых долго рассказывать. В общем, мне не известны другие реализации этого решения. Если они таки найдутся, то пришлите на сравнение. Приведенная же статья несколько устарела, для первичного ознакомления берите эту: habrahabr.ru/post/247543