Здравствуйте, Qulac, Вы писали:

Q>Чем? Все также просто показывает.

Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д. Добавьте сюда множество платформ и девайсов, адаптивную верстку и т.д.

А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?

Здравствуйте, Qulac, Вы писали:

Q>Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.

Так было 20 лет назад. Сейчас UI в современных проектах — нередко превосходит по сложности бэкенд.

Здравствуйте, Qulac, Вы писали:

S>>А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?
Q>Это не сложность.

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

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

Здравствуйте, Janus, Вы писали:

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

20 лет только этим и занимаюсь.

J> Никому не нужно усложнять проект , заказчику вообще фиолетово какой фреймворк внутри проекта ( Иногда бывает что , фреймворк оговорен в ТЗ или есть внешний аудит ) Никто в коммерческой разработке не занимается искусством ради искусства и освоением новых технологий на проектах заказчика . Для этого существуют pet проекты.

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

Здравствуйте, Shmj, Вы писали:

S>20 лет только этим и занимаюсь.

Этим — болтовнёй на форуме?

S>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?

Переход количества в качество — слыхали? Поинтересуйтесь при случае у GPT, что это такое.
Мы в дебри языков лазали на первом курсе. Ну чтобы понять ту или иную возможность языка. Решить задачу тогда считалось вторичным.
А сейчас нужно задачи рашать. И я не буду для небольшой GUI-программы делать интерфейс на HTML, а сделаю на чём-нибудь попроще. Всё определяется решаемой задачей и только ею.

S>Чистый декларативный дедовский подход не удобен и существует только как легаси.
S>Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?
Хочу такую штуку:
Толпа шибко умных разработчиков-физтехов-краснодипломников с феноменальной памятью — делает исходный проект допустим на WPF MVVM, или на 300 гигаметров жабаскрипта,
а ИИ это берёт и превращает в проект WPF/Winforms/Delphi/TurboVision с обработчиками в кнопках на форме. В которых все полезные действия делает по кратчайшему пути, схлопнув все слои и уровни абстракций в 0, без 300-строчных stack trace последовательно через 10 микросервисов ради сохранения 1 записи в базу.

Здравствуйте, Shmj, Вы писали:

S>Бек сейчас только отдает JSON, по сути.

Ну да, и больше нифига не делает, просто отдаёт какой-то JSON

Здравствуйте, Marty, Вы писали:

S>>Ну значит знай что бывает и такое — будешь знать что чел. с 20 летним стажем, который только этим и занимался и другого ничего не умеет — может так мыслить. Иногда стаж не решает — Природа первична и она всех наделила разными способностями, ничего стесняться этого. Кто-то вообще дауном родился — и что такого?

M>Да, в общем-то, ничего такого, только если родился дауном, в разработку имхо наверное не стоит лезть, может чем-то попроще ограничится?

Это уже каждый человек сам решает чем ему заниматься — бывает по- разному, не смотря на стереотипы: https://ru.wikipedia.org/wiki/%D0%9F%D0%B8%D0%BD%D0%B5%D0%B4%D0%B0,_%D0%9F%D0%B0%D0%B1%D0%BB%D0%BE

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

Это все самые передовые фрейморки — такие как Flutter, Jetpack Compose, SwiftUI, React. Т.е. все самое передовое и современное — авангард вертски можно сказать. Чистый декларативный дедовский подход не удобен и существует только как легаси.

Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?

Подход	Часто используется в
MVC	ASP.NET, Django, Ruby on Rails
MVP	Android (раньше), WinForms
MVVM	WPF, Xamarin, Flutter
Redux / UDF	React, Angular, Flutter
BLoC	Flutter
Elm / TEA	Elm, Flutter
Clean Architecture	Любые масштабируемые проекты

Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код

Что вы используете и что лучшее на ваш взгляд?

Здравствуйте, Shmj, Вы писали:

Правильнее будет — паттерны управления состоянием. state management — устоявшийся термин, что гораздо правильнее т.к. UI это малая часть того чем надо управлять.

