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

Отдельно поговорим, как заменить GIF на видео в AV1 и H.264 — тогда его размер упадёт в 20-40 раз.



YouTube уже использует его в TestTube. Netflix заявил, что AV1 будет «их основным кодеком следующего поколения».

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

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

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

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

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

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

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

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

В этой статье вас ждёт десять лучших докладов от Андрея Александреску, Дэвида Вандервурда, Джона Калба и многих других.

Фичи компилятора C++, асинхронность, многопоточность, параллелизм, модель памяти, алгоритмы и STL, метапрограммирование и рефлекшен, огромное множество тем.

Всё это — записи с конференции C++ Russia, самой большой в истории. Восемь сотен участников, немаленький зал, спикеры с мировым именем. Прошёл год, но большинство докладов ничуть не утратило своей актуальности. Впрочем, и неудивительно — именно такие доклады и попадают в топ по оценке участников.

Формат таков:

• Обязательное видео на YouTube
• Слайды, если есть
• Подробное описание доклада на русском языке
• Краткая биография докладчика

Плюс у вас есть комментарии Хабра, чтобы обсудить увиденное. Реклама на ютубе отключена, никто не будет мешать. Есть всё, чтобы начать смотреть прямо сейчас.

При разработке ПО для микроконтроллеров на С++ очень часто можно столкнуться с тем, что использование стандартной библиотеки может привести к нежелательным дополнительным расходам ресурсов, как ОЗУ, так и ПЗУ. Поэтому зачастую классы и методы из библиотеки std не совсем подходят для реализации в микроконтроллере. Существуют также некоторые ограничения в использовании динамически выделяемой памяти, RTTI, исключений и так далее. В общем случае, чтобы писать компактный и быстрый код нельзя просто так взять библиотеку std и начать пользоваться, скажем операторами типа typeid, потому что необходима поддержка RTTI, а это уже накладные расходы, хоть и не очень большие.

Поэтому иногда приходится изобретать велосипеды, чтобы выполнить все эти условия. Таких задач немного, но они есть. В данном посте, хотелось бы рассказать про вроде бы как простую задачку — расширить коды возврата существующих подсистем в ПО для микроконтроллера.

«Лучший способ писать — это переписывать»
— Пол Грэм, «The Age of the Essay»

Первую подборку на русском всех статей Пола Грэма (а их 176) меня вдохновили сделать ребята из tceh.com (60 переводов).
Вторую — Edison Software (125 переводов).
Третью — Филтех-акселератор (134 перевода и еще несколько в процессе).
На четвертую… уже закончатся эссе Грэма, буду переводить его Twitter (там, кстати, много полезного).

Недавно я подключился к проекту, цель которого содействовать «филантропическим стартапам» (это такие, которые «за добро во всем мире», типа GNU/Linux, Wikipedia и WebArchive). Я вношу свои 5 копеек подборкой самых полезных концептуальных/теоретических материалов про стартапы и стартаперское (хакерское) мировоззрение.

А для тех, у кого все же стартап, а не ICO:

До 16 января 2018 идет прием заявок, предакселератор PhilTech.
С 5 по 23 февраля будет акселерация «по-полной».
С 19 по 25 мая — финальный интенсив в Москве.

Есть время подучить матчасть, особенно для CEO.

Кто такой Пол Грэм?
Если вы хоть как-то связаны со стартапами у вас возник такой вопрос, то вам обязательно под кат.

Подборка из серии «добавить в избранное и читать по одному эссе в день».
(хватит на полгода, кстати)

Здесь будет длиннющая стена текста, с типа случайными мыслями. Основные идеи:

1. В C++ очень важно время компиляции,
2. Производительность сборки без оптимизаций тоже важна,
3. Когнитивная нагрузка ещё важней. Вот по этому пункту особо распространяться не буду, но если язык программирования заставляет меня чувствовать себя тупым, вряд ли я его буду использовать или тем более — любить. C++ делает это со мной постоянно.

Блогпост «Standard Ranges» Эрика Ниблера, посвященный ренжам в C++20, недавно облетел всю твиттерную вселенную, сопровождаясь кучей не очень лестных комментариев (это ещё мягко сказано!) о состоянии современного C++.

Даже я внёс свою лепту (ссылка):

Этот пример пифагоровых троек на ренжах C++20, по моему, выглядит чудовищно. И да, я понимаю, что ренжи могут быть полезны, проекции могут быть полезны и так далее. Тем не менее, пример жуткий. Зачем кому-то может понадобиться такое?

Давайте подробно разберём всё это под катом.

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

Короче, если вы контрибьютили свою альтернативную реализацию хэширования в Cassandra, то вряд ли тут для вас найдутся откровения. Но если нагрузка на ваши сервисы уже прибывает, а системные знания за ней не поспевают, то милости просим. Великий и ужасный Андрей Аксёнов (shodan) в свойственной ему манере расскажет, что шардить плохо, не шардить — тоже плохо, и как это внутри устроено. А еще совершенно случайно одна из частей рассказа про шардинг вообще не совсем про шардинг, а черт знает про что — как объекты на шарды мапить.

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

Хотели ли Вы когда-нибудь заглянуть под капот операционной системы, посмотреть на внутреннее устройство её механизмов, покрутить винтики и посмотреть на открывшиеся возможности? Возможно, даже хотели поработать напрямую с железом, но считали, что драйвера — rocketscience?

Предлагаю вместе пройтись по мостику в ядро и посмотреть, насколько глубока кроличья нора.

