Книжный куб

Наука под покрывалом (Hot. La scienza sotto le lenzuola) Я люблю читать научно-популярные книги на разные темы и вот на днях я дочитал Аличе Паче, которая весело и задорно говорит о том, как романтика переходит в близость. Автор рассказывает про то, как работают наши органы чувств, оценивая потенциальных кандидатов; как мозг расчитывает вероятности с учетом данных с этих сенсоров, а также как на эти расчеты реагируют наше тело:) В книге автор рассматривает все вопросы с точки зрения науки, поэтому легко опровергает устоявшиеся мифы, связанные с сексуальностью. Автор уместила все свои тезисы примерно в 200 страниц, которые разделены на 14 глав с говорящими названиями:) 1. Почему мы это делаем - Этого хотят гены и нужно для выживания? Или мы делаем это ради удовольствия? Или и то и другое? 2. Сексуальность повсюду - Глава про развитие сексуальности у людей, а также как появилась отдельная наука, что исследует этот вопрос 3. Пять органов чувств: режим "Включено" - Как наши пять органов чувств работют в команде, чтобы оценить кандидатов 4. Рот в рот - Глава про поцелуи, динамику французского поцелуя, а также почему они нравятся людям:) 5. В голове - Как наш мозг работает при влечении, а также какие зоны мозга вовлекаются в этот процесс и причем здесь нейромидиаторы и какие именно (и да здесь есть рассказ про дофамин) 6. Гидравлика пениса - Как работает эрекция, как это устроено с точки зрения гидродинамики и имеет ли размер значение 7. География женского возбуждения - Глава про аналог топографической карты для желающих узнать больше про женское возбуждение 8. Половой акт, исследуемый вблизи - Про фазы сексуальной релаксации, их длительность и частоту:) 9. Мастурбации - да, мастурбации нет - В этой главе разбирается техника и развенчиваются популярные мифы 10. На уровне оргазма - Что такое оргазм и как он влияет на мозг, а также можно ли заметить симуляцию оргазма 11. Семяизвержение и все, что с ним связано - Как это работает у мужчин и женщин 12. SOS! Химия спешит на помощь - Немного про фармацевтику 13. Высокотехнологичные барьеры - Про то как предохраняться 14. Экстремальный секс - Мифы и реальность В общем, это интересная книга про интересную тему, которая написана забавным языком и совсем не пошло:) P.S. Я раньше уже публиковал посты о научно-популярных книгах по биологии - От оргазма до бессмертия. Записки драг-дизайнера - Самая главная молекула. От структуры ДНК к биомедицине XXI века (Unraveling Dna: The Most Important Molecule Of Life) - Биология желания. Зависимость - не болезнь (The Biology of Desire. Why Addiction Is Not a Disease) - Жизнь на грани (Life on the Edge: The Coming of Age of Quantum Biology) - Закон Джунглей (The Serengeti Rules. The Quest To Discover How Life Works And Why It Matters - Рождение сложности. Эволюционная биология сегодня - В моей голове (In mijn hoofd) P.P.S. В Лабиринте сейчас хорошая скидка на эту книгу Аличе Паче #Biology #PopularScience #Brain

Библиотека В этом году я переехал с семьей в новую квартиру. При проектировании этой квартиры мы с женой решили половину гостинной выделить мне под библиотеку под самый потолок. Для такой библиотеки нам пришлось заказывать кастомные шкафы и лестницу, которая позволила бы забираться на самый верх. Нам изготовили и установили шкафы, а потом довезли лестницу. А дальше я несколько месяцев потихоньку перевозил книги из прошлой квартиры и с дачи. И в процессе перевоза книг я четко ощутил всю тяжесть знаний и необходимость быть сильным специалистом для того, чтобы ворочать чемоданами книг. Только сегодня я закончил и все книги оказались на законных местах. И в этом момент кроха-сын решил занять место папы и показать, что он тоже готов читать книги - ведь тут есть и его полки с книгами, которые расположены пониже, чтобы он мог дотянуться. P.S. В общем, перед новым годом я успел оборудовать себе место для чтения и в новом году буду вас радовать еще большим количеством обзоров книг:) #Book #ForParents

