Александр Белькевич </> Frontend вдохновляет

#frontend_useful

Гуляло по разным tg-каналам, но не могу не поделиться ещё раз полезной ссылкой на бесплатные книги и документации на русском языке на разные языки программирования и технологии

https://github.com/EbookFoundation/free-programming-books/blob/main/books/free-programming-books-ru.md

#frontend_mylife

За 2 месяца второй раз приехал в Краснодар 🙂

Сначала ездили с ребенком и женой сюда по делам, теперь с товарищем приехали на футбол. В воскресенье домой, а завтра - на стадион.

#frontend_post

Работа с npm пакетами: Управление версиями и обновление

Думаю, каждый из вас работал с NPM. На всякий случай уточню: это инструмент, который позволяет разработчикам JavaScript и Node.js управлять зависимостями в своих проектах. Одним из ключевых аспектов работы с npm является управление версиями пакетов.

Версии пакетов и семантическое версионирование

npm использует систему семантического версионирования (semver), которая позволяет понять, какие изменения в пакете были внесены с выходом новой версии. Формат версии состоит из трех чисел: MAJOR.MINOR.PATCH.

🍏 MAJOR: крупные изменения, которые могут нарушить обратную совместимость.

🍎 MINOR: добавление нового функционала, который не нарушает обратную совместимость.

🍋 PATCH: исправления ошибок, которые не нарушают обратную совместимость.

Управление версиями в package.json

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

🍏 Точная версия: "react": "17.0.1" - всегда будет использоваться версия 17.0.1.

🍎 Символ ^: "react": "^17.0.1" - будет использоваться любая MINOR или PATCH версия, начиная с 17.0.1, например, 17.1.0 или 17.0.2.

🍋 Символ ~: "react": "~17.0.1" - будет использоваться любая PATCH версия, начиная с 17.0.1, например, 17.0.2, но не 17.1.0.

Обновление пакетов

Проверить устаревшие пакеты можно с помощью команды:

npm outdated

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

Чтобы обновить пакеты до последней версии, можно использовать команду:

npm update

Однако эта команда обновит пакеты только до версий, разрешенных текущими диапазонами версий в package.json.

Для обновления всех пакетов до последних версий, нужно сначала обновить диапазоны версий в package.json, а затем установить пакеты:

npx npm-check-updates -u
npm install

Эта команда обновит все версии в package.json до последних доступных, после чего вам нужно будет выполнить npm install, чтобы установить эти версии.

Работа с версиями npm пакетов и их обновление — важная часть управления проектами на JavaScript и Node.js. Понимание семантического версионирования и использование символов для указания диапазонов версий помогает эффективно управлять зависимостями и поддерживать стабильность проекта. Не забывайте регулярно проверять устаревшие пакеты и обновлять их, чтобы воспользоваться последними улучшениями и исправлениями ошибок.

А вы знали про такие нюансы при работе с версиями пакетов?
👍 - Да
🙏 - Нет
🔥 - Пили еще контент, полезно

#frontend_mylife

Короче пока непонятно, что с YouTube. У большинства в России перестало работать. У кого-то ещё живет, кто-то в другой стране, кто-то сидит с VPN.

Но тем не менее, надо искать обходные пути.

Можете подписаться на меня в Rutube 🤦‍♂️

rutube.ru/channel/39487443

Пока туда перенес видосы по Pinia. Чуть позже остальное добавлю.

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

Пока предлагает одно пропагандистское 💩

#frontend_useful

Недавно вышло отличное видео на канале freeCodeCamp про асинхронность в JS. К просмотру советую

https://www.youtube.com/watch?v=OFpqvaJ3QYg

#frontend_mylife

Про формат работы. Личный опыт.

До тех пор, пока не начался COVID, удаленка (даже для айтишников) была скорее роскошь, нежели частая практика.

Я удаленку в свое время не очень любил, не хватало то, что нужно большинству из нас: самоорганизации и живого общения.

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

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

После COVID началась (и продолжается) череда удаленной работы.

Сначала пытался дома. Но с рождением ребенка это стало в принципе почти невозможно. Какой выход? Да очень простой: с одним из работодателей я договорился о том, что мне покрывают расходы на снятие офиса (10к рублей в месяц).

И это действительно отличный вариант.

1. Я не сижу дома
2. Езжу в офис
3. Офис обставил так, как мне нравится и как мне комфортно

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

Живое общение решилось просто: дейликов, всяких созвонов хватает и потребность именно общения с глазу на глаз пропала 😄😁

По итогу уже третий год снимаю офис и радуюсь. Ехать до него 20 минут и это время точно не жалко потратить на свой укромный уголок.

А вы почему выбрали офис, гибрид или удаленку? Хочется ли что-то поменять?

#frontend_useful

Вышла MMORPG для разработчиков: Artifacts.

Здесь можно крафтить, растить своих персонажей и заниматься тем, что мы любим делать в играх с одним НО: необходимо писать скрипты и общаться с API.

Конечно, после этого в Google вас не возьмут. но довольно залипательно)

#frontend_mylife

Месяц у меня ушел на то, чтобы прочитать «Будущее» Дмитрия Глуховского.

Сюжет кратко: относительно недалекое будущее. Люди победили все болезни и научились делать лекарство для вечной молодости. Из этого вытекающие последствия:
- Перенаселение
- Запрет на детей или обмен жизни ребенка на инъекцию для ускоренной старости одного из родителей
- Жуткое социальное неравенство


Ближе к середине книги повествование чуть проседает, но потом выравнивается.

Из плюсов:
- Прекрасно прописаны персонажи
- Захватывающий сюжет и отлично прописанный мир
- Несколько неожиданных поворотов, главный из которых на последней странице книги

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

