Martin Fowler Blog: Slack

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

Проблема этого подхода в том, что у команды не остается буфера для внезапных задач, рефакторингов, налаживания процессов. Вместо этого предлагается ввести Slack (наверное корректный перевод будет зазор, но я не уверен). Т.е. планировать заведомо меньше, чем обычно делает команда. Например, команда на протяжении последних N итераций делала 30 работы, но минимальное значение было 20 - давайте планировать итерации на 20, а все остальное - это зазор.

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

https://martinfowler.com/bliki/Slack.html

#managment #martinFowler #estimation #velocity #process

​​📖 Я наконец-то попробовал ChatGPT

Я не особо успеваю за трендами, поэтому попробовать ChatGPT дошли руки только сейчас.

Регистрировался по инструкции из статьи.

- Перед регистрацией почистил куки браузера
- В качестве VPN использовал VeePN-расширение для хрома
- Для регистрации использовал свой google аккаунт
- Пользовался сервисом OnlineSim для регистрации иностранного номера чтобы получить SMS код для регистрации
- Пополнил счёт на 50 рублей через СБП
- Пользовался Нидерландским номером для регистрации, который купил за $0.54
- Без VPN не могу зайти на сайт ChatGPT
- Переодически нужно перезагружать страницу

Я попросил его написать пост на основе текста, который вы прочитали выше и вот что получилось

#chatgpt #fridayreading

​​📖 Процесс ревью кода структурно порочен. Вот, как его исправить

На ревью слишком много времени тратится на переключение контекста и ожидание автора и ревьера:
- После создания PR’а, мы ждём, когда ревьюер закончит свои дела и изучит код автора.
- Если необходимо внести изменения, то приходится ждать, когда вернется автор и внесет изменения, ведь скорее всего он уже занимается следующей задачей.
- И всё повторяется снова до тех пор, пока качество не удовлетворит ревьюера.

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

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

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

Как решить?
- Обсудить план решения с более опытным коллегой, чтобы в дальнейшем пришлось меньше переделывать
- Произвести первое ревью, когда изменения готовы на 30-50%. Скорее всего ваш план не сработал на 100%, поэтому ваши видения с ревьюером снова разошлись, поэтому нужно снова провести ревью. Здесь необходимо смотреть на концепцию решения задачи и не придираться к небольшим ошибкам.
- Чтобы сократить время ожидания ревьера можно ввести роль дежурного по ревью. Как только появляется PR, ревьер сразу же приступает к ревью. В свободное время ревьюер занимается низкоприоритетными задачами: техническим долгом или неважными багами.

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

#fridayreading #codereview

​​🧮 Задача на знание this в JavaScript

Иногда на собеседованиях дают подобные каверзные задачи, в которых необходимо хорошо понимать, как работают одновременно: стрелочные функции, контекст this и замыкания. Вот одна из задач, которую мне давали на собеседовании пару лет назад.

Что будет выведено в консоль?

function foo() {
  const x = 10;

  return {
    x: 20,
    bar: () => console.log(this.x),
    baz() {
      console.log(this.x);
    },
  };
}

foo.x = 50;

const obj1 = foo();
obj1.bar(); // ?
obj1.baz(); // ?

const obj2 = foo.call({ x: 30 });
const x = obj2.bar;
x(); // ?
obj2.bar(); // ?
obj2.baz(); // ?

Необходимая теория для решения задачи
- this - контекст вызова функции. Если метод вызывается не на объекте, то this — глобальный объект window, иначе this указывает на объект, на котором был вызван метод.
- У стрелочной функции нет собственного this. Если внутри стрелочной функции идёт обращение к this, его значение, как и обычная переменная, берётся из внешнего лексического окружения.
- Если метод объекта присвоить переменной, и вызвать такую переменную-функцию, то контекст потеряется и this будет ссылаться на window. Но это не работает в случае стрелочной функции, так как у неё нет собственного this, поэтому и потерять она его не может.

