👋,

Расскажу про сгенерированный мною контент, про который я еще не писал в канале.

Для всех
1. Перевод "Как писать условия в JSX". Не сложные рецепты про то как не стрелять себе в ногу, когда пишешь шаблоны.
2. Перевод "Возможности TypeScript, которых нужно избегать". TLDR, не нужно использовать ничего, чего нет в JavaScript. Статья стремительно улетает в минуса, но ее читают и комментируют. Если вы поставите ⬆️, то будет вообще супер.

Для патронов
В своем 🤝Patreon я каждую неделю пишу эксклюзивные заметки для патронов. В январе писал про:
* что такое обратная совместимость и что я ожидаю от Junior разработчика.
* внедрение инноваций в компаниях и проблемы с этим. backstage.
* про работу офтальмолога в Германии; внедрение backstage, стратегия; про то, что важно ясно выражать свои потребности, на примере.

#дайджест

Мозг уже все решил

Мы, как Хорошие разработчики и как люди, просто постоянно принимаем решения. Какие-то решения не слишком важны (посмотреть это видео на youtube или поработать?), какие-то более важные (принять оффер от этой компании?). Порой мы долго думаем, взвешиваем все за и против, и это делает нашу жизнь менее приятной.

А что если все это бессмысленно, что если мы уже приняли решение? Этот пост вдохновлен воспоминаниями о прочтении книги "Иллюзия Я, или игры, в которые играет с нами мозг".

В книге описан такой эксперимент. В 1980-х годах психолог Бенджамин Либет посадил людей перед кнопкой и просил их нажимать на нее тогда, когда им самим взбредет в голову. Параллельно, он наблюдал за активностью их мозга. Он заметил, что перед тем, как люди нажмут на кнопку происходит всплеск активности нейронов. Но, что было интересно, всплеск активности происходит раньше, чем человек ощущал сознательное намерение нажать на кнопку. Разница колебалась от 1/5 секунды до 7 секунд.

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

Я часто использую этот “хак” при решении проблем, которые затягивают и затягивают меня. Как поступить лучше? Продолжать хайринг процесс с этой компанией? Какой вариант рефакторинга выбрать? Когда я замечаю, что воронка принятия решения меня затягивает, то я спрашиваю себя — какое решение УЖЕ выбрано? И часто я знаю, какое это решение. Окружать себя вопросами становиться бессмысленно.

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

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

⬛️ Еще раз — если вы долго не можете принять решение, то спросите себя — какое решение я УЖЕ принял? Как правило, оно уже есть. Теперь у нас есть свободное время, чтобы тревожиться о чем-то другом.

Напишите, пожалуйста, интересны ли такие, более далекие от IT, темы.

#софтскиллы

Не переживайте, сообщение выше это не прогрев на покупку NFT или какого-то 🐶-коина.

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

Перевел статью для Хабра, где, с картинками и постепенно, объясняется как работает биткоин.

https://habr.com/ru/post/649597/

Про разные форматы данных

Как-то раз, недавно, к нам в команду поступил баг 🐞. Наш BI сказал, что от нас приходят таймстампы в разных временных поясах, то как в Берлине, а то как в Гринвиче. Я стал разбираться.

Чуть-чуть разобрался, и оказалось, что наша логика простая — взять то, что возвращает вендор (многомиллионная компания 💸) и отправить дальше. Стал проверять, а что же возвращает вендор? Сделал разные запросы и — ухты, иногда, он возвращает 2022-04-30T00:00:00+01:00 а иногда 2022-04-29T23:00:00Z. В одном формате есть часовой пояс, а в другом просто UTC.

Еще интересно, что время, которое возвращает вендор, выбираем мы. Мы выставляем это время через их UI и дальше оно не только участвует в бизнес процессе, но и возвращается нам.

Я написал вендору с примерами и попросил разобраться. Их ответ меня удивил. Они написали, что действительно, буквально месяц назад они выпустили обновление. И теперь, когда ты сохраняешь время через UI, то возвращаться оно будет в UTC. А вот те значения, что были созданы раньше, будут, как и раньше, возвращаться с часовым поясом. Если вы хотите, чтобы формат был одинаковый, стоит лишь сохранить все еще раз через UI (для нас это более 100 раз). А в конце дружелюбно добавили — а почему вы вообще спрашиваете? Ведь мы возвращаем одно и то же время.

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