S>
S>
S>
S>
S>
S>
S>
S>
S>
S>

Подход	Часто используется в
MVC	ASP.NET, Django, Ruby on Rails

MVC это совсем необязательно серверное решение. Автономный клиент безо всякого сервера точно так же может быть на MVC

В этом случае код получает довольно близким к разновидностям redux:
вместо reducer будет command
вместо enhancer будет плагин или мидлвара
вместо мидлвары будет или команда или команда-мидлвара или тоже мидлвара
модель может быть пассивной, активной, реактивной, мутабельной, иммутабельно, какой угодно, в отличие от редукс модель только иммутабельная пассивная.

например.
mvc

conroller.execute(Action.DocumentOpen)

контроллер находит команду-обработчик,
вызывает её с учетом всех нужных мидлвар итд, передает модель как аргумент
команда обновляет состояние модели
в конце контроллер вызывает обновление UI
— метод update у каждого из view
— event update на который подписаны все view
— observable/subscription на который подписаны все view
— кидает в шину сообщение update

последние два варианта наиболее близки к redux


redux

store.dispatch(Action.DocumentOpen)

store вызывает все редюсеры
потом вызывает мидлвару
сохраняет новое состояние модели
триггерит subscription на который подписаны все view

Здравствуйте, Shmj, Вы писали:

S>Вот, саму верстку форм вроде обсудили. Лучшее к чему пришло человечество можно назвать: декларативный UI с функциональной интеграцией.

S>Это все самые передовые фрейморки — такие как Flutter, Jetpack Compose, SwiftUI, React. Т.е. все самое передовое и современное — авангард вертски можно сказать. Чистый декларативный дедовский подход не удобен и существует только как легаси.

S>Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?


S>Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код

S>Что вы используете и что лучшее на ваш взгляд?

MVVM конечно.

Здравствуйте, Shmj, Вы писали:


S>Что вы используете и что лучшее на ваш взгляд?

Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет )
Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть
свой велосипед (и не один !) к ним.

Здравствуйте, Janus, Вы писали:

S>>Что вы используете и что лучшее на ваш взгляд?

J>Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет )
J>Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть
J>свой велосипед (и не один !) к ним.

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

Так что же в таком ракурсе?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Janus, Вы писали:

S>>>Что вы используете и что лучшее на ваш взгляд?

J>>Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет )
J>>Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть
J>>свой велосипед (и не один !) к ним.

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

S>Так что же в таком ракурсе?

Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.

S>Так было 20 лет назад. Сейчас UI в современных проектах — нередко превосходит по сложности бэкенд.

Чем? Все также просто показывает.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Чем? Все также просто показывает.

S>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д. Добавьте сюда множество платформ и девайсов, адаптивную верстку и т.д.

S>А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?

Это не сложность.

Здравствуйте, Shmj, Вы писали:

S>Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код

S>Что вы используете и что лучшее на ваш взгляд?

Мой текущий personal jesus — это JMIX-студия. Это как Дельфи, но для разработки корпоративных клиент-серверных JavaEE-систем и фулстэк-приложений.
Максимально, просто неимоверно максимально, ускоряет разработку production-ready корпоративного ПО и делает её очень комфортной, позволяя сосредоточиться на бизнес-сущностях и их бизнес-логике, а не потонуть в мириадах строк шаблонного boiler-plate кода. Это примерно как в своё время появился Дельфи как откровение после виндузового морока с MFC — ты просто лепишь на форму поля и кнопки, создаёшь обработчики событий, х*як-х*як — и десктоп-приложуха готова. Если в JMIX нужно вызвать диалог, даже асинхронный с background-прогресс-баром — вызываешь его в коде, без лишней писанины по десяти разным местам.
Архитектура там Server-Side MVC на основе Vaadin.

Здравствуйте, Shmj, Вы писали:


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

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

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Чем? Все также просто показывает.

S>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

Раскрой подробнее каким образом этот фунционал относится UI

Здравствуйте, Janus, Вы писали:

S>>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

