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

Этот пост — «краткое содержание предыдущих серий», где эти витки собраны вместе (конечно, в очень упрощённом виде: в одном тексте все важные нюансы не расписать). А после него, окинув взглядом весь контекст, можно и на текущие задачи посмотреть по-новому. Какие новые запросы человечества видны сейчас, и какими станут новые языки программирования, отвечающие на них? Расскажите в комментариях, через десять лет проверим.

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

Elasticsearch вырос из простого приложения для рецептов, которое сделал для своей жены Шей Бэнон. Сейчас это флагманский продукт всемирно известной компании. Когда в 1991-м году Линус Торвальдс известил мир о появлении Linux, то написал: «just a hobby, won't be big and professional». Что в итоге получилось, мы все знаем.

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

В этой подборке расскажем о самых разных пет-проектах — странных и полезных — и об их создателях. 

Я страдаю частичным дальтонизмом (не различаю некоторые оттенки) и всегда затруднялся в магазине выбрать галстук к рубашке и пиджаку, а потом каждое утро составлять комбинацию из многих вариантов. В результате жена делала мне комплекты, и я просто выбирал «комплект 1» или «комплект 9».

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

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

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

Андрей Лушников выступил у нас на Heisenbug с докладом о Playwright ещё в 2020-м. Но похоже, что с тех пор тема доклада стала только актуальнее: 34 000 звёзд проекта на GitHub ясно показывают, что он пришёл к популярности. А Андрей по-прежнему остаётся одним из главных контрибьюторов Playwright. Поэтому мы решили сделать для Хабра текстовую версию его доклада.

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

Видео и расшифровка — под катом. Далее повествование будет вестись от лица спикера.

В IT все знают про Тьюринга, Страуструпа, Ритчи и Торвальдса. Эти люди много сделали для становления компьютерной науки. Но, как и везде, в IT-индустрии есть свои невоспетые герои. Поэтому в этой подборке мы решили рассказать об ученых и инженерах, которые внесли большой вклад в развитие Computer Science, но которых нечасто вспоминают на Хабре.

Если вы мобильный разработчик, знаете ли вы, каково пользоваться вашим приложением незрячим людям? В каких именно местах они могут столкнуться с главными сложностями? Как вообще будет происходить взаимодействие с приложением?

На нашей конференции Mobius Виктор Вихров (Яндекс Go) рассказал о том, как сделать Android-приложение более подходящим для использования «вслепую». А эксперт в сфере цифровой доступности Анатолий Попко помог ему, прокомментировав представленные решения с точки зрения такого пользователя. Мы считаем, что такой контент нужен и на Хабре — поэтому сделали текстовую расшифровку доклада.

Привет, на связи DotNetRu – сообщество, объединяющее .NET разработчиков России и не только. Казалось бы, совсем недавно мы рассказывали про митапы и прочие наши активности 2019 года и с оптимизмом смотрели в наступающий 2020-й. Штош, начался он действительно бодро, но затем известные события чуть охладили наш пыл. Какое-то время мы посидели со всей страной в домике в надежде переждать неприятности. Но ближе к лету дошли до стадии принятия и провели митап онлайн, открыв новую большую главу в истории сообщества DotNetRu. И если в конце 2020-го хотелось просто сесть, выдохнуть и забыться, а не писать статьи на хабр, то сейчас, в начале 2022-го, мы полны сил и бодры как никогда!

Поэтому встречайте – итоги жизни сообщества сразу за два года! Под катом не только интересные истории, но и хит-парад докладов.

Мы без конца ругаем NFT и, разумеется, за дело. Но ощущаю, что рядом со справедливой критикой встречается и необоснованная. И часть оценок вида «скоро всё точно громко лопнет» или «это вообще никому не нужно» может быть излишне категоричной.

При этом о минусах NFT на Хабре активно пишут, а вот развёрнутых текстов с другой стороны здесь не видел. Поэтому, хотя я совершенно не фанат NFT, во имя полной картины решил побыть адвокатом дьявола и описать эту другую сторону. Нужно ведь, чтобы вечером пятницы Хабру было о чём похоливарить! А если вы всей душой ненавидите NFT и холивары, лучше просто пропустите пост.

Современные «умные устройства» выглядят привлекательно для потребителей: получать уведомления от видеоняни, управлять домом голосовыми командами, подзывать свою Tesla — всё это звучит как будущее. Есть и менее броские, но не менее полезные применения IoT: вплоть до датчиков в мусорных контейнерах, позволяющих удалённо проверить, вывезен ли мусор.

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

Недавно популярность VR резко скакнула: шлем Quest 2 от Meta так массово дарили на Рождество, что разработчики VR-приложений сообщили о рекордном всплеске пользователей. И это не разовая случайность, Quest 2 вообще продаётся куда лучше, чем все VR-шлемы до него. Он не требует подключения к компьютеру и стоит всего $300, а в итоге делает VR массовым.

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

