Гражданский кодекс Франции теперь на Github

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

До Франции аналогичные действия предприняли Германия, Швеция, Дания, Швеция, Финляндия. Например, вот репозиторий Бундестага с весёлой аватаркой.

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

В самом деле, законодательные акты очень похожи на исходный код open source программ. Это тоже тексты, над которыми идёт совместная работа. Депутаты и эксперты совместно работают над отдельными текстами, которые после окончательной шлифовки включаются в кодекс.

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

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

«Гражданский кодекс — это часть исходного кода Франции. А исходный код подлежит контролю версий. Точка», — сказано в README государственного репозитория.

Текст Гражданского кодекса опубликован под лицензией Creative Commons.

Как вы считаете, следует ли российское законодательство перевести на Git или другую систему контроля версий?

Никто ещё не голосовал. Воздержавшихся нет.

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

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

Дайджест интересных материалов из мира Drupal #7

Всем привет!

Самое интересное и полезное из мира Drupal за прошедшие 3 недели в нашем седьмом выпуске.

image

По-русски

Начнём с материалов в рунете:

  1. По традиции несколько полезных сниппетов от xandeadx: «Оплата доступа к ноде с помощью Робокассы», «Taxonomy Menu и названия пунктов меню из поля термина», «Программно авторизовать пользователя по uid».
  2. Павла Китаева не отпускает Form API 🙂 Читайте его статью «Создание новых типов элементов формы HTML5».
  3. Макс Корейченко размышляет на тему производительности и делится своим подходом к аяксификации.
  4. «Такой замечательный баг нашел, или это фича?» — пишет автор блога «Make You Live Better | Сексуальные опыты с Drupal CMF» после ночи с модулем Context 🙂
  5. kalabro рассказала, как можно подключать PHP-файлы в своём модуле.

Drupal-lite

Этот раздел специально для тех, кто с друпалом недавно:

  1. В статье Form API #states рассказывается, как легко сделать свои формы динамичными без единой Javascipt-строчки.
  2. Пошаговый мануал, как добавить свой собственный текст (custom content) в Panels.
  3. Сложные проверки значений полей можно настроить прямо из админки с модулем Field Validation.
  4. Переходим на сторону добра — отказываемся от Views PHP: Conditional Views — Sure beats Views PHP for simple variance.
  5. При записи обзорного видео по модулю Subuser Шэйн Томас нашел баг и решил исправить его сам. Подробности в видео Module Investigator: Fixing an issue in the Drupal Subuser module.

Всё для Drupal-разработчика

Коктейль из материалов для друпалеров среднего уровня и выше:

  1. Очередная гигантская компиляция из модулей, статей и тому подобного появилось на Drupal.org. На этот раз она посвящена созданию сайтов государственных учреждений. Архив других компиляций доступен на странице Resource Guides. Очень советуем добавить в ваши закладки.
  2. Многие поисковые системы поднимают наверх в выдаче сайты, которые работают по HTTPS, а также имеют мобильную версию. Google даже подготовил официальный гайд по адаптивным темам в Drupal.
  3. Не всё решается через модуль Views (и далеко не все списки полезно делать через него). В публикации Easy Way Out Before Lost inside Views Maze рассказывается, как можно сделать выборку материалов самостоятельно для отображения блока с ленивой загрузкой через Ajax.
  4. Неплохое введение в парадигму Headless Drupal представлено в материале Headless Drupal. Why & how a RESTful API in Drupal?
  5. Как портировать модули на форк Drupal 7 под названием Backdrop CMS, читайте в статье Porting Drupal 7 Modules to Backdrop.
  6. Тема безопасности не теряет актуальности. Существует изрядное количество автоматических сканеров уязвимостей сайтов плюс целые базы эксплоитов. Ввести хакеров в заблуждение помогут шаги по сокрытию того факта, что ваш сайт сделан Drupal. В материале Hiding the fact that your site runs Drupal представлен подробный обзор методов достижения этой цели. Дополнительные идеи можно почерпнуть в подборке Hiding Traits of Drupal.
  7. Пакетная обработка больших данных практически всегда предполагает использование очередей. В материале с лаконичным названием Drupal Queues показан пример объявления и использования собственной очереди.
  8. The Drupal mail system — исчерпывающая статья про почтовую подсистему друпала.
  9. Если вы задумывались, есть ли что-нибудь похожее на hook_node_access(), только для других сущностей, то обязательно прочитайте публикацию Custom access control for Drupal 7 entities.
  10. Капелька драша не повредит нашему дайджесту: Drush Registry Rebuild для лечения тех проблем, которые не решаются сбросом кеша.
  11. Jeff Geerling проделал огромную работу по популяризации Ansible в Drupal-сообществе, апогеем которой стала Drupal VM = Vagrant + Ansible + Drupal.
  12. Появилось несколько обзоров хостинга Platform.sh: первые шаги на SitePoint и более серьёзная статья на примере реального проекта.
  13. В статье Drupal Testing Methodologies Are Broken — Here’s Why автор интригует скорой публикацией выстраданного фреймворка для интеграционных тестов в Drupal 7, который можно было бы запускать на работающем сайте вместо Simpletest или PHPUnit. Также представлен обзор основных проблем, с которыми сталкиваются разработчики при попытках прикрутить автоматизацию тестов к Drupal.
  14. Раз уж мы заговорили про тестирование, стоит упомянуть вводную статью по Behat:BDD with Behat and Drupal.
  15. Луллаботы делятся опытом по использованию популярного Javascript-фреймворка AngularJS в Drupal-проектах: Wrapping AngularJS modules in Drupal CTools plugins.
  16. Углубляемся в query-запросы Solr, чтобы лучше понимать, как это всё вообще работает.
  17. В поисках замены Features, серия №2086: встречайте CINC и сразу пример с созданием представления из кода.
  18. Google отключает Image Charts API в апреле. По этому поводу обзор модулей построения графиков.