Разбор задачи построчно
6. bar — стрелочная функция, this берётся из лексического окружения
7. baz — обычная функция, поэтому this будет ссылаться на возвращаемый объект
15. Так как функция foo вызывается не на объекте, то this в этом случае равен глобальному объекту — window.
16. Так как стрелочная функция берёт this из лексического окружения, то this = window. В консоль будет выведен undefined, потому что на window не определено свойство x.
17. Функция baz реализована с помощью обычной функции, поэтому в данном случае this ссылается на сам объект. В консоль будет выведено 20.
19. Здесь явно указывается контекст вызова функции — объект { x: 30 }
20-21. Так как метод bar реализован с помощью стрелочной функции, то контекст в данном случае не теряется. Используется контекст из лексического окружения — { x: 30 }. В консоль будет выведено 30.
22. Вызывается тот же метод bar, логика точно такая же. В консоль будет выведено 30.
23. Явное указание контекста при вызову функции foo никак не влияет на функцию baz, так как метод вызывается на объекте, и контекстом будет являться данный объект. В консоль будет выведено 20.

Ответ ⬇️
undefined
20
30
30
20

Теория по теме
- Повторяем стрелочные функции
- Конструктор, оператор "new"
- Методы объекта, "this"
- Привязка контекста к функции

#javascript #interview

📖 Выравнивание последнего элемента по правому краю с помощью flexbox

Сегодня хочу порекомендовать короткую, но очень полезную статью о флексбоксах How to Align Last Flex Item to Right.

Довольно часто необходимо сверстать UI, в котором все элементы выровнены слева, и только один необходимо выравнять по правому краю.

Раньше я делал так:
- Создавал 2 div’а-обёртки
- Всё что должно быть слева клал в левый div
- Элемент, который должен быть справа, клал в правый div
- К родительскому элементу применял justify-content: space-between

Это решение всегда работает, но можно обойтись и без div’ов-обёрток. Всё, что нужно сделать — применить margin-left: auto к элементу, который должен располагаться справа.

Вот простой пример разметки из трех элементов и соответствующий CSS-код, где последний элемент выравнивается по правому краю.

HTML разметка:

<div class="flex-container">
  <div class="flex-item">Первый элемент</div>
  <div class="flex-item">Второй элемент</div>
  <div class="flex-item align-right">Последний элемент</div>
</div>

CSS код:

.flex-container {
    display: flex;
}

.flex-item {
    border: 1px solid black;
}

.align-right {
    margin-left: auto;
}

💡 Пояснение
Дело в том, что всё свободное пространство будет распределено между auto-маржинами. Подробнее можно почитать в спеке флексбоксов Aligning with auto margins.

#html #css #flexbox #fridayreading

​​🧮 Задача на знание замыканий в JavaScript

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

/** 
* Нужно написать функцию, которая принимает число N и возвращает функцию,
* вызов которой первые N раз возвращает 'yes', а потом – 'no'.
*/
function canGetCount(n) {
    // code here
}

const getOne = canGetCount(2);
 
getOne()  === 'yes'
getOne()  === 'yes'
getOne()  === 'no'

#javascript #interview

https://github.com/localtunnel/localtunnel

npx localtunnel --port 3000

Бесплатная и простая альтернатива ngrok - возможность пошарить локальный сервер по публичному адресу. Удобно, что бы быстро показать результат работы, пока она не доделана.

🎬 Backend-Driven UI

Сегодня посоветую доклад с HolyJS — Виталий Полещук, Стёпа Михайлюк — Server-driven UI в вебе. Не пиши, а описывай свой фронтeнд

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

Backend Driven UI представляет собой подход, в котором бэкенд говорит клиенту, как должен выглядеть интерфейс. В случае с формами, например, может передаваться массив элементов, где у каждого элемента есть тип:

- header
- select
- checkbox
- …

клиент проходится по этому массиву и рендерит соответствующий UI компонент. Таким образом реализация компонентов находится на фронте, а их расположение и взаимодействие на бэке.

👍 Основные преимущества Backend Driven UI

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

Ещё по теме:
- Яндекс выпускает DivKit — фреймворк для server-driven UI с открытым кодом

#fridayreading #frontend #architecture

🍎 Хочу поделиться Apple Shortcuts для добавления в инбокс Notion

