Ищу UI\UX дизайнера, HTML верстальщика в стартап

New part:

Ищу UI\UX дизайнера, HTML верстальщика. Задача, верстать компоненты UI
Оплата $$$, но возможно обсуждение (небольшой) доли в компании.
Люди без\c малым опытом, в процессе учебы, молодые художники, тоже приветствуются.
Пишите мне learn.fractal [@] gmail.com
Отличная возможность зайти в начинающий стартап. Причем стартап не на этапе лендинга или выбора стека технологий. Он имеет почти всю кодовую базу и практически сразу выйдет в плюс на рынке. Первые девелоперы, которые зайдут, однозначно будут иметь профит сильно больше обычного.

Old part:

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

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

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

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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Скучновато на этом вашем доу. Новый видосик запилил, подробности позже :)
www.youtube.com/watch?v=0NXPVvsayZ0

Мне не понравилось. Буквы огромные.
Что касается современного уих. Наиболее современный подход это отдать все юзеру. Хочет он кнопку сбоку — пусть туда двигает и сохраняет у себя в настройках. Хочет собственную кнопку — пусть добавляет. Хочет собственный стиль — пусть создает.
Не находится твой уих дизайнер? Воткни консоль. Набрал на консоли адд батон и вот он посреди пустого рабочего пространства. Набрал дальше set style bla-bla-bla — готово.
Дергать функции расставляющие по рабочему пространству с консоли повинуясь указаниям некоего мана — да это мечта любого пользователя. Создал расстановочные скрипты, залил в библиотеку, расшарил для своих и т.д. и т.п. Автогенерация с рендомным поиском лучших сочетаний цветов тоже здесь..

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

Я описал, как я формулами расставляю пикселы в своих узорах. Коих у меня в твиттере немеряно.

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

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

Ой йо, еще и про диоды волноваться ...

Ага. Мне тоже художник нужен. У меня есть кисти и краски, но нет идей для nft.

Мне тоже художник нужен.

Люди находятся достаточно легко, если есть понимание, что каждый труд стоит денег.

UP. Все еще ищу UI\UX дизайнера, HTML верстальщика. Имейл для связи тотже learn.fractal [@] gmail.com

Куда, кстати, делся бубен? Начинаю переживать.

Эккаунт «базист», вроде, жив (хоть и давно без коммитов) и днепро-бд снесен (у меня осталась копия :) ). В общем, как-то затих...

Все норм, спасибо за беспокойство =) Волею судеб, на начало войны оказался за границей, в одной арабской стране. В связи с событиями отдых затянулся и вместо двух недель там провел почти три месяца, поменяв несколько отелей. Потом перебрался в Стамбул, там еще месяц пожил. Потом сьездил посмотрел Нидерланды, потом в Венгрию. Потом думал махнуть в азию на год, но знаете что, понял. Хочу домой !
Эх мужики, это не передать словами, когда проезжаешь первые сотни метров после пропускного пункта, сразу такой буст, наконецто я дома, на родной земле !
Впрочем, всеже семью пока оставил за границей и теперь я полон энергии и свободного времени работать над проектом до перемоги, как и вся страна на военных рельсах.

Вообщем «Доброго Вечора, ми з України» =)

Ну что зАйчатки, новое видео подвезли или сказка на ночь, что можно написать в 150 строк кода, если у вас на руках правильные инструменты.
www.youtube.com/watch?v=dyhYrNkLuHA

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

Посчитаем в таком микро приложении для начала количество скринов, не считая логинки.
1. Дашбоард чата
2. Создание чата
3. Редактирование списка юзеров
4. Редактирование списка проектов
5. Редактирование списка тимов
6. Грид со списком чатов
7. Редактирование инфо самого чата

Посчитаем теперь количество реляционных таблиц
1. Юзеры
2. Тимы
3. Проекты
4. Связь между Юзером к Тиме
5. Связь между Юзером и Проектом
6. Чаты
7. Связь между Чатами и Тимами
8. Связь между Чатами и Проектами
9. Связь между Чатами и Юзерами
10. Связь между Чатами и Сообщениями
11. Сообщения

Итого 11 таблиц. Если прикинуть что в обычном приложении разложеном на обычную архитектуру примерно 500-1000 строк кода приходится на одну таблицу, то имеем:
1. Слева 150 строк кода на платформе (новый подход в разработке)
2. Справа 7 скринов + 11 таблиц + от 7 тыс до 11 тыс строк кода, если еще с архитектором повезет.

Что еще интересного. Вы видите настоящий пример слабосвязаной архитектуры. Это когда большие куски функциональности (бизнесс логика\база\юай) можно перекидовать между разными проектами. В обычной архитектуре перекинуть функциональность между сложными проектами практически невозможно, нужно все переписывать. Здесь, если понадобятся тимзы в другом проекте, все скрины с базой и бизнесс логикой перекинуть дело 10-15 минут.

Ищу UI\UX дизайнера, HTML верстальщика. Задача, верстать компоненты UI
Оплата $$$, но возможно обсуждение (небольшой) доли в компании.
Люди без\c малым опытом, в процессе учебы, молодые художники, тоже приветствуются.
Пишите мне learn.fractal [@] gmail.com
Отличная возможность зайти в начинающий стартап. Причем стартап не на этапе лендинга или выбора стека технологий. Он имеет почти всю кодовую базу и практически сразу выйдет в плюс на рынке. Первые девелоперы, которые зайдут, однозначно будут иметь профит сильно больше обычного.

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

Два желудя вместо одного?

Два желудя вместо одного?

Прекрасно понимаю твой скептицизм.
Поэтому там есть опция.
Или за $$$ или доля в компании. Бюджет есть.
Причем мне выгодней заплатить $$$ чтобы не размывать долю в проекте который уже давно не находится на стадии «паверпоинт презентации».
Оплата возможна с любым графиком. Вплоть до «ежедневно\еженедельно» по мере продвижения работы.

Смысл раздавать долю, если проект уже почти готов? Долю как раз дают когда проект на стадии лендинга и нет денег. Когда деньги есть и все готово, нечего доли разбазаривать.

Смысл раздавать долю, если проект уже почти готов?

Есть области в которых проект нужно усилить прямо сейчас. И это в том числе UI дизайн.
Здесь готов обсуждать в том числе небольшую долю. С другой стороны, даже эта небольшая доля в будущем может вылится в те самые "какие компании раздают четыре мульта"© :D
Но это не точно, думаю здесь больше циников которые хотят $$ здесь и сейчас,
а не потом и много =)

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

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

Теперь я придумал добавить кастомный layout, где можно указать свою подложку для страницы (футер, заголовок, меню и тд). Каждый контрол теперь имеет LayoutLocation и может размещатся в определенной части страницы. Также вводится новый тип контрола Component.

Итого юзер экспириенц на платформе выглядит так.
1. Ты проектируешь свое приложение и в подарок получаешь автосгенерированный юай совершенно бесплатно. В юае ты имеешь выбор из стандартеых контролов, сейчас их 9 штук, включая дропдауны, гриды, деревья и тд. При этом твой входной билет на платформу zero html, zero rest, zero sql, zero rdbms и тд.
2. На следующем этапе тебя не устраивают стандартные контролы и стандартный layout и ты можешь их кастомизировать. Нарисовать свой дизайнерский layout, поменять фон контролов, шрифты, какието элементы css.
3. И наконец некоторые стандартные контролы не устраивают полностью и ты вместо их пишешь Component. А внутри уже вообще любой html и javascript.

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

Минусы подхода.
1. Весь FE генерится по прежнему на серверной стороне. Есть плюсы и минусы такого подхода.
2. Частично теряется кросплатформеность. Если раньше единая кодовая база запускалась и как десктоп приложение и как веб сайт, то сейчас есть проблемы в местах где написаны свои кастомные компоненты. И это нормально, если ты надизайнил css и html то в автоматическом режиме его невозможно конвертнуть в виндовс контролы на форме. Но есть и хорошая новость, эти части будут отрисованы стандартными автогенерируемыми контролами, что является компромисом.

Вообщем я уже 70% этого FE собрал и частично протестировал и могу сказать, что уже наполовину открыта дорога к Web конструктору приложений, когда все приложение можно собрать в окне браузера.
Что забавно, на 90% конструктор скорей всего будет собран на себя же самом. Что занятно. Поскольку другие lowcode евангелисты обычно говорят что на нашей туле можно собрать почти все, но конечно же не сам lowcode )

Для начала надо ознакомиться с идеями уже существующих-разрабатываемых решений, к примеру для нашей страны стек Метархиа / Сваер github.com/metarhia/swayer (и вообще в целом понять сколько сообщество сил потратило и как тяжело продвигаться, организовывать людей).
От ближнего соседа $mol (mol.hyoo.ru на хабре зачетные статьи, и тоже понять как один даже гениальный человек не смог продвинуть в массы и как относятся к велосипеду).
Прочекать современные решения Remix (https://remix.run).
В ваши примеры не вникал, но визаульно тоже самое в этом (правда платном) наборе контролов под ангуляр на изи залетает ej2.syncfusion.com/angular/demos

Чем больше я смотрю на все эти JS фреймворки, тем больше не покидает чувство дежавю. Вот почему народ штампует однотипные решения. Вот чем на рынке координально Джава отличается от Дот нета, Руби от ПХП, vue.js от react.js, еще какой-то $mol придумали. Нет, я понимаю что те кто в теме, меня сейчас захейтят, но если так подумать и разобраться. Какой из этих фреймворков позволяет в сто раз быстрее писать и в сто раз с меньшим количеством багов ? Никакой. Ну начнешь проект на дот нет, потратишь месяц. И на джаве потратишь месяц. Начнешь писать на реакт, потратишь месяц и на вью месяц и на мол ну пускай 3 недели. А вот так чтобы в сто раз проще и быстрее все написать, то нет.

Потому что простота, это самая сложная вещь. Сделать не еще один клон, а простую но функциональную вещь, невероятно сложно.

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

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

Клон жиры на минималках за 3 часа🤣 Автор ещё совсем юн и наивен (в профессиональном плане)

А в чем проблема ? Там внизу описан минимальный список функционала.
1. Регистрация пользователя
2. Подтверждение аккаунта по имейл, восстановление пароля через имейл
3. Управление списком пользователей.
4. Две роли Админы и Юзеры
3. Визард по созданию сторей
4. Сторя содержит разную инфо вроде эпик, описание, статус, ассайгнится на юзера
5 Сторя содержит список тасок и дефектов. Сами таски имеют статусы, асайгнятся на людей.
6. Есть чатик с комментариями в сторе.
7. Есть форма отчета, содержит список из 14 разных параметров. Сколько сторей в каком статусе, сколько осталось эстимейтов, какие заасайгнены на текущем юзере.
8. На всех основных формах фильтры и сортировки, можно искать по разным атрибутам стори.

Не допилил спринты. Обычно в скраме начинают с спринта и его наполнения сторями с беклога. Это еще может час работы.

Я считаю это минимальный функционал.
Можешь сделать лучше на своих инструментах ? За сколько времени ?

1. Регистрация пользователя
2. Подтверждение аккаунта по имейл, восстановление пароля через имейл
3. Управление списком пользователей.
4. Две роли Админы и Юзеры

Це все є авторизаціїї / автентиффікації немає ))
Так може любий дев вигадати собі забаговані вимоги і накидати ла*но за 1 час

Це все є авторизаціїї / автентиффікації немає ))

Первое правило девелопера — ясно выражать свои мысли. Чего конкретно немае ? Какой юзер кейс ?

Так може любий дев вигадати собі забаговані вимоги і накидати ла*но за 1 час

Вимоги джиры вверху есть.
Если можешь за час накидать хотябы пятую их часть, зачем лишний раз трепаться. Накидываешь на своих инструментах, снимаешь видео что работает. Показываешь сколько строк кода, чтобы пруфнуть что их реально было за час написать и отладить.
Вопрос закрыт.
А то уже который раз один и тотже сценарий.
1. Громкие слова
2. В кусты
3. Тишина

Предлагаю запилить тебе трех чесовое видео как надо пилить джиру за 3 часа

Для этого мне придется все удалить и пилить заново. Так не интересно.
Лучше расширить функционал того что есть. Возможно это будет портал, который обьединит в себе частично функционал апворка, джиры и портала для обучения и сертификации разработчиков с курсом "как правильно запилить джиру за 3 часа"©
И конечно это уже не будет тикток видео, а будет онлайн ссылка для регистрации

От ближнего соседа $mol (mol.hyoo.ru на хабре зачетные статьи, и тоже понять как один даже гениальный человек не смог продвинуть в массы и как относятся к велосипеду).

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

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

Я решил завязать и уже давно с созданием своих ЯП. Хотя в свое время их понаписывал тоже не мало. Сейчас понимаю что все эти сравнения — смотрите слева у меня три строчки, справа 500 строчек, не работают. Потому что эти три строчки, не так то просто написать. Сейчас мой ориентир, можно ли ребенка посадить и научить писать на этом за пару вечеров. Если можно — это хороший знак. Люди любят простые решение, вот прям чтоб для идиотов. Тогда они не чувствуют себя идиотами и у них не пропадает мотивация в этом всем разбираться.

Клас, кльовий проєкт! Можеш подивитись як Wix зроблений, зробити реверс інжиніринг, погуглити, чи знайти ще якийсь схожий білдер.

Також можеш подивитись в сторону AWS Amplify. Я ніколи ним не користувався, але наче щось схоже до твого продукту.

Wix
AWS Amplify.

Там чеклист должен быть примерно такой.
1. Использует реляционные базы данных вместо NoSQL ? в топку
2. Использует NoSQL но там нет транзакций и ACID ? в топку
3. Работает просто в схеме запрос\ответ и не имеет взрослые механизмы синхронизации данных в стиле дифов, подписок, с восстановлением закорапченых данных, асинхронным обновлением ? в топку
4. Как расширяется ф-сть. По принципам АОП или это просто кастомизация типичных шаблонов приложений ? Шаблоны — в топку
5. Как легко тюнить перформанц приложения ? Можно ли легко горизонтально масштабировать ? Можно ли довести прототип приложения не переписывая его с нуля до миллионов активных пользователей ? Нельзя ? В топку.

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

І навіть не важливо, що там під капотом. MySQL норм, Mongo норм, головне не файлик :)

З’являться перші користувачі, будуть відомі юз кейси — тоді вже можна і подумати, щоб розширятись.

Можна і зараз про це думати звісно, витрачати час, щось придумувати. Я знаю багато таких прикладів, тільки вони ніколи не запустились :/

Файлик норм, купа систем так були написані і досі працюють

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

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

"Всегда выбирайте самый трудный путь — на нем вы не встретите конкурентов."© Шарль де Голль

Но это в идеале, на практике в условиях ограниченных ресурсов, всегда стараешся идти по пути 80% результата за 20% усилий.

Все что тебе осталось это написать свой UI фреймворк, свой webpack, свой роутер, свой Store и еще кучу всего, а потом завернуть это в твою систему написав автобилдер, автопаблишер, автогенератор стилей и т.д...

Уже примерно прикинул как UI конструктор буду писать. Все не так печально. Модель данных есть, она обновляется. Ее нужно к лейаутам и стилям забайндить. Наверно возьму основные идеи из реакта и его компонент + бутстрап для стилей.

Так, новый функционал подвезли. Теперь сортировки есть везде в гридах.
www.youtube.com/watch?v=CI514uhlj8k

Ничего особенного. Но есть ньюансы.
1. По каким колонкам можно сортировать данные настраивается в конфиге. По умолчанию можно сортировать по всем колонкам.
2. Сама сортировка персистенц. Тоесть сохраняется состояние сортировки после закрытия/переоткрытия формы
3. Сортировка прекрасно сочитается с фильтром на форме и с пейджингом

Ссылка вверху битая.
Перезалил видео, добавил еще эпизод как сортировка вместе с фильтром сочетается
www.youtube.com/watch?v=npgkwwMo10g

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

И да — я вот работу криптовалютной биржи сейчас изучаю.
Почему бы ТС тоже такой фигней не заняться?

Крипта мне не интересна.
Я считаю ее вредной технологией, в смысле не полезной для общества.

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

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

Думаю — 2/3 будет достаточно. Это такое упражнение для ума. «Предположим, что на самом деле 2+2=5. В таком случае...»
«Закинул старик невод и пришел он пустой, только с тиной морскою» Но опыт обдумывания заведомого паралогического абсурда останется с нами (мной и вами).

Не знаю, поможет ли... Есть одна хитрость в продвижении нового. Даже если работающего.
Всем достаточно старого.
Новое требует приобретения опыта работы на нем для принятия. То есть, без необходимости привыкания новое обычно отторгается всеми возможными способами.
Новое — черный лебедь. Представим некую площадь (canvas), заполненную случайного цвета областями. Алгоритм путешествия по ней будет таким: из области одного цвета в область похожего — комфортно. Иначе — неохота.
А теперь в этой площади промоделируем изобретение нового цвета. Если он оказался сходным с каким-то цветом есть некоторые шансы, что путешественник не откажется этот путь присоединить к обыденным.
Делать новое привычным — работа ли это для одного? И факт — работа такого рода должна быть оплачиваемой.
Вау эффект это на самом деле оплаченная реклама.
P.S.
И конешно, осознанная или неосознаваемая необходимость в будущем исследовать решения конкурентов (wix?) может привести к появлению всяких флуктуаций идей в настоящем. Ослепительных идей вспышек откровений заставляющих все бросить и писать код.
Вот только оно уже может все быть написано кем-то, увидено изобретателем полностью или краем глаза и забыто, а потом бац! идея!
Идеи это глюки. Один из видов. Неприятно, но вот так вот оно есть.

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

Что подеть. Общество — инертно.
Только шоковая терапия, совмещенная с практическими результатами, сможет сдвинуть тектанические плиты сознания масс.

Нет. Может тебе Дон Кихота перечитать? Кажется там именно про внезапную одержимость ослепительными идеями.

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

Это все очень ок. В теории.
На практике — загони систему на облако с биллингом, тот же GCP Free Tier дает $300 на 90 дней. Сделай там нагрузочное тестирование на 10k, 100k, 1m — и покажи насколько у тебя оптимизировано TCO для масштабирования в виде графиков по времени, объемам тестирования и стоимости.
У тебя может быть золотое решение — но и стоимость его эксплуатации тоже будет золотой.

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

Ну просто допустим будет фронт и что дальше? Очередной lowcode/nocode с непонятным масштабированием и стоимостью поддержки.

