Leetcode - прогресс за четвертый месяц

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

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

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

Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) - Part I

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

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

#SelfDevelopment #PublicSpeaking #Software

Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) - Part II

В этом посте я продолжу рассказ о книге Рэнди Пауша Последняя лекция (The Last Lecture), о которой я говорил в прошлом посте. Здесь я расскажу про мысли Рэнди о том, как жить собственной жизнью и каким принципам следовать. Большую часть принципов я практикую сам, а оставшиеся я хотел бы практиковать, но это сложновато:)

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

#SelfDevelopment

Остановка. Мокьюментари-драма с элементами детектива @ Театр "Практика"

Вчера мы с женой ходили на эту постановку и нам понравилось. Завязка всей истории звучит так

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

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

#Theater #SelfDevelopment #Culture

Глубокое обучение и анализ данных. Практическое руководство

Прочитал эту книгу Дмитрия Малова за пару недель, что пришлись на отпуск и разъезды. Книга издана в 2023 году и сопровождается кодом и графиками, что доступны на Github. В книге 270 страниц, разделенных на 8 отдельных глав, причем автор пытается сначала изложить необходимые основы, а дальше уже переходить к практике и примерам:
1. Основы машинного обучения - здесь автор начинает с базиса, в который входит
- Линейная алгебра - скаляр, вектор, матрица, тензор, норма
- Теория информации и теорвер - случайная величина, распределение вероятности, условная вероятность, матожидание, дисперсия, ковариация, правило Байеса
- Основные понятия машинного обучения и решаемые задачи - классификация, регрессия, обнаружение аномалий, машинный перевод, структурный вывод, синтез и выбборка), а также отношение к опыту при обучении и варианты обучения с учителем, без учителя, с частичным привлечением учителя, а также обучение с подкреплением
- Основы разработки: синтаксис python, основы ооп (абстракция, инкаспусляция, полиморфизм, наследование и композиция), процессы разработки: waterfall и agile:)
2. Основные алгоритмы машинного обучения - здесь автор начинает с предобработки данных, а дальше рассматривает алгоритмы снижения их размерности: линейные и нелинейные методы, линейную и логистическую регрессию, деревья решений, метод опорных векторов, наивный байесовский классификатор, k-means, k nearest neighbors, случайный лес и алгоритм градиентного бустинга. Все это умещается в 30 страниц, поэтому если вы отдельно не изучали все эти вещи, то иногда сложно успевать за мыслью автора (я слава богу до этого это все уже ботал лет 10 назад, когда у меня был приступ самообразования и я зависал на Coursera и Edx)
3. Основы глубокого обучения - здесь автор начинает с обратного распространения ошибки (backpropagation), дальше рассказывает про персептрон, цепь Маркова, машину Больцмана, сеть Хопфилда, сверточные нейронные сети (CNN), трансформеры, рекуррентные нейронные сети (RNN), автокодировщики, генеративно состязательные сети (GAN). А в конце приводит пример системы, которую автор походу делал для whitepaper или диплома:)
4. Основы data science - интересно, что тут рассказ начинается с методологии работы с данными, а точнее с CRISP-DM (Cross-Industry Standard Process for Data Mining, дальше рассказывается про роли в команде ML-разработки, где примечательны data analyst, data engineer, data scientist. Дальше автор рассказывает про тренды: deep fakes и борьба с ними, интерес бизнеса к обучению end2end моделей, Auto ML для low-code и no-code использования, MLOps (я недавно писал про whitepaper на эту тему от Google и участвовал в подкасте на эту же тему). А заканчивает эту главу автор тем, что рассматривает популярные библиотеки для ML разработки, среди которых хотелось бы упомянуть TensorFlow, PyTorch, Keras
5. Задачи глубокого обучения - в этой главе автор приводит примеры задач и показывает как их можно решать при помощи deep learning. Тут как раз пригодится код из репозитория, чтобы поиграть с задачами самому. Тут есть примеры аугментации данных, компьютерного зрения и использования OpenCV, классическая задача на распознование символов, обработка естественного языка, обработка аудио, а также обработка видео. В общем, в этой и следующих трех главах собрана самая мякотка:)
6-8. Последние три главы посвящены знакомству с TensorFlow, Keras и PyTorch. Здесь показано как решать задачи из 5 главы с использованием конкретной библиотеки.

Если финализировать саммари по книге, то она показалась мне кратким интро в область deep learning. В ней есть вся нужная базовая инфа, но чтобы ее понять придется почитать дополнительные материалы. Здесь же есть примеры задач и код, который может стать стартовой точкой для ваших экспериментов. В общем, книга мне скорее понравилась, но надо учесть, что за исключением конкретных библиотек TensorFlow, Keras и PyTorch все остальное я уже достаточно давно и неплохо изучил:)

