Разработка в Lotus (очень старая тема)

[Kee_Keekkenen]

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

2Mihal

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

 

[Fossil Code]

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

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

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

А это бывает. Это даже можно назвать системой. Всю жизнь "влюблялся" в языки, программы, превосходные сами по себе, которые в конце концов оказывались вытесненнымиагрессивным "черт-ти чем". Это я про C++ против Модулы, Парадокс против Клариона, IE против Нетскейпа и прочая и прочая и прочая. Объяснение найти можно, например, здесь:

Ссылка скрыта от гостей

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

Боюсь, что здесь ответ тот же, что в предыдущем пункте:

Ссылка скрыта от гостей

 

[Kee_Keekkenen]

2K-Fire

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

 

[Fossil Code]

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

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

 

[Mihal]

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

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

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

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

 

[Kee_Keekkenen]

db.search здесь не является узким местом.. - узкое место сортировка...
вьюхи хорошо, однако их рефрешить надо перед использованием..

а какова ваша идея сортировки строк, с цифрами то все просто ?

 

[K-Fire]

<!--QuoteBegin-Mihal+9:02:2007, 14:35 -->
<span class="vbquote">(Mihal @ 9:02:2007, 14:35 )</span><!--QuoteEBegin-->А почему бы не построить вьюху, в которой первая колонка - сортированая. Причём значения разбиты на слова (@Trim(@Explode(field1;" "))).

[snapback]55634" rel="nofollow" target="_blank[/snapback]​

[/quote]

Такое катит только если строка поиска - отдельное слово. Если это часть слова, или 2 слова то уже работать не будет.

По идее db.Search() будет оптимальным способом получить коллекцию документов содержащих строку поиска.
Сортировку строк быстрее чем некая специализированная функция сделать вряд ли можно.

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

 

[Kee_Keekkenen]

да уж, например выборка по полю ФИО - отобрать всех женщин по ключу "вна" или мужчин по "вич"

 

[Mihal]

Такое катит только если строка поиска - отдельное слово. Если это часть слова, или 2 слова то уже работать не будет.

Протестую! В постановке было сказано "поиск вхождение этого слова в...". Не "этого сочетания симовлов", а "слова"! Так нечестно!

В принципе, лучше использовать поиск по ключу во вьюхе. Просто так быстрее работает. И рефрешить её надо если Вы подняли объект NotesView, что-то туда добавили. а потом хотите добавленое там найти. А так, по идее, отрефрешиться само. И работать будет точно не медленне чем db.Search.

Насчёт запихивания в фолдер - не уверен. Если два человека замутят такое одновременно? Что ж, персональные фылдеры плодить? ИМХО, вариант с беганьем по всем отсортированым и проверкой наличия в коллекции с помощью NotesDOcumentCollection.GetDocument самый лучший.

И, кстати, чем сортировка строк отличается от сортировки чисел? Операция сравнения есть? Есть. В чём проблема-то?

И ещё, почему не самописная функция будет лучше? Она работает на тех же алгоритмах .

 

[Kee_Keekkenen]

гм.. про операцию сравнения я как-то не подумал в плане сортировки

про "слово" я неправильно выразился конечно же это сочетание символов, жутко ИЗВИНЯЮСЬ за то, что ввел в заблуждение

 

[Mihal]

2K-Fire

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

Что бы проверить производительность надо написать код на скрипте. Потом написать его "клон" на Яве (большинство классов имеют свои аналоги) и запустить енто дело по очереди с секундомером. Мы оцениваем ПРОИЗВОДИТЕЛЬНОСТЬ, а не "фичи" языка. Например 1000 раз запустить получение текущей базы данных и создание в ней документа.

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

 

[LuMee]

Пардон, если повторяю уже высказанные кем-то мысли, но все же

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

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

