Пришло время продолжить цикл статей о запуске личного блога. На очереди конфигурация сервера с помощью Ansible.

На очереди конфигурация сервера с помощью Ansible. Данная статья будет разделена на три блока: несколько слов о результатах первой статьи, блок о самом инструменте Ansible и блок о конфигурации сервера с помощью него. 

Полагаю, каждый разработчик рано или поздно приходит к мысли о том, что ему есть, что рассказать и чем поделиться. Кто-то даже начинает это делать в том или ином формате. И, конечно, хочется сказать спасибо всем тем, кто отвечает на вопросы на stackoverflow, пишет статьи или делает еще какой-либо контент. Однако быть автором труд весьма специфичный, всегда есть риск, что твой контент не будет полезен или даже интересен. За несколько лет мною было написано около пары десятков статей, а также было начато несколько своих проектов, но все это выглядит на первый взгляд как «работа в стол».

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

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

Изначально эта статья задумывалась, как рассказ о различиях и назначении полей dependencies, devDependencies и peerDependencies в package.json. Эту тему выбрали ребята в моем телеграм-канале, кстати подписывайтесь, если еще не. Однако, когда я посмотрел количество контента на эту тему, то понял, что его достаточно даже в русском сегменте. При этом я прочитал одну статью, которая показалась мне очень хорошей, а также там были мысли на тему будущего управления зависимостями.

В итоге, я решил кратко пересказать вышеупомянутую статью, чтобы лучше самому усвоить тему, а также набросать проект по управлению зависимостями прямо на клиенте, через ES Modules. Так что вы можете прочитать либо оригинальную и полную статью у автора, либо сокращенную версию в первой половине этой статьи. А разбор работы ESM будет во второй половине.

Думаю, многие в курсе, что JetBrains остановили продажи своих продуктов на территории России, но стоит отдать должное оставили бессрочные лицензии на ту версию продукта, что использовалась на тот момент. Не круто конечно, но долгое время меня этот момент не волновал. Да, не самое свежее ПО, но и платить не нужно. Однако недавно на одном из проектов мне было нужно перейти на Vite и Vitest. И в этот момент я осознал, как для меня важно запускать тесты из IDE. Оказалось, что моя версия WebStorm не поддерживает Vitest.

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

Как вы, наверное, поняли, сегодня будет рассказ о том, как я сменил религию IDE, совершив переход с WebStorm на Cursor (VS Code).

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

За моими плечами 6 лет в enterprise разработке и и еще много лет другой работы, которую я совмещал с фрилансом по разработке, а через месяц мне будет 32 года. Это не только короткая справка обо мне, но и важный контекст для моих размышлений. Дело в том, что не только разные подходы к организации времени подходят разным людям, но одному человеку в разные этапы его жизни также будут подходить разные подходы относительно организации его времени. Кто-то моложе и имеет больше сил, кто-то старше и может иметь меньше сил, а бывает и наоборот. Но цель организации времени для разных людей в разные моменты жизни одна. И эта цель - не успеть все или как можно больше, как мне казалось совсем недавно, а определить подходящий тебе темп, чтобы ты чувствовал себя хорошо, чтобы ты был на пике своей формы постоянно, чтобы ты жил для себя, а не для работы или своих дел.

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

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

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

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

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

Именно кастомные шаблоны и бонусом, кастомная конфигурация, будут раскрыты в текущей статье. Поехали!

Прежде чем начать писать данную статью, я озадачился интересным вопросом. А кто как вообще работает с API в 2024 году? Для меня наличие Swagger-контракта или OpenAPI-контракта уже несколько лет как must have. И откровенно говоря, мне сложно представить, что люди не используют этот фреймворк для работы c REST API. Однако, если среди читателей таковые есть, и вам до сих пор скидывают «дтоошки», то вперед осваивать и продвигать OpenApi.

Для понимания работы swagger-typescript-api я сначала кратко опишу основные моменты спецификации OpenAPI. Читатели, которые уже знакомы с этим, могут сразу перейти к части про swagger-typescript-api.

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

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