Синхронизация музыки и игровых событий на Unity

Руки прочь от консоли!

Любой организм стремится к гомеостазу. То есть к стабильности, предсказуемости, спокойствию.

Это означает, что любая встряска, любое резкое изменение порождает стресс. Особенно, если в 3 часа ночи, особенно если сразу надо что-то с этим делать, разбираться, чинить…

Кому знакома ситуация, когда что-то очень важное (база данных, финансовый сервис, айпад генерального) ВДРУГ перестают работать. Это всегда происходит вдруг… А вы как назло, отвечаете своей головой за это важное.

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

Вспоминаю случаи, когда мы делали по ночам работы по настройке сетевой безопасности РАО ЕЭС России, а потом нам звонили «срочно-все_сломалось-чините!». Сколько косяков я мог избежать, если бы не ломился сразу вбивать команды с колотящемся сердцем… Сколько оправданий можно было бы не придумывать. Ведь стыдно признаться в своей поспешности и глупости…

Напомню, чтобы быть точным: стресс – это реакция организма. Физиологическая. Впрыскивается адреналин, увеличивается кровоток в ногах, выделяется норадреналин и кортизол (в мозг). Вы спросите «зачем»?

Бежать, конечно. И чем быстрее, тем лучше! Организм первым делом стремится сбежать, чтобы там, в тишине и покое, разобраться с проблемой, если она вообще осталась.

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


Если бежать невозможно, то тогда наш древний рептильный мозг выбирает вторую альтернативу – драться!

«Драться» в нашем случае – нападать. Можно нападать на того, кто принес весть (например, отрицать или обесценивать сказанное, мол вечно вы из мухи слона, сами ни черта не понимаете). Это нормальная реакция, но она не ведет к решению. Либо можно атаковать несчастную железку ☺

Если же и драться невозможно, то остается только третья реакция – замереть! И в этот момент в теле «запаковывается» огромное количество физиологической энергии. По моим наблюдениям, люди, работающие со сложными ИТшными системами, как правило реагируют замиранием. Оцепенение только снаружи выглядит спокойствием. Изнутри в это время бушует химический фонтан, который подстегивает организм к действию, но никакого выхода не происходит.

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

Из опыта: если блокировать доступ, так непременно «шнур из коммутатора выдернуть», если что-то не работает, срочно перезагружать, не удосужившись снять логи для анализа, если виртуальную машину перевезти на другую ферму, так по питанию весь сервер рубить, если не работает почта, то накатить параллельно непроверенный бэкап и потерять переписку за неделю навсегда… Столько всего насмотрелся (да и наделал, чего греха таить) за 12 лет.

Запомните: в состоянии стресса человек мыслит НЕ ЭФФЕКТИВНО! Эволюция запрограммировала нас убегать от стресса, а не эффективно решать умные задачки!

А мы лезем дрожащими руками в самые теплые и беззащитные недра ИТ-систем, режем по живому без анестезии, оперируем кухонным ножом, делаем аборт вполне здоровому ребенку…

Что же делать?

Если есть возможность, то нужно сделать следующее:

1. Привести себя в порядок. Как? Сбросить часть двигательной и эмоциональной энергии, разрядить.

2. Подождать в спокойной обстановке хотя бы 20 минут – это то время, которое необходимо организму для снижения уровня «химии» в мозгу и теле. Само собой станет легче и мысли станут стройнее. Ведь вы в стрессе никуда не теряете свой интеллект, опыт и знания. Они просто временно «не доступны» в полном объеме.

3. Действовать, стараясь оградить себя от новых, индуцированных стрессов, типа орущего начальника «Когда_уже_все_будет_всех_уволю!» или ноющих пользователей.

Если промедление невозможно, то и в этом случае можно себе помочь. Как?

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

2. Не предпринимайте поспешных решений «сначала сделаю, потом разберусь». Это как правило самое опасное и усугубляет проблему.

3. Постарайтесь привлечь еще кого-то знающего. Техника «4 глаза» дает хорошие результаты по недопущению ухудшения состояния «больного»

4. Используйте инструкции. Их писали не дураки и в спокойной обстановке.

Но в любом случае все это требует навыков. Работы с собой и деятельности в стрессе. Этому можно научить и научиться. Это ваш вклад в стабильность того мира, в котором мы живем и зависим от ИТ-систем!

Спасем мир от безумного админа!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Brackets для сомневающихся и новичков

СД: НЧ

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

Введение

Не так давно на Хабре было опубликовано множество статей, касающихся тем или иным образом редактора Brackets. У многих людей сразу же появились вполне справедливые вопросы:

1. Чем он лучше используемого мной %EDITOR_NAME%?


2. Много ли под него плагинов?


3. Стоит ли связываться или лучше использовать какую-нибудь известную IDE или текстовый редактор?

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

Функционал «из коробки»

Хоть Brackets и позиционируется как текстовый редактор, по факту он всё больше напоминает полноценную IDE. Тем не менее, следует сказать о том, что мы получаем при базовой установке этого редактора:

• плагин для Live Preview — работает только с Google Chrome. Вносим какие-либо изменения в код в редакторе — в окне браузера автоматически отображаются изменения


• подсветка синтаксиса


• подсказки при редактировании CSS, JS и HTML-файлов


• корявое отображение кириллического текста. Обещают исправить в одном из следующих релизов. Сейчас есть несколько обходных путей, об этом ниже.

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

Brackets из коробки

Общего назначения

Extensions Rating

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

До и после

Brackets Git

Тут всё предельно ясно из названия. Очень полезное расширение для работы со всем известной системой контроля версий.

Git в Brackets

Code Folding

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

Сворачивание кода

Emmet

В представлении не нуждается, но для новичков будет интересно о нём узнать. Этот плагин позволяет существенно ускорить ввод текста при редактировании LESS, CSS и HTML.

Например, вводим такую конструкцию:

button.btn.btn-primary{Кнопка}

После нажатия клавиши Tab она будет развёрнута в такую:

Идём дальше:

div.btn-toolbar>(button.btn.btn-default{Кнопка})*3

по нажатию развернётся в

Не буду делать дальнейших спойлеров, лучше почитайте уже имеющиеся на Хабре обзоры:

Прощай, Zen Coding. Привет, Emmet!

Вышел Emmet v1.0

Также рекомендую официальную инструкцию (на английском).

Codeoverview

Включает небольшую панель в правой части окна редактора, где отображается весь код «с высоты птичьего полёта». Можно быстро перейти к любому интересному участку.

Помимо плагина CodeOverview есть также BluePrint в стадии Beta. Какой лучше — решайте сами.

Обзор кода

Documents Toolbar

Для тех, кто привык к вкладочному интерфейсу и не хочет от него отвыкать (взамен Brackets предлагает список открытых файлов над деревом).

Brackets Fonts

Позволяет выбрать из списка шрифт, которым будет выводиться текст в редакторе. Обратите внимание на то, как стали отображаться кириллические символы. Кроме этого есть ещё несколько плагинов с таким же функционалом. Имеется возможность открыть в меню пункт Вид/Themes, где вручную прописать, какие шрифты следует использовать.

Шрифты

Http Server for Brackets

Запускает локальный HTTP-сервер для отладки вашего проекта. В чём отличие от встроенного Live Preview?

1. Это не LivePreview, т.е. страницу надо обновлять вручную.


2. Обратиться к данному серверу можно из любого браузера, установленного в системе. Разработчики под IE и Firefox ликуют.

Также в каталоге расширений есть плагин Static Preview, подобный LivePreview, но позволяющий делать «живую» правку в других браузерах, однако на текущий момент (8 ноября 2014 года) он «вешает» Brackets. Если быть более точным, он не даёт редактору возможности нормально завершить свою работу — сохранить настройки и список открытых файлов. Возможно, эту ошибку скоро исправят, но имеющиеся проблемы лично меня уже оттолкнули от этого плагина.

Grunt for Brackets

Brackets может предложить плагин для Grunt'а. Его настройка — отдельная тема, некоторые даже целые книги написали об этом. От себя замечу лишь, что сейчас, в 2014 году, не использовать Grunt или Gulp — признак дурного тона и несерьёзности разработчика.

Beautify, Beautifer

