No-code. Как сделать сайт без программирования

Либо-либо. Всем привет! Самат Галимов и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионала, с которым можно поговорить простым человеческим языком. Представьте, вы хотите сделать себе сайт, интернет-магазин или, может быть, даже какую-то программу, которая облегчит вашу работу. Можно, конечно, заказать эту работу профессионалам, программистам, каким-нибудь компаниям. У меня, например, такая есть. Но на рынке есть довольно много предложений, вы, возможно, видели рекламу, мол, запусти сайт самостоятельно или запусти интернет-магазин, не имея навыков программирования. Есть даже сервисы, которые обещают, что можно создать полноценную программу, не будучи программистом. Насколько все эти обещания правдивы? Можно ли запустить сложный продукт, не будучи программистом и не программируя? Во всем этом мы сейчас разберемся вместе с техническим директором одного из подобных сервисов. Это подкаст студии Либо-Либо. Сделали мы его совместно с сервисом онлайн образования Яндекс Практикум. У Практикума есть курсы по разработке, по анализу данных и по английскому языку. Но сегодня я вам хочу рассказать о курсе DevOps для эксплуатации и разработки. Очень многие программисты умеют писать код, но не могут довести его до продакшена, то есть сделать так, чтобы он начал приносить пользу конечным клиентам. DevOps— это навыки делать именно это, то есть настраивать инфраструктуру, привозить туда готовый код и надежно и стабильно его эксплуатировать. Это не только технические навыки, но и некоторые принципы работы внутри команды. В общем, классный курс для разработчиков. Ссылка с подробностями в описании к этому эпизоду.

Привет, меня зовут Антон Васин, я технический директор компании ReadyMag. ReadyMag— это дизайн-инструмент, который позволяет собирать сайты в интернете без кода.

У меня есть бизнес. Я продаю услуги разработки. Мы делаем там сайты, мобильные приложения, сервисы всякие. Инт-проекты у меня обычно работают опытные программисты и стоят это миллионы рублей, не меньше. При этом в интернете есть такое растущее движение— ноу-код и лоу-код. Это когда люди делают сайты и приложения в специальных сервисах, которые не требуют программирования. Честно говоря, в этом что-то не сходится, потому что вот с одной стороны такая разработка серьезная, с другой стороны там типа накликал и все заработало само. Где здесь обман?

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

Отлично. Давай тогда разберемся, какие программы можно сделать в 23-м году без программистов. С простого начнем с самого. Можно ли собрать сайт-визитку?

Конечно. на Readymag, например. Можно собрать на каких-то других. сайт-билдеры (site builders) или как-то еще. Их много. Там, если кто смотрит YouTube и видит рекламу в YouTube, они их знают.

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

Ну, это, наверное, больше похоже, да, там, на какой-то Word. Только если Word— это в первую очередь текстовая, да, какая-то история. Мы работаем там с параграфами, с блоками текста. Ну, картинку можем вставить, да, там, или график какой-нибудь. Сайты всё-таки больше, в первую очередь, визуальная какая-то штука. WYSIWYG. What you see is what you get. Положили что-то на страничку, мышкой это перетащили в нужное место, покрутили, шрифт выбрали, картиночку также загрузили, поставили куда-то. Вот сайт. То есть, такое перетаскивание мышкой можно всё сделать.

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

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

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

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

А мне кажется, на самом деле, вот эти сайт-билдеры, которые упоминал, в какой-то момент, мне кажется, у всех сайт-билдеров появляется возможность построить еще и интернет-магазин тоже. у Wix это точно есть, у Tilda это точно есть. У Readymag, да, интернет-магазин?

Да, у нас есть, Ecwid.

Про Stripe. Напомяну ли, это самая крупная платформа для обработки онлайн-платежей в мире?

Да-да-да, это типа The Platform. То есть все денюжки, которые ходят по интернету, они по большей части ходят через Stripe, так или иначе.

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

Ну да, да, да. Склад, бизнес-аналитика и вот все самые интересные бизнес уже какие-то части интернет-коммерции / e-commerce.

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

Да, это админка, это просто админка. Мы когда запустили свой eShop widget, у нас, по-моему, первый работающий магазин появился в первую неделю. И это просто были какие-то стикеры, абсолютно малюсенькое какое-то производство. Просто наша юзерка взяла, собрала сайт, магазин. Мы потом эти стикеры заказали, они к нам приехали. Было абсолютно потрясающе.

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

