Книжный куб

[1/2] Feeding the Machine (Как кормят машину) (Рубрика #AI) Я всегда ценил расширение наших знаний и возможностей об окружающем мире. Меня с детства интересовало как устроено все вокруг, поэтому мне нравится стремительный темп развития науки и технологий. Но в этой книге авторы поднимают интересные вопросы о том, а что же стоит за красивым фасадом AI (artificial intelligence), самой горячей технологии на сегодняшний день. В название книги вынесена метафора про машину, которую мы кормим своим трудом, знаниями и навыками в надежде на счастливое будущее. Про это рассказывают три автора Джеймс Малдун, Марк Грэм и Каллум Кант. Джеймс Малдун является преподавателем менеджмента в Университете Эссекса, научным сотрудником Оксфордского университета и руководителем цифровых исследований в аналитическом центре Autonomy. Его исследования посвящены вопросам использования современных технологий на благо общества. Марк Грэм — директор проекта Fairwork и профессор Оксфордского института Интернета, специализирующийся на глобальных цифровых рынках труда. Каллум Кант — старший преподаватель бизнес-школы Университета Эссекса, изучающий проблемы труда, технологий и современных кризисов. В общем, достойный коллектив для разбора такой сложной темы. Авторы идут по пути рассказа о всей цепочке извлечения данных, тратя по главе на каждый этап. В итоге, у нас получается такой список глав 1) The Annotator (разметчик) - Глава посвящена сотрудникам, которые вручную размечают данные, используемые для обучения моделей искусственного интеллекта (AI). Эти работники выполняют монотонные задачи за низкую оплату в нестабильных условиях труда. Так же здесь рассказывается о работе модераторов контента для условных соцсетей. Авторы много работали на африканском континенте и показывает как это устроено в Уганде. Собственно, в страны Глобального Юга обычно аутсорсится такая работа и выполняется ооочень дешево, так как она не требует особой экспертизы и может быть перемещена в любую точку земного шара Продолжение обзора в следующем посте. #AI #Software #Management #Processes #Productivity

Баскетбол: ЦСКА - Енисей (Рубрика #LifeStory) Были вечером в среду с сыном на матче баскетбольного ЦСКА. Решили в этот раз сесть на уровне поля, чтобы оценить насколько по другому смотрится матч. Оказалось, что тут ощущения совсем другие - когда ты сидишь в нескольких метрах от команды и слышишь, что говорит тренер во время перерывов, или видишь игроков, пробегающий почти мимо тебя. В общем, места были зачетные, а еще игра оказалась не проходной - ребята из Енисея в первую половину клали трехи почти без промаха и ЦСКА горел примерно на 15 очков к перерыву. Меня даже Максим, мой сын, спрашивал, а почему ЦСКА так плохо играет. Я ответил, что во второй половине тренер им все объяснит и они начнут переигрывать Енисей. Примерно так и получилось, но матч был близким до последних секунд и еще за полминуты до конца отрыв был всего в треху. Правда, в итоге ЦСКА победил и мы с Максом отправились домой, обсуждая перепитии матча. #Sport #ForKids

[2/3] A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making (Рубрика #Architecture) Продолжим рассмотрение whitepaper на тему использования Gen AI в архитектуре, начатый в первом посте, рассмотрением паттернов промтинга. 1) Software architect persona pattern Это паттерн, расширяющий паттерн персоны, где суть в том, чтобы AI генерировал контент релевантный для архитектора, то есть он был точный и адресовал те проблемы, с которыми сталкиваются архитекторы. Это достигается путем создания запросов, которые четко определяют роль архитектора программного обеспечения, цели и ограничения в отношении целевого проектного решения. Вот шаблон промпта от авторов

You are [Persona’s Name] in the role [Role]. Your main goal is [Main Goal]. You cannot [Limitations/Constraints].

В качестве примера промпта приводится следующий

You are a Senior Software Architect specializing in cloud-based solutions.Your main goal is to optimize system scalability and performance. You cannot propose solutions that significantly increase operational costs.

2) Architectural project context Авторы предлагают задавать контекст проекта через три ключевых фактора - Операционные, такие как доступное время разработки - Организационные, такие как размер команды - Финансовые, такие как бюджет проекта Эти факторы напрямую влияют на осуществимость и направление архитектурных решений, что требует паттерна, который эффективно интегрирует эти элементы в процесс принятия решений. Интересно, что авторы тут рассматривают проектный подход реализации больших архитектурных изменений. Вот шаблон промпта от авторов

Given a development timeline of [Time], a team of [Team Size], and a budget of [Budget], determine if the proposed architecture [Architecture Description] is feasible and can meet the project requirements without compromising on quality.

В качестве примера промпта приводится следующий

Given a development timeline of 6 months, a team of 10 developers, and a budget of $500k, determine if implementing a microservices-based architecture for our e-commerce platform is feasible and can deliver the required scalability and performance within these constraints.

Как по мне, такое описание контекста проекта кажется слишком убогим, хотелось бы посомтреть как выглядит output LLM, если ей скормить полноценное описание:) 3) Quality attribute question pattern Для проектирования качественной архитектуры нужно правильно определить функциональные и нефункциональные требования, а также выделить желаемые атрибуты качества. Дальше уже можно выбирать архитектурные паттерны, тенологиии и все остальное. В этом паттерне авторы предлагают научить AI-ассистент задавать вопросы живым архитекторам как раз для выделения этих ключевых атрибутов качества. Вот так выглядит шаблон промпта

