Идеальный сервис для прослушивания музыки
На дворе 2020 год, а все сервисы для прослушивания музыки, которые я пробовал (Яндекс.Музыка, Spotify, Deezer, Google Play Music, Apple Music), работают отвратительно.
Мой субъективный гигиенический минимум для таких сервисов:
1. Кроссплатформенность и синхронизация фонотеки между девайсами. Здесь нечего добавить.
2. Простой и понятный интерфейс, который в первую очередь показывает твою фонотеку (исполнители, альбомы, треки, жанры), а не рекомендации и подкасты.
3. Стабильность фонотеки. Привет Яндекс.Музыке, в которой я постоянно обнаруживаю то дубли альбомов, то отсутствие добавленных ранее песен.
4. Переключение треков без задержек. Отсутствие этого особенно бесит, когда слушаешь что-то вроде Pink Floyd, где на протяжении всего альбома один трек плавно переходит в другой.
5. Возможность скачивания музыки на девайс. Как целыми альбомами, так и отдельными треками (привет, Spotify, в котором отдельный трек нельзя скачать без диких ухищрений вроде его добавления в специально созданный плейлист для скачивания).
6. Предсказуемая и стабильная работа в офлайне (например, в самолётах). Снова привет Яндекс.Музыке, у которой в офлайне половина песен пропадает, остальные перемешиваются (в прямом смысле, в альбом заходишь, а там песни в неправильном порядке), а у большинства песен не отображаются обложки альбомов.
Не такие важные для меня, но приятные возможности:
1. Просмотр текстов песен. Оценил эту возможность в Яндекс.Музыке.
2. Встроенный поиск треков по записи (аля Shazam). Тоже удобно, чтобы не держать отдельное приложение.
3. Экспорт и импорт метаданных фонотеки. Невозможно запомнить все треки, которые когда-то понравились, хотелось бы владеть данными фонотеки и иметь возможность их выгрузить и импортировать в любом сервисе (заодно это бы облегчило переход между сервисами).
Если знаете сервис, который удовлетворяет всем критериям — делитесь в чате!
На дворе 2020 год, а все сервисы для прослушивания музыки, которые я пробовал (Яндекс.Музыка, Spotify, Deezer, Google Play Music, Apple Music), работают отвратительно.
Мой субъективный гигиенический минимум для таких сервисов:
1. Кроссплатформенность и синхронизация фонотеки между девайсами. Здесь нечего добавить.
2. Простой и понятный интерфейс, который в первую очередь показывает твою фонотеку (исполнители, альбомы, треки, жанры), а не рекомендации и подкасты.
3. Стабильность фонотеки. Привет Яндекс.Музыке, в которой я постоянно обнаруживаю то дубли альбомов, то отсутствие добавленных ранее песен.
4. Переключение треков без задержек. Отсутствие этого особенно бесит, когда слушаешь что-то вроде Pink Floyd, где на протяжении всего альбома один трек плавно переходит в другой.
5. Возможность скачивания музыки на девайс. Как целыми альбомами, так и отдельными треками (привет, Spotify, в котором отдельный трек нельзя скачать без диких ухищрений вроде его добавления в специально созданный плейлист для скачивания).
6. Предсказуемая и стабильная работа в офлайне (например, в самолётах). Снова привет Яндекс.Музыке, у которой в офлайне половина песен пропадает, остальные перемешиваются (в прямом смысле, в альбом заходишь, а там песни в неправильном порядке), а у большинства песен не отображаются обложки альбомов.
Не такие важные для меня, но приятные возможности:
1. Просмотр текстов песен. Оценил эту возможность в Яндекс.Музыке.
2. Встроенный поиск треков по записи (аля Shazam). Тоже удобно, чтобы не держать отдельное приложение.
3. Экспорт и импорт метаданных фонотеки. Невозможно запомнить все треки, которые когда-то понравились, хотелось бы владеть данными фонотеки и иметь возможность их выгрузить и импортировать в любом сервисе (заодно это бы облегчило переход между сервисами).
Если знаете сервис, который удовлетворяет всем критериям — делитесь в чате!
Подход Fail Fast
В разработке есть довольно здравые и широко применимые подходы, о которых почему-то редко рассказывают в учебных курсах или книгах, и ты со временем либо интуитивно приходишь к ним сам (зачастую не в состоянии осознанно их сформулировать), либо узнаешь о них случайно. Для меня одним из таких подходов оказался Fail Fast. Давно о нём где-то поверхностно услышал и отложил в закладки, а сейчас добрался до исходной статьи Джима Шора Fail Fast (PDF, ~120 КБ).
Джим пишет, что одни из самых неприятных багов — те, которые проявляются не сразу и вызывают отложенные последствия, по которым сложно определить исходную проблему. Такие баги обычно вызваны тем, что в процессе выполнения программы ошибки всеми силами глушатся и игнорируются, чтобы сохранить работоспособность программы.
Рецепт борьбы с такими багами — подход Fail Fast, предполагающий немедленное сообщение о проблеме при её обнаружении. Джим предлагает покрывать для этого код специальными проверками в неоднозначных местах, где что-то может пойти не так.
Как раз недавно столкнулся на работе с проблемой, которую можно было бы предотвратить с помощью этого подхода. Моё приложение ожидает, что при запуске в переменных окружения будет задан определённый внешний URL, который открывается в iframe на одной из страниц приложения. При запуске нового экземпляра приложения эта переменная окружения ошибочно была задана с неправильным названием. Приложение успешно поднялось, а спустя некоторое время пользователи сообщили, что iframe перестал работать.
Джим приводит аналогичный пример про конфигурацию прямо в начале своей статьи: при отсутствии значения в конфигурации лучше вообще не запускать приложение и выводить сообщение о проблеме, чем использовать какое-то значение по умолчанию. В первом случае разработчик попробует запустить приложение и получит ошибку вида «Ключ ____ отсутствует в конфигурации», а во втором случае он уйдёт отдыхать и узнает о проблеме от недовольных пользователей, которые не могли решать свои задачи всё время его отсутствия.
Важно отметить, что этот подход не про полную остановку программы при обнаружении ошибки, а в первую очередь про то, чтобы сделать проблемы заметными. Джим приводит в пример пакетную обработку данных, при которой можно обойтись отправкой сообщения об ошибке разработчику (например, через Sentry) и ненавязчивым сообщением пользователю о том, что часть данных обработать не удалось. Основная идея в том, чтобы разработчик узнал о проблеме как можно раньше и чтобы сообщение о проблеме направило его как можно ближе к причине.
В разработке есть довольно здравые и широко применимые подходы, о которых почему-то редко рассказывают в учебных курсах или книгах, и ты со временем либо интуитивно приходишь к ним сам (зачастую не в состоянии осознанно их сформулировать), либо узнаешь о них случайно. Для меня одним из таких подходов оказался Fail Fast. Давно о нём где-то поверхностно услышал и отложил в закладки, а сейчас добрался до исходной статьи Джима Шора Fail Fast (PDF, ~120 КБ).
Джим пишет, что одни из самых неприятных багов — те, которые проявляются не сразу и вызывают отложенные последствия, по которым сложно определить исходную проблему. Такие баги обычно вызваны тем, что в процессе выполнения программы ошибки всеми силами глушатся и игнорируются, чтобы сохранить работоспособность программы.
Рецепт борьбы с такими багами — подход Fail Fast, предполагающий немедленное сообщение о проблеме при её обнаружении. Джим предлагает покрывать для этого код специальными проверками в неоднозначных местах, где что-то может пойти не так.
Как раз недавно столкнулся на работе с проблемой, которую можно было бы предотвратить с помощью этого подхода. Моё приложение ожидает, что при запуске в переменных окружения будет задан определённый внешний URL, который открывается в iframe на одной из страниц приложения. При запуске нового экземпляра приложения эта переменная окружения ошибочно была задана с неправильным названием. Приложение успешно поднялось, а спустя некоторое время пользователи сообщили, что iframe перестал работать.
Джим приводит аналогичный пример про конфигурацию прямо в начале своей статьи: при отсутствии значения в конфигурации лучше вообще не запускать приложение и выводить сообщение о проблеме, чем использовать какое-то значение по умолчанию. В первом случае разработчик попробует запустить приложение и получит ошибку вида «Ключ ____ отсутствует в конфигурации», а во втором случае он уйдёт отдыхать и узнает о проблеме от недовольных пользователей, которые не могли решать свои задачи всё время его отсутствия.
Важно отметить, что этот подход не про полную остановку программы при обнаружении ошибки, а в первую очередь про то, чтобы сделать проблемы заметными. Джим приводит в пример пакетную обработку данных, при которой можно обойтись отправкой сообщения об ошибке разработчику (например, через Sentry) и ненавязчивым сообщением пользователю о том, что часть данных обработать не удалось. Основная идея в том, чтобы разработчик узнал о проблеме как можно раньше и чтобы сообщение о проблеме направило его как можно ближе к причине.
Список сделанных рабочих задач
Рутинная, но крайне полезная практика — ведение списка сделанных рабочих задач. Я веду такой список с февраля 2017 года и могу точно сказать, чем я занимался на работе в любую из недель с той даты.
Каждую неделю я завожу в списке отдельную секцию с временным диапазоном (например, «24–28 мая 2021») в заголовке и в течение недели записываю сделанные задачи.
Основная польза в том, что мне больше не нужно в разных ситуациях мучительно вспоминать, чем я занимался и что сделал. А такие ситуации в моём опыте возникают постоянно:
1. Ежедневные встречи с командой, на которых рассказываешь, чем занимался вчера.
2. Еженедельные отчёты о проделанной командой работе, для которых каждый член команды составляет список сделанных им задач.
3. Ретроспектива: понять, на что ушло время вместо важных запланированных задач.
4. Performance review: выделение основных достижений за последние полгода.
5. Подготовка к поиску работы: список освежает память при составлении резюме и рассказе о прошлом опыте.
В общем, горячо рекомендую завести себе такой список и снять с себя когнитивную нагрузку в описанных (и не только) случаях.
Рутинная, но крайне полезная практика — ведение списка сделанных рабочих задач. Я веду такой список с февраля 2017 года и могу точно сказать, чем я занимался на работе в любую из недель с той даты.
Каждую неделю я завожу в списке отдельную секцию с временным диапазоном (например, «24–28 мая 2021») в заголовке и в течение недели записываю сделанные задачи.
Основная польза в том, что мне больше не нужно в разных ситуациях мучительно вспоминать, чем я занимался и что сделал. А такие ситуации в моём опыте возникают постоянно:
1. Ежедневные встречи с командой, на которых рассказываешь, чем занимался вчера.
2. Еженедельные отчёты о проделанной командой работе, для которых каждый член команды составляет список сделанных им задач.
3. Ретроспектива: понять, на что ушло время вместо важных запланированных задач.
4. Performance review: выделение основных достижений за последние полгода.
5. Подготовка к поиску работы: список освежает память при составлении резюме и рассказе о прошлом опыте.
В общем, горячо рекомендую завести себе такой список и снять с себя когнитивную нагрузку в описанных (и не только) случаях.
Как упростить кодревью
Делюсь проверенными на личном опыте способами упростить ревью вашего кода и в целом повысить культуру кодревью в компании.
📏 Размер пулреквестов — 80% успеха
Чем меньше пулреквесты — тем лучше. Большие PR демотивируют ревьюеров и снижают качество ревью, потому что сложно удерживать объём изменений в голове.
Если получается большой пулреквест, возможно вы смешали в нём правки в разных частях системы, требуемые для решения исходной задачи. Такие правки обычно можно разбить на отдельные PR: например, отделить новые UI-компоненты от реализации страницы с их использованием.
Ещё один случай больших PR — рефакторинги. Обычно их можно разделить на две части:
1. Содержательные изменения в какой-то части системы
2. Шаблонное обновление остального кода
Отделите первое от второго, и вы сэкономите время и силы ревьюеров, которым не очень важен бойлерплейт.
В завершение про размер пулреквестов: не поддавайтесь соблазну докинуть новую функциональность в уже открытые PR. Новая функциональность — новый пулреквест. Это опять же про самодостаточные изменения и внимание ревьюеров, которое не бесконечно.
📝 Описание изменений
Ревьюерам сильно поможет внятное описание ваших изменений. Какую задачу вы решали, почему решили её именно так, на что стоит обратить внимание.
Не ленитесь описать это прямо в PR, не все открывают прилинкованные задачи, и в них может не хватать контекста.
В идеале описание нужно сопроводить ссылкой на тестовый стенд, где изменения можно оценить вживую. Если стенда нет, позаботьтесь о том, чтобы проект было легко запустить локально, и сопроводите описание скриншотами конечных изменений (актуально для фронтендеров).
Если пулреквест содержит неочевидные решения или хаки, от которых не избавиться, заранее сопроводите их комментариями прямо в коде — для ревьюеров и для будущих поколений, которые будут читать этот код.
Не стесняйтесь сопроводить PR собственными комментариями на отдельных участках кода, чтобы:
— указать порядок чтения;
— прояснить мотивацию к конкретным изменениям;
— явно обратить внимание на сложные места;
— явно запросить обратную связь, если сомневаетесь в своём коде.
🕵️ Ревью собственных пулреквестов
Прежде чем запрашивать ревью у других разработчиков, просмотрите свои изменения, будто кто-то другой запросил у вас ревью. Так вы сэкономите своё и чужое время, сразу обнаружив очевидные косяки вроде опечаток или забытого кода для отладки.
🔔 Уведомления о ревью
Чтобы вам и ревьюерам не приходилось вручную следить за запросами ревью, комментариями, апрувами и прочим, настройте уведомления о них в рабочем мессенджере. Например, я использую интеграцию GitHub и Slack.
🤝 Явное обозначение намерений в комментариях
У вас будет больше взаимопонимания, если ревьюер явно обозначит, какие замечания считает критичными, а какие можно проигнорировать.
Conventional Comments — хороший пример готовых соглашений для обозначения намерений.
Делюсь проверенными на личном опыте способами упростить ревью вашего кода и в целом повысить культуру кодревью в компании.
📏 Размер пулреквестов — 80% успеха
Чем меньше пулреквесты — тем лучше. Большие PR демотивируют ревьюеров и снижают качество ревью, потому что сложно удерживать объём изменений в голове.
Если получается большой пулреквест, возможно вы смешали в нём правки в разных частях системы, требуемые для решения исходной задачи. Такие правки обычно можно разбить на отдельные PR: например, отделить новые UI-компоненты от реализации страницы с их использованием.
Ещё один случай больших PR — рефакторинги. Обычно их можно разделить на две части:
1. Содержательные изменения в какой-то части системы
2. Шаблонное обновление остального кода
Отделите первое от второго, и вы сэкономите время и силы ревьюеров, которым не очень важен бойлерплейт.
В завершение про размер пулреквестов: не поддавайтесь соблазну докинуть новую функциональность в уже открытые PR. Новая функциональность — новый пулреквест. Это опять же про самодостаточные изменения и внимание ревьюеров, которое не бесконечно.
📝 Описание изменений
Ревьюерам сильно поможет внятное описание ваших изменений. Какую задачу вы решали, почему решили её именно так, на что стоит обратить внимание.
Не ленитесь описать это прямо в PR, не все открывают прилинкованные задачи, и в них может не хватать контекста.
В идеале описание нужно сопроводить ссылкой на тестовый стенд, где изменения можно оценить вживую. Если стенда нет, позаботьтесь о том, чтобы проект было легко запустить локально, и сопроводите описание скриншотами конечных изменений (актуально для фронтендеров).
Если пулреквест содержит неочевидные решения или хаки, от которых не избавиться, заранее сопроводите их комментариями прямо в коде — для ревьюеров и для будущих поколений, которые будут читать этот код.
Не стесняйтесь сопроводить PR собственными комментариями на отдельных участках кода, чтобы:
— указать порядок чтения;
— прояснить мотивацию к конкретным изменениям;
— явно обратить внимание на сложные места;
— явно запросить обратную связь, если сомневаетесь в своём коде.
🕵️ Ревью собственных пулреквестов
Прежде чем запрашивать ревью у других разработчиков, просмотрите свои изменения, будто кто-то другой запросил у вас ревью. Так вы сэкономите своё и чужое время, сразу обнаружив очевидные косяки вроде опечаток или забытого кода для отладки.
🔔 Уведомления о ревью
Чтобы вам и ревьюерам не приходилось вручную следить за запросами ревью, комментариями, апрувами и прочим, настройте уведомления о них в рабочем мессенджере. Например, я использую интеграцию GitHub и Slack.
🤝 Явное обозначение намерений в комментариях
У вас будет больше взаимопонимания, если ревьюер явно обозначит, какие замечания считает критичными, а какие можно проигнорировать.
Conventional Comments — хороший пример готовых соглашений для обозначения намерений.
👍38
С наступающим 2025
Давно ничего не писал, собрался с силами и вернулся к давно забытому жанру итогов года: https://andrew-r.ru/notes/bye-2024/
Давно ничего не писал, собрался с силами и вернулся к давно забытому жанру итогов года: https://andrew-r.ru/notes/bye-2024/
andrew-r.ru
Пока, 2024
Новый дом, новая работа, поездки, потери и рефлексия
❤30👍15👎4
Мониторинг падений браузера
В рабочем чате недавно интересовались, можно ли как-то отследить падение браузерной вкладки с нашим веб-приложением. Я о таких способах не знал, поэтому из любопытства отправился гуглить.
Нетривиальность задачи заключается в том, что падение неожиданно обрывает выполнение кода вашего приложения, так что стандартные подходы вроде обработки какого-то глобального события неприменимы, ведь для обработки события нужен живой процесс, исполняющий ваш код.
Как выяснилось, существует экспериментальный Reporting API, позволяющий отслеживать как падения, так и другие виды проблем, например, нарушения политик безопасности (вроде Content Security Policy) и использование устаревших фич.
Reporting API предоставляет два основных способа получения отчётов о проблемах:
1. Глобальный класс ReportingObserver, позволяющий подписаться на предупреждения и как-либо их обрабатывать через JavaScript; так как это клиентский API, он не отслеживает падения.
2. HTTP-заголовок Reporting-Endpoints, задающий серверные эндпойнты, на которые бразуер должен отправлять собранные отчёты; этот способ покрывает все виды отчётов, включая падения.
На портале Chrome for Developers есть хороший обзор Reporting API.
API всё ещё не стабилен, спецификация находится в статусе черновика, и пока она реализована не во всех основных браузерах. Несмотря на все эти оговорки, аналогов Reporting API нет, и его уже используют, например, в Figma.
В рабочем чате недавно интересовались, можно ли как-то отследить падение браузерной вкладки с нашим веб-приложением. Я о таких способах не знал, поэтому из любопытства отправился гуглить.
Нетривиальность задачи заключается в том, что падение неожиданно обрывает выполнение кода вашего приложения, так что стандартные подходы вроде обработки какого-то глобального события неприменимы, ведь для обработки события нужен живой процесс, исполняющий ваш код.
Как выяснилось, существует экспериментальный Reporting API, позволяющий отслеживать как падения, так и другие виды проблем, например, нарушения политик безопасности (вроде Content Security Policy) и использование устаревших фич.
Reporting API предоставляет два основных способа получения отчётов о проблемах:
1. Глобальный класс ReportingObserver, позволяющий подписаться на предупреждения и как-либо их обрабатывать через JavaScript; так как это клиентский API, он не отслеживает падения.
2. HTTP-заголовок Reporting-Endpoints, задающий серверные эндпойнты, на которые бразуер должен отправлять собранные отчёты; этот способ покрывает все виды отчётов, включая падения.
На портале Chrome for Developers есть хороший обзор Reporting API.
API всё ещё не стабилен, спецификация находится в статусе черновика, и пока она реализована не во всех основных браузерах. Несмотря на все эти оговорки, аналогов Reporting API нет, и его уже используют, например, в Figma.
👍27❤5