[management] Яркий пример поведения настоящего прирожденного менеджера

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

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

Фрагмент из очерка Чунихина В.М. “Ложь, о которой не узнал Сталин” (воспоминания маршала авиации А.Е.Голованова):

  ...Не помню точно день, но это, кажется, было весной, в апреле, мне позвонил Сталин и осведомился, все ли готовые самолеты мы вовремя забираем с заводов. Я ответил, что самолеты забираем по мере готовности.
  - А нет ли у вас данных, много ли стоит на аэродромах самолетов, предъявленных заводами, но не принятых военными представителями? - спросил Сталин.
  Ответить на это я не мог и попросил разрешения уточнить необходимые сведения для ответа.
  - Хорошо. Уточните и позвоните, - сказал Сталин. 
  Я немедленно связался с И. В. Марковым, главным инженером АДД (Авиации дальнего действия - В.Ч.). Он сообщил мне, что предъявленных заводами и непринятых самолетов на заводских аэродромах нет. Я тотчас же по телефону доложил об этом Сталину.
  - Вы можете приехать? - спросил Сталин. 
  - Могу, товарищ Сталин. 
  - Пожалуйста, приезжайте. 
  Войдя в кабинет, я увидел там командующего ВВС генерала П. Ф. Жигарева, что-то горячо доказывавшего Сталину. Вслушавшись в разговор, я понял, что речь идет о большом количестве самолетов, стоящих на заводских аэродромах. Эти самолеты якобы были предъявлены военной приемке, но не приняты, как тогда говорили, "по бою", то есть были небоеспособны, имели различные технические дефекты. 
  Генерал закончил свою речь словами: 
  - А Шахурин (нарком авиапромышленности. - А. Г.) вам врет, товарищ Сталин. 
  - Ну что же, вызовем Шахурина, - сказал Сталин. Он нажал кнопку - вошел Поскребышев. - Попросите приехать Шахурина, - распорядился Сталин. 
  Подойдя ко мне, Сталин спросил, точно ли я знаю, что на заводах нет предъявленных, но непринятых самолетов для АДД. Я доложил, что главный инженер АДД заверил меня: таких самолетов нет. 
  - Может быть, - добавил я, - у него данные не сегодняшнего дня, но мы тщательно следим за выпуском каждого самолета, у нас, как известно, идут новые формирования. Может быть, один или два самолета где-нибудь и стоят. 
  - Здесь идет речь не о таком количестве, - сказал Сталин. Через несколько минут явился А. И. Шахурин, поздоровался и остановился, вопросительно глядя на Сталина. 
  - Вот тут нас уверяют, - сказал Сталин, - что те семьсот самолетов, о которых вы мне говорили, стоят на аэродромах заводов не потому, что нет летчиков, а потому, что они не готовы по бою, поэтому не принимаются военными представителями, и что летчики в ожидании матчасти живут там месяцами. 
  - Это неправда, товарищ Сталин, - ответил Шахурин. 
  - Вот видите, как получается: Шахурин говорит, что есть самолеты, но нет летчиков, а Жигарев говорит, что есть летчики, но нет самолетов. Понимаете ли вы оба, что семьсот самолетов - это не семь самолетов? Вы же знаете, что фронт нуждается в них, а тут целая армия. Что же мы будем делать, кому из вас верить? - спросил Сталин. 
  Воцарилось молчание. Я с любопытством и изумлением следил за происходящим разговором: неужели это правда, что целых семьсот самолетов стоят на аэродромах заводов, пусть даже не готовых по бою или из-за отсутствия летчиков? О таком количестве самолетов, находящихся на аэродромах заводов, мне слышать не приходилось. Я смотрел то на Шахурина, то на Жигарева. Кто же из них прав?
  Невольно вспомнилась осень 1941 года, когда Жигарев обещал Сталину выделить полк истребителей для прикрытия выгружавшейся на одном из фронтов стрелковой дивизии, а оказалось, что истребителей у него нет. Как Павел Федорович тогда вышел из весьма, я бы сказал, щекотливого положения? Не подвел ли его и сейчас кто-нибудь с этими самолетами? Алексея Ивановича Шахурина я уже знал как человека, который не мог делать тех или иных заявлений, а тем более таких, о которых сейчас идет речь, предварительно не проверив, да еще не один раз, точность докладываемых в Ставку данных. 
  И тут раздался уверенный голос Жигарева: 
  - Я ответственно, товарищ Сталин, докладываю, что находящиеся на заводах самолеты по бою не готовы. 
  - А вы что скажете? - обратился Сталин к Шахурину. 
  - Ведь это же, товарищ Сталин, легко проверить, - ответил тот. - У вас здесь прямые провода. Дайте задание, чтобы лично вам каждый директор завода доложил о количестве готовых по бою самолетов. Мы эти цифры сложим и получим общее число. 
  - Пожалуй, правильно. Так и сделаем, - согласился Сталин. В диалог вмешался Жигарев: 
  - Нужно обязательно, чтобы телеграммы вместе с директорами заводов подписывали и военпреды. 
  - Это тоже правильно, - сказал Сталин. 
  Он вызвал Поскребышева и дал ему соответствующие указания. Жигарев попросил Сталина вызвать генерала Н. П. Селезнева, который ведал заказами на заводах. Вскоре Селезнев прибыл, и ему было дано задание подсчитать, какое количество самолетов находится на аэродромах заводов. Николай Павлович сел за стол и занялся подсчетами. 
  Надо сказать, что организация связи у Сталина была отличная. Прошло совсем немного времени, и на стол были положены телеграммы с заводов за подписью директоров и военпредов. Закончил подсчет и генерал Селезнев, не знавший о разговорах, которые велись до него. 
  - Сколько самолетов на заводах? - обратился Сталин к Поскребышеву. 
  - Семьсот один, - ответил он. 
  - А у вас? - спросил Сталин, обращаясь к Селезневу. 
  - У меня получилось семьсот два, - ответил Селезнев. 
  - Почему их не перегоняют? - опять, обращаясь к Селезневу, спросил Сталин. 
  - Потому что нет экипажей, - ответил Селезнев.
  Ответ, а главное, его интонация не вызывали никакого сомнения в том, что отсутствие экипажей на заводах - вопрос давно известный. 
  Я не писатель, впрочем, мне кажется, что и писатель, даже весьма талантливый, не смог бы передать то впечатление, которое произвел ответ генерала Селезнева, все те эмоции, которые отразились на лицах присутствовавших, Я не могу подобрать сравнения, ибо даже знаменитая сцена гоголевский комедии после реплики: "К нам едет ревизор" - несравнима с тем, что я видел тогда в кабинете Сталина. Несравнима она прежде всего потому, что здесь была живая, но печальная действительность. Все присутствующие, в том числе и Сталин, замерли и стояли неподвижно, и лишь один Селезнев спокойно смотрел на всех нас, не понимая, в чем дело... Длилось это довольно долго. 
  Никто, даже Шахурин, оказавшийся правым, не посмел продолжить разговор. Он был, как говорится, готов к бою, но и сам, видимо, был удивлен простотой и правдивостью ответа. 
  Случай явно был беспрецедентным. Что-то сейчас будет?! Я взглянул на Сталина. Он был бледен и смотрел широко открытыми глазами на Жигарева, видимо, с трудом осмысливая происшедшее. Чувствовалось, его ошеломило не то, почему такое огромное число самолетов находится до сих пор еще не на фронте, что ему было известно, неустановлены были лишь причины, а та убежденность и уверенность, с которой генерал говорил неправду. 
  Наконец, лицо Сталина порозовело, было видно, что он взял себя в руки. Обратившись к А. И. Шахурину и Н. П. Селезневу, он поблагодарил их и распрощался. Я хотел последовать их примеру, но Сталин жестом остановил меня. Он медленно подошел к генералу. Рука его стала подниматься. "Неужели ударит?" - мелькнула у меня мысль.
  - Подлец! - с выражением глубочайшего презрения сказал Сталин и опустил руку. - Вон!

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

[comp.prog.thoughts] Так вот о языке Go

Хотя я и не написал на языке Go ни одной программы (пока?), но благодаря штудированию Effective Go, мнение о языке у меня сложилось. Однако, и я попробую показать это далее, мнение об именно Go не так интересно, как сам факт его появления. Но обо всем по порядку.

Язык Go производит впечатление добротно сделанного, практичного и минималистичного языка, уровнем повыше C – за счет сборки мусора, встроенных в язык хэш-таблиц и каналов, поддержки лямбда функций и goroutines, а так же за счет интерфейсов.

Язык приятно удивляет повторным использованием одних и тех же идиом. Я был поражен тем, как выполняются: проверка наличия элемента в хэш-таблице, неблокирующее чтение из канала и проверка типа объекта:

func demo( m map[string]int, ch chan int, err os.Error ) {
  v, present := m[ 'key' ];
  i, isRead := <-ch;
  e, isCastSuccessful := err.(*os.PathError);
  ...
}

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

Язык оставляет впечатление, что очень умные и опытные люди пробуют создать удобный для себя инструмент. Заточенный под конкретную нишу – разработку околосистемных вещей, которые сейчас пишутся на C. Я думаю, что Subversion или Apache от переписывания на Go только выиграл бы.

Однако лично меня язык Go оставил равнодушным, не захотелось мне на нем программировать. Наверное, из-за отсутствия в нем нормального ООП, шаблонов, исключений, константности для объектов. Если не сравнивать Go с C++ (поскольку в C++ нет сборки мусора), то язык D выглядит предпочтительнее, чем Go. Ведь за счет средств D можно повторить все, что есть в Go (включая goroutines и каналы).

Т.е. моя главная претензия к Go – это его ограниченные возможности по сравнению с другими современными языками. Пока ты пишешь какую-нибудь несложную утилиту командной строки или жестко ориентированный под конкретную задачу сервер, языка Go может и хватит. Но стоит ступить чуть в сторону – и что? Например, можно ли на Go эффективно написать аналог Boost.MultiIndex? Я сомневаюсь.

Что в истории с Go интересно, так это шум вокруг его появления. Имя Google – это сильно, это внушаить! ;)

Такое впечатление, что все, что выбрасываетсявыбирается из Google на свет божий, просто обречено на известность. Анонсировал Google свой Protocol Buffers – все “Вау!” Опубликовали альфа-версию Go – по всему миру “Go! Go! Go!” Ну а что этот Go? Пока ничего. Ну да ладно, жизнь не совершенна, и не стоит искать справедливости в информационных технологиях ;)

Но самое интригующее – это практически одновременный выход на свет двух очень похожих, на мой взгляд, языков – Go и Zimbu. Вот это уже тенденция. Новые минималистичные нативные языки, но со сборкой мусора. Нацеленные на замену в околосистемных нишах как C (за счет высокоуровневости), так и C++ (за счет простоты, сборки мусора и безопасности). Что позволяет мне говорить о двух вещах.

Во-первых, явно демонстрируется, что managed-платформы не подходят для целого ряда задач. Начиная от написания мелких системных утилит и текстовых редакторов вроде ViM, заканчивая высоконагруженными серверами. Безопасность, кроссплатформенность, большие библиотеки, Ынтырпрайзность и поддержка крупными корпорациями – все это хорошо. Но нафиг не упало, когда нужно написать что-то типа svn.exe.

Во-вторых, четко проявляется картина, в которой язык C не удовлетворяет современных разработчиков своей низкоуровневостью, а C++ – своей монстрообразностью и переусложненностью. Действительно, нерадостно в XXI-м веке вручную распределять память и искать библиотеки, реализующие хэш-таблицы. Равно как и нерадостно годами изучать C++ для того, чтобы быть уверенным в безопасности своего кода.

И, если поиграть в пророка, то я бы сказал, что разработчики (некоторая их часть) сейчас заинтересованы в появлении современного нативного языка. Более мощного, чем C, и менее сложного, чем C++. Более безопасного, чем каждый из них.

На его роль могли бы претендовать Eiffel, OCaml или D. Но, поезда Eiffel и OCaml уже ушли (при всем уважении к ним и к их пользователям). D так и не отправился в путь, хотя уже догнал по сложности C++ и хочет обогнать. Должен быть какой-то новый игрок. Именно новый, за которым еще не тянется след обманутых ожиданий :) Может быть это будет Zimbu. Может быть Go. Может быть еще кто-то.

Но я сомневаюсь. Поскольку практически все современные мейнстримовые языки (C++, Java, C#) начинались более простыми, чем есть сейчас. И эта сложность не случайна. Она возникла как следствие попыток решения реальных задач. Ведь любой успешный инструмент начинает применяться совсем не так, как это предполагал его автор. Как следствие, инструмент обрастает фишечками и рюшечками, без которых никак. Но которые превращают язык в неповоротливого монстра типа C++.

Это неизбежный процесс. Очень хорошо он виден именно на примере языка D. Он в начале 2000-х был почти как Zimbu сейчас. Вальтер Брайт был даже против поддержки шаблонов в языке. Сначала. Но потом появились и шаблоны, и замыкания, и константность, а на горизонте маячат еще и макросы. А ведь на D еще ничего толкового и не написали! Так что уже говорить о C++, Java или C#, на которых народ клепает чуть ли не миллионы строк в сутки, в самых разных прикладных областях.

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

Такие вот пироги. И кажется мне, что если в нишу C/C++ и ворвется какой-то молодой C++киллер, то он изначально должен быть не слабее C++ по своим выразительным возможностям, а напротив – гораздо, многократно мощнее. Но при этом он должен быть простым в изучении, а так же обеспечивать отличную интеграцию с уже написанным C/C++ кодом. Такой, что осваивается за один вечер, а потом рвет C++ как тузик грелку! :)

Появится ли что-нибудь такое? Будем посмотреть. Но вряд ли это будет Zimbu или Go.

[comp.prog] Краткий пересказ Effective Go на русском

В принципе, готов: http://eao197.narod.ru/desc/short_effective_go.html

За орфографические ошибки и очепятки не пинать, лучше сообщайте мне по почте, постараюсь устранить все найденное :)

Мое впечатление о языке чуть позже (так что stay tunned ;)

[comp.prog.thoughts] Гримасы вирусной константности

В второй версии языка D хотят сделать т.н. “вирусную константность” – если объект A хранит ссылку на объект B, то в константном методе объекта A объект B так же будет константой. Продемонстрирую это на примере C++ (поскольку с D уже давно не работал и синтаксис подзабыл). Итак, в C++ мы имеем:

class B {
  public :
    void change() {}
    void query() const {};
};

class A {
  private :
    B b_;
  public :
    void query() const {
      b_.change(); // (1)
      b_.query();
    }
};

Строка, помеченная (1) не компилируется, т.к. в константном методе A::query() объект b_ так же считается константой. Это потому, что атрибут A::b_ является объектом. Если бы он был ссылкой (или указателем), то для него можно было бы вызывать метод change() без проблем – мы же не меняем атрибут A::b_. Поэтому следующий код компилируется и работает “на ура”:

class B {
  public :
    void change() {}
    void query() const {};
};

class A {
  private :
    B & b_;
  public :
    A( B & b ) : b_( b ) {}
    void query() const {
      b_.change();
      b_.query();
    }
};

Но это в C++, в котором вирусной константности, вроде бы нет (об этом ниже). А вот в D он не будет работать, т.к. там в методе A::query атрибут A::b_ сменил бы свой тип с B& на const B&.

Вирусная константность стала одной из главных причин, по которым язык D мне уже не интересен. Поскольку неприятности возникают как раз там, где мне бы не хотелось их иметь. В частности, когда я продумывал портирование SObjectizer в D2, я думал, что сообщения между агентами будут ходить в виде иммутабельных объектов. Это позволило бы передавать один объект сообщения сразу нескольким агентам одновременно (в разных потоках) и не задумываться о том, что какой-то агент это сообщение модифицирует – просто не смог бы этого сделать.

Это было бы классной фишкой языка D, но! При этом в сообщении нельзя было бы передавать мутабельные ссылки. Т.е. вообще нельзя. Представьте себе, что ряду агентов нужно разослать сообщение с ссылкой на новый логгер:

class ChangeLoggerMsg : public Msg {
  private :
    Logger & logger_;
  public :
    Logger & logger() const { return logger_; }
};

Вроде бы просто. Но в D2 это не пройдет. Поскольку метод ChangeLoggerMsg::logger() не сможет возвратить Logger& – только const Logger&. А константная ссылка на логгер, мягко говоря, на фиг никому не упала.

Этот пример (или аналогичный ему) я приводил в news-группе языка D, пытаясь привлечь внимание к тому, что вирусная константность – это не есть хорошо на 100%. Никого там это не тронуло, ну и ладно. Это уже будут проблемы D-шников.

Но вот на днях довелось столкнуться со случаем вирусной константности в C++. Да, да, именно вирусной константности, я сам удивился. А дело было так: во время code review нашел что-то вроде:

class factory_base_t {
  // Интерфейс фабрики для создания некоторых объектов.
  // Часть методов фабрики является неконстантными.
};
typedef Poco::SharedPtr< factory_base_t > factory_base_ptr_t;

// Каталог доступных фабрик.
// По списку фабрик можно пройтись, выбрать нужные, и скопировать
// ссылки на них к себе.
std::vector< factory_base_ptr_t > &
query_all_factories() {
  static std::vector< factory_base_ptr_t > factories;
  // Вектор factories заполняется при первом обращении, а затем
  // может меняться время от времени.
  return factories;
}

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

Но делать это нельзя. Поскольку, константный operator[] для vector<T> возвращает const T&. В данном случае это будет const SharedPtr<T>. А константный operator* (и operator->) для SharedPtr<T> будет возвращать const T&. Т.е. если возвращать константную ссылку на вектор фабрик, то для фабрик из этого вектора нельзя будет вызывать неконстантные методы. Грубо говоря, нельзя будет написать:

const std::vector< factory_base_ptr_t > & v = query_all_factories();
for( size_t i = 0; i != v.size(); ++i )
  v[ i ]->decrement_priority( priority_delta );

Выпутаться из этой ситуации можно разными способами. Например, можно возвращать вектор фабрик по значению. Или можно возвращать объект, который будет хранить в себе ссылку на вектор, но не будет давать к ней доступа. Можно делать копию умного указателя на фабрику перед обращением к ней. Можно и еще что-нибудь сделать – в том числе и полностью сменить дизайн хранилища фабрик (а так же сменить язык программирования, место работы и страну проживания ;).

Однако, важен сам факт того, что нужно вообще что-то делать. Казалось бы, простой случай – я хочу защитить объект от модификации, но не хочу защищать от этого те объекты, на которые он ссылается. Ан нет! :) Не знаю, как кому, но меня раздражает необходимость обходить систему типов в таких случаях.

Наличие константности в языке, по-моему, очень большой плюс. Это как раз то, что меня держит в C++ (помимо прочего). Но вот чрезмерная константность – на мой взгляд, это плохо.

При наличии обычной (не вирусной) константности обеспечить вирусную можно без проблем – достаточно определить константные геттеры, как это делается в C++. А вот когда константность вирусная по умолчанию, то избавиться от нее гораздо сложнее.

[life.wow] Батуты в цирке дю Солей: афигеть!

Складывается впечатление, что в какие-то моменты на актера перестают действовать силы притяжения.

[comp.prog.d] Статья The Case for D переведена на русский

Статья Андрея Александреску The Case for D, о которой я писал несколько месяцев назад, была переведена на русский язык сообществом сайта http://dprogramming.ru/

Вариант в виде pdf: http://verypositive.com/files/d2.pdf
И в виде dvi: http://verypositive.com/files/d2.dvi

Желающие могут присоединиться к обсуждению либо на LOR-е, либо на RSDN-е.

[life; prog; humour] Программисты – они такие – делают только то, что сказали

Из Господин Инженер’s Journal:

в знакомой конторе руководитель проекта звонит девелоперам и говорит:

- так, показ системы заказчику, всем отлогиниться от сервера разработки и полтора часа не заходить!

через полчаса перезванивает и орет:

- бля, кто в скайп написал "а когда зарплата будет?"??!!

И чего ругается? Сам же сказал – отключиться от сервера. От сервера отключились. А команды не беспокоить руководителя не было :)

PS. Сам долго втыкал, где же лопата зарыта. Потом дошло, что руководитель на своем компьютере заказчикам демонстрацию делал. И они увидели сообщения в скайпе.

[life.photo] Пара отличных “летательных” снимков

Старт шаттла Атлантис:

На фестивале воздушных шаров в Мексике:

Фотографии найдены в очередном выпуске WSJ’s Picture of the Day.

[comp.prog.flame] Так ведь Microsoft и не благотворительный фонд

Замечательный перл выдал некто vshabanov в обсуждении новости об открытии исходников .NET Micro Framework на RSDN:

Речь шла о том, что вот мол платформа (сиречь библиотеки), а вот виртуальная машина, теперь можно быстро наклепать поверх реализацию любого языка, не сильно заморачиваясь с компиляцией, да еще и получить простой интерфейс к куче библиотек от МС (типично МС-овский подход, кстати: любой язык, но на нашей платформе). Оказалось только, что под эту платформу/VM можно переводить далеко не любые языки. Более того, языки дающие наибольшую производительность труда программиста переводить сложнее всего -- слишком низок уровень донетовской платформы.

Т.е. рекламируемый смысл дотнета "фигачьте компилер вашего любимого языка под нашу платформу и получайте язык+библиотеки=профит", стоит переделать как "привяжитесь к МС навсегда", а языки -- это так замануха.

(выделение жирным мое)

Бл* (простите мне мой французский), когда программисты начинают обвинять MS в стремлении получить прибыль, я перестаю понимать смысл происходящего.

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

Всякие Just for Fun – это несерьезно. Нет ни одной более-менее работающей и использующейся OS, ни одного браузера, ни одного компилятора, который бы разрабатывался сейчас Just for Fun.

OpenSource – это вообще уже давно серьезное коммерческое предприятие. Большие и не очень большие компании вкладывают деньги в OpenSource только для того, чтобы потом сэкономить.

Итак, если кто-то вкладывает деньги в продукт, он, понятное дело, хочет продать свой продукт. Пусть не .NET Framework, так Windows, под которую .NET Framework заточен. Но продать. Т.е. получить пользователей. А после того, как получить – еще и удержать их. Например, за счет уникальной возможности объединения в рамках .NET кода на разных языках. Не всех, возможных языков, понятное дело. А тех, которые интересны Microsoft. И у каждого есть выбор – либо работать на основе продуктов Microsoft и получать от этого профит (как сделали тысячи компаний, выпускающих Windows only приложения), либо работать на чем-то другом. Никто никого не заставляет, а Microsoft хочет получить прибыль.

Это нормально.

Поэтому когда кто-то начинает обвинять MS в том, что она хочет продавать людям свой продукт (Windows в данном случае)… Любо это говорит обиженный Microsoft-ом конкурент, либо непонимающий происходящего ребенок, либо какой-то идеалист.

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

---

Этот же персонаж выдал далее по ветке еще один пассаж (о недостатках F# по сравнению с OCaml):

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

Ну такое классное OO в OCaml, ну такое… Что прям не пользуется никто, т.к. нафиг не нужно.

Не случайно, что все это говорит ярый сторонник ФП :) Они, эти ярые сторонники ФП, временами отличаются удивительной оторванностью от реальности :)

[comp.prog.wow] Распределенный MS Office Excel на подходе?

Похоже, таки да: об этом упоминается в статье в Dr.Dobb’s -- “Windows HPC Server 2008 R2 Released”. Одна из новых фич MS Windows HPC Server 2008:

Новые пути ускорения работы таблиц MS Office Excel, такие как поддержка предназначенных для работе в кластерах пользовательских функций (cluster-aware user-defined functions) и возможность запуска распределенного Excel 2010 в кластере.

Она как!

PS. Кстати, и о самом существовании Windows HPC Server я раньше не слышал ;)

[comp.prog.cpp] Miser – многопоточный распределитель памяти

До недавнего времени я был наслышан только об одном специализированном менеджере памяти для многопоточных C/C++ приложений: Hoard-е. Но потом мне попалась на глаза статья “Multicore-enabling the N-Queens Problem Using Cilk++”, в которой упоминался менеджер памяти Miser, разработанный для Cilk++.

Подробнее о нем можно прочитать в блоге разработчиков: Miser – A Dynamically Loadable Memory Allocator for Multi-Threaded Applications. Неплохое чтиво, интересующимся данной темой, думаю, будет интересно.

Напомню, что сейчас Cilk++ является собственностью Intel и Miser распространяется вместе с Cilk++.

[comp.prog] Zircon – продукт для распараллеливания вычислений на основе ACE

В блоге Стива Хьюстона проскочило упоминание продукта Zircon, который разработан на основе библиотеки ACE (чем и привлек мое внимание).

Насколько я понял из их большой презентации, суть заключается в следующем: есть какая-то вычислительная программа, которую нужно распараллелить. Для этого некоторые процедуры, вычисления в которых можно разнести по разным узлам сети, оформляются в специальные zPlugin-ы. Т.е., была функция F, получили функцию z_F. Само приложение переписывается так, чтобы оно вызывало не F, а z_F. Такой вызов делегируется промежуточному слою, которым является Zircon. Этот промежуточный слой позволяет вынести вычисления на разные узлы сети, контролировать ход работы, обрабатывать сбои и отказы и т.д.

Сама среда Zircon кроссплатформенна и может работать под Windows, Linux, HP-UX, Solaris. Но, как я понял, zPlugin-ы должны запускаться только на той платформе, под которую они скомпилированны (т.е. один и тот же zPlugin, написанный на C++, не может просто так переехать с Windows-узла на Solaris-узел).

[business] Идея для легального скачивания видео

Когда-то я уже высказывался по поводу файлообмена:

Вот уж кому действительно выгодно процветание пиратства – так это Интернет провайдерам. Народ качает пиратский контент, провайдеры в выигрыше :)

Как по мне, так медиа-гигантам давно нужно было менять свою политику. Ну ведь все равно понятно, что воровать будут. Так почему бы не сделать воровство невыгодным для пиратов, а распространение фильмов/музыки через Интернет – выгодным для себя? Размещайте сами в Сети фильмы, и берите деньги с провайдеров. Вот, скажем, у меня unlimit за $20 в месяц. Пусть из этих денег $5 идут продавцам контента. Таких как я только в одной Белоруссии наберется тысяч сто, я думаю. Это значит, что какой-нибудь Warner Bros. будет получать по $500K в месяц от какой-то заштатной Белоруссии.

Вот была бы красота: захотел фильм посмотреть, зашел на сайт Warner Bros., выбрал подходящее для себя качество и размер (700Mb, 1.5Gb, 4.5Gb…), качнул. С нормального сайта, на нормальной скорости. Warner Bros. и Белтелеком получили свою денежку, я – свой фильм. Лепота!

После обсуждения этой мечты с коллегами стало понятно, что она несбыточна: кто-нибудь один скачает фильм, выложит в “домашнюю” сеть и все. Десятки, а то и тысячи соседей и друзей соседей будут смотреть его бесплатно. Собственно, сейчас тоже самое происходит с незащищенными, или плохозащищенными DVD – покупается, рипится, перекодируется в Xvid, заливается в файлообменник.

Значит, нужно сделать так, чтобы скачанный из интернета фильм мог посмотреть только один человек. Как это сделать? Разве что привязать при скачивании содержимое файла к конкретному девайсу. И, мне кажется, это не так уж сложно.

Предположим, что есть какая-то штука, типа DVD-проигрывателя со встроенным HDD и/или подключением внешних USB носителей. В ней находится крипто-модуль (что-то типа HSM) с уникальной парой открытый-закрытый ключ. Допустим, что эта штука содержит в себе Web-браузер и имеет возможность подключаться к Интернет. Владелец такого проигрывателя заходит через встроенный Web-браузер на сайт Warner Bros., выбирает нужный ему фильм в нужном качестве. После этого девайс отправляет на сайт владельца фильма запрос. В запросе содержится открытый ключ девайса + какая-то информация для снятия денег с пользователя (не думаю, что к расчетам нужно будет привлекать Интернет-провайдера, проще проводить простую платежную транзакцию через какой-нибудь PayPal).

Получив открытый ключ потребителя, владелец фильма дает потребителю URL для скачивания специально подготовленной для этого потребителя копии фильма. Копии не простой. Файл с фильмом разбивается на порции, каждая порция шифруется каким-то симметричным алгоритмом (с быстрой дешифровкой) и в начале каждой порции хранится ключ этой порции, зашифрованный открытым ключом потребителя. Т.е. расшифровать ключи, которыми закрыты фрагменты фильма можно только закрытым ключом. А закрытый ключ хранится аппаратно внутри этого хитрого девайса.

В итоге, девайс завершает скачивание фильма и сохраняет его на своем HDD или внешнем USB-носителе. Тиражирование этой копии для владельца фильма не опасна, т.к. она зашифрована уникальными ключами. А воспроизвести эту копию может только данный девайс.

Не думаю, однако, что эта идея может быть воплощена в жизнь. Но я бы такой схемой пользовался бы. Поскольку DVD с фильмами не покупаю, т.к. не любитель коллекционировать фильмы и не хочу хранить дома сотни дисков, которые редко пересматриваю. Да и жалко $5-10 за фильм, который смотришь только один раз. А так, особенно если 700Mb версия фильма будет стоить $1, скачал фильм, посмотрел, не понравилось – удалил. Понравилось – сделал резервную копию. Очень понравилось – доплатил еще пару долларов и скачал копию в лучшем качестве. Воровать будут и при такой схеме, но, думаю, уже в несколько раз меньше. К тому же такая схема позволит скачивать не весь фильм, а только его часть для ознакомления за совсем смешные деньги.

PS. Пара-тройка технических соображений.

В свете того, что сейчас появляются нетбуки за $80, а ассиметричная криптография встраивается даже на телефонные SIM-карты, я не думаю, что подобный девайс будет дорого стоить.

Тем более, что вся программная начинка для него может быть полностью Open Source.

А в качестве секюрного хранилища криптоключей может использоваться как раз SIM-карта (при этом пользователь будет иметь возможность переставить ее из одного девайса в другой при поломке).

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

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

И самому девайсу не нужно уметь лазить в Интернет. Он может уметь скидывать на USB свой открытый ключ (или этот ключ может сразу хранится на mini-CD, в комплекте с девайсом). А имея этот ключ пользователь может заказывать и скачивать фильмы со своего компьютера. Потом перекидывать на USB или DVD и просматривать с помощью девайса.

[life.humour] Phantom Bike – велосипедостроение в прямом смысле слова