Простым нажатием комбинации клавиш Ctrl+L или Ctrl+B плохо оформленный JS- или HTML-код превращается в оформленный вполне приемлемо. На картинках global_main.js Хабра до и после применения данного плагина. Не используйте эти плагины для LESS! Они вставляют пробелы после двоеточий, что делает LESS-файл некомпилируемым.

Ассистент, всё в мясорубку!

QuickSearch

При двойном клике на выражение подсвечивает все его вхождения в документ. Автор расширения вдохновлён Notepad++, чего не скрывает.

Notepad++? Нет.

SFtpUpload, FTP-Sync

Позволяют выгружать файлы проекта на сервер через (S)FTP. Умеют в авторизацию по ключу.

FTP Sync, SFtpUpload

Верстальщику

LESS Autocompile

Для тех, кто не хочет головной боли от правки CSS давно придуман LESS. Данный плагин позволяет автоматически компилировать ваши .less-файлы при сохранении. В текущем состоянии требует небольшой настройки.

Brackets Autoprefixer

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

Минимализм настроек Autoperefixer

CSSLint, LESSLint, LESS StyleSheets Formatter

Три плагина, призванные помочь в улучшении вашего LESS- и CSS-кода. Будут указывать на типичные и не очень ошибки. Пример на картинке.

Ошибки в CSS

HTMLHint, More CSS Code Hints, More HTML5 Code Hints

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

ColorHints, Brackets Color Picker

Первый выводит подсказку при наведении курсора на код или название цвета в редакторе, умеет также показывать градиенты. Второй выводит окошко с палитрой для выбора нужного цвета. При редактировании LESS-файлов окошко для выбора цвета следует вызывать по Ctrl+Alt+K, если оно не появилось автоматически после ввода слова color.

Подсказки при вводе градиентов и цвета

JavaScript-разработчику

JSHint, JSLint, JSHint Configurator, JSLint Configurator

Крайне полезные плагины для разработчиков, которые не только верстают, но и пишут код на JavaScript. На выбор JSHint и JSLint, хотя можно использовать оба (второй куда более предвзято отнесётся к вашему коду). Конфигураторы, как видно из названия, позволяют настроить разные параметры проверки кода, например, игнорировать использование функции requirejs до её объявления.

Все и так знают, для чего нужен каждый из параметров

FuncDocr

Плагин позволяет быстро документировать функции JS.

Например, имеется следующий код:

Desktop.prototype.addResizeHandler = function(handler) {
    if ($.isFunction(handler)) {
        this.resizeActions.push(handler);
    }
};

Становимся перед объявлением функции и вводим /**. После нажатия клавиши Enter FuncDocr развернёт этот комментарий, подставив заготовки, куда надо лишь вписать нужное:

/**
 * [[Description]]
 * @param {[[Type]]} handler [[Description]]
 */
Desktop.prototype.addResizeHandler = function(handler) {
    if ($.isFunction(handler)) {
        this.resizeActions.push(handler);
    }
};

AngularJS Code Hints, AngularJS for Brackets

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

Rename JavaScript Identifier

Становимся на идентификатор, нажимаем Ctrl+R, вводим новое имя — все вхождения переменной в скрипт автоматически переименовываются.

Ложка дёгтя

При всём многообразии настроек и параметров, есть некоторые претензии к Brackets. Первая и самая важная — скорость работы. При наличии большого количества плагинов и множестве подключенных к документу CSS начинает довольно заметно подтормаживать появление подсказок при редактировании документов. Иногда довольно долго приходится ждать реакции редактора при правке JS-скриптов. Второе — довольно неудобное дерево навигации. Третье — некоторые плагины способны «повесить» редактор, не давая ему нормально закрыться и сохранить настройки.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Минимализм Objective-C

Я часто пишу небольшие тестовые проекты на Objective-C, чтобы поэкспериментировать или поиграться с чем-нибудь. Обычно, я помещаю код в main.m и избавляюсь от всего остального:

#!/usr/bin/env objc-run
@import Foundation;

@implementation Hello : NSObject
- (void) sayHelloTo:name
{
    printf("Hello %s, my address is %p\n", [name UTF8String], self);
}
@end

int main ()
{
    id hello = [Hello new];
    [hello sayHelloTo:@"sunshine"];
}

Это полноценный проект из одного файла, готовый к выполнению. Под катом — описание приемов, позволивших прийти к данному минимализму.

• Все пишется в main.m. Или “Test.m”, или что угодно. Функция main() может находиться в любом файле.


• Используем objc-run. Если вы еще не сталкивались с ней, objc-run — прекрасная утилита, которая “позволяет легко использовать файлы Objective-C в качестве консольных скрипто-подобных задач”. Установите ее: brew install objc-run и добавьте права на выполнение вашему исходному файлу: chmod u+x main.m


• Модули вместо предкомпиленных заголовков. Возможно, есть смысл в #imports и PCH в больших проектах, но для маленьких тестовых программ? Нет уж.


• Никаких объявлений @interface Я случайно узнал, что ObjC позволяет указывать суперкласс прямо в директиве @implementation. Не совсем понятно, с какой целью это допущено, но это позволяет полностью избавиться от блока @interface.


• Неявные типы параметров функций. Возвращаемые типы и параметры методов ObjC неявно равны (id), что значит
  
  -(id)doSomethingWith:(id)param; это абсолютно то же самое, что и -doSomethingWith:param; но второй вариант выглядит удобнее.


• Никаких аргументов в main(). Хотя это считается плохой практикой, вполне допустимо писать void main () вместо int main (int argc, char**argv). Зачем это все объявлять, если вы все равно не пользуетесь этими аргументами?


• Избавляемся от return в main(). Начиная со стандарта C99, при возвращении управления от main() без оператора возврата — считается, что было вызвано return 0;


• printf вместо NSLog. NSLog — для сообщений об ошибках, а не для вывода текста — мне не нужно выводить путь к выполняемому файлу и ID потока на каждой строчке.

Примечание переводчика: при отсутствии @interface меня раздражает вывод warning:

/dev/fd/63:3:17: warning: cannot find interface declaration for 'Hello'
@implementation Hello : NSObject
                ^
1 warning generated.

Это warn_undef_interface, для которого нет соответствующего флага -W (для заглушения предупреждений по типам). Так что для себя я оставил пустой интерфейс.

#!/usr/bin/env objc-run
@import Foundation;

@interface Hello : NSObject
@end

@implementation Hello
- (void) sayHelloTo:name
{
    printf("Hello %s, my address is %p\n", [name UTF8String], self);
}
@end

int main ()
{
    id hello = [Hello new];
    [hello sayHelloTo:@"sunshine"];
}

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Уютный книжный пост для вас и вашего проекта

Как заработать миллион за день, стать искусным оратором за неделю, похудеть на 100 кг за 2 дня, стать успешным в тысяча ста начинаниях и прочая мишура регулярно засоряет наше информационное пространство. А порой так хочется взять в руки книгу, которая не просто съест кусок вашего свободного времени повествуя о неприменимых в отечественных реалиях вещах, но и подкинет хотя бы несколько полезных советов, способных оказать позитивное влияние на развитие вашей личности и вашего проекта.

Если вы хотите найти и/или поделиться хорошими книгами, добро пожаловать под кат.

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

Немного об эффективном общении

• Как вырабатывать уверенность в себе и влиять на людей, выступая публично — Дейл Карнеги
  

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

  
  


• Психология общения — Вердербер Рудольф и Кейтлин
  

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

  
  

На заметку стартаперу

• Стартап за $100 — Крис Гильбо
  

  По-моему мнению, достаточно водянистая книга, тем не менее, есть масса интересных примеров по увеличению эффективности проектов из разных сфер, полезные заметки о ценообразовании, добавлениях премиум версий, хорошее объяснение цели FAQ-страницы и пару хороших хаков (например, о нестандартных гарантиях возврата средств, которые могут существенно повысить выхлоп проекта)

  
  


• Стартап. Настольная книга основателя — Стив Бланк, Боб Дорф
  

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

  
  


• The Gamification Revolution: How leaders leverage game mechanics to crush the competition — Gabe Zichermann and Joselin Linder
  

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

  
  

Маркетинг, позиционирование

