function getCookie(name) {
    var start = document.cookie.indexOf(name + "=");
    var len = start + name.length + 1;
    if ((!start) && (name != document.cookie.substring(0, name.length))) {
        return null;
    }
    if (start == -1) return null;
    var end = document.cookie.indexOf(';', len);
    if (end == -1) end = document.cookie.length;
    return unescape(document.cookie.substring(len, end ));
}

С тех пор она обошла весь интернет и сотню рейтингов типа «10 самых обосраться лучших JavaScript-функций за все времена».

С тех пор все подряд либо тянут её себе, либо, как обычно, переписывают на свою «ещё более лучшую, ведь я программист», но везде впихивают этот грёбаный indexOf().
Чем он вам понравился?
Даже Дэвид Флэнаган в своём «подробном руководстве» не удержался.

indexOf(name + "=") – мы здесь не переменную «name» ищем, мы ищем переменную, заканчивающуюся на «name».
Что следующий код нам вернёт?

setCookie("sex", "yes");
setCookie("x", "no");
 
console.log(getCookie("x"));

Правильно:

sex=yes; x=no;

Ну и escape/unescape совершенно для других целей нужны.

А посему:

function getAllCookie() {
    var parts  = document.cookie.split(";"),
        cookie = {},
        part,
        name,
        value,
        i,
        len = parts.length;
    for (i = 0; i < len; i += 1) {
        part  = parts[i].split("=");
        name  = part[0].replace(/^\s+/, "").replace(/\s+$/, "");
        value = (part[1] || "").replace(/^\s+/, "").replace(/\s+$/, "");
        cookie[name] = decodeURIComponent(value);
    }
    return cookie;
}

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

Ну и, конечно, для этого у нас есть наша любимая утилита mysqldump.

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

Ну ладно, просто воспользуемся опцией --ignore-table-data, которая, конечно, где-то в обильном списке опций должна быть.
Опа, а нет, оказывается, ничего подобного.
Только заявка на неё и благодарность за заявку.

Какие же другие варианты у нас есть?

--ignore-table: просто игнорировать таблицы. Не катит, структура нам нужна, в них же всё равно что-то писаться будет.

--where="true limit 100": выбрать только сотню записей. Плохо, другие таблицы нам нужны полными.

Придётся сделать в два захода:

1. Сохранить для таблиц с логами только структуру (--no-data).

2. Сделать дамп всех остальных таблиц.

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

#!/bin/sh
 
DB_NAME="dbname"
DB_USER="username"
DB_PASS="qwerty"
 
OUTPUT_FILE="$DB_NAME-$(date +%Y-%m-%d).sql.tar.gz"
 
TMP_SQL_FILE="$DB_NAME.sql"
 
tables_cmd=""
ignore_cmd=""
 
for table in "log_table_1" "log_table_2" "log_table_3"
do
    tables_cmd="$tables_cmd $table"
    ignore_cmd="$ignore_cmd --ignore-table=$DB_NAME.$table"
done
 
echo "Dump to $TMP_SQL_FILE"
 
mysqldump \
    -u$DB_USER \
    -p$DB_PASS \
    --databases $DB_NAME \
    --no-create-db \
    --add-drop-table \
    $ignore_cmd \
    > $TMP_SQL_FILE;
 
echo "Append big tables structures to $TMP_SQL_FILE"
 
mysqldump \
    -u$DB_USER \
    -p$DB_PASS \
    --databases $DB_NAME \
    --no-create-db \
    --add-drop-table \
    --tables $tables_cmd \
    --no-data \
    >> $TMP_SQL_FILE;
 
echo "Archiving to $OUTPUT_FILE"
tar -czf $OUTPUT_FILE $TMP_SQL_FILE
 
echo "Remove $TMP_SQL_FILE"
rm $TMP_SQL_FILE

Мои познания в баше не позволили мне вынести список таблиц в отдельную переменную, но и так работает.

Там мои мыльца, жежешечки, твиттерочки и гуглоплюсики.

Френдите, фоловьте, плюсуйте и следуйте за мной на твиттер, БЛЕАДЬ!

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

