Итак, настал тот moment, когда вам нужно работать с датами в разных часовых поясах (Новый год же!), а ваш архитектор/начальник не разрешает использовать Moment Timezone или Luxon, потому что они увеличат размер вашей сборки, а для вашего проекта важно, чтобы UI грузился быстро. Или потому что вы делаете небольшую задачу, и непонятно пока, будет ли расширение работы с часовыми поясами.

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

По аналогии с принципом LSP из ООП, при работе с функциями в Typescript стоит придерживаться следующего принципа:

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

Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код.

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

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

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

Всем привет! Сегодня я хочу поделиться приемами улучшения производительности фронтенда путем оптимизации RxJS стримов.

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

В этих двух статьях я буду сравнивать TailwindCSS с чистым CSS + BEM. Цель - разобраться что является лучшим решением для хорошей архитектуры приложения. Это не вопрос предпочтений, от этого выбора будет зависеть очень многое на поздних этапах разработки и оно должно быть очень хорошо обосновано. Начну со сравнения производительности. Tailwind позволяет значительно уменьшить размер итогового CSS и тем самым ускорить время отображения страницы. Но это сработает только в том случае, если Tailwind классы будут написаны прямо в HTML коде, а не в виде @apply в CSS. Tailwind уменьшает CSS, но увеличивает HTML. Давайте посчитаем разницу с учетом HTML. Будем сравнивать чистый Tailwind с чистым CSS + BEM.

Всех нас учили, что в JavaScript есть примитивные и ссылочные типы данных. Исчерпывающая информация есть в официальной документации, а на просторах интернета полно статей на этот счет.

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

В одном из своих предыдущих постов под названием "Эйлер, Чёрч и Мандельброт — этюд о красоте и математике" я немного затронул тему рассмотрения функционального программирования в качестве основы реальности. Под тем постом было оставлено множество интересных комментариев, один из которых, написанный @nickolaym, вдохновил меня на развитие мысли в данном направлении. Так появился этот пост, в котором прямо как во времена пифагорейской школы и платоновской академии философия переплелась с математикой, а математика с философией.

Привет, Хабр!

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

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

Итак, что такое pg_trgm? Этот модуль PostgreSQL предоставляет набор функций и операторов, которые позволяют работать с трехграммами (триграммами) - это последовательности из трех символов. Для понимания, давайте взглянем на пример...