Developing.ru

1). Интересно кому же тогда Инфра Рессурс продаёт свои сертификаты. И довольно много продаёт ...Если к вам придрались с OLP MS Office, то точно так же могут
придраться и с ООо. Было бы желание. Хотя, повторюсь, cудебных перспектив у
такого случая нет. Впрочем, это беспредметный спор. У каждого свой опыт.
2). Так вы готовы платить реальные деньги за разработку (freelance) в среде ООо ?
Если нет - это ещё одно подтверждение высказанного мной ранее тезиса.
(Если да - исключение )

Разумеется, рыночная ниша офисного программирования довольно узка.
Но к счастью она существует. Помимо малых компаний и ИП заказчиками кстати могут быть довольно крупные структуры. Если конечно вам что нибудь говорят слова SharePoint Portal и Visual Studio For Application или Visual Studio Tools for Office.
На счёт 1С и Excel, это по видимому была тонкая шутка.

У меня довольно большой пакет заказов от 1С интеграторов на построение макросов облегчающих анализ выгрузок из 1С баз.

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

Насчёт того, что сложные вещи всегда распределённые - согласен частично. Бывают очень простые распределённые проекты. А бывают сложные проекты принципиально завязанные на одного пользователя. Например, макрос для Excel, восстанавливающий нормальную форму почтового адреса (для обычной почты), в котором компоненты записаны в произвольном порядке с произвольными разделителями (или без них) и с возможными орфографическими ошибками. А так же с возможным употреблением старых названий городов и улиц ...
У каждой задачи своя ниша программных продуктов. Более того. Часть задач моих
клиентов, которая раньше решалась в ACCESS, c появлением офиса 2007 переехала в Excel. Это оказалось и проще и удобнее.
Есть и клиент у которого лист EXCEL автоматически заполняется на основании SQL запроса к Oracle

3) Скорость скомпилированного VBA кода значительно выше. А уж как JRE обновляется. Я у одного конечного пользователя в системе нашёл 8 установленных отдельно update ...

4,5) Боюсь, что вы не будучи профессиональным программистом не понимаете о чём идёт речь. Помимо прочего, при сравнении VBA и SB имеются в виду среды в совокупности а не чистые голые языки.

6) Никто не говорил что документации вообще нет. Но где же нормальное
подробное описание объектной модели с чем то хоть в половину похожим на
Object Browser из IDE VBA

7) В Excel ответ на все вопросы - да, легко
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------

Esgalin писал(а):В общем в плане альтернативы VBA (из за платности офиса), нам оказалось проще переделывать проект под SpreadsheetGear.

Полностью согласен. Я ещё TX Text Control вместо Word люблю использовать.
Правда не бесплатный он. Но девелоперовскою лицензию один раз можно купить..

Esgalin писал(а):Гм. Исходя из пунктов 2 и 3 я бы рискнул предположить что по мнению автора не отличается сложность реального кода трехстрочных макросов. С которыми не вполне корректно говорить о разработке на VBA .

Мы оценивали возможность переноса нормальной управляющей надстройки (тысяч на 5 строк) с VBA на ОО.
....

Я готов согласиться с тем, что OOBasic сам по себе проще VBScript: это логично, OOB моложе, финансовых возможностей меньше.
Но, во-первых, если я услышу от программиста "напишу программу в 1000 строк на VBScript" (не говоря о 5 тыс), этот программист у меня просто не будет работать. Кому нужен идиот, который готов потратить свое время на создание непереносимого медленного продукта? К тому же, ну как можно читать этот код (это уже религиозное, но все же).

Большой объем данных в "Офисе" -- это как Оку в качестве автобуса использовать. В принципе, формы и обработки значительно проще сделаются в 1С:Предприятии (хотя я не жалую этот продукт), а скорость работы с таблицами будет на ПОРЯДКИ быстрее обработок листов (ODBC для VBScript опускаю). Графики, чарты и анализ: серьезные вещи VBScript не сможет сделать просто из-за ограничений производительности. Тут SAP BA подойдет больше (если не смотреть в сторону RRDTools, Perl/PHP).

