Угу, сейчас упрощенные DSL имеют некоторое преимущество в том, что проще объяснить GPT как писать правильно. Он же правда и недостаток, тк приходится передавать свою документацию в контекст. Но непонятно сколько такая ситуация продержится.
Мои соображения (на правах разрабатывающего подобного типа платформу):
— Идея оставить одного аналитика работает. — Чисто визуальная штука с конструированием всего мышкой очень ограничена по возможностям тк мышкой не сделать сложную логику — поэтому нужен код! — Если сказать аналитику «а теперь выучи JS, что бы пользоваться платформой» то это уже будет не аналитик, а программист. — Мы сделали свой упрощенный код для неразработчиков и он работает, но это дорого для нас, как для разработчиков платформы, и это маркетинговая бомба, пока у вас нет миллиона пользователей. — Учиться и повышать свой скилл в инструменте аналитику неизбежно придется. — Иногда, что бы получить хорошую архитектуру, ему нужна помощь архитектора (в нашем случае это либо более опытный спец, либо консультация у нас, как у разработчиков платформы). — Если нет критических ошибок в архитектуре — решение нормально масштабируется. Для внутренних корпоративных задач достаточного простого вертикального масштабирования, да и горизонтальное можно, но до этого еще никто не доходил. — Что бы использовали крупные корпорации — этим надо специально заниматься. К нам несколько раз обращались (типа хотим использовать), но через их внутреннюю бюрократию не пролазит — теперь мы им прям сразу на входе говорим «забудьте».
Мы тоже метались между докером и нативной установкой sh-скриптом и пришли к выводу, что при отсутствии ресурсов полноценно поддерживать несколько вариантов установки, надо сосредоточится на том варианте, который проще и понятнее для майнтейнеров или про который проще всего объяснить пользователям как обновить.
В нашем случае — это оказалась нативная установка sh-скриптом (еще раз повторю, что в других проектах, в том числе здесь может быть по другому). Но докер мы сделали и с него кто-то даже что-то поставил и теперь мне приходится и его тоже поддерживать как второй способ (о чем жалею).
Те по хорошему хорошо бы еще иметь и собственный сайт с осмысленным содержимым на том же ip, что и cloak, что бы он его и отдавал?
Также я из текста понял, что там подменяется сертификат и это потенциальная сигнатура для отслеживания и блокировки. Но если у нас есть сайт на который типа идет пользователь, то у нас есть и оригинал сертификата...
Но вообще вы молодцы! Уже прилично звезд нафармили на GH. Я знаю им цену :)
На правах решавшего задачу установки сложносоставного софта на сервак людьми без спецподготовки:
1. Конечно же это делается на чистом сервере. И не только из-за секретности а банально из-за того, что установщики не рассчитывают на какой-то там еще софт.
2. Приходится в какой-то степени доверять разработчику, причем неважно подключается там что-то по ssh или вы deb/sh скачали и запустили.
3. В случае максимальной секретности и защищенности люди качают источник, читают что там написано и убедившись, что все ок — делают make, потом поднимают apparmor, изолируют сервер от остальной сети итп.
Мы используем jsonb для упрощенной типизации внутри приложения а также читаем конкретно постгресовские коды ошибок дедлока и конкретно для постгреса передаем параметр жизни транзакции, что бы пользователь, который ничего не знает про БД не столкнулся с блокировкой таблицы вдруг. Поэтому как основную Бд мы не будем поддерживать MySQL. Про хостинги — как минимум копеечный VPS. Если совсем за 100 р/мес то вот https://ru.docs.totum.online/install_on_net_angels но реально притормаживает в прайм-тайм тк это жесточайший шаред.
Спасибо, что написали — у меня была возможность еще немного поразмышлять в этом направлении. Если говорить про язык, то вы все верно пишете (не просто так же языки эволюционировали).
Дело в том, что у нас не язык — к нему надо относится как к «конфигу на стероидах».
Еще важен скилл того, кто с ним работает. Когда человек больше трех лет смотрит в километры кода — он хочет, что бы там отсутствовали лишне элементы — он по виду функции знает, что третий параметр это..., последний это result, сразу хочется вложить преобразование в передачу параметра внутри функции и тп.
И я про это как-раз хотел сказать в статье — если подходит имеющийся синтаксис, то надо брать его. А если цель другая, то надо с этим бороться. Те нет задачи разработать синтаксис, ради того, что бы его разработать — это дичь.
А я же сознательно делал «инстаграм синтаксис», так-как мой пользователь — это человек, который про программирование не знает. А вот # как тег и @ как указание пользователя ему знакомы. Вот какой паттерн мы активировали.
Также он воспринимает = как знак сравнения и страдает от концепции присваивания (поэтому присваивание отправили в топку, оно есть, но почти никогда не используется). while тоже есть, но люди его использую не так как вы привыкли — а для выполнения нескольких последовательных действий :) Про рекурсию я целый абзац написал — она есть, но когда я про нее пытаюсь пользователю рассказать у него на лице написано, что он хочет поскорей пойти набухаться и забыть про это.
Это была еще одна мысль про которую сразу непонятно — иногда упростить с ограничением возможностей, если вы большой профи, очень сложно.
Например мы через 4 года только поняли, что нашим пользователям в 99% случаев while как while нужен только для того, что бы последовательно перебрать имеющийся список. Тогда мы сделали для этого функцию, которая всегда пережевывает весь список от начала до конца без возможности выхода, итератора и всего прочего, чего есть в нормальном while. И это было настоящим открытием — сложность проектов у людей сразу выросла.
Код и есть конструктор того, что хочешь получить на выходе.
Но идея эта распространена и вроде как есть куча конструкторов. Я BPMS например к конструкторам отношу. А мы специально хотели, чтоб был код. Должен же быть в мире выбор :)
Мы столкнулись с тем, что придется дофига всего позапрещать. И большая часть документации состояла бы из «это не трож», «сюда не ходи» и тп. Те надо было бы научить питону, а потом ограничениям над питоном — по мне, так это безнадега. А сейчас, если программисту надо разобраться (реально надо) то день потыкал и уже почти бог.
Да и у пайтона совсем другая логика — у нас очень много декларативщины, нам если брать, то надо было бы брать хаскель-подобные.
Лучший результат у нас — это если человек когда-то в далеком прошлом лабораторку на фортране делал :) В смысле давно, немного и криво программировал что-то и бросил. Такие пользователи прям в восторге.
Сейчас самая большая проблема для нас — это не объяснять синтаксис (с этим все совсем просто), а с объяснением хорошей архитектуры решения. В 60% случаев начинают делать так, как у них было в табличке эксель и соответсвенно тянут оттуда все архитектурные ограничения. Вот это быстро пофиксить не получается — делаем консультации, записываем видосы. Если пользователь не программировал никогда и ничего и разбирается со всем сам, то сейчас он со своего второго проекта начинает понимать как таблички должны быть организованы, а я хочу чтоб с первого.
Но если проект простой — до 5 табличек, то там любая архитектура прокатывает. А потом (после этих 5 первых) таблички людям мозг захватывают и их система начинает расти 5 -> 30 -> 100 -> 150 (это реально уже проект-монстр который даж меня пугает).
Сначала сделали это, а потом отказались, так-как было много ошибок. Пользователь копировал вызов поля вместе с диезом и вставлял поставив в начале дополнительный диез. Получалась логическая ошибка не отображаемая в подсветке — поэтому решили, что такой случай надо определять через отдельную строку:
Ну хотелось такой аксесс, ток серверный и без SQL визардов. А так я знаю несколько проектов переехавших из аксесса — люди там счастливы не передать как.
Что вы имеете в виду под открытым форматом файлов?
Угу, я ее исправлял, но похоже не до конца. Спс
Угу, сейчас упрощенные DSL имеют некоторое преимущество в том, что проще объяснить GPT как писать правильно. Он же правда и недостаток, тк приходится передавать свою документацию в контекст. Но непонятно сколько такая ситуация продержится.
Выложили ml-часть: https://github.com/twitter/the-algorithm-ml
Спасибо! Очень ценно
Мои соображения (на правах разрабатывающего подобного типа платформу):
— Идея оставить одного аналитика работает.
— Чисто визуальная штука с конструированием всего мышкой очень ограничена по возможностям тк мышкой не сделать сложную логику — поэтому нужен код!
— Если сказать аналитику «а теперь выучи JS, что бы пользоваться платформой» то это уже будет не аналитик, а программист.
— Мы сделали свой упрощенный код для неразработчиков и он работает, но это дорого для нас, как для разработчиков платформы, и это маркетинговая бомба, пока у вас нет миллиона пользователей.
— Учиться и повышать свой скилл в инструменте аналитику неизбежно придется.
— Иногда, что бы получить хорошую архитектуру, ему нужна помощь архитектора (в нашем случае это либо более опытный спец, либо консультация у нас, как у разработчиков платформы).
— Если нет критических ошибок в архитектуре — решение нормально масштабируется. Для внутренних корпоративных задач достаточного простого вертикального масштабирования, да и горизонтальное можно, но до этого еще никто не доходил.
— Что бы использовали крупные корпорации — этим надо специально заниматься. К нам несколько раз обращались (типа хотим использовать), но через их внутреннюю бюрократию не пролазит — теперь мы им прям сразу на входе говорим «забудьте».
Мы тоже метались между докером и нативной установкой sh-скриптом и пришли к выводу, что при отсутствии ресурсов полноценно поддерживать несколько вариантов установки, надо сосредоточится на том варианте, который проще и понятнее для майнтейнеров или про который проще всего объяснить пользователям как обновить.
В нашем случае — это оказалась нативная установка sh-скриптом (еще раз повторю, что в других проектах, в том числе здесь может быть по другому). Но докер мы сделали и с него кто-то даже что-то поставил и теперь мне приходится и его тоже поддерживать как второй способ (о чем жалею).
Те по хорошему хорошо бы еще иметь и собственный сайт с осмысленным содержимым на том же ip, что и cloak, что бы он его и отдавал?
Также я из текста понял, что там подменяется сертификат и это потенциальная сигнатура для отслеживания и блокировки. Но если у нас есть сайт на который типа идет пользователь, то у нас есть и оригинал сертификата...
Но вообще вы молодцы! Уже прилично звезд нафармили на GH. Я знаю им цену :)
На правах решавшего задачу установки сложносоставного софта на сервак людьми без спецподготовки:
1. Конечно же это делается на чистом сервере. И не только из-за секретности а банально из-за того, что установщики не рассчитывают на какой-то там еще софт.
2. Приходится в какой-то степени доверять разработчику, причем неважно подключается там что-то по ssh или вы deb/sh скачали и запустили.
3. В случае максимальной секретности и защищенности люди качают источник, читают что там написано и убедившись, что все ок — делают make, потом поднимают apparmor, изолируют сервер от остальной сети итп.
Мы используем jsonb для упрощенной типизации внутри приложения а также читаем конкретно постгресовские коды ошибок дедлока и конкретно для постгреса передаем параметр жизни транзакции, что бы пользователь, который ничего не знает про БД не столкнулся с блокировкой таблицы вдруг. Поэтому как основную Бд мы не будем поддерживать MySQL. Про хостинги — как минимум копеечный VPS. Если совсем за 100 р/мес то вот https://ru.docs.totum.online/install_on_net_angels но реально притормаживает в прайм-тайм тк это жесточайший шаред.
Все, как вы описали, но для локальной машины мы не стали делать по причине отсутствия запроса и денег на разработку этой ветки
Спасибо, что написали — у меня была возможность еще немного поразмышлять в этом направлении. Если говорить про язык, то вы все верно пишете (не просто так же языки эволюционировали).
Дело в том, что у нас не язык — к нему надо относится как к «конфигу на стероидах».
Еще важен скилл того, кто с ним работает. Когда человек больше трех лет смотрит в километры кода — он хочет, что бы там отсутствовали лишне элементы — он по виду функции знает, что третий параметр это..., последний это result, сразу хочется вложить преобразование в передачу параметра внутри функции и тп.
И я про это как-раз хотел сказать в статье — если подходит имеющийся синтаксис, то надо брать его. А если цель другая, то надо с этим бороться. Те нет задачи разработать синтаксис, ради того, что бы его разработать — это дичь.
А я же сознательно делал «инстаграм синтаксис», так-как мой пользователь — это человек, который про программирование не знает. А вот # как тег и @ как указание пользователя ему знакомы. Вот какой паттерн мы активировали.
Также он воспринимает = как знак сравнения и страдает от концепции присваивания (поэтому присваивание отправили в топку, оно есть, но почти никогда не используется). while тоже есть, но люди его использую не так как вы привыкли — а для выполнения нескольких последовательных действий :) Про рекурсию я целый абзац написал — она есть, но когда я про нее пытаюсь пользователю рассказать у него на лице написано, что он хочет поскорей пойти набухаться и забыть про это.
Это была еще одна мысль про которую сразу непонятно — иногда упростить с ограничением возможностей, если вы большой профи, очень сложно.
Например мы через 4 года только поняли, что нашим пользователям в 99% случаев while как while нужен только для того, что бы последовательно перебрать имеющийся список. Тогда мы сделали для этого функцию, которая всегда пережевывает весь список от начала до конца без возможности выхода, итератора и всего прочего, чего есть в нормальном while. И это было настоящим открытием — сложность проектов у людей сразу выросла.
Я думаю вы описали рабочий вариант и если у кого-то логика похожа на питон — это прям зэ-бест подход будет.
Код и есть конструктор того, что хочешь получить на выходе.
Но идея эта распространена и вроде как есть куча конструкторов. Я BPMS например к конструкторам отношу. А мы специально хотели, чтоб был код. Должен же быть в мире выбор :)
Мы столкнулись с тем, что придется дофига всего позапрещать. И большая часть документации состояла бы из «это не трож», «сюда не ходи» и тп. Те надо было бы научить питону, а потом ограничениям над питоном — по мне, так это безнадега. А сейчас, если программисту надо разобраться (реально надо) то день потыкал и уже почти бог.
Да и у пайтона совсем другая логика — у нас очень много декларативщины, нам если брать, то надо было бы брать хаскель-подобные.
Вот мы такую штуку в MIT-лицензии делаем: https://habr.com/ru/post/666184/
Лучший результат у нас — это если человек когда-то в далеком прошлом лабораторку на фортране делал :) В смысле давно, немного и криво программировал что-то и бросил. Такие пользователи прям в восторге.
Сейчас самая большая проблема для нас — это не объяснять синтаксис (с этим все совсем просто), а с объяснением хорошей архитектуры решения. В 60% случаев начинают делать так, как у них было в табличке эксель и соответсвенно тянут оттуда все архитектурные ограничения. Вот это быстро пофиксить не получается — делаем консультации, записываем видосы. Если пользователь не программировал никогда и ничего и разбирается со всем сам, то сейчас он со своего второго проекта начинает понимать как таблички должны быть организованы, а я хочу чтоб с первого.
Но если проект простой — до 5 табличек, то там любая архитектура прокатывает. А потом (после этих 5 первых) таблички людям мозг захватывают и их система начинает расти 5 -> 30 -> 100 -> 150 (это реально уже проект-монстр который даж меня пугает).
Сначала сделали это, а потом отказались, так-как было много ошибок. Пользователь копировал вызов поля вместе с диезом и вставлял поставив в начале дополнительный диез. Получалась логическая ошибка не отображаемая в подсветке — поэтому решили, что такой случай надо определять через отдельную строку:
Ну хотелось такой аксесс, ток серверный и без SQL визардов. А так я знаю несколько проектов переехавших из аксесса — люди там счастливы не передать как.
Во, мне нравится как Haskell думает :)