#AI #Math #Statistics #Software #DataScience #ML

How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023 (Рубрика #Architecture)

Интересный доклад от Adam Tornhill на тему социотехнических запахов (презентация доступна здесь). Суть в том, что наши современные системы очень сложны и они включают как software, так и людей, которые его пишут (пока не это не стали делать LLMs самостоятельно). Обеспечить баланс достаточно сложно, так как из кода напрямую не ясен социотехнический контекст - кто и зачем его написал, а также какие в нем были изменения. Adam Tornhill предлагает использовать подход behavioral code analysis, где мы сочетаем в себе анализ кода с данными о том, как команды взаимодействуют внутри кода, например, кто вносит изменения и насколько параллельно это происходит, как выглядят параметры cohesion и coupling, а также насколько сложно поддерживать код с высоким техническим долгом. Интересно, что за год до этого Adam рассказывал крутой доклад на тему приоритизации техдолга и я об этом рассказывал. Если же возвращаться к behavioral code analysis, то автоор предлагает, использую их, уменьшить организационное трение и сосредочить внимание на ряде общих задач
- Выявите узкие места архитектурной координации и поймите технические root causes
- Визуализируйте неявные зависимости между командами, а дальше действуйте так, чтобы отделить (decouple) команды
- Выявите риски знаний, измерив bus factor. Узнайте, как смягчить его
- Сообщите о рисках масштабирования, присущих закону Брукса, показав данные о том, как он влияет на вашу доставку
- Выйдите за рамки технического воздействия, зная, как плохой код приводит к низкому моральному духу и увеличению истощения

Ну и социотехнические факторы, которые называет автор звучат примерно так
1. The overcrowded system - когда слишком много людей работают над одной системой и дают слишком маленький выхлоп:)
2. Coordination bottlenecks in the code - проблема с большим количеством изменений в одних и тех же файлах вашей системы людьми из разных команд. Здесь очень велика сложность поддержания ментальной модели кода, поэтому это приводит к большему количеству багов и более сложным внесениям изменений. Кажется, что в этой части еще пригодились бы подходы из whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles", про которую я рассказывал раньше
3. A propagating cost of change - про change coupling и как изменения в одном месте тянут за собой большое количество изменений в других местах, если change coupling высокий. Как раз недавно я рассказывал про книгу Кента Бека "Чистый дизайн" ("Tidy First?"), где неплохо разбирались вопросы change couplin
4. Dependent work crossing team boundaries - здесь автор говорит примерно про обратный маневр Конвея, где нам нужно так выбрать структуру команд, чтобы она матчилась с желаемой архитектурой. Плюс нам надо так организовать архитектуру системы, чтобы она хорошо укладывалась на problem domain и позволяла организовать естественные границы для команд
5. Unhealthy code with a low Truck Factor - тут автор вспоминает про bus factor и выбывающих людей, а дальше показывает, что если это наложить на нездоровый код, то мы получаем большую проблему. Условно, если мы теряем эксперта по запутанному коду, то наши знания о деталях реализации систем сильно уменьшаются и осуществлять изменения становится дольше и дороже.

P.S.
У автора есть сайт https://codescene.com/ и книга "Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis", в которой этот подход подробно разобран. Лицензция стоит $300 в год на разработчика.

P.P.S.
Whitepapers, на которые ссылался автор
- The business impact of Code Quality
- On-boarding costs in unhealthy code
- Happiness and the Productivity of Software Engineers
- The Influence of Organizational Structure On Software Quality

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management

