Хотел я написать небольшую статейку на тему, как скрестить effector и Sentry. Мои любимые коллеги выдвинули такое требование и идеи, дополнительно я провел опрос среди участников русского эффектор комьюнити. Сел делать, сделал, отправил на ревью, и … мое решение развернули и на самом деле по факту, было много дыр в производительности, и пришлось решать все чистым джаваскриптом. Нос не вешаю, эта ситуация помогла найти мне микро недостаток у Sentry, я пошел и сделал PR к ним в GitHub, +1 монетка в копилку опенсорсера.
Когда нибудь я сяду, потрачу время, но доведу эту идею до конца, закрыв все недостатки, потому что в интернете такой информации НЕТ.
Мир потерял статью об effector+sentry, но приобрел улучшение библиотеки которой пользуется много людей.
- - - - - - -

#Хроника_разработки
Хочу написать несколько постов в формате заметок, больше даже наверное для себя, чтобы в дальнейшем сделать некий look behind, но и для вас я тоже думаю будет интересно почитать именно про опыт и ощущения.
- - - - -
Проект над которым я сейчас работаю помимо основной работы - портал для публикации студентами моего ВУЗа своих портфолио.
Все началось с выбора стека. В основном технологии выбирались по принципу "хочу потыкать" - Next JS, Prisma, PostgreSQL. Еще до кучи обернул все это в докер.
Что могу сказать про начальный этап - сложно!
Куча разной по свежести и скиловости инфы, каждый варит конфиги как хочет, непонимание как "правильно" изза того что никогда с этим не работал. Пробы и ошибки, тяп ляп, запустилось - выдохнул.
Дальше по плану была авторизация, принципиально не хочу смотреть видосы, вывезти чисто по документациям, оооч долго мучался, по итогу уже когда все было готово но не работало, плюнул и пошел смотреть индусов. (Мой совет, не обрезайте заранее для себя источники информации, плохая идея)
Дальше было несколько дней раздумий, как и куда двигать проект, какие фичи делать, какой дизайн соблюдать. (В идеале нужно садиться с бумажкой и несколько дней записывать/расписывать идеи, но это не мой подход. Тут я выдам на первый взгляд странный совет - просто делайте)
Когда уже будет готов скелет из нескольких "фич", работа пойдет как по маслу, глаз сам уже будет хотеть видеть на каком то месте график, список, кнопку, блок с каким то текстом, главное записывать все эти идеи, если у вас не мега память.
Сейчас я довожу проект до стадии MVP (думаю что до конца апреля управлюсь) и сажусь писать душный текст диссертации.
Есть много моментов которые мне хотелось бы рассказать более подробно, например почему в моем проект нет и не будет вообще стейт-менеджера. Думаю некст пост будет как раз на эту тему.
- - - - - - -

Немного про новенький React 19
- - -
Уже из каждой щели, каждый уважающий себя блогер и не блогер высказал свое уважаемое мнение. Я не буду выписывать технические подробности, вы их можете прочитать где угодно.
- - -
1) Всем не нравятся новые хуки, которые по сути обертки над старыми с надеждой починить косяки, в целом все последние обновы реакта это попытка починить кривую систему ререндеров.
2) Все хотят видеть сигналы в реакте, ведь они уже есть ляли везде, SolidJs, с которого все снимают копию, Vue с реактивными переменными, скоро будет в Angular. Но реактивность в реакте я думаю будет не скоро, ведь у них «свой путь развития».
- - -
Я уже долгое время пропагандирую SolidJS, там работают здравые ребята, за ними будущее.
Резюме такое, общество будет бесконечно ныть, до тех пор пока макака на реакте будет выгоднее для бизнеса, а выгоднее она будет еще очень долго, потому что средняя макака на реакте банально дешевле чем средний чел на Vue, смотрите статистику.
- - - - - - -

Немного про open source
- - -
Я по этому поводу думаю следующее, каждый должен попробовать что то сделать для сообщества.

Я не так давно заинтересовался этой темой, спасибо Егору Бугаенко за поднятие духа авантюризма в этой сфере. Если кратко, это жестко развивает насмотренность, что очень важно. Вторым пунктом идет понимание того, что своей публичной деятельностью вы двигаете прогресс на микрошажок вперед, потому что все проекты, от маленьких пет-проджектов до огромных продуктов используют open source решения, и может быть именно ваш проект или хотя бы PR в какой то репозиторий сделает чью то жизнь чуточку лучше.

