Около года назад на работе интегрировал 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 на дваче и запустили туда же своего бота.

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

НО, решил я слить пару часов жизни в помойку и в очередной раз разобраться "че там с компилятором React" (спойлер одно разочарование). Хайп утих, весь плохой материал осел на дно, и можно попробовать найти действительно годный контент.

https://www.developerway.com/posts/i-tried-react-compiler

В статье автор попытался на уже существующих проектах попробовать React 19 + compiler и никакой магии кеширования не произошло. Все так же на каждый чендж инпута происходит ререндер всего чего только можно.

ЧТД, пока что с помощью зеро конфига привнести магию в реакт не получится, и я думаю допилят до прода его еще не скоро. А это значит, что владение алгоритмами React все еще ценный навык, и у меня сложилось впечатление что с компилятором даже больше надо упарываться в мемоизацию чем без него.

Получилась почти целая книга.

Ждем понедельника…

Вот и закончилась суета, теперь почти официально магистр, осталось только диплом забрать.

На время выпадал из каких то пет проектов и опенсорса из-за большой нагрузки, накопилось много вещей которые хочется попробовать или улучшить (например пописать на vue, и много заметок по улучшению зоопарка для effector)
Какие то вещи я просто тыкал в свободное время и по ним тоже сформировалось свое мнение которым хотелось бы поделиться (например htmx в связке с golang)

А что у нас тут? Правильно - AI

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

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

https://github.com/microsoft/generative-ai-for-beginners