No-code

Этот манифест Эммануэль Страшнов, со-основатель No-Code-сервиса bubble.io опубликовал еще в 2014 году в Huffington Post. Но до сих пор он читается как текст из будущего. Зерокодинг не просто новая нефть, это путь развития и освобождения человека.

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

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

В 80-х и 90-х годах инженеры создавали такие продукты, чтобы людям надо было говорить по-компьютерному. Apple и Microsoft взлетели, сделав компьютеры доступными для всех с помощью графического, интуитивного и простого пользовательского опыта. Когда они только возникли, людям приходилось изучать командную строку, чтобы использовать компьютеры. Mac II и Windows заменили терминал графическим пользовательским интерфейсом и это сделало компьютеры доступными не только горстке технарей, но и всем людям так ПК завоевали мир. И это типичная тенденция в технологиях: с течением времени все становится проще и все больше людей использует эти упрощенные решения.

Программирование еще не пошло по этому пути. BASIC, одному из первых языков программирования исполнилось 50 лет в мае 2013, но языки программирования до сих пор работают на тех же принципах. Сегодня люди точно так же программируют, набирая строго структурированный текст то есть код все в том же текстовом редакторе. Получается, мы должны писать так, чтобы компьютеру было легко анализировать программы, а не так, чтобы нам легко было их читать. Конечно, процесса программирования заметно ускорился и этому способствовали лучшие проекты для обучения (например, Stack Overflow) и совместного использования кода (движение Open Source или FSF). Но несмотря на все эти усилия, мы всё ещё должны учиться на инженера, чтобы создавать программное обеспечение.

Я не могу представить себе людей, которые через 50 лет программируют так же, как мы сейчас. Этого просто не может быть. Будущее, которое я себе представляю, это мир, в котором программирование не требует сложных объяснений, где люди просто разговаривают с компьютерами и так создают программное обеспечение. Чтобы попасть в этот мир, инструменты программирования должны говорить с нами на одном языке. Нам не надо писать код, чтобы сделать кнопку красной надо просто показать на нее пальцем и выбрать нужный оттенок. И вместо того чтобы говорить о понятиях, которые волнуют компьютер (например, переменные и серверы), инструменты программирования должны говорить о вещах, которые волнуют программиста (картинка или заказ одежды).

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

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

Революция в программировании это одна из самых удивительных возможностей нашего времени. Нет такой области, где компьютеры еще не оказывали бы сильного влияния и это только начало. Удивительно, компьютеризация позволяет сделать больше с гораздо меньшими усилиями. Так как же прийти в это прекрасное будущее? Есть два пути. Один из способов довериться инженерам, чтобы они создавали продукты, которые будут преобразовывать мир. Тогда бы мы и по факту мы уже начали это делать превратили инженеров в элитный класс, который управляет миром. Технологические гиганты будут контролировать нашу жизнь. Люди, которые не умеют программировать, в какой-то момент станут лишними. Подумайте о таксистах. Они всё ещё будут нужны, когда беспилотники Google станут мейнстримом? А ведь речь идёт о массе людей: только в Соединенных Штатах 3,5 миллиона водителей грузовиков и 300 000 таксистов. А значит, во всем мире сотни миллионов людей рано или поздно потеряют работу.

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

Пообщаться с фанатами зерокодинга можно в чате Bubble Chat & Community и канале Зерокодер.

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

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

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

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

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

Важная оговорка: рассмотренная здесь задача выбрана только для демонстрации примера расчетов no-code, а терминология может раздражать, например, специалиста 1С. Терминология и организация не важны, мы обсуждаем механизм расчетов без кода.

Коротко о предметной области. Есть понятие движение в рамках какого-то договора с контрагентом. У договора есть сальдо сумма нашего долга контрагенту. Движение показывает, какое количество товара (номенклатуры) поступает и расходуется со склада. Для каждой номенклатуры мы храним остатки на складах, вычисляем себестоимость.

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

