Oberon space
General Category => Общий раздел => Тема начата: Romiras от Март 18, 2012, 03:24:44 pm
-
В связи с тем, что часто приходится иметь дело с бизнес-логикой, хочу поинтересоваться тем как вы строите архитектуру программы для того, чтобы было просто приспосабливать программу под частоизменяющиеся требования бизнеса.
В проектах работаю с парадигмой MVC. Проблема состоит в том, что, к сожалению, бизнес-логика размазана по всем трём узлам: она присутствует как в моделях и контроллерах, так и в конечном отображении.
Малейшие изменения в определении бизнес-сущности влекут за собой изменения в трёх узлах:
- в моделях - логика запросов к БД (есть небольшая абстрактная прослойка над SQL) с зависимостями между моделями
- в контроллерах - логика обработки входных параметров, подготовка требуемого формата данных и формирование данных
- в отображении - логика отображения объектов
Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?
-
Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?
Это единственный критерий оптимизации? Например, тебя устроит если правки в коде будут самыми минимальными, но при этом всё работать станет в двадцать раз медленнее?
Я, кстати, на работе оптимизирую как раз по критерию производительности. То есть правка в коде может быть достаточно большой (например, шесть недель), главное чтобы потом программа работала быстро.
-
Например, тебя устроит если правки в коде будут самыми минимальными, но при этом всё работать станет в двадцать раз медленнее?
Это похоже на риторический вопрос. Ну, конечно, не устроит. ???
Интересует, есть ли какой-то систематический подход к решению данной задачи. Не уж то всё так тривиально?
Мне приходится иметь дело с несколькими языками разработки (веб-фреймворк) и задача изменения кода согласно новым требованиям порой довольно непроста. Хочется упростить и саму разработку и изменения. Но хотелось бы получить ответы независимо от языка и инструмента разработки.
Самые муторные изменения касаются конечной вёрстки. Потому как и поддержка разных броузеров, многоязычности интерфейса, а ещё и в зависимости от требований клиента.
Всё время думаю о том как внедрить какое-то DSL-средство. Нет, не панацею. Может, несколько разных под разные задачи. Уж больно много параметров в системе и трудно за всем уследить.
-
Что нужно сделать, чтобы сократить количество изменений и свести их к минимуму?
Как правило, изменения связаны с тем, что меняются представления пользователей о том, что должна делать программа. В свою очередь, изменение представлений связано с тем, что у руководителей меняются
- условия/правила работы (изменения во внешней среде);
- объекты (или представления об объектах) управления (изменения внутри);
- методы управления (или представления о методах и их применимости), включая методы получения/обработки/анализа/представления данных/показателей деятельности;
С первым видом изменений бороться невозможно, если, конечно нет возможности лоббировать свои интересы в головной компании или... гос. органах (министерствах, ведомствах, Гос. Думе и пр.). Но надо отметить, что изменения во внешней среде происходят, как правило, не слишком часто.
Со вторым видом изменений бороться нельзя, поскольку такая борьба исключит развитие предприятия. Но... этих изменений можно избежать почти полностью, если программное обеспечение построено на качественных моделях, отражающих семантику каждого объекта управления (исходя из тезиса, что семантика меняться не может).
Третьего вида изменений можно избежать, если программное обеспечение представляет собой набор инструментов для пользователей, а не средства решения конкретных задач. То есть, программное обеспечение не берёт на себя функции специалистов предприятия, но даёт им набор средств для решения их задач.
Если Вы напишите более конкретно, какие проблемы и в какой области Вы решаете, возможно мы сообща сможем найти приемлемое решение... Но с большой долей уверенности можно предположить, что обсуждаться будут, прежде всего, подходы к моделированию и проектированию... и только в незначительной части... к программированию.
-
1. Фирма имеет малый штат. Условно назовём стартапом. Работа с заказчиком происходит практически полностью через менеджера. Менеджер имеет лишь базовые представления о разработке. Большей частью не более чем знание что такое HTML. Менеджер своими словами описывает функциональность В ОБЩИХ СЛОВАХ, тыча пальцем в экран. Гораздо реже показывает снимки экрана или эскизы. Функциональность меняется постоянно, буквально изо дня в день (по очередному изъявлению желания заказчика или же менеджеру, которого заказчик убедил в важности некоторых прибамбасов). Поэтому спецификаций НЕТ. Техническую документацию я веду сам для себя. Другим это неинтересно и не нужно. Нет единого стиля программирования. Каждый пишет как ему угодно. Потом довольно тяжело разбирать чужой код.
2. Код пишется на Ruby на фреймворке Ruby on Rails.
Что касается View, то это длинная история и её нужно рассказывать частями.
Отражаемый на экране текст в большинстве случаев определяет программист (тексты оповещений, ошибок). Английский является базовым языком интерфейса, но он не является родным для программистов. На основе английского производится перевод с помощью схожего с gettext способа (inline).
Например:
"Dear #{user.name}, you have to select at least one option.".t
Такие строки встречаются и в коде и в вёрстке - всюду. Часто программист исправляет орфографические и синтаксические ошибки как свои, так и чужие. И, при этом, вносит другие. Любое исправление переводимого текста требует обновление базы данных перевода. А поскольку эти изменения часты, то перевод сплошь и рядом отсутствует. Хоть переводом программист не занимается - и то хорошо.
HTML View (embedded Ruby):
<% if selected.size > 0 %>
<div><%= sprintf("%d of %d items selected".t, x, y) %></div>
<% else %>
<div class="error_class1"><%= "No selected items".t %></div>
<% end %>
View helper (Ruby):
if @want_pizza and @user.has_enough_money()
render_block(pizza)
else
render_block(start_again)
end
JavaScript:
function save_sub_phones(field_to_update)
{
var fields = $$(".phone_field")
var elem;
var phones=[];
phones = fields.map(function(field) {
return field.id.split("_")[1]+"="+field.value;
} );
$(field_to_update).value = phones.join(";");
Element.hide("phone_orders");
}
Пример я привёл с головы, для общего представления. Эти конструкции типичны в нашем коде.
Здесь видно, что несмотря на то, что используется парадигма MVC, код очень быстро засирается сложными конструкциями, состоящими из смеси Ruby/HTML/JavaScript/Ruby Javascript (RJS-Ajax). Вся логика лежит на технологиях нескольких языков и технологий в разных местах.
3. Модели и контроллеры оставлю на следующий раз, ибо всего сразу не переварить.
4. Хотелось бы, чтоб текстами и вёрстками HTML занимались отдельные редакторы, графики или просто компетентные люди. К сожалению, у меня нет влияния на наше руководство, поэтому нет смысла ждать от них чуда. Поэтому нужно придумать способ отделения данных, вёрстки от кода. Желательно, чтобы основной код был сосредоточен в одном месте и мог быть с лёгкостью изменён, повлияв на генерацию остального кода/шаблонов.
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
-
1. Фирма имеет малый штат. Условно назовём стартапом. Работа с заказчиком происходит практически полностью через менеджера.
Логично. Если с заказчиками будут общаться разработчики... сегодня один, завтра другой... то заказчик сбежит.
Менеджер имеет лишь базовые представления о разработке. Большей частью не более чем знание что такое HTML. Менеджер своими словами описывает функциональность В ОБЩИХ СЛОВАХ, тыча пальцем в экран. Гораздо реже показывает снимки экрана или эскизы.
Должно быть описание продуктов, их функциональных возможностей, дизайна, преимуществ и пр. Менеджеру будет значительно проще работать с заказчиками, отвечать на их вопросы, готовить презентации... Помимо этого неплохо бы собирать отзывы и пожелания от заказчиков, которые уже приобрели продукты фирмы. Эти пожелания должны передаваться руководству фирмы, чтобы планировались изменения с учётом мнения заказчиков.
Функциональность меняется постоянно, буквально изо дня в день (по очередному изъявлению желания заказчика или же менеджеру, которого заказчик убедил в важности некоторых прибамбасов). Поэтому спецификаций НЕТ. Техническую документацию я веду сам для себя. Другим это неинтересно и не нужно. Нет единого стиля программирования. Каждый пишет как ему угодно. Потом довольно тяжело разбирать чужой код.
Довольно типичная ситуация для фирм, которые провели несколько удачных продаж. Если продажи упадут, фирма рассыпется, если вырастут, то... тоже рассыпется... или поумнеет.
Если Вы опишите функциональность продуктов, то можно подумать над тем, почему она меняется так часто... Причина, в принципе понятна, она связана с недостаточной проработанностью исходной модели. Но детали обсудить пока невозможно.
2. Код пишется на Ruby на фреймворке Ruby on Rails.
Что касается View, то это длинная история и её нужно рассказывать частями.
Отражаемый на экране текст в большинстве случаев определяет программист (тексты оповещений, ошибок). Английский является базовым языком интерфейса, но он не является родным для программистов. На основе английского производится перевод с помощью схожего с gettext способа (inline).
Например:
"Dear #{user.name}, you have to select at least one option.".t
Такие строки встречаются и в коде и в вёрстке - всюду. Часто программист исправляет орфографические и синтаксические ошибки как свои, так и чужие. И, при этом, вносит другие. Любое исправление переводимого текста требует обновление базы данных перевода. А поскольку эти изменения часты, то перевод сплошь и рядом отсутствует. Хоть переводом программист не занимается - и то хорошо.
Строки с текстом можно вынести в отдельные файлы, каждому сообщению присвоить идентификатор (константу), который остаётся стабильным независимо от языка общения. Соответственно, переводчики должны поддерживать согласованность всех разноязычных файлов, а программисты пополняют изменяют только файл на своём (русском, например) языке. При этом у каждого разработчика может быть свой вариант файла и свой диапазон идентификаторов.
HTML View (embedded Ruby):
Пример кода я не комментирую.
Пример я привёл с головы, для общего представления. Эти конструкции типичны в нашем коде.
Здесь видно, что несмотря на то, что используется парадигма MVC, код очень быстро засирается сложными конструкциями, состоящими из смеси Ruby/HTML/JavaScript/Ruby Javascript (RJS-Ajax). Вся логика лежит на технологиях нескольких языков и технологий в разных местах.
Для того, чтобы аккуратно разнести это "вавилонское столпотворение", необходимо разобраться с моделью программного обеспечения, эту модель и разделить по интерфейсам в зависимости от возможностей того или иного средства разработки...
4. Хотелось бы, чтоб текстами и вёрстками HTML занимались отдельные редакторы, графики или просто компетентные люди.
Да, это правильное желание. Если оно неосуществимо, то эти функции можно разделить между разработчиками. Так чтобы вопросы дизайна/вёрстки (внешнего представления) решал кто-то один, графику разрабатывал кто-то другой, тексты сочинял третий и т.д. Такое разделение труда иногда кажется избыточным, но ростом объёма работы, оно позволит работать быстрее, а само программное обеспечение выглядит более однородно и эргономично. А главное... каждый специалист подумает над тем, чтобы облегчить свою участь... и, возможно, предложит простые инструменты, способные позволить решать текущие задачи быстрее и в одном стиле. Но если объёмы работ небольшие, то затраты на разработку инструментов не окупятся.
К сожалению, у меня нет влияния на наше руководство, поэтому нет смысла ждать от них чуда. Поэтому нужно придумать способ отделения данных, вёрстки от кода. Желательно, чтобы основной код был сосредоточен в одном месте и мог быть с лёгкостью изменён, повлияв на генерацию остального кода/шаблонов.
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вы думаете в правильном направлении, но начинать надо с модели...
-
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.
-
При всем этом нужно найти способ трансляции требований бизнеса в инструкции по генерации кода работы с моделями и отображением. Если с конечным кодом более-менее ясно, то вот с формализацией бизнеса все гораздо сложнее. А без формализации предметной области автоматизировать процесс никак не получится.
-
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").
-
... а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. ...
Хотел уточнить, Вы на оберонкоре для предприятия ТАКУЮ модель представляли? Или что то другое? (тема называлась содержание деятельности, кажется). Это я к тому, чтобы еще раз перечитать, т.к. сразу только мельком просмотрел из-за нехватки времени, но тема тоже интересует.
-
... а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. ...
Хотел уточнить, Вы на оберонкоре для предприятия ТАКУЮ модель представляли? Или что то другое? (тема называлась содержание деятельности, кажется). Это я к тому, чтобы еще раз перечитать, т.к. сразу только мельком просмотрел из-за нехватки времени, но тема тоже интересует.
Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...
-
Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...
И не получит, и дело не в оберон коре - а в том , что она требует определенного уровня развития восприятия, который свойственен скорее администраторам чем исполнителям...
-
С моделями дело обстоит сложнее. Когда я устроился на фирме, к тому времени монстры-модули, состоящие из десятков атрибутов с многочисленными связями-спагетти уже существовали. Тогда у меня вообще ноль опыта было. При этом, я быстро понял, что их можно было бы существенно сократить без ущерба функциональности.
Но так уж повелось и поменять подход, повыбрасывав ненужное, можно только если все вместе на это будут согласны. Потому что в рефакторинге этого проекта я смысла не вижу - его нужно писать с нуля, учтя прежние неудачные подходы. А при построении этого проекта не было четкого понимание предметной области, так как решили осваивать новый рынок. Все это было сделано без консультаций со специалистами.
Так или иначе, менять модели уже нельзя. Можно лишь проектировать новые с функциональностью старых, а потом от последних избавляться. А на это время не уделяется.
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов. Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта. Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).
-
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов. Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта. Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).
Да вы поняли правильно -конкретные архитектурные решения , всего лишь следствия вашего ПОНИМАНИЯ сущности проблемы... И все остальное верно.... А в конце вы ответили на свой вопрос - хотите облегчить участь свою -а не программистов , которых вполне вероятно что устраивает текущая ситуация (либо по другой причине) -переходите на другой уровень. Весь вопрос в степени личной мотивации - мне видится, что все остальное у вас УЖЕ есть...
)
-
Любая деятельность формализуется (для любой деятельности можно построить формальную модель). Да, на оберонкоре я выкладывал модели основных видов предприятий, но развития тема не получила, и в существо подсистем мы не погружались. Как, собственно, не рассматривался и макроэкономический уровень. А здесь скорее всего потребуется модель одной из подсистем. Хотя автору темы виднее...
И не получит, и дело не в оберон коре - а в том , что она требует определенного уровня развития восприятия, который свойственен скорее администраторам чем исполнителям...
Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов.
-
Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов. :)
:) :) :) Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН ;) :D
-
Мы с Вами понимаем нечто разное, когда говорим о моделях. Вопрос не в том... менять модели или не менять... Вопрос в том, чтобы найти (умозрительно построить) полную и непротиворечивую (формальную) модель деятельности (предприятия или отдела)... деятельности, попадающей под автоматизацию. Это не модель базы данных, не модель программного обеспечения, не та модель, которая существует в головах руководителей... или ваших заказчиков. Все перечисленные модели - это частные проекции, а нужна единая/целая/общая модель... то есть, семантическая модель, отражающая смысл/суть этой деятельности. И тогда, имея такую модель, станет понятно, что надо менять и в программном обеспечении, и в управлении предприятием (то есть, в голове руководителей), и в плане выстраивания отношений с заказчиками... и любые другие частности. При этом не надо впадать в крайности, считая что такая модель либо невозможна, либо очень сложна, либо излишне абстрактна/бесполезна (a'la "сферический конь в вакууме").
Кажется теперь я стал понимать о чём речь. Исходя из сказанного, прихожу к выводу, что это уровень выше программно-исполнительного и он пересекается больше с деятельностью руководства, чем с программистов.
Модели должны быть одни и те же и у руководства, и у программистов. Различие в моделях - это область непонимания друг друга.
Он неподвластен мне - вряд ли я смогу получить от кого-либо непротиворечивую модель деятельности нашего проекта.
Модель Вам никто не принесёт "на блюдечке с голубой каёмочкой"... модель надо построить самому.
Я понимаю, что нужно начинать с уровня выше, но руководство само нечётко понимает происходящие процессы и уж, тем более, не в состоянии формализовать его. Являюсь самым младшим звеном в этой цепи. Должности "архитектора ПО" у нас нет.
Да, не так важно, понимает руководство или нет, важно, чтобы понимали Вы и Ваши коллеги. Понимая предметную область можно работать на опережение понимания руководства, на облегчение собственной работы.
Построение семантической модели деятельности мне кажется довольно интересной темой, однако я задавал вопрос с намерением облегчить участь деятельности программистов (моей в частности).
Так об этом и речь. Ну, в качестве примера... Создание ERP систем занимает 3000-8000 чел. лет. А можно тоже самое (с запасом) сделать за 10-20 чел. лет. Вот и соотнесите затраты труда программистов, количество согласований, переделок... и прочих нервных окончаний...
Но, поймите правильно, я Вас ни к чему не призываю... хотите идти "широкой дорогой" проб и ошибок... идите.
-
И дело сдесь не в простоте а в наличие степени развития достаточной для восприятия курса, без нее получается в лучшем случае банально заучивание материала (слова понятны - смысл нет)
-
Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов. :)
:) :) :) Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН ;) :D
Пусть будет так. Не навязываю...
-
Не знаю... не знаю... Модели очень простые, я читал лекции студентам 3-4 курса, никаких трудностей с пониманием у них не возникало. Наоборот, они жалели, что узнали о системном подходе к экономическим моделям слишком поздно, когда, собственно, экономику им уже отчитали. Вместо заучивания приходит понимание основополагающих процессов. :)
:) :) :) Не знаю... я вот помню тоже жалел, что механику на первом курсе у нас читали не по Ландау.... правда это было ПОСЛЕ того когда курс начального уровня (по Савельеву, Сивухину, Матвееву ...) был прослушан и частично УСВОЕН ;) :D
Пусть будет так. Не навязываю...
Аминь
-
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
-
Я постоянно нахожусь в процессе поиска приемлемого решения данной проблемы с тем, чтобы его приняли и другие разработчики. То есть оно должно помочь нам снизить трудозатраты при небольших усилиях.
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.
-
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.
Гм. А можно пример той самой мифической семантической модели предметной области?
PS. Никогда не понимал разделения на динамический и статический контент.
-
Вообще да. Задачка злободневная. Особенно удивлен, что она столь остро стоит даже при использовании ROR (это вроде как один из самых человечных веб-фреймворков, если не самый человечный, и цена равная 20ти кратному замедлению уже заплачена).
Вообще, фреймворк RoR ненамного отличается от других фреймворков. Снаружи кажется всё красиво, поди даже, аккуратно. А, глянь внутрь - понимаешь, как всё непросто. RoR - это сахарная надстройка над генерацией динамического контента. Принципиально она ничего не решает. Рутинной работы - завались. Увеличение производительности можно получить только при разумном использовании.
Хотелось бы иметь фреймворк, в который загоняешь ту самую семантическую модель предметной области, а на выходе получать динамический контент, расчитанный на использование разных видов клиентов (веб-броузерами, удалёнными сервисными серверами и прочим). Ну а задачей программиста была бы подгонять генерацию под конкретные модули-реализации.
Гм. А можно пример той самой мифической семантической модели предметной области?
PS. Никогда не понимал разделения на динамический и статический контент.
Вопрос по примерам семантической модели - не ко мне. Для меня они являются сферическими конями на сей момент. Я просто "подхватил" идею.
Статический контент - это простой, безусловный HTML. Он не подвержен влиянию никаких внешних параметров при запросе серверу и времени.
by valexey: дальнейшее обсуждение статического и динамического контента перенесено сюда по просьбе автора: http://oberspace.dyndns.org/index.php/topic,209.msg4314.html
-
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?
Получилась бы нормальная клиент-серверная система.
-
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?
Получилась бы нормальная клиент-серверная система.
И вся бизнес-логика будет сидеть на клиенте? А ещё добавить сюда постоянную борьбу с совместимостью браузеров...
Это ведь однозначно тихий ужас будет: как в отношении разработки, так и в отношении поддержки.
-
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?
Получилась бы нормальная клиент-серверная система.
И вся бизнес-логика будет сидеть на клиенте? А ещё добавить сюда постоянную борьбу с совместимостью браузеров...
Это ведь однозначно тихий ужас будет: как в отношении разработки, так и в отношении поддержки.
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.
Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
-
Возвращаясь к топику - вы не пробовали отдавать просто не генерируемую html'ину с намертво зашитым жабаскриптом, который бы уже после загрузки выдергивал бы запросами из сервера необзодимую информацию и строил бы на стороне клиента страничку?
Получилась бы нормальная клиент-серверная система.
И вся бизнес-логика будет сидеть на клиенте? А ещё добавить сюда постоянную борьбу с совместимостью браузеров...
Это ведь однозначно тихий ужас будет: как в отношении разработки, так и в отношении поддержки.
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.
Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
В таком случае, нужно придумывать свой веб-каркас. Только для этого нужно сначала проработать идею. С наскоку такие вещи не делаются.
-
Сама логика, подозреваю, пишется единообразно на всех браузерах. Не единообразно пишется рендеринг/манипуляция DOMом. Собственно тот же gmail работает именно так. И, не к ночи будет упомянут, вконтактик тоже.
Алсо для того чтобы не бороться с жабаскриптом есть например GWT.
В таком случае, нужно придумывать свой веб-каркас. Только для этого нужно сначала проработать идею. С наскоку такие вещи не делаются.
Да. И лучше вначале посмотреть как это сделано у других. Я не верю что нет ни одного веб-фреймворка который бы этот самый ajax не использовал бы таким способом по полной программе.
Тут собственно есть ровно одна проблема - это поисковики. Они хотят только статику (клиентскую статику, на сервер им плевать конечно же). Но на эту тему у гугла есть решение: http://habrahabr.ru/company/roundlake/blog/140291/
-
Да господа это оффспин - на со
-
Да господа это оффспин - ИМХО показатель порочности практики построения решений на основе лишь "семантики". (сорри , с предыдущим сообщением, у меня браузер глюкнул)