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

Мессенджеры, это отличная альтернатива, и это путь, который я выбрал. Telegram предоставляет один самых простых способов создания ботов (если не самый простой). На его месте может быть что угодно — другие мессенджеры, телефонные звонки (Amazon Connect) или Яндекс Диалоги.

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

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

Это статья нацелена, чтобы заполнить некоторые пробелы, которые могли возникнуть, и в конечном счете улучшить вам сервис на node.js.

P.S. Ни в коем случае не считаю себя экспертом: есть куда расти. Но вместе с тем есть чем поделиться.

Файловая структура проекта

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

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

Приготовьтесь написать клон сервиса по доставке еды deliveroo.co.uk используя современные технологии: Nuxt.js, GraphQL, Strapi и Stripe!

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

При обработке входящего HTTP запроса требуется выполнить большое количество действий, таких как:

• Логирование входящего HTTP запроса
• Проверка на допустимость HTTP метода
• Выполнение аутентификации (basic, MS AD, ...)
• Проверка валидности token (при необходимости)
• Считывание тела (body) входящего запроса
• Считывание заголовка (header) входящего запроса
• Собственно обработка запроса и формирование ответа
• Установка HSTS Strict-Transport-Security
• Установка Content-Type для исходящего ответа (response)
• Логирование исходящего HTTP ответа
• Запись заголовка (header) исходящего ответа
• Запись тела исходящего ответа
• Обработка и логирование ошибок
• Обработка defer recovery для восстановления после возможной panic

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

Повторять все это в каждом HTTP обработчике крайне неэффективно.

Даже если вынести весь код в отдельные подфункции, все равно получается примерно по 80-100 строк кода на каждый HTTP обработчик без учета собственно обработки запроса и формирования ответа.

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

Этот подход реализован в шаблоне backend сервера на Golang

В попытках оптимизировать 2D анимацию созданную в canvas, был найден один интересный вариант.

Предварительная визуализация — prerender.

"А что если записать все кадры заранее и показать их после окончания анимации?" — подумали мы с товарищем и вот что получилось на следующий день.

Привет всем, меня зовут Илья. В ИТ я работаю около 6 лет, последние 2 года — в компании «Яндекс.Деньги» фронтенд-разработчиком. В обязанности входит поддерживать/развивать части приложений, в данный момент проект «Личный кабинет» (и нет, это не просто «в ие неправильные отступы поправить», «кнопке цвет поменять» или «быстро форму сошлепать»).

В отделе разработки у нас есть внутренний проект Challenges — так мы называем задачи, не связанные напрямую с основными продуктами. Это задачки, которые будут общественно полезны, помогут улучшить инфраструктуру, CI/CD и другое. Например, доработать бота, оповещающего о релизах, сделать плагин для IDEA по автогенерации assert по объекту и провести рефакторинг старой UI-библиотеки. Такие «вызовы» можно брать по желанию — они прекрасно подходят для разбавления бизнес-задач.

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

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

Итак, есть Jenkins, Bitbucket, почта (или Telegram, Slack — что понадобится) и необходимость проверять размер бандла. Надо это всё подружить.

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



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

Мы погрузились в недра профайлера и обнаружили некоторые особенности работы с Buffer в Node.js, знание которых может сильно сэкономить ваше время и серверные ресурсы.

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

Привет, Хабр! Это второй пост в серии из трех частей, которая даст представление о механике и семантике работы планировщика в Go. Этот пост посвящен планировщику Go.

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

Автор статьи, перевод которой мы сегодня публикуем, решил рассказать о нескольких необычных способах измерения времени в браузерах. Для их использования понадобится доступ к различным API, которые применяются в веб-разработке, поэтому они не подходят для платформы Node.js. Правда, если кто-то нуждается в необычном способе измерения времени в Node.js, то, полагаем, после прочтения этого материала у него могут появиться кое-какие идеи на этот счёт.

Кнопка — это один из тех элементов, которые чаще всего используются на веб-страницах. Тег <button></button> может быть применён для запуска некоего процесса вроде вывода данных, открытия модального окна, отправки формы и так далее. В материале, перевод которого мы публикуем, речь пойдёт о тонкостях стилизации элемента button и о том, как оформлять кнопки с учётом того, чтобы они хорошо работали бы в любых браузерах. Кроме того, тут будет рассмотрено большинство часто используемых стилей кнопок. Поговорим мы здесь и о некоторых сложностях, которые возникают при работе с кнопками.

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

В прошлой статье наш проект выглядел так:



Теперь мы будем использовать и другие инструменты для веб-разработки, надеюсь у вас установлен Node.js и npm, если нет, то срочно установите. И так открываем терминал и запускам:

Приветствую! Представляю вашему вниманию перевод статьи «Understanding CSS Grid: Creating A Grid Container» автора Rachel Andrew

Хотя технология CSS Grid стала поддерживаться некоторыми браузерами еще в 2017 году, у многих разработчиков пока не было возможности использовать её в своих проектах. Технология CSS Grid привносит множество новых свойств и значений. Из-за этого может казаться сложной. Однако, многие используемые в ней инструменты являются взаимозаменяемыми, а это значит, что вам не нужно изучать всю спецификацию, чтобы начать. Цель серии статей "Понимание CSS Grid" – провести читателей по пути от новичка до эксперта.

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

В этой статье мы рассмотрим:

• Создание grid-контейнера с помощью display: grid или display: inline-grid
• Создание колонок и строк с помощью grid-template-columns и grid-template-rows
• Управление размерами неявных треков (полос / дорожек) с помощью grid-auto-columns и grid-auto-rows

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

В данной статье я хочу рассказать, о том, как можно сверстать «хорошо» (по крайней мере структурировано ;), а заодно рассказать и о методологии, которая может «упростить жизнь» при верстке. Структура поста будет следующей:

• BEM
• Собственно пример — как сверстать страницу

Key promoter X

Использование сочетаний клавиш вместо мыши может значительно повысить производительность. С таким количеством функций, которые предлагает IDEA, это может быть пугающим и трудным для изучения всех быстрых клавиш. К счастью, есть плагин под названием Key Promoter X, который может вам помочь.

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

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

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

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

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

С другой стороны, мы могли просто переименовать файлы и включить их в один прекомпилированный css (без какого-либо рефакторинга). Но для улучшения кода было бы хорошо порефакторить стили. Эта работа более затратная, но в будущем себя бы окупила. И, что самое важное — это позволило бы нам работать быстрее, с большей уверенностью что мы что-то не сломаем.

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

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

На этот раз было решено построить визуально регрессионный набор тестов.

На днях писал тесты для модуля, который взаимодействует с базой данных. Привязывать модуль тестов к настоящей базе данных не хотелось — это создаёт дополнительные требования к окружению, где будет выполняться тестирование. Создавать сразу экземпляры типа sql.Rows, с нужными табличками также не хотелось — для меня этот тип "чёрный ящик", и хотелось бы, чтобы так оно и оставалось. Поиском по теме ничего интересного также не нашлось.

Захотел поделиться с сообществом своей находкой: в основной поставке Go, есть почти готовый инструмент для таких нужд: называется FakeDb.

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

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

Это цикл статей больше специалистов, значительно более углубленно, чем все мои прошлые статье в этой области. В статье я расскажу про крупнейшие интернет-магазины США, Китая, России и Украины, расскажу как маркетинг влияет на проектирование, покажу подробный Mind Map гипермаркета, опишу 57 основных модулей интернет-магазинов для внешней (покупательской) части и более 50 модулей для внутренней части (административной), покажу интерфейсы магазинов и еще много полезного.

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

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