The Making of Prince of Persia Рабочий год закончен и можно немного отдохнуть и многие для этого используют игры. Но я не играю в игры почти 20 лет, поэтому я снял с полки книгу про создание игры "Prince of Persia". Это игра из моего детства, которую создали еще до моего рождения. Эта книга выпущена издательством Stripe Press, которое издает очень мало книг, но каждая из них сделана очень качественно и с душой:) Как-то я заказал с Amazon почти все вышедшие книги и теперь дождался каникул, чтобы их почитать:) P.S. На тему игр и геймдизайна у меня уже были раньше посты - Геймдзайн (Designing games. A guide to engineering experiences) - Minecraft: Мобиология (Minecraft: Mobestiary) - Кровь, пот и пиксели (Blood, sweat and pixels) - Настольная игра "Нефариус" - Настольная игра "Корпорация Гоблинов" (Goblins Inc) - Прогейминг, Overwatch, киберспорт (Young guns: obsession, owerwatch, and the future of gaming) - Мастера Геймдизайна (Game Designer Confessions: Insights from Finland's Top Game Designers) - Мальчик, сделанный из кубиков (A Boy Made of Blocks) - Настольня игра "Бумунту" - Документальный фильм про AlphaGo - Настольная игра "Ужасы Аркхэма" #GameDesign

Ты во сколько будешь?

Интервью с YaTalks На конференции YaTalks я не только выступил с докладом "Как формировать структуру команд под запросы бизнеса", но и успел дать интервью Владимиру, что ведет канал "Владимир в IT". В этом интервью помимо меня есть еще Леша Пименов из Neogenda и Александр Королев из Home банка. Основные вопросы в интервью затрагивали следующие темы - Какой язык является лучшим - это вопрос для разминки - В чем секрет успеха IT в Тинькофф - Зачем я рассказываю про system design interview - про мое хобби в виде проектирования и архитектуры - Как Тинькофф заботится о сотрудниках - про соцпакет и возможность работы над интересными проектами - Как растут сотрудники в Тинькофф - про Т-Рост - Как расти внутри компании - Что я думаю про IT курсы и вход в IT - Что я ценю в сотрудниках:) #Management #Conference #Interview #Software #Leadership #Engineering #SelfDevelopment

Code of Architecture - Поздравление с новым годом В этом году мы в рамках книжного клуба Code of Architecture продолжили двигаться в сторону своей миссии, которая состоит в распространении знаний о проектировании и архитектуре. Мы успели обсудить за год пять книг, каждая из которых дала что-то свое зрителям: - Distributed systems — фундаментальная книга по распределенным системам от Таненбаума и ван Стина. Книга очень хороша для структуризации своих знаний и глубокого погружения в мир распределенных систем. Если бы в книге были актуальные примеры, то она была бы вообще вне конкуренции. Общий обзор книги доступен в моей статье; - A Philosophy of software design — одна из редких книг, что написаны понятно, но при этом содержат в названии слово философия. Джон Остерхут делится своими мыслями о разработке софта и его хочется слушать, так как видна глубина проработки и опыт автора, что много лет преподавал в Стэнфорде и является соавтором алгоритма консенсуса Raft. Общий обзор книги доступен в моей статье; - Building evolutionary architecture — книга с интересной концепцией применения эволюционного подхода к архитектуре. К сожалению дальше концепции авторы продвинулись не сильно. Общий обзор доступен в моей статье; - Kubernetes patterns — хорошая книга для разработчиков про примитивы Kubernetes. Но тут отличие в том, что подача идет от сценариев применения, которые интересуют людей проектирующих приложения, а не тех, кто поддерживает сам K8s. И эта точка зрения делает книгу очень полезной. Общий обзор доступен в моей статье; - Continuous architecture in practice — хорошая обзорная книга с прикольным набором принципов, которая при глубоком погружении оказывается пустоватой, но содержит кучу референсов на другие материалы. И вот пожелания для вас на следующий год, которые мы вывели из этих книг: — Сделать свою распределенную систему так, чтобы было не стыдно показать ее Эндрю Таненбауму; — Использовать стратегическое программирование как учил Джон Остерхут; — Помнить про эволюцию систем и ее архитектуру, а также не оказаться со своей системой на обочине эволюции Чарльза Дарвина; — Использовать K8s не потому что вас заставили, а потому что это помогает вашей системе проще решать стандартные проблемы, про которые написали Bilgin Ibryam, Roland Huss; — Использовать не только CI/CD (continuous integration/delivery), но и следовать принципам CA (Continuous architecture), которые на бумаге звучат хорошо. Не теряйте интерес к саморазвитию, читайте хорошие книги и применяйте прочитанное на практике для закрепления знаний. Все это позволит стать лучше как инженер и эффективнее исполнять роль архитектора, если это придется делать 😎 P.S. А еще в этом году мы провели несколько спецвыпусков по мотивам whitepapers - Zanzibar: Google’s Consistent, Global Authorization System - Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases - Large-scale cluster management at Google with Borg - Google's Hybrid Approach to Research И в новом году я персонально рекомендую вам начать читать больше whitepapers - в них контента больше и он гораздо плотнее, чем обычные книги:) С наступающим Новым годом!