Хочу поделиться с вами отличной находкой, связанной с Apple Shortcuts. Год назад я упоминал, что с помощью Apple Shortcuts можно с легкостью добавлять записи в базу ноутшена, например, я использую её для добавления записей в мой инбокс.

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

Чтобы настроить это, вам нужно сделать всего лишь несколько шагов (скриншот в комментариях):

1. В блоке "Text" вставьте идентификатор вашей базы вместо "<your database id>".
2. В блоке "Get contents of" вставьте ваш секретный токен интеграции вместо "<your secret token>".
3. Вместо "Name" укажите название вашего поля, если оно отличается.

Я подготовил два шаблона для добавления записей, чтобы вам было проще начать использовать это:

- Команда для добавления записи текстом
- Команда для добавления записи голосом

Инструкцию по настройке команды с нуля можно найти здесь.

Если будут вопросы — пишите, будем разбираться.

#notion #nocode #automation

📖 Неделя после пуска или Cooldown week

Как часто после очередного спринта вы чувствуете, что

- в одном месте не успели отрефакторить
- в другом месте не успели дописать документацию
- где-то осталось пару багов, которые было бы неплохо пофиксить
- нужно рассказать команде о важных (или не очень) архитектурных изменениях или базовых компонентах, которые были добавлены

Кроме того, вам в любом случае нужно время между релизами, чтобы

- подвести итог прошлого релиза
- запланировать следующий

В этом случае вам подойдёт Cooldown Week подход (Неделя после пуска), который поможет вам закрыть все недоделки (или, по крайней мере, самые важные из них), прежде чем погрузиться с головой в новый спринт.

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

Такой подход используется в Basecamp и в Бюро Горбунова

- Basecamp — How we work — Cooldown
- Бюро Горбунова — Как оценивать доработки после запуска?

#processes #fridayreading #planning

​​❓Как восстановить удалённый коммит в Git?

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

Потом понял, что закоммитил в мастер, а не в ветку с фичей. Поэтому сделал git reset --soft, чтобы удалить коммит, сохранив все изменённые файлы, и переключился в фича ветку.

Если ветки сильно отличаются, то иногда приходится делать git clean -fxd, чтобы удалить все ненужные артефакты. И тут я понял, что удалил все свои изменения.

Повезло, что перед этим я закоммитил свои изменения, хотя коммит и был удалён. Ведь git позволяет восстановить удалённые коммиты. Для этого я сделал:

git reflog

Нашёл в списке хэш моего коммита и перенёс из него все изменения в текущую ветку с помощью: git cherry-pick —no-commit <hash>

#git

📖 О бизнес процессах и авторитаризме

На майских праздниках я наконец-то дочитал книгу “Авторитарная Россия. Бегство от свободы, или Почему у нас не приживается демократия”.

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

💡 Мысль

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

Как указывает автор, “Авторитаризм может быть подобен швам или гипсовой повязке, которые на время позволяют срастись разорванным тканям и дают тем самым травмированному организму время и шансы на то, чтобы укрепить свой потенциал для “выращивания ” новых правил игры”.

То есть, государство тем или иным образом берёт все рычаги власти в свои руки и наводит порядок “жёсткой рукой”. Таким образом временно (опять же, в лучшем случае) происходит отклонение от демократии в сторону авторитаризма.

💼 Ассоциации с бизнес-процессами в компании

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

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

👀 Пример

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

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

P.S. Главное не слишком сильно закручивать гайки, иначе весь механизм разлетится вдребезги.

#processes #book #politics #fridayreading

📖 What developers need to know about Chrome's Memory and Energy Saver modes - Chrome Developers

В конце прошлого года в Google Chrome появились 2 новых режима

- Memory Saver (Экономия памяти)
- Energy Saver (Энергосбережение)

Они позволяют более гибко управлять использованием системных ресурсов браузером.

🔸 Memory Saver: Этот режим автоматически освобождает неиспользуемые фоновые вкладки, чтобы освободить память для активных вкладок и других запущенных приложений. Но для сложных сайтов с интерактивностью это может привести к проблемам восстановления состояния страницы.

