Книжный куб

Остановка. Мокьюментари-драма с элементами детектива @ Театр "Практика" Вчера мы с женой ходили на эту постановку и нам понравилось. Завязка всей истории звучит так

Однажды муж, отец и успешный бизнесмен Виктор Волков остановил свой BMW 5-й серии возле трамвайной остановки, вышел из машины и сел на скамейку. Это событие привлекло внимание всего города и разрушило две счастливые семьи.

На самом представлении ты попадаешь в небольшой зал, где восемь рядов сидений по 11 мест и сцена начинается прямо от первого ряда:) Сама сцена минималистична - есть наклоненный полукруг в центре диаметром в 3-4 метра с кубиком на нем и 4 отдельных кубика по краям, на которых могут сидеть артисты. Логично, что актеров как раз четверо - двое мужчин и двое женщин, которые играют семейные пары. Все остальные персонажи появляются в виде больших голов прямо внутри наклоненного круга, который оказывается экраном, на котором транслируются их мини-видео интервью в нужные моменты постановки. В общем, интерьер не отвлекает от игры актеров, которые показывают как может выглядеть остановка в жизни каждого человека и к каким последствиям она может привести. Эта постановка местами веселая, а местами грустная, подталкивает на размышления:) #Theater #SelfDevelopment #Culture

Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) - Part II В этом посте я продолжу рассказ о книге Рэнди Пауша Последняя лекция (The Last Lecture), о которой я говорил в прошлом посте. Здесь я расскажу про мысли Рэнди о том, как жить собственной жизнью и каким принципам следовать. Большую часть принципов я практикую сам, а оставшиеся я хотел бы практиковать, но это сложновато:) - Мечтай по крупному - Усердие лучше, чем понты - Выбросить белый флаг - про неотвратимость некоторых событий - Заключим сделку - про то, как можно изменить динамику взаимоотношений с человеком - Не жалуйся, просто работай лучше - Лечи болезнь, а не симптомы - Не придавайте слишком много значения тому, что думают о вас окружающие - Для начала сядьте рядом - про работу в группе - Ищите в каждом лучшие стороны - Думай о делах, а не о словах - Если сразу добиться успеха не удалось ... пытайся снова и снова - Будь первым пингвином - отсылка к тому, что надо пытаться реализовывать новые идеи и не бояться неудач. В крайнем случае ты получишь опыт, а опыт - это то, что приобретаешь, когда не получаешь желаемого:) - Привлекай внимание людей - Забытое искусство благодарственных писем - Верность - это дорога с двухсторонним движением - Решение пятничного вечера - рассказ Рэнди о том, как он достигал выдающихся результатов. Многие его спрашивали как он это делает и он отвечал "Все очень просто. Просто позвоните мне в офис в пятницу в 10 часов вечера и я вам все объясню". Так он подсвечивал то, что для достижения цели надо упорно трудиться - Проявляйте благодарность - Делайте подарки - Рассчитывать можно только на то, что вы принесли с собой - Плохие извинения хуже их полного отсутствия - Говорите правду - Не забывайте о коробке с мелками - их запах порождает воспоминания из детства - Солонка за сто тысяч долларов - история про то, как в магазине в Дисней Парке поменяли бесплатно детям солонку, что они разбили, чтобы они не плакали и смогли подарить эту солонку родителям - Нет работы, недостойно тебя - Пойми, где ты оказался - пример того, как со своим уставом в чужой монастырь не ходят - Никогда не сдавайся - Помни об ответственности перед обществом - Тебе нужно только попросить - Прими решение: Тигра или Иа - быть оптимистом или пессимистом - Как стать оптимистом - Письма, письма, письма ... - про то, как письма знакомых и незнакомых людей помогали Рэнди на протяжении его последних дней. Эти письма стали приходить к нему после появления его последней лекции на Youtube и прихода настоящей популярности #SelfDevelopment

Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) - Part I Эта книга Рэнди Пауша и Заслоу Джеффри посвящена детским мечтам и их осуществлению. Рэнди был знаменитым профессором в Carnegie Mellon University, который занимался виртуальной реальностью еще когда это не было у всех на слуху. Около 20 лет назад ему диагностировали рак поджелудочное железы и шансов на излечение было немного. Руководство университета предложило ему выступить с "последней лекцией", что было традицией для профессоров, уходивших на пенсию. В итоге, Рэнди согласился дать лекцию, но рассказывал он не про достижения науки, а про достижение мечты вашего детства, а точнее про то, как прожить жизнь так, чтобы мечты стали реальностью. Про саму лекцию я рассказывал уже раньше. Но по мотивам лекции Рэнди решил написать еще и книгу, с чем ему помог Заслоу Джеффри, с которым общался Рэнди во время лечебных процедур и за 53 мини-лекции надиктовал все то, что вошло в итоговую книгу. Книга состоит из следующих частей - Последняя лекция - предыстория, где автор рассказывает как он пришел к идее последней лекции и как ее готовил, одновременно пытаясь победить болезнь, но столкнувшись с метастазами после операции и химиотерапии, поняв, что проживет меньше года - Воплоти в жизнь свои детские мечты - рассказы о том, как каждая детская мечта была реализована и как само их наличие и стремление к ним помогло Рэнди на протяжении жизни - Авантюры ... и усвоенные уроки - очень интересные рассказы о полученных уроках, мне особенно понравилась история о "голландском дядюшке", что говорит горькую правду, но которая может помочь измениться к лучшем (у Рэнди это был фидбек от профессора, у которого он был ассистентом, о том, что он слишком высокомерен и это помешает ему добиться многого) - Давай возможность другим людям воплощать их мечты - автор рассказывает о том, как будучи профессором он работал со своими студентами и помогал им достигать их своих целей. Например, тут была история о том, как сам Рэнди выступил в качестве "голландского дядюшки" для одного из студентов:) А за другого студента он вступился и добился, чтобы его не отчисляли за низкие результаты по матану и этот студент с блеском закончил университет и стал правой рукой Рэнди в исследовательской работе - Как жить собственной жизнью - в этой части приведены очень крутые советы о том, каким принципам следовать в своей жизни, и я про эти принципы напишу в продолжении этого поста - И наконец ... - финальная часть, в которой Рэнди делится тем, что он хотел бы сказать своим детям. И основная мысль тут такая