lowcode/nocode

Это не лоукод\ноукод в классическом понимании.
1. Он позволяет получить сразу взрослую архитектуру
2. Некоторые приложения крайне тяжело собрать на других конструкторах. На этом можно.
dou.ua/...​rums/topic/36344/#2341606

Платформа возможно гдето посередине, между лоукод и просто другой парадигмой программирования.

Ну вот как сможешь показать десяток приложений с 1M установок и 4+ звездочками — готовься грузить деньги бочками.

с непонятным масштабированием

И непонятными возможностями. Кроме видосиков и «текстов и постов» о том что оно все-все-все на свете может, у нас нет никакой информации в виде документации или спецификации.

обычный галерный гребец компенсирует

При в целом верной оценке, не могу однако, согласится, что наш топикстартер — обычный галерогреб.

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

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

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

Архитектура как и алгоритмы для начала валидируются в теории.
Например, с нотацией О большого. Если в теории все сходится, то на практике обычно тоже не должно быть проблем.

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

А почему у них должна быть плохая оптимизация ? То что я не занимаюсь оптимизацией не означает что что-то тормозит. Например оно может держать 5 тыс запросов в секунду, а с оптимизацией 10-15 тыс. Но мне пока не интересно выжимать эти биты, поскольку работы и так хватает.

Все части идеально подогнаны друг к другу

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

Можно ли вместо какой-то «этой части» использовать другую, не вашу?
Как это обеспечивается?

легко расширяемые

Укажите способ расширения, и почему он легкий

буквально за час-два времени собрать мини прототип

Всякая развитая экосистема разработки позволяет за час-два времени сделать вывод сообщения:
Hello world!

собственной субд

это точно неинтересная фича. Видов надежных, проверенных СУБД достаточно много, чтобы рисковать доверять данные какой-то новой, неизвестной

Азы:
Персистентные данные это такие, время жизни(ценность) которых превышает время существования ПО которое с ними работает.
Например: по какой-то причине движок DOU захотят переписать на C#.
А все темы-комменты за годы — без проблем сохранятся, и новый движок без мук будет с ними работать.

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

Это сразу в мусорную корзину.
Проблемы с таким юай отлично известны — поддерджка и развитие становятся фактически невозможны

Да, есть и Oracle APEX, и Wix — но no-code и low-code про другое.

как строятся современные юай фреймворки. С чего начать, куда смотреть, что взять за основу ?

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

Если вы не знаете с чего начать — то у вас просто нет никаких проблем с юай. Вы их — не знаете, а не «как строятся»
Вот например история Vue.js
Vue.js: The Documentary (Русская Версия)
Эван Ю решал конкретную свою проблему. Он точно знал какую.

И помнится, обсуждал с вами проблемы форумного движка DOU. Вы и этого не знаете — какие проблемы стоят перед разработчиками подобного массового ПО, поэтому уверен — и эти проблемы ваша система «создания веб/десктоп/моб приложений» не будет решать.

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

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

Можно ли вместо какой-то «этой части» использовать другую, не вашу?
Как это обеспечивается?

Можно.

Укажите способ расширения, и почему он легкий

Через АОП. Легкий потому что, чтобы добавить новый функционал иногда не нужно даже перегружать приложение. Напр. добавить локализацию, кеширование, валидацию и мн. др.

это точно неинтересная фича. Видов надежных, проверенных СУБД достаточно много, чтобы рисковать доверять данные какой-то новой, неизвестной

Универсальный аргумент. Надо было тогда на какомто фокс про остаться в 90х. Потому что все новое неизвестное.

Это сразу в мусорную корзину.
Проблемы с таким юай отлично известны — поддерджка и развитие становятся фактически невозможны

Да, есть и Oracle APEX, и Wix — но no-code и low-code про другое.

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

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

Я тебе проблемы указал. Осталось тебе их решить на своих инструментах с тем же качеством.

И помнится, обсуждал с вами проблемы форумного движка DOU. Вы и этого не знаете — какие проблемы стоят перед разработчиками подобного массово ПО, поэтому уверен — и эти проблемы ваша система «создания веб/десктоп/моб приложений» не будет решать.

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

Через АОП.

Он мертв. Мертвее некуда.
Проверено и доказано индустрией разработки.
Вы в каком году живете, если не знаете этого?

Надежд на него да, было много.

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

Надо было тогда на какомто фокс про остаться в 90х

У Фокспро были конкретные недостатки. Я на нем писал
Которые решились с помощью двух-звенной архитектуры. У которой тоже оказались недостатки. Которые решились — трех-звенной

Это не в корзину. Это фича.

Ну вам виднее конечно

Если тебе нужно срочно протестировать бекенд

То я возьму какой-нить Postman
Или, как в одном проекте — за полдня наваяю более специализированный.
Которым пользовались — несколько лет и фронтендеры на проекте :)

Осталось тебе их решить на своих инструментах с тем же качеством.

Их все решают, с разным качеством :)

Но есть да, уникумы, которые никаких проблем не только не решали, а не имеют даже представления о них, но уверенно дают советы :)

но в интернете полно примеров где ленты комментариев обновляются асинхронно без перезагрузки страницы

Да
И для этого все есть
Кроме времени, людей, или политической воли владельцев сервиса

И сидеть обсуждать что «это никому не нужно» для меня както странно.

Для меня ничего странного.
Бизнес, он такой, заказывает то что считает нужным. И не заказывает то что не считает нужным.
В инете полно сайтов известных торговых сетей с отвратительно тормозящими фильтрами товаров.
Для того чтобы не тормозило — все уже давно есть, во множестве вариантов. Но им — просто не надо, вот и НЕ поставили задачу — программистам.

Это только говорит что у разработчика недостаточно времени\опыта чтобы сделать более современный функционал.

Что говорит о том, что вы напрочь не в курсе причин как получается кривое, косое, устаревшее с рождения ПО

Он мертв. Мертвее некуда.
Проверено и доказано индустрией разработки.

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

Как я и говорил, проще вайтишника/студента/джуниора научить писать сложные масштабируемые

да. Кузьмин тоже так говорит
Всякому гению опытные — помеха.

Открывайте набор — студенты и вайтишники жалуются что сотнями рассылают резюме, полгода ищут работу
И вперед.
Воскрешать АОП!

Гендальф не умер, просто он так пахнет...

Всякому гению — опытные помеха.

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

О, пошли плиточники, квадратные кирпичи и лабрадоры :-)

Чувак ты сначала на серьезных щях про АОП, а потом вот таким гивном поливаешь? Лечи болезнь «непризнаного гения» иначе затянется.

Чувак ты сначала на серьезных щях про АОП

А чего же не говорить про АОП на серьезных щах. Если АОП подобно изменению генома приложения, позволяет добавлять целые пласты функциональности, которая охватывает все аспекты работы приложения. Если ООП это неуклюжий каркас с набором контрактов и какимито проблесками полиморфизма, то АОП (по крайней мере в моей реализации) это просто живая система. Именно поэтому мне не составляет труда собрать форму на сотню контролов за 20 минут или джиру на минималках за часа 3. За это время на существующих инструментах это сделать невозможно. Даже джира это минмум 20-30 таблиц в субд + тысяч 20 строк портянок кода. И даже если ты это все там напишешь, каждый залет функциональности типа секурити, локализации, историчности приведет к переписыванию большинства этого кода.

Но зато у «эксперта» по пхп и дельфи АОП ... цитирую:

мертв. Мертвее некуда.
Проверено и доказано индустрией разработки.
Вы в каком году живете, если не знаете этого?

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

Ты хоть обну апликушку родишь или все таки остатнется в твоей шизе? Где твоя жыра и фб? залил бы на копеечный хостинг хотя бы, мы бы поржали, заодно увидели бы перформанс, вернее его смерть на 10+ юзерах :-)

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

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

Мне не придется ;-) Была бы апликушка зашел, видосики — ниже отписали. Пока видно что ты можешь записывать видосы, программировать — нет.
Так что пока в перспективе Кузьмен и Бубич канал более реальный ;-)

Была бы апликушка зашел,

Ну мне просто лень. Я ленивый. Мне апликушку писать гдето в среднем минут 30-40. Видос снимать 3 минуты. А задеплоить апку, этож надо пойти хостинг найти, развернуть там все. И для чего, чтобы какойто аноним из интернета убедился что видео это не фотошоп. В этом нет смысла.

В этом нет смысла.

Во всех твоих поделках нет смысла )))

«Секрет успеха в том, чтобы вызвать возмущения у как можно большего числа людей.» — Джордж Бернард Шоу

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

Так а где успех бубен? Пока я вижу только видосики про машину Кузьмина :-) Или это и есть твой успех, таки решился вести канал? ))))

Какую базу данных используете?

Все, кончились базы данных. Конекшин стринг и отдельный инстанц субд это уже вчерашний день. В новом подходе вводится такое понятие как Storage. И он как в ореховой скорлупе обшивается бизнесс логикой с разных сторон. Такой подход имеет ряд существенных приимуществ.
1. Абстракция Storage очень простая. Поэтому реализаций Storage — много и будет еще больше. От Dumb которые ничто никуда не пишут и не читают и используются для тестирования, до имплементаций которые поддерживают полный ACID или являются сборными солянками сразу нескольких алгоритмов хранения данных.
2. Storage обшивается только той бизнесс логикой, которая нужна в контексте. Нужны транзакции, валидация, секурити, проверка на форейгн ключи ? Ок, добавляешь. Не нужно, не добавляешь. Тоесть по перформанцу ты платишь только за то, что используешь в отличии от классических субд, где ты платишь просто за все, даже если это в твоем контексте работы с данными не нужно.
3. Подход когда Storage зашит в скорлупу бизнесс логики дает неймоверные приимущества по быстродействию. Это как сравнивать работу ядер процессора, которые читают данные с диска и ядра которые читают/пишут данные с L1/L2 кешей, которые у них «под носом». Прирост по производительности может составлять и 100 и 1000 раз. В некоторых бенчмарках движки стореджей «раскручивают свои роторы» до обработки 10-15 млн запросов в секунду. Что является близким к теоретическому пределу, что вообще можно выжать с оборудования.

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

еще 10 лет назад классические системы обрабатывали миллионы.запросов в секунду. тоесть эта абстракция просто сьела прирост производитльности серверов за десять лет? а какие-то плюсы есть?

еще 10 лет назад классические системы обрабатывали миллионы.запросов в секунду. тоесть эта абстракция просто сьела прирост производитльности серверов за десять лет? а какие-то плюсы есть?

Почему сьела, если наоборот, вернула ?

В некоторых бенчмарках движки стореджей «раскручивают свои роторы» до обработки 10-15 млн запросов в секунду.
Все, кончились базы данных.

А где данные лежат? Все в оперативной памяти? :-)

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

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

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

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

Конекшин стринги есть. Но нет этого дибильного. Открыли эскьюэль команду, напихали параметров, открыли конекшон, сделали экзекют. Распаковали, промапили. Короче драйвер одбс и вот это вот все НЕ НУЖЕН. Не в ручном режиме

Подход когда Storage зашит в скорлупу бизнесс логики дает неймоверные приимущества по быстродействию

Ааа, так ты просто придумал embedded Redis № 2.
Поздравляю. Уже есть Hazelcast, на котором работает система сбора данных БАК. ~400 нод которые сохраняют ~200GB в секунду.
Может через годик напишешь аналог H2.

ты просто придумал embedded Redis № 2

Ок. И как Редис научить хранить документы. Научить в взрослое секурити ( с наследованием ролей и выдачей прав на каждый атрибут\парент атрибут документа). Как научить Редис в транзакции ? Там есть эта ф-сть ?

Как научить Редис в транзакции ?

Вбей в гугл два слова «redis transactions»

Научить в взрослое секурити

Это ты свою модель почему-то назвал взрослой? )

с наследованием ролей и выдачей прав на каждый атрибут\парент атрибут документа

А эта дрочь кроме тебя никому не нужна. Вот беда-то.

И как Редис научить хранить документы.

А что такое «документ»? Все, что ты положил в редис, можно назвать документом. Если мне нужно будет распидорашивать жсон на поля для индексирования/FTS, я возьму Solr/Lucene, который точно будет уметь это лучше, потому что он для этого сделан. А если мне это не нужно, то мне достаточно редиса.

Ну так вперед. В чем дело. Я уже шесть приложений написал за неделю пока ты чехлишся и в уме (!) собираешь вундервафлю с кафкой редисом и люсеной. С таким подходом аккурат все сделаешь через год или два

И что твои 6 приложений умеют делать? :-)

Он еще не решил )
Но их точно можно написать за час. Нет, за 10 минут. Нет, за 1 минуту.

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

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

Ну так а кто бы сомневался ? Программировать на джава и им подобным полуфабрикатам — это боль и страдания. Как не твоим мозолистым пальцам этого не знать. Поэтому врядли мы здесь увидим даже туду лист на джаве.

Платформа представляет собой полную экосистему для разработки, от собственной субд до фронт фреймворка

А messaging?

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

Це все файно. Але messaging є чи ні? Щось я не зрозумів.
Чи є черги повідомлень з балансуванням по консьюмерам? Які гарантії доставки? At least once? Exactly once?

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

Яблука не заміна апельсинам.

Простий приклад — треба нотифікації юзерам розсилати, на імейл і на СМС. Вирішується елементарно двома чергами і лоад-баланснутими консьюмерами з автоскейлом по розміру черги.

А діфами як це вирішити? До чого тут діфи взагалі?

Дифами это решается элементарно.
Мастер база данных содержит коллекцию SentEmails и слейв содержит SentEmails коллекцию. Они синхронны. Но у слейв есть хендлер, который оживает когда а локальную субд вставлена запись. Он отправляет имейл и помечает запись там, что почта отправлена в случае успеха.
Плюсы. Лог отправленных имейлов. Если почтовый сервис недоступен, письма сохраняются как неотправленные и потом могут быть отправлены хендлером снова. Систему можно остановить, запустить снова и она начнет работать с места на котором ее остановили.
Вклад же тех идиотов которые придумали оперировать голыми очередями я могу сравнить с вкладом идиотов которые придумали везде пихать GoTo. Что там что там получается асинхронная многопоточная лапша которая живет своей жизнью и хрен это все нормально отладишь.

хендлер, который оживает когда а локальную субд вставлена запись

Як це суміщається із

Если почтовый сервис недоступен, письма сохраняются как неотправленные и потом могут быть отправлены хендлером снова

Як налаштувати retry стратегію з експоненційним часом ретраю наприклад?

Який перформенс такого рішення, де по суті замість черги — СУБД?
Після Кафки з їх лінійними партішнами це мабуть буде дико лагати.

Як налаштувати retry стратегію з експоненційним часом ретраю наприклад?

Как настроишь так и будет работать. Ретрай через 15 сек значит через 15 сек, напр.

Який перформенс такого рішення, де по суті замість черги — СУБД?
Після Кафки з їх лінійними партішнами це мабуть буде дико лагати.

Смешно читать про перформанц очереди отправки имейлов или смс. Ты решил отправить миллион имейлов или смс за секунду через кафку ? Тебя забанит смтп сервер навечно и отключит от сети )

То есть эта система изначально не масштабируема даже под 1M юзеров? Печально...

То есть эта система изначально не масштабируема даже под 1M юзеров? Печально...

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

Ну ок — простая задача, взятая из тобой примера — вызов такси. Есть 10m активных юзеров, N такси (они приходят и уходят в любой момент). Задача — обеспечить приезд такси в срок 15 минут, с условием что любой таксист внезапно может уйти (поломаться итд) или зайти (новая рега).
Каким образом ты будешь решать это из расчета, что запись/апдейт 1m таблицы в базу займет 10 минут, а с одной ноды можно отправить 50k пушей за 3 минуты.

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

Тоесть математика здесь такая. Допустим в Мастер базу данных льют по 10 новых заказов в секунду от пользователей. В городе 5 тыс таксистов. В одном районе города сконцентрировано в среднем 50 машин. То по попдписке сервер будет рассылать сообщения только 50 *10/сек новых заказов, обновляя дифами каждую секунду 500 своих слейв клиентов. Для одного сервера это совершенно нормальная нагрузка.

А если нагрузка возрастет? Можно просто добавить сервер и система сама сделает балансировку?

Да. Можно применить топологию типа «звезда». Центральный мастер реплицирует заказы на несколько слейвов, своих дублеров. А те уже в свою очередь выполняют роль «мастеров» в своих геолокациях.
Но сам подход подписки, когда моб клиент получает только то, что изменилось на мастере дифами, уже координально разгружает сервер. Сервер не задергивают все клиенты и сразу своими обновлениями, а ждут сообщений от мастера, который планомерно рассылает всем изменения.

Каким образом у тебя мобильное приложение «ждет» без задергиваний?

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

Скорее всего будет дико жрать батарею.

У таксистов мобила всегда включена и подключена к прикуривателю =)

А теперь вместо прикуривателя можно использовать батарею :-)

Скорее как обогреватель. И это мы еще не прошли кейс когда телефон повис а после рестарта клиенская субд покрешилась.

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

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

Кстати — ты только что решил теоретическую проблему о том как пропихнуть свои неоптимизированные аппки в сторы — стать гигантом типа Фейсбук.
Так, с теорией закончено — давай реализовывай на практике.

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

Как будешь сабмитить в сторы — поймешь.

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

Для этого есть хелз чек и база может быть восстановлена «с нуля»

Она будет не только дичайше жрать батарею, но и оперативку. Т.е. реально, его предложение сводится к тому что клиент(!!!) должен хранить копию мастер-данных(!!!!!) локально

А твой мессенджер например Телеграмм не хранит копию мастер данных ?

Как настроишь так и будет работать. Ретрай через 15 сек значит через 15 сек, напр.

Це на всю базу, на таблицю, на запис?
Якісь казки «все ідеально працює як захочеш». Дуже сумнівно звучить.

Якщо хендлер тригериться при інсерті в базу, то звідки береться ретрай взагалі? Треба ж нові інсерти кожен раз виходить. Тим більше ретрай через час — а хто рахує час? База чекає поки тригернути хендлер? Чи в самому хендлері треба писати таку логіку?

Ты решил отправить миллион имейлов или смс за секунду через кафку ? Тебя забанит смтп сервер навечно и отключит от сети )

Як тільки Фісбук не забанили.