J>Раскрой подробнее каким образом этот фунционал относится UI

Ну смотря что такое UI по-вашему. Тонкий моб. клиент, который тупо дергает API сайта — да и сами Web-клиенты сейчас такие — что это как не UI?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Janus, Вы писали:

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

S>20 лет только этим и занимаюсь.
У тебя очень странные вопросы для человека с 20 летнем стажем коммерческой разработки .

J>> Никому не нужно усложнять проект , заказчику вообще фиолетово какой фреймворк внутри проекта ( Иногда бывает что , фреймворк оговорен в ТЗ или есть внешний аудит ) Никто в коммерческой разработке не занимается искусством ради искусства и освоением новых технологий на проектах заказчика . Для этого существуют pet проекты.

S>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?

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

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Janus, Вы писали:

S>>>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

J>>Раскрой подробнее каким образом этот фунционал относится UI

S>Ну смотря что такое UI по-вашему. Тонкий моб. клиент, который тупо дергает API сайта — да и сами Web-клиенты сейчас такие — что это как не UI?

ты не слезай с темы

S>>> На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

где здесь UI ?

Здравствуйте, Janus, Вы писали:

S>>20 лет только этим и занимаюсь.
J> У тебя очень странные вопросы для человека с 20 летнем стажем коммерческой разработки .

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

S>>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?

J>Проблема в качестве итогового продукта и времени затраченном на разработку . У тебя есть фреймворк понятный твоей команде + 100500 наработок (тестов) на этом фреймворке от предыдущих проектов, позволяющие выдать клиенту качественный прототип продукта через условную неделю. Прыгать на граблях не очень благодатное занятие в коммерческой разработке .

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

Здравствуйте, Janus, Вы писали:

J>ты не слезай с темы

J>

S>>>> На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

J> где здесь UI ?

Так мы же не о верстке — а о полном цикле управления всем пользовательским UI-состоянием.

Здравствуйте, Shmj, Вы писали:

S>Вот, саму верстку форм вроде обсудили. Лучшее к чему пришло человечество можно назвать: декларативный UI с функциональной интеграцией.

S> MVC, MVP, MVVM, Redux / UDF, BLoC, Elm / TEA, Clean Architecture и еще что-то, что пока не придумали, но обязательно придумают как назвать

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

Здравствуйте, Qulac, Вы писали:

Q>Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.

Сложность UI в количестве требований, частоте их изменений и соответствующем стейтменеджменте

Здравствуйте, Qulac, Вы писали:

S>>А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?

Q>Это не сложность.

Ну так и у вас такой же аргумент про ui.

Здравствуйте, Janus, Вы писали:

S>>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

J>Раскрой подробнее каким образом этот фунционал относится UI

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

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

Здравствуйте, Janus, Вы писали:

J>

S>>>> На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.

J> где здесь UI ?

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

Здравствуйте, dsorokin, Вы писали:

D>Никогда не понимал смысла запоминания таких слов. Как вы умудряетесь писать код в рамках таких схем? Вы, что, прямо так пишите код и думаете: "ага, здесь такая схема, а вот если бы так написал, то была бы другая"? Как это, вообще, возможно?

Код пишется под задачу, а такие слова нужны что бы выбор был. В противном случае будет вариант "много кода никто не понимает"

Здравствуйте, Shmj, Вы писали:

S> Бек сейчас только отдает JSON, по сути.

А какой цикл жизни у данных перед тем как они в джсон запишутся и уйдут на клиент?

Здравствуйте, Pauel, Вы писали:

P>Код пишется под задачу, а такие слова нужны что бы выбор был. В противном случае будет вариант "много кода никто не понимает"

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

Здравствуйте, Pauel, Вы писали:

P>А какой цикл жизни у данных перед тем как они в джсон запишутся и уйдут на клиент?

Ну если это блог/форум или новостной сайт — то записать в базу, считать из базы, отмапить, проверить права доступа собсно.

Если фин. система — то добавляется еще взаимодействие по JSON с внешним сервисом, возможно повторы, задания по таймеру.

