💡 Отток клиентов (customer churn rate) — показатель количества клиентов, которые бизнес теряет за данный период времени, обычно месяц или год. Измеряется в процентах.

Важен для бизнесов с подписочной моделью: SaaS (sofware as a service), телекомов (операторы сотовой связи и интернет-провайдеры), стримингов.

🎯 Чем выше отток, тем хуже продукт или услуга решают задачу пользователей и соответствуют их ожиданиям.

🤔 Churn может мяняться и под влиянием внешних обстоятельств: кризисов, войн и т.п.

Не путайте customer churn с revenue churn, оттоком выручки.

🔍 Представьте, что оператор сотовой связи обслуживает 1,000 клиентов зарабатывает 1,000,000 руб в месяц.

Каждый месяц он теряет 1% клиентов, то есть 10 человек.

Отток выручки составляет 15,000 руб против ожидаемых 10,000 руб (10 x 1,000 руб в среднем на клиента).

Такое возможно, если некоторые из клиентов переключаются на более дешёвые тарифы, например.

🔗 https://ru.wikipedia.org/wiki/Отток_клиентов

🌍 REST API (Representational State Transfer) — это способ построения API для веб-сервисов.

Обычно работает поверх протокола HTTP и использует методы GET, POST, PUT и DELETE для выполнения CRUD-операций над ресурсами.

Важные свойства REST:

1️⃣ отсутствие состояния (stateless) — ни сервер, ни клиент не обязаны знать о прежних запросах.

2️⃣ операции над ресурсами, а не выполнение команд — в этом отличие от RPC-протоколов.

REST API — это один из способов сделать API на основе HTTP с использованием JSON.

🧐 Вокруг этих терминов часто возникает путаница: не каждый веб-сервис с HTTP API является RESTful, а REST API не обязан исползовать HTTP для транспорта или JSON для сериализации данных.

📖 Например, так может выглядеть ответ на запрос GET /users/1

{
  "links": {
    "self": "http://api.app.com/users/1",
    "friends": "http://api.app.com/users/1/friends"
  },
  "data": {
    "id": "1",
    "type": "user",
    "attributes": {
      "name": "Oleg Gromov"
    }
  }
}

🔗 https://ru.wikipedia.org/wiki/REST

🔍 HATEOAS (Hypermedia as the Engine of Application State) — это одно из важных ограничений RESTful архитектуры.

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

🏆 По сути, это адаптация идеи WWW для HTTP API.

Как пользователь открывает страницу и дальше переходит по ссылкам, так и API-клиент может узнавать о возможностях cервера прямо из его ответов, а не хардкодить урлы его "ручек".

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

👎 Минусы: ограничение достаточно абстрактное и теоретическое, его сложно встретить в "дикой природе" и ещё сложнее правильно реализовать.

Обычному веб-приложению совсем не нужны эти премудрости, т.к. несмотря на деление на клиент-сервер, оно развивается и обновляется как монолит.

📚 Например, HATEOAS используется в REST API системы управления задачами Genie от Netflix 👇

🔗 https://netflix.github.io/genie/docs/3.0.0/rest/#_hateoas_links_4

🚩 Мемоизация (memoization) — это ускорение долгой функции, которая вызывается несколько раз, c помощью кэширования результатов.

Часто используется вместе с рекурсией.

Для мемоизации обычно используется cловарь, где ключом являются параметры фукнкции, а значением — её результат.

✅ Плюсы: ускорение выполнения за счёт уменьшения количества повторных вычислений.

⛔️ Минусы: увеличение потребления памяти из-за хранения промежуточных результатов.

Даёт ускорение только при наличии частых повторных вычислений, иначе может просто сожрать память.

📚 Например, запустите эту программу на python и сравните количество вызовов fib_memo с fib.

def fib(n):
  if n <= 1:
    return n
  print(n)
  return fib(n-1) + fib(n-2)

def fib_memo(n, memo):
  if n in memo:
    return memo[n]
  if n <= 1:
      return n
  print(n)
  memo[n] = fib_memo(n-1, memo) + fib_memo(n-2, memo)
  return memo[n]

print('memoized: %d' % fib_memo(10, {}))
print('recursive: %d' % fib(10))

🔗 https://ru.wikipedia.org/wiki/Мемоизация

Пятница-пятница. А вы деплоили сегодня? 😁

⭐ Сине-зелёные деплои (blue-green depoyments) — это метод развёртывания приложений без даунтайма (downtime, простой).