Якщо хендлер тригериться при інсерті в базу, то звідки береться ретрай взагалі? Треба ж нові інсерти кожен раз виходить. Тим більше ретрай через час — а хто рахує час? База чекає поки тригернути хендлер? Чи в самому хендлері треба писати таку логіку?

Хендлер на самом деле это таймер. Он читает сообщения с определенным статусом и пытается их обработать.

Як тільки Фісбук не забанили.

Даже Фейсбук не отправляет миллион имейлов в секунду. Аминь.

де по суті замість черги — СУБД

Кстате это вопрос на миллион баксов. Если посмотреть на скрины по всему интернету, где тебе должна прийти смс или имейл, везде есть кнопка «отправить повторно». Почему ? Потому что эти гавеные очереди нигде не работают. Везде лепят какуюто вундервафлю с кафкой, с упаковкой сообщений, распаковкой, возвратом в очередь если пришло не в том порядке и др. И всеравно, никто не может нормально собрать, чтобы 100% сообщений доходило до адрессата и вообще что делать с этой помойкой если она ушла в рассинхрон. Впрочем рассинхрон этой помойки это ее нормальное состояние и кнопка отправить повторно смс хорошее решение.
А теперь что я предлагаю. Да еще одна субд, которая железно всегда синкается и умеет восстановить свое состояние при сбоях. И твой код работает с локальной бд, его не интересует как что синкается. Ты не пишешь кучу кода для работы с очередями и не разворачиваешь эту вундервафлю с кафкой. Все работает как надо с копеечным кодингом и с первого раза.

Если посмотреть на скрины по всему интернету, где тебе должна прийти смс или имейл, везде есть кнопка «отправить повторно». Почему ?

Потому что у сообщений и мэйлов (которые в подавляющем большинстве случаев используются для разного рода верификаций) весьма ограниченный TTL, не? И если по каким-либо причинам клиент не смог его обработать в срок, оно уже expired и его необходимо перегенерить ?

Потому что эти гавеные очереди нигде не работают

== неасилил )))

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

Как эта СУБД выглядит с точки зрения CAP теоремы ?

весьма ограниченный TTL, не? И если по каким-либо причинам клиент не смог его обработать в срок, оно уже expired и его необходимо перегенерить

Это надо у разработчиков спрашивать. То что смс иногда не приходят по каким либо причинам и гдето теряются — факт. И кнопка повторно отправить есть почти у всех.

Как эта СУБД выглядит с точки зрения CAP теоремы ?

Выглядит как обычно. Кап теорема накладывает ограничения на все виды распределенных систем. Моя не исключение.

CAP теорема каже «при нетворк партішнінгу ваша дістріб’ютед система може бути або consistent, або available, але не те і те одночасно».

То ваша consistent чи available?

В зависимости от того как установишь Sync.Mode. Если ByVersion то это CP. Если ByView то это CA. Если ByAttr или OnDemand то это AP

Що таке CA? :D

CAP теорему не вчили, бачу.

Ще раз: CAP теорема каже «при нетворк партішнінгу ваша дістріб’ютед система може бути або consistent, або available, але не те і те одночасно».

В результаті можливі лише два класи систем Consistent (те що ви назвали CP) або Available (те що ви назвали AP). Немає ніякого CA.

Що таке CA? :D

CAP теорему не вчили, бачу.

Ще раз: CAP теорема каже «при нетворк партішнінгу ваша дістріб’ютед система може бути або consistent, або available, але не те і те одночасно».

В результаті можливі лише два класи систем Constitant (те що ви назвали CP) або Available (те що ви назвали AP). Немає ніякого CA.

1. Что такое «Constitant» ?
2. Если с CAP не сложилось, википедия в помощь.
С точки зрения теоремы CAP, распределённые системы в зависимости от пары практически поддерживаемых свойств из трёх возможных распадаются на три класса — CA, CP, AP.

Це що, російська вікіпедія? Сміхота!
Вони повторюють ті самі бздури що і ви. Подивіться в АНГЛІЙСЬКУ вікіпедію і побачите що там сказано ЗОВСІМ ІНШЕ

When a network partition failure happens, it must be decided whether to:
— cancel the operation and thus decrease the availability but ensure consistency or to
— proceed with the operation and thus provide availability but risk inconsistency.
Thus, if there is a network partition, one has to choose between consistency and availability

2 класи! Немає ніяких 3 класів! Не читайте совєцькіх газєт.

ШТА ?
www.ibm.com/cloud/learn/cap-theorem

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

Короче все. Скучно. Какаято епамовская пыль припылила этот топик.

Не прошел в епам, вот ты и бесишься :-)

Не прошел в епам, вот ты и бесишься :-)

Может быть и прошел. Если бы главный офис был не в химках
www.youtube.com/watch?v=2omIAdSzpGE

Ти сам то свою ссилку відкривав, дядя? Що там написано? Я за тебе читати маю?

Чорним по білому сказано: «So, while we can discuss a CA distributed database in theory, for all practical purposes, a CA distributed database can’t exist»

І далі описуються ДВА класи CP та AP.

Ти читав текст взагалі? Чи бездумно ссилку копіпастнув?

На відміну від тебе, я ці речі розумію на логічному а не «інтуітивному» рівні. І розуміти там багато не треба — CAP говорить distributed системи, в яких відповідно може бути network partitioning. І якщо він відбувається — ця система або відмовляє запитам, або оновлює лише дані в доступних репліках, тобто або Consistent або Available. Tertium non datum.

Стаття на сайті IBM-у теж біс зна ким писана, бо будь-яка повноцінна стаття про CAP про це і говорить (з тої ж англ вікіпедії починаючи). Але навіть на сайті IBM-у це сказано, хоч і якось через одне місце — що не може бути distributed систем які consistent та available при network partitioning-у. Ще раз цитую: «for all practical purposes, a CA distributed database can’t exist»

Прочитай следующее предложение.
However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.

Це бздура і автор просто бреше. Реляційні бази — поки вони реляційні а не недо-NoSQL з шардами — consistent. Хоча можна переконфігати і будуть available замість consistent (хоча тоді вже не ACID). Але немає такого класу CA.

І окремо про CP та AP дуже раджу почитати тут:
martin.kleppmann.com/...​g-databases-cp-or-ap.html

Це бздура і автор просто бреше. Реляційні бази — поки вони реляційні а не недо-NoSQL з шардами — consistent. Хоча можна переконфігати і будуть available замість consistent. Але немає такого класу CA.

Слив засчитан. Тоесть ты взял и вычеркнул все реляционные базы с их CA (которых между прочим большинство).

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

Короче учи мат часть.

доступной, но которая сразу ляжет

Available система яка «лягла» не є available!
Невже ти своїм «інтуїтивним» розумінням цього не розумієш?

Якщо настав network partitioning то твоя система або відповідає (але не апдейтить всі репліки — тому не консистент), або «лягла» (і тому останній стан constistent, але вона вже не available).

Ясно що поки немає нетворк партішнінгу то всі системи і консистент, і авейлебл, і все в них добре і прекрасно. Але нетворк партішнінг в дістріб’ютет системах відбувається, про що і мова в CAP! І вже тоді настає те, про що вона говорить — доводиться обирати між availablity і consistency.

Якщо система «лягла» то яка ж вона available? Ти смієшся чи що?

Знову ж, читай уважно тут:
martin.kleppmann.com/...​g-databases-cp-or-ap.html
«A lot of people have taken that advice to heart, describing their systems as „CP“ (consistent but not available under network partitions), „AP“ (available but not consistent under network partitions), or sometimes „CA“ (meaning „I still haven’t read Coda’s post from almost 5 years ago“).»

І по ссилці про «CA»
codahale.com/...​fice-partition-tolerance
«You cannot, however, choose both consistency and availability in a distributed system»

CA

вот правда, чего ж не понятно то челу :)

это просто один инстанс БД. Моно.
А если реплики, синки — то уже появляется P

Точно такая же история как в многопоточном приложении:
Если наложил мьютекс- то все потоки будут ждать когда отпустишь. то есть не available
Если НЕ наложил, то можешь получить не constistent

и выбрать можно только одно
или ты накладываешь, или не накладываешь
(та же история как недавно писал с синхронным и асинхронным
или ты ждешь ответа, или ты не ждешь.
одновременно ждать и не ждать — невозможно)

Есть lock free алгоритмы и штуки, но они решают только частные случаи, и вобщем-то — не решают проблемы, а уменьшают время «не available» до приемлимого, «незаметного»

это просто один инстанс БД. Моно

Це не дістрібютед система :D

Хоча насправді і тут буде трабла. Навіть якщо один інстанс але клієнт на іншій машині, система стає дістрібютед — і якщо той один інстанс нагнеться то клієнт отримає що база not available. Тому це CP, consistent але не available.

Якщо тільки клієнт і сервер бази на одному компі, і вони дохнуть одночасно — тоді тільки це consistent + available але не дистрибютед система.

Власне про це сказано тут: codahale.com/...​fice-partition-tolerance
«add remote clients to the monolithic Oracle server and you get a distributed system which can experience a network partition (e.g., the Oracle server becomes unavailable).»

Це не дістрібютед система :D

Ну да ж, так :)

P це ознака дістрібютед системи.
Прибрав P, тобто оставив CA — ну ок, прибрав дістрібютед :)

Хоча насправді і тут буде трабла

Так. deadlock — і усьо, А теж зникає :)

А виникає він тому що нам треба C, і не дуже вдало ми наклали очікування відповіді

Власне про це сказано

Та я ж те й кажу, не зрозуміло що незрозуміолого.
CAP така очевидна, як трохі маєш досвіду програмування...

это просто один инстанс БД. Моно.

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

Построить распределенную СА систему конечно можно. Но она не будет Partial Tolerance и будет чувствительна даже при потере одной ноды. Зато данные будут всегда доступными и всегда консистентными.

Осталось только разобраться что такое «Моно».

Разбирайтесь.
Вам же поясняют про CAP теорему, вы не врубаетесь

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

Если снаружи этого не видно, например Redis однопоточный, то это неважно, что там внутри. для CAP теоремы
Один инстанс — значит буквы P нет. Два инстанса — значит она есть. То есть либо моно, либо дистрибьютед

А потоки внутри одного инстанса да, тоже имеют вобщем-то те же проблемы что описываются CAP теоремой. Но чаще — законом Амдала

Построить распределенную СА систему конечно можно.

Невозможно. Потому что распределенная система будет иметь буковку P

Так же как невозможно написать однопоточно многопоточное приложение. Оно либо одно, либо много, а вместе — никак

Так что либо есть буква P либо ее нет
в СА ее нет. Значит речь о НЕ распределенной системе

распределенная CA это вид
круглого квадрата.
сухого мокрого.
и прочего абсурда

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

Ну просто нет доп инстансов нет проблем с репликацией, констистентонстью и прочим гемором, просто программисты тупые, напридумали чепухи... :-)

Available система яка «лягла» не є available!

Твоя логика меня просто поражает. А если все ноды лягли.
То ты не получишь не CP не AP не СА. Получается вообще ничего нельзя построить ? Не видишь тоже разночтений ?

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

Еще раз. Хватит выдумывать, заходишь на сайт айбиэм (они в этом чтото понимают) и читаешь.

www.ibm.com/cloud/learn/cap-theorem

However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.
А если все ноды лягли.

Яка імовірність такого?
А якщо не всі? От тут і постає distinction.

Суть CAP взагалі в network partitioning, тобто ноди навіть можуть не лежати — але не можуть одна до іншої достукатись.

Хоча коли лежать це теж partitioning.

Здесь А означает, что у тебя не будет скорей задержек на чтение данных

Latency це зовсім інша річ яку CAP НЕ розглядає. Для latency є PACELC.

ты будешь иметь и С и А, но только тогда, когда все части системы вместе и никакая нода не отпала.

ТАК ВСІ СИСТЕМИ ТАКІ! ВСІ СИСТЕМИ Є І CONSISTENT І AVAILABLE АЖ ПОКИ НЕ СТАНЕТЬСЯ NETWORK PARTITIONING!
Ну як не зрозуміло ж?

заходишь на сайт айбиэм (они в этом чтото понимают) и читаешь

І читаю, і тобі цитую:

So, while we can discuss a CA distributed database in theory, for all practical purposes, a CA distributed database can’t exist

Ще раз, CA DISTRIBUTED DATABASE CAN’T EXIST

Поразительная быстрота обучения юнита, от

В результаті можливі лише два класи систем Consistent (те що ви назвали CP) або Available (те що ви назвали AP). Немає ніякого CA.

До

ВСІ СИСТЕМИ Є І CONSISTENT І AVAILABLE АЖ ПОКИ НЕ СТАНЕТЬСЯ NETWORK PARTITIONING!

С Епама донат за обучение гребца

Зато з тебе доната не треба бо ти необучаємий і змісту слів не розумієш.

Всі системи є і consistent i available поки немає network partitioning — ТОМУ НЕМАЄ ТАКОГО КЛАСУ CA. Бо CAP говорить що network partitioning неминучий в distributed системах, і ВЖЕ КОЛИ ВІН СТАЄТЬСЯ тут з’являються відмінності, і відповідно класи consistent vs available.

Бо всі ци системи — які ви помилково називаєте CP та AP — вони всі є CA поки немає network partitioning!

Може так дійде: Множина CA включає CP та AP повністю. А вже множини CP та AP не пересікаються.

CA ∩ AP = AP.
CA ∩ CP = CP.
CP ∩ AP = Ø.

Дійшло, обучатєль юнітов?

Ще раз, CA DISTRIBUTED DATABASE CAN’T
EXIST

Юнита который плохо учится по википедии можно тролить бесконечно. Скажи, а если система была DISTRIBUTED и состояла из двух нод Node A и Node B. И вдруг Node B отключили на профилактику и все обязаности переложили на Node A.
Это все еще DISTRIBUTED система или нет ? Ведь она теперь стала Моно и СА.

Ведь она теперь стала Моно.

Она проектировалась для двух нод?
Значит она — дистрибьютед

А ее состояние работы

отключили на профилактику и все обязаности переложили на Node A.

временное, и не является ее характеристикой.

Вам бы разобраться с тождеством
дистрибьютед(распределенная)=P

перед тем как кого-то поучать

дистрибьютед(распределенная)=P

Как узок мир.
Ок. Вот тебе пример. У меня стоял один сервер MS SQL, он держал нагрузку допустим 1 тысячу запросов. Мне понадобилось держать нагрузку в 2 тысячи запросов на чтение. Я ставлю ровно такой же тазик в 30 см от первого, соединяю его прямым шнурком и оба живут на одном и томже безперебойнике.

Теперь, когда запрос идет к первому серверу. Сервер не только обновляет себя, но и обновляет соседа (реплицирует свои изменения ему) и только после этого отдает ответ клиенту. На лицо две буквы CA в распределенной системе где стоят два MS SQL тазика. Оба сервера Available. Оба сервера Consistency. Но система абсолютно не толерантна к потере одного из серверов.

Это не распределенная система ?
Она горизонтально не промасштабирована ?

Ця система не available бо якщо одна нода ляже інша не відповідатиме. Буде «CP».

Або — якщо наконфігати так що коли одна нода ляже то інша далі прийматиме апдейти, то між нодами вже не буде consistency і система буде «AP», available але не consistent.

Все ж елементарно просто і зрозуміло.

Ця система не available бо якщо одна нода ляже інша не відповідатиме. Буде «CP».

У тебя смешались люди-кони. За «ляже інша» отвечает Partial Tolerance. Тоесть насколько система устойчива к потере своей части. И она не устойчива. Но если ноды все на месте, все ноды и consistency и available.

При CP, если одна нода отпала, она уходит в ОФЛАЙН до тех пор пока не станет consistency и вместо этого ты теряешь свое available. Поскольку одна из нод теперь в офлайне и половина мира у тебя могло отвалится. Дошло наконец ?

Ти сам то перечитай свій набір слів.

За «ляже інша» отвечает Partial Tolerance

Як вона «атвічає»? Що за бздури?

Суть CAP в тому що network partitioning в дистрибутет системах неминучий. Його не можна позбутись!

Питання тільки що робить твоя система коли він настає.

Ти ж сам привів приклад — дві ноди, які реплікуються.

Знову ж, поки немає network partitioning в них все добре, consistency і availability ясно що є — у всіх є.

Але ще раз, суть CAP в тому що network partitioning в дистрибутет системах неминучий.

І коли він настає, скажімо відпадає одна нода з двох — тоді твоя система має або бути consistent і не відповідати на апдейти тобто не available, або бути available і приймати апдейти в одну ноду, які не попадають в іншу котра лежить, тому не бути consistent.

Щось одне з двох.

Що ще не ясно?

Суть CAP в тому що network partitioning в дистрибутет системах неминучий. Його не можна позбутись!

У меня только один вопрос. Почему P ты переводишь своей самодеятельностью. Не так как это сказано в книжках, Partition Tolerance. А какимто неизвестным network partitioning. Тоесть это конечно фейспалм, но тебе нужно начать с того, что перевести просто НОРМАЛЬНО эти три буквы и не заниматся самодеятельностью.

Еще раз цитата с айбиэм который ты не любишь

www.ibm.com/cloud/learn/cap-theorem

However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.

На этом я закругляюсь. Мое время стоит дороже.

По приведенной тобой же ссылке:

CA database: A CA database delivers consistency and availability across all nodes. It can’t do this if there is a partition between any two nodes in the system

Это невозможно сделать, если есть P между любыми двумя узлами в системе

Называется, ты сам то читал свои источники?

Мне уже стыдно, но сейчас Лысака будем учить английскому.

Поскольку речь о Partition Tolerance, то вестимо в контексте Partition можно перевести как РАЗДЕЛЕНИЕ, ПОТЕРЯ СВЯЗИ между частями системы. И весь абзаз переводится так

It can’t do this if there is a partition between any two nodes in the system

Вы не можете добиться (СА) если ваши любые две ноды потеряли связь в системе между собой.

However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.

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

Теперь и на тебя больше нет времени нет. Я закругляюсь.

Мне уже стыдно, но сейчас Лысака будем учить английскому.

Не стыдытесь, гений всех учит :D
Ему просто не везет — все ж тупые вокруг :)

Вы не можете добиться (СА) если ваши любые две ноды потеряли связь в системе между собой.

Если есть связь — она может быть потеряна

Никаких гарантий нет что — она не может быть потеряна

CAP теорема о том говорит

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

Означает что — не можете.
Отрывок о том.
и CAP теорема о том. О невозможности круглого квадрата.

Но вы гений, можете. Вперед :)