• Маркетинговые войны — Джек Траут и Эл Райс
  

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

  
  


• Позиционирование. Битва за умы — Джек Траут и Эл Райс
  

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

  
  


• Партизанский маркетинг. Добро пожаловать в маркетинговую революцию — Джей Конрад Левинсон
  

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

  
  


• Breakthrough Advertisement — Eugine Schwartz
  

  Еще одна книга, которую судя по всему можно прочитать только на английском. Отличное пособие по написанию разнообразных рекламных текстов, начиная от печатной рекламы, заканчивая грамотно сформированной email-подписке и посадочной странице. Множество примеров, полезных советов, интересных кейсов по увеличению конверсий. Несмотря на то, что есть много «российских» аналогов, по-моему мнению, это одна из лучших книг для людей, которые занимаются копирайтерством, ведением стартапов, формированием рекламных обращений.

  
  


• Огилви о рекламе — Дэвид Огилви
  

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

  
  

Еще несколько полезных книг

• Супермышление — Тони Бьюзен
  

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

  
  


• Монах, который продал свой Феррари. — Шарма Робин
  

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

  
  


• Рождение новой идеи — Эдвард де Боно
  

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

  
  


• Психология влияния — Роберт Чалдини
  

  Стоит прочитать каждому. Книга откроет глаза обывателям на то, как ими манипулируют различные вымогатели денег, начиная от «волонтеров» по сбору благотворительности и прочих сект, заканчивая розничными магазинчиками и крупными торговыми сетями.
  
  В то же время, маркетологи, владельцы бизнеса различных масштабов и просто смышленые ребята могут успешно применять описанные стратегии себе на благо.

  
  


• Сила привычки — Чарльз Дахигг
  

  Несмотря на то, что я читал её в английском варианте (Charles Duhigg — The Power of Habit), по идее, она так же существует в русском варианте. На Хабре даже был о ней пост. Просто безумно клёвая книга о том, как «работают» наши привычки, о том, как с ними бороться. Ну и особенно о том, как их навязывать вашим потребителям/подчиненным. Эта книга также будет полезна широкому кругу читателей.
  

  
  

У меня пока всё, но в то же время, я был бы безумно вам благодарен за любые советы/дополнения/комментарии. И не забывайте делиться хорошими книгами.

Удачи!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

«ИТ-театр» из бетона и зелени

Испанская финансовая группа Santander – финансовый лидер в Еврозоне и третий по величине частный банк в Бразилии – открыла в Кампинасе, штат Сан-Паулу, дата центр стоимостью почти 500 млн американских долларов. ЦОД в Кампинасе занимает 800 тыс квадратных метров и служит для обработки и размещения данных корпорации. Он спроектирован таким образом, чтобы сочетать в себе высокую скорость обработки данных, высокую устойчивость системы, безопасное размещение данных, и возможность внедрения новейших технологий.

Дата центр в Кампинасе увеличил в 3 раза физическое пространство объектов, которые хранят оборудования, отвечающего за операции Santander. Мощности позволяют хранить более 5 петабайт информации и способны обеспечить проведение более 210 млн транзакций в день. Инфраструктура позволит банку удовлетворить ожидаемый растущий спрос на его услуги, а также даст возможность мониторить все операции в Латинской Америке. Мощности ЦОДа способны разместить до 9 тыс виртуальных серверов.

Проект в Кампинасе получил сертификат уровня отказоустойчивости Tier IV от Uptime Institute. Комплекс состоит из двух идентичных зданий, соединенных между собой для еще большей надежности. Каждый блок достигает площади 25 тыс квадратных метров, имеет три этажа, два из которых расположены частично под землей. Грунт выбранный в процессе строительства, был помещен обратно после завершения работ, что позволило строениям органично вписаться в окружающую среду. Стены и перекрытия усилены и способны выдержать вес верхних этажей в случае обрушения.

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

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

Здания дата центра представляют собой два независимых энергетических комплекса и блок запасных генераторов, позволяющих обеспечить бесперебойную работу. Если вдруг основное обеспечение будет прервано, комплекс сможет работать на полную мощность еще 4 дня без дозаправки генераторов. В свою очередь электрические генераторы не содержат свинцовых батарей, а вода, которая сконденсировалась в системе охлаждения используется на нужды ЦОДа. Система озеленение ЦОД способна восстанавливать массу растительности, а система подъездных каналов адаптируется к логистических потребностей комплекса.

Это первый дата центр Santander в Бразилии, созданный в дополнении к существующим площадкам. Также есть два объекта в Испании, и по одному в Великобритании и Мексике. Santander обратился в Совет по экологическому строительству (Green Building Council) за сертификатом LEED Gold и имеет все шансы его получить.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Карьера менеджера проекта vs организация

В предыдущей статье «Медовый месяц менеджера: как его провести с пользой» мы говорили о том как происходит назначение на позицию менеджера и что может делать новый менеджер первые месяцы работы в должности. Давайте продолжим разбираться в этой теме.

Нужно ли расти из технического специалиста или целенаправленно, с нуля учиться на менеджера? Смогу ли я управлять коллективом, не умея выполнять задания, которые я даю своим сотрудникам? Что ждет меня через 3-5-7 лет? Что предпринять сейчас, чтобы приблизиться к собственной мечте (и какова вообще она — карьерная мечта руководителя проектов)?

Я больше 10 лет занимаюсь проектным менеджментом и такие вопросы слышу часто (да что там — задаю их и сам себе). Единственно-верных ответов, конечно, не существует, а вот собственными соображениями я поделиться могу.

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

Мы знаем, примеры есть. Однако, когда и почему такие переходы оказываются успешны — ответить затрудняемся.

Часто работодатели не ограничиваются в вакансии требованиями к знаниям проектного управления и общему стажу, а обязательно требуют релевантный опыт (например — 5 лет в управлении разработкой сайтов или внедрения ERP и т.п.). Сами менеджеры тоже стараются строить карьеру с таким прицелом, чтобы развиваться в наиболее симпатичной области. Но это на уровне интуиции. А можно ли подвести под нее какие-либо правила?

Мой ответ: можно. И не самые очевидные.

Я попытаюсь порассуждать на тему карьеры руководителя проектов: что она собой представляет и как меняется в зависимости от типа компаний, с которыми может свести судьба. Существенное место в моих рассуждениях займет классификация от Генри Минцберга, о которой подробнее скажу ниже.

Чтобы говорить о карьере менеджера, позвольте мне предложить хоть какое-то понимание сути его работы и критериев ее эффективности.

В самом деле, когда мы говорим о софтверном разработчике – все (на первый взгляд) гораздо понятнее. Хороший разработчик отличается от плохого хотя бы тем, что в более короткий срок создает более качественный продукт (в самом широком смысле — соответствия требованиям или ожиданиям, устойчивости и масштабируемости архитектуры продукта и т.п.). Я не хочу создавать серьезных споров, отмечу лишь, что разработчик делает продукт (софтверный), он делает его не для себя, а значит то, каким качественным и быстрым оказался результат — всегда можно проверить.

С менеджером немного сложнее. Он занимается чем-то, что гораздо трудней померить, а результат — всегда зависит не от него одного. Он сам, как правило, не производит ничего материального (кроме диаграмм Ганта или стикеров на Канбан-доске, да каких-нибудь актов приемки-передачи, если таковые на проекте нужны). Посему задача «отличить плохого менеджера от хорошего» отнюдь не является простой (в то время как ответ — критично важен для любого карьериста — к чему стремится, что показывать работодателю, какие качества и навыки развивать, чтобы рассчитывать на незаурядный профессиональный рост)?

Наверняка у вас уже есть простые ответы.

Например: «хороший менеджер закрывает проекты в срок и в бюджет», или «у хорошего менеджера довольный заказчик» или «хороший менеджер закрывает проекты с меньшими отклонениями, чем коллеги», или «хорошей менеджер — лидер» и т.п. Опять же, не буду спорить. Скажу лишь, что по моему опыту работает два принципа, которые все эти простые ответы немного нивелируют. Первый — «кто везет — на том и едут» (т.е. стоит менеджеру проявить себя, как ему начинают поручать более сложные проекты, рисковые задачи, подсовывать особо трудных клиентов и т.п. и в итоге его показатели завершения проектов «проседают», по сравнению с коллегами, хотя внутри компании все помнят — Егор работает на невероятно трудных задачах, он крутой). С другой стороны, проектный менеджмент — это всегда много коммуникаций и иногда — немного политики, а посему использование трудно измеримых показателей (типа менеджер проектов — «лидер») приводит к вкусовщине, и лучшими признаются те, кто громче и складнее говорит и к тому же лучше строит отношения, причем больше с менеджментом, чем с командой.

