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

Либо — либо — либо. А вот этой прекрасной книги, в которой сочетается всё, что думающий и практикующий специалист ценит, — её нет.

Поэтому мы решили, что она должна быть. И не одна — таких книг должно быть много. Решили — и открыли собственное издательство ITSumma Press: возможно, первое издательство в России, созданное IT-компанией.

Было потрачено много сил, времени и порядком денег. Но вот за день до конференции Uptime day 4 мы получили пилотный тираж и подержали первую изданную нами книгу в руках (весь тираж подарили участникам конференции в итоге). Невероятное ощущение! Никогда заранее не знаешь, куда в итоге может тебя привести твоя тяга к прекрасному. Первая книга, по понятным причинам, была своеобразным пробным шаром. Нам нужно было самим прощупать весь процесс книгоиздательства, понять, что мы можем привнести сразу, а над чем нужно будет подумать ещё. И по итогу мы остались очень довольны результатом. Это важное дело, которое мы хотим продолжать и развивать. А в этом тексте хочу просто рассказать, с чего всё начиналось, как мы спорили про название, как заключили договор с, ни много, ни мало, самими O’Reilly и сколько редактур надо провести, прежде чем отдать текст в прод в типографию.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

При соблюдении ряда условий, опция фильтра $rewrite, внедренная в AdBlock, AdBlock Plus и uBlock с обновлением 3.2 от 17 июля 2018 года, позволяет выполнять произвольный код на отображаемой пользователю веб-странице, сообщается в блоге armin.dev.

Вот как описывается проблемная функция в самом патчноуте AdBlock:

В этом патче реализована новая опция фильтра $rewrite, которая позволяет авторам списков фильтров предотвращать показ (в основном это касается видео) рекламных объявлений, которые ранее не могли быть заблокированы на ряде веб-сайтов.

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

Уязвимость просуществовала почти 9 месяцев и была найдена только сейчас.

В прошлом месяце на NVIDIA GTC 2019 компания NVIDIA представила новое приложение, которое превращает нарисованные пользователем простые цветные шарики в великолепные фотореалистичные изображения.


Приложение построено на технологии генеративно-состязательных сетей (GAN), в основе которой лежит глубинное обучение. Сама NVIDIA называет его GauGAN — это каламбур-отсылка к художнику Полу Гогену. В основе функциональности GauGAN лежит новый алгоритм SPADE.

В этой статье я объясню, как работает этот инженерный шедевр. И чтобы привлечь как можно больше заинтересованных читателей, я постараюсь дать детализированное описание того, как работают свёрточные нейронные сети. Поскольку SPADE — это генеративно-состязательная сеть, я расскажу подробнее и о них. Но если вы уже знакомы с эти термином, вы можете сразу перейти к разделу «Image-to-image трансляция».

Генерация изображений

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

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



Сохраните следующую программу в /tmp/quine.pl

Illegal division by zero at /tmp/quine.pl line 1.

Запустите её командой

perl /tmp/quine.pl

и она выведет свой собственный код.

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

  File "quine.py", line 1
    File "quine.py", line 1
   ^
IndentationError: unexpected indent

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

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

И вот, четверка крупнейших IT-компаний в лице Amazon, Google, Microsoft и Facebook дошли до того, что начали вкладываться не только в непосредственно дата-центры и серверы, но и в сами магистральные кабели — то есть зашли на территорию, которая традиционно являлась зоной ответственности совершенно иных структур. Причем, судя по выводам в блоге APNIC, упомянутый квартет технологических гигантов замахнулся не просто на наземные сети, а на магистральные трансконтинентальные линии связи, т.е. на всем нам знакомые подводные кабели.



Самое удивительное, что острой необходимости в новых сетях сейчас нет, но компании активно наращивают пропускную способность «про запас». К сожалению, найти внятную статистику о мировой генерации трафика почти невозможно благодаря многочисленным маркетологам, которые оперируют размерностями вида «65 миллионов постов в инстаграме ежедневно» или «N поисковых запросов в Google» вместо прозрачных и понятных техническим специалистам петабайт. Можно осторожно предположить, что ежедневный трафик составляет ≈2,5*10^18 байт или около 2500 петабайт данных.

Вчера, полностью серьезно и без каких-либо шуток-прибауток, компания Cloudflare анонсировала свой новый продукт — VPN-сервис на базе DNS-приложения 1.1.1.1 для мобильных устройств с использованием собственной технологии шифрования Warp. Основной фишкой нового продукта Cloudflare является простота — целевой аудиторией нового сервиса являются условные «мамы» и «друзья», которые не способны самостоятельно купить и настроить классический VPN или не согласны устанавливать прожорливые в плане энергопотребления сторонние приложения от неизвестных команд.



