Apache Kafka является мощным инструментом для обработки и передачи потоковых данных в реальном времени, который находит широкое применение в различных индустриях для обработки огромных объемов данных с низкой задержкой. В центре этой платформы лежит способность эффективно распределять данные между множеством производителей (producers) и потребителей (consumers), при этом поддерживая высокую пропускную способность и масштабируемость. Однако, с увеличением количества и разнообразия данных, возникает необходимость в управлении структурами этих данных, что обеспечивает Schema Registry. Этот компонент является критически важным для поддержания согласованности данных в Kafka, поскольку он управляет схемами сообщений и обеспечивает совместимость между различными версиями схем, что позволяет системам бесперебойно обмениваться данными даже при изменении структуры сообщений.

Про закулисье async/await написано предостаточно. Как правило, авторы декомпилируют IL-код, смотрят на IAsyncStateMachine и объясняют, вот дескать какое преобразование случилось с нашим исходным кодом. Из бесконечно-длинной прошлогодней статьи Стивена Тауба можно узнать мельчайшие детали реализации. Короче, всё давно рассказано. Зачем ещё одна статья?

Я приглашаю читателя пройти со мной обратным путём. Вместо изучения декомпилированного кода мы поставим себя на место дизайнеров языка C# и шаг за шагом превратим async/await в код, который почти идентичен тому, что синтезирует Roslyn.

Я более десяти лет жизни писал код в одной российской компании и активно собеседовал-нанимал людей. За это время успел пообщался с четырьмя сотнями кандидатов. На моих интервью было все – от алгоритмических задач до разговоров о «жизни». Но форма вторична – я рассматриваю интервью как инструмент для проверки совпадения с кандидатом по культуре. И все эти десять лет в моей компании менялся подход к оценке программиста на интервью и менялась культура.

Любое собеседование адекватно компании, которая его проводит. Даже если от собеседования «бомбит» и «подгорает» - проблема в кандидате, а не в компании. И как кандидат я очень рад такому простому фильтру для отбраковки не подходящих мне компаний. Но и компания тоже преследует свои цели – сохранение и изменение своей культуры за счет найма «правильных» людей. Проверка технических навыков тоже важна, но важнее нанимать людей, с которыми можно работать.

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

Я обучил небольшой (порядка 10 миллионов параметров) трансформер по превосходному туториалу Let’s build GPT: from scratch, in code, spelled out Андрея Карпати. После того, как он заработал, я захотел максимально глубоко понять, как он устроен внутри и как создаёт свои результаты.

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

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

Если вы знакомы с трансформерами и хотите сразу узнать вывод, то он таков: каждый блок трансформера (содержащий слой многоголового внимания и сеть с прямой связью) изучает веса, связывающие конкретный промт с классом строк, найденных в обучающем корпусе. Распределение токенов, соответствующее этим строкам в обучающем корпусе, и есть приблизительно то, что блок выводит как прогноз для следующего токена. Каждый блок может ассоциировать один и тот же промт со своим классом строк обучающего корпуса, что приводит к другому распределению следующих токенов, а значит, и к другим прогнозам. Окончательный результат работы трансформера — это линейное сочетание прогнозов каждого блока.

Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня расскажем о
том, как мы помогали клиенту справиться с нехваткой data-инженеров и увеличить темпы найма, дообучая кандидатов навыкам работы с Apache Spark на реальных задачах компании.

Как создать АПИ для умных? Такое апи, чтобы создание клиента для него было не скучным механическим процессом, а настоящим приключением с элементами детектива, хоррора и мистики? Такое апи, о котором пользователи будут взахлёб рассказываете коллегам? Апи взрывающее мозг, заставляющее смеяться, кричать и плакать? Я постарался отобрать лучшие практики, с которыми пришлось столкнуться.

Приветствую тебя, Хабр! Наверняка вы заметили, что тема стилизации фотографий под различные художественные стили активно обсуждается в этих ваших интернетах. Читая все эти популярные статьи, вы можете подумать, что под капотом этих приложений творится магия, и нейронная сеть действительно фантазирует и перерисовывает изображение с нуля. Так уж получилось, что наша команда столкнулась с подобной задачей: в рамках внутрикорпоративного хакатона мы сделали стилизацию видео, т.к. приложение для фоточек уже было. В этом посте мы с вами разберемся, как это сеть "перерисовывает" изображения, и разберем статьи, благодаря которым это стало возможно. Рекомендую ознакомиться с прошлым постом перед прочтением этого материала и вообще с основами сверточных нейронных сетей. Вас ждет немного формул, немного кода (примеры я буду приводить на Theano и Lasagne), а также много картинок. Этот пост построен в хронологическом порядке появления статей и, соответственно, самих идей. Иногда я буду его разбавлять нашим недавним опытом. Вот вам мальчик из ада для привлечения внимания.

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

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Этой публикацией я открываю серию переводов раздела "Продвинутые руководства" (Advanced Guides) официальной документации библиотеки React.js.

JSX — подробности

Фундаментально, JSX является синтаксическим сахаром для функции React.createElement(component, props, ...children).