Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.

Взявшись исследовать некоторые непонятки с производительностью в Chrome, я обнаружил, что Microsoft распараллелили обнуление памяти, и иногда работа из-за этого сильно замедляется. В Windows 11 такое замедление можно частично побороть, но в последних версиях Windows Server — где этот фактор наиболее важен — баг живее всех живых.

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

Окей – давайте перейдем к деталям.

За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.

Всякий раз дискуссия выходит к одним и тем же ответам:

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

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

Если этот первый абзац вселил в вас надежду, то второй ее обломает: в этой статье я не собираюсь углубленно анализировать самые низкоуровневые аспекты конкурентной производительности. Мы попросту очень многого не знаем о том, как выполняются атомарные инструкции и барьеры памяти, и эту тему мы пока отложим.

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

Часто ловлю себя на мысли, что рассуждаю именно в таких категориях, когда мне нужна высокопроизводительная конкурентность: каков наилучший уровень, который я реально могу достичь при решении конкретной задачи? Держать в уме эти уровни полезно и на этапе первичного проектирования (иногда небольшое изменение требований или высокоуровневого дизайна позволяют вам выйти на более выгодный уровень), а также при оценке уже существующих систем (для еще более точного понимания имеющейся производительности и выстраивания пути наименьшего сопротивления, ведущего к улучшениям).

Как вы могли заметить, я давно работаю с процессором STM32 ARM при помощи Mbed. Были времена, когда Mbed был весьма прост, но многое изменилось с тех пор, как он превратился в Mbed OS. К сожалению, это означает, что многие примеры и библиотеки, которые вы могли бы найти, с относительно новой системой работать не будут.

Мне нужен был поворотный энкодер — и я вытянул дешевый экземпляр из одного набора «49 плат для Arduino», какие продаются повсюду. Уверен, это не самый филигранный поворотный шифратор из имеющихся в природе, но для поставленной задачи его должно было хватить. К сожалению, в Mbed OS нет драйвера для такого датчика, а первые несколько сторонних библиотек, которые я нашел, либо работали по принципу опроса, либо не компилировались под последнюю версию Mbed. Разумеется, для чтения поворотного энкодера никакой магии не требуется. Но насколько сложно самостоятельно написать для него код? В самом деле, довольно сложно. Подумал, поделюсь моим кодом и расскажу, как к этому коду пришел.

Много воды утекло с тех пор, как я в последний раз участвовал в собеседовании по программированию как соискатель. Но до сих пор помню особенно полюбившийся мне вопрос с такого собеседования. Дело было в MemSQL, году так в 2013. (Они даже успели переименоваться, поэтому, полагаю, конкретно этот вопрос они на собеседовании уже не задают. Не чувствую вины за то, что выдаю его. Это отличная история, которая также кажется мне поучительной; просто раньше я о ней никогда не писал).

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

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

А вы знали, что бывает такая атака на компилятор через бэкдор, защититься от которой невозможно? В этом посте я покажу вам, как реализовать такую атаку менее чем в 100 строках кода. Кен Томпсон, создатель операционной системы Unix, рассказывал о такой атаке еще в 1984 году в своей лекции по поводу присуждения Премии Тьюринга. Такая атака по-настоящему опасна и сегодня, причем, не известно решений, которые обеспечивали бы полную неуязвимость от нее. Вирус  XcodeGhost, открытый в 2015 году, проводит атаку через бэкдор по методу, предложенному именно Томпсоном. Я покажу здесь атаку Томпсона на языке   C++, но этот пример легко адаптировать для любого другого языка. Дочитав эту статью, вы крепко задумаетесь, а осталось ли у вас вообще какое-то доверие компилятору.

Представляю, сколь скептически вы можете отнестись к моим заявлениям – и, возможно, у вас уже возникли вопросы. Ниже приведу примерный диалог, который мог бы состояться у нас с вами, снять некоторые ваши сомнения и помочь вам почувствовать суть атаки Томпсона.

Встречайте, вот и Go 1.18, а с ней – первый релиз долгожданной реализации дженериков, наконец-то готовых к реальному использованию в продакшене. Дженерики – это весьма востребованная возможность, давно вызывающая жаркие споры в сообществе Go. С одной стороны, самые голосистые беспокоятся по поводу сложности, которую привносят дженерики. Их страшит неизбежная эволюция Go, которая доведет его либо до многословия как в энтерпрайз-версии Java, со своими обобщенными фабриками, либо, самое страшное, превратит Go в вырожденный HaskellScript, где if-ы придется заменить монадами. Положа руку на сердце, оба этих опасения могут быть преувеличенными. С другой стороны, поборники дженериков считают, что дженерики критически важны для масштабного внедрения чистого кода, пригодного для многоразового использования.

Автор этой статьи не принимает ни одну из сторон в данных дебатах и не дает рекомендаций, где и в каких случаях использовать дженерики в Go. Напротив, эта статья призвана осветить запутанный случай с дженериками в Go с третьей стороны: с точки зрения системных программистов, которые воодушевлены не дженериками как таковыми, а мономорфизацией и тем, как она может сказаться на производительности. Нас таких десятки. Десятки! И мы все имеем изъявить некоторое серьезное разочарование.

Познакомьтесь с 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 году, когда компьютеры-мейнфреймы еще занимали целые залы и работали на электронно-лучевых трубках, Фрэнк Розенблатт из Корнельского университета, исходя из знаний о том, как устроены связи между нейронами в мозге, спроектировал первую нейронную сеть, которую прозорливо описал как «устройство для распознавания образов». Но амбиции Розенблатта сильно опережали его время – и он об этом знал. Даже в своей инаугурационной статье он был вынужден признать, с каким волчьим аппетитом нейронная сеть жрет вычислительные ресурсы, сетуя на то, что «по мере того, как количество связей в сети растет… нагрузка на традиционный цифровой компьютер вскоре становится чрезмерной».  

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

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