Вышел Opal 1.0, компилятор из Ruby в JavaScript.

http://amp.gs/UJkN

К моменту релиза существует уже несколько фреймворков — и куча библиотек — поддерживающих Opal: http://amp.gs/UJks.

Читайте отчет о конференции RubyKaigi 2019 от участника, марсианина Андрея Новикова.

Внутри рассказ о его докладе (мониторинг Ruby-приложений), отличной организации конференции, рекомендации самых интересных докладов и выжимка из них.

http://amp.gs/U0pJ

Ежегодная рубрика «Intel опять».

В процессорах нашли ряд серьезных уязвимостей.

— Красочный сайт: http://amp.gs/U3ox
— Intel официально про MDS/ZombieLoad: http://amp.gs/U3ol
— Что делать и куда бежать в блоге Digital Ocean: http://amp.gs/U3oG (обновляться и ждать обновлений)

Про ZombieLoad:

— Подробно на русском языке с видео на OpenNet: http://amp.gs/U3Mv

— Proof of Concept с исходными кодами на GitHub: http://amp.gs/U3ME

Продолжаем рассказывать про GraphQL в Ruby: на этот раз Владимир Дементьев рассказывает о том, как «готовить» авторизацию и представляет новый гем для этого–action_policy-graphql.

Читать на devto: http://amp.gs/d8wl

Собираетесь на фестиваль РИТ++ в понедельник в Сколково? У нас два спикера: автор PostCSS Андрей Ситник расскажет, как продвигать open source проекты — лучшего спикера по этой теме сложно представить. Андрей ждет вас в 11 утра в Конгресс-холле.

А в 5 вечера наша аккаунт-менеджерка Ирина Назарова покажет, как начать делать продвинутую продуктовую аналитику даже в небольшом проекте. Ищите зал Москва.

Вся программа фестиваля тут: http://amp.gs/dZbh
Подходите за наклейками, ребята будут рады!

Послушайте разговор двух живых легенд. Керниган берет интервью у Томпсона. Рассказывать, кто это, даже как-то неудобно.

https://www.youtube.com/watch?v=EY6q5dv_B-o&feature=youtu.be

Культовый редактор Emacs (не GNU Emacs, а оригинал) был написан Гослингом, позже получившим известность как автор языка Java. И продавался примерно по стоимости подержанного автомобиля.

https://twitter.com/unix_byte/status/1118808597654204416

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

GitHub до Microsoft

GitHub с самого начала был командой отличных программистов и опенсорсеров, которые делали продукт для себя и отлично понимали механику работы сообщества. Приоритетом всегда было развитие платформы для разработчиков, а не создание монстра, в котором есть все, что душа пожелает — на контрасте с современными заимствующими у GitHub конкурирующими продуктами, в которых есть, как правило, вообще все, что можно представить («everything but the kitchensink»).

В первые годы работы GitHub отказался от поддержки своей системы распространения RubyGems (репозиторий библиотек кода на Ruby), доступной всем пользователям. Пришлось решать много проблем с безопасностью, публикация шла с задержкой и требовала больших ресурсов — в общем, команда решила сосредоточиться на основном и необходимом функционале.

Таких принципов в GitHub придерживались годами. Да, есть простой трекер задач и ошибок, которого, в принципе, достаточно для работы в несложных open source проектах, но его принципиально не усложняют и не делают «убийцу JIRA». Вместо этого GitHub постоянно дорабатывает собственное API: есть уже целый ряд продуктов, которые предоставляют интерфейс над уже живущей в GitHub тикетницей — канбан-доску, например. Тот же подход с continuous integration — до сих пор нет фирменного GitHub CI, как бы ни ходили слухи о скорой покупке GitHub’ом очередного стартапа, зато есть API для идеальной интеграции со сторонними сервисами.

GitHub расправил плечи

Многие гранды нашей отрасли — компании, которые развивают сверхпопулярные платформы и диктуют правила игры — совершенно не стесняются не просто менять правила во время игры, но и быть откровенно враждебными к клиентам собственной платформы. Больше всех тут отметились, например, Amazon — любят строить прямых конкурентов собственным стартапам-клиентам на своих же технологиях (Dropbox vs. Cloud Drive) — и Apple — полностью контролирует правила игры, ограничивает на уровне API сервисы конкурентов, не гнушается напрямую копировать удачные приложения интерфейсно или целиком (Delicious Library vs. iBooks).