Ну, начнем с того, что ГУИ-программирование в Офисе есть, причем очень цивильное (в отличие от Лотуса). Сам лично видел очень некислый и действительно функциональный софт с удобным графическим интерфейсом, построенный в Экселе И потом, в Офисе хотя бы отчеты есть, в лотусе так до сих пор и не сделали...
Рассматривать же Лотус как "набор сервисов для документов" ИМХО просто уныло. Кому нужна система для работы с документами за такие деньги? Куда дешевле будет соорудить такой "набор сервисов" на базе MS Office + Exchange/Sharepoint/далее-по-необходимости.
Так что вполне естественно, что от Лотуса хотят нечто большее, чем просто систему тасования документов между серверами, хотят иметь возможность данные, хранящиеся в этих документах, не просто гонять туда-сюда, но и обрабатывать. И вот в ходе реализации этих нехитрых желаний регулярно возникают всевозможные трудности, когда очередная гениальная идея IBM'овых программистов вынуждает разработчика искать обходные решения а-ля "автогеном через заднее место" (вспомним ту же многострадальную встроенную вью, из которой надо получить выбранный документ: IBM'овцы решили, что это нафиг никому не надо, и до сих пор в это верят, а народ мучается ).
Другое дело, конечно, что нередко тут и заказчик перегибает палку, желая от Лотуса невозможного и отчаянно не желая понять, почему, собственно, это невозможно...

 

[Kee_Keekkenen]

в общем, я тестировал на одной и той же выборке более 10000 документов..
методы в языках, конечно же, различные в скрипте использовал быструю сортировку и код скрипта еще далек до оптимального...
в целом картина производительности по моим "неоптимальным" решениям на джаве и скрипте
выглядит так в относительных величинах
локально скрипт/джава 1сек / 2 сек - скрипт и джава агент запускаются в локально БД
сервер скрипт/джава 8 сек / 4 сек -
скрипт и джава агент запускаются на сервере

 

[nor]

Для: K-Fire

Я, к примеру, вообще не понимаю сути полемики. Есть конкретная предметная область - Лотус. Есть конкретные пользователи данной области - клиенты, программисты, мэнеджеры... люди. Продукт востребован на рынке? Да - Нет? Да.

Мне все это больше напоминает субъективные жалобы на потраченные зря человеко-часы. Не нравится продукт? Мне тоже. Иногда я готов его разнести в клочья, если бы такая возможность существовала. Много багов? Продукт не соответствует теперяшним новым технологиям и техникам программирования? Да. Да. Данный спор также глуп, как, например, и спор о том, какая OS лучше - Линункс или Виндовс.

Но. Хочу обратить внимание на следующие очевидные для всех моменты:
1. Никто никого никогда под страхом смерти или невыносимых пыток не заставлял программировать на Лотусе. Сегодня есть альтернатива в виде .Net, Java, РСУБД... другие платформы, другие языки, другие техники. В удовольствие работайте, было бы желание и умение.
2. Несмотря на все минусы продукта, он живет, если я не ошибаюсь, c 1987 года. Можете мне перечислить какие-либо продукты, программы, игры, технологии, которые имеют такой же стаж в наше время, когда срок в 1 год уже является довольно таки существенным для сферы IT. Не сомневаюсь, что сможете, но не думаю, что ваш список будет большим.
3. (копий ос виндовс установлено на порядки больше, чем линукса). Рынок диктует свои условия для всех. Когда-нибудь Лотус умрет, но не в этом и не в следуещем году. И тогда можно будет посидеть за чашечкой кофе, тыкаясь в Java, и с язвительной ухмылкой (а может быть наоборот - с ностальгической доброй улыбкой) вспомнить Lotus.

 

[Constantin A Chervonenko]

2. Несмотря на все минусы продукта, он живет, если я не ошибаюсь, c 1987 года

C 1984 oн уже Lotus, PLATO был еще раньше

 

[K-Fire]

Да мне обидно просто что Лотус такой корявый Большинство технологий прогрессируют с ужасающей быстротой, лотус остается без изменений уже лет 10. Вот в Ганновере IBM делает клиент на основе Эклипса, это значит Java, Java, Java... Если полностью писаный клиент на Java не будет поддерживать Java везде нормально, то я просто убью себя

 

[Constantin A Chervonenko]

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

Шо ты хошь? Общество потребления. Продукт должен устаревать/выходить из моды/ломаться немедленно после покупки. Иначе потребитель больше ничего не купит.
Очень мало кто может позволить себе делать качественные вещи. Вон даже фирму РоллсРойс кто-то сожрал (пиндоссы?). Если машина будет служить 20 лет, кто тогда купит новую?

 

[K-Fire]

Я тихо фигею. Полазил в выходные по блогам разработчиков лотуса 8. Мало того что это (если по блогам судить конечно) женщины за 40!!!, то они похоже еще и супер-профессионалы.
Вот например как будет выглядеть SL в новой версии:

Ссылка скрыта от гостей

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

 

[Fossil Code]

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

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

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

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

 

[Mihal]

Разработчики Лотуса, как известно - индусы .