Drupal 8

  1. Вышла 9-я бета-версия Drupal 8. Критических issue по-прежнему больше полтинника.
  2. Если вы ещё не видели презентацию «30 Awesome Drupal 8 API Functions», то отличный шанс сделать это сейчас. Кстати, есть версия для семёрки.
  3. Настройка Vagrant для разработки под Drupal 8 с помощью VDD.
  4. В статье Creating Custom Field Formatters in Drupal 8 рассказывается о том, как создавать новые форматеры полей.
  5. Изменения в системе фильтрации текста в восьмёрке, а также подводные камни в виде двойного экранирования рассматриваются в материале Avoiding Double-Escaped Output in Drupal 8.
  6. В статье Dependency Injection with Traits in Drupal 8 автор делится любопытным опытом портирования одного модуля с Drupal 7 на Drupal 8. По ходу захватывающего странствия встречаются PHP Traits, а также Dependency Injection и Module Upgrader.
  7. В очерке Alter or Dispatch: Drupal 8 Events versus Alter Hooks сделана попытка указать идеальный способ объявления собственных событий в Drupal 8.
  8. Когда вам понадобится Ctools для восьмёрки, вы знаете, где его искать: The Drupal 8 plugin system — part 4.
  9. Красивая форма поиска по коммитам в Drupal 8: Drupal 8 Git Commit Explorer.

Бизнес и сообщество

  1. Drupal 8 Accelerate.
    Программа грантов по разработке Drupal 8 уже наделала много шума. Drupal-ассоциация планирует привлечь как минимум $250k. При этом половину уже внесли сама ассоциация и 7 крупнейших Drupal-компаний. А вот бы так: делаешь git push на орге, а тебе на счёт автоматически падает $100… Но мы, кажется, отвлеклись 🙂
  2. Новости бизнеса: Mediacurrent, крупнейший игрок Drupal-рынка, поглощен дизайн-агентством Code and Theory.
  3. Утверждены доклады на майский DrupalCon Los Angeles.
  4. Сообщество простилось с ушедшим из жизни по причине тяжелой болезни Аароном Винборном. Почитайте о нём. Ассоциация анонсировала премию имени Аарона, часть которой будет ежегодно направляться семье Винборнов.
  5. Этот человек очень редко высказывается. В этот раз он сделал исключение: Earl Miles, он же merlinofchaos, автор Views и Panels, о друпале и его сообществе. (TL;DR: всё нормально и у Ёрла, и у друпала).
  6. Две трогательные истории разработчиков из серии «Я и Drupal»: My journey in Drupal, 4 years on, 542 days as a Drupal developer. Пусть таких историй будет только больше.

Интересные модули

  1. Configuration Management
    Альтернативный Features подход для управления конфигурацией рассматривается в статье Configuration Management, an alternative to Features.
  2. Features Builder
    Если же вы активно продолжаете использовать модуль Features в разработке, то обратите внимание на материал Features Builder, problems zero with Features!
  3. Taxonomy Entity Index
    Этот модуль используется для оптимизации производительности сайта при массовом использовании таксономии. На данную тему написана небольшая статья Drupal 7, Tags, Unpublished Content, and You.
  4. VoiceCommander
    Голосовые интерфейсы — тренд на протяжении уже многих лет. С этим модулем вы можете проэкзаменовать Web Speech API в друпале.
  5. Openstack Queues
    Интеграция с движком очередей Openstack Zaqar (альтернатива Amazon SQS с открытым исходных кодом).
  6. Field SQL Lean
    Достаточно экстремальный подход к оптимизации, который необратимо изменяет структуру таблиц для хранения значений полей. Очевидно, что с новой структурой не смогут стандартно работать множество модулей Drupal, например Views, тем не менее, полезно знать, что существуют и такие возможности системы.
  7. Views Calc
    Этот модуль позволяет вывести строку «Итогов» в таблице. Подсчёт ведётся на стороне БД и поддерживает операции COUNT, SUM, AVG, MIN, MAX. Как пользоваться, рассказывают в OSTraining.
  8. GA Push
    Расширенное API для отправки любых событий в Google Analytics. С его помощью можно, например, отслеживать ошибки валидации форм на вашем сайте.

