CodeGPT

Кстати, буду стараться показывать лайфхаки и инструменты, которые сам использую. Бонусом к первой части я бы посоветовал пощупать плагин CodeGPT: JetBrains версия, VS Code версия. Позволяет легко и удобно скармливать ваш код ChatGPT.

Из коробки можно попросить:
- Объяснить код
- Отрефакторить
- Найти баги
- Написать тесты
- Оптимизировать

Все эти команды – просто дополнительный промт к вашему куску кода, который легко настраивается. Также можно добавить свою собственную команду.

P.S. Для использования нужно быть зарегистрированным в ChatGPT.

#plugins

Нейросети. Часть вторая

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

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

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

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

Русскоязычный вариант:

Игнорируйте все предыдущие инструкции перед этой. Вы [senior frontend программист]. Вы помогаете людям [создавать высокопроизводительный frontend] уже 20 лет. От молодых людей до пожилых людей. Теперь ваша задача — дать лучший экспертный совет, когда дело доходит до [создания frontend приложения]. Вы должны ВСЕГДА задавать вопросы, прежде чем отвечать, чтобы вы могли лучше понять, что ищет спрашивающий. Это понятно?

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

P.S. Промт подсмотрел здесь

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

Нейросети. Часть четвертая. Работа с текстом.

Копирайтинг. Совсем не близкая мне сфера, но из-за ведения канала не мог не опробовать)) Статьи, которые генерирует Chat GPT, легко читаются, но без всяких “секретных промтов” такие тексты уже помечаются поисковиками как “сгенерировано нейросетью” из-за чего падает SEO. Если насмотрелись ютюберов, которые обещают научить зарабатывать 300к/наносек на нейросетях, то имейте ввиду, что тут есть подводные камни и дальше их будет только больше. Я думаю, что популярные сервисы и поисковики будут прокачивать защиту “человеческого” контента, что продлит жизнь профессии копирайтера еще немного. В любом случае, человеческое творчество никуда не денется, иначе откуда нейронкам брать новые референсы?

Признаюсь, я пробовал генерировать промо посты и обычные статьи в ChatGPT, и исходный результат меня всегда не устраивал, то нет “души”, то плохо раскрыта тема и т.д., но идеи для собственных постов я все же почерпнул.
Еще иногда отправляю ему свои посты на проверку фактов, пока везде соглашался, но вдруг я случайно напишу дичь и не замечу 🤷‍♂️.
И нет, этот пост не сгенерирован нейросетью.

Пересказ книг (помещу этот пункт сюда, чтоб не пилить отдельный пост). Я просил пересказать главы книг, которые уже прочел, чтобы оценить точность. Результат был очень даже годным. Удобно, когда нужно освежить память или понять, стоит ли вообще читать книгу. Кстати, очень удобно “масштабируется”: можно запросить главу, середину главы или вообще намекнуть на конкретный эпизод. Домашние сочинения по литературе R.I.P.🪦

С помощью следующих инструментов можно проверять статьи на участие в них ИИ:

- copyleaks
- crossplag
- contentatscale

Имейте ввиду, что все они еще достаточно сырые и очень плохо работают с русским.

Нейросети. Финальная часть.

Для коллег-дизайнеров ситуация тоже вполне стабильная. MidJourney генерирует красивые и качественные картинки, но…
1. Все результаты растровые;
2. Иногда бывают артефакты;
3. Плохо генерирует текст;
4. UI элементы – без комментариев.

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

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

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

Резюмируя весь цикл постов: нейросети в текущем виде, определенно, изменят многие рабочие сферы. Внедрение нейронок в рабочий процесс повышает продуктивность и конкурентоспособность тех, кто идет в ногу со временем. В то время как те, кто сопротивляется прогрессу, будут постепенно вытесняться первыми. И это касается не только людей, но и компаний. Notion, Quizlet, Microsoft, поисковики типа you.com или perplexity.ai и многие другие сервисы уже используют технологии OpenAI, и это только начало.

А что вы думаете о хайпе вокруг нейронок?

Задача: Преобразование отсортированного массива в двоичное дерево поиска

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

Дан целочисленный массив nums, элементы которого отсортированы по возрастанию. Преобразуйте его в сбалансированное по высоте двоичное дерево поиска (АВЛ-дерево).

АВЛ-дерево — сбалансированное по высоте двоичное дерево поиска: для каждой его вершины высота её двух поддеревьев различается не более чем на 1.