Тут я предложу немного пофилософствовать. Давайте сделаем шаг назад и попытаемся окинуть взглядом всю профессию проектного менеджера в целом, а уже потом снова вернуться к критериям, отделяющих «плохих» от «хороших».

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

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

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

Где сегодня мы чаще слышим о проектах?

— сфера информационных технологий (ИТ в самом широком смысле)

— строительство

— развитие бизнеса

— медиа-деятельность (да, телепроект «Дом-2» и иже с ним)

— кое-где в научных кругах

— и т.п.

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

Есть ли что-то общее у этих сфер – сравнительно молодого ИТ, гораздо более взрослого «медиа» и совсем уж древних по своему происхождению науки и строительства? Хотя бы то, что Генри Минцберг называл «внешней средой» для компании. В обоих случаях она, эта среда, оказывается в современных условиях – «сложной» и «динамичной». «Сложная» — значит сама компания со всеми имеющимися ресурсами интерпретирует свои задачи как тяжелые, трудно-постижимые, труднообъяснимые. «Динамичная» — значит, что постоянно приходится реагировать на принципиально новые запросы клиентов, осваивать новые технологии, учитывать другие драматические технологические и не только новации. О теории Минцберга мы еще скажем.

Зафиксируем тезис.

Проектное управление — это реакция на неумение систематически добиваться положительного результата.

Кстати, именно поэтому отчеты типа «Chaos report», говорящие, что не меньше трети всех проектов в ИТ проваливаются — отражают причину, а не следствие. Дело не в том, что менеджеры проектов повально и сплошь безрукие неумехи, но в том, что именно эти менеджеры принимают самые сложные вызовы в современном управлении. Вольно перефразируя Черчиля о демократии, «управление проектами не очень эффективно, но ничего лучшего человечество сейчас придумать не смогло».

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

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

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

Так чего же ждут на самом деле от руководителя проектов? Зачем приглашают его на «проекты»? Уж точно не ради рассказа и внедрения проектных методологий, нарисованных диаграмм Ганта или расклененных стикеров на Канбан-доске, не ради харизмы и красноречия.

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

Сведем это к универсальным терминам: «эффективность» и «конкурентоспособность».

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

Никто не любит проектное управление «за красивые глаза». Бизнес и прочие структуры интересует лишь рост эффективности и конкурентоспособности. В сфере ИТ есть немало фирм, управляющих своей работой по принципам, утвержденным в 70-х, и это сильные игроки. У них своя специфика, никакого проектного управления им не надо (и не вздумайте предлагать). В том же строительстве есть подход, альтернативный управлению проектами (создание не команд, а жестко регламентированных и взаимодействующих по шаблонам «служб» или «управлений»), который имеет право на жизнь и в некоторых случаях более успешен.

Фиксируем второй тезис.

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

Это очень конкретные показатели. Их можно и нужно измерять (в каждой отрасли по-своему, но всегда однозначно).

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

Нужно больше конкретики.

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

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

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

Используем классификацию Генри Минцберга (сформулированную в его книге «Структура в кулаке») для того, чтобы понять, в каких компаниях может оказаться менеджер проекта, на какие ожидания ему там, внутри, придется равняться и, в конечном счете, какие формы может принять, в результате, его карьера.

Ниже я изложу суть теории Минцберга очень кратко и своими словами (намеренно опуская многочисленные нюансы). Для наглядности сопровожу иллюстрациями — предупреждаю, отдельные картинки, на первый взгляд, кажутся неприличными.

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

Простая компания

Многие компании начинаются как маленький «стартап» — один основатель и несколько единомышленников, составляющих так называемое «операционное ядро». Этот тип называется «простая компания». Она демократична насколько это возможно. Но вся полнота власти — в руках основателя (он, в конечном счете, «узкое место» всей системы). В компании пока нет ничего лишнего.

Рисунок 1 — Простая компания

Механистическая бюрократия – власть стандартов и менеджеров

Затем компания растет. Например, таким образом: расширяется количество сотрудников (к примеру, инженеров), т.е. увеличивается операционное ядро. Основатель-собственник уже не справляется и приходят первые менеджеры.

По мере того, как фирма растет — менеджерская прослойка увеличивается. Она утолщается ближе к ядру (начальники секторов, отделов, департаментов), а тоньше — к «голове».

Со временем в компании появляются и два своеобразных довеска (на графике — в виде осьминогов). Они не относятся явно ни к тем, кто производит (инженеры и другие сотрудники ядра), ни к тем, кто командует (менеджерская прослойка и голова). Они как бы «сбоку». Один довесок — это всевозможные вспомогательные службы, неизбежно разрастающиеся при развитии фирмы: бухгалтерия, кадры, юристы, хозяйственники и прочие (на схеме — грустный осьминог).

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

Рисунок 2 — Механистическая бюрократия

То, что мы описали сейчас, сам Минцберг называл «Механистической бюрократей» и относил к не самым человечным формам организаций (т.к. там особенно рядовые сотрудники в наибольшей степени подвержены демотивации и выгоранию). Яркий пример — завод по сборке автомобилей (по сборке, а не по изобретению). Деятельность основной массы сотрудников — простая и жестко регламентированная (конвеер). Начальники, в первую очередь, следят за соблюдением инструкций и регламентов, которые заботливо создает и уточняет один из «осьминогов». Стратегические решения принимаются в голове компании и, если надо, спускаются сверху вниз. Обратите внимание, такие компании нацелены на стандартизацию процесса работы (и сами эти стандарты описывают). Механистические бюрократии неповоротливы и очень хорошо себя чувствуют в простой и стабильной среде (и завтра, и послезавтра, и через 5 лет процедура сборки автомобилей едва ли существенно изменится, так что подобные заводы будут процветать).

Профессиональная бюрократия — власть специалистов

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

Пример — работа врача.

Каждый доктор — профессионал в своем деле. Если кто и контролирует доктора — то не столько начальник, сколько старшие товарищи (интерна опекают полноценные доктора, за докторами присматривают профессора на отделении).

Большую часть времени доктор работает на отделении один на один с пациентом. В сложном случае он может просить совета, но в целом — должен сам принимать решения. Тем более нелепо предположить, что глава клиники будет давать ему указания. На Западе клиниками чаще рулят управленцы, в России — это, почти всегда, бывшие врачи. Но и в российских реалиях, главный врач едва может охватить свою собственную бывшую специальность (например, кардиологию), и отнюдь некомпетентен в контроле, скажем, хирургов (заявляю ответственно, как бывший хирург).

Вот и получается, что для эффективной работы компания (в нашем примере — больница) перестраивается. Растет операционное ядро, растут и полномочия его сотрудников.

Растет вдогонку вспомогательный аппарат (грустный осьминог), т.к. должен обслуживать разнообразные потребности профессионалов — закупки бинтов, каталок, выставление счетов и т.п…

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

Рисунок 3 — Профессиональная бюрократия

Менеджерская прослойка сжимается за ненадобностью (даже в России доктора от главврача крупнейшей больницы отделяет всего 2-3 ступени: заведующий отделением, начмед, да какой-нибудь «зам. глав врача по лечебной работе»). Функции же головы компании также невелики и сводятся больше к администрированию. Очень многие запросы, в конечно счете определяющие стратегию больницы, идут снизу — доктора выходят с инициативами о закупке оборудования, лекарств, потребностях в новых коечных мощностях, а менеджеры и высшие руководители их интерпретируют и иногда претворяют в жизнь. Такую форму организации Минцберг называет «Профессиональная бюрократия». Она достаточно устойчива в сложной, но стабильной среде. Сложность предопределяет требования к профессионализму (мы не знаем, с чем придет пациент завтра и послезавтра, доктор должен уметь многое и научиться этому еще до прихода к нам — в этом отличие от рабочего у конвейера, которого мы можем чуть не с нуля научить сами). Но сама среда довольно стабильна (больница знает, какие болезни вообще существуют в природе, что ей в принципе может понадобиться сегодня-завтра-всегда) и при наличии профессионалов в штате и денег на счетах — готова справиться с любым адекватным вызовом.

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

