файл отрицательного размера

Единственная программа, написанная на похапе, которая мне нравится – это Zabbix!
Сегодня утром он прислал уведомление, что на одном mysql-slave-сервере слишком большая задержка относительно master’а, более двух часов:

Причём там и Slave_IO (скачивание логов с master’а и сохранение их у себя), и Slave_SQL (выполнение операторов из тех логов) всё время работали:

Оригинал этой записи в личном блоге.

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

А иногда при применении внесённых изменений pfsense почему-то перегружался.. Но потом всё же успешно загружался и продолжал работать.

А вот сегодня после внесения очередного мелкого изменения — пропал.. Я ждал минут пять, а он так и не появился. Заполз в него через консоль, и оказалось, что там опять IP-адреса на всех сетевых интерфейсах потерялись. Пробовал подсовывать прежние варианты конфигов из его бэкапной директории и перегружать — а фиг, всё то же самое, при загрузке не может разобрать этот xml, потому и не знает, какие адреса приделывать.

Хотя когда я вручную приделал ему адрес (ifconfig’ом) и маршрут (route’ом), и зашёл в его веб-интерфейс, то там у него все настройки успешно виделись, в том числе и для сетевых интерфейсов. То есть, там этот конифг успешно читается, а в процессе загрузки почему-то нет..

Потом попробовал как в прошлый раз factory reset, настроил сетевые параметры, а после перезагрузки он их из этого совсем маленького свежесозданного конфига всё равно почему-то прочитать не может. Вот же уродские быдлокодеры..

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

Потом ещё попробовал подложить туда однозначно рабочий конфиг от новой версии (со своей виртуалки, где я экспериментировал с обновлением старой версии pfsense до нынешней). А всё та же фигня — не может этот xml прочитаться в процессе загрузки, хотя в веб-интерфейсе вполне может. Но и при попытке через веб-интерфейс что-то слегка поменять, чтоб конфиг заново переписался, всё равно вылезает хрень:

Или ещё больше:
Fatal error: Cannot create references to/from string offsets nor overloaded objects in /etc/inc/xmlparse.inc on line 103 Call Stack: 0.0001 245880 1. {main}() /usr/local/www/vpn_ipsec_phase1.php:0 0.0943 4425904 2. write_config() /usr/local/www/vpn_ipsec_phase1.php:550 0.6794 4967024 3. cleanup_backupcache() /etc/inc/config.lib.inc:593 30.6301 8763792 4. parse_xml_config() /etc/inc/config.lib.inc:859 30.6302 8764280 5. parse_xml_config_raw() /etc/inc/xmlparse.inc:178 31.5878 11278400 6. xml_parse() /etc/inc/xmlparse.inc:217 31.5878 11278776 7. startElement() /etc/inc/xmlparse.inc:217 PHP ERROR: Type: 1, File: /etc/inc/xmlparse.inc, Line: 103, Message: Cannot create references to/from string offsets nor overloaded objects

Видать, там не всё обновилось, а какие-то кривые старые скрипты ещё остались и продолжают поганить систему.

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

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

Оригинал этой записи в личном блоге.

В смысле, не просто язык (иногда мне самому случается на нём писать), а типичных похапешных программистов, пишущих уродские программы.

Итак, имеется софтина SSH Key Management, которая предназначена для автоматизированного раскладывания ssh-ключей на удалённые сервера. Идея полезная, так гораздо удобнее и быстрее добавлять и удалять юзерские ключи, чем вручную, и заодно можно в одном месте посмотреть, у кого на какой сервер какой доступ есть, а не лазить на каждый сервер и не искать там вручную.

Раньше она везде успешно работала, а сегодня про один новый сервер внезапно стала ругаться, что не может там скопировать authorized_keys2, что она всегда делает в качестве бэкапа. Зашёл на сервер, посмотрел — а копии-то вполне себе есть.. Так как же она их успешно создаёт, и при этом считает, что не вышло?!

Пошёл копаться в коде, и, как водится, обнаружил множество идиотизмов.

Оригинал этой записи в личном блоге.

а студент-двоечник.

Категории и тэги лежат в одной таблице. Зачем — непонятно, но это ещё фигня. Таблица выглядит так:

CREATE TABLE `wp_terms` (
  `term_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(200) NOT NULL DEFAULT '',
  `slug` varchar(200) NOT NULL DEFAULT '',
  `term_group` bigint(10) NOT NULL DEFAULT '0',
  PRIMARY KEY (`term_id`),
  UNIQUE KEY `slug` (`slug`),
  KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Что такое term_group — загадка природы, там у всех записей 0.
slug — это URL-encoded name. Им лень было при обработке запросов в /tag/ и /category/ сделать url-decode и поискать по имени, лучше сделать лишнее поле. Причём поле это такой же длины, как и name, а один неанглоязычный символ из name в url-encoded виде занимает 6 байт, например буква “л” выглядит в slug как %d0%bb . А вот почему slug сделан уникальным ключом, а name неуникальным — загадка природы.

А тип записей в wp_terms вообще отсутствует. Он ВНЕЗАПНО лежит в другой таблице:

CREATE TABLE `wp_term_taxonomy` (
  `term_taxonomy_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `term_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `taxonomy` varchar(32) NOT NULL DEFAULT '',
  `description` longtext NOT NULL,
  `parent` bigint(20) unsigned NOT NULL DEFAULT '0',
  `count` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`term_taxonomy_id`),
  UNIQUE KEY `term_id_taxonomy` (`term_id`,`taxonomy`),
  KEY `taxonomy` (`taxonomy`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Вот в ней в поле taxonomy хранит тип записи. В текстовом виде: “category”, “post_tag” или “link_category”. И в сочетании с term_id оно составляет уникальный ключ. То есть, если попытаться создать и категорию, и тэг с одинаковым именем, то в wp_terms будет только одна запись, а в wp_term_taxonomy – две, с одинаковым term_id. Но это такая редкость, что экономить единичные записи в таблице, существенно усложняя при этом поиск по имени (join двух таблиц вместо простого поиска в одной) — это идиотизм.

Что есть parent — я вообще не понял, там всегда 0. А count (руки оторвать за использование названий стандартных функций в качестве имён полей) по идее должен хранить количество постов, привязанных к данной категории или тэгу. И для большинства записей это действительно так. Но иногда..

mysql> select term_taxonomy_id, count from wp_term_taxonomy where term_taxonomy_id = 1;
+------------------+-------+
| term_taxonomy_id | count |
+------------------+-------+
|                1 |  1933 |
+------------------+-------+

mysql> select count(*) from wp_term_relationships where term_taxonomy_id = 1;
+----------+
| count(*) |
+----------+
|     3708 |
+----------+

Ничего общего.. И даже если посчитать только опубликованные посты (исключить черновики и старые версии), всё равно не совпадает:

mysql> select count(*) from wp_term_relationships r join wp_posts p on r.object_id=p.ID where r.term_taxonomy_id = 1 and p.post_status='publish';
+----------+
| count(*) |
+----------+
|     1936 |
+----------+

Оригинал этой записи в личном блоге.

Пытаюсь разобраться в структуре базы wordpress’а… Там есть таблица wp_comments, в ней, очевидно, лежат комментарии. Сотня:

mysql> select count(*) from wp_comments;
+----------+
| count(*) |
+----------+
|      101 |
+----------+

А ещё есть таблица wp_commentmeta, в которой лежит в шесть раз больше не пойми чего..

mysql> select count(*) from wp_commentmeta;
+----------+
| count(*) |
+----------+
|      667 |
+----------+

mysql> desc wp_commentmeta;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| meta_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| comment_id | bigint(20) unsigned | NO   | MUL | 0       |                |
| meta_key   | varchar(255)        | YES  | MUL | NULL    |                |
| meta_value | longtext            | YES  |     | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+

meta_key там везде одинаковый:

mysql> select distinct meta_key from wp_commentmeta;
+-----------------------+
| meta_key              |
+-----------------------+
| _wp_trash_meta_status |
+-----------------------+

А значений у него целых два, 0 и 1:

mysql> select distinct meta_value from wp_commentmeta;
+------------+
| meta_value |
+------------+
| 1          |
| 0          |
+------------+

Но при этом имеющиеся там comment_id совершенно не совпадают с теми, что есть в wp_comments:

mysql> select count(*) from wp_commentmeta where comment_id in (select comment_id from wp_comments);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

Я фигею, дорогая редакция.

Оригинал этой записи в личном блоге.

Попробовал экспортировать блог из вордпресса и импортировать его в другой движок. Фигтам, импорт сломался, ругнувшись на некорректный формат pubDate. Пошёл смотреть, что там в экспортном xml, офигел. Первый год до нашей эры:

$ grep pubDate wordpress.2014-05-02.xml
<pubDate>Wed, 13 May 2009 21:36:54 +0000</pubDate>
<pubDate>Fri, 15 May 2009 11:42:31 +0000</pubDate>
<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
<pubDate>Sun, 17 May 2009 18:48:06 +0000</pubDate>
<pubDate>Mon, 18 May 2009 13:06:05 +0000</pubDate>

“Давайте отрубим крокодилу хвост до самой головы!” Чтоб эти быдлокодеры больше не брались писать программы.

Upd: выскрытие показало, что так выглядит дата публикации черновиков (неопубликованных постов). Причём в базе у них дата вполне себе есть. Нету лишь даты в GMT:

mysql> select ID, post_date, post_date_gmt, post_status, post_modified, post_modified_gmt from wp_posts where post_date_gmt=0;
+------+---------------------+---------------------+-------------+---------------------+---------------------+
| ID   | post_date           | post_date_gmt       | post_status | post_modified       | post_modified_gmt   |
+------+---------------------+---------------------+-------------+---------------------+---------------------+
| 3955 | 2012-03-26 06:38:53 | 0000-00-00 00:00:00 | draft       | 2012-03-26 06:38:53 | 2012-03-26 06:38:53 |
| 5347 | 2013-05-07 09:51:35 | 0000-00-00 00:00:00 | draft       | 2013-05-07 09:51:35 | 2013-05-07 09:51:35 |
+------+---------------------+---------------------+-------------+---------------------+---------------------

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Теперь в него добавили генераторы в стиле питона..
via

Оригинал этой записи в личном блоге.

In early stages of Internet, developers were forced to work with poor, dry, functional, horrific languages. Everything had to be done through austere functions and operators. There was no objects. No interfaces. No dependency injection.

For example, to make something as simple as an addition, our dads had to write: 1+1. Yeah, really.

Hopefuly now, we have PHP 5.3 and its solid OOP implementation. SimplePHPEasyPlus lets you make this addition in a more fashionable way, using real OOP. It is fast, simple, flexible and tested. To add 1 to 1, all you have to do is:

use SimplePHPEasyPlus\Number\NumberCollection;
use SimplePHPEasyPlus\Number\SimpleNumber;
use SimplePHPEasyPlus\Number\CollectionItemNumberProxy;
use SimplePHPEasyPlus\Parser\SimpleNumberStringParser;
use SimplePHPEasyPlus\Iterator\CallbackIterator;
use SimplePHPEasyPlus\Operator\AdditionOperator;
use SimplePHPEasyPlus\Operation\ArithmeticOperation;
use SimplePHPEasyPlus\Operation\OperationStream;
use SimplePHPEasyPlus\Engine;
use SimplePHPEasyPlus\Calcul\Calcul;
use SimplePHPEasyPlus\Calcul\CalculRunner;

$numberCollection = new NumberCollection();

$numberParser = new SimpleNumberStringParser();

$firstParsedNumber = $numberParser->parse('1');
$firstNumber = new SimpleNumber($firstParsedNumber);
$firstNumberProxy = new CollectionItemNumberProxy($firstNumber);

$numberCollection->add($firstNumberProxy);

$secondParsedNumber = $numberParser->parse('1');
$secondNumber = new SimpleNumber($secondParsedNumber);
$secondNumberProxy = new CollectionItemNumberProxy($secondNumber);

$numberCollection->add($secondNumberProxy);

$addition = new AdditionOperator('SimplePHPEasyPlus\Number\SimpleNumber');

$operation = new ArithmeticOperation($addition);

$engine = new Engine($operation);

$calcul = new Calcul($engine, $numberCollection);

$runner = new CalculRunner();

$runner->run($calcul);

$result = $calcul->getResult();
$numericResult = $result->getValue(); // 2

This library is now available for production purposes. Enjoy!

Отсюда
via

Оригинал этой записи в личном блоге.

на слово PHP.NET ?

Мне так на несколько секунд стало дурно

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

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

С таким подробным отчётом локализация ошибки становится исключительно простым делом.

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

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

Оригинал этой записи в личном блоге.