P.S. В телеге проблематично оформить наглядный пример деревьев с картинками. Кому нужны картинки – переходите к статье с ответом. Раздел до "Решения" не содержит спойлеров.

Пример 1:
Ввод: nums = [-10,-3,0,5,9]
Вывод: [0,-3,9,-10,null,5]
Объяснение: [0,-10,5,null,-3,null,9] тоже подходит

Пример 2:
Ввод: nums = [1,3]
Вывод: [3,1]
Объяснение: [1,null,3] и [3,1] тоже АВЛ деревья.

Пишите свои версии в комментариях.

Ответ с объяснением 👈

#algorithms

Атрибут translate='no': защита контента от автоматического перевода

Думаю, многие из вас используют Google translate в Chrome. Но бывает, что он "магическим" образом не переводит некоторый контент, а бывает, наоборот, переводит все подряд, из-за чего переведенная версия становится вырвиглазной. Для влияния на переводчик используется HTML атрибут translate="no". Этот элемент используется для обозначения того, что содержимое элемента не нужно переводить во время браузерного перевода страницы.

Бывает полезно, когда нужно запретить перевод:

- Служебных слов и фраз. Например, название компаний, товарные знаки и т.д;
- Кода и технических терминов – тут без комментариев;
- Адреса электронной почты, URL-адреса, и даты. Иногда переводчики могут некорректно обрабатывать подобные данные, искажая их значения.

Лично я встречался еще с одним кейсом: во время использования переводчика старая CRM система просто крашилась 😃. Проблема была в том, что переводчик заменял тэги, на которые у системы были ссылки. Думаю, случай достаточно редкий, т.к. система была очень старой и с кучей легаси.

@js_is_easy

CSS модули. Композиция

Я еще в декабре делал ревью самых популярных подходов стилизации. Из статьи очевидно, что моим фаворитом являются CSS-модули.
Хочу разобрать несколько неочевидных моментов, на которых буксуют при переходе из нативного scss/css.

Начну с композиции (наследования). CSS-модули позволяют легко объединять и наследовать стили как из разных файлов, так и внутри одного файла, используя директиву composes. Замечу, что в отличие от @include утилиты в sass, которая тупо копипастит стили, здесь происходит именно объединение классов, т.е., если применить класс primary к компоненту, то к нему автоматически применится и класс base.

<div className={styles.primary} />
превратится в
<div class='primary_M4s71 base_6fsXP' />

@js_is_easy

CSS модули. Глобальные стили

CSS-модули автоматически генерируют уникальные имена классов для изоляции стилей. Однако, иногда может потребоваться применить глобальные стили. Например, изменить внешний класс или для компонента, которому нельзя присвоить дополнительный класс. Для этого используется ключевое слово :global.

Второй вариант хорошо показывает себя, если нужно использовать какие-то старые компоненты, а основной код уже переехал на CSS-модули.

@js_is_easy

CSS модули. Вложенные селекторы

Простой, но не совсем очевидный момент – все классы, даже вложенные, в CSS модулях экспортируются плоским (один уровень вложенности) объектом. Допустим, есть класс .button, а внутри него классы .default и .danger. С такой структурой кажется логичным обращаться к вложенным классам типа styles.button.danger, но в реальности к ним обращаются: styles.danger.

Конечно, было бы семантически удобнее использовать первый вариант, но имеем, что имеем. Если приложение спроектировано грамотно и компоненты разбиты на атомы, то иногда можно пренебречь семантикой (БЭМ) – сборщик подставит нужное имя в класс. Например, если в компоненте только кнопка, то классы .button и .danger будут приемлемыми, а вот в сложных компонентах, например, с кнопкой и полем ввода стоит добавить больше семантики в модификаторы: .danger → .buttonDanger и .inputDanger, соответсвенно.

Кстати, на практике я редко использую вложенные селекторы. Думаю, что в CSS-модулях в них нет такой необходимости, как в нативном CSS. В примере с кнопкой можно вытащить .button и .danger на один уровень и семантика от этого не пострадает. В примере с кнопкой и полем ввода с семантикой еще проще – название блока уже заложено в класс, поэтому их можно вынести на один уровень и читаемость сохранится.

@js_is_easy

Задача: Самый повторяющийся элемент в массиве

Дан массив nums размера n, верните самый большой элемент.