Проводка означает отражение сумм документов на сальдо договора и остатках на складах. В результате проводки мы снимем пометку Черновик с документа и изменим сальдо по договору на сумму движения. Если на эту дату записи Сальдо нет, то мы создадим её. Также мы пересчитаем остатки товаров на складе. Если записи по остаткам на этот день нет, то мы её создадим.

Данные, введенные в систему согласно этой структуре, выглядят примерно таким образом:

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

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

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

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

Вот так выглядит и работает конструктор запросов, в котором мы выбираем нужные нам данные:

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

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

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

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

В следующем случае запрос объединит таблицы шапки документа, справочника договоров, регистров сальдо с фильтром на дату документа:

Будь мы программистами SQL, мы бы написали операторы JOIN ON и WHERE, написав соответствующие условия на объединение таблиц и отбор только тех Сальдо, которые относятся к дате документа. Здесь же мы задали имя формулы в нашей колонке Движение, а затем использовали это имя в фильтре по дате, взяв в квадратные скобки. Конструктор сам извлёк и объединил нужные нам данные, мы только наложили дополнительное условие по дате сальдо.

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

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

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

Вычисленные значения можно присвоить вместо имеющихся в базе данных, записав их в поле SET Присвоить:

Мы задаем нужное нам выражение в поле SET колонки Сальдо, а конструктор запишет его результат вместо существующего значения сальдо.

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

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

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

Получившийся запрос Сальдо вставим в выражение в поле SET, чтобы получить корректное значение сальдо, даже если записи о предыдущем сальдо нет:

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

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

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

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

• ROUND(x, 2) округление x до двух знаков после запятой (аналог в экселе ОКРУГЛ())

• IF(A, B, C) если условие A верно, то вернуть B, иначе C (аналог ЕСЛИ())

• x IS NULL Истина, если x пустое или неизвестно (аналог ЕПУСТО())

• SUM(x) просуммировать все x с группировкой по остальным полям (аналог СУММА())

• abn_ID возвращает внутренний ID объекта, нужна для однозначного его определения

Этот запрос делает всё то, что мы собирались сделать в начале этой заметки инвертирует пометку Черновик у документа, пересчитывает сальдо договора, остатки товаров на складе и их средневзвешенную себестоимость. То есть, он проводит документы, но также умеет откатить проводку и вернуть все остатки, себестоимости и сальдо, как было!

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

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

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

Подводя итог, вам часто придется программировать даже в no-code и low-code системах, однако большую часть функционала вы сможете сделать, не владея программированием, и в достаточно короткий срок.

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

Применимость low-code: случаи, когда уникальная интеграция и визуализация занимают 90% усилий проекта и длятся, условно, 4 дня на проекте в 1 неделю. Часто базу данных и бэкенд можно накликать за 1 день, вместо 1-2 недель в традиционной разработке.

Пример, рассмотренный в статье, был сделан по ТЗ для простого приложения в 1С. В конструкторе с чистого листа были реализованы бизнес-сущности и формы ввода документов, которые уже есть в 1С. Для сравнения приведу некоторые факты (сравнение весьма субъективное, ибо 1С крут в своём сегменте, а тут нам нужно быстро собрать MVP):

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

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

Другое дело, что следует продумать архитектуру системы, а в случае необходимости трансформировать её, для чего нужен опыт разработки. Да, сильные разработчики будут востребованы даже во времена no-code, если таковые всё-таки наступят.

Ещё, говоря о серьезном продукте, следует вспомнить про релизы, версионность, масштабируемость, авто-тесты, CI/CD и прочие сопутствующие вещи. Здесь всё достаточно просто конструктор, так же как и любая система, может быть покрыт стандартными процедурами. Можно выгрузить его состояние в гит, сравнить версии, оформить релиз и процедуру отката, но это тема отдельной статьи.