Тут мне кажется, когда мы подходим уже к чему-то а не на сайт. Тут все становится более непонятно. Я бы ответил так, какой это можно построить маркетплейс? Тот ли это маркетплейс, который прям нужен заказчику в этот момент со всеми-всеми нюансами? Я не решусь сказать, что вот прям это 100% возможно, потому что больше неизвестных. Много игроков, это какая-то уже такая подвижная, такая живая система, где не просто отношение продавец-покупатель, да, много покупателей, много продавцов и еще владелец этого маркетплейса, как некоторые руководители всего этого процесса вверху стоят. То есть у нас начинают с разговора про алгоритмы, про, может быть, какие-то воплощения, может быть, юзеров на платформе, какие-нибудь, может быть, бонусы или какие-нибудь сделки с продавцами, с мерчантами. Это уже такая вещь, которая напрямую связана с живым бизнесом. Соответственно, как разработчики мы подозреваем, что ее рано или поздно нужно будет модифицировать в зависимости от того, что происходит в реальном мире. И вот это уже такая более сложная какая-то материя.

Менее стандартная.

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

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

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

То есть если бы какую-то черту подводить, то получается все эти сервисы запустить что-нибудь без программирования бьются на два больших лагеря. Один— это сервисы, которые решают одну узкую задачу— сделать сайт-визитку, ну короче статический сайт, либо интернет-магазин, либо что-то еще вот такое уже готовое, понятное, массовое, штампованное. И они не требуют никакого программирования, ими можно как в PowerPoint собрать сайт себе, который будет решать твою задачу. Либо второй класс инструментов— это уже ад технарей для технарей. Просто что-то сделать быстрее, возможно, не так, как обычно. Мы с тобой немножко поговорили про то, как это выглядит для человека, который создает эти сервисы. Ну, интернет-магазины, сайты. А как это выглядит для пользователя? У меня как пользователя вообще есть разница, отдельные программисты сделали этот сайт или сайт сделали с помощью какого-то сервиса. Я это вообще замечу.

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

Сколько сил мы это вложили.

Сколько сил мы вложили, да-да-да. Насколько мы вообще все друг с другом договорились о том, что мы делаем, да, или мы там в разные стороны все побежали и получилось типа на троечку как-то. Ноу-код решения ещё обезопашивают от человеческого фактора, грубо говоря. То есть меньше подвижных частей, мы больше контролируем, что в итоге получится. Даже если получится немножко хуже, чем если бы мы сделали ВК. Но вот это как раз очень зависит от вендора, то есть от сервисов, в котором это собрано. Потому что, ну как я для себя это сформулировал, мы работаем в вебе. что сервис работает настолько хорошо, насколько он хорошо понимает веб в очень таком широком плане. Как быстро у нас загружается сайт? Откуда он загружается? Сколько данных мы передаем с клиента на сервер? Используем ли мы CDN? Правильно ли мы пожали картинки? для правильного вьюпорта, да, то есть типа не нужно отдавать большую картинку для мобилы. Все вот эти вот нюансы, как раз которыми занимается разработчик, да, в традиционном каком-то подходе. Авторы этих сервисов, они должны наперед все это продумать. И это все очень сильно зависит от того, ну, что сервис хочет, грубо говоря, в мир принести, да. Больше подписок, фич, хайп, что-то такое, ему вот это важно, не очень важно, что потом получается. Либо сервис упирается именно в то, что мы будем идеально все доставлять, там, да, у нас будет за 100 миллисекунд все грузиться классно-классно, но может быть мы пожертвуем, да, каким-то хайпом, чем-то еще.

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

Конечно, конечно. У меня вообще есть теория, что внутри любого бизнеса есть, грубо говоря, если его до предела довести, какую-то, да, вот некоторую бизнес-гипотезу, там все заканчивается тем, что пишут на C (си), потому что там всегда есть какая-то твердая инженерная проблема. Да, да, да, внутри всего этого.

Скажи, а код вообще, который отдают такие сервисы, он хороший получается?

