Познакомьтесь с WebAssembly на примере этого простого туториала, требующего лишь самых общих знаний в веб-разработке. Весь инструментарий, который понадобится вам, чтобы составить впечатление о Wasm на основе готовых к запуску примеров кода – это редактор кода, любой современный браузер, а также контейнер Docker с наборами инструментов для C и Rust – он прилагается к статье.

На момент написания статьи WebAssembly в ходу уже три года. Она работает во всех современных браузерах, а некоторые компании уже даже решились использовать ее в продакшене  (Figma, наше почтение). За этим продуктом стоит мощная интеллектуальная поддержка: Mozilla, Microsoft, Google, Apple, Intel, Red Hat — в разработке участвовал инженерный цвет этих и других компаний. Web Assembly повсеместно считается Следующим Большим Прпорывом в веб-технологиях, но широкая аудитория фронтенд-разработчиков не спешит на нее переходить. Все мы знаем HTML, CSS и JavaScript, тех трех китов, на которых зиждется Веб, и для пересмотра такой парадигмы трех лет мало. Особенно, если краткий поиск в Google дает нечто подобное:

Более пяти лет назад мы запустили платформу Slack, предоставив разработчикам легкий способ создавать приложения в Slack и публиковать их в нашей App Directory. Сегодня миллионы пользователей переносят свою работу в Slack, и их приложения, создаваемые более чем 885 000 активными разработчиками, действующими на этой платформе – залог дальнейшего улучшения совместной работы в Slack. 

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

Если API спроектированы хорошо, разработчики их полюбят и могут стать самыми креативными инноваторами, пользующимися вашими API. Они будут сильно в них вкладываться, а иногда даже могут стать евангелистами ваших API. Мы также ценим время разработчиков и те ресурсы, которыми они могут рискнуть, имея дело с нашей платформой. Если API плохо спроектировать, то его примут холодно, и он даже может вызывать фрустрацию. Плохие API превращаются для компании в обременение.

Я не утверждаю, что Slack всегда проектировал API хорошо. У нас были ошибки, и платформа определенно могла бы быть удобнее для разработчиков. Но мы признаем эти ошибки и определяем, как их исправить – иногда даже дополнительно упирая на то, чтобы придерживаться какого-то выбора, сделанного в прошлом, тогда как сейчас мы бы с этим выбором не согласились — и в целом можем улучшить для разработчика опыт работы с платформой.

Давным-давно, когда мир был юн, и компьютеры в нем были в новинку, я учился по программе на младшего сотрудника (Associate Degree) по обработке данных – программ по «компьютерным наукам» тогда не было – и в рамках этой программы преподавались бухгалтерское дело, математика, статистика, а также три языка программирования: ассемблер IBM/360, FORTRAN и COBOL. К 80-м студентам уже рассказывали, что COBOL мертвый язык, и никто его больше не изучают.

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

Quarkus – это стек Java, приспособленный для работы с OpenJDK HotSpot (или OpenJ9 на zSeries) и GraalVM, собранный из оптимизированных библиотек и стандартов Java. Он хорошо подходит для создания сильно масштабируемых приложений, при этом значительно скромнее использует ресурсы CPU и памяти, нежели другие фреймворки Java. Quarkus может работать с традиционными веб-приложениями, бессерверными приложениями и даже с функциями, предоставляемыми как услуга.

Существует много документированных случаев, в которых организации переносили свои приложения на Quarkus. В этой статье рассмотрим один из таких миграционных путей: со Spring Boot на Quarkus. Есть в этом своя магия и свое безумие. Магия – это когда миграция осуществляется как по мановению руки, и ни одной строки кода при этом менять не приходится. Безумие – в том, чтобы попытаться осознать, как все это делается.

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

Хотя, славные дни глубокого обучения начались сравнительно недавно, зародилась эта парадигма много лет назад. В 1958 году, когда компьютеры-мейнфреймы еще занимали целые залы и работали на электронно-лучевых трубках, Фрэнк Розенблатт из Корнельского университета, исходя из знаний о том, как устроены связи между нейронами в мозге, спроектировал первую нейронную сеть, которую прозорливо описал как «устройство для распознавания образов». Но амбиции Розенблатта сильно опережали его время – и он об этом знал. Даже в своей инаугурационной статье он был вынужден признать, с каким волчьим аппетитом нейронная сеть жрет вычислительные ресурсы, сетуя на то, что «по мере того, как количество связей в сети растет… нагрузка на традиционный цифровой компьютер вскоре становится чрезмерной».  

Концепция микро-фронтенда – это микросервисный подход при разработке клиентской части. В настоящее время есть тенденция создавать мощное и функционально насыщенное веб-приложение, расположенное поверх микросервисной архитектуры. Со временем микро-фронтендовая архитектура становится частью приложения, зачастую ее разрабатывает отдельная команда. Эта архитектура растет, ее становится сложно поддерживать. Возникает так называемый «фронтендовый монолит». Для решения этой проблемы была сформулирована концепция микро-фронтендов.

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