Все мы в последнее время довольно много слышим о платформах low-code/no-code. Платформы без кода обещают сделать разработку программного обеспечения столь же простой, как использование Wordа или PowerPointа, чтобы обычный бизнес-пользователь смог продвигать проекты без дополнительных затрат (денег и времени) на команду инженеров. В отличие от платформ без кода, low-code по-прежнему требует определенных навыков программирования, однако обещает ускорить разработку программного обеспечения, позволяя разработчикам работать с предварительно написанными компонентами кода.

Согласно Gartner, к 2024 году 65% разработанных приложений будут относиться low-code.

Еще в 2017 году я участвовал в раннем сравнительном тестировании производительности традиционной разработки (с использованием Java) и проектом low-code/no-code, основанном на моделях. Результаты были впечатляющими: при использовании метода low-code/no-code производительность увеличивалась в 5-7 раз. Опрос, проведенный компанией No-Code Census в 2020 году, показал прирост производительности в 4,6 раза по сравнению с традиционным программированием.

Low-code/no-code: Фрагментация платформы

Область low-code/no-code довольна сложна и включает в себя многочисленные решения, платформы и субрынки. Например, существуют субрынки, ориентированные на крупные, средние и малые предприятия. Корпоративные платформы low-code/no-code обеспечивают высокую масштабируемость, производительность, безопасность и интеграцию с приложениями предприятия. Они, как правило, дороже остальных. Ниже представлен Магический Квадрант Gartner для корпоративных low-code платформ:

Gartner дает платформе low-code (LCAP) следующее определение: Это платформа, которая поддерживает быструю разработку приложений, одноэтапную раскатку, выполнение и управление с использованием декларативных абстракций программирования высокого уровня, таких как языки программирования на основе моделей и метаданных.

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

Неудивительно, что многие платформы low-code являются платформами управления бизнес-процессами. BPM уже давно поддерживает разработку на основе моделей (Model-driven Development), где нужно нарисовать диаграммы, объясняющие, как должно работать программное обеспечение, прежде чем его создавать. Эта схема похожа на процессный подход BPM, при котором для задания бизнес-процесса необходимо в правильном порядке расположить блоки, представляющие собой подпроцессы. (Самым популярным стандартом отображения процессов, поддерживаемым большинством BPM-платформ, является BPMN). Поэтому процессно-ориентированные решения достаточно популярны. Примерами low-code/no-code платформ для BPM являются Appian, Pega, Outsystems.

Но существуют и другие примеры под эгидой low-code/no-code:

Веб-платформы для использования предприятиями любого размера. Ведущими конкурентами являются WordPress, Wix, Squarespace и WebFlow.

Платформы управления базами данных, начиная от таких, как Mendix, и заканчивая такими, как Airtable. Существуют также low-code/no-code платформы баз данных NoSQL, например, KgBase, предназначенная для построения графов знаний.

Платформы с автоматизированной интеграцией, среди которых несколько новых и интересных, например, Zapier, Parabola и Integromat. С помощью них вы можете быстро разрабатывать мощные и сложные схемы интеграций. Вот пример рабочего процесса Parabola, в котором данные извлекаются из API, с ними выполняются некоторые действия, а затем данные отправляются в другой API. Процесс можно запускать по запросу, по расписанию или через вебхуки.

Разработка мобильных приложений. Большинство платформ low-code/no-code, таких как Bubble, предоставляют возможности адаптивного пользовательского интерфейса, другие предлагают встроенную поддержку ведущих мобильных OC (iOS и Android). Thunkable пожалуй, лучший пример low-code/no-code платформы для разработки мобильных приложений.

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

Другие категории платформ нацелены на определенные области или ниши приложений:

• E-commerce и онлайн-магазины: лидирующим примером здесь является Shopify.

• Управление рабочим процессом: отличный пример Monday.com.

• Приложения ERP (планирование ресурсов предприятия): в качестве интересного примера (также указанного в MQ Gartner) можно привести Zoho. Еще одна важная и впечатляющая платформа для ERP и CRM это Salesforce.