Чаще всего да, конечно, потому что как инженер тебе всегда легче написать более оптимальный алгоритм, архитектуру, что угодно, когда у тебя больше данных. Естественно, когда ты сабвилдер, как он, дизайн инструментов, у тебя тысяч-тысяч-тысяч Можешь просто посмотреть, а какой у меня самый большой объем трафика за сайт, сколько запросов мы делаем в среднем со страницы. То есть это та роскошь, которую может себе Netflix, Google, FAANG, вот это вот все, и не могут часто себе позволить обычные компании, у которых один домен, у них только свои клиенты, сколько зашло, столько зашло, мы не можем ничего предугадывать. Тут же мы можем смотреть на цифры, мы можем строить метрики и так далее, и делать просто все, что внутри происходит более оптимально.

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

Operations. Это же все дух Operations.

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

Я бы сказал, что чаще это безопаснее, чем если это делать вручную. Безопасность просто такая штука, ее нельзя галочкой где-то включить. Нельзя сделать npm install безопасность, и у тебя все будет хорошо. Чаще всего наоборот. Если сделал npm install что-то, оно менее безопасным становится.

Слушай, надо пояснить, NPM Install— это когда ты установишь для популярного языка JavaScript.

Да-да-да.

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

Да, и ты не знаешь, кто это написал, когда, был ли он в здравом уме тогда, когда он написал, думал ли автор вообще про твой use case, или ты его как-то прицепил сбоку, а на самом деле не стоило так делать. Большие все компании, они, естественно, сталкиваются с проблемой безопасности рано или поздно. И когда ты кучу персональных данных, когда ты обрабатываешь кучу трафика, сайтов, ну, вот некоторые дикие интернеты с тобой происходят, да? Конечно, во-первых, у тебя больше вызовов, да, просто вот сама индустрия, да, как бы, не знаю, делает тебе вызов такой. Вот, но и больше еще требований. То есть регуляции никто не отменял. Если хочется, ну, мы это все знаем, да, если хочется продавать кому-то более серьезному, нужно показать, что у тебя там все хорошо на кухне. Для этого тебе нужно получать либо аттестацию, либо делать какие-то тестирования внешние, еще что-то. Это заставляет тебя думать про все эти вещи.

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

Да.

Поэтому тебе приходится делать безопасно. Второе. Когда ты начинаешь это продавать условному Google или Gazprom, то тебе Лучше Гуглу. Окей, Гуглу. Когда ты пытаешься продать что-то Гуглу, то у тебя в требованиях для того, чтобы что-то им продать, нужно там, чтобы безопасник поставил галочку, что ты соответствуешь с каким-то требованием безопасности.

Да, и в разных юрисдикциях это разные люди, разные галочки. То есть SOC 2, самый популярный сертификат. В Европе это ISO... забыл код. ISO-аналог, да, касательно персональных данных. GDPR, в Америке пока ничего нет. В Калифорнии есть похожий тоже закон про персональные данные. Про все это нужно помнить, думать, конечно же, всегда.

И эти штуки, на самом деле, получение таких сертификаций, это не панацея, но все равно лучше... Абсолютно.

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

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

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

как показывает последние там 4-5 лет, можно сделать много всего интересного, но все равно меньше, чем с сайтом, куда можно загрузить там свою фотографию, например.

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

У меня есть такая мысль появилась, что на самом деле безопаснее тот сервис, в котором работал хороший безопасник. Все остальное это как бы частности.

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

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

Ну, опять же, положить можно всё при желании. Вот недавно, по-моему, был репорт от Cloudflare и Google, что они какой-то очень хитрый DDoS через HTTP2 отбили, который там побил. То есть, если почитать новости про InfoSec в целом большой, то от года в год мы видим новости, типа, мы отбили самую большую в истории DDoS-атаку, потом следующий год мы отбили ещё больше DDoS-атаку. С предела этого нет. В целом будет, конечно, стабильнее все, потому что, как я сказал, scale, да, если его по-правильному использовать и выносить уроки из своего объема, из своего масштаба какого-то, конечно, можно подготовиться, потому что то, что для таких сервисов нормальная нагрузка, это high load для какого-нибудь отдельного standalone сайта, да, потому что там на кого-нибудь идет в 400 раз больше трафика, и ты просто, ну, ты должен это уметь как-то обрабатывать, иначе твой бизнес не работает. Естественно, есть вещи типа Cloudflare, Amazon, у которых тоже есть инструмент для работы с этим. Если посмотреть в целом, то есть какая-нибудь компания, которая работает в клауде, они не то чтобы сами прям какие-то пишут антибоевой софт, они используют тот или иной инструмент, который уже существует. Поэтому тут в целом такие немножко равные получаются условия. То есть можно взять, поднять сайтик, закрыть его в Cloudflare Proxy, и у тебя все, в принципе, будет хорошо.

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

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

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

