Взгляд от сохи

В компьютерной периодике нередко встречаются статьи производителей программного обеспечения или представителей фирм комплексной автоматизации. При этом мнение жертвы эти поводыри уже и не спрашивают. Вещи, которые, явно или скрыто, рекламируются, после самостоятельного тестирования оказываются мыльными пузырями. Так, например, согласно основной идее компаний, занимающихся комплексной автоматизацией, следует отказаться от доморощенных, непрофессиональных АСУ или КИС и перейти на системы могучие и тиражируемые. На деле же спуститься до самого низа и решить все мелкие проблемы с их помощью не получается, - вот и приходится держать параллельно несколько систем. Поэтому я хочу подать слабый голос в защиту тех, кто ежедневным трудом подчищает мелкие проблемы, возникающие вследствие новых постановлений правительства, всевозможных комитетов и налоговых служб. Подчас достаточно одного выверта нашего государства, чтобы поставить крест на самой настраиваемой программе, самом крутом производителе тиражируемых систем.

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

1994 год, декабрь. Одно гипотетическое совместное предприятие, как бы это сказать, обмишурилось в пух и прах и развалилось. Но не все погибли. Рациональное зерно с небольшой пенкой было востребовано "большим братом" - ММК (Магнитогорским металлургическим комбинатом) и превратилось в Управление декларирования. В наследство ему достается программное обеспечение, написанное на FoxPro 2.5, операционная система Novell NetWare 3.11 и парк компьютеров: Compaq 486SX/66, 4 Мбайт RAM - клиенты; Compaq Pentium 90, 16 Мбайт RAM - файл-сервер. Три программиста - в придачу, на сто человек пользователей.

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

Надо было дружить с "большим братом", работавшим с TCP/IP, а мы, как понятно, - на IPX.

Структурные переделки позволили уйти от круглосуточной работы на дневной график, и некий объем работ решили выполнять по ночам, но без человеческого участия. Требовался механизм, который позволил бы запускать задачи в назначенное время. NetWare 3.11 этого не могла.

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

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

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

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

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

Поясню один тонкий момент. Руководство нашего подразделения возражало против того, чтобы полтора программиста переходили в состав АСУ "большого брата", на то были объективные причины. Одна из них - таможня не давала добро на обычный порядок решения проблем на крупных предприятиях:

• обозначить проблему;
• вынести ее на обсуждение;
• поднять на еженедельном совещании;
• обозначить сроки постановки задачи;
• поставить задачу;
• определить сроки написания программы;
• написать;
• внедрить;
• отчитаться.

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

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

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

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

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

Итак, первое: NetWare, как за уши ни притягивай, нас не устраивала: отсутствием TCP/IP (повторяю, это 1995 год) и невозможностью запуска программ в назначенное время. "Большой брат" посоветовал взять какой-либо Unix, например, что попроще - "скотину" (SCO-Unix). Взглянув на жертв, вынужденных работать с анекдотично богатым интерфейсом, а также на монстров командной строки и их производительность, мы решили, что пойдем другим путем. Нам нужна была операционная система, обучение которой займет наименьшее время. Кроме NetWare, мы знали еще и DOS. Однако это был уже 1995 год, и мы хотели иметь графический интерфейс.

Мы выбрали Windows NT 3.5. Чем она нас привлекла? Команды управления - те же, что и в DOS, плюс небольшие нововведения, которые и расширяли возможности, и решали наши проблемы. Графический интерфейс - как в Windows 3.11. К тому же сама ОС оказалась весьма "железобетонной". В этой версии была программа AT (scheduler service), которая а-ля Unix cron позволяла запускать bat-файлы. И что же было в этих bat файлах? Плавный переход от файл-сервера к серверу баз данных и серверу приложений. Для разгрузки сети мы решили разделить отчеты на оперативные и временные. Временные отчеты запускала AT, а файл-репорты помещались в определенную область на диске, куда и обращались программы. Тем самым мы ускорили получение отчетов клиентом. Программа AT работала и ночью, чем нас очень радовала. Но за ее работой необходимо было следить. А как? Редактировать время запуска в AT было весьма неудобно. Было найдено простое решение. Создается bat-файл, в котором первой командой стоит at /delete, а далее перечисляются все AT-команды. Это позволяло редактировать, добавлять и удалять команды. В результате появился набор bat-файлов, который по синтаксису был понятен любому разбирающемуся в DOS и, более того, был реализован штатными средствами без написания программного кода.