• Блокчейн и Интернет вещей: Atra.

• Искусственный интеллект: сейчас мы начинаем наблюдать появление таких инструментов, как C3 AI Ex Machina.

Челленджи low-code/no-code

Платформы low-code/no-code имеют множество преимуществ, но в то же времясоздают определенные трудности и требуют обучения для работы с ними. Многие передовые практики только появляются и относительно незрелы, и следовательно, растет ответственность при их использовании. Что касается традиционного программирования, здесь накоплен огромный опыт, существуют сильные сообщества, а передовые практики задокументированы. Во многих отношениях low code/no-code находится в зачаточном состоянии даже несмотря на то, что разработка на основе моделей существует уже давно (особенно платформы BPM).

Вот некоторые из наиболее серьезных проблем:

1. Необходимость изменения культуры: low-code/no-code требует изменения культуры организации, будь то корпорация или стартап. Изменить культуру для избавления от лишних процессов непросто, это требует схожего видения и одобрения руководства, а также выделения бюджета и полномочий для центра компетенций по цифровой трансформации low-code/no-code.

2. Время и усилия на изучение платформ: low-code/no-code увеличивает скорость и производительность, но инструменты и платформы нетривиальны, и для развития необходимого уровня владения ими требуется время. Это один из наиболее неправильно понимаемых аспектов low-code/no-code. Сложные программные конструкции, такие как вложенные циклы, не так уж и просты на любой платформе.

3. Необходимость использования нескольких платформ: одни платформы имеют более полную функциональность, другие нет. Unqork и Bubble, например, предназначены для любого сценария использования и поэтому предлагают множество вариантов интеграции с корпоративными системами. Кроме того, они могут взять много полезного из других компонентов, специализирующихся в определенных областях; например, Bubble вместе, скажем, с Parabola или плагином Zapier можно использовать для автоматической интеграции. С возможностями управления данными и интеграциями в Parabola или Zapier работать легче, чем с нативными от Bubble. Существуют и другие плагины или технологические компоненты, дополняющие платформы low-code/no-code: посмотрите, например, список технологических партнеров Unqork или полный список плагинов для Bubble.

4. Недостаточность ресурсов и поддержки сообщества: в мире существуют миллионы, или даже десятки миллионов разработчиков обычных языков программирования, множество онлайн-курсов, а также книги и материалы, доступные для таких языков, как Java или C#, есть множество сообществ и ресурсов для аутсорсинга. Совсем иначе дела обстоят для low-code/no-code, особенно для более новых платформ.

5. Сбивающее с толку ценообразование: корпоративные low-code/no-code платформы, как правило, неоправданно дороги. Платформы для среднего и малого рынка менее затратны, но, как правило, менее масштабируемы. А использование нескольких платформ для создания комплексного решения еще больше усложняет вопросы ценообразования.

Это лишь некоторые из основных проблем. Они ясно дают понять, что low-code/no-code не панацея. Тем не менее, такой подход остается серьезной тенденцией для разработки инновационных решений как для действующих предприятий, так и для стартапов.

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

Готовы ли вы к переходу на low-code/no-code?

Примечание переводчика: наша компания предоставляет как low-code/no-code омниканальный облачный контакт-центр Voximplant Kit с широкими возможностями автоматизации обслуживания клиентов, так и serverless-платформу Voximplant для традиционной разработки с набором API для создания голосовых, видео- и текстовых коммуникаций.

No-code сейчас в тренде. Статей на эту тему пока не много, хотя они появляются достаточно регулярно. На Хабре по тегу no-code и его вариантам я нашел всего около 15 статей и первая из них появилась только в июне 2020 меньше года назад! Во время чтения одной из статей у меня возникла идея собрать разные варианты no-code сценариев и снабдить некоторых из них, наиболее востребованных, инструкциями по реализации. Мне кажется, это будет интересно многим. Внизу после туториала, вы найдете пока небольшой, но пополняемый список сценариев и опрос, а пока давайте посмотрим как реализовать один простой сценарий.