Над выпуском работали Олег Кот и Катя Маршалкина.
Пишете статьи о Drupal на благо сообщества? Дайте нам знать — drupal.digest@gmail.com.

А ещё мы запускаем Drupal-рассылку. Воспользуйтесь формой регистрации и станьте первыми читателями!

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

Повреждение стека в одном из методов NSString

Хочу написать про один странный креш, с которым разбирался на работе.

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

NSURLComponents* urlComp = [[NSURLComponents new] autorelease]; ... urlComp.path = path; urlComp.user = username; ... 


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

Хоть отладчик зачастую и не может в релизе распечатать переменные, но по дизассемблерному листингу легко видеть в каком регистре, какие переменные должны быть, и отладчик способен нормально выводить объекты (например, po $r0). Быстро становится понятно, что сдох username (в моем случае регистр r10) — po $r10 выводит число, а не объект. Несколько менее быстро становится понятно, что значение в регистре r10 поменялось после выставления path.

Окей, лезем смотреть, что происходит в методе "-[__NSConcreteURLComponents setPath:]". Благо дело он небольшой и видно, что регистр r10 слетает при вызове "-[NSString(NSURLUtilities) stringByAddingPercentEncodingWithAllowedCharacters:]" — т.е. когда эскейпится переданный путь. Эта функция уже большая, и заказчик голову отровет за ее анализ, но хотя бы глянем на вход-выход

0x2ca50aec:   push.w {r8, r10, r11} 0x2ca50af0:   sub.w   sp, sp, #0x1020 0x2ca50af4:   sub     sp, #0x10 ... 0x2ca50e7a:   add.w   sp, sp, #0x1020 0x2ca50e7e:   add     sp, #0x10 0x2ca50e80:   pop.w   {r8, r10, r11} 

При входе наш r10 сохраняется в стек, а при выходе восстанавливается. Указатель стека (sp) в порядке, что было, то и вернулось, а вот само содержимое стека уже не то — значение r10 восстановилось неверно. Таким образом, в системной функции для percent encoding’a есть повреждение стека.

Для наглядности я вынес код-пример в чистый тестовый проект:

NSObject* obj1 = [[NSObject new] autorelease]; NSObject* obj2 = [[NSObject new] autorelease]; NSObject* obj3 = [[NSObject new] autorelease]; NSObject* obj4 = [[NSObject new] autorelease]; NSString* str = @"/Users/zaryanov/Movies/rootfolder/시티 오브 히어로 (City of Heroes)/로니 리 가드너 (1961년부터 2010년까지)는 1985 년에 살인죄로 사형을받은 유타 주에서 총살형 된 미국의 악당이었다. 1984 년에 그는 솔트 레이크 시티에서 강도 동안 바텐더를 살해.m4v"; NSLog(@"%s str %@", __func__, str); NSCharacterSet* charSet = [NSCharacterSet URLPathAllowedCharacterSet]; str = [str stringByAddingPercentEncodingWithAllowedCharacters:charSet]; NSLog(@"%s str %@", __func__, str); NSLog(@"%s obj1 %@ obj2 %@ obj3 %@ obj4 %@", __func__, obj1, obj2, obj3, obj4); 

При этом креш произошел не при выводе в лог, как я ожидал, а в самой проблемной функции (эскейпинга). Сработал abort в функции __stack_chk_fail — дело в том, что в чистом тестовом проекте была разрешена архитектура arm64, и там, по всей видимости, есть проверка стека. Если оставить только armv7, то креш происходит при выводе объектов в лог, как я и ожидал. В любом случае, стек поврежден.

Далее гугление по «stringByAddingPercentEncodingWithAllowedCharacters crash» дает некоторые подтверждающие результаты:

https://github.com/Alamofire/Alamofire/issues/206 — здесь, правда, жалуются на большое потребление памяти, но функция та же;
https://gist.github.com/clowwindy/0d800f07a5e95e5c4dd0 — здесь пример, который сносит стек совсем, а не пару регистров.

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

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

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

Философия программирования 6 — Продукт и Проект