Елка телеканала Карусель в Крокусе Нам на работе подарили билеты на детскую елку телеканала Карусель и я сегодня водил на нее своих детишек трех и восьми лет. Малышам все понравилось: - Масштаб представления и интересный сюжет - Знакомые герои из мультиков, которыые они видели - Интерактивные вставки, когда актеры ходят по залу и дают пять детишкам - Игры в виде летающих по залу шаров, которые дети бросают в разные стороны - Победа Деда Мороза над Бабой Ягой с помощью целой банды мультяшных персонажей Я тоже не скучал, а смотрел представление с детишками и могу сказать, что оно прикольное:) P.S. На обратном пути маленький заснул, а восмилетний ныл насчет того, что мы долго едем. Но вот на само представление мы ехали с приподнятным настроением, что видно по фотке из машины:) #ForKids #ForParents

Tinkoff on Ice 22 января в Парке Горького будет наш уже традиционный IT каток от Тинькофф. Мероприятие будет очень насыщенным, поэтому есть смысл зарегестрироваться и - покататься на коньках - пройти квест на льду - пообщаться в рамках IT.Date - поучаствовать в хоккейном фристайле с ребятами из КХЛ - попробовать поскрести лед поиграть в керлинг - послушать доклады и дискуссии про разработку:) - отдать детей на каток с аниматорами и инструкторами - перекусить на фудкорте Организаторы отдельно отмечают, что они

учли опыт прошлогоднего катка. Поэтому, уверены, что этот будет максимально комфортным, удобным, и свободным от очередей — мы сделали всё для этого!

В общем, я думаю, что - я как и в прошлый раз зарегестрируюсь на каток - но в этот раз все-таки смогу на него попасть:) #ForParents #ForKids #Conference

Профессия SDE (software development engineer) Вчера я говорил про профсообщества и профессии, поэтому сегодня решил продолжить эту тему и поговорить про SDE. Эта тема интересна, так как основной состав tech компаний составляют именно инженеры разработчики, но часто в больших компаниях у них особо не единства: - Они делятся по условным направлениям бекенд, фронтенд, мобайл, ... - Внутри этих направлений есть свои деления по языкам (c++, go, java, .net, ...), платформам (iOS, Android, кросс-платформа), фреймворкам (Angular, React, Vue) и так далее Понятно почему так происходит: - Это завязано на найм - и нанимающему менеджеру проще сказать ищи джависта и рекрутингу проще их искать - Это завязано на собеседования - что мы спрашиваем у условного джависта по его языку - Это бывает завязано на матрицы компетенций - что мы ожидаем от джависта в рамках его инструментария - Это бывает завязано на стандарты профессии, общий тулинг и так далее - удобно когда все джависты в компании на одной волне (например, у нас есть фреймворк kora для джава приложений в Tinkoff) Но иногда такое дробление мешает и требуется наоборот большая унификация - В случае общего видения матрицы для SDE, где нет специфики стека, но есть общие моменты вида -- Scope - какая область влияния у инженера -- Impact (Delivery) - какой вклад у инженера в продукт/проект -- Complexity - какой технической сложности задачи решил инженер -- Leadership - какие лидерские свойства демонстрировал инженер и насколько успешно коммуницировал с другими сотрудниками -- Improvement - какие улучшения инженер внедрил в процессы или как помог вырасти своим коллегам и себе Как видно, в такой матрице многое сфокусировано на значимых достижениях инженера, который их систематически демонстрирует. И если он движется по грейдам, то у него все меньше привязки к стеку, а все больше отсылок к хорошим инженерным процессам и демонстрации technical leadership. И если рассматривать условную классификацию, то - Middle разработчик может быть описан как SDE -> backend -> java (уровень Middle) - А вот Staff инженер уже должен описываться скорее как SDE (уровень Staff). Интересно, что у тех же Staff инженеров есть свои архетипы, но они прибиты не к стеку, а скорее к исполняемой им роли (подробнее можно прочитать в статье) #Management #Leadership #Staff #Engineering #Software #SoftwareDevelopment

