В основе Apache Kafka находится лог — простая структура данных, которая использует последовательные операции, работающие в симбиозе с оборудованием. Эффективное использование дискового буфера и кэша процессора, prefetch, передача данных zero-copy и много других радостей — все это благодаря построенной на логе структуре, которая славится своей эффективностью и пропускной способностью. Обычно эти преимущества, а еще базовая реализация в виде лога коммитов, — первое, что люди узнают о Kafka.

Код самого лога составляет относительно малую часть всей системы. Гораздо больше занимает код, который отвечает за организацию партиций (т. е. логов) на множестве брокеров в кластере — назначает лидеров, обрабатывает сбои и т. д. Этот код и делает Kafka надежной распределенной системой.

Раньше важной частью работы распределенного кода был Apache ZooKeeper. Он хранил самые важные метаданные системы: где находятся партиции, кто из реплик лидер и т. д.

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

В ЭТОЙ СТАТЬЕ НЕТ ИНФОРМАЦИИ О ПУБЛИКАЦИИ НАТИВНЫХ ТАРГЕТОВ. И тем не менее, надеюсь, информация в статье будет вам полезна.

В этом нашем айти я торчу всю сознательную жизнь — и это слишком мало.
Трясина IT глубока и обширна; когда-то давно я мечтал испить эту чашу до дна, но скоро выяснилось, что не получится быть крутым спецом сразу во всём. Зато у меня получилось вывести принципы и правила, применимые в любой разработке, да и вне её, пожалуй, тоже. Они всякие, конкретные и абстрактные, выведенные из своих ошибок или чужих, новые, или миллион раз повторенные, но всё равно актуальные.

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

Не бойся ошибаться, но работай над ошибками

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

Первая парадигма, которую мне втолковали на моей первой серьёзной работе — косячат все. Как бы ответственно и серьёзно ты не подходил к выполняемой задаче, каким бы профессионалом ты не был — рано или поздно ты ошибёшься. Опыт и знания только уменьшают шанс получения ошибки, но она точно случится.

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

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

Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.

Продолжаем беседовать с разработчиками экосистемы сервисов Serverless. В начале нашего путешествия Глеб Борисов описал ситуацию с Yandex Cloud Function, затем Данил Ошеров погрузил нас в мир протокола S3 и сервиса Object Storage, а сегодня Андрей Фомичев поделится подробностями о NewSQL. 

Благодаря современным облакам можно накапливать большие объёмы информации, что в перспективе позволит легко прогнозировать потребление ресурсов (то есть использовать предсказательную аналитику). В новых условиях мы ожидаем, что СУБД и сервисы, их сопровождающие, подскажут нам: сейчас необходимо повысить производительность, а для этого — увеличить платёж. Или: игнорируйте запросы, которые приходят, чтобы спала мусорная нагрузка. Кажется, такого раньше не было...

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

Я начал заниматься базой знаний, будучи зеленым джуном, так что все описанные в посте рекомендации применимы даже в том случае, если у вас нет административных или финансовых ресурсов. Иными словами, советов в духе "просто заставьте всех писать и штрафуйте непослушных" тут не будет, мы пойдем другим путем.

Меня зовут Илона, я Senior Experience Designer в EPAM. Я проектирую сложные интерфейсы для зарубежных заказчиков, выступаю с докладами, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.

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

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

В любом случае, вот краткое изложение некоторых из кардинальных "грехов", которые я совершил при использовании docker-compose.

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

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

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

База данных становится слишком большой или старой? Ее тяжело обслуживать? Что ж, надеюсь, я смогу немного помочь. Текст, который вы собираетесь прочитать, содержит реальный опыт масштабирования монолитной базы данных, лежащей в основе одного из сайтов Топ-250 (согласно alexa.com). На момент написания этой статьи chess.com занимал 215 место в мире по популярности. Ежедневно к нам заглядывали более 4 млн уникальных пользователей, а наши MySQL-базы обрабатывали в общей сложности более 7 млрд запросов. Год назад сайт ежедневно посещали 1 млн уникальных пользователей; в марте прошлого года их число увеличилось до 1,3 млн; сегодня более 4 млн человек заходят на chess.com ежедневно, а число сыгранных партий превышает 8 млн. Я, конечно, знаю, что это не сопоставимо с самыми крупными игроками на рынке, однако наш опыт все же может помочь в такой сложной задаче, как «исправление» монолитной базы данных и ее вывод на новый уровень производительности.

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

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Сантош Вемпала и Ричард Пенг из Технологического института Джорджии, придумали новый, более быстрый способ решения некоторых систем линейных уравнений, «рабочую лошадку современных вычислений». Используя случайность, новый алгоритм предлагает принципиально новый — и более быстрый — способ выполнения одного из самых простых вычислений в математике и информатике.

Одна из самых простых и базовых концепций в программировании игр — это идея игрового цикла. При запуске вашего проекта происходит его инициализация, после чего игровой цикл действует до тех пор, пока игрок хочет продолжать игру: каждый кадр вы обрабатываете ввод, обновляете состояние игрового мира и выводите результат на экран. Когда игрок закрывает игру, происходит очистка данных, и на этом все заканчивается. 

Но когда вы пишете игровой код на Unreal Engine, вы не имеете дело с игровым циклом напрямую. Вы не начинаете работать сразу с основной функцией — сначала вы определяете подкласс GameMode и переопределяете функцию под названием InitGame. Или пишете одноразовые классы Actor и Component и переопределяете их функции BeginPlay или Tick для добавления собственной логики. Это самый минимум того, что вам нужно сделать: обо всем остальном движок позаботится за вас.

Unreal Engine также предлагает вам как программисту мощный и гибкий инструментарий: конечно, он имеет открытый исходный код, но также возможно и расширение несколькими другими способами. Даже если вы только начинаете работать с этим движком, было бы не лишним получить представление о его GameFramework: о таких классах, как GameMode, GameState, PlayerController, Pawn и PlayerState.

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

Алексей Миловидов работал инженером в Яндекс.Метрике, и перед ним стояла непростая задача. 

Яндекс.Метрика работала с петабайтами данных — это был третий по популярности сервис веб-аналитики в мире. Для него нужна была база данных, которая может обрабатывать огромное количество данных в реальном времени, очень быстро, при этом не сжигая миллиарды денег.

Долгое время такая СУБД разрабатывалась только для внутренних нужд — но в 2016 вышла в опенсорс под названием ClickHouse, и сообщество встречает инструмент по-разному.

Мы поговорили с Алексеем о том, как он стал разработчиком, почему ClickHouse намного быстрее всех аналогов и как так получилось, какова цена производительности, почему ClickHouse стал опенсорсным и куда вообще движется индустрия.

Обслуживая большое количество проектов, мы пришли к необходимости простого управления OpenVPN (сертификатами и маршрутами для пользователей), подразумевая под этим веб-интерфейс вместо того, чтобы ходить по серверам/контейнерам и выполнять в них вручную команды. Поскольку существующие для этого решения (вроде Pritunl и OpenVPN AS) — коммерческие, несколько лет назад мы создали (и используем по сей день) свой интерфейс. Рассказываем про Open Source-проект ovpn-admin!