Поговорим сначала о подходах к старому и новому 🙂
Относительно недавно я общался с одной финской компанией, где нужно было внедрить электронные УПД. Задача не слишком сложная, дня 2 работы. Но клиент сначала попросил меня прислать рекомендации от других клиентов и чуть ли не резюме. Вместо резюме я отправил ссылку на свою страницу в линкедине, рекомендации всё-таки отправил. После этого мне устроили смотрины, как будто я собираюсь на них жениться 🙂 После этого я расписал предполагаемые трудозатраты и описал технологии, с помощью которых предполагаю осуществить задачу, а конкретно был упомянут канал MSRS. И вот тут начинается всё самое интересное. Все прочитали моё сообщение, ни у кого не возникло никаких вопросов, наметили встречу в питерском офисе с сотрудницей, осуществляющей поддержку iScala из Финляндии, она специально приехала в Санкт-Петербург. И что вы думаете? Оказалось, что она не знает что такое канал MSRS и кроме того у меня лично возникло ощущение, что она вообще не читала всю переписку и моё подробное изложение того, какие технологии будут применяться. И весь разговор свелся примерно к следующему: «А почему мы про это ничего не слышали? А кто еще из консультантов использует эту функциональность? А почему кроме Вас никто это не использует? Ну не могут же все быть дураками, а один Вы умным». Ну, да, тут я, наверное, погорячился, ответив «потому что дураки» на вопрос «А почему кроме Вас никто это не использует?». Мои коллеги консультанты, конечно не дураки. И не ленивые, просто иногда им даже некогда осваивать что-то принципиально новое, лучше привычный убогий Crystal, чем неизвестный доселе MSRS. Я задавал вопрос в группе в Линкедин, почему люди не используют канал MSRS, большинство ответов было, что не хочется переделывать существующие документы. «А новые?», спросил я. «Для новых внедрений это подходит», согласились мои коллеги. И знаете, чем закончилось история с тем клиентом? Ничем! Я ждал обещанного через неделю ответа почти месяц, а потом решил напомнить. В результате получил ответ не от сотрудницы, с которой мы беседовали, а от финансового директора с российской стороны, что они работают с Кристалом и не хотят в одной программе иметь 2 разных технологии. И вы что думали, что я никак на это не отреагирую? Нет конечно.
Вот моё ответное письмо (русский вариант):
Здравствуйте, [имя финансового директора],
Спасибо Вам за Ваш ответ.
Уважаемые коллеги,
Разумеется, Вы и только Вы имеете право решать, какие технологии использовать, хорошо известные старые или современные новые. Я не оспариваю Ваше право, но ничто не помешает мне дать оценку Вашему решению (ну, вы же не думали, что я просто промолчу в ответ?) 🙂
На мой взгляд, самый лучший способ знакомства с новой технологией — это начать её использовать. Вам предоставилась возможность получить её из рук наиболее опытного специалиста в данной области. То, что Вы отказываетесь от новых технологий только потому, что кто-то конкретный ничего о них не слышал/не знает/не интересовался/не желает разбираться, для меня выглядит неубедительным доводом. Мне нравится разумный консерватизм, но в данном случае Ваши сомнения представляются мне избыточными, а само решение выглядит для меня неверным. Если Вы планируете и дальше работать с iScala, то обратите внимание что в iScala 3.3 (последняя версия на текущий момент) технологии MS SQL Server Reporting Services ещё больше интегрированы в ней.Я не навязываюсь Вам в друзья или партнёры, я просто высказываю своё мнение.
Всего хорошего и успехов Вам в Вашем бизнесе,
С уважением,
Алексей Васильев
Я не собираюсь никого уговаривать. Давайте просто посмотрим некоторые факты о живучести старых технологий и старых решений.
Посмотрите на картинку. Я постарался собрать на ней 3 разных функции Crystal из формы счёта на оплату:
Это всё попытка определить формат числа, используемого в iScala и преобразовать текст типа 123’456,78 в число 123456.78! Это даже не про Crystal. Это про время, когда не было расширенных форматов DDF кодов (или про то, что консультант использует старые наработки, хотя эти коды уже давно появились). Я уже писал об этом: «Возможно, Вы просто не знаете, что в DDF файле можно в явном виде задать формат числа без всяких разделителей тысяч, а также с использованием точки, как десятичного разделителя. Это, так называемые Extended DDF форматы, например, <.13> (будет выведено 123456789.01) вместо <13> (будет выведено в отформатированном виде, например, 123’456’789,01)»
А что на счёт вот этого?
Не буду подробно вдаваться в детали, но можно видеть, что используется пресловутая библиотека CRUFLavv.dll. Причем она возвращает одно единственное значение. То есть, если, предположим, нам нужно в каком-нибудь подобном документе для каждой строки заказа получить 10 разных значений, а строк в заказе 100, то запрос будет посылаться 1000 раз. А при использовании канала MSRS вы просто сможете задать JOIN для присоединения требуемой таблицы со всеми необходимыми вам полями. Хоть вот так (кстати, это фрагмент запроса для создания XML файла для Диадока):
Хоть как-то иначе. В общем, я ничего не навязываю. С моей подачи в новую версию iScala 3.4 обещали включить стандартные шаблоны для канала MSRS для некоторых наиболее употребимых документов. Возможно тот факт, что их до настоящего момента не было и послужил проблемой на пути распространенности этого самого «зверя» под названием «канал MSRS». Это явный прокол компании разработчика 🙁 Надеюсь что в iScala 3.4 с этим всё станет хорошо 🙂