Я просто не могу придумать какой-то области, в которой что-либо в Word/Excel/Access было бы по-настоящему полезно для обработки большого количества информации. Я допускаю, например, что в Excel можно сделать какой-то анализ выручки/бонусов/продаж для демонстрации того, что нужно, чтобы потом программисты написали это в чем-то быстром/платформонезависимом/расширяемом,SVC-совместимом . Т.е. я считаю, что Excel может помочь упорядочить данные, предоставив пользователям логичный инструмент выражения мыслей. Потом эти мысли нужно обработать и реализовать в чем-то другом.

Дополнительно, давайте прямо, многие корпоративные вещи (работа с LDAP,хранение истории для графиков и т.п.) в каком-нибудь Perl сделаются значительно быстрее.

Здравствуйте putin_ai.
после аллегории "Ока - Автобус" хочу спросить - как часто Вы покупаете трактор при необходимости вскопать клумбу?
"чтобы потом программисты написали это в чем-то быстром/платформонезависимом...", а будет ли в этом необходимость, если продукт создавался для защиты от "человеческого фактора" и используется два раза в год.
"многие корпоративные вещи...", а как быть не-корпорациям, мелким офисам и конторам?
Ясно одно - на каждый товар есть свой покупатель, с этим спорить бесполезно.
Евгений.

Teslenko_EA писал(а):Здравствуйте putin_ai.
после аллегории "Ока - Автобус" хочу спросить - как часто Вы покупаете трактор при необходимости вскопать клумбу?
"чтобы потом программисты написали это в чем-то быстром/платформонезависимом...", а будет ли в этом необходимость, если продукт создавался для защиты от "человеческого фактора" и используется два раза в год.
"многие корпоративные вещи...", а как быть не-корпорациям, мелким офисам и конторам?
Ясно одно - на каждый товар есть свой покупатель, с этим спорить бесполезно.
Евгений.

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

В Excel защита от человеческого фактора?

Aent писал(а): 3) Скорость скомпилированного VBA кода значительно выше. А уж как JRE обновляется. Я у одного конечного пользователя в системе нашёл 8 установленных отдельно update ...

А при чем OO Script и JRE? Обновление JRE мне тоже не нравится. Правда, эта проблема характерна только для Windows, в Linux обновляется все вместе с компонентами ОС и прочими приложениями. Я думаю, это так Sun беспокоится о сторонних разработках на Java, которые сами себе указывают путь к JVM при инсталляции.

По поводу 1С: во-первых, 1С -- это не аналитика. Я говорил про ввод и обработку данных. В 1С она удобнее на порядок и без шуток. Аналитика -- это к SAP. Это Excel + Oracle -- шутка.

Мы же не говорим о простых вещах, а о сложных, так? Сложные вещи в Excel писать нельзя. Это просто выкинутые деньги на ветер: дальнейших перспектив у таких разработок нет, поддерживать их сложно, а в группе разработчиков еще сложнее, код не переносим и медленный.

Задача программиста -- не заниматься одноразовыми вещами, а пытаться все систематизировать.

К сожалению, в этой стране, из-за крайне низкого уровня образования программистов (которым почти не рассказывают про проектирование, а если рассказывают, то так, что никто все-равно не понимает или считает это не нужным). А умение писать макросы в Офисе становится почти обязательным (вообще, нонсенс!). Я помню, сколько проблем у меня было, когда нужно было написать курсовик с использованием офиса, а я написал COM-объект на Visual C++, транслировавший вызовы из Excel в БД на Access -- как на меня обиделись преподаватели, так как "сука выпендирлся" (не словами, но взглядом).

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

