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

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

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

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

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

1. Механические препятствия

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

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



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

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

1. Начать с «терминов и определений»
Есть несколько вариаций этого способа:

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

Как правильно должен быть написан учебник? Ответ стандартный:
— сначала предмет изучаемой науки;
— затем принципы и методология;
— потом основные разделы;
— потом подразделы каждого раздела;
— и в конце практические детали.

Этот порядок считается классическим, а учебник, написанный таким образом — образцовым.

В своей статье я намерен доказать, что хороший учебник пишется строго задом на перед. А хорошие учебники в области IT тем более. Не зря ведь существует «Hello, World!»

Менеджер пакетов в Mac OS X позволит нам легко работать с пакетам посторонних разработчиков. В этом топике рассмотрим два таких менеджера: MacPort и Homebrew.

В этой заметке я расскажу как использовать GrowlNotify, Launchd и AppleScript для периодического вывода всплывающих сообщений (на примере классических латинских выражений). Заметка рассчитана на новичков, профессионалы вряд ли найдут для себя что-то новое.

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

Кроме сторонних файловых менеджеров в Mac OS X, которые довольно плохо интегрируются с системой и заменяют Finder (за исключением, пожалуй, Path Finder — он в этом плане довольно далеко продвинулся), можно прокачать обычный Finder :)

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

К слову, автором этого плагина является человек, зарекомендовавший себя Visor'ом (Quake-like Terminal.app).

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

В один прекрасный день я стал использовать mac os x как основную операционную систему. И с тех пор я иногда обнаруживаю, что некоторые функции, к которым я привык, отсутствуют в том или ином виде. Работая с компьютерами больше 10 лет, у меня выработалась стойкая привычка блокировать рабочий стол, если я отхожу даже на 2 минуты.

Начиная с Windows Vista, Microsoft включила в состав операционной системы механизм управления учетными записями пользователей (сокращенно UAC). Механизм работы UAC большинство пользователей восприняли негативно, так как бесконечные дополнительные валидации в виде затенения экрана и прощелкивания кнопочки Yes могли вывести из себя даже самого терпеливого. Зачастую UAC функционировал не вполне корректно, что приводило к не возможности работы с рядом программ, которые были написаны под ранние версии Windows. C выходом SP1 для Vista UAC был доработан, но пользователи уже успели отключить UAC и забыть что это такое.

В Windows 7 UAC приобрел дополнительные настройки. И я бы хотел рассказать, как именно сделать UAC действительно полезным инструментом для защиты ОС.

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

В последнее время я наблюдал несколько десятков презентаций, которые начинались вот так:

— Мы делаем систему управления электронным обучением…

— Мы провели исследование поведения посетителей на нашем сайте…

— Наша компания была основана более ста лет назад…

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

— Мы предлагаем SAAS-решение…

— Наши технологии…

И мое любимое:

— Начну рассказ с того, кто мы такие…

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

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

Почему каждый раз это происходит?

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

+ Время-люди-деньги и другие треугольники
+ Управление временем
+ Deadline
+ Другие Ресурсы
+ Как стать менеджером проекта

http://www.happy-pm.com/blog/
http://it-games.ru

Продолжение статьи «Ставим голос».
В предыдущей статье мы рассмотрели теорию и попробовали производить наш настоящий голос. Появилась заинтересованность в теме.

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

Доброго времени суток.

Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).

Процесс

Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.

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

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

Обзавелся новой игрушкой — Smart Q7 MID, так и не нашел ни одного обзора на хабре, поэтому расскажу и покажу

В данном топике я попытаюсь сравнить некоторые из игр для программистов.

• Colobot
• CeeBot
• Terrarium
• Robocode
• Evole
• DarwinBots II
• breve

Более подробное описание для игр Colobot/CeeBot можно прочитать здесь, про Robocode здесь, про CoreWars здесь.

