Довольно долго искал, чем же можно нормально писать вебинары.

В итоге остановился на vokoscreen.

Из достоинств:

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

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

Даже если запись изначально прошла удачно, то итоговый файл все равно мало пригоден для аплоада на ютуб или куда-нибдь еще (для разрешения 1920х1080 и 60 минутах записи объем итогового файла перевалит далеко за 2 гига).

Поэтому можно воспользоваться кодемо ffmpeg. Для меня подошли следующие опции.

ffmpeg -i input.mkv -vcodec libx264 -strict -2 -crf 20 -threads 7 -r 25 output.mp4  

Где:

• -i input.mkv - исходный файл
• -vcodec libx264 - кодек видео x264
• -strict -2 - этот набор опций включает поддержку эекспериментального энкодера aac
• -crf 20 - опция энкодера, которая задает степень сжатия (в мануале - это квантование). от 0 до 51. 0 - лучшее качество картинки, а 51 - наихудшее.
• -threads 7 - количество потоков (равно количество реально-виртуальных ядер минус один. в таком случае можно за компьютером еще что-то делать)
• -r 25 - кадры в секунду для выходного видео
• output.mp4 - куда пишем

Подробный мануал по кодирования x264.

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

// глобальная переменная, которую мы попытаемся дальше получить  
var bar = 42;

// Мозг предполагает, что до объявления bar в теле функциии глобальный bar будет доступен  
function simple_define() {  
 alert(bar);  
 var bar = 10;  
 alert(bar);  
}

// Но это не так. Функция выше на самом деле выглядит вот так  
function real_define() {  
 var bar;  
 alert(bar);  
 bar = 10;  
 alert(bar);  
}

// А что же с условиями? Разве они не создают локальные области видимости?  
function define_inside_if() {  
 if (true) {  
 var bar = -10;  
 }

alert(bar);  
}

// Ну а циклы?  
function define_inside_while() {  
 do {  
 var bar = 10;  
 } while (false);  
 alert(bar);  
}

// И переменные из for?  
function define_inside_for() {  
 for (var bar = 0; bar < 10; bar++);  
 alert(bar);  
}

/*  
 * Да. Это особенность js - компилятор собирает все объявления переменных текущей области видимости  
 * и выделяет под них все требуемые ресурсы сразу при входе в функцию.  
 */

Сколько можно? :) Ядер все больше и больше, а

$ tar -cjf /mnt/_backup/`date '+%Y-%m-%d_%H-%M-%S'`.tbz2 /home

как работал в один поток, так и работает.

Есть два многопоточных решения:

• pbzip2 - параллельный bzip
• pigz - параллельный gzip

$ tar -c /home | pbzip2 -vc -9 -p7 /mnt/_backup/`date '+%Y-%m-%d_%H-%M-%S'`.tbz2

Опцией -p# можно управлять количеством ядер, которые будет использовать архиватор. Нормально - это N-1.

Аналогично и для gzip

$ tar -c /home | pigz -vc -9 -p7 /mnt/_backup/`date '+%Y-%m-%d_%H-%M-%S'`.tbz2

С удивлением открыл для себя, что - в bash по дефолту означает stdout. И

$ tar -cf - file

будет использовать в качестве файла stdout. :)

Столкнулся сегодня с этой ошибкой в консоли фокса.

Причина проста: повреждение хранилища localStorage. Подробнее можно посмотреть официальную документацию.

Решается удалением файла ``` webappsstore.sqlite

В коде же это исключение так же следует обрабатывать корректно (чтобы не пугать пользователя).

```javascript
try {  
 setLocalStorageItem(key, value);  
} catch(e) {  
 if(e.name == "NS_ERROR_FILE_CORRUPTED") {  
 showMessageSomehow("Sorry, it looks like your browser storage has been corrupted. Please clear your storage by going to Tools -> Clear Recent History -> Cookies and set time range to 'Everything'. This will remove the corrupted browser storage across all sites.");  
 }  
}

Странно, но в моем случае чистка всего-всего таки не помогла. Помогло ручное удаление файла.

Virtual Environment - полезный инструмент, который позволет держать различные конфигурации зависимостей проектов в разных директориях. Например он решает проблему когда одному приложению требуется версия 1.0 пакета X, а другому - 2.0.

vitrualenv

Главным инструментов будет virtualenv.

$ sudo yum install python-virtualenv

Использование

Создадим окружение

$ cd project_dir  
$ virtualenv proj_env

Этими командами мы создадим папку proj_env, которая будет содержать наше новое окружение. В этой папке будет набор скриптов и копия интерпретатора python, который будет использоваться в окружении (окружение использует свой интерпретатор, а не общесистемный).

При создании окружения можно указать, какая версия python нам нужна.

Возможно, что в системе параллельно стоит как python2, так и python3. Выбирать версию при создании окружения мы можем ключем -p. Если ключ не указан, то будет выбрана версия /usr/bin/python.

$ virtualenv -p /usr/bin/python3.4 proj_env

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

$ source proj_env/bin/activate

Теперь мы внутри окружения.

Определеить это можно по изменившемуся приглашению:

(proj_env)тут_старое_приглашение_из_$PS1

Все. Мы внутри окружения. Можно ставить зависимости для нашего приложения.

$ pip install flask flask-bootsrap rq rq-scheduler pymysql

Выйти из окружения можно при помощи

$ deactivate

Теперь мы попали обратно в систему с дефолтными интерпретаторами.

Сохранение информации о зависимостях

Опция –no-site-packages отключает использование глобально-установленных пакетов, что может быть полезно (сейчас это дефолтное поведение virtualenv).

Хорошей идей будет сохранить информацию об установленных в окружении пакетов.

{code lang=”shell”]$ pip freeze > requirements.txt

После развертывание окружения в новой системе можно поднять все пакеты сразу.

```shell
$ pip install -r requirements.txt

Не забываем добавить папку окружения в .gitignore.

virtualenverapper

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

$ sudo yum install python-virtualenvwrapper

Применение

Добавляем в .bashrc

export WORKON_HOME=~/.envs  
source /usr/bin/virtualenvwrapper.sh

Теперь можно создавать окружения.

$ mkvirtualenv proj_env

Активировать окружения.

$ workon proj_env

Выходить из окружения можно так же как это делалось в кготом virtualenv.

$ deactivate

Удалять окружения.

$ rmvirtualenv proj_env

При этом все папки окружений будет расположены в одном месте: папке, которая задана через $WORKON_HOME.

Дополнительные команды

Есть несколько дополнительных команд

• lsvirtualenv - покажет список созданных окружений
• cdvirtualenv - перейдет непосрественно в папку окружения
• cdsitepackages - переведет в site-packages выбранного окруженияч
• lssitepackages - сделает ls для папки site-packages

Посмотреть полный список команд.

autoenv

Утилита позволяет активировать окружение при входе в папку, и деактивировать при выходе.

$ git clone git://github.com/kennethreitz/autoenv.git ~/.autoenv  
$ echo 'source ~/.autoenv/activate.sh' >> ~/.bashrc