Я считаю, что родители должны учить детей получать радость от жизни и, самое главное, стремиться реализовать собственные мечты. Лучшее, что мы можем сделать, - это помочь им самим добиться цели. Я желаю своим детям, чтобы они нашли собственный путь в жизни и сумели реализовать свои мечты. И поскольку в этот момент меня не будет рядом с ними, я хочу, чтобы они ззапомнили мои слова: "Дети, не пытайтесь понять, кем я хотел вас увидеть. Я хочу, чтобы вы стали теми, кем сами захотите стать!"

#SelfDevelopment #PublicSpeaking #Software

Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) Эта книга Рэнди Пауша и Заслоу Джеффри посвящена детским мечтам и их осуществлению. Рэнди был знаменитым профессором в Carnegie Mellon University, который занимался виртуальной реальностью еще когда это не было у всех на слуху. Около 20 лет назад ему диагностировали рак поджелудочное железы и шансов на излечение было немного. Руководство университета предложило ему выступить с "последней лекцией", что было традицией для профессоров, уходивших на пенсию. В итоге, Рэнди согласился дать лекцию, но рассказывал он не про достижения науки, а про достижение мечты вашего детства, а точнее про то, как прожить жизнь так, чтобы мечты стали реальностью. Про саму лекцию я рассказывал уже раньше. Но по мотивам лекции Рэнди решил написать еще и книгу, с чем ему помог Заслоу Джеффри, с которым общался Рэнди во время лечебных процедур и за 53 мини-лекции надиктовал все то, что вошло в итоговую книгу. Книга состоит из следующих частей - Последняя лекция - предыстория, где автор рассказывает как он пришел к идее последней лекции и как ее готовил, одновременно пытаясь победить болезнь, но столкнувшись с метастазами после операции и химиотерапии, поняв, что проживет меньше года - Воплоти в жизнь свои детские мечты - рассказы о том, как каждая детская мечта была реализована и как само их наличие и стремление к ним помогло Рэнди на протяжении жизни - Авантюры ... и усвоенные уроки - очень интересные рассказы о полученных уроках, мне особенно понравилась история о "голландском дядюшке", что говорит горькую правду, но которая может помочь измениться к лучшем (у Рэнди это был фидбек от профессора, у которого он был ассистентом, о том, что он слишком высокомерен и это помешает ему добиться многого) - Давай возможность другим людям воплощать их мечты - автор рассказывает о том, как будучи профессором он работал со своими студентами и помогал им достигать их своих целей. Например, тут была история о том, как сам Рэнди выступил в качестве "голландского дядюшки" для одного из студентов:) А за другого студента он вступился и добился, чтобы его не отчисляли за низкие результаты по матану и этот студент с блеском закончил университет и стал правой рукой Рэнди в исследовательской работе - Как жить собственной жизнью - в этой части приведены очень крутые советы о том, каким принципам следовать в своей жизни, - И наконец ... -

Your AI Survival Guide • Sol Rashidi & Joe Reis • GOTO 2024 Интересный выпуск книжного клуба "Goto Book Club" про искусственный интеллект, в котором Joe Reis берет интервью у Sol Rashidi, автора книги "Your AI Survival Guide". И вот из чего состоит это интервью - Sol рассказывает о своем опыте работы с искусственным интеллектом: помогала запускать IBM Watson в 2011, была Chief Data and AI Officer в Sony Music, Chief Data and Analytics Officer в Merck Pharmaceutical и т.д. В общем, она занималась AI в больших корпорациях, но уже 8 месяцев как она стала ex C-suite executive - AI теперь демократизировался и он доступен не только крупным компаниям, что есть хорошо, но из-за этого возникает всеобщий хайп - А книга посвящена реальным проблемам и неудачам, связанным с искусственным интеллектом, и как их избежать. - Выбор AI стратегии в компании должен зависеть от зрелости самой организации и ее готовности к риску - Если организация консервативна (как многие корпорации), то важно убедиться, что стратегия ориентирована на внутренний мир, а не на внешний. Суть в том, что мы можем подвести внутренних клиентов, когда пытаемся внедрить AI, но скорее всего мы не готовы экспериментировать на внешних клиентах - Одновременно надо держать в голове крупные цели, но начинать с малого и тренировать мышцы (условно надо сорвать низковисящие фрукты и показать, что стратегия работает) - Сол прикольно рассказывает о том, что при выборе провайдера AI решений не надо слушать маркетинговый булшит продажников, а надо общаться с инженерами и solution архитекторами (которые обычно есть у провайдеров) - это поволяет понять насколько решение реально закрывает ваши потребности и его действительно можно тащить в прод - По мнению Сол open source подходит для небольших компаний или PoC, но в enterprise чаще используют managed сервисы. Отчасти это объясняется тем, что в enterprises в принципе любят коробки, так как крутые технари не готовы идти в условную корпорацию, поэтому собственных компетенций корпорациям не хватает. - Дальше Joe задал вопрос про то, что ждет AI в будущем и Sol дала прогноз насчет трех вещей -- В будущем компании начнут учитывать стоимость использования managed сервисах при оценке ROI внедряемых AI инноваций. Эту стоимость надо учитывать при внедрении решений. Сейчас все внедряют AI, но не всегда сводят экономику при этом -- Сейчас на AI тратятся огромные энергетические ресурсы, как на тренировки, так и на inference. Это все не очень сочетается с ESG повесткой и устойчивым развитием. Дальше тренды на AI и ESG попробуют свести вместе -- Сейчас хайп разворачивается вокруг LLM, которые показывают state-of-the-art результаты во многих областях. Много компаний делают foundational модели, другие файн-тюнят их под свои нужды. Сол предполагает, что дальше появится какой-то managed middle-layer, что позволит корпорациям не спускаться до уровня LLM. - Под конец Joe спрашивает Sol о том, как разработчикам повышать свою квалификацию в AI и Сол отвечает, что надо начинать с использования искусственного интеллекта в собственной жизни и в решении собственных проблем. Это может быть полезным для повышения квалификации. Сол предлагает изучать различные приложения и игроков в этой области, а также экспериментировать с ними. Также она предлагает пройти курсы по AI от топовых университетов, что доступны на Coursera, Edx, Linkedin. #DataScience #ML #AI #Data #PopularScience #Engineering