Начинать данную статью с различных вводных матчастей о «Великой силе SCRUM'а» и «ущербности водопадной методологии» считаю пустой тратой времени, поскольку в интернете и так достаточно много ресурсов, позволяющих узнать всё: от историй предпосылок создания технологий до всех преимуществ и недостатков в текущих реализациях. Как говорится: «Кто ищет, тот всегда найдет...» (с) :-).

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

Итак, начнем…

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

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

Существующие проблемы ПО находятся прямо «на поверхности», их не надо искать, а уж тем более вытаскивать из глубины. Но тем не менее, начинаются новые обсуждения, новые концепции… в итоге «кто в лес, кто по дрова»… но главное, существующие недостатки завуалированы емкими терминами и как следствие новая система только стала еще сложнее и не понятнее. Жалко потраченного времени (2-5 лет), а уже тем более жалко выкидывать «тонны кода», ведь программисты не виноваты.

После разведенной мною демагогии о «водопадном подходе» :-) имеет смысл перейти к реально рабочей технологии SCRUM. Данная технология действительно помогает оживлять продукты и способствует разработке новых и качественных продуктов.

Инициативная группа разработки решила поработать по SCRUM, пытаясь исправить существующее положение вещей. Была сформирована команда в составе: программисты, аналитики и тестировщики, в которой как и положено технологии был ProductOwner со своим ProductBacklog'ом и SCRUM-мастер.

Процесс
Практику SCRUM мы объединили с некоторыми практиками XP (eXtreme Programming). SCRUM позволяет решить вопросы управления и организации, а XP специализируется на инженерных практиках. Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стилевое описание кода. Также на ретроспективах мы определили для себя ряд правил, которых мы придерживаемся. Для проектирования качественного GUI применяем практику использования персонажей.

Используем только легковесное документирование: диаграмма БД и UML-модель, которые разрастаются только в ходе разработки, соответственно — это не такие страшные пауки, как было описано выше.

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

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

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

SCRUM — митинг
Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски. После встречи делается отметка на графике сгорания. Задача считается выполненной, т.е. переносится в «Done», только после тестирования. Программист может взять следующую задачу в «InProgress» только после одобрения аналитиком предыдущей задачи, взятой на выполнение. Диаграмму сгорания «подбивает» Скрам-мастер. Чтобы не превышать временной 15-минутный лимит, встреча проводится стоя. На встрече мы определяем, что мы сделали, что будем дальше делать, какие проблемы. Стараемся не обсуждать технические детали, но не всегда получается. Обычно встреча длится не более 10 минут. Если на митинге были определены некоторые технические проблемы, то их обсуждение проводится после скрам-митинга возле «стены проектирования» (доска с маркерами).

SCRUM — доска
В качестве скрам-доски мы используем обыкновенную пробковую доску. Область доски мы разделили на три части: ToDo (что надо сделать), InProgress (В работе), Done (Выполнено).

Однако, мы ведем и электронную версию доски (UserStory, задачи, % участия задействованных участников команды и т.д.) в программе. Это делается «для истории», в работе мы пользуемся только доской.

График сгорания
График сгорания является наглядным индикатором прогресса. Ось X — это ось времени. Ось Y — трудоемкость невыполненных задач. Задача считается выполненной если она проверена тестировщиком, во всех остальных случаях задача не выполнена.

Выполненные задачи переносятся в раздел «Done» скрам-доски. Таким образом график отображает сумму трудоемкости задач, находящихся в разделах «ToDo» и «InProgress». После ежедневных митингов, диаграмма сгорания «подбивается» с учетом выполенных задач за день. Также информация о выполнении заносится в программу, в которой наглядно отображается дата взятия задачи в «InProgress», дата выполнения данной задачи. В продукте автоматически подсчитывается средняя скорость команды, фокус-фактор. Данная информация иногда может помочь в переоценке трудоемкости задач и фокус-фактора команды.

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

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

Для проведения ретроспективы используем доску с маркерами, которая условна разделена на 4 блока: минусы, плюсы, идеи и план. После того как все участники высказались и все идеи были записаны, мы проводим голосование путем расставления магнитных фишечек. Практически все, что было записано в блок «План» мы стараемся впоследствии соблюдать.

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