Он относительно многоцелевой и с его помощью можно сделать различные интеграции для электронной почты, в том числе временный адрес почты для регистрации на разных сайтах. Если вы считаете, что можно просто зарегистрировать очередной ящик на gmail, или если вы знаете реализации такого сервиса, можете написать об этом в комментарии и дальше не читать. Наверняка, можно сделать это проще, нужно меньше 10 строчек кода. Хорошо, если хотите, напишите и об этом. Ну а для остальных, кому интересны технологии no-code, но пока не доходили руки разобраться и что-то сконструировать самому, предлагаю подробное описание сценария и пошаговую инструкцию.

Описание задачи

Предположим, вам нужен временный адрес, который не жалко засветить при регистрации на малоизвестном сайте или сайте с репутацией, вызывающей вопросы. После регистрации или когда надобность в адресе отпадет, можем удалить или оставить, но временно заблокировать его (см. об этом шаг 10c ниже) вдруг нужно будет позже восстановить пароль. Идея простая и очевидная и такие сервисы наверняка есть, хотя я сам ими не пользовался. Говорят, что существует такой сервис у Apple, когда при регистрации с помощью Apple Id, он предлагает подменить основной почтовый адрес временным. Хорошая идея, но в данном случае она доступна только владельцам яблочных гаджетов, более того, сайт на котором нужна регистрация, должен принимать Apple Id. Также я сам видел бота, который предлагал временный адрес почты. Это был простейший бот, но он почему-то не работал.

Получаются два стартовых условия: 1) делаем свой, кастомный и настраиваемый сценарий; подробнее об этом см. варианты развития сценария шаг 11 почти в самом конце; 2) обходимся без единой строчки кода.

Конечно, сценарий будет зависеть от сторонних сервисов и их поставщиков, а также будет, скорее всего, платным. Но есть и хорошие новости, он может быть создан на коленке за считанные минуты. В самом худшем случае, если вы делаете это первый раз или если вдруг что-то пойдет не так, за 1-2 часа максимум. В последние несколько лет количество новых no-code сервисов растет как на дрожжах, так что сценарий может быть реализован разными способами и мы можем выбирать наиболее удобный вариант и таким образом снизить зависимость от провайдеров no-code. Поэтому добавляем еще условие: 3) задействованные сервисы должны быть легко заменяемыми и настраиваемыми. В одной статье не получится полностью описать, как реализовать все 3 условия, но будем считать это заделом на будущее развитие сценария (шаг 11). Кроме того, сейчас не будем подробно сравнивать разные альтернативы и объяснять, почему именно эти варианты выбраны. Об этом есть множество других публикаций (примеры есть по ссылкам в следующем абзаце) и, конечно же, можете написать обо всех альтернативах в комментариях.

Альтернативы no-code

Если вы в первый раз слышите о no-code, возможно вам будет интересно почитать вводные обзоры и статьи для знакомства с отдельными сервисами. Для старта подойдет небольшой обзор No-code как отличная альтернатива для быстрого решения бизнес-задач. Взвешиваем pro et contra Движение No-code конец программистов? Разбираем плюсы и минусы. Введение в один из инструментов на Хабре n8n. Автоматизация ИБ со вкусом смузи.

Мы подходим к задаче серьезно, поэтому изучив и выбрав лучшие (на сегодняшний день) из доступных альтернатив, уточним ТЗ.

Техническое задание

Нужно получить временный адрес и указать его при регистрации на каком-то левом сайте/сервисе сомнительного качества или с репутацией, вызывающей вопросы. И далее мы должны будем получить письмо или как-то прочитать его. Нас интересует только ссылка или код регистрации в теле письма, поэтому достаточно его извлечь и переслать дальше. Вот только куда? На основной адрес? Но зачем нам это письмо на почте, может лучше в виде короткого сообщения в чате или даже СМС-ки. Можно подключить WhatsApp, Slack или другой мессенджер. Но удобнее всего, конечно, Телеграм, для него и сделаем сценарий.