Leetcode - прогресс за четвертый месяц Продолжаю свою серию постов про свой опыт с Leetcode (смотри 1, 2, 3 и 4). Я закончил четвертый месяц с leetcode - В курсе "Data Structures and Algorithms" осталось пройти только часть про динамическое программирование - Пытаюсь стабильно решать ежедневные задачи, но под конец месяца срываюсь в пике (особенно, если куда-то уезжаю) - Но решать только задачки на leetcode стало скучно - например, в отпуск я взял с собой книгу "Алгоритмический тренинг" от Максима Иванова, которая показалась мне интересной. Автор хорошо разбирает типовые задачи, причем разбор часто элегантнее, чем то, что я могу придумать сходу сам:) В общем, дофамин от решения задач пока никуда не делся, поэтому я продолжаю тренироваться с алгоритмами. Правда, я думаю, что скоро начну решать задачки и на codeforces.com, так как задаи для самостоятельного решения из книги "Алгоритмический тренинг" ведут на codeforces, а я хочу проверять насколько хорошо я понял материал книги:) #SelfDevelopment #Algorithm #Software #SoftwareDevelopment

А вот обложки оригинальной и переведенной книг, а также немного иллюстраций, чтобы стал понятен стиль изложения.

MBA в картинках (The Visual MBA) - Part II Продолжая первый пост про книгу, расскажу про оставшиеся 8 глав 13. Рассмотрение и принятие решений - рассказ алгоритм вида: проблема -> цели -> альтернативы -> последствия -> компромиссы. А дальше автор рекомендует использовать волшебный вопрос "зачем", смотреть на вопрос с разных точек зрения и знать про наши biases и две системы мышления 1 и 2 Канемана и Тверски. Подробнее про мышление и принятие решений можно почитать книги из моих подборок: на тему системного и критического мышления и на тему работы мозга 14. Роль генерального директора - про решение задач и устранение проблем в условиях неопределенности, про постановку задачек по SMART (specific, measurable, assignable, realistic, time-related), а также про change management (про это можно почитать простенькую книгу "Наш айсберг тает", про которую я писал раньше и по мотивам которой часто проводят игры на тему внедрения изменений) 15. Стратегическое мышление - такая себе глава, где говорится про консенсус в принятии коллективных решений, а рядом говоритс о том, что надо знать когда принять решения самому. Приводятся в пример разные исторические лидеры и дальше оценивается их стиль принятия стратегических решений по итоговому результату:) В общем, проявление эффекта ореола во всей красе. Рекомендую по поводу стратегического мышления прочитать книгу "Теория игр. Искусство стратегического мышления в бизнесе и жизни", а по поводу заблуждений менеджеров почитать книгу "The Halo Effect", про которую я уже рассказывал 16. Креативность и инновации - рассказ про дивергенцию и конвергенцию, про метод мозгового штурма, человека типа Т. Рекомендую на тему креативности в компаниях прочитать книгу про Pixar "Корпорация гениев" ("Creativity, Inc"), про которую я уже рассказывал 17. Основы стартап-маркетинга - рассказ о том, как придумать крутую идею продукта, как работать с фокус-группами (используя подход шести шляп мышления), как продавать эмоции от использования продукта, а не его свойства 18. Производительность и мотивация - здесь разбирается модель принципала и агента, которую я люблю использовать для размышлений, а также упоминается сбалансированная система показателей (balanced scorecard), которая была модной 20 лет назад вместе с концепцией реинжиниринга бизнес-процессов:) 19. Глобальный менеджмент - как выходить на глобальный рынок, учитывая все отличия: культурные, административные, географические, экономические 20. Собираем все воедино - в этой главе автор показывает как построить путь к своему бизнесу используя знания из предыдущих глав (условно перечисляет в каком порядке знакомится с этими главами) #Thinking #SelfDevelopment #Management #Leadership #MBA