В итоге прошла еще пара дней. Они исследовали как бы это обновить, а я исследовал, что мы будем делать, если они не обновят. Я реализовал свое решение, а они сообщили, что теперь все данные консистентны. Happy end!

🎁 Бонус знание, если вы видите время и в конце стоит Z, то это всегда UTC. When “Z” (Zulu) is tacked on the end of a time, it indicates that that time is UTC, so really the literal Z is part of the time.

Какие выводы мы можем сделать?

1. На самом деле не важно сколько стоит вендор, это я забавы ради написал. IT процессы не зависят напрямую от стоимости компании.
2. При обновлениях нужно следить за обратной совместимостью
3. Ошибаться не страшно, но нужно признавать свои ошибки

Что думаете?

#истории

Про меня

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

Меня зовут Павел, в профессиональной (той, что приносит мне 💰) разработке я уже около 18 лет. Сначала я работал фрилансером на PHP. Потом на 🇳🇱 компанию в Харькове, делал магазины на Magento. Потом на 🇩🇪 компанию в Харькове, делал финпродукт на PHP. А потом я и вовсе переехал в Германию, продолжал работать на ту же 🇩🇪 компанию, но уже на Node.js. 4 года назад я присоединился к SHARE NOW, сначала с Node.js, а потом конвертировался в Java/Kotlin. Но разве языки программирования что-то обо мне говорят? Я думаю мало.

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

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

📚Истории
* Как я не получил промоушен
* Как я получил промоушен: часть 1, часть 2
* Как хакер украл 10.000€

⚙️ Хард скиллы
* Что такое ADR
* Что такое Technology Radar от ThoughtWorks
* Что такое Levels of maturity

🍦Софт скиллы
* 💎 of participatory decision making
* Техника Fist to Five
* Матрица Эйзенхауэра

📰 Есть еще пара лонгридов
* Как я завел экспертный TikTok и потерпел неудачу
* Как практики из IT помогают растить детей

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

Спасибо, что присоединились 🤗 И спасибо старожилам, что еще здесь 🤝.

Application Performance Monitoring

Мы написали новый классный сервис. Что обязательно нужно сделать, перед тем как выкладывать его на продакшен? Много чего. У сервиса должны быть тесты, у сервиса должны быть логи, у сервиса должны измеряться бизнес метрики, + что-то еще, что нужно именно этому сервису. Но есть вещь, которую нужно интегрировать прямо везде. Это Application performance monitoring или APM.

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

Самое классное с APM — для того чтобы внедрить их сбор, как правило, нужно подключить лишь одну библиотеку. Например, можно сделать это с помощью NewRelic (платно 💸), их клиент поддерживает большинство языков (Go, Java, .NET, Node.js, PHP, Python, Ruby, C SDK). В Node.js буквально:

if (process.env.NEWRELIC_LC) {
  // eslint-disable-next-line global-require
  require('newrelic');
}

Такие библиотеки часто могут определить какой фреймворк вы используете (Spring) и дополнительно измерять что-то, что свойственно этому фреймворку. А еще, например, могут строить карту ваших сервисов, как они друг с другом взаимодействуют.

Есть и бесплатные решения, например, OpenTelemetry. Это решение с открытым исходным кодом, за него не надо платить кому-то, но нужно устанавливать его на свою инфраструктуру и потом рисовать дэшборды, в какой-нибудь Grafana. Зато тоже есть библиотеки для разных языков программирования.

⬛️ Еще раз — что бы ни делал наш сервис, мы должны иметь возможность наблюдать за ним. В каждый сервис нужно встраивать APM, они помогут следить за здоровьем сервиса.

Какие вы используете библиотеки для APM?

#хардскиллы

Кто такой фасилитатор

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

Но есть проблема, если группа большая или у участников еще не установилось доверие, то договориться сложно. А еще к группе приставили какого-то странного магического персонажа 🧙‍♂️ — фасилитатора. Он(а) вообще норовит превратить весь митинг в детскую игру с какими-то упражнениями. Нет бы просто хорошо поговорить и принять уже решение?

