Критическое мышление, когда сделаешь

Я за последние годы выработал один лайфхак - какие-то важные value-задачи сделать и после нажатия кнопки send очень быстро видишь любые косяки и быстро исправляешь.

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

Или составляем кастомный договор для клиента на крупную сумму, и как только я открываю gmail и закачиваю договор - мгновенно вспоминаю где еще я забыл проверить что-то (и нахожу, быстро исправляя найденный косяк). То есть суть хака в том, что до value-event (отправить пост, загрузить аттач) мозг еще в режиме value creation, а не critical check.

Вместо того, чтобы очень долго (часами/днями) быть в терзаниях нормально ли замутил штуку, делаешь «хуяк и в продакшн».

То же самое по софту - можно много сидеть над тестированием фичи (и конечно же что-нибудь найдешь), но стоит задеплоить апдейт - резко вспомнишь, что забыл «вон ту штуку проверить».

Кстати, именно так я воспринимаю фразу «Done is better than Great”.

Трамп: Илон, какое министерство ты хочешь возглавить?
Маск: DOGE!
Трамп: Ни слова больше!

История борьбы с зависаниями системы

Давно боролся с глухими, рандомными зависаниями системы. Уже поменял SSD, хотя старый был ещё в нормальном состоянии. Поменял систему с Ubuntu на Windows. Провёл кучу диагностики, но ничего не помогало. В логах находились ошибки, но они не были связаны с зависаниями. Было ясно, что это не программный глюк.

Проверил оперативную память через memtest86+ — всё оказалось в порядке. Поиск зашёл в тупик.

Однако вчера, в очередное зависание, я решил переключить *tty* через комбинацию Ctrl + Alt + F1-5. И вот оно! Segfault на всех процессах.

Закинул ошибки в ChatGPT. Он предложил ещё раз проверить память. Но, так как memtest86+ ничего не показал, я поискал другой инструмент и нашёл stressapptest.

stressapptest -W -v 20 -M 12192 -s 3600

Эта утилита богов сразу показала проблему:

2024/12/03-01:37:39(MSK) Report Error: miscompare : DIMM Unknown : 1 : 24s
2024/12/03-01:37:39(MSK) Hardware Error: miscompare on CPU 11(<-7) at 0x736213902600(0x601:DIMM Unknown): read:0xffffbfffffff00ff, reread:0xffffbfffffffbfff

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

Мораль: При любом диагнозе ищите второе мнение! 🛠

Перестал открываться гугл, чатгпт и еще куча зарубежных сайтов, dns 8.8.8.8 не помогает, есть какие то новости? VPN не включен.

То ли плакать, то ли смеяться...

Я так понимаю планируют что то такое...

Кто так же ревью делает?

Вот серьезно, кто может по git diff сделать ревью? Ну максимум там совсем какую то дичь видно. А так без переключения на ветку, без запуска, без понимания в контексте что делает код, ревью сводится к бесполезной трате времени или формальности.

Turbo v2

Третьего дня(c) решил обновить Turbo до 2 версии. Очень уж глаза мозолило сообщение при запуске билда.

Миграция - мое почтение, всем бы так

yarn dlx @turbo/codemod migrate

Команда бодро отработала с первого раза, не упала, все ок.

Локально все билдилось замечательно, но пошли падать CI\CD билды.

Все указывало на то, что что то случилось с переменными.

Оказалось, что в Turbo 2 появилась (а может и раньше была с другим поведением) фигня, которая ограничивает использование env до указанных в конфигурации, или которые лежат в файле .env. При этом все переменные окружения игорируются!
И чтобы справится с этим, нужно при запуске задач ставить

--env-mode=loose

Вот такая вот охуительная автоматическая миграция

Хеви металл, который мы заслужили

Теперь ты можешь слушать металл и учить Java.
Итальянцы Nanowar спели код)

Ссылка на ютуб тоже есть
https://www.youtube.com/watch?v=yup8gIXxWDU

P.S. Концовка убила..

Если вдруг у вас сегодня перестала билдиться призма на alpine, посмотрите эту issue https://github.com/nodejs/docker-node/issues/2175

Отрицательные даты

Сегодня была ржакаобоссака у нас в Funlee.
Значит прилетает с утра 3 оплаты за год, мы такие "ура открываем шампанское!"
Тут дизайнер прибегает, "эй, какого х.. вы у меня с карты пытались 27к списать??!!!!1111"
Я такой - "так, подержи мой бокал", начинаю проверять, смотрю аккаунт знакомый, смотрю значит свой телефон, а у меня там успешно списано 27к.

Тут еще бро пишет, "Э брат, вы чо ох..ли там? Почему у меня с карты улетело на ваш сервис 27к?, при том что у меня промокод бессрочный на 99%??!!!".
Ну кароч сделали возвраты, стали разбираться. Поняли, что это вообще оплата за месяц, а не за год :)
Но тесты же, сука, проходят...