Профсообщества в корпорациях: как, зачем и почему? Через месяц я буду на оффлайн встрече безвотэтоговотвсего общаться насчет внутренних сообществ в больших компаниях. В Тинькофф это называется профессиями - У профессий есть свои лидеры, что исполняют эту роль, совмещая с участием в продуктах/проектах - Професии являются точкой синхронизации людей, объединенных вокруг чего-то общего: профессии (продакт менеджер, системный аналитик, qa-инженер, разработчик), языка разработки в случае разработчиков(golang, kotlin/java/.net, etc), функции (архитектура, процессы разработки) и так далее - У каждой профессии есть ее лидеры, которые ее развивают как во всей организации, так и внутри крупных подразделений - Лидеры профессий помогают определять ожидания от специалистов, которые входят в определенную профессию - это так называемые матрицы компетенций - Лидеры профессий участвуют в рассмотрении заявок на повышение, что идут через наш процесс Т-Рост, про который я рассказывал в своей статье - Лидеры профессий помогают улучшать найм сотрудников в рамках своей профессии (это наши стримы найма, например я когда-то курировал и рассказывал про system design и troubleshooting) - В рамках профессии вырабатываются стандарты и часто реализовывается общий инструментарий, который помогает всем в рамках профессии быть эффективным - Также лидеры профессий часто ведут публичную деятельность по освещению своей профессии как внутри, так и снаружи компании (aka devrel) Для меня концепция профессии звучит классно и позитивно, но возникает вопрос а почему не выделить это в отдельную должность? Ответ в том, что при выделении сотрудников на fulltime мы получаем сломанную ситуацию, когда крутой представитель профессии постепенно теряет - Экспертизу в ней, так как перестает работать руками - Связь с землей и уходит в абстракции, так как перестает работать руками В итоге, лидер профессии вынужден сидеть на двух стульях. Но тогда возникает вопрос, а зачем ему это делать? Ответ в том, что это улучшает карму сотрудника и повышает вероятность успешного повышения в рамках процесса Т-Рост, причем для высоких грейдов это становится необходимым, но недостаточным критерием:) В общем, регистрируйтесь и приходите на оффлайн встречу и задавайте вопросы там, я с удовольствием отвечу на них вживую. Встречу организует Сергей Щербинин, автор канала безвотэтоговотвсего, кроме того там будут еще гости кроме меня: ⁃ Паша Соломин, руководитель разработки и сопровождения Сбербанк онлайн/ лидер профсообществ Сбера ⁃ Саша Денисов, Директор департамента ит поддержки пользователей и клиентов цифровых сервисов Росбанка ⁃ Макс Морозов, СЕО Астон #Management #Leadership #Engineering #Staff #Software

