Компьютерная безопасность для сомневающихся
— Да кому я интересен? Я не публичный человек, хакерам на меня пофиг.
Большинство хакерских атак — массовые. Хакеры взламывают всех, кого получится взломать.
— Окей, всё равно хакерам нечего у меня взять.
Не пользуетесь онлайн-банками и храните деньги наличными под кроватью? Хакеры могут зашифровать ваши данные и потребовать выкуп. Могут продать ваши социальные аккаунты на чёрном рынке. А ещё могут использовать ваш компьютер как прокси для DDOS, рассылки спама или других чёрных дел, за которые отвечать придётся вам.
❧
Ребята из CyberYozh выпустили обширный курс по анонимности и безопасности в сети. Я бы включил его в школьную программу.
— Да кому я интересен? Я не публичный человек, хакерам на меня пофиг.
Большинство хакерских атак — массовые. Хакеры взламывают всех, кого получится взломать.
— Окей, всё равно хакерам нечего у меня взять.
Не пользуетесь онлайн-банками и храните деньги наличными под кроватью? Хакеры могут зашифровать ваши данные и потребовать выкуп. Могут продать ваши социальные аккаунты на чёрном рынке. А ещё могут использовать ваш компьютер как прокси для DDOS, рассылки спама или других чёрных дел, за которые отвечать придётся вам.
❧
Ребята из CyberYozh выпустили обширный курс по анонимности и безопасности в сети. Я бы включил его в школьную программу.
Cyberyozh
Курс по анонимности и безопасности в сети
Бесплатный курс по анонимности и безопасности в сети от CyberYozh security group
Английский по мультикам
Показательная история выходца из постсоветской Румынии: он изучал в школе английский и французский, но теперь владеет только английским. Понимает, говорит и пишет.
Секрет оказался в кабельном телевидении, подключенном ему в детстве: в те времена не было средств на дубляж телепередач, поэтому их транслировали на английском, в лучшем случае с субтитрами. Каждый день он несколько часов смотрел мультики на английском.
Это в очередной раз доказывает, что сухое изучение грамматики неэффективно; гораздо эффективнее просто погрузиться в языковую среду.
Показательная история выходца из постсоветской Румынии: он изучал в школе английский и французский, но теперь владеет только английским. Понимает, говорит и пишет.
Секрет оказался в кабельном телевидении, подключенном ему в детстве: в те времена не было средств на дубляж телепередач, поэтому их транслировали на английском, в лучшем случае с субтитрами. Каждый день он несколько часов смотрел мультики на английском.
Это в очередной раз доказывает, что сухое изучение грамматики неэффективно; гораздо эффективнее просто погрузиться в языковую среду.
Сокращение рабочей недели
<цитатники ВК>Работать нужно не 12 часов, а головой. © Стив Джобс</цитатники ВК>
Недоумеваю от того, что программисты стремятся увеличивать зарплату, а не уменьшать количество часов в рабочей неделе. Айтишникам с их перегретыми зарплатами на жизнь хватает с достатком, так что можно безболезненно пожертвовать частью достатка в обмен на свободное время.
Зачем уменьшать рабочее время? Ходят слухи, что из стандартных 8 рабочих часов продуктивно работать получается от силы 5—6 часов. На что уходит оставшееся время, думаю, каждый сам для себя ответит. Офисным работникам хуже всего, удалёнщикам, которым не нужно трекать время, попроще — принёс дневной объём пользы и пошёл заниматься своими делами, не дожидаясь окончания рабочего дня.
Тест-драйв сокращённой рабочей недели можно устроить, не меняя работодателя и не уходя на фриланс: для этого можно использовать накопленный отпуск. С работодателем можно договориться о сокращении рабочего дня или недели в счёт отпуска. Я использовал отпуск, чтобы пару месяцев поработать в формате четырёхдневной рабочей недели с выходными по средам. Рекомендую попробовать.
<цитатники ВК>Работать нужно не 12 часов, а головой. © Стив Джобс</цитатники ВК>
Недоумеваю от того, что программисты стремятся увеличивать зарплату, а не уменьшать количество часов в рабочей неделе. Айтишникам с их перегретыми зарплатами на жизнь хватает с достатком, так что можно безболезненно пожертвовать частью достатка в обмен на свободное время.
Зачем уменьшать рабочее время? Ходят слухи, что из стандартных 8 рабочих часов продуктивно работать получается от силы 5—6 часов. На что уходит оставшееся время, думаю, каждый сам для себя ответит. Офисным работникам хуже всего, удалёнщикам, которым не нужно трекать время, попроще — принёс дневной объём пользы и пошёл заниматься своими делами, не дожидаясь окончания рабочего дня.
Тест-драйв сокращённой рабочей недели можно устроить, не меняя работодателя и не уходя на фриланс: для этого можно использовать накопленный отпуск. С работодателем можно договориться о сокращении рабочего дня или недели в счёт отпуска. Я использовал отпуск, чтобы пару месяцев поработать в формате четырёхдневной рабочей недели с выходными по средам. Рекомендую попробовать.
Плоти нологи
Считаю, что одно из лучших решений для повышения сознательности граждан — переложить отвественность за уплату налогов с работодателей на сотрудников.
Многие думают, что с зарплаты отчисляется всего 13% налогов. Более осведомлённые ребята знают, что помимо НДФЛ есть ещё множество страховых взносов, которые зарплату «на руки» в 100 000₽ превращают в ~150 000₽ для работодателя. Но осведомлённость не повышает осознанность; о налогах вспоминают, лишь когда о них заходит разговор.
Нужно начислять сотрудникам зарплату до вычета налогов, чтобы они раз в квартал или в конце года сами заносили налоговой кровно заработанные. Чем больше будет разрыв между начислением зарплаты и уплатой налогов, тем обиднее будет расставаться с деньгами. Чувство собственности вынудит задаться вопросами, на что и насколько эффективно тратятся деньги.
Ради интереса можете посчитать, сколько денег ваш работодатель платит государству.
Считаю, что одно из лучших решений для повышения сознательности граждан — переложить отвественность за уплату налогов с работодателей на сотрудников.
Многие думают, что с зарплаты отчисляется всего 13% налогов. Более осведомлённые ребята знают, что помимо НДФЛ есть ещё множество страховых взносов, которые зарплату «на руки» в 100 000₽ превращают в ~150 000₽ для работодателя. Но осведомлённость не повышает осознанность; о налогах вспоминают, лишь когда о них заходит разговор.
Нужно начислять сотрудникам зарплату до вычета налогов, чтобы они раз в квартал или в конце года сами заносили налоговой кровно заработанные. Чем больше будет разрыв между начислением зарплаты и уплатой налогов, тем обиднее будет расставаться с деньгами. Чувство собственности вынудит задаться вопросами, на что и насколько эффективно тратятся деньги.
Ради интереса можете посчитать, сколько денег ваш работодатель платит государству.
Личный дневник
Я больше года веду файлик did.txt, в который каждый день записываю, что я сделал для себя за прошедший день и что необычного произошло. Однако до сих пор я пользовался этим файлом в режиме write-only и не рефлексировал. Решил, что пора делать это более осмысленно, отсюда назрел вопрос к вам.
Ведёте ли вы личный дневник или его аналог? Как часто и что туда записываете? Поделитесь опытом и расскажите о своей мотивации, в общем!
Я больше года веду файлик did.txt, в который каждый день записываю, что я сделал для себя за прошедший день и что необычного произошло. Однако до сих пор я пользовался этим файлом в режиме write-only и не рефлексировал. Решил, что пора делать это более осмысленно, отсюда назрел вопрос к вам.
Ведёте ли вы личный дневник или его аналог? Как часто и что туда записываете? Поделитесь опытом и расскажите о своей мотивации, в общем!
Синдром text neck
Прочитал недавно статью о вреде наклона головы при пользовании телефоном. Прикреплённая картинка говорит сама за себя.
Ирония в том, что я вспомнил об этой статье от дискомфорта в шее, сидя за ноутбуком с такой же наклонённой головой. В очередной раз напоминаю себе и вам, что экран должен располагаться на высоте глаз: нужен внешний монитор или подставка для ноутбука. Раньше дома я использовал подставку Roost, сейчас пользуюсь ей на работе вместе с внешним монитором, рекомендую. Ну и не рекомендую ставить ноутбук под внешний монитор и посматривать в экран ноутбука, очевидно, это не избавит вас от проблем.
Прочитал недавно статью о вреде наклона головы при пользовании телефоном. Прикреплённая картинка говорит сама за себя.
Ирония в том, что я вспомнил об этой статье от дискомфорта в шее, сидя за ноутбуком с такой же наклонённой головой. В очередной раз напоминаю себе и вам, что экран должен располагаться на высоте глаз: нужен внешний монитор или подставка для ноутбука. Раньше дома я использовал подставку Roost, сейчас пользуюсь ей на работе вместе с внешним монитором, рекомендую. Ну и не рекомендую ставить ноутбук под внешний монитор и посматривать в экран ноутбука, очевидно, это не избавит вас от проблем.
Блокировка рекламы на уровне DNS
Безумно изящная идея — блокировать рекламу и трекеры прямо на уровне DNS, а не в браузере. При таком подходе трекеры не могут следить за тем, какие сайты вы посещаете, а рекламные скрипты в принципе не скачиваются, что ускоряет загрузку сайтов и снижает нагрузку на сеть.
Я знаю два решения, реализующих этот подход: Pi-hole и NextDNS. Pi-hole — опенсорсное решение, требующее самостоятельной нетривиальной настройки, но полностью контролируемое вами и никем другим. NextDNS — по сути Pi-hole as a Service, требует минимальной настройки, но и не даёт гарантий того, что логи ваших DNS-запросов никуда не сливаются.
Оба решения предоставляют дашборды с красивой статистикой, из которой можно, например, узнать, куда в фоне стучится ваш смартфон.
Безумно изящная идея — блокировать рекламу и трекеры прямо на уровне DNS, а не в браузере. При таком подходе трекеры не могут следить за тем, какие сайты вы посещаете, а рекламные скрипты в принципе не скачиваются, что ускоряет загрузку сайтов и снижает нагрузку на сеть.
Я знаю два решения, реализующих этот подход: Pi-hole и NextDNS. Pi-hole — опенсорсное решение, требующее самостоятельной нетривиальной настройки, но полностью контролируемое вами и никем другим. NextDNS — по сути Pi-hole as a Service, требует минимальной настройки, но и не даёт гарантий того, что логи ваших DNS-запросов никуда не сливаются.
Оба решения предоставляют дашборды с красивой статистикой, из которой можно, например, узнать, куда в фоне стучится ваш смартфон.
Может перестанем называть доступностью UX и юзабилити?
Мне кажется, на слова доступность и скринридер в нашем сообществе уже распространился феномен баннерной слепоты. Попробовал сформулировать причину проблемы: https://andrew-r.ru/notes/a11y-ux-usability/
Мне кажется, на слова доступность и скринридер в нашем сообществе уже распространился феномен баннерной слепоты. Попробовал сформулировать причину проблемы: https://andrew-r.ru/notes/a11y-ux-usability/
Пока, 2019: фиксирую значимые для меня события за прошедший год и немного рефлексирую — https://andrew-r.ru/notes/bye-2019/
Портировал любимую цветовую схему Alabaster от Никиты Прокопова на Highlight.js, используемый для подсветки кода в моём блоге (и куче других сайтов!).
Если устали от фейерверка в примерах кода на вашем сайте, подключайте: https://github.com/andrew--r/hljs-alabaster
Если устали от фейерверка в примерах кода на вашем сайте, подключайте: https://github.com/andrew--r/hljs-alabaster
Глобальный .gitignore
В .gitignore проекта часто добавляют файлы, относящиеся не к проекту, а к окружению и инструментам разработчика. Пример:
Из пяти строк только две касаются непосредственно специфики проекта — node_modules и dist. Чем больше разработчиков работают над проектом, тем больше шума будет в .gitignore.
Хорошее на мой взгляд решение — вместо добавления нерелевантных данных в .gitignore проекта завести персональный глобальный .gitignore и добавить в него всё, что касается вашего окружения, будь то настройки IDE или генерируемые операционной системой файлы:
Достаточно сделать это один раз и забыть о случайных коммитах с лишними файлами и последующем обновлении локальных .gitignore. Если вы работаете в команде и кто-то присылает на кодревью .gitignore со специфичными для его окружения файлами, попросите его завести глобальный .gitignore — так вы избавите его от проблем не только в вашем проекте, но и в любых других.
В .gitignore проекта часто добавляют файлы, относящиеся не к проекту, а к окружению и инструментам разработчика. Пример:
.idea
node_modules
dist
.DS_Store
.vscodeИз пяти строк только две касаются непосредственно специфики проекта — node_modules и dist. Чем больше разработчиков работают над проектом, тем больше шума будет в .gitignore.
Хорошее на мой взгляд решение — вместо добавления нерелевантных данных в .gitignore проекта завести персональный глобальный .gitignore и добавить в него всё, что касается вашего окружения, будь то настройки IDE или генерируемые операционной системой файлы:
git config --global core.excludesfile ~/.gitignore_globalДостаточно сделать это один раз и забыть о случайных коммитах с лишними файлами и последующем обновлении локальных .gitignore. Если вы работаете в команде и кто-то присылает на кодревью .gitignore со специфичными для его окружения файлами, попросите его завести глобальный .gitignore — так вы избавите его от проблем не только в вашем проекте, но и в любых других.
Говорить в мире собеседника
Мой опыт работы начался с фриланса. Неотъемлемой частью было общение с заказчиками: сбор требований, согласование работы, решение проблем вроде сдвинутых сроков.
В те времена я совершал ошибку, которую теперь сам периодически замечаю среди других людей. Я говорил не в мире собеседника.
Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:
> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!
Что из этого понятно заказчику:
> доделал главную страницу, двигаюсь дальше!
Иногда люди считают, что собеседник обладает не меньшими знаниями, чем они сами, и начинают грузить его ненужной, непонятной и часто страшно звучащей для него информацией. Ситуацию усугубляет ещё и часто сопутствующее этой проблеме неумение отвечать на поставленный вопрос.
Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:
1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.
Это сильно упростит жизнь вам и всем, с кем вы будете разговаривать.
Мой опыт работы начался с фриланса. Неотъемлемой частью было общение с заказчиками: сбор требований, согласование работы, решение проблем вроде сдвинутых сроков.
В те времена я совершал ошибку, которую теперь сам периодически замечаю среди других людей. Я говорил не в мире собеседника.
Объясню на примере. Представьте, что человеку нужно сделать сайт, а он в этом ничего не понимает. Он нанимает специалиста и в какой-то момент интересуется, как продвигается работа. Ему отвечают:
> У меня возникли проблемы с модулем кеширования страниц в WordPress, почитал StackOverflow, там рекомендуют обновиться до PHP 7, тем более в нём появились декларации типов, которые очень полезны в разработке. Я обновил PHP, но из-за этого пришлось решать проблемы с новым механизмом обработки ошибок. К счастью, как раз сегодня закончил с этим разбираться и доделал главную страницу, двигаюсь дальше!
Что из этого понятно заказчику:
> доделал главную страницу, двигаюсь дальше!
Иногда люди считают, что собеседник обладает не меньшими знаниями, чем они сами, и начинают грузить его ненужной, непонятной и часто страшно звучащей для него информацией. Ситуацию усугубляет ещё и часто сопутствующее этой проблеме неумение отвечать на поставленный вопрос.
Чтобы не совершать этих ошибок, можно пользоваться двумя приёмами:
1. Отвечать на вопросы максимально коротко, не погружаясь в детали. Собеседник при необходимости переспросит или уточнит важные ему детали.
2. В разговоре ставить себя на место собеседника и стараться оценить, будете ли вы ему понятны.
Это сильно упростит жизнь вам и всем, с кем вы будете разговаривать.
Один удалённо — все удалённо
В частично распределённых командах работающие удалённо сотрудники могут испытывать сложности на совещаниях. Их забывают подключать, не дают слова, забивают на слышимость. В результате комфортно только тем, кто присутствует на совещании лично.
Подсмотрел у команды Miro принцип, помогающий справиться со сложностями: «один удалённо — все удалённо». Если хоть один участник совещания не может присутствовать лично, все остальные тоже подключаются удалённо. Это обеспечивает равные условия и комфорт: все говорят в собственные микрофоны, все видят друг друга (если камеры включены), никто не чувствует себя отчуждённым.
В частично распределённых командах работающие удалённо сотрудники могут испытывать сложности на совещаниях. Их забывают подключать, не дают слова, забивают на слышимость. В результате комфортно только тем, кто присутствует на совещании лично.
Подсмотрел у команды Miro принцип, помогающий справиться со сложностями: «один удалённо — все удалённо». Если хоть один участник совещания не может присутствовать лично, все остальные тоже подключаются удалённо. Это обеспечивает равные условия и комфорт: все говорят в собственные микрофоны, все видят друг друга (если камеры включены), никто не чувствует себя отчуждённым.
https://miro.com/
Miro | The Innovation Workspace
Miro is the innovation workspace where teams manage projects, design products, and build the future together. Join 80M+ users from around the world.
Не просите время у бизнеса
Рефакторинг, доступность, быстродействие, тесты: эти вещи объединяет фраза «бизнес не выделит на это время».
Некоторые инженеры почему-то решают, что на рефакторинг или тесты нужно просить время у заказчика. Это ставит их в неловкое положение. Во-первых, это слабая позиция с точки зрения переговоров — вы пришли к заказчику с просьбой, а не он к вам, очевидна ваша нужда. Во-вторых, заказчикам обычно неинтересны или непонятны технические детали, поэтому просьба в духе «мне нужен день на рефакторинг» звучит для них как «мне нужен день непонятно на что вместо важных и понятных улучшений».
Чуть лучше, когда инженеры не просто озвучивают свою потребность в рефакторинге, а подкрепляют её пользой. Например, «мне нужен день на то, чтобы навести порядок внутри системы: благодаря этому я сделаю задачу N за день вместо четырёх, а другим разработчикам будет проще вникнуть в код».
Откуда вообще возникают такие просьбы? По моему опыту, так случается, когда задачи выполняются как можно скорее, жертвуя тестами, качеством кода и чем угодно ещё. Такой подход даёт выгоду только в краткосрочной перспективе, в долгосрочной техдолг копится, замедляет и усложняет разработку. Когда становится совсем невмоготу, разработчики осознают, что маленьким локальным рефакторингом не обойтись, и идут просить у бизнеса время на борьбу с техдолгом.
Более здоровый подход, работающий в долгосрочной перспективе — когда рефакторинг, тесты, документация и прочие технические работы становятся частью любой продуктовой задачи. Не нужно считать рефакторинг или написание тестов отдельными видами работ, которые нельзя сделать в рамках какого-то улучшения продукта и на которые нужно выделять отдельное время. Заложите эти работы в оценку продуктовой задачи и просто сделайте их вместе с задачей. Тогда, как говорится, и волки будут сыты, и овцы целы.
Рефакторинг, доступность, быстродействие, тесты: эти вещи объединяет фраза «бизнес не выделит на это время».
Некоторые инженеры почему-то решают, что на рефакторинг или тесты нужно просить время у заказчика. Это ставит их в неловкое положение. Во-первых, это слабая позиция с точки зрения переговоров — вы пришли к заказчику с просьбой, а не он к вам, очевидна ваша нужда. Во-вторых, заказчикам обычно неинтересны или непонятны технические детали, поэтому просьба в духе «мне нужен день на рефакторинг» звучит для них как «мне нужен день непонятно на что вместо важных и понятных улучшений».
Чуть лучше, когда инженеры не просто озвучивают свою потребность в рефакторинге, а подкрепляют её пользой. Например, «мне нужен день на то, чтобы навести порядок внутри системы: благодаря этому я сделаю задачу N за день вместо четырёх, а другим разработчикам будет проще вникнуть в код».
Откуда вообще возникают такие просьбы? По моему опыту, так случается, когда задачи выполняются как можно скорее, жертвуя тестами, качеством кода и чем угодно ещё. Такой подход даёт выгоду только в краткосрочной перспективе, в долгосрочной техдолг копится, замедляет и усложняет разработку. Когда становится совсем невмоготу, разработчики осознают, что маленьким локальным рефакторингом не обойтись, и идут просить у бизнеса время на борьбу с техдолгом.
Более здоровый подход, работающий в долгосрочной перспективе — когда рефакторинг, тесты, документация и прочие технические работы становятся частью любой продуктовой задачи. Не нужно считать рефакторинг или написание тестов отдельными видами работ, которые нельзя сделать в рамках какого-то улучшения продукта и на которые нужно выделять отдельное время. Заложите эти работы в оценку продуктовой задачи и просто сделайте их вместе с задачей. Тогда, как говорится, и волки будут сыты, и овцы целы.
Публичные CDN и кеширование
Один из аргументов в пользу публичных CDN — подключенные с CDN библиотеки загружаются пользователем один раз и кешируются браузером для всех сайтов, использующих их.
Недавно узнал, что больше на это полагаться не стоит. Браузеры считают такой подход к кешированию небезопасным: он позволяет определить, посещал ли пользователь определённые сайты, то есть поощряет слежку за пользователями.
Проблему слежки решает разделение кеша (cache partitioning): каждый сайт должен иметь собственный кеш для подключаемых на нём ресурсов. Если facebook.com и vk.com подключают с cdnjs.cloudflare.com jQuery одинаковой версии, пользователь при заходе на них скачает jQuery дважды.
Оказывается, в Safari кеш разделён аж с 2013 года. В Chrome с 77 версии тоже ведётся работа по разделению кеша. Инженеры Mozilla активно помогают в стандартизации этого поведения.
Один из аргументов в пользу публичных CDN — подключенные с CDN библиотеки загружаются пользователем один раз и кешируются браузером для всех сайтов, использующих их.
Недавно узнал, что больше на это полагаться не стоит. Браузеры считают такой подход к кешированию небезопасным: он позволяет определить, посещал ли пользователь определённые сайты, то есть поощряет слежку за пользователями.
Проблему слежки решает разделение кеша (cache partitioning): каждый сайт должен иметь собственный кеш для подключаемых на нём ресурсов. Если facebook.com и vk.com подключают с cdnjs.cloudflare.com jQuery одинаковой версии, пользователь при заходе на них скачает jQuery дважды.
Оказывается, в Safari кеш разделён аж с 2013 года. В Chrome с 77 версии тоже ведётся работа по разделению кеша. Инженеры Mozilla активно помогают в стандартизации этого поведения.
GitHub
GitHub - shivanigithub/http-cache-partitioning
Contribute to shivanigithub/http-cache-partitioning development by creating an account on GitHub.
О личной эффективности
Марина Сафонова в 2016 году рассказала о своих принципах личной эффективности, а через два года очень хорошо над ними порефлексировала:
Спустя два года перечитываю тот пост и вижу между строк идею «как бы мне еще себя помучить».
Рекомендую к прочтению всем, кто гонится за продуктивностью и думает о том, как бы провести максимум времени с пользой.
Марина Сафонова в 2016 году рассказала о своих принципах личной эффективности, а через два года очень хорошо над ними порефлексировала:
Спустя два года перечитываю тот пост и вижу между строк идею «как бы мне еще себя помучить».
Рекомендую к прочтению всем, кто гонится за продуктивностью и думает о том, как бы провести максимум времени с пользой.
Идеальный сервис для прослушивания музыки
На дворе 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 — хороший пример готовых соглашений для обозначения намерений.