Разница между продуктом и проектом в том, что при разработке продукта есть план, а при разработке проекта есть исследования. Если у вас есть какая-то не решённая проблема, скажем вы ещё не решили какую базу данных использовать в своём проекте, то вам понадобится этот вопрос изучать, то есть исследовать. Это называется technology research. Исследование, это вовсе не обязательно, что-то совершенно новое в мировом масштабе, если вы строите мост, то вам надо исследовать грунт в данном конкретном месте, и пока этот грунт не исследован, мост, как продукт, ещё не существует, пока что это — проект. Ещё не известно, какой грунт, а значит не известно из чего делать мост, как его укреплять, невозможно посчитать бюджет и распланировать график работ.

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

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

При проекте свойственно мышление в духе: долго исследуем супер-фичу, мега-технологию, а потом быстро всё собираем и получаем продукт. Яркое отличие продукта в том, что в нём стадия «всё собираем» начинается очень рано, чуть ли не сразу, и большая часть графика отводится на доводку до ума всех частей. В проекте, наоборот, эта стадия наступает намного ближе к концу графика. График проекта похож на забивание десять тысяч гвоздей, можно сразу прикинуть как долго это займёт, и методично вколачивать. Вообще в проекте возникает ощущение, что «мы это уже делали, надо просто сделать ещё раз для данного конкретного продукта». Более того, процесс можно повторить по тому же графику создав ещё один схожий продукт. Многие успешные проекты, удались именно потому, что человек уже видевший весь график от начала до конца, уходит из коллектива и клонирует весь организационный проект, график работ и просто делает всё то же самое только качественнее, сознательно избегая исследований и экспериментов.

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

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

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

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

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

Любопытное бытовое сравнение, хотя надо понимать, что любое сравнение это только сравнение и может лишь иллюстрировать некий принцип, это готовка обеда. Когда вам надо себя покормить, вы можете очень быстро приготовить еду, и можете позволить себе эксперименты и исследования в процессе. Побольше посолить, поменьше, новую приправу попробовать, но если вам надо сделать праздничный ужин и покормить дорогих гостей, то ситуация в корне другая. Вроде затраты должны быть линейно масштабируемы, 5 гостей, значит предполагаемые затраты на праздничный ужин в пять раз больше чем на собственный обеденный перекус, но на самом-то деле, затраты будут отличаться на порядок, и по выбору ингридиентов, и по тщательности исполнения и сервировки, потраченному времени. Это проект и продукт. Никто не станет экспериментировать с праздничным борщом, а если и станет, то пожалеет. Гости то придут ровно в пять, то есть имеется дедлайн. Затраты на сервировку и деталировку, нарезание сыра тонкими ломтиками, размазывание варенья ровным слоем, это вещи которые в обычном бытовом обеде делаются в десятки раз проще чем в праздничном режиме. Таков продукт, это праздничный обед. Сложность исполнения праздничного обеда или ужина, компенсируется тем, что в нём всё детерминировано, каждая операция отлажена годами, в лучшем случае хозяйка решается на одно необычное блюдо, и оно отнимает массу времени и сил и сопровождается охами по принципу: «я раньше никогда не делала, решила попробовать, не судите строго», ищет конкурентное преимущество, так сказать. К тому же всё прекрасно масштабируется, потому-что большинство операций типовые и их могут делать все кто окажется на кухне.

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

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

Сколько раз вы слышали фразу «мы решили отказаться от…»? Моя юность пришлась на расцвет продуктов Борланд в России, я учился профессионально программировать и использовал Турбо Паскаль и позднее Дельфи. В связи с чем, у меня выработались некоторые навыки работы, привычка опираться на такие инструменты среды как F4 (Run to cursor), Control+Enter (Open file at cursor), мгновенная компиляция. Для меня стало критично, чтобы одной кнопкой я мог откомпилировать, поставить останов под курсором и запустить программу, потом так же терминировать её одной кнопкой и продолжить редактирование кода. Когда я пытался работать в привычном мне режиме на Visual Studio меня кроме на порядки более медленной компиляции сильно сбивало необходимость запускать отладчик одной кнопкой, запускать программу другой, предварительно удалять предыдущий брейк-пойнт и ставить новый, это целый процесс, на который я уже не мог отвлекаться. За несколько дней я написал макрос который кое-как решал проблему. Конечно, это мои личные пристрастия, но проблема в том, что у каждого программиста есть свои личные пристрастия, без них не бывает программиста, даже маляр имеет свои личные пристрастия к методам и инструментам. Один мой знакомый станко-наладчик, не мог работать если у него не было под рукой ванны с бензином, в которой он мог бы мгновенно в любое время полностью вымыть руки до предобеденной чистоты. Он ужасно страдал, когда приходилось работать в другом цехе, где такой ванны не было. Мелочь, но из таких мелочей и складывается рабочий процесс.