Много реляционных баз данных, как Постгрес, предоставляют consistency и availability и могут быть задеплоены на множество нод используя репликацию.

Их узлы в это время — не доступны

Поэтому и появились Кассандры и прочие. Которые жертвуют C ради А

У меня только один вопрос. Почему P ты переводишь своей самодеятельностью. Не так как это сказано в книжках, Partition Tolerance.

Відповідь давно наводив, вона тут: codahale.com/...​fice-partition-tolerance

Бложик автора такойже альтернативно одаренный как ты.
Даже в статье можно найти по тексту сноски.

(Update: I was wrong about this part. See this for more.)

Тоесть автор бложика такой запутавшийся танцор как ты.
И вы вдвоем, вместо того чтобы немного пораскинуть мозгами, прочитать нормальные источники, продолжаете упираться, а потом I was wrong about this part

А Dr. Brewer approves не читав? А це автор CAP на секунду :D

А що Dr. Stonebraker does not approve, там є питання до нього:
„That said, Dr. Stonebraker’s assertion that ‚surviving [partitions] will not ‘move the needle’ on availability because higher frequency events will cause global outages’ is wrong. Multi-node failures may be rarer than single-node failures, but they are still common enough to have serious effects on business.”

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

А, ну так, автор чергового болгенОС буде обговорювати CAP теорему лише з її автором — а ми всі смєрди і «нє панімаєм гєнія». Останній прихисток людини, яка не шарить.

А яку інформацію «усваювати»? Що твій болгенОС тобто супер СУБД кращий за все на світі бо «я так сказав»? LOL, повеселив.

В тон відповім: от справку від Брювера принесеш що так і є — тоді поговорим. «А пака скріпач ні нужин».

а ми всі смєрди

Так ты и есть епамовский смердь. Который никогда не писал ничего близкого к субд, распределенных движков и тд. И ты споришь с человеком который имеет как минимум 20 лет общего и 15 лет в конкретной области опыта работы. Который свой карьерный путь начинал с написания ЯП уже будучи джуном на курсах. На что ты вообще расчитываешь ?
Мне просто уже надоело тебя бить по рукам. То ты какойто бложик притянишь, Update: I was wrong about this part. See this for more.). То какая то феерическая чушь что СА не существует. То ты не можешь нормально абревиатуру перевести с P. То с английским у вас проблемы. То ты вытянул какойто дискас на форуме, вместо того чтобы почитать определения. Какого вообще хрена ? Люди претендуют быть хирургами не имея там никакого опыта, даже из неудачных проектов и чтото мне доказывают ? Свободен.

20 років займався хто зна чим, а CAP теорему не освоїв. Зато точно знаєш хто є смєрд.

Зрозуміло.

However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.

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

Коротше вмовив — ідем читати не IBM і не бложики — ідем читати лише Брювера, самого автора CAP теореми.

І що він пише?

А от що
www.infoq.com/...​w-the-rules-have-changed

„Why ‚2 of 3’ is missleading

The easiest way to understand CAP is to think of two nodes on opposite sides of a partition. Allowing at least one node to update state will cause the nodes to become inconsistent, thus forfeiting C. Likewise, if the choice is to preserve consistency, one side of the partition must act as if it is unavailable, thus forfeiting A. Only when nodes communicate is it possible to preserve both consistency and availability, thereby forfeiting P. The general belief is that for wide-area systems, designers cannot forfeit P and therefore have a difficult choice between C and A.”

Ты мне уже надоел. Покажи там четко цитату, где он говорит что СА не существует в распределенных системах. Как ты это утверждаешь уже двадцатое сообщение.

„Does choosing consistency and availability (CA) as the ‚2 of 3’ make sense? As some researchers correctly point out, exactly what it means to forfeit P is unclear.11,12 Can a designer choose not to have partitions? If the choice is CA, and then there is a partition, the choice must revert to C or A. It is best to think about this probabilistically: choosing CA should mean that the probability of a partition is far less than that of other systemic failures, such as disasters or multiple simultaneous faults.”

www.infoq.com/...​w-the-rules-have-changed

Тобто вибір CA це тільки якщо ймовірність що partition відбудеться куди менша ніж імовірність інших проблем — закрили очі „не бачу тому не існує”. А по факти „If the choice is CA, and then there is a partition, the choice must revert to C or A”

Must. Без варіантів.

Автор тексту — сам Брювер.

Ще питання?

Тобто вибір CA це тільки якщо ймовірність що partition відбудеться куди менша ніж імовірність інших
проблем

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

Немає ніякого CA.

И такойже альтернативно одаренный Лысак утверждал что «CA возможно только в Моно»

Наконец до вас дошло, то что я писал первыми постами.

Ти сліпий? Бо чітко Брювером сказано що його насправді немає — бо якщо ти «обрав CA» то все одно при настанні нетворк партішнінгу ти мусиш обирати між C та А.

Вище ж цитата.

Ну мне что с вами опять английский учить ?

If the choice is CA, and then there is a partition, the choice must revert to C or A.

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

Тобто вибір CA це тільки якщо ймовірність що partition відбудеться куди менша ніж імовірність інших
проблем

Если вероятность маленькая с Р, то ты им жертвуешь и получаешь свое СА. Вроде же все просто.

Так це не CA а взагалі CAP клас виходить — нема партішнінгу немає проблем. А що означає «пожертвувати Р»? Уявити собі що нетворк партішнінга не станеться і на голому оптимізмі всім розказувати що в нас все ідеально? Глубіна глубін паніманія :D

Так це не CA а взагалі CAP клас
виходить

Опять логика на высоте. Это не CAP поскольку система не Partition Tolerance.

С таким успехом можно сказать что CP и AP это тоже полная САP. Просто в одном случае нужно ничего не писать, а во втором случае ничего не читать.

на голому оптимізмі

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

Чем плохая архитектура ?

Это не CAP поскольку система не Partition Tolerance

Tolerant якщо ти вже за англійську вимахуєшся.

А тепер поясни, в чому різниця між цією CA і CP наприклад?
Якщо немає нетворк партішнінгу вони всі consistent і available — це вже уяснили.

А тепер появляється network partitioning. І все — ні та ні та не available, але обидві consistent.

Немає різниці. Значить немає такого окремого класу CA.

У меня стоит два сервера, один от другого на расстоянии 30 см

Ну нагнувся хард в одного, або ОС в апдейт пішла, або просто своп який закінчився — і він ліг. Все.

Розказувати потім будеш про аптайм свій, але система твоя отримає network partitioning так чи інакше бо це distributed система.

хостится сайт, которому позволительно допустим раз в 3 года перейти и поработать на одной ноде вместо двух, пока другую чинят

Так друга нода буде не consistent. Нічого поганого — це «AP» система (BASE точніше).

А тепер появляється network partitioning. І все — ні та ні та не available, але обидві consistent.

Ты все опять напутал, перевернул с ног на голову.
Твой network partitioning означает проблемы сети.
Это означает что Нода А живая и доступная и Нода Б живая и доступная для клиентов, но каждая нода теперь живет своей жизнью. Теперь они обе, не консистентны между собой, но обе доступны с своей версией данных для клиентов. это твой АP.

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

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

Я не буду коментувати решту ноненсу, просто жирним підкреслю

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

ТА ВСІ СИСТЕМИ Є І CONSISTENT I AVAILABLE «пока у них нет проблем с связью между собой». Всі!

Ну скільки можна товкти!

P.S. Окремо поржав над «всегда. Но до тех пор»

ТА ВСІ СИСТЕМИ Є І CONSISTENT I AVAILABLE «пока у них нет проблем с связью между собой». Всі!

Ну блин, если нет и быть не может проблем с связью, то ясен хрен что ты забираешь Р из САР и остается СА.

Если проблемы есть. То ты жервтуешь или С или А. Или ноды все доступны но рассинхронизировались. Или они синхронны, но посылает всех клиентов нафиг чтобы не уйти в рассинхрон, доступны только на чтение.

Что тут не понятного ?

нет и быть не может проблем с связью

Так в тому то і справа що в реальних а не вигаданих системах воно завжди «может».

І в не distributed системі теж, тільки тоді це називається single point of failure.

Пів дня це товчем.

P.P.S. Я зрозумів схему.
CP — консистент коли нетворк партішнінг настає.
AP — авайлебл коли нетворк партішнінг настає.
CA — нетворк партішнінг не настає, бо я так сказав :D

Справді «миші — станьте їжаками», або система «страус» — якщо нетворк партішн то голову в пісок.

CA — нетворк партішнінг не настає, бо я так сказав :D

Тебе уже писали. Что так построено 90% систем. Бекап субд и вся гарантия что данные не пропали. А серверов может быть и 10 в кластере. Репликация штука не хитрая.

А тепер поясни, в чому різниця між цією CA і CP
наприклад?

Разница в том что СА работает так как будто она «моно», нигде ничего не сбоит ноды всегда доступны. И механизмов выравнивания данных в разных нодах там вообще может не быть. Например Нода А слушает очередь и Нода Б слушает очередь и обе из этой очереди пишут себе сообщения. Это чистая СА.
CP система расчитана что она может себя както чинить после рассинхрона. И на время уходит в офлайн. Потому что она P. Тоесть если это опять две ноды которые читают очередь, то это как минимум плюс оркестратор для восстановления консистенси. И на это время нода будет не доступна. Вот и вся разница.

нигде ничего не сбоит ноды всегда доступны

Бо ти так сказав.
Але в реальності ноди падають.
Невже не зрозуміло?

А ты не видишь здесь трейдофф, где СА намного проще в реализации (и чаще всего реализовуют именно так не заморачиваясь) чем CP с оркестратором ?

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

Оба сервера подключены к интернету? Если да, то что произойдет, если при обслуживании какого-то оборудования кто-то случайно вытянет 30-сантиметровый шнурок, которым серверы соединяются?

А що означає "пожертвувати Р«

А это «мыши станьте ежами», вид сбоку.

Если вероятность маленькая с Р, то ты им жертвуешь и получаешь свое СА. Вроде же все просто.

Хмм, «а давайте пожертвуем network partition и обойдемся без». Сцуко, это же гениально — как это никто раньше не догадался? :) Мыши станьте ежами.

А так-то конечно «это какой-то... позор». Штирлиц никогда еще не был так близок к провалу.

Хмм, «а давайте пожертвуем network partition и обойдемся без него». Сцуко, это же гениально — как это никто раньше не догадался? :) Мыши станьте ежами.

А так-то конечно «это какой-то... позор». Штирлиц никогда еще не был так близок к провалу.

Для тебя будет сейчас шок. Но наверно 80% серверов в мире работают по принципу СА. Это самый распространенный шаблон. Или сервер + бекап базы данных. Или два сервера + тотже бекап базы данных. Причем я не говорю что у меня не возможен CP, AP, просто СА тоже возможен, как самый простой шаблон.

Па а дэ море!? Как в анекдоте :-)

Как узок мир.

ничего не попишешь
такие термины и их обозначения

То что вы их не понимаете, а потому уверены что живете в другом мире — ну то такое.

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

Вот тебе пример.

Разберитесь с тождеством P=дистрибьютед

Оно является обобщением и вашего примера, и тьмы других

но и обновляет соседа (реплицирует свои изменения ему)

в это время — запросы обрабатываются? значит A. Но информация еще не обновилась, то есть не стала одинаковой на всех нодах — значит «не C»
запросы не обрабатываются во время репликации? Значит «не A»

О том CAP теорема — вы не можете гарантировать при P одновременные C и A

Она горизонтально не промасштабирована ?

Разберитесь с тождеством P=дистрибьютед

Но информация еще не обновилась, то есть не стала одинаковой на всех нодах — значит «не C»

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

И в моем примере consistency конечно есть.

в твоем примере:

Оба сервера Consistency.

и в случае когда запрос приходит на второй сервер, а первый его, второй еще не обновил?

Если же ВСЕ запросы всегда встречает только первый сервер, то снаружи это — не дистрибьютед система.
Хоть сколько там серверов не наставь
у тебя один сервер отвечает на все запросы

поэтому

И в моем примере consistency конечно есть.

в твоем примере либо нет consistency, либо нет дистрибьютед

а не понимаешь ты этого, потому что не понимаешь о чем CAP теорема

а выдумал свой какой-то словарь терминов.

Но компьютеры у тебя — те же, и проблемы на них значит тоже — те же.

и в случае когда запрос приходит на второй сервер, а первый его, второй еще не обновил?

Я там специально написал, что сервер не отвечает клиенту до тех пор, пока не переведет соседнюю ноду в тоже состояние. Consistency сохраняется.

в твоем примере либо нет consistency, либо нет дистрибьютед

Есть и консистенси (обе ноды одинаковы) и есть дистрибютед (к обоим нодам можно обращаться из вне). Но система не устойчива к потере своей ноды.

Я там специально написал

я уже привел выше отрывок из статьи на ibm

пока не переведет соседнюю ноду в тоже состояние

означает отсутствие A в это время. Обновляемая нода — не отвечает в это время на входящие запросы

Есть и консистенси (обе ноды одинаковы) и есть дистрибютед (к обоим нодам можно обращаться из вне).

Но нет A, потому что ты же и написал:

не отвечает клиенту до тех пор, пока

то есть она — недоступна
а реплика может накатываться — часами. мало ли какой сплит был перед этим

Я там специально написал, что сервер не отвечает клиенту до тех пор, пока не переведет соседнюю ноду в тоже состояние. Consistency сохраняется.

Ты похоже реально не понимаешь что такое полноценная distributed система.

По-простому — у тебя есть система из произвольного количества нод, каждая из которых должна обслуживать запросы любого типа (read/write/delete) в любоймомент времени

И чтобы адресовать проблемы таких систем (затюнить баланс между C и A) — на арене появляются consistency level-ы, quorum-ы и прочие глупости

Ты похоже реально не понимаешь что такое полноценная distributed система.

Что такое полноценная.
Начни с того, какие из двух букв в CAP ты решил оставить. И что вообще за апликейшин ты строишь.

Без этого «ваши леса не самые лесистые» выглядит не очень.

какие из двух букв в CAP

Тебе термин

consistency level

Что-то говорит в принципе?

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

везде идут компромиссы и задержки по синхронизации

Это производное.
А смысл в том, что продвинутые движки позволяют ступенчато подстраивать баланс между С и A, в зависимости от специфических требований софта, который их использует. Твои чудо-БД-c-диффами так умеют?

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

Могу тебе предложить три сценария на подумать

1. strong consistency — клиент коннектится к любой из нод и получает полность консистентные данные в строгом порядке выполнения операций
2 bounded consistency — гарантируется, что клиент получает консистентные данные в строгом порядке с опозданием не более чем X тайм-юнитов или Y-операций (конфигурируется)
3 weak / eventual consistency — consistency и порядок в общем случае не гарантируются

У тебя есть три ноды, и клиенты могут коннектиться к любой из них. Плюс вероятные проблемы с доступностью

P.S. На самом деле уровней обычно побольше, но они вендор-специфик

Если честно, не понял только как реализовать это

3 weak / eventual consistency — consistency и порядок в общем случае не гарантируются

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

С остальными два, вроде должно быть все Ок.

1. strong consistency — клиент коннектится к любой из нод и получает полность консистентные данные в строгом порядке выполнения операций

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

2 bounded consistency — гарантируется, что клиент получает консистентные данные в строгом порядке с опозданием не более чем X тайм-юнитов или Y-операций (конфигурируется)

А здесь уровень обеспечивается ByTime/BySize. Тоесть синк между нодами происходит не сразу, а по таймауту, который можно задать в конфиге.

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

У тебя приходит два апдейта на две ноды одновременно. (два таксиста одновременно нажали «мой заказ», лоад-балансер раскидал по разным нодам). Кто кому пропагейтит?

А здесь уровень обеспечивается ByTime. Тоесть синк между нодами происходит не сразу, а по таймауту, который можно задать в конфиге.

Это не совсем то.
Смысл — что ты выставляешь например 15 секунд, и в любой момент времени у тебя гаранировано консистентые данные на now()-15сек. Более новые данные могут быть, а могут не быть консистентыми — это не гарантируется.Т.е. у тебя непрерывное sliding window. При этом, естественно, ресурсов должно потребляться меньше чем в strong случае.

У тебя приходит два апдейта на две ноды одновременно. (два таксиста одновременно нажали «мой заказ», лоад-балансер раскидал по разным нодам). Кто кому
пропагейтит?

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

Это не совсем то.
Смысл — что ты выставляешь например 15 секунд, и в любой момент времени у тебя гаранировано консистентые данные на now()-15сек. Более новые данные могут быть, а могут не быть консистентыми — это не гарантируется.Т.е. у тебя непрерывное sliding window. При этом, естественно, ресурсов должно потребляться меньше чем в strong случае.

Да. Оно так работает. Цель, уменьшить трафик и переключения контекста на обноления, ресурсов жрать будет меньше.

в цепочку изменений мастера.

Что такое мастер? Как определяется мастер?

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

Несомненно. У теба атрибут «баланс» банковского счета 5000. И есть конфликт 1000 (после покупки) и 10000 (после пополнения).
Простой overwrite одним из значений самое оно.

Что такое мастер? Как определяется мастер?

Master это source of true. Слейв может пытаться пропагейтить свои изменения на Мастер, но за Мастером остается право резолвить конфликты и определять, можно принимать историю изменений от слейва или нет.

Несомненно. У теба атрибут «баланс» банковского счета 5000. И есть конфликт 1000 (после покупки) и 10000 (после пополнения).
Простой overwrite одним из значений самое оно.

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

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

Master это source of true

То есть у нас четко централизованная система. Реально распределенной тут и не пахнет. Пьяный экскаваторщик рвет оптику в датацентр где распложен мастер — что происходит дальше?

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

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

То есть у нас четко централизованная система. Реально распределенной тут и не пахнет. Пьяный экскаваторщик рвет оптику в датацентр где распложен мастер — что происходит дальше?

Также как и везде. Если мастер не доступен (коммандира ранили) его роль выполняет первый заместитель (слейв). Как только клмандира вылечили, заместитель передает ему последние дела. А ты хотел строить все как мать анархия ?

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

Для этого одна из стратегий резолва конфликтов это суммирование.

мать анархия ?