Напомним, ровно год и один день назад — 1 апреля 2018 года — компания запустила свой публичный DNS 1.1.1.1, аудитория которого за прошедший период выросла на 700%. Сейчас 1.1.1.1 борется за внимание публики с уже ставшим классическим DNS от Google по адресу 8.8.8.8. Позже, 11 ноября 2018 года, CloudFlare запустили мобильное приложение 1.1.1.1 для iOS и Android и вот теперь, на его базе запускается и «VPN по кнопке».

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

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

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

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

Вчера, 26 марта, команда разработчиков браузера Firefox представила новый продукт под названием Firefox Lockbox — менеджер паролей для мобильный устройств. Согласно странице FAQ проекта, сейчас доступна только версия для iOS, но «в ближайшее время появится и вариант для устройств под управлением Android». Возможно, FAQ просто не обновили, потому что в Google Play приложение уже есть и доступно для скачивания. Также для ознакомления можно посмотреть репозиторий проекта на GitHub.

Идея Firefox Lockbox одновременно и проста до банальности, и весьма символична, так как решает очень распространенный пользовательский кейс: извлечение паролей из браузера. Firefox Lockbox — по своей сути, тот же менеджер паролей, что и 1password или KeePass, однако имеет из коробки синхронизацию с одним из популярных браузеров. Приложение позволяет извлекать пользовательские пароли и переносить их в приложение без этапа передачи в открытом виде (если делать выгрузку логинов-паролей руками). Конечно, далеко не все пользователи способны извлечь свои данные, а некоторые даже не подозревают о такой возможности.

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

«Да чего же ждать от конференций? Сплошь танцовщицы, вино, гулянки» — шутил герой фильма «Послезавтра».

Наверное, на каких-то конференциях и не такое бывает (делитесь историями в комментах), но на it-сборищах обычно вместо вина пиво (по завершении), а вместо танцовщиц — «танцы» с кодами и информационными системами. 2 года назад мы тоже вписались в эту хореографию, организовав конференцию Uptime day. В этом апреле, на День космонавтики, мы проводим её уже в четвёртый раз — традиционно бесплатно и традиционно под аккомпанемент вопросов «зачем вам это надо?»
На весеннем Uptime day будем говорить об организации резервирования веб-проектов со сложной распределённой архитектурой — способам переключения с боевого окружения на резервное, а также разбору различных сценариев отката и переключения на резервную площадку в случае неудачного деплоя.

А зачем нам это надо?.. Об этом под катом. И о том, чем вам будет полезна конференция Uptime day.

У нас есть определенно хорошие новости: поисковой гигант Google, по всей видимости, пересмотрел свою стратегию касательно конкурента DuckDuckGo. Компания включила «утку» в список поисковых систем по умолчанию Chrome для 60 различных регионов. Обновление поставляется с версией 73 Chromium.

При этом сами инженеры Google утверждают, что никакого «подвоха» в их действиях нет — они лишь обновили списки согласно собранным ранее данным о пользовательских предпочтениях. Таким образом компания признает, что популярность DuckDuckGo выросла и стала заметной для внесения подобных корректировок. Список стран, получивших DuckDuckGo «из коробки», весьма разнообразен: от Коста-Рико и Гондураса, до Канады, Великобритании и даже Индии. Правда, для РФ варианты поискового движка остались прежними: Google, Bing, Yandex, Mail.ru.

С актуальным перечнем поисковых систем, доступных по умолчанию в Chromium и, соответственно, в Chrome, можно ознакомиться на этой странице GitHub.

От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.

---

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

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.

На первый взгляд, в этой истории есть всё, чтобы заслужить статус романтичного поста накануне 8 марта: самолёты, любовь, чуточка шпионажа и, наконец, котик (точнее, кошка). Трудно представить, что всё это имеет самое непосредственное отношение к Kafka, KSQL и эксперименту «как в домашних условиях с помощью информационных технологий найти самый шумный самолёт». Трудно, но придётся: именно такой эксперимент провёл Саймон Обьюри, а мы перевели статью его авторства с описанием всех подробностей процесса.

Типичное IoT-устройство