Разработка Web-приложений с использованием UML (Building Web Applications with UML) Достал с полки эту раритетную книгу, которой уже больше 20 лет:) В ней автор в начале 2000х рассказывал про web разработку и как там применять UML. Я решил понастальгировать и вспомнить как выглядели книги по проектированию и разработке во времена начала моей карьеры:) Эта книга была написана в 2000 году - Сразу после появления Ajax (Asynchronous JavaScript and XML) в 1999, но в книге в основном рассказывалось про апплеты Java, элементы ActiveX - Еще до появления Agile Manifesto в 2001 и поэтому упор был на RUP (Rational Unified Process) как итеративный процесс разработки - Еще до заката UML (сложно определить конкретную дату), поэтому в книге UML прикручивается ко всему, даже DOM-страничке:) - Еще до рассвета Agile, поэтому есть глава про определение архитектуры, в которой говорится про use cases и три паттерна: тонкий клиент, толстый клиент и распределенный вариант с блекджеком и шлюхами CORBA (Common Object Request Broker Architecture) и RMI (Remote method invocation) - Еще до повального увлечения user stories, поэтому есть целая глава про требования, функциональные и нефункциональные и их ранжирование В главе про реализацию забавно смотреть на sequence и activity диаграммы web-системы, которая совсем не выглядит интерактивной:) А в главе про реализацию по старой традиции приведены простыни html кода (десятки страниц), который, видимо, надо было перепечатывать для воспроизведения примеров у себя:) В общем, сейчас эта книга скорее является букинистической диковинкой и окном в прошлое веб-разработки, чем полезным источником знаний:) #Software #SoftwareDevelopment #UML #Engineering

Hello Deep Learning • Bert Hubert • GOTO 2023 Интересное выступление Bert Hubert с рассказом про Deep Learning на пальцах. Сам Bert достаточно известный товарищ, который является немного ученым, разработчиком и предпринимателем. Забавно, как вначале он говорит, что много лет игнорировал хайп вокруг deep learning, отчасти потому что также яро проповедовали и blockchain, который оказался пшиком. Но после появления chatGPT игнорировать глубокое обучение уже было нельзя и он решил погрузиться в этот домен. Для этого он выбрал подход, что похож на "Kubernetes the hard way" от Kelsey Hightower. Для этого Берт взял стандартную задачу по распознаванию цифр и решил ее решить с нуля:) А дальше он кратко рассказал про - Статью Attention is all you need - NIST и его подборку рукописных цифр как базу для обучения - Подход втупую через вычитание значений пикселей для 3 и 7 между собой и ручное разделение множеств - Дальше усложняем с перемножением на рандомную матрицу - Дальше добавляем функцию потерь (loss function) - Переход к трем слоям для классификации цифр по десяти категориям - Добавление нелинейности при перемножениях (ReLU и GELU) - Добавление градиентов для обучения коэффициентов модели и получение хороших результатов - Добавление шума в исходные данные и получение полного треша в качестве результатов от обученной модели и дальше автор говорит следующее

Production use of a neural network tends to go through these four phases (if you are lucky): 1. It works on the training data 2. It also works on the validation data 3. After a lot of disappointment, we get it to work on other people’s real life data too 4. Other people can get it to work on their own data as well

Almost all demos declare victory after phase 2.

И дальше автор делает финальные выводы по выступлению - Deep learning реально - Deep learning позволяет получать магические результаты - Deep learning не является волшебным и обманчиво простым - Все еще можно попасть на борт этого корабля:) В итоге, автор предлагает не опираться на внешние API облачных сервисов, а делать свои продукты поверх решений, доступных on-premise. Автор предлагает посмотреть на следующие материалы - Whisper.cpp: state of the art voice transcription in dozens of languages, entirely self-contained on your own computer/phone: https://github.com/ggerganov/whisper.cpp - LlaMA “GPT-like”, self-contained, own computer etc: https://github.com/ggerganov/llama.cpp - https://berthub.eu/articles/posts/hello-deep-learning/ - the series behind this presentation, https://github.com/berthubert/hello-dl - https://berthub.eu/articles/posts/ai-is-guaranteed-to-disrupt-us/ #ML #DataScience #Data #Math #Software #SoftwareDevelopment #Engineering

