Чтобы не терялись свиньи девятого уровня

Sep 15, 2012 21:29

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

Есть такая замечательная архитектура REST (REpresentational State Transfer ( Read more... )

rest, проектирование систем

Leave a comment

Comments 26

gineer September 16 2012, 13:44:26 UTC
Вот интересно.
А сколько сейчас в этом комюнити людей,
чтобы ставить такие вот широкие задачи? :)

Reply

sbobrovsky September 16 2012, 16:44:37 UTC
23 писателя и 45 читателей, но это к делу не относится, все равно никто что-то конкретное делать не будет:)

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

Reply

gineer September 16 2012, 17:10:57 UTC
\\нужна интересная инновационная идея

Идей -- полно. :)))
И по-дешовке. :)))

Reply

sbobrovsky September 16 2012, 17:17:36 UTC
Ну так давайте)

Reply


Модели, сценарии fractaler September 17 2012, 09:41:24 UTC
Имеет смысл вначале создать хотя бы простенькую модель мира, в которой сценарии будут в единой системе. Тогда многое упрощается и многое становится интереснее (особенно, если знакомо носителю модели).

Reply

sbobrovsky September 17 2012, 16:44:26 UTC
Если с технической т.зр., облачная модель вполне подходит, SaaS например.

Reply

fractaler September 18 2012, 07:08:58 UTC
Хороший инструмент, конечно, залог быстроты и удобства. Но дать "молоток", это ещё не значит, что будет построен дом. "Дом" то всё-равно делать придётся. А кем и по каким принципам?

Reply

sbobrovsky September 18 2012, 17:39:03 UTC
Кем -- программистами. По принципам, которые например мы тут обсуждаем:) Или о чем-то другом речь?

Reply


lseder September 18 2012, 14:43:57 UTC
про масштабирование исполнения понятно. переложить часть расчетов на клиента.

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

Reply

sbobrovsky September 18 2012, 17:44:22 UTC
Если система спроектирована "по Алану Кею", то по хорошему багов в ней быть не должно (ну кроме как в мелкой логике), так как ключевые моменты реализуются прозрачно, а закодированы выразительно. И внесение изменений в архитектуру по этим причинам тоже должно протекать гладко. В идеале)

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

Reply

lseder September 19 2012, 07:27:22 UTC
>было серверную логику распараллеливать
распаралеливать исполнение кода ?
или процесс написания кода ?
или процесс проектирования модели программы, а с ним и сам код.

возьмем пример с товарищей системных инженеров.
исполнение в рамках: срока (который они сами сказали), бюджета, списка требований.

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

Reply

sbobrovsky September 19 2012, 17:17:53 UTC
распаралеливать исполнение кода ?
или процесс написания кода ?
или процесс проектирования модели программы, а с ним и сам код.
Да, да, да!
Только акцент не столько на распараллеливании, сколько на асинхронности, в стиле ФП (параллелизм тут уже естественно проявится). Я об этом как раз следующий пост пишу.

Reply


(The comment has been removed)

sbobrovsky November 15 2012, 18:10:33 UTC
REST скорее как концепция имеется в виду, когда клиент достаточно толстый, и сервер может обойтись как раз чистым CRUD-ом.

С технической т.зр. возможно лучше сразу брать что-то готовое, пусть само оно нечто REST-подобное и реализует. Этим летом делал питерцам видеочат на миллион одновременных пользователей (так было в ТЗ:), дабы не заморачиваться, взял хороший ORB, причем для .NET, рекомендую: http://www.themidnightcoders.com/products/weborb-for-net/overview.html

Reply

(The comment has been removed)

sbobrovsky November 19 2012, 17:35:07 UTC
Да, это точно. Сложновата она оказалась для мэйнстрима.

Reply


Leave a comment

Up