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

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

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

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

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

Вот.

Все-таки Михал был прав про молоток и отвертку...

Наша компания - не смейтесь - продает ПО, написанное на Oracle!!!
Тут есть реально крутые ораклоиды!

НО! - весь внутрикорпоративный ДО, включая и подготовку поставок для клиентов, у нас на лотусе.
Еще есть вопросы?

Для: GROMILA - аналагична, без обид. Просто интереснейшая ветка получилась Приятно почитать подескутировать. Но вот это дискусия превращаеться в обсуждения вроде nVidia VS ATI
Pentium VS AMD и т.д. Вы я так понимаю больше приверженец РСУБД, это видно из

посему Вы и будете считать Лотус не подходящим и т.д.

Всем желаю отлично отдохнуть на выхадных

Уж если это не неприязнь, и даже не откровенное отвращение, к Лотусу, да еще перенесенные на тех, кто Лотусом доволен и осмеливается открыто обсуждать его достоинства...

...Тогда я совершенно не понимаю ни русского языка, ни людей. Ни в малейшей степени.

я просто применил термин ТРАНЗАКЦИЯ, чтобы обозначить широко известную проблему, которая может возникнуть при выполнении согласованных изменений, но я ее не реализовывал в том виде, как это сделано в РСУБД

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

Это довольно трудоемкий, но единственный нормальный выход, спасающий от сбоев!!!
Это то, о чем не приходится задумываться в РСУБД

О! Вот так бы и начинали сразу! С правды да в глаза! А то "организация, должность, сотрудник, функционал". Вот так бы сразу!

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

P.S. Предлагаю разжаловать и оранжевый цвет с надписи убрать!



А Вы уверены что это был Лотус?

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

PS. Все же вместо криков хотелось бы увидеть правильное решение поставленной задачи от вас.
чтобы реально ощутить RADость

Всё-таки у вас мОзги заштампованы. Трудно вам будет с non-1st-normal-form базами. А это - светлое будущее всех СУБД.
И с распределенной обработкой ничего никогда у вас уже не выйдет, можете не оправдываться.

PS: загнивающие считают, что после 30 лет человек уже необучаем

Трудности при разработке под РСУБД мне тоже известны.
Во многих задачах сбора информации предпочту лотус.



Нет, я просто не могу быть столь категоричным, чтобы говорить, что лотус не подходит вообще.
Просто у него есть ощутимые проблемы, о которых хотелось бы информировать читателей первого сообщения данной ветки.

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

Я - поругал, старался на конкретных примерах.
Вы - похвалили, правда вяловато и против правил порой.

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

В общем, действительно, удачных всем выходных.


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

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

Надо список подразделений - делаю вьюху без дубликатов (галочка на, кажисть, предпоследней закладки). И использую как справочник. Можно сделать отдельный справочник. То такое. Чуть помучавшись смогу забить иерархию во вью. Ну и всё такое.

Ну эт так, навскидку.

P.S. И я не кричу! Эт у меня голос такой!

Сообщение отредактировал Mihal - 1:12:2006, 18:35

Еще раз для непонятливых:
СУБД заточены под централизованную обработку. Только при этом условии реализуются преимущества реляционной модели (нормализация) и механизмов взаимного исключения (транзакция). И не тычьте в "распр."СУБД с двухфазной транзацкцией! Необходимым условием 2ФТ является on-line доступность всех частей базы. И чем это отличается от N винчестеров на одном (2-3) шлейфах SCSI?
Так что "распределенная база данных" это та, где в произвольный момент времени невозможна 2х-фазная транзакция. А не та, где 2 винта нах-ся в разных помещениях.

Lotus заточен под распределенную обработку. Поэтому в него "не положили" транзакцию (преднамеренно!), поэтому ему вредна нормализация. Зато его база non-1st-normal-form (мультиполя), что частично компенсирует неизбежную избыточность данных. А "теговый" способ хранения данных (в отличие от табличного) не только увеличивает рыхлость хранения. Именно он и является основой RAD-ости (не требуется реорганизация таблиц по каждому чиху в дизайне). Эквивалентом в СУБД является триплетная модель. Но там оно выходит еще рыхлее, чем в LND и еще медленнее

Это я прошелся только по хранилищу. Такие прелести LND как встроенная VM клиента, мультиплатформный UI (все это под СУБД надо писать самому), встроенные коммуникационные механизмы и др. чудеса оставил за кадром.

В др.разрезе:
СУБД - специализированный инструмент. Они замечательно исполняют свою главную функцию - хранение и выборку хорошо структурированных данных.
LND - "все в одном" (это опять на мельницу RAD)

И т.д..