Ну и так, как нужно показать что-то материальное: встречайте, альфа-версия системы бронирования гостиниц Hotel-inn.
В ролях: я, дизайнер Асанов, программист Марио и другие.
Сначала я хотел показать её тогда, когда мы наконец её закончим. Потом, когда её закончат уже другие люди. А теперь приходится показывать, пока эти люди ещё не успели всё убить.

А теперь мы сняли офис, чтобы опять хуячить без обеда и выходных, над хрен знает чем.

Офис в советском здании. В советском здании советские флаги, советские лестницы и советский похуизм абсолютно ко всему.

В грязных окнах: подсобки, люди какие-то за компами и золотые купола.

Вобщем всё опять заебись.

Мы хотим себе веб-программиста.

Веб-программист должен:

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

Веб-программист должен знать:

• PHP5 (желательно 5.3 с неймспейсами и всем остальным)
• JavaScript (работать с jQuery и иметь представление о том, как она сама работает)
• MySQL
• HTML и CSS на уровне «внедрить и подправить». Верстать макеты заставлять не будем.
• Unix, хотя бы на уровне пользователя.
• ООП, MVC и т.д. и т.п.

Веб-программист получит от нас:

• Рабочее место на 40 часов в неделю
• от 35 000 рублей в месяц в начале
• Ещё больше рублей в месяц в зависимости от успехов
• Молодой разнополый коллектив, офис в центре, дартс и печенюшки
• Возможность развиваться в профессиональном плане

Контакты: oleg.grigoriev@insaito.ru.

server {
 
    listen {{ listen }};
    server_name {{ server_name }};
    root {{ root }};
 
    {{ IF htpasswd }}
    # если надо закрыть от посторонних глаз - закрываем
    auth_basic "Password, please!";
    auth_basic_user_file {{ htpasswd }};
    {{ END }}
 
    # К картинкам и стилям доступ обычный
    location ~* ^/(i|css|js)/ {
        expires 7d;
    }
 
    # К robots.txt также
    location = /robots.txt {
    }
 
    # Всё остальное перехватываем на файл index.php
    location / {
        fastcgi_pass   {{ fastcgi_pass }};
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root/index.php;
        fastcgi_read_timeout 600;
    }
}
# Upload-поддомен
server {
    listen {{ listen_upload }};
    server_name {{ server_name_upload }};
    root {{ root_upload }};
 
    location / {
    }
}

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

Параметры

Теперь вспомним, что мы говорили про платформы. У нас получается 7 конечных платформ (4 у разработчиков + local + test + рабочий сайт). Наследуются они от базовой конфигурации. Раздел этой базовой конфигурации, отвечающей за сервер, сейчас и набросаем (всё что NULL – требует переопределения для каждой платформы):

return array(
 
    'listen'      => 80,   // обычно у всех будет 80-й порт
    'server_name' => null,
    'root'        => null,
 
    'htpasswd'    => false, // у большинства htpasswd не нужен
 
    'fastcgi_pass' => 'php-fpm', // у большинства PHP-FPM, но может быть, например, SPAWN-FCGI
 
    'listen_upload'      => 80,
    'server_name_upload' => null,
    'root_upload'        => null,
);

А теперь определяем настройки конкретной платформы (например, для go.example.local):

return array(
    'server_name' => 'go.example.local',
    'root'        => '/home/go/go.example.local/www',
 
    'server_name_upload' => 'img.go.example.local',
    'root_upload'        => '/home/go/go.example.local/img',
);

Для test.example.ru прописываем путь до htpasswd.

Генерация config-файла

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

Остаётся запустить этот скриптик в нужный момент, скопировать результирующий файл в каталог с конфигами nginx’а и перезапустить сервер. Можно повесить это всё на хук в системе контроля версий (не говорите только, что при таком количестве народа её нет).

Что и файл каждый раз копировать лениво? Автоматически скопировать в каталог nginx’а не выйдет – прав скорее всего нет. Поставить права на запись – некошерно как-то, да и всё своё лучше носить с собой.

Поэтому создаём у себя каталог, например, local, игнорируем в системе контроля версий и все подобные генерируемые файлы храним там. В nginx’е же делаем inclide всех подобных файлов или делаем на них символические ссылки.