Стратегия продуктовой разработки, видимо, начала меняться уже после того, как Microsoft купил GitHub.

Еще до конференции GitHub Satellite компания выпустила неожиданный апдейт: решили воскресить GitHub Package Registry, http://amp.gs/dGFs. Несмотря на то что его же, но в урезанном варианте (только RubyGems) убили много лет назад.

Действительно, новости отличные, и пользователи от такого только выиграют. Однако, GitHub решительно зашел на территорию стартапов, которые предоставляют управление пакетами и теперь представляет для них серьезную угрозу. Так, npm (репозиторий пакетов для Node.js) монетизируется как раз через платные аккаунты для закрытых репозиториев. Есть ли смысл после этого анонса вообще покупать платный аккаунт на npm? Пока неясно, GitHub держит Package Registry в закрытой beta. Мало того, с поддержкой Docker, GitHub, видимо, решил потеснить и Docker-ориентированные стартапы (Quay, например).

Tidelift

Прежде чем переходить к рассказу о нововведениях на GitHub Satellite, стоит напомнить о Tidelift. Tidelift — известная в коммерческом open source компания, основанная open source-знаменитостями из Red Hat. Tidelift упрощает для компаний управление open source зависимостями, поддержку, уведомления о проблемах с безопасностью и контроль лицензий.

Кажется, что проблема надуманна, и никаких сложностей быть не должно, верно? Расскажу, почему это не так. Попробуйте открыть популярное Electron-приложение, например, Slack или Discord. Зайдите в About, найдите что-то вроде Credits, и найдите страницу, на которой перечислены все open source проекты, которые используются в продукте; там будут сотни npm-пакетов. И это только десктопное приложение — можно представить, что творится в backend-части. Впрочем, думаю, в любом развитом приложении у читателей найдутся сотни зависимостей — или тысячи, если оно на JavaScript.

Что может пойти не так?

— Как узнать, что разработчики случайно не добавили пакет с известными проблемами в патентном смысле (Facebook) или с неудобной для продукта лицензией? Если за этим не следить, в коммерческом продукте разработчик может случайно нанести ущерб компании, включив в состав библиотеку с чрезчур агрессивной лицензией.
— Как узнать, не изменилась ли лицензия одной из библиотек с очередной версией?
— Как следить за проблемами с безопасностью? Не все уязвимости в библиотеках дублируются в CVE, не у всех языков и фреймворков есть качественные рассылки по безопасности, да и, вообще говоря, далеко не все мейнтейнеры вообще думают о том, чтобы сообщать о найденных уязвимостях.
— Как можно связаться с разработчиком той или иной библиотеки, если изменить ее под свои нужды не получается никак, а человек не отвечает на email или вообще скрывается?

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

Мы в Злых марсианах не просто добавляем самые популярные наши open source проекты в Tidelift, но и уже некоторое время поддерживаем партнерские отношения. Конечно, тема заслуживает отдельного поста. Но мы отвлеклись.

GitHub Sponsors

Уже долгое время open source мейнтейнеры пытаются немного заработать на своем нужном и неоплачиваемом труде, собирая деньги на поддержку. Как правило, для этого используются сервисы вроде Patreon, где через ежемесячный платеж можно оказать поддержку разработчику или даже получить какие-то бонусы. Почему это никак не является способом «монетизации open source», и ничем не отличается от поддержки стримеров или блогеров — тема отдельного большого поста.

К сожалению, у Patreon-подхода есть существенные минусы. Сейчас мейнтейнеры постоянно сталкиваются с хамством и потребительским отношением, как правило не получая взамен ничего — это главная причина выгорания разработчиков в open source и полного отказа от поддержки открытых проектов. Что меняется с добавлением Patreon? Теперь любой человек, который платит мейнтейнеру 5 долларов в месяц, может посчитать, что тот на него работает. А значит, приоритетная поддержка, бесплатные консультации, «когда будет сделано». Почему бы и нет, он ведь теперь «платит за разработку»?

Тем не менее, GitHub анонсировал программу Sponsors: http://amp.gs/dGXk

https://github.com/sponsors

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

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

Кстати, той же точки зрения про Patreon-подход придерживается и DHH, высказавшийся по теме: https://twitter.com/dhh/status/1131584970194018304

