Чат - это привычная форма диалога. Эталон. Все привыкли к такой форме. Я делаю достаточно универсальную штуку, которая не может не включать чат. Вообще базово отталкивался от форумов. И если выкинуть "лишний обвес", то на выходе будет тот же чат. Другими словами люди отвыкли писать абзацами, а разбивают на отдельные короткие предложения. ОРИ - это речь про количество читателей. А если в "форуме" всего два человека - то это частный разговор. Если сотня - чат поселка. Заявка - несколько заинтересованных участников. Но я надеюсь дорасти до масштабов ОРИ - у меня запланировано, чтобы пользователь настраивал каналы новостей со многих сообществ. Поэтому это не проблема, а цель ;) И главная мечта - географическая интеграция сообществ. Объединять поселки с общим забором и дорогой. Объединять МКД в микрорайоны.
Спасибо за интересную статью. И важный опыт. Согласен, что рынок тяжелый. И приятно видеть, что кто-то рядом меняет его, засучив рукава и без нытья. Я делаю похожую систему https://pro.deloset.ru - и тоже сложности с пилотным запуском. С обывателями уже наговорился вдоволь, далее думаю сосредоточиться на председателях. Но они еще и возрастные часто, и не хотят усложнять свою жизнь. Но с другой стороны - не толкаешься жопами с конкурентами. Мой стек: сервер на Go, тонкий клиент PWA-React. Я сразу начал со сложных задач, и жахнул на них несколько лет: у меня возможно связывать сообщества между собой (соседние поселки), форумы для хранения документов и ролевая система доступа для каждого поселка, голосование тремя методами и упрощенный бухучет с двойной записью для местечковых проектов. Самое сложное - механизм связи сообществ, где бизнесовые партнерятся с потребительскими. Я хочу, чтобы не только новости частников, но и бизнесы присутствовали - в этом и есть бизнес-модель. И система профилей - по интересам и бизнесам, включая "по доверенности". Потому долго делаю. И не вайбкодил, ии в чате юзаю. И только сейчас шлифую чаты. Потому что все собеседники пытаются сравнить с понятным - телеграм, и навороты на старте напрягают. И да, кодить и продавать - разные задачи. И интроверту тяжело в продажах.
Обязательные по закону вопросы - это 6 категорий и 55 тем. В основном про внешние большие деньги. И местечковое голосование может быть легитимным, если собственники отдельным вопросом решат, что оно легитимное. А еще гос-ОСС "тяжелое и дорогое" - можно рассматривать местечковые системы как промежуточное для выработки альтернатив и предварительной оценки успеха.
Я у себя такое выше написал - вопрос ко мне? Щас по-свежему распишу. Push - это про service worker. Нахлобучка между сайтом и браузером мимо обычной бизнес-логики. SW подписывается на определенный endpoint на ресурсе конкретного браузера. В логике сайта нужно поднять разрешение/подписку, и отправить на сервер. Сервер запоминает подписку. И по нужде пишет зашифрованное сообщение на тот самый endpoint, который слушается клиентом. Важно, SW работает даже если сайт закрыт. И на этом устроено PWA. И обновляет, и поднимает push'и в системном трее. В dev-режиме нужно настраивать vite, чтобы sw правильно поднимал. Еще у меня есть SSE - server side events. Это для открытого чата. Тут клиент подписывается на stream-канал, который держится открытым, восстанавливается если упадет. И сервер просто отправляет сообщения в открытый канал. Важно, что http/2 это не умеет (в go так). Нужно снижать версию http-соединения. И подстраивать канал под flush сообщений. То есть отличается от обычного http-запроса. И nginx перед сервером может требовать хитрой настройки. Email у меня свой. Нативный Postfix на VDS и доменном имени. Тут сложности больше в "белой почте" ака трех защитах - даже у профессионалов приходят письма с ошибками. Сервер просто отсылает письма на свой smtp-сервер через стандартную библиотеку.
Тоже такое делаю. Уже несколько лет ;) Мне больше не хватало системного аналитика, который бы сразу сказал "как правильно" и еще убедил бы в этом - переделывал много раз. И еще буду переделывать - уверен. У меня PWA/SPA на реакте. Управляю состоянием компонентов на useSWR. И куча контекстов. И три уровня токенов авторизации ;) И go на сервере. В go я хожу отдыхать... ;) Про состояния сервера в принципе давно узнал, потому делаю сразу stateless и две базы - master для записи и реплики. И ci освоил - рекомендую, недельку-другую поматериться, а потом хорошо. Тема - CivilTech: объединение жильцов и собов в целях управления общим имуществом (но можно всех объединять - спортсообщества, профсоюзы и школьные комитеты). Сейчас освоил push'и, чтобы было похоже на телеграм, но в базе древовидные форумы для хранения документов. Описание: https://pro.deloset.ru - тут немножно стрёмно описано - щас чаты допилю, и стану маркетологом.
Да. Согласен. Я технарь, и дизайн от этого страдает. В основном сейчас шлифую чат, а он невидим для новичка. А pro.deloset.ru - поделка с ии за пару дней. Чаты допилю, и вернусь к нему. Согласен с "а что тут вообще продают?" - маркетинг еще одна задача отдельно от кода и дизайна. Обычное дело, когда в одно лицо делаешь - выбираешь самые вкусные задачи.
Прочел с интересом. Спасибо за обзор и ссылки. Увидел в скрине "общее собрание" - это локальное решение или редирект куда-то? Пообщаться бы о функционале и о вашем местном опыте. Я делаю свою deloset.ru (https://pro.deloset.ru), где нет автоматизации охраны, а но решаю разные модели общения включая доступ по ролям (и объектам) и контакты с внешними сообществами (например, соседние поселки или сервисные компании). Задумка в том, чтобы не только автоматизировать текущую переписку внутри поселка, но структурировать доставку (email-рассылки), хранение (форум) и доступ (объекты и роли) к накопленной информации. В принципе работает - шлифую интерфейс и близок к старту как никогда раньше. И интроверту очень нужны поселки для пилотного тестирования. Интересно ли вам (или другим читателям)? Ведь лучше управление - растет оценка недвижимости. Если интересно, то напишите в личку или tg:@victor_kupriyanov, пообщаемся.
Кстати да, госключом можно только pdf/картинку/text подписать - переименовал zip-архив в jpg и подписал ;) В самом начале писал, что "решал похожую задачу" - у кого-то другие задачи, это обычное явление. Важно, что в go-окружении (js оставил легким клиентом, а java не смотрел) можно рисовать pdf, но это типа по канве рисовать - для бекендера не нативно и больно. Потому html удобный промежуточный вариант, особенно в виде документа. Потом можно в pdf уделать, но я пока приостановился, вернусь когда важно станет.
Решал похожую задачу - генерация печатных листовок с индивидуальным qr-код. Решил, но по дороге поменял точку назначения.
Сначала казалось, что выход в pdf. Решал в go (react-клиент у меня легкий). Тоже нашел решение с бинарником, но сразу не хотел тащить в свой код. Далее учился рисовать pdf - не зашло. Потом видел решение, где данные отдельным слоем поверх старого накладывают - большой размер файла и было не решено. Еще слышал, как для преобразования word->pdf поднимают виртуалку с мс-офисом и запускают скрипт.
Конкретно я нашел решение в html - шаблон листовки встраивается в go-код через embed. Вставка текста в шаблоне очень быстрая - я на лету генерирую файлы, даже не стал заморачиваться с хранением в s3, асинхронщиной и состояниями. Основное время тратится на генерацию qr-кода.
На клиент передаю html. Дальше пользователь может сохранить в pdf из браузера. И внезапно оказалось, что pdf привычен, но не особо нужен - статичный html открывается легко везде, и имеет кучу настроек "на печать". PDF к такому html еще шрифт добавляет, и вырастает с 5КБ до 150КБ - на тысяче сгенерированных файлов уже заметно ;)
Наверно, можно "печатать" через браузер. Если не через клиентский, то настроить виртуальный принтер в какой-то форме, но я пока за минимальное решение. И еще не возвращался к такой задаче.
Эти три соединяются в обычном variants. Если можно в прозрачность, то ставится основной цвет text-success-700, а фон задается bg-current/5 сразу для всех вариантов. Вот с variant=solid такой фокус не срабатывает и там уже compoundVariants и длинное "text-success-50 bg-success-700". Все равно куча кнопок, но скорее из-за логики. Например, кнопки download/upload выделены в отдельные с наследованием ts-пропсов. А если какая-то редкая замысловатая кнопка, то проще стилизовать на месте, а не мудрить в универсальность. У всех компонент какой-то жизненный цикл. А "одна кнопка для всего" - зло.
Норм там с иконкой внутри и без. Четвертый tailwind умеет в хитрые штуки типа селекторов потомков. И умеет в data-атрибуты. Уверен, вы видели это в shadcn - я оттудова копипастю и адаптирую под себя. Так кусочек, когда нужно для xs только иконку, а текст в span прятать и оставлять только img/svg-иконку: adaptive: { true: "[&>span]:hidden sm:[&>span]:inline", false: ""} Еще в cva есть compoundVariants, когда просто variants не хватает. Здесь размер кнопки + текст/нет: compoundVariants: [ // отступы, если есть span-текст { adaptive: false, size: "md", class: "has-[>span]:px-3" }, { adaptive: false, size: "lg", class: "has-[>span]:px-4" }, { adaptive: true, size: "md", class: "sm:has-[>span]:px-3" }, { adaptive: true, size: "lg", class: "sm:has-[>span]:px-4" },
Да, все в css переводится. Но работает, и это уже хорошо
Не понял сабжа. Если делаешь универсальное решение, то по дефолту оно и является проблемой. Просто управляем сложностью, и рядом с XButton может быть XButton2 - норм. Про cva вы умолчали, что наряду с VariantProps-параметрами остается доступный className, куда можно добавить своё накопившееся.
Я тоже "нимношка" пишу свой коммуникатор. И пишу давно, потому что с нуля - хочу реанимировать древние форумы, скрещиваю их с мессенджерами и ролевыми доступами. Я одиночка, потому хз где кончается творчество и начитается бизнес-цель. Знаю, что в московской оффлайн-тусовке кто-то уже пилит НОВЫЙ мессенджер командой (не макс), но название я запамятовал. И уверен, что тут как с облаками - через полгода будет дофига мессенджеров. Потому что ит - это инфраструктура, и общаться через нее можно и нужно. Вопросы по задумке - Цель в чем? Если просто "осчастливить народ", то тухляк. Потому что сервера не бесплатные, поддерживать-развивать, а народ за сообщения платить не будет. Если окупаться, то кто платит?! И за что и сколько? Если есть бизнес-цель, то как набрать критическую массу. Я вот интроверт, и мне физически тяжело поддерживать кучу контактов. Еще в древние доковидные времена говорилось, что самоокупаемость соцсетей начинается с 50к пользователей.
На восьмой vite уже перешел. И заодно разделять бандл научился - проект небольшой и maplibre+terradraw увеличил бандл с 1МБ до 2МБ. Полет нормальный. А как это совсем без useEffect?! У меня много чего через useSWR, но что-то приходится через useEffect делать. И вот в в прошлом-этом месяце много эффектов было. И страдал от захватов и всякого. Разрулил, и с облегчением мечтаю, чтобы нескоро снова лезть в эффекты.
Мир разделяется. Технологии приравнены к оружию. И повесточка дня не "дружба дружбой, а табачок врозь", но "разделять и властвуй". В целом пиплу приходится думать, что радует. Ну и потерпеть придется, не без этого.
Зачем request в logError(r *http.Request, error), где он не используется. Наверно в поначалу поднимали логгер из контекста. И в http-ответе он не нужен, нужен только w.
Не надо, чтобы `message interface{}` (причем давно - any). Стоит сделать string, и приводить к строке на на месте или реализовывать интерфейс через String().
Не очень понял логику. serverErrorResponse пишет в лог и в http, а два других метода только в http. Типа это не ошибка бизнеса и не надо логгировать?! - для меня необычно, ну да ладно.
В принципе примерно также писал, но потом понял, что http-хелпер не пересекается с бизнес-логикой и стал писать вида `if d.CatchErr(op, err) { return }`, где d - обертка поверх (w, r).
Вау, оказалось, что я комментил вашу предыдущую статью.
Поражен вашей внимательностью ;) Писал залпом, и это был кусок кода из головы. Не проверял, потому что в этом месте по сценарию должен быть uuid. И мне трудно представить, что я его где-то чистым текстом вписал. Для такого зарезервированные значения в models.
Тут бы разбить общение на деловое и нет. Я тут ниже написал, что делаю "деловое общение" (или "что") - там важны статусы, деловая этика и рациональные мысли. И есть неделовое "как" - важны как раз эмоции, которые точно не рациональны. Потому это просто разное общение в разных системах. И проблемы, только если мешать одно с другим.
Чат - это привычная форма диалога. Эталон. Все привыкли к такой форме. Я делаю достаточно универсальную штуку, которая не может не включать чат. Вообще базово отталкивался от форумов. И если выкинуть "лишний обвес", то на выходе будет тот же чат. Другими словами люди отвыкли писать абзацами, а разбивают на отдельные короткие предложения.
ОРИ - это речь про количество читателей. А если в "форуме" всего два человека - то это частный разговор. Если сотня - чат поселка. Заявка - несколько заинтересованных участников. Но я надеюсь дорасти до масштабов ОРИ - у меня запланировано, чтобы пользователь настраивал каналы новостей со многих сообществ. Поэтому это не проблема, а цель ;)
И главная мечта - географическая интеграция сообществ. Объединять поселки с общим забором и дорогой. Объединять МКД в микрорайоны.
Спасибо за интересную статью. И важный опыт. Согласен, что рынок тяжелый. И приятно видеть, что кто-то рядом меняет его, засучив рукава и без нытья.
Я делаю похожую систему https://pro.deloset.ru - и тоже сложности с пилотным запуском. С обывателями уже наговорился вдоволь, далее думаю сосредоточиться на председателях. Но они еще и возрастные часто, и не хотят усложнять свою жизнь. Но с другой стороны - не толкаешься жопами с конкурентами.
Мой стек: сервер на Go, тонкий клиент PWA-React. Я сразу начал со сложных задач, и жахнул на них несколько лет: у меня возможно связывать сообщества между собой (соседние поселки), форумы для хранения документов и ролевая система доступа для каждого поселка, голосование тремя методами и упрощенный бухучет с двойной записью для местечковых проектов. Самое сложное - механизм связи сообществ, где бизнесовые партнерятся с потребительскими. Я хочу, чтобы не только новости частников, но и бизнесы присутствовали - в этом и есть бизнес-модель. И система профилей - по интересам и бизнесам, включая "по доверенности".
Потому долго делаю. И не вайбкодил, ии в чате юзаю. И только сейчас шлифую чаты. Потому что все собеседники пытаются сравнить с понятным - телеграм, и навороты на старте напрягают. И да, кодить и продавать - разные задачи. И интроверту тяжело в продажах.
Обязательные по закону вопросы - это 6 категорий и 55 тем. В основном про внешние большие деньги. И местечковое голосование может быть легитимным, если собственники отдельным вопросом решат, что оно легитимное. А еще гос-ОСС "тяжелое и дорогое" - можно рассматривать местечковые системы как промежуточное для выработки альтернатив и предварительной оценки успеха.
Я у себя такое выше написал - вопрос ко мне? Щас по-свежему распишу.
Push - это про service worker. Нахлобучка между сайтом и браузером мимо обычной бизнес-логики. SW подписывается на определенный endpoint на ресурсе конкретного браузера. В логике сайта нужно поднять разрешение/подписку, и отправить на сервер. Сервер запоминает подписку. И по нужде пишет зашифрованное сообщение на тот самый endpoint, который слушается клиентом.
Важно, SW работает даже если сайт закрыт. И на этом устроено PWA. И обновляет, и поднимает push'и в системном трее. В dev-режиме нужно настраивать vite, чтобы sw правильно поднимал.
Еще у меня есть SSE - server side events. Это для открытого чата. Тут клиент подписывается на stream-канал, который держится открытым, восстанавливается если упадет. И сервер просто отправляет сообщения в открытый канал. Важно, что http/2 это не умеет (в go так). Нужно снижать версию http-соединения. И подстраивать канал под flush сообщений. То есть отличается от обычного http-запроса. И nginx перед сервером может требовать хитрой настройки.
Email у меня свой. Нативный Postfix на VDS и доменном имени. Тут сложности больше в "белой почте" ака трех защитах - даже у профессионалов приходят письма с ошибками.
Сервер просто отсылает письма на свой smtp-сервер через стандартную библиотеку.
Тоже такое делаю. Уже несколько лет ;) Мне больше не хватало системного аналитика, который бы сразу сказал "как правильно" и еще убедил бы в этом - переделывал много раз. И еще буду переделывать - уверен.
У меня PWA/SPA на реакте. Управляю состоянием компонентов на useSWR. И куча контекстов. И три уровня токенов авторизации ;) И go на сервере. В go я хожу отдыхать... ;) Про состояния сервера в принципе давно узнал, потому делаю сразу stateless и две базы - master для записи и реплики. И ci освоил - рекомендую, недельку-другую поматериться, а потом хорошо.
Тема - CivilTech: объединение жильцов и собов в целях управления общим имуществом (но можно всех объединять - спортсообщества, профсоюзы и школьные комитеты). Сейчас освоил push'и, чтобы было похоже на телеграм, но в базе древовидные форумы для хранения документов. Описание: https://pro.deloset.ru - тут немножно стрёмно описано - щас чаты допилю, и стану маркетологом.
Да. Согласен. Я технарь, и дизайн от этого страдает. В основном сейчас шлифую чат, а он невидим для новичка. А pro.deloset.ru - поделка с ии за пару дней. Чаты допилю, и вернусь к нему.
Согласен с "а что тут вообще продают?" - маркетинг еще одна задача отдельно от кода и дизайна. Обычное дело, когда в одно лицо делаешь - выбираешь самые вкусные задачи.
Прочел с интересом. Спасибо за обзор и ссылки.
Увидел в скрине "общее собрание" - это локальное решение или редирект куда-то? Пообщаться бы о функционале и о вашем местном опыте. Я делаю свою deloset.ru (https://pro.deloset.ru), где нет автоматизации охраны, а но решаю разные модели общения включая доступ по ролям (и объектам) и контакты с внешними сообществами (например, соседние поселки или сервисные компании). Задумка в том, чтобы не только автоматизировать текущую переписку внутри поселка, но структурировать доставку (email-рассылки), хранение (форум) и доступ (объекты и роли) к накопленной информации. В принципе работает - шлифую интерфейс и близок к старту как никогда раньше. И интроверту очень нужны поселки для пилотного тестирования. Интересно ли вам (или другим читателям)? Ведь лучше управление - растет оценка недвижимости. Если интересно, то напишите в личку или tg:@victor_kupriyanov, пообщаемся.
Какая вероятность встретить динозавра на улице?
50 на 50! Встретишь или нет!
Кстати да, госключом можно только pdf/картинку/text подписать - переименовал zip-архив в jpg и подписал ;)
В самом начале писал, что "решал похожую задачу" - у кого-то другие задачи, это обычное явление. Важно, что в go-окружении (js оставил легким клиентом, а java не смотрел) можно рисовать pdf, но это типа по канве рисовать - для бекендера не нативно и больно. Потому html удобный промежуточный вариант, особенно в виде документа. Потом можно в pdf уделать, но я пока приостановился, вернусь когда важно станет.
Решал похожую задачу - генерация печатных листовок с индивидуальным qr-код. Решил, но по дороге поменял точку назначения.
Сначала казалось, что выход в pdf. Решал в go (react-клиент у меня легкий). Тоже нашел решение с бинарником, но сразу не хотел тащить в свой код. Далее учился рисовать pdf - не зашло. Потом видел решение, где данные отдельным слоем поверх старого накладывают - большой размер файла и было не решено. Еще слышал, как для преобразования word->pdf поднимают виртуалку с мс-офисом и запускают скрипт.
Конкретно я нашел решение в html - шаблон листовки встраивается в go-код через embed. Вставка текста в шаблоне очень быстрая - я на лету генерирую файлы, даже не стал заморачиваться с хранением в s3, асинхронщиной и состояниями. Основное время тратится на генерацию qr-кода.
На клиент передаю html. Дальше пользователь может сохранить в pdf из браузера. И внезапно оказалось, что pdf привычен, но не особо нужен - статичный html открывается легко везде, и имеет кучу настроек "на печать". PDF к такому html еще шрифт добавляет, и вырастает с 5КБ до 150КБ - на тысяче сгенерированных файлов уже заметно ;)
Наверно, можно "печатать" через браузер. Если не через клиентский, то настроить виртуальный принтер в какой-то форме, но я пока за минимальное решение. И еще не возвращался к такой задаче.
Эти три соединяются в обычном variants. Если можно в прозрачность, то ставится основной цвет text-success-700, а фон задается bg-current/5 сразу для всех вариантов. Вот с variant=solid такой фокус не срабатывает и там уже compoundVariants и длинное "text-success-50 bg-success-700".
Все равно куча кнопок, но скорее из-за логики. Например, кнопки download/upload выделены в отдельные с наследованием ts-пропсов.
А если какая-то редкая замысловатая кнопка, то проще стилизовать на месте, а не мудрить в универсальность. У всех компонент какой-то жизненный цикл. А "одна кнопка для всего" - зло.
Норм там с иконкой внутри и без. Четвертый tailwind умеет в хитрые штуки типа селекторов потомков. И умеет в data-атрибуты. Уверен, вы видели это в shadcn - я оттудова копипастю и адаптирую под себя.
Так кусочек, когда нужно для xs только иконку, а текст в span прятать и оставлять только img/svg-иконку:
adaptive: { true: "[&>span]:hidden sm:[&>span]:inline", false: ""}Еще в cva есть compoundVariants, когда просто variants не хватает. Здесь размер кнопки + текст/нет:
compoundVariants: [// отступы, если есть span-текст{ adaptive: false, size: "md", class: "has-[>span]:px-3" },{ adaptive: false, size: "lg", class: "has-[>span]:px-4" },{ adaptive: true, size: "md", class: "sm:has-[>span]:px-3" },{ adaptive: true, size: "lg", class: "sm:has-[>span]:px-4" },Да, все в css переводится. Но работает, и это уже хорошо
Не понял сабжа. Если делаешь универсальное решение, то по дефолту оно и является проблемой. Просто управляем сложностью, и рядом с XButton может быть XButton2 - норм.
Про cva вы умолчали, что наряду с VariantProps-параметрами остается доступный className, куда можно добавить своё накопившееся.
Я тоже "нимношка" пишу свой коммуникатор. И пишу давно, потому что с нуля - хочу реанимировать древние форумы, скрещиваю их с мессенджерами и ролевыми доступами. Я одиночка, потому хз где кончается творчество и начитается бизнес-цель. Знаю, что в московской оффлайн-тусовке кто-то уже пилит НОВЫЙ мессенджер командой (не макс), но название я запамятовал. И уверен, что тут как с облаками - через полгода будет дофига мессенджеров. Потому что ит - это инфраструктура, и общаться через нее можно и нужно.
Вопросы по задумке - Цель в чем? Если просто "осчастливить народ", то тухляк. Потому что сервера не бесплатные, поддерживать-развивать, а народ за сообщения платить не будет. Если окупаться, то кто платит?! И за что и сколько?
Если есть бизнес-цель, то как набрать критическую массу. Я вот интроверт, и мне физически тяжело поддерживать кучу контактов. Еще в древние доковидные времена говорилось, что самоокупаемость соцсетей начинается с 50к пользователей.
На восьмой vite уже перешел. И заодно разделять бандл научился - проект небольшой и maplibre+terradraw увеличил бандл с 1МБ до 2МБ. Полет нормальный.
А как это совсем без useEffect?! У меня много чего через useSWR, но что-то приходится через useEffect делать. И вот в в прошлом-этом месяце много эффектов было. И страдал от захватов и всякого. Разрулил, и с облегчением мечтаю, чтобы нескоро снова лезть в эффекты.
Мир разделяется. Технологии приравнены к оружию. И повесточка дня не "дружба дружбой, а табачок врозь", но "разделять и властвуй". В целом пиплу приходится думать, что радует. Ну и потерпеть придется, не без этого.
Зачем request в
logError(r *http.Request, error), где он не используется. Наверно в поначалу поднимали логгер из контекста. И в http-ответе он не нужен, нужен только w.Не надо, чтобы `message interface{}` (причем давно - any). Стоит сделать string, и приводить к строке на на месте или реализовывать интерфейс через String().
Не очень понял логику.
serverErrorResponseпишет в лог и в http, а два других метода только в http. Типа это не ошибка бизнеса и не надо логгировать?! - для меня необычно, ну да ладно.В принципе примерно также писал, но потом понял, что http-хелпер не пересекается с бизнес-логикой и стал писать вида `if d.CatchErr(op, err) { return }`, где d - обертка поверх (w, r).
Вау, оказалось, что я комментил вашу предыдущую статью.
Пользуйтесь на здоровье!
Поражен вашей внимательностью ;) Писал залпом, и это был кусок кода из головы. Не проверял, потому что в этом месте по сценарию должен быть uuid. И мне трудно представить, что я его где-то чистым текстом вписал. Для такого зарезервированные значения в models.
Тут бы разбить общение на деловое и нет. Я тут ниже написал, что делаю "деловое общение" (или "что") - там важны статусы, деловая этика и рациональные мысли.
И есть неделовое "как" - важны как раз эмоции, которые точно не рациональны. Потому это просто разное общение в разных системах. И проблемы, только если мешать одно с другим.