Эдуард Пройдаков — директор Виртуального компьютерного музея, разработчик, эксперт в области информационных технологий, преподаватель, журналист и переводчик. В интервью для Музея DataArt Эдуард Михайлович рассказал об экспедициях в пустыни и болота, системе бронирования билетов советского «Аэрофлота», полонезе Огинского на ламповой М-20, программистах-романтиках 1960-х, архитектурном кризисе и его преодолении.

Вступительное слово

Я выступил с этим докладом на английском языке на конференции GopherCon Russia 2019 в Москве и на русском — на митапе в Нижнем Новгороде. Речь в нём идёт о bitmap-индексе — менее распространённом, чем B-tree, но не менее интересном. Делюсь записью выступления на конференции на английском и текстовой расшифровкой на русском.

Мы рассмотрим, как устроен bitmap-индекс, когда он лучше, когда — хуже других индексов и в каких случаях он значительно быстрее них; увидим, в каких популярных СУБД уже есть bitmap-индексы; попробуем написать свой на Go. А «на десерт» мы воспользуемся готовыми библиотеками, чтобы создать свою супербыструю специализированную базу данных.

Очень надеюсь, что мои труды окажутся для вас полезными и интересными. Поехали!

Raspberry Pi снискали огромную популярность по всему миру. Однако многие из любителей-разработчиков сталкиваются с проблемой доступа к устройству из интернета. Как правило приходится колдовать с DDNS или докупать статический IP адрес. Оба варианта предполагают настройка роутера, что не для всех и не всегда доступно. Кроме того – откртытие прямого доступа к устройству из интрента несет в себе определнные риски безопасности.

Крайне распространенным способом решения этой проблемы является использование промежуточного сервера, через который сервер и клиент подключаются друг к другую.
Схема крайне широко используется в различных пакетах удаленного доступа: VNCViewer, AmmyyAdmin и т.д.

Вариант 1-DDNS



Вариант 2 – статический IP адрес



Вариант 3 – использование промежуточного сервера



Эту схему подключения можно реализовать через протокол MQTT over Websockets, но мне было инетесно реализовать что-то значительно более простое, JSON-ориентированое, расширяемое, без ограничений протокола на размер сообщения и с более очевидной моделью безопасности.

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

Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.

Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.

Зачем это нужно

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

C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.

А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.

Как это работает

На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.

К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.

Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).

Настройка на macOS

Разберем настройку DNS over TLS на последней версии macOS, на примере резолвера knot

Ключевой задачей высоконагруженных WEB-систем является способность обработать большое число запросов. Решить эту проблему можно по-разному. В этой статье я предлагаю рассмотреть необычный метод оптимизации запросов к backend через технологию content-range (range). А именно — сократить их количество без потери качества системы путем эффективного кеширования.

В этой статье я хотел бы рассказать о такой замечательной штуке, как файлы, отображаемые в память(memory-mapped files, далее — MMF).
Иногда их использование может дать довольно таки существенный прирост производительности по сравнению с обычной буферизированной работой с файлами.

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

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

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

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



Что ж, мы рискнем поговорить о том, о чем обычно говорить не принято.

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

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

Мы приготовили для вас небольшую подборку сериалов, так или иначе связанных с ИT. А натолкнула нас на идею этого поста многолетняя дружба ЛАНИТ с Международным фестивалем документального кино "ДОКЕР", где, кстати, в том числе с нашей помощью традиционной стала номинация для фильмов о возможностях информационных технологий «Let IT Doк!».

Кадр из сериала «Mr. Robot» (eps3.1_undo.gz)

Всем привет. Я – айтишник «за 30», и я люблю английский язык. Так получилось, что на протяжении многих лет английский никак не хотел полюбить меня. Перед вами живой пример человека с «плохой памятью», «неспособностью к языкам», богатейшим опытом неудачного изучения английского как на курсах, так и самостоятельно, упущенными из-за незнания языка шансами и возникшими на этой почве комплексами. Все, что можно было сделать в изучении иностранного языка плохо, я попытался сделать еще хуже. Не смотря на все это, перед вами история с хэппи эндом, которая, верю, поможет кому-то избежать глупых ошибок, сэкономить время, избавится от иллюзий и предрассудков по поводу изучения нового языка с около нулевого уровня.

Большинство из нас уже давно научилось готовить Docker и используют его на локальных машинах, на тестовых стендах и на боевых серверах. Docker, который недавно превратился в Moby, прочно вошел в процессы доставки кода до пользователя. Но best practice работы с контейнерной виртуализацией и, в частности, с Docker вырабатываются до сих пор.

Как это было

В начале становления Docker как основного инструмента изоляции процессов, многие использовали его аналогично использованию виртуальных машин. Подход был максимально прост: устанавливаем все необходимые зависимости в образ (Docker Image), там же билдим всё, что должно билдиться а что не должно двигаем и билдим, получаем артефакт сборки и запекаем всё это в итоговый образ.

Привет, %username%! Сегодня у нас немного пятничная криптотема. В марте 2016 года вышла интересная публикация от NIST под номером 800-38G (pdf) и с очень интересным называнием Recommendation for Block Cipher Modes of Operation:Methods for Format-Preserving Encryption, в которой отписываются два алгоритма, позволяющие не менять формат данных при шифровании. То есть, если это будет номер кредитки 1234-3456-4567-6678, то после шифрования он тоже останется номером, просто другим. Например 6243-1132-0738-9906. И это не простой xor, там AES и вообще всё серьезно. Давайте немного поговорим о FPE вообще, и об одной из реализаций в частности.

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

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

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

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

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

Здравствуйте, меня зовут Саша, я написал самый быстрый ресайз изображений для современных х86 процессоров. Я так утверждаю, поскольку все остальные библиотеки, которые я сумел найти и протестировать, оказались медленнее. Я занялся этой задачей, когда работал над оптимизацией ресайза картинок на лету в Uploadcare. Мы решили открыть код и в результате появился проект Pillow-SIMD. Любой желающий с легкостью может использовать его в приложении на языке Python.

Любой код выполняется на конкретном железе и хорошей оптимизации можно добиться, только понимая его архитектуру. Всего я планирую выпустить 4 или 5 статей, в которых расскажу как применять знание архитектуры железа для оптимизации реальной задачи. Своим примером я хочу побудить вас оптимизировать другие прикладные задачи. Первые две статьи выйдут в течение недели, остальные — по мере готовности.

Добрый день, я занимаюсь разработкой сервиса по прогнозированию спроса на базе Microsoft Azure, Spark Apache в IT компании. В цикле статей я расскажу про реальные бизнес кейсы из российских реалий, с которыми сталкивается IT компания. В основном статьи будут про бизнес: есть клиент, есть его задачи, нужно найти способ как их решать и доказать менеджменту адекватность расчётов, далее уже внедрение.

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

Первый бизнес-кейс

Компания хочет понять сколько у неё потерь (очень круто, когда компания сразу знает, что хочет), и как можно их уменьшить.



Цель поставлена. Теперь немного о компании: Федеральная сеть 400 розничных магазинов. Пилотную версию проекта договорились проводить с одной категорией товара – 20 sku, средний срок годности продукта 15 дней.

В прошлой статье мы прикрутили к нашей системе «умный дом» небольшой веб-интерфейс. Самое время обратиться к той части дела, ради которой все это и затевается — управление нагрузкой. Под нагрузкой подразумевается любое электроустройство, которым есть смысл управлять.
За подробностями реализации прошу под кат.