MBA в картинках (The Visual MBA) - Part I В отпуске я прочитал эту книгу с кучей картинок, где двухгодичный цикл обучения MBA упакован в 200 страниц картинок с небольшими примесями текста. И могу сказать, что формат подачи и сами иллюстрации в книге достаточно неплохие, но если вы не изучали эти темы отдельно, то такое краткое саммари не даст вам понимания ни в одной из тем - в книге 20 отдельных глав, где каждой уделяется 10 страниц. Но вот если вы были знакомы с темами заранее, то чтение этой книги позволяет вспомнить много из изученного. У меня как раз такой случай - я проходил разные вариации mini-MBA и MBA уже несколько раз и даже писал про них - Про программу MBA INSEAD+Tinkoff и рекомендованная литература (моя версия) - Блоки из mini MBA, что проходил до этого про лидерство и про мотивацию - Блоки из новой программы MBA Tinkoff + Сколково, которую я посещал со вторым потоком, например, про организационное поведение Если возвращаться к самой книге, то она состоит из 20 глав 1. Лидерство - здесь немного про бренд лидера и как производить впечатление, про автономность, мастерство и цель, которую надо давать своим последователям и про командную работу 2. Корпоративная финансовая отчетность - здесь речь про бухгалтерский учет (Активы = Обязательства + Собственный капитал), про отчеты о финансовых результатах, о движении денежных средств, прогнозный отчет. Также разбираются фин коэффициенты соотношение заемного капитала к собственному, коэффициент текущей ликвидности, рентабельность собственного капитала, норма чистой прибыли, а также модель Дюпона 3. Предпринимательский менеджмент - как искать идею для своего бизнеса (стоит идти от боли, которую мы хотим решить). Здесь приводится цепочка: сопереживание -> распознование -> идея -> прототип -> испытание. 4. Управленческий учет - базовый рассказ про постоянные и переменные издержки и ABC (activity-based costing) 5. Финансы предприятия - рассказ про цепочку капиталовложний: капитал -> активы -> товары -> продажи -> прибыль -> капитал. Дальше рассказ про дисконтированную стоимость денег и сложные проценты 6. Маркетинг - рассказ про сегментирование аудитории, позиционирование продукта и брендинг, а также про цепочку: свойство продукта -> преимущество продукта -> преимущество для покупателя -> личная ценность. 7. Операционный менеджмент - здесь рассказ про то, как организовывать процессы и основные моменты вида: время выполнения, выработка, время цикла, производительность, эффективность, узкое место. Про это можно глянуть книгу “Визуализируйте работу” (“Making Work Visible”) 8. Стратегическое управление персоналом - найм, мотивация и оценка результативности сотрудников (выше уже упоминал что можно почитать) 9. Деловые переговоры - здесь надо больше слушать, а не говорть, а также иметь альтернативный вариант для обсуждаемого соглашения. Рекомендую почитать "Большую книгу переговоров" для прокачки этих навыков (я уже вспоминал про нее) 10. Стратегия - здесь все начинается с модели 5 сил Портера, продолжается модель VRIO (Value,Rarity, Imitability (ease/difficulty to Imitate), Organization (ability to exploit the resource or capability)) и заканчивается концепциями алого и голубого океанов:) Рекомендую на тему стратегии почитать книгу "Теория игр. Искусство стратегического мышления в бизнесе и жизни" за авторством Авинаша Диксита и Барри Нейлбаффа. И еще материалов, что я рекомендовал раньше 11. Деловая этика - контролируйте эмоции + проверьте мысленно что будет, если про ваши действия расскажут в новостях ... а дальше действуйте в соответствии с этикой 12. Финансирование предпринимательской деятельности - рассказ про SWOT анализ, венчурные инвестиции, жизненный цикл компании А про оставшиеся 8 глав я расскажу в следующем посте. #Thinking #SelfDevelopment #Management #Leadership #MBA

Самарканд Вместе с женой вдвоем мы улетели на три дня майских праздников в Самарканд, чтобы провести время вдвоем, погулять по улочкам этого древнего города, поесть узбекского плова и выспаться:)) В общем и целом, пока все идет по плану и из вышеперечисленных пунктов выполнено все, кроме плова, но сегодня мы это исправим, а завтра уже полетим домой. Если же говорить о впечатлениях о городе, то мне как туристу он понравился - чистые улицы целая россыпь достопримечательностей из славной истории Средней Азии (включая памятники Тамерлана), вкусная еда. А вот насколько тут комфортно жить - это большой вопрос. Мне показалось, что темп жизни тут очень размеренный. #Vacation

Чистый дизайн (Tidy First?) - Part V - Теория (Theory) Этот пост заканчивает серию постов про книгу "Чистый дизайн" (предыдущие посты: 1, 2, 3 и 4). - Зацепление (coupling) - автор описывает концепцию каскадных изменений, когда изменения в одном компоненте тянут за собой изменения в других компонентах. Это свойство описали еще Эд Йордон и Ларри Константайн в своей книге "Structured Design" и определение звучало так

Два элемента считаются связанным в отношении некоторого изменения, если изменение одного элемента требует изменения другого элемента

В это определении важно не просто, что элементы связаны между собой, но и что эта связь существует относительно определенного изменения. Поэтому для анализа coupling недостаточно простого просмотра исходного кода - важно знать какие изменения уже произошли, а также какие возможны в будущем. В итоге, coupling повышает затраты на разработку, поэтому при очистке часто полезно понимать какие изменения приведут к его уменьшению. - Равенство Костантайна (Constantine’s equivalence) - интересная цепочка размышлений автора -- Где он начинает с того, что большую часть совокупной стоимости владения кодов составляет стоимость измений -> cost(software) ~= cost(change) -- Продолжает тем, что стоимость изменений имеет степенное распределение (power law distribution), а не нормальное, откуда следует, что стоимость больших изменений перевешивает нормальные события -> cost(change) ~= cost(big changes) -- А большие изменения обусловлены высоким coupling -> cost(big changes) ~= coupling Так получается равенство Константайна: cost(software) ~= cost(change) ~= cost(big changes) ~= coupling или проще говоря

