Robur

Dokku

Знак доллара - распространённое обозначение для команд, которые предлагается выполнять в терминале.
Попробуйте ввести команду без знака доллара:
node -v

Нужно просто качать через поток:

request('https://google.com/doodle.png').pipe(fs.createWriteStream('doodle.png'))

По своему опыту могу сказать, что при переходе на удалённую работу(10 лет) из офиса(7 лет) мое развитие и производительность увеличились в разы.
1) В офисе ты можешь ничего не делать, а просто показывать лицо и с умным видом рассуждать о полиморфизме. На удалёнке тебя никто не видит, а видят только твои результаты- это обязывает шевелиться быстрее и только по делу.
2) В офисе ты слишком призязан к месту и организации, зачастую тебя берут на какой нибудь вырост, а в последствии могут дать поддерживать старую программку на фортране или на бейсике, или сунут печатать документы и рисовать рисунки и т.п. и ничего не скажешь. На удалёнке тебе легко поменять проект, если закончились твои задачи, ты смотришь на работу не как на что-то вечное и стабильное, а как на проект, на который тебя взяли из-за определенных скиллов, под конкретные задачи и от тебя ждут конкретные результаты.
3) В офисе тебя отвлекают разговорами, совещаниями, теннисом и т.п., купят тот стул и комп, который купят, а не который ты хочешь, на удаленке у тебя отдельная комната - как минимум, кресло и мощный игровой ноут (легко поднимающий виртуальные машины или докер-контейнеры), которые ты сам себе выбрал.
4) Да, экономия на времени, дороге, спорте, месте жительства само собой.
5) В офисе обучение предлагается/навязывается, но так как вроде положение там стабильное то и оно не так и хочется прям учится, на удалёнке ты понимаешь что это твое конкурентное преимущество и без обучения никак, ты ищешь, анализируешь, что в тренде и больше востребовано, и подгоняешь свои скилы под общие требования рынка, а не конкретной организации.
6) в офисе не особо поднимают тебе зарплаты типа никуда не денешься, а попросить неудобно, на удалёнке ты с каждым новым проектом пересматриваешь свою цену и приобретенный опыт. (ну хотя здесь немного вру, в офисе повышали нормально, после удачных релизов )

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

И да... в офисе, мне сказали сразу, что тебя наняли решать задачи, а не отвлекать коллег, так что на то, что там кто-то делиться опытом, мне наверно не повезло.

Развитие специалиста определяется решаемыми им задачами, а не местонахождением опоры под его задницей.

Присоединяюсь к мнению выше, что по коду можно весьма примерно оценить.
И, наверное, чем серьезнее разработчик, тем сложнее оценить только по коду.
Имхо, очень многое зависит от конкретного компонента и требований к нему.
Пойду от очевидного:
- чистота кода,
- знание и использование в нужных местах возможностей ES6 (стрелочные, интерполяция, спред, деструктуризация),
- умение решать промежуточные микрозадачи с минимумом кода, элегантно, легкочитаемо,
- глядя на компонент, как ни парадоксально, можно сделать предположение, программист ещё пишет классами, или перешел на функциональные компоненты, но это не точно)),
- в связи с предыдущим пунктом можно оценить понимание и использование жизненного цикла или хуков,
- подход к хранению данных: стейт, контекст, ридакс etc,
- если Redax, например, то что осталось в компоненте, что пошло в action, является ли reducer чистой функцией,
- JS или TypsScript...

Я когда начинал писать не думал, что такой список получится... Выходит, много можно оценить!)

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

Я бы на вашем месте просто делал бы реальные тестовые задания с hh.ru, Это позволит вам понять где вы реально находитесь и быстро прокачаться. Когда тестовое задание будет сделано, его можно будет выложить в качестве портфолио.

два адекватных человека всегда способны договориться.
прост отведите его в сторонку и спросите: "wtf?".
услышите убедительные доводы - дело в вас.
не услышите - либо меняйте работу, либо вы не в адеквате.

Исторически предполагалось что будут одинаково востребованы www.example.com, ftp.example.com, smtp.example.com и эти субдомены сделают обращения к ним более понятным для ученых которых работают с сетью (а ведь кому, кроме ученых может понадобиться интернет, правда?).
В наше время лучше предполагать введение адреса с www., просто добавить переадресацию на без-www, потому что во первых некоторые пользователи могут на автомате его добавлять, во вторых как дополнительный запас для распределения нагрузки: https://www.yes-www.org/why-use-www/

1 кейс.
У вас есть запросы на которые нужно отвечать быстро (текущее состояние) и какой-то сервис с отчетами. Когда пользователи запрашивают большой отчет скорость ответа текущего состояния начинает проседать. Тогда вы делаете отдельный сервис для отчетов, выносите его в отдельное приложение и на отдельную виртуалку. Таким образом вы изолируете потребляемые ресурсы и устраняете влияние сервисов друг на друга. Плюс получаете возможность отдельно масштабировать сервис отчетов во времена наибольшей нагрузки.

2 кейс.
У вас есть сервис авторизации для которого нужно учесть множество разных требований и стандартов по безопасности. Вы привлекаете отдельную команду для его разработки с определенными навыками. В этом случае вы изолируете ресурс "навыки разработки безопасных сервисов" чтобы команда не тратила свое время на другие фичи.

3 кейс.
Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.

Итог.
Разделение на несколько приложений - это либо логическое разделение, когда приложения делают разные и несвязанные вещи. В этом случае удобно думать о разных задачах как о разных приложениях. Отдельно их разрабатывать, деплоить и т.д.
Либо это управление вычислительными мощностями. Когда разные части системы требуют разделения ресурсов, нелинейного масштабирования или имеют совсем разный режим работы (например АПИ для загрузки фоток и асинхронный воркер который делает превьюшки для этих фоток)
Либо это управление на уровне человеческих ресурсов, когда приходится вводить в разработку несколько команд.

В общем нашел решение, может кому пригодится друзья

Нужно использовать директивы
К примеру мы не хотим в одном из условий подгружать поле description
Значит создаем директиву к данному полю с типом Boolean и далее при запросе в разделе variables указываем в булевом значении нужно это поле или нет(true/false)

query getProducts($withDescription: Boolean!){
 products{
  id
  name
  price
  description @include(if: $withDescription)
  images
  ...
 }
}

....

variables: {
 withDescription: false
}