Open source

Как сделать Public API, которым будут пользоваться

Во фронтенде практически безраздельно правит OpenSource, а с недавних пор набирает популярность компонентный подход. Вроде бы всё чудесно. Небольшим компаниям компонентный подход помогает переиспользовать код, а крупным компаниям выравнивать UX во всей линейке продуктов, сервисов и прочего. И вот мы все такие замечательные крутые разработчики пилим свои фреймворки, библиотеки и виджеты, радостно полагая, что если они решают наши задачи, то решают и проблемы окружающего мира. Мы выкладываем их в паблик, ожидая благодарных пользователей, звезд на GitHub, скачиваний на NPM-е. Но почему-то одни библиотеки взлетают, а другие остаются незамеченными и позабытыми.

Обфускация данных для тестов производительности

Пользователи ClickHouse знают, что его главное преимущество — высокая скорость обработки аналитических запросов. Но как мы можем выдвигать такие утверждения? Это должно подтверждаться тестами производительности, которым можно доверять. О них мы сегодня и поговорим.
Такие тесты мы начали проводить в 2013 году, задолго до того, как продукт стал доступным в опенсорсе. Как и сейчас, тогда нас больше всего интересовала скорость работы данных сервиса Яндекс.Метрика. Мы уже хранили данные в ClickHouse с января 2009 года. Часть данных записывалась в базу с 2012 года, а часть — была переконвертирована из OLAPServer и Metrage — структур данных, которые использовались в Яндекс.Метрике раньше. Поэтому для тестов мы взяли первое попавшееся подмножество из 1 миллиарда данных о просмотрах страниц. Запросов в Метрике ещё не было, и мы придумали запросы, больше всего интересные нам самим (всевозможные виды фильтрации, агрегации и сортировки).
ClickHouse тестировался в сравнении с похожими системами, например, Vertica и MonetDB. Для честности тестирования его проводил сотрудник, который до этого не был разработчиком ClickHouse, а частные случаи в коде не оптимизировались до получения результатов. Похожим образом мы получили набор данных и для функциональных тестов.
После того, как ClickHouse вышел в опенсорс в 2016 году, к тестам стало больше вопросов.

Как починить все самому, если баг-репорты игнорируются: отлаживаю wkhtmltopdf под Windows

wkhtmltopdf — это один из самых мощных инструментов для генерации PDF. Он позволяет использовать в генерируемом документе все возможности HTML и CSS. «Под капотом» у него движок WebKit, так что результат почти в точности соответствует выводу «Print to PDF», встроенному в Chrome. Судя по вопросам на Stack Overflow, wkhtmltopdf используется для генерации карт, графиков, бухгалтерских отчётов, подарочных сертификатов, и практически любого другого контента, который в конечном счёте должен оказаться распечатанным на бумаге.
Мой давний заказчик с помощью wkhtmltopdf генерирует PDF-инвойсы в своём веб-магазине. При печати в «шапке» инвойса должен отображаться чёрно-белый логотип, тогда как на сайте используется цветной. Очевидное решение — подменить изображение в CSS Но тут обнаружилась проблема: если изображение не используется вне , то оно не загружается и при печати (этот баг можно заметить и в окне Print Preview самого Chrome).

Определение

Определение Open Source (Открытое ПО) используется организацией Open Source Initiative для определения степени соответствия лицензии на программное обеспечение стандартам Открытого программного обеспечения (Открытое ПО). Основываются на директивах Debian для свободного программного обеспечения, которые большей частью написаны Брюсом Перенсом.

Определение состоит из десяти требований к лицензиям на Открытое ПО:

• Свободное распространение. Это значит, что лицензия не должна налагать ограничений на продажу и распространение ПО.
• Доступные исходные тексты. Даже если ПО не поставляется с исходными текстами, эти тексты должны быть легко доступны.
• Возможность модификации. Простая возможность читать исходные тексты не позволяет экспериментировать с ними и выпускать модификации
• Даже в случае неприкосновенности авторского исходного текста, производные программы и их исходные тексты должны свободно распространяться.
• Отсутствие дискриминации против людей и групп людей. Некоторые страны, например, США, имеют некоторые ограничения на экспорт ПО.
• Отсутствие дискриминации по цели применения. Свободная лицензия должна разрешать все виды деятельности, включая генетические и ядерные исследования, коммерческое применение и т. д
• Распространение лицензии. Права, связанные с Открытым ПО, должны быть применимы ко всем пользователям программы без заключения дополнительных соглашений, например, соглашения о неразглашении.
• Лицензия не должна ограничивать другие программные продукты. За исключением банальной несовместимости, пользователь имеет право выбирать, чем пользоваться.
• Лицензия должна быть технологически нейтральной. То есть, лицензия не должна требовать что-либо от интерфейса или технологий, применяемых в производной программе.
• Лицензия не должна быть привязана к конкретному продукту. Права на программный код не должны зависеть от того, является ли программа частью какого-то продукта. Человек, распространяющий программу в отрыве от сборника или перенёсший часть кода в другой продукт, имеет такие же права, какие давал сборник.

[править] Драма

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

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

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

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

Выгоды от использования свободного программного обеспечения

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

Исправление ошибок

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

Совместное использование

Свободное программное обеспечение даёт вам право распространять его копии, таким образом помогая вашим друзьям использовать свободные программы без получения лицензий.

