Яхтенный глэмпинг парк "Точка Немо"
Вместе с женой и тремя сыновьями уехали на 4 дня в глэмпинг, который в отличие от названия, расположен не в южной части Тихого океана, а под Ярославлем:)
Мы живем в лесу на берегу реки в двух домиках: шарообразный купол для жены, самого мелкого сына и меня, а также домик на дереве для старшего и среднего сына. Домики достаточно комфортные и удобные для проживания, а рядом с домиками есть купели в виде большой бочки, где можно отдохнуть вечером в горячей воде. У детишек днем и вечером плотная программа - они учатся ходить под парусом, ходят в походы, жарят маршмелоу на костре, а мы с женой и самым маленким гуляем по территории:)
В общем, тут действительно можно отдохнуть на природе с детьми и чуток выдохнуть перед началом нового учебного года:)
#Holidays
Вместе с женой и тремя сыновьями уехали на 4 дня в глэмпинг, который в отличие от названия, расположен не в южной части Тихого океана, а под Ярославлем:)
Мы живем в лесу на берегу реки в двух домиках: шарообразный купол для жены, самого мелкого сына и меня, а также домик на дереве для старшего и среднего сына. Домики достаточно комфортные и удобные для проживания, а рядом с домиками есть купели в виде большой бочки, где можно отдохнуть вечером в горячей воде. У детишек днем и вечером плотная программа - они учатся ходить под парусом, ходят в походы, жарят маршмелоу на костре, а мы с женой и самым маленким гуляем по территории:)
В общем, тут действительно можно отдохнуть на природе с детьми и чуток выдохнуть перед началом нового учебного года:)
#Holidays
👍28❤7🔥5
Meet For Charity
Сегодня стартовал благотворительный аукцион Meet For Charity, где в качестве лота предлагается встреча со мной:)
Формат аукциона следующий
- для победителя аукциона я проведу небольшую экскурсию по офису Тинькофф и дальше мы пообщаемся за обедом в нашем ТЦ Водный
- собранные по итогам аукциона средства будут направлены в фонд «Нить добра»
В принципе, я готов обсудить разные темы, например, такие:
- почему сейчас бизнес и IT должны быть на одной волне;
- как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
- как выстроить архитектурные процессы в компании;
- как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
- как появление искусственного интеллекта изменило расклад на рынке разработки.
Но если у победителя будет своя тема на обсуждение, то я попробую обсудить и ее:)
P.S.
Ну и немного формальной части про меня:
- я работаю в Тинькофф почти семь лет и являюсь техническим директором юнита клиентские интерфейсы, маркетинг и вовлечение в Тинькофф
- до этого успел побыть руководителем группы разработки в Банки.ру и Woman.ru
- когда-то был software development engineer, а до этого успел закончить Физтех (МФТИ)
P.P.S.
Плюс победителю я подарю книгу Олега Тинькова "Революция. Как построить крупнейший онлайн-банк в мире", в одной из глав которой рассказывается про машину привлечения клиентов, к строительству которой я приложил руку:)
#Charity #Software #Management #Leadership
Сегодня стартовал благотворительный аукцион Meet For Charity, где в качестве лота предлагается встреча со мной:)
Формат аукциона следующий
- для победителя аукциона я проведу небольшую экскурсию по офису Тинькофф и дальше мы пообщаемся за обедом в нашем ТЦ Водный
- собранные по итогам аукциона средства будут направлены в фонд «Нить добра»
В принципе, я готов обсудить разные темы, например, такие:
- почему сейчас бизнес и IT должны быть на одной волне;
- как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
- как выстроить архитектурные процессы в компании;
- как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
- как появление искусственного интеллекта изменило расклад на рынке разработки.
Но если у победителя будет своя тема на обсуждение, то я попробую обсудить и ее:)
P.S.
Ну и немного формальной части про меня:
- я работаю в Тинькофф почти семь лет и являюсь техническим директором юнита клиентские интерфейсы, маркетинг и вовлечение в Тинькофф
- до этого успел побыть руководителем группы разработки в Банки.ру и Woman.ru
- когда-то был software development engineer, а до этого успел закончить Физтех (МФТИ)
P.P.S.
Плюс победителю я подарю книгу Олега Тинькова "Революция. Как построить крупнейший онлайн-банк в мире", в одной из глав которой рассказывается про машину привлечения клиентов, к строительству которой я приложил руку:)
#Charity #Software #Management #Leadership
👍20🔥13❤6🤔1
Практика визуального мышления. Оригинальный метод решения сложных проблем (Unfolding the Napkin. The Hands-On Method for Solving Complex Problems with Simple Pictures)
Эта книга Дэна Роэма продолжает книу «Визуальное мышление», в которой рассказывалось как простые рисунки могут играть в деле генерации идей и коммуникациях в целом. Она представила новую интересную методику решения совершенно различных проблем — от стратегических вопросов топ-менеджмента до самых прозаичных офисных проблем. А в книге-продолжении помогает читателям внедрить свою методику в ежедневную практику. Книга полна подробных примеров, упражнений и пустого места для ваших рисунков.
Я прочитал эту книгу с удовольствием. Единственная проблема - надо было продраться через скучные повторы первых пятидесяти страниц (ощущение, что их писали для страдающих от провалов в памяти). Как только вводная часть с большим количеством повторов закончилась, все стало очень интересно и полезно, например
- Мне понравилось то, что автор выделил 6 вопросов для решения любой проблемы, на которые надо ответить при помощи картинок. Я запомнил эти вопросы в таком порядке Что, Где, Когда (по названию знаменитой телепередачи) и оставшиеся 3 - Сколько, Как, Почему.
- Мне зашла концепция о глубине проработки проблемы для разных людей, которым ты хочешь донести свои мысли. Т.е. для кого-то требуется подготовить верхнеуровневую картину без погружения в детали, а другим же требуется детализированное отображение. Если не понимать потребности этих людей, то первые посчитают, что ты их перегружаешь ненужными деталями, а вторые решат, что ты не разбираешься в рассматриваемом вопросе:)
В общем, книгу можно порекомендовать всем, кому требуется анализировать проблемы, в качестве еще одного метода для использования такого мощного инструмента как человеческий мозг:)
#SelfDevelopment #Brain #Patterns #Creativity
Эта книга Дэна Роэма продолжает книу «Визуальное мышление», в которой рассказывалось как простые рисунки могут играть в деле генерации идей и коммуникациях в целом. Она представила новую интересную методику решения совершенно различных проблем — от стратегических вопросов топ-менеджмента до самых прозаичных офисных проблем. А в книге-продолжении помогает читателям внедрить свою методику в ежедневную практику. Книга полна подробных примеров, упражнений и пустого места для ваших рисунков.
Я прочитал эту книгу с удовольствием. Единственная проблема - надо было продраться через скучные повторы первых пятидесяти страниц (ощущение, что их писали для страдающих от провалов в памяти). Как только вводная часть с большим количеством повторов закончилась, все стало очень интересно и полезно, например
- Мне понравилось то, что автор выделил 6 вопросов для решения любой проблемы, на которые надо ответить при помощи картинок. Я запомнил эти вопросы в таком порядке Что, Где, Когда (по названию знаменитой телепередачи) и оставшиеся 3 - Сколько, Как, Почему.
- Мне зашла концепция о глубине проработки проблемы для разных людей, которым ты хочешь донести свои мысли. Т.е. для кого-то требуется подготовить верхнеуровневую картину без погружения в детали, а другим же требуется детализированное отображение. Если не понимать потребности этих людей, то первые посчитают, что ты их перегружаешь ненужными деталями, а вторые решат, что ты не разбираешься в рассматриваемом вопросе:)
В общем, книгу можно порекомендовать всем, кому требуется анализировать проблемы, в качестве еще одного метода для использования такого мощного инструмента как человеческий мозг:)
#SelfDevelopment #Brain #Patterns #Creativity
👍12❤4🔥1
Выбор. Правила Голдратта (The Choice)
Я прочитал эту книгу лет семь назад и мне она понравилась. В ней автор рассказывает про новейшие методы активизации мышления и показывает как они работают на практике. Книга выстроена в форме диалога с дочерью, где разбираются конкретные ситуации, для решения в которых требуется обеспечить совместную работу логики, интуиции и эмоций. Сложно сказать что нового я вынес из книги, но мне понравился подход автора. Он с видимой легкостью смог донести читателям свои идеи о использовании научного подхода в жизни. Особо понравились следующие моменты в его рассужденияъ:
- о простоте систем и о том, что степень простоты зависит от формулировки того что же это такое:)
- о причинах и следствиях, а также как понять что является причиной, а что нет
- о гармонии в отношениях элементов системы и о том, что компромисы при конфликтах часто являются злом, т.к. устраняются симптомы проблемы, а не ее корень
- о том, что надо верить в людей:)
P.S.
Подробнее про концепции Голдратта можно почитать в других постах
- Теория ограничений Голдратта (Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement)
- Критическая цепь (Critical Chain)
#Management #Processes #Project #ProjectManagement
Я прочитал эту книгу лет семь назад и мне она понравилась. В ней автор рассказывает про новейшие методы активизации мышления и показывает как они работают на практике. Книга выстроена в форме диалога с дочерью, где разбираются конкретные ситуации, для решения в которых требуется обеспечить совместную работу логики, интуиции и эмоций. Сложно сказать что нового я вынес из книги, но мне понравился подход автора. Он с видимой легкостью смог донести читателям свои идеи о использовании научного подхода в жизни. Особо понравились следующие моменты в его рассужденияъ:
- о простоте систем и о том, что степень простоты зависит от формулировки того что же это такое:)
- о причинах и следствиях, а также как понять что является причиной, а что нет
- о гармонии в отношениях элементов системы и о том, что компромисы при конфликтах часто являются злом, т.к. устраняются симптомы проблемы, а не ее корень
- о том, что надо верить в людей:)
P.S.
Подробнее про концепции Голдратта можно почитать в других постах
- Теория ограничений Голдратта (Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement)
- Критическая цепь (Critical Chain)
#Management #Processes #Project #ProjectManagement
❤14👍6🕊2
Макет Золотого кольца России
В воскресенье мы успеои посмотреть макет Золотого кольца России. Мы оказались в Ярославле по дороге в яхтенный парк "Точка Немо", куда мы ездили в миниотпуск. Честно говоря, я люблю эти минигорода и видел макет Москвы в ВДНХ и гранд макет в Питере, поэтому не посетить миниатюрный музей в Ярославле я не мог:)
В этом макете Золотого кольца интересно сделана геймификация для детей, которые могут взять задание на поиск пасхалок - знаменитых мультяшных персонажей, что раскиданы по мини-версиям Ярославля, Костромы, Иваново, Ростова и других городов, что входят в кольцо. Наших детей эти поиски захватили на час, но к концу часа они отчаявшись запросили помощи у тетушек, что продавали сувениры у выхода и получили подсказки по остальным персонажам. Именно так они выполнили свой квест и получили подарки в виде трех колокольчиков 1) в форме кота с гитарой, 2) волка из мультика "Жил был пес" и 3) кота, который сидит на колокольчике. В общем, всем в этом миниатюрном музее (он действительно небольшой) понравилось:)
#Holidays
В воскресенье мы успеои посмотреть макет Золотого кольца России. Мы оказались в Ярославле по дороге в яхтенный парк "Точка Немо", куда мы ездили в миниотпуск. Честно говоря, я люблю эти минигорода и видел макет Москвы в ВДНХ и гранд макет в Питере, поэтому не посетить миниатюрный музей в Ярославле я не мог:)
В этом макете Золотого кольца интересно сделана геймификация для детей, которые могут взять задание на поиск пасхалок - знаменитых мультяшных персонажей, что раскиданы по мини-версиям Ярославля, Костромы, Иваново, Ростова и других городов, что входят в кольцо. Наших детей эти поиски захватили на час, но к концу часа они отчаявшись запросили помощи у тетушек, что продавали сувениры у выхода и получили подсказки по остальным персонажам. Именно так они выполнили свой квест и получили подарки в виде трех колокольчиков 1) в форме кота с гитарой, 2) волка из мультика "Жил был пес" и 3) кота, который сидит на колокольчике. В общем, всем в этом миниатюрном музее (он действительно небольшой) понравилось:)
#Holidays
❤13👍3🔥1
Frontend Architecture for Design Systems. A modern blueprint for scalable and sustainable websites
Лет 5 назад я прочитал эту книгу с интригующим названием "Frontend Architecture for Design Systems", ожидая от нее многого.
Книга написана Micah Godbolt на основании его многолетнего опыта работы в качестве фронтендера на разнообразных проектах. Один из последних проектов был в том, чтобы переделать сайт RedHat.com, которая славилась тем, что научилась зарабатывать на open source решениях, но особых достижений во фронтенде раньше отмечено не было.
Что особенно радует в книге, что автор не скатывается до выбора одной из библиотек и фреймворков и не объявляет его/ее серебрянной пулей, например, говоря, что Angular/React/Vue животворящий поможет решить вам все проблемы:) Фактически, автор борется за то, чтобы фронтенд-архитектура тоже была жителем первого класса в проекте разработки программного обеспечения. Для этого автор выделяет 4 столпа, а именно:
- Код (сладкое трио html, css, javascript)
- Процессы (инструменты и процессы для создания эффективного workflow)
- Тестирование (создание устойчивого решения)
- Документация
В первой части книги, а именно во вступлении автор поднимает интересный вопрос того как мы оказались в текущем положении, от появления www до появления понятия фронтенд-архитектура. Дальше он расматривает составные части этого понятия, а именно:
- Design ("By designing a system all frontend developers are going to work within, the architect sets a clear vision of what the end product, the code, will look like")
- Planning
- Oversight ("Frontend architecture is never a “set it and forget it” proposition ... A key talent of a frontend architect is the ability to continually make needed adjustments")
Вводная часть завершается мыслью о роли фронтового архитектора: "Without the early input of a frontend architect, projects run the risk of having to choose between reworking designs, platform, or infra‐ structure and telling the frontend developers to make do"
Вторая часть содержит главы относительно того, как надо структурировать код, а именно писать html, css и javascript'а. Но забавно, что в этой книге я в первый раз увидел изложение принципа единственной ответственности (Single Responsibility Principle) в переложении на фронт, а именно в главе, где рассматривались правила работы с CSS:)
Следующая часть относится к процессам. В ней рассказывается про старый и новый workflow. Также обсуждаются вопросы CI/CD в общем и сборки asset'ов в частности.
В главе 10, где обсуждается процесс Red Hat, где раскрывается schema-driven design система, в которой имеются:
- JSON schema - схема компонентов
- Template file - шаблон компонента
- Sass partial - стили компонента
- Visual regression tests - тесты для визуального регресса
- Testing data - тестовые данные
- Documentation - документация компонента
- Documentation data - данные для документации
В общем, этот подход "schema-driven design system" мне до боли знаком:) И по опыту могу сказать, что он работает куда лучше, чем альтернативные варианты.
В части, относящейся к тестрованию рассматривались:
- юнит-тесты
- performance-тесты
- визуальное регресс-тестирования
- интеграция всего этого в процесс тестирования в Red Hat:)
В части, относящейся к документированию основной акцент идет на том, как организовать в модульной дизайн системе набор компонентов, доступных для переиспользования.
Опять идет отсылка к Brad Frost’s Atomic Design principles (хоть это и убогое название для стандартного компонентого подхода от автора, который не разбирается ни в химии, ни в биологии).
В итоге, книга действительно неплохая и хорошо раскрывает подход к рендерингу фронтового отображения семилетней давности:) Но книга явно не дотягивает до рассказа об архитектуре всего приложения и если вы делаете изоморфное приложение, одновременно отвечая за бекенд (даже довольно тонкий), то одной этой книги вам не хватит.
#Architecture #Software #SoftwareArchitecture #SoftwareDevelopment #Engineering
Лет 5 назад я прочитал эту книгу с интригующим названием "Frontend Architecture for Design Systems", ожидая от нее многого.
Книга написана Micah Godbolt на основании его многолетнего опыта работы в качестве фронтендера на разнообразных проектах. Один из последних проектов был в том, чтобы переделать сайт RedHat.com, которая славилась тем, что научилась зарабатывать на open source решениях, но особых достижений во фронтенде раньше отмечено не было.
Что особенно радует в книге, что автор не скатывается до выбора одной из библиотек и фреймворков и не объявляет его/ее серебрянной пулей, например, говоря, что Angular/React/Vue животворящий поможет решить вам все проблемы:) Фактически, автор борется за то, чтобы фронтенд-архитектура тоже была жителем первого класса в проекте разработки программного обеспечения. Для этого автор выделяет 4 столпа, а именно:
- Код (сладкое трио html, css, javascript)
- Процессы (инструменты и процессы для создания эффективного workflow)
- Тестирование (создание устойчивого решения)
- Документация
В первой части книги, а именно во вступлении автор поднимает интересный вопрос того как мы оказались в текущем положении, от появления www до появления понятия фронтенд-архитектура. Дальше он расматривает составные части этого понятия, а именно:
- Design ("By designing a system all frontend developers are going to work within, the architect sets a clear vision of what the end product, the code, will look like")
- Planning
- Oversight ("Frontend architecture is never a “set it and forget it” proposition ... A key talent of a frontend architect is the ability to continually make needed adjustments")
Вводная часть завершается мыслью о роли фронтового архитектора: "Without the early input of a frontend architect, projects run the risk of having to choose between reworking designs, platform, or infra‐ structure and telling the frontend developers to make do"
Вторая часть содержит главы относительно того, как надо структурировать код, а именно писать html, css и javascript'а. Но забавно, что в этой книге я в первый раз увидел изложение принципа единственной ответственности (Single Responsibility Principle) в переложении на фронт, а именно в главе, где рассматривались правила работы с CSS:)
Следующая часть относится к процессам. В ней рассказывается про старый и новый workflow. Также обсуждаются вопросы CI/CD в общем и сборки asset'ов в частности.
В главе 10, где обсуждается процесс Red Hat, где раскрывается schema-driven design система, в которой имеются:
- JSON schema - схема компонентов
- Template file - шаблон компонента
- Sass partial - стили компонента
- Visual regression tests - тесты для визуального регресса
- Testing data - тестовые данные
- Documentation - документация компонента
- Documentation data - данные для документации
В общем, этот подход "schema-driven design system" мне до боли знаком:) И по опыту могу сказать, что он работает куда лучше, чем альтернативные варианты.
В части, относящейся к тестрованию рассматривались:
- юнит-тесты
- performance-тесты
- визуальное регресс-тестирования
- интеграция всего этого в процесс тестирования в Red Hat:)
В части, относящейся к документированию основной акцент идет на том, как организовать в модульной дизайн системе набор компонентов, доступных для переиспользования.
Опять идет отсылка к Brad Frost’s Atomic Design principles (хоть это и убогое название для стандартного компонентого подхода от автора, который не разбирается ни в химии, ни в биологии).
В итоге, книга действительно неплохая и хорошо раскрывает подход к рендерингу фронтового отображения семилетней давности:) Но книга явно не дотягивает до рассказа об архитектуре всего приложения и если вы делаете изоморфное приложение, одновременно отвечая за бекенд (даже довольно тонкий), то одной этой книги вам не хватит.
#Architecture #Software #SoftwareArchitecture #SoftwareDevelopment #Engineering
👍6❤5🔥4
Выборы новой книги для изучения в рамках клуба "Code of Architecture"
Уже в сентябре мы начнем читать новую книгу в книжном клубе Code of Architecture и это будет как обычно та книга, которую выберете вы:)
На выбор представлены 4 книги, три из которых я уже прочитал и рекомендовал вам их. Вот мои впечатления по каждой из них
1) Building Secure and Reliable Systems - крутая, но тяжелая книга от Google про проектирование надежных систем. Подробнее про эту книгу я рассказывал здесь
2) Continuos Architectere in Practice — крутая и практичная книга по архитектуре, что мне показалась на голову выше творчества Нила Форда и его друзей (это отсылка к книге Software Architecture. The hard parts). Кратко про принципы continuous architecture я рассказывал здесь, но я очень хочу эту книгу полноценно разобрать в рамках Code of Architecture - это будет точно бомба:)
3) The Software Architect Elevator — интересная книга про роль архитектора в digital enterprise. Про нее я рассказывал здесь
4) Machine Learning Design Patterns — книга от ребят из Google про то, как готовить данные, строить модели и делать MLOps. Тема для меня интересная, но пока это единственная книга из спика, которую я не дочитал:)
Рекомендую выбрать вариант 2:)
#SoftwareDevelopment #Architecture #SoftwareArchitecture #Software #Leadership #SystemDesign
Уже в сентябре мы начнем читать новую книгу в книжном клубе Code of Architecture и это будет как обычно та книга, которую выберете вы:)
На выбор представлены 4 книги, три из которых я уже прочитал и рекомендовал вам их. Вот мои впечатления по каждой из них
1) Building Secure and Reliable Systems - крутая, но тяжелая книга от Google про проектирование надежных систем. Подробнее про эту книгу я рассказывал здесь
2) Continuos Architectere in Practice — крутая и практичная книга по архитектуре, что мне показалась на голову выше творчества Нила Форда и его друзей (это отсылка к книге Software Architecture. The hard parts). Кратко про принципы continuous architecture я рассказывал здесь, но я очень хочу эту книгу полноценно разобрать в рамках Code of Architecture - это будет точно бомба:)
3) The Software Architect Elevator — интересная книга про роль архитектора в digital enterprise. Про нее я рассказывал здесь
4) Machine Learning Design Patterns — книга от ребят из Google про то, как готовить данные, строить модели и делать MLOps. Тема для меня интересная, но пока это единственная книга из спика, которую я не дочитал:)
Рекомендую выбрать вариант 2:)
#SoftwareDevelopment #Architecture #SoftwareArchitecture #Software #Leadership #SystemDesign
Telegram
Code of Architecture
Какую книгу будет читать следующей?
Building Secure and Reliable Systems — безопасность и надежность ПО от команды Google / Continuos Architectere in Practice — современный гайд по архитектуре ПО в эпоху Agility и DevOps / The Software Architect Elevator…
Building Secure and Reliable Systems — безопасность и надежность ПО от команды Google / Continuos Architectere in Practice — современный гайд по архитектуре ПО в эпоху Agility и DevOps / The Software Architect Elevator…
👍7🔥5❤1
Курс "Теория вероятностей" на Stepik
Лет шесть назад я прошел этот курс на степике и действительно могу подтвердить, что он тянет на свою оценку в 4.8 из 5, что указана на платформе:)
В самом курсе рассказывается о базовых понятиях и теоремах теории вероятностей и содержит много практических заданий для самостоятельного решения.
Курс состоит из двух частей по два модуля в каждой:
- Первая часть посвящена классической версии теорвера, где испольхуются элементарные методы и доказательства. Модули внутри первой части так и называются "Элементарная теория вероятностей: случайные события" и "Элементарная теория вероятностей: случайные величины"
- Вторая часть содержит материал посложнее. Третий модуль называется "Общая теория вероятностей" и содержит аксиоматический подход к теории вероятностей и строгое изложение общей теории. Это самый интересный и сложный модуль. Четвертый модуль "Дискретные и непрерывные случайные величины" содержит обсуждение частных случаев, которые после общей теории кажутся простыми и понятными:)
В итоге, курс мне кажется полезным для получения базовых знаний по теории вероятности, которые нужны в быту, например, чтобы понять как считается надежность системы, состоящей из кучи сервисов, если у каждого сервиса есть свой SLA по доступности и все из них нужны для работоспособности системы верхнего уровня:) Как-то я такого типа вопрос хотел добавить в скрининг SRE-инженеров:)
P.S.
Сам я теорвер люблю еще со школы - это началось после того как в 10 классе съездил в Москву посмотреть на МГУ и МФТИ, чтобы решить куда буду поступать из своего Северодвинска:) В итоге, я вернулся с набором книг, в котором была книга по теорверу, которая мне понравилась, но обложку которой я не смог найти потом в Google, чтобы узнать название этой книги и перечитать по прошествии лет.
#Math #Course
Лет шесть назад я прошел этот курс на степике и действительно могу подтвердить, что он тянет на свою оценку в 4.8 из 5, что указана на платформе:)
В самом курсе рассказывается о базовых понятиях и теоремах теории вероятностей и содержит много практических заданий для самостоятельного решения.
Курс состоит из двух частей по два модуля в каждой:
- Первая часть посвящена классической версии теорвера, где испольхуются элементарные методы и доказательства. Модули внутри первой части так и называются "Элементарная теория вероятностей: случайные события" и "Элементарная теория вероятностей: случайные величины"
- Вторая часть содержит материал посложнее. Третий модуль называется "Общая теория вероятностей" и содержит аксиоматический подход к теории вероятностей и строгое изложение общей теории. Это самый интересный и сложный модуль. Четвертый модуль "Дискретные и непрерывные случайные величины" содержит обсуждение частных случаев, которые после общей теории кажутся простыми и понятными:)
В итоге, курс мне кажется полезным для получения базовых знаний по теории вероятности, которые нужны в быту, например, чтобы понять как считается надежность системы, состоящей из кучи сервисов, если у каждого сервиса есть свой SLA по доступности и все из них нужны для работоспособности системы верхнего уровня:) Как-то я такого типа вопрос хотел добавить в скрининг SRE-инженеров:)
P.S.
Сам я теорвер люблю еще со школы - это началось после того как в 10 классе съездил в Москву посмотреть на МГУ и МФТИ, чтобы решить куда буду поступать из своего Северодвинска:) В итоге, я вернулся с набором книг, в котором была книга по теорверу, которая мне понравилась, но обложку которой я не смог найти потом в Google, чтобы узнать название этой книги и перечитать по прошествии лет.
#Math #Course
Stepik: online education
Теория вероятностей
Курс знакомит слушателей с базовыми понятиями теории вероятностей: вероятностным пространством, условной вероятностью, случайными величинами, независимостью, математическим ожиданием и дисперсией. Доказываются закон больших чисел и некоторые версии предельных…
🔥14👍8❤3
Мой доклад "Improving Software Flow" на IT-пикнике 2 сентября
Уже через неделю будет большой ИТ-пикник в Коломенском парке от Тинькофф, DevFest и Мельницы. Я на этом пикнике входу в программный комитет трека "Архитектура, надежность, качество", где будет шесть докладов. Один из докладов выпал из-за форсмажора, поэтому я внезапно стал еще и спикером, который закроет этот трек с докладом "Improving software flow", который я уже рассказывал вначале августа в Казани на нашем фестивале (расшифровка доклада есть здесь, но записи пока нет).
Если вы планируете зайти на фестиваль, то не забудьте зайти именно на наш трек, а может и на мой доклад:)
Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут.
#Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems
Уже через неделю будет большой ИТ-пикник в Коломенском парке от Тинькофф, DevFest и Мельницы. Я на этом пикнике входу в программный комитет трека "Архитектура, надежность, качество", где будет шесть докладов. Один из докладов выпал из-за форсмажора, поэтому я внезапно стал еще и спикером, который закроет этот трек с докладом "Improving software flow", который я уже рассказывал вначале августа в Казани на нашем фестивале (расшифровка доклада есть здесь, но записи пока нет).
Если вы планируете зайти на фестиваль, то не забудьте зайти именно на наш трек, а может и на мой доклад:)
Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут.
#Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems
it-picnic.ru
ИТ-пикник 2025 — летний фестиваль для ИТ-специалистов и их близких
Лекции, интерактивы, детские зоны, музыка и яркий летний день. Ждем вас на ИТ-пикнике 16 августа в Коломенском. Подписывайтесь на телеграм-канал, чтобы не пропустить регистрацию
👍12❤4🔥1
Специальный выпуск Code of Architecture с разбором white paper про Borg
Этот выпуск мы записывали в начале августа на Тинькофф ИТ-фесте в Казани. У нас была аутентичная обстановка - ковер на фоне, чак-чак и самовар на столе:)
И мы обсуждали научную статью 2015 года от Google "Large-scale cluster management at Google with Borg" в составе:
- Владимир Чистяков - руководитель разработки в Тинькофф, один из постоянных ведущих "Code of Architecture", который приехал на конференцию в Казань из Воронежа, где он работает в воронежском центре разработки
- Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform, который живет в Казани и работает в казанском центре разработки
- Автор этого канала, который приехал на конференцию из Москвы, где работает в Headquarters
Если вернуться к содержанию статьи, то надо сказать, что Borg - это система оркестрации рабочих нагрузок, которая используется в Google. Интересно, что именно в недрах Google родился и Kubernetes, в котором был утчен опыт создания и эксплуатации Borg. Интересно, что в 2016 году вышла статья со сравнением трех оркестраторов "Borg, Omega, and Kubernetes", которую интересно прочитать в продолжении.
#Kubernetes #SystemDesign #SoftwareArchitecture #SoftwareDevelopment #Software #Architecture #DistributedSystems
Этот выпуск мы записывали в начале августа на Тинькофф ИТ-фесте в Казани. У нас была аутентичная обстановка - ковер на фоне, чак-чак и самовар на столе:)
И мы обсуждали научную статью 2015 года от Google "Large-scale cluster management at Google with Borg" в составе:
- Владимир Чистяков - руководитель разработки в Тинькофф, один из постоянных ведущих "Code of Architecture", который приехал на конференцию в Казань из Воронежа, где он работает в воронежском центре разработки
- Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform, который живет в Казани и работает в казанском центре разработки
- Автор этого канала, который приехал на конференцию из Москвы, где работает в Headquarters
Если вернуться к содержанию статьи, то надо сказать, что Borg - это система оркестрации рабочих нагрузок, которая используется в Google. Интересно, что именно в недрах Google родился и Kubernetes, в котором был утчен опыт создания и эксплуатации Borg. Интересно, что в 2016 году вышла статья со сравнением трех оркестраторов "Borg, Omega, and Kubernetes", которую интересно прочитать в продолжении.
#Kubernetes #SystemDesign #SoftwareArchitecture #SoftwareDevelopment #Software #Architecture #DistributedSystems
YouTube
Разбираем white paper Large-scale cluster management at Google with Borg — Code of Architecture
Записали специальный выпуск Code of Architecture на Тинькофф ИТ-фест в Казани. Разобрали white paper от Google «Large-scale cluster management at Google with Borg».
В нем описывается система управления кластерами, которую использует компания. Гостем стал…
В нем описывается система управления кластерами, которую использует компания. Гостем стал…
👍4❤3🔥3
Thinking Architecturally. Lead technical change within your engineering team
Эту небольшую брошюру от Nathaniel Schutta я прочитал в далеком 2019 году, когда гораздо проще было путешествовать по зарубежным конференциям и собирать ништяки. Конкретно в этой книге 56 страниц, но это только уменьшает количество воды, которую обычно наливают авторы в книги, чтобы растянуть книгу на 200 - 250 страниц. Конкретно в этой книге получилось 7 коротких глав:
1. Technology Changes - здесь речь идет про то, что технологии меняются и мы не можем предотвратить изменения, поэтому нам надо уметь ими управлять. Автор отмечает, что изменения в технологиях часто повторяют себя и нам надо знать прошлое, чтобы распознавать будущие паттерны. Здесь автор предлагает учиться на своих ошибках и ошибках индустрии (например, постмортемы, про которые я как-то рассказывал здесь), оценивать развитие технологий и не верить в хайп с конференций. Тут автор упоминает даже про пользу legacy skillset, на примере COBOL:)
2. Thinking Strategically - основная мысль в том, что думать об изменениях в технологиях надо стратегически и также стратегически надо думать про свое развитие. Автор предлагает фокусироваться на нескольких областях, которыми вы глубоко увлечены и прокачивайте их. Дальше автор рассказывает про использование техрадаров по технологиям, которые можно использовать и для поддержания своих технологических знаний (подробнее про техрадары я говорил здесь). Дальше идет речь про структурирование потоков информации, создание планов по своему развитию с созданием пет-проектов, персональное обучение, обучение в группе, общение с коллегами по индустрии
3. Evaluating Pros and Cons - эта глава посвящена принятию решений, как оценивать компромиссы, риски. Тут же обсуждается technology hype cycle и выбор правильного инструмента
4. Evaluating and Choosing Technologies - как выбрать критерии для оценки, например: документация, коммьюнити, структуру контрибьюторов, кодовая база, тестируемость, зрелость, стабильность, расширяемость, поддержка, тренинги, возможность найма специалистов, безопасность, попадание в корпоративнудю структуру. Как это можно все свести в spreadsheet для оценки, сделать proof of concept и как на решение влияет политика организации
5. Introducing Technologies - про то, что внедрение новой технологии зачастую сложнее ее выбора:) Как митигировать изменения, как влиять на окружающих, как работать с возраениями и заниматься маркетингом своих идей
6. Maintaining Technologies - как поддерживать внедренные технологии по мере эволюции программных систем. Автор вспоминает про концепцию quality attributes (примерно то же самое, что architectural characteristics), которые надо выделить как важные для конкретного продукта, дальше отприоритизировать их и использовать подход continuous или evolutionary architecture с их фитнес-функциями для отслеживания того, что характеристики не уплывают по мере инкрементального развития продукта (вот тут подробнее про continuous architecture, эволюционную архитектуру)
7. Conclusion - в конце автор рекомендует стратегически подходить к применению новых технологий к вашему продукту/проекту.
#Architecture #Management #Leadership #Software #SoftwareArchitecture #SoftwareDevelopment
Эту небольшую брошюру от Nathaniel Schutta я прочитал в далеком 2019 году, когда гораздо проще было путешествовать по зарубежным конференциям и собирать ништяки. Конкретно в этой книге 56 страниц, но это только уменьшает количество воды, которую обычно наливают авторы в книги, чтобы растянуть книгу на 200 - 250 страниц. Конкретно в этой книге получилось 7 коротких глав:
1. Technology Changes - здесь речь идет про то, что технологии меняются и мы не можем предотвратить изменения, поэтому нам надо уметь ими управлять. Автор отмечает, что изменения в технологиях часто повторяют себя и нам надо знать прошлое, чтобы распознавать будущие паттерны. Здесь автор предлагает учиться на своих ошибках и ошибках индустрии (например, постмортемы, про которые я как-то рассказывал здесь), оценивать развитие технологий и не верить в хайп с конференций. Тут автор упоминает даже про пользу legacy skillset, на примере COBOL:)
2. Thinking Strategically - основная мысль в том, что думать об изменениях в технологиях надо стратегически и также стратегически надо думать про свое развитие. Автор предлагает фокусироваться на нескольких областях, которыми вы глубоко увлечены и прокачивайте их. Дальше автор рассказывает про использование техрадаров по технологиям, которые можно использовать и для поддержания своих технологических знаний (подробнее про техрадары я говорил здесь). Дальше идет речь про структурирование потоков информации, создание планов по своему развитию с созданием пет-проектов, персональное обучение, обучение в группе, общение с коллегами по индустрии
3. Evaluating Pros and Cons - эта глава посвящена принятию решений, как оценивать компромиссы, риски. Тут же обсуждается technology hype cycle и выбор правильного инструмента
4. Evaluating and Choosing Technologies - как выбрать критерии для оценки, например: документация, коммьюнити, структуру контрибьюторов, кодовая база, тестируемость, зрелость, стабильность, расширяемость, поддержка, тренинги, возможность найма специалистов, безопасность, попадание в корпоративнудю структуру. Как это можно все свести в spreadsheet для оценки, сделать proof of concept и как на решение влияет политика организации
5. Introducing Technologies - про то, что внедрение новой технологии зачастую сложнее ее выбора:) Как митигировать изменения, как влиять на окружающих, как работать с возраениями и заниматься маркетингом своих идей
6. Maintaining Technologies - как поддерживать внедренные технологии по мере эволюции программных систем. Автор вспоминает про концепцию quality attributes (примерно то же самое, что architectural characteristics), которые надо выделить как важные для конкретного продукта, дальше отприоритизировать их и использовать подход continuous или evolutionary architecture с их фитнес-функциями для отслеживания того, что характеристики не уплывают по мере инкрементального развития продукта (вот тут подробнее про continuous architecture, эволюционную архитектуру)
7. Conclusion - в конце автор рекомендует стратегически подходить к применению новых технологий к вашему продукту/проекту.
#Architecture #Management #Leadership #Software #SoftwareArchitecture #SoftwareDevelopment
👍8❤4🔥2
Кто такие Technical Product Manager, зачем они компаниям и как им взаимодействовать со стейкхолдерами?
Интересная статья про технических менеджеров продуктов, которые есть в некоторых компаниях (в Тинькофф они тоже есть).
По-факту, такие технические продакт-менеджеры делают внутренний платформенный продукт, у которого пользователями являются инженеры внутри, которые не всегда любят делиться своими проблемами, используя мантру "я могу решить любую проблему". В итоге, такой продакт менеджер должен уметь классно общаться с технарями, чтобы понять как сделать продукт, который им действительно поможет. В этой статье приводятся метрики таких платформенных продуктов:
- как они влияют на time to market продуктовых команд (платформы должны помогать сократить ttm)
- dimension cost или ограничение по стоимости продукта (если строить платформу слишком дорого, то это не ок)
- net promoter score (насколько инженеры довольны своей работой на платформе, по этому показателю можно оценить developer experience)
Дальше рассматривается вопрос о том, как на этой роли взаимодействовать со стейкхолдерами и доносить пользу от своих продуктов - часто признание находит только продуктовые команды, а создатели внутренних платформ часто оказываются крайними в случае проблем и невидимками в случае успехов:) В итоге, надо уметь разжевывать технические детали нетехническим стейкхолдерам и вклад своих команд в общий результат.
#Management #Leadership #ProductManagement
Интересная статья про технических менеджеров продуктов, которые есть в некоторых компаниях (в Тинькофф они тоже есть).
По-факту, такие технические продакт-менеджеры делают внутренний платформенный продукт, у которого пользователями являются инженеры внутри, которые не всегда любят делиться своими проблемами, используя мантру "я могу решить любую проблему". В итоге, такой продакт менеджер должен уметь классно общаться с технарями, чтобы понять как сделать продукт, который им действительно поможет. В этой статье приводятся метрики таких платформенных продуктов:
- как они влияют на time to market продуктовых команд (платформы должны помогать сократить ttm)
- dimension cost или ограничение по стоимости продукта (если строить платформу слишком дорого, то это не ок)
- net promoter score (насколько инженеры довольны своей работой на платформе, по этому показателю можно оценить developer experience)
Дальше рассматривается вопрос о том, как на этой роли взаимодействовать со стейкхолдерами и доносить пользу от своих продуктов - часто признание находит только продуктовые команды, а создатели внутренних платформ часто оказываются крайними в случае проблем и невидимками в случае успехов:) В итоге, надо уметь разжевывать технические детали нетехническим стейкхолдерам и вклад своих команд в общий результат.
#Management #Leadership #ProductManagement
Блог ProductSense
Кто такие Technical Product Manager, зачем они компаниям и как им взаимодействовать со стейкхолдерами?
Technical Product Manager (технический менеджер продуктов) — это менеджер продуктов с хорошей технической подготовкой техническим, опытом в разработке, который больше работает с командой разработки…
👍9❤6🔥4