🔸 Energy Saver: Режим Energy Saver позволяет браузеру снизить частоту обновления экрана для экономии заряда батареи. Обычно, для большинства сайтов, не требуется внесение изменений, но если вы используете JavaScript-анимации, имейте в виду, что они могут замедлиться.

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

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

- Периодически, когда состояние изменяется
- Когда вы переходите на другую вкладку, по событию visibilitychange

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    storeState();
  }
});

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

- Для этого можно открыть в адресной строке chrome://discards и для нужно вам вкладки использовать кнопку Urgent Discard.
- Инструменты автоматического тестирования пока не помогут вам протестировать эти режимы с помощью автотестов. Но вы можете использовать простую перезагрузку страницы, она почти полностью идентична выгрузке вкладки. Разница лишь в том, что при выгрузке вкладки, события beforeunload, pagehideи unload не будут вызваны.

Подробнее можно почитать в статье

#javascript #browser #frontend #fridayreading

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

- Хабр
- Яндекс Дзен
- ВК
- Пикабу

Вам не сложно, а мне приятно 🙂

#about_me

📖 Why I’ve stopped exporting defaults from my JavaScript modules

Сегодня на повестке статья из далёкого и спокойного 2019 “Why I've stopped exporting defaults from my JavaScript modules”.

В статье автор предлагает отказаться от экспортов по-умолчанию в JavaScript. Я бы выделил 2 причины, которые кажутся для меня наиболее важными:

1️⃣ Дефолтные экспорты не указывают имя функции или класса, которую вы импортируете, что может (и будет) вызывать неконсистентность в именовании.

В одном файле вы можете указать имя LinkedList

import LinkedList from "./linked-list.js";

А в другом файле, другой разработчик может указать имя List

import List from "./linked-list.js";

В случае с именованными экспортами, вы не можете просто присвоить рандомное имя, оно должно совпадать с именем экспортируемой функции/класса/объекта

import { LinkedList } from "./linked-list.js";

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

2️⃣ Когнитивная нагрузка замедляет разработку. Если вы используете дефолтные экспорты, вам придётся самостоятельно, каждый раз указывать название импорта. В случае с именованными экспортами ваша IDE наверняка подскажет вам имя, как только вы начнёте печатать и вам останется лишь нажать Enter.

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

⚠️ Исключения

К сожалению, в некоторых ситуациях нельзя использовать именованные экспорты. Одним из примеров может служить React.lazy(() ⇒ import('../path')) используемый для код сплитинга и ленивой загрузки.

🤖 ESlint

Чтобы убедиться, что все разработчики используют именованные экспорты, вы можете использовать правило import/no-default-export

Когда я добавлял это правило в наш проект, я наткнулся на GitLab issue, где команда Гитлаба планировали перейти с дефолтных экспортов на именованные. Они также ссылаются на эту статью.

- Оригинал на английском
- Перевод на русский

#linters #eslint #javascript #architecture #fridayreading

​​Проверка именования файлов и папок с помощью плагина eslint-plugin-import

Во время код ревью, можно заметить, что мы часто оставляем одни и те же комментарии об именованиях или каких-то соглашениях (которые описаны в вики, и которые никто не читает). В такой момент, нужно задуматься можно ли эти проверки как-то оптимизировать. Например недавно я писал пост о том как контролировать импорты в JS с помощью import/no-restricted-path. Сегодня я хочу рассказать о проверке именования файлов и папок.

Наверняка в вашем проекте есть какая-то определённая структура организации папок, например, это могут быть папки:

- /models
- /services
- /stores
- /pages

И скорее всего все файлы в этих папках должны иметь определённый суффикс:

- Model
- Service
- Store
- Page

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

- Helper/Helpers
- Util/Utils
- Utility/Utilities

Чтобы избежать всей этой путаницы и обеспечить единое именование файлов можно использовать плагин eslint-plugin-import

Плагин содержит несколько плавил:

1️⃣ check-file/filename-blocklist

Синтаксис следующий — вы описываете объект, у которого:

- ключи — запрещённые паттерны
- значения — тот паттерн, который рекомендуется использовать.

Например, если мы хотим обеспечить единое именование утилитных методов, чтобы все они оканчивались на `Utils`, то нам нужно запретить использование суффиксов: Helper, Util, Utilities. Также, нужно учесть, что:

- Первая буква может быть как в верхнем, так и в нижнем регистрах
- Все суффиксы могут быть как в единственном, так и во множественном числе

Описание такого правила будет выглядеть так:

plugins: [
  'check-file',
],
rules: {
 "check-file/filename-blocklist": [
      "error",
      {
    "**/*+([Hh]elper?(s|*)|[Uu]til|[Uu]tilitie?(s|*)).ts": "*Utils.ts"
      }
  ]
}

2️⃣ check-file/folder-naming-convention

Это правило позволяет нам задать паттерн именования папок:

- ключ — паттерн для папок, которые необходимо валидировать
- значение — паттерн, которому папки должны удовлетворять. В нашем случае, паттерну удовлетворяют все папки, которые не называются Helpers, Util, Utilities.

"check-file/folder-naming-convention": [
      "error",
      {
        "src/**/": "!([Hh]elper?(s|*)|[Uu]til|[Uu]tilitie?(s|*))"
      }
    ]

Все правила описываются с помощью glob-паттернов). Протестировать свой паттерн можно тут.

#linters #javascript #archtecture

Как правильно “придираться” во время код ревью

Когда вы проверяете код своего коллеги не нужно требовать от него “идеального” кода.

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

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

ℹ️ В стандартах код ревью гугла, описано, что в таких ситуациях можно использовать префикс NIT, в комментариях к пул реквесту. NIT — сокращение от “nitpick” или “придираться”.

❓В каких ситуациях стоит использовать NIT

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

Подробнее об этом можно почитать здесь:

- The Standard of Code Review

#codereview #fridayreading

Нужно выстраивать правила игры, добиваться их принятия и играть по ним

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

🔄 Ситуация

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

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

✍️ Как?

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

☄️ Возвращение к договорённостям

Часто бывает, что кто-то не следует правилам и всячески их игнорирует. В таком случае нужно "возвращаться к договорённостям", напоминая о правилах. "Мол, помнишь, мы всей командой договорились, что будем придерживаться этого подхода? Если ты считаешь, что нам это не нужно, то подготовь аргументы и расскажи всей команде, почему этот подход плох, и мы должны перестать ему следовать". Вряд ли кто-то захочет напрягаться, и проще будет следовать правилам.

⚠️ Но все это будет работать только если ваша команда играете по правилам.

🎭 Аналогия

Эти правила можно рассматривать как законы в стране, по которым должны играть все граждане. Если тем или иным политическим группам что-то не нравится, они могут продвигать нужные им законы (не всегда хорошие), чтобы изменить правила игры.

❌ Чего делать не стоит

Многие, вместо того чтобы что-то сделать, просто жалуются из раза в раз. Иногда, чтобы привести таких людей в чувства, можно их спросить: "Окей, мы можем это изменить?" Если ничего изменить нельзя, то смысл жаловаться? Это только демотивирует, раздражает и никоим образом не влияет на те самые "правила игры".

——

Кстати, о планировании технического долга я писал вот тут.

#processes #technicaldebt

📖 Примеры использования Chat GPT

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

Автор делится шаблонами и рассказывает:

- Как генерировать вопросы для интервью
- Генерировать и валидировать идеи
- Составить план-презентации
- Писать SQL запросы
- Генерировать Excel и Google Sheet формулы

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

- Нахождения задач на Leetcode описанных в курсе, чтобы потренироваться прежде чем читать разбор решения. Chat GPT выдаёт название задачи (иногда даже вместе с ссылкой), которая появится первой в списке поиска гугла.
- Для перевода C++ и Python кода на JavaScript, ведь намного приятнее читать примеры кода на языке, который ты знаешь.

Также я использовал Chat GPT для генерации glob паттернов. Хотя в этом он оказался не так уже хорош.

#fridayreading #chatgpt #algorithms #ai