Проблемы, которые должен решать сценарий: 1) в общем случае текст письма может быть длинным, в то время как текст сообщения ТМ ограничен до 4096 символов, нужно обрезать длинные письма или разбивать их на части, 2) нам нужно также извлечь из письма ссылку или код для регистрации, т.е. нужно уметь обработать не только plain-text, но и HTML.

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

Шаг 1. Регистрируемся в Zapier

Если у вас есть аккаунт, этот шаг пропускаем. Если нет, нужно будет пройти стандартную процедуру регистрации на сайте Zapier и выбрать тарифный план или тестовый период. К сожалению, я регистрировался давно и точных условий сейчас не знаю, кажется, бесплатный тариф позволяет выполнить до 100 операций в месяц. Это совсем мало, но для тестирования сценария хватит. К тому же, посчитайте, как часто вы регистрируетесь на разных сайтах? И если этот сценарий придется вам по вкусу и вы захотите его и адрес почты использовать на всю катушку, можно будет попробовать заменить Zapier на другой сервис (например, бесплатный n8n) или заплатить за тариф, который вас устроит.

Шаг 2. Создайте новый Zap

Нажимаем [MAKE A ZAP] см. скриншот

Шаг 3: Укажите название запа и выберите триггер

Нужно как-то назвать Зап/сценарий и настроить триггер, который его запускает.

a) Жмем на Name your zap и вводим название запа. Вы можете выбрать любое. Я назвал его TMP Email Zap.
b) Далее в строке поиска вводим: email, Zapier покажет доступные почтовые сервисы.
c) В качестве триггера доступны различные приложения, но они потребуют дополнительных действий и регистрации новых сервисов, скорее всего. Нам не нужны такие трудности, выбираем простейший и первый в списке вариант Email by Zapier. См. скриншот выше.

Шаг 4: Выберите событие триггера

a) В разделе Trigger event нажмите на Choose an event
b) Тут вариантов не много: выбираем New inbound Email. См. скриншот выше.
c) Нажмите дальше [Continue]

Шаг 5: Выберите адрес email

Укажите адрес почты:

a) Появится поле для ввода email-адреса. Можете добавить любое слово. Но важно использовать ТОЛЬКО буквы в нижнем регистре или цифры, иначе вы не сможете пройти дальше.
b) Сохраните полученный адрес (кнопка [Copy]), вы будете использовать его для регистрации на левом сайте.
c) Нажмите дальше [Continue]. См. скриншот выше.

ВНИМАНИЕ!!!

Не показывайте никому этот адрес. Иначе вы рискуете попасть на спам. После чего, в лучшем случае, вы превысите бесплатные лимиты и сценарий перестанет работать, а в худшем случае придётся заплатить рублем, причём не деревянным, а зелёным по текущему курсу ЦБ. Хотя Zapier не очень дорогой, но платить только за спам совсем не хочется.

Шаг 6: Протестируйте email адрес

После того, как вы получили адрес почты, можете его протестировать.

a) Попробуйте отправить письмо на адрес, который вы получили на шаге 5b.
b) После отправки письма нажмите кнопку [Test Trigger]
c) Если ничего не происходит или Zapier пишет что-то вроде Request no found, подождите несколько секунд и еще раз нажмите кнопку письму нужно время, чтобы дойти до сервера Zapierа
d) Если письмо все еще не пришло, проверьте, правильно ли вы скопировали адрес
e) После того как Zapier получит тестовое письмо, он покажет содержание письмо и все доступные поля (sender, subject и пр. их довольно много).
f) После тестирования, нажмите кнопку [Continue]

Шаг 7: Настройте бота, получателя сообщения

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