IoT — сегмент рынка крайне молодой, только пробующий делать первые серьезные шаги. Конечно, IP-камеры и прочие датчики существуют уже давно, но полноценно назвать их «умными» язык не поворачивается. При этом одной из проблем рынка является, как ни странно, цикл разработки, потому что он подразумевает не только создание физического девайса, но и написание ПО для него в условиях крайне ограниченных ресурсов. Это 20 лет назад несколько мегабайт памяти под приложение было нормой. Сейчас же, когда оптимизация потребления ресурсов пользователям (да и разработчикам) только снится, а для топовых продуктов нормальны утечки памяти или нереальная прожорливость (привет, Chrome), работа в условиях пары сотен килобайт флеш-памяти на энергоэффективном микроконтроллере кажется наказанием для тех девелоперов, кто плохо себя вел в прошлом году.

Но это не единственная проблема IoT. Не мне вам рассказывать, насколько беспомощными являются умные устройства в плане информационной безопасности. Истории о ботнетах из IP-камер, холодильников и прочих микроволновок периодически всплывают в медиа, начиная еще с 2015 года. Добавим в это «блюдо» еще и «соус» из всяких умных колонок и ассистентов типа Alexa или Алисы, и мы получим пугающую картину; со времен китайских ноунейм-камер, продукты от Amazon и Яндекса обзавелись еще и возможностью совершать онлайн-заказы по запросу владельца. Собственно, именно эти функции нового поколения IoT-устройств и заставили производителей ПО начать шевелиться, а именно — укреплять рубежи цифровой обороны наших говорящих ящиков и прочих датчиков.

На прошлой неделе, 21 февраля, сообщество Linux Foundation анонсировало старт работ над платформой Enabling Linux in Safety Application (ELISA), цель которой — стандартизировать разработку и повысить надежность автоматизированных систем во всех основных промышленных областях. В их число, в том числе, входит медицина, энергетика и автомобилестроение.



Также цель платформы — повысить скорость вывода новых продуктов на рынок и параллельно снизить количество критических ошибок и рисков при проектировании систем, которые могут повлечь проблемы в эксплуатации, техногенные аварии и человеческие жертвы. В разработку будут вовлечены британский производитель чипов ARM Holdings, BMW Car IT GmbH, Toyota и немецкая компания KUKA Robotics, сообщается в официальном пресс-релизе.

Платформа ELISA является наследником более раннего проекта Linux Foundation — Automotive Grade Linux (AGL) 5.0 — совместного с Toyota open source проекта по разработке программного обеспечения и систем автопилота для транспорта. Также в основу платформы легли наработки по проекту SIL2LinuxMP (урезанное окружение GNU/Linux для RTOS) и Real-Time Linux (PREEMPT_RT).

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

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

Мы и сами активно используем эту технологию в наших проектах. Но ведь всегда интересно, а как оно получается у других? И вдвойне интересно, если это не просто пример из чьей-то практики, а целенаправленное тестирование технологии. Поэтому мы перевели свежую статью, в которой рассказывается о том, как Dropbox опытным путём искал границы возможностей и лимиты выносливости у Kafka. И нашёл что хотел.

Скандальные, важные и просто очень крутые материалы выходят в СМИ не каждый день, да и со 100% точностью спрогнозировать успешность той или иной статьи не возьмётся ни один редактор. Максимум, чем располагает коллектив — на уровне чутья сказать, «крепкий» материал или же «обычный». Все. Дальше начинается непредсказуемая магия СМИ, благодаря которой статья может выйти в топы поисковой выдачи с десятками ссылок от других изданий или же материал канет в Лету. И вот как раз в случае публикации крутых статей сайты СМИ периодически падают под чудовищным наплывом пользователей, который мы с вами скромно называем «хабраэффектом».

Этим летом жертвой профессионализма собственных авторов стал сайт издания Republic: статьи на тему пенсионной реформы, о школьном образовании и правильном питании в общей сложности собрали аудиторию в несколько миллионов читателей. Публикация каждого упомянутого материала приводила к настолько высоким нагрузкам, что до падения сайта Republic оставалось совсем «вот столечко». Администрация осознала, что надо что-то менять: нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.

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

*В ходе переезда ни один технический специалист Republic не пострадал

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

За последние два года в нашей стране появилось два новых крупных игрока на рынке облачного хостинга: Яндекс.Облако и Mail Cloud Solutions. Нам стало интересно, на что способно железо каждой из представленных компаний и насколько реально производительны предоставляемые конфигурации ресурсов. Мы решили это выяснить, а после — сопоставить данные с озвученными ценовыми предложениями.

Так как сами хостинг мы не продаем, а лишь периодически консультируем наших клиентов и подбираем им оптимальное по цене-качеству решение, то в этом вопросе мы сможем быть сравнительно объективны.

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.