Прокси-серве для Яндекс.Музыки

Прошлой весной начал разбираться с OpenAPI и решил написать схему для Яндекс.Музыки. Проблема была лишь в том, что из-за CORS нормально пользоваться сгенерированной документацией невозможно. Чтобы отключить CORS в хроме приходилось запускать его с флагом -disable-web-security.

Решение скажем честно - не очень 👎. Правильным решением будет написание прокси-сервера, на котором были бы разрешены кросдоменные запросы. Другими словами, вместо того, чтобы напрямую обращаться к серверу Я.Музыки, на котором запрещены крос-доменные запросы, мы обращаемся к прокси-серверу, который перенапрявляет все наши вопросы к Я.Музыке и возвращает нам ответ. Так как CORS, есть только в браузере, то мы свободно отправляем запросы с нашего прокси сервера на сервер Я.Музыки.

Собственно, вчера я и написал такой прокси-сервер на основе библиотеки cors-anywhere и захостить его на хероку (https://yandex-music-cors-proxy.herokuapp.com/).

Теперь все запросы можно проксировать следующим образом: https://yandex-music-cors-proxy.herokyapp.com/<any-url>

Например: https://yandex-music-cors-proxy.herokuapp.com/https://api.music.yandex.net:443/users/541320800/playlists/list

Ресурсы:

- Исходники прокси сервера
- Исходники OpenAPI-схемы Я.Музыки
- OpenAPI документация Я.Музыки

Ещё по теме:

- cors-anywere
- Getting Started on Heroku with Node.js
- GitHub Integration (Heroku GitHub Deploys)

#yandexmusic

Пятничное чтиво

Сегодня порекомендую всего одну статью. Она мне напоминает меня самого, ведь я допускал и возможно всё ещё допускаю те же ошибки. Я довольно часто отчаянно отстаивал свою позицию (даже в не значимых моментах) и считал, что это нормально. Представьте моё удивление, когда я узнал, что мои коллеги считают меня агрессивным 😅.

Как меня чуть не уволили из-за токсичного поведения и что было дальше

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

#fridayreading #article

Почему CSS называется каскадными таблицами стилей?

Каскад — это алгоритм, который определяет, как вычислить результирующие стили элементов на основе CSS правил, объявленных в различных источниках.

CSS правила могут быть объявлены в следующих источниках:
- User-agent stylesheets (Браузерные стили) - дефолтные стили браузера, обычно мы сбрасываем их с помощью CSS Reset
- Author stylesheets (Авторские стили) - Стили задаваемые разработчиками, именно эти стили и пишем мы с вами.
- User stylesheets (Пользовательские) - стили, которые могут применять к нашему сайту обычные пользователи. Возможно когда-то, вы видели, как кто-то использует их, чтобы задать кастомный вид для ВК.

То есть, для применения стилей, браузеру необходимо знать не только специфичность правила, но и источник этих правил, ведь у них тоже есть свой приоритет:
1. Авторские/Правила разработчиков - самый приоритетный
2. Пользовательские
3. Браузерные стили

При применении !important всё становится с ног на голову и приоритеты меняются следующим образом:

1. Браузерные стили с !important - самый приоритетный
2. Пользовательские с !important
3. Авторские/Правила разработчиков !important

Таким образом, алгоритм каскада выглядит вот так:
1. Найти стили из различных ресурсов, которые применимы к данному элементу
2. Выбрать источник с наибольшим приоритетом (важен именно приоритет источника, специфичность всё ещё не учитывается)
3. В ход идёт алгоритм специфичности, чтобы выбрать свойство с наибольшим весом
4. Если специфичность нескольких правил равна, в результате берётся то значение, которое объявлено позже

Вывод
Для понимания тема кажется полезной, но на практике ваши стили всегда будут перебивать браузерные стили, а пользовательские стили поддерживаются всё меньше:
- Поддержка в хроме удалена в 2013 году
- В Firefox поддержка по-умолчанию выключена

Примеры
- CSS Cascading and Inheritance Level 4 - Example 18
- Introducing the CSS Cascade - Example

Ещё по теме
- Дока - принцип каскада
- Дока - специфичность
- MDN - Introducing the CSS Cascade
- CSS Cascading and Inheritance Level 4
- CSS Reset в 2021

#css #web

Настройка VPN

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

Есть вероятность, что и наше правительство начнёт "замедлять" и блокировать сайты/приложения, где может размещаться "нежелательная" на их взгляд информация:
- Instagram
- Facebook
- Twitter
- YouTube

Поэтому самое время настроить VPN (напрмер, pshiphon) или установить TorBrowser.

Mock-функции в Jest

В Jest существует 3 основные функции для подмены (мока) реализации:
- jest.fn() - mock function
- jest.spyOn().mock<...> - mock/spy function
- mockResolvedValue()
- mockReturnValue()
- mockImplementation()
- jest.mock() - mock module

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

jest.fn() - самый простой способ создать mock-функцию. Функция используется в следующих случаях:
- Тестируемая функция принимает в качестве аргумента другую функцию, которую мы можем подменить с помощью jest.fn() - Dependency Injection
- Нам не важна предыдущая реализация и мы можем просто заменить её следующим образом obj.func = jest.fn().

jest.spyOn() заменяет начальную реализацию шпионом, что позволяет нам отслеживать вызовы функции. При этом, по умолчанию реализация не изменяется, если необходимо изменить реализацию, это можно сделать следующим образом: spyOn(obj, ‘func’).mockImplementation(() => “mocked value”). Функция используется в следующих случаях:
- Необходимо отслеживать вызовы функции без подмены реализации
- Необходимо подменить зависимость, которая используется внутри тестируемой функции и не передаётся в качестве параметров
- Необходимо подменить реализацию для отдельного теста/группы тестов и восстановить оригинальную реализацию для остальных mockedFunc.mockRestore
Why use spyon with mock implemenation rather than jest.fn? - хороший пример, описывающий ситуацию, в которой лучше использовать jest.spyOn() вместо jest.fn()

jest.mock(). В отличие от функций jest.fn() и jest.spyOn(), функция jest.mock() - заменяет не отдельную функцию, а весь модуль. Функция используется в следующих случаях:
- Необходимо подменить все экспортируемые функции модуля
- Необходимо подменить часть экспортируемых функций модуля
Недостаток функции jest.mock в том, что она не позволяет восстановить оригинальную реализацию, для таких случаев лучше использовать jest.spyOn

Ещё по теме
- Understanding Jest Mocks - подробно описывает каждую рассмотренную функцию с примерами
- Mock Functions и ES6 Class Mocks - официальная документация jest

#frontend #tests #jest

Управление техническим долгом

На прошлой неделе задал вопрос об управлении техническим долгом Василию Половнёву - Техническому директору в Бюро Горбунова.

Подскажи, как вы управляете техническим долгом и задачами, которые не связаны с разработкой продукта (обновление пакетных менеджеров (yarn 1 => pnpm), написание документации для старого кода, ...) в Бюро?

👉 Во-первых, мы на одной волне с бизнесом в этом вопросе: и мы, и ребята договорились о том, что техдолг — это плохо, это не дает нам запускать новые фичи быстрее. Если этот вопрос не решен, лучше начать с него. Иначе бизнесу будет казаться, что вы тратите время на какую-то фигню.
👉 Во-вторых, весь технический долг мы аккуратно записываем и периодически пересматриваем. Часто бывает, что какой-то должок вообще не нужно отдавать. А что-то вдруг начинает гореть прямо сейчас.
👉 В-третьих, мы берем продуктовый налог: 10-20% времени и внимания в итерации тратим на рефакторинг. Получается непрерывный рефакторинг в рамках итерации.
👉 В-четвертых, у нас есть неделя после пуска. Это отдельная неделя сразу после пуска крупной (шестинедельной) фичи, которая тратится только на рефакторинг, доработки и горячие исправления. Эта неделя помогает выдохнуть, трезво оценить обстановку и заняться техдолгом. В Бейскемпе эта же штука занимает две недели между циклами.

А куда вы записываете тех долг, это тот же самый таск трекер, в котором ведутся обычные продуктовые задачи?

👉 Да, это все в github issues.

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

👉 Да, именно.

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

#planning #technicaldebt

Пятничное чтиво

Сегодня порекомендую доклад Алексея Катаева Рефакторинг: договариваемся, планируем, внедряем! Расшифровку можно почитать здесь.

Основные моменты:
- Если у вас есть желание переписать всё с нуля, значит вы всё время добавляли новые и новые костыли и не рефакторили
- Если в команде отсутствует культура рефакторинга:
- скорость разработки замедляется
- стабильность будет падать
- сложнее набирать новых разработчиков, ведь легаси дофига, а документации нифига
- как результат ⇒ бизнес теряет деньги
- Необходимо проводить непрерывный рефакторинг
- Чтобы убедить руководство в необходимости рефакторинга, необходимо договариваться, а не жаловаться. Нужны конкретные предложения вместо нытья
- Определять фронт работ (список областей для рефакторинга) должны все разработчики, а не только тимлид, ведь он наверняка не в курсе всех проблем в коде.
- С чего начать? Наверняка у каждого разработчика есть код, который он ненавидит всей душой, ведь после каждого изменения в этом коде он получает 5 новых багов. Можно начать с рефакторинга этих областей.
- Вести “Рефакторинг задачи” можно в вашем привычном таск трекере.
- “Рефакторинг задачи” должны описываться по определённому формату:
- Проблема
- Профит
- Возможное решение
- Оценка по срокам
- Что с приоритетом? Как уже было сказано, разработчики лучше других знают приоритет, они и должны его выставлять.
- Выделить бюджет для рефакторинга, например 15% от времени спринта.
- Чтобы уменьшить количество нового технического долга, необходимо:
- Заниматься ростом команды
- Шарить знания по проекту
- По прошествии какого-то времени можно будет оценить количество технического долга и его рост.

#fridayreading #technicaldebt #planning #processes

Пятничное чтиво - Interaction tests

Недавно команда storybook добавила новую фичу - Interaction tests, поэтому в эту пятницу хочу порекомендовать к прочтению статью Test component interactions with Storybook, которая очень хорошо показывает преимущества по сравнению с jest тестами.

Немного проанализировав, для себя я смог выделить следующие преимущества и недостатки.

Преимущества:
✅  Интерактивные тесты запускаются в реальном браузере и в связи с этим не имеют тех ограничений, которые имеет JSDOM. Поэтому, например, мы можем проверять размеры элементов и их расположение относительно друг друга.
✅  Проще отлаживать тесты компонентов в браузере чем в консоли, ведь мы своими глазами видим причину падения тестов. Особенно это упрощает жизнь, если у вас есть мигающие тесты, падающие время от времени.
✅  Наличие фичи пошаговой отладки, позволяет пошагово отлаживать тесты прямо в браузере без использования dev tools.

Недостатки:
⚠️  Для запуска интерактивных тестов используется playwright. Michael Shilman (член команды storybook) утверждает, что в настоящее время playwright тесты занимают в среднем на 30% больше времени, чем jest тесты. В то же время, команда storybook работает над разработкой своего собственного тест-раннера и считает, что сможет добиться скорости выполнения тестов сравнимой с JSDOM.
⚠️ Тест-раннер работает только с запущенной версией storybook, поэтому помимо запуска тестов необходимо предварительно запустить storybook. Если storybook ещё не включен в ваш CI/CD pipeline — это также увеличит время работы pipeline’а.
⚠️ Storybook позволяет мокать API запросы, но в целом всё ещё в значительной степени уступает jest. Например, вы не сможете замокать код только для выбранных историй, или мокать код индивидуально для каждой выбранной истории.
⚠️ В данный момент интерактивные тесты не поддерживают test coverage.

Напоследок, хотел бы отметить два момента:
⚫️ Интерактивные тесты, не являются полной заменой jest - они предназначены лишь для тестирования компонентов и не подходит, например, для тестирования утилитных функций.
⚫️ Все перечисленные недостатки скорее всего будут со временем решены, так как релиз фичи состоялся не так давно, и команда storybook работает над её улучшением.

#fridayreading #tests #storybook

Фраза недели

Недавно посмотрел видео “Причина грыжи диска. Плавание и позвоночник.”, в котором была сказана очень интересная фраза:

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

Невероятное сходство можно проследить с процессами в команде или компании. Достаточно заменить, например “нагрузку” на “оценку работы” и “организм” на “процессы” — «Однобокая оценка работы всегда будет вызывать перестройку процессов в определённых местах, чтобы сотрудники, жертвуя чем-то, добивались поставленных целей.».

Если в качестве метрик используется только количество закрытых задач и сделанных фич, то многие процессы в компании подстроятся, чтобы добиться необходимых результатов. Но придётся чем-то жертвовать:
● Будет меньше времени уделяться тестированию и написанию тестов
● На смену CodeReview придёт простое нажатие кнопки Approve или вовсе отмена обязательного ревью
● Будут исправляться симптомы, а не проблемы. Вряд ли кто-то будет докапываться до сути проблем, возникающих в продукте, поэтому будут появляться все новые и новые костыли
● Сотрудники перестанут помогать друг другу, ведь нужно закрыть как можно задач!

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

#weekphrase #processes

​​📖 Пятничное чтиво

В статье "Как быть более продуктивным, не заставляя себя" есть следующая фраза

Есть группа людей, которые работают и получают от своей работы удовольствие. Давайте назовем этих людей *деятелями*. Под этим понятием мы не имеем в виду трудоголиков, которые не живут, а лишь работают целыми днями. У деятелей здоровый баланс работы и отдыха. Что же особенного есть у них, чего нет у тех, кто ненавидит свою работу?

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

Для них работа — это приятный цикл позитивной обратной связи. Деятели воспринимают работу как источник энергии и удовлетворения. С их точки зрения, работа позволяет им по-настоящему насладиться заслуженным отдыхом. Отдых делает их счастливее и мотивирует затем снова заняться работой.

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

А это на прошлой неделе я был в Нижнем Новгороде, а сейчас замотивированный уже работаю.

#fridayreading

​​Интеграция Notion и Apple Shortcuts

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

Например, пришла вам какая-то крутая идея — нужно её записать как можно скорее. Если процесс наполнения инбокса не прост как дважды два, вы просто забудете, что хотели записать.

Сегодня настроил интеграцию Apple Shortcuts и Notion. Так как Siri поддерживает шорткаты, то заметки и задачи можно добавлять в ваш инбокс просто диктуя их Siri.

- Using Siri to add to a Notion Database - Tutorial - Инструкция на Youtube
- Siri → Notion Database Tutorial - Инструкция в Notion

#planning #notion #timemanagement

Автоматизированные бэкапы в Notion

В конце апреля начали появляться сообщения, что некоторые русские аккаунты в Notion были заблокированы. Поддержка сперва подтвердила это, но в итоге сослалась на то, что они тестировали новый алгоритм и случайно заблокировали аккаунты, мол сейчас всё должно быть хорошо - продолжайте пользоваться. Но как тут спокойно пользовать после такого, сразу вспоминается фраза “мыши плакали, кололись, но продолжали жрать кактус”. Поэтому я решил настроить автоматизированные бэкапы.

Для этого можно использовать:
- GitLab
- GitHub

Обе реализации используют один и тот же подход:
1. Для скачивания архива (тот же самый архив, который мы получаем при ручном экспорте вокспейса) используется внутренний API Notion
2. Для хранения бэкапов используется GitLab/GitHub репозиторий
3. Скачанный архив разархивируется и пушится в репозиторий
4. Для запуска бэкапа используется GitLab Pipeline/GitHub Actions

Я решил использовать GitHub. У меня много страниц с очень длинными названиями поэтому пайплайн валится при разархивировании. Я не стал заморачиваться и просто удалил разархивирование из пайплайна. Для меня это не так важно, ведь в любом случае ссылка на скачивание приходит на почту и хранится в течение 30 дней, поэтому если Notion заблокируют, я в любом случае смогу скачать бэкап.

#notion

📖 Пятничное чтиво

Как жалобы перенастраивают ваш мозг на негатив

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

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

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

#fridayreading #нытьё

WAI-ARIA Authoring Practices перенесли сюда и обновили дизайн - не теряйте!

#frontend #accessibility

🎥 Пятничное чтиво

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

Пару месяцев назад посмотрел сериал Выбывшая. Рекомендую посмотреть, чтобы понять, как начинаются стартапы, и на что приходится идти чтобы они не потонули. Правда в этом случае, основатели зашли слишком далеко. Фильм основан на реальных событиях.

#fridayreading

Это будет моя самая короткая статья.

Когда-то я был молод и зелен и решал проблемы именно так, как их решают джуны. Алгоритм такой:

1. Узнать о проблеме
2. Локализовать проблему
3. Загуглить проблему и решение
4. Пофиксить проблему

Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открывал файл, редактировал проблемную строчку, закрывал файл. Проблема решена.

Или другой пример: не отработал скрипт из-за ошибки в коде. Чиню ошибку, скрипт начинает работать.

Прошло 10 лет... Алгоритм претерпел изменения:

1. Узнать о проблеме
2. Локализовать проблему
3. Загуглить проблему и посмотреть много решений
4. Понять, почему это произошло
5. Понять, что нужно сделать, чтобы это не произошло снова
6. Понять, что ещё затронуто проблемой
7. Понять, где ещё потенциально могут возникнуть похожие проблемы
8. Пофиксить проблему
9. В зависимости от количества необходимых усилий, пофиксить всё сопутствующее
10. Рассказать пацанам в слаке про свой фейл (== поделиться опытом)

Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открываю файл, разбираюсь, как проблемная строчка попала в него, пытаюсь сделать, чтобы она туда больше не попадала, ищу такие же ошибочные строчки в файле, ищу другие потенциальные ошибки, чиню файл сам или заворачиваю на доработку. Проблема решена - либо полностью, либо частично, но с полным осознанием это факта.

Или другой пример: не отработал скрипт из-за ошибки в коде. Разбираюсь, кто написал скрипт, почему писал ручками вместо того, чтобы вызвать какую-то команду для настройки и деплоя, где ещё подобные ошибки могут быть (и в этом проекте, и в проектах других клиентов), чиню и делаю всё возможное, чтобы это не произошло опять.

К чему всё это
Пожалуйста, не решайте конкретную проблему. Это никогда не работает. Оно сломается снова.

Решайте класс проблем. Выходите за рамки проблемы, ищите похожие, ищите связанные. Будьте ответственными и любопытными.

Иначе я так и буду находить XSS в тех же местах, о которых писал ранее.

https://www.youtube.com/watch?v=kD_t1HkK21Y

​​Интеграция Notion и Алисы 💥

В одном из предыдущих постов я писал, как настроить интеграцию между Notion и Apple Shortcuts. Сегодня (дабы поддержать отечественного производителя) расскажу об интеграции Notion и Алисы.

Настраивается всё очень просто — инструкцию можете найти здесь. Если кратко, то процесс интеграции выглядит следующим образом:

- Создаёте новую интеграцию тут и копируете токен
- Копируете идентификатор страницы или базы данных
- Отправляете всё в навык и всё готово

Навык отлично подходит для добавления дел в инбокс. Если вы (как и я) ведёте список дел в базе данных, то при конфигурации укажите её идентификатор, тогда навык будет добавлять новые строки. Если вы укажите идентификатор страницы, то навык будет добавлять новую запись в to-do list.

Если вы хотите поучаствовать в разработке навыка, то вот здесь найдёте исходники навыка. Если у вас есть какие-то предложения по улучшению навыка вступайте вот в этот чат.

#planning #notion #timemanagement #алиса

Обязанности, полномочия, вознаграждение

Не так давно прочитал в книге Ицхака Адизеса «Идеальный руководитель: Почему им нельзя стать и что из этого следует» такой абзац:
«Нельзя рассчитывать на ответственность без соблюдения трех условий: работник знает, в чем состоят его обязанности, обладает достаточными полномочиями, властью и/или влиянием, чтобы их выполнять, и рассчитывает на адекватное вознаграждение после того, как они будут выполнены.»

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

Обязанности
Адизес говорит, что каждый человек должен иметь конкретные и понятные обязанности, чтобы точно знать, что он должен делать, что не должен, где все зависит от него, а где другой человек подхватит.
На практике же бывает, что обязанности могут расплываться со временем. Сегодня Вася делает А, завтра понадобится еще и Б. Сейчас попробуем Васю нагрузить, если будет тащить и не сопротивляться, то теперь и Б – его обязанность. А послезавтра мы даже не будем явно это проговаривать, но понадеемся, что Вася еще и В начнет делать.

Почему? Просто потому что оно где-то рядом, а если Вася уже А и Б делает, то, наверное, и В должен.

В результате ни Вася, ни его товарищи не понимают, кто точно за это В отвечает, а что делать, если Г появится, а почему вообще всё так изменилось? Если это всё явно не проговаривать и не фиксировать, то получится одновременно и слишком много «якобы ответственных» и слишком мало «действительно ответственных».

Полномочия
Ну это прям классика тимлидского жанра и руководителей среднего и низкого уровней.
В типичном случае тебе говорят: «Ты теперь ответственен за процессы, внутреннее устройство и результаты команды». А где-то внизу мелким шрифтом приписка, что фондом оплаты труда ты не владеешь никак, инициировать найм, или увольнение ты не можешь, а весь твой арсенал управления командой строится либо на хорошем профессиональном авторитете, либо как Таракан, Таракан, Тараканище – «он рычит, он кричит, и усами шевелит».

Надо ли объяснять, насколько человек принимает ответственность за то, куда приедет машина, если ему не дали педали и руль?

Вознаграждение
Вознаграждение очень тонкая и дискуссионная тема. Хотел даже написать отдельный пост про плюсы и минусы премий, например. Ну может когда-нибудь и напишу.
А сейчас по теме поста общая идея такая: человек должен понимать, что за труды получит адекватное вознаграждение. «Адекватное» – грубый и упрощенные аналог слова «соразмерное». Если Вася работает с 9 до 6, а Петя с 8 до 20, да еще и в субботу выходит, чтобы выполнить пятилетку за 3 года, но при этом у них одинаковый оклад, то как скоро Петя демотивируется, перестанет выдавать высокий результат, да еще и обидится на всю компанию?

То же самое касается любителей сотрудников с «горящими глазами». Вполне справедливое желание мечтать о таких. Любой каприз за ваши деньги. Только если окажется, что деньги платят без какой-то понятной мотивационной системы, то глупо будет удивляться, что глаза так и не загорелись. А если у кого и загорелись, то со временем потухли.

Итог
На мой взгляд, комбо из понятных обязанностей, необходимых полномочий и адекватного вознаграждения – хорошая система для построения эффективной командной работы.

Ну и в целом хороший повод задуматься: а так ли у вас? А чего вам не хватает? А почему этого не хватает? А что вам мешает это сделать?

Новое свойство Статус в Notion

По многочисленным просьбам Notion добавил новое свойство Status. У него много преимуществ, почитать о них можно вот здесь, в официальной документации Notion, если больше нравится видео формат - то посмотреть можно здесь.

Для своей системы планирования я выделяю 2 главных преимущества:

1. У статуса, есть значение по-умолчанию. Больше не будет задач, у которых пустой статус 🎉
2. Можно легко мигрировать с поля Select, которое часто использовалось в качестве поля Status. Достаточно просто изменить тип поля на Status и он автоматически конвертирует все значения. Ни фильтры, ни доски, после конвертации не пострадают.

Пример конвертации селекта в статус в комментариях.

#notion

Help pick a syntax for CSS nesting - Chrome Developers
https://developer.chrome.com/blog/help-css-nesting/