nbdime - человеческие дифы для Jupiter Notebooks

А вот и как бы в догонку :P.

Одной из самых приличных заноз в мягких местах дата-саентистов является версионирование Юпитер-ноутбуков.

Да-да, есть мнение, что им даже не место в гите, не говоря о продакшене :)

Тем не менее, тул nbdime дает возможность не только вести версионирование удобно, но и проводить мержи.

Подробнее в официальной документации.

Улучшение Kotlin через поиск аномалий

Ура, мы открываем рубрику #видоснавыходные. И начать хотелось бы с доклада Владимира Коваленко (@vovak) на треке CodeMining @Data Fest Online 2020.

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

Процитируем тезисы:

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

Приятного просмотра!

Одна из самых крупных конференций про анализ кода MSR объявила очередной хакатон.

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

При этом для исследований предлагается использовать GrimoirLab, о нем мы когда-нибудь напишем поподробнее.

Регистрация до 18 октября.

Вышла JDK 17 LTS

Поздравляем Java-мир с выходом новой версии JDK 17!

Релиз тут.
Свежий обзор фич по-английски тут.
Комментарии по-русски здесь.

Если коротко:
- строгая инкапсуляция внутренних элементов JDK во имя обратной совместимости;
- поправлена семантика с плавающей запятой;
- новый интерфейс и реализация генераторов псевдослучайных чисел;
- нативное исполнение Java кода на AArch64;
- апплеты депрекейтед!
- паттерн матчинг, зарождение ;)
- ahead-of-time (AoT) compilation, удаление;
- колдовня с десериализацией.

Цикломатическая сложность

Мы продолжаем знакомить читателя с базовыми понятиями программной инженерии. Сегодня поговорим про цикломатическую сложность (cyclomatic complexity).

Если коротко, то это метрика оценки сложности программы разработанная в 1976 году Томасом МакКейбом (Thomas J. McCabe).

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

M = E − N + 2P,
где:

M — цикломатическая сложность (ЦС),
E — количество рёбер в графе,
N — количество узлов в графе,
P — количество компонент связности.


А чем же это всё может быть полезно?

1. Избыточные значения ЦС указывают на переусложненные участки вашего кода.

2. Комплексное отслеживание ЦС спасает вас от влетания на рефакторинг (внезапно!). 📈

3. Излишне высокие значения ЦС намекают на сложности сопровождения программы.


О пороговых значениях Цикломатической сложности и её отличиях от Когнитивной будем писать в следующих постах. А пока простая задачка, как вы думаете, какая ЦС у кода ниже?

void foo(void)
{
    if (a)
        if (b) 
            x=1;
    else
        x=2;
}

Moscow Python Conf++ 2021 и автоматически анализ цикломатической сложности

Вчера рассказали вам про цикломатическую сложность, а сегодня предлагаем поучаствовать в нашей совместной активности с Moscow Python Conf++ 2021 по ревью исходного кода тех участников, которые покажут самые сложные авторские решения.

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

Ревью кода рекордсменов сложности будет проведено 27 сентября в лайв-режиме. Участник ПК конференции и сооснователь MoscowPython Михаил Корнеев разберет самые веселые кейсы, и покажет, как делать не нужно совсем, или как делать не нужно, если на то нет острой необходимости ;).

Сайт конференции: https://conf.python.ru/moscow/2021
Отправить свой репозиторий на анализ цикломатической сложности можно по ссылке: https://mpccomplexity.codescoring.com/

Что такое Software Composition Analysis (SCA)

Мы уже неоднократно упоминали в этом канале про open source, лицензии и разное вокруг них. Сегодня хотим дать максимально ёмкое и по возможности коротко определение термину, который это всё объединяет — SCA, он же Software Composition Analysis, он же композиционный/компоненты анализ программ/кода/софта/ПО.

SCA — это процесс, где:
1. на вход подаётся код в произвольной форме (репозиторий, директория с файлами, Docker-образ, бинарник и т.п.);
2. этот код сканируется на наличие и зависимость от всех возможных open source компонентов через поиск файлов манифестов (типа package.json, poetry.lock, Dockerfile и т.п.) и через умное сравнение файлов с компонентными базами с примесью всякой магии типа нечётких хэшей;
3. по списку этих компонентов проверяются лицензии и их совместимость с заявленной лицензией самого продукта и между собой;
4. и вишенкой на торте по списку этих компонентов ищутся известные уязвимости по открытым и полуоткрытым базам (например, National Vulnerability Database, Github Advisory и другим).

На вид просто, но по факту внутри множество особенностей и нюансов. Например, на выходе второго шага формируется ещё одна аббревиатура — SBoM, Software Bill of Materials, про его суть, форматы и при чём тут недавний приказ Байдена о кибербезопасности мы расскажем отдельно. Также отдельно расскажем, почему поиск уязвимостей по уже известной компонентной базе (сюрприз-сюрприз) совсем нетривиальная задача.

SCA не так известен среди русскоязычных разработчиков как SAST (статический анализ кода) или DAST (динамический анализ кода), но набирает очки с каждой новой историей найденной уязвимости в распространённой open source библиотеке.

