Позвали меня как-то в одну контору перенести оракловый сервер на новое железо, так как старое начало подавать признаки скорой кончины. Задача знакомая: инсталлирую сервисы, настраиваю основные параметры, заливаю базу через импорт-экспорт. Запускаю для проверки пользовательское приложение, написанное кем-то неизвестным на коленке — ошибка, причём дурацкая: «Параметр не является датой». На старом сервере то же самое приложение запускается без проблем. Настройки сервера в порядке. Сравниваю содержимое таблиц — байт в байт. Серверы одинаковые, но на первом прога работает, а на втором — нет.

Воевал с ошибкой до утра. Под конец уже думал, что умом тронулся, ибо в природе такое просто невозможно... В конце концов, конечно, нашёл. Оказалось, что приложение было написано с ошибкой в тексте запроса, вследствие чего в оператор TO_DATE() мог попасть текст, действительно не являющийся датой. Проблема же эта нивелировалась другой ошибкой, но уже на стороне сервера: на нём с рождения ни разу не собирали статистику. В результате то самое кривое значение не попадало в оператор из-за кривого плана выполнения запроса. Настраивая же новый сервер, я машинально поставил сбор статистики на таймер — для Оракла это правильно. Умный оптимизатор сразу же поменял план запроса, и две ошибки перестали компенсировать друг друга.

В общем, уходил я из той конторы под утро злой, с одной мыслью: 99% айтишных проблем мы создаём себе сами, когда ленимся выполнить мелкие, но обязательные вещи.

Есть такой замечательный продукт: SQL-сервер от мелкого и мягкого гиганта IT-индустрии. Помимо полнотекстового поиска, удобной работы с транзакциями и импорта managed-кода, есть в этом продукте как минимум четыре способа перенести базу данных (или её часть) на другой сервер или передать разработчикам в качестве тестовых данных:

1) Бэкап базы данных;

2) Отцепление файла с данными от базы;

3) Пакет мастера экспорта/импорта;

4) Старые добрые SQL-скрипты.

Ну почему, почему из всех этих способов заказчик выбрал именно документ Excel весом в 41 мегабайт, куда вставил четыре проджойненные таблицы?!

По негласной классификации я принадлежу к группе «продвинутый пользователь» со всеми вытекающими плюсами и минусами, особенно в небольшой деревне в депрессивном районе депрессивного региона. Учат тут в соседнем городке К. на специальность «Автоматизированные системы обработки информации и управления». Это присказка, дальше сказка.

Возвращаюсь летом со школьного выпускного. Три часа ночи, ноги уже плохо держат, однако бреду счастливый домой. Тут разрывается в кармане телефон: «Выручай, мне твой телефон дали, у меня дипломная прога не запускается, а сдавать её в семь утра». Не бросать ведь человека!

Приезжают, везут меня за сто километров от родной обители и усаживают перед компом: разбирайся, мол. Открывают код. До мутного сознания начинает доходить, что мне подсунули ни фига не Паскаль, а неизвестный мне Visual FoxPro. Допрос горе-программиста ничего не дал: проект типовой, сам код не кодил, честно скопипастил из нескольких источников. Пришлось тупо курить код без справочника с экспериментальными заменами. Выяснилось, что программер решил перенести своё «творение» на дискету и в соответствии с рекомендациями некоего сенсея заменил относительные пути на абсолютные с кириллической буквой «А» в начале. Естественно, законов DOS никто не отменял, и прога (вернее, БД) вываливалась с ошибкой. На все мои возмущения студент реагировал примерно так: «„А“ — она и в Африке „А“, какая разница, на каком языке?»

Вылеченная БД успешно прошла защиту, а мне была вручена спайка пива, успешно использованная по назначению.

Писал я как-то своей знакомой курсовую на тему «Использование MySQL в веб-разработках». Поскольку теоретические выкладки меня интересовали мало, я сделал для подруги отличный сайт с форумом и блогом, естественно, использующий MySQL. Наступило время объяснять, что же я ей дал, с чем это едят, а главное, рассказать про MySQL. Всё было хорошо до тех пор, пока мы не дошли до структуры базы. Не помогало ничего, и я предложил:

— Давай нарисую!

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

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

Работала давным-давно в отделе автоматизации девочка-программист — ваяла на FoxPro программки по обработке данных. Однажды увидел я кусочек кода, призванного убрать в каждой записи базы данных лишние пробелы слева от фамилии. Код выглядел примерно так:

scan 'цикл по базе

if(at(a.fieldname,” ”)) 'если в первой позиции пробел,

replace a.fieldname with substr(a.fieldname, 2) 'то исключаем первый символ

endif

endscan

Код убирал в каждой записи один пробел слева. «А что, если слева будет 17 пробелов?» — спрашиваю. Девочка потупила взор и поняла, что придётся запускать программу 17 раз.

Каково же было её удивление, когда я показал ей свой код, вернее, одну команду, которая может убрать хоть 17, хоть 30 пробелов и слева, и справа:

replace all a.fieldname with alltrim(a.fieldname)

Намедни мне пришлось мотнуться в прошлое на часок и обратно.

Вызвали в одну конторку, в которую кто-то слил мой телефон. Отказывать людям в помощи не стал, тем более, что просьба звучала безобидно: «Нам бы 62-й счёт в жёлтой проге настроить». Казалось бы, чего там? Рассказать людям, как разносятся платежи и где результаты посмотреть можно. На деле всё оказалось совершенно не так.

Когда я пришёл в контору, мне показали базу складского учета, в которой разносились все платежи. Одним из требований было оформить всё так, как это делал бухгалтер, который недавно уволился. На вопрос продемонстрировать результаты его труда мне принесли огромный гроссбух формата А3, в котором подробно записывались клиенты, суммы их счетов, наценка по счёту в целом, НДС и общая сумма. Зашёл с другой стороны: «А какая бухгалтерская программа есть?» Оказалось, что того же производителя. Людям местные представители благополучно впарили сначала одну версию, а потом другую, более свежую. Ни в одной из этих программ бухучёт налажен не был. Спрашиваю, как же они ведут учёт и отчётность готовят? Оказывается, так по гроссбуху и ведут, а отчётность вносят с бумажек в программу. «Для чего же эти бухгалтерские программы?!» — спросите вы. Я тоже спросил. Блин! Платёжки печатать!

Сначала у меня был порыв оплатить это шоу, но после выхода из конторы появилось желание выпить. Нет, не так — появилось желание нажраться до поросячьего визга, чего я не делал года этак с 93-го, но это уже другая история.

Разрабатываю сайт для одного агентства недвижимости местного значения. Жена моя работает в этом же агентстве менеджером по рекламе — принимает звонки от клиентов и хозяев, распределяет нагрузку между риелторами. На сайте, как и у каждого агентства, представлена база данных квартир. Написал я её на PHP; есть там, конечно же, вход с логином и паролем для зарегистрированных пользователей: риелторы, менеджеры, директор агентства и все остальные, то есть гости. Гостям телефоны хозяев не показывают, только телефон самого агентства. Дескать, звоните, мы вам всё подскажем и денег с вас сдерём.

Стукнуло мне в голову (не просто так, имели место неприятные инциденты) написать систему логов. Если юзер логинился, да ещё и кривой пароль вводил, то в логи тщательно записывалось: входил такой-то с такого-то IP, вводил такие-то логин с паролем. Зарелизились, директор рад: видит, кто работает, а кто груши околачивает — красота!

В первый же день стучится некто к нам на сайт с неизвестного IP, явно пытается брутфорсить: вводит сочетания «login/password», «password/123» и прочие. Среди прочих вводит пару «vladimir/682619». Мы с директором на это взглянули и задумались, что за Владимир такой и почему пароль именно такой выбрал.

— О, а ведь у конкурентов есть риелтор Владимир! — осеняет шефа.

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

Если хочешь показаться умнее остальных и мнишь себя начинающим хакером, в процессе брутфорса не сливай конкурентам свой аккаунт. Вполне возможно, что «для повышения качества обслуживания все разговоры с БД записываются».

Было дело в начале двухтысячных. Работал я в крупной торговой компании; была, естественно, БД со всей жизнью компании внутри. Крутилась в тот момент база на Oracle 8.1.6. И была в учётной политике тогда дурная технология по очистке справочников от неактивных клиентов. Задача ерундовая, на пять-семь строк размашистого кода.

Накопилось опять несколько потенциальных клиентов на убиение. Запускается скрипт — «Получен конец файла по коммуникационному каналу». Это клиент так оповещает, что связь с сервером — тю-тю. Смотрю на службу, а она действительно тю-тю, то есть совершенно в дауне. Запускаем — всё нормально поднялось. Повторяем и... правильно, читаем про конец файла.

Становится интересно — начинаем грохать по одному клиенту. Первый — нормально, второй — нормально, и так далее, пока не попадается нечто с названием «Чего-то-там-Гранит». И на этом гранитном орехе происходил коллапс.

Потом, конечно, и версия движка была повыше, и дурные принципы были пересмотрены, но до сих пор я уверен: неспроста тогда это было, ох, неспроста!

С разным софтом приходится иметь дело приходящим админам. Плохо пишутся офлайновые банк-клиенты, и каждый плох по-своему. Плохо пишут ПО в рамках выигранных в госконторах тендеров. До сих пор перед глазами, как живая, аксессовая «субдина» для бухгалтерии организации, имеющей шестьдесят одновременно трудящихся бухгалтеров — кто по RDC, кто напрямую — на одну несчастную .mdb. Но речь пойдёт не о них.

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

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

При нормализации реляционной базы данных до болгарской нормальной формы на каждый учитываемый объект заводится от 7 до 50 штук маленьких, но очень гордых .dbf, в каждом из которых парой строчек описывается очередной признак или атрибут объекта. И не ссылками на записи в библиотеках, а именно сами признаки и атрибуты — словами. Надо ли объяснять, что при накоплении пары сотен тысяч объектов база распухает до сотен гигов этих самых мелких файликов? Для пущего антуража пишется всё это безумие на болгарифицированном FoxPro. Вы знаете, что означают слова «грешка» и «забележка»? А любой специалист, пытавшийся работать с этим чудом, знает, что это «ошибка» и «ярлык».

База размещается строго в папке, в которой установлена программа, а программа — строго в C:\%ProgramName%\, и никаких компромиссов. Экзешник должен быть запущен из-под админской учётки — это защита от воровства такая, программа постоянно тычется в сервак горе-разработчика, подтверждая свою легальность. Папка программы обязательно должна быть расшарена на полный доступ. Мало того, должен быть открыт полный доступ к трём DLL в System32, как вы его организуете — ваша забота. Приложения работают непосредственно с базой напрямую, программист не слышал ни о каких технологиях доступа к данным.

Всё это венчает достойная отдельного абзаца монументальная Марья Петровна, «человек-за-всё», с ложкой в правой руке в качестве скипетра и литровой банкой домашних щей в левой в качестве державы ведущая активную работу на имеющем безлимитное подключение к инету P4 с одним IDE-винтом на 160 гигов — рядом с мокрыми зимними сапогами, без бесперебойника, на одном оплавленном удлинителе с калорифером. (Выдохнул.) Мечта админа.

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

К сожалению, рынок сбыта этой программы ограничен спецификой предметной области, и нормально профинансировать разработку ПО на замену этому безобразию — дело довольно рискованное. Так что конкурентов у этого чуда практически нет, и возрастает ценность меня как специалиста по болгарским нормальным формам, знающего, куда бить кувалдой в случае чего.

На работе прислали новую версию программы. Старая версия была ужасна — новую я уже «люблю» за вот такой пассаж из прилагаемой инструкции:

Пользователи версии 2.01 могли заметить ошибку при автоматической нумерации выдаваемых справок. Данная ошибка возникает из-за неравномерности записи данных в базу. Эта неравномерность вызвана неправильной эксплуатацией вашего компьютера, а именно возникает от частой записи и удаления файлов (или программ) больших объёмов. Чтобы устранить эту неравномерность, необходимо регулярно проводить дефрагментацию логических дисков вашего компьютера.

Зацените, как надо делать — валить глюки своей проги на фрагментирование диска! Это ж додуматься надо.