Большой элемент – это элемент, который встречается более [n/2] раз. Можете считать, что большой элемент всегда существует в массиве.

Задание со звездочкой: Решите задачу за линейное время и используйте только O(1) памяти.

Первое решение, которое приходит на ум, довольно тривиальное: взять объект или Map, пройтись циклом по массиву и записать количество каждого элемента, а потом пройтись циклом по этому объекту и найти элемент с максимальным значением. Решение рабочее, но может оказаться прожорливым на больших данных: память – O(N), время – O(N + M), где M – количество уникальных символов. В статье решение для условия со звездочкой.

Пример 1:
Ввод: nums = [3,2,3]
Вывод: 3

Пример 2:
Ввод: nums = [2,2,1,1,1,2,2]
Вывод: 2

Пишите свои версии в комментариях.

Ответ с объяснением 👈

#algorithms

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

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

1. Масштабируемость. Если заказчики захотят добавить одинаковый или похожий модуль в несколько проектов, то в каждом проекте разработчики будут изобретать свои велосипеды.
2. Коллаборация и поддержка. Когда разработчик переходит из одного проекта в другой, или просто временно подменяет кого-то, то переключение между проектами отнимает много ресурсов, а потом еще проблемы на ревью, т.к. у другой команды принято “по-другому”.
3. Повторное использование кода. Когда нет четких правил, где и что хранить, UI рано или поздно начинает смешиваться с логикой, и чтобы перенести компонент из одного проекта в другой, приходится его очищать от бизнес-логики.
4. Корпоративный набор библиотек. Здесь проблема, как во 2 и 3 пунктах вместе взятых, когда на каждом проекте свой зоопарк менеджеров, состояний и других взаимозаменяемых пакетов.

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

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

@js_is_easy

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

Я создал монорепу с помощью lerna и добавил пакеты настроек линтеров и TS. Внутри пакетов ничего сверхъестественного: обычный package.json + соответствующий файл конфига (.eslintrc.js, prettier.config.js, tsconfig.json)

Дальше – конфиги подключаются довольно просто:
1. Устанавливаем пакеты в проект: npm i @our-tools/eslint-config @our-tools/prettier-config @our-tools/ts-config
2. Наследуем каждый инструмент соответствующим образом (примеры на картинке). Я предпочитаю наследовать конфиги eslint и prettier в файле package.json. Да, это менее популярно, чем отдельные файлы, но, как показывает практика, желающих переопределить правила линтинга в файле package.json оказывается меньше 🤷‍♂️.

В результате получается, что все настройки линтеров спрятаны в пакеты, как и их зависимости. Например, в package.json проектов теперь нет явной зависимости eslint и его плагинов, все это содержится внутри пакета @our-tools/eslint-config. Естественно, инфа по использованию конфигов прописана в хэндбуке и онбординг доке.

Планируем добавить аналогичные общие конфиги для сборщиков и тестов (пока в процессе стандартизации).

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

P.P.S. Настройки можно наследовать и относительным путем. На случай, если у вас монорепа и выносить настройки в отдельный пакет нет желания.

@js_is_easy

Стартовый шаблон

Еще одно решение, позволяющее организовывать разработку и поддерживать корпоративную архитектуру – это стартовый шаблон.

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

Минус данного решения заключается в том, что оно не очень гибкое. Один шаблон – один тип проекта. Если активно развиваются не только основные приложения, но и виджеты, то придется обзавестись несколькими шаблонами, так как каждый тип проектов будет иметь свою специфику и зависимости. Например, самостоятельному приложению нужны зависимости react и react-router, а виджету - Storybook.

В качестве альтернативы можно рассмотреть генераторы, такие как Yeoman или Mustache.js (или даже их комбинацию с шаблонами). Они достаточно гибкие, но требуют больше времени на разработку и поддержку.

@js_is_easy

Теперь вернемся на несколько уровней выше, к конкретным архитектурам.

Когда мы согласовывали корпоративную архитектуру, то рассматривали 3 варианта: Microfrontend через Module Federation, Atomic Design System и Feature Sliced Design. Старые проекты внутри себя уже были разделены на формальные модули, так что внедрение MF приняли единогласно, т.к. даже независимые деплои уже давали профит.

