My current projects have a significant portion of legacy code and lots of gem dependencies. Time to time, I check their Gemfiles just to be puzzled about some of the gems I barely know about. Sooner or later, I will have to check those dependencies to learn if those gems are up to date and still supported — there is a chance I would need to get rid of irrelevant code, especially if it is already outdated.
The same problem arises when you need to add a new dependency to the project or choose a new gem from a myriad of alternatives. It would be great to check the amount of changes going on with the gem, its development history, its changelog and issues — on GitHub or RubyGems — and do it all at once while comparing it to alternatives.
I am going to share some interesting infographics on trends and development history of some of the most well-known Ruby projects (hanami, sinatra, slim, minitest and others), will talk about the aspects of getting the metrics from the sources mentioned above, and, most of all, about several ways to classify that data. Also, of course, we are going to have a demo of the project which was born as a result of my research; it will be available as an open-source project.
3. Опасности стороннего кода
https://robots.thoughtbot.com/to-gem-or-not-to-gem
— Вы ничего не знаете о качестве и безопасности кода.
— Вы ничего не знаете о его поддержке в дальнейшем.
— Вы не знаете, сколько ресурсов потребует в работе
сторонний гем.
— Вам необходимо использовать гем в соответствии с его
лицензией.
— Вам придется мириться с его DSL/API.
— Возможно, вам придется тащить слишком большой
багаж.
4.
5.
6. 1. На Rubygems порядка 100 000 гемов, при этом большая
часть загрузок приходится на ~1%
Проблемы open-source зависимостей
7. 2. У Node.js, передовика open-source, дела обстоят хуже:
“The average open source node.js project has a dependency
graph more than 3 times bigger than the average ruby
project!”
Проблемы open-source зависимостей
https://twitter.com/teabass/status/763325955486146560
8.
9. 1. Ruby Toolbox — альтернативы, популярность, динамика
2. RubyGems — информация о версиях
3. Github — сommits, issues & pulls, контрибьюторы
4. CodeClimate — качество кода
5. coveralls.io — покрытие документацией
6. Rubocop — cоответствие стилю
Стандартный цикл оценки
Ruby OSS-проекта
11. — rubocop — проверка на соответствие стилю
— simplecov, coveralls, rcov — тестовое покрытие
— yard, inch — покрытие кода документацией
— Code Climate, cane/flog/flay — качество кода
— Бейджики с загрузками за последний период или с
пометкой об устаревании кода
Инструменты для анализа
кодовой базы
13. — Наличие хорошей документации
— Качественная архитектура
— Наличие инструмента взаимодействия с
потребителем/пользователем/контрибьютором
— Наличие и качество тестового покрытия
— Наличие Roadmap (или долгосрочных планов развития)
— Количество открытых багов
— Число подписчиков на mailing list
Примеры метрик
для оценки зрелости
http://www.dmst.aueb.gr/dds/pubs/conf/2008-OSS-qmodel/html/SGSS08.htm
14. 1. Популярность проекта
2. Качество поддержки
3. Характеристики кода
4. Характеристики документации
Направления «созревания»
open-source
15. 1. Подвижность проекта
— количество и динамика изменений в коде
— релизы
— открытые/закрытые Pulls & Issues
2. Участники проекта
— сколько контрибьюторов
— кто и в чем участвует
— сколько загрузок
Ключевые группы метрик
поддерживаемости
16.
17.
18. 1. Rubygems:
— зависимости
— релизы
— ссылки на исходники, wiki
— описание
— другие метаданные из gemspec
2. Bestgems:
— данные о загрузках за каждый день
— данные о рейтинге по загрузкам за каждый день
Данные из открытых источников (1/2)
19. 3. Github:
— pull requests (статусы, комментарии, пользователи,
даты)
— issues (статусы, комментарии, пользователи, даты)
— commits за последний год
— contributors
— и другая интересная информация
Данные из открытых источников (2/2)
25. — Sinatra — уровень стабилизировался с 2014
— Padrino — спад начиная с 2014
— Hanami — рост с 2014, пик в конце 2015
Треды по пользователям
создающим Issues
26.
27. 1. Sinatra — 49,84% (~100 активных участников за квартал)
2. Hanami — 27,71% (~85)
3. Padrino — 21,6% (<35)
4. Ramaze — 0,84%
Рейтинг по количеству
активных участников
31. 1. Padrino — 51,75% (~60 issues за квартал)
2. Hanami — 23,47% (~35)
3. Sinatra — 22,08% (~30)
4. Ramaze — 3,48%
Рейтинг по числу Issues
32. — Hanami — лидер по коммитам и проценту закрытия Issues
— Sinatra — лидер по числу вовлеченных в проект людей
— Padrino — лидер по потоку Issues
Предварительный итог
33.
34. 1. Rails — 83,76%
2. Sinatra — 8,84%
3. Hanami — 4,08%
4. Padrino — 2,6%
Рейтинг по количеству
активных участников
35.
36. 1. Rails — 63,85%
2. Sinatra — 35,74%
3. Padrino, Hanami — <1%
Рейтинг по числу загрузок
47. 1. Haml — 68,67% (~25)
2. Slim — 31,33% (~10)
Рейтинг по числу Pull Request'ов
48.
49. 1. Haml — 90,65% (max — 15)
2. Slim — 9,35% (max — 2)
Рейтинг по числу
старых Pull Request'ов
50.
51. 1. Slim — 80% (36)
2. Haml — 20% (9)
Рейтинг по числу
коммитов за год
52.
53. 1. Haml — 72,29% (6,260,388)
2. Slim — 27,71% (2,903,900)
Рейтинг по числу загрузок
54. — У обоих проектов невысокая активность разработки
— Haml — лидер по количеству загрузок и числу реквестов
— Slim — лидер по количеству участников и их вкладу
Итог
70. — Инструмент оценки зрелости и поддерживаемости
проекта на Ruby в полноценном режиме
— Анализ зависимостей
— Агрегация с метриками по качеству кода и документации
— Рекомендации проектам по шагам для роста зрелости
— Поддержка Elixir, Python и других языков
Дальнейшие шаги
71.
72.
73. 1. Находим альтернативы на Ruby Toolbox
2. Выбираем достаточно зрелые проекты, тут поможет
Ossert или другой способ разностороннего анализа
3. Выбираем тот, проект чей DSL ближе, не забывая про
рекомендации он Thoughtbot
«Зрелый» цикл оценки
Ruby OSS-проекта
Привет. Меня зовут Долганов Сергей, я работаю backend-разработчиком в Evil Martians.
Сегодня я хочу поговорить о наших &quot;котах в мешке&quot; - гемах.
Именно с Rubygems и Bundler&apos;а создание open-source библиотек для решения
любых задач стало таким популярным.
Использовать сторонний код - это всегда риск, вот, например, советы по этому поводу от thoughtbot.
При этом очень часто ключевым критерием выбора гема становится его популярность,
оцените статистику, из более ~100_000 проектов на Rubygems бОльшая часть загрузок приходится на менее чем 1%.
(слайд)
Сейчас эстафету open-source активности перехватило сообщество Node.js
у них
еще острее проявились кризисы высоких темпов роста кол-ва библиотек.
Вспомним, инцидент с left-pad. Когда из-за отката одной библиотеки в несколько строк упало огромное количество веб-приложений, т.к. дерево зависимостей оказалось сломанным (пауза)
:
Чтобы стало понятнее, почему так происходит - напомню как мы ищем библиотеки на Ruby
мы обычно идем на Ruby Toolbox, где нам в лучшем случае предложат несколько альтернатив.
Остается только выбрать.
Правда для окончательного решения нам придется заглянуть на
Rubygems ...
И на Github, чтобы посмотреть что же именно происходило ... в последнее время...
И глянуть лицензию, Code of Conduct.
Readme и Wiki
(вдруг повезет и будет пример использования и описание DSL).
Т.е. мы очень доверяем собственным &quot;экспертным&quot; суждениям о проектах, при этом имея совсем немного объективной информации для принятия решения.
- libgrader - ныне почивший, инструмент показывал статус по коммитам, лицензию, readme, code of conduct
- Bestgems - инструмент для наблюдения за рейтингом проектов по кол-ву загрузок
- Экспериментальный проект Issue Stats - показывает среднее время реакции на issue
- Dependency CI - пометки от создателя Устарело, Удалено, Не поддерживается
- и, напоследок, самый интересный NPMS (npm search). Поиск с ранж. Поддержка, Качество, Популярность. По каждому из них дается оценка от 0 до 100%. К сожалению, не прозрачен алгоритм оценки и работает только для Node.js.
Действительно, цельной картины по таким данным не складывается.
Сделаем новый агрегатор
классификация проблема весьма сложная, т.к. с одной стороны у нас уже
есть множество аспектов оценки open-source’а:
С другой, используются это средства в разнобой и не всегда, а мне хотелось привнести в этот зоопарк что-то новое и полезное
Так я откопал историю об Open-Source Maturity Model или Модели Зрелости Открытого ПО.
Capability Maturity Model - метод оценки субподрядчиков для разработки ПО
В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения.
мы обычно идем на Ruby Toolbox, где нам в лучшем случае предложат несколько альтернатив.
Остается только выбрать.
Правда для окончательного решения нам придется заглянуть на
Rubygems ...
И на Github, чтобы посмотреть что же именно происходило ... в последнее время...
И глянуть лицензию, Code of Conduct.
Readme и Wiki
(вдруг повезет и будет пример использования и описание DSL).
Т.е. мы очень доверяем собственным &quot;экспертным&quot; суждениям о проектах, при этом имея совсем немного объективной информации для принятия решения.