Людей в команде стало больше в 2 раза, а результаты в 2 раза не увеличились (Рубрика #Management)

Вчера в офисе беседовал со своим коллегой на эту тему. Он раньше руководил несколькими командами, а теперь как staff engineer работает над вопросами архитектуры и проектирования. Коллега отметил насчет одной из команд, с которыми раньше он много взаимодействовал, что она значительно увеличилась, а результат увеличился не соразмерно. И дальше мы ушли в обсуждение причин такого эффекта, которые я объясняю следующими факторами

1. Убывающая предельная полезность - по мере добавления инженеров в команду их предельная полезность уменьшается. Суть в том, что добавление первого инженера позволяет начать развивать продукт, решая самые приоритетные задачи. Добавление второго инженера позволяет уделить время важным задачам, а добавление условно седьмого инженера позволяет заняться nice to have фичами. Примерно тоже самое наблюдается и в жизни, условно, когда вы страдаете от жажды в пустыне - первый стакан воды вам просто необходим и вы готовы за него заплатить много денег, второй полезен и вы все еще готовы платить, а условно десятый стакан для вас уже не несет пользы и платить за него вы не готовы:)
2. Групповая динамика отношений и онбординг новых людей - при добавлении новых людей в команду их требуется обучить и вписать в общую динамику группы (модель Такмана). На онбординге мы тратим время самих онбордящихся, а также сильных людей из команд. Кроме того, перформящая по Такману команда может проваливаться в стадию storming, где бурлят обсуждения и команда работает менее эффективно, чем до этого
3. Стоимость коммуникаций - даже если человек уже заонбордился, а динамика команды вернулась в норму, то у нас все равно остаются затраты на коммуникации. Если у нас в команде все общаются со всеми, то у нас получается полный граф, где количество связей равно n*(n-1)/2. Каждую связь требуется поддерживать, поэтому накладные расходы на коммуникации растут квадратично с ростом команды. Отсюда у нас получаются ограничения вида two-pizza team
4. Проблемы с параллелизацией работы - тут нам нужно вспомнить закон Амдала

В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного фрагмента.

А значит что парараллелизация работы внутри команды не позволяет линейно масштабироваться с увеличением количества человек, так как у нас есть часть работы, которую мы должны делать последовательно (планнинг, ретро, часть архитектурной работы, работа над местами с bottleneck в коде, про что рассказывалось в докладе "How Technical Problems Cause Organizational Friction", о котором я упоминал вчера). Кстати, именно поэтому все стремятся сделать автономные команды и топологию команд (можно почитать про team topologies или послушать первую серию подкаста Code of Leadership).

Если подводить итоги, то эти факторы приводят к тому, что масштабируя команды мы получаем сублинейное масштабирование эффекта. Причем если процессы на уровне компании выстроены совсем печально, то сублинейное время скорее похоже на ассимптотику log(N), где N - это количество людей🙂 В общем, в лоб решить задачу, закидав ее людьми не получится.

P.S.
Отдельным постом потом напишу про решение действительно сложных задач и почему там требуется не просто наращивать команду, а скорее искать центр кристализации (супер-крутого эксперта) и дальше вокруг него выстраивать команду из инженеров с высоким потенциалом.

#Management #Leadership #Processes #Team #Software #SoftwareArchitecture