cost(software) ~= coupling

Поэтому все и хотят уменьшать coupling, но это требует компромиссов. - Зацепление и его уменьшение (coupling versus decoupling) - автор начинает с того, что "зацепление часто остается незаметным, пока на него не наступишь - совсем как кубик Лего в темной комнате". Но как появляется зацепление - есть несколько вариантов -- При реализации поведения мы выбрали путь с дополнительным зацеплением, учтя NPV решения (можно было сделать без него, но это было дольше и не ясно когда окупится) -- Изначально оно не создавало проблем (мы изначально не планировали делать изменения, которые теперь внезапно появились перед нами) -- Его было не избежать - в конце концов между нашими элементами системы должны быть отношения и взаимосвязи иначе это уже не система, а группа элементов:) Дальше мы должны принять решение - платить дальше за зацепление или заплатить за его уменьшение. Если построить график, то видно, что оба экстремальных решения приведут к чрезмерным затратам и нам нужно выбрать что-то посередине (как обычно где именно посередине остановиться надо искать эмпирически). - Связанность (cohesion) - здесь автор фактически говорит про кластеризацию элементов нашей системы. Условно сильносвязанные элементы должны попадать в свои кластера, а несвязанные элементы должны оказываться в разных кластерах. А вот coupling - это уже связи между этими кластерами. - Заключение (conclusion) - в последней главе автор рассказывает о том, как принимать решение по очистке

-- Затраты. Снизит ли уборка затраты на более позднее время или сделает их менее вероятными? -- Доход. Повысит ли уборка доход больше, быстрее или вероятнее? -- Coupling. Приведет ли уборка к тому, что мне придется менять меньше элементов? -- Cohesion. Сможет ли наведение порядка привести к тому, что элементы, которые мне нужно изменить, будут находиться в меньшем и более концентрированном объеме?

И напоследок он приводит сравнение очистки, рефакторинга и эволюции архитектуры, где меняется масштаб изменений, стейкхолдеры, причины и способы осуществления каждого из подходов. Плюс это только первая книга из серии, поэтому ждем следующую. P.S. В конце автор рекомендует кучу книг, из которых я читал всего несколько - "A philosophy of software Design" - "The Design of Everyday Things" #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Как Китай теряет свое экономическое превосходство | Разбор на цифрах (видео с канала MyGap) Как-то раньше я уже говорил, что мне нравится инфографика для представления информации. А еще я люблю иногда читать комиксы по сложным темам. Обе эти вещи скомбинированы на канале MyGap, где автор делает информативные мультики на интересные темы. Например, в последнем видео была разобрана история с китайским экономическим чудом, которое вывело экономику КНР на второе место о номинальному ВВП после США, и на первое по ВВП по паритету покупательной способности (с 2014 года). Бурный рост проходил с 1979 года по 2010, но потом чуддо забуксовало и за фасадом мегапроектов забрезжили убытки и долги. В этом видео MyGap расскажет на пальцах как китайское экономическое чудо теряет волшебный ореол и как это может отразиться на остальном мире:) #PopularScience #Economics #Comics #Infographics

Чистый дизайн (Tidy First?) - Part IV - Теория (Theory) Продолжая посты (1, 2 и 3) о книге "Чистый дизайн" расскажу про последнюю часть, в которой автор делится своими теоретическими изысканимями, которые позволяют наработать интуицию в принятии решений относительно дизайна софта. Здесь автор рассматривает вопросы

- Что такое программный дизайн? - Как дизайн влияет на разработку и эксплуатацию софта и наоборот? - Стоит ли вкладываться в проработку струтктуры софта и к чем это приведет? - Каакие принципы (экономические и гуманитарные) можно использовать для принятия решений о изменении структуры софта?