Да-да-да, ты обрастаешь панцирем таким, хочешь не хочешь.

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

А он у нас один.

Да. Что происходит? Как чинить эти проблемы, если ты заказал сайт через сервис?

Ну, они, как правило, не падают так. То есть, либо у тебя упал весь сервис, и людей с такой проблемой еще, типа, 40 тысяч. И значит, что, скорее всего, сервис очень быстро работоспособность вернет. Но в целом, я бы сказал, просто не происходит. То есть, опять же, из-за того, что у нас есть вот этот комбайн по хостингу, обработке данных и так далее, большое количество вещей, которые ломаются, они автоматизированы. Соответственно, они меньше ломаются. Если какой-либо процесс происходит часто и автоматически, он стабильнее всегда. Знаешь, да, ошибки возникают часто, когда это давно не трогали, это какая-то ручная штука, какой-то скрипт написали пять лет назад, и вот нам нужно что-то поменять, поменяли не так, он сломался, да? Это такая аналогия как на коньках, когда ты катаешься, чем быстрее ты едешь, тем ты стабильнее, тем ты устойчивее.

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

Да.

А не то, что мы как бы надеемся, что, не дай бог, ветер не подует.

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

Отперфекционисты, знаешь, да?

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

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

Было еще классное слово вебмастер, помнишь? Ну, на самом деле, это часть, мне кажется, value proposition таких сервисов, то, что клиент сам может это все исправлять. Да, то есть не нужно обладать какими-то специальными знаниями, чтобы сделать сайт, и также не нужно обладать специальными знаниями, чтобы его редактировать, потому что это тот же самый какой-то процесс. Мы идем, поменяли контент, картиночку перезалили, что-то другое поставили. Но вот эти вот вещи, которыми занимались веб-мастера или что-то такое, они куда-то уходят за кулисы. Мне кажется, максимум, что такого техничного нужно сделать при работе с такими сервисами, это привязка доменов. И там нужно будет пойти в админку, в крайнем случае в свою админку DNS-хостинга, прописать нужные буквки-циферки, чтобы привязался домен. Вот это, мне кажется, максимум какой-то технички, с которой сталкивается клиент.

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

Да, или дизайнер, которого нанял тот же самый бизнес, да, но идея то, что не нужен админ, не нужен разработчик.

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

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

Ага, это как Амазон, у которого 100 миллисекундная задержка ведет к потере покупок на сотни миллионов долларов.

Да, да, да. То тут, конечно, только инженеры, вот те самые, да, люди, которые сидят, чё-то носи, пишут, чтобы оно быстро работало. То же самое касается, ну это тоже гадикающая такая штука, все, ну, bleeding edge, грубо говоря, да, то есть все, что касается того, что вот происходит прямо сейчас у нас на глазах, да, там какой-нибудь AR, machine learning, все что угодно. Естественно, да, это еще вчера было так, сегодня уже по-другому. Что тебе может сервис предложить?

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

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

Типа, все, что можно написать текстом, можно накликать мышкой.

Ну, якобы. Некоторый worldview такой представляется. Но правда, как мы сейчас выяснили, иная. Не все. Не 100% программ можно сделать ноукодом. Соответственно, встает вопрос, что мы делаем с этими оставшимися процентами программ? И тут не обязательно это должно быть что-то хардкорное. То есть я говорю, программа— это типа мы не Google сейчас пишем, да. Может быть, мы пишем какой-нибудь хитрый календарь для букинга, я не знаю, отеля.

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

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

Кайф. Можешь привести пример? Вот, допустим, я запустил интернет-магазин в Shopify, да? Там просто кликаешь, указываешь название своего магазина, логотип там, всё. Можешь покупать, в какие страны доставляешь, какие нет, и всё, всё заработало. Получился у меня интернет-магазин. В какой момент мне всё-таки придётся прийти к программистам и попросить их что-то запрограммировать?