Андрей Акиньшин @DreamWalker хорошо известен в .NET-сообществе: он мейнтейнер BenchmarkDotNet и perfolizer, член программного комитета нашей конференции DotNext, автор книги Pro .NET Benchmarking о том, как правильно бенчмаркать.

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

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

Массовый переход от монолитов к микросервисам решает ряд проблем:

• раздельный деплой и рефакторинг;

• удобное масштабирование частей системы;

• прозрачное разграничение ответственности команд;

• снижение бласт-радиуса;

• снижение когнитивной нагрузки на разработчика.

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

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

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

По материалам выступления на конференции DotNext.

Именно с таким провокационным тезисом я выступил осенью 2021 года на конференции Mobius. Но речь здесь вовсе не о том, что завтра исчезнут смартфоны — а о том, что не будет мобильной разработки в привычном нам виде. А в каком же будет? Для этого предлагаю хабравчанам ознакомиться с текстовой расшифровкой моего доклада. 

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

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

Я не встречал на Хабре упоминаний этого теста, а по-моему, это очень интересные данные, заставляющие задуматься о том, что представляет ценность для пользователей. Поэтому решил описать текстом и свежие результаты Маркеса Браунли (так зовут MKBHD), и общие выводы за несколько лет.

Я парю в космосе, вокруг простирается грандиозный Млечный Путь. Передо мной висит экран размером как в кинотеатре, плавно изогнутый, на идеальном для просмотра расстоянии. Восемь разных панелей сверкают кодом — грани технологической жемчужины, через которые можно заглянуть в мозг системы, отвечающей за движение десятков миллионов долларов в день. На коммуникационной консоли, расположенной под углом (как чертёжная доска), прямо на кончиках пальцев находится пункт переписки с коллегами, календарь, документация API и видеопотоки с камер «реального» мира. Слева от меня, рядом с огромным массивом кода, на вертикальном экране высотой в два этажа отображаются детали текущей задачи вместе с плейлистом Spotify. Врубаю музыку и вхожу в поток.

Это не отрывок из романа Эрнеста Клайна — это моя повседневность. На этой неделе я проведу 40–50 часов в виртуальной реальности, как уже делал и на прошлой неделе, и каждую рабочую неделю в течение последних 2,5 лет. Виртуальная реальность — это не просто развлечения и игры (хотя их и предостаточно), а еще физические упражнения, медитация, творчество, общение и т. д.  Но в этой статье я сосредоточусь только на работе.

Statoscope — это инструмент для анализа webpack-бандлов, а я его автор и мейнтейнер. Он зародился в далеком 2016 году как эксперимент, а теперь это полноценный тулкит для просмотра, анализа и валидации сборки.

В ноябре на конференции HolyJS я выступил с докладом о Statoscope и провёл воркшоп по его использованию. Зрителям понравилось, так что мы с организаторами HolyJS решили, что доклад может пригодиться и читателям Хабра — поэтому сделали текстовую версию. Видеозапись тоже прилагаем.

Приглашаем на бесплатный митап по мобильной разработке 16 декабря (четверг) в 18:00.

Краткие описания докладов — под катом.

Мы провели этой осенью девять конференций, причём у каждой часть программы сразу сделали доступной всем. И теперь хотим:

— поделиться с Хабром видеозаписями общедоступной части (суммарно по всем конференциям это более ста часов видео!)

— анонсировать наш следующий конференционный сезон: уже можно и подавать заявки на доклады, и приобретать билеты

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

Ежедневно люди загружают на Facebook сотни миллионов видеороликов. Чтобы каждое доставляемое видео было наилучшего качества — с максимальным разрешением и минимальной буферизацией — нужно оптимизировать не только то, когда и как видеокодеки сжимают и распаковывают видео для просмотра, но и то, какие кодеки используются для тех или иных видео. Огромный объем видеоконтента на Facebook также означает, что нужно найти эффективные способы его обработки, не требующие больших затрат вычислительной мощности и ресурсов.

Для этого мы используем различные кодеки, а также адаптивный битрейт (ABR), который улучшает качество просмотра и уменьшает буферизацию — он выбирает наилучшее качество в зависимости от пропускной способности сети зрителя. Но хотя более современные кодеки (например, VP9) обеспечивают лучшую производительность сжатия по сравнению со старыми кодеками вроде H264, они также задействуют больше вычислительной мощности. С вычислительной точки зрения применение самых современных кодеков к каждому видео, загружаемому в Facebook, было бы непомерно неэффективным. А значит, нужен способ приоритизировать видеоролики, которые должны быть закодированы с использованием более современных кодеков.