a) Откройте Telegram и бота по этой ссылке @co_notbot. Если у вас еще нет Телеграма, его нужно установить.
b) При входе нажмите кнопку [Start] или введите команду /start. Ждите некоторое время пока бот отработает команду. Появится сообщение с Главным меню бота и две кнопки внизу.
c) Нажмите на кнопку [Подключить]. См. скриншот выше.
d) Откроется следующее окно, в котором появится больше вариантов и кнопок. Нас интересует кнопка [Webhook]. Нажмите на нее и подождите до 1-3 секунд. См. скриншот ниже:

e) В следующем сообщении от бота вы получите вебхук, который нужно будет скопировать и затем добавить в наш Zap на шаге 9a.

ВНИМАНИЕ!!!

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

Шаг 8: Выбираем Action

a) Вернитесь в Zapier и нажмите кнопку [Action].
b) В строке поиска наберите web
c) Из списка выберите Webhook by Zapier. См. скриншот выше

a) далее выберите Action event, нажмите на [Choose an Event]
b) из списка выберите вариант [POST]. См. на скриншоте выше.
c) Нажмите дальше [Continue]

Шаг 9: Добавьте вебхук и параметры

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

a) в поле [URL] введите адрес вебхука, который вы получили на шаге 7e. На скриншоте приведен пример. У вас должна быть точная копия с токеном и адресом.
b) в поле [Payload Type] оставьте вариант [Form]
c) в следующем разделе [Data] нужно будет добавить/задать передаваемые параметры вебхука. Нам нужно будет задать одно поле text и его значение, в котором будет передаваться сообщение.
d) в поле text можно сначала добавить значение [Subject], [Sender], [Body Plain] или [Stripped Text] из письма
e) если тестирование (шаг 10) пройдет успешно, можно попробовать обрабатывать и передавать значения из html (об этом см. шаг 11c). Можно пробовать разные варианты и смотреть, что получится в результате. Если после выполнения Zapier будет выдавать сообщения об ошибках, попробуйте задать статическую строку, например, Hello world! и посмотрите, что получится.
f) остальные поля, ниже раздела [Data], заполнять и изменять не нужно

Шаг 10: Тестирование отправки письма и всего сценария

a) после того как все поля будут заполнены вы можете снова протестировать отправку письма и весь сценарий. Отправьте новое тестовое письмо и нажмите кнопку [Test & Review]
b) если тест пройдет успешно, то вы получите ответ в зеленой зоне и сообщение вроде Test was successful включите Zap/сценарий, нажмите на переключатель [off] [on];
c) обратным действием можно выключить (или на время заблокировать) этот сценарий позже

Шаг 11: Развитие сценария: извлекаем ссылки, добавляем фильтр, укорачиваем текст

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

a) проверка длины текста и самостоятельно решаем обрезать текст или делить его на куски < 4096 символов, чтобы не превысить лимиты Телеграма; можно реализовать по-разному, модулем Formatter by Zapier, например;
b) можно пересылать не каждое сообщение, а пропускать все сообщения через фильтр, который оставит только нужное и уберет спам, например. См. Filter by Zapier;
c) можно сделать более сложную обработку входящих писем и извлекать ссылки и/или картинки из HTML кода письма (Formatter by Zapier). Как вариант, после этого картинки можно пропустить через один из сервисов распознавания изображений для извлечения чисел/текста/номеров/лиц и пр.
d) можно самостоятельно зарегистрировать бота Телеграм и подключить один из бот-конструкторов; и тогда сможем реализовать бота по-своему и не будем зависеть от работоспособности стороннего бота. Правда попадем в новую зависимость от сервиса-конструктора;
e) можно сделать новый чат, куда с помощью аналогичного вебхука вместо письма настроить получение RSS, уведомлений или любого другого потока сообщений;
f) и наконец, можно сделать отдельные шаги взаимозаменяемыми, чтобы не зависеть от отдельного провайдера сервиса no-code. Например, вместо Zapierа можно использовать n8n или Integromat.