Есть 2 идентичные среды: "синяя" и "зелёная". "Синяя" обслуживает пользователей, а "зелёная" используется для развертывания и тестирования новой версии.

Если релиз успешный, трафик переключается с синего на зелёное окружение, а они меняются местами.

🔥 Плюсы: деплои проходят без простоя (zero-downtime deployment), можно быстро откатить релиз.

😢 Минусы: требует работы двух идентичных сред, а это накладно для сложных приложений. Нужен reverse-proxy или load balancer для роутинга трафика.

📚 Скажем, вы выкатываете новый бэкенд сервиса такси.

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

Пользователи не замечают деплоя и плавно "перетекают" из одной копии в другую благодаря использованию reverse-proxy, например, traefik или haproxy.

🔗 https://yandex.cloud/ru/docs/tutorials/web/blue-green-canary-deployment

👍 COALESCE() — это SQL-функция, которая возвращает первое не-NULL значение из списка аргументов.

🤗 Её полезно использовать при работе с данными, где могут встречаться NULL.

📚 Например, есть таблица с заказами, и вы хотите посчитать стоимость каждого заказа.

При этом NULL и 0 в колонке tax отличаются: при NULL вам не нужно подавать отчёт по НДС, а при 0 всё равно нужно.

| order_id | subtotal | tax    |
|----------|----------|--------|
| 201      | 120.00   | NULL   |
| 202      | 45.75    | 3.50   |
| 203      | 89.99    | NULL   |
| 204      | 150.00   | 12.00  |

Наивный запрос вернёт неправильные значения total для tax = NULL.

SELECT 
  order_id, 
  subtotal + tax AS total 
FROM orders;

Чтобы получить правильные результаты, используйте COALESCE:

SELECT 
  order_id, 
  subtotal + COALESCE(tax, 0) AS total
FROM orders;

🔗 https://ru.wikipedia.org/wiki/NULL_(SQL)#Операции_с_NULL

👍 git bisect — это способ найти коммит с ошибкой в git-репозитории.

👌 Он ускоряет процесс перебора благодаря использованию бинарного поиска, а также автоматически переключается между коммитами.

Особенно полезен в больших проектах и при работе с чужим кодом, когда искать ошибку вручную будет очень долго.

🔍 Например, вы знаете, что в текущем HEAD-коммите баг есть, а в версии 3.5 его не было.

git bisect start
git bisect bad
git bisect good v3.5

Потом, на каждом шаге, проверяйте наличие бага в данной версии и используйте git bisect good или git bisect bad.

✋ Остановить процесс в любой момент поможет git bisect reset.

🔗 https://git-scm.com/book/ru/v2/Инструменты-Git-Обнаружение-ошибок-с-помощью-Git#r_binary_search

🚩 Xerox Alto — это первый компьютер, который предложил пользователям графический интерфейс.

Он произвёл настоящую революцию: вместе с GUI (graphic user interface) появилась концепция окон и пиктограмм (иконок), с которыми можно взаимодействовать с помощью мышки.

Его разработали в 1973 году в исследовательском центре Xerox PARC, а одним из главных разработчиков был Alan Key (снова он!).

В момент выхода на рынок компьютер стоил от $32,000, что в те годы было относительно невысокой ценой для персонального компьютера — размером с комод, на минуточку.

P.S. Любопытно, что Xerox произносится по-английски "зиракс", с ударением на первый слог, а вовсе не "ксерокс" 🤪

🔗 https://www.youtube.com/watch?v=M0zgj2p7Ww4

😃 Посты прошедшей недели:

- Бас-фактор
- OAuth2
- Рекурсия
- Code smell
- LTV
- Churn rate
- REST API
- HATEOAS в REST
- Мемоизация
- Сине-зелёные деплои
- COALESCE() в SQL
- git bisect
- Xerox Alto

🔥 Какой пост был круче всего?

Спагетти-кодом называют плохо структурированный код, в котором сложно проследить порядок исполнения, взаимосвязи, отделить важное от неважного.

У него есть множество разных признаков:

1️⃣ перемешаны бизнес-логика и представление, "чистая" и императивная часть

2️⃣ взаимозависимость компонентов: всё зависит от всего, нет явной иерархии и слоёв

3️⃣ нарушена инкапсуляция, отсутствуют или неправильно созданы абстракции (типичный PHP)

4️⃣ состояние разбросано по всей программе, не получается изолировать разные компоненты