Хорошая новость в том, что множество SCA-like инструментов в той или иной степени присутствуют в экосистемах менеджеров пакетов, IDE, систем контроля версий или в виде отдельных инструментов. К сожалению, не все они удобны, точны или просты в использовании. But we're getting there.

Ну и если короткое описание только разожгло ваше любопытство, посмотрите обзорный доклад про эволюцию подходов SCA с прошедшего Data Fest Online v2: https://www.youtube.com/watch?v=9fydREfnKb4. Красочные слайды и висящая голова на белом фоне в комплекте.

#видоснавыходные #словарькодмайнера

Коротко о том, как менять копирайты в лицензиях ;).

ClickHouse теперь не только база, но и Inc.

Upd: Да, обратите внимание на автора коммита, Тигран Худавердян, управляющий директор и член совета директоров группы компаний «Яндекс». Регистрация для одного коммита. Миленько.

Criticality Score

Одна из фундаментальных проблем проектов с открытым исходным кодом — трагедия общих ресурсов (tragedy of the commons). Пользуются OSS решениями всё больше и больше, но поддержкой многих проектов по-прежнему занимается довольно узкая группа людей, чей ресурс рискует однажды кончиться, что по цепочке может привести к проблемам в зависимом комерческом коде.

К счастью, многие пытаются эту проблему решить. И один из интересных ходов в эту сторону сделал в прошлом году Гугл, выпустив проект Criticality Score — алгоритм оценки open source проектов по их критичности для всей экосистемы. Логика в том, что такой рейтинг на основе такого параметра поможет выявить важные проекты, которым не хватает внимания спонсоров и контрибьюторов.

Алгоритм разработал небезызвестный Роб Пайк, один из создателей таких штук как UTF-8, Unix и языка программирования Go, над которым он и продолжает работать в Google.

На вход алгоритм принимает репозиторий с кодом, ранжирует его по набору параметров, комбинирует всё, подставляя в формулу (и это не просто взвешенная сумма) и выдаёт значение от 0 (наименее важный проект) до 1 (самый критически важный проект). Среди параметров в оценке:
- даты создания и последнего обновления
- число контрибьюторов и разных организаций, к которым они относятся
- частоты коммитов и релизов
- число зависимых проектов

Дополнительно реализованы скрипты, которые анализируют github и выдают топы по каждому языку и общий.

Так первую десятку открывают такие проекты как Node.js, Kubernetes (K8s) и язык программирования Rust, а замыкает её Git, обогнав Linux на 10 позиций.

Реализация алгоритма на python: https://github.com/ossf/criticality_score
Статья Роба Пайка про алгоритм: https://github.com/ossf/criticality_score/blob/main/Quantifying_criticality_algorithm.pdf
Списки критически важных проектов по языкам: https://commondatastorage.googleapis.com/ossf-criticality-score/index.html

Лицензирование Питон-приложений

В ближайший вторник (28 сентября в 11:25), @alsmirn выступит на очередном Moscow Python Conf++ и расскажет про сабж.

Тизер выступления можно поглядеть в записях Moscow Python Podcast, где проблематика также обсуждаласьс в уютной атмосфере кухни Григория Петрова ;).

Тезисы.
- Рассмотрим общую картину применения Open Source-лицензий в PyPI: общие практики, нисходящие и восходящие тренды выбора новой лицензии, а также случаи её смены.

- Ответим на частные вопросы о том, какие лицензии наиболее часто применяются для проектов в разных областях и почему: от веб-приложений и фреймворков до библиотек и утилит в областях машинного обучения (ML) и обработки естественного языка (NLP).

- C применением CodeScoring изучим, какие сюрпризы несовместимости лицензий можно поймать, если относиться к задаче лицензирования собственного кода халатно. И в конце концов, поймем, как всего этого избежать и корректно настроить CI/CD в части отслеживания лицензионной чистоты.

ЗЫ: говорят, что будет трансляция.

Благодарности псто

TL;DR: Всем спасибо!

Немного осмыслились после Moscow Python Conf++ и хочется выразить благодарность его организаторам и вдохновителям из сообщества Moscow Python.

Спасибо Вале Домбровскому и Коле Маркову за приглашение! Конференция душевная, много полезного общения и замечательных ребят, а с ними идей и планов на будущие движухи.

Спасибо Пете Ермакову и Наташе Хапаевой, коллегам по ods.ai за интересный круглый стол, на котором мы обсудили взаимодействие Data Science/Python сообществ.

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

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

Ура!

А тем временем, нас стало овер 100 подписчиков и мы открываем комментарии, как и обещали. Тем не менее, рассказать про наш уютный канальчик коллегам всё-равно стоит ;).

Text2Bash

Продолжая традицию #видоснавыходные, предлагаем видео с прошедшего в этом году трека CodeMining, про автогенерацию кода на bash по запросам на естественном языке. В докладе Глеб Моргачев из JetBrains делится сокровенным опытом и рассказывает, на что же способны роботы сегодня ;).