Давайте разберемся, зачем нужен фасилитатор. Начнем сразу с определения — задача фасилитатора, позаботится о том, чтобы каждый член в группе мог участвовать в решении вопроса лучшим образом ⭐️. Ни у кого не возникает сомнения, что лучшее решение группа может принять, тогда когда каждый из ее членов может себя проявить, верно?

Теперь по другому — у фасилитатора нет задачи помочь принять какое-то конкретное решение, фасилитатор не находится на чьей-то стороне. Он(а) просто помогают группе проходить процесс принятия хорошего решения. Сам, обычно, процесс состоит из нескольких частей — divergent zone, groan zone, convergent zone, closure zone. Сначала группа придумывает разные варианты решения проблемы; потом плотно их обсуждает, чтобы убедиться, что все понимают о чем идет речь; потом появляются лидирующие варианты, группа дорабатывает их и принимает решение.

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

⬛️ Еще раз — простые решения (business as usual) хорошо принимаются и без фасилитатора. Сложные решения тоже можно принять самостоятельно. А можно использовать роль фасилитатора, если кто-то выполняет эту роль, то он(а) помогает члену группы эффективно участвовать в решении проблемы. Фасилитатор, это не обязательно отдельный человек, член команды тоже может фасилитировать принятие решения.

Вы любите митинги с фасилитаторами?

#софтскиллы

👋,

Вчера мы начали (продолжили) говорить про то как здорово принимать решения группой людей и как с этим может помочь фасилитатор.

Сегодня хочу порекомендовать еще один канал, на который подписан сам — Нестыдная фасилитация. Канал ведут три Agile-эксперта — Саша, Женя и Оксана, они же — партнеры в проекте co-actors.

Я узнал об этом канале после подкаста 🎧 Podlodka #217 — Фасилитация, который, в принципе, обязателен к прослушиванию.

В канале девушки регулярно пишут обо всем, что связано с принятием решений и эффективной работе в команде. Эти темы актуальны не только для Agile-коучей, но и если вы разработчик или тимлид. Например:
* Как создать базовые договоренности в команде
* Когда у команды нет идей, что это может значить?

Хороший разработчик не индивидуалист, он работает в команде, и нам важно знать, как работать в команде эффективно.

Подписывайтесь: https://news.1rj.ru/str/no_shame_facilitation

Все стремится к энтропии

В каком-то источнике, я однажды прочитал, что в должностной инструкции Senior+ инженеров в Google указано, что часть их работы это “уменьшать хаос”. Сейчас, когда мне пришла идея этого поста, то я уже не смог найти источник, но это во мне срезонировало и я часто об этом думаю.

Мы разрабатываем информационные системы, это не только микросервисы или приложения, это еще и тесты, процессы, люди, железо. Весь этот механизм как-то пыхтит, скрипит, но работает. Но если его не трогать, то он точно когда-нибудь развалиться 🧨.

Существует даже физический закон “Закон неубывания энтропии” (беспорядка) — в изолированной системе энтропия не уменьшается. Информационную систему с внешними зависимостями сложно назвать стабильной. Поэтому, если перенести этот физический закон в наш абстрактный IT мир, то можно сделать вывод — если жизнь в нашей системе не поддерживать, то она точно сломается.

Проблема в том, что нельзя точно расписать все процессы, которые поддерживают в системе жизнь. Можно постараться, но все расписать точно нельзя. Если представить, что на каждое действие должен быть таск, то можно умереть ☠️ в бюрократии.

Это требует от Хорошего разработчика проактивности. “Правило бойскаута”, которое мы часто употребляем по отношению к коду — оставляй код как минимум столь же чистым, каким его принял, нужно распространять везде. Нужно каждый день уменьшать энтропию, а еще лучше — когда это делают все.

Примеры:
1. Заметил(а), что в README.md что-то уже не актуально? — удали
2. Заметил(а), что не хватает какой-то документации — добавь
3. Какой-то процесс не задокументирован? — напиши документацию
4. В Slack вашу команду о чем-то спросили? — ответь
5. Кто-то болел и потерял контекст? — созвонитесь и расскажите ему что произошло

Есть идиома "это последняя соломинка, которая сломает спину верблюду”. Одна из задач Хорошего разработчика это убирать эти соломинки, тогда спина нашего верблюда никогда не сломается.

Какие еще примеры приходят вам в голову?

#истории

CIDR