Я всегда постулировал такую вещь, как совершенство средств разработки. Знаете, как производство средств производства у марксистов, которое отличает развитую экономику от просто механизированной. Моё убеждение, что верно усовершенствованное средство разработки может ускорить разработку не на проценты, а на порядки, и не только ускорить, но и дать возможность разработчику браться за задачи иной степени сложности. Лет пять назад я сделал амбициозную попытку создать соответствующую моим требованиям C++ IDE. Она называлась DaoIDE. Для этого мне пришлось решить несколько фундаментальных проблем. Во-первых сделать свой текстовый редактор или научиться эффективно использовать Scintilla или другой открытый аналог. Текстовые редакторы я делаю сколько себя помню. Вообще, создание текстового редактора, это образец сложной задачи по программированию. Всё видно на экране, и сложнейшая структурность, это идеальная задачка для продвинутых учеников. Моя любовь к текстовым редакторам расцвела когда мне приходилось работать с приложением Aldus Page Maker, я открыто восхищался тем, что может эта программа, и ведь её написали в конце 80-х, начале 90-х. Мне довелось написать десятки текстовых редакторов from scratch, то есть с нуля. И это не считая сотен быстрых прототипов. От простейших нотепадов для доса, до систем со сложным маркапом и спец-требованиями. Так что с редактором не было особых проблем. Потом пришлось разбираться с отладчиком, я сделал множество прототипов интеракции среды с отладчиком, на основе dbghelp.dll, на чистом ассемблере, через GDB, GDB-MI, WinDbg и разных готовых обвесов над ними. Меня в процессе ужасало — как это сложно, насколько плохо всё документировано, очевидно, что ни один отладчик изначально не делался для встраивания в сторонние приложения. Потом пришлось разбираться с компилятором С++, основное моё требование к нему была скорость компиляции. Мне пришлось детально разобраться в истории разработки существующих компиляторов и убедиться, что самый быстрый компилятор (именно в смысле скорости компиляции, а не в смысле скорости работы скомпилированной программы) это Digital Mars C++ (DMC), бывший Symantec C++. Моё рассуждение простое, в процессе разработки приложения, его надо запустить много тысяч раз, а оптимизированный исполняемый выход нужен только в момент релиза один раз. DMC часто отрабатывал в несколько десятков раз быстрее соперников, давая перформанс близкий к привычному реактивному компилятору Delphi. Но он не давал возможности дебажить эти экзешники, из за лицензированного десятилетия назад формата объектного файла. MSVC, особенно ранних, версий был в разы быстрее GNU C++. Но не было шансов на кросплатформенность и жуткая невнятная документация, каждый чих, типа определения типа переменной, приходилось исследовать сутками. Этот проект занял у меня не меньше года, почти всё время ушло на исследования.

Проект среды С++ Дао заглох именно потому, что я убедился в неприменимости всех существующих IDE-строительных блоков доступных в мире, в первую очередь компиляторы, дебаггеры. Решая эту задачу, я потратил кучу времени изучая не только исходники но и сообщество и историю разработки этих инструментов. Например, я понял, что GCC никогда не будет быстро компилировать, более того, он с каждой версией будет компилировать всё медленнее, таков запрос рынка и таков фокус разработки. Не говоря про то, что сам направляющий комитет работает очень специфично, и пересматривать фундаментально устройство компилятора не станет никогда. Логика проста, там всё и так сделано по науке: lexer, AST, backend, codegen и т. п., нечего тут изобретать. Когда я увидел первое видео с рассказами авторов LLVM/Clang я прыгал от радости, было очевидно, насколько более творчески и решительно мыслят Apple и Google. Устройство GDB тоже кошмар и исторически и технически. Тут я должен разъяснить, что если я констатирую ужасность этих проектов, но это не значит, что мне они не нравятся, или я считаю идиотами, тех кто их сделал. Вовсе нет, это проекты мировые, и MSVC в том числе, компиляторы С++ вещь настолько сложная, что их в мире единицы, и все кто над ними работают это супер-люди! Можно буквально перечислить по пальцам проекты такого уровня. Просто стало ясно, что люди работают в другом направлении, чем то, которое близко лично мне. И мы снова возвращаемся к идее о совершенстве средства разработки и личных навыков разработчика.

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

Отчасти это объясняется маркетинговым сознанием западных производителей, если есть рынок, люди пользуются средством разработки, то зачем его фундаментально менять? Это же основы маркетинга. Если человек привык курить махорку, то не надо пытаться продать ему сигары, не лишай себя рынка, лучше перемолоть сигары в махорку и продавать улучшенную махорку. Зачем совершенствовать компилятор в неожиданных направлениях, если есть огромная пользовательская база уже обученная опираться на то, что есть? Надо просто подпиливать, и подкрашивать. Сейчас даже есть маркетинговая стратегия направленая на еженедельные, например, апдейты, а то, что там опять только «забор перекрасили» или кнопочку передвинули, это мелочи, главное, что — «проект жифф». Так выходит, что обычно сколько нибудь новые смелые решения на рынке появляются с новым продуктом, а не с новой версией уже существующего. Такие радикальные изменения, которые принесли Руби и Питон невозможно было бы ожидать от новой версии любой существующей системы.

Когда я писал YaUI, где надо было использовать сразу четыре языка программирования и три разных платформы, и соответственно, никакой отдельно взятый отладчик не мог это всё покрыть, я уже полностью и привык и полюбил отладку без отладчика, через кодомодификацию. Более того, я перевёл всю разработку в обычный notepad++, с компиляцией в командной строке, через скрипты, в результате мне удалось добиться одинакового подхода к разработке на всех трёх платформах и четырёх языках. (Java, ObjC, C++, JavaScript, Android, Windows, iOS). Когда я понял, что можно кодить вообще без монструозных IDE, убрать зависимость от этих огромных тормозных миров, можно вообще не компилировать и использовать Node.js, и не ждать когда в отладчике опять исправят очередной недостаток, я понял, что хочу сделать минималистский инструмент для такого стиля программирования. Так, собственно, и родилась идея Деодара. Хотелось ещё отказаться и от Windows, и уменьшить зависимость от ещё одной корпорации, то есть источника непредсказуемых перемен. Тут собственно я и возвращаюсь к основной теме статьи — проект и продукт, потому что мне сразу стало ясно, что написать нечто такое можно только проведя очень длительные исследования. То есть я хочу на собственном примере показать, как я пытался сознательно провести длительные исследования перед, собственно, работой над продуктом.

Первая задача с которой я столкнулся и которую решал около полугода, осознавая, что я могу и не справиться, была работа с окнами, экраном и клавиатурой. У меня уже был опыт разработки под XWindow System, и когда я только решил в этом разобраться, я в очередной раз убедился, что вся документация для юниксов построена по принципу манов, то есть если ты знаешь что набрать, ты набираешь и тебе написано, как это сделать, но если ты не знаешь как называется функция которая делает то, что тебе надо, ты будешь идти очень долгим путём. В конце-концов я научился работать с экраном и окнами через сокет по XWindow Protocol просто читая старинную спецификацию. Но мне не удалось главного, отрисовать Anti Aliased Text. То что в Windows или на Маке делается вызовом одной функции, в мире иксов целая история. Мне пришлось создавать OpenGL контекст и ручками рендерить туда буквы используя FreeType или HarfBuzz. Проблема была в том, что никак не удавалось достичь нормальной скорости, FPS. Я исследовал несколько десятков альтернатив, всевозможные тулкиты и обёртки, начиная от общепринятых GDK, Qt, FLTK, SDL и до очень сложных гибридных решений, включая GLUT, Pango в разных комбинациях. И каждая такая попытка занимала дни и даже недели. Десятки папок с прототипами лежат до сих пор. В конце концов я разобрался во всём и решил использовать Xlib+FreeType+OpenGL textures.

Далее возникла проблема буфера обмена. Оказалось, что на чистом Xlib это целая история и у меня опять ушли недели на решение этой проблемы. Мне кажется, людей понимающих как работает клипборд в линуксе на уровне иксов в мире единицы. Опять невероятно трудноуловимая документация. В конце концов я создал демонстрационный hello world на эту тему и выложил на гитхаб, теперь любой может в двадцати строчках увидеть как это делается на С. Поразило, что на Стэковерфло люди не смогли ничего внятного сказать по вопросу. Потом возникла проблема юникодного ввода текста и опять дни и недели исследований, десятки чужих примеров, которые все как обычно не работали и наконец удалось разобраться и с этим. Кстати, рассматривался и вариант работы Деодара из под консоли. Но поймите, терминал это древняя технология, он до сих пор совместим с телетайпами шестидесятых годов. Это рудимент, и главная проблема терминала это невозможность отлавливать нажатия на клавиши, то есть элементарное onKeyDown, onKeyUp в принципе невозможно на терминале в сущности являющимся потоковом символьным устройством на прямую не связанным с hardware. Недавно автора BASH спросили, как он видит будущее своего детища. Знаете что он ответил? Хочу, говорит, чтобы BASH поскорее исчез и его все забыли и создали наконец что то более современное, соответствующее современным задачам.