Ну я попросил ребят разобраться, но как обычно (был послан на...), пошел разбираться сам.

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

 // Когда заканчивается скидка по промокоду.
      const discountEnds = dayjs(promocode.appliedDate)
        .add(promocode.durationMonths ?? 0, 'months')
        // Добавляем резервный период. Он позволяет менять тарифный план и опции после применения промокода.
        // Если пользователь применил промокод и оплатил тариф, а через день хочет поменять тариф на другой,
        // то без этого периода промокод применён не будет (хотя в теории ещё есть 29 дней).
        .add(promocode.daysLimitForPromoUse ?? 14, 'days');
      const monthsLeft = dayjs(discountEnds).diff(dayjs(now), 'months');

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

Как жаль, богатство было так близко...

Я вот сегодня заметил, что Codeium стал подсказывать какую то лютую дичь. Ну то есть больше мешать, чем помогать, контекста вообще не понимает железный болванчик. Что посоветуете вместо?

Key в React

Мы привыкли, что key используется только для рендера списков. Но использование key не ограничивается только этим.

Изменение key показывает React что это другой компонент, и необходимо старый размонтировать, а новый замонтировать.

Мы например можем добавить prop key к компоненту формы

<UserForm key={userId} />

Таким образом если userId изменится, то вся форма размонтируется и смонтируется новая форма, и нам не придется обнулять значения формы руками при изменении пользователя.

BEARlogin dev

#react #advices #собеседования

Только я решил сузить тему канала до React\JS\TS, но не могу не поделится этим лайфхаком.
Кароче, когда режете лук, в рот воды наберите, и глаза болеть не будут!
Это какая долбаная магия, но работает!

setState функция в React

Допустим у нас есть какой то state.

const [count, setCount] = useState(0);
return <SomeComponent setCount={setCount} />

Так вот, setCount не нужно оборачивать в useCallback (некоторые так делают) при передаче его как пропс в дочерний компонент.

React гарантирует, что функция setState не изменится между рендерами.

Так же не нужно добавлять ее в зависимости useEffect, useMemo и useCallback.

Если не верите, то добавьте

useEffect(() => {
  console.log('It has changed!!!!! AAAAAaaaa!!!!11111')
},[setCount])

Но если я вдруг ошибаюсь, и кейс мемоизации сетера действительно существует, то напишите в комменты :)

BEARlogin dev

#react #advices #собеседования

SRP как много в этом звуке...

Буква S в SOLID вызвала больше холиваров и разбитых лиц чем React vs {anyFrontendFramework}.

Его классическое определение - Класс должен иметь лишь одну причину для изменений.

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

Но к счастью для нас он уточнил потом в Clean Architecture

Модуль должен отвечать перед одним и только одним актором.

Тоже нихера непонятно, но уже можно размышлять. Что есть актор?

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

Каждый актор — это внешний драйвер, который влияет на твою логику.
И вот что важно: модуль должен обслуживать только одного актора.

Понятней не стало?

Ок, приведем пример:

class OrderService {
  createOrder(orderData) {
    // Покупатель создает заказ
  }

  getOrderDetails(orderId) {
    // Покупатель и менеджер получают информацию о заказе
  }

  updateOrderStatus(orderId, status) {
    // Менеджер меняет статус заказа
  }

  cancelOrder(orderId) {
    // Покупатель отменяет заказ
  }
}

Представим, что нам нужно для пользователя добавить возможность указать комментарий к заказу.
Мы идём в OrderService и меняем его.

А теперь нужно дать менеджеру возможность перенести доставку на другую дату.
Мы снова идём в OrderService и меняем его.

И вот тут всё встаёт на свои места. Вот она "причина" для изменений. Это вот этот самый актор — драйвер изменений.
Итог: два актора на один класс. На лицо нарушение принципа SRP.

Что делать?

Разделить сервисы, чтобы они работали только с одним актором.

// Модуль для покупателя
class CustomerOrderService {
  createOrder(orderData) {
    // Логика создания заказа
  }

  getOrderDetails(orderId) {
    // Логика получения деталей заказа для покупателя
  }

  cancelOrder(orderId) {
    // Логика отмены заказа
  }

  createOrder(orderData) {
    // Логика создания заказа для покупателя
  }
}

// Модуль для менеджера
class ManagerOrderService {
  getOrderDetails(orderId) {
    // Логика получения деталей заказа для менеджера
  }

  updateOrderStatus(orderId, status) {
    // Логика изменения статуса заказа
  }

  changeDeliveryDateTime(orderId, dateTime) {
    // Логика изменения доставки
  }

  cancelOrder(orderId) {
    // Логика отмены заказа
  }
}

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

SRP не про то, что делает класс, а про причину его изменений. Про, если хотите, заказчика, драйвера этих изменений.

P.S. Вы могли заметить, что для соблюдения SRP нам пришлось дублировать методы. А как же DRY??!!
Я мог бы сказать перефразируя цитату классика

Он нам и нах... не нужон DRY ваш!

Но не буду, и расскрою эту тему в дальнейших постах, так как в архитектуре все зависит от контекста(с).

STAY TUNE)

BEARlogin dev — подпишись!

#архитектура #advices #solid