Хороший разработчик работает с инфраструктурой. Кто-то чаще, кто-то реже, но все сталкиваются с этим. Часть инфраструктурных задач связана с сетью. Например, мы хотим создать новую VPC (Virtual Private Cloud) на AWS и разместить там наши виртуальные сервера. Когда мы создаем VPC, нужно указать пул IP адресов, которые могут участвовать в этой сети, для этого нас просят указать CIDR блок.

CIDR (Classless inter-domain routing) нотация позволяет нам компактно указать какие IP адреса мы выделяем. Например 10.10.10.10/24 говорит нам, что можно выделять IP с 10.10.10.0 по 10.10.10.255, то есть 256. Но почему так? Я постоянно забываю принцип, по которому из строки можно получить пул IP. Давайте разберемся, может после этого и я запомню.

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

Теперь про сам IP — IP это четыре байта байт.байт.байт.байт , каждый байт состоит из восьми бит, их можно представить как десятичное число. Байт=11000000 это 192. Таким образом, мы понимаем, что IP это четыре раза по 8 бит, то есть 32 бита.

10.10.10.10 = 00001010.00001010.00001010.00001010.

Теперь возьмемся за /24 , 24 в этом случае это количество бит, начиная слева, которые НЕЛЬЗЯ менять, когда мы хотим получить новый IP. Эти биты являются адресом подсети. Т.е. когда мы выделяем новый IP из этого блока, то мы работаем с такой схемой: 00001010.00001010.00001010.*. У нас осталось 8 бит, чтобы выделять новые IP. В эти 8 бит поместится ровно 256 разных значений.

Теперь другой пример, мы хотим, чтобы наша сеть была маленькой, чтобы в ней было максимум 8 IP. Как мы это сделаем? Зафиксируем больше битов! 10.10.10.10/29. Тогда мы можем выделать IP с 10.10.10.8 по 10.10.10.15.

⬛️ Еще раз — когда нужно указать подсеть, мы используем CIDR. Если вы вдруг (опять) забыли, как это работает, то используйте онлайн калькулятор https://cidr.xyz .

#хардскиллы

Новости

В начале этой недели стали доступны результаты IT Salary Survey December 2021. Особенность конкретно этого опроса в том, что его участники, преимущественно русскоговорящие экспаты.

🔭 Наблюдения следующие:

* Большинство экспатов переезжают в Берлин. Определенно там и вакансий больше и ЗП повыше.

* Зарплаты растут, сейчас медианная ЗП составляет 75.000€, когда я переезжал была 60.000€.

* Total compensation практически никогда не отличается от базовой зарплаты больше чем на 10%. В Германии по-прежнему не распространено давать стоки. Обычно бонус это какой-то ежегодный процент от ЗП.

* Большинство ответов из Берлина, 20% из всех ответов питонисты. Они что там все переезжают data science делать в Берлин?

* Фрилансеры зарабатывают прям много, но у них и рабочих часов в году больше, чем у обычных работников. 2000 vs ~1800.

Остальное посмотрите сами, интересные наблюдения велком в комментарии.

Спасибо организаторам за проведение опроса 🤗.

#новости

VAPID цели

Было ли с вами такое, что вы задумали сделать что-то хорошее, но ничего не происходит? Например, вы подумали — надо больше читать. Действительно хорошая идея 💡.

Если мы хотим что-то сделать, то нужно поставить цель. А когда мы слышим про постановку цели в голову приходит одна аббревиатура — SMART. Цель должна быть Specific, Measurable, Attainable, Relevant, Time-Bound. Тогда шансы на успех повышаются.

Хорошо, мы теперь знаем (знали) как ставить хорошие цели, а что есть что-то наоборот? Как проверить, не поставили ли мы перед собой “плохую” цель? Решение есть. Недавно я узнал еще одну аббревиатуру — VAPID.

VAPID это:

Vague – Цель не ясна, шаги, которые нужно предпринять непонятны

Amorphous – Непонятно, что будет считаться достижением цели

Pie in the sky – Она очень амбициозна

Irrelevant – Цель сложно отнести к чему-то, что действительно важно для нас

Delayed – Не ясно когда планируется осуществлять намерение, это может произойти в любой момент

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

Пример VAPID цели — “давайте избавимся от технического долга”, “надо найти новую работу”.