Сообщение отредактировал Constantin A Chervonenko - 4:12:2006, 08:47

Как жаль что так поздно увидел эту тему, предлагаю ее продолжить!

Прочел в ней большое количество мнений, с которыми категорически не согласен.

Какие КРУПНЫЕ недостатки лотуса я могу назвать:
1. ПАРАДИГМА архитектуры Лотуса устарела лет на 15. Несмотря на то что в нем до сих пор есть элементы (типа нахождения дизайна и данных на сервере в одном месте) очень удобные и продвинутые.
- Отсутствие высокопроизводительной БД
- Отсутствие нормальных средств работы с XML и web
- Ужасная бедность GUI
Всё это плата за идиотскую никому не нужную совместимость со старыми версиями. Которая к тому же глючит очень неприятно во совершенно нелогичных местах.

2. По данным IBM лотус имеет ~150млн установленных рабочих мест. Вы что, думаете, что на всех этих раб. местах используют лотусовые приложения кроме почты? Только почту и используют. Почему, если Lotus такой супер-распрекрасный RAD? Потому что средство не расчитано на создание серьезных приложений. Конек лотуса - документооборот. Даже это единственное он делает с трудом.
В IBMе сидят грамотные маркетологи, они позиционируют лотус только как средство групповой работы (т.е. почта, мессаджинг, и т.п.). Как средство разработки они его не позиционируют вообще.

3. Сборная солянка языков программирования: LS (функциональное программирование онли), Java (которая работает только в агентах, плюс использует свою ibm-овскую устаревшую JVM), JavaScript, поддержка которого меня вообще вводит в тупик, @-формулы, на которых невозможно писать логику.

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

P.S. Достоинства у лотуса конечно же есть. И их много. Но они все в очень большой степени нивелируются недостатками к сожалению

Эх, как я обожаю конструктив! Ну шо, уважаемы, K-Fire, начнём?

Для начала ряд вопросов:
1. В чём Вы измиряете производительность БД?
2. Откуда у Вас статистика о способах использования Лотуса? Я поверить не могу, что данные о подавляющем использовании Лотуса во всём мире только как почты взяты от фонаря.
3. Интиресно, как вообще бедность GUI может быть связана с обратной совместимостью? Думал-думал... Не придумал...
4. Какие существуют критерии "нормальности" средств работы с XML и Web (ну, в вашем понимании)?

Да, кстати, а в чём заключается устаревание парадигмы? Я чегой-то думал, что парадигма бывает либо подходящей под определённую задачу, либо нет. Но устаревшей... Как это?

Для: K-Fire


1. А какая "ПАРАГДИМА" актуальна на 2007 год? Можно поподробнее?
2. Сравнение производительности nsf относительно каких критерикв проводилось? И кем?
3. Lotus не предназначен для работы в web. Это его не первоочередная задача как продукта, а дополнительная возможность, расширяющая возможности продукта. Для работы в web IBM позицинирует другие продукты.
4. Каких элементов GUI конкретно критически не хватает?

Ай, можно тоже пофлудить о наболевшем
1. По вопросам производительности: в чем ее не измеряй, а большинство нормальных реляционных БД работает значительно быстрее Лотуса. Это может быть еще не так заметно при выполнении простых операций (типа поиска каких-то документов), но вот при необходимости произвести какую-то сложную обработку данных разница становится очень большой.
2. По вопросам GUI: мне вот лично катастрофически не хватает таблиц. Встроенные вью, которые использую вместо них, конечно по-своему хороши, но уж больно у них много ограничений (даже нельзя узнать, какой документ выбрал юзер).
3. Языковые средства: тут полностью солидарен с K-Fire. Не понимаю, почему нельзя было ввести единый ОО-язык для всех нужд? Тем более, что и придумывать особенно ничего не надо - взять и расширить границы применения той же Java. Для последней было бы неплохо еще реализовать возможность использования внеших JRE/JDK вместо своей, а то с JDK 1.1.8, идущей с R5, много не навоюешь.
4. Может это просто мне с релизом (R5 чего-то там) не повезло, но оно глючит, причем жестоко, причем без повода. Конечно, все программы глючат, но Лотус тут регулярно выходит далеко за рамки приличия, глюкавя и падая без видимых причин. В свое время брался даже составить список действий, которые надежно убивают Designer или Notes, да руки что-то не дошли... С ходу помню только кусочек кода типа такого:

Не знаю, что в нем не так (в других ЯП подобные конструкции успешно работают), но у меня от такого Notes сразу умирает.

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

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

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

Ну это вы уже явно не в ту степь ушли. Практически любой сервер самой разной функциональности можно завалить чрезмерно большим объемом/потоком информации.

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

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

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