Code Mining

Code2Code @AI Journey Contest 2021 В рамках AIJ с 7 по 31 октября проводится Fusion Brain Challenge. Участникам предлагается решить 4 задачи в борьбе за призовые в ₽6.5 млн (первое место - до ₽3 млн). Чем это интересно нам? А тем, что первой задачей стоит Code2code Translation, где предлагается попереводить Java<->Python. Участникам предлагается датасет для обучения, в котором содержится 6к решенных задач на каждом из языков, на каждом языке от 1 до 5 вариантов решения. Подробные описания данных, где брать и что курить на странице челленджа. Описание и сорцы также доступны на на Github. Лицензия проекту не выставлена 😱, но по части C2C сорцы под Apache 2.0 & MIT. За наводку на соревы спасибо: @lovedeathtransformers.

Semgrep. Легковесный статический анализатор Если вам нужно что-нибудь находить в исходниках, для исследований или в рамках CI/CD-процессов, то может приглянуться Semgrep. Удобное написание правил, гибкие интеграции, хорошая документация и конечно же свободное программное обеспечение (репа, LGPL-2.1). Есть публичный реестр правил, где можно посмотреть-поучиться и погонять в интерактиве. Внутри примеры на проверки инъекций, xss, xxe, плохого журналирования и т. п. согласно OWASP-классификации. Поддерживает почти 20 языков. Хороших грепов мало не бывает.

Аналитика полного цикла разработки в почти реальном времени Видео: 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 и обновляем все метрики и предсказания на лету. Это оказалось сложно, и я расскажу почему именно, какие ошибки мы допустили, как их исправляли и добились результата, и чего нам это стоило в $$$.

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

Что такое 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

ODS Licensing Course - перенос на 21 октября! По следам Moscow Python Conf мы получили много-много обратной связи по лицензионной боли разработчиков и юристов. Считаем, что всё это должно быть раскрыто в курсе, в связи с этим, берем дополнительное время на подготовку. Если у вас есть вопросы про лицензирование Open Source, пишите в комментариях, будем рады их также включить в наш свободный курс 😊. А пока, следите за новостями, мы их тут много приготовили.

npm install

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

Hacktoberfest 2021 В пятницу, 1 октября, стартовал уже восьмой Hacktoberfest. Это ежегодное событие, которое длится в течение всего октября, призвано привлечь больше внимания и, конечно, больше контрибьюторов в open source проекты. За 4 валидных принятых пулл реквеста в течение октября организаторы раздадут 50 000 футболок с символикой или на выбор участника могут посадить дерево. В мероприятии участвуют проекты, которые хостятся на GitHub или GitLab и имеют топик “hacktoberfest”. Со спамом и мусорными пулл реквестами будут бороться, жуликов исключать. Вся движуха организована компанией DigitalOcean и поддерживается многими другими крутыми ребятами. Если вы не очень с кодом, то можете поддержать выбранные проекты донатом через GitHub Sponsors. Подробная информация и правила на сайте проекта: https://hacktoberfest.digitalocean.com/

Text2Bash Продолжая традицию #видоснавыходные, предлагаем видео с прошедшего в этом году трека CodeMining, про автогенерацию кода на bash по запросам на естественном языке. В докладе Глеб Моргачев из JetBrains делится сокровенным опытом и рассказывает, на что же способны роботы сегодня ;). Тезисы: В рамках конференции NeurIPS 2020 проходило соревнование по генерации bash команд по запросам на естественном языке. Я расскажу об опыте участия нашей команды в этом соревновании, используемых метриках и способах получения обучающей выборки. Также дам краткий обзор подходов, показавших лучшие результаты. Видео: https://www.youtube.com/watch?v=NPfYDDbprtw Лайки, репосты, все дела.

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

Благодарности псто TL;DR: Всем спасибо! Немного осмыслились после Moscow Python Conf++ и хочется выразить благодарность его организаторам и вдохновителям из сообщества Moscow Python. Спасибо Вале Домбровскому и Коле Маркову за приглашение! Конференция душевная, много полезного общения и замечательных ребят, а с ними идей и планов на будущие движухи. Спасибо Пете Ермакову и Наташе Хапаевой, коллегам по ods.ai за интересный круглый стол, на котором мы обсудили взаимодействие Data Science/Python сообществ. Спасибо Михаилу Корнееву, Михаилу Кольцову и Сергею Буткину за ревью кода участников конференции. Получилось живо и хорошо. Наша команда подогнала анализатор, ребята сделали суперский разбор. В очередной раз показана наглядная польза измерения цикломатической сложности в проектах во избежание преждевременных рефакторингов. Спасибо участникам конференции афтепати первого дня конференции за ценнейшие вопросы про лицензирование open source, что заставило нас в ночи дополнить доклад и найти лицензионные нарушения в библиотеке requests ;). Ура!

Лицензирование Питон-приложений В ближайший вторник (28 сентября в 11:25), @alsmirn выступит на очередном Moscow Python Conf++ и расскажет про сабж. Тизер выступления можно поглядеть в записях Moscow Python Podcast, где проблематика также обсуждаласьс в уютной атмосфере кухни Григория Петрова ;). Тезисы. - Рассмотрим общую картину применения Open Source-лицензий в PyPI: общие практики, нисходящие и восходящие тренды выбора новой лицензии, а также случаи её смены. - Ответим на частные вопросы о том, какие лицензии наиболее часто применяются для проектов в разных областях и почему: от веб-приложений и фреймворков до библиотек и утилит в областях машинного обучения (ML) и обработки естественного языка (NLP). - C применением CodeScoring изучим, какие сюрпризы несовместимости лицензий можно поймать, если относиться к задаче лицензирования собственного кода халатно. И в конце концов, поймем, как всего этого избежать и корректно настроить CI/CD в части отслеживания лицензионной чистоты. ЗЫ: говорят, что будет трансляция.

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

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

Что такое 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. Красочные слайды и висящая голова на белом фоне в комплекте. #видоснавыходные #словарькодмайнера

Moscow Python Conf++ 2021 и автоматически анализ цикломатической сложности Вчера рассказали вам про цикломатическую сложность, а сегодня предлагаем поучаствовать в нашей совместной активности с Moscow Python Conf++ 2021 по ревью исходного кода тех участников, которые покажут самые сложные авторские решения. Специально для этого мы совместно с организаторами разработали небольшой сервис, в который можно передать свой репозиторий на автоматический анализ цикломатической сложности. По итогам анализа выводится средняя цикломатическая сложность по проекту и топ-5 самых «сложных» файлов. Ревью кода рекордсменов сложности будет проведено 27 сентября в лайв-режиме. Участник ПК конференции и сооснователь MoscowPython Михаил Корнеев разберет самые веселые кейсы, и покажет, как делать не нужно совсем, или как делать не нужно, если на то нет острой необходимости ;). Сайт конференции: https://conf.python.ru/moscow/2021 Отправить свой репозиторий на анализ цикломатической сложности можно по ссылке: https://mpccomplexity.codescoring.com/

Цикломатическая сложность Мы продолжаем знакомить читателя с базовыми понятиями программной инженерии. Сегодня поговорим про цикломатическую сложность (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;
}

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

Одна из самых крупных конференций про анализ кода MSR объявила очередной хакатон. В этом году, как обычно, четких тем нет, но организаторы предложили, как вариант, несколько направлений: анализ проблем в онбординге новых инженеров, нахождение проблем в коммуникациях и другие. Полный список и описание тут При этом для исследований предлагается использовать GrimoirLab, о нем мы когда-нибудь напишем поподробнее. Регистрация до 18 октября.