Сейчас у меня есть большое желание создать что то значимое и нужное для людей, пока что в поисках идей, но я стараюсь поддерживать другие репозитории. На моем счету уже 3 смерженых PR в репозитории, которыми пользуются много людей, один из них Sentry, Effector (да, они очень маленькие, но все же). В дальнейшем хотелось бы делать полноценные фичи, или хотя бы куски фич, но для этого надо подкачаться.

Главный вопрос, а зачем все это именно для меня (или любого другого конкретного человека). Если без демагогий о саморазвитии, ответ банально простой - дешевый дофамин. Пусть это будет маленький PR на 5 строчек, но у вас будет ощущение, что вашу работу заметили, оценили, и ей будут пользоваться множество таких же разработчиков.

Мой GitHub
- - - - - - -

Около года назад на работе интегрировал code coverage и загрузку данных в GitLab

Трудности тогда ждали абсолютно на всех этапах, начиная от кривой апишки гитлаба для работы с coverage, заканчивая не менее кривым Jest который хер пойми как анализирует покрытие + постоянные предупреждения в консоли об ошибке в конфиге джеста (у них между прочим в доке есть описание такой конфигурации + ишью на гихабе которое висит уже года 3-4)

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

Но тут прилетело требование, нужно разогнать coverage до 90% (сейчас 80+) Тесты написаны уже почти на все, исключать что то? Плохая идея. Просмотрел все coverage файлы и понял что джест плохо анализирует значения которые возвращает какая то функция.

export const [$a, b, c] = createFn()

Например во такой код будет показан как не покрытый, если вы напрямую в тестах не использовали эти значения, даже если на саму функцию createFn тесты написаны.
С этим можно жить, например мне пришла идея пометить такие строки как /* istanbul ignore next */ , чтобы джест их не анализировал, но тут началось все веселье.

Jest под капотом использует istanbul, в истанбуле эти фичи есть, но они не работают и вообще он уже депрекейтед)) Мейнтейнеры мне посоветовали использовать nyc утилиу, это по сути проект от тех же разрабов, то есть istanbul 2.0.

Под nyc нету никакой инфраструктуры, вся трудность в том что у нас проект на NX и для нормально работы нужны под все это экзикуторы.

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

Суммарно потратив около двух дней на переосмысление системы coverage покрытия кода, поймал себя за руку что уже пишу кастомные экзикуторы для NX, понял что я занимаюсь вообще не тем. По итогу все манипуляции с результатами coverage переделал на nyc, а сам анализ кода решил пока что не трогать. Просто со свежей головой проанализирую еще раз что нам действительно нужно покрывать, а что нет, и насколько сильно вообще.
- - - - - - -

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

У меня большой вопрос к биг техам, ведь у них же 100% есть инструменты для покрытия, у них огромные репозитори, почему это остается какой то сакральной тайной, почему бы не сделать гайд для разрабов?

Рабочее место типичного работяги 💻

Делитесь вашими в комментах 👨‍💻

Вчера в ночи доделал проект который мне нужен для защиты магистерской диссертации.

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

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

Записывайте, берете на бек+фронт - Next JS, для бдшки - Postrges, в качестве ORM - Prisma, для стилей чтобы не копаться в css - tailwind (для большого продакшена никогда бы не взял бы, но если разрабатывает один человек, то why not), ну и дальше библиотеки по вкусу для решения ваших локальных проблем. Ну и запихиваете все это в докер. Никогда раньше не использовал докер для пет проектов - а зря, если разобраться, очень удобный инструмент, который позволяет избавиться от головной боли связанной с ОС на которой вы работаете и деплоите свое приложение.

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

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

Интересная история у меня вышла с деплоем в продакшен приложения. Если фронт это непосредственно моя работа, про бек я хотя бы что то понимал/слышал/тыкал, то во с деплоем я никогда отношений не имел. Первый раз все всегда сложно. Посмотрел гайды, начал тыкать у себя, ничего не получается. Спустя вечер изучения, дебага, решил отказаться от идеи деплоить на какой то платный хостинг, и воспользовался решением от Vercel. До этого я деплоил туда только свои клиентские приложения, но оказывается у них можно даже создать БДшку, для меня это было идеальным решением. И вот пройдя весь процесс, я уже осознал как это можно сделать, использую простую виртуальную машину.