Это типичная ситуация: человек в институте выучил 1С и Офис, после чего в работе ничего нового не изучает, зато всем объясняет отсутствие знаний тем, что "это круто" и ничего больше не нужно. В итоге, человек с пятилетним опытом программирования какого-нибудь 1С может не знать о документации кода, базы знаний не поддерживает, схем нет и о существовании UML не знает в принципе, о существовании SQL только догадывается, а авторизовать существующих пользователей в Active Directory -- это фантастика. Даже реляционную от постреляционной БД не отличит. Хотя все это резко увеличило бы ценность труда такого персонала.
А пользователи, в свою очередь, и понятия не имеют про какой-нибудь SAP, а понятия SQL, SOAP, OLE, LDAP -- вообще, не для них. У них системный блок -- это "процессор", а браузер -- "интернет". Именно из-за этого и возникает рынок разработок в Экселе: программисты не могут, а пользователи не знают и не хотят (и в этом тоже я виню общий уровень догматичного российского образования, которое не учит людей автоматизировать свои действия).


Наглядный результат: общий уровень производительности труда в стране.

putin_ai писал(а):Я готов согласиться с тем, что OOBasic сам по себе проще VBScript: это логично, OOB моложе, финансовых возможностей меньше.

Еще раз. Откуда VbScript ? Намеренное пренебрежение или незнание предметной области ?

putin_ai писал(а): Но, во-первых, если я услышу от программиста "напишу программу в 1000 строк на VBScript" (не говоря о 5 тыс), этот программист у меня просто не будет работать.

Ну я если услышу от программиста что сейчаc он возьмет 200 готовых XLS шаблонов и по религиозным соображениям за полгодика перегонит их в PHP\xml , он тоже у меня работать не будет. Прикладные задачи разные бывают

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

Нормально. Нет ООП (полиморфизма\классов) а так нормально. Право не понимаю как тут же можно php в котором вообще ничего нет в пример ставить. Как вы говорите объявляется переменная и её тип ?

putin_ai писал(а): Большой объем данных в "Офисе" -- это как Оку в качестве автобуса использовать.

Да, безусловно. Но существует не только хранение данных.

putin_ai писал(а): В принципе, формы и обработки значительно проще сделаются в 1С:Предприятии (хотя я не жалую этот продукт), а скорость работы с таблицами будет на ПОРЯДКИ быстрее обработок листов (ODBC для VBScript опускаю).

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

putin_ai писал(а): Графики, чарты и анализ: серьезные вещи VBScript не сможет сделать просто из-за ограничений производительности. Тут SAP BA подойдет больше (если не смотреть в сторону RRDTools, Perl/PHP).

Да. Ес-но есть предел. Но php\perl то здесь вообще при чем ? Особенно Php ?

putin_ai писал(а): Потом эти мысли нужно обработать и реализовать в чем-то другом.

Да. Здесь у нас слабина. Обычно т.к. потом лень реализовывать в чем то другом. Не трогай рабтающее, пока не заплатят.

putin_ai писал(а): В Excel защита от человеческого фактора?

Да. От рядового пользователя - легко. Защиты поставить несложно. У продвинутого пользователя обычно хватит головы поставить на место то с чем он поигрался.

putin_ai писал(а): Основная причина использования макросов в больших приложениях среди программистов -- отсутствие нормальных навыков и умений работы в каких-то других средах.

Нет. Основные причины делания того или иного программистами -согласованное с заказчиком ТЗ.
--------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
Попытка переписать без частностей
Мое понимание позиции уважаемого putin_ai: Open Office является адекватной заменой MS Оffice для разработчика. Т.к. примитивные вещи в нем есть, а сколько нибудь продвинутые -надо делать иным образом

Моя точка зрения: Существуют задачи которые прекрасно решались в VBA MS Office, и гораздо дороже в иных средах. OpenOffice дает крайне примитивные возможности, ради которых я не стану подключать этого монстра к проекту. Как не стану к примеру заморачиваться с Excel ради сортировки и печати таблички с двумя формулами.

Esgalin писал(а):Еще раз. Откуда VbScript ? Намеренное пренебрежение или незнание предметной области ?