Если ты пользуешься Shopify в этой ситуации, то, скорее всего, сам Shopify тебя будет устраивать до победного. То есть сам твой движок e-commerce, через который у тебя товары и деньги летят, с ним, скорее всего, будет хорошо, потому что это основной бизнес Shopify. Ты вряд ли сделаешь что-то лучше Shopify. Проблема возникнут, скорее всего, в том, что вокруг. То есть, может быть, ты хочешь историю заказов, может быть, ты хочешь какие-нибудь приколы с купонами, может быть, ты хочешь еще что-то сделать. То есть, наверное, всё, что связано с реальным миром и не связано вот с движком Shopify. Да, потому что движком Shopify всё будет, скорее всего, хорошо.

А, и это как раз классный пример, когда мне не придётся заново всё писать, я могу рядом что-то написать для того, чтобы обернуть Shopify в такую обернуть.

Конечно, конечно, потому что это такой атомный реактор по созданию магазинов.

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

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

Ты просто украл мое сердечко, потому что вот эта идея про проверим бизнес-гипотезу, она мне безумно нравится. Когда ко мне приходят клиенты, я там 90% отбреваю вот на этом этапе. Ну, окей, я не отбреваю, но пытаюсь как-то объяснить, что вы, конечно, можете сейчас вложить миллионы рублей, и я с удовольствием возьму ваши деньги, но мы же не понимаем, типа, получится у вас этот бизнес или не получится. Типа, инструмент это только 10%. 90% это, типа, есть ли у вас клиенты, есть ли у них такая потребность? Будет ли этот инструмент реально помогать?

Это в целом, мне кажется, очень... ну вот это лично моя какая-то инженерная философия, что мы в целом, только написав код, даже не написав, а задеплоив его, и

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

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

несет ли оно ценность. И вот, насколько я понимаю, все эти сервисы помогают сократить этот промежуток между «мы придумали идею» и «мы проверили ее на живых людях, на реальных клиентах».

фидбэк-луп (feedback loop). И это очень полезно, особенно когда бизнес только начинает, только развивается, ему нужно вот есть-есть-есть смотреть, что происходит. Иметь короткий цикл критично. Да, потому что никому не хочется там... Мы еще ничего толком не запустили, не сделали, а у нас уже там... Девкоманда, у нас есть, значит, бэклоги, спринты, что-то

там происходит, какая-то... План на два года вперед.

План на два года вперед, а ничего не запустили.

Мне очень нравится, меня один раз много лет назад хорошо остудили, я спросил, это что, штука для бедных? И мне объяснили, нет, чувак, это штука для богатых, которые просто умеют считать свои деньги и экономить, и вообще защищаться. Это вообще было про другую штуку, но вот конкретно эти инструменты, это не решение для бедных, у которых нет денег на программистов. Это для тех, кто просто умеет понимать, когда нужен этот инструмент, когда нет. Все, что мы сейчас обсуждали, это веб-сайты, на самом деле. Веб-веб-веб. А что насчет мобильных приложений? Потому что, мне кажется, мобильные приложения, может, даже важнее уже, чем сайты. Если мы говорим про какие-то no-code, что-то

такое, скорее всего это будет происходить в вебе. Скорее всего это будет какой-то редактор у тебя в браузере, мобильное приложение. Технически подкованные люди знают, что тут уже закрался нюанс некоторый. Как мы что-то из браузера превратим во что-то, что на айфоне. Мы, скорее всего, будем использовать какую-то очень хитрую технологию. универсального как бы программирования под разные платформы, кроссплатформенные программирования. Да, либо какой-нибудь Kanba мы будем использовать, либо ReactNet, либо что-то такое. Это уже сам заход на эту территорию несет определенные сложности. Писать кроссплатформенно сложно даже когда ты программист и знаешь, что ты делаешь.

Причем хороший программист.

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

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

