the beatles

некоторое время назад, благодаря постоянным «новостям» о том, что битлы наконец проложат свой путь в itunes music store, я решил таки послушать что и как они поют. и это оказалось для меня потрясением — большинство песен с точки зрения звука оказались беспомощным говном. я был в шоке от этого феномена и решил не обращаться к этой теме больше. но недавно услышал как fiona apple поет их песню и понял, в чем дело.

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

например — битлы:



и fiona apple:



второй по звуку для меня на порядок приятнее.

restore data from broken hdd

сохранность данных

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

восстановление данных

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

дальше уже все было просто — подключаем в powermac, запускаемся, с трудом грузимся, монтирование диска происходит в течении десятка минут. на диске у меня два раздела и если второй смог показаться в finder и я спокойно смог начать копировать с него данные, то первый не мог ни подключиться, ни пройти верификацию в disk utility. тут я вспомнил, что были две программы, которые могли бы помочь мне скачать информацию даже с такого раздела. этими программи оказались TechTool Pro 4.6.2 и Data Rescue II.

кратко о том, каков у них принцип работы.

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

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

TechTools Pro — это такой небольшой комбайн для тыканья ответкой в разные чувствительные части вашего мака. он вроде может определить неисправность основных узлов и сказать, что с вашим алюминием в порядке, а что — не совсем. заодно может создать специальный скрытый раздел на диске с собой любимым и как–бы восстанавливает данные.

программа проработала около 14 часов и прогресс остановился. я нажал кнопку отмена и она (о чудо!) и вывела список директорий, которые она думала, что могла бы восстановить. спустя три часа после копирования одного из файлов я решил прервать этот процесс, потому как у меня было ощущение, что это не закончится никогда. результат: около 20 часов работы, около 20 восстановленных файлов из нескольких каталогов в домашней директории. вернуться к списку директорий мне не позволили и это полностью определило дальнейшую судьбу программы — она отправилась в корзину. если остальные функции этой программы реализованы также хорошо, то она не стоит своих денег и … вообще ничего не стоит.

Data Rescue II «умеет» только восстанавливать файлы. но функциональность в целом схожа с восстановлением у TechTools Pro. то есть софт чрезвычайно долго мурыжит диск, потом выдает список «восстановимых» файлов и при выборе мучительно пытается их восстановить. завершения процедуры я не дождался, на часах уже были третьи сутки с момента падения диска.

эти программы дали мне довольно много информации о том, как вообще живет софт восстановления данных на mac os x. его просто нет. бэкапьтесь почаще!

как показал гугл, восстановление данных с диска формата hfs+ стоит от 250 евро. в моем случае нужно было бы еще и убирать гермоблок, то есть еще около 100 евро. данные, которые у меня были не сохранены, столько не стоили и я решил попробовать сам все скопировать.

закат солнца вручную.

эта часть повествования относится скорее к unix geek, чем к обычным пользователям. поэтому ее можно прочитать как руководство к действию, а можно вообще не читать, пока у вас ничего не случилось.

подготовка

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

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

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

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

допустим, вам повезло

стоит понять, какая вероятность того, что ваши данные восстановимы. если диск монтируется и с него даже худо–бедно что–то копируется, то вам повезло. точно также вам повезло, если вы сможете подмонтировать диск с помощью команды mount_hfs -j (это значит, что вы просто проигнорировали журнал при монтировании). это и было степенью моего везения. после этого я с помощью команды cp в терминале (Finder перестает копировать файлы после первой ошибки) получил все важные данные (некоторые не скопировались, конечно, но основное я получил). при этом я скопировал всего 3 гигабайта из 45 в течении часа. это одна из причин, почему план спасения данных, расписанный вплоть до файлов с директориями — хорошая идея. при этом начало диска оказалось безнадежно испорчено — 200 мегабайт из начала копировались 4 часа. но тут уж как повезет.

возможно, не повезло

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

dd bs=4096 if=/dev/disk2s2 of=/Volumes/vert/tristane.dmg conv=noerror,sync

где 4096 — размер блока, /dev/disk2s2 — это ваше отвалившееся устройство, /Volumes/vert/tristane.dmg — место и файл, куда будут сбрасываться полученные данные. эта процедура может длиться очень долго. может даже недели. так что озаботьтесь доставкой пиццы и кока–колы для себя и бесперебойным питанием для компьютера, на котором вы будете переливать все из пустого (все непрочитанные блоки dd забивает нулями) в порожнее. кроме того, за этим компьютром вам будет сложно работать, потому что иногда система перестает отвечать. еще раз повторю, что, возможно, ждать придется долго.

допустим, у вас спустя время создался образ вашего диска. вот теперь вы можете напустить на него Data Rescue II. есть вероятность, что он даже найдет в образе несколько файлов.

ну и в последний раз повторюсь — не хотите производить эти все операции — делайте backup.

usability sucks

http://www.ibm.com/developerworks/ru/library/os-whistle/index.html

напоминает анекдот:

«В одной деревне жил старичок, который мог напердеть любую мелодию. И вот
узнали об этом телерепортеры. Приехало к нему телевидение, берут,
значит, интервью.
Журналист: А правда, что вы можете напердеть любую мелодию?
Старик: Да, конечно.
Журналист: А "Калинку-малинку" можете?
Старик: Могу.
И напердел мелодию.
Журналист: А " Во саду ли в огороде" слабо?
Старик: Нет.
И тоже напердел песенку.
Журналист: А что-нибудь из классики вы могли бы напердеть?
Старик: Например?
Журналист: Ну, например, Моцарта?
Старик: Не знаю, давайте ноты.
Ему дают ноты, он около 10 минут пристально смотрит на них.
Журналист: Ну так что, сможете?
Старик: Нет, не смогу.
Журналист: Почему же?
Старик: Да тут в 2 местах обосраться можно»