Понятно. Похоже, о такой базовой вещи как
en.wikipedia.org/...​m_(distributed_computing
ты не слышал

Для этого одна из стратегий резолва конфликтов это суммирование.

Продолжая пример — у тебя банковский счет с овердрафтом — ты можешь уйти в минус, но платишь за это штраф. Т.е последовательности операций
100 (-200 ; здесь штраф) -> −100 (+500) -> 400
100 (+500) -> 600 (-200) -> 400
не тождественны, хотя сумма одинакова

Понятно. О таких базовых вещах как
en.wikipedia.org/...​m_(distributed_computing
мы не слышали.

О каких базовых вещах ? Что в твоем случае Source Of True ? Как резолвишь конфликты если у тебя два капитана в одной посудной лавке каждый наколбасил свою личную историю ? Кто выполняет роль оркестратора ?

Продолжая пример — у тебя банковский счет с овердрафтом — ты можешь уйти в минус, но платишь за это штраф. Т.е последовательности операций
100 (-200 ; здесь штраф) -> —100 (+500) -> 400
100 (+500) -> 600 (-200) -> 400
не тождественны, хотя сумма одинакова

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

О каких базовых вещах ? Что в твоем случае Source Of True ? Как резолвишь конфликты если у тебя два капитана в одной посудной лавке ? Кто выполняет роль оркестратора ?

Добро пожаловать в дивный новый мир computer science
Думаю тебя там еще ждет много открытий ))
Например:
en.wikipedia.org/...​/Paxos_(computer_science

Сенситив данные ты транзакционно (атомарно) меняешь, запросом на сервре

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

Добро пожаловать в дивный новый мир computer science
Например:
en.wikipedia.org/...​/Paxos_(computer_science

И зачем мне это надо ? Я не пишу децентрализованные сети.
Самая простая репликация которая покрывает все кейсы это Мастер — Слейв. Слейв может быть репликой Мастера. Может быть подмножеством Мастера. Может быть временно выполняющим обязанности Мастера. Всё.

Напиши кейс где это не будет работать. В каком приложении.

Напиши кейс где это не будет работать. В каком приложении.

Ты можешь писать напрямую на любой слейв? да/нет

Ты можешь писать напрямую на любой слейв? да/нет

Могу писать. И он потом будет синкаться с мастером с анализом конфликтов.

Напиши кейс где это не будет работать. В каком приложении.

В хуллиарде кейсов это не будет работать — при адовом объеме операций записи, при необходимости гарантировать HA, при необходимости обеспечить минимальный латенси для клиентов по всему шарику (то есть писать нужно в локальные ноды с минимальным пингом, а не в один мастер за тридевять земель) и т.п. Понятно, что львиная доля проектов до этого состояния/масштаба/юскейсов никогда не дорастает, но сам факт того что ты похоже _вообще_ не слышал о leaderless моделях очень знаешь ли доставляет учитывая расставленные веером пальцы.

_вообще_ не слышал о leaderless моделях очень знаешь

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

Причем мержится все на уровне отдельных атрибутов максимально гранулярно.

Когда гит научиться автоматически и корретно разруливать все возможные случаи мердж-конфликтов в 99.999999% случаев, тогда и

можешь построить глобальную платежную систему и ничто ни счем не будет конфликтовать
Когда гит научиться автоматически и корретно разруливать все возможные случаи мердж-конфликтов в 99.999999% случаев, тогда и

Он это делает автоматически и корректно, если это не противоречит конечно мат аппарату. Никакого космоса нет слить две истории изменений, если есть все хронологические метки что за чем идет.

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

Он это делает автоматически и корректно, если это не противоречит конечно мат аппарату

И правда, что это я гоню

-strategy-option ours

cамая простая репликация которая покрывает все кейсы

Ну ты смешон. Ты или приводишь кейсы которые не имеют математического решения. Или возвращаешся в те кейсы, которые решает легко гит. Не существует волшебства. Если у тебя будет даже в твоей распределенной вундервафле пакксов два атрибута с одинаковой временной меткой (версией) и с разными значениями. Что ты будешь делать в своем паксос лидерлесс ? Как ты их смержишь без конфликтов ?

Он это делает автоматически и корректно

Бля, ты походу совсем из реальности выпал.

Тоесть история изменений заливается в другую историю изменений, в хронологическом порядке ?

А что считается временем изменения? Время его прилета на мастер ноду? Так более старое может прилететь последним. Время на клиентах? Так оно у них может быть (и будет) рассогласовано в хлам...

Да, я не ошибся. Это говноблокчейн

Paxos is a regulated blockchain infrastructure platform, building a new, open financial system.

Официально заявляю. На моей платформе блокчейна не будет !

Да, я не ошибся. Это говноблокчейн

Нит
Пардон была битая ссылка, случайно убрал скобку
Вот корректная
en.wikipedia.org/...​/Paxos_(computer_science

Я тебе написал возможные схемы репликаций данных.
Распределенных транзакций в децентрализованных сетях — нет.
И не предвидится. Ввиду узкой специализации.

Распределенных транзакций в децентрализованных сетях — нет.
И не предвидится. Ввиду узкой специализации.

(я не сталкивался || я не знаю) != нет и не предвидится, совсем.

я не сталкивался != нет, совсем.

Действительно не сталкивался. Знаю что в тех же процессинговых сетях, информация о балансе карт может лежать в очень простой субд с высокой доступностью. А всякая инфа о самой карточке, о ее владельце и счетах, в субд которая меняется реже — раз в день или несколько часов. Итого это стандратное решение. Есть процессинговая Key/Value которая все что делает вычитает балансы и блокирует суммы на карте. А есть другая тяжелая база, которая обновляется не так быстро.
И все это работает в масштабах страны. Городить какойто космолет по децентрализации .... ну можешь писать свою реализацию. Я не вижу в ней смысла.

ну можешь писать свою реализацию

Я не сторонник велосипедов. Реализаций же есть и в достаточном количестве.
Начиная от уже почти классики
en.wikipedia.org/wiki/Apache_Cassandra
и далее к например
azure.microsoft.com/...​vices/cosmos-db/#overview

Я не сторонник велосипедов. Реализаций же есть и в достаточном количестве.
Начиная от уже почти классики
en.wikipedia.org/wiki/Apache_Cassandra
и далее к например
azure.microsoft.com/...​vices/cosmos-db/#overview

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

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

Еще раз убеждаюсь в твоем непонимании реального мира.
Сама по себе базовая функциональность

мессенджер с офлайновой базой

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

за сутки

если добавлять работу с контактами, поиски, обмен фоточками и т.п.

хотябы за неделю

То что ты так не можешь, говорит только и только об этом.

Основная трудоемкость тут — имплементация кастомных протоколов (Skype), или специфичного шифрования (Telegram), или много интеграционной работы (MS Teams), совсем не в том чтобы склепать три простых скрина и прицепить БД.

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

А не имплентация какихто мифических протоколов. Протоколы там достаточно простые, в некоторых случаях просто xml гоняют как в аське. А вот все остальное — ой.

если пакет пропал,

На каком уровне? Ты пишешь свой транспорт вместо TCP?

Архивация данных, история сообщений и тд.

Абсолютно тривиальные задачи.

А не имплентация какихто мифических протоколов. Протоколы там достаточно простые

Повторюсь еще раз — если ты чего-то не знаешь, это не значит что это просто.
en.wikipedia.org/wiki/Skype_protocol
Не уверен как на сейчас, но до 13 года был очень и очень нетривиален.
Вот когда напишешь свой децентрализованный peer-to-peer, тогда и будешь так говорить

Асинхронное оповещение

Открой для себя в 22 году старый добрый websocket что ли, для простейшей имплементации

На каком уровне? Ты пишешь свой транспорт вместо TCP?

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

Абсолютно тривиальные задачи.

Ну конечно. В КосмосДБ и Кассандре твоей любимой, там прямо из коробки. Разворачиваешь на моб устройстве вместе с архивацией и шифрованием сообщений.

Повторюсь еще раз — если ты чего-то не знаешь, это не значит что это просто.
en.wikipedia.org/wiki/Skype_protocol
Не уверен как на сейчас, но до 13 года был очень и очень нетривиален.

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

Открой для себя в 22 году старый добрый websocket что ли, для простейшей имплементации

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

Что значит на каком уровне.

Продолжаем открывать для тебя основы Computer Science:
en.wikipedia.org/wiki/OSI_model

всю глубину глубин проблем синхронизации данных.

О да. Основная проблема в реализации любого мессенджера это синхронизация лога чятика, несомненно. А

когда чел сидит одновременно в веб, моб и десктоп клиенте.

это вообще задача для God mode

Уровень твоей экспертизы поражает.
Только один вопрос. Что будет делать твой мессенджер если юзер отлогинился и залогинился под новым существующи пользователем.

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

Что будет делать твой мессенджер если юзер отлогинился и залогинился под новым существующи пользователем.

Что именно в этом процессе вызывает такое смущение?

Что и какие технологии ты будешь использовать

Зависит от назначения мессенджера, его киллер-фич, платформ(ы) для которых(-ой) он предназначается. Подход «если у меня есть молоток, то все вокруг гвозди» очень глуп, знаешь ли

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

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

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

Ты как раз идеально следуешь путем даже не джуна, а трэйни.

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

Я не зря попросил уточнить

назначения мессенджера, его киллер-фич, платформ(ы) для которых(-ой) он предназначается

Например:
1) Мы делаем snapchat-like мессенджер. База данных не нужна в принципе, так как сообщения короткоживущие в пределах сессии пользователя

2) Мы делаем что-то только под Android, например VIber2+ disclaimer: я не специалист в Android разработке, могу ошибаться, но судя по user experience — для использования другого аккаунта в мессенджере тебе необходимо/достаточно использовать другой профайл юзера в OS. Вопрос

дропнуть всю базу или ее гдето забекапить.

 в этом случае неактуален в принципе

3) Аналогично для Win — например, у тебя корпоративный мессенджер и профайл в мессенджере завязан на профайл пользователя OS (MS Teams). Вопрос

дропнуть всю базу или ее гдето забекапить.

 в этом случае неактуален в принципе

4) У тебя изначально нет локальной копии данных (например, из-за требований к security). Или у тебя используется физический ключ для шифрования данных

5) ... еще 100500 вариантов использования и требований

Но ты все сводишь к древнему как говно мамонта

месенджере типа аська.

Убогий клон которого никому не интересен в 2022 году

И думаешь что тривиальные вещи

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

будут вызывать какие-то затруднения

С снапчатом понятно. Потомучто он подоходит под уровень джуна. Не хранит историю. Еще есть классный мессенджер Yo. Он еще круче снапа. Для трейни.

для использования другого аккаунта в мессенджере тебе необходимо/достаточно использовать другой профайл юзера в OS

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

Изобретаешь велосипеды

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

Ты бы к врачу сходил, правда.

Сегодня в 9-00 утра я тебе ставил планку в 70 бесмысленных сообщений чтобы апать тему. Ты выдал на гора всего 15-20.
Я не доволен. Чтобы завтра исправился.

В 9 утра ты похмелилися и пошло поехало по новой :-)

О каких базовых вещах ? Что в твоем случае Source Of True ? Как резолвишь конфликты если у тебя два капитана в одной посудной лавке каждый наколбасил свою личную историю ? Кто выполняет роль оркестратора ?

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

Ты совсем в глаза долбишься?

CA database: A CA database delivers consistency and availability across all nodes. It can’t do this if there is a partition between any two nodes in the system, however, and therefore can’t deliver fault tolerance.
We listed this type last for a reason—in a distributed system, partitions can’t be avoided. So, while we can discuss a CA distributed database in theory, for all practical purposes, a CA distributed database can’t exist.

Твоя же ссылка. CA — это обычная база без партиций и распределенности.

Хоть ты еще не позорься.

However, this doesn’t mean you can’t have a CA database for your distributed application if you need one. Many relational databases, such as PostgreSQL, deliver consistency and availability and can be deployed to multiple nodes using replication.

Ну бля. Тебя ж уже ниже носом потыкали, не заставляй копипастить чужие посты.

Скажи, ты тупой ? Учим еще тебя английскому

dou.ua/...​rums/topic/36344/#2343057

Та ему уже весь день копипастят и переводят и разжовывают, все бестолку :-)

Після Кафки

Я так понял автор не знал о кафке.

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

Чувак, Кафка уже написана, ты опоздал.

Что там что там получается асинхронная многопоточная лапша которая живет своей жизнью и хрен это все нормально отладишь.

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

Ну просто в голс! И мессджинг тупик и базы данных как отдельный инстанс тоже тупик! Весь айти мир в тупикэ и только гениальный бубен, который решил положить бизнес логику и данные в кучу, а саму кучу в оперативу, решает все проблемы айти!
Ну просто ппц :-))))

решает все проблемы айти

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

Ты даже очевидные и базовые вещи САР не можешь понять, куда тебе там что-то решать :-))

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

Весь айти мир в тупикэ и только гениальный бубен, который решил положить бизнес логику и данные в кучу, а саму кучу в оперативу, решает все проблемы айти!
Ну просто ппц :-))))

Он просто положил на форуме кучу :-)

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

Странно, истерика вроде как у меня: а бомбит тебя :-)
Давай свой фб :-) Самое время у них спад юзеров и акции обвалились ;-)

Очередей нет. Это тупик эволюции.

Га га га

проблема с порядком прихода сообщений

Так и скажи — слооожнаа, я не осилил, а до реализации акноледжа вообще не дополз, поэтому объявил очереди ересью.

Так и скажи — слооожнаа, я не осилил, а до реализации акноледжа вообще не дополз, поэтому объявил очереди ересью.

Я действительно синк до сих пор до конца еще не осилил. Мне намного проще было научить базу в транзакции и секурити чем нормально в синк, который я до сих пор допиливаю. Так вот. Любая очередь (кафка) это кривой велосипед с кучей нерешенных проблем (порядок сообщений, гарантия доставки, восстановление после сбоя и тд тп). Подумай как бы тебе помогла твоя очередь, написать банальный Мессенджер. Только нормальный, чтобы сообщения не терялись, инит синк, хелз чек и вот это вот все. Как отойдешь от ужаса, начнешь думать о нормальных зрелых системах, которые синкаются дифами и а не очередями.

Bootsrap 5 и Vue в помощь.

Вдохновение для работы можете присмотреть у :
Кваркли, Адало, ФлаттерФлоу, Тханкабл....

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

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

Итак:
1. Чтобы добавить фильтр в свой апликейшин, нужно сделать всего 2 клика мышки
2. Фильтр фильтрует значения в гриде
3. Фильтр прекрасно сочетается с пейджингом. Если фильтранул грид и там все еще 100500 записей, пейджируешь результаты после фильтрации
4. Фильтр фильтрует с учетом контента вложенных форм. Например если в гриде строка искомое значение не содержит, но содержит какая-либо вложенная (!) сущность, которая стоит за этой строкой в гриде, то строка показывается в гриде после фильтрации.
5. Фильтр фильтрует также контролы (!!) на форме. Например я открыл форму, а там 100 контролов и мне лень глазами искать. Я забиваю свое значение и все что на форме что хоть както связано с этим фильтруемым значением показывается.
6. Фильтр работает моментально, страница перегружается за миллисекунды.
7. Фильтр работает по правилам полнотекстового поиска. Можно указывать шаблоны для поиска и тд.

Пример как это сделано в джира гриде
www.youtube.com/watch?v=Y1sRzwvB1pw

Фильтр фильтрует также контролы (!!) на форме. Например я открыл форму, а там 100 контролов и мне лень глазами искать. Я забиваю свое значение и все что на форме что хоть както связано с этим фильтруемым значением показывается.

Меткий выстрел в ногу пользователям.

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

chrome://settings/?search=cookies

Такі фільтри є багато де — навскидку, з того, з чим стикаюсь: Google Docs/Sheets, Sublime Text (там взагалі всі сетінги — один сплошний фільтр), cPanel/WHM, NetSuite

Фильтры есть много где. Но вот прямо чтобы были 7 пунктов что я написал выше, такое редко.
Ну и почему нет тоже понятно. За кадром обычно реляционка. А чтобы по ней искать, по всем колонкам, названиям колонок и значениям во всех таблицах, это надо чтото особое городить. И отдельная песня с фронтом. Показывать/скрывать контролы в зависимости от фильтра тоже нужно извратится. Обычно везде шаблоны страниц со всеми контролами гвоздями прибиты

Чего это ?

Потому что интерфейс приложения не должен меняться по велению левой пятки — это рушит воркфлоу пользователей. Де-факто чуть ли не единственный кейс где такое допустимо — это как раз «настройки хрома» (собственно такое не только хром умеет), которые по сути просто безразмерные полотенца key/value и там как раз такое и нужно, потому что иначе никак. То что твое решение умеет такое из коробки — это прикольно, но это не должно быть дефолтным поведением имхо.

Какую базу данных используете?

Ну что ребята, не дня без нового проекта !
Еще никогда не было так просто и быстро создавать новые апликейшины. Особенно полезные.
Предистория. Вчера мелкий не хотел учить таблицу умножения. Пришла интересная мыль, что он может сам написать тренажер для изучения таблицы умножения. Там всего то нужно сконфигурить два джисона. Но решил всетаки написать чуть больше функционала, перед началом тренировки можно задать с какой по какую цифру учим, перемешивать ли формулы. Вообщем 20 минут личного времени и до 100 тривиальных строчек кода и тренажер готов.

www.youtube.com/watch?v=Vq0rGswDr0M

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

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

Бабла заработаете куда больше чем на свих поделках :-)

ЗЫ Идея бесплатна, можете «воровать» :-)

Я там вверху тренажер написал. Напиши мне, если хочешь немного потренироваться и поумнеть =)

Не не не, ты с Кузьмичем давай, так не интересно, денег не дам :-))

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

Есть такое уже: www.meteor.com

СУБД на клиенте, которая синхронизируется с back-end СУБД. Тоже в 2 клика можешь добавить компонент на сайт. Неплохо подходит для написания прототипов. Для чего-то серьезного не взлетел.

Открыл первую демку в их списке.
simpletasks.meteorapp.com/tasks

Демка туду лист.
1. Тормозит. Натурально отрабатывает прогрессбар при логине (!) и добавлении айтема. В самом простейшем проекте.
2. Открыл исходники. Там десятки файлов. На глаз строк 300-500 кода.

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

Логин и любой экшин у меня работает за миллисекунды. Видео кстате не передает, но скрины везде где я клацаю обновляются на уровне 25 кадров в секунду.

Твой проект тоже будет тормозить. Как и все другие лоу код поделки. Инфа 146%

Твой проект тоже будет тормозить. Как и все другие лоу код поделки. Инфа 146%