Какой итог? Приложение работает, скил поднял, страх неизведанного пропал.

ТЮЮЮЮЮ ВОТ ЭТО ДЕВТУЛЗЫ ВО ВЬЮ МОЕ УВАЖЕНИЕ!

https://react.dev/learn/react-compiler

> You may be familiar today with manual memoization through useMemo, useCallback, and React.memo. The compiler can automatically do this for you

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

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

#Литература

Дочитал сегодня книгу «Современный JavaScript для нетерпеливых» Кэй С. Хорстман

Это буквально «голопом» по языку, от самой базы до сложных вещей.

Я не выступаю против такой литературы, но смысла в этом нет, только если реально интересно и есть энтузиазм.
50% а то и больше что заложено в языке, например в том же JS, вы никогда не будете использовать, и информация эта нужна исключительно для того чтобы:
1) Делать какой то реверс-инженеринг или писать библиотеки
2) Душить кандидатов на собесах
3) Самому отбиваться от душных вопросов на собесах
ВСЕ!

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

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

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

Накидайте литературы в комменты которая по вашему мнению достойна внимания.

Choose your fighter:

Раз в месяц примерно проверяю че там в мире железок происходит.

В этот раз Microsoft попытались порадовать, сделав процессор с дополнительными ядрами с интеграцией ИИ.

Прорыв? Да! Выкатили два проца, на 12 и 10 ядер.

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

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

Tested May 2024 using Cinebench 2024 Multi-Core benchmark comparing Copilot+ PCs with Snapdragon X Elite 12 core and Snapdragon X Plus 10 core configurations to MacBook Air 15” with M3 8 core CPU / 10 Core GPU configuration. Performance will vary significantly between device configuration and usage.

Ну сделайте вы честную презентацию, возьмите m3 max или хотя бы pro заряженные, сделайте понятные графики, где быстрее, где хуже, для каких задач это вообще все нужно будет. Пусть это будет не 50%+ как они написали, пусть это будет маленький процент, но он будет честный.

Business is business, и это грустно

Бог создал землю за 7 дней, а Линус Торвальдс создал git за две недели.

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

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

Если интересно тут можно почитать полную версию.

https://graphite.dev/blog/bitkeeper-linux-story-of-git-creation

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

Речь сейчас пойдет не про классическое бережливое производство (большое уважение Тойоте) из которого появился Agile, а в свою очередь на базе которого построен Scrum.

Речь пойдет как раз такие про "одибиленный" современный scrum в контексте it.

Некий Маглинец Ю.А. в своем собрании лекций "АНАЛИЗ ТРЕБОВАНИЙ К ИНФОРМАЦИОННЫМ СИСТЕМАМ" пишет о том, что самая главная проблема при разработке продукта, это невыполнение сроков разработки. Если бы все продукты разрабатывались точно в срок, наверное, не было бы необходимости регламентировать такие аспекты. При заключении договора между разработчиком и заказчиком, второй берет на себя много рисков, среди которых – большая временная просрочка и низкое качество финального продукта. Для решения данных проблем как раз и существуют проектные требования, в которые может входить полная регламентация процесса разработки программного обеспечения и его аудит.

В переводе на человеческий язык, "Заказчик нанимает дешевых обезьян, и постоянно боится что обезьяны ничего не сделают. Из-за этого бедных обезьян надо каждые 5 минут проверять и давать нагоняй. Обезьяны начинают ненавидеть начальника и как следствие работают еще хуже."

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

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

Я этого давно ждал, because формат сначала картинка потом текст мне никогда не нравился, но я уже почти смирился.

Задумайтесь, когда в следующий раз решите "замокать" данные

Можете удалять интернет, лучше мема вы уже не увидите!

*для всех кто не знаком с лучшим знатоком подкапотного JS, очень советую

https://www.youtube.com/live/_P2YmY3sxhY?si=ll7hzel455CIlXBH

Какие же гении работают в ВК.

Оказывается мужики года два назад натренировали LLM на дваче и запустили туда же своего бота.