Ну, а в какой же компании менеджеру живется лучше всех?

Ответ — ни в какой.

Давайте вспомним, что каждый вид компании формируется естественным образом в своей среде.

Простая — в простой, динамичной среде

Механистическая бюрократия — в простой, стабильной среде.

Профессиональная бюрокартия — в сложной, стабильной среде.

Чего-то не хватает, правда?

Да, именно, самого экстремального варианта: сложной, динамичной среды.

Т.е. такой, где навыки специалиста стандартизовать нельзя (как и в примере с врачом). Но при этом, сама среда очень изменчива. Сегодня клиент просит одно, завтра — что-то совершенно другое, приходится постоянно применять новые технологии и делать то, чего мы никогда доселе не делали, не умеем спланировать, не можем оценить.

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

В такой ситуации, с точки зрения Минцберга — компания будет превращаться в Адхократию (от латинского «Ad hoc» — по запросу»). Системы «созвездий», т.е. самых разных людей самой высокой квалификации буду собираться вместе, чтобы сообща ответить на вызов внешней среды. Руководить ими будет не «начальник-в-кабинете», а, в каком-то смысле, гораздо более близкий к ним человек. Тот, кто не увязает в формализме, способен общаться с каждым членом команды непосредственно и адекватно, при этом не являться специалистом во всех аспектах (это невозможно — деятельность слишком сложная). При этом такой менеджер будет держать в голове глобальную цель и «интегрировать» (т.е. соединять в единое целое) всех участников, добиваться чтобы их усилия по возможности были направлены на общий результат, а не в стиле «лебедя, рака и щуки». Да-да, вот и появился классический менеджер проекта.

Адхократия — власть профессиональных созвездий, Родина менеджера проектов

На что похожа такая структура? Она чем-то напоминает простую, но происхождение ее отлично. Операционное ядро очень значимо (хотя, в некоторых случаях может состоять, скажем, из outsource-команды). Менеджер проекта погружен в него, но в то же время не теряет связи и с вышестоящими руководителями. Менеджерская прослойка сокращается (в ней нет нужды, результат, как и в примере с врачами, создается ниже этажом). Вспомогательный аппарат вливается в менеджера проектов и ядро (в самом деле, как часто менеджер проекта держит руку на пульсе в заключении контрактов, прохождении платежей, выверке соглашений, подписании актов и т.п.?). Стандартизация в полной мере невозможна (иначе она бы давно произошла) и тоже сочетается с работой менеджера проектов и ядра. Здесь всевозможные службы качества, здесь проектные методологии, которые здорово помогают, но никакой панацеей, в отрыве от людей, не являются.

Рисунок 4 — Адхократия

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

Только что, при помощи Г. Минцберга мы сделали большой шаг — свели все компании к четырем основным типам (на самом деле, у автора их чуть больше, но сути это не меняет).

Можем ли мы теперь, как и намеревались, смоделировать обстановку, ожидания и возможный карьерный путь менеджера проектов в каждой из них?

Уверен, определенные соображения у вас уже возникли. Иные — потребуют широких дискуссий. Мне же не остается ничего более, как сообщить тут свое субъективное мнение и поделиться личными наблюдениям за своей и чужими карьерами за последние 10 лет. Сделаю это по возможности кратко и приглашу поделиться собственными примерами в комментариях.

Итак, работа и карьера.

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

Куда растут менеджеры проектов? Это почти готовые бизнесмены. На мой взгляд, в таких компаниях хорошо людям (по выражению Натальи Касперской «с повышенным уровнем внутренней агрессии»), людям немного авантюрным и нацеленным на творчество, риск и большой успех. Иногда простые структуры выстреливают и пополняют зал славы, а менеджеры — вливаются в ряды пожинающих большой успех (но, кстати, тоже не всегда). Гораздо чаще — простые структуры увядают (такова судьба едва не 99% стартапов). Но очень многие мои знакомые менеджеры, выходцы из таких структур, ищут себя как предприниматели. К тому же умелые менеджеры из простых структур — обычно, очень хорошие продавцы (и порой делают карьеру, дорастая до коммерческих директоров или специалистов по развитию бизнеса).

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

Куда растут менеджеры проектов?

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

Профессиональные бюрократии. Эти компании нацелены на то, чтобы повседневно «делать свое дело». Тут царит абсолютная власть профессионалов, а менеджер в наибольшей степени рискует оказаться бесполезным и бессильным. Можно сказать, что менеджеру-не-выходцу из профессиональной среды освоится в таких фирмах очень трудно. Пытаясь ответить на вопрос «как я повышу эффективность и конкурентоспособность», он, то стремится овладеть нужным набором экспертных знаний, чтобы выдерживать дискуссию коллег (обычно, безуспешно), либо становится «нянькой» своей команде (фактически, уподобляясь вспомогательному осьминогу). С точки зрения руководства (да и менеджера проектов в частности) профессиональная бюрократия часто не выглядит управляемой системой вообще и менеджера кидает в крайность. Он пытается придумать систему контроля, ввести показатели, как-то формализовать работу команды (что, как мы помним, практически невозможно). Отсюда появляются разные извращения. Например, «палочная» система в работе полиции, когда вместо охраны правопорядка успешным считается полицейский, схвативший за месяц нужное количество преступников, лично раскрывший пару преступлений, а также предотвративший 1 ДТП — типичный пример неразумного и нерационального вмешательства менеджмента. Печальные последствия — широко известны. Менеджеры проектов (если не являются выходцами из той же специальности, что и их подчиненные коллеги) — часто быстро выгорают. Выходцы же — нередко чувствуют себя очень комфортно, их роль из руководителя порой превращается просто в «лида» (того самого старшего товарища, мнению которого доверяют). Часто такие менеджеры предпочитают горизонтальный рост.

Адхократии. Эффективность и конкурентоспособность — это выпуск нужного продукта (услуги) в срок заданными ресурсами. Команда адхократии должна превосходить в этом любую другую форму, иначе невозможно оправдать существование такой формы организации (неустойчивой и требующей очень грамотных управленцев). Команда адхократии строится на коммуникациях, в этой форме они особенно дороги. Потому особо важна способность менеджера проектов быть убедительным, внимательным, уверенным в себе, внятным, говорить доходчиво для всех, уметь вскрывать и управлять конфликтами и т.п. При этом, одними разговорами работа не делается, а при большом размере команды (тем более — при работе с распределенной командой) особую важность приобретают методологии. Они должны быть адекватными потребности — сложными настолько, насколько это оправданно, позволять команде видеть реальную ситуацию по проекту, менеджеру — эффективно планировать и контролировать проект, а не пассивно ждать «у моря погоды», и при этом не слишком всех отвлекать от работы. Быть профессионалом во всех тех же областях, что и члены команды менеджеру — не нужно (да и невозможно), куда важнее способность «объединять» команду в единое целое, направлять и поддерживать в стабильном состоянии.

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

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


• эффективность и конкурентоспособность — то, что проектное управление должно привносить в компанию


• профессия «менеджера проектов» — не устоявшееся понятие, аспекты карьеры (обязанности, возможности, перспективы) зависят, в том числе, от типа компаний, с которыми конкретный руководитель связывает свою работу


• не во всех компаниях востребованы руководители проектов «в чистом виде»


• переходить между компаниями разных типов для менеджера проектов бывает труднее, чем сменить предметную область


• тип компании определяет не только то, какие качества и навыки с высокой вероятностью вы разовьете через N лет работы, но и то, как рынок в будущем станет вас воспринимать

Все сказанное, на какие бы теории не опиралось, является лишь субъективным мнением и не претендует истину в последней инстанции. За рамками статьи осталось влияние типа компании на подбор проектных методологий, надеюсь, описать это со временем. Буду рад, если статья оказалась полезной.

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

