Over 3.1 million fake "stars" on GitHub projects used to boost rankings (Рубрика #Humor)
Прочитал сегодня статью про накручивание рейтинга в GitHub. По-факту, здесь примерно та же проблема, что в других соцсетях, где популярност, лайики и ззвезды несут своим обладателям дополнительную ценность. В GitHub такой ценностью является то, что звезды воспринимаются как proxy метрика популярности проекта в коммьюнити и его дальнейшие перспективы. В середине декабря появилось исследование от Carnegie Mellon University, Socket Inc, North Carolina State University на эту тему. В нем ученые сначала разработали интструмент 'StarScout', который проанализировал 20 ТБ данных GitHub и первоначально обнаружил 4,5 миллиона подозрительных звезд от 1,32 миллиона аккаунтов. После фильтрации для повышения точности, окончательный подсчет показал 3,1 миллиона поддельных звезд от 278 000 аккаунтов в 15 835 репозиториях. Результаты исследования показывают, что проблема достигла пика в 2024 году, когда примерно 15,8% репозиториев, имевших более 50 звезд в июле 2024 года, были вовлечены в эти обманные практики. Эффективность инструмента обнаружения StarScout была подтверждена тем, что к октябрю 2024 года GitHub удалил 91% выявленных подозрительных репозиториев и 62% неаутентичных аккаунтов.
Вот список находок авторов исследование
В итоге, имеем вывод, что звезды - это ненадежный сигнал для тех, кто практикует использование или контрибьют в open-source. Требуется использовать и другие сигналы, например из OpenSSF Scorecard, для которой есть отдельный whitepaper.
#Software #Management
Прочитал сегодня статью про накручивание рейтинга в GitHub. По-факту, здесь примерно та же проблема, что в других соцсетях, где популярност, лайики и ззвезды несут своим обладателям дополнительную ценность. В GitHub такой ценностью является то, что звезды воспринимаются как proxy метрика популярности проекта в коммьюнити и его дальнейшие перспективы. В середине декабря появилось исследование от Carnegie Mellon University, Socket Inc, North Carolina State University на эту тему. В нем ученые сначала разработали интструмент 'StarScout', который проанализировал 20 ТБ данных GitHub и первоначально обнаружил 4,5 миллиона подозрительных звезд от 1,32 миллиона аккаунтов. После фильтрации для повышения точности, окончательный подсчет показал 3,1 миллиона поддельных звезд от 278 000 аккаунтов в 15 835 репозиториях. Результаты исследования показывают, что проблема достигла пика в 2024 году, когда примерно 15,8% репозиториев, имевших более 50 звезд в июле 2024 года, были вовлечены в эти обманные практики. Эффективность инструмента обнаружения StarScout была подтверждена тем, что к октябрю 2024 года GitHub удалил 91% выявленных подозрительных репозиториев и 62% неаутентичных аккаунтов.
Вот список находок авторов исследование
Research Question 1: How prevalent are fake stars in GitHub?
1) Fraudulent starring activities start to gain momentum in 2022 and have been surging since 2024.
2) Even a small portion of fake stargazers can greatly distort stars as a repository popularity signal.
3) Only a few repositories with fake star campaigns are published in package registries such as npm and PyPI. Even fewer are widely adopted.
Research Question 2: What are the characteristics of GitHub repositories with fake star campaigns?
4) Most repositories with fake star campaigns are short-lived (only a few days of activity).
5) The majority of GitHub repositories with fake star campaigns seem related to pirated software, game cheats, and cryptocurrency bots. However, it is likely that they are actually malware clickbaits.
Research Question 3: What are the characteristics of GitHub accounts that participated in fake star campaigns?
6) Compared to average GitHub users, accounts in fake star campaigns are slightly more likely to have an empty profile, but the differences are relatively small.
7) At least 60% of the accounts that participated in fake star campaigns have trivial activity patterns.
Research Question 3: To what extent are fake stars effective in promoting the target GitHub repositories?
8) Buying fake stars may help a repository gain real attention in the short-term future (i.e., less than two months), but the effect is 3–4x smaller compared to real stars; it has a negative effect in the long term.
В итоге, имеем вывод, что звезды - это ненадежный сигнал для тех, кто практикует использование или контрибьют в open-source. Требуется использовать и другие сигналы, например из OpenSSF Scorecard, для которой есть отдельный whitepaper.
#Software #Management
👍11🔥7❤3⚡2
The elearning designer's handbook (E-learning. Пошаговое руководство по разработке электронного обучения) (Рубрика #Education)
Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше.
1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов
2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (чтобы дом достроился и был сдан, а не остался брошенным недостроем )
3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (лучше по матрице RACI, но он про это не говорит ). Важно построить график проекта и отметить ключевые точки и контролировать их прохождение и так далее
4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него.
5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям.
6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами
7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками.
В общем и целом, это очень базовая книга по созданию электронных курсов, у которой на английском вышло второе издание аж в 2020 году, а та версия, которую читал я, была издана на языке Шекспира в далеком 2018 году. Кажется, что с тех пор эта информация про создание курсов стала просто базой:)
P.S.
Кстати, у автора есть свой сайт TimSlade.com
#Education #Writing
Эта книга Тима Слейда попалась мне на глаза случайно и хотя она рассказывает про создание онлайн курсов, но мне это показалось отчасти близким к написанию книги:) По-итогу, я прочел книгу за пару часов в силу ее небольших размеров и общей очевидности идей. Если рассказывать про книгу кратко, то она состоит из предисловия, вступления, пяти основных шагов и финального напутствия о том, что надо продолжать двигаться дальше.
1) Предисловие - здесь автор рассказывает про свой путь к педагогическому дизайнеру электронного обучения (я даже не знал, что это так называется до того, как прочел книгу). Тим изначально был subject matter expert много лет, а потом его попросили сделать курс для обучения других и ... так его карьера сделала поворот к созданию курсов
2) Вступление - здесь автор на пальцах показывает, что создание курса похоже на строительство дома. Он объясняет, что нужно понимание кто такие бизнес-заказчики, кто такие subject matter experts и зачем нужен план (
3) Шаг первый - создание плана проекта. По-факту, если вы знаете про проектное управление и руководили проектами, то тут вы не узнаете почти ничего нового. Автор рассказывает про то, что надо определиться со scope проекта, участниками, их зоной ответственнсти (
4) Шаг второй - составление раскадровки курса. В этой части автор говорит о том, что лучше не делать курс целиком, а пользоваться методом прогрессивного JPEG, когда содержимое курса сначала набрасывается в черновом верхнеуровневом варианте, а дальше показывается стейкхолдерам. Это позволяет на начальном этапе провалидировать концепцию курса и получить ценную обратную связь. Этот этап позволяет задать канву курса и зафиксировать примерно материалы, что войдут в него.
5) Шаг третий - разработка курса. На этом шаге надо пойти и сделать сами материалы. Когда есть понятная канва и структура, то это должно быть не таким сложным делом. Главное сломать страх чистового листа и начинать работать над деталями курса по частям.
6) Шаг четвертый - проверка и контроль качества курса. Здесь автор рассказывает про базовые вопросы тестирования самого продукта, потом выкатку на бета-тестеров, а также проверку удобства получившегося продукта с точки зрения user experience через интервью с бета-тестерами
7) Шаг пятый - запуск курса. Автор говорит о том, что иногда курсы могут публиковаться в LMS системах, а иногда это просто html странички в интернете. В любом случае автору курса надо понимать на какой платформе он публикует курс, как он сможет его дорабатывать, а также где сможет посмотреть аналитику по прохождению курса учениками.
В общем и целом, это очень базовая книга по созданию электронных курсов, у которой на английском вышло второе издание аж в 2020 году, а та версия, которую читал я, была издана на языке Шекспира в далеком 2018 году. Кажется, что с тех пор эта информация про создание курсов стала просто базой:)
P.S.
Кстати, у автора есть свой сайт TimSlade.com
#Education #Writing
Tim Slade | Award-Winning Freelance eLearning Designer
Hi, I'm Tim Slade. I'm a speaker, author and award-winning freelance eLearning designer.
👍7❤5🔥3
Code of Leadership #27 - Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет (Рубрика #Management)
В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music.
На общение мы потратили чуть больше часа и успели обсудить следующие темы
- Где Витя родился, учился и как попал в IT
- Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад
- Как прошла технологическая трансформация при переходе со старого решения на react
- Как команда росла и пришлось делать организационные изменения
- Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть
- Как выглядел проект ребрендинга в общем и что надо было сделать технической команде
- Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной
- Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие
В общем, выпуск получился очень плотный по темам, поэтому думаю, что вам не придется скучать при просмотре:)
P.S.
Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты.
#Management #Leadership #Software #Processes #Retrospective #ChangeManagement
В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и личные кабинеты физических лиц. А начинал Витя с позиции инженера и занимался формами для привлечения клиентов. Эпизод доступен в Youtube, Podster, Yandex Music.
На общение мы потратили чуть больше часа и успели обсудить следующие темы
- Где Витя родился, учился и как попал в IT
- Как он переехал из Нижнего Новгорода в Москву, приняв офер Т-Банка 12 лет назад
- Как прошла технологическая трансформация при переходе со старого решения на react
- Как команда росла и пришлось делать организационные изменения
- Как выглядели вызовы в 2022-2023 годах и как их удалось с успехом преодолеть
- Как выглядел проект ребрендинга в общем и что надо было сделать технической команде
- Как вообще подходить к позиции технического руководителя и чем она отличается от инженерной
- Какие советы можно дать вкатывающимся в IT, а также продолжающим свое профессиональное развитие
В общем, выпуск получился очень плотный по темам, поэтому думаю, что вам не придется скучать при просмотре:)
P.S.
Я с Витей работаю 8 лет, с самого своего первого дня работы в компании и могу сказать, что он прошел большой путь от хорошего инженера до крутого технического руководителя. До последнего года он был моим прямым reportee и я как мог помогал этому случиться. В последний год он мой skip level reportee, но это ему не мешает показывать классные результаты.
#Management #Leadership #Software #Processes #Retrospective #ChangeManagement
YouTube
Code of Leadership #27 - Interview with Viktor Firsov about Web development evolution at T-Bank
В этом выпуске подкаста ко мне пришел Виктор Фирсов для того, чтобы обсудить как эволюционировали веб-интерфейсы Т-Банка и как он всеми силами помогал этому. Сейчас Виктор является техническом руководителем 100+ инженеров, что отвечают за публичный веб и…
🔥15❤7👍4
Developer Productivity for Humans, Part 8: Creativity in Software Engineering (Рубрика #Management)
Продолжаю читать статьи от ребят из Google на тему продуктивности инженеров, а точнее в этот раз это статья про креативность. Я уже рассказывал про колонку про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы исследования сделали обзор предыдущих статей и литературы и отметили, что креативность - это качество крутых инженеров
2) Но вот что значит креативность в software engineering - это большой вопрос, который авторы по привычке решили выяснить, начав с людей
3) Если кратко, то их выводы были в том, что креативность в разработке - это умное переиспользование, а не полная новизна, как принято в других сферах
4) Авторы проводили это исследование для того, чтобы понять как лучше измерять и поддреживать креативность инженеров - их интересует именно, что делает кретивным процесс разработки, а не какие персональные качества делают креативными конкретных инженеров
5) Свое исследование они решили сделать количественным, но поделили его на отдельные фазы
- Feedback studies, когда обратную связь нужно было дать непосредственно, когда происходило определенное событие
- Elicitation studies, когда нужно было сделать фотографию креативного момента раз в неделю (это мог был скриншот с сессии брейншторма, скриншот дизайн-документа, скриншот кода, который подвергся жестокому рефакторингу и так далее)
- Follow-up interviews, когда исследователи задавали вопросы по фотографиям с воспоминаниями и просили инженеров описать в чем именно состояли моменты креативности
- Post analysis, когда исследователи идентифицировали общие темы из собранных данных, такие как: повторное использование, инфраструктура, knhowledge sharing, обучение, новизна
- Объединение полученных тем с конкретными моментами в developer workflow, которые помогли исследователям получить более глубокое понимание опыта участников исследований
6) В итоге, авторы выделили три ключевые темы, которые относятся к креативности
- Коллаборация и брейншторминг взращивают креативность среди разработчиков
- Problem solving с исследованием проблемной области через изучение и исследование создают сцену для креативности
- Умное переиспользование и рекомбинация существующего кода полезным способом является основным атрибутом креативности в software engineering. Суть в том, что не надо быть новатором в коде, а лучше сделать решить сложную задачу простым и понятным способом, который потом будет легко поддерживать и развивать
7) Интересно, что авторы видят противоречие между продуктивностью и креативностью, когда чрезмерно фокусируясь на продуктивности не остается времени на креативные решения. Например, часто инженеры отмечали, что коллаборация с коллегами для решения сложной проблемы или сложный рефаторинг являются креативными, но редко когда такое менеджеры считают продуктивным:) Авторы формулируют гипотезу, что продуктивность - это про ближайшее время, а креативность про долговременный эффект от качественного кода.
Напоследок авторы отмечают, что
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Processes #Creativity
Продолжаю читать статьи от ребят из Google на тему продуктивности инженеров, а точнее в этот раз это статья про креативность. Я уже рассказывал про колонку про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы исследования сделали обзор предыдущих статей и литературы и отметили, что креативность - это качество крутых инженеров
2) Но вот что значит креативность в software engineering - это большой вопрос, который авторы по привычке решили выяснить, начав с людей
3) Если кратко, то их выводы были в том, что креативность в разработке - это умное переиспользование, а не полная новизна, как принято в других сферах
4) Авторы проводили это исследование для того, чтобы понять как лучше измерять и поддреживать креативность инженеров - их интересует именно, что делает кретивным процесс разработки, а не какие персональные качества делают креативными конкретных инженеров
5) Свое исследование они решили сделать количественным, но поделили его на отдельные фазы
- Feedback studies, когда обратную связь нужно было дать непосредственно, когда происходило определенное событие
- Elicitation studies, когда нужно было сделать фотографию креативного момента раз в неделю (это мог был скриншот с сессии брейншторма, скриншот дизайн-документа, скриншот кода, который подвергся жестокому рефакторингу и так далее)
- Follow-up interviews, когда исследователи задавали вопросы по фотографиям с воспоминаниями и просили инженеров описать в чем именно состояли моменты креативности
- Post analysis, когда исследователи идентифицировали общие темы из собранных данных, такие как: повторное использование, инфраструктура, knhowledge sharing, обучение, новизна
- Объединение полученных тем с конкретными моментами в developer workflow, которые помогли исследователям получить более глубокое понимание опыта участников исследований
6) В итоге, авторы выделили три ключевые темы, которые относятся к креативности
- Коллаборация и брейншторминг взращивают креативность среди разработчиков
- Problem solving с исследованием проблемной области через изучение и исследование создают сцену для креативности
- Умное переиспользование и рекомбинация существующего кода полезным способом является основным атрибутом креативности в software engineering. Суть в том, что не надо быть новатором в коде, а лучше сделать решить сложную задачу простым и понятным способом, который потом будет легко поддерживать и развивать
7) Интересно, что авторы видят противоречие между продуктивностью и креативностью, когда чрезмерно фокусируясь на продуктивности не остается времени на креативные решения. Например, часто инженеры отмечали, что коллаборация с коллегами для решения сложной проблемы или сложный рефаторинг являются креативными, но редко когда такое менеджеры считают продуктивным:) Авторы формулируют гипотезу, что продуктивность - это про ближайшее время, а креативность про долговременный эффект от качественного кода.
Напоследок авторы отмечают, что
There remains a need to better understand what creativity means in the context of software engineering, how it affects the whole software development process, and how factors like work location or AI tools might influence it.
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Processes #Creativity
🔥8👍6❤2
Enhancing Software Design and Developer Experience Via LLMs (Рубрика #ML)
Иногда меня спрашивают почему я читаю whitepapers преимущественно от bigtech компаний. Часто я отвечаю, что они редко разачаровывают с точки зрения качества. Но тут я решил дать шанс другой статье, а точнее "Enhancing Software Design and Developer Experience Via LLMs" с "ASE '24: Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering"
Абстракт статьи звучит неплохо
- Первоначальное внимание уделяется способности моделей понимать концепции дизайна высокого уровня
- Впоследствии исследование переходит к расширенной генерации программных артефактов
- В конце вводятся методы, специфичные для организации или задачи, для повышения производительности и опыта разработчиков программного обеспечения.
Но если читать дальше, то складывается ощущение, что саму статью писал LLM:) И из всего плана исследования сделан только обзор работы LLMs для генерации кода.
А дальше я расскажу подробности.
Во введении идет речь, что сейчас LLM обычно дают подсказки уже после коммитов, а хотелось бы давать их или на ранних стадиях или в рантайме. Для этого автор рассказывает, что создание софта - это не только про написание кода и там есть еще куча этапов CI/CD. Поэтому план исследования выглядит так
1) Understand LLM - How LLMs handle code and natural language
2) LLM for software design (Plan-Code-Build-Test), где автор выделил фазы
- Post commit. Identify problems and provide solutions
- Pre-commit. Predict problems
- Line level suggestion. Predict problems & provide hints while developers are working
3) ML Plugin. Develop a framework that can provide ML hints to developers
4) Generalize the framework. Apply the framework in other software development processes
Интересно, что автор фокусируется на использовании в своих предсказаниях логов
Во второй части статьи автор рассказывает базу про трансформеры, а также приводится обзор других статей, что исследовали эффективность LLMs при разработке софта.
В третьей части автор раскрывает карты и рассказывает про модель, которую он планирует использовать ... и это откопаннаястюардесса, а точнее методология Model-Driven Architecture (MDA) от Object Management Group прямиком из начала двухтысячных. Сама методология предполагает использование трех шагов
1) Создание Platform-Independent Model (PIM)
2) Преобразование PIM в Platform-Specific Model (PSM)
3) И дальше генерация кода для выполнения
Автор исследования стремится предоставить решения, специфичные для организации или задачи, адаптированные к различным контекстам компании, а также структуру, способную обобщать эти решения для более широкого применения в индустрии программного обеспечения. Чтобы достичь этого, автор планирует сначала разработать PIM на основе домена, а затем PSM, которые отражают конкретные настройки и требования различных компаний. Впоследствии можно усовершенствовать первоначальную PIM на основе отзывов от PSM, тем самым создав стандартизированную архитектурную структуру, которую можно будет использовать в будущих проектах внутри определенного домена.
В четвертой части статьи авто рассказывает про то, как будет проиходить оценка работы моделей для PSM, где предплагается провести вычислительные эксперименты для предварительной обработки данных и оценки проектирования и процесса обучения модели. Это включает в себя файнтюнинг моделей и сравнение их производительности с другими предложенными моделями.
В пятой части автор рассказывает, что из всего описанного пока готов только обзор использования LLM при написании кода:)
P.S.
В итоге, у нас whitepaper уровня курсовой работы студента, что он нагенерировал вместе с GPT-4 за пару вечеров - обзор нормальный, а все остальное в планах:)
#AI #ML #Software
Иногда меня спрашивают почему я читаю whitepapers преимущественно от bigtech компаний. Часто я отвечаю, что они редко разачаровывают с точки зрения качества. Но тут я решил дать шанс другой статье, а точнее "Enhancing Software Design and Developer Experience Via LLMs" с "ASE '24: Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering"
Абстракт статьи звучит неплохо
- Первоначальное внимание уделяется способности моделей понимать концепции дизайна высокого уровня
- Впоследствии исследование переходит к расширенной генерации программных артефактов
- В конце вводятся методы, специфичные для организации или задачи, для повышения производительности и опыта разработчиков программного обеспечения.
Но если читать дальше, то складывается ощущение, что саму статью писал LLM:) И из всего плана исследования сделан только обзор работы LLMs для генерации кода.
А дальше я расскажу подробности.
Во введении идет речь, что сейчас LLM обычно дают подсказки уже после коммитов, а хотелось бы давать их или на ранних стадиях или в рантайме. Для этого автор рассказывает, что создание софта - это не только про написание кода и там есть еще куча этапов CI/CD. Поэтому план исследования выглядит так
1) Understand LLM - How LLMs handle code and natural language
2) LLM for software design (Plan-Code-Build-Test), где автор выделил фазы
- Post commit. Identify problems and provide solutions
- Pre-commit. Predict problems
- Line level suggestion. Predict problems & provide hints while developers are working
3) ML Plugin. Develop a framework that can provide ML hints to developers
4) Generalize the framework. Apply the framework in other software development processes
Интересно, что автор фокусируется на использовании в своих предсказаниях логов
This project aims to advance the analysis and utilization of logs geneated during software development and testing. By implementing real-time log analysis and auto-suggestion features, the research seeks to improve the post-test phase and provide actionable insights for future testing, simulation, and maintenance activities
Во второй части статьи автор рассказывает базу про трансформеры, а также приводится обзор других статей, что исследовали эффективность LLMs при разработке софта.
В третьей части автор раскрывает карты и рассказывает про модель, которую он планирует использовать ... и это откопанная
1) Создание Platform-Independent Model (PIM)
2) Преобразование PIM в Platform-Specific Model (PSM)
3) И дальше генерация кода для выполнения
Автор исследования стремится предоставить решения, специфичные для организации или задачи, адаптированные к различным контекстам компании, а также структуру, способную обобщать эти решения для более широкого применения в индустрии программного обеспечения. Чтобы достичь этого, автор планирует сначала разработать PIM на основе домена, а затем PSM, которые отражают конкретные настройки и требования различных компаний. Впоследствии можно усовершенствовать первоначальную PIM на основе отзывов от PSM, тем самым создав стандартизированную архитектурную структуру, которую можно будет использовать в будущих проектах внутри определенного домена.
В четвертой части статьи авто рассказывает про то, как будет проиходить оценка работы моделей для PSM, где предплагается провести вычислительные эксперименты для предварительной обработки данных и оценки проектирования и процесса обучения модели. Это включает в себя файнтюнинг моделей и сравнение их производительности с другими предложенными моделями.
В пятой части автор рассказывает, что из всего описанного пока готов только обзор использования LLM при написании кода:)
P.S.
В итоге, у нас whitepaper уровня курсовой работы студента, что он нагенерировал вместе с GPT-4 за пару вечеров - обзор нормальный, а все остальное в планах:)
#AI #ML #Software
www.omg.org
Model Driven Architecture (MDA) | Object Management Group
Model Driven Architecture® (MDA®) is an approach to software design, development and implementation led by the OMG. MDA provides guidelines for structuring specifications, which are expressed as models.
😁12❤4👍4
Fundamentals of Enterprise Architecture (Рубрика #Architecture)
Прочитал на каникулах книгу Tanu McCabe, что была посвящена корпоративной архитектуре и вышла квартал назад, а точнее в сентябре 2024 года. Мое мнение, что корпоративная архитектура - это удел корпораций, что сначала запускали devops трансформации, потом digital трансформации, а теперь все гонятся за AI. В общем, если у вас не технологическая компания, то enterprise architecture вам может и пригодится. В этой книге Tanu McCabe делает подход к снаряду, чтобы придать корпоративной архитектуре современный вид и теоретически у нее получается неплохо, но неясно как это стоит осуществлять на практике, хотя каждая глава сопровождается практически анекдотами, где приводятся примеры плохой реализации корпоративной архитектуры и хорошие варианты, что соответствуют современным тенденциям. И у нее достаточно неплохо это получается
Если говорить про основные мысли книги, то они изложены в первой главе, где затрагиваются следующие моменты
1) Зачем нужна корпоративная архитектура? И автор отвечает, что она нужна для
- Избегания изоляции отдельных частей организации (avoiding silos)
- Избегания хаоса - здесь идет речь про борьбу с complexity через стандарты
- Избегания технического долга, который мешает инновациям и бизнес гибкости
Все три вещи выше являются признаками неэффективной корпоративной архитектуры, а вот эффективная помогает сформулировать технологическую стратегию на каждом уровне корпорации и помогает поставлять нужные решения
2) Автор описывает vision, mission, что должны быть у корп архитектуры и приводит generic примеры
Читатели могут взять эти или придумать для себя сами.
3) Автор описывает функции корпоративной архитектуры, куда входят strategy, oversight, enablement, пересечение которых обеспечивает крутые архитектурные решения.
- Стратегия помогает в достижении бизнес-целей организации - для этого важно про них знать
- Enablement мне напоминает по описанию то, как компании создают платформы для поддержки работы своих компаний
- Oversight включает в себя governance, risk, compliance
4) Автор рассказывает про роли архитекторов: enterprise, solution, software. Тут примерно то же самое, что я рассказывал 4 года назад в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения". Правда, у нас не было корпоративных архитекторов, а их роль лежит на технических директорах как мне кажется:) Эти ребята принимают решения разных volume и scope.
5) В принятии архитектурных решений помогают специализированные функции, что включают security, network, cloud, SRE, data, compliance и так далее. В общем, это похоже на привлечение центров экспертиз для принятия важных решений.
6) Бывают разные организационные модели: централизованная, федеративная и гибридная
- В централизованной модели роль корпоративной архитектуры централизована и находится на уровне других топ-левел орг юнитов.
- В федеративной модели роли распределена по отдельным доменам
- В гибридной есть небольшая центральная часть, а основная часть федеративна
7) Автор описывает типичные архитектурные deliverables, что включают
- Architecture decision deliverable - подробнее можно почитать здесь
- Architecture pattern deliverable - это паттерн для решения типичной проблемы внутри организации, желательно с объяснением логики и примерами кода
- Capability target architecture deliverable - это целевое описание группы возможностей, которое можно назвать архитектурным доменом. Про это интересно рассказать в отдельном посте
- Application target architecture deliverable - это целевое описание архитектуры приложения
В общем, книгу определенно интересно читать, она хорошо и логично написана, многое звучит хорошо, но не ясно как оно должно работать на практике:)
#Architecture #Management #Leadership #Software
Прочитал на каникулах книгу Tanu McCabe, что была посвящена корпоративной архитектуре и вышла квартал назад, а точнее в сентябре 2024 года. Мое мнение, что корпоративная архитектура - это удел корпораций, что сначала запускали devops трансформации, потом digital трансформации, а теперь все гонятся за AI. В общем, если у вас не технологическая компания, то enterprise architecture вам может и пригодится. В этой книге Tanu McCabe делает подход к снаряду, чтобы придать корпоративной архитектуре современный вид и теоретически у нее получается неплохо, но неясно как это стоит осуществлять на практике, хотя каждая глава сопровождается практически анекдотами, где приводятся примеры плохой реализации корпоративной архитектуры и хорошие варианты, что соответствуют современным тенденциям. И у нее достаточно неплохо это получается
Если говорить про основные мысли книги, то они изложены в первой главе, где затрагиваются следующие моменты
1) Зачем нужна корпоративная архитектура? И автор отвечает, что она нужна для
- Избегания изоляции отдельных частей организации (avoiding silos)
- Избегания хаоса - здесь идет речь про борьбу с complexity через стандарты
- Избегания технического долга, который мешает инновациям и бизнес гибкости
Все три вещи выше являются признаками неэффективной корпоративной архитектуры, а вот эффективная помогает сформулировать технологическую стратегию на каждом уровне корпорации и помогает поставлять нужные решения
2) Автор описывает vision, mission, что должны быть у корп архитектуры и приводит generic примеры
The vision: Define technology strategy that transcends organizational differences to connect different aims into common business goals.
The mission: Enable great architecture decisions to deliver great solutions as one team.
Читатели могут взять эти или придумать для себя сами.
3) Автор описывает функции корпоративной архитектуры, куда входят strategy, oversight, enablement, пересечение которых обеспечивает крутые архитектурные решения.
- Стратегия помогает в достижении бизнес-целей организации - для этого важно про них знать
- Enablement мне напоминает по описанию то, как компании создают платформы для поддержки работы своих компаний
- Oversight включает в себя governance, risk, compliance
4) Автор рассказывает про роли архитекторов: enterprise, solution, software. Тут примерно то же самое, что я рассказывал 4 года назад в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения". Правда, у нас не было корпоративных архитекторов, а их роль лежит на технических директорах как мне кажется:) Эти ребята принимают решения разных volume и scope.
5) В принятии архитектурных решений помогают специализированные функции, что включают security, network, cloud, SRE, data, compliance и так далее. В общем, это похоже на привлечение центров экспертиз для принятия важных решений.
6) Бывают разные организационные модели: централизованная, федеративная и гибридная
- В централизованной модели роль корпоративной архитектуры централизована и находится на уровне других топ-левел орг юнитов.
- В федеративной модели роли распределена по отдельным доменам
- В гибридной есть небольшая центральная часть, а основная часть федеративна
7) Автор описывает типичные архитектурные deliverables, что включают
- Architecture decision deliverable - подробнее можно почитать здесь
- Architecture pattern deliverable - это паттерн для решения типичной проблемы внутри организации, желательно с объяснением логики и примерами кода
- Capability target architecture deliverable - это целевое описание группы возможностей, которое можно назвать архитектурным доменом. Про это интересно рассказать в отдельном посте
- Application target architecture deliverable - это целевое описание архитектуры приложения
В общем, книгу определенно интересно читать, она хорошо и логично написана, многое звучит хорошо, но не ясно как оно должно работать на практике:)
#Architecture #Management #Leadership #Software
O’Reilly Online Learning
Fundamentals of Enterprise Architecture
With the increasing complexity of modern cloud-based systems, an effective enterprise architecture program is more critical than ever. In this practical book, author Tanu McCabe... - Selection from Fundamentals of Enterprise Architecture [Book]
👍11❤6🔥4
Обложка книги "Fundamentals of Enterprise Architecture" и немного иллюстраций. Забавно сравнить отличия финальной версии обложки и early preview.
🔥16👍6❤2
DevOps Metrics. Your biggest mistake might be collecting the wrong data (Рубрика #Management)
Ради интереса я решил прочитать whitepaper шестилетней давности, в котором Nicole Forsgren и Mik Kersten рассказывали о devops метриках. Интересно, что статья начинается с цитат великих
А дальше начичнается погружение в эру digital и devops трансформаций и продажа разнообразным CIO рассказов о том, что организации зачастую не достигают целей IT из-за проблем со скоростью поставки программного обеспечения. И для того, чтобы улучшить эти процессы авторы предлагают поработать над созданием метрик, которые позволят обеспечить прозрачность и управляемость в этой области. Для этого они предлагают комбинировать 2 типа данных
1) System-based metrics
Это метрики, которые строятся на основе данных из реальных систем. Например, данные о сборках, автотестах, релизах, работе в IDE и так далее. При рассмотрении этих данных требуется учесть аспекты
- Completeness - достаточно ли полны данные, собранные из определенной системы для обеспечения той наглядности, метрик и отчетов, которые являются целью инициативы?
- Comprehensiveness - достаточно ли данных собрано во всех системах для учета сквозной метрики, например, time-to-market?
- Correctness - достаточно ли скоррелированы данные, чтобы быть правильными? Условно надо уметь матчить совпадающие данные из разных систем
У этих метрик есть крутые преимущества
- Precision - данные в системах создаются с большой точностью
- Continuous visibility - данные из систем доступны в реальном времени, можно работать на потоке данных или анализировать их пост-фактум
- Granularity - мы можем смотреть на данные из разных подсистем или компонент или наоборот подняться на уровень системы
- Scalability - когда система сбора данных имплементирована, то ее можно растянуть на все продукты/проекты
Но есть и сложности
- Gaining a holistic view - во-первых сложно собрать данные со всех систем (нужен тулинг), а также из-за того, что у нас социо-технические системы, то нужна информация из глаз разработчиков о том, как работают инженерные процессы
- Capturing drifts in the system - при изменениях в системах данные из них могут не обновляться, что дает неактуальную картину
2) Survey-based metrics
Это метрики на основе проведения опросов о том, как работают процессы, системы или сами люди чувствуют себя:) У таких данных есть следующие важные аспекты
- Cohesiveness - данные, полученные в ходе опросов, особенно хороши для предоставления полного и целостного представления о системах.
- Correctness - разработка и измерение опросов является хорошо изученной дисциплиной, которую можно использовать для предоставления качественных данных и понимания систем и культуры.
У этих метрик есть крутые преимущества
- Accuracy при правильном сборе данных
- A holistic view of the system - ответы, которые предоставляют респонденты, отражают их общее восприятие ситуации
- Triangulation with system data - можно сочетать с системными данными
- Capturing behavior outside of the system
- Cultural or perceptual measures related to the system
Но список недостатков тоже широк: precision данных не очень велик, получать данные постоянно невозможно (никто не будет заполнять опросы слишком часто), объем собранных данных (мало кто готов заполнять сложные опросы даже редко). А также если данные опросов используются для оценок, то ответы в опросах могут быть смещены в сторону ожиданий топ-менеджмента.
В общем, по итогу авторы приходят к выводу, что комбинация двух подходов дает отличный эффект.
Кстати, подробнее про развитие этой темы можно почитать в моем посте "Зачем заниматься темой developer productivity в большой компании"
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
Ради интереса я решил прочитать whitepaper шестилетней давности, в котором Nicole Forsgren и Mik Kersten рассказывали о devops метриках. Интересно, что статья начинается с цитат великих
“Software is eating the world.” —Marc Andreessen
“You can't manage what you don't measure.” —Peter Drucker
А дальше начичнается погружение в эру digital и devops трансформаций и продажа разнообразным CIO рассказов о том, что организации зачастую не достигают целей IT из-за проблем со скоростью поставки программного обеспечения. И для того, чтобы улучшить эти процессы авторы предлагают поработать над созданием метрик, которые позволят обеспечить прозрачность и управляемость в этой области. Для этого они предлагают комбинировать 2 типа данных
1) System-based metrics
Это метрики, которые строятся на основе данных из реальных систем. Например, данные о сборках, автотестах, релизах, работе в IDE и так далее. При рассмотрении этих данных требуется учесть аспекты
- Completeness - достаточно ли полны данные, собранные из определенной системы для обеспечения той наглядности, метрик и отчетов, которые являются целью инициативы?
- Comprehensiveness - достаточно ли данных собрано во всех системах для учета сквозной метрики, например, time-to-market?
- Correctness - достаточно ли скоррелированы данные, чтобы быть правильными? Условно надо уметь матчить совпадающие данные из разных систем
У этих метрик есть крутые преимущества
- Precision - данные в системах создаются с большой точностью
- Continuous visibility - данные из систем доступны в реальном времени, можно работать на потоке данных или анализировать их пост-фактум
- Granularity - мы можем смотреть на данные из разных подсистем или компонент или наоборот подняться на уровень системы
- Scalability - когда система сбора данных имплементирована, то ее можно растянуть на все продукты/проекты
Но есть и сложности
- Gaining a holistic view - во-первых сложно собрать данные со всех систем (нужен тулинг), а также из-за того, что у нас социо-технические системы, то нужна информация из глаз разработчиков о том, как работают инженерные процессы
- Capturing drifts in the system - при изменениях в системах данные из них могут не обновляться, что дает неактуальную картину
2) Survey-based metrics
Это метрики на основе проведения опросов о том, как работают процессы, системы или сами люди чувствуют себя:) У таких данных есть следующие важные аспекты
- Cohesiveness - данные, полученные в ходе опросов, особенно хороши для предоставления полного и целостного представления о системах.
- Correctness - разработка и измерение опросов является хорошо изученной дисциплиной, которую можно использовать для предоставления качественных данных и понимания систем и культуры.
У этих метрик есть крутые преимущества
- Accuracy при правильном сборе данных
- A holistic view of the system - ответы, которые предоставляют респонденты, отражают их общее восприятие ситуации
- Triangulation with system data - можно сочетать с системными данными
- Capturing behavior outside of the system
- Cultural or perceptual measures related to the system
Но список недостатков тоже широк: precision данных не очень велик, получать данные постоянно невозможно (никто не будет заполнять опросы слишком часто), объем собранных данных (мало кто готов заполнять сложные опросы даже редко). А также если данные опросов используются для оценок, то ответы в опросах могут быть смещены в сторону ожиданий топ-менеджмента.
В общем, по итогу авторы приходят к выводу, что комбинация двух подходов дает отличный эффект.
Кстати, подробнее про развитие этой темы можно почитать в моем посте "Зачем заниматься темой developer productivity в большой компании"
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
queue.acm.org
DevOps Metrics - ACM Queue
Delivering value to the business through software requires processes and coordination that often span multiple teams across complex systems, and involves developing and delivering software with both quality and resiliency. As practitioners and professionals…
👍5❤2🔥2👎1
The Culture Map (Карта культурных различий) (Рубрика #Management)
Прочитал на каникулах этот бестселлер десятилетней давности от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя
1. Communication (коммуникация): low-context vs. high-context
2. Evaluation (оценивание): direct vs. indirect negative feedback
3. Persuading (убеждениe): principles-first vs. applications-first
4. Leading (лидерство): egalitarian vs. hierarchical
5. Decision-making (принятие решений): consensual vs. top-down
6. Trust (доверие): task-based vs. relationship-based
7. Disagreement (несогласие): confrontational vs. avoidance
8. Scheduling (планирование времени): structured vs. flexible24
Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось
1. Communication (коммуникация)
- Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00"
- Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность.
2. Evaluation (оценивание
- Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки".
- Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы".
3. Persuading (убеждениe)
- От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы.
- От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные.
4. Leading (лидерство)
- Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении.
- Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству.
5. Decision-making (принятие решений)
Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования.
Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов.
6. Trust (доверие)
На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков.
На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы.
7. Disagreement (несогласие):
Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч.
Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации.
8. Scheduling (планирование времени)
Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками.
Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств.
В итоге, книга через модель и примеры помогает читателям взглянуть на другие культуры непредвзято и оценить какие недоразумения возникают из-за культурных различий, а не некомпетентности. Это позволяет преодолеть культурные границы и может помочь менеджеру мультикультурной команды
- Определить потенциальные области конфликтов между культурами
- Адаптировать стиль управления под конкретную культуру/культуры
- Улучшить коммуникацию в международных командах
P.S.
Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid.
#Management #Leadership #Culture #PopularScience
Прочитал на каникулах этот бестселлер десятилетней давности от Erin Meyer и он мне понравился. В нем Эрин, профессор INSEAD, интересно изложила свою гипотезу о карте различий разных культур, которую можно воспринимать через восемь отдельных непрерывных шкал, включающих в себя
1. Communication (коммуникация): low-context vs. high-context
2. Evaluation (оценивание): direct vs. indirect negative feedback
3. Persuading (убеждениe): principles-first vs. applications-first
4. Leading (лидерство): egalitarian vs. hierarchical
5. Decision-making (принятие решений): consensual vs. top-down
6. Trust (доверие): task-based vs. relationship-based
7. Disagreement (несогласие): confrontational vs. avoidance
8. Scheduling (планирование времени): structured vs. flexible24
Школа мысли Эрин в том, что у каждой из этих шкал есть два экстремальных значения, а дальше каждая из стран позиционируется на шкале так, чтобы отображать медиану приемлемого поведения. Но важна не сама точка, а скорее относительное положение стран между собой, так как все познается в сравнении. Для этого автор щедро приводит очень большое количество примеров, разбирая каждую ось
1. Communication (коммуникация)
- Низкоконтекстная - (США): Американский менеджер прямо скажет "Крайний срок проекта - следующая пятница, 17:00"
- Высококонтекстная (Япония): Японский менеджер может сказать "Нам стоит подумать о завершении в ближайшее время", ожидая, что команда поймет подразумеваемую срочность.
2. Evaluation (оценивание
- Прямая (Нидерланды): "Эта презентация полностью неверна и требует переделки".
- Непрямая (США): "Вы сделали несколько интересных замечаний, но, возможно, стоит рассмотреть альтернативные подходы".
3. Persuading (убеждениe)
- От принципов (Германия): Немецкий менеджер сначала объяснит теоретическую базу и методологию, прежде чем представить выводы.
- От практики (США): Американский презентующий начнет с вывода или рекомендации, затем при необходимости предоставит подтверждающие данные.
4. Leading (лидерство)
- Эгалитарное (Дания): Сотрудники свободно не соглашаются с начальником на встречах и могут пропускать иерархические уровни при общении.
- Иерархическое (Китай): Сотрудники должны следовать proper каналам и получать одобрение непосредственного руководителя перед обращением к высшему руководству.
5. Decision-making (принятие решений)
Консенсусное (Япония): Каждый отдел должен рассмотреть и одобрить предложение, прежде чем оно пойдет вверх по цепочке командования.
Сверху вниз (Бразилия): Босс принимает решения самостоятельно, а члены команды должны выполнять их без вопросов.
6. Trust (доверие)
На основе задач (США): Доверие строится через стабильное достижение результатов и соблюдение сроков.
На основе отношений (Китай): Доверие развивается через совместные обеды, личные разговоры и построение социальных связей вне работы.
7. Disagreement (несогласие):
Конфронтационное (Франция): Члены команды открыто дебатируют и оспаривают идеи друг друга во время встреч.
Избегающее (Япония): Проблемы обсуждаются приватно в малых группах для поддержания гармонии и избегания публичной конфронтации.
8. Scheduling (планирование времени)
Структурированное (Германия): Работа следует фиксированным графикам с четкими дедлайнами и точными временными рамками.
Гибкое (Индия): Графики адаптируемы, с подвижными дедлайнами и регулируемым рабочим временем в зависимости от обстоятельств.
В итоге, книга через модель и примеры помогает читателям взглянуть на другие культуры непредвзято и оценить какие недоразумения возникают из-за культурных различий, а не некомпетентности. Это позволяет преодолеть культурные границы и может помочь менеджеру мультикультурной команды
- Определить потенциальные области конфликтов между культурами
- Адаптировать стиль управления под конкретную культуру/культуры
- Улучшить коммуникацию в международных командах
P.S.
Есть хороший обзор книги от Руслана Фазлыева, CEO Ecwid.
#Management #Leadership #Culture #PopularScience
👍16❤7🔥3
Обложки и немного иллюстраций к книгам "The Culture Map" и "Карта культурных различий"
👍12🔥5❤2
What Do Developers Want From AI? (Рубрика #DevEx)
Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи
1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
Летом 2024 года вышла интересная статья про то, что эволюция AI - это поворотный момент, но с технологическими революциями, что меняют формат работы людей, человечество сталкивается не в первый раз. Поэтому авторы статьи решают провести параллели с развитием автомобильной промышленности и сфокусироваться на потребностях и целях наших разработчиков. Это статья из серии "Hunam centric approach to developer productivity" от ребят из Google, про которую я рассказывал раньше. А теперь основные моменты статьи
1) Последние достижения в AI привели к появлению большого количества инструментов разработки для поддержки искусственного интелекта (например, DuetAI, CoPilot и ChatGPT для задач программирования). После этого было проведено много исследований влияния этих инструментов на продуктивность разработчиков, где задавались вопросы навроде
- Повышают ли улучшения ИИ скорость написания кода?
- Улучшают ли они качество написанного кода?
- Помогают ли они разработчикам находить более креативные решения?
2) Но вот обсуждений того, а как разработчики хотят взаимодействовать с AI в своих инструментах, было гораздо меньше. Авторы исследования со своим фокусом на человекоориентированный подход к пониманию продуктивности разработчиков решили это испраивать и провести исследование для ответа на вопрос, а где разработчики хотят видеть ИИ в своих рабочих процессах, и какими, по их мнению, будут его эффекты?
3) Здесь авторы начинают проводить параллели с автомобилями для понимания потребностей. Они говорят, что понимание того, что люди хотят и в чем нуждаются от технологий, является основой исследований пользовательского опыта. Однако этот подход иногда подвергается сомнению, особенно когда речь идет о крупных технических инновациях - в этих случаях вспоминают знаменитую фразу, приписываемуюГенри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали 'более быстрых лошадей'".
4) Для исследования предпочтений разработчиков авторы провели многочисленные интервью и пользовательские сследования с разработчиками, имеющими различный опыт работы с инструментами разработки с поддержкой ИИ. Разработчики выражали свое желание, чтобы такие инструменты экономили их время и энергию, помогая им более эффективно выполнять свою работу, то есть они хотят, чтобы ИИ поддерживал более простые задачи и уменьшал рутину, позволяя им сосредоточиться на решении сложных проблем и творческих аспектах их работы.
5) Для того, чтобы понять какие области мешают разработчикам быть продуктивными в Google исследователи проводят опросы и анализируют логи. Это позволяет сфокусировать усилия на самых важных факторах, тройка которых в Google сейчас такая
- Технический долг
- Плохая или отсутствующая документация
- Сложности в изучении новых платформ и технологий
6) Авторы классифицировали эволюцию улучшений AI по трем типам (проведя параллели с автомобильной промышленностью)
- Улучшение существующих человеческих возможностей. Для машин это усилитель руля, антиблокировочная система для тормозов. Для AI в разработке это code completion.
- Расширение человеческих возможностей (добавление новых). Для машин это камера заднего вида, контроль слепых зон. Для AI в разработке это code review suggestions, chatbots
- Делегирование человеческих возможностей (фичи, что убирают human in the loop). Для машин это удержание полосы движения, автоматическое торможение, улучшенный круиз-контроль. Для AI в разработке это автоматический откат проблемных релизов, автоматическое удаление dead code, генерация тестов
7) Для успешного внедрения изменений с AI необходимо
- Понимание сопротивления и скептицизма разработчиков
- Создание правильной инфраструктуры для внедрения
- Обеспечение безопасного и справедливого доступа во всех отраслях
- Сохранение фокуса на целях разработчиков, а не только на технологических возможностях
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
🔥8👍7❤6
Новогодний отпуск
Мой отпуск уже заканчивается, завтра на работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers
В общем, отпуск удался, а завтра у меня уже будет первый рабочий день в новом году.
P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)
Мой отпуск уже заканчивается, завтра на работу, а сегодня еще 9 часов лета. Если подводить итоги, то отпуск в новогодние каникулы обычно бывает хорош и позволяет успеть многое:
- Можно хорошо провести время с семьей и отдохнуть
- Посмотреть красивые места - в этот раз это была Шри Ланка
- Порефлексировать о прошедшем годе и его итогах
- Подумать о будущем - раньше я бы сказал о планировании, но сейчас предпочитаю не строить планы, а думать о приоритетах
- Почитать интересные книги - я прочел тройку книг и несколько whitepapers
В общем, отпуск удался, а завтра у меня уже будет первый рабочий день в новом году.
P.S.
И раз отпуск заканчивается, то дальше я смогу постить еще больше интересного в канале:)
👍49❤17🔥5🥰2