Занимательная математика Эта книга Якова Перельмана как-то обошла меня в детстве стороной, хотя я до дыр зачитывал его "Занимательную физику". В этой книге про математику Яков Перельман собрал большое количество приключенческих и фантастических рассказов, в которых скрыты математические загадки. А дальше в примечаниях после каждого произведения Яков расшифровывает математическую суть этой истории. Если вы читали Герберта Уэллса, Жюля Верна, Владимира Бенедиктова, то возможно уже сталкивались с этими произведениями, но скорее всего не могли оценить правдоподобность идей авторов. Ниже представлены все части этого сборника в формате "Название оригинального произведения. Название комментариев от Перельмана. Мои комментарии о чем все это" 1. На мыльном пузыре - рассказ Курда Лассвица. Относительность пространства и времени. Напоминает фильм "Дорогая, я уменьшил детей" 2. Машина времени - извлечение из повести Герберта Уэллса. Время как четвертое измерение. Просто про пространство и время. 3. На комете - из романа Жюля Верна. Примечания. Про силу притяжения и как подручными средствами определить вес и плотность кометы. 4. Предшественник Нансена - рассказ В. Ольдена. Живой планетарий. Про движение планет и как это можно моделировать:) 5. Универсальная библиотека - рассказ К. Лассвица. Литературная машина. Про комбинаторику и вероятности. Примерно то же самое, что толпа обезьян, которая стуча по клавиатуре случайно напишет "Войну и мир". Интересно смотреть сейчас на успехи LLMs, которые успешно генерируют связный текст:) 6. Пирамида Хеопса и ее тайны - рассказ Я. Перельман. Действия над приближенными числами. Развенчивание подходов желтой прессы на примере желтых заголовков о Пирамиде Хеопса:) 7. История одной игры - Вильг и Аренса. Примечания. Про игру "пятнашки" и как она появилась и почему привела изначально к буму 8. Странная задача на премию -Проф. Г. Симона. Диофант Александрийский. Про решение целочисленных уравнений 9. Числовые анекдоты - Барри Пен. Просто забавный набор задач, что можно порешать и проверить себя 10. Хитрое разрешение мудреной задачи - В.Г. Бенедиктов. Увеселительная арифметика Бенедиктова. Интересный сборник Бенедиктова и как пример задачка про продажу куриных яиц 11. Вверх дном - из романа Жюля Верна. Возможно ли переместить полюса Земли. Про вращение Земли вокруг своей оси и ее полюса 12. Самокатная подземная железная дорога - А. Родных. Сказочная дорога. Аля прообраз Hyperloop, что недавно закрылся, только еще более феерический:) Напоследок приведу цитату самого Якова Перельмана насчет этого сборника

В поисках средств для оживления в широких кругах интереса к математике, мне пришла мысль собрать ряд произведений, трактующих математические темы в беллетрической или полубеллетрической форме, и предложить их читателю с соответствующими комментариями. Число таких произведений, конечно, весьма ограничено. Этим объясняются скромные размеры настоящего сборника. Однако, затрагиваемые в нем математические темы все же довольно разнообразны: относительность пространства и времени, четырехмерный мир, расчеты из области небесной механики, вопросы математической географии, комбинаторика и исполинские числа, приложение математического анализа к играм, неопределенный анализ, уравнения. Можно надеяться, что этот небольшой сборник натолкнет иных читателей на более серьезные размышления и побудит к систематическому ознакомлению с тем или иным отделом математики. Настоящий сборник является первым известным мне опытом подобного рода.

#Math #PopularScience #Physics

How Data & Software Eng. Teams Collaborate to Ensure Smooth Data Integrations • Sam Bail • GOTO 2023 Интересное выступление Sam Bail про коллаборацию команд, что отвечают за разработку софта и за аналитические данные:) Слайды этого выступления доступны здесь. Сетап проблемы выглядит так

Product manager: We’re launching this awesome new feature next month! And we need analytics from day 1! Let’s GOOO! Data team: HOLD ON! Lemme talk to the software engineering team first and see what their data architecture looks like…