You are [Role] responsible for [Description Project]. Your primary focus is to design an architecture that excels in [List Of The Quality Attribute]. Your task is [Decision-making Process]. You should ask [Clarify Doubts]. [Recommendations]. Additionally, provide a [Comprehensive Prompt].

В качестве примера промпта приводится следующий

Уou are an experienced software architect responsible for creating a credit card processing system for a medium-sized financial institution. Your primary focus is to design an architecture that excels in scalability, security, and performance. Your task is to carefully navigate through the decision-making process of the credit card processing system architecture step by step. You should ask any necessary questions to clarify doubts about the quality attributes of the new system. Avoid making any architectural decisions until all questions are answered. Additionally, provide a comprehensive prompt that includes all the data collected in the previous steps, along with an explanation of the rationale behind each architectural decision-making.

Продолжение обзора паттернов и их совместного использования в следующем посте. #Architecture #GenAI #AI #ML #Software #Engineering #SystemDesign #DistributedSystems #Project

The Future of U.S. AI Leadership with CEO of Anthropic Dario Amodei (Рубрика #AI) 11 марта 2025 года состоялась беседа в рамках серии "CEO Speaker Series" Совета по международным отношениям (CFR), где президент совета Майкл Форман провел интервью с генеральным директором и соучредителем компании Anthropic Дарио Амодеем. Именно на этой встрече Дарио дал свое предсказание о том, что 90% кода через полгода будут писать AI, а через год и все 100%. В итоге, я решил посмотреть всю встречу и отметить основные моменты, что мне показались интересными. 1) Основание и миссия Anthropic Дарио Амодей рассказал о причинах ухода из OpenAI в конце 2020 года и создании Anthropic. Он объяснил, что его команда одной из первых распознала "гипотезу масштабирования" - принцип, согласно которому ИИ становится лучше при увеличении вычислительных мощностей и данных. Anthropic была создана как компания, ориентированная на миссию, с акцентом на безопасность и предсказуемость технологий ИИ. Здесь Дарио недвусмысленно намекнул, что у OpenAI были другие планы на развитие этих технологий 2) Безопасность и ответственное развитие ИИ Амодей подробно рассказал о подходах Anthropic к безопасности, включая: - Механистическую интерпретируемость для понимания поведения ИИ - Конституционный ИИ, обучаемый на основе принципов - Политику ответственного масштабирования - Уровни безопасности ИИ, сравнимые с уровнями биобезопасности 3) Будущее программирования Это самый горячий топик, из-за которого я пошел смотреть это выступление. Амодей сделал прогноз о том, что в течение 3-6 месяцев ИИ сможет писать 90% всего программного кода. При этом он отметил, что роль программистов изменится, но останется важной для определения требований, дизайна приложений и принятия критических решений. 4) Геополитика и национальная безопасность Амодей подчеркнул важность экспортного контроля над технологиями ИИ и обсудил риски, связанные с возможным доминированием Китая в этой области. Звучала фраза в стиле того, что кто получит доминацию в этой технологии, тот получит военное и экономическое превосходство и во всем остальном. Также обсуждались вопросы контрабанды графических процессоров и сотрудничества с институтами национальной безопасности. 5) Социальные последствия развития ИИ В беседе затрагивались вопросы влияния ИИ на рынок труда, общество и человеческие ценности. Амодей представил как оптимистичный, так и пессимистичный сценарии будущего, где ИИ может либо помочь людям создавать великие вещи, либо привести к обесцениванию человеческого труда. Интересно, что я сейчас дочитываю книгу "Feeding the Machine" ("Как кормят машину"), где очень интересно поднимаются именно эти темы. 6) Перспективы развития ИИ Амодей обсудил возможные ограничения роста ИИ, включая потенциальное исчерпание данных к 2030 году, но отметил, что новые методы обучения, такие как "reasoning models", могут устранить эту проблему, позволяя ИИ учиться на основе собственных мыслей. Беседа завершилась размышлениями о том, что, несмотря на все технологические достижения, человеческие качества и взаимоотношения останутся важными, а ИИ может помочь, но не заменит фундаментальные человеческие ценности. #AI #Software #Engineering #Storytelling #ML #Architecture

Модели T-lite и T-pro: training report Интересный отчет от моих коллег о том, как проходили тренировки моделей T-lite и T-pro. - Зачем адаптировать модели на русский язык - тут ребята объясняют, а зачем всем этим заниматься, если есть зарубежные open source модели - Стадии обучения языковой модели - здесь кртако идет речь про Parameter Efficient Fine-Tuning, Supervised Fine Tuning, General Post-Training и главное Continual Pretraining, который применяют ребята. Кратко суть подхода в том, чтобы

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

А затем авторы разбираю каждый этап в деталях и это действительно интересное чтиво для интересующихся современными подходами к созданию LLM. Рекомендую. #AI #ML #Software #Engineering

Code of Leadership #32 - Interview with Nikita Burkov about Marketing, Sales & Xsell В очередном выпуске подкаста ко мне пришел интересный гость, Никита Бурков, который CTO в сфере X-Sell маркетинга и продаж в Т-Банке. Он обладает обширным и разносторонним опытом, а его карьерный путь начался с оффлайн-продаж в 10 лет, что сформировало его понимание рынка и потребностей клиентов. Также он развивал LMS-системы в университетах, создавал программное обеспечение для бухгалтерии международного процессингового центра и работал над первым финансовым маркетплейсом в России. Никита развивался, как Java-разработчик и стремительно прошел путь до CTO, благодаря страсти к технологиям и лидерским качествам. В подкасте мы обсуждаем как работает маркетинг, продажи, кросс-селл, а также как быть хорошим техническим директором. Вообще мне все эти темы отзываются, так как я уже больше 10 лет связан с маркетингом, привлечением и всем всем всем. Кажется, именно поэтому мы записали рекордный выпуск на 2.5 часа, где мы поговорили на следующие темы - Личный и профессиональный путь Никиты - Системы и платформы для кросс-продаж - Маркетинговые стратегии: кросс-канальность и омниканальность - Сегментирование и таргетирование - Бизнес-метрики и NPV в экосистеме - Архитектура бизнес-доменов - Типы команд и их функции - Триггерная система и обработка данных - Роль технического директора и стратегическое планирование - Продуктовый подход и развитие сотрудников Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Architecture #Software #Engineering #ProductManagement #Management #Economics

ACM A.M. Turing Award для Эндрю Барто и Ричард Саттон (Рубрика #AI) ACM A.M. Turing Award получили в этом году Эндрю Барто и Ричард Саттон. Эту награду часто называют "Нобелевской премией в области информатики" и им ее дали за их новаторский вклад в reinforcement learning (обучение с подкреплением). Их сотрудничество, начавшееся в 1980-х годах, ввело ключевые концепции, математические основы и влиятельные алгоритмы, которые стали фундаментальными для современных систем ИИ. Reinforcement learning позволяет машинам обучаться оптимальному поведению путем взаимодействия с окружающей средой через метод проб и ошибок, руководствуясь наградами и штрафами. Среди их наиболее значимых достижений: - Развитие концепции temporal-difference learning, а точнее TD-Lambda, позволяющей системам учиться на основе разницы между последовательными предсказаниями - Создание математических основ обучения с подкреплением с использованием марковских процессов принятия решений - Разработка методов градиента политики (policy-gradient methods) - Концепция временной абстракции, позволяющая ИИ учиться поэтапно, что критически важно для систем, которым необходимо рассуждать на длительных временных горизонтах - Использование нейронных сетей для представления изученных функций Краеугольным камнем их наследия является влиятельный учебник "Reinforcement Learning: An Introduction", впервые опубликованный в 1998 году, со значительно расширенным вторым изданием, выпущенным в 2018 году. Эта книга широко признана определяющим руководством по reinforcement learning, четко излагающим ключевые идеи и алгоритмы. Кстати, я заказал себе как раз второе издание книги на английском, к концу марта оно доедет ко мне и дальше я попробую ее почитать:) #AI #Math #Engineering #ML #Software

2 гига спустя - эпизод первый (Рубрика #News) Это первый выпуск подкаста с лайтовым обсуждением новостей двумя ведущими Суть в том, чтобы в научпоп формате обсуждать интересные IT новости и выпускать эпизоды раз в неделю. В этом мне помогает Антон Костерин, мой коллега, с которым мы вместе развиваем архитектурную функцию в Т-Банке. Антон входит в программный комитет "Teamlead Conf", а также уже много раз появлялся в моем канале: - Внешний подкаст с темой "Миграция в срок, реальность или миф?" - Подкаст "Code of Architecure" в первой серии по книге ван Стина и Таненбаума "Distributed Systems" - Третий выпуск Code of Architecture по книге "A Philosophy of Software Design" - Code of leadership #17 - Interview with Anton Kosterin about Architecture В первом выпуске мы обсудили темы 0) Vibe coding в обсуждении Y Combinator. Где vibe coding становится новым подходом к программированию, позволяющим быстро создавать код с помощью ассистентов без необходимости глубокого изучения программирования, что особенно полезно для стартапов и домашних проектов. Оригинальное видео и мой краткий разбор 1) Forbes написали о том, что 95% объектов критической инфраструктуры используют зарубежные решения, включая Zabbix для мониторинга (85%), что поднимает вопросы импортозамещения 2) Ситибанк допустил серьезную ошибку, случайно переведя 81 триллион долларов вместо 280 тысяч, что подчеркивает необходимость многоуровневой защиты в финансовых системах. 3) C++ сталкивается не только с проблемами безопасности, но и с проблемами маркетинга, что может привести к его упадку, несмотря на то, что он остается стандартом де-факто в индустрии. Об этом рассказал сам создатель языка, Бьерн Страуструп 4) Равинд Шинивас, CEO Perplexity, поделился своим опытом создания компании, разрабатывающей AI поиск с использованием LLM моделей и успешно конкурирует с Google Search, Microsoft Bing и остальными. Оригинальное видео и мой разбор 5) Исследование показало, что внешность кандидата может влиять на успешность прохождения интервью, что поднимает этические вопросы при найме. Нейронные сети могут перенимать человеческие предубеждения из обучающих данных, что особенно проблематично в таких областях как медицина, где важна точность прогнозов. Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Management #AI #Software #Engineering #Reliability #Processes #Productivity

2 гига спуста - эпизод первый (Рубрика #News) Это первый выпуск подкаста с лайтовым обсуждением новостей двумя ведущими Суть в том, чтобы в научпоп формате обсуждать интересные IT новости и выпускать эпизоды раз в неделю. В этом мне помогает Антон Костерин, мой коллега, с которым мы вместе развиваем архитектурную функцию в Т-Банке. Антон входит в программный комитет "Teamlead Conf", а также уже много раз появлялся в моем канале: - Внешний подкаст с темой "Миграция в срок, реальность или миф?" - Подкаст "Code of Architecure" в первой серии по книге ван Стина и Таненбаума "Distributed Systems" - Третий выпуск Code of Architecture по книге "A Philosophy of Software Design" - Code of leadership #17 - Interview with Anton Kosterin about Architecture В первом выпуске мы обсудили темы 0) Vibe coding в обсуждении Y Combinator, где vibe coding становится новым подходом к программированию, позволяющим быстро создавать код с помощью ассистентов без необходимости глубокого изучения программирования, что особенно полезно для стартапов и домашних проектов. Оригинальное видео и мой краткий разбор 1) Forbes написали о том, что 95% объектов критической инфраструктуры используют зарубежные решения, включая Zabbix для мониторинга (85%), что поднимает вопросы импортозамещения 2) Ситибанк допустил серьезную ошибку, случайно переведя 81 триллион долларов вместо 280 тысяч, что подчеркивает необходимость многоуровневой защиты в финансовых системах. 3) C++ сталкивается не только с проблемами безопасности, но и с проблемами маркетинга, что может привести к его упадку, несмотря на то, что он остается стандартом де-факто в индустрии. Об этом рассказал сам создатель языка, Бьерн Страуструп 4) Равинд Шинивас, CEO Perplexity, поделился своим опытом создания компании, разрабатывающей AI поиск с использованием LLM моделей и успешно конкурирует с Google Search, Microsoft Bing и остальными. Оригинальное видео и мой разбор 5) Исследование показало, что внешность кандидата может влиять на успешность прохождения интервью, что поднимает этические вопросы при найме. Нейронные сети могут перенимать человеческие предубеждения из обучающих данных, что особенно проблематично в таких областях как медицина, где важна точность прогнозов. #Management #AI #Software #Engineering #Reliability #Processes #Productivity

[4/4 + Extra] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx) В этом посте приложены ключевые иллюстрации из статьи, что разбиралась в четырех предыдущих частях обзора 1, 2, 3 и 4.

[4/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx) Закончим рассмотрение статьи про developer productivity (1, 2 и 3) и обсудим полученные авторами результаты. Топ пять факторов, что получились после анализа содержали следующие факторы - Project code quality (качество кода в проекте) - Hindrance of shifting priorities (препятствия в изменении приоритетов) - Technical debt in projects (технический долг в проектах) - Innovation of infrastructure & tools (инновации в инфраструктуре и инструментах) - Overall satisfaction with infra & tools (общая удовлетворенность инфраструктурой и инструментами) Дальше авторы применили панельный анализ с запаздыванием. Суть в том, что они получили корреляцию между продуктивностью инженеров и факторами, что приведены выше, а хотелось бы получить более сильные результаты и понять направление связи. Для этого они выдвинули две гипотезы 1) QaP: изменения в качестве кода в момент T-1 коррелирует с изменениями в продуктивности инженеров во времени T. В виде формулы это выглядело так: Δ𝑃𝑖𝑡 = 𝛼 + 𝛽Δ𝑄𝑖𝑡−1 + Δ𝜖𝑖𝑡 2) PaQ: изменения в продуктивность в момент T-1 коррелирует с изменениями в качестве кода в момент T. В виде формулы это выглядело так: Δ𝑄𝑖𝑡 = 𝛼 + 𝛽Δ𝑃𝑖𝑡−1 + Δ𝜖𝑖𝑡 Оказалось, что первая гипотеза о том, что рост качества кода связан с повышением производительности подтверждается со следующей силой

We found that a 100% increase of satisfaction rating with project code quality (i.e. going from a rating of ‘Very dissatisfied’ to ‘Very sat- isfied’) at time T-1 was associated with a 10% decrease of median active coding time per CL, a 12% decrease of median wall-clock time from creating to mailing a CL, and a 22% decrease of median wall-clock time from submitting to deploying a CL at time T.

А вот обратная гипотеза отвергается, так как она не подтверждена экспериментальными данными. Собственно, эти результаты и привели к названию статьи, а также к целой серии дальнейших исследований, что я упоминал в части 3 этого обзора. Отдельно надо рассказать про опасности для валидности этого эксперимента, которые описали авторы. Их всего 4 1) Content. Авторы измеряли продуктивность по ответу на один вопрос в проводимом EngSat опросе, что конечно не дает полной картины. Например, авторы отмечают, что этот вопрос был про индивидуальную продуктивность инженера, а не про эффективность команды. Примерно также не все факторы, что могут влиять на продуктивность были рассмотрены 2) Construct. Восприятие вопроса про продуктивность могло отличаться у респондентов. Например, кто-то мог думать о продуктивности в формате нафигачить быстро фичу, а кто-то учитывал разницу в качестве при создании фичи. Ну и там был еще ряд мест, где респонденты по разному могли воспринять сами вопросы 3) Internal. В этом исследовании авторы используют панельный анализ с запаздыванием, что эффективно предполагает, что эффекты на индивидуальных инженеров не зависят от времени. Например, у одного инженера сменился проект и команда, другому достался крутой ментов, у третьего что-то случилось в семье. Одновременно, могли бы быть проблемы, если какие-то категории инженеров систематически не участвовали в опросе, например, ветераны разработки или наоборот новички. Но авторы такие отклонения контролировали. 4) External. Весь эксперимент основывает только на опыте инженеров внутри Google, а значит может не иметь обобщающей силы на другие компании в индустрии. Несмотря на все потенциальные проблемы, мне понравилось это исследование не только итоговым ответом на вопрос про то, что улучшает developer productivity в Google, но и самой методологией проведения эксперимента. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Вдруг что-то важное - Как учиться с помощью AI, развивать технические скиллы и причем тут адаптивность (Рубрика #SelfDevelopment) Появился выпуск подкаста "Вдруг что-то важное", куда я пришел в качестве гостя, чтобы поговорить про обучение и адаптивность. Ведущими эпизода были: - Андрей Смирнов, организатор конференции Soft Weekend и подкастер - Ульяна Батуева, тимлид PR-отдела в KODE А обсуждали мы тему постоянных изменений - вокруг меняется все: фреймворки, методологии, инструменты, тренды… Как писал Льюис Кэролл в своей Алисе "Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!". Но такая погоня легко может привести к выгоранию. В выпуске мы попробовали обсудить как найти баланс, как научиться адаптироваться к изменениям осознанно, без стресса и паники, как использовать AI для обучения и не утонуть в потоке информации. По-моему, выпуск получился достаточно интересным, хотя не уверен, что я сам знаю ответы на вопросы, представленные выше:) #Management #SelfDevelopment #Edu #AI #Leadership #Software

Обложка книги "Программирование. Математические основы, средства, теория"

Программирование. Математические основы, средства, теория (Рубрика #Math) Сегодня я решил вспомнить книгу Святослава Сергеевича Лаврова 2001 года издания, которая была выпущена в качестве фундаментального учебника по программированию. Автор был ученым, член-корреспондентом АН СССР и одним из пионеров советского программирования. Эта книга стала его последней работой. Честно говоря, я ее купил себе на первом курсе больше 20 лет назад и она мне тогда показалось сложноватой, но я честно пытался ее прочесть. Сейчас, пересматривая этот учебник, я понял почему она тогда показалась мне такой - автор решил в одной книге на 300 страниц дать основы математики и программирования, чтобы показать фундаментальную связь между этими дисциплинами. Зацените список дисцплин, что излогает автор в первой части с математическими основами - Формальные языки и логические формальные теории - Propositional and predicate logic - Теория множеств, а заодно про графы и деревья - Вероятности, немного про измерение информации и случайные процессы - Теория вычислимости с lisp и Машиной Тьюринга Каждая из этих тем тянет на отдельный семестровый курс, а то и больше:) И теперь, когда я пролистывал эту книгу, то мне все кажется достаточно понятным, а 20+ лет назад все казалось не таким ясным Во второй части автор переходит к основным понятиям и конструкциям языков программирования, где все начинается с дружелюбного использования формы Бэкуса — Наура для описания синтаксиса языка, дальше продолжается описанием структур данных, структуры действий, работы с процедурами, а дальше новыми веяниями в виде объектно-ориентированного и функционального программирования. В третьей части речь идет про анализ свойств программ, где автор рассказывает про оценку сложности алгоритмов, доказательство свойств программ, формализацию семантики языков программирования и так далее. В общем, автор написал книгу, в которой программирование рассматривается с математической точки зрения, а не с инженерной. Это сильно отличается от доминирующего подхода в наше время, но имеет свое право на жизнь. Мне в свое время книга понравилась как раз своей математической составляющей, но программировать я решил учиться по другим книгам:) #Math #Engineering #Software

The Pragmatic Programmer: From Journeyman to Master (Программист-прагматик) (Рубрика #Engineering) Достал тут очередную древнюю книгу с полки, чтобы вспомнить былое и рассказать как начинался для меня IT в начале 2000х годов. В этот раз речь пойдет про влиятельную книгу того времени, написанную Эндрю Хантом и Дэвидом Томасом в 1999. Основная мысль книги была о том, что программист должен быть прагматичным профессионалом, который постоянно совершенствуется, мыслит критически и ответственно относится к своему труду. Сейчас я бы сказал, что авторы пропагандируют здоровый инженерный подход, а не просто программирование. Интересно, что я уже рассказывал про книгу, но тогда фокусировался на своих записях из 2000х годов, а теперь решил поговорить про pragmatic programmer , ключевого персонажа, которого описывают авторы и который - Заботится о качестве своего кода и принимает ответственность за свои решения (care about your craft) - ту есть отсылка к craft, а не engineering, в те времена были разные школы мысли о том, является ли программирование инженерной деятельностью или это скорее craftmanship (потом даже появился craftmanship manifesto для софта) - Применяет принцип DRY (don't repeat yourself), избегая дублирования кода - Использует автоматизацию для повышения эффективности разработки (automation) - Регулярно тестирует код и применяет подходы вроде TDD (test-driven development) - Постоянно обучается и адаптируется к изменениям технологий (по прошествии 25 лет я бы поставил этот пункт на первое место) - Использует системы контроля версий (Version Control) как обязательную часть рабочего процесса - Стремится к написанию понятного, легко поддерживаемого кода. - Применяет техники отладки (debugging), такие как разговор с уточкой (rubber duck debugging) - Следует принципам YAGNI ("You aren't gonna need it"), избегая излишней сложности - Применяет подходы рефакторинга для улучшения структуры кода В книге есть забавные истории про теорию разбитых окон ("broken windows theory"), о каменном супе ("stone soup") или супе из топора в русских сказках, а также метод отладки "резиновая уточка" ("rubber duck debugging"). Книга была издана чуть больше 25 лет назад и на тот момент она была чрезвычайно прогрессивной и новаторской - из описанного выше она ввела или популяризировала - Принципы DRY, принци ортогональности (orthogonality) для декомпозиции системы на независимые компоненты (decoupling), важность рефакторинга - Сфокусировала внимание на автоматизации процессов разработки и тестирования задолго до массового распространения CI/CD (Continuous Integration/Continuous Delivery) систем. Например, в то время многие компании не использовали даже VCS, не то что не писали тесты - Сделала акцент на личной ответственности программиста за качество своего продукта, что было новаторским подходом на фоне тогдашних более формализованных методологий - Предложила концепцию постоянного обучения и адаптации как неотъемлемой части профессионального роста разработчика задолго до того, как это стало общепринятым стандартом P.S. Интересно сравнивать то, что интересовало меня 20+ лет назад при прочтении книги и как я сейчас на нее смотрю с высоты опыта:) #SelfDevelopment #Engineering #Software #SoftwareDevelopment #Management #Leadership

Using Architectural Kata in Software Architecture Course: An Experience Report (Рубрика #Architecture) Эта статья вышла летом 2023 и в ней Usman Nasir из Blekinge Institute of Technology (Швеция) рассказывал о своем опыте обучения студентов software architecture с использованием кат. Этот опыт основан на одном семинаре с катами на 20 студентов в рамках продвинутого курса по архитектуре. И хоть ничего нового в описании нет, но мне нравится сама идея использовать архитектурные ката при обучении студентов. Семинар по архитектурным ката был интегрирован в курс обучения как групповое упражнение, где студенты совместно участвовали в мероприятии, направленном на проектирование, документирование и оценку получившейся архитектуры. В качестве задачек были взяты ката с сайта Ted Neward architecturalkatas.com, но были выбраны такие задачи, доменная область которых была легко понятна студентам, например, Check Your Work или Making The Grade. Сам семинар включал в себя - Discussion & design phase - на этой фазе студенты изучали проблему, определяли архитектурные драйверы (нефункциональные требования, ограничения), а также дизайн решения, которое удовлетворяет требованиям - Peer review & voting phase - на этой фазе студенты презентуют свои решения и оценивают работу друг друга, причем для оценок использовалась шкала -- Nailed it: все ключевые функциональные требования закрыты и атрибуты качества учтены, а получившееся решение достижимо в плане реализации (feasible) -- Missed a few things: в решении пропустили какие-то ключевые функциональные требованя или атрибуты качества -- Missed it, badly: врешение пропушены ключевые функциональные требованя, атрибуты качества или сделаны большие неверные предположения при дизайне После окончания курса преподаватель собрал отзывы и они показали положительный опыт студентов. Участники сообщили об улучшении не только технических навыков, связанных с проектированием и оценкой архитектуры, но и soft skills, таких как командная работа, коммуникация и критическое мышление. Студенты оценили практический характер семинара, который позволил им практиковать принятие архитектурных решений без давления, связанного с реальными проектами. В принципе, мне кажется, что проведение архитектурных ката - это хороший способ практического обучения - Для студентов в универах это можно совместить с реальной реализацией предложенного решения на протяжении всего семестра - Для инженеров в компаниях это можно совместить с воркшопом по проектированию спроектированного поверх возможностей, что есть в IDP (internal developer platform) #Architecture #SystemDesign #Management #Engineering #Software #SoftwareArchitecture #Edu #Whitepaper

Парк Львов "Земля Прайда" (Рубрика #Kids) Сегодня с детишками мы были в парке львов "Земля Прайда". Мы часто ездим загород по выходным к родителям жены, а этот парк оказался всего в получасе езды от их дома. Поэтому мы проснулись сегодня утром, позавтракали, а дальше сели в машину и поехали в парк, где спокойно тусят львы, тигры, медведи и другие животные. Мы приехали почти к самому открытию парка, поэтому посетителей было немного и мы, прикупив ведерки с едой для животных, смогли пройтись по територии и потренироваться в метании мяса тиграм и львам, а также покормить с рук кроликов, уток и гусей, коз, овечек, верблюдов и осликов. Парк нам понравился - Многие животные были выкуплены из неволи и выхожены сотрудниками парка - видно, что они достаточно вольготно живут и хорошо питаются - На территории парка все сделано для животных и людей - вальеры для животных большие, тигры, мишки и львы живут на большой и огороженной территории, где ты поднимаешься по лестнице наверх и дальше смотришь не через прутья клетки, а как бы с высоты на зверей - В парке есть львиный прайд, который только просыпался в районе 10 часов - то есть бросать надо было точно иначе львы не особо горели желанием идти за мясом За час мы быстрым темпом обошли всех животных, потом взяли по капучино для взрослых и по мороженному для детей в кафешке, сели в машину и поехали обратно. В итоге, получился очень легкий и приятный выезд на природу - благо Солнышко и теплая погода сделали эту прогулку еще приятнее. #ForParents #ForKids #Family #Stories

Интервью с Глебом Михеевым про Individual Contributors, Site Reliability Engineering и надежность Летом прошлого года мы записали выпуск подкаста "Фичи Катятся" с Глебом Михеевым, автором канала "Уставший техдир" (@tired_glebmikheev). Примерно в это время Глеб поменял работу и занялся AI-ассистентом в Сбере, поэтому снятое отправилось на полку. А сегодня Глеб опубликовал эту запись, где мы с ним много общались про развитие инженеров, проектирование систем, обеспечение их надежности и безопасности. В общем, за час мы успели обсудить много интересных тем. Вообще, мы часто с Глебом встречаемся на разнообразных конференциях и часто такие разговоры получаются очень насыщенными. Рад, что в этот раз мы записали такое общение на камеру:) Сам выпуск доступен почти везде: ВК, Rutube, Spotify, Apple Podcast. #Engineering #Software #Reliability #Architecture #Management #Processes #Leadership

[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx) Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели. Независимые переменные Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий 1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи - "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал - "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье 2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно - "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал 3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях - "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше - "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше 4) Goals & priorities - это про ясность целей и про изменение приоритетов 5) Interruptions - здесь авторы замеряют влияние встреч 6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡 Где - 𝑦 - это самооценка продуктивности для инженера i в момент t - 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков - 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России) - 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t - 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t - 𝜖𝑖𝑡 - это ошибка во время t Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где - Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками - T - это категорийная переменная, что означает разницу между периодами - после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

How To Build The Future: Aravind Srinivas (Рубрика #AI) Интересное интервью CEO и ко-основателя Perplexity ребятам из Y Cominator. Я сам с большим удовольствием пользуюсь Perplexity как основным поисковым движком, а также ассистентом для размышлений. Именно поэтому мне было интересно глянуть историю о том, а как была создана компания, как она развивалась и куда идет сейчас. В итоге, основные идеи этого выступления примерно следующие 1) Происхождение Perplexity и путь основателя Аравинд начал свой путь в ИИ с обучения в Индии, после чего переехал в США, где стажировался в OpenAI под руководством Ильи Суцкевера. Именно Суцкевер указал ему на важность обучения без учителя и обучения с подкреплением. После работы в Беркли над неконтролируемыми и генеративными моделями и стажировки в Google, Аравинд пришел к идее, что создание компании с ИИ и разработка продукта неразрывно связаны. Идея Perplexity родилась из поста Дэниела Гросса о создании следующего Google и концепции улучшения формулировки запросов с помощью суффиксов. Первоначально команда экспериментировала с вертикальным поиском и базами данных, используя модели OpenAI Codex для создания SQL-запросов. Это был продукт b2b для поиска по базам данных внутри компаний-закачиков 2) Эволюция продукта Первый прототип Perplexity был создан за выходные и вдохновлен статьей WebGPT. Хотя изначально использовалась медленная модель 175 AGP, команда применила эвристический подход, выбирая первые k ссылок и краткие описания из кэша. Аравинд отмечает парадоксальный момент: "глупый подход сработал, когда модели стали лучше следовать инструкциям". Это позволило решить проблемы с задержкой в пользовательском интерфейсе, сократив время ответа с 7 секунд до приемлемого значения. Ключевым фактором успеха стала возможность задавать дополнительные вопросы, что удвоило время взаимодействия пользователей с продуктом. 3) Конкурентное преимущество и стратегия Аравинд не видел прямой конкуренции с Google из-за перегруженности их интерфейса, хотя запуск чата Bing от Microsoft вызвал некоторое беспокойство. В отличие от Google, Perplexity фокусируется на том, что "пользователь всегда прав", требуя уточнений от ИИ. Потребительские продукты, по мнению Аравинда, должны быть проще и удобнее для пользователей. 4) Корпоративная культура и подход к разработке Основной показатель эффективности компании — количество запросов в день. Еженедельные и ежемесячные данные помогают управлять командой без жесткой иерархии. Компания активно использует Twitter для общения с клиентами, ценя прямолинейную критику больше, чем комплименты. Аравинд подчеркивает важность "дотошных и одержимых людей в команде" и постоянной "борьбы с энтропией" для поддержания качества. 5) Будущее и видение Аравинд видит Perplexity как "более интеллектуальный поиск", чем Google, стремясь создать место для полного пользовательского опыта. Он планирует построить систему из небольших моделей и графов знаний, уделяя особое внимание управлению ИИ и новым моделям монетизации. В отличие от Google, компания позиционирует себя как организация, "заботящаяся о пользователях и продукте", способная быстро внедрять новейшие модели и обучать их. Это дает Perplexity преимущество в конкуренции с технологическими гигантами, которым сложнее интегрировать инновации из-за их размера и устоявшихся бизнес-моделей. #AI #Software #Engineering #Storytelling #ML #Architecture