JavaScript *

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

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

Но почему-то, в случае с регэкспами у программистов как будто появляется слепое пятно на чувстве стиля. Вот такая регулярка – совершенно обычное дело:

/^(0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])[- /.]((19|20)\d\d)$/

Тестирование приложений через сквозные (end-to-end) тесты сейчас довольно популярно. Этот вид тестирования позволяет оценить работоспособность приложения со стороны пользователя. Поэтому компания, в которой я работаю, внедряет этот вид тестирования в проекты.

Летом 2022 года мы разрабатывали блокчейн приложение. Моя задача заключалась в проведении E2E тестирования DApp [Децентрализованное приложение — приложение, которое базируется на технологии блокчейн совместно с механизмом распределенного выполнения необходимых инструкций]. Но мы столкнулись с проблемой - готовых решений для проведения end-to-end тестирования DApp под нашу конкретную задачу не было. Эта статья о том, как мы решали эту проблему.

Создадим приложение с использованием фреймворка Next.js, настроим облачные сервисы Amazon S3, Amazon CloudFront, AWS Lambda@Edge, развернем приложение и настроим маршрутизацию доменного имени.

Привет, друзья!

Представляю вашему вниманию перевод этой статьи, вызывавшей определенный резонанс в сообществе React-разработчиков.

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

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

Правильное решение - это со старта внедрять бухгалтерию с двойной записью (double ledger).

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

Есть MVC-приложение на frontend, которое активно расширяется:  создаются новые модели, представления и контроллеры.
Со временем такое приложение начинает напоминать лабиринт из моделей, а баги, живущие в этом лабиринте превращаются в настоящих минотавров. Но все не так плохо, похоже есть нить, которая ведет из этого лабиринта…

Всем привет! Сталкивались ли вы с ситуацией, когда в вашей админке пользователям трудно интуитивно разобраться, возможности быстро исправить это нет, а существующую документацию по ней никто не читает? Знакомы ли вам частые вопросы вида "А как это настроить?" или "А можно ли сделать настройками X?", ответы на которые уже описаны?

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

Реализация автоматического импорта событий из календаря Notion в свой Google Calendar. Также, под катом, ссылка на npm пакет, упрощающий данную процедуру и пример запуска данного решения без аренды своего сервера.

Идея создать проект «По местам съёмок фильма «Брат» пришла спонтанно, когда я собирался в поездку в Санкт-Петербург. Подумал о том, что я могу объединить профессиональные знания в картографии и своё почтительное отношение к фильму, тем более, что совсем недавно было 25 лет со дня выпуска фильма. Стандартные туристические маршруты надоели. Мне не нравится гулять там, где ходят толпы туристов, делая одни и те же фотографии.

Первый этап — это понимание того, где конкретно снят тот или иной фрагмент. Информацию искал в интернете, но многие точки были описаны очень неконкретно. Двор на такой-то улице или Морская набережная, 15Б, а по факту этот дом на 29 подъездов. Приходилось на месте искать точки съемки и делать фото, потом уточнять точки в геоинформационной программе на карте QGIS.

В голове почти любого человека начиная с 2018-2019 года появляются мысли о том, чтобы поменять профессию на что-то около IT. Эти мысли сразу разбиваются о скалы нескольких больших мифов.

Я люблю сталкиваться с трудностями. Но с такими, которые можно решить, подумать над интересным решением, подобрать технологию. Люблю быть в потоке, а после решения чувствую себя настоящим профессионалом.

Но есть кое-что, из-за чего я не люблю программировать. Как ни странно, это тоже трудности, только другого рода. Например, когда, чтобы пофиксить баг, приходится разбираться с легаси-компонентом, который написан на классах на 300 строк кода. Разбираясь уже второй час, ловлю себя на мысли, что уже 10 минут просто смотрю в экран, а в голове «из-за угла» выглядывает мысль «Псс, парень, программирование — это не твое». Такие задачи не вызывают удовлетворения.

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

Привет, друзья!

Представляю вашему вниманию перевод этой замечательной статьи, посвященной 4 малоизвестным API, которые в некоторых ситуациях могут оказаться весьма полезными:

• Page Visibility API;
• Web Share API;
• Broadcast Channel API;
• Internationalization API.

Код примеров на GitHub.

В предыдущей части мы научились эффективно передавать данные вспомогательным потокам из основного через разделяемую память, используя Atomics-операции и блокировки.

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

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

Браузеры постоянно добавляют новые функции HTML, JavaScript и CSS. Вот несколько полезных дополнений к работе с формами, которые вы могли пропустить…

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

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

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

Всем привет. Меня зовут Андрей, я работаю в компании SegmentStream, занимаюсь вопросами архитектуры, инфраструктуры и написанием кода. Сегодня я расскажу как мы адаптировали Cube под наши нужды. В рамках статьи я не буду подробно рассказывать про сам Cube, если вы не знакомы с Cube, то лучше сначала немного почитать про него на официальном сайте cube.dev/docs. Если говорить про SegmentStream, то мы разрабатываем SaaS-платформу для оптимизации рекламных кампаний на основе машинного обучения. Звучит просто, но я рекомендую почитать, там много интересных вещей.

Также, в статье будет достаточное количество кода на TypeScript, который можно при желании не стесняться заимствовать. Я постараюсь оставлять объяснения к нему.

Если у вас есть компьютер и вы используете его по назначению, то скорее всего вы так или иначе работали с приложениями на Electron (даже если об этом не знали).

Меня зовут Сергей Володин, я руковожу командой разработки VK WorkMail. В этой статье я расскажу, как на основе Electron мы за две недели создали PoC кроссплатформенного настольного приложения Почты, что узнали о технологии и к каким выводам пришли.