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

Во-первых, складывается (давно сложилось) впечатление, что люди, приходя в Лотус из традиционной разработки (C, Pascal, etc.), подсознательно не желают отказываться от своих умений и привычек, сопротивляясь новой среде с непохожей идеологией. Благо Лотус предоставляет им нишу под названием Lotus Script. Честно скажу, что лучшего объяснения "засилью" скрипта не представляю. Доводы о мощи скрипта по сравнению с формулами и т.п. , хоть и верны, но не слишком убеждают. Почему же в таком случае не С++ и Notes API? Потому, что для каждой работы есть свой инструмент: на мух -- с мухобойкой, на медведя -- с ружьишком, ну a на танк уже с С++... Это рассуждение плавно подводит нас к вопросу о том, какой же инструмент есть в Лотусе и для какой же работы он (инструмент, да и сам Лотус) предназначен? А это уже вопрос второй, имеющий явственный схоластически-философский оттенок...

Во-вторых, невооруженным глазом видно, как народ, воспитанный на классических языках программирования и впитавший сызмальства идею реляционной базы данных (Что, бывают другие!?), отчаянно пытается сделать на Лотусе то, и так, как он к тому привык и знает... Что греха таить, 10 лет назад, начиная работать с Лотусом (принимаю поздравления по поводу юбилея), около полугода переживал болезненный период ломки стереотипов и "врастания" в Лотус, его, в широком смысле слова, инструментарий и идеологию. С тех времен осталась формула "если это тяжело и никак не получается сделать -- это не Лотус". То есть, нужно искать "ассимметричный ответ", который легко решит вопрос другим образом, естественным для Лотуса. Это и есть (была) главная проблема: должно быть именно так, а иначе я не представляю и вообще, по-другому не бывает, потому, что не может быть никогда. Для признания существования этой проблемы нужны серьезные усилия. Лично мне помог такой случай: наряду с Лотусом, мы, как ярые новообращенные, поставили себе Lotus Suite взамен MS Office. Что тут началось! Даже не представлял, что редактирование текста может быть иным! Если Вы тоже "даже не представляете" -- попробуйте, не пожалеете. Именно то, что нужно для ломки стереотипов...

В-третьих, мне очень понравилась фраза какого-то зарубежного разработчика "За что я люблю Лотус? Представьте, приходит ко мне пользователь и говорит, что ему нужно не так, а эдак... И стоит над душой, возле меня, сложив руки, смотрит, пока я ему это не сделаю!" Представьте и вы: в какой иной среде, для какого продукта такое возможно?! Лотус сам по себе -- сплошная RAD. И не даром Лотус говорит о методологии "протоциклирования". Кстати, раньше было гораздо интереснее документацию к новым релизам читать: всегда было там что нибудь "воспитательное" про идеологию, методологию, правильное применение... И не даром у Лотуса, если не устарели цифры, что помнятся, второе место в мире по установочной базе после MS Office. Лотус, он гораздо ближе к офису, чем к монолитному высокоспециализированному приложению, целиком наваянному на ЯВУ. Соответственно, и способы решения одной и той же задачи для Лотуса и такого приложения -- разные. Но, как упоминалось, многие программисты пытаются работать на Лотусе, стремясь получить то самое монолитное приложение с высокоспецифичными и тесными взаимосвязями внутри своего проекта. Не всегда это правильно.

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

Вот.

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



Ну, не знаю. У мя объёмы разработок тока растут. И новые релизы Лотуса клепаются регулярно. Вон, Гановер на подходе.

А Вы, я так понимаю, все свои выводы строите на 5-ке?

Не имеет значения на какой версии делать выводы 5ка, 6ка и 7ка не имеют значительных отличий.



Да, очень хочется уже пощупать эту версию. Очень надеюсь что там будет хоть что-то новое.

Так-так-так! Придется для начала высказываться краткими репликами.

Для K-Fire: Первое, о чем сразу захотелось попросить, -- это показать хоть одну _современную_ парадигму, которая бы продержалась _хотя-бы_ 15 лет!

Для Wanderer: Ну совсем недавно прочел, что на западе набирает силу обратная волна -- компании начинают набирать айтишников, чтобы уйти от зависимости от аутсорсеров.

Для Lu Mee: У меня 5-рка тоже работала весьма неустойчиво. Не сервер, связка клиент-дизайнер. Но на 5,0,11 стало полегче. Это, если не ошибаюсь, был один из ключевых релизов.

И повторюсь, меня не оставляет впечатление, что от Лотуса хотят (и делают на нем) не вполне то и не вполне так, как предполагает сам продукт и его "парадигма". Ну неудобно шлицевой отверткой крестовой винт закручивать!

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

Считаю, что Лотус изначально продукт _офисного_ класса. Причем, главным образом, на уровне программируемого текстового редактора. Почитайте историю Лотуса, чтобы в том убедится. И оцените, сколько сервиса наворочено вокруг _документа_, созданного в этом продукте. И сравните, с МС Офисом. Так вот, по-моему, Лотус так и следует воспринимать и использовать: как набор сервисов для документов. А здесь такие горизонты...

Естественно, в лотусе есть классические элементы и БД и терминологии БД. Но именно классические. Но лотус -- не СУБД общего назначения! Он использует собственные БД для хранения собственных докумнтов. Представьте себе, как нужная Вам задача решалась _до компьютеров_, при помощи бумажных документов, процедур регистрации, подшивки, поиска в архивах и т.п. И убедитесь, что это один-в-один, и очень легко ложится на Лотус.

