Путешествие в Лондон
Вчера мы сначала 10+ часов летели в Лондон с пересадкой в Баку, а потом целый день бродили по нему. Была отличная погода: солнышко, +10 градусов и запах весны. В итоге, мы находили порядка 20 тысяч шагов и успели прогуляться по центру города и вернуться в номер. Часов в 20 по местному времени мы отключились, а сегодня утром идем на персональную экскурсию по Лейстер square.
В обшем, эту неделю я побуду в роли туриста, а не технического директора (но материалов для tg-канала я приготовил заранее достаточно, так что вам все еще будет, что почитать - посты будут продолжаться и во время моего отпуска)
#Travel
Вчера мы сначала 10+ часов летели в Лондон с пересадкой в Баку, а потом целый день бродили по нему. Была отличная погода: солнышко, +10 градусов и запах весны. В итоге, мы находили порядка 20 тысяч шагов и успели прогуляться по центру города и вернуться в номер. Часов в 20 по местному времени мы отключились, а сегодня утром идем на персональную экскурсию по Лейстер square.
В обшем, эту неделю я побуду в роли туриста, а не технического директора (но материалов для tg-канала я приготовил заранее достаточно, так что вам все еще будет, что почитать - посты будут продолжаться и во время моего отпуска)
#Travel
👍45❤13🔥9👎1
A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering)
Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др.
Ниже интересные моменты про его биографию, не все из которых я знал
- В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки
- На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные.
- В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой".
- Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя.
Не забыли они обсудить и сам C++, его предназначение и историю развития
- В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы.
- Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором.
- Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество.
- Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык.
В итоге, я себе отметил моменты
1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора.
2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий.
3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто.
4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге
5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара.
6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы.
#Engineering #Software #Management #Leadership #Architecture
Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др.
Ниже интересные моменты про его биографию, не все из которых я знал
- В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки
- На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные.
- В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой".
- Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя.
Не забыли они обсудить и сам C++, его предназначение и историю развития
- В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы.
- Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором.
- Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество.
- Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык.
В итоге, я себе отметил моменты
1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора.
2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий.
3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто.
4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге
5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара.
6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы.
#Engineering #Software #Management #Leadership #Architecture
YouTube
A Brief History of Bjarne Stroustrup, the Creator of C++
In this portrait, we meet Bjarne Stroustrup where we talk about his childhood, his accidental entry into computer science (what is "datologi" anyway?), and the ideas that shaped one of the most influential programming languages ever made -- among many, many…
❤11👍5🔥4
The Rise and Rise of FastAPI (Рубрика #API)
Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг
Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически
2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints
3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация
4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.
5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".
Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"
2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне
3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99
4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью
На сайте system-design.space есть чуть более подробный разбор.
#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture
Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг
Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически
2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints
3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация
/docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.
5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".
Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"
2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне
3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99
4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью
На сайте system-design.space есть чуть более подробный разбор.
#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture
YouTube
The Rise and Rise of FastAPI
FastAPI has rapidly become the #1 most-starred backend framework on GitHub, surpassing not only Python giants Flask and Django, but frameworks across other languages, including Gin, Laravel, Spring Boot, and Express.
Meet Sebastián Ramirez, the creator…
Meet Sebastián Ramirez, the creator…
❤6👍6🔥2
Студия, где снимали Гарри Поттера (Рубрика #Travel)
Вчера с Настей были в студии Warner Brosers под Лондоном, где снимались все книги про Мальчика, что выжил. Посмотрели на павильоны, интерьры, костюмы, спецэффекты и нам все очень понравилось. Видно, что была проделана огромная работа, но в результате получилась легендарная экранизация. В мае приедем сюда же, но уже с детишками.
Вчера с Настей были в студии Warner Brosers под Лондоном, где снимались все книги про Мальчика, что выжил. Посмотрели на павильоны, интерьры, костюмы, спецэффекты и нам все очень понравилось. Видно, что была проделана огромная работа, но в результате получилась легендарная экранизация. В мае приедем сюда же, но уже с детишками.
1❤19👍9🔥8👎2😍1
Zero to One (От нуля к единице. Как создать стартап, который изменит будущее) (Рубрика #Startups)
Прочитал интересную книгу Питера Тиля, со-основателя PayPal и Palantir, еще 2014 года, которая является конспектом его курса в Stanford, который он читал за пару лет до этого. В этом курсе Питер обсуждал не рецепты успеха, а говорил про сдвиг мышления: как из технологии сделать новую категорию, а не ещё один продукт, что будет чуть лучше, чем у конкурентов.
В 2010 году эта книга пришлась ко двору во время бума венчура и стартап‑культуры - всем хотелось поймать "следующего единорога", а книга требовала делать наоборот: искать уникальность и строить защитный ров вокруг своей идеи. В книге было много ярких формулировок, например, вокруг того, что "конкуренция - это для лузеров", а это привело к тому, что они стали вирусными и разошлись на цитаты. В общем, с точки зрения маркетинга идей книга была хороша. С тех пор многое поменялось, но ее до сих пор полезно прочесть и подумать над идеями вроде
1️⃣ Идея "0→1 vs 1→n"
Вообще, название книги противопоставляет идею создания чего-то нового с нуля (0→1) и идею дальнейшего масштабирования и улучшения (1→n). По мнению Питера ценность часто в 10x скачке за счет архитектуры, алгоритмов, UX, стоимости или надёжности и т.д., а не в бесконечной полировке продукта
2️⃣ Идея секретов
Эта идея крутится вокруг важной истины в вашей области, что неочевидна большинству. Собственно, это очень напоминает мышление from the first principles, когда можно взглянуть на ситуацию не через стереотипы, а шире и найти нестандартное решение
3️⃣ Про пользу монополий по сравнению с идеальной конкуренцией
У Тиля очень нестандартный взгляд на монополии и кокуренцию. Я думаю, что это особенность позиции большого капиталиста, но он говорит про творческое преимущество, а не про возможность задушить рынок. Для него монополия - это идея вокруг того, а почему вас сложно повторить (данные, интеграции, сеть, стандарты, бренд, скорость поставки).
4️⃣ Про важность дистрибуции
У Тиля это часть системы - можно собрать идеальный движок, но без канала доставки ценности он не станет продуктом. Но про остальные процессы для рабочего продукта он почти не говорит.
Если посмотреть, а как менялись подходы к венчуру после выхода книги, то получим примерно такой таймлайн
- 2014–2019: Lean/MVP + рост → затем мода на blitz scaling (захватим рынок, потом оптимизируем)
- 2020–2021: дешёвые деньги → мегараунды, гонка оценок, “growth at all costs”
- 2022→ now: разворот к эффективности и юнит‑экономике: burn, выручка, маржа, путь к прибыльности снова стали "first-class metrics"
- 2023→ now: AI‑волна усилила запрос на реальные рвы (данные, модели, доступ к compute) и честный GTM (go-to-markt), а не просто красивую историю
Какие вопросы можно задать себе как руководителю
- Какой секрет мы видим в нашем продукте?
- Где наш потенциальный 10x?
- Почему нас сложно скопировать - и как мы доставим ценность пользователю?
#Startup #Management #Leadership #Economics #Engineering
Прочитал интересную книгу Питера Тиля, со-основателя PayPal и Palantir, еще 2014 года, которая является конспектом его курса в Stanford, который он читал за пару лет до этого. В этом курсе Питер обсуждал не рецепты успеха, а говорил про сдвиг мышления: как из технологии сделать новую категорию, а не ещё один продукт, что будет чуть лучше, чем у конкурентов.
В 2010 году эта книга пришлась ко двору во время бума венчура и стартап‑культуры - всем хотелось поймать "следующего единорога", а книга требовала делать наоборот: искать уникальность и строить защитный ров вокруг своей идеи. В книге было много ярких формулировок, например, вокруг того, что "конкуренция - это для лузеров", а это привело к тому, что они стали вирусными и разошлись на цитаты. В общем, с точки зрения маркетинга идей книга была хороша. С тех пор многое поменялось, но ее до сих пор полезно прочесть и подумать над идеями вроде
1️⃣ Идея "0→1 vs 1→n"
Вообще, название книги противопоставляет идею создания чего-то нового с нуля (0→1) и идею дальнейшего масштабирования и улучшения (1→n). По мнению Питера ценность часто в 10x скачке за счет архитектуры, алгоритмов, UX, стоимости или надёжности и т.д., а не в бесконечной полировке продукта
2️⃣ Идея секретов
Эта идея крутится вокруг важной истины в вашей области, что неочевидна большинству. Собственно, это очень напоминает мышление from the first principles, когда можно взглянуть на ситуацию не через стереотипы, а шире и найти нестандартное решение
3️⃣ Про пользу монополий по сравнению с идеальной конкуренцией
У Тиля очень нестандартный взгляд на монополии и кокуренцию. Я думаю, что это особенность позиции большого капиталиста, но он говорит про творческое преимущество, а не про возможность задушить рынок. Для него монополия - это идея вокруг того, а почему вас сложно повторить (данные, интеграции, сеть, стандарты, бренд, скорость поставки).
4️⃣ Про важность дистрибуции
У Тиля это часть системы - можно собрать идеальный движок, но без канала доставки ценности он не станет продуктом. Но про остальные процессы для рабочего продукта он почти не говорит.
Если посмотреть, а как менялись подходы к венчуру после выхода книги, то получим примерно такой таймлайн
- 2014–2019: Lean/MVP + рост → затем мода на blitz scaling (захватим рынок, потом оптимизируем)
- 2020–2021: дешёвые деньги → мегараунды, гонка оценок, “growth at all costs”
- 2022→ now: разворот к эффективности и юнит‑экономике: burn, выручка, маржа, путь к прибыльности снова стали "first-class metrics"
- 2023→ now: AI‑волна усилила запрос на реальные рвы (данные, модели, доступ к compute) и честный GTM (go-to-markt), а не просто красивую историю
Какие вопросы можно задать себе как руководителю
- Какой секрет мы видим в нашем продукте?
- Где наш потенциальный 10x?
- Почему нас сложно скопировать - и как мы доставим ценность пользователю?
#Startup #Management #Leadership #Economics #Engineering
👍11❤6🔥1
Science Museum (Рубрика #Travel)
Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми.
#Science #Museum #ForKids #ForParents #Culture
Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми.
#Science #Museum #ForKids #ForParents #Culture
🔥16❤8👍4