Нас часто спрашивают, где же можно почитать квинтэссенцию State of the Art (да-да, та самая SOTA) по теме Data-Driven Software Engineering.

И мы ответим, конечно же материалы с конференций, публикации с которых мы также будем освещать на нашем скормненьком канале в ближайшем будущем.

1. Mining Software Repositories
http://www.msrconf.org/

2. Source Code Analysis and Manipulation
http://www.ieee-scam.org/2020/

3. The International Conference on Software Maintenance and Evolution (ICSME)
https://icsme2020.github.io/ и https://conferences.computer.org/icsm

4. Machine Learning (ML) for Systems
http://mlforsystems.org/

5. Workshop on Computer-Assisted Programming (NeurIPS)
https://capworkshop.github.io/

Copilot может внести до 40% ошибок и уязвимостей в ваш код

Мы запустили канал несколько позже чем это задумывалось и не пишем уже анонсы про такие вещи как Tabnine или Github Copilot. А вот про их обновления или особенности, — с удовольствием!

Тема внесения ошибок и уязвимостей через автогенерацию старая, но не избитая. И сейчас только набирает тренды. Многие в последнее время задаются вопросом о том, как бы так подпортить наборы данных, чтобы работа модели была небезопасной.

Так вот, группа исследователей поисследовала, написала (https://arxiv.org/abs/2108.09293) и выяснила, что можно ничего и не портить, а просто использовать инструменты обученные на Open Source (внезапно ;).

Было сформировано 89 различных сценариев в которых использовались предложения кода из Copilot, в рамках которых написано 1600 программ. По результату проведения ревью, исследователи выяснили, что почти 40% программ получились уязвимыми тем или иным путем (подробнее в статье).

В заключение процитируем:

Overall, Copilot’s response to our scenarios is mixed from a security standpoint, given the large number of generated vulnerabilities (across all axes and languages, 39.33 % of the top and 40.48 % of the total options were vulnerable).

Ждем существенных обновлений в Copilot по качеству и очередных срывов покровов ;).

ODS Open Source Licensing Course

Всё-таки не зря мы писали новость про лицензии ;)

Завтра наш трек CodeMining участвует в линейке курсов в рамках ODS Course Fest #1.

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

Следить за расписанием анонсов можно тут: https://ods.ai/events/course_fest_1/Timing.

А вживую будет стрим на канале ODS. Подключайтесь!

Таки да, случился анонс курса по лицензированию на ODS Course Fest #1.

Да, он будет с Data Science уклоном, но я обещал своему адвокату, что материал будет понятен всем ;).

Посмотреть анонс можно здесь.

Обратную связь и пожелания буду рад принять лично — @alsmirn.

Делитесь информацией с коллегами, кому может быть полезным.

The Matrix Resurrections

Мы всё понимаем, но не написать об этом не можем ;)

Вышел первый трейлер грядущей Матрицы.

Пумц: https://www.youtube.com/watch?v=9ix7TUGVYIo.

Fast Inverse Square Root (Q_rsqrt)

Увы, но немногие современные разработчики знают, что вычисление корней медленнее чем возведение в степень. И уж совсем отдельные 🤓 знают трюки, как ускорить эти процессы, пусть и приблизительно 😉.

Алгоритм быстрого обратного квадратного корня стал известен, когда небезызвестная компания id Software открыла исходники движка Quake 3 Arena.

Делимся потрясающим и 🔥 видео, которое проливает свет на этот вопрос: https://www.youtube.com/watch?v=p8u_k2LIZyo.

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

JetBrains DataSpell (EAP)

Ну что, кто-то дождался. JetBrains анонсировали выход новой IDE для Data Science. Фичи можно посмотреть тут.

Пока только EAP, т. е. программа раннего доступа. Если всё пройдет хорошо, то появится и платная версия.

Поживем-увидим.

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 подписчиков и мы открываем комментарии, как и обещали. Тем не менее, рассказать про наш уютный канальчик коллегам всё-равно стоит ;).