Здравствуйте, dsorokin, Вы писали:

S>> MVC, MVP, MVVM, Redux / UDF, BLoC, Elm / TEA, Clean Architecture и еще что-то, что пока не придумали, но обязательно придумают как назвать

D>Никогда не понимал смысла запоминания таких слов. Как вы умудряетесь писать код в рамках таких схем? Вы, что, прямо так пишите код и думаете: "ага, здесь такая схема, а вот если бы так написал, то была бы другая"? Как это, вообще, возможно?

Многие люди знают только 1 "схему" — и им хватает. Хватает чтобы лет 10 работать, дом построить и т.д. Все знать не обязательно. Т.е. вполен чел может кроме MVVM — ничего не уметь, хоть и слышал — и ему хватает с головой.

Здравствуйте, Shmj, Вы писали:

S>Ну значит знай что бывает и такое — будешь знать что чел. с 20 летним стажем, который только этим и занимался и другого ничего не умеет — может так мыслить. Иногда стаж не решает — Природа первична и она всех наделила разными способностями, ничего стесняться этого. Кто-то вообще дауном родился — и что такого?

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

Здравствуйте, gyraboo, Вы писали:

G>Мой текущий personal jesus — это JMIX-студия.

Нихрена непонятно, но очень интересно )))

Здравствуйте, Shmj, Вы писали:

S>>>Ну значит знай что бывает и такое — будешь знать что чел. с 20 летним стажем, который только этим и занимался и другого ничего не умеет — может так мыслить. Иногда стаж не решает — Природа первична и она всех наделила разными способностями, ничего стесняться этого. Кто-то вообще дауном родился — и что такого?

M>>Да, в общем-то, ничего такого, только если родился дауном, в разработку имхо наверное не стоит лезть, может чем-то попроще ограничится?

S>Это уже каждый человек сам решает чем ему заниматься — бывает по- разному, не смотря на стереотипы: https://ru.wikipedia.org/wiki/%D0%9F%D0%B8%D0%BD%D0%B5%D0%B4%D0%B0,_%D0%9F%D0%B0%D0%B1%D0%BB%D0%BE

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

Где список проектов, сделанных этим челом?

Здравствуйте, Marty, Вы писали:

S>>Это уже каждый человек сам решает чем ему заниматься — бывает по- разному, не смотря на стереотипы: https://ru.wikipedia.org/wiki/%D0%9F%D0%B8%D0%BD%D0%B5%D0%B4%D0%B0,_%D0%9F%D0%B0%D0%B1%D0%BB%D0%BE

M>Правда, что если быть дауном, сложно сыграть дауна?

Довольно сложно. Кроме того он получил диплом бакалавра — это немалое достижение для него. Внес свое имя в WIKI, чего тебе, к примеру, не светит.

Главное не абсолютные достижения а относительные. Помнишь Христа и его слова о том, что вдова, кинувшая в сокровищницу храма 100 рублей — больше всех пожертвовала?

M>Где список проектов, сделанных этим челом?

Он же в другой области работал — в области преподавания.

В области разработки ПО — см. другой человек: https://ru.wikipedia.org/wiki/%D0%94%D1%8D%D0%B2%D0%B8%D1%81,_%D0%A2%D0%B5%D1%80%D1%80%D0%B8

Кстати, вроде кто-то пытался этот проект воскресить и продолжить.

Здравствуйте, Shmj, Вы писали:

P>>А какой цикл жизни у данных перед тем как они в джсон запишутся и уйдут на клиент?

S>Ну если это блог/форум или новостной сайт — то записать в базу, считать из базы, отмапить, проверить права доступа собсно.

Если расчет в том, что посетителей максимум 10 штук в минуту, то примерно так и будет.

S>Если фин. система — то добавляется еще взаимодействие по JSON с внешним сервисом, возможно повторы, задания по таймеру.

Вы хорошо понимаете смысл фразы "цикл жизни данных" ? Вы вместо цикла жизни рассказываете про одну единственную точку.