Профессия: No-Code / Low-Code разработчик

Телефон, почтовый индекс и идентификатор лучше не хранить как обычные числа. У них могут быть ведущие нули, знаки и буквы; арифметика с ними не нужна. Если идентификатор E-101 превратить в число, смысл будет утрачен. Тип поля выбирайте по будущим действиям, а не по внешнему сходству значения.

Пустая строка, отсутствующее поле и нулевое значение различаются. Стоимость 0 может означать бесплатную услугу. Отсутствующая стоимость означает, что цену ещё не определили. Если автоматизация смешивает эти состояния, она отправит неверное предложение. Для каждого важного поля заранее задайте, что делать при отсутствии значения.

Записи и связи

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

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

Уникальный идентификатор не должен зависеть от имени клиента или номера строки. Имя меняется, строки сортируются. Для учебных данных мы используем понятные коды R-101 и E-101. В рабочей системе обычно применяется идентификатор, созданный платформой или согласованным механизмом. Красивый номер для человека можно хранить отдельно.

JSON

и сопоставление полей

JSON — распространённый текстовый формат передачи данных. Он описывает объекты, списки и значения. Не нужно учиться писать большую программу, чтобы понимать небольшой объект. Каждая пара состоит из имени поля и значения. Кавычки вокруг текста важны; число записывается без кавычек, если получатель ожидает именно числовой тип.

В учебном событии поля event_id, service_code и description обозначают идентификатор события, код услуги и описание. Получатель должен заранее знать, какие поля обязательны. Если один сервис отправляет service, а другой ищет service_code, значение не появится автоматически. Это и есть задача сопоставления полей — mapping.

Сначала нарисуйте соответствие на бумаге: поле формы Service → service_code события → Service записи приложения. Затем настройте его в редакторе. Так проще заметить, что русское отображаемое название и технический код используются по-разному. Для пользователя показывается «Ремонт стиральной машины», между сервисами передаётся washer.

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

API

и вебхук

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

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

Не путайте адрес вебхука с публичной страницей. Длинный случайный адрес затрудняет угадывание, но сам по себе не всегда достаточен для защиты. Там, где источник поддерживает подпись или другой способ подтверждения, используйте его. Если такой возможности нет, поставьте контролируемый приёмник, ограничьте полномочия и не передавайте чувствительные данные без проверки архитектуры.

Ответы и ошибки

HTTP-ответ содержит код состояния. Коды семейства 2xx обычно означают успешное принятие запроса на соответствующем уровне. 400 часто указывает на неверный запрос, 401 — на отсутствие подходящей авторизации, 403 — на запрет, 404 — на ненайденный ресурс, 429 — на превышение ограничений, 5xx — на проблему на стороне сервера. Точное значение уточняется в документации API.

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

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

Время и порядок

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

Дата без времени подходит для дня рождения или отчётного дня. Момент события требует времени и зоны. Строка «14.10.2026 10:00» не сообщает, в каком регионе произошло действие. Запись 2026-10-14T07:00:00Z однозначно обозначает UTC; отображение в конкретной зоне выполняется отдельно.

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

Практика чтения данных

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

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

Сохраните словарь полей. Для каждого укажите техническое имя, тип, обязательность, пример и назначение. Этот документ будет использоваться в Tilda, Bubble и Make. Когда все три части называют одно значение одинаково, интеграции становятся заметно проще.

Глава 4. Сайт на

Tilda

от пустой страницы до формы

В этой главе вы соберёте сайт мастерской. Его задача проста: объяснить, какие услуги доступны, показать порядок обращения и довести посетителя до формы. Мы не будем начинать с анимации и необычной композиции. Сначала сделаем понятную страницу, затем проверим её на разных экранах и подключим учебный приём данных.

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

Структура страницы

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

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

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

Блок услуг содержит три карточки: стиральные машины, холодильники и посудомоечные машины. У каждой есть название, краткое описание и ссылка к форме. Цена пока не указывается: в нашей модели она определяется после уточнения. Если добавить «от 500 рублей» без объяснения состава, посетитель может ожидать полный ремонт за эту сумму.

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

Сборка стандартными блоками

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

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

