Вот зачем я стал программистом.

Пока все будут искать готовые решения, я напишу свою мелкую утилитку с дебагом и dry-run.

Вот за это я очень люблю nodejs — быстро писать код и быстро использовать. При этом в этом микропроекте ни одной зависимости.

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

Скоро всем раскатятся спойлеры и реакции в телеграме!
Обновляйтесь))

Переверстали менюшки, иконки дергаются.

Как потратить 3 часа на конвертацию svg-иконок в typescript forest.

При этом заюзав unified, rehype и babel.

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

https://gist.github.com/sergeysova/33061985430617c417fb90915e4f29df

А теперь вопрос знатокам forest.

В объекте icons у меня лежат компоненты-иконки. Для каждого проекта иконка прилетает из интернетов, то есть заранее статически я не знаю какая именно.

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

Может есть более красивый вариант? мб заюзать variant или route?

Если вдруг кто-то не слышал, что там с faker.

https://snyk.io/blog/open-source-npm-packages-colors-faker/

Еще больше панелей надо… а то я до сих пор контент могу читать, осталось 3 строки закрыть

Юбилейный десятый выпуск рассылки!

Не забывайте о существовании реакций)
https://news.sova.dev/issues/10-931476

Открыл для себя fig.io

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

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

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

А это значит, что бизнес-логику можно попробовать определить так:
код, который не объясняет зачем он реализует определенную логику, скорее всего является бизнес-логикой. Иначе он должен быть предельно понятным.

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