5️⃣ глубоко вложенные условия, циклы, callback-функции (классический jQuery)

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

📝 Например, вот кусочек jQuery-кода, который подходит под описание спагетти-кода.

Или вот чей-то кусок кода для Wordpress, который выводит комментарии к посту.

Общее у них то, что ничего невозможно понять 💩 Не пишите так.

🔗 https://ru.wikipedia.org/wiki/Спагетти-код

Amazon S3 (Simple Storage Service) — сервис хранения "объектов".

В отличие от файлов в иерархической файловой системе, объекты хранятся в key-value хранилище с определённым именем (bucket).

В нём нет каталогов, а "пути" являются частью ключа-строки.

🤌 Объекты нельзя модифицировать, только заменить новой копией. Например, не получится открыть текстовый файл и изменить в нём один символ.

S3 является де-факто стандартом для хранения разной статики: видео, фото, аудио, бэкапов. Его API также поддерживается большинством аналогов.

❤️ Плюсы: надёжность, практически бесконечная масштабируемость.

⛔️ Минусы: S3 может оказаться очень дорогим для хранения данных большого объёма, особенно при неверном исплоьзовании. Зависимость (вендор-лок) от AWS.

Чтобы сэкономить, рассмотрите более "холодные" классы хранения (storage classes), а также взгляните на Backblaze B2.

Используйте CDN, например, Cloudfront или Cloudflare, чтобы уменьшить egress fees.

🔗 https://yandex.cloud/ru/docs/storage/s3/api-ref/

CORS (Cross-Origin Resource Sharing) — это способ ограничения доступа к ресурсам веб-сервера (картинкам и пр.).

Включает в себя набор HTTP-заголовков, которые можно использовать в ответе, например:

• Access-Control-Allow-Origin для указания разрешённого домена
• Access-Control-Allow-Methods для разрешённых HTTP-методов

📌 Только современные браузеры учитывают CORS-ограничения.

CORS нужен, чтобы разрешить кросс-доменные XHR-запросы, например, в API, а также ограничить нагрузку на сервер.

🧐 Не путайте CORS и CSP, Content Security Policy, которые используется для ограничения со стороны страницы (см. следующий пост).

📚 Например, вы делаете редактор мемов и загружаете картинку https://i.chzbgr.com/full/9699850496/h4640AF11 через XHR, чтобы вставить в canvas.

Браузер делает запрос, и получает следующий заголовок в ответе:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: i.chzbgr.com

У вашего сайта другой домен, поэтому картника не загрузится.

🔗 https://ru.wikipedia.org/wiki/Cross-origin_resource_sharing

CSP (Content Security Policy) — это способ разрешить странице загружать только определённые ресурсы.

Ограничения выставляются через HTTP-заголовок Content-Security-Policy или meta-теги.

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

✨ Так же, как и CORS, CSP учитываются только современными браузерами.

🤔 Но, в отличие от CORS, CSP-ограничения работают наоборот: они указываются для страницы, а не ресурса.

📚 Скажем, вы работаете над новостным сайтом, и сейчас все его страницы отдаются со следующим заголовком:

Вы хотите начать показывать рекламу Яндекса, которая грузится с an.yandex.ru, поэтому вам нужно обновить заголовок:

⚠️ Лучше явно указывать директивы script-src, style-src, img-src и подобные вместо default-src.

🔗 https://developer.mozilla.org/ru/docs/Web/HTTP/CSP

CAC (Customer Acquisition Cost) — стоимость привлечения клиента.

Расчитывается по формуле: CAC = затраты на маркетинг и продажи / кол-во привлечённых клиентов.

🧩 Используется при планировании и анализе маркетинговых кампаний, в юнит-экономике.

Также полезно держать в уме CAC при планировании cтоимости сетки продуктов.

Для стартапов важно отношение CAC:LTV (life-time value, сколько денег принесёт клиент компании за всё время) — чем оно меньше, тем лучше.

Если CAC > LTV, то юнит-экономика не сходится, а значит бизнес нестабилен, не может расти и, скорее всего, долго не протянет.

🔍 Допустим, SaaS-компания тратит в месяц на маркетинг и отдел продаж $50,000.

В среднем ей удаётся привлекать 200 новых клиентов в месяц, то есть:

CAC = $50,000 / 200 = $250

Если при этом средний чек cоставляет $1000, то у компании всё в порядке.