А дальше доклад посвящен следующим темам и выстроен в виде важных вопросов, которые обычно задает Sam в очередном проекте 1. Logistics - нужны доки, нужны встречи и понятная зона ответственности, понятные коммуникации, ответы на вопросы: что мы планируем измерять и когда (уже в первый день, неделю, месяц, ...). Как сделать так, что команда разработки была в синке с аналитикой. 2. Infrastructure - где хостятся данные, какой там тип хранилища, могут наши ETL инструменты с этим справиться, нужен ли SSH туннель. Есть ли prod и dev инстансы, мы используем реплики для получения данных? Нужен ли нам доступ на запись? Что мы делаем с credentials (личные они или общие, как мы их шарим). Когда удастся получить доступ к данным? На dev или prod? 3. Data model - как выглядит схема данных, есть ли документация, кто поддерживает изменения в схеме и кто и как их коммуницирует? Как будет выглядеть data constraints enforcing (foreign key relationship, NULL values, default values, JSON schemas)? Как обрабатываются таймзоны в датах, валюты? Действительно ли мы сохраняем все, что хотим измерять? 4. Application and data flow - как и когда записи создаются и поля заполняются значениями? Какие действия вызывают модификации значений? Как события модификаций данных логируются (поле updated_at или отдельная таблица с событиями логирования)? Как будут обработаны удаления (hard или soft удаления)? Архивируются ли "старые" данные? Нужна ли миграция данных из старого приложения? Будут ли реалистичные тестовые данные, на которых можно будет разрабатывать? Будут ли тестовые данные в production среде? 5. Data contracts - как будут документированы договоренности из пунктов 1-4? И как мы будем обеспечивать их соблюдение в будущем не требуя слишком большого человеческого участия? Что из этого можно вынести в CI/CD и проверять на стороне производителе данных (а не как обычно на стороне потребителя)? Как нужно будет коммуницировать об изменениях и кого надо будет информировать об этом? Что делать, если что-то сломается? Как надо будет репортить о проблемах, а также какое SLA будет на фиксы? Автор обобщает весь доклад тремя пунктами

- Integrating data from a new source into your data warehouse isn’t just “plug n play” - There are an infinite number of questions to consider. You will probably miss something. - The key is connection and context between teams.

А дальше, если все сделать правильно, то проблема из самого начала превращается в

Product manager: Look at this awesome new feature! And the dashboard to track all these cool metrics! Data team: Well it’s not everything you asked and it was a bit bumpy getting there, but it works! Go team!

#Data #Software #SoftwareDevelopment #Engineering #Management #Leadership #Databases

Геймдзайн (Designing games. A guide to engineering experiences) - Part IV Этот пост продолжает обзор книги, по которой уже было два поста: 1, 2 и 3. И тут мы продолжим говорить про вторую часть книги "Искусство создания игры" Глава 6. Баланс Автор начинает с определения

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

Баланс является инструментом, который используют для разных целей, где выделяются две: честность и глубина - игра считается честно, если вначале ни у одного из игроков нет преимущества - для того, чтобы игра была глубокой, она должна генерировать решения, которые были бы настолько сбалансированы, что даже эксперту сложно было бы принять решения Обычно игроки используют определенные стратегии - конкретные наборы действий для достижения целей. И если нет вырожденной стратегии (очевидно лучшей для данной ситуации), то игра является глубокой. Интересно, что баланс зависит от навыка игрока, так как разный уровень навыков дает доступ к разным стратегиям. Иногда ради баланса геймдизайнер решает поменять одну из механик, из которых состоит игра. Но изменения в механиках меняют все стратегии, в которые она встроена, а не только те, что мы планировали изменить. Поэтому поиск баланса достаточно сложен. Прямо как при принятии архитектурных решений:) Глава 7. Многопользовательская игра Эту главу автор начинает с рассмотрения теории игр, которой посвящены отдельные книги "Теория игр", "Теория игр в комиксах". Тут идет речь про равновесие Нэша, смешанные стратегии, yomi (чтение мыслей противника и попытка его убедить, что вы сделаете что-то одно, а вы на самом деле сделаете что-то другое). Дальше идет речь про то, что в многопользовательских играх часто у игроков могут быть разные цели, что приводит к тому, что одни игроки нарушают опыт других игроков. Глава 8. Мотивация и удовлетворение Эта глава начинается к отсылке к дофаминовому удовольствию и предвкушению награды, которое работает лучше, чем собственно получение награды. Дальше автор рассказывает про режим подкрепления

Режим подкрепления - это система правил, которая определяет, когда выдается награда

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

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

