Thursday, February 5, 2015

Повышаем интуицию с Python

Наткнулся в сети на интересную задачку:
Предположим, вы являетесь участником "Поля чудес". Выпал приз, Якубович предлагает выбрать один из трех ящиков, в одном из которых деньги. Предположим, вы выбрали первый ящик. Ведущий открывает один из ящиков, пусть третий — он пустой. Ведущий предлагает передумать и выбрать второй ящик. Измените ли вы свое решение?
Предлагаю поразмыслить над ответом, а потом будет немного кода на Python.

Saturday, May 24, 2014

Раскрашиваем bash prompt

Существует множество вариантов кастомизации приглашения bash for fun and profit. Сегодня поговорим об использовании различных цветов в PS[1234].

Thursday, September 19, 2013

Как отключить ALPS-тачпад в Archlinux

В некоторых моделях ноутбуков (не миновала сия участь и мой Dell Inspiron 7720) в Archlinux тачпад определяется как "PS/2 Generic Mouse". Разумеется, при этом он отказывается конфигуриться (и отключаться) драйвером Synaptic. Хотя вики советует устанавливать некий самопальный модуль с AUR, есть способ проще.

Friday, July 5, 2013

Perl всё

Ура, я наконец-то перешел на Python в качестве основного языка разработки. Довольно долгое время моим основным орудием был Perl, но в последнее время я все чаще стал посматривать на альтернативы (e.g. Python, Ruby, NodeJS). Немного о том, что мне не нравится в Perl, в произвольном порядке.

  • Perl, пожалуй, худший выбор в качестве первого языка программирования. Этот язык упорот настолько, что поюзав его несколько лет переключиться на что-то вменяемое становится сложно. Чего стоит, например, передача аргументов в функцию в виде массива @_, реализация областей видимости переменных, etc.

    Примерно в этом же ключе отзывался Дейкстра по отношению к Basic:
    "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
    Справедливости ради стоит отметить, что комьюнити у перла весьма дружелюбное и открытое.

  • Стремление к сходству с естественным языком (на Perl можно даже писать стихи). Звучит прикольно, но на практике лишь раздувает синтаксис и делает код менее читабельным/поддерживаемым.

  • Мантры TMTOWTDI (There’s More Than One Way To Do It) и DWIM (Do What I Mean). Чем больше существует способов "сделать это", тем сложнее язык в изучении и понимании. Попытка заставить интерпретатор строить догадки также ни к чему хорошему не приводит.

  • Отсутствие вменяемого ООП. А без ООП нынче никуда.

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

  • Очень узкая ниша. На мой взгляд – это относительно небольшие (одноразовые) скрипты, позволяющие быстро выполнить задачу. Причем "быстро" как по времени написания кода, так и его выполнения.

  • Perl – единственный язык, в котором имеется goatse operator =)

На этом унылом фоне всё лучше смотрится Python. Он на порядок читабельней, более строгий и полностью объектно ориентированный. Наконец, его гораздо легче набивать вслепую из-за минимума пунктуации ) И еще, я уже давно собирался на него перейти...

Friday, April 5, 2013

Фиксированные имена сетевых интерфейсов в Archlinux

Как известно, в Linux имена сетевых интерфейсов обычно имеют вид "eth0", "eth1" и назначаются ядром при загрузке системы. Поскольку модули соответствующих драйверов загружаются асинхронно, порядок обнаружения интерфейсов не является постоянным. Поэтому, если в системе имеется несколько сетевых интерфейсов, их имена могут периодически меняться при перезагрузке. Это может доставлять проблемы для приложений, использующих имена интерфейсов (e.g. фаерволы, сетевые мониторы).

Начиная с версии v197 systemd/udev автоматически назначает постоянные фиксированные имена для всех Ethernet, WLAN и WWAN интерфейсов. Для имен используются префиксы en, wl и ww соответственно и автоматически сгенерированные идентификаторы. Пример для ethernet-интерфейса: enp1s0.

