Достижения через преодоление себя против наслаждения процессом достижения целей

Достижения через преодоление себя против наслаждения процессом достижения целей

Рассмотрим две популярные точки зрения.

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

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

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

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

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

Определимся со спортивными целями. Они могут быть разными:
1. Не хочу быть толстым, поэтому буду бегать 2-3 раза в неделю.
2. Хочу красивое тело — буду ходить в зал 3-5 раз в неделю.
3. Хочу стать марафонцем.
4. Хочу пробежать марафон из 3-х часов.
5. Хочу стать КМС в каком-либо виде спорта.
6. Хочу поучаствовать в ЧМ по триатлону.

Первые три цели — про наслаждение процессом по большому счету. Не надо убиваться, переусердствовать и т. д. Достаточно просто стабильности, как в ежедневной работе. Да, бывают сложности, но в целом все ровно — пришел на работу, поработал без перенапряжения в свое удовольствие и ушел.

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

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

Чем выше планка — тем больше страданий и дисциплины. Это нужно либо принять, либо поумерить свои амбиции.

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

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

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

Фабрицио Тейшейра и Тайо Брага написали, что может сделать дизайнер, чтобы цифровые продукты, над которыми он работает, становились этичнее.

Несколько цитат:

В погоне за кликами и просмотрами технические платформы ищут новые способы использовать человеческие инстинкты (стыд, лень и страх). Цифровой фастфуд обещает пользователям быстрое удовольствие, но оставляет после себя только экзистенциальный вакуум.

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

Хотя мы понимаем, что такая тактика — проектирование ради метрик — реально не всегда полезна, мы называем свои методы позитивно: взлом роста (growth hacking), геймификация и петли вовлечения. Мы стараемся не думать о возможных пагубных последствиях.

«Пока мы не начнём измерять то, что ценим, мы будем переоценивать то, что измеряем», — Ким Гудвин.

Представьте: девушка присоединяется к ЛГБТК-хору в колледже. Руководитель хора добавляет её в группу в Facebook, и Facebook автоматически делится этим действием в новостной ленте студента. Однако девушка ещё не рассказала семье о своей сексуальной ориентации. Могут ли продукты случайно нанести вред?

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

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

https://awdee.ru/world-needs-a-tech-diet/

Думай как Билл Гейтс

Смотрю сейчас на Netflix документальный сериал про Гейтса. Очень увлекательно! В последней серии зацепил диалог следующего содержания:
— Билл, как ты думаешь, Microsoft монополист?
— Если монополия это большая доля рынка и краткосрочная власть над ним, то ответ да. Если вы подразумеваете, что у нас непобедимая позиция и никакой более удобный и эффективный продукт не может её пошатнуть, ответ нет.

И ведь правда. У слова монополия очень сильная негативная составляющая. Но разве это плохо? На свободном рынке, если не рассматривать государственные и прочие нечестные монополии, большая доля рынка говорит о том ,что продукт хорошо решает проблемы пользователя. Да, он может быть кривой и показывать вам периодически "синий экран сметри". Но он, чёрт побери, работает! В сериале есть вставки из хрорники, где народ расхватывает коробки с Windows 95, буквально сметает её с полок :)

Сейчас модно ругать Windows. Но ведь именно эта ОС сделала революцию на рынке персональных компьютеров. Сначала её, конечно, сделал Apple в сфере железа. Именно два Стива сделали компьютер персональным (Джобс и Возняк). Но они были нацелены на определенную ЦА. А вот Майкрософт сделал ПК по-настоящему массовым.

Сейчас Гейтс много времени уделяет проблемам энергетики и климата. Они с женой потратили кучу денег (28 миллиардов долларов) на стартапы и инициативы, которые пытаются сделать жизнь лучше в масштабах планеты. Крутой сериал про крутого бизнесмена и просто очень умного человека. Советую!

Редактор UX Movement Энтони написал о цветовом контрасте и доступности интерфейса по стандартам WCAG

1. Требования WCAG не всегда оптимальны. Алгоритм оценки контраста занижает её для белого текста на ярком фоне (синем или оранжевом), хотя читать его легче чёрного текста.

2. Контраст текста не обязательно тянуть на уровень 7:1. Это полезно, если большая часть вашей аудитории — люди старше 70 лет с потерей зрения 20/80. Для определённого контента достижение уровня 7:1 невозможно вовсе.

3. Так как текст надо читать, его стандарты контрастности выше, чем у других компонентов интерфейса. У текста 4,5:1 против 3:1 у иконок.

4. Если у иконки есть доступная подпись (контраст 4,5:1), контраст самой иконки не важен. Также не важен цвет кнопки, если находящийся на кнопке текст доступен. Требование контрастности не распространяется на неактивные компоненты (например, отключённые кнопки).

5. Дальтоники нормально воспринимают различные уровни цветового контраста. Если для разграничения состояний использовать только контраст, вероятно, эти состояния будут им доступны.

6. Требование «цвет не должен использоваться в качестве единственного визуального средства передачи информации, обозначения действия или различия элемента» справедливо, когда разным цветам назначены конкретные значения для информирования пользователя. Если для информирования использовать светлоту и темноту с хорошей разницей в контрасте, дополнительный сигнал не нужен.

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

https://ux.pub/mify-o-dostupnosti-tsvetovogo-kontrasta/

PHP Intl. Правильная транслитерация кириллицы

PHP Intl. Правильная транслитерация кириллицы

Современные фреймворки предоставляют готовый функционал в составе библиотек или хелперов для работы с библиотекой ICU (http://site.icu-project.org/home) через API Intl.

Такой функционал необходим для поддержки интернационализации разрабатываемого веб-сервиса. На основе указанной локали могут устанавливаться форматы отображения валют, времени и даты, а также подбираться настройки для инициализации транслитераторов (https://www.php.net/class.transliterator).

В разделе «Телеграм-каналы (https://chulakov.ru/notes)» сайта Студии во время автоматического импорта постов из наших каналов производится транслитерация названий заметок для формирования ЧПУ (https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_URL).

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

Например, уникальная часть URL заметки (https://chulakov.ru/notes/development/php-8-pocti-novogodnij-podarok) про релиз PHP 8 после транслитерации имела вид php-8-pocti-novogodnij-podarok. Замена некоторых букв произошла некорректно.

Для того чтобы транслитерация кириллицы производилась по традиционным правилам, необходимо произвести конфигурацию объекта-транслитератора (https://www.php.net/manual/ru/transliterator.create.php), передав следующее значение параметра $id:

Russian-Latin/BGN; Any-Latin; Latin-ASCII; NFD; [:Nonspacing Mark:] Remove; NFC;

После такой конфигурации результат преобразования наименования заметки изменится на php-8-pochti-novogodniy-podarok.

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

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

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

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

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