Новые книги

«Как пасти котов» – это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды разработчиков. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись. А может быть, вы – опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда, опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса, она поможет вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», – а значит, моя книга окажется для вас небесполезной.
«Яндекс» — это, конечно, компания мечты. По всем параметрам. В пятерке поисковиков мировой Сети, в тридцатке самых инновационных компаний мира, и одно из самых желанных мест для работы в России. Бизнес, возникший из головы, интеллекта, знаний, упорного труда, способности к риску и удачи — возникший, несмотря на давление со стороны инвесторов, власти и конкурентов.

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

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

Секретов больше нет.

Email Addresses

Адреса Email

Для электронной почты адрес состоит из, по крайней мере, имени машины, обрабатывающей почту определенного человека, и идентификатора пользователя, распознаваемого этой системой. Это может быть имя входа в систему получателя, но это не обязательно. Есть и другие почтовые схемы адресации. Например, в X.400 используется более общий набор "атрибутов", которые используются, чтобы найти машину получателя в каталоге сети X.500.

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

RFC-822

Абоненты Internet твердо придерживаются стандарта RFC-822, который требует записи [email protected], где host.domain задает полное доменное имя машины назначения. В середине знак @. Поскольку эта запись не включает маршрут до машины адресата, но дает взамен уникальное hostname (имя машины), она называется абсолютным адресом.

Вы увидете, что в Internet использование RFC-822 распространяется не только на почту, а также проникает в другие услуги, например новости. Мы обсудим как RFC-822 используется для новостей в главе 20.

Форматы почтовых адресов

В оригинале среды UUCP распространенная форма была path!host!user (путь!машина назначения! пользователь), где path описывал последовательность машин для достижения машины адресата (host). Эта конструкция называется записью bang path, потому что метка восклицания называется "bang". Сегодня много uucp-подобных сетей приняли стандарт RFC-822 и понимают этот тип адреса.

Другие сети имеют различные способы адресации. Decnet-сети, например, используют два двоеточия как разделитель адресов, производя адрес так: host::user. Стандарт X.400 использует совсем другую схему, описывая получателя (без связи с машиной!) набором пар свойств, например, страна и организация.

В сети FidoNet каждый пользователь идентифицирован кодом, подобным 2:320/204.9, состоящим из четырех чисел, обозначающих: зону (2 для Европы), сеть (320 для Парижа), узел и указатель (машину индивидуального пользователя). Fidonet-адреса могут быть отображены на RFC-822; вышеупомянутое написали бы как [email protected].

Два формата почтовых адресов

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

Основная проблема: смшивание UUCP стиля bang-path и формата RFC-822. Эти два типа адресации соединить не так-то просто. Допустим, есть адрес domainA!user@domainB. Неизвестно, что важнее: знак @ или путь. Другими словами: мы должны послать сообщение на domainB, который отправляет его на domainA!user, или письмо надо послать domainA, который отошлет его user@domainB?

Адреса, в которых операторы адресации смешаны, называются гибридными (hybrid addresses). В только что приведенном примере считается, что знак @ важнее пути. Запись domainA!user@domainB означает послать сообщение сначала на domainB.

Имеется способ определить маршруты RFC822-совместимыми способами: <@domainA,@domainB:user@domainC > обозначает адрес пользователя user в домене domainC, где domainC должен быть достигнут через domainA и domainB (именно в этом порядке!). Этот тип адресов часто называется адресом, направленным источником (source routed). Положиться на это поведение не очень хорошая идея, поскольку изменения в RFC, описывающие маршрутизацию почты, рекомендуют, чтобы маршрутизация источника в адресе почты игнорировалась, а взамен должна быть сделана попытка доставить письмо непосредственно удаленному адресату.

Когда имеется оператор адреса % (например, user%domainB@domainA), письмо будет сначала послано domainA, который превратит знак процента в знак @. Теперь адрес user@domainB, и почтовая программа передаст Ваше сообщение на domainB, который перешлет его пользователю user. Этот тип адреса иногда упоминается как "Ye Olde ARPAnet Kludge" и его использование не приветствуется. Однако, много средств транспортировки почты генерируют этот тип адреса.

Но лучше всего использовать адрес именно в виде абсолютного адреса RFC-822 [email protected], если это позволяет Ваша система.