При обновлении с более ранних версий systemd в Archlinux эта фича остается отключенной, благодаря наличию файла /etc/udev/rules.d/80-net-name-slot.rules:


$ cat /etc/udev/rules.d/80-net-name-slot.rules
# This file masks persistent renaming rules for network devices. If you
# delete this file, /usr/lib/udev/rules.d/80-net-name-slot.rules may
# rename network devices according to ID_NET_NAME_{ONBOARD,SLOT,PATH}
# properties of your network devices, with priority in that order. See
# the output of 'udevadm test-builtin net_id /sys/class/net/$interface'
# for details on what that new name might be.
#
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames


Чтобы для всех интерфейсов использовалось постоянное сгенерированное имя, достаточно удалить файл /etc/udev/rules.d/80-net-name-slot.rules. Посмотреть, какое имя будет назначено интерфейсу можно командой


udevadm test-builtin net_id /sys/class/net/eth0

Thursday, March 21, 2013

SSH-соединения с использованием промежуточных хостов

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

Предположим нам надо зайти на хост B (недоступный с текущего места) и мы можем зайти на хост A (с которого доступен хост B). В настройках ssh (e.g. ~/.ssh/config) указываем, что соединение с хостом B должно проксироваться через хост A, используя опцию -W:

Host B
HostName myhost
ProxyCommand ssh -q -W %h:%p A


После этого просто используем команду ssh B. Имя myhost должно резолвиться хостом A и указывать на хост B. По аналогии можно добавить произвольное число промежуточных хостов.

Надо заметить, что опция -W появилась в OpenSSH 5.4 (март 2010г). Для более ранних версий можно использовать netcat:

ProxyCommand ssh A nc %h %p


Данная простая настройка делает возможным установку соединения с хостом одной командой, а также открывает доступ к нему приложениям rsync, git, etc., использующим SSH в качестве транспорта.

Saturday, December 22, 2012

OAuth 2.0: введение

В октябре текущего года стандарт OAuth 2.0 наконец-то вышел из статуса "черновика" и превратился в RFC. Все больше сервис-провайдеров начинают поддерживать OAuth в своих API. Что же такое OAuth и зачем он нужен?

Согласно RFC, этот протокол позволяет предоставить третьему лицу (клиенту) ограниченный доступ к какому-либо HTTP-сервису от имени пользователя. При этом клиент использует для авторизации не параметры доступа пользователя (e.g. логин и пароль), а полученный от сервиса токен. Это во многом повышает секьюрность модели аутентификации:


  1. Клиенту не надо хранить параметры доступа пользователя в виде плэйнтекста.

  2. Возможность ограничить полномочия клиента, в т.ч. длительность их предоставления.

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

  4. Компрометирование какого-либо клиента не приводит к утечке параметров доступа пользователя.



Рассмотрим как происходит OAuth-авторизация с использованием авторизационного кода. Именно такая схема используется во многих приложениях для авторизации в Facebook и других сервисах.


  1. Приложение (клиент) перенаправляет пользователя на урл авторизации сервиса. В параметрах запроса содержится идентификатор клиента, запрашиваемые права, случайная последовательность символов и урл, на который следует перенаправить пользователя после того, как он подтвердит (или отменит) авторизацию.

  2. Сервис (он же authorization server, он же resource server) авторизует у себя пользователя и устанавливает, подтверждает ли он предоставление запрошенных прав клиенту.


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


  4. Клиент делает запрос к сервису, содержащий полученный код авторизации, а также параметры доступа клиента.


  5. Сервис проверяет параметры доступа клиента, код авторизации и возвращает access token.

  6. Profit!



В принципе, это самая сложная схема авторизации в OAuth 2.0 в настоящий момент.

Схема с обменом реквизитов пользователя на access token, например, гораздо проще и по сути представляет собой обычную авторизацию, используемую во многих web-приложениях.