Не будет тормозить. Но чтобы это понять, нужно немного глубже копнуть.
1. Проект использует свою NoSQL субд. Которая работает на очень больших скоростях. Вся вертикаль из компонент, начиная от фронта заканчивая субд интегрирована идеально между собой, без лишних абстракций и коммуникаций.
2. Проект построен так, что на любом уровне мы можем кешировать данные. На уровне клиента, на уровне сервера, на уровне субд. Могут внедрятся смарт кеши by design.
3. Экономия работы на прослойках приложения. Там нет Рест, нет маперов дто и прочьей ерунды которая есть скорей всего в твоем проекте. Данные идут почти напрямую в субд через tcp.
4. Данные льются батчами при обновлении, а не бесконечным единичными задергиваниями сервера
5. Данные идут на сервер максимально гранулярно. Если в строке в гриде изменился один атрибут, то никто не шлет всю строку целиком, шлют только изменившийся атрибут.

Там client-side JS в большей мере и тормозит. Если с meteor демок убрать boostrap, выпилить все спистоперделки, то и он будет летать не хуже :)
Тут вопрос больше в цели проекта. Как понял из описания топика, главная цель это:

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

Meteorjs же, как и множество подобных ему решений, эту цель выполняет на ура. И у подобных решений быстродействие — далеко не самый главный критерий успешности. Главное уметь быстро и с минимальными вложениями развернуть MVP, который не стыдно показать инвесторам.

И если на проект автора накатить более-менее серьезный UI, то, конечно он будет больше тормозить. Даже вот по тем же пунктам, что автор предоставил выше.

Не будет тормозить. Но чтобы это понять, нужно немного глубже копнуть.
1. Проект использует свою NoSQL субд. Которая работает на очень больших скоростях. Вся вертикаль из компонент, начиная от фронта заканчивая субд интегрирована идеально между собой, без лишних абстракций и коммуникаций.
2. Проект построен так, что на любом уровне мы можем кешировать данные. На уровне клиента, на уровне сервера, на уровне субд. Могут внедрятся смарт кеши by design.
3. Экономия работы на прослойках приложения. Там нет Рест, нет маперов дто и прочьей ерунды которая есть скорей всего в твоем проекте. Данные идут почти напрямую в субд через tcp.
4. Данные льются батчами при обновлении, а не бесконечным единичными задергиваниями сервера
5. Данные идут на сервер максимально гранулярно. Если в строке в гриде изменился один атрибут, то никто не шлет всю строку целиком, шлют только изменившийся атрибут.

1. MeteorJS тоже использует NoSQL СУБД. Внезапно, она тоже работает на очень больших скоростях.
2. MeteorJS тоже построен так, что на любом уровне мы можем кешировать данные. Как и любой современный Framework.
3. MeteorJS тоже может работать без REST/мапперов и «прочей ерунды». Синхронизация между клиентским и серверным хранилищем через WebSockets и Publish-Subscribe паттерн. Там, кстати, есть реактивность из коробки, совместимость и даже частичная имплементация PWA и тд.
4. У MeteorJS данные тоже льются батчами при обновлении.
5. У MeteorJS данные тоже идут на сервер максимально гранулярно. Никто не ганяет туда-сюда кучу лишних данных.

И это сравнение только с MeteorJS. А сколько есть других подобных ему решений или стеков... Я веду к тому, что нету проблемы, которую нужно решать ещё одним Революционным FE Фреймворком.

Ещё мне кажется очень странным подход в выборе языка, технологий и вообще подхода. То есть, как понимаю, автор — BE разработчик с отличным стажем. И автор собрался создать некий Революционный FE Framework. Но с FE автор не дружит. Уже как бы странности, не находите? Или автор думает, что современный Front-End, это так, просто стили накатить?

Опустим вопрос, зачем миру нужен ещё один Революционный FE Framework, которых и так уже как грибов после дождя. Допустим в создании оного есть смысл. Теперь след вопрос, а зачем брать Java, которая как бы не оч подходит для создания прототипов?

На client-side у нас доминирует JS. И так будет ближайшие N лет. Почему бы тогда на Back-End тоже не вписать JS? Хотя бы для того, что бы использовать подход с изоморфными JS компонентами. Это ведь как раз в стиле Framework, основная цель которого — предоставить возможность для быстрого создания веб/десктоп/моб приложений.

Ну и много других странных решений по типу создания своих СУБД. Тысячи людей трудятся над реализацией максимально оптимизированных, безопасных и продуктивных СУБД. Автор утверждает, что это всё сильно устарело, а вот его велосипед едет лучше остальных.

Откровенно говоря, это всё похоже на некий троллинг. Даже, если это не троллинг, то не вижу смысл для автора распинаться перед анонимами на DOU. Допустим даже этот новый Революционный FE Framework будет действительно чем-то инновационным и его ожидает успешный успех. Окей, но в таком случае нужно подготовить демку, показать её инвесторам, получить финансирование и нанять нужное количество опытных FE/BE/кого-там-не-достает-в-команде. Никто за бесплатно ничего делать не будет, в особенности, если это не open-source проект.

Если с meteor демок убрать boostrap, выпилить все спистоперделки, то и он будет летать не хуже :)

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

MeteorJS тоже использует NoSQL СУБД.

Сам подход с использованием сторонних СУБД я бы назвал немного устаревшим.
dou.ua/...​rums/topic/36344/#2342576

BE разработчик с отличным стажем. И автор собрался создать некий Революционный FE Framework.

Потому что при нормальной архитектуре, нет большой разницы между FE и BE.
Они похожи. И что более важно, должни работать идеально согласовано.

а зачем брать Java

Не Java а С++, плюс .NET для вебсервера.

смысл для автора распинаться перед анонимами на DOU.

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

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

Проект с открытым исходным кодом: github.com/meteor/meteor Welcome за пруфами :)

Сам подход с использованием сторонних СУБД я бы назвал немного устаревшим.

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

Потому что при нормальной архитектуре, нет большой разницы между FE и BE.
Они похожи. И что более важно, должни работать идеально согласовано.

Опять таки неверно. Сильно зависит от задачи. Иногда нужно 3 разных фронта написанных разными командами/компаниями прицепить к одному беку. RESTful API тут может подойти. И тут BE вообще ничего не знает про фронт. То есть и речи не идет про «должны работать идеально согласовано» и «нет большой разницы между FE и BE».
Автор слишком узко мыслит. В этом вся проблема, это же пытаются сказать другие комментаторы.

Не Java а С++, плюс .NET для вебсервера.

Собственно, мой вопрос тогда остается актуален.

Наводит на мысли куда смотреть, что делать.
Плюс это какой никакой но фидбек.

Так а зачем фидбек человеку, который называет СУБД устаревшими, существующие фреймворки и решения называет устаревшими, его велосипед называет самым идеальным решением мира сего? Опять таки, как по мне, весь топик — троллинг чистой воды.

Проект с открытым исходным кодом: github.com/meteor/meteor Welcome за пруфами :)

Тоесть пруфов не будет ? Кстате предположение что тормозит «из-за бутстрапа», тоже повеселило. Я еще ниразу не видел чтобы CSS стили тормозили. Это какоето ноу хау.

Опять таки неверно. Сильно зависит от задачи. Иногда нужно 3 разных фронта написанных разными командами/компаниями прицепить к одному беку. RESTful API тут может подойти. И тут BE вообще ничего не знает про фронт. То есть и речи не идет про «должны работать идеально согласовано» и «нет большой разницы между FE и BE».
Автор слишком узко мыслит. В этом вся проблема, это же пытаются сказать другие комментаторы.

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

Так а зачем фидбек человеку, который называет СУБД устаревшими, существующие фреймворки и решения называет устаревшими, его велосипед называет самым идеальным решением мира сего?

Потому что это так и есть. Если считаешь иначе, вопросов нет. Заходишь на мой канал, берешь любое приложение из списка. И пытаешся собрать на своем любимом фреймворке так чтобы:
а) Собрано было за считанные минуты/часы
б) Не тормозило
в) Туда залетали новые требования по функционалу за теже часы\минуты

Можешь начать с самого простейшего. Например тренажера
dou.ua/...​sb_comments_forum#2341606

Опять таки, как по мне, весь топик — троллинг чистой воды.

Не :)
Человек просто ощущает себя гением.

Как-то лет 5 тому, а может 7, на ДОУ приходил такой же
Искал инвестиций, для переворота индустрии разработки.
200 килобаксов всего-то ему нужно было

Я даже с ним пообщался онлайн, на словах приняв его NDA

Оказалось
Чел — вайтишник, из заводских инженеров. За полгода разработки на PHP «он понил в чем Инштейн ашибался»
И предложил революционное решение
Операторам SQL сопоставить напрямую HTML теги
Показал даже пример, как замечательно получается тогда туду лист...

Кузьмин с Бубном изрекают подобной же революционности идеи

Да, есть много чудиков.. Как-то читал статью на Хабре, мол парень запилил тупо весь back-end на хранимых процедурах. Без этих всех нелюбимых ему java/python/nodejs/php/etc. Это всё более-менее работало на его проекте и были бы все довольны, но парниша начал рассказывать, что это the only true way и вообще вы все в корне ошибаетесь. Ещё очень обижался, помню, когда в комментах были с ним несогласны.
Сейчас вот поискал, но, увы, не нашел статьи. Но ситуация оч похожая :)

Как-то читал статью на Хабре, мол парень запилил тупо весь back-end на хранимых процедурах. Без этих всех нелюбимых ему java/python/nodejs/php/etc.

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

Например здесь, правильные пацаны, переписали на процедуры и получили следующие результаты

engineering.fb.com/...​infrastructure/messenger

Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000.

А веб «java/python/nodejs/php/etc» приматы вполне умудрятся напечатать несколько миллионов строк и успеют выгореть как спички в кабинетах у психологов. Просто не понимая как на самом деле нужно строить такие архитектуры.

Просто не понимая как на самом деле нужно строить такие архитектуры.

Когда на вашей архитектуре будет построен хотя бы сложности DOU проект — тогда и можно будет доверять — вашему пониманию
Пока же голословные заявления, примеры Hello world и полное непонимание что вас спрашивают, и на что указывают

гений, да. глух.

Пока же голословные заявления, примеры Hello
world

А зачем ты выдумываешь ? Можешь показать где на моем канале или в этой теме, выложен пример «Hello world» ?

Там есть у меня пример реализации, может конечно примитивный

о примитивности ваших примеров вам постоянно говорят.
не только в этой теме.
Выдумывают. Клевещут на гения, да

Кузьмин проще говорит — все идиёты, неспособные понять Его Идею

Там есть у меня пример реализации, может конечно примитивный

Тоесть приложение которое имеет офлайновую базу данных (моб приложение), оптмизировано по трафику, имеет подписки и обновление. Моделирует флоу заказа такси, его проводки начиная от этапа «аукциона» между таксистами заканчивая выполнением заказа и его архивированием. Регистрация пользователей, секурити с ролями для диспетчеров ты назвал «Хелоу Ворлд» ?

Окей. У меня только один вопрос. За сколько ты такой «Хелоу Ворлд» напишешь на своих инструментах ? Когда выложишь демку хелоу ворлда ?

Тоесть приложение которое

которое работает в продакшене.

За сколько ты такой «Хелоу Ворлд» напишешь на своих инструментах

Я не видел тех задания. По фотографии давно не ставлю диагнозов

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

Работа чего-то в проде — обязательный критерий, для отличия хелло ворлда от действительно чего-то стоящего

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

По твоей же логике тебе не следовало бы ни стартовать сиё обсуждение на ДОУ, ни писать FE Framework без понимания основ Front-End :)

А по поводу хранимок. Никто же не против их использования... Просто в реальном мире очень редко можно встретить ситуацию, когда вот этот подход единственно правильный, а вот все остальные — неправильные. Когда человек пишет, мол перепишите весь back-end на хранимки ибо это the only true way, то он априори неправ. Ибо back-end бывает очень разным и далеко не всегда есть смысл тулить логику в хранимки.

Аналогично, если человек пишет, мол СУБД устарели и тут у меня на коленке самое лучшее решение в мире собрано, это тоже, вероятно, некий фанатизм/троллинг/непонимание предметной области/недостаток экспертизы/слишком ограниченый и узкий взгляд.

Сейчас вот поискал, но, увы, не нашел статьи

Наверное эта:

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

я встречал такой подход на практике. Он вполне рабочий.
Но ессно не the only true way :)
У него топовое ограничение — нужны серьезные sqlищики
А не — дальше ОРМа не заглядывал. Да и в сам ОРМ, в его кишочки тоже.
Второе — масштабирование.

Где-то лежит в копилке редкой детальности статья кого-то из тех лидов, какого-то российского оптового поставщика автозапчастей, как они все это замутили на кластере MySQL и шардингах с партицированием. На примере истории пересчета цен для дистрибьюторов, диллеров и прочих СТО
Там жестко, и хотя не все в хранимках — ОРМы и все такое — посланы подальше давно.

Откровенно говоря, это всё похоже на некий троллинг. Даже, если это не троллинг, то не вижу смысл для автора распинаться перед анонимами на DOU.

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

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

Ты просто местный петрушка, вот тебя и не банят, трафик нагоняешь.
ЗЫ Я так давно не смеялся, спасибо, правда.
ЗЗЫ про стрим с Кузьмичем реально подумай, вообще агонь будет!

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

А ты собираешься уйти от устаревшей © арихитектуры процессора и перевести свою работу на Машину Кузьмина © тм?

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

У Кузьмина еще сортировки не подвезли, а у меня в гриды уже подвезли квиксорт. Вообщем я еще думаю.

Видишь — смешить людей у тебя лучше получается чем программировать, тему твою поднимают развче что на смех, а не потому что ты сделал что-то революционное :-)
Ты уже подтянул САР теорему?

Пробовал лет пять назад — ужасно лагавый, сырой, нестабильный. Потому и не взлетел.

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

www.youtube.com/watch?v=B7m2JYI2FYQ

Итак, что мы имеем в первой версии.
1. Страница регистрации пользователя. С валидацией полей, Required, MinLen, MaxLen, Unique
2. Когда пользователь зарегился, он может залогинится. Это все настраивается в секурити и ролях.
3. Как только он залогинился он видит несколько новых кнопок.
a. Users — Список зарегестрированных девелоперов в системе. При двойном клитке открываем и редактируем инфо девелопера.
b. Stories — Грид с полным списком сторей
c. Report — Там отображены 14 разных параметров. Сколько заэстимейтили сторей. Сколько дефектов, сколько багов. Сколько на залогиненом юзере, сколько в статусе active, inpgrogress, closed и тд тп.
d. MyStories — тоже самое что и Stories только в этом гриде стори которые заасайгнены лично на юзера
4. New Story — Визард в котором заводим новую сторю. Сторе автоматом присваивается новый уникальный номер, сторя может относится к разным эпикам. Список эпиков может динамически конфигурится не закрывая браузер, как впрочем и списки возможных статусов сторей, дефектов и багов.
5. Когда открываем сторю, видим всякие разные параметры вроде описание, статус, на кого заасайгнена, список тасков список дефектов. Что интересно, там есть два поля Estimated и Remained. Это сколько запланировали времени на сторю и сколько еще осталось по мнению девелопера. Эти два значения высчитывается динамически, в зависимости от того какие таски залинкованы к сторе. Также к сторе заатачены список дефектов, когда таски заимплеменчены сторя должна тестироваться и баги линковаться. Все редактируется. В каждой таске и дефекте отдельно есть микро чатик чтобы общаться между собой.

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

PS: Все еще ищу фронендщика. Условия обсуждаются в личке =)

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

Эх, как говорил Томас Юнг про знаменитый эксперимент с двумя щелями,
Всю квантовую физику можно извлечь просто тщательно обдвумывая результаты этого эксперимента ©

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

public void Report()
        {
            Client.SetDefaultCollection("Stories");

            FormBuilder.OpenForm(UserContext, new 
            { 
                Stories = new
                {
                    Total = Client.GetAll().Count(),
                    Status = new
                    {
                        New = Client.GetWhere("{'Status':'New'}").Count(),
                        Active = Client.GetWhere("{'Status':'Active'}").Count(),
                        Closed = Client.GetWhere("{'Status':'Closed'}").Count()
                    }
                },
                Time = new
                {
                    Total = new
                    {
                        Estimated = Client.GetAll().Sum("{'TaskEstimated':$}"),
                        Remained = Client.GetAll().Sum("{'TaskRemained':$}"),
                    },
                    Status = new
                    {
                        New = new
                        {
                            Estimated = Client.GetWhere("{'Status':'Closed'}").Sum("{'TaskEstimated':$}"),
                            Remained = Client.GetWhere("{'Status':'Closed'}").Sum("{'TaskRemained':$}")
                        },
                        Active = new
                        {
                            Estimated = Client.GetWhere("{'Status':'Active'}").Sum("{'TaskEstimated':$}"),
                            Remained = Client.GetWhere("{'Status':'Active'}").Sum("{'TaskRemained':$}")
                        },
                        Closed = new
                        {
                            Estimated = Client.GetWhere("{'Status':'Closed'}").Sum("{'TaskEstimated':$}")
                        }
                    }
                },
                Defects = new
                {
                    Status = new
                    {
                        Active = new
                        {
                            Count = Client.GetWhere("{'Status':'Active'}").Count("{'Defects':[{'Title':$}]}")
                        }
                    }
                },
                MyTasks = new
                {
                    Count = Client.GetWhere(DQL("{'Tasks':[{'AssignedTo':'@Me'}]}", UserContext.User.Name))
                                  .Count("{'Tasks':[{'Title':$}]}"),
                    Estimated = Client.GetWhere(DQL("{'Tasks':[{'AssignedTo':'@Me'}]}", UserContext.User.Name))
                                      .Sum("{'Tasks':[{'Estimated':$}]}"),
                    Remained = Client.GetWhere(DQL("{'Tasks':[{'AssignedTo':'@Me'}]}", UserContext.User.Name))
                                     .Sum("{'Tasks':[{'Remained':$}]}"),
                }
            });
        }

