Смотрите, в нормальном мире есть средний и малый бизнес и команды из двух-трех человек.
И далее, чтобы ваш "специальный специалист" мог найти общий язык с инженером, то этот специалист либо должен быть сам инженером, либо инженер иметь немного знаний из области "специального специалиста".
Также я нигде не писал, что информацию должен собирать программист - у него своя работа, но чтобы эту информацию воспринять и воспринять максимально правильно - знания области, из которой приходит информация - дает огромную фору.
Пример. Ваша целевая аудитория: люди с ограниченным зрением (думается на таком примере понятнее всего будет, надеюсь)
Теперь расскажите, насколько разработчику должно быть всё равно и не его дело знать о целевой аудитории и о том как продукт будет продаваться (с технической точки зрения, а не маркетинговой). А то мне рисуется картина, как пандусы у нас делают, по которым если спустишься - еще больше инвалидом станешь. Не, ну а что, там же строители, не их забота думать о целевой аудитории и том, как их продукт использоваться будет.
И конечно же, если для вас программист - это тот кто код набирает, то вы безусловно правы в своих суждения. Однако для меня программист - это инженер, и его главный навык - умение анализировать и находить решение.
Вообще немного сбоку есть. Например, понимание кто твой покупатель дает возможность лучше продумать этап сборки и распространения приложения. А этот этап уже может быть технический и в том числе частью разработки.
Знание маркетинга является той сферой, которую должен понимать разработчик, если его ПО работает в сфере маркетинга. Аналогично тому, как разработчик в сфере медицины имеет знания из области медицины, в сфере банкинга - знания по банкингу и т.д.
В любом случае небольшие знания из смежной области еще никому не вредили и зачастую позволяют делать свою работу более качественно и эффективно.
Так в ресте у вас тоже нет поддержки DateTime - это просто строка. Вам же никто не запрещает с таким же успехом эту строку и по грпц передать. С другой стороны DateTime уже поддерживаятся, это называется "хорошо известные типы". По сути это структура на основе примитивов, а не выделенный тип.
Вы же можете воспользоваться автоматическим отражением и предоставить привычный rest внешним клиентам. Или можете написать отдельные сервисы, которые и будут трансформировать ответ под требования клиента. Например, когда с вами должны и по rest, и по soap, у кучи других форматов взаимодействовать. Это ни разу не проблема.
Не во всех случаях. Это зависит от должности, на которую претендует кандидат. Например, джун не выбирает стек технологий для разработки, следовательно его незнание и непонимание таких вещей не имеет большого значения — разберется в процессе работы и когда уровень поднимется, то будет знать.
Во первых. Взаимодействие чего с чем? Внутри системы или с конечным потребителем? Протоколы не обязаны быть идентичными и могут серьезно отличаться даже между компонентами внутри системы.
Во вторых. Вы смешали все в кучу. Между rest/mq/rpc нет или.
rest — архитектурный стиль, концепция
mq — компонент общения между процессами/потоками
rpc — удаленный вызов функций/процедур в заданном формате
т.е., банально,mq — это очередь сообщений, она не производит вычислений, а организует отложенную обработку для некоторого иного процесса, который из этой очереди будет читать сообщения и возможно, всего лишь возможно, отправлять в нее результат работы.
rpc же выполняет некоторую полезную нагрузку и выдает результат.
В третьих, что действительно важно, это ответить на вопросы:
— какой канал связи должен быть между вашими компонентами: двунаправленный или однонаправленный (и в каких именно направлениях, что тоже очень важно)
— формат сообщений (рядом, на мой взгляд, имеет смысл поставить и тип, а не выделять отдельно): json, xml, brotobuf и т.д.
В четвертых, есть асинхронный/синхронный и последовательный/параллельный вариант исполнения (их вариации).
Простой пример. Вы можете наружу выставить REST/JSON, который транскодируется в GRPC, который отправляет данные на обработку в RabbitMQ, из которого некоторое приложение читает данные по требованию удаленной информационной системы, обрабатывает и отдает ей результат через RPC/SOAP, которая связывается с исходной системой через предоставленный REST/JSON и передает результат своей обработки всем новым клиентам, через эту самую очередь.
«Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?»
Отвечая на ваш вопрос: я выберу ровно то из этого, что необходимо для решения задачи в соответствии с требованиями к системе.
Какие-то задачи в вакууме, которые на фронте чуть более чем никогда не применяются. Вообще не понятно, что с их помощью выясняется о кандидате: справится или нет?
Хорошими задачами являются те, которые максимально приближены к специфике работы, на которую человек устраивается. Ведь решать придется именно задачи проекта, а не вот этот треш, который в целом пишется один раз, помещается во вспомогательную библиотеку и забывается.
Некоторые теоретические вопросы также бессмысленны, например, такой как вопрос про регистрацию событий, при условии, что человек нанимается на уже действующий проект, в котором тот или иной подход укрепился.
Скорее всего писать «обертку» для каждого языка придется, ибо не все языки имеют одинаковые возможности и средства написания. Т.е. сперва привести к общему знаменателю.
Конечно можно написать и интерпретатор для каждого языка, но сути это не меняет. Производительности таким образом теоретически можно добитться большей, но сложность реализации на порядок возрастет, на мой взгляд.
Довольно малоприменимый подход.
Получится своего рода код, который генерируют визуальные редакторы html, с поправкой на то, что языков программирования много и они намного сложнее и богаче в синтаксисе и возможностях. О качестве генерируемого кода можно даже не говорить.
Такой подход имеет право на существование в очень ограниченном списке задач. Но зачастую это проще и лучше обойти встроенным рантаймом иного языка. Например, встраивание lua в язык более низкого уровня.
Для начала убедитесь, что все необходимые технологии у вас присутствуют в системе. Во вторых, есть большая вероятность, что проброс видеокарт реализован более-менее для nvidia, ati, maxtor, поэтому для начала попробуйте пробросить вторую видеокарту, а не intel. И в третьих, проверьте, на какой видеокарте работает ваша система, т.к. карта для проброса должна быть «отключена».
Если речь идет об одной видеокарте, которую предполагается использовать между хостом и гостем или гостями, то теоретически такое переключение возможно.
Для реализации подобного следует обратить внимание на технологию SPICE. Она позволит на хост-машине под управлением Linux эмулировать видеокарту, отключив физическую. После вы сможете пробросить ее в гостя.
Одновременное использование видеокарты невозможно, поэтому потребуется извлечь ее из гостя тем или иным способ.
Далее, если вы захотите вернуть видеокарту в хост-систему или перебросить в другой хост, то действовать вы будете вслепую, поэтому у вас есть следующие пути решения:
— создать демона для прослушки процесса и выполнения операций включения устройства обратно в хост или запуска другого хоста с видеокартой в автоматическом неконтролируемом режиме.
— удаленное администрирование по любому доступному протоколу (например, ssh, http, vnc) хост-машины с другой машины с целью выполнения указанных ранее действий.
Дайте угадаю, это восьмой по счету?)
Смотрите, в нормальном мире есть средний и малый бизнес и команды из двух-трех человек.
И далее, чтобы ваш "специальный специалист" мог найти общий язык с инженером, то этот специалист либо должен быть сам инженером, либо инженер иметь немного знаний из области "специального специалиста".
Также я нигде не писал, что информацию должен собирать программист - у него своя работа, но чтобы эту информацию воспринять и воспринять максимально правильно - знания области, из которой приходит информация - дает огромную фору.
Пример. Ваша целевая аудитория: люди с ограниченным зрением (думается на таком примере понятнее всего будет, надеюсь)
Теперь расскажите, насколько разработчику должно быть всё равно и не его дело знать о целевой аудитории и о том как продукт будет продаваться (с технической точки зрения, а не маркетинговой).
А то мне рисуется картина, как пандусы у нас делают, по которым если спустишься - еще больше инвалидом станешь. Не, ну а что, там же строители, не их забота думать о целевой аудитории и том, как их продукт использоваться будет.
И конечно же, если для вас программист - это тот кто код набирает, то вы безусловно правы в своих суждения. Однако для меня программист - это инженер, и его главный навык - умение анализировать и находить решение.
Вообще немного сбоку есть. Например, понимание кто твой покупатель дает возможность лучше продумать этап сборки и распространения приложения. А этот этап уже может быть технический и в том числе частью разработки.
Знание маркетинга является той сферой, которую должен понимать разработчик, если его ПО работает в сфере маркетинга. Аналогично тому, как разработчик в сфере медицины имеет знания из области медицины, в сфере банкинга - знания по банкингу и т.д.
В любом случае небольшие знания из смежной области еще никому не вредили и зачастую позволяют делать свою работу более качественно и эффективно.
Так-то оно так. Только одно но:
в монолите за связностью должен следить кто-то (ревьюер, например), никакие паттерны не дают гарантий и безопасности
в микросервисах вы этого можете добиться ограничением на видимость сервисов и разделением на слои, т.е. архитектурно
Отсюда вывод: микросервисы позволяют эффективнее контролировать уровень связности.
Так в ресте у вас тоже нет поддержки DateTime - это просто строка.
Вам же никто не запрещает с таким же успехом эту строку и по грпц передать.
С другой стороны DateTime уже поддерживаятся, это называется "хорошо известные типы". По сути это структура на основе примитивов, а не выделенный тип.
Вы же можете воспользоваться автоматическим отражением и предоставить привычный rest внешним клиентам.
Или можете написать отдельные сервисы, которые и будут трансформировать ответ под требования клиента. Например, когда с вами должны и по rest, и по soap, у кучи других форматов взаимодействовать.
Это ни разу не проблема.
Linux Astra — стабильность и скрепы.
Во первых. Взаимодействие чего с чем? Внутри системы или с конечным потребителем? Протоколы не обязаны быть идентичными и могут серьезно отличаться даже между компонентами внутри системы.
Во вторых. Вы смешали все в кучу. Между rest/mq/rpc нет или.
rest — архитектурный стиль, концепция
mq — компонент общения между процессами/потоками
rpc — удаленный вызов функций/процедур в заданном формате
т.е., банально,mq — это очередь сообщений, она не производит вычислений, а организует отложенную обработку для некоторого иного процесса, который из этой очереди будет читать сообщения и возможно, всего лишь возможно, отправлять в нее результат работы.
rpc же выполняет некоторую полезную нагрузку и выдает результат.
В третьих, что действительно важно, это ответить на вопросы:
— какой канал связи должен быть между вашими компонентами: двунаправленный или однонаправленный (и в каких именно направлениях, что тоже очень важно)
— формат сообщений (рядом, на мой взгляд, имеет смысл поставить и тип, а не выделять отдельно): json, xml, brotobuf и т.д.
В четвертых, есть асинхронный/синхронный и последовательный/параллельный вариант исполнения (их вариации).
Простой пример. Вы можете наружу выставить REST/JSON, который транскодируется в GRPC, который отправляет данные на обработку в RabbitMQ, из которого некоторое приложение читает данные по требованию удаленной информационной системы, обрабатывает и отдает ей результат через RPC/SOAP, которая связывается с исходной системой через предоставленный REST/JSON и передает результат своей обработки всем новым клиентам, через эту самую очередь.
«Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?»
Отвечая на ваш вопрос: я выберу ровно то из этого, что необходимо для решения задачи в соответствии с требованиями к системе.
Хорошими задачами являются те, которые максимально приближены к специфике работы, на которую человек устраивается. Ведь решать придется именно задачи проекта, а не вот этот треш, который в целом пишется один раз, помещается во вспомогательную библиотеку и забывается.
Некоторые теоретические вопросы также бессмысленны, например, такой как вопрос про регистрацию событий, при условии, что человек нанимается на уже действующий проект, в котором тот или иной подход укрепился.
Конечно можно написать и интерпретатор для каждого языка, но сути это не меняет. Производительности таким образом теоретически можно добитться большей, но сложность реализации на порядок возрастет, на мой взгляд.
Довольно малоприменимый подход.
Получится своего рода код, который генерируют визуальные редакторы html, с поправкой на то, что языков программирования много и они намного сложнее и богаче в синтаксисе и возможностях. О качестве генерируемого кода можно даже не говорить.
Такой подход имеет право на существование в очень ограниченном списке задач. Но зачастую это проще и лучше обойти встроенным рантаймом иного языка. Например, встраивание lua в язык более низкого уровня.
Для реализации подобного следует обратить внимание на технологию SPICE. Она позволит на хост-машине под управлением Linux эмулировать видеокарту, отключив физическую. После вы сможете пробросить ее в гостя.
Одновременное использование видеокарты невозможно, поэтому потребуется извлечь ее из гостя тем или иным способ.
Далее, если вы захотите вернуть видеокарту в хост-систему или перебросить в другой хост, то действовать вы будете вслепую, поэтому у вас есть следующие пути решения:
— создать демона для прослушки процесса и выполнения операций включения устройства обратно в хост или запуска другого хоста с видеокартой в автоматическом неконтролируемом режиме.
— удаленное администрирование по любому доступному протоколу (например, ssh, http, vnc) хост-машины с другой машины с целью выполнения указанных ранее действий.
Обозначенный вариант выбран из соображений совместимости при тестировании. Исправил на более предпочтительный.