Дэвид Хэррон, автор материала, перевод которого мы публикуем сегодня, задался следующим вопросом: «Должен ли человек, работавший более 10 лет в Sun Microsystems, в команде Java SE, до последнего вздоха думать лишь о байт-коде Java и создавать экземпляры абстрактных интерфейсов?». Он задавал этот вопрос применительно к себе, и для него платформа Node.js, после Java, оказалась подобна глотку свежего воздуха. Дэвид говорит, что когда он был уволен из Sun в январе 2009 года (прямо перед поглощением этой компании Oracle), он узнал о Node.js. Эта технология его зацепила. Что значит «зацепила»? С 2010-го года он много писал о программировании для Node.js. А именно, написал несколько книг, в том числе — «Node.js Web Development», четвёртое издание которой вышло в этом году. Он подготовил множество небольших материалов о Node.js, опубликованных в интернете. Фактически, он уделил очень много времени и сил, рассказывая о платформе Node.js и о возможностях JavaScript. Почему того, кто раньше занимался исключительно Java, так увлекли Node.js и JavaScript?
Статья про то, что делать тем, кто хочет переехать работать в США. Я предполагаю инженерные позиции, на которые проще всего получить визы, но, возможно, статья окажется полезна и другим специалистам.
За последнее время появилось 
Как только в компании появляется хотя бы две информационных системы, которым необходимо обмениваться данными, возникает вопрос, как организовать их взаимодействие. Вариантов множество: файловый обмен, линки между базами данных, web или rest сервисы, различные системы обмена сообщениями, устаревшие RPC и CORBA, новомодный gRPC и т.д. Выбор зависит от предпочтений участников проекта и от возможностей систем (архитектура системы, используемая платформа, наличие готового API и пр.). Предположим, выбрали какой-то способ обмена, системы начали взаимодействовать, все хорошо. Но потом возникает третья система, с которой тоже надо интегрироваться, потом четвертая и т.д. Нужно опять садиться и выбирать способ обмена, и не факт что удастся ограничиться уже используемыми технологиями (где-то это продиктовано ограничениями новых систем, где-то разработчик настоял на другой технологии или захотел попробовать что-то новое). С ростом количества систем растет количество и сложность взаимодействий между ними, растет количество используемых технологий. В итоге вся интеграционная архитектура компании начинает напоминать запутанный клубок разноцветных ниток, как-то связывающих системы компании, который все сложнее распутывать при разборе ошибок и доработках. Рано или поздно начинают приходить мысли о создании единой интеграционной среды, которая прозрачно и расширяемо свяжет все системы воедино.