Через полгода робот взял на себя всю работу, связанную с электронной рассылкой, получением выборок из баз и прочими почтовыми сообщениями с FTP-сервером "Большого брата". А еще через полгода не осталось ни одной задачи, в которой бы не участвовал робот самым непосредственным образом.

Так минул год. Мы решили почти все проблемы. Провели сеть на витой паре 5-й категории. Выбрали для этого оборудование 3Com, наиболее дешевое из качественного. Решили проблемы по связи с "большим братом". Осталось одно - старый добрый DBF-формат. Сменить источник данных оказалось труднее всего.

Единственный минус от внедрения NT заключался в том, что мы были первыми, кто появился в сетевом окружении "большого брата". До нас NT на комбинате никто не ставил, и советоваться было не с кем.

Следующей крупной вехой стал Интернет. Как оказалось, мы его давно ждали. Роботы получили свою страницу, через которую мы могли отслеживать его действия в прошлом, настоящем и будущем. Временные отчеты, формируемые в FoxPro 2.5 for DOS, без больших переделок превратились в отчеты для Интернета. Для этого необходимо было только убрать в генераторе отчетов для FoxPro for DOS псевдографику и добавить теги HTML. Что же еще заставило нас выбрать Интернет, а не продолжать использовать FoxPro на клиенте? Дальнейшие версии программ требовали увеличения объема памяти и вычислительной мощности на клиенте и оставались файл-серверным решением проблем развития. Нам необходимо было выбирать между зарплатой и усилением компьютерной клиентской части. Решение было принято в пользу зарплаты, то есть:

• единого клиента - браузера;
• усиления сервера дополнительными модулями ОЗУ;
• создания Web- и FTP-серверов;
• все отчеты были переведены под HTML.

Начало 1996 года, еще нет MS Internet Information Server. Мы сменили три Интернет-сервера, прежде чем дождались MS IIS, и, получив его, больше не ищем.

Дальнейшим шагом стал перевод данных под SQL-сервер. К тому времени были созданы рабочие места и отчеты с использованием технологии IDC компании Microsoft. IDC через ODBC обращается к базе фразами SQL, поэтому переделка при переходе к SQL почти не понадобилась. FoxPro по-прежнему осталась средством разработки и администрирования. FoxPro for DOS запускается роботами для получения временных отчетов, оставшихся в DBF данными, и стала как бы продолжением командного режима ОС NT.

Шаги перехода от DBF к SQL

Инсталляция SQL Server 6.5.

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

Создание рабочих мест, пользующихся браузером через IDC и ASP, при этом отладка или даже временное заполнение может идти через ODBC в DBF. Дальнейшая переделка состояла в изменении источника ODBC, и данные уже вносились в SQL.

1997 год. Очередная мода - Java, умные беседы про необыкновенные возможности. Книги о Java набиты рассказывают, какие глюки можно сделать на этом интерпретаторе. И ни слова о реальных приложениях. Мы проверили возможности Java-аплетов, включая Corel Office Java. Напоминаю: машины клиентов - это Win 3.1 на 486SX/66 с 8 Мбайт ОЗУ. Попробуйте сами. Если лень, поясню. На такой конфигурации Java-аплеты еле живут, и их применение невозможно. Я не хочу повторяться и говорить, что танки - это мода, а кавалерия вечна, но сегодня Java на клиенте - это пока мода.

ActiveX также не прижились, страшно самих себя ограничивать только MS Internet Explorer, к тому же среди наших клиентов были и внешние службы, использующие Netscape Navigator.

Основная нагрузка легла на ASP и IDC - решения от Microsoft, которые выполняют обращение к базе данных на сервере, а клиенту посылают уже чистый HTML. Как следствие, клиентом может быть любой браузер, способный работать с HTML. Правда, изредка мы все-таки используем скрипт-функции для подтверждения действия (confirm) или для проверки данных перед оправкой на сервер (но, при желании, это можно заменить простыми HTML-файлами без скриптов).

Следующий миф - NC (сетевой компьютер), и как самый яркий его представитель - NC от Sun, так называемый чайник за 1000 долларов без монитора. Мне довелось присутствовать на презентации этого чуда, проводимой представителем Sun у нас на ММК в апреле 1998 года. Перечислю его возможности в тезисах.

Повторюсь: цена 1000 долларов при объеме ОЗУ 64 Мбайт, но без монитора;

