Маша, электронную почту не приносили?

Дародная цётка, кіраўніца нейкага там аддзелу буйного прадпрыемства пытаецца ў сакратаркі. "Нет еще. Может через полчаса будет." — адказвае тая.

Пры капіталізме прадпрыемства зацікаўлена ў выкарыстоўваньні найноўшых тэхналёгіяў, каб быць на паўкрока наперадзе канкурэнтаў. Пры рынкавым сацыялізме найноўшыя тэхналёгіі насаджваюцца зьверху загадамі ды дырэктывамі. Вось загадалі ўсім зрабіць сайты. Потым перакласьці іх на ангельскую (тое бяды, што на прадпрыемстве па ангельску размаўляць ніхто не умее). Цяпер трэба карыстацца электроннай поштай. Абавязкова, бо з выканкаму абяцалі праверыць. А што рабіць, калі топ мэнэджэры толькі-толькі асвоілі як той кампутар уключаць-выключаць? Правільна: садзім хлопчыка і ён кожны дзень добрасумленна раздрукоўвае электронныя лісты. Настолькі добрасумленна, што раздрукоўваецца нават спам, улучна з нігерыйскімі лістамі, кітайскім ролексам, віяграй без рэцэптаў ды іншымі падаўжальнікамі пенісаў.

Все, что нажито непосильным трудом :)

3157 страниц — такой объем документации по Гедымину, платформе и настройкам, имеем мы на сегодняшний день. Включая wiki, но не считая статей на сайте. Конечно, там есть повторы; в подсчет попали страницы оглавления, указателей, заголовки разделов и т.п. Но, даже если отнять половину, все равно останется более полутора тысяч страниц полезной информации.

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

Такой редактор должен прочитать все, разбить на части и каталогизировать. Подсказать чего не хватает, что раскрыть подробнее, где выкинуть лишнее, какие главы переписать, где описанная функциональность не соответствует существующей. Из откорректированных частей собрать две книги: Руководство пользователя и Руководство разработчика, объемом по 600-800 страниц каждая. Подготовить их к изданию.

И тогда останется всего ничего: заставить наших пользователей и разработчиков прочитать эти руководства.

Растет как на дрожжах

Инстоляция Adobe Acrobat Reader 9.3.3 завешивает на все 52.1 Мб! А когда-то хватало и пяти (инстоляция Acrobat Reader v 4.0, поставляемая на компакт-диске с программами Анжелика имела размер 5,4 Мб). Bloatware во всей его красе.

Проверка структуры базы на повреждения

В развитие предыдущего поста. В некоторых базах (но не всех!) из тех, где не проходит команда изменения домена или создания чека, ситуация еще хуже: несколько чеков из разных таблиц ссылаются на один и тот же системный триггер. Проверить можно с помощью такого запроса:

select *
from rdb$relation_constraints rc1 
  natural join rdb$check_constraints cc1
where cc1.rdb$trigger_name in
(
   select cc.rdb$trigger_name
   from rdb$relation_constraints rc 
     natural join rdb$check_constraints cc
   where rc.rdb$constraint_type = 'CHECK'
   group by cc.rdb$trigger_name
   having count(*) > 1
) 

Ошибочка в RC 3 FB 2.5 (и более ранних релизах)

Вдруг откуда ни возьмись вылезла неприятная ошибка в FB. На некоторых базах не проходит команда изменения дефолтного значения для домена (например, ALTER DOMAIN domain SET DEFAULT 0), а так же не создаются ограничения CHECK на поля. При этом сервер выдает сообщение об ошибке:

This operation is not defined for system tables.
unsuccessful metadata update.
DEFINE TRIGGER failed.
action cancelled by trigger (1) to preserve data integrity.
Cannot update trigger used by a CHECK Constraint.

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

Разработчики FB поставлены в известность. Предположительно, сбой в структуре метаданных возникает (не всегда!) при миграции с Yaffil и Firebird 2.0 на 2.5.

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

Как удалить все записи

Приведенная команда позволяет удалить все документы, которые не заблокированы ссылочной целостностью или триггерами:

execute block
as
  declare variable id integer;
begin
  for select id from gd_document into :id
  do begin
    delete from gd_document where id=:id;
    when any do begin end
  end
end

Очевидно, что вместо gd_document можно указать, например, gd_contact и почистить справочник клиентов.

НЕ ИСПОЛЬЗУЙТЕ НА РАБОЧИХ БАЗАХ КЛИЕНТОВ!

PS: И, да, у нас полумиллионный посетитель на сайте!

Pascal forever

Apple has opened sources of their MacPaint and QuickDraw applications. Naturally, it had been done in Pascal with some assembler insertions. The sources are available from this Computer History Museum page.

Для тренировки зрения

Посадили дерево

В наших интервальных деревьях всю жизнь была ошибка. Интервалы перекрывались в следующем случае: есть два элемента A и B, имеющих одного родителя. A расположен левее B. Пусть B имеет два дочерних элемента C и D, примыкающих друг к другу, причем C расположен левее D и интервал C уже D. Тогда, при перемещении D в A, в процессе расширения интервалов вправо, интервал C будет перекрываться с A и B.

KISS

Компоненты IBX имеют жутко навороченный механизм трассировки SQL команд: монитор, хук к нему, интерфейс к хуку и две нити, для чтения и записи лога. Вероятно была попытка сделать монитор, который бы минимально тормозил текущие операции (отсюда раздельная запись и чтение в обособленных нитях), и позволял бы менять движки как перчатки (отсюда хук и интерфейс, кстати достаточно бесполезный, так как объявляется в самом модуле монитора и завязан на объявления прочих объектов из этого модуля).

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

Новый механизм был создан за два дня, буквально следуя принципу KISS — Keep It Simple Stupid. В его основе объект истории SQL запросов (TgdcSQLHistory) и копия интерфейса борландовского SQL монитора. Везде, где надо, через условную компиляцию мы подменили обращение к модулю IBSQLMonitor.pas на IBSQLMonitor_Gedemin.pas.

Лог трассировки находится в SQL редакторе на соответствующей вкладке. Там же — чек-бокс для включения/выключения и кнопка очистки. Трассировку можно также активировать параметром командной строки /trace.

Жорсткая праўда беларускага інтэрнэту

Адзін з найбуйнейшых айчынных правайдэраў, Деловая Сеть, мае канал у 750 Мбіт/с на... 6 000 кліентаў. Які тут анлім. Калі ўсе разам пойдуць у сеціва атрымаецца па 125 Кбіт/с на брата. У іншых "незалежных" правайдэраў каналы яшчэ вузейшыя. І ўсе разам яны ўпіраюцца ў ліміт знешнега каналу нашага горача любімага манапаліста Белтэлекома, які ў заходнім накірунку складае менш за 16 Гбіт/c. Калі падзяліць на колькасць карыстальнікаў сеціва (4 млн), дык кожнаму дастанецца ажно па 4 (Чатыры!) Кбіт/с.

Дело было не в бобине

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

Либо сбой в алгоритме (тронуться можно, если пытаться проследить его работу в уме), либо (что гораздо хуже) сбой в сервере при многократных рекурсивных вызовах процедур и триггеров.

Будем искать.