И вот что я вынес из этой части - Взаимовыгодные отношения между элементами (bene€cially relating elements) - собственно, это и есть определение программного дизайна от автора, которое лаконично и интересно. По-факту, в определении приведены основные части: элементы, отношения и взаимная выгода между ними. А дизайнеры - это те, кто как раз обеспечивают то, чтобы отношения были взаимовыгодными. - Структура и поведение (structure and behavior) - ценность кода в том, что он умеет делать уже сейчас (поведение), а также в том, что он сможет делать завтра (структура). Поведение можно характеризовать двумя способами: парами вход/выход и инвариантами, которые сохраняются во время изменений системы. Структура не влияет напрямую на поведение, но она влияет на варианты развития событий - насколько нам просто будет дорабатывать систему тем или иным способом. Изменения в поведении видны сразу, а вот изменения в структуре замерить сложно, поэтому их часто откладывают. - Экономика: ценность во времени и вариативность (economics: time value and optionality) - автор рассказывает про природу денег: -- Доллар сегодня стоит больше доллара завтра, поэтому зарабатывать надо раньше - тут можно посмотреть в сторону дисконтированных денежных потоков и NPV -- В ситуации хаоса лучше вариативность, чем однозначность, поэтому перед лицом неопределенность создавайте варианты В итоге, задачей дизайн автор видит согласование императивов "зарабатывать раньше/тратить позже" (поведение) и "создаавать вариативность, а не однозначность" (структура). - Доллар сегодня стоит больше, чем доллар завтра (a dollar today > a dollar tomorrow) - рассказ про пальцах про дисконтирование денежных потоков - Вариативность (options) - рассказ про "дилемму Златовласки", где у нас не должно быть слишком много дизайна или очень рано, но и не должно быть слишком мало дизайна или слишком поздно. Дальше вступает в дело концепция опционов, когда мы платим деньги сейчас за возможность купить что-то в будущем. В итоге, проектирование, которым мы знимаемся сегодня, - это "опционная премия", которую мы платим, "покупая" изменения поведения программы в будущем. - Опционы и денежные потоки (options versus cash flows) - здесь автор объясняет как принимать решения об очистке (tidying) с учетом наших знаний ою опционах. Одновременно звучит тезис о том, что программный дизайн - это про налаживание отношений с людьми, а очистка - это про отношения с самим собой:) Считать всю экономику для очистки часто бывает затратно, но принимая решения о ней мы тренируем -- Привычку читывать факторы, влияющие на время и область действия дизайна -- Навыки выстраивать взаимоотношения с людьми - Обратимые изменения структуры (reversible structure changes) - структурные изменения обычно обратимы, а вот изменения в поведении приводят к сайд-эффектам, которые мы не всегда можем откатить (условно, рассылка не тех сообщений не тем людям). В итоге, надо работать с разной степенью тщательности с обратимыми и необратимыми изменениями (это сходно с концепцией one-way door и two-way door decisions как это описывал Джефф Безос) В следующем посте я расскажу про оставшиеся части теории и про литературу, что советует изучать автор. #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

МегаШкола ИТМО 2024 Игорь Котенков - State of the LLM Landscape Интересный доклад с обобщением состояния дел в LLM (large language modes) от Игоря Котенкова, автора канала "Сиолошная" (@seeallochnaya), который я почитываю с интересом. Конкретно в этом видео автор за 2 часа дает хороший обзор последних достижений для студентов ИТМО. Из презентации (что доступна здесь) я вынес следующие моменты - Что такое большие языковые модели, как они работают и для чего их сейчас используют - Как LLMs уже влияют на реальный мир (особенно когда они начинают использовать интернет для выполнения действий) и какое их ждет будущее - Как обучают большие языковые модели - по-факту, модели предсказывают следующее слово в контексте, модель обучается на большом количестве текста (значимая часть интернета), дальше на выходе получается многогигабайт параметров, которые задают веса в моделе - Дальше модельку доучивают с использованием человека - есть пара текстов, где один из ответов выбирается человеком как лучший и это подается модельке. В итоге, это ускоряет процесс обучения и оптимизирует человеческие предпочтения. - ChatGPT - для создания модели использовались огромные мощности и высококачественные данные, а дальше продукт стал самым быстрорастущим в мире и достиг 100 млн пользователей примерно за 2 месяца - Чатботы сейчас уже можно использовать для автоматизации деятельности, например, для повышения эффективности разработчиков (подробнее в докладе про Copilot) или для повышения эффективности консультантов (пример от BCG) - LLMs могут научиться не просто гененрировать текст, но и некоторым навыкам, например, математическим - Исследователи активно работают на интерпертируемостью LLMs, в перспективе это позволяет модели запоминать и применять паттерны, а не запоминать все подряд. - При использовании LLMs могут быть проблемы с утечкой конфиденциальной информации - Пока единственный гарантированный способ сделать LLM лучше - это насыпать больше мощностей и подкинуть данные получше на стадии обучения, но исследователи постоянно пытаются придумать еще что-то, например, оптимизируя алгоритмы - К моделям можно подключать инструменты, например, калькулятор (или Wolfram Alfa, про это можно подробнее почитать в книге Стивена Вольфрама "What Is ChatGPT Doing ... and Why Does It Work?", про которую я рассказывал раньше) - Модели можно помогать, попросив построить цепочку рассуждения (chain-of-thought prompting) - Дальше внешние инструменты и chain-of-thought можно объединить в подходе ReAct (Reasoning + Actions). ReAct - это способ промтинга, позволяющий модели выполнять несколько шагов поиска информации. Игорь дает интересные примеры с моделями -- Для поиска информации в интернете и вставкой текста в модель -- Для использования сервиса для обмана капчи:) -- Для синтеза ядов -- Для генерации предметов в майнкрафте, где модель создала себе skill library и выучила скиллы по созданию предметов - LLMs могут работать не только с текстом, но и с видео, звуками и другими модальностями - На базе LLMs можно создавать автономные браузерные агенты, которые будут выполнять действия на сайте, предсказывая, что нужно сделать. - Для обучения моделей можно использовать синтетические данные, сгенерированные другими моделями. Это позволяет улучшить качество обучения и увеличить навыки модели. - Есть направление по использованию LLM в научных исследованиях, так как LLM могут генерировать десятки тысяч, сотни тысяч ответов на задачи, что позволяет строить дерево мыслей и находить правильный ответ. В будущем такие модели могут быть использованы для создания научных статей и новых знаний. - Сейчас LLMs могут выдумывать факты или соглашаться с неправильными фактами, но это может быть решено в будущем. - Дальше ML будет охватывать все новые и новые сферы или доводить до идеала те, в которых уже применяются технологии. В итоге, будет работа как по созданию лучших моделей, так и по интеграции существующих моделей для решения реальных бизнес-задач. #DataScience #ML #AI #Data #PopularScience #Math

Чистый дизайн (Tidy First?) - Part III - Управление (Managing) Продолжая посты (1 и 2) о книге "Чистый дизайн" расскажу про вторую часть, в которой автор рассказывает о том, как управлять очисткой: когда начинать, когда заканчивать, а также как объединить ее с изменением поведения системы. Здесь автор дает следующие советы - Очистка отдельно (separate tidying) - очистку надо проводить отдельно от изменений, что меняют поведение системы. Это можно легко организовать заворачивая все изменения по очистке в отдельный MR (merge request). Плюс надо думать над размером MR - он должен давать некоторую картину для понимания изменений, но, одновременно, не быть слишком большим для осмысления - Цепочки (chaining) - когда вы начинаете очистку, то эти изменения начинают создавать изменения для дальнейшей очистки. Важно уметь планировать очистку на несколько шагов, а также знать, когда требуется остановиться. Подробнее про подходы к очистке можно прочитать во втором посте по книге - Размер наборов операций (batch sizes) - здесь автор рассказывает как определиться с размером очистики. Он предлагает оценивать стоимость ревью изменений (что форсирует не делать маленькие MRs с очисткой) и проблемы с большими батчами по очистке: потенциальные коллизии, изменения в поведении и спекулятивные изменения. В итоге, нам надо найти оптимум:) - Ритм (rhythm) - автор говорит о том, что в уборке нужна ритмичность - мы не можем разово убраться и забыть об очистке:) Нам надо делать это периодически, если мы хотим жить в чистом месте - Распутывание (getting untangled) - иногда, при написании кода, изменяющего поведение, приходит идея провести очистку. Дальше опять дописать код, что меняет поведение, а потом еще почистить код. Автор предлагает не делать так, а если все таки у вас получилось такое запутанное изменение, то снести его и дальше сделать все сначала с новыми знаниями и пониманием, что надо поделить изменения поведения и очистку на отдельные MRs - До, после, позже, никогда (first, after, later, never) - ответ на вопрос, а когда делать очистку. И это как обычно it depends ... И тут все зависит от экономических эффектов: если очистка сильно поможет нам с дальнейшим внесением изменений, то можно начать с нее. А если нам никогда-никогда не придется менять код (мы пишем разовый скрипт), то чистить ничего не требуется:) А вот варианты в промежутке уже посложнее и по ним автор дает следующие рекомендации: - Проводите очистку после изменений, если -- Ожидание следующего удобного случая, чтобы провести ее сразу перед изменениями, обойдется дороже -- Без этого вы не чувствуете, что работа завершена - Проводите очистку позже, если -- Очистка предполагает много работы, которая не возымеет немедленного эффекта -- Ее завершение окупится позже -- Ее можно проводить небольшими частями #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Lessons from a Hyperscaler • Casey Rosenthal • GOTO 2024 Интересный доклад от Casey Rosenthal, автора книги "Chaos Engineering", в котором он рассказывает о тех уроках, что были получены от работы в компаниях-гиперскейлерах, где hyperscale это

Hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system.

Сам автор работал в компании Netflix и был изначально в traffic team, которая отвечала за то, чтобы Netflix работал для пользователей. А в комплексных системах возникает такой уровень сложности, который не помещается ни в одну голову. Для того, чтобы бороться с этой сложностью в Netflix придумали Chaos Monkey, который рандомно отключает машинки с частями системы. Это помогает инженерам искать системные недостатки и принимать решения для повышения надежности системы. Дальше автор приводит конкретный пример с двумя микросервисами, один из которых stateful и хранит данные в persistent DB, а также у него есть кеш в Redis. А дальше что-то идет не так со stateful сервисом и вся система деградирует:) Суть примера в том, что в комплексных системах возможны пробелмы, несмотря на то, что все компоненты соответствуют спецификациям. Автор говорит про 4 модели, что помогают гиперскейлерам бороться со сложностью: - Observability (not metrics) - обеспечение наблюдаемости системы, просто метрик для этого не достаточно - DevUX (platfoorm engineering) - создание платформенных команд, что делают dev2dev продукты, что снижают когнитивную сложность (можно почитать мой разбор "State of Platform Engineering Report 2023 от Puppet") - Experimentation over testing - экспериментирование, а не тестирование. Суть в том, что эксперименты помогают узнать что-то новое о системе, а тестирование - это проверка того, что система соответствует нашим ожиданиям - Low bureaucracy - низкий уровень бюрократии, где у инженеров достаточно полномочий на то, чтобы делать свою работу без кучи согласований Автор рассказывает про 4 экономических столпа комлексности - States - ограничение количества состояний системы. Например, Ford Model T, где потребитель мог купить машину любого цвета, если этот цвет черный:) Но сейчас это ушло в прошлое и мы ценим вариативность и персонализацию продуктов под конкретного клиента - Relationships - здесь у нас тоже все идет по нарастающей - добавляются новые связи, новые уровни абстракции, динамическое поведение систем становится все сложнее - Environment - окружающая среда тоже не отличается предсказуемостью и мало кто из компаний может на нее как-то значимо повлиять в свою пользу (если вы не Amazon или Google) - Reversability - а вот тут разработка софта сильно выделяется на общем фоне. Мы можем выбрать для себя фокус на этом и получить возможность откатывать изменения. Тут нам в помощь CI/CD, a/b тестирование гипотез, ... Но для того, чтобы это все работало нам требуется observability. И автор рассказывает про подходы: observability 1.0 и observability 2.0, где observability 1.0 это • Metrics (метрики) • Unstructured logs (неструктурированные логи) • Structure logs (структурированные логи) Недостатком observability 1.0 является убывающая полезность и нарастающие затраты на создание и хранение логов и метрик. Суть в том, что по мере роста системы, добавления компонентов, инцидентов, логов будет становиться все больше и сложно будет искать в них нужную информацию, а также это все будет занимать все больше места. В качестве ответа автор говорит про observability 2.0, который обладает следующими возможностями: - Это подход с high cardinality / high dimenions и в одном месте, который является единым источником истины - Из этого хранилища можно получать показатели, логи, структурированные и неструктурированные данные - А кроме того, это не уменьшает эффективность разработчиков, а скорее увеличивает за счет использования одного решения У нас в Tinkoff таким единым источником истины является Sage, наша obserbility платформа, которая является стандартом де-факто для всех в компании. #Devops #PlatformEngineering #Management #SoftwareDevelopment #Software #SRE

Чистый дизайн (Tidy First?) - Part II - Очистка (Tidyings) Продолжая первый пост о книге "Чистый дизайн" расскажу для начала про первую часть, в которой автор рассказывает о концепции небольших изменений, которые делают код проще. Причем здесь мы меняем структуру софта, а не его поведение. Автор говорит, что это напоминает рефакторинг и tidyings - это подможество рефакторинга. Отдельный термин появился потому, что рефакторингом теперь часто называют и те измения, что меняют поведение программы, а автор это хочет четко отделить. В итоге автор предлагает следующие подходы - Охранные выражения (guarding clauses) - вынос в начало функции начальных выражений, которые надо учитывать и ранний возврат при их наступлении из функции - Мертвый код (dead code) - его просто надо удалить (если он понадобится, то его можно будет восстановить из системы контроля версий) - Нормализация симметрий (normalize symmetries) - если кратко, то надо использовать консистентные подходы по всему коду, например, подход к определению и инициализации переменных. Тут могут помочь линтеры или подходы к readability, как в Google (про которые я писал раньше в посте про measuring engineering productivity) - Новый интерфейс, старая реализация (new interface, old implementation) - при реализации изменений мы можем определить новый красивый интерфейс и всех перевести на него, а поначалу под капотом дергать вызов старой реализации. На самом деле это дефолтный подход при миграциях:) - Порядок чтения кода (reading order) - файл с кодом должен быть устроен так, чтобы его было удобно изучать читателю (забавно, что это верно для всего: книг, презентаций, мануалов) - Принцип связности (cohesion order) - суть в том, чтобы организовать код в файле так, чтобы при изменениях элементы, что меняются вместе, распологались рядом. Это же верно и для разных файлов, что сцеплены (coupling) - их можно перенести в общий каталог. - Соединение объявления переменной и его инициализации (move declaration and initialization together) - опять же тут суть в том, чтобы свести связанные кусочки логики вместе - Пояснительные переменные (explaining variables) - создание отдельных переменных для сложных выражений вместо вычисления их just in place, например при прокидывании выражения в параметры вызываемой функции - Пояснительные константы (explaining constants) - создание констант вместо раскиданных по коду магических значений - Явная передача параметров (explicit parameters) - вместо прокидывания hashmap с ненормированным количеством параметров лучше их явно прокинуть в параметры при вызове функции - Визуальная группировка инструкций (chunk statements) - если при чтении кода вы понимаете, что одна часть делает вот это, а другая делает то, то просто добавьте дополнительную пустую линию между этими блоками кода, плюс этот блоки кода можно улучшать при помощи остальных советов из этой части - Извлечение функций-хелперов (extract helper) - извлечение вспомогательных блоков кода в отдельные функции с именем - Одна большая свалка (one pile) - во время очистки иногда требуется свести все части кода в одно место, а уже потом применять остальные подходы. Когда мы делаем так, то получаем одну большую свалку. - Содержательные комментарии (explaining comments) - если при чтении куска кода у вас щелкает и возникает мысль "Ах, вот что это такое", то есть смысл записать это озарение в комментарий - Удаление избыточных комментариев (delete redundant comments) - иногда при очистке кода часть комментариев становится очевидной, в этот момент такие комментарии стоит удалить. #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Чистый дизайн. Практика эмпирического проектирования ПО (Tidy First?: A Personal Exercise in Empirical Software Design) - Part I Вчера меня доставили новую книгу Кента Бека (Kent Beck), который много лет назад придумал экстремальное программирование (XP, Extreme programming) и участвовал в подписании Agile Manifesto. Прошлую книгу Кента я читал почти 20 лет назад, когда только начинал заниматься разработкой, поэтому я сразу прикупил себе перевод издательства Питер и прочитал ее в тот же день, когда мне ее доставили. Книга получилась определенно интересной, хоть и жутко короткой. Смысл книги можно передать вспомнив слоган стирального порошка Tide, созвучного с названием книги: "Вы еще кипятите? Тогда мы идем к вам!". - Введение (Introduction) - начало книги автор посвящает рассказу о том, как он подходит к вопросам проектирования софта. И что дизайн софта - это острозаточенный инструмент, которым не все умеют пользоваться. А цель автора книги - помочь разработчикам чувствовать себя безопаснее. В итоге, автор пытается рассматривать дизайн не с точки зрения теории, а с точки зрения практики. Когда у нас есть насущная задача поменять поведение софта (добавить фичу), а также есть структура софта, которая может помогать этому а может мешать. И автор предлагает очистку как способ борьбы со сложностью. В книге 3 части, про которые я расскажу в отдельных постах - Часть I. Очистка (Tidyings) - Часть II. Управление (Managing) - Часть III. Теория (Theory) #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture