ИТ-цирк уехал, клоуны остались

Недавно в интернетах проскользнуло довольно таки интересная статья о том, что в EPAM собраны все ИТ знания мира большинство современных конференций не несут никакой ценности ее участникам, а все происходящее можно охарактеризовать как «ноль идей, ноль контента и ноль контактов».

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

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

  1. Новичек. На этой стадии, как правило, еще молодой специалист посещает все конференции и встречи ради контента в стиле «Что нового в .net 4.5», «Обзор новых возможностей Drupal v.Next» и т.д. Доволен доставшейся футболке, ручке и фирменной кружке. При этом в 99% участник доволен контентом, организацией и пишет восторженные отзывы о мероприятии.
  2. Участник. На этой стадии развития человек не только ходит на презентации, но и задает какие-то вопросы, общается с докладчиками. Радуется новой футболке, но первоначальных оргазмических чувств не испытует. В большинстве случаев доволен происходящим.
  3. Тусовщик. На этой стадии развития человек ходит не сколько ради контента, сколько ради общения в кулуарах или на афтепати. Как правило, редко пишет отзывы, получает порцию общения, нетворкинга и новых деловых связей.
  4. Организатор. В какой то момент участник или тусовщик может стать организатором мероприятий (хотя далеко не обязательный этап развития). В большинстве случаев после нескольких организованных ивентов начинает более сдержано комментировать других организаторов и, наконец, прекращает верить в то, что продав 300 билетов по $100 можно купить майбах, хотя бы подержанный.
  5. Выступающий. Человек, который сам начинает выступать на мероприятиях, вне своего выступления ведет себя, как правило, как тусовщик.
  6. Гуру. Человек, достигший высшего степеня просветления, мастер, который перестает посещать конференции, т.к., по его мнению, все превратилось в УГ, нет идей и вообще мир остановился в развитии. Позволяет себе критически оценивать работу коллег.

А теперь хочу разобрать несколько популярных мнений о конференциях.

На больших конференциях большинство докладов от Капитана Очевидность

Это действительно так. Происходит это потому, что когда в зале сидит 300-1000 человек, то по закону нормального распределения вы получите лишь 5% аудитории, которая сможет понять узкоспециализированную тему.

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

Зарубежные докладчики крутые, а наши — отстой

Очень популярное заблуждение. У меня была возможность слушать как зарубежных, так и отечественных докладчиков. Могу с уверенностью заявить, что наши докладчики, в среднем, дают больше полезной информации за единицу времени, чем зарубежные. Кроме того, выступающие, в лучшем случае такие же КО (им еще сложноее, т.к. они не только не ориентируются в уровне компетенции аудитории, но часто первый раз слышат о стране, в которой им прийдется выступать), в лучшем — делают мини шоу на сцене, действительно временами превращая все в ИТ-цирк.

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

Единственный зарубежный спикер, который смог «зажечь», рассказывая о технологиях, был Скотт Хасельман на прошедшем DevCon. Но таких ярких талантливых спикеров очень и очень мало.

Организаторы — жадные твари и, вообще, кто так организовывает мероприятия? Вот я бы…

Начнем с объективных причин — что в Москве, что в Киеве, что в Минске очень мало мест, где можно провести ИТ мероприятие на высоком уровне. Как только организаторы не извращаются — проводят и в театрах, и в домах культуры и спорта, и даже… в ночных стрип клубах.

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

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

Вот у них конференции…

Да, хорошие. С бюджетом в несколько миллионов долларов. Организационным комитетом на 50 человек. Со спонсорами в количестве 20-30 штук. С залами на 15 тыс. человек. И да, с ценником, минимум, в 600 евро. Вот мне бы хотелось посмотреть на местную компанию, которая сможет регулярно орправлять по 5-10 человек за свой счет на такие конференции.

Вместо заключения

Напоследок хочу дать несколько советов, как перестать беспокоиться и начать ловить кайф от мероприятий:

  1. При выборе докладов смотрите не на громкие имена работодателей и даже не на название доклада. Смотрите на имена докладчиков, даже если они вам не знакомы (чтобы исправить это, есть Google). Если вы не знаете человека, но он каким-то образом попал в список докладчиков, есть большая вероятность, что он хороший эксперт, но еще не дошел до уровня «звезды». Кстати, есть звездные докладчики, которые в какой-то момент начинают рассказывать об одном и том же, причем искривляя объективную реальность под себя. Такие доклады могут принести даже больше вреда, чем пользы.
  2. Задавайте вопросы докладчикам и экспертам. Желательно в кулуарах или на афтепати. Не важно, что вы их спросите, главное, что вы сможете услышать, как они мыслят. 10 минут в кулуарах принесет вам больше пользы, чем часовое выступление этого же человека на сцене.
  3. Если все докладчики вам знакомы, тусить вы не намерены, а знаний у вас больше, чем у всех посетителей двух задних рядов, поменяйте сферу деятельности. Если вы айтишник, походите на встречи маркетологов, пиарщиков или дизайнеров. Это даст вам новые ощущения и жизненный цикл, по сути, можно будет пройти заново.
  4. Ходите не на те доклады, в тематике которых вы разбираетесь, а на те, в которых вы не профи (исключения конечно же могут быть, если, вам нравится спикер или вы хотите углубиться в изучение своей темы).

Лично у меня есть такие критери успешности мероприятия:

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

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

Интересных вам конференций и спасибо за внимание!

ссылка на оригинал статьи http://habrahabr.ru/company/devrainsolutions/blog/174855/

DAC и HeadAMP и не только: HA INFO DA1

Заказал на ebay с месяц назад себе простой усилитель для наушников HA INFO U2 PLUS, а вместо него пришла модель старше и дороже.


HA INFO DA1

  • Входы: USB (32kHz — 96kHz / 16 — 24 bit); Coaxial, Optical (44.1kHz — 192kHz / 16 — 24 bit); Analog (Stereo)
  • Выходы: Coaxial, Optical (44.1kHz — 192kHz / 16 — 24 bit); Headphones (Stereo), Analog (Stereo)
  • Динамический диапазон: > 110db
  • SNR: > 100dB
  • USB Reciever: TENOR TE7022L
  • DAC: WM8805+WM8740
  • Усилитель для наушников Class A
  • OpAMP: OP275
  • 2V RMS в Line Out и 5V RMS в наушники


В комплекте:

  • Сам HA INFO DA1
  • USB-Кабель
  • AC-DC адаптер 110-220V с переходником-монстром под евровилку
  • Переходник 6.3mm → 3.5mm
  • Краткая инструкция на китайском

На передней панели есть тумблер включения/выключения и выбор между коаксиальным и оптическими источниками и приемниками звука.

Эта штука звучит прилично, нагревается сильно и весит относительно много (~0.7 кг), Class A, как-никак.
Усилителя хватит для любых наушников. Он способен выдавать 700mW при 32Ом, 200mW при 120Ом и 100mW при 250Ом, что более чем достаточно. На полной громкости мои Sennheiser HD 518 можно использовать как динамики.

Сзади у нас DC IN, USB IN, Оптические, коаксиальные и аналоговые разъемы.

Стоит это устройство, судя по ebay, около 4000 рублей. Отличный выбор для домашнего использования, ведь его можно использовать не только как звуковую карту, но и как ресивер для S/PDIF.

ссылка на оригинал статьи http://habrahabr.ru/post/174851/

«Жемчужный» доступ к 1С: Предприятию 8.2

Думаю, всем вам известен такой программный продукт, как 1С: Предприятие 8.2. И, наверное, многим из вас известен тот факт, что к 1С: Предприятию можно подключиться, используя OLE/COM-соединение. А многие ли из вас знают, что с помощью OLE/COM-соединения можно не только выполнять программный код 1С, но и “управлять” сервером 1С: Предпрития? К примеру, можно подключиться к Агенту кластера серверов 1С: Предприятия, получить список открытых клиентских сессий, прочитать информацию о выданных им лицензиях… К тому же, наличие варианта подключения посредством OLE/COM-соединения расширяет в арсенале программиста добавляет возможность выбора языка программирования, отличного от встроенного языка 1С: Предприятия. Можно выбрать любой язык, который способен работать с OLE/COM-компонентами: будь то VB.Net, C#.Net, или Java, или даже… Perl. Да, вы не ослышались. Именно Perl.

Итак…

Задача.

Необходимо реализовать автоматический рестарт службы Агент сервера 1С: Предприятия 8.2 с помощью планировщика задач Windows. Но перед рестартом необходимо проверить, не работает ли кто-нибудь в базе Base, расположенной на сервере 1С: Предприятия. Если кто-нибудь работает, то перезапуск службы недопустим.

Решение.

У вас может закрасться вопрос, мол, зачем нужно периодически перезапускать службу Агента сервера? Дело в том, что в версии 1С: Предприятие 8.2 х64 есть одна “маленькая” ошибка. Она возникает при динамическом обновлении информационной базы и приводит БД к невозможности обновления и работы в ней. Разработчики официально (в личной переписке с ними) заявили, что данная ошибка не планируется к исправлению в версии 8.2. Придется ждать и “выживать” до официального релиза 8.3. Я-то знаю способ исправления этой ошибки (если надо — расскажу в комментариях или апдейте статьи). Но, как заверяют разработчики, данный способ обхода может разрушить базу данных совсем. У меня за год использования этого способа обхода база не разрушилась. Но не об этом статья.

Итак. Задача поставлена. Основной проблемой для меня стало условие проверки существующих подключений к определенной БД. Для реализации поставленной задачи я решил не использовать встроенный язык 1С: Предприятия, ни один из .Net-языков, а также Java (only console, only true linux-way).

В синтаксис-помощнике 1С: Предприятия был найден метод проверки наличия подключений к БД, но он предполагал использование OLE/COM-соединения к Агенту сервера 1С: Предприятия. Что ж… Приступим.

Выдержка из синтаксис-помощника

Соединение с агентом сервера (IServerAgentConnection)
GetInfoBaseConnections (GetInfoBaseConnections)
Синтаксис:

GetInfoBaseConnections(<Кластер>, <ИнформационнаяБаза>)

Параметры:

<Кластер> (обязательный)
Тип: Кластер серверов. Кластер серверов, для которого должен быть получен массив описаний соединений.

<ИнформационнаяБаза> (обязательный)
Тип: Описание информационной базы. Информационная база, для которой должен быть получен массив описаний соединений.

Возвращаемое значение:
Тип: COMSafeArray. Массив описаний соединений кластера. Каждое описание соединения представлено объектом с интерфейсом Описание соединения.

Описание:
Получает массив описаний соединений информационной базы.

Доступность:
Интеграция.

Для работы с OLE/COM-объектами средствами Perl нам понадобиться задействовать модуль Win32::OLE. В используемой мной сборке StrawberryPerl данный модуль уже был предустановлен. Но даже если это не так, можно установить его через CPAN:

C:\Perl\perl\bin\cpan Win32::OLE 

Чтобы получить список соединений базы данных 1С, нам нужно:

  • Создать COM-подключение к объекту V82.COMConnector;
  • Подключиться к агенту кластера серверов 1С: Предприятия;
  • Получить объект кластера 1С;
  • Авторизоваться на кластере;
  • Получить список баз 1С на этом кластере;
  • Найти необходимую нам базу;
  • Получить список активных соединений к этой базе данных.

Вот код с комментариями, который получает список активных соединений клиентов с базой данных 1С: Предприятия, расположенной на сервере 1С: Предприятия.

use strict; use warnings;  use Win32::OLE;  use Data::Dumper;  sub getConnectionsCount {     # имя сервера (с портом) и имя базы будем получать из параметров метода     my ($server, $dbname) = @_;     # создаем COM-соединение     my $ole1c = Win32::OLE->new("V82.COMConnector") or die "Could not create OLE-connector!\n";     # создаем объект Агента сервера 1С:Предприятия     my $_agent = $ole1c->ConnectAgent($server) or die "Could not connect to server!\n" . cnv(Dumper $ole1c->ErrorDescription());     # получаем объект кластера (у меня один кластер)     my $_cluster = $_agent->GetClusters()->[0] or die "Could not get cluster 0 from array\n";     # авторизуемся на кластере серверов.      # Авторизоваться надо с помощь логина и пароля Администратора кластера серверов,     # которого можно задать в утилите Администрирования сервера 1С:Предприятия.     # не путайте этого администратора с администратором базы данных, что заводится     # через конфигуратор в пользователях.     # У меня нет администраторов, оставляю пустыми параметры логина и пароля.     $_agent->Authenticate($_cluster, "", "");     # получаем список баз данных, расположенных в данном кластере     my $_basesinfo = $_agent->GetInfoBases($_cluster);     # найдем нашу базу данных     my @_bases = grep { defined $_->{Name} && $_->{Name} =~ m/^$dbname$/ } @$_basesinfo;     # она точно будет одна     my $_base = $_bases[0];     # заведем счетчик подключений     my $connCounter = 0;     # получим все активные подключения или сразу вернем 0     my $_baseconns = $_agent->GetInfoBaseConnections($_cluster, $_base) or return 0;     # “отсечем” все соединения по типу приложения, на которые можно не обращать внимание.     # если эти подключения есть, то можно смело перегружать службу      # Агента сервера 1С:Предприятия     foreach (@$_baseconns) {         # нам не важны планировщики задач и подключения через консоль кластера         if ($_->{Application} !~ m/JobScheduler/ && $_->{Application} !~ m/SrvrConsole/) {             $connCounter++;         }     }      return $connCounter; }  # вызов очень простоой. # только порт нужно указывать тот, который слушает агент кластера серверов 1С:Предприятия print “There are “ . getConnectionsCount(“localhost:1540”, “Base”) . “ active connections\n”; 

Перезапустить службу Агента можно с помощью команд “net start” и “net stop”:

net stop <ИмяСлужбы> net start <ИмяСлужбы> 

Полный код, выполняющий поставленную задачу я расположил на Bitbucket-е.

ссылка на оригинал статьи http://habrahabr.ru/post/174857/

Три рецепта питона

imageВ качестве продолжения прошлогодней статьи из серии «когда не надо, но хочется попробовать» хочу рассмотреть пример использования property(), модуля traceback и декораторов.

Предположим, что у нас есть очень нам нужный модуль, документация к которому представляет собой C++ исходники python bindings самого модуля и C++ исходники оригинального пакета. Ну и, конечно, dir(obj) с help(obj.method) немного упрощают жизнь. Но хочется большего: вменяемого если не автокомплита, то хотя бы py-модуля с перечнем методов каждого класса (имеющих описание, список и типы параметров и результата; a la pydoc). А вот бы еще получить словарь со всеми именами и значениями…

В качестве варианта реализации можно было бы просто оформить серию прокси-классов

from ourextmod import extClass class Class(object):     @accepts(extClass)     def __init__(self, extobj):         self._obj =  extobj      @returns(str)     def version(self):         return self._obj.version      @returns(str)     def name(self):         return self._obj.name      @accepts(str)     @name.setter     def name(self, value):         self._obj.name = value      @returns(dict)     def smth(self):         return self._obj.strange_original_method_name_for_smth_action()      @returns(str)     def full_name(self):         return self._obj.full_name()      @accepts(str)     @full_name.setter     def full_name(self, value):         self._obj.set_full_name(value)      def dump(self):         return {             'version'   : self.version,             'name'      : self.name,             'smth'      : self.smth,             'full_name' : self.full_name,         }         # можно через getattr; от дублирования кода это не избавляет 

В общем, на пятом десятке таких методов даже самый спокойный разработчик может начать нервничать…

Применяем property()

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

property

Функция создает property-атрибут в классе, принимая на вход реализацию getter, setter, deleter и pydoc-описание (его опускаем для простоты):
property([fget[, fset[, fdel[, doc]]]])

Для имеющих getter и setter получаем:

    def prop(obj, name):         return property(lambda self: getattr(getattr(self, obj), name),                         lambda self, value: setattr(getattr(self, obj), name, value),                         None         ) 

С такой функцией работу с name можно заменить на:

class Class(object):     name = prop('_obj', 'name') 

Для read-only полей нужно задавать только getter:

    def prop_ro(obj, name):         return property(lambda self: getattr(getattr(self, obj), name),                         None,                         None         ) 

smth и full_name являются методами и для их описания нужно лишь добавить вызов в lambda-функции. Также full_name.setter отличается по имени метода, учтем это:

    def prop_call_ro(obj, name):         return property(lambda self: getattr(getattr(self, obj), name)(),                         None,                         None         )      def prop_call(obj, name, setter_name=None):         setter_name = setter_name if setter_name else name         return property(lambda self: getattr(getattr(self, obj), name)(),                         lambda self, value: getattr(getattr(self, obj), setter_name)(value),                         None         ) 

Завернув все наши поля в такие обертки, получаем:

class Class(object):     def __init__(self, extobj):         self._obj =  extobj      version = prop_ro('_obj', 'version')      name = prop('_obj', 'name')      smth = prop_call_ro('_obj', 'strange_original_method_name_for_smth_action')      full_name = prop_call('_obj', 'full_name', 'set_full_name') 

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

Автоматизируем dump()

Теперь уже хочется упростить dump(), чтобы не приходилось указывать список полей.
Если нужны все публичные поля, то можно было бы обойтись и [f for f in dir(self) if not f.startswith(‘_’)], но это не интересно 🙂

Хочется чтобы все поля, созданные через = prop*(…) автоматически отмечались как учитываемые в dump().

Создадим общий родительский класс, который будет делать за нас всю черновую работу:

class Dumpable(object):     @staticmethod     def prop(obj, name):         return property(lambda self: getattr(getattr(self, obj), name),                         lambda self, value: setattr(getattr(self, obj), name, value),                         None         )     ... 

Наш оригинальный класс немного поменяем:

class Class(Dumpable):     name = Dumpable.prop('_obj', 'name') 

Можно компактнее, но, имхо, так выходит понятнее что и откуда растет.
В итоге все prop*-поля попадают внутрь Dumpable. Так давайте же сохраним имена этих полей!

class Dumpable(object):     _props = {}      @staticmethod     def prop(obj, name):         Dumpable._add_me()         return ...     ...      @classmethod     def _add_me(cls):         prop_def = traceback.extract_stack()[-3]         cls_name = prop_def[2]         prop_name = prop_def[3].split('=')[0].strip()         cls.add_prop(cls_name, prop_name)         return      @classmethod     def add_prop(cls, cls_name, prop_name):         if not cls_name in cls._props:             cls._props[cls_name] = set()         cls._props[cls_name].add(prop_name)         return 

Dumpable.add_prop() добавляет во внутренний словарь имен классов со множествами имен полей указанную пару строк «имя класса» и «имя поля».
Dumpable._add_me(), априори зная, что вызывается только напрямую из prop*-методов самого Dumpable, выбирает из стека вызовов строчку с описанием поля (что-то вида «name = Dumpable.prop(‘_obj’, ‘name’)»), из которой получает уже имя поля «name». Заодно из стека вытягивается имя класса, в котором выполняется объявление поля.

Важно для понимания, что стек хранится в порядке от начального скрипта до текущей строки. В таком случае stack[-1] выдаст текущее положение, stack[-2] – точку вызова текущей функции и т.п.

В итоге, в словаре Dumpable._props у нас содержатся все имена классов и методов, описанных через prop*.

Дело остается за малым, реализовать dump():

class Dumpable(object):     ...      @classmethod     def _dump(cls, cls_name):         return cls._props.get(cls_name, set())      def dump(self, req=False):         props = Dumpable._dump(self.__class__.__name__)         results = {}         for key in props:             value = getattr(self, key)             if isinstance(value, Dumpable):                 value = value.dump() if req else value.__class__.__name__             results[key] = value         return results 

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

А благодаря
props = Dumpable._dump(self.__class__.__name__)
мы получаем имена полей именно для того класса, у которого вызывается метод dump().
Остается дело техники: перебрать все имена и получить значения. Если значением является другая инстанция Dumpable, то мы опционально либо делаем рекурсивный вызов dump, либо возвращаем название класса-потомка Dumpable (вот так захотелось).
В итоге реализацию dump() в Class можно вообще выкинуть.

Применяем декораторы

Все хорошо, пока нам не понадобится добавить произвольный метод в список dump-полей.

    class Class(Dumpable):         def foo(self):             return 42 

Не зря ранее были разделены реализации _add_me() и add_prop() в Dumpable. add_prop() нам теперь пригодится, нужно лишь вызвать его с указанием класа и имени метода. Но не руками же это делать. Тут поможет декоратор:

    class Dumpable(object):         @staticmethod         def decor(f):             return <магия>     ...     class Class(Dumpable):         @Dumpable.decor         def foo(self):             return 42 

Происходит магия и dump() начинает выдавать еще и foo.

Как начинающим волшебникам страны Оз нам осталось придумать эту магию.

    class Dumpable(object):     @staticmethod     def decor(f):         prop_name = f.__name__ # имя функции, на которую навешан наш декоратор          cls_name = traceback.extract_stack()[-2][2] # опять лезем в стек и достаем           Dumpable.add_prop(cls_name, prop_name)          def _(*args, **kwargs):             return f(*args, **kwargs)         return _ 

Однако, все работает до тех пор, пока наш декоратор указывается последним в списке.

        # так работает         @accepts(int, int)         @Dumpable.decor         def sum(self, a, b):             return a+b          # а так уже не будет         @accepts(int, int)         @Dumpable.decor         @returns(int)         def sub(self, a, b):             return a-b 

Дело в том, что во втором случае, приходящая в декоратор переменная f, уже не метод, а декоратор, объявленный после нашего (или целая их пачка, навернутых один над другим). И f.__name__ выдает совсем не то, что нам бы хотелось.
Но это все не помеха, достаточно раскрутить цепочку дектораторов до исходного метода:

    @staticmethod     def decor(f):         while f.func_closure is not None:             f = f.func_closure[0].cell_contents         if hasattr(f, 'func_name'):             prop_name = f.func_name         else:             raise RuntimeError('Impossible to calculate property name')          cls_name = traceback.extract_stack()[-2][2]          Dumpable.add_prop(cls_name, prop_name)          def _(*args, **kwargs):             return f(*args, **kwargs)         return _ 

Заданное значение для func_closure указывает на наличие замыкания поверх функции, до которой можно достучаться через f.func_closure[0].cell_contents. Вот так и раскручиваемся. В итоге получаем или нужное нам имя метода, либо оказываемся в глупом положении: например, при указании нашего декоратора на методе, которому ниже указан @property.

Теперь можно в чистой совестью навешивать декораторы как вздумается 🙂

    @property     @accepts(str)     @Dumpable.decor     @returns(dict)     def spam(self, cnt):         ... 

Автор не агитирует использовать решение целиком 🙂
Это лишь подборка нескольких частных случаев в одной решенной проблеме.

ссылка на оригинал статьи http://habrahabr.ru/post/174843/

AN/FSQ-7 — самый снимаемый компьютер

Ещё во время Второй мировой войны Военно-морские силы США сделали предложение Массачусетскому технологическому университету о возможности создания симулятора полётов для тренировки экипажей бомбардировщиков. После успеха ЭНИАКА в 1945 году было решено использовать для этих целей компьютер и оставить безуспешные попытки создания аналогового вычислителя.

Проект заметно затянулся, и был закончен уже после окончания Второй мировой войны. Оставалось неясным, что делать с созданным компьютером Whirlwind — военные утратили к затее интерес. Он, тем не менее, представлял историческую важность — именно Whirlwind и нереализованный проект Whirlwind II стали основой предложения Джея Форрестера по созданию системы противоздушной обороны.

Течение событий ускорил факт появления у СССР атомного оружия и откровенно натянутые отношения двух государств. Уже в декабре 1949 года комитет по воздушной обороне, возглавляемый Джеорджем Вэлли, рекомендует компьютеризированные вычисления для радарных станций. Вэлли и Форрестер фактически заложили основы будущей системы Сейдж (SAGE), разработка которой стоила около 10 млрд. долларов 1954 года и включала создание 24 командных центров, оборудованных в том числе компьютером AN/FSQ-7, рекорд размеров которого так никогда и не был побит.

Компьютеры являлись ключевым компонентом системы. Легко увидеть в сотнях панелей Q7 с их переключателями, кнопками и мигающими лампочками рай для визуального оформления кинофильма. И именно поэтому Q7 является самым снимаемым компьютером в истории. Различные его части и сегодня появляются в кадре, несмотря на то, что он был создан на заре компьютерной эпохи и после 1983 года уже не использовался.

В сентябре 1953 года на основе нереализованных планов Whirlwind II с IBM был заключен контракт на поставку двух прототипов. 28 октября того же года совет ВВС рекомендует выделить средства из бюджета 1955-ого года для финансирования автоматической системы «Линькольн» (в 1954 году переименованной в SAGE). В 1955 году был закончен экспериментальный подсектор SAGE в Лексингтоне, а к октябрю в здании F появился прототип AN/FSQ-7 под названием XD-1, изначально работавший без дисплеев.

Сотрудники ВВС проходили тренировку в Кингстоне (штат Нью-Йорк) в 1955 году. К 1959 году было проведено уже 2 тысячи симулированных перехватов, а первый настоящий состоялся в августе 1958 года. Проводились масштабные тесты математической модели алгоритма ATABE (Automatic Target and Battery Evaluation) с использованием реальных показаний военных радаров, которые засекали учебные нарушения секторов обороны (в частности, военные учения Skyshield).

Каждый из 24 монстров имел внутри себя 49 тыс. вакуумных ламп (вместе с внешними системами каждый пункт содержал порядка 60 тыс. ламп), весил 250 тонн, занимал 2 тыс. квадратных метров (три этажа укрепленных зданий SAGE, расположенных в различных точках США и Канады) и потреблял в пике 3 мегаватта электроэнергии, зато производительность была высока для того времени — 75 тыс. операций в секунду, что позволяло отслеживать положение до 300 воздушных целей. К компьютеру можно было подключить 100 консолей операторов, включавших в себя монитор со световым пистолетом для выделения целей, прикуриватель и пепельницу.

Для обеспечения надежности функционирования Q7 системы ОЗУ, контроля инструкций, сопровождения, арифметический модуль, контроль ввода-вывода и программные элементы дублировались. Таким образом каждый из Q7 представлял из себя объединение двух независимых компьютеров, называемых латинскими буквами A и B. Они не функционировали не одновременно: A выполнял работу, в то время как B в режиме ожидания и мог обслуживаться, затем они менялись ролями. В среднем каждый из компьютеров потреблял 1 мегаватт электроэнергии.

Компьютер оснащался карточным перфоратором IBM 723, устройством чтения перфокарт IBM 713, вспомогательным запоминающим устройством на основе магнитного барабана (50 «участков» по 2048 машинных слов в каждом) и магнитными барабанами IBM 728, устройствами обмена с другими компьютерами AN/FSQ, а также системой светового отображения и предупреждения, которая представляла из себя несколько десятков консолей в различных комнатах.

С помощью Q7 можно было напрямую запустить ракеты из комплекса «Бомарк», а алгоритмы компьютера автоматически управляли взлётом, полётом и началом сверхзвукового прыжка на цель. Позже была реализована система настройки автопилотов пилотируемых истребителей на наведение на цель посредством подсистемы связи земля-воздух.

Q7 обладал Памятью на магнитных сердечниках 1 (Magnetic Core Memory No. 1) — сеткой 256×256 33-битных слов (всего 65.536 машинных слова, приведена на фотографии слева) — и вторым модулем поменьше — 64×64, 4096 33-битных слова. Цикл памяти составлял 3.25 микросекунд. Его младший собрат FSQ-8, которым комплектовались контрольные центры системы SAGE, обладал двумя модулями размера 4096 машинных слов. Причиной наличия двух модулей была необходимость запуска диагностического режима посредством одного из модулей памяти. Один из битов 33-битного машинного слова являлся битом четности.

Для хранения данных каждое из машинных слов делилось на две половины, в каждой из них хранилось 15-битное число и бит знака. Арифметические операции проводились на обеих половинах одновременно. Числа представлялись как дроби от −1 до 1, чтобы избегать переполнения при умножении. Установление пределов вычислений ложилось на плечи программиста.

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

Также машины имели по 12 магнитных барабанов: 6 для системы дисплеев, 6 для самого компьютера. Каждый из барабанов обладал 33 головками и несколькими запасными, что позволяло быстро читать 33-битное слово.

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

При всей технической красоте компьютеры обладали целым семейством недостатков: это были и короткая жизнь вакуумных ламп, что требовало системы автоматической диагностики, и огромное потребление электроэнергии. Однажды при испытаниях в Ньюбурге (штат Нью-Йорк) компьютер был подключен не к той фазе, что привело к выходу из строя линейных выключателей до самой Пенсильвании. Каждая из машин требовала штат из приблизительно 60 человек, разделенных на три группы: собственно компьютер, ввод-вывод и дисплеи. В 1964 году во время теста была обнаружена ошибка в обработке траекторий полётов: при совпадении нескольких технических условий они часто отбрасывались.

В конечном итоге SAGE, на который было потрачено средств больше, чем на весь Манхэттенский проект, был свернут. Компьютеры AN/FSQ-7 постепенно были заменены системой BUIC (Backup Interceptor Control System), однако, два Q7 обслуживались до 1983 года.

Технологии, появившееся в AN/FSQ-7, использовались в созданной IBM в 1964 году системе бронирования билетов Sabre. Q7 подтолкнул к созданию множества технологий и явился первой распреленной сетью вычислительных машин, использовавших телефонную линию для связи, что явилось прототипом современных модемов. В Q7 использовались новые для того времени память на магнитных сердечниках, интерактивные графические дисплеи, сетевые базы данных, многозадачные системы, структурированные программные модули и модульные компьютеры. Благодаря проекту SAGE появились профессия инженера разработки программного обеспечения и световой пистолет, изобретенный Робертом Эвереттом.

Безусловно, AN/FSQ-7 оставил огромный след в информатике, но куда интересней то, что стало с компьютером после его смерти. Удивительно, но несмотря на то, что машина разрабатывалась в 50-х годах прошлого века, её фрагменты до сих пор используются для создания эффекта футуристичного суперкомпьютера или хотя бы для создания эффекта оборудования более поздней эпохи, чем та, в которую попал Q7.

К примеру, панели лампового компьютера используются в фильме для создания эффекта 22 века. В комедии «Спящий» (Sleeper) 1973-ого года, где Майлз Монро (роль исполняет Вуди Аллен) засыпает в криогенной камере на 200 лет и оказывается в 2173 году, используется довольно много оборудования от Q7: это и панели командного пункта, и секция индикаторов консоли обслуживания дуплексной связи.

Майк Лоуэн, служивший в ВВС США в 1982-86 гг. и одним из последних заставший последний работающий экземпляр AN/FSQ-7, впервые заметил знакомые панели в сериале эры середины 60-ых The Time Tunnel и заинтересовался тем, в каких ещё фильмах сыграл этот ламповый монстр. Во «Временном туннеле» Q7 исполняет роль секретного государственного проекта машины времени, строящейся под пустыней Аризоны.

Появление компьютера AN/FSQ-7 было бы более всего логично в фильме «Доктор Стрейнджлав, или Как я перестал бояться и полюбил бомбу» — тогда бы он выполнял свою прямую функцию воздушной обороны, но в комедии Стэнли Кубрика используется старый IBM 7090/94.

Одни из наиболее популярных произведений, в которых появился Q7, является «День независимости» (Independence Day) 1996 года. Хотя последний компьютер серии был остановлен за 13 лет до этого, в фильме он играет роль современного командного центра.

Фильм 1983 года «Военные игры» (WarGames) полон множества мигающих панелей, экранов (чего стоит сам оборонный компьютер WOPR), но Q7 не имеет с ними ничего общего, он появляется в виде панелей контроля главного магнитного барабана и индикаторов схем лишь в архивном видеоролике с профессором Фалкеном.

AN/FSQ-7 до сих пор появляется на экране, к примеру, он был замечен в сериале Lost («Остаться в живых»). Он предстаёт целой группой (слева направо) панелей питания, ручной проверки барабанов и радарных панелей.

Как же оборудование от засекреченого оборонного компьютера так быстро попало в кадр массового кино? Наиболее известны две фирмы, обладавших панелями и частями списанных Q7: Vectrex Corporation и Woody’s Electrical Props. Первая компания из Санта-Моники давала части компьютера напрокат для, к примеру, «Звёздного крейсера „Галактика“» (Battlestar Galactica), но в 80-ых они вышли из бизнеса и продали оставшееся оборудование. Некоторые из панелей были приобретены частными лицами.

«Электрический реквизит Вуди» предоставлял части Q7 для фильмов об Остине Паурсе, WarGames (Военные игры) и Apollo 13 (Аполлон-13) и сериала Lost (Остаться в живых). В начале 60-ых «Двадцатый век Фокс» приобрела списанный AN/FSQ-7, панели которого позже были выкуплены работавшим там специалистом по реквизиту Вуди. С того времени часть ламп в панелях была заменена, и Майк Лоуэн приводит фотографии реквизита Вуди.

По материалам отчёта Introduction to AN/FSQ-7 Combat Direction Central and AN/FSQ-8 Combat Control Central, IBM-SAGE-Computer, plyojump.com, воспоминаниям Пита Каркулиаса, техника Q-7 в 1967—69 годах, Wired.com, списка Майка Лёвена появлений компьютера IBM AN/FSQ-7 в медиа и списка сайта Starring the Computer появлений компьютера IBM AN/FSQ-7 в медиа.

ссылка на оригинал статьи http://habrahabr.ru/post/174845/