Глава 9. Интерфейс Автор начинает с того, что у нас 2 цели - донести информацию о том, что проихсодит в игре - здесь мы должны разработать системы, которые структурируют и упорядочивают информацию - обеспечить возможность управления - здесь мы должны разработать сложную комбинацию ограничений, соглашений и вспомогательных систем Для этого часто используются метафоры, которые придают новой информации знакомые черты, чтобы ее можно было легче понять. Больше того, игра должна задать словарь метафор, который указывает какие элменты моделируют механику, и соответствовать этому словарю. Для того, чтобы информация воспринималась лучше используется визуальная иерархия, в которой важные элементы становятся более заметными, чем неважные. Глава 10. Рынок Эта глава посвящена тому, как игры чувствуют себя на рынке. Про эффект Матфея, дилемму новатора, сегментацию рынка, кривую ценности. В общем, здесь мы заходим на территорию маркетинга и планирования продаж:) P.S. На этом обзор это книги заканчивается, так часть книги про "Процессы" очень хорошо пересекается с обычными процессами разработки, о которых я и так часто рассказываю. #Design #GameDesign #SystemDesign #SystemThinking #Management #SelfDevelopment

Practical (a.k.a. Actually Useful) Architecture • Stefan Tilkov • GOTO 2023 Это выступление является последним для Стефана Тилькова на goto конференциях, где он начал выступать еще в 2012 году. Я помню как в 2019 году лично посетил его выступление про архитектуру в Берлине на Software Architecture Conference. Тогда мне показалось, что он очень бодрый спикер и консультант, который еще много лет будет выступать, напишет много статей и книжек, но в середине 2023 года его не стало. Goto сделали страницу в память о его наследии, ну а дальше я расскажу про его последнее выступление, в котором он дал 10 советов для прагматичной архитектурной работы 1. Choose your perspective(s) consciously - Стефан предлагает выбирать перспективу осмысленно. Он показывает разные перспективы: доменную архитектуру (с основными сервисами по доменам и стыками с внешними системами), макро-архитектуру (с основными доменами и их взаимодействиями внутри), микроархитектуру (какие технологии используются для этих сервисов). 2. Explicitly architect your team setup - здесь Стефан фактически отсылает нас к обратному маневру Конвея и дальше упоминает книгу Team topologies 3. Match your organizational setup to project size, etc. - про эту тему я рассказывал отдельный доклад на YaTalks, правда, у Стефана фокус на том, как выглядит архитектурная работа в каждом из случаев 4. Don't be afraid to decide things centrally - для эффективной работы автономных команд требуется принять ряд централизованных решений (что довольно иронично). Стефан рассказывает про то, какие это решения 5. Pick your battles wisely - тут речь про change management и про выбор тех изменений, которые требуются прямо сейчас. Важно не запускать слишком много изменений 6. Enforce the least viable amount of rules, rigidly - здесь автор показывает важность того, чтобы правил не было слишком много, иначе мы можем потерять гибкость и слишком бюрократизироваться 7. Balance prescriptive vs. descriptive architecture - здесь автор говорит хорощие вещи, что документирование архитектурных решений - это не то же самое, что их принятие:) Часто это документирование является первым шагом, но не конечной целью. Также круто сказано о том, что хорошее архитектурное решение не может нравиться всем, а если вам удалось принять решение, удовлетворяющее всех, то скорее всего это плохое решение (на эту тему можно посмотреть клип Би2 - Компромисс) 8. Don't aim for perfection - iterate - про итеративный подход к улучшениям 9. Architect for delivery flow as much as for runtime quality - здесь Стефан рассказывает о том, что при принятии архитектурных решений надо смотреть не только на функциональные и нефункциональные требования, но и на то, как это влияет на процессы разработки. Про это я тоже рассказывал в докладе "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса" 10. Be boring & do more with less - здесь Стефан рассказывает про технологическую стабильность, а также про уровень безумия компаний, который зависит от количества денег, что они готовы тратить на консультации:) В итоге, советы от Стефана звучат так

Prefer simple, straightforward solutions to overly clever and complicated, cool approaches

и

Focus innovation on the domain, not technology

Ну и финальный аккорд выступления посвящен тому, что архитектура до сих пор остается самой интересной областью в IT потому, что она имеет значение - если сделать ее плохо, то все развалится, а вот если сделать правильно, то успех еще не гарантирован:) P.S. RIP Стефан. Ты был крутым архитектором, консультантом и спикером. #Architecture #Software #Engineering

Картинка к посту про PACELC