Как я обещал, кратко перечислю более-менее простые сценарии no-code. Выберите наиболее интересные на ваш взгляд.

• Кастомный фильтр спама на базе AI/ML

• Временная почта для регистраций (см. пример этого выше)

• Агрегатор и фильтр вакансий/новостей/объявлений/rss

• Сканирование и учет чеков и финансовых операций

• Кастомный uptime-мониторинг для сайтов, серверов

• Уведомления и команды Умного дома

• No-code решения для скилов Алексы или навыков Алисы

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

Весной 2021 проходит шестой запуск проектно-образовательного интенсива От идеи к прототипу Университета 20.35. В нём студенты придумывают идеи для будущих технологических проектов самостоятельно, либо получают их от инновационных бизнес-компаний. С 2020 года в интенсивах существует Банк задач чуть больше чем за год в проект привлечено 30+ компаний, в 25% случаев заказчики предлагали студентам стажировку или работу по итогам интенсива, не менее половины команд решили задачи и показали прототипы на финале проектного трека.

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

Наташ, мы всё уронили

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

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

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

Как мы пришли к Airtable

В предыдущем запуске отраслевые партнёры предложили 13 задач, весной 2021 их стало уже вдвое больше вопрос, где разместить эти 28 кейсов, чтобы всё не превратилось в хаос. С помощью Airtable удалось разработать удобное и опрятное решение для всех пользователей: организаторов интенсивов, проектных наставников и координаторов в вузах, компаний.

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

На витрине расположены карточки со всеми задачами для студентов весеннего запуска интенсивов, каждый пользователь видит:

• краткое описание того, что предстоит сделать,

• тематику задачи (например, агротех, дизайн, VR или чат-боты),

• требования к команде (если компания оставила пожелания),

• подробную расшифровку в pdf-файле

• бронирования от вузов кто уже взял эту задачу

При том, что задач стало больше, благодаря системе тегов можно легко ориентироваться и сортировать подходящие для вуза кейсы. Расшифровки в pdf открываются на той же странице, а значит никто не потеряется по пути обратно к карточке. Новый подход показал: больше не нужно проводить подробные вебинары с инструктажем как пользоваться таблицей. Хотя руководители проектной деятельности и получили объяснение, как работает витрина, многие наставники разобрались с ней самостоятельно. И больше никаких проблем из-за прав доступа или возможной порчи документа. Посмотрев задачи, представитель вуза переходит на страницу бронирования: в заявке можно сразу указать все кейсы, которые хочется взять для студентов и не заполнять форму по несколько раз.

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

А что сейчас?

В марте 2021 года координаторы 29 вузов выбрали 27 задач из 28 предложенных, самыми популярными по количеству запросов оказались задачи edtech, медицинско-ветеринарного профиля и агротех. Традиционно высокий спрос на решения data science и веб-разработку.

Уфимский ГАТУ вдохновился примером Банка и воспользовался готовым шаблоном на Airtable от разработчиков Университета 20.35. Так студенты этого вуза смогли асинхронно выбрать предложенные задачи с помощью витрины и наглядно записаться в интересующие их проекты.

Что даёт участие в Банке задач стартапам и компаниям:

возможность найти талантливых и заинтересованных студентов, протестировать их своей задачей и принять решение о дальнейшем найме этих студентов в качестве сотрудников;

решить не самую приоритетною задачу за счёт внешнего ресурса без лишних затрат;

предложить себя в качестве работодателя в обход конкуренции с большими и популярными корпорациями, чтобы студенты познакомились со спецификой бизнеса и корпоративной культурой стартапов;

прокачать навык менторства и получить новые идеи для решений других задач от студентов

К слову, если вы тоже хотите, чтобы студенты интенсива потрудились над задачей вашей компании, оставьте заявку: http://business.2035.university.