А теперь я расскажу как такое пишут на галерах + фаангах.
1. Постановка, нам нужна форма отчет в которой должно быть 14 параметров.
2. Эскьюэльщик пишет от 1й до 14 процедур на базе данных.
3. Бекендщик пишет новый репозиторий, инжектит его в диай. В репозитории вызывает 14 процедур. Репозитория недостаточно, еще должен быть один класс сервиса, который инжектится тудаже. Плюс минимум два класса плюс конфиг на диай. Плюс тесты что диай это диай.
4. Данные аккуратно мапит на модель, создает еще минимум один класс с дто
5. Дальше долбит новые апи рест методы, которым дто с базы данных не подходит. Создает еще одно дто. Перемапливает из дто базы данных в дто подходящий фронту
6. Подключается фронтендщик, начинает писать свою лапшу которая дергает от 1 до 14 рест фулл апи методов, чтобы сформировать отчет
7. Результаты стягивает себе кудато в локальный сторадж
8. Потом както парсит джисонину и както натягивает ее на форму
9. В этот момент оказывается что вся эта лапшла подтормаживает, добавляют прогрессбар
10. Тестеры обнаруживают что совершенно неожиданно в новых 1000 строках кода, чтобы продрать резултаты из базы через все круги современных фреймворков, обнаружилось минимум 10 багов.
11. Фиксят их еще 2 спринта.
12. Когда залетели новые требования что отчет должен локализироваться, кешироваться, настраиваться динамически ... архитекторы сказали что таких требований раньше не видели и надо все переписать.

Теперь я понял, что это :)

Это django/rails/whatever -admin со своими прибамбасами. Но кода хотелось бы поболее — как выглядит обработка форм, как туда тыцнуть уже упомянутую валидацию на 3rd-party сервисе и прочие штуки, которые чуть сложнее отображения списка.

В идеале, github прожект, где можно всё вместе посмотреть

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

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

До того, как публика увидит код, она вообще не может быть уверена, что там вообще есть какой-то фреймворк, а не просто ad-hoc решение на голом асп.нете.

Джира на минималках is coming !

Глянь FogBugz

Хорошая штука от Джо Спольски. Работал с ним еще лет 10 назад. Сейчас на работе atlassian confluence. Но использовать думаю в случае чего всеже самописную системку. Просто в бизнессе рекомендуют «eat your own», чтобы лучше понимать и развивать то, что ты пишешь.

Я тут собі консольну джиру пишу...

Я бы на вашем месте за докторскую диссертацию немедленно сел.

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

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

бубновый, ты походу удачно дилера сменил

Я так, коротко по тезисам.

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

Мне бы такое самомнение — может и Гугл новый давно уже появлися ;)

Как видишь, твой валидатор как создается так и настраивается даже без перезагрузки браузера. Что достаточно удобно, если нужно что-то починить прямо «на проде».

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

Вообще больше половины системы можно просто вот так мышкой сконфигурить.

В целом, закапывайте стюардессу — см. SFCC Pipeline.

С другой стороны, а что с контролем версий, раз всё тыцается мышкой из браузера? Как реплицировать всё это дело между энвайрементами — дев-стейж-прод?

На самом деле речь уже идет как минимум о 7 мини субд. 3 на шарпе и 4 на си.

...

Это дает грандиозную киллерфичу. Теперь не нужно городить слева кафку, справа редис, сбоку постгрес.

...

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

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

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

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

Почему вытаскивать кишки базы наружу это плохо — не буду (думаю, вам все эти тезисы знакомы, оглядываясь на 20+ лет опыта), но задам несколько вопросов:

— как будет выглядеть парсинг и валидация адресов в вашем случае? Со всеми вот этими нудными этапами — укажи страну, адрес, индекс, проверками, что индекс для страны допустим, услуга в этом городе по этому адресу для запрашиваемого количества услуги есть, стоимостью услуги для этого адреса при выбранном виде оплаты, сопутствующими платежами/налогами и так далее;

— как будет выглядеть валидация пользовательского ввода, когда данные необходимо проверять у какого-то 3rd party сервиса, перед тем, как записывать всё это добро себе в базу? Например, пойти проверить, нет ли e-mail адреса в некоем спам-листе.

Хотелось бы увидеть скринкаст, как это настроить за рекламируемые 20 минут.

2. Одним легчайшим (!) движением руки ты совмещаешь отрисовку юай и твой запрос к базе, тоесть весь твой мапинг в обе стороны. И буквально одной строчкой кода (!!) отрисовываешь форму. В этом коде просто невозможно допустить даже мельчайший баг. Его выразительность и простота поражает.

public void ViewStock()
{
Client.SetDefaultCollection("Stock")
.GetAll()
.OpenForm();
}

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

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

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

---

И я концептуально не понимаю — если на клиенте будет своя база, то как будет выглядеть работа с миллионом документов? Это всё будет лететь дружным отрядом на фронт? Есть какая-то виртуализация, чтобы огромные списки не тормозили безбожно? Есть ли возможность загружать документы чанками, чтобы не нагружать напрасно сеть? Есть ли возможность загружать только те свойства, которые необходимо отображать, чтобы, снова же, не нагружать сеть и процессор low-end девайсов?

---

Понимаю, отговаривать вас заниматься делом вашей жизни смысла нет, так что смотрите в сторону Sencha Ext JS или скооперируйтесь с чуваком с Хабра, который двигает $mol. У него тоже весьма таки нестандартное мышление, мб что и получится толковое из кооперации.

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

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

С другой стороны, а что с контролем версий, раз всё тыцается мышкой из браузера? Как реплицировать всё это дело между энвайрементами — дев-стейж-прод?

Конфигурятся в итоге джисон файлы, а они под контролем версии.

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

Может я не правильно выразился, но подразумевалось что на сейчас уже есть несколько движков для хранения данных. Тоесть это аналог разделения MyISAM и INNODB в MySQL, например. Тоесть все эти «базы» живут под одной крышой. Две разные коллекции могут быть привязаны к своим имплементациям в одной и тойже субд. И все они поддерживают одни и теже диалекты языков DQL, KV, TSQL и др.

— как будет выглядеть парсинг и валидация адресов в вашем случае? Со всеми вот этими нудными этапами — укажи страну, адрес, индекс, проверками, что индекс для страны допустим, услуга в этом городе по этому адресу для запрашиваемого количества услуги есть, стоимостью услуги для этого адреса при выбранном виде оплаты, сопутствующими платежами/налогами и так далее;

— как будет выглядеть валидация пользовательского ввода, когда данные необходимо проверять у какого-то 3rd party сервиса, перед тем, как записывать всё это добро себе в базу? Например, пойти проверить, нет ли e-mail адреса в некоем спам-листе.

Ну опять, я там писал. В моем понимании в обычном приложении должно быть как минимум две базы данных. Это собственно привычная всем субд на сервере и клиентская субд. В большинстве ваших приложений роль клиентской субд выполняет наспех сшитая модель данных — кастомный класс. И на основе ее вы натягиваете форму, попутно реализуя все круги мапперов/рест/байнд и тд. Поэтому когда мы говорим что «база валидирует», да она валидирует. Но какая база ? Валидирует и _клиентская_ и _серверная_ база. Если нужно проавалидировать в 3rd party сервиса, то база просто колбеком вызовет ваш код, если обнаружит что в Formula есть переменная которая должна быть посчитана как тру/фолс гдето вне системы. www.youtube.com/watch?v=qxxD9qoGhHc

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

Это отличный вопрос. Есть для этого специальный дименшин Security. Там взрослая настройка прав на основе наследования и ролей. А само секурити конфирутися, например, так.

{
  "MyDashboard": {
    "Disallow": {
      "Read": [
        "Guest"
      ]
    }
  },
  "MyStories": {
    "Disallow": {
      "Read": [
        "Guest"
      ]
    }
  },
  "NewStory": {
    "Disallow": {
      "Read": [
        "Guest"
      ]
    }
  },
  "Users": {
    "Disallow": {
      "Read": [
        "Guest"
      ]
    }
  },
  "Register": {
    "Allow": {
      "Read": [
        "Guest"
      ]
    }
  }
}

Это скрывает/показывает кнопки в зависимости залогинен пользователь в систему или нет.

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

Часть скорей всего открою, там где нужна будет помощь.

И я концептуально не понимаю — если на клиенте будет своя база, то как будет выглядеть работа с миллионом документов? Это всё будет лететь дружным отрядом на фронт? Есть какая-то виртуализация, чтобы огромные списки не тормозили безбожно? Есть ли возможность загружать документы чанками, чтобы не нагружать напрасно сеть? Есть ли возможность загружать только те свойства, которые необходимо отображать, чтобы, снова же, не нагружать сеть и процессор low-end девайсов?

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

Понимаю, отговаривать вас заниматься делом вашей жизни смысла нет, так что смотрите в сторону Sencha Ext JS или скооперируйтесь с чуваком с Хабра, который двигает $mol. У него тоже весьма таки нестандартное мышление, мб что и получится толковое из кооперации.

Некогда кооперироваться. Тестировать нужно. Фронтендщика искать. Писать документацию =)

Риски преувеличены. Здесь как с Экселем

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

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

Безусловно, круто, но вопрос «зачем» всё ещё открыт :)

Клиентская база это то что использует клиент. Не больше не меньше

Клиент отображает 100 000 договоров (ну вот наркоману какому-то так захотелось для супер-быстрого поиска по одному-двум признакам). Они все уйдут на клиент? Со всеми данными? С каким FPS это всё будет скроллиться в браузере?

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

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

Безусловно, круто, но вопрос «зачем» всё ещё открыт :)

Данные даже в одном документе могут иметь разные требования по чтению, обновлению, хранению данных. Они требуют разных алгоритмов storage

Данные даже в одном документе могут иметь разные требования по чтению, обновлению, хранению данных. Они требуют разных алгоритмов storage

Мой вопрос «зачем» не о том, для чего 7 движков, а для чего было свои пилить, в которых 100% есть уязвимости, неизведанные баги и нет информации о том, как они себя ведут под реальным профилем нагрузки.

Мой вопрос «зачем» не о том, для чего 7 движков, а для чего было свои пилить, в которых 100% есть уязвимости, неизведанные баги и нет информации о том, как они себя ведут под реальным профилем нагрузки.

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

Клиент отображает 100 000 договоров (ну вот наркоману какому-то так захотелось для супер-быстрого поиска по одному-двум признакам). Они все уйдут на клиент? Со всеми данными? С каким FPS это всё будет скроллиться в браузере?

Зависит от того как напишешь. Для этого случая я бы рекомендовал использовать Sync.Mode = OnDemand он же Proxy. Только если данные не будут найдены в клиентской базе, они будут динамически подгружаться с сервера в зависимости от действий пользователя.

Платформа представляет собой полную экосистему для разработки, от собственной субд до фронт фреймворка.

youtu.be/_dGq3RGt6sA?t=420
Бабу бы тебе и поскорее © ))

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

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

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

Более того, я ушел еще дальше.

"Если ты такой умный, то где твои деньги?" ©
«Пендальф, внатуре, а где наши деньги?!» ©

ну так пишет же человек — фронта нет :)

Посмотрим, изменится ли что либо с фронтом ))

Не с то го конца начинаете 😀 Сначала надо посторожить большое приложение — а потом из него фреймворк выделять.

Хотите я завтра за 20 минут создам круд приложение с нуля с сотней вложенных форм и тысячью контролов ?
Пора обращать заблудшие души джавистов на путь истинный !
Да причастятся к светлым технологиям блудники и блудницы и да отрекутся от своих спрингов и энтити фреймворков 😀

Хотите я завтра за 20 минут создам круд приложение с нуля с сотней вложенных форм и тысячью контролов ?

Хотим :-)

Я c++ник, не могу обещать :-) у меня один постоянный фреймворк — Qt, и QML в нем чертовски хорош.

Ух
Not bad
Если это сгенерировано из шаблонов и твой двиг все это связал друг с другом — респект

Круто! Теперь надо ещё потратить минут 20, чтобы приложение было осмысленным, и делало что-либо полезное, чтоб людям было хотябы не лень его смотреть.

Так, выбираем веб проект на завтра. Напишем мини соцсеть или небольшой аналог джиры ? Таски то надо гдето заводить.

да, «джиру» давай

DNAExp, у меня к тебе всего несколько очень простых вопросов.

1) ты когда-нибудь сталкивался с таким явлением как BPMN?
2) ты имеешь представление что такое и откуда возникла такая вещь как MDM?

Не совсем понятно, к чему ты ведешь.

Ты на вопросы ответь плиз сначала.

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

Я говорю без контекста. Ты вообще в курсе о бпмн и мдм?

По поводу мдм у меня есть такой волшебный дименшин Lifetime называется. Его роль в базе дропать все данные по прошествию какого-то времени. Есть также еще более магический дименшин Encrypt. Он шифрует данные в базе.
По поводу бпмн все еще не понятно о чем речь.

мдм у меня есть такой волшебный дименшин Lifetime называется. Его роль в базе дропать все данные по прошествию какого-то времени.

Это не мдм.

en.wikipedia.org/...​ki/Master_data_management
en.wikipedia.org/...​rocess_Model_and_Notation
en.wikipedia.org/...​orkflow_management_system

Все еще ускользает твоя основная мысль.

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

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

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

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

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

Все познается в сравнении. Приведи пример где спринг хорош, мы напишем два приложения и сравним оба подхода.

Приведи пример где спринг хорош

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

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

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

Я 20 лет работаю с такими проектами.

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

Я не понял зачем ты привел их пример и что пытался мне доказать. И ты так и не смог обьяснить.

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

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

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

Как у фронта, у меня больше проблем с редаксом, чем с фрейморком (реакт).

Большая часть задач последних всех SPA-проектов — это пульнуть json и положить его в стор чтобы компоненты могли юзать. На это простое действие в текущих реалиях нужно: отредактировать штук 10 файлов, написать 3 экшона, все 3 похендлить в редюсерах и в очередной раз долбать сагу.

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

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

Вот эту хрень хочется заменить на что-то более адекватное.

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

Ну банально на 5 скринов визарда (и 5 постов) нужно сидеть и писать 15 экшонов и соотв 15 редюсеров и потом все это еще в сагу прибивать гвоздями.

Хотя если думать головой, то эти данные никак не могут быть нужны другим компонентам сайта и их вообще не нужно трогать редаксом. Но текущий фронтенд так уж устроить и написать fetch в компоненте — моветон.

Спасибо за наводку. Пробую почитать по теме.

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

В теории да, а по факту провезешь мимо редакса/саги — так сразу начинаются срачи про «анконсистенси». Итого все и приходит в флоу — засунули в редакс, достали из редакса.

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

Все должно существенно упростится и ускорится

Вы недооцениваете фантазию евангелистов фронта :)

Не сколько проблем с самими технологиями (html/css/js), сколько от гемороя принесенного попытками типизации и унификации всего и вся.

Да на бекенде тоже полно любителей с помощью ООП столбиком умножать. Единая вертикаль, где бекенд и фронтенд будет написан в едином стиле и идеально согласован друг с другом без лишних прослоек полностью поменяет ход дела

контролы забандить к данным в базе напрямую

А валидация на стороне фронта, или на стороне базы? Подозреваю, что на стороне базы.

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

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

Итак, как же будут работать твои волшебные байндинги, когда ченж поля А(фронт) напрямую улетит в А(база)?

Но это еще не все. Если в некоем стороннем легаси-сервисе, поле allow-shit-data-in-A-B стоит тру, то валидацию делать не надо. Т.е. в момент изменения А или Б — нужно дернуть сторониий сервис, и запросить текущее значение. Более того, допустим это высоковолатильные данные, и поле allow-shit-data-in-A-B может меняться ежесекундно. Это значит, что для описания условий консистентности, на любом ченже А или Б тебе нужно сохранять текущее состояние allow-shit-data-in-A-B+timestamp+userId+changeId (да-да, бизнес захотел хранить историю взаимоотношений А и Б).

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

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

Это уже работает. Например при регистрации проверяются два поля введите пароль, на совпадение.

Это значит, что для описания условий консистентности, на любом ченже А или Б тебе нужно сохранять текущее состояние allow-shit-data-in-A-B+timestamp+userId+changeId (да-да, бизнес захотел хранить историю взаимоотношений А и Б).

Эту историю уже и так хранит дименшины Logs и History. Тоесть это уже работает. Ты можешь получить срез базы данных на определенную дату в прошлом.

Это уже работает.

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

Ты можешь получить срез базы данных на определенную дату в прошлом.

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

Что насчет сайд вызовов ты не ответил.

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

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

{
  "Name1": {
    "Formula": "@Value = Document.Name2"
  },
  "Name2": {
    "Formula": "@Value = Document.Name1"
  }
}

Некоторые значения в формуле ты можешь задавать как вариейбл
«Formula»: «@ValidateByValue»

и далее в своем обработчике уже дергать что хочешь кастомное и стороннее при валидации

switch (variable)
            {
                case "ValidateByValue":
                    {
                        var count = Client.SetDefaultCollection("Articles")
                                          .GetDoc(docID)
                                          .Count("{'Messages':[{'Who':$}]}");

                        return count > 100;
                    }
                default:
                    throw new NotImplementedException();
            }
С чего ты это взял ? Правило которое ты описал выписывается в дименшине Validation.
Некоторые значения в формуле ты можешь задавать как вариейбл
«Formula»: «@ValidateByValue»

и далее в своем обработчике

Ты просто написал бекенд логику в базе. Штош.
Ты просто написал бекенд логику в базе. Штош.

Ну можешь так думать. Просто ремарка.
1. Баз данных теперь как минимум 2, но чаще даже 3 или больше.
а. Первая это на сервере, которая является source of true
b. Вторая база данных на клиенте (ее может не быть)
с. Третья база данных закеширована в твоей форме. Ибо форму на основе чегото нужно показать. Ты ее показываешь на основе моделек в своем коде. А я ее показываю на основе коллекции из базы данных

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

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

Ну и чтобы ты не думал что я тут что-то фантазирую, вот тебе реальный видос как работает описанный тобой валидатор

ibb.co/DpBw8dv

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

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

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

Кстати, чисто технический вопрос. Какой транспорт у тебя обеспечивает этот постоянный байндинг? Просто тсп сокет?

И да, еще вопрос. Подними сторонний сервис, который должен дергаться при валидации этих двух полей, поставь там таймаут скажем рандом от 200 до 2000 мс. Открой таких страничек штук 300 и и начни менять. Пусть каждая страничка тянется к своей версии А и Б. Скажем, что это не static.A, а user.A. Как поживают застывшие в ожидании ответов от сервиса транзакции? Я же правильно понимаю, что пока А и Б валидируется, транзакция ждет?

Во-первых, ты взял простейшие примеры.

Примеры как примеры. Валидация везде достаточно примитивная штука. Для не примитивных кейсов есть formula и есть кастомный код.