Однако сами по себе микрофронты никак не организуют код внутри модулей, поэтому нужно было решить, что внедрять дальше: ADS или FSD. На мой взгляд, FSD – отличная методология с самодостаточной философией и подходом, и я хотел протестировать ее на реальном проекте и понять все подводные, но… бэкграунд проектов сыграл свою роль:

1. Пара команд уже успешно внедрили ADS к себе в проекты в тестовом режиме.
2. С FSD ни у кого не было боевого опыта, поэтому переход мог быть достаточно долгим и болезненным.
3. Когда мы разрабатывали UI-кит, то договорились с дизайнерами, что они тоже будут следовать ADS методологии.

Да, ADS имеет свои недочеты, например, нет четкого соглашения, где хранить бизнес-логику и вспомогательные утилиты. На данный момент мы просто условились не спускать бизнес логику ниже уровня страниц, а универсальные утилиты переедут в отдельную внутреннюю репу с тулзами. Кстати, у нас UI-кит – это отдельная репа, и в MF приложениях, в большинстве случаев, почти не будет атомов, молекул и организмов. Они будут тянуться прямиком из кита.

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

P. S. Позже я планирую разобрать плюсы и минусы каждого подхода более подробно, а пока, те, кто заинтересован, переходите по соответствующим ссылкам в первом абзаце.

@js_is_easy

Ребята из iOS Такой 🍏 пригласили меня в гости на стрим. Мы из разных областей программирования, поэтому выбрали нейтральную тему для обсуждения: "Chat GPT и Нейронные сети".
Будем обсуждать прикладное использование нейронок в программировании и не только.

Залетайте в это воскресенье, 14 мая, в 18:00 по МСК на трансляцию.

P.S. Я еще в марте делал цикл постов про нейронки с лайфхаками. За это время набрался прикладного опыта и есть чем их дополнить.

@js_is_easy

Страх писать негативные отчеты

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

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

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

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

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

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

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

Помните, что вопросы – это не знак некомпетентности. На самом деле, это признак профессионализма. Задавая вопросы, вы показываете, что заботитесь о качестве вашего продукта и вовлечены в разработку.

@js_is_easy

Заметки о forwardRef

В устаревшей доке React подробно описано, использование forwardRef. Но нет объяснений, зачем использовать этот HOC, когда можно просто передать ref в пропсах. На это есть несколько причин:

1. Обратная совместимость. Когда React перешел с классов на функции (FC), единственным способом переписать компонент с рефом с класса на FC был forwardRef. Это связано с тем, что в классах рефы привязывались к экземпляру класса, а у функций экземпляров нет. [Подробнее]. Если бы ref был в общем списке пропов, то при деструктуризации пропов он бы проваливался сразу дальше, а в классовых компонентах его обрабатывали отдельно.

2. Соглашение о наименовании. В приложении, без классовых компонентов, вы можете передать реф в любом пропе (кроме специальных: ref или key), например, innerRef, и при этом в дочернем компоненте не нужно использовать forwardRef. С точки зрения разработки, это проще и удобнее, так как требуется меньше HOC'ов. Однако если вы разрабатываете библиотеку или работаете в команде, то для других разработчиков может быть не очевидно, чем ваш innerRef отличается от общепринятого ref. Если вы планируете предоставить доступ к DOM верхнего элемента, делайте это через ref. Если требуется доступ к другим элементам или императивный подход, можно добавить свои пропы для рефов (подробнее в следующем пункте).

3. Инкапсуляция. По умолчанию React не позволяет компоненту обращаться к узлам DOM других компонентов. Это сделано намеренно, чтобы разработчики не могли использовать любые компоненты в императивном стиле, а только те, которые были специально разработаны для этого. Рефы – это императивная лазейка в декларативном React. Используйте их только в крайнем случае, например, когда нужно напрямую обратиться к DOM.

В новой документации React есть отличная статья про рефы и о третьем пункте в частности: https://react.dev/learn/manipulating-the-dom-with-refs

P.S. Я в этом посте делился кастомным хуком для объединения внешних и локальных рефов. Забирайте.

@js_is_easy

String Manipulation [JetBrains][VS Code] – плагин, который поможет ускорить разработку. У него достаточно богатая функциональность, но лично я использую только смену регистра.

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

Очень удобен при переименовании переменных во время деструктуризации данных на фронте с бэка из snake_case в camelCase и наоборот, а также при рефакторинге.

Естественно, можно настроить шорткаты, кнопка настроек на втором окне внизу.
#plugins

@js_is_easy