Итак, представляю драйвер-фреймворк для kernel-хакинга, написанный на C++17, и призванный, по возможности, снять барьеры между ядром и юзермодом или максимально сгладить их присутствие. А также, набор юзермодных и ядерных API и обёрток для быстрой и удобной разработки в Ring0 как для новичков, так и для продвинутых программистов.

Основные возможности:

• Доступ к портам ввода-вывода, а также проброс инструкций in, out, cli и sti в юзермод через IOPL
• Обёртки над системной пищалкой
• Доступ к MSR (Model-Specific Registers)
• Набор функций для доступа к юзермодной памяти других процессов и к памяти ядра
• Работа с физической памятью, DMI/SMBIOS
• Создание юзермодных и ядерных потоков, доставка APC
• Юзермодные Ob*** и Ps***-каллбэки и фильтры файловой системы
• Загрузка неподписанных драйверов и ядерных библиотек

… и многое другое.

Зачем покупать дорогой ПК, если ваш iPhone быстрее решает SMT?

Задача выполнимости формул в теориях (satisfiability modulo theories, SMT) — это задача разрешимости для логических формул с учётом лежащих в их основе теорий. — Википедия

Несколько дней назад я написал в твиттере: «Любопытный эксперимент: на новом iPhone прувер Z3 работает быстрее, чем на моём (довольно дорогом) десктопном Intel. Пора перевести все формальные методы исследований на телефон».


Я читал о невероятном прогрессе, которого добились разработчики процессоров Apple, и что скоро маки переведут на собственные ARM-процессоры от Apple. Эти отчёты обычно ссылаются на некоторые кросс-платформенные тесты, такие как Geekbench для демонстрации, что мобильные процессоры Apple не уступают мобильным и настольным процессорам Intel. Но я всегда немного скептически относился к этим кросс-платформенным тестам (как и к другим) — действительно ли они отражают скорость выполнения реальных задач, для которых я использую свои Mac?

Привет, Хабр!

Мы раскупорили последние резервы книги "Apache Kafka. Потоковая обработка и анализ данных" и отправили ее в допечатку. Более того, мы получили контракт на книгу "Kafka Streams in Action" и приступаем к ее переводу буквально на будущей неделе.



Чтобы показать занятный кейс использования библиотеки Kafka Streams, мы решили перевести статью о парадигме Event Sourcing в Kafka от того самого Адама Уорски, чья статья о языке Scala выходила у нас две недели назад. Тем интереснее, что мнение Адама Уорски не бесспорное: вот здесь, например, утверждается, что эта парадигма решительно для Kafka не подходит. Тем более запоминающимся, надеемся, получится впечатление от статьи.

Термин «Event Sourcing» переведен как «Регистрация событий» и в нашем издании "Чистой архитектуры" Роберта Мартина, и в данной статье. Если кому-нибудь импонирует перевод «прокачка событий» — дайте знать пожалуйста.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Advice for programming students".

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

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

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

Привет!

Наши коллеги постоянно выступают на технических конференциях самого разного масштаба — от встреч локальных сообществ до мировых форумов. Мы часто проводим в нашем офисе митапы для разработчиков, для которых ищем и находим самых интересных спикеров. И вот уже больше двух лет мы с маленькой, но гордой командой технопиара рассказываем о работе технического отдела Авито в разных источниках. Начиналось всё с твиттера, продолжалось фейсбуком, потом мы начали делиться инженерными историями здесь, на Хабре.
В итоге накопилось очень много контента разной тематики (бэкенд и фронтенд, мобильная разработка и тестирование, DevOps и высокие нагрузки...), в котором бывает довольно сложно разобраться и найти нужную информацию в разных источниках. Нас часто спрашивали, есть ли место, где есть всё про технологии Авито. И вот, кажется, что мы подросли настолько, что готовы объединить собранное за эти годы на отдельном сайте. Встречайте — avito.tech!

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

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

На хабре уже была попытка пользователя zepps начать серию публикаций о настройке оборудования cisco и практической стороне сетевых технологий, но, к сожалению, на первых двух статьях дело остановилось. Это было время моего становления, как специалиста в этой области и zepps сурово обломил меня отсутсвием продолжения.
Многократно пользователи здесь публиковали отрывочные топики о теоретической составляющей, решение сложных задач, куски из википедии или xgu.ru, но более менее цельной серии с информацией, которая непонятна после чтения цисковских книг при отсутсвии практики таки не было.
Поэтому мне пришло в голову снять несколько обучающих роликов с подробным описанием, начиная с настройки VLAN на свитчах, заканчивая… пока не знаю, чем заканчивая (может, OSPF, BGP, а может и чуточку дальше). Теории будет немного, в основном практика на PacketTracer и GNS3, с перечислением более или мене часто встречающихся трудностей.

На днях дочитал книгу Чеда Фоулера (Chad Fowler) Страсть к программированию (The Passionate Programmer). Сразу скажу, что она мне действительно понравилась и даже меня зажгла. На мой взгляд, данный опус не совсем соответствует своему названию (которое, кстати, уже менялось) и книга вряд ли придаст кому-то реальной страсти к такому интересному занятию как программинг. Однако следуя её советам вполне можно построить эффектную карьеру в любимом деле. Автор указывает на типичные ошибки и показывает, как их избежать. В конце каждого из разделов (а их 53) есть пункт «Действуй!» с описанием того, что можно попробовать и применить прямо здесь и сейчас.
Книга мне настолько понравилась, что я решил начать её переводить. Оригинал можно скачать здесь стоит это удовольствие всего 15$. В среднем буду стараться держать темп — по одному разделу в неделю, со временем доходя до 2-3 разделов. А сегодня — глава первая.