⬛️ Еще раз — хорошо ставить цели используя SMART фреймворк. Чтобы убедиться, что с целью все в порядке — проверим не выглядит ли она как VAPID цель.

#софтскиллы

Как я промоутил без фактов

Как-то раз я работал тимлидом в команде. В мои обязанности входило не только деливери и техническое лидерство, но и непосредственно формальный менеджмент. Я временами проводил 1-1 (редко), давал людям фидбэк и участвовал в процессах эвалюэйшена.

Тогда процесс был такой — тимлиды заполняют документы на членов команд, собирают с них фидбэк, дают свой и делают вывод — как проявил себя человек в этом полугодии. Вариантов было три — below expectation, meets expectation, overachieved expectations. Если человек overachieved, то ему выплачивался бонус 💰, согласно контракту. Потом был митинг среди всех хэдов, где производилась калибровка, утрясались детали и утверждались результаты.

В моей команде, по моему мнению, был один человек below, два meets и один overachieved. Поговорим о последнем. На этого разработчика всегда можно было положиться, он брал на себя ответственность, разбирался с бизнес требованиями, предлагал улучшения, делал больше чем написано в тикете, было понятно чем он занят. В общем это был Хороший разработчик.

С этой информацией я, собственно, и подошел к калибрационному митингу. Это был первый подобный опыт для меня. На митинге мы быстро прошлись по below и meets — вопросов не было. Потом начали обсуждать overachieved. И тут меня спросили — а почему этот разработчик overachieved? Я рассказал про то же, что написал выше. Тогда меня спросили — а что конкретно сделал этот разработчик, как можно это измерить?

И тут я понял, что я в беде 📉. У меня не было ответа на этот вопрос. Для меня было очевидно, что он работает отлично. Я думал, что и для других очевидно, а если не очевидно, то они поверят моим словам. К сожалению, у меня не было подготовлено конкретных примеров (а лучше еще и слегка преувеличенных). Я попытался что-то быстро вспомнить, но это был провал. При этом я наблюдал, как другие хэды предметно нахваливали своих подопечных, тех, кого я бы не оценил, как Хороших разработчиков.

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

⬛️ Какой вывод можно сделать? Я делаю такой — нужно не забывать, что мы живем в информационном пузыре. Если что-то очевидно мне, это не значит, что это очевидно и другим. Если хочешь в чем-то убедить других, легче всего это делать, используя что-то, что можно измерить. Например, я мог сказать — разработчик N сделал рефакторинг пайплайна, теперь мы билдим проект за 5 минут, это сэкономило нам 20 часов в прошлом месяце. А его об этом даже никто не просил. Все нужно измерять, это пригодится.

#истории

Написал лонгрид для VC о том, как я в 2019 изобрел тесты в Instagram.

Будет интересно почитать всем любителям пет-проектов. У вас есть какие-то? Расскажите в комментариях.

Еще есть кросс-пост на Хабре, для ваших апвоутов 🤗.

Mutation testing

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

Мы можем тестировать компоненты отдельно с помощью unit тестов, мы можем тестировать как все работает вместе, с помощью интеграционных тестов. Но сколько тестов нужно? Чем сложнее приложение, тем больше сценариев, как оно может работать — тем больше тестов можно написать. Все сценарии покрыть невозможно. Но можно усилить свой quality assurance процесс дополнительно. Один из таких вариантов — применять mutation testing 🧟‍♂️.

Суть этого подхода проста. Специальная библиотека делает в вашем коде изменение (мутант) и запускаются тесты. Если ваши тесты упали, значит они убили мутанта ☠️. Если ваши тесты не упали, значит он выжил и нанес ущерб. Это что-то значит. Хотя бы следующее — либо изменение было сделано в мертвом коде, либо этот кусок кода не тестируется, либо ваши тесты плохо работают. Из этого уже можно сделать какие-то выводы и принять решения.

Какие изменения вносятся в код? Например, у вас в коде есть if(myValue == 50), мутант может выглядеть так if(myValue != 50). Мутант ведет себя как обычный баг.

Качество ваших тестов можно будет измерить ориентируясь на mutation score. mutation score = number of mutants killed / total number of mutants. Если mutation score низкий — нужно менять ваши тесты.

