Ушёл на базу. Через шифрованную дырку.

С открытием второй пиццерии (с моей точки зрения - с развёртыванием второй системы управления производством) возникли вопросы взаимодействия:

Как дать возможность оператору отправить заказ на нужную пиццерию?

Как формировать консолидированные отчёты по двум точкам?

Как синхронизировать меню, цены, акции, дисконты, купоны - всё, что может измениться в любой момент?

Вариант master/slave в MySQL сразу не рассматривал, потому что схема должна быть такой, чтобы пережить атомную бомбардировку: уцелевшие пиццерии должны продолжить автономную работу несмотря на оборванные провода и исчезнувшие соединения.

Это можно сделать через REST: куча писанины и куча новых ошибок.

Либо обращаться к базе удалённо.

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

Немножко почитал интернеты и понял, что понадобится:

autossh - надстройка над ssh, поддерживающая соединение в рабочем состоянии, пока это возможно;

авторизация на основе ключей.

И всё.

К слову, Гугл по поиску autossh в третьей позиции даёт ветку под названием "Чтоб вы знали: autossh - полное дерьмо". Я её внимательно изучил. Она меня не убедила.

Ещё нужен скрипт для управления autossh как службой, он находится здесь и отлично встраивается в Debian.

Смотав это всё синей изолентой, получаем на сервере А новый порт MySQL, открытый в тьму внешн базу данных сервера Б, без создания новых дырок, через зашифрованное, автоматически устанавливающееся и магически восстанавливающееся соединение.

Дальше - с отвёрткой в зубах - в PHP-класс работы с SQL. Здесь делаем выбор параметров соединения из массива предопределённых вариантов. Важно: если сервером указывать localhost, запрос такого-то порта будет проигнорирован. Поэтому указываем 127.0.0.1. Вроде хрен и редька, а вот хрен.

Настало время первой проверки. Пишем коротенький скрипт, который запрашивает максимальные идентификаторы из таблиц заказов серверов, разнесённых на некоторое количество километров:

Холишыт, это действительно работает!

Дальше так: в интерфейс операторов, принимающих заказы с доставкой, добавляем выбор пиццерии:

Чуть позже по умолчанию будет та, чей этот клиент географически.

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

Дальше надо поэкспериментировать и понять, как лучше строить консолидированные отчёты: federated table?

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

Печать чеков на Posiflex Aura: траблшутинг

Как уже сообщалось, произошло обарывание принтера Posiflex Aura для печати из-под CUPS; как оказалось, не окончательное.

При попытке перехода на новую схему оказалось, что некоторые чеки выходят в виде вертикальных полос либо просто чёрным листом с обрывком контента внизу. Их PDF выглядят такими же, как и нормально печатающиеся. Загадка? Загадка.

Надо думать. Теорию суперструн вон придумали, а ср@ные полоски на бумаге не осмыслим? Так не бывает.

Вот драйвер принтера переварил PDF и выдал растровую страницу. Вот она пошла в принтер. Может переполниться память? Если она есть, то может.

Посмотрел спецификацию принтера. Памяти страниц нет. Есть входной буфер размером 10К.

Значит, принтер не запоминает всё задание перед печатью. Выводит поток на ленту и тут же забывает. Логично: все нелазерные принтеры так работают.

Очевидно, размер буфера рассчитан так, чтобы в нём поместились данные, втекающие в трубу одного диаметра и вытекающие из трубы другого. В нормальных условиях.

Теперь смотрим на PDF, который мы печатаем. Начало.

Что, если жирный логотип сразу забивает буфер и не успевает утечь в дренаж? Buffer overrun. Скорее всего, часть данных будет потеряна; затем напечатается обрывок нижней части. Размер чека будет таким, будто всё напечатано правильно: скорее всего, он передаётся в задании.

Это именно то, что мы имеем.

Проверяем. Открываем шаблон PDF и комментим лого. Надо же - всё печатается хорошо.

Исправляем в стиле логотипа ширину: 40 мм вместо 70. Полёт нормальный.

Ставим 50 мм. Нормально.

Где-то между 50 и 70 находится критический размер, дающий битмап под 10К. Я не стал его выяснять: 5-сантиметровое лого ОК.

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

select count(ID) as c, order_id 

from ########## 

group by order_id order by c desc limit 1

Получаем заказ из 52 позиций, это исторический максимум со среза базы в январе.

Печатаем его чек. Две 32-сантиметровые страницы, всё чётко. С логотипом.

Последнее: уменьшенный логотип имеет некрасивые края: dithering. Открываем Gimp, меняем печатный размер лого: 50 мм при разрешении 8 dpmm (из спецификации). Переводим в 1-битный битмап и сохраняем. О, печатается намного лучше!

Последнее. Открываем скрипт печати и переключаем вывод сокета TCP на очередь CUPS.

Трибуны беснуются.