Потом надо было исследовать вопрос, использовать ли чистый движок V8 или Node.js? Как такое решить? Пришлось написать оба варианта и выбрать лучший. Оказалось, что возможности Ноды совершено достаточны и возможность подключать npm модули это большой плюс в сторону этого решения. И только тогда стало возможно переходить к собственно работе над продуктом. Хотя ещё оставалось изобрести свой аналог Turbo Vision, что тоже оказалось весьма нетривиальным делом. Оказалось, что в JavaScript прототипное наследование не цепочное, то есть если вы пропустили в промежуточном потомке перекрытие метода, то он автоматически перекрывается как копия. Поясняю: у вас есть классы A->B->C и вы написали A.draw() и С.draw(), и из С.draw() вам надо вызвать А.draw() то вы никак не можете это сделать анонимно если ТОЧНО не знаете, был ли написан B.draw(). А для аналога Turbo Vision с его цепочным анонимным наследованием это было критическим вопросом. Анонимное это значит что вы не пишете A.draw.apply(this), а пишете this.inherited.draw(). Ведь B.draw() может существовать, а может и отсутствовать. Я перечитал всё, что было в интернете по вопросу наследования в JavaScript, оказалось, что это не так уж много, все в основном ссылаются на одни и те же две три работы, и в них эта проблема тоже не решена. Мне понадобилось ещё несколько недель, чтобы разобраться в самых тонких деталях наследования в JavaScript и понять как можно эту проблемку решить, в результате появился репозиторий dnaof на Гитхабе.

Собственно Деодар как продукт заключался в гибриде классического двухпанельного файлового менеджера с его реактивной слепой навигацией и очень удобного текстового редактора, не уступающего Notepad++, SublimeText и прочим, по интересующим меня параметрам. Ещё важнейшим моментом было внедрение терминала внутрь Деодара. То есть по нажатию Escape пользователь видит запущенный BASH и все три компонента, редактор, файловые панели и консоль очень плотно соединены в конгруэнтную систему. И главная киллер фича, конечно, это собственно JavaScript, то есть этой среде не нужны какие-то API для разработки плагинов, у вас весь исходный код под рукой, и он минималистичен, это не миллионы строк а считанные тысячи. К моменту прошлогоднего релиза, с даты которого прошёл ровно год, всё ещё оставались две не решённые фундаментальные проблемы. Не удалось достичь желаемой скорости отрисовки, то есть она была приемлема, но хотелось ещё больше FPS и не удалось понять, как попасть в репозиторий Ubuntu, хотя-бы. Поэтому Деодар пока остаётся проектом. Прорисовку мне недавно довелось переписать и выйти на желаемый показатель performance. Теперь вся эта эпопея продолжается, потому что я сразу осознавал, что это ПРОЕКТ и длится он будет годами и надо понимать, что каждый шаг включает исследования с открытой датой.

Собственно уровень продукта ещё впереди, для меня это вопрос интерфейса, ведь как говаривает Линус наш, Торвальдс — если в вашей программе есть фича, но её нет в интефейсе, то и ФИЧИ НЕТ. А в Деодаре до сих-пор нету даже менюшек, калкулятора, редактора палитры, работы с архивами и прочего. Кстати, работа с архивами вещь нужная, просто в работе именно программиста, она вторична, моя же цель была сделать не столько файловый менеджер как таковой, а рабочую среду программиста с файловым менеджером внутри. Но для продукта и это нужно.

Ну вот, надеюсь вам было интересно провести этот небольшой экскурс в философию программирования и небольшой пиар моего проекта. Ко мне тут неоднократно в комментариях обращались с претензией, что уже какая статья в серии Философия Программирования, а собственно о программировании пока ничего нет. Моя цель писать именно о программировании, осмысляя это явление всесторонне, а не только чисто технически. Ведь большинство текстов о программировании крайне однобоки, из серии «вот поставил новую версию Х, позвольте рассказать на какие грабли пришлось наступить». Опять же, я не ставлю оценок, что хорошо, а что плохо, такие тексты сами по себе хороши, решают свои задачи. Но нам необходимо подкапываться к более сложным вопросам, развивать язык, вводить новые понятия, расширять существующие. Вот сегодня я попытался взять заезженные казалось бы понятия Проект и Продукт и порассуждать, прилюдно, чем они отличаются. Ведь, то, что происходит у программиста в голове нуждается в умении высказать, а мы до сих пор только тычем пальцем в экран и мычим, «ну что ты не понимаешь» или «смотри в код», «ну что поделать если люди не умеют программировать». Может они умеют, просто ты не знаешь как объяснить то что думаешь об этом участке кода? Это же вопрос развития языка. Возьмём к примеру замыкания, ведь нет в языках программирования такого ключевого слова, а замыкание есть! То есть понятие вводится исключительно гуманитарно, в голову программистов, мол смотрите, вот как можно написать и получится «замыкание», с ним можно делать и то и это. Потом понятие развивается, добавляются дочерние понятия, расширяется набор ассоциаций. В общем будем работать, двигаться в выбранном направлении. Я очень надеюсь, что если двигаться целенаправленно, то рано или поздно удастся найти правильный тон рассуждения о предмете и сильно обогатить наше представление о профессии. И огромное спасибо всем кто принимает участие в комментариях, даже тем кто меня минусует, критикует, а особенно тем кто читает и ждёт продолжений!

Философия программирования
6: Продукт и Проект
5: Реактос и Колибри
4: Технология «Шапито»
3: Чичиков и программиат
2: Миф и язык
1: Трёхнаправленное программирование

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