Тезисы:
В рамках конференции NeurIPS 2020 проходило соревнование по генерации bash команд по запросам на естественном языке. Я расскажу об опыте участия нашей команды в этом соревновании, используемых метриках и способах получения обучающей выборки. Также дам краткий обзор подходов, показавших лучшие результаты.

Видео:
https://www.youtube.com/watch?v=NPfYDDbprtw

Лайки, репосты, все дела.

Hacktoberfest 2021

В пятницу, 1 октября, стартовал уже восьмой Hacktoberfest. Это ежегодное событие, которое длится в течение всего октября, призвано привлечь больше внимания и, конечно, больше контрибьюторов в open source проекты.

За 4 валидных принятых пулл реквеста в течение октября организаторы раздадут 50 000 футболок с символикой или на выбор участника могут посадить дерево.

В мероприятии участвуют проекты, которые хостятся на GitHub или GitLab и имеют топик “hacktoberfest”. Со спамом и мусорными пулл реквестами будут бороться, жуликов исключать.

Вся движуха организована компанией DigitalOcean и поддерживается многими другими крутыми ребятами.

Если вы не очень с кодом, то можете поддержать выбранные проекты донатом через GitHub Sponsors.

Подробная информация и правила на сайте проекта: https://hacktoberfest.digitalocean.com/

Труъ. Боль для тех, кто анализирует JS сорцы 😭

npm install

ODS Licensing Course - перенос на 21 октября!

По следам Moscow Python Conf мы получили много-много обратной связи по лицензионной боли разработчиков и юристов. Считаем, что всё это должно быть раскрыто в курсе, в связи с этим, берем дополнительное время на подготовку.

Если у вас есть вопросы про лицензирование Open Source, пишите в комментариях, будем рады их также включить в наш свободный курс 😊.

А пока, следите за новостями, мы их тут много приготовили.

Что такое Software Bill of Materials (SBOM)

Продолжаем рубрику #словарькодмайнера.

Мы, конечно, живём в своём пузыре, но внутри него немного нелепая аббревиатура SBOM за последний год стала всплывать в разы чаще, чем раньше. Даже Байден про неё говорил, и теперь все IT проекты для госорганов США должны содержать этот самый SBOM, это уже не шутки.

Software Bill of Materials — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта. По каждой компоненте SBOM минимально содержит информацию о названии, версии и лицензии. Некоторые форматы обязательным указывают ещё и тип компонента (например, «фреймворк» или «библиотека»).

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

Составлять и поддерживать SBOM в теории полезно всем проектам. На практике за полным списком зависимостей с учётом транзитивных мало кто следит, не говоря уже об их качестве, перспективах и жизнеспособности. Ещё меньше компаний и программистов обращают внимание на лицензии и их совместимость. К уязвимостям внимания чуть больше, как и инструментов для их обнаружения, например, в том же GitHub или пакетных менеджерах.

Самые известных форматы SBOM это:
- CycloneDX https://cyclonedx.org/
- SPDX https://spdx.dev/
- SWID https://csrc.nist.gov/projects/Software-Identification-SWID
- табличка в Excel 🤭

Иногда SBOM пишут BOM, BoM, SBoM, и вообще как только не угорают. Вообще BOM пришёл из производства, где представляет собой опись всех деталей, из которых состоит продукт.

Для генерации SBOM используется два основных источника информации:
1. манифесты и lock-файлы пакетных менеджеров
2. непосредственный поиск скопированных файлов или частей кода в кодовой базе

Про то, какими инструментами генерировать SBOM и как потом использовать, мы расскажем отдельно.

Подробнее про SBOM советуем читать на сайте National Telecommunications and Information Administration:
https://www.ntia.gov/SBOM

Аналитика полного цикла разработки в почти реальном времени

Видео:
https://www.youtube.com/watch?v=BiLew55dxho

Продолжая традицию #видоснавыходные, в этот раз поговорим об анализе так называемых код-артефактов в применении к анализу жизненного цикла разработки (SDLC, Software Development Lifecycle).

Докладчик Вадим Марковцев, очень так некисло причастный к целой грядке крутейших инструментов выпущенных в open source компаниями source{d} и Athenian. Про них мы ещё обязательно напишем.

Тезисы от автора:

Я работаю в международном стартапе Athenian в качесте Head of Analytics и управляю командой бэкенда SaaS продукта. Мы продаем зарубежным компаниям облачное веб-приложение которое указывает на узкие места процессов разработки, непрерывной интеграции, деплоев, и JIRA. При этом стараемся придерживаться принципов blameless и non-personal, иначе говоря, делаем все возможное чтобы лиды-пользователи не стали сравнивать пиписьки рядовых разработчиков.

Одна из ключевых фишек Athenian - мы непрерывно анализируем поток событий GitHub и JIRA и обновляем все метрики и предсказания на лету. Это оказалось сложно, и я расскажу почему именно, какие ошибки мы допустили, как их исправляли и добились результата, и чего нам это стоило в $$$.

Лайки, репосты, все дела 😏.