O Di

Правильно/неправильно это относительная оценка.

Я делаю так.
до 500 мег под /boot
далее создаю LVM на котором ставлю
/
/home
/log
swap

Но важным является то, что я не выделяю всё свободное место, а только необходимое плюс небольшой запас. С таким подходом пока имеется свободное место на LVM имеется возможность сделать lvresize и resize2fs прямо на ходу не перегружая систему.
Диски для виртуалон же выделяю прямо в LVM.

Для виртуализации использую KVM.

Прежде чем выводить данные, книги, или пользователя - контроллер их получает из базы. Обычно в урле содержится id объекта. Типа books/65/edit. Вот эти 65 попадут в params[:id], а в контролере будет написано @book = Book.find(params[:id]).

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

Для вьюх application_helper.rb
Для общих функций application_controller.rb
Для данных модели.

1) Не стоит снимать офис, пока нет острейшей необходимости. Острейшая необходимость - вас 4+ разработчиков и вы должны бешено что-то вместе пилить. До этого момента офис вам не нужен. Чтобы сесть в офис и уж тем более нанимать сотрудников вам нужно быть ИП или юр. лицом. Чтобы их открыть чаще всего это занимает от двух недель и не меньше 20к рублей. Сам офис будете искать, ездить, реонтировать, докупать технику туда, решать проблемы с ним постоянно возникающие - итого уже тысяч 100 для того чтобы смочь начать работать в офисе.
2) офис почти гарантированно заставит вас нанимать сотрудников официально. Если коротко, найм сотрудника влечёт 40% налогов от его з/п.

p.s. Попробуйте trello, он настолько простой и приятный что хочется в нем постоянно сидеть и закрывать таски)

Не стоит смотреть на вопрос виртуализации через призму гипервизора, попробуйте Docker

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

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

Советую для напоминании и постановки задач другим сотрудникам todoist и trello.

Доброй ночи.

1. Касаемо CRM - попробуйте разные решения, на вкус как говорится. Рекомендую обратить внимание на Мегаплан, есть еще teamer.ru/about он проще, но в принципе норм. Для старта хватит бесплатной версии CRM, а там уж видно будет

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

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

3. Насчет бухгалтерии - попробуйте Эльбу или МоёДело, для начала бизнеса - отличные сервисы. Касаемо распределения обязанностей - идите от выгоды. Например, есть премиум-клиент, который Вам очень дорог - следите за этим проектом тщательно. Проекты проще и слабее можно передать сотруднику. Учитесь обращать внимание только на важные вещи, иначе загнетесь.

А вообще, кризис - время действия. Удачи Вам!

Мне нравится Webflow. Делаю в нем.

Какие атрибуты имеются в наличии у @autos(у модели) и какие вы хотите присвоить? Допустим:
@autos.map { |auto| auto.my_attr = my_example if auto.weight < 1000 }

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)