Книга действительно оставляет после себя мысли на тему «А нужно ли человеку бессмертие?».

Так что если любите антиутопию, книги по типу «1984» и «451 градус по Фаренгейту» - бегите читать ❤️

#frontend_post

Обещал рассказать про груминг 🙃 Обещания надо выполнять!

Груминг играет ключевую роль в управлении проектами и разработке. Он помогает командам быть организованными, продуктивными и нацеленными на результат.

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

Что такое груминг?

Простым языком, груминг — это процесс подготовки и обработки задач.

Груминг бывает двух видов. Бэклога и определенной задачи. Сегодня поговорим про груминг бэклога.

Если вдруг кто не знает: бэклог - это список задач, которые есть у команды.

Груминг включает в себя:

1. Определение приоритетов:
Решение о том, какие задачи наиболее важны и требуют немедленного внимания.

2. Уточнение требований:
Работа с задачами для их детализации и уточнения, чтобы они были понятны всей команде.

3. Разбиение задач:
Разделение крупных задач на более мелкие и управляемые части.

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

Почему груминг важен?

Груминг — это не просто подготовка. Это стратегический процесс, который значительно влияет на эффективность работы команды и качество конечного продукта.

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

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

3. Эффективное распределение ресурсов:
Груминг помогает равномерно распределить нагрузку между членами команды, избегая перегрузок и простоев.

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

Как проходит груминг?

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

Встречи по грумингу включают:

1. Обсуждение каждой задачи:
Что нужно сделать? Какие есть нюансы и детали?

2. Приоритизация:
Какие задачи наиболее важны и должны быть выполнены в первую очередь?

3. Разделение задач:
Как лучше всего разбить задачи на подзадачи, чтобы каждый знал, что делать?

4. Оценка времени и ресурсов:
Сколько времени потребуется на выполнение каждой задачи? Какие ресурсы нужны?

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

Если вы хотите, чтобы ваш IT-проект шел гладко, не забывайте про груминг — это ваш ключ к успешной разработке!

Если хочется больше постов про процессы в продуктовой разработке - ставьте ❤️

Ну и свои вопросы всегда можете задать под постом 😊

#frontend_mylife

Пока вы отвечаете на опрос выше я готовлю новый пост и делюсь разными интересностями из жизни 😃

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

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

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

Итог: дорого, но оно того стоит и за 2 недели ни разу не пожалели 😃

Всем привет!

Рекомендую канал разработчика с более чем 10-летним опытом в frontend и fullstack разработке. Сергей является экспертом в TypeScript, Node.js, React, а также имеет значительный опыт с Rust, Swift, Ruby и C++. Он мастерски использует эти технологии для создания масштабируемых и производительных приложений.

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

На канале @sergeysova Сергей делится знаниями о разработке и интеграции API в frontend, создании дизайн-систем и библиотек компонентов, а также показывает, как эффективно использовать CI/CD.

Подписывайтесь, чтобы получить ценные знания и советы от опытного разработчика!

#frontend_post

Про Design review

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

Все мы привыкли (ну или большинство из нас) к code review. Сделали задачу, отправили на проверку, проверил QA и вперед в production.

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

Кто должен отвечать за то, что до production доедет то, что задумал дизайнер? Кто-то из нас забивает на отступы, кто-то на межстрочный интервал, а для кого-то не важно, какой шрифт юзать: Helvetica, Sans-Serif или Arial. Текст же можно прочитать? Значит сойдет 😃

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

И вот тут подключается Design Review. То есть дизайнер смотрит то, что вы сделали и как нашкодившего кота тыкает вам в неверные border-radius и неправильные тени.

Помню, на прошлой работе я на первом Design Review получил около 30 правок. Почему? Я не настолько сильно парился с отступами и размерами. Конечно, работа была сделана не тяп-ляп, но многие моменты я упустил и дизайнер на это указал.

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

На текущей работе дизайнер не смотрит Pixel Perfect, поэтому чуть легче, но все равно бывает что-то ускользает от взгляда разработчика и вот тут Design Review как никогда кстати приходится.

Какие плюсы и минусы у Design Review есть?

➕➕➕➕➕

Выявление проблем на раннем этапе
Иногда неверно сверстанный блок доставляет не просто визуально выглядит не так, но и ломает логику. QA может не заметить (или же для него/нее это не кажется чем-то критичным), но дизайнер обязательно подсветит то, что без правок тут никак. Иначе то, что задумывалось в будущем, в текущем вариант работать не будет.

Совместное творчество и улучшение идей
Бывает такое, что на этапе Design Review появляются споры и если дизайнер сговорчивый, то нередко frontend-разработчик успешно "защищает" свое решение (если может обосновать, почему он сделал не так, как было нарисовано)

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

➖➖➖➖➖

Затраты времени
Design Review - это нередко довольно долгий процесс. Одно дело вы кнопочку вставили в проект, другое - переделали целый раздел. Чем больше задача - тем больше правок и итераций может пройти.

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

Итог:
Design Review - это круто, но если в этом есть реальная необходимость. К примеру, если вы делаете MVP - излишний перфекционизм может стоит денег (ведь каждый час работы разработчика стоит немало). С другой стороны, если проект приносит прибыль - наплевательски к визуалу относиться никак нельзя.

А какие плюсы и минусы в Design Review вы можете отметить для себя?

Ну и по стандарту, давайте отмечаться 🙃

👍 - Design Review нужен
👎 - Design Review это лишняя трата времени
❤️ - Лайк в поддержку поста

Ну и пишите в комментариях свое мнение 🙃