Все-таки красные у меня глаза или нет? Кажется не очень. Может так и должно быть? Я внимательно разглядывал себя в зеркало. Нет, всё-таки красные, хоть и не так сильно. Может не стоит уже с утра проверять почту и ходить по всем этим сайтам? Ну напишут там что-то, а я не прочитаю, ну и что такого? Нет, каждый раз просыпаюсь и первым делом туда…

Так начинался фантастический рассказ — антиутопия про один день из жизни программиста в недалёком будущем, написанный мной в 2010 году. Меня просили продолжить, и через какое-то время появились идеи, но всё никак не было времени их реализовать. Однако в связи с последними событиями начинает казаться, что придуманный мной сюжет того гляди может стать реальностью. Поэтому сегодня представляю вам вторую главу. Рисунок был сделан в прошлом году совсем по другому поводу, но он хорошо подошел сюда как иллюстрация.

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

От переводчика. Предлагаю вашему вниманию статью Скотта Янга с одноименного блога. Я решил оставить термин «энерджи-менеджмент» без перевода, поскольку существенной мыслью автора является противопоставление его тайм-менеджменту.
Приятного чтения!

Моё первое знакомство с коллегой-блоггером по имени Phil Gerbyshak состоялось, когда я опубликовал весьма подробный комментарий о том, что воспринимаю энерджи-менеджмент (управление энергией) и тайм-менеджмент (управление временем) как независимые друг от друга вещи, обе из которых следует использовать полноценно. Я также дал понять, что склонен считать подход тайм-менеджмента превосходящим энерджи-менеджмент по части пиковой производительности.

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

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

… или практическое применение мотивации и краудсорсинга

Привет, Хабр! Ежедневно мы обсуждаем сотни актуальных тем, таких как: GTD, управление проектами, мотивация персонала, работу в команде и другие темы менеджмента. Здесь всегда есть у кого спросить и что прочитать: множество статей, гора учебников, литературы и прочего. В конце концов, мужик: «Ты же получаешь зарплату!». Соответственно, совсем другая тема, ставшая очень актуальной в пору развития ИТ — мотивация людей, которые за свою работу ничего не получают, или, как сейчас модно говорить, краудсорсинг. Об этом и поговорим далее…

На Хабре полно разных инструкций, как связать Nginx с php5-fpm, даже я уже такую писал. Но сегодня предлагаю кое-что новенькое, а именно видео-инструкцию покупки и настройки собственного VPS на Linode.

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

Смотреть видео категорически не рекомендуется супер-крутым админам и беременным женщинам!



Под катом подробности организации + план работ с кусками кода, для удобного копипастинга.

Некоторое время назад я занимался поисками датчика давления для одного сайта. Требования были простыми — подключение по USB и минимум паяльника, т.к. опыт использования данного инструмента у меня только в криптоанализе. Оказывается, что в отличие от температуры и влажности, китайцы ещё не освоили этот рынок, и наиболее простой и дешёвый вариант: купить любой барометр, направить на него веб-камеру и анализировать показания.
Несмотря на бредовость данной затеи, она серьёзно рассматривалась, но в конце-концов была отметена по банальной причине — ночью нужна подсветка. Т.е. работать система ночью не будет, а если будет, то потребует дополнительных усилий по настройке.

Из других вариантов, наиболее подходящим была USB Meteo Board от Sparkfun на основе Arduino, или самодельная система на основе того же Arduino или Netduino.

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

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

Часто в скриптах можно встретить что-то вроде foobar|awk '{print $1}' («часто» — это действительно часто).

Такой вызов awk всего лишь вывходит первую (n-ную) колонку из вывода предыдущей команды. Но это явный оверкилл! awk — довольно мощный язык потоковой обработки данных, и применение его как простого field-separator не есть хорошо.

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

В современном линуксе обработка вызова awk куда более сложна, чем вызов cut. В дебиане, например, awk — линк на /etc/alternatives/awk, который ведёт (чаще всего) на gawk. Который почти в 10 раз больше по размеру, чем cut. Разумееся, cut загружаеся быстрее.

cut умеет вырезать не только байты, но и нужные поля (опция -f). Поле — это текст между разделителями. По-умолчанию разделитель пробел/табуляция, но он легко меняется опцией -d.

Второй подход — использовать опцию -o у grep. Эта опция выводит не всю строку, а только совпадающее с критерием поиска grep. Очевидно бесполезно при поиске точной подстроки, но очень полезно при использовании регулярных выражений.

Например,
grep -v "#" /etc/inittab |cut -f 4 -d : -s
выведет список программ, запускающихся init'ом (четвёртое поле, поля разделяются двоеточием).

Или
grep http://\\S\\+ -o /var/log/apache2/error.log
выдаст список URL'ов из файла с ошибками (первый урл в строке).

… и никакого awk.

UPD: В комментариях подсказывают ещё более интересную конструкцию без запуска внешнего файла (команда read реализуеся средствами bash'а):
foobar | (read p1 p2; echo p1)

P.S. Речь не о единичном вызове (тут нет разницы awk, grep или даже python/perl). Речь о множестве вызовов в цикле в скрипте. Все примеры сравнивайте в цикле с сотнями (лучше тысячами) вызовов.