В каждом блоке различайте содержание и настройки. Содержание — тексты, изображения, ссылки и поля. Настройки — размер, цвет, отступы, фон и видимость. Если менять оба слоя одновременно, трудно понять, что испортило результат. Сначала заполните содержание всей страницы, затем займитесь внешним видом.

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

Текст и смысл кнопок

Кнопка должна объяснять действие. «Подробнее» подходит для перехода к описанию; «Отправить заявку» — для отправки формы. «Начать» и «Далее» могут быть понятны внутри конкретного процесса, но на первом экране часто не сообщают, что произойдёт. Посетитель должен понимать действие до нажатия.

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

Для перехода к форме используйте якорную ссылку. Якорь — отметка внутри страницы, к которой браузер может прокрутить содержимое. Задайте устойчивое имя, например request-form, и подключите его к кнопкам. После публикации проверьте переход с начала и середины страницы. Если закреплённое меню закрывает заголовок формы, скорректируйте отступ или поведение меню.

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

Изображения и права использования

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

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

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

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

Типографика и композиция

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

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

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

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

Форма обращения

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

Назначьте технические имена service_code, contact_demo и description там, где выбранный блок позволяет задать имена переменных. Отображаемая подпись может быть русской. Проверьте, какие значения отправляет выпадающий список: видимый текст, технический код или оба значения. Не предполагайте, что слово washer появится автоматически, если в поле видна «Стиральная машина».

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

Обязательными сделайте услугу и тестовый контакт. Описание оставьте необязательным, но ограничьте разумную длину, если это поддерживается выбранным способом обработки. Пример подсказки: «Для демонстрации используйте [e-mail]». Домен example.com предназначен для примеров; не отправляйте туда реальные уведомления и не рассчитывайте на получение письма.

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

Сообщения об ошибках и успехе

Пустое обязательное поле должно вызывать сообщение рядом с ним или другой явно связанный сигнал. Сообщение «Ошибка» слишком короткое. Подойдёт «Выберите услугу» или «Укажите тестовый контакт». Если внешний сервис не отвечает, не обвиняйте пользователя: «Не удалось отправить. Попробуйте позже» понятнее, чем технический код на весь экран.

Сообщение об успехе зависит от того, что подтверждено. Если форма только принята платформой, текст «Мастер уже назначен» неверен. Для учебной версии используйте «Учебная заявка отправлена. Проверьте её появление в журнале». Для реального сайта обещайте только согласованный следующий шаг.

Проверьте поведение повторного нажатия. Даже если кнопку временно блокирует интерфейс, пользователь может отправить ту же форму после обновления страницы. Поэтому защита от повторов не заканчивается в браузере. Её нужно учитывать на стороне обработки событий и записей.

Подключение приёмника

У Tilda есть встроенные сервисы приёма данных. Общая последовательность такова: подключить сервис в настройках сайта, выбрать его в конкретной форме, сохранить и опубликовать страницу. Сам факт появления подключения в настройках сайта ещё не означает, что новая форма отправляет данные именно туда.

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

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

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

Первая публикация

Сохраните страницу и опубликуйте её на учебном адресе. Откройте адрес в другом окне, где вы не работаете в редакторе. Проверьте заголовок, все кнопки, порядок блоков и форму. Затем обновите текст в одном блоке, повторно опубликуйте и убедитесь, что изменение действительно появилось.

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

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

Проверка содержания

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

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

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

Глава 5. Мобильная версия, домен и запуск сайта

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

Мы также разберём Zero Block, домен, HTTPS, базовые настройки поиска и аналитики. Эти задачи относятся к одной цели: посетитель должен найти страницу, понять её и выполнить действие. Подключение десятка инструментов без проверки основного пути не улучшает запуск.

Мобильная проверка по действиям

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

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

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

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

Когда нужен

Zero

Block

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

Выберите один учебный участок — например, небольшой блок «Как проходит обращение». Соберите в Zero Block заголовок, три шага и кнопку. Не переводите в него весь сайт сразу. Так вы сможете сравнить трудоёмкость и понять, оправдывает ли собственная композиция дополнительную поддержку.

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

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

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

Размеры и доступность

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