Comments 102
Во-первых Denwer чудовищно устарел. PHP 5.3? Нет, спасибо!
Во-вторых все «сборки» тащат за собой множество ненужных компонентов. И всё равно требуют настройки.
В-третьих нам нужна идентичность версий nginx, PHP и прочего на всех серверах. Чтобы этого добиться — всё равно придется ставить заново все перечисленные компоненты. Так зачем же нужна «сборка»?
Итак, всё встало на свои места, сборка заработала, как ей и положено. Настала пора писать код!
упаковать — автоматизировать все то что вы описали в статье (до момента «Настала пора писать код!»)
Вы меня не так поняли.
Сборка — это процесс деплоя приложения в данном случае.
— TeamCity видит изменения в репозитории
— запускает шаги СБОРКИ
— первый шаг: передача файлов на целевой сервер
— второй шаг: запуск на целевом сервере сценария СБОРКИ
— который уже и делает нужные действия
Вы, видимо, под сборкой имели в виду что-то другое.
1. Пишется Excel со следующим макросом:
а) считываем имя файла и берём оттуда идентификатор
б) идём по определённому URL, идентификатор из пункта (а) параметром, там 2 таблицы, одна с данными, вторая с макросом
в) данные сохраняем на лист, макрос eval'им
2. На сервере, по окончании выполнения отчёта, складываем данные и макрос для этого отчёта, сохраняем идентификатор данных.
3. Выдаём пользователю Excel-файл из п.1 в названии которого будет идентификатор из п.2
Основная проблема заключается в том, что уровни безопасности макросов необходимо снизить чуть более чем полностью.
Более того, пользователь — не человек :)
Это веб-сервис для других сервисов. Часть микросервисной архитектуры.
Для начала был установлен PowerShellServer. Это позволило нам подключаться к windows-серверу по привычному всем протоколу ssh, не изобретая велосипедов. Поддерживается авторизация по ключам, работает rsync (это важно). Жаль, что в Personal Edition ограничение только на одно одновременное подключение, но для нас это некритично.
EULA
6. NON-COMMERCIAL LICENSE. If the Licensed Software product you have downloaded or otherwise obtained is marked as “PERSONAL”, “HOBBYIST”, “NON-COMMERCIAL”, or “EDUCATIONAL” the following license terms apply: Subject to the terms, conditions, and restrictions set forth in this Agreement, /N SOFTWARE hereby grants to you a limited, personal, non-exclusive, non-transferable license to Use the Licensed Software as follows: (i) personal and non-Commercial Use of the most recent version and edition of the Licensed Software specified in the License Key; (ii) non-Commercial Use of the Licensed Software in conjunction with the maximum number of Authorized User(s) specified in the product option You have purchased; and (iii) make one backup copy of the Licensed Software for archival purposes. You may not distribute Applications that use the Non-Commercial Software as a runtime component.
Стыдно должно быть: клиенты — банки, а вы $99 авторам пожалели, спиратили.
Я для ознакомления и исследовательских целей волен ставить любой софт, какой захочу. Это вполне себе fair use. Убедившись в эффективности, можно и купить.
Откуда вы знаете, что «спиратили»? По себе людей судите?
Мне кажется, вы зря в штыки так это воспринимаете. Ну ошиблись, нарушили лицензию. Цена вопроса — $99 долларов. Не страшно пойти и заплатить таким же разработчикам, как и вы.
По себе людей судите?
Скорее, с собой сравниваю. Я вот из статьи узнал об этом продукте. Заинтересовался, первое, что сделал — прочитал условия предоставления бесплатной лицензии. Чего и всем желаю — уж IT-шники труд коллег должны ценить, к нам же это и вернётся в первую очередь.
Второе. Да, в моей юрисдикции существует понятие добросовестного использования. В личных (а я лично изучал применимость утилиты для моих собственных целей), научных и учебных целях. Что и было проделано.
К моменту запуска сервиса в продакшн коммерческая лицензия будет приобретена, либо использование утилиты будет прекращено.
Считаете, что я неправ — можете подать в суд. Полные личные реквизиты могу предоставить по запросу.
Также точно будут проблемы с одновременными запросами, не закрывшимся Excel и всем этим.
Как вариант: с помощью какой-либо из тысяч библиотек открывать базовый xslx, подставлять туда нужные входные параметры и предлагать пользователю скачать результат и уже у него на машине пусть считает.
Также точно будут проблемы с одновременными запросами, не закрывшимся Excel и всем этим.
Нет таких проблем. Excel корректно закрывается. Одновременные запросы работают одновременно, открывая каждый свой экземпляр приложения.
Чтобы избежать проблем с дурацким «восстановлением», файл перед открытием копируется во временную папку и открывается оттуда. При корректном завершении скрипта файл удаляется, если что-то валится — его собирает отдельный сборщик мусора.
создать символическую ссылку на NTFS — не проблема. Проблема ее удалить
тоже не проблема
создание и удаление линков на каталог (важно: опция /D)
mklink /D new_dir_link c:\Users
rd new_dir_link
создание и удаление линков на файл
mklink new_file_link %windir%\system32\cmd.exe
del new_file_link
Довольно феерично наблюдать за сервером: при приходе запроса мгновенно открывается Excel, запускается экспорт и потом также мгновенно всё это хозяйство закрывается.
а Вы случайно эту мгновенность в rps-ах не меряли? Возникают обоснованные (на мой взгляд) вопросы по производительности. (интересно под виндой вообще можно заставить приложение headless работать?)
// @todo: выключить, если не требуется видеть работу приложения
$this->xls->Application->Visible = 1;
Вот эта строчка, если в ней присвоить свойству Visible = 0, как раз и предотвращает появление приложения на рабочем столе.
Производительность, честно говоря, никакая. Запрос с расчетом простейшей формулы типа «2+2» занимает чуть ли не секунду. Но мне это некритично, к счастью.
вероятный способ ускорения: при старте веб-сервера заранее запускать эксель, запоминать его идентификатор процесса и по требованию обработать новые данные передавать этому процессу файл, данные.
я привел специально один маленький и незаметный комментарий
Это ж тусовка программистов, а где вы видели программистов читающих комментарии ) Спасибо!
Но для крупного заказчика все-таки стоили предложить промышленный подход — проанализировать алгоритмы в файле (раз уж заказчик не готов их сам описать) и разработать решение без костылей…
1. «Крупных заказчиков» десятки
2. Файлов сотни, их список меняется несколько раз в день
3. Алгоритмы в файлах также могут меняться ежедневно
Анализ такого объема алгоритмов, а, главное, их верификация и QA обошелся бы на три порядка дороже, чем один маленький виртуальный сервер с «виндой».
Но мыши продолжают колотся…
P.S. я не со зла) Просто стиль изложения такой)
Может было проще сделать ещё один макрос в экселе и добавить его в существующие файлы(раз макросы и так неизбежное зло)? Тогда сотрудники(или клиенты) не зависели бы от внутреннего сервера…
Ни в коем случае не осуждаю — каждый решает задачу самым удобным для себя инструментом. Просто на мой взгляд сотрудники были бы оперативнее без внутренних сервисов.
По запросу это приложение открывает нужный файл (а точнее, его копию), подставляет в этот файл данные, запускает пересчет, считывает данные после пересчета, инициирует импорт книги в PDF.
В ответе клиенту в формате JSON передается массив считанных результатов просчета и ссылка на файл PDF.
Скажите, как «еще один макрос» решил бы эту задачу?
Добавлю для понимания — «клиенты» не являются людьми. Эти данные требуются другим сервисами.
Нет никакого «заказчика». Никто не будет ничего запускать вручную. Я уже подробно это объяснял в комментариях.
Какие костыли? Я не понимаю вас. Штатным образом запускается приложение, совершенно штатным и документированным — идет взаимодействие с ним. Где тут костыли?
То, что сервер на windows — да, лично для меня это странно. Но каких только чудес на свете не бывает ))
Проблема с одним процессом решается так: https://github.com/deemru/php-cgi-spawner
Вот тут я комплект собирал для локальной разработки: https://github.com/samdark/wnmp-dev
Кстати, у вас процесс будет отваливаться через какое-то количество запросов. Чтобы этого не происходило без spawner-а надо PHP_FCGI_MAX_REQUESTS
установить в 0
.
Нет никаких «заказчиков», никто не собирается ничего править в таблицах.
Есть заранее данные файлы Excel, содержащие расчеты. Запустили — подставили данные — считали результат. Таких файлов сотни. Подставлять в них данные нужно сотни и тысячи раз в день.
Никакая «вёрстка» на PHP не справится с задачей «Запустить файл с макросами».
Пожалуйста, перечитайте статью внимательнее.
Вы никогда не работали, скажем, со «Сбербанком»? Рассказать, как вас далеко пошлют с такими «рацпредложениями»? И как вы будете кувыркаться?
И потом, где вы нашли в задачах «принимать данные»? Нужно не данные принимать, а запускать алгоритмы, реализованные в виде Excel-файлов. Данные поступают совершенно из других источников.
Так что теперь, через 10 лет после разработки есть экселевский «черный ящик», куда нужно вбить информацию и получить достоверный прогноз. Поэтому отлично понимаю такой подход из статьи.
Даже при большом желании бизнес уже не сможет дать алгоритмы по данному конкретному случаю, а работать то надо…
Наступают обычно на грабли. А об камни спотыкаются
актуального опыта работы с Windows ни у кого нет
Вот бедолаги)))
По хорошему нужно было под IIS писать на шарпе сервис. Вебсервисы под винду так и заточен. Хотя и на com объектах можно.
Надо полагать OpenSSH через cygwin, потому как адекватно мелкомягкие SSH к серверным осям еще не прикрутили… *facepalm*
Потом, использовать ole automation на сервере — очень плохая идея. Старая статья на эту тему support.microsoft.com/en-us/kb/257757
К примеру, Excel запросто может на ровном месте выдать какой-нибудь модальный диалог и ждать, пока человек не нажмет кнопочку.
Ну например, а как вы узнаете, куда в очередной полученный файл нужно подставлять исходные данные и откуда получать результат?
Странный вопрос. Во-первых файлы поступают вместе с документацией. Во-вторых места, куда нужно подставлять исходные данные и откуда забирать результат, помечены именованными диапазонами. Получить их список — элементарно.
К примеру, Excel запросто может на ровном месте выдать какой-нибудь модальный диалог
Это ему делать запрещено:
$this->xls->DisplayAlerts = 0;
См. https://msdn.microsoft.com/en-us/library/office/ff839782.aspx
— на первом этапе поставить консолидирующую базу, которая бы для начала только агрегировала данные с екселев
— на втором этапе можно было бы заставить эту консолидированную базу посредством веб-сервисов получать/отдавать данные во внешний мир
— на третье этапе, можно было как-то бить эти ексели на логически законченные куски, и переносить формулы «как есть» в консолидирующую базу в виде готовых моделей. Самый тяжелый этап. Т.к. информация в виде сорцов есть, то можно будет сравниваться всегда с эталонными данными. После того, как какой-то расчет перенесен в консолидацию, можно настроить какой-нибудь джоб, который бы сравнивал, что получилось расчетно, а что — через первый этап. Все недочеты, конечно, оперативно исправлять. И так, шажком за шажком, за какое-то время можно все имеющиеся расчеты перенести в консолидацию. И что самое главное, можно все сверить на эталонных данных. Естественно, что все новые расчеты нужно сразу делать в консолидирующей базе. В итоге, тысячи екселевских книг должны уйти в небытие, а вместо них должны получиться отчеты в консолидирующей базе.
Под «консолидирующей» базой я понимал продукт с которым сам имел дело, под названием 1С: Консолидация или же его новой реинкарнацией 1С: Управление Холдингом. Естественно, на все_это мало кто идет, т.к. в этом случае требуются значительные затраты со стороны заказчика-банка + понимание того, а зачем при всем работающем — вот_это_все нужно. Плюсом практически у всех ит-отцов банков при одном упоминании аббревиатуры «1С» на лице читается «лолшта???» 1С в беке банка? Парень, да ты безумец! И тяжело таким отцам, практически невозможно обосновать понятие «технического долга», который заказчик уже накопил и продолжает копить. Все работает, нужно цифры в ексель вбить! Какой долг? О чем вы вообще? Еще 1С приплел? Аха-ха-ха..1С Консолидации вообще пофик с какими екселями работать, самой платформе — тоже. Таки в чем проблема? Аха-ха-ха, давай до свиданья, шутник!
Поэтому все так. Автору — крепких нервов, глубокого сна, и железобетонной веры в то, что все что он делает — светлое и чистое! Если такие кульбиты, по поддержке банковской суровой реальности делать постоянна, эта вера, по собственному опыту, тает со временем.
нужно, чтобы работали макросы, и еще бы хорошо всё это сохранять в PDF
Могу ещё добавить, что мы переехали на Win+COM, когда появилась потребность обрабатывать/генерировать большие xls/xlsx файлы.
Производительность PHPExcel просто удручает.
Т.е. если отбросить, в общем-то, не очень важные детали (как подключиться к виндовому серверу, как удалить ссылку), всё сводится к COM.
Что ж, всё новое — хорошо забытое старое! ИМХО, COM — это ОЧЕНЬ неплохой механизм; прямо таки претендует на фундаментальную фичу!
Весь мир поделить на интерфейсы, каждому присвоить уникальный GUID, потом свести все прочие параметры/указатели к void** — и так, максимально всё абстрагировав, по GUID дальше тупо вызывать методы!
MS хороши тем, что достаточно последовательно следовали этому своему механизму, что позволяло (и позволяет) весьма легко реверс-инженерить практически любую MS-"системную" программу (Скачай отладочные символы для нужного бинаря. Найди из множества применений компонента наиболее очевидное в дизассемблере. Прокомментируй понятно смысл работы его отдельных методов — и вот, дальше по тому же GUID распутывается цепочка остальной логики программы!) Например, тот же Windows mail (aka Outlook Express) свою базу для хранения писем подключает через CoCreateInstance с guid базы. И потому если даже внешне он выглядит неприступным (подписанный .exe загрузил свою собственную подписанную .dll, что лежит прям рядом), по факту подмена единственного ключа в реестре позволяет загрузить что-то своё, и дальше рулить, следуя тем же правилам COM (подписи/приоритеты/доверие ничто. GUID — всё!). К слову, если убрать глобаьные моменты (вроде общесистемного CoCreateInstance), то более локально (спросить у произвольного поинтера, что же он из себя представляет и что он может) — как раз таки и есть вполне фундаментальная фича.
Для упрощения перезапуска всего этого «добра» был написан несложный cmd-файл:
а смотрели в сторону Windows Service Wrapper, от автора Jenkins?
Я бы написал демона на .net, имеющий API методы, которые отражают ваши операции над XLS документами и возвращают только нужные данные.
— .net сделан для windows, огромное сообщество, у него есть typehinting для COM объектов.
— php/nginx под линукс можно установить/обновить из пакетов парой строчек.
Ну а минусы вы сами знаете, у вас вся статья состоит из костылей и ограничений.
Несколько лет назад ходил по таким же.
ТЗ — рассчет калькуляторов часто меняется, как он работает — никто не знает, нужно не программировать аналоги, а использовать готовые XLS в продакшене с возможностью их оперативной замены.
Все от жадности. Видимо, пока проект дойдет проект до конечного исполнителя весь бюджет откусывается и остается денег только на это.
В итоге — система была построена (PHP на windows-хостинге), все автоматически открывалось, заполнялось и вычислялось. Но оказалось, что один и тот же файл в один и тот же момент времени винда умеет открывать только один раз (на тот момент, по крайней мере, было так). Для продакшена не самый приятный момент.
В любом случае, извращение.
Ну тогда мы на разных языках говорим. У нас, в рамках решения этой задачи, серверные ресурсы не ограничены.
«Хайлоад» — имел ввиду не яндекс, конечно, но и не хоумпэйдж. А работать такое решение будет только в последнем случае.
Не помню, какая нагрузка планировалась (давно было дело), но рассчитывали делать сервис по кредитным калькуляторам с поиском лучших условий по разным банкам.
В любом, случае, я думаю, важно понимать, какие ресурсы и ограничения потребуются для такого решения.
Если под каждого клиента поднимать «на лету» сервер и инициализировать приложение, то да, работать будет. В противном случае — маловероятно.
Да и с открытием копий были тоже проблемы — не нравилось майкрософту, по моему, что у двух открытых документов были одинаковые заголовки.
А вы реально проект тестировали или пока только радуетесь тому, что технически все сошлось?
У меня тогда все работало, но в реальный продакшн это запустить не получилось — слишком много ограничений + требовательность к ресурсам.
А вы реально проект тестировали или пока только радуетесь тому, что технически все сошлось?
Реально. И задача очень близкая вашей. Только не кредитные калькуляторы, а скоринговые модели.
не нравилось майкрософту, по моему, что у двух открытых документов были одинаковые заголовки.
Не удалось воспроизвести такой кейс.
О том, как мы на PHP запускали настоящий MS Excel и что из этого вышло