Если же Вам нужно (или просто привычно) работать не с документами, а с _информацией_, которая из документов может быть извлечена, и, к тому же, писать пользовательские приложения с произвольным интерфейсом, для манипуляции этой _информацией_, то меняйте Лотус на РДБ, пересматривайте свои привычки, но сам Лотус -- абсолютно ни в чем не повинен и не дефектен!

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

Клиент-сервер + РСУБД



А какие горизонты? С Оффисом он работает только через OLE. Интеграция лотусовых данных с внешними какими-то решениями - не знаю удачных примеров реализации. Т.е. почти что вещь в себе.

Тут подумал, может быть действительно перестать предлагать лотус как middleware решение, а исключительно как хранилище документов. Только боюсь что клиенты скажут: а у нас же есть Оффис, зачем нам лотус?

Ой, не смешите! Если не врет тот же IBM, то Лотус был _первой_ коммерческой системой, реализовавшей технологию клиент-сервер! Концепция РСУБД, если не подводит общая эрудиция, появилась несколько позже Лотуса, но это не принципиально, важно то, что эти обе концепции суть старые, но не утратили своего значения до сих пор. А я спрашивал именно про новые парадигмы.



А что, Лотус должен работать с МС Офисом как-то иначе? См. Лотус SmartSuite для тесной и легкой интеграции.

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

А) Существует масса задач, эффективно решаемых при помощи Лотуса и его сервисов. Весь фокус в том, что задачи простые, решаются на "раз", но они очень важные для заказчика...

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

Словом, выбирайте, что больше нравится.



А ведь верно: Лотус это никакое не middleware. Это самостоятельный продукт с массой сервисов, представляющий собою распределенную среду, которую можно населять лотусовыми приложениями с возможным интерфейсом к стандартному вебу, почте, РДБ.

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

Mihal, вот код джавы, интересно узнать твое мнение по поводу его оптимизации


Сообщение отредактировал Kee_Keekkenen - 9:02:2007, 11:54

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

Это меня печалит очень сильно. Я недавно спросил коллегу, который на J2EE-технологиях сидит, спрашиваю: а вот есть у вас это, а есть то? Он мне говорит: есть и это, если и то. Простые и бесплатные библиотеки, легко интегрируются. Так что скоро может оказаться так: мне надо написать приложение для которого я бы взял лотус как 100% подходящее решение. Но я использую совсем другие технологии, потому что они дешевле, быстрее и надежнее. А IBM в своем роадмапе ясно сказал - лотус после Ганновера будет лишь подсистемой для Websphere. Может конечно передумают...

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

Вот почитал и возник вопрос: а полнотекстовый поиск чем-то не устраивает? Быстрее, чем он вряд-ли найдется метод. А доступ к нему -- хотите из стандартного ГУИ, хотите, из скрипта или той же Явы.

И рядом скриптовый код. Мы ж сравниваем, типа.

Ну скорее всего Kee_Keekkonen имел в виду следущее: идити и напишите сами функцию сортировки строк, а я возьму Java.Utils и оттуда заюзаю нужный мне метод

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

2Mihal

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

Простите, этот пассаж мне не совсем ясен. Мы, фактически, сравниваем Лотус только с РДБ + клиент на С++ или Дельфи? И, по-моему, это сравнение ног с руками. Какие другие продукты и что они делают лучше? И что означает "слишком большие усилия" для того, что Лотус делает хорошо? Ой, нет, поясните...



А это бывает. Это даже можно назвать системой. Всю жизнь "влюблялся" в языки, программы, превосходные сами по себе, которые в конце концов оказывались вытесненнымиагрессивным "черт-ти чем". Это я про C++ против Модулы, Парадокс против Клариона, IE против Нетскейпа и прочая и прочая и прочая. Объяснение найти можно, например, здесь: http://www-users.cs.york.ac.uk/susan/joke/cpp.htm



Боюсь, что здесь ответ тот же, что в предыдущем пункте: http://www-users.cs.york.ac.uk/susan/joke/cpp.htm

2K-Fire

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

Сообщение отредактировал Kee_Keekkenen - 9:02:2007, 12:32

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

А почему бы не построить вьюху, в которой первая колонка - сортированая. Причём значения разбиты на слова (@Trim(@Explode(field1;" "))). Есть второе представление, тоже сортированое. Но только по тому итему, который нужен для сортировки результата. На основании введённого слова шаримся по первому представлению. Получаем коллекцию ViewEntries'ов (GetAllViewEntriesByKey, кажется).
Потом начинаем бегать по второй вьюхе (тупой перебор). Берём энтри и смотрим его наличие в коллекции (одним методом класса NotesViewEntryCollection). Есть? Записали значение в массив. Нету? Идём дальше.

Оч. реально, что такой вариант будет работать быстрее чем с помощью DB.Search (по крайне мере перебор энтрисов проходит оч. быстро). С одной стороны, казалось бы. много лишних просмотров, но, с другой стороны, время на сортировку не тратится.

Вы, похоже, намекаете на отсутсвии сортировки массива в лотусе, да? Ну, у всех, в принципе, уже есть функция, которая сортирует массив (причём не методом выбора, а, скажем. быстрой сортировки). Можно и похожим на ваш алгоритм. С ThisDB.Search. Но только не сортировать, а брать из второй вьюхи документы и смотреть наличие документа в коллекции после поиска.