Если же они продают B2C продукт со стоимостью подписки в $10, то всё очень плохо ☠️

🔗 https://en.wikipedia.org/wiki/Customer_acquisition_cost

А еще есть программисты, которые не используют copilot!

Ретеншн (retention, удержание клиентов) — это способность компании сохранять клиентов на протяжении определённого времени.

🎯 Удержание клиентов важно в отраслях, где существуют повторные продажи или продают подписки.

Retention — показатель, обратный churn, оттоку клиентов. Если компания теряет в месяц 10% клиентов (сhurn), то её retention составляет 90%.

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

🤷‍♀️ Не путайте retention с NPS (net promoter score — вероятность, что клиент будет рассказывать про ваш продукт).

📝 Например, в компании, продающей онлайн-курсы считают retention по когортам:

| Когорта | Янв | Фев | Мар |
|---------|-----|-----|-----|
| Январь  | 100 | 80  | 70  |
| Февраль | 120 | 90  | 70  |

Видно, что январская когорта более лояльна компании, чем февральская: в ней 70% пользователей остались после 3 месяцев (а не 58%).

🔗 https://ru.wikipedia.org/wiki/Удержание_клиентов

Canary — это способ выкатки новых версий ПО только для маленькой части пользователей.

Название, вероятно, происходит от использования канареек в угольных шахтах. Так делали, чтобы безопасно (для людей) обнаружить угарный газ.

🔥 Canary-релизы помогают получить быструю обратную связь и уменьшают цену ошибки.

Пользователи, которые получат canary-версию, могут выбираться с помощью:

🦜 фича-флагов (feature flag)
🦅 ID, тарифа, геолокации и т.д.
🦩 сервера, на котором находится их сессия

💔 Минусы: сложность инфраструктуры и настройки, мониторинга результатов. Можно поломать привычный UX.

🔍 Представьте, что вы работаете в команде Google Chrome.

Ваша фича попадает в релизную ветку и следующей ночью оказывается в Canary-cборке.

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

Примерно через месяц ваша фича выкатывается в следующей стабильной версии и становится доступна всем.

🔗 https://yandex.cloud/ru/docs/api-gateway/concepts/extensions/canary

RPC (remote procedure call, удалённый вызов процедур) — это способ клиент-серверного взаимодействия, при котором клиент отправляет команды серверу и получает их результаты.

Может работать поверх HTTP, HTTP/2, TCP или UDP. Самые известные реализации RPC: XML-RPC, JSON-RPC, gRPC, Apache Thrift и его форк fbthrift, trpc.

Запросы и ответы сериализуются в текстовые (JSON, XML) или бинарные форматы (protobuf).

🏆 Плюсы: более гибкий в отличие от, например, REST, который оперирует "ресурсами" и строго привязан с CRUD-cемантике.

⚠️ Минусы: сильная взаимная зависимость клиента и сервера.

🔍 Например, используем OpenWeatherMap API, выполненному в виде JSON-RPC:

curl https://api.openweathermap.org/data/3.0/onecall/overview?lon=-11.8092&lat=51.509865&appid={key}

И получаем ответ:

{
   "lat": 51.509865,
   "lon": -0.118092,
   "tz": "+01:00",
   "date": "2024-05-13",
   "units": "metric",
   "weather_overview": "The current weather is overcast..."
}

🔗 https://ru.wikipedia.org/wiki/Удалённый_вызов_процедур

iCalendar — стандартизированный в RFC 5545 формат описания календарных данных:

📅 встречи и их настройки
📝 задачи
🔔 напоминания
🌴 выходные, отпуска и т.п.

Это текстовый формат, который используется в Google и Apple Calendar, MS Outlook, для импорта/экспорта и обмена календрными событиями, а также в их API.

📝 К примеру, так задаётся день рождения одного из моих друзей:

BEGIN:VEVENT
DTSTART;TZID=Europe/London:20240602T080000
DTEND;TZID=Europe/London:20240602T090000
RRULE:FREQ=YEARLY
DTSTAMP:20240901T133201Z
UID:[email protected]
CREATED:20240602T195932Z
LAST-MODIFIED:20240602T195932Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:День рождения друга
TRANSP:OPAQUE
END:VEVENT

Обратите внимание на RRULE, который задаёт частоту повторения.

Кроме RRULE есть также RDATE для указания списка дат, а таже EXRULE и EXDATE для задания исключений.

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

🔗 https://datatracker.ietf.org/doc/html/rfc5545