А как называется этот язык? VBA, VB for Application?
Перестаньте!

Esgalin писал(а): Ну я если услышу от программиста что сейчаc он возьмет 200 готовых XLS шаблонов и по религиозным соображениям за полгодика перегонит их в PHP\xml , он тоже у меня работать не будет. Прикладные задачи разные бывают

Переписывать -- это другое. Здесь нужно учитывать время программистов.
А писать новое?! Заказчику можно всегда объяснить, что такое хорошо и что такое плохо. И если данные, которые вводятся или обрабатываются, в конечном итоге не будут доступны для дальнейшей обработки, то такая работа стоит ничего. Если вы исполняете требования заказчика без предоставления ему альтернатив (а вот можно так сделать, и в дальнейшем можно будет так, и вот эдак), то вы только вредите заказчику, потому что полагаетесь на то, что заказчик действительно может сформулировать самостоятельно ТЗ.
Как вы используете версионники в VBA? Только если отправлять весь Spreadsheet/Документ.
Как можно отследить использование UML-модели? Очевидно, что никак.

Esgalin писал(а): Нормально. Нет ООП (полиморфизма\классов) а так нормально. Право не понимаю как тут же можно php в котором вообще ничего нет в пример ставить. Как вы говорите объявляется переменная и её тип ?

Без объектной модели невозможно строить UML-схемы (во всяком случае, автоматически).
В PHP есть очень много. Например, объектная модель. Практически все, что нужно для первичной обработки данных. Остальное (предсказание данных на следующий год и т.п.) -- пожалуйста, SAP. Любые графики могут быть построены с накоплением и без, и это будет стабильно работать с поминутной детализацией с анализом за год И время формирования страницы -- 0,0-чего-нибудь там секунд.

Esgalin писал(а): Да, безусловно. Но существует не только хранение данных.


Несложные Формы и обработки (к примеру декларация по налогу на прибыль) значительно проще делаются в экселе . Скорость обработки экселя - выше, математический функционал экселя очень мощен.
Да. Ес-но есть предел. Но php\perl то здесь вообще при чем ? Особенно Php ?

А что еще существует? Куда декларация по налогу потом уйдет? Она должна уходить в МосНалог через Интернет (ФНС распространяет ПО "Референт"). А в компании должна храниться в таком формате, чтобы учесть эти данные в общем отчете. И при чем тут Эксель?!

Математика у Perl мощная (и многие компоненты портированы на PHP в CPAN/PEAR). А как Perl строки обрабатывает -- вообще, сказка! Регулярные выражения в VBA значительно скромнее.

Esgalin писал(а): Да. От рядового пользователя - легко. Защиты поставить несложно. У продвинутого пользователя обычно хватит головы поставить на место то с чем он поигрался.
[/QUOTE=Esgalin]
Это все некорпоративные решения.

Esgalin писал(а): Нет. Основные причины делания того или иного программистами -согласованное с заказчиком ТЗ.

Заказчика нужно обучать. Показывать новые перспективы.

Esgalin писал(а): --------------------------------------------------------------------------------
Добавлено сообщение
--------------------------------------------------------------------------------
Попытка переписать без частностей.
Мое понимание позиции уважаемого putin_ai: Open Office является адекватной заменой MS Оffice для разработчика. Т.к. примитивные вещи в нем есть, а сколько нибудь продвинутые -надо делать иным образом

Моя точка зрения: Существуют задачи которые прекрасно решались в VBA MS Office, и гораздо дороже в иных средах. OpenOffice дает крайне примитивные возможности, ради которых я не стану подключать этого монстра к проекту. Как не стану к примеру заморачиваться с Excel ради сортировки и печати таблички с двумя формулами.

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

Чтобы поставить точку в споре: приведите РЕАЛЬНЫЙ пример того, что можно реализовать в MS Office и нельзя или очень долго реализовать в OpenOffice, при этом не затрагивающие ввод и первичную обработку информации (мы договорились, что эти задачи в Excel решать принципиально ошибочно?)