Чтобы поддержать другие способы спонсорства, добавлена поддержка для специального файла FUNDING. Там можно сослаться на Patreon, OpenCollective, Tidelift.

https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository

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

Dependents (Used by)

Еще одна фича, тоже очень полезная для разработчиков и проблемная для сторонних сервисов.

https://github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/

Теперь в любом популярном open source проекте можно посмотреть список зависящих от него — появилась кнопка Used By. Смотрите, как красиво выглядит результат у PostCSS, больше полутора миллиона репозиториев: https://github.com/postcss/postcss/network/dependents.

И, наоборот, для любого проекта, можно отслеживать полностью весь список зависимостей, получать уведомления о всех проблемах и уязвимостях. Ничего не напоминает?

Tidelift, хоть и гранд, но не единственный проект, который занимается управлением open source зависимостями для коммерческих проектов. Tidelift заявили о партнерстве с GitHub (https://blog.tidelift.com/tidelift-partners-with-github-funds-4000-open-source-projects) — действительно, вместе с GitHib они поддерживают монетизацию open source проектов — но видно, что у GitHub появилась еще одна фича, которая серьезно заимствует у крупного игрока их собственной платформы и открытого сообщества.

Что дальше?

Думаю, мы все-таки увидим GitHub CI. Странно было бы иметь сверхразвитую экосистему вокруг управления зависимостями и релизами, но не иметь продвинутого Continuous Integration сервера вроде Circle CI.

Это позволит, наконец, разрабатывать и сопровождать вообще все в GitHub — и деплоить в Microsoft Azure, почему нет? После новостей о покупке Microsoft’ом GitHub было распространено мнение о том, что Microsoft обязательно использует GitHub как стартовую площадку для развития своих облачных сервисов Azure, главного конкурента Amazon Web Services.

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

* * *

Если вам нравятся такие посты, можно оказать нам внимание, подписавшись:

— на наш Twitter https://twitter.com/evilmartians и Facebook https://www.facebook.com/evilmartians для новостей без лишнего — только про наш open source, выступления, материалы и блог;
— на наш русскоязычный Twitter, где мы в том числе публикуем выдержки из канала: https://twitter.com/evilmartians;
— на Instagram с марсианскими фотками, в том числе с зарубежных и наших конференций: https://www.instagram.com/evil.martians.

Слайды Андрея Ситника с FrontendConf про то, как хайп и ориентация только на популярные решения убивают инновацию в фронтовом опенсорсе — и как на этом фоне пиарить свой опенсорс и исправить сообщество.

http://amp.gs/dxtK

Open source, поддержка, коммерция. Продолжаем тему вчерашнего поста докладом DHH, автора Rails, с RailsConf этого года. Доступно видео и транскрипт.

http://amp.gs/dCMB

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

Сравнили производительность imgproxy, нашего быстрого сервера для ресайза и конвертации картинок, с прямыми аналогами. Он всех сделал — надо же.

Бенчмарки: http://amp.gs/dkEt

Пост-представление imgproxy: http://amp.gs/dkEG

Продолжаем тему этой недели с Сальваторе Санфилиппо, автором Redis. Он пишет о сложностях бытия open source-разработчиком.

http://amp.gs/d74z

Обещает, что это первый пост из серии.

Смотрите слайды Ирины Назаровой c #RITfest2019 о том, как строить когорты и тестировать гипотезы, используя Google Analytics API и формулы в Google Sheets вместо кода:

http://amp.gs/dPBK

Марсианин Андрей Козин делится опытом тестирования Ruby приложений исключительно на базе фикстур. Фикстуры повсюду: от генерации объектов базы данных до сложной имитации (stubbing) методов.

Читайте на devto: http://amp.gs/dP9M

Обнаружено отличное приложение для iOS, iSH:

https://ish.app

Терминал со встроенным x86 эмулятором и установкой пакетов через apk (Alpine).

Вообще, хороший способ пользоваться терминалом в iOS на ходу известен давно — покупаем виртуальную машину на Digital Ocean или аналогах, ставим нужное окружение, всегда имеем доступ к сетевым утилитам и языкам программирования без ограничений через SSH-клиент — если есть связь до сервера, конечно. Но это достойная альтернатива для простых случаев.