Adaptive Architectures • Marty Pitt • GOTO 2023 (Рубрика #Architecture)

Интересный доклад от Marty Pitt на ту же самую тему, которую он поднимал за год до этого в докладе "Using Semantic Metadata to Create an Automated Microservice Data Mesh", про который я рассказывал раньше. Правда, теперь эта идея подается через адаптивную архитектуру, которая достигается за счет того, что мы не пишем связующий код (glue code), который нам требуется для интеграции наших отдельных API для выполнения полезной работы. Как и в прошлый раз это достигается за счет:
- Языка Taxi для семантической разметки наших существующих API, когда мы поверх ним добавляем этим языком метаданные для описания семантики
- Декларативного языка запросов TaxiQL для описания того, что мы хотим выбрать с точки зрения семантики
- Платформы Orbital для хостинга этих метаописаний и исполнения этих декларативных запросов, когда под капотом платформа выполняет все запросы и выплевывает готовую информацию

В итогe, Taxi похоже на GraphQL в плане целей предоставления единой точки входа для объединения нескольких API. Но в Taxi не требуются resolvers, Taxi независима от протокола и может объединять разные API (OpenAPI, RAML, JsonSchema и Protobuf, ...), TaxiQL позволяет потребителям определять свои контракты данных. Но и проблемы похожи на те, что есть у GraphQL.

В итоге, адаптивную архитектуру по мнению автора можно построить на базе

- Taxi - semantic metadata for APIs
- TaxiQL - declarative query language
- Orbital - TaxiQL engine + observability

#Data #Software #SoftwareArchitecture #Architecture #Engineering

Дизайн всего (How Design Makes the World) (Рубрика #Design)

Очень простая и короткая книга на тему дизайна от Скотта Беркуна, который написал много книг, включая "Откровение оратора" (подробнее в посте) и "Искусство управления IT-проектами" которые я читал до этого. Как обычно Скотт пишет очень просто и легко, приводит кучу примеров и много шутит, но глубина проработки тем такова, что читать ее интересно начинающим. Но вы не узнаете много нового, если вы уже в теме и читали упоминаемые Скоттом книги типа
- “Дизайн привычных вещей” ("The Design of Everyday Things") Дона Нормана (подробнее в моем посте) или
- "Предсказуемая иррациональность" ("Predictably Irrational") Дэна Ариели
На протяжении книги автор подводит к тому, что дизайн - это не просто про интерфейсы или визуал, а это про осмысленное создание предметов, которые служат определенным целям определенной аудитории. В итоге, у него получаются 4 главных вопроса, которые задают хорошие дизайнеры

1. Что вы хотите улучшить?
2. Для кого вы хотите это улучшить?
3. Как вы добьетесь того, чтобы дизайн оказался успешным?
4. Кому может навредить ваша работа - сейчас или в будущем?

Для того, чтобы оценить повестование можно взглянуть на главы, которые входят в книгу
1. У всего есть дизайн - даже если о дизайне не думали, то он какой-то получился, но чаще всего он получился не очень
2. Производить или проектировать - что сложнее? - Ответ автора в том, что чаще проще сделать вещь, чем ее спроектировать
3. Что такое хорошо? - зависит от цели
4. Люди прежде всего - рассказ про сигвеи и что бывает, если идти от технологии
5. Дизайном занимается каждый - и инженеры при проектировании софта тоже:)
6. Улица за окном - про проектирование городов и районов, а также про прямоугольную сетку улиц (что использовалась с древних времен)
7. Стиль - это послание - про бренд и особенности стиля, которые передают мысль окружающим
8. Дизайн - это функциональность - про ментальные модели, которые дизайнеры используют для облегчения использования предметов, например, про кнопки-плацебо, багажную ленту в аэропорту и так далее
9. За чей счет? - кому-то придется заплатить за улучшенный дизайн: покупателю, продавцу или государству. Тут приводится интересный пример с ремнями безопасности в машинах
10. Как скажут сверху - политики и руководители компаний тоже являются дизайнерами, так как обычно они принимают финальное решение:)
11. Дизайн - это действие - про итеративную работу дизайнеров и дизайн-мышление (design thinking)
12. Билет в кармане - разбор посадочного билета на самолет и почему он такой (спойлер: это обусловлено работой с ограничениями реального мира и наличии legacy систем)
13. Идеи и системы - если системам такова, что там принимаются неудачные решения, то и дизайн там получится неудачный (пример с госучереждениями)
14. Как для себя? - суть главы в том, что вы - нерепрезентативны. А для того, чтобы принимать удачные решения надо иметь разношерстную команду и думать о разных потребителях
15. Образ мышления: это важно! - важно не заставлять клиентов думать о том, как пользоваться вашими спроектированными решениями + если они все-таки ошибаются при использовании, то это не должно приводить к серьезным проблемам
16. Ценности и компромиссы - компромиссы - это то, к чему мы приходим в реальной жизни. Важно понимать к чему мы стремимся и как оценивать альтернативы (и больше не значит лучше)
17. Хороший дизайн незаметен - все должно быть ясно без объяснений и инструкций
18. Дизайн раздора - про темные паттерны дизайна и противоречие между людьми, которое возникает из-за спроектированных решений
19. Новые решения - новые проблемы - примерно про day-2 проблемы (что будет после того, как спроектированное решение будет внедрено)
20. Куда смотреть - чеклист для понимания дизайна от автора
21. Рекомендации - куча отсылок к источникам

В общем, читать интересно и полезно. Но если вы гуру дизайна, то вам будет скучно:)

#Architecture #Management #Thinking #Leadership #SystemDesign #SystemThinking

Краткая история Китая (The Shortest History Of China) (Рубрикак #History)

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

1. Истоки - Яйцо проклевывается, и рождается цивилизация
2. Чжоу - От идеального правления к периоду Сражающихся царств
3. Цинь - Объединение, тирания и Поднебесная
4. Хань - Интриги, инновации и короткое междуцарствие
5. Великий разлад - Три царства, две женщины-воительницы, семь мудрецов и порошок из пяти минералов
6. Тан - От золотого века до вечной печали
7. Сун - Протосоциалисты, неоконфуцианы и городское житье
8. Монгольская Юань - От "славной резни" к великолепному городу
9. Мин - Великолепие и упадок
10. Великая Цин - Трудный путь к современности
11. Республика - Большие надежды и жестокие предательства
12. Японское вторжение и гражданская война - Республика распадается
13. Годы Мао - Непрерывная революция
14. Эпоха реформ - Процветание и недовольные
15. Новая эра Си Цзиньпина - Появление воинов-волков

P.S.
По мере прочтения этой книги до меня доходили истинные масштабы Китая: количество разных национальностей, людей, городов, героев и злодеев, а также династистий, что сменяли друг друга. И мне вспомнилась фраза из 1984, которой пользовались часть из правителей для того, чтобы управлять будущим

Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым

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

#History #Economics