Знать и контролировать то, что и как делает программа

В подавляющем большинстве случаев вы не можете знать, что именно делает собственническая программа. Таким образом, вы не можете быть уверенным в том, что программа делает только то, что вы от нее просите, ибо некоторые действия она может делать без вашего ведома (например, отсылать своим создателям информацию о вас как о пользователе, или обладать недокументированными возможностями различного характера). Разумеется, в случае использования свободной программы, вы полностью застрахованы от подобных неприятностей. Ведь в вашем распоряжении находится исходный код программы, что позволяет вам точно знать, что и как делает программа. Если же те или иные её возможности и/или особенности работы вас не устраивают, вы можете внести в код необходимые вам изменения.

Технические выгоды

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

Экономические выгоды

Свободное программное обеспечение предоставляет компаниям возможность разделить между собой стоимость разрабатываемого программного обеспечения. К примеру, компании Novell и RedHat соперничают в разработке одинаковых программ, но тем самым помогают друг другу. IBM и HP также являются конкурентами, но они тоже внесли свой серьёзный вклад в разработку ядра Linux, тем самым разделив затраты на разработку. Свободное программное обеспечение позволяет иметь конкурентоспособный рынок технической поддержки, и потому качество её, как правило, весьма высокое. С собственническим программным обеспечением ситуация прямо противоположная: только компания-разработчик имеет доступ к исходному коду и способна предложить соответствующую техническую поддержку, и в этом проявляется некоторая степень монополиста.
Кроме того, к экономическим выгодам необходимо отнести вопрос стоимости приобретения программного продукта. В том случае, если он является свободным, вы можете один раз скачать его копию из Интернета (или приобрести на твёрдом носителе), установить его на любое число компьютеров и использовать его неограниченное время. Если же продукт собственнический, то условиями лицензионного договора использование продукта может быть весьма сильно ограничено (например, с ограничением числа установок и/или времени использования).

Проблемы

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

Иерархия

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

Прочитав все CONTRIBUTION.md и поучаствовав в нескольких обсуждениях, можно определить активных участников и «теоретических» боссов. Казалось бы всё, вопрос решен, но! Никто ни за что не отвечает, ни в масштабах проекта, ни в масштабах отдельной задачи. Нет начальника, который назначит задачу и дедлайн, нет исполнителя, который обязан закрыть issue. Также как от меня никто не может требовать написания тестов для v14 Node.js, также и я не могу требовать этого от других. В результате, может случится так, что эти тесты никто и никогда не напишет.

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

• Как можно релизить не покрытую тестами новую версию продукта?
• Кто за это отвечает?
• Кто должен был написать тесты?

На коммерческом проекте эти вопросы резонны, в open source — нет. Это так называемая коллективная ответственность, в которой нет ни героев, ни виноватых.

Планирование

В отличие от коммерческих проектов, здесь отсутствует привычный план разработки. Здесь нет JIRA/Trello карточек, прикрепленных к конкретным личностями. Это non-paid участие и следовательно никто не может устанавливать сроки и требовать выполнения задач. Такое положение вещей приводит к хаосу, где каждый делает то, что ему вздумается.

Можно возразить, что мол есть GitHub Projects (Trello на минималках встроенный в GitHub) и Milestones, которые используются на серьезных проектах.

Наверное пора открыть завесу тайны — деда мороза не существует эти доски ведутся «заинтересованными» людьми. Интересом может выступать:

• финансовая поддержка — оплачиваемая из спонсорских взносов
• энтузиазм — авторы идеи или core-разработчики, которые просто радеют за продукт

В таких случаях всё работает по правилам коммерческой разработки, и если с денежной мотивацией всё ясно — работает пока платят, то с энтузиазмом — всё очень неконтролируемо. Из этого я сделал вывод, что модель бесплатного open source не может похвастаться стабильностью и планомерностью, что в свою очередь влияет на производимый продукт и developer experience. Оплачиваемый open source пока только начинает набирать обороты, поэтому его в расчет не берем.

Пинг

Последнее и пожалуй самое ненавистное для меня это задержка в коммуникации. Если я сделал PR с фиксом сегодня, то никто не гарантирует, что его посмотрят, одобрят и смерджат в тот же день. Первая проблема это географическое положение всех участников. У меня разгар рабочего настроения, а единственный товарищ от которого я жду «LGTM!» сейчас спит на другом конце света и наоборот.

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

• day 0: я создал issue
• day 0: Отметил целевых участников: user1, user2
• day 1: user1 отреагировал смайликом 0_0
• day 2: user2 добавил метку «bug» и прокомментировал «Thanks for contribution. I’ll take a look»
• day 5: user1 прокомментировал «please add details about X and Y»
• day 6: я добавил комментарий с деталями по X и Y
• day 7: user1 прокомментировал «okay thanks»
• day 12: я прокомментировал «any progress»
• day 24: я прокомментировал «friendly reminder»
• day 30: я прокомментировал «ping ping»
• day 60: user2 прокомментировал «was busy for last months, will take a look soon»
• day 60: я прокомментировал «sounds great, thanks»
• day 65: user2 прокомментировал «PR with fix #000»
• day 67: issue закрыто после успешно принятого PR

Hygieia

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

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

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