из браузеров - только HotJava, который не знает, что такое скрипты от Microsoft или Netscape;

время загрузки с ППЗУ составило 30 секунд, плюс минута на обращение к серверу и скачка с него каких-то еще модулей. То есть полторы минуты против мифа "включай и работай". На такой конфигурации Windows 95 загрузится быстрее с жесткого диска - не то что с ППЗУ;

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

Хотя, конечно, я лукавлю: был, несомненно, был один большой плюс - элегантная форма, позаимствованная у электрочайника фирмы Tefal. В комбинации с чашкой кофе на столе ваш офис приобретет очень уютный вид. А сколько денег вы сэкономите на затратах владения этим прибором (в основном из-за отсутствия смысла его включения)! Sun и Oracle с NC напоминают мне IBM двухлетней давности со своим PowerPC. Я знаю одного беднягу, купившего тогда это изделие. И сегодня он рад только одному: он купил ЭТО на деньги фирмы, а не на свои кровные…

Позвольте уж и мне, скромному сельскому труженику, высказать свой прогноз по поводу этой борьбы. Если кто-то и сделает слабого клиента, так это опять Microsoft. И им станет Windows CE под старые и знакомые 286, 386, 486. Их действительно очень много, и глупо ставить оператору, которого пока не может заменить датчик, Pentium. В Windows CE есть основные составляющие успеха:

• Word и Excel для локальной и нетехнологичной работы;
• дружба со старшими братьями и знакомое лицо;
• браузер Интернета для создания рабочих мест;
• дешевизна.

Итак, мои советы. Если у вас нет желания (или возможности) менять компьютеры каждый раз, когда Intel создаст новый процессор или Microsoft напишет новую операционную систему, то стоит присмотреться к нашему выбору.

Забудьте о клиенте и отдайтесь серверу. Технология "клиент-сервер". При этом можно тратиться на апгрейд серверной части. Даже на ста клиентах экономия составляет несколько порядков. По экономическим соображениям наш выбор - это MS NT 4.0, IIS 3.0, SQL server 6.5, SMS server.

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

Независимый клиент (забудьте о Dynamic HML от Microsoft или о слоях Netscape; гонка за превосходство извратила идею и ведет по пути расслоения Unix). Используйте теги старых совместимых друг с другом версий HTML.

Минимизируйте использование апплетов, ActiveX и скриптов.

Минимизируйте число поставщиков программного обеспечения.

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

В подтверждение последнего продолжим следующее.

1998 год. Мы решили интегрироваться с "большим братом": сменили MS SQL на Oracle 7. Программы не переделывались. Сменился только драйвер ODBC. Неделя ушла на смену функций и тонкую настройку select'ов к базе. Пользователи так и не узнали, что они стали работать с другим SQL-сервером.

Наконец, последняя модная тема и ее реальные воплощения. Это базы данных для хранения изображений, звуков и прочих нетекстовых элементов. Жизнь, а точнее - господин Починок, есть такой чиновник, выпестованный Магниткой (жаль, что отец у него не Тарас Бульба), заставил нас хранить сканированные образы деклараций до того, как мы их отправим на пограничный пост, и после. Соответственно, их необходимо искать, подбирать и печатать. Мы пробовали хранить изображения в таблицах тех баз данных, которые использовали, но самое эффективное решение оказалось простейшим. Любой документ имеет систему нумерации. Разделив номера по весу разряда так, чтобы в одном каталоге теоретически невозможно было хранить более двух сотен каталогов или файлов (например, документ с номером 123456 хранится в каталоге c:\123\1234\123456.gif), мы получили систему поиска, индексирования и хранения. Зная этот механизм, можно писать программы доступа через браузер или разноски из определенного каталога после сканирования именно в каталог, путь которого зашит в имени. Для этого на Visual Basic создана программа, которая резидентно запущена на сервере и следит за определенными каталогами, выполняя функции менеджера сканерных копий и их принт-сервера, чтобы не загружать клиентов печатью графики. Но главное, что сканированный образ - это просто файл. Он копируется, доступен почти из любой программы, виден из Интернета. Проблемы доступа решаются штатными средствами Windows NT. Так что не всегда самое дорогое есть самое нужное. Нужно определить размер воробья, прежде чем выбирать калибр орудия.

Ну, вот, пожалуй, и все о ваших высоких технологиях применительно к нашей сельской местности.

Для желающих продолжить общение - e-mail: declar1@mmk.ru.