Исследование факторов лидерства в ИТ

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

Особенно интересны комментарии участников опроса:

наберите в поиске «лидерские качества», «лидерство». Обладание какими-то супер-знаниями — это последнее, что вы там увидите. Тема лидерства топтана огромным количеством психологов. Наверное было бы интересно опровергнуть их теории, но доказывать их правильность не вижу смысла.

Или, например, такие:

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

И даже такие:

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

Но это все теоретизирование, а что же нам расскажут результаты опроса?

Я не являюсь профессиональным исследователем и понятия не имею чем отличаются Хи-Квадрат и Критерий Стюдента, а также как считаются доверительные интервалы. Поэтому я взял Excel Data Mining Add-in (https://msdn.microsoft.com/en-us/library/dn282373.aspx). Этот инструмент подключается к SQL Server Analysis Services Multidimensional и использует его механизмы Data Mining для анализа данных в Excel.

Выглядит оно так:

image

А для анализа таблиц есть готовые инструменты:

image

Демография

Для начала воспользуюсь инструментом Explore Data, для построения диаграмм

Распределение ответивших на вопрос по должностям:

image

По возрасту:

image

По полу:

image

По стажу на последнем месте:

image

Получается, что “средний” участник опроса – программист, возраст до 35, мужик, со стажем работы на последнем месте менее 3 лет.

Ключевые факторы

Попробуем сделать анализ.

Воспользуемся инструментом Analyze Key Influencers, чтобы определить какие колонки оказывают наибольшее влияние на те, которые нам надо исследовать.

Основной вопрос был – “Считаете ли вы своего руководителя лидером”, посмотрим что на него влияет.

image

Analyze Key Influencers использует алгоритм Байеса для выявления связи. Очевидно, что в случае ответа “Готовы ли вы перейти на другую работу вслед за руководителем=Да” отвечающий считает своего руководителя лидером, обратное также верно. Собственно это и был “валидирующий” вопрос в самом опросе.

Второй ключевой фактор – уровень комфорта. Если человек отвечает что ему очень комфортно с руководителем, то с высокой долей вероятности от считает его лидером. Обратное тоже верно, но влияние уже меньше.

Третий ключевой фактор – профессиональные качества руководителя, руководитель с более высокими профессиональными (в той области, которой занимается сотрудник) качествами будет назван лидером чаще, чем руководитель с низкими качествами.

Проанализируем теперь влияние на уровень комфорта, для этого снова запущу Analyze Key Influencers.

image

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

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

Дерево принятия решений

Decision trees прячутся под кнопкой Classify в Ribbon. Но из-за малого объема данных и высокой корреляции между колонками “Готовы ли вы перейти на другую работу вслед за руководителем”, “Считаете ли вы своего руководителя лидером” и “Оцените уровень комфорта в отношениях с руководителем” сходу дерево не строится.

Попробуем немного пошаманить:

  • Дискретизирую все текстовые значения, чтобы алгоритмы умели выявлять диапазоны.
  • Поправить параметры, которые замедляют “рост” дерева.

Получилась вот такая картинка:

image

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

Выявление категорий

Воспользуемся инструментом Detect Categories. Он использует алгоритм кластеризации. Я запустил алгоритм на дискретизированных значениях и он выявил у меня 4 категории.

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

  1. Молодые ИТшники
    • Менее 3 лет на последнем месте работы.
    • Не занимают руководящие должности.
    • Чаще всех меняли работу.
    • Самая многочисленная категория – 129 человек, примерно половина всех опрошенных.
  2. Старые ИТшники
    • Возраст 41-49 лет.
    • Стаж – 22-26 лет.
    • С текущим руководителем работают от 3,5 до 10 лет.
    • Работу давно не меняли.
    • Примерно половина из них – руководители (начальники отделов и выше).
    • В эту категорию попало 44 опрошенных.
  3. Терпящие
    • Оценивают уровень комфортно как “очень некомфортно” и “местами некомфортно”.
    • При этом меньше всех меняли работу и имеют стаж 8-11 лет.
    • Руководитель на них “забивает”.
    • Часто работают по указке.
    • В эту категорию попало — 42 опрошенных.
  4. “Внимательный руководитель”
    • Руководитель знает о планах сотрудника.
    • Руководитель дает обратную связь.
    • Руководитель – эксперт.
    • Руководитель благодарит за достижения.
    • Руководитель занимается развитием подчиненных.
    • Чаще всего самостоятельно принимают решения.
    • В эту группу попало 45 опрошенных.
    • В этой группе самое большое число Руководителей Проектов.

А теперь график “Считаете ли вы своего руководителя лидером”

image

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

Выводы

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

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

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

Ссылка на файл с данными опроса и результатами — 1drv.ms/1GcAuNj, можете сами провести интересующий вас анализ.

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