Вышла JDK 17 LTS
Поздравляем Java-мир с выходом новой версии JDK 17!
Релиз тут.
Свежий обзор фич по-английски тут.
Комментарии по-русски здесь.
Если коротко:
- строгая инкапсуляция внутренних элементов JDK во имя обратной совместимости;
- поправлена семантика с плавающей запятой;
- новый интерфейс и реализация генераторов псевдослучайных чисел;
- нативное исполнение Java кода на AArch64;
- апплеты депрекейтед!
- паттерн матчинг, зарождение ;)
- ahead-of-time (AoT) compilation, удаление;
- колдовня с десериализацией.
Поздравляем Java-мир с выходом новой версии JDK 17!
Релиз тут.
Свежий обзор фич по-английски тут.
Комментарии по-русски здесь.
Если коротко:
- строгая инкапсуляция внутренних элементов JDK во имя обратной совместимости;
- поправлена семантика с плавающей запятой;
- новый интерфейс и реализация генераторов псевдослучайных чисел;
- нативное исполнение Java кода на AArch64;
- апплеты депрекейтед!
- паттерн матчинг, зарождение ;)
- ahead-of-time (AoT) compilation, удаление;
- колдовня с десериализацией.
Цикломатическая сложность
Мы продолжаем знакомить читателя с базовыми понятиями программной инженерии. Сегодня поговорим про цикломатическую сложность (cyclomatic complexity).
Если коротко, то это метрика оценки сложности программы разработанная в 1976 году Томасом МакКейбом (Thomas J. McCabe).
По сути, цикломатическая сложность (ЦС) части программного кода — количество линейно независимых маршрутов через программный код. Если выражать формулой, то параметр может быть представлен следующим образом:
где:
А чем же это всё может быть полезно?
1. Избыточные значения ЦС указывают на переусложненные участки вашего кода.
2. Комплексное отслеживание ЦС спасает вас от влетания на рефакторинг (внезапно!). 📈
3. Излишне высокие значения ЦС намекают на сложности сопровождения программы.
О пороговых значениях Цикломатической сложности и её отличиях от Когнитивной будем писать в следующих постах. А пока простая задачка, как вы думаете, какая ЦС у кода ниже?
Мы продолжаем знакомить читателя с базовыми понятиями программной инженерии. Сегодня поговорим про цикломатическую сложность (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/
Вчера рассказали вам про цикломатическую сложность, а сегодня предлагаем поучаствовать в нашей совместной активности с 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. Красочные слайды и висящая голова на белом фоне в комплекте.
#видоснавыходные #словарькодмайнера
Мы уже неоднократно упоминали в этом канале про 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. Красочные слайды и висящая голова на белом фоне в комплекте.
#видоснавыходные #словарькодмайнера
YouTube
Алексей Смирнов | Эволюция подходов Software Composition Analysis (SCA)
Data Fest Online 2021
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Алексей Смирнов, Основатель Profiscope.io / CodeScoring
Организатор трека CodeMining @ods.ai
Опыт применения инструментов из области композиционного анализа программного…
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Алексей Смирнов, Основатель Profiscope.io / CodeScoring
Организатор трека CodeMining @ods.ai
Опыт применения инструментов из области композиционного анализа программного…
Коротко о том, как менять копирайты в лицензиях ;).
ClickHouse теперь не только база, но и Inc.
Upd: Да, обратите внимание на автора коммита, Тигран Худавердян, управляющий директор и член совета директоров группы компаний «Яндекс». Регистрация для одного коммита. Миленько.
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
Одна из фундаментальных проблем проектов с открытым исходным кодом — трагедия общих ресурсов (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 в части отслеживания лицензионной чистоты.
ЗЫ: говорят, что будет трансляция.
В ближайший вторник (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 ;).
Ура!
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
Лайки, репосты, все дела.
Продолжая традицию #видоснавыходные, предлагаем видео с прошедшего в этом году трека CodeMining, про автогенерацию кода на bash по запросам на естественном языке. В докладе Глеб Моргачев из JetBrains делится сокровенным опытом и рассказывает, на что же способны роботы сегодня ;).
Тезисы:
В рамках конференции NeurIPS 2020 проходило соревнование по генерации bash команд по запросам на естественном языке. Я расскажу об опыте участия нашей команды в этом соревновании, используемых метриках и способах получения обучающей выборки. Также дам краткий обзор подходов, показавших лучшие результаты.
Видео:
https://www.youtube.com/watch?v=NPfYDDbprtw
Лайки, репосты, все дела.
YouTube
Глеб Моргачёв | Text2Bash: как мы участвовали в соревновании NeurIPS
Data Fest Online 2021
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Глеб Моргачев, Data Scientist @JetBrains
В рамках конференции NeurIPS 2020 проходило соревнование по генерации bash команд по запросам на естественном языке. Я расскажу…
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Глеб Моргачев, Data Scientist @JetBrains
В рамках конференции NeurIPS 2020 проходило соревнование по генерации bash команд по запросам на естественном языке. Я расскажу…
Hacktoberfest 2021
В пятницу, 1 октября, стартовал уже восьмой Hacktoberfest. Это ежегодное событие, которое длится в течение всего октября, призвано привлечь больше внимания и, конечно, больше контрибьюторов в open source проекты.
За 4 валидных принятых пулл реквеста в течение октября организаторы раздадут 50 000 футболок с символикой или на выбор участника могут посадить дерево.
В мероприятии участвуют проекты, которые хостятся на GitHub или GitLab и имеют топик “hacktoberfest”. Со спамом и мусорными пулл реквестами будут бороться, жуликов исключать.
Вся движуха организована компанией DigitalOcean и поддерживается многими другими крутыми ребятами.
Если вы не очень с кодом, то можете поддержать выбранные проекты донатом через GitHub Sponsors.
Подробная информация и правила на сайте проекта: https://hacktoberfest.digitalocean.com/
В пятницу, 1 октября, стартовал уже восьмой Hacktoberfest. Это ежегодное событие, которое длится в течение всего октября, призвано привлечь больше внимания и, конечно, больше контрибьюторов в open source проекты.
За 4 валидных принятых пулл реквеста в течение октября организаторы раздадут 50 000 футболок с символикой или на выбор участника могут посадить дерево.
В мероприятии участвуют проекты, которые хостятся на GitHub или GitLab и имеют топик “hacktoberfest”. Со спамом и мусорными пулл реквестами будут бороться, жуликов исключать.
Вся движуха организована компанией DigitalOcean и поддерживается многими другими крутыми ребятами.
Если вы не очень с кодом, то можете поддержать выбранные проекты донатом через GitHub Sponsors.
Подробная информация и правила на сайте проекта: https://hacktoberfest.digitalocean.com/
Hacktoberfest
Hacktoberfest 2024
Hacktoberfest: a month-long celebration of open-source projects, their maintainers, and the entire community of contributors.
Forwarded from 🇺🇦 Math.random(): javascript community via @like
This media is not supported in your browser
VIEW IN TELEGRAM
npm install
ODS Licensing Course - перенос на 21 октября!
По следам Moscow Python Conf мы получили много-много обратной связи по лицензионной боли разработчиков и юристов. Считаем, что всё это должно быть раскрыто в курсе, в связи с этим, берем дополнительное время на подготовку.
Если у вас есть вопросы про лицензирование Open Source, пишите в комментариях, будем рады их также включить в наш свободный курс 😊.
А пока, следите за новостями, мы их тут много приготовили.
По следам 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
Продолжаем рубрику #словарькодмайнера.
Мы, конечно, живём в своём пузыре, но внутри него немного нелепая аббревиатура 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. Про них мы ещё обязательно напишем.
Тезисы от автора:
Лайки, репосты, все дела 😏.
Видео:
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 и обновляем все метрики и предсказания на лету. Это оказалось сложно, и я расскажу почему именно, какие ошибки мы допустили, как их исправляли и добились результата, и чего нам это стоило в $$$.
Лайки, репосты, все дела 😏.
YouTube
Вадим Марковцев | Аналитика полного цикла разработки в *почти* реальном времени
Data Fest Online 2021
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Вадим Марковцев, Head of Analytics @Athenian
Я работаю в международном стартапе Athenian в качесте Head of Analytics и управляю командой бэкенда SaaS продукта. Мы продаем…
Code Mining track https://ods.ai/tracks/code-mining-df2021
Спикер: Вадим Марковцев, Head of Analytics @Athenian
Я работаю в международном стартапе Athenian в качесте Head of Analytics и управляю командой бэкенда SaaS продукта. Мы продаем…
Semgrep. Легковесный статический анализатор
Если вам нужно что-нибудь находить в исходниках, для исследований или в рамках CI/CD-процессов, то может приглянуться Semgrep.
Удобное написание правил, гибкие интеграции, хорошая документация и конечно же свободное программное обеспечение (репа, LGPL-2.1).
Есть публичный реестр правил, где можно посмотреть-поучиться и погонять в интерактиве. Внутри примеры на проверки инъекций, xss, xxe, плохого журналирования и т. п. согласно OWASP-классификации.
Поддерживает почти 20 языков.
Хороших грепов мало не бывает.
Если вам нужно что-нибудь находить в исходниках, для исследований или в рамках CI/CD-процессов, то может приглянуться Semgrep.
Удобное написание правил, гибкие интеграции, хорошая документация и конечно же свободное программное обеспечение (репа, LGPL-2.1).
Есть публичный реестр правил, где можно посмотреть-поучиться и погонять в интерактиве. Внутри примеры на проверки инъекций, xss, xxe, плохого журналирования и т. п. согласно OWASP-классификации.
Поддерживает почти 20 языков.
Хороших грепов мало не бывает.
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.
В рамках AIJ с 7 по 31 октября проводится Fusion Brain Challenge.
Участникам предлагается решить 4 задачи в борьбе за призовые в ₽6.5 млн (первое место - до ₽3 млн).
Чем это интересно нам? А тем, что первой задачей стоит Code2code Translation, где предлагается попереводить Java<->Python.
Участникам предлагается датасет для обучения, в котором содержится 6к решенных задач на каждом из языков, на каждом языке от 1 до 5 вариантов решения.
Подробные описания данных, где брать и что курить на странице челленджа.
Описание и сорцы также доступны на на Github. Лицензия проекту не выставлена 😱, но по части C2C сорцы под Apache 2.0 & MIT.
За наводку на соревы спасибо: @lovedeathtransformers.