Что можно использовать:
* Stryker — для JavaScript, C#, Scala
* Pitest — для JVM языков
* Mull — для C или C++
* mutmut — для Python

⬛️ Еще раз — тесты это классно. Их нужно писать. Если хотите контролировать, что ваши тесты действительно что-то проверяют, добавьте mutation testing.

#хардскиллы

Моя страна атакована, мой город атакован, не хочу делать вид, что этот канал вне политики.

Сегодня Путин объявил войну Украине, мотивируя свои действия идеями "денацификации". Это полная чушь и не имеет ничего общего с реальностью. Когда я жил в Украине я ездил в Донецк и отлично проводил там время. Я ездил во Львов, говорил там по-русски, и отлично проводит там время. Народ Украины и власть, которую украинцы выбрали в ходе демократических выборов, хочет одного — жить мирно и счастливо.

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

Я знаю, что в этом канале много россиян. Посмотрите обращение президента Зеленского к россиянам (на русском с 02:03).

Всех призываю помочь фонду "Повернись живим". Это можно сделать тут:
* https://www.patreon.com/savelife_in_ua
* https://savelife.in.ua/donate/

Переживаю, но верю в будущее 🇺🇦

Работа с тревожностью

Разработчики много переживают. Особенно сейчас 💙💛. Тревожность (anxiety) сковывает, мешает делать свою работу, кидает тебя в объятья думскроллинга. Именно так я провел вчерашний день.

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

Хочу порекомендовать апп Sayana. Я узнал о нем около месяца назад, на фоне новостей о том, что Headspace купили его. В приложении простая механика - вы делаете чекин, отмечаете как себя чувствуете (тревожно, спокойно, счастлив, устал и т.п.), можете сделать заметку из-за чего. А после этого, апп рассказывает вам что-то полезное. Например, о простой практике с фокусом на когнитивно-поведенческую терапию или что-то про когнитивные искажения или просто историю.

Например, упражнение Breathing daisy 🌸. Если дышать в темпе вдох 4 секунды и выход 4 секунды, то тело подумает, что вам спокойно и вы тоже успокоитесь.

Еще мне понравилась притча оттуда:

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

⬛️ Еще раз — можно переживать, можно не переживать, но лучше быть осознанным и понимать, почему ты чувствуешь то, что чувствуешь. С этим может помочь практики когнитивно-поведенческой терапии.

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

#софтскиллы

Пятый день войны 💙💛

Моя мама только что рассказала, что в дом 60 метров от нашего дома в Харькове прилетел разгонный блок ракеты. Поврежден первый этаж дома. Это обычный жилой квартал, рядом больница.

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

С сегодняшнего дня КАЖДЫЙ россиянин тоже чувствует эффект — рубль обесценивается. Весь прогрессивный мир объединился и стоит на стороне Украины. Благодаря действиям вашего правительства, ваше будущее ставится под сомнение. Не жизнь, а БУДУЩЕЕ и будущее ваших детей.

В 21-ом веке страны не умеют делать все в одиночку. Нельзя в одиночку написать хороший софт, сделать телефон, нельзя придумать компьютер, нельзя построить спутник и колонизировать Марс. Импорт технологий в Россию уже ограничен. Из-за действий человека, который даже не использует интернет, ограничиваются ваши свободы, возможности, фактически ухудшается качество вашей жизни. Ради чего?

Россия ведет полноценную войну в Украине. "Умные" ракеты и точечные удары закончились в первый день, применяется оружие неизбирательного действия. За время войны на территории Украины уже погибло 16 детей. Гибнут и попадают в плен ваши солдаты. Солдаты не мотивированы воевать, даже они не понимают смысла происходящего.

Россияне, тут нет второго варианта, вы НЕ ХОТИТЕ войны, потому что вы хотите будущего. Хороший разработчик не хочет войны, потому что он хочет развития. Каждый должен делать что-то, что в его силах, чтобы остановить войну. Вы не хотели этой войны, но теперь эта война и ВАША ответственность. Распространяйте информацию, это минимум. Посмотрите как мирные жители встречают ваших солдат.

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

Комментарии под этим постом оставляю открытыми. Мир уже изменился, нет никаких "других" площадок. Все площадки должны говорить о войне и о том как ее остановить!

Украина будет свободной!