Именно об этом я и расскажу на своем вебинаре в среду 12 ноября в 20:00 МСК, который является частью большой онлайн-конференции PRO+ЛЮДЕЙ от Школы менеджеров Стратоплан.

Участие в конференции платное: 980 руб. за 5 мастер-классов. На момент публикации уже >360 человек уже стали участниками.

Вы ничего не пропустите: каждый, купивший билет на Онлайн-Конференции PRO+ЛЮДЕЙ, получит записи всех вебинаров.

Присоединяйтесь и бронируйте вечера следующей недели под себя.

Хорошего дня!

С уважением,

Иван Селиховкин

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Выразительный JavaScript: Поиск и обработка ошибок

Содержание

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

Брайан Керниган и П.Ж.Плауэр, «Основы программного стиля»

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

Мастер Юан-Ма, «Книга программирования».

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

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

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

Ошибки программистов

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

Разные языки по-разному могут помогать вам в поиске ошибок. К сожалению, JavaScript находится на конце этой шкалы, обозначенном как «вообще почти не помогает». Некоторым языкам надо точно знать типы всех переменных и выражений ещё до запуска программы, и они сразу сообщат вам, если типы использованы некорректно. JavaScript рассматривает типы только во время исполнения программ, и даже тогда он разрешает делать не очень осмысленные вещи без всяких жалоб, например

x = true * "обезьяна"

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

Но часто ваши бессмысленные вычисления просто породят NaN (not a number) или undefined. Программа радостно продолжит, будучи уверенной в том, что она делает что-то осмысленное. Ошибка проявит себя позже, когда такое фиктивное значение уже пройдёт через несколько функций. Она может вообще не вызвать сообщение об ошибке, а просто привести к неправильному результату выполнения. Поиск источника таких проблем – сложная задача.

Процесс поиска ошибок (bugs) в программах называется отладкой (debugging).

Строгий режим (strict mode)

JavaScript можно заставить быть построже, переведя его в строгий режим. Для этого наверху файла или тела функции пишется «use strict». Пример:

function canYouSpotTheProblem() {
  "use strict";
  for (counter = 0; counter < 10; counter++)
    console.log("Всё будет офигенно");
}

canYouSpotTheProblem();
// → ReferenceError: counter is not defined

Обычно, когда ты забываешь написать var перед переменной, как в примере перед counter, JavaScript по-тихому создаёт глобальную переменную и использует её. В строгом режиме выдаётся ошибка. Это очень удобно. Однако, ошибка не выдаётся, когда глобальная переменная уже существует – только тогда, когда присваивание создаёт новую переменную.

Ещё одно изменение – привязка this содержит undefined в тех функциях, которые вызывали не как методы. Когда мы вызываем функцию не в строгом режиме, this ссылается на объект глобальной области видимости. Поэтому если вы случайно неправильно вызовете метод в строгом режиме, JavaScript выдаст ошибку, если попытается прочесть что-то из this, а не будет радостно работать с глобальным объектом.

К примеру, рассмотрим код, вызывающий конструктор без ключевого слова new, в случае чего this не будет ссылаться на создаваемый объект.

function Person(name) { this.name = name; }
var ferdinand = Person("Евлампий"); // ой-вэй
console.log(name);
// → Евлампий

Некорректный вызов Person успешно происходит, но возвращается как undefined и создаёт глобальную переменную name. В строгом режиме всё по-другому:

"use strict";
function Person(name) { this.name = name; }
// Опаньки, мы ж забыли 'new'
var ferdinand = Person("Евлампий ");
// → TypeError: Cannot set property 'name' of undefined

Нам сразу сообщают об ошибке. Очень удобно.

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

Короче говоря, надпись «use strict» перед текстом программы редко причиняет проблемы, зато помогает вам видеть их.

Тестирование

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

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

Для примера вновь обратимся к типу Vector.

function Vector(x, y) {
  this.x = x;
  this.y = y;
}
Vector.prototype.plus = function(other) {
  return new Vector(this.x + other.x, this.y + other.y);
};

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

function testVector() {
  var p1 = new Vector(10, 20);
  var p2 = new Vector(-10, 5);
  var p3 = p1.plus(p2);

  if (p1.x !== 10) return "облом: x property";
  if (p1.y !== 20) return " облом: y property";
  if (p2.x !== -10) return " облом: negative x property";
  if (p3.x !== 0) return " облом: x from plus";
  if (p3.y !== 25) return " облом: y from plus";
  return "всё пучком";
}
console.log(testVector());
// → всё пучком

Написание таких проверок приводит к появлению повторяющегося кода. К счастью, есть программные продукты, помогающие писать наборы проверок при помощи специального языка, приспособленного именно для написания проверок. Их называют testing frameworks.

Отладка (debugging)

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

Иногда это очевидно. Сообщение об ошибке наводит вас на конкретную строку программы, и если вы прочтёте описание ошибки и эту строку, вы часто сможете найти проблему.

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

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

function numberToString(n, base) {
  var result = "", sign = "";
  if (n < 0) {
    sign = "-";
    n = -n;
  }
  do {
    result = String(n % base) + result;
    n /= base;
  } while (n > 0);
  return sign + result;
}
console.log(numberToString(13, 10));
// → 1.5e-3231.3e-3221.3e-3211.3e-3201.3e-3191.3e-3181.3…

Даже если вы нашли проблему – притворитесь, что ещё не нашли. Мы знаем, что программа сбоит, и нам нужно узнать, почему.

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

Размещение нескольких вызовов console.log в стратегических местах – хороший способ получить дополнительную информацию о том, что программа делает. В нашем случае нам нужно, чтобы n принимала значения 13, 1, затем 0. Давайте выведем значения в начале цикла:

13
1.3
0.13
0.013
…
1.5e-323

Н-да. Деление 13 на 10 выдаёт не целое число. Вместо n /= base нам нужно n = Math.floor(n / base), тогда число будет корректно «сдвинуто» вправо.

Кроме console.log можно воспользоваться отладчиком в браузере. Современные браузеры умеют ставить точку остановки на выбранной строчке кода. Это приведёт к приостановке выполнения программы каждый раз, когда будет достигнута выбранная строчка, и тогда вы сможете просмотреть содержимое переменных. Не буду подробно расписывать процесс, поскольку у разных браузеров он организован по-разному – поищите в вашем браузере “developer tools”, инструменты разработчика. Ещё один способ установить точку остановки – включить в код инструкцию для отладчика, состоящую из ключевого слова debugger. Если инструменты разработчика активны, исполнение программы будет приостановлено на этой инструкции, и вы сможете изучить состояние программы.

Распространение ошибок

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

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

Допустим, у вас есть функция promptInteger, которая запрашивает целое число и возвращает его. Что она должна сделать, если пользователь введёт «апельсин»?

Один из вариантов – вернуть особое значение. Обычно для этих целей используют null и undefined.

function promptNumber(question) {
  var result = Number(prompt(question, ""));
  if (isNaN(result)) return null;
  else return result;
}

console.log(promptNumber("Сколько пальцев видите?"));

Это надёжная стратегия. Теперь любой код, вызывающий promptNumber, должен проверять, было ли возвращено число, и если нет, как-то выйти из ситуации – спросить снова, или задать значение по-умолчанию. Или вернуть специальное значение уже тому, кто его вызвал, сообщая о неудаче.

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

Вторая проблема – работа со специальными значениями может замусорить код. Если функция promptNumber вызывается 10 раз, то надо 10 раз проверить, не вернула ли она null. Если реакция на null заключается в возврате null на уровень выше, тогда там, где вызывался этот код, тоже нужно встраивать проверку на null, и так далее.

Исключения

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

Код, встретивший проблему в момент выполнения, может поднять (или выкинуть) исключение (raise exception, throw exception), которое представляет из себя некое значение. Возврат исключения напоминает некий «прокачанный» возврат из функции – он выпрыгивает не только из самой функции, но и из всех вызывавших её функций, до того места, с которого началось выполнение. Это называется развёртыванием стека (unwinding the stack). Может быть, вы помните стек функций из главы 3… Исключение быстро проматывает стек вниз, выкидывая все контексты вызовов, которые встречает.

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

Пример:

function promptDirection(question) {
  var result = prompt(question, "");
  if (result.toLowerCase() == "left") return "L";
  if (result.toLowerCase() == "right") return "R";
  throw new Error("Недопустимое направление: " + result);
}

function look() {
  if (promptDirection("Куда?") == "L")
    return "дом";
  else
    return "двоих разъярённых медведей";
}

try {
  console.log("Вы видите ", look());
} catch (error) {
  console.log("Что-то не так: " + error);
}

Ключевое слово throw используется для выбрасывания исключения. Ловлей занимается кусок кода, обёрнутый в блок try, за которым следует catch. Когда код в блоке try выкидывает исключение, выполняется блок catch. Переменная, указанная в скобках, будет привязана к значению исключения. После завершения выполнения блока catch, или же если блок try выполняется без проблем, выполнение переходит к коду, лежащему после инструкции try/catch.

В данном случае для создания исключения мы использовали конструктор Error. Это стандартный конструктор, создающий объект со свойством message. В современных окружениях JavaScript экземпляры этого конструктора также собирают информацию о стеке вызовов, который был накоплен в момент выкидывания исключения – так называемое отслеживание стека (stack trace). Эта информация сохраняется в свойстве stack, и может помочь при разборе проблемы – она сообщает, в какой функции случилась проблема и какие другие функции привели к данному вызову.

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

Ну, почти.

Подчищаем за исключениями

Представьте следующую ситуацию: функция withContext желает удостовериться, что во время её выполнения переменная верхнего уровня context получит специальное значение контекста. После завершения выполнения, она восстанавливает её старое значение.

var context = null;

function withContext(newContext, body) {
  var oldContext = context;
  context = newContext;
  var result = body();
  context = oldContext;
  return result;
}

Что, если функция body выбросит исключение? В таком случае вызов withContext будет выброшен исключением из стека, и переменной context никогда не будет возвращено первоначальное значение.

Но у инструкции try есть ещё одна особенность. За ней может следовать блок finally, либо вместо catch, либо вместе с catch. Блок finally означает «выполнить код в любом случае после выполнения блока try”. Если функции надо что-то подчистить, то подчищающий код нужно включать в блок finally.

function withContext(newContext, body) {
  var oldContext = context;
  context = newContext;
  try {
    return body();
  } finally {
    context = oldContext;
  }
}

Заметьте, что нам больше не нужно сохранять результат вызова body в отдельной переменной, чтобы вернуть его. Даже если мы возвращаемся из блока try, блок finally всё равно будет выполнен. Теперь мы можем безопасно сделать так:

try {
  withContext(5, function() {
    if (context < 10)
      throw new Error("Контекст слишком мал!");
  });
} catch (e) {
  console.log("Игнорируем: " + e);
}
// → Игнорируем: Error: Контекст слишком мал!

console.log(context);
// → null

Несмотря на то, что вызываемая из withContext функция «сломалась», сам по себе withContext по-прежнему подчищает значение переменной context.

Выборочный отлов исключений

Когда исключение доходит до низа стека и его никто не поймал — его обрабатывает окружение. Как именно – зависит от конкретного окружения. В браузерах описание ошибки выдаётся в консоль (она обычно доступна в меню «Инструменты» или «Разработка»).

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

Если возникновение проблемы предсказуемо, программа не должна падать с необработанным исключением — это не очень дружественно по отношению к пользователю.

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

При входе в блок catch мы знаем только, что что-то внутри блока try привело к исключению. Мы не знаем, что именно, и какое исключение произошло.

JavaScript (что является вопиющим упущением) не предоставляет непосредственной поддержки выборочного отлова исключений: либо ловим все, либо никакие. Из-за этого люди часто предполагают, что случившееся исключение – именно то, ради которого и писался блок catch.

Но может быть и по-другому. Нарушение произошло где-то ещё, или в программу вкралась ошибка. Вот пример, где мы пробуем вызывать promptDirection до тех пор, пока не получим допустимый ответ:

for (;;) {
  try {
    var dir = promtDirection("Куда?"); // ← опечатка!
    console.log("Ваш выбор ", dir);
    break;
  } catch (e) {
    console.log("Недопустимое направление. Попробуйте ещё раз.");
  }
}

Конструкция for (;;) – способ устроить бесконечный цикл. Мы вываливаемся из него, только когда получаем допустимое направление. Но мы неправильно написали название promptDirection, что приводит к ошибке “undefined variable”. А так как блок catch игнорирует значение исключения e, предполагая, что он разбирается с другой проблемой, он считает, что выброшенное исключение является результатом неправильных входных данных. Это приводит к бесконечному циклу и скрывает полезное сообщение об ошибке насчёт неправильного имени переменной.

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

Значит, нам надо поймать определённое исключение. Мы можем в блоке catch проверять, является ли случившееся исключение интересующим нас исключением, а в противном случае заново выбрасывать его. Но как нам распознать исключение?

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

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

function InputError(message) {
  this.message = message;
  this.stack = (new Error()).stack;
}
InputError.prototype = Object.create(Error.prototype);
InputError.prototype.name = "InputError";

Прототип наследуется от Error.prototype, поэтому instanceof Error тоже будет выполняться для объектов типа InputError. И ему назначено свойство name, как и другим стандартным типам ошибок (Error, SyntaxError, ReferenceError, и т.п.)

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

Теперь promptDirection может сотворить такую ошибку.

function promptDirection(question) {
  var result = prompt(question, "");
  if (result.toLowerCase() == "left") return "L";
  if (result.toLowerCase() == "right") return "R";
  throw new InputError("Invalid direction: " + result);
}

А в цикле её будет ловить сподручнее.

for (;;) {
  try {
    var dir = promptDirection("Куда?");
    console.log("Ваш выбор", dir);
    break;
  } catch (e) {
    if (e instanceof InputError)
      console.log("Недопустимое направление. Попробуйте ещё раз.");
    else
      throw e;
  }
}

Код отлавливает только экземпляры InputError и пропускает другие исключения. Если вы снова сделаете такую же опечатку, будет корректно выведено сообщение о неопределённой переменной.

Утверждения (Assertions)

Утверждения – инструмент для простой проверки ошибок. Рассмотрим вспомогательную функцию assert:

function AssertionFailed(message) {
  this.message = message;
}
AssertionFailed.prototype = Object.create(Error.prototype);

function assert(test, message) {
  if (!test)
    throw new AssertionFailed(message);
}

function lastElement(array) {
  assert(array.length > 0, "пустой массив в lastElement");
  return array[array.length - 1];
}

Это – компактный способ ужесточения требований к значениям, который выбрасывает исключение в случае, когда заданное условие не выполняется. К примеру, функция lastElement, добывающая последний элемент массива, вернула бы undefined для пустых массивов, если б мы не использовали assertion. Извлечение последнего элемента пустого массива не имеет смысла, и это явно было бы ошибкой программиста.

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

Итог

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

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

Выброс исключения приводит к разматыванию стека до тех пор, пока не будет встречен блок try/catch или пока мы не дойдём до дна стека. Значение исключения будет передано в блок catch, который сможет удостовериться в том, что это исключение действительно то, которое он ждёт, и обработать его. Для работы с непредсказуемыми событиями в потоке программы можно использовать блоки finally, чтобы определённые части кода были выполнены в любом случае.

Упражнения

Повтор

Допустим, у вас есть функция primitiveMultiply, которая в 50% случаев перемножает 2 числа, а в остальных случаях выбрасывает исключение типа MultiplicatorUnitFailure. Напишите функцию, обёртывающую эту, и просто вызывающую её до тех пор, пока не будет получен успешный результат.

Убедитесь, что вы обрабатываете только нужные вам исключения.

function MultiplicatorUnitFailure() {}

function primitiveMultiply(a, b) {
  if (Math.random() < 0.5)
    return a * b;
  else
    throw new MultiplicatorUnitFailure();
}

function reliableMultiply(a, b) {
  // Ваш код
}

console.log(reliableMultiply(8, 8));
// → 64

Запертая коробка

Рассмотрим такой, достаточно надуманный, объект:

var box = {
  locked: true,
  unlock: function() { this.locked = false; },
  lock: function() { this.locked = true;  },
  _content: [],
  get content() {
    if (this.locked) throw new Error("Заперто!");
    return this._content;
  }
};

Это коробочка с замком. Внутри лежит массив, но до него можно добраться только, когда коробка не заперта. Напрямую обращаться к свойству _content нельзя.

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

function withBoxUnlocked(body) {
  // Ваш код
}

withBoxUnlocked(function() {
  box.content.push("золотишко");
});

try {
  withBoxUnlocked(function() {
    throw new Error("Пираты на горизонте! Отмена!");
  });
} catch (e) {
  console.log("Произошла ошибка:", e);
}
console.log(box.locked);
// → true

В качестве призовой игры убедитесь, что при вызове withBoxUnlocked, когда коробка не заперта, коробка остаётся незапертой.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Охлаждение погружением, серверы «под водой»: Immersion-2 для 3M™ Novec™ обеспечил волшебные результаты, применение на практике в Гонконге

Охлаждение погружением — иммерсионное охлаждение. В прошлой статье посвященной иммерсионному охлаждению были рассмотрены по сути преимущества размещения серверов в минеральном масле. Я глубоко заблуждался, когда мне казалось, что это наиболее эффективное решение в глобальном плане. Ознакомившись с некоторыми иными разработками я осознал, что эффективен сам базовый принцип — охлаждение погружением, а вот все остальное, как говорят «depends on»…

Cегодня я Вам хочу поведать о сравнительно новой двухфазной системе охлаждения Immersion-2, которая использует все преимущества «сухой воды» 3M™ Novec™ для достижения по истине волшебных результатов, превращая недостатки в достоинства!

Что такое 3M™ Novec™ повторяться не будем, об этом уже писали в рунете много раз, и даже на Хабре существует прекрасная статья, а вот как это можно применять для охлаждения серверов на практике и почему «сухая вода» оказывается эффективнее минерального масла, жидкостных систем охлаждения электроники в замкнутых контурах, рассмотрим сейчас.

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

К примеру 20 материнских плат потребуют 20 закрытых корпусов, 20 теплообменников, 40 разъемов для циркуляции жидкости (20 входящих и 20 исходящих), 20 разъемов питания, 20 устройств контроля и т.д. Все эти компоненты будет очень трудно обслуживать. В открытом подходе, благодаря 3M™ Novec™, применяют одну иммерсионную охлаждающую полуоткрытую баню с 2-фазным охлаждением, где все оборудование может быть помещено в один корпус целиком.

Благодаря тому, что 3M™ Novec™ начинает кипеть при атмосферном давлении уже при температуре 34°C, 49°C или 56°C (в зависимости от применяемого типа различается температура кипения) происходит его фазовый переход из жидкого состояние в газообразное. Это свойство можно применить для охлаждения оборудования без применения гидравлических помп, как в случае охлаждения минеральным маслом, так как нет необходимости в перекачки жидкости внутри резервуара, 3M™ Novec™ кипит и перемешивается, удаляет лишнее тепло благодаря физическим процессам испарения и конденсации, двум фазовым переходам, благодаря чему конструкция системы значительно упрощается.

Для лучшего понимания приведу этапы 2-х фазного иммерсионного охлаждения:

Подобно иммерсионному охлаждению, «запечатанные серверы» применяют однофазный процесс охлаждения. Это гораздо менее эффективно в сравнении с 2-х фазной системой (коэффициент теплопередачи значительно выше) и требует большего количества компонентов. Высокая плотность, например, в пассивных 2-фазных системах, просто не возможна, потому процесс перемешивания прекрасно проходит без применения насосов. Технически запечатанные серверы используют диэлектрическую жидкость, такую как минеральное масло или флюид похожий на жидкость, используемый в пассивном 2-фазном иммерсионном охлаждении. Но процесс отвода тепла не происходит за счет испарения и конденсации, основной процесс — перемешивание при помощи помп, что в любом случае только увеличивает потребление энергии и снижает эффективность охлаждения.

В целом стоит отметить, что идея Immersion-2 по сути не нова. Еще в 1970-х годах проводились соответствующие исследования с применением флюида C6F14, который кипел на поверхности кремниевого чипа. Однако сам чип был далек от совершенства и флюид оказывал негативное воздействие на него. Короче говоря, компьютерная и чип технология созрела только в последние несколько десятилетий. То, что мы не могли сделать 20 лет назад теперь можно благодаря современному пакету микросхем, которые включают распределители тепла с интерфейсами высокой производительности, ssd-дискам, в которых отсутствуют вращающиеся компоненты и герметичных HDD-дисках, применение которых возможно в жидкой среде. Другим фактором, который повлиял на то, что технология ранее не исследовалась, стало отсутствие вычислительных систем высокой плотности в то время и только за последние несколько лет эта проблема набрала актуальность.

Компания Allied Control всерьез занялась разработкой этой идеи, применила ее на практике и вот, что из этого получилось:

В качестве тестового проекта в Гонконге в офисном здании на небольшой площади был сооружен мини дата центр, который стал самым энергоэффективным дата центром не только в Азии, а пожалуй в целом мире, так как был достигнут коэффициент энергоэффективности PUE на уровне 1,01!

Со слов Allied Control максимальная мощность приходящаяся на стойку при использовании их системы охлаждения может составлять до 225 кВт. Для тестовых целей система охлаждения мощностью до 500 кВт была инсталирована для 24 стоек. В этом офисном мини дата центре тише, чем в библиотеке!

Забавно то, что первый в мире самый энергоэффективный дата центр в истории был применен не для научной работы, а для майнинга криптовалюты BitCoin, реалии современного мира, но инновации нужно как-то окупать! Для роста майнинг-фермы даже резервирована дополнительная площадь:

А так выглядят «лезвия», которых может быть до 92 в каждой единице:

Система жидкостного охлаждения само собой резервирована:

Разумеется также, как и каналы связи и электропитание.

— в 4000 раз более эффективно, чем воздушное охлаждение (электронные компоненты погружают в диэлектрическую жидкость, которая имееет гораздо большую теплопропроводность и теплоемкомсть, нежели воздух);

— энергоэффективность 1,01 (возможность отвода от 18 до 225 кВт тепла со стойки);

— «охлаждаем сотни киловатт», используя всего лишь 1500 Ватт (экономия на электроэнергии для текущей площадки из 24 шкафов, заполненных оборудованием, составляет свыше $60 000 / месяц);

— низкая температура кипения способствует перемешиванию и пасивному охлаждению благодаря испарению, исключает необходимость применения насосов (используется флюид с температурой кипения 34°C (93°F) под названием 3M™ Novec™ 7000);

— более высокая плотность (занимаемая оборудованием площадь сокращается во много раз, тем самым позволяе экономить на всех прочих инженерных системах дата центра);

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

— невероятная чистота (двухфазная иммерсионная система охлаждения обладает полезными побочными эффектами — массивный поток воздуха, пыль и шум, исключаются из объекта, что-либо погруженное в флюид не только не нуждается в очистке и сушке при извлечении, но даже становится еще чище за счет испарения флюида с поверхности);

— крайне высокая степень экологичности и пожаробезопасности (не содержит веществ, которые разрушают озон, более того обладает свойством вытеснения кислорода, тем самым предотвращая процессы возгорания, что активно используется в газовых системах пожаротушения на основе 3M™ Novec™);

— долгий срок жизни (свыше 30 лет) и различные температуры кипения охлаждающего вещества (34°C, 49°, 56°C и т.д., в основном применяют Novec 7000 и Novec 649 с температурой 34 и 49 градусов соответственно);

— безопасность (при работе благодаря низким температурам кипения невозможно получить ожог, а благодаря отсутствию токсичности — отравление);

— не запатентированность (возможность универсального дизайна под конкретный проект);

— готовое модульное решение для заказчика с быстрым сроком ввода в эксплуатацию (до 6 месяцев).

На последнем пункте остановимся подробнее. Серийное решение получило наименование DataTank™ и предоставляет возможность отвести до 1,4 МВт тепла с оборудования, размещенного в одном контейнере:

Модули DataTank ™ являются системами третьего поколения и способны эффективно работать даже в жарком и влажном климате Азии, при этом обеспечивая PUE 1,01 или даже менее. Несколько контейнеров могут быть объеденены для развертывания крупномасштабной контейнерной фермы.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.