Мы избавились от лишней ручной работы. Мы молодцы.

Промежуточные платформы

Вспомним теперь про промежуточные платформы.

У нас два ярко выраженных типа платформ:

1. Dev: разработчики и example.local. Для пущего объединения, предположим что все они работают на одном сервере, а разработчики вносят изменения, подключившись через samb’у.
2. Prod: это, конечно, рабочий сайт. А ещё – test.example.ru – он лежит на том же сервере, должен работать в том же окружении и с теми же настройками, чтобы быть максимально приближенном к конечному результату.

Возьмём и сделаем эти две промежуточные платформы.

Зачем дизайнеру и верстальщику отдельные img-поддомены? Зачем им заполнять их тестовыми данными, а в случае изменения формата переконверчивать их. Им только вывод настраивать надо. Сделаем им один и тот же поддомен вместе с example.local, и только у разработчиков переопределим его.

return array(
    'server_name_upload' => 'img.go.example.local',
    'root_upload'        => '/home/go/go.example.local/img',
);

fastcgi_pass также на всём сервере будет один.

Шаблоны параметров

Заметим ещё несколько закономерностей: имя поддомена обычно имеет вид «img. + хост», порт поддомена обычно тот же, что и у основного хоста. Хосты разработчиков располагаются на поддоменах одного домена и пути к ним обычно имеют один формат. Мы избавились от множества рутины, но по прежнему копипастим. Возьмём и впихнём Blitz ещё и в параметры:

/* Базовая конфигурация */
return array(
 
    'base_server_name'   => null,
    'prefix_server_name' => null,
    'www_home'           => null,    
    'prefix_upload'      => 'img.',
 
    'listen'       => 80,
    'server_name'  => '{{ prefix_server_name }}{{ base_server_name }}',
    'project_home' => '{{ www_home }}/{{ server_name }}',
    'root'         => '{{ project_home }}/www',
 
    'htpasswd'     => false,    
    'fastcgi_pass' => 'php-fpm',
 
    'listen_upload'      => '{{ listen }}',
    'server_name_upload' => '{{ prefix_upload }}{{ server_name }}',
    'root_upload'        => '{{ project_home }}/img',
);

Теперь конфигурация DEV-платформ:

return array(
    'base_server_name' => 'example.local',
);

И конфигурация платформы разработчика go:

return array(
    'prefix_server_name' => 'go.',
    'www_home'           => '/home/go',    
);

И после слияния конфигов плучается:

array(
    'base_server_name'   => 'example.local',
    'prefix_server_name' => 'go.',
    'www_home'           => '/home/go/',    
    'prefix_upload'      => 'img.',
 
    'listen'       => 80,
    'server_name'  => '{{ prefix_server_name }}{{ base_server_name }}',
    'project_home' => '{{ www_home }}/{{ server_name }}',
    'root'         => '{{ project_home }}/www',
 
    'htpasswd'     => false,    
    'fastcgi_pass' => 'php-fpm',
 
    'listen_upload'      => '{{ listen }}',
    'server_name_upload' => '{{ prefix_upload }}{{ server_name }}',
    'root_upload'        => '{{ project_home }}/img',
);

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

array(
    'base_server_name'   => 'example.local',
    'prefix_server_name' => 'go.',
    'www_home'           => '/home/go/',
    'prefix_upload'      => 'img.',
 
    'listen'       => 80,
    'server_name'  => 'go.example.local', // {{ prefix_server_name }}{{ base_server_name }}
    'project_home' => '/home/go/go.example.local', // {{ www_home }}/{{ server_name }}
    'root'         => '/home/go/go.example.local/www'. // {{ project_home }}/www
 
    'htpasswd'     => false,    
    'fastcgi_pass' => 'php-fpm',
 
    'listen_upload'      => 80, // {{ listen }}
    'server_name_upload' => 'img.go.example.local', // {{ prefix_upload }}{{ server_name }}
    'root_upload'        => '/home/go/go.example.local/img // {{ project_home }}/img
);

Ну и сам итоговый конфиг:

server {
 
    listen 80;
    server_name go.example.local;
    root /home/go/go.example.local/www;
 
    # К картинкам и стилям доступ обычный
    location ~* ^/(i|css|js)/ {
        expires 7d;
    }
 
    # К robots.txt также
    location = /robots.txt {
    }
 
    # Всё остальное перехватываем на файл index.php
    location / {
        fastcgi_pass   php-fpm;
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root/index.php;
        fastcgi_read_timeout 600;
    }
}
# Upload-поддомен
server {
    listen 80;
    server_name img.go.example.local;
    root /home/go/go.example.local/img;
 
    location / {
    }
}

Другие сервисы

Какие там у нас ещё используются сервисы, требующие файла конфигурации? Sphinx? Ещё какие-то? Так тоже самое с ними.

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

Какие же прелести нас ожидают:

1. Traits: сколько бы задроты «чистого ООП» не гневались, а вещь в умелых и умеренных руках вполне себе полезная. Реализация опять может вызывать вопросы, но всё же лучше, чем ничего.

2. Array dereferencing: всего пяток лет обещаний и вот оно. Вот так вот уже было можно: func()->method(), вот так тоже: $A['var'], и даже так: $A['var'](). Теперь можно так: func()['var]. Ещё пара нововведений и пых обгонит питон по языковым плюшкам.

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

function get($id) {
    // Дикий запрос в базу
}
 
echo 'Имя: '.get(1)['name'];
echo 'Фамилия: '.get(1)['surname'];
echo 'Вся фигня: '.get(1)['fignya'];

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

3. Поддержка DTrace: несомненно отличнейшая вещь, которая сделает нашу жизнь намного лучше.
А может и не сделает. Я, если честно, вообще не знаю, что это такое.

Но возможность писать вместе с PHP на языке D, который совсем не тот язык D, а совсем другой язык D, конечно доставляет.

4. Чистка мусора: register_globals, allow_call_time_pass_reference, register_long_arrays, session_is_regisitered(), session_registered(), session_unregister().

Давно пора, но единственно печалит удаление allow_call_time_pass_reference. Это, когда разрешается по старинке решать в момент вызова как передавать аргумент в функцию: по ссылке или по значению. Без включения этой настройки тоже разрешается, но интерпретатор начинает бурчать себе под нос про DEPRECATED.

Мне оно не нужно, но иногда приходится в чём то старом копаться. Что характерно, все остальные хреновены (register_globals, long_arrays) давно не встречаются. И в случае чего легко эмулируются. А time pass reference вылезает зачастую и так просто от него не избавишься.

Так, а теперь нам нужен сисадмин.

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

Требования

1. Unix, nginx, apache, php, mysql и всё сопутствующее с административной точки зрения
2. DNS, DHCP и т.д. и т.п.
3. Немного Windows
4. PHP на уровне, чтобы хотя бы знать где поменять параметры подключения к базе при переносе
5. …
6. Ну вы поняли…

Примеры задач на начальном этапе

1. Перенести сайт с виртуального хостинга к нам на сервер.
2. Перенести ещё 30 сайтов с виртуального хостинга к нам на сервер.
3. Сбегать за стремянкой и проверить почему не пингуется роутер спрятанный в потолочном перекрытии.
4. Разобраться почему вдруг отвалился сайт.
5. Ругаться с техподдержкой различных хостингов по телефону.
6. Перетащить провода в офисе так, чтобы не мешались под ногами.
7. Помочь девушке-менеджеру у которой завис комп.
8. Сбегать в праздник за пивасом, если больше некому.
9. Если что-то не получается, не бояться сказать об этом чётко, вместо того чтобы сидеть и тупить.

Карьерный рост

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

С нас

1. Двадцать тысяч рублей в месяц в начале.
2. Рабочее место на 40 часов в неделю, впрочем больше находиться на нём запрещать не будем.
3. Балкон, выходящий на Таврический сад.
4. Чай, кофе, сырные палочки, пицца.
5. Молодой, разнополый коллектив.
6. Дартс и другие безделушки для тех, кто сделал все дела на сегодня.
7. Люди, готовые научить тому, что знают, если есть желание учиться.

Контакты

go@blgo.ru