Да-да-да, это такая безумная газета ожившая. И мы до сих пор в этой парадигме все строим. Внутри всего, там, не знаю, Notion'а или Facebook'а или чего угодно— это документ. Некоторая бумажка с заголовком, с абзацами, с чем-то таким. Большое такое, да, вот программирование, когда мы уже пишем под какую-то архитектуру, под какой-то процессор, под какую-то операционную систему, оно, во-первых, требует гораздо более глубокого понимания, что происходит, да, мы уже не с CSS-ом общаемся, да, а с каким-нибудь там с GIF-ом, с C или с Java, с Kotlin-ом, с чем-то таким, мы думаем про память, мы думаем про такие вот сложные вещи. Я к тому, что это сложнее скрыть, да, то есть если мы хотим построить некоторую шапку сверху, которая всю эту сложность сильнее постараться сделать этот инструмент более качественным. Там нужно больше ресурсов потратить, чтобы он вообще начал что-то полезное делать. Второе, то что мы всегда будем ограничены тем, что этот сервис сошел в себя. Это не будет такая же свобода, как мы посадили дизайнера-разработчика и сказали, сделай нам приложение, которое попадет в предложку AppStore.

Объем скрытого становится вообще каким-то гигантским. Это айсберг, у которого, не знаю, 5% сверху, а 95% снизу.

Да.

Мне кажется, еще один пункт это то, что приложение, когда ты сделаешь сайт, то ты его вот сделал на сервере, и он мгновенно доступен всем. А приложение еще нужно загрузить в App Store и пройти модерацию в Apple или в Google. И они еще могут его не пропустить.

Да. И каждый фикс должен проходить, если ты не сделал что-то хитрое для того, чтобы over the air накидывать с апдейта, да?

И вот это хитрое, оно в серой зоне на самом деле. Фиг знает. Ну иногда он хорошо относится, иногда плохо.

Ну да, да, да.

А когда тебе нужно вот этот релизный цикл, ну в смысле нужно как-то прокатывать через App Store, то это... Хочешь, не хочешь, ты становишься инженером. Тебе нужно как бы планировать, думать. Это не просто зашел, как бы нажал на кнопку и забыл.

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

Самое-то ужасное. У тебя в какой-то момент может оказаться несколько версий одного и того же приложения. Типа часть людей обновилась, часть людей нет.

Да, еще есть разные регионы в App Store, где какие-то приложения могут быть доступны,

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

Да-да-да. И как бы в теории сервис такой, он может все это съесть за тебя, да, то есть можно представить, что да, мы за тебя берем там ревью-процесс, что-то еще, но там опять же, да, по полису, к тому же, ты всегда, как автор, загружаешь тут в App Store, не какая-то third-party, да, то есть ты несешь всегда ответственность за это.

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

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

Да, то есть... Которых сделать нельзя?

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

А есть какие-то неуловимые джо, которых нет, но которые нафиг никому не нужны? Да, да, да.

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

«О, хочу свой блокчейн». Да. Классный пример, я об этом не знал и интересно такое слышать. Есть ли еще что-то такое, что ты в последнее время видел, что типа «Ого, ничего себе, чему еще научились».

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

Сейчас-сейчас, погоди. Ты хочешь сказать, что внутри этих сервисов появились помощники, такие AI помощники, в котором ты просто говоришь, сделал мне интернет-магазин, и он тебе дальше все накликивает сам? Да, да. Офигеть! А это в каких сервисах есть? Где вот сейчас можно такое использовать?

Вебфлоу точно, по-моему, имеет это.

Такой известный тоже сайт-билдер.

Да-да-да. Вот, ну то есть, наверное, я это к тому, что вот с чат-ботами самое интересное, да, то есть все, что можно представить в парадигме «я хотел x, и json выглядит y», да, вот между вот этими двумя штуками можно поставить чат-бота, и он будет автоматически генерировать проекты, данные, сайты, приложения.

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

Да-да-да, как сказал переводчик.

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

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

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

Нет, не думаю. Я думаю, что большая, может быть, часть инженеров будет так делать. Но я верю, что всегда есть вот этот вот некоторый край, да, который развивается постоянно. Некоторый вот текущий предел, где нужны живые люди, где ты и сидишь и пишешь руками код. Без генерации, без всего. Занимаешься тем же, чем ты занимался 40 лет назад, грубо говоря. Это всегда в том или ином объеме будет.

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

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

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

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

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

Мне тоже очень понравилось. Спасибо, что позвал.

Это подкаст Студии Либо-Либо, и сделали мы его совместно с сервисом Яндекс Практикум. Над подкастом работали редакторки Маша Агличева и Рита Берденникова, продюсеры Настя Медведева и Данил Остапов, звукорежиссер Юрий Шустицкий. За джингл спасибо Алексею Зеленскому. Редактор субтитров А.Синецкая Корректор А.Егорова