Программисты не нужны? No-Code разработка.
Большой ажиотаж по no-code/low-code инструментам, кажется прошел. В то же время, они все более глубоко входят в нашу жизнь: огромное количество сайтов, приложений и систем автоматизации сделаны на таких платформах. Решения без кода меняют продуктовый подход.

В некоторых сферах, давно привыкли к low-code. А в других его все еще стараются обходить стороной. Все это безумно интересно изучить. Чем мы и займемся в первом выпуске 5го сезона 🤩 Поговорим и про бурный рост и про риски и про то, нужны ли программисты, когда есть No-code.

А ещё этот эпизод, как и весь сезон, выпускается при поддержке драйвовой команды инженеров — @avitotech. Ребята создают сервисы, которыми пользуется треть жителей России каждый месяц.

🎧 Слушайте подкаст «Кода кода» в Яндекс музыке, Apple podcasts, VK и много ещё где по ссылке https://kodakoda.mave.digital/

Гости выпуска
Вастрик
Программист, техноблогер
Использовал NoCode до того, как это стало мейнстримом и после тоже

Игорь Озеров
Основатель и директор Swiftle
Fastest no-code development

Специальный гость
Олег Харатов
руководитель разработки юнита
в Аналитической платформе @avitotech

Ведущие
Виктор Корейша
@koreysha

Евгений Антонов
@eantonov
Канал Тимлид Очевидность

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

Это нормальный процесс, наглядно продемонстрированный кривой зрелости технологии.

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

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

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

Какие критерии, показатели? Учитывая, что не все готовы делиться всеми данными, а по некоторым проектам может быть подписано NDA.

Подсчет токенов для GPT по API

Кто уже интегрировал GPT в своих проектах знает, что размер контекста (памяти) у него ограниченный.

Например, GPT 3.5 (который ChatGPT) в своей памяти вмещает 4096 токенов. GPT 4 умеет работать уже с 8192 токенами и даже отдельная модель есть, вмещающая 32768 токенов.

Токены - это то, как GPT разбивает текст на кусочки, с которыми далее работает. Например, слово “hamburger” разбивается на токены “ham”, “bur” and “ger”. А слово “pear” это один токен.

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

Так вот, подсчитать количество токенов можно только на Python, то есть в коде. У мы тут адепты ноукода, и нам это не подходит. Нужно API.

Вот вчера некто “Bilal Tahir” запилил такое API, и оно на текущий момент даже бесплатное:
https://gptcalculator.xyz/docs

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

https://producthunt.com/posts/gpt-calculator - вот тут поддержать можно лайком, если у вас есть аккаунт.

К слову, однажды я попрошу вас поддержать запуск Creatium на Product Hunt. Если вы готовы поддержать нас в будущем, то в зависимости от вашей готовности, вы можете:

1. Держать за нас кулачки (ничего не делать)

2. Просто зарегистрировать на сайте сейчас, чтобы потом проголосовать (чтобы не было так, что все вдруг в день запуска продукта зарегистрировались)

3. Зарегистрироваться и даже проявлять некоторую активность на сайте - голосовать за проекты, комментировать.

Формулы Creatium - что это такое, и почему оно такое (часть 1)

Я разрабатываю конструкторы уже 10 лет. В начале это была “Платформа LP”, сейчас Creatium. Казалось бы, за столько времени можно было решить все хотелки клиентов, но это так не работает.

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

Допустим, мы сделали сайт с блогом, где любой может зарегистрироваться и писать посты. А потом, если необходимо, то и редактировать. Выглядит просто, логику можно описать так: “Пользователь может редактировать пост, если он автор поста”.

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

А потом вы решаете, что нечего редактировать свои старые посты, и хотите закрыть редактирование спустя сутки. А модератор при этом может когда захочет. “Пользователь может редактировать пост, если он модератор или (он автор поста и пост опубликован меньше 24 часов назад)”.

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

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

Формулы Creatium - что это такое, и почему оно такое (часть 2)

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

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

Javanoscript полон сюрпризов. Смотрите сами:
Проверка, является ли переменная числом: typeof x == "number"
Является ли переменная строкой: typeof x == "string"
Является ли переменная массивом: x instanceof Array
Является ли переменная объектом: typeof x == "object" && x !== null 😅
При этом массив - это тоже объект. И дата это тоже объект. И это далеко не все.

Еще один объект не равен другому такому же. Чтобы сравнить 2 объекта нужно трансформировать их в JSON-строки, после чего сравнивать, или использовать дополнительные библиотеки вроде Lodash. И еще Moment для адекватной работы с датами. И в итоге вам нужно знать поверхностно и Javanoscript, и Lodash, и еще Moment в придачу.

В то же время в формулах:
Проверка, является ли переменная числом: type(x) == "number"
Является ли переменная строкой: type(x) == "string"
Является ли переменная массивом: type(x) == "array"
Является ли переменная объектом: type(x) == "object"
При этом массив - это только массив, а не еще и объект. То же и с датой.

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

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

Формулы Creatium - что это такое, и почему оно такое (часть 3)

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

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

Даже при выводе табличных данных на странице (товары, вакансии и тд) можно будет указать “фильтр по формуле”.

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

Вот буквально сейчас в чате бета-версии Creatium пишут, что поиск по товарам не работает, потому что ищут "3600 мм”, а в таблице там везде неразрывные пробелы стоят.

(да, неразрывный пробел и просто пробел это разные знаки)

Без формул единственным решением является отказ от неразрывных пробелов. С формулами можно будет сделать “фильтр по формуле”, которая выглядит примерно так: contains(replaceAll(' ', ' '), search), и это полностью решит проблему.

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

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

Вот пример кода, который выводит текст “Hello, World!":

org  0x100 
mov  dx, msg
mov  ah, 9
int  0x21
mov  ah, 0x4c
int  0x21
msg  db 'Hello, World!', 0x0d, 0x0a, '$'

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

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

Нашел тут свою старую, очень старую рассылку - которую писал еще 2007 году.

https://subscribe.ru/archive/inet.webbuild.prostosite/200703/16154715.html

Мне было 12 лет, я делал первые шаги в “сайтостроении”, и спешил поделиться успехами со всем миром. И хотел научить всех делать свои сайты. Я был молод и наивен.

Однако в тексте есть нечто примечательное, цитата:

“На самом деле сдесь НЕТ ничего сложного, все что понадобится, так это водить, клацать мышкой и печатать текст.
И ни каких работ с кодом!С кодом мы будем работать ОЧЕНЬ РЕДКО!!!”

Похоже, мое призвание в No-code было найдено еще 16 лет назад.

Писал пост про ценности No-code, и обнаружил интересный парадокс.

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

Увидели? Заказчик платит меньше, а исполнители получают больше. Как такое возможно?

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

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

Над этим мы и работаем.

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

Мы учимся на чужих ошибках

Конструктор Bubble недавно изменил принцип образования цен. Это уже вторая их попытка (первая была год назад). Обе попытки сообщество восприняло очень негативно, потому что это не просто подорожание, а именно изменение принципа, при котором некоторые проекты могут начать стоить в разы дороже.

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

Мы выбирали между двумя принципами образования цен:

Первый, когда мы считаем выполнение каждой операции, количество строк в базе данных поштучно, как это сделано в Make (ранее Integromat) и как это работает у нас на сайтах сейчас.

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

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

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

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

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