Просто тсп сокет

Через тсп

И да, еще вопрос. Подними сторонний сервис, который должен дергаться при валидации этих двух полей, поставь там таймаут скажем рандом от 200 до 2000 мс. Открой таких страничек штук 300 и и начни менять. Пусть каждая страничка тянется к своей версии А и Б. Скажем, что это не static.A, а user.A. Как поживают застывшие в ожидании ответов от сервиса транзакции? Я же правильно понимаю, что пока А и Б валидируется, транзакция ждет?

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

Т.е. валидация происходит ДО открытия транзакции, которая бы заблокировала А и Б для конкурентых модификаций?

А причем тут транзакция ?

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

Т.е. валидация происходит ДО открытия транзакции, которая бы заблокировала А и Б для конкурентых модификаций?

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

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

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

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

Идея была сделать иммутируемый единый стор (в котором нельзя что-то случайно грохнуть из-за линковки объектов) и чтобы типа все изменения были описаны и отслеживались.

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

Но все вышло весьма криво. В погоне за конфигурацией названий экшонов / структуры стора вывилось огромная гора бесполезного кода (хотя можно было и экшоны и путь в сторе называть по адресу эндпоинта аля store[’/users/trainings’] и никто бы не умер).

Но текущий фронтенд так уж устроить и написать fetch в компоненте — моветон

Там же хуки завезли, и уже ж типа можно, церковь одобряет. useQuery/useFetch и прочее ж без всяких там редаксов. Более того, написать свой useFetch и лезть с ним на стековерфлоу — путь истинного самурая.

у меня больше проблем с редаксом, чем с фрейморком (реакт).

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

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

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

Потому что реакт и его экосистема это клоунское говно, бери vue и ты великолепен.

Рынок диктует правила, мне все равно на чем формошлепить

по моему человеку который задает подобные вопросы рановато писать собственную плктформу

Кстате отличный наглядный пример, как пишут код по старинке и как должно быть.
Взял рандом файл из твоего проекта, по бухучету.
github.com/...​06/www/app/pages/main.php

Теперь давай рассмотрим как ты пишешь на ПХП типичную форму редактирования.
1. Ты используешь SQL базу данных. Что само по себе уже немного архаично. Намного лучше исользовать документоориентированные базы. В одном документе может компактно содержаться полная доменная структура данных, которая у тебя размазана по десяткам таблиц. Редуцируются ненужные референцы. Появляются возможности горизонтального масштабирования. Превкушаю вопрос про АСИД и транзакции, но нет, они в моей базе есть.

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

3. Весь код написан как закостенелый каркас. Локализация, секурити, пейджинг, сортировки. По-моему если прийдет одно из этих требованийй (что является логичным развитием системы), придется переписать почти все.
github.com/...​templates/pages/chat.html

Теперь смотри как пишут код по новому.
1. Ты создаешь свою доменную модель как джисон документ. В джисоне выписываешь весь контракт твоего обьекта, сколь угодно сложного документа.

2. Одним легчайшим (!) движением руки ты совмещаешь отрисовку юай и твой запрос к базе, тоесть весь твой мапинг в обе стороны. И буквально одной строчкой кода (!!) отрисовываешь форму. В этом коде просто невозможно допустить даже мельчайший баг. Его выразительность и простота поражает.

 public void ViewStock()
        {
            Client.SetDefaultCollection("Stock")
                  .GetAll()
                  .OpenForm();
        }

3. Если тебе нужны такие фишки пропертей как локализация, секурити, кеширование, ты его добавляешь как отдельный слой, не смешивая (!!) его с бизнесс логикой и доменной моделью. Этот слой описывается в джисон и крайне выразителен. Например вот здесь описано что сток имеет менюшку. Даже если форма будет иметь 5000 контролов и три грида, весь юай, локализация, секурити, кеширование будет аккуратно и выразительно выделено по отдельным файлам. А прибить или добавить к примеру секурити по всей системе можно будет просто удалив или добавив один (!) джисон файл !

{
  "StockProducts": {
    "MenuItems": [
      {
        "Text": "Add To Cart",
        "Action": "AddToCart"
      }
    ]
  }
}

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

Добро пожаловать в новый мир.

Одним легчайшим (!) движением руки ты совмещаешь отрисовку юай и твой запрос к базе, тоесть весь твой мапинг в обе стороны. И буквально одной строчкой кода (!!) отрисовываешь форму.

Ну так это пример уровня хеллоу ворлд. Для такого уровня задач вообще не нужно писать код — нужно взять вордпресс + пару плагинов для всяких свистоперделок, натянуть красивую темку купленную за полтинник и делов-то (а в принципе и этого уже не нужно — есть 100500 SaaS решений на любой вкус и кошелек).

Так в верху и есть твой вордпресс на ПХП. А точней тот стиль в котором обычно пишут.

взять вордпресс + пару плагинов для всяких свистоперделок

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

ibb.co/rmSMS6G

Что тут интересного. У каждого таксиста мобила может иметь слабый трафик интернета. Она должна обновлятся и синхронизироваться с сервером, буквально побайтно. Это приложение это делает. Таксист регистрируется, отслеживает в своем регионе заказы (может фильтровать) берет заказ и его комплитит. В архиве хранится история заказов. В системе три роли пользователей, диспетчеры, таксисты и админы. Все приложение было написано тоже гдето за час.

Удачи с «вордпресс» и подбором «саас» в борьбе просто с другой парадигмой программирования.

Таксист регистрируется, отслеживает в своем регионе заказы (может фильтровать) берет заказ и его комплитит.

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

Удачи с «вордпресс» и подбором «саас» в борьбе просто с другой парадигмой программирования.

В чем-в чем? В борьбе? Шутка дня, однако.

Как будет выглядеть кинцо если один и тот же заказ попытаются взять два таксиста?

У них там вообщето аукцион. Я правда поленился его допилить, это надо было еще минут 15 времени потратить. Пока поле не заполнено Who заказ можно брать.

Они оба в моменте оказались оффлайн, в локальных базах принятие заказа закоммитилось, телефоны поймали сеть и попытались синхронизироваться — получили конфликт.

Для этого помимо дименшина Sync есть дименшин History. Другими словами, синхронизация происходит в стиле гит. Каждый клиент присылает пачку своих изменений на центральную базу данных Patch. После этого сервер шерстит историю изменений и смотрит, нет ли конфликтов чтобы замержить этот Patch с момента последнего обновления клиента. Если нет, мержит историю изменений. Если конфликт, не разрешает сохранится и клиент делает Pull последних изменений. Эти кейсы у меня уже покрыты и протестированы интеграционными тестами. Хотя баги еще могут конечно быть. Гранулярность самого мержа на уровне не строк в таблице, а отдельных значений. Что максимально уменьшает количество конфликтов.

Это первое. Второе, все изменения с новыми заказами таксистам прилетают в стиле subscription. Тоесть если 5 тысяч таксистов в сети, сервер аккуратно каждому из активных таксистов присылает только те данные, которые измененились в его зоне.

В чем-в чем? В борьбе? Шутка дня, однако.

Лучше расскажи с каким проектом работаешь. Я тебе расскажу как его переписать, сильно проще и короче.

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

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

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

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

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

Почему они должни быть неверными если там есть подписка на постоянное обновление ?

то есть ты хочешь сказать, что один пропатчил одно поле на бекенде, то всем клиентам рассылается обновленные данные?

какой ужас :)
ну удачи! :)

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

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

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

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

Все как раз наоборот. Подписка координально разгружает сервер и распределяет нагрузку равномерно по сети.

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

если ты про нагрузку на апп сервер — то в этом мало практического смысла — железо — самое дешевое из проблем.
Если ты про нагрузку на базу данных — так у тебя ж документ стор с горизонтальным масштабированием.
Идея уменьшать нагрузку на базу через использование локального кеша не нова и известны все вытекающие отсюда проблемы.
По сути твой движок синхронизации пытается решить вопрос инвалидации кеша. Каким образом pull или push — это уже второй вопрос.
Вопрос насколько это реально будет работать.
Но весь адъ на мой взгляд именно в том что ты пытаешься race condition который сейчас решается на уровне апдейта базы сделать распределенным через локальные кеши.
Может я не прав — но на первый взгляд сама идея навевает ужас от возможных коллизий данных.

Но весь адъ на мой взгляд именно в том что ты пытаешься race condition который сейчас решается на уровне апдейта базы сделать распределенным через локальные кеши.
Может я не прав — но на первый взгляд сама идея навевает ужас от возможных коллизий данных.

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

Почему они должни быть неверными если там есть подписка на постоянное обновление ?

Ну да. Машина Кузьмина же.
«А внутре у ней неонка» ©

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

А просто выдумывать про неонку

Это цитата из АБС. Почитай «Сказку про тройку», потом почитай посты Кузьмина про концепты концептируют концептуальные адрессные адрессации, сладко проорешь, неонка там очень кстати. А тут ты просто очень похоже написал как Кузьмин пишет, поэтому это просто шутка.

Если ты мне не веришь, ты можешь предложить пример

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

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

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

Понимаешь дружище, как писал еще старина Ницше

Безумие отдельного человека встречается редко, а безумие целых групп, партий, народов, времен — является фактически правилом.© Фридрих Ницше

К сожалению да. Большинство долбят низкоуровневый код. Такой себе Ассемблер в 21м веке. Пишут длинные статьи о том как причесать рест, как сделать мапинг, как обойти проблемы с консистентностью на фронте и др. Большая простыня кода и командной строки чтобы сделать полезного ровно нихрена.
Я не виноват что люди в 21м веке, пишут низкоуровневый код, при построении прикладного ПО. Пишите высокоуровневый код.
Я покажу как.

В одном документе может компактно содержаться полная доменная структура данных

А если в множестве объектов домена А содержатся референсы к некоему подмножеству объектов домена Б, что делать? Грубо говоря, твоя идея противоречит ссылке по внешнему ключу.

Есть разные варианты.
1. Хранить референц. Например айди или какой-то другой уникальный ключ. Но тогда сложнее вытягивать связанный обьект. Нужно делать это вручную.
2. Хранить дубликат данных.
3. Использовать дименшин Sync. В этом дименшине может указываться, что блок документа синхронизируется из другого документа. Другими словами между документами тогда возникает сильная связь. Актуальность дублированных данных берет на себя «движок» по синхронизации, аналогично с materialized view в реляционных субд.

2. Хранить дубликат данных.

...I’m on the highway to hell
On the highway to hell
Highway to hell
I’m on the highway to hell
:D

3. Использовать дименшин Sync

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

Актуальность дублированных данных берет на себя

... и ты возвращаешься к пункту 2, просто твоя разработка подпирает это костылем, который ты называешь «Sync дименшн». Лучше оно от этого не становится.

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

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

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

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

Ой фронт очень сложно унифицировать. Все думают что фронт это просто но это далеко не так.

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

Все думают что фронт это просто

кто эти люди — это ппц сложно

кто эти люди — это ппц сложно

Пора это исправить.

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

С контекстом проблем нет. Все изначально проектировалось так, что на клиенте может быть своя полноценная клиентская база данных (даже с транзакциями!). Которая к томуже асинхронно обновляется. Тоесть фронту даже не нужно лазить рест запросами на бек. Просто читать свою локальную базу ! Другими словами, визарды на много скринов, валидациями, секурити, сортировками и тд, все это уже есть и работает. Проблем вообще нет.

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

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

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

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

Я не стесняюсь своих недостатков :) Также как я хорош в базах данных и бекенде, плох в фронтенде. Фронт мне никогда не был интересен и писал его всегда, просто чтобы были контролы и было куда клацать.

та я тож фронтенд не люблю.
но все-таки решать системные проблемы в какой-то области стоит с освоения это области, чтобы понять че там за проблемы, разве нет? :)
Просто «все сложно», а надо что было «все просто» — это не формулирование ни проблемы, ни решения.

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

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

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

Фронт мне никогда не был интересен

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

базах данных и бекенд

.

«милишнику не стать рейнджем» )

Тимур похоже тоже начал что-то подозревать.
Говорит текущие лоу код решения так себе и стоит написать свои.
Скоро профессия прикладного программиста всё ....
www.youtube.com/...​tch?v=vNmO0Y_LTr4&t=1610s

По многим пунктам с ним соглашусь.
На сегодня прикладной код неоправданно сложно устроен. Его слишком долго пишут. Использует слишком много разных технологий. Требует слишком много ресурсов. Как результат такой код в итоге содержит слишком много багов и слишком медленно работает.

Рассмотрим то, что можно написать отказавшись от устаревших подходов, потратив час времени и написав примерно 150 строк тривиального кода.
1. Страница логин/логаут
2. Страница регистрации пользователя
3. Каталог товаров
4. Поиск товаров по названию в стоке
5. Корзина покупок
6. (транзакционное) Вычитание списка товара из стока при покупке в онлайн магазине

ibb.co/s9V4zYs

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

PS: Господа FE девелоперы. Все еще ищу идеи/людей которые помогут оживить юай.

Так, в новой теме заложу новую добрую традицию !

В соседних темах нам рассказывают как освоить REST, gRPC, IoC, GO, PHP предлагая длинные технические статьи. Эта тема, о том, как избавится от всего лишнего, очистить сознание, постигнуть дзен и писать приложения с лекостью 12 летнего ребенка, который просто играется увлекательным конструктором.

Это приложение в виде анонимной голосовалки, вместе с админкой, было написано всего в 6 (шесть) строк кода.
ibb.co/GC0hNn1

У приложения есть админка, тоесть список вопросов можно редактировать прямо не перегружая браузер.
Вообщем время от времени я буду выкладывать ролики с работающими приложениями.

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

Это приложение в виде анонимной голосовалки, вместе с админкой, было написано всего в 6 (шесть) строк кода.
ibb.co/GC0hNn1

Эти скрины никому не интересны. Выложи куда-то исходники и инструкции по сборке, и юзабельную демку, чтоб ее можно было пощупать.

Демку позже выложу, как настрою сервер в мир. Возможно на неделе соберу более интересное приложение.
Но

Выложи куда-то исходники

Исходники выкладываться не буду. Не хочу давать фору конкурентам на ранних этапах.
Если есть в теме толковый фронтендщик, который хочет написать свою «шукуру» для фронтенда, пишите в личку. У него будет полный картбланш. Половина фронта уже есть, включая субд которая хостится на клиенте.

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

Исходники выкладываться не буду. Не хочу давать фору конкурентам на ранних этапах.

www.forbes.com/...​our-idea/?sh=1c843cae6a53

No One Will Steal Your Idea

Это прекрасно. Идеи бесплатно я могу отгружать по сотне к обеду.
Но здесь речь не о «идее», а о вполне рабоющей платформе, которая имеет вполне конкретные преимущества и уже постепенно перешла в раздел тестирования. Худо бедно покрыта юнит тестами и под нее написаны уже первые несколько приложений, хоть и с архаичным интерфейсом.

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

У тебя был опыт чтоб твоим кодом кто-то пользовался, нарушая твои права? Откуда такая фобия?

По опыту HArray могу сказать, что даже если код будет открыт, в нем мало кто сможет разобраться. (Тебе вот 5 лет например не хватило времени). Это не камень в твой огород, просто я не вижу в этом большого смысла. Начнется обычная ловля блох в коде, в котором и так понятны узкие места и что и как там нужно дальше делать. Тоесть самого профита от открытого кода «для всех» я не вижу.

Также по опыту HArray можно сказать, что как только код появляется в открытом доступе, сразу становится понятно, что король голый, а пока кода нет, можно собирать internet clout, выкладывая видосики

Также по опыту HArray можно сказать

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

здесь речь не о «идее», а о вполне рабоющей платформе, которая имеет вполне конкретные преимущества и уже постепенно перешла в раздел тестирования

Это не имеет никакого смысла без поддержки со стороны FAANGов. По большому счёту нет никакого значения, что ты там напишешь, полезность определяется всё равно субъективным отношением. А субъективное отношение формируется средствами маркетинга.

Это не имеет никакого смысла без поддержки со стороны FAANGов.

Я не против. Пускай фаанги покупают исходники вместе с проектом. А так, написать 100к строк высокотехнологичного кода и подарить фаангам на шару ... зачем ? Пускай вот там на рынке нанимают кадров, которые несчастный мессенджер пишут в миллион строк кода.

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

эйфория новичка ))) или твоя «прога» умеет в финмодель и операционный менджмент?)))

эйфория новичка )))

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

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

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

Your best bet это интегрировать свой фреймворк как фичу/библиотеку дополнение к существующему популярному фреймворку. А еще лучше сделать ее framework agnostic, чтоб можно было использовать из разных UI фреймворков или вообще напрямую без прослойки в виде фреймворка.

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

Если сильно хочется сделать свой вклад в кладбище никому не нужных UI фреймворков, начни «working backwards» — представь себе что фреймворк уже есть и ты его используешь. Как выглядит код? Какие функции ты вызываешь, чтоб его использовать? Какой синтаксис? И так далее.

Если фантазии не хватает, бери какой-то существующий и одалживай оттуда идеи или форкни его и замени релевантные части на свои.

Your best bet это интегрировать свой фреймворк как фичу/библиотеку дополнение к существующему популярному фреймворку. А еще лучше сделать ее framework agnostic, чтоб можно было использовать из разных UI фреймворков или вообще напрямую без прослойки в виде фреймворка.

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

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

Оставляю честь писать свой агностик квадратик другим ребятам.

Умный каждый день пополняет свои занния. Мудрый каждый день стирает лишнее© Лао-Цзы

Сегодня мы не должны быть умными. Мы должни быть мудрыми.

предлагаю закопать вообще все существующее, и перейти сразу к машине Кузьмина

В каждой шутке есть доля шутки.
Современное программирование выглядит примерно так. Мы решали проблему А. Пока решали проблему А, у нас появилась проблема Б и В. Чтобы решить проблему Б и В, мы придумали технологии Г, Д, Е, Ж И К. И теперь что-то пошло не так ....

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

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

мы придумали технологии Г, Д, Е, Ж И К

там ще Ё бракує — «технологии Г, Д, Е, Ё Ж И К»

Г, Д, Е, Ё Ж И К ?!

Так, DOU, сделайте смайлик рядом с поддержать )

Хочется вспомнить легендарное высказывание Леонардо Да Винчи
Простота — это то, что труднее всего на свете: это крайний предел опытности и последнее усилие гения © Леонардо да Винчи

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

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

Підписатись на коментарі