Книжный куб

Вычислительная машина и мозг (The Computer and the Brain) (Рубрика #PopularScience) С большим интересом я прочитал это научно-популярное исследование, посвященное сравнению человеческого мозга и вычислительных машин. Эта книга не завершена и опубликована посмертно почти 70 лет назад (в 1958 году). Изначально этот материал Джон готовил для Силлимановских лекций в Йеле. Сама книга до сих пор актуальна, а в свое время была пророческой. Она состоит из трех частей 1) Первая часть посвящена устройству вычислительных машин: памяти, хранимому коду программы, аналоговым и цифровым элементам. 2) Вторая часть исследует мозг с точки зрения нейронных сетей, памяти и логической глубины. 3) Неоформленная третья часть касается выводов о роли кода и языка в системах36. Основные идеи: 1) Сравнение мозга и компьютера Фон Нейман рассматривает мозг как вычислительный механизм, сравнивая его с современными ему компьютерами. Он анализирует аналоговые и цифровые аспекты работы мозга и машин, начиная с базовых элементов — нейронов и транзисторов. Автор исследует различия и сходства в архитектуре, памяти, обработке информации и точности работы мозга и ЭВМ. По-факту, он комбинирует теорию информации, начало которой положил Клод Шеннон, а также идею про абстрактный вычислитель от Алана Тьюринга (так называемая машина Тьюринга). 2) Ключевыми вопросы - Является ли мозг аналоговым или цифровым автоматом? (как мы помним в 50-е годы 20 века знаний о мозге были сильно, чем сейчас) - Может ли искусственный интеллект достичь уровня человеческого разума? Фон Нейман, беря за основу идею машины Тьюринга, приходит к выводу, что различия между ними минимальны, несмотря на разницу в строительных блоках. 3) Роль языка и информации В конце книги поднимается вопрос о том, какой язык использует мозг для обработки информации. Фон Нейман предполагает, что этот язык может быть менее логически строгим, чем привычные математические системы. Мне кажется, что эта часть обрывается затравкой - Джон не смог дописать свои лекции из-за болезни, которую уже победить не смог. Эта книга интересна как попытка объдинить биологию и информатику в рамках кибернетики еще 70 лет назад, а также показала путь к междисциплинарному подходу к изучению интеллекта — как естественного, так и искусственного. Интересно, что Джон фон Нейман сделал еще много хорошего в разных дисциплинах, среди которых 1) Архитектура компьютеров: Разработал концепцию фон Неймановской архитектуры, которая легла в основу современных компьютеров. Принципы этой архитектуры следующие - Единое хранилище памяти для программ и данных - Процессор. Процессор предназначен для обработки данных и выполнения команд из памяти - Последовательное выполнение команд. Команды выполняются одна за другой, в строгой последовательности - Ввод-вывод. Устройства ввода-вывода обеспечивают интерфейс между компьютером и внешним миром. - Адресуемая память. Все данные и инструкции имеют уникальные адреса в памяти, что позволяет процессору быстро получать доступ к нужной информации. 2) Теория игр: Совместно с Оскаром Моргенштерном заложил основы теории игр. Его теорема о минимаксе стала фундаментом для изучения стратегического поведения в экономике, политике и других областях. Интересно, что этой работой заинтересовался Джон Нэш, который продолжил копать тему теории игр, а потом получил за нее Нобелевскую премию 3) Квантовая механика: Внёс вклад в математическое обоснование квантовой механики, разработав алгебру фон Неймана и концепцию гильбертова пространства для описания квантовых систем. 4) Манхэттенский проект: Участвовал в разработке атомной бомбы, предложив концепцию взрывных линз для симметричного сжатия плутониевого ядра. 5) Клеточные автоматы: Разработал теорию клеточных автоматов и концепцию самовоспроизводящихся систем, что стало основой для моделирования сложных систем и развития искусственного интеллекта. Подробнее про Джона можно прочитать в книге "Человек из будущего" (она у меня на очереди) или в интересной статье с кратким обзором #SelfDevelopment #Brain #PopularScience #Thinking #Architecture

How to Learn: Unlocking the Brain's Secrets • Barbara Oakley & Charles Humble • GOTO 2024 (Рубрика #SelfDevelopment) Интересный подкаст клуба goto, в котором Чарльз Хаммел берет интервью у Барбары Оукли. Барбара автор очень популярного курса "Learning How to Learn" на Coursera. К этому курсу Барбара написала книгу "Думай как математик" ("A Mind For Numbers"), про которую я раньше уже рассказывал. А в этом подкасте было поднято много интересных тем 1. Для разных предметов эффективны разные методы, напрмер, для изучения языков и математики 2. Интересно, что Барбара сама прошла путь от ученого-лингвиста до профессора по инженерии. Книга "Мышление в цифрах", что я уже упоминал выше посвящена методам обучения, подходящим для STEM-дисциплин. 3. Сейчас есть кризис повторяемости результатов исследований в общем, а также исследований в образовании. Барбара приводит конкретные примеры, когда популярные, но неэффективные методы обучения сопровождались научными статьями, результаты которых не удалось повторить 4. Барбара рассказывает о двух работах мозга: сосредоточенный и рассеянный. Для эффективного обучения нужно уметь переключаться между режимами 5. Физические упражнения помогают в обучении, повышая когнитивные способности и успеваемость 6. Тренировки помогают вырабатывать нейротрофический фактор мозга BDNF, который помогает нейронам соединяться друг с другом, а также способствует лучшему усвоению знаний 7. Сон помогает мозгу обрабатывать и закреплять новые знания, а правильное питание, включая растения, орехи и темный шоколад, способствует здоровью мозга. 8. Осознанная практика помогает в обучении - важно практиковать выполнение сложных задач, так как рост на стандартных задачах без вызовов гораздо медленнее 9. Для обучения, как и для работы важна психологическая безопасности, которая означает уважение и способность бросать вызов. В эффективных командах важно бросать вызов и обсуждать неудобные темы. Подробнее можно почитать про проект Аристотель - тут ребята из Google исследовали факторы, что делают команды эффективными и самым важным фактором стала psychological safety 10. Для обучения важно как понимать как работает working и long-term memory. Рабочая память позволяет временно удерживать информацию. Долговременная память хранит информацию надолго. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Подробнее про типы памяти можно почитать в книге "The Programmer's Brain", о которой я уже раньше рассказывал 11. Гиппокамп быстро формирует и разрушает связи в мозге. Зубрежка перед тестом неэффективна, так как связи быстро исчезают. Повторение с интервалами помогает лучше запоминать информацию. 12. Память хранится в соединениях между нейронами. Эти связи формируют память, как биты в компьютере. 13. Метафоры помогают связывать концепции и понимать новые идеи. А также они помогают лучше их запоминать 14. Барбара рассказывает как она использует AI в обучении через суммаризацию сложных документов перед началом их изучения. 15. Учителя должны обучать студентов эффективному обучению. А AI может помочь им в преподавании, но для этого сами учителя должны быть готовы к новым технологиям 16. Наши знания ржавеют и воспоминания исчезают, если их не использовать. Дендритные отростки могут отмирать, если не использовать навыки. Использование знаний помогает восстановить забытые навыки. 17. Есть еще много областей в исследовании мозга, которые покрыты туманом неизвестного и поэтому тут можно и нужно проводить дальнейшие исследдования, что принесут нам понимание и удивительные результаты P.S. Если этот подкаст вам понравился, то могут понравиться материалы из моего предыдущего поста с подборкой материалов на тему работы мозга. #SelfDevelopment #Brain #PopularScience #Thinking

ЦЕХ 4 - Урок #26 "Работа автора с литературным агентом. Эксперт — Галина Бочарова" (Рубрика #Writing) В очередном уроке разбирался вопрос, а кто такие литературные агенты и с чем они могут помочь начинающему или продолжающему автору. Об этом рассказывала Галина Бочарова, опытный литературный агент. Основные моменты, что я вынес из урока такие 1. Зарубежом важность литературных агентов достаточно велика, особенно в США и Европе, где они играют ключевую роль. В России их влияние пока ограничено. 2. Но даже на российском рынке виден рост числа агентов - это связано с интересом к переводным книгам, ростом уровня русскоязычных авторов и развитием цифровых платформ, таких как Bookmate. 3. Авторы могут сотрудничать с агентами для продвижения книг, но это не всегда необходимо. Важно выбирать подходящие издательства и правильно готовить рукописи, но это могут делать сами авторы самостоятельно 4. Договоры с издательствами требуют внимательного изучения. Особое внимание следует уделять правам на экранизации, переводы и театральные постановки, которые могут приносить значительный доход. 5. Продажа прав на кино, переводы и зарубежные рынки может быть сложной, но прибыльной. Агенты активно работают с продюсерами и зарубежными партнёрами. 6. Агенты получают комиссию (обычно 20%) от авансов, роялти и других доходов. Дополнительный доход возможен через цифровые сервисы и продюсирование проектов. 7. Издательства могут требовать активного участия автора в продвижении. Агент помогает в этом процессе, но автор также должен быть вовлечён. 8. Агенты готовы работать с новичками, если видят потенциал. Однако это требует больших усилий и рисков. 9. На рынке есть отдельно агенты, а также скауты. Агент представляет интересы автора за комиссию, а скаут работает на издательство за фиксированную оплату. Предыдущие посты про этот курс писательского мастерства доступны здесь 1. Увидеть свое имя на обложке может каждый 2. Целевая аудитория и ее потребности в создании книги 3. Жанры и стили. Как найти тему для нон-фикшн-книги 4. Как организовать работу 5. Как преодолеть писательские блоки. Практическое занятие 6. Жду музу, а она все не приходит 7. Книга по полочкам 8. MS Word для работы с большими и сложными текстами 9. Рассказываем истории: сторителлинг в книге 10. Саморедактура: работа с текстом, сокращения, фактчекинг 11. Правила сильной книги захватывающего текста 12. Авторская стилистика 13. Как превратить рукопись в сценарий 14. Рукопись готова. Что дальше? 15. Превращение рукописи в издание 16. Авторские права и договор с издательством 17. Дизайн книги. 18. Продвижение в самиздате. 19. Продвижение автора 20. Social media marketing (SMM) 21. Ведение блога и его продвижение в Телеграме 22. Взаимодействие с обозревателями, критиками и СМИ 23. Продвижение автора. Личный кейс 24. Продающие тексты 25. Как стать брендом? #SelfDevelopment #PublicSpeaking #Storytelling #Writing

Менеджмент ИТ-проектов (IT Project Management: On Track from Start to Finish) (Рубрика #Management) Разбирал старые бумаги и наткнулся на свой сертификат руководителя проектов (PMP). На этом фоне решил вспомнить как 17 лет назад изучал целую пачку книг по управлению проектами, когда начал учиться в только что открывшейся магиструре IBS в МФТИ:) Тогда я купил и заботал несколько книг на эту тему, одна из которых оказалось именно этой книгой Джозефа Филлипса. Сама книга включала информацию по каждому этапу процесса управления проектом, включая инициацию, планирование, выполнение, мониторинг и завершение проектов. Основные темы, охватываемые в книге, включают определение требований к проекту, создание технико-экономических обоснований, управление объемом и расходами проекта, разработку планов управления проектом, организацию и руководство командами, отслеживание прогресса с использованием таких метрик, как индекс производительности по затратам, внедрение изменений и обеспечение постоянного управления качеством. Помню, что тогда мне книга не зашла, а перечитывая сейчас я понял почему - она написана формально и содержит нужную информацию, но она выглядит или формальной или очевидной. Чтобы достать что-то интересное, требуется иметь опыт и внимательно вчитываться в каждую главу. Отдельно автор активно промотировал сертификации в общем, а также экзамен CompTIA Project+ в частности:) На голову выше были две книги, который я изучил еще в то время - "Проектный бизнес - Адаптированная модель для России" - "Rita Mulcahy's PMP® Exam Prep, Tenth Edition" (тут конечно издание было не последнее, а сильно более раннее) Еще из интересного стоит отметить, что в магистратуре IBS учили не управлению проектами по PMI (Project Management Institute), а его альтернативе в виде IPMA (International Project Management Association), а точнее его локализованной российской версией в виде СОВНЕТ. Если говорить откровенно, то те же яйца, только в профиль:) #Management #Leadership #Processes #Project #ProjectManagement

Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Рубрика #Management) Это очередной обзор статьи из серии человеческого подхода к продуктивности разработчиков. Это статья фокусируется на критических аспектах онбординга и наращивания скорости работы инженеров. Основные моменты этой статьи следующие 1. Вопрос онбординга очень важен - это процесс перехода нового инженера от новичка до продуктивного члена команды. Он важен как для индивидуального успеха, так и общекомандной производительности. Эффективный онбординг может сократить время "разгона" и улучшить долговременную продуктивность 2. Но адаптации инженеров часто мешают стандартные проблемы: недостаточная документация, отсутствие наставничества, неясные ожидания от инженера, а также сложные исходный код проектов. Эти факторы могут задерживать способность разработчика эффективно вносить вклад в работу команды 3. Для оценки качества онбординга надо уметь его измерять. По-факту, это измерение относиться к измерению продуктивности инженеров, но так как нас интересуют только результаты изменений в подходах к онбордингу, то авторы решили мерить не саму продуктивность, а изменения в ней. 4. Предыдущие подходы к ramp-up-time metrics включали сравнение параметров новчиков с опытными инженерами, но авторы этого исследования пошли своим путем, в котором им нужно было избежать сравнения между самими инженерами-новичками (иначе у них появилась бы мотивации геймить метрики и показывать как они здорово онбордятся). В итоге, они решили валидировать метрики-кандидаты относительно восприятия самих инженеров относительно того, насколько они заоонбордились в стандартные инженерные задачи. 5. Авторы исследовали 9 метрик-кандидатов и выбрали для дальнейшего анализа 3, в которых есть прогресс со временем работы и выход на некоторый стабильный уровень. Это метрики - Active coding time per line of code (LOC) - Reviewed LOC - Submitted LOC Дальше авторы аггрегировали новых инженеров по недельным когортам, а потом начали отслеживать сколько недель потребуется этим метрикам, чтобы выйти на стабильный уровень и оставаться там по-крайней мере 4 недели. 6. Потом авторы запустили опросы для инженеров (что работали меньше 40 недель). Этот опрос прошло порядка 3к инженеров. Вопросы были вокруг 17 стандартных задач, навроде, writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe и так далее. Вопросы были про опыт вокруг этих задач в последнюю неделю и было 5 вариантов ответов от "Я не выполнял таких задач", до "Я уже выполняю такие задачи на максимально эффективном уровне по моим ожиданиям". 7. Авторы нашли стат значимую негативню корреляцию между "Active coding time per LOC" и самооценкой эффективности выполнения 15 из 17 задач. А 6 из 17 задач стат значимо были связаны с submitted LOC. Авторы взяли и эту метрику в качестве ramp-ut-time. 8. Авторы рассказали про результаты COVID-19 для ramp-up-time, так как у них данные начали собираться еще до всей петрушки. - Для инженеров до COVID-19 средняя круизная скорость была в 2.5 раза выше, чем начальная. А для выходящих в COVID она стала всего 1.5x - До COVID 19 инженеры выходили на стабильный submitted LOC за 12 недель, а после - за 18 недель 9. Авторы думают, что смогут использовать результаты исследования для помощи коллегам, которые запускают образовательные инициативы и треннинги для инженеров внутри компании Авторы предлагают следующие рекомендации для улучшения онбординга - Предоставляйте исчерпывающую документацию и четкие guidelines. - Назначайте наставников или «buddies» для помощи новым разработчикам. - Реализуйте структурированные программы адаптации с определенными этапами. - Поощряйте обратную связь от новых сотрудников для совершенствования процессов адаптации. - Инвестируйте в инструменты и системы, которые упрощают навигацию по исходникам и рабочим процессам. P.S. Разводящий пост с обзорами всех статей из серии доступен здесь. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Les Art Resort (Рубрика #Kids) Эти выходные мы с женой и детьми провели в Les Art Resort, отмечая ее день рождения. Нам очень понравилось - здесь много развлечений для детей и взрослых: тюбинги, открытый и закрытый бассейны, игровые комнаты для детей, боулинг, биллиард, зоопарк с оленями, которвх можно покормить с руки и много еще чего. В общем мы сюда еще приедем и изучим подробнее в следующий раз:) #ForKids #ForParents

ЦЕХ 4 - Урок #25 "Продающие тексты. Эксперт — Игорь Манн" (Рубрика #Writing) В очередном уроке Игорь Манн рассказывает про построение личного бренда. А уж он знает в этом толк:) Из этого урока я вынес следующие основные идеи 1) Личный маркетинг (что равно личному бренду) начинается с постановки цели и аудита самого себя. А еще он должен быть системным 2) Для этого можно задать себе четыре главных вопроса: кто вы, что вы делаете, как вы это делаете и как об этом узнают. 3) Личный бренд помогает целевой аудитории запомнить вас и выбрать ваши выступления, статьи и книги. 4) К этому вопросу надо подходить системно и работать параллельно над качеством и узнаваемостью 5) Вообще, это про инвестиции в себя, в образование, книги, внешний вид, благоприятные условия для жизни, работы и новых впечатлений 6) Игорь советует начать заниматься личным брендом сразу, а не тогда, когда вы набьете 10к часов в своей области и станете экспертом 7) В личном бренде важно постоянство - нельзя делать это иногда или по настроению 😍 Игорь говорит, что важно быть хорошим профессионалом, а уже затем хорошим человеком (это из серии, что хороший человек - это не профессия) 9) Автор отмечает необходимые навыки, которые нужны человеку доверие, коммуникабельность, умение общаться с ИИ, инициативность, тайм-менеджмент, личную эффективность, умение продавать и стрессоустойчивость, умение доводить дела до конца и проявлять упорство. 10) А дальше можно оценить свои навыки и понять, что требуется просто поддерживать, а над чем надо поработать 11) Игорь говорит о важности самопрезентации и предлагает упражнение "100 слов о себе", а потом экстремальные "3 слова о себе" 12) Для личностного роста нужны вызовы, проходя которые ты делают тебя сильнее (прямо как по Ницше) 13) Секрет профессионального долголетия Игоря в том, что он постоянно занимался самообразованием и стремился стать номером один в своей области. 14) Важно иметь хорошие отношения в семье и уделять ей достаточно времени, а также окружать себя интересными людьми и работать над своим нетворкингомЁ 15) Можно сделать SWOT анализ самого себя и понять сильные и слабые стороны, а также расписать возможности и угрозы 16) Важно правильно работать с самооценкой и уметь преодолевать синдром самозванца 17) В этом могут помочь сравнения с более ранней версией самого себя или крутыми конкурентами 18) Также полезны профессиональные достижения и признание людей 19) Но для всего этого надо работать много, системно и по приоритетам 20) Для того, чтобы это сделать нужно уметь отвечать на вопрос "А зачем мне это нужно":) Предыдущие посты про этот курс писательского мастерства доступны здесь 1. Увидеть свое имя на обложке может каждый 2. Целевая аудитория и ее потребности в создании книги 3. Жанры и стили. Как найти тему для нон-фикшн-книги 4. Как организовать работу 5. Как преодолеть писательские блоки. Практическое занятие 6. Жду музу, а она все не приходит 7. Книга по полочкам 8. MS Word для работы с большими и сложными текстами 9. Рассказываем истории: сторителлинг в книге 10. Саморедактура: работа с текстом, сокращения, фактчекинг 11. Правила сильной книги захватывающего текста 12. Авторская стилистика 13. Как превратить рукопись в сценарий 14. Рукопись готова. Что дальше? 15. Превращение рукописи в издание 16. Авторские права и договор с издательством 17. Дизайн книги. 18. Продвижение в самиздате. 19. Продвижение автора 20. Social media marketing (SMM) 21. Ведение блога и его продвижение в Телеграме 22. Взаимодействие с обозревателями, критиками и СМИ 23. Продвижение автора. Личный кейс 24. Продающие тексты #SelfDevelopment #PublicSpeaking #Storytelling #Writing

CMMI (Capability Maturity Model Integration) (Рубрика #Management) Когда я только начинал свою карьеру как инженер на слуху были модели зрелости для процессов разработки софта, а конкретнее CMMI. Сегодня я решил вспомнить историю этой модели и границы применимости, так как в последнее время я вижу большое увлечение разными моделями зрелости, например, KMM или ACMM. Я расскажу про них подробнее в следующий раз, а сегодня давайте поговорим про CMMI. Изначальную версию CMM (Capability Maturity Model) разработал SEI (Software Engineering Institute) внутри Carnegie Mellon University в конце 1980х годов для Department of Defense. Цель была в том, чтобы улучшить практики разработки софта в этом ведомстве. К 2000 годe CMM объединило в себе разные модели зрелости и расширилось на еще одно слово Integration, чтобы выйти в свет в виде модели CMMI и увеличить границы применимости. Фреймворк строился вокруг концепций возможностей и зрелости - Возможности относились к способностям организации достигнуть бизнес-цели через хорошо выстроенные процессы - Зрелость отображала концепцию эволюции процессов во времени от ad-hoc до файнтюна и вылизывания выстроенных процессов:) Фокус был на определении, имплементации и непрерывном улучшении процессов для обеспечения консистентности и эффективности. Фреймворк включал цели и лучшие практики для помощи в движении к лучшим процессам. В нем были следующие уровни зрелости 1) Initial: непредсказуемые и реактивные процессы (условно реакция по факту произошедшего события) 2) Managed: процессы планируются и выполняются с учетом политик 3) Defined: процессы хорошо описаны и стандартизированы 4) Quantitatively Managed: процессы измеримы и контролируются с учетом статистических методов 5) Optimizing: фокус на улучшении процессов через инновации Адепты этого подхода упирали на плюсы фреймворка 1) Increased efficiency and productivity - это достигалось за счет стандартизации и оптимизации, что приводило к выравниванию workflow и лучшему распределению ресурсов 2) Quality improvement - предполагалось выравнивание процессов на требования заказчиков для повышения качества продуктов и удовлетворенности клиентов 3) Competitive advantage - достижение высоких уровней зрелости выделяло компании на рынке, что показывало их приверженность лучшим практикам (особенно актульно для сервисных компаний, что делают проекты на заказ) 4) Scalability - фреймворк позволял организациям масштабироваться по мере роста и наработки какой-то специфики А среди недостатков выделяли 1) Complexity and cost - имплементаци CMMI была комплексной, требовала кучу времени и была дорогой из-за выделения значительных ресурсов, тренировок и документации 2) Rigidity - модель была негибкой, а также предотвращала внедрение новых практик и технология, что появлялись после ее внедрения 3) Bureaucracy - модель требовала значительного количества документов, что повышало уровень бюрократии и снижало гибкость и креативность (ака без бумажки ты букашка) 4) Lack of customizability - эта общая модель не всегда хорошо натягивалась на любую организацию (например, на bigtech компании, что взлетали в начале 2000-х), что ограничивало такие организации, если они пытались внедрить CMMI В итоге, я видел внедрения CMMI в начале 2000х в сервисных компаниях (галерах), которые работали на рынке заказной разработки, но не слышал ни про одну bigtech компанию, принявшую эту модель. Я думаю, что причина в том, что на вопрос "А какую проблему мы решаем" эта модель CMMI не дает никакого ответа внутри продуктовой компании. Я думаю, что надо фокусироваться на конкретных практиках, что решают конкретные проблемы, например, - Процесс написания RFC и фиксация арх решений в ADR - Ведение техрадара в организации - Как работать с надежностью систем: observability, SLI/SLO/SLA, бюджет ошибок - и так далее Но вот в упор не могу понять на...я выбивать уровень 5 CMMI кроме как порадовать своего внутреннего бюрократа. #Processes #Management #Metrics #Leadership #Software

Evolution of software architecture with the co-creator of UML (Grady Booch) (Рубрика #Architecture) Интересная серия подкаста с Гради Бучем, на книгах которого я учился в самом начале карьеры:) Гради придумал объектно-ориентированное программирование, был одним из создателей языка UML (Unified Modeling Language), а также основал компанию Rational Rose, которую 20 лет назад купил IBM. Сразу после покупки Rational Гради стал Fellow внутри IBM и, судя по разговору в подкасте, именно это ни один раз его спасало от увольнения (как я понял Fellow нельзя так просто взять и уволить). В следующем году Гради исполнится уже 70 лет, но он бодр и полон сил. Сам подкаст затрагивает следующие основные темы 1) Эволюция разработки ПО: разработка программного обеспечения - это история повышения уровня абстракции, где современные фреймворки и облачные сервисы стали ключевыми архитектурными решениями. 2) Роль архитектора изменилась: теперь архитектор решает системные проблемы и управляет более абстрактными уровнями системы. 3) Гради Буч примерно 20 лет назад получил предложение от Билла Гейтса стать Chief Architect всего Microsoft, но он отказался и сосредоточился на работе в IBM, в частности, в области искусственного интеллекта (помогал делать IBM Watson). 4) UML был создан для описания систем на разных уровнях абстракции и впоследствии стал стандартом. Несмотря на это, со временем его использование уменьшилось из-за сложности, которая появилась в версии 2+. Кстати, я действительно помню, как сложность скачком увеличилась и UML начали двигать от визуализации архитектуры в сторону языка прогаммирования, из которого можно генерить код на обычных языках 5) Среди современных вызовов есть следующие - В bigtech компаниях иногда используют формальные методы для описания алгоритмов распределенных систем - это нужно для сложных случаев - AI и LLM сейчас на коне, но Гради отмечает их потенциальные ограничения и опасности. 6) Эволюция архитектуры произошла из-за распределенных систем, которые потребовали новых методов обмена сообщениями между частями системы. А современные архитектурные решения часто зависят от предварительно созданных компонентов и API, что снижает риски и затраты на создание систем. 7) Напоследок Гради дает совет, что начинающим инженерам-программистам не стоит бояться экспериментировать и учиться новому. #DistributedSystems #Architecture #Software #SystemDesign

Enabling efficient analysis of biobank-scale data with genotype representation graphs (Рубрика #Data) Наткнулся тут в рассылке от ACM (Association of Computing Machinery) на новость, что отлично демонстрирует то, что большие данные уже не такие большие:) Собственно, в генетике данных было всегда много после того, как ученые научились расшифровывать геном. Но эти данные надо было уметь где-то хранить и быстро лопатить для того, чтобы извлекать инсайты. И теппрь ученые-исследователи из Корнелла разработали новый метод сжатия данных, который позволяет хранить большие геномные наборы данных на локальных компьютерах. Раньше эти данные весили сотни террабайт, а теперь они жмутся в гигабайты. Этот метод, названный Genotype Representation Graph (GRG), описан в статье, опубликованной 5 декабря 2024 года в Nature Computational Science. GRG использует графы для представления генотипов, что позволяет компактно и интуитивно кодировать информацию о геномах, а также выполнять вычисления без необходимости разжатия данных. Это делает анализ биобанковских данных более эффективным и менее затратным. В отличие от традиционных матричных представлений, GRG фиксирует связи между индивидами через общие мутации в их геномах. Метод был разработан для решения проблемы роста объема данных, который теперь может достигать петабайтов из-за увеличения доступности полногеномных последовательностей. GRG обеспечивает масштабируемость и точное представление данных, позволяя проводить сложные анализы, которые ранее были недоступны из-за высокой вычислительной стоимости. Исследование уже привлекло внимание научного сообщества, и другие ученые начали тестировать метод на различных наборах данных. Работа поддержана грантом Национального института здравоохранения США. #Data #Math #Software #Whitepaper

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture) Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие 1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance 2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии 3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем 4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения 5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения 6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег 7) Следующий шаг - это дизайн ревью решений в асинхронном формате 😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью. 9) Дальше появляется реестр таких документов и возможность поиска и анализа решений 10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата 11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения 12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы 13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок. 14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются 15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners 16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий. 17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life) 18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее 19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров #Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Quantum Computing Inches Closer to Reality After Another Google Breakthrough (Рубрика #Physics) Интересная статья вышла на этой неделе в New York Times, в которой рассказывается про последние достижения Google в области квантовых вычислений. Суть в том, что Google заявляет о достижении "квантового превосходства", так как их квантовый компьютер на чипах Willow решил синтетическую задачу за минуты, а классическим суперкомпьютерам на архитектуре фон Неймана потребовались бы септиллион лет (10^24 лет). Звучит конечно круто, но так как задача синтетическая, то пользы от нее можно не ждать, но при этом достижении ребята из Google смогли преодолеть проблему коррекции ошибок. Суть в том, что квантовые компьютеры состоят из квантовых битов или кубитов, которые изолированы от окружающей среды и заморожены до сверхнизких температур. Вычисление представляет собой последовательное измерение функции Шредингера для системы из всех кубитов, чтобы в конце прийти к состоянию, где наиболее вероятным состоянием при измерении будет то, что дает правильный ответ. Вся эта машинерия может очень интересно сбоить, поэтому в процесс надо встраивать коррекцию ошибок, которая в этом компьютере ребят преодолела некоторый порог, который приближает всю эту конструкцию к практическому применению. В общем, по всем характеристикам это крутое событие, что усилит конкуренцию между технологическими гигантами, каждый из которых делает свои квантовые компьютеры. В интересное время мы живем. P.S. Рекомендую почитать книгу Алексея Семихатова "Сто лет недосказанности: Квантовая механика для всех в 25 эссе", про которую я рассказывал недавно. #PopularScience #Physics #Software #Architecture #Engineering

Big Data is Dead (Рубрика #Data) Этот пост Jordan Tigani вышел почти два года назад в блоге компании MotherDuck, которая является материнской для DuckDB. Сам Jordan был одним из инженеров, что стояли у основ Google BigQuery, а потом он отвечал за ее продуктовое развитие, а значит знает о чем говорит. Ну а компания MotherDuck пытается сделать облачную версию DuckDB, интересную аналитическую in-process базу данных, про которую рассказывали в докладе "DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 ", который я уже разбирал. Но если возвращаться к самой статье, то основной посыл Джордана в том, что эпоха «больших данных» как доминирующей концепции завершилась. Суть в том, что большинство организаций на самом деле не работают с огромными объемами данных, и акцент должен сместиться с размера данных на получение практических инсайтов. Ключевыми идеями статьи являются 1) Рассмотрение хайпа больших данных через призму реальности: нарратив о том, что компании перегружены огромными объемами данных, не оправдался для большинства организаций. Хотя объемы данных растут, развитие аппаратного обеспечения и технологий баз данных опережает эти темпы, делая традиционные системы достаточными для многих задач. 2) У большинства компаний умеренный объем данных: анализ клиентских данных Google BigQuery показывает, что большинство организаций управляют относительно небольшими наборами данных, часто менее 1 терабайта. Даже крупные предприятия редко генерируют или обрабатывают действительно огромные массивы данных, а типичные рабочие нагрузки затрагивают лишь небольшую часть хранимой информации. 3) Разделение compute и storage: современные облачные архитектуры разделяют хранение и вычислительные ресурсы, позволяя масштабировать их независимо. Это привело к росту объема хранилищ при тех же вычислительных потребностях, так как аналитика чаще сосредоточена на актуальных или агрегированных данных, а не на исторических архивах. 4) Экономические и практические ограничения: обработка больших объемов данных дорогостоящая и зачастую избыточная. Такие технологии, как колоночное хранилище, отсечение разделов и сжатие данных, сокращают объем обрабатываемой информации, что соответствует экономическим стимулам минимизировать затраты. 5) Данные как источник риска: хранение большого количества неиспользуемых данных может создавать риски, включая проблемы с соблюдением нормативных требований (например, GDPR), юридическую ответственность и операционные сложности из-за «старения» старых наборов данных. 6) Спад популярности систем для больших данных: традиционные монолитные базы данных (например, MySQL и Postgres) демонстрируют рост популярности, тогда как масштабируемые системы вроде NoSQL стагнируют. Количество рабочих нагрузок, требующих распределенных систем, сократилось благодаря значительному увеличению возможностей одиночных машин. Напоследок Джордан предлагает компаниям оценивать свои реальные потребности в работе с данными вместо того, чтобы следовать маркетинговым нарративам о «больших данных». Большинство организаций могут извлечь выгоду из инструментов для управления данными меньшего масштаба вместо инвестиций в системы для гипотетически огромных массивов информации. Кстати, одним из таких инструментов может быть и DuckDB (это читается между строк). P.S. В продолжении темы можно изучить 1) Статью "What Goes Around Comes Around... And Around..." Майкла Стоунбрейкера, создателя Postgres, и Эндрю Павло, исследователя баз данных, про развитие СУБД за последние 20 лет. У меня есть краткий обзор в трех частях: 1, 2 и 3 2) Выступление от создателя DuckDB "A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024" и мое краткое саммари 2) Подкаст "Research Insights #6 с Колей Головым про дата платформы" 3) Подкаст "Code of leadership #22 с Димой Аношиным про data engineering" #Database #Architecure #Software #Data #SystemDesign #Engineering

Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms (Рубрика #Data) И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm За время подкаста мы обсудили темы - Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой - Как можно строить платформы данных (централизованно, гибридно и децентрализованно) - Как выглядят принципы федерализации данных (аля data mesh) в теории - Во что этот подход превращается на практике - Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году - Что не так с классическими базами данных (Postgres и иже с ним) - Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...) - Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике - Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов - Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute - Что такое medalion architecture - Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения Дополнительные материалы - Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы" - Статья из периода работы в Manychat: 1 и 2 - Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov" - Запись "DataVault / Anchor Modeling / Николай Голов" - Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009 - Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019 #Data #Datamesh #Processes #Management #Architecture

Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open Добрался на пятый митап российского сообщества разработчиков СУБД и распределенных систем, на котором будут доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и CedrusData. Мероприятие является частью конференции ISPRAS Open в Москве. Программа митапа плотная и насыщенная: - Эволюция архитектуры СУБД на примере YDB,  Андрей Фомичев, Яндекс, основатель и руководитель YDB - отличный доклад получился (Андрей и его ключевые мысли из доклада на первом снимке) - Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata - доклад тоже получается интересным (Костя и слайд про in-memory на втором снимке) Дальше будет еще пара докладов и панельная дискуссия про планировщики запросов - Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер - Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData #Database #Architecture #Management #DistributedSystems #Software #Engineering

Запустили open-source модели на 7 и 32 миллиарда параметров Сегодня мы выложили в открытый доступ две большие языковые модели на русском языке: T-Pro на 32 млрд параметров и обновленную T-Lite на 7 млрд параметров. Они построены на базе моделей Qwen 2.5 и дообучены на русский язык. T-Pro заняла второе место по бенчмарку MERA среди всех моделей, включая проприетарные, и первое место среди открытых. А T-Lite стала лучшей русскоязычной open-source моделью в классе «до 10 миллиардов параметров» по ряду индустриальных бенчмарков. 🎄Скачать модели можно с huggingface. Больше подробностей — совсем скоро ;)

Коллеги из AI Центра продолжают радовать большими языковыми моделями на русском языке - теперь вышла T-Pro, которая по бенчмаркам хороша. Отдельно стоит отметить, что новая модель T-Pro выложена в opensource как и T-Lite и обе можно скачать с Hugging Face.

ЦЕХ 4 - Урок #24 "Продающие тексты. Эксперт — Алена Лепилина" (Рубрика #Writing) В очередном уроке разбирался пример создания продающих текстов:) Я сразу вспомнил книгу "Пиши, сокращай", о которой я рассказывал раньше. Экспертом урока была Алёна, что работает с текстами более 16 лет, руководит командой контента и редактирует курсы. Алёна рассказывает о важности текстов и их влиянии на аудиторию. Основные тезисы урока 1) Пирамида аудитории - про это рассказывали подробно во втором уроке 2) Для написания своей книги: - Выделите свои смыслы и идеи, которые лежат на поверхности. - Работайте над книгой, пока не найдете новые идеи. - Продвигайте книгу, показывая её любой аудитории. 3) Для книги стоит составить контент план и дальше использовать разные площадки, правильно подбирая tone of voice в зависимости от площадки 4) В продающих текстах важно выстроить отношения с читателем, а не просто втюхать книгу. Для этого лучше не обещать больше того, что есть в книге:) 5) Можно писать про книги посты, подборки или гайды. Также можно писать трейлеры к книгам (внезапно по аналогии с трейлерами к фильмам) 6) Важно, чтобы текст к книге выщывал эмоции у читаталей, но не надо ими манипулировать и учитывать жанровую специфику - Нон-фикшн: упор на пользу и практичность. - Художественная литература: создание атмосферы и избегание спойлеров. - Детская литература: учет формата и возраста читателя. 7) При написании текстов важен ритм и ясность. Длину предложений стоит чередовать, а также не надо перегружать читателя деталями, надо быть кратким и понятным 😍 Истории лучше сопровождать иллюстрациями 9) Тексты должны быть уникальными и интересными.Важно удивлять аудиторию и вдохновлять её. Важно писать нестандартно и оригинально. 10) Можно проявлять креативность в текстах, но не надо забывать проверять факты (делать фактчекинг) 11) Редактировать тексты стоит безжалостно - надо дорабатывать текст до момента, пока он не станет интересным и полезным. Можно привлекать внешнего редактора (так каксамому часто сложно резать написанный текст) 12) Чтобы писать хорошие тексты, надо много читать других авторов и профессионально развиваться в этой области 13) Полезно иметь сильный личный бренд - это помогает продвигать книгу 14) Стоит использовать аналитику для оценки эффективности текстов Предыдущие посты про этот курс писательского мастерства доступны здесь 1. Увидеть свое имя на обложке может каждый 2. Целевая аудитория и ее потребности в создании книги 3. Жанры и стили. Как найти тему для нон-фикшн-книги 4. Как организовать работу 5. Как преодолеть писательские блоки. Практическое занятие 6. Жду музу, а она все не приходит 7. Книга по полочкам 8. MS Word для работы с большими и сложными текстами 9. Рассказываем истории: сторителлинг в книге 10. Саморедактура: работа с текстом, сокращения, фактчекинг 11. Правила сильной книги захватывающего текста 12. Авторская стилистика 13. Как превратить рукопись в сценарий 14. Рукопись готова. Что дальше? 15. Превращение рукописи в издание 16. Авторские права и договор с издательством 17. Дизайн книги. 18. Продвижение в самиздате. 19. Продвижение автора 20. Social media marketing (SMM) 21. Ведение блога и его продвижение в Телеграме 22. Взаимодействие с обозревателями, критиками и СМИ 23. Продвижение автора. Личный кейс #SelfDevelopment #PublicSpeaking #Storytelling #Writing

Introducing Domain-Oriented Microservice Architecture - Part II (Рубрика #Architecutre) Заканчивая рассказ про DOMA, начатый в первом посте, я хотел бы рассказать про оставшиеся компоненты архитектуры и получившиеся результаты. Третьим архитектурным принципом является gateway. Он достаточно стандартен с точки зрения технической реализации, но на уровне домена он позволяет обеспечить за счет четкого котракта уменьшение сложности для взаимодействующих с доменом, а также более простые миграции внутри самого домена. Четвертый элемент - это точки расширения предлагают две возможности: расширение логики и расширение модели данных. Логические расширения реализованы через возможность подключения плагинов с интерфейсами определяемыми для каждого сервиса самостоятельно (приводится пример с кейсом, когда водитель выходит на линию и дополнительными проверками, что ему можно это делать). А данные можно расширять через добавление к core-модели данных произвольных опций. Также команды внутри доментов могут придумывать и другие точки расширения. На выходе авторы получили 1) Снижение сложности: благодаря объединению 2200 микросервисов в 70 доменов DOMA упрощает управление зависимостями и обслуживание системы (за счет доменов и слоев) 2) Улучшенная масштабируемость и гибкость: архитектура позволяет осуществлять независимую разработку и развертывание доменов, сохраняя гибкость для будущих миграций (за счет gateways) 3) Улучшенный опыт разработчиков: структурированный подход снижает когнитивную нагрузку на разработчиков, позволяя быстрее разрабатывать функции и упрощать устранение неполадок (за счет понятных API и точек расширения) 4) DOMA доказала свою эффективность в управлении крупномасштабными operations в Uber Напоследок автор рекомендует использовать стартапам монолиты, средним по размеру организациям микросервисы, а большим идти в сторону дома (DOMA) Итого, это интересная статья от ребят из Uber из 2020 года. Если сейчас поискать дополнительную информацию, то кажется, что этот подход до сих пор используется Uber. Ради интереса я поискал whitepapers от Uber на тему DOMA и не нашел ни одной - Uber не Google, чтобы писать научные статьи:) #DistributedSystems #Architecture #SystemDesign #Engineering #Software

Introducing Domain-Oriented Microservice Architecture - Part I (Рубрика #Architecutre) В 2020 году Adam Gluck написал интересный пост про редизайн микросервисной архитектуры Uber и переход на DOMA. А потом Адам уволился и пошел пилить свой стартап, но к делу это не относится:) Если вернуться к статье, то Адам описал стадии эволюции архитектуры 1) Монолитная архитектура (примерно 2012-2013), где было 2 больших сервиса и набор проблем: риски доступности, опасные деплои, poor separation of concerns, плохой execution изменений в бизнес-логике. Эти проблемы возникли при росте от десятков инженеров к сотням 2) При решении этих проблем ребята пошли в микросервисную архитектуру ради: общесистемной надежности, separation of concerns, ясной ответственности и владения (ownership), скорости разработки (developer velocity). Ребята на начальных этапах получили все запланированное, но при росте команды до тысяч инженеров возник распределенный монолит 3) С 2018 года шла работа над новой концепцией под названием DOMA (Domain-oriented microservice architecture), в которой ребята решили, что микросервисы - это просто i/o-bound библиотеки, а микросервисная архитектура - это большое распределенное приложение, то для его архитектуры можно использовать стандартные подходы - Domain-driven design - про эту концепцию интереснее всего читать у Влада Хононова в книге "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh - Clean architecture - лучше всего изучить книгу Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь - Service-oriented architecture - это предтеча микросервисной архитектуры:) И на выходе получаться принципы для дизайна крупных распределенных систем в больших организациях. Основные принципы DOMA такие 1) Вместо ориентации на отдельные микросервисы надо ориентироваться на их коллекции, что организованы вокруг доменов 2) На самом деле домены тоже объединяются в коллекции, которые называются уровнями. Уровни определяют то, какие зависимости могут быть у микросервисов внутри домена. Базовое правило - это то, что микросервисы из верхних уровней могут зависеть только от микросервисы с нижних уровней. Авторы называют это слоенным дизайном. Для меня он напоминает семиуровневую модель OSI (технологии часто развиваются по кругу) 3) Домены предоставляют чистые интерфейсы (clean interfaces), которые являются единой входной точкой в коллекцию. Такие входные точки называются gateways 4) Зависимостями между доменами быть не может - ни по коду, ни по моделям данных. Для того, чтобы сделать доступным включение логики из одного домена в другой (например, для кастомной валидации или мета контекста) авторы предоставляют точки расширения внутри доменов Имплементация выглядит так, что домены позволяют подумать о логической роли коллекции микросервисов и могут быть разных размеров. Коллекции доменов в виде слоев представляют из себя способ управления специфичностью слоя и его бласт радиусом. Всего в Uber были выделены пять слоев

1) Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking. 2) Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight. 3) Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc). 4) Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web). 5) Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

Окончание обзора в следующем посте. #DistributedSystems #Architecture #SystemDesign #Engineering #Software