и это снова я про mysql

новыя знания — новыя печали

теперь я использую mysql таким образом:

"DBI:mysql:database=regru_auction;mysql_multi_statements=1;mysql_enable_utf8=1;mysql_auto_reconnect=1"

тогда есть надежда, что можно сразу несколько statements в do напихать, но я уже этим не пользуюсь. парсить sql оказалось проще, чем договориться с mysql.

причем, как показывает опыт, последний флаг не работает вообще. как был morning bug, так и остался. Apache::DBI отдыхает.

но это не все. после ошибки DBD::mysql становится нестабильным и может порождать ошибки типа таких:

DBD::mysql::st bind_columns failed: bind_columns called with 1 values but 10 are needed [for Statement "select count(*) from `auction` "]

для тех, кто в танке: иногда имеет смысл запустить возможно ошибочное sql выражение, чтобы не трясти базу лишний раз. а именно, вместо проверки, есть ли пользователь с таким username/password просто попытаться пользователя туда вставить. тогда, в случае ошибки, мы можем сказать: «э нет, чувак, такое как ты уже есть». ха. не в случае mysql. случай mysql:

eval {
$dbh->do (…);
};

if ($@) {
$dbh->disconnect;
Core::make_new_dbh ();
}

ну и сладкое напоследок.

есть вероятность не выйти из транзакции. то есть после commit или rollback есть вероятность остаться в транзакции со всеми вытекающими. в мануале предлагают дисконнектиться и соединяться заново. а, ну и autoreconnect в таком случае отключается -)

P.S.: совсем забыл. если создать mysql dbh и форкнуться, то есть вероятность чрезвычайно круто попасть впросак, потому что как–то оно очень хуево после этого работает.

мудаки.

migration postgresql => mysql

есть достаточно большое количество statements, которые после запуска не могут быть rollback. список: для 5.0, для 5.1, то есть mysql не является ACID compliant, хотя оно заявлено.

drop table if exists temp_test_one, temp_test_two;

begin;
create table temp_test_one (a int, b int);
rollback;

-- fail here, create table caused implicit commit
create table temp_test_one (a int);


begin;
alter table test1 drop b;
rollback;

-- fail here, because alter table also caused implicit commit
alter table test1 drop b;

по непонятным для меня причинам, второе поле типа timestamp не может принимать значение now() при вставке, что делает возможным создание поля created только с помощью триггера. зато первое поле такого типа по умолчанию апдейтится при каждом обновлении записи. вот такая долбаная магия.

-- fail here, error: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause (WHY?)
create table temp_test_two (created timestamp default now(), updated timestamp default now());

-- fail here because first timestamp column have default now()
create table temp_test_two (updated timestamp, created timestamp default now());

create table temp_test_two (updated timestamp, created timestamp);

-- now updated column being updated on any update

триггеры может создавать только пользователь с правами super (вроде, в 5.1 они это поправили)

-- fail here if you don't have super privilege (5.0)
create trigger temp_test_two_bcreate before insert on temp_test_two for each row set new.created = now();

чюваки из mysql до сих пор не смогли написать нормального парсера, чтобы разграничивать внутренности процедур от остального sql кода.

-- fail because you don't set delimiter (stupid mysql parser can't recognize trigger end without separation delimiters inside trigger and outside)
create trigger contact_aupdate after update on contact
for each row begin
if new.contact_auth = 'ok' then
update domain set domain_authenticated = true, domain_state = 'auth' where auth_contact_id = new.contact_id;
end if;
end;

теперь про перл

mysql не может запускать сразу два statement в одном do; если сделать fork, то придется создавать новое соединение, так как старое привязано к process id.

my $dbh = DBI->connect;

my $pid = fork;
if ($pid) {
# failed because you can't launch two statements at same time
$dbh->do ('drop table if exists temp_test_one; drop table if exists temp_test_two; ');
} else {
# failed because cloned dbh doesn't work
$dbh->do ('drop table if exists temp_test_one, temp_test_two;');
}

короче, если нет возможности использовать что–то другое, то можно, иначе — нужно как можно быстрее избавляться от mysql в пользу postgresql и/или sqlite.

perl death is postponed

в последнее время начал работать с перлом серьезно (весь в кишках). и как–то так получилось, что уже в третий раз нахожу в нем ошибку. один товарищ сказал, что пора переключаться на java — там я буду дилетантом и не буду соваться во всякую мутную низкоуровневую поебень.

меня больше тянет к ruby, потому что по архитектуре java меньше подходит в качестве web языка. но, судя по последним данным, вряд ли я стану ruby или java специалистом.

давайте посмотрим на вот эту картинку:


по ней явно видно, что перл держится молодцом между enterprise level java и активно продвигаемым одной небезызвестной компанией ASP.NET.

как всем уже давно известно, perl не развивается. но не в том смысле, что не появляется чего–то нового. а скорее в том плане, что без большого объема общения сложно выяснить, что же стоит использовать и для каких целей. для тех же accessors в перле есть не один десяток модулей. то же касается web frameworks, ORM. короче, трендов нет, есть одна глобальная помойка под названием cpan. нет инструментов и удобных frameworks. но есть куча перлового кода, который был написан и будет написан и все это барахло нужно поддерживать.

волшебные слова типа Catalyst и Moose оставьте при себе. в реалиях сегодняшнего дня у них нет достаточного уровня производительности: http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/ . если охота более свежих тестов, то в компании, где я сейчас работаю, используется Catalyst и при потреблении памяти в 500 мегабайт он умеет обслуживать не более 10 простых запросов в секунду. Moose же работает в 10 раз медленнее моих самописных accessors, и это в самом простом случае, когда они не типизированы. простите, но это лажа.