Андрей Катасонов

Некоторое время назад я натолкнулся на презентацию Kathy Sierra насчёт создания пользователей буквально «влюбленных» в Ваше ПО. Аннотация этой презентации представлена ниже.  Простые, но очень правдивые факты и идеи

• Если мы хотим создать влюбленных пользователей, мы должны помочь им стать лучше.
  • ‘Никто не относится со страстью к тому что он делает плохо (и знает об этом)
  • Фотокамеры многих людей постоянно включены на режим“P” – автоматический режим — несмотря на то что их фотокамеры предоставляют возможность более точного управления такими вещами как экспозиция и выдержка.
  • Что это будет значить для пользователей если мы откроем дверь и поможем им быть просто «классными»?
• В книге Malcolm Gladwell, Outliers (Посторонние), главной идеей является  “Правило 10,000 часов”, которое говорит что требуется по крайней мере 10,000 часов практики чтобы достичь мастерства в чем-то.
  • 10,000 часов это очень долго – это может быть удручающей перспективой
  • Согласно книге, 10,000 часов это около 3-х часов практики ежедневно на протяжении 10 лет
  • Чтобы достичь мастерства необходимо практиковаться всё время
  • Всё что помогает Вашим пользователям практиковаться – поможет им получить эти 10,000 часов (и стать лучше) быстрее.
• Давайте Вашим пользователям шаблоны успеха
  • В каждом шаблоне которые Вы даёте своим пользователям должна быть “одна вещь” которую они могут взять с собой как урок
  • Вам надо ответить на вопрос: “Есть ли что-то одно (и что это) что Вы можете делать  блестяще?”
• Давайте своим пользователям лучшие инструменты
  • Они будут работать лучше
  • “Не бойтесь тратить деньги!”
  • Объясняйте людям почему им нужны лучшие инструменты  которые Вы предлагаете
• Мотивация очень важна
  • Воспринимайте мотивацию как подарок
  • Делайте продукт который люди будут использовать на самом деле
  • “Ваша беговая дорожка стоит в углу собирая пыль не потому что Вы её не используете, Вы не используете её потому что она стоит в углу.”
  • “Сделайте правильные действия легкими для пользователей а неправильные – сложными”
• А теперь, то чего не следует делать:
  • Мы часто фокусируемся на инструменте а не на том чего хотят добиться пользователи с помощью этого инструмента
    
  • “Мы относимся к людям очень хорошо перед тем как они купят наш продукт, но после этого мы относимся к ним хуже.”
    • Это также причина почему люде не хотят платить за обновление продукта
    • Если мы хотим помочь людям обновить наш продукт – а им нужно будет сделать это если они хотят двигаться вперёл – мы должны понять что для них это проигрышь и удар по их уверенности в себе
  • Мы пишем FAQ так как будто наши пользователи любознательны и имеют TabletPC под рукой
    • Люди обращаются к FAQ и разделу помощи потому что уже имеют плохой опыт работы с Вашим продуктом
  • Не разрешайте “политике простоты использования” затмить все остальное
    • Вы не чувствуете себя блестяще когда освоили что-то что под силу 3-х годичному ребёнку
  • Наём консультанта по социальным медиа является ошибкой:
    • Они фокусируются на неправильном направлении
    • Консультанты по социальным медиа фокусируются на том чтобы Ваши пользователи любили Вас, что является неправильным – никто не является «блестящим» потому что любит Вас
    • Они думают что цель в том чтобы Ваши пользователи хотели веселиться с Вами на вечеринке
    • Настоящая цель это сделать так чтобы пользователи хотели веселиться на вечеринке из-за того что сделали Вы, что помогло им стать непревзойденными. Они должны веселиться из-за Вас, но без Вас
    • Вы хотите связывать пользователей с другими пользователями, не с Вашей компанией
    • Намного лучшим использованием социальных медия является выяснение:
      • Какую роль мы играем в жизни наших пользователей
      • Какую роль играют наши конкуренты в жизни наших пользователей
      • Какие точки «боли» (сделать что-то трудно) и «удовольствия» имеются у наших пользователей
    • Стараясь быть конкурентноспособными и фокусируясь на конкурентах мы оказываемся неконкурентноспособными
      • Это приводит к фичеризму (переизбыток функций)
      • Все заканчивается тем что мы производим продукт которы вредит нашему пользователю
      • Наилучшее что мы можем сделать это взглянуть на более большую, классную вещь – мир в котором существуют наши продукты и продукты наших конкурентов, проблемы которые эти продукты пытаются решить, вещи в которых наши пользователи стараются быть лучшими – и использовать социальные медиа для того чтобы общаться об этом

Недавно я решил выбрать приличный IDE для программирования на PHP и Python. Из бесплатных естественно Будучи наслышанным об Aptana Studio решил взвести её и посмотреть собственно за что её хвалят. Года 2 назад у меня уже был опыт работы в клипсе (Eclipse) + PHPEclipse – неплохая среда но всё таки слишком медленная, за что и была уничтожена и заменена на Vim.

Aptana построена на базе Eclipse и конечно же по производительности ничем не выделяется. Но на этот раз я уже решил соптимизировать Java машину чтобы посмотреть как она будет вести себя на современном железе. Итак, мы будем редактировать файл AptanaStudio.ini находящийся у меня в папке «C:\Users\<ИМЯ ПОЛЬЗОВАТЕЛЯ>\AppData\Local\Aptana Studio 1.2″ . Именно туда он устанавливается по умолчанию на Висте.

Содержание моего файла приведено ниже.Я объясню значение каждого параметра который я добавил или изменил. Все добавленные или измененные аргументы идут после аргумента -vmargs.

-name
Aptana
Studio
-vmargs
-Xmx384M
-Xms128M
-Xverify:none
-XX:+UseParallelGC
-XX:+AggressiveOpts
-XX:+UseFastAccessorMethods
-XX:CompileThreshold=100
-Djava.awt.headless=true
-Djava.awt.nativeDoubleBuffering=true

• Xmx384M – максимальный размер кучи (памяти) Aptana может съесть (384Mb). Это значение обычно вычисляется инсталлятором автоматически на основе объема памяти установленной на Вашем компьютере. Увеличьте это значение чтобы дать Java машине больше памяти для кеширования скомпилированного кода
• Xms128M – начальный размер кучи. Минимальный объем памяти используемый Aptana. Увеличение этого значение немного ускорит начальную загрузку
• Xverify:none – пропустить стадию проверки классов при их загрузке. Даёт выигрыш во времени загруки  в 10-15%
• XX:+UseParallelGC – использовать параллельный сборщик мусора. То что надо для современных мультиядерных или мультипроцессорных систем. Дает прирост в производительности за счет выполнения нескольких стадий сборки мусора параллельно
• XX:+AggressiveOpts – включает агрессивную оптимизацию кода. В будущих релизах Java машины этот параметр будет всегда включен
• XX:+UseFastAccessorMethods – без лишних слов увеличивает производительность
• XX:CompileThreshold=100 – этот параметр увеличит начальное время загрузки, поскольку Java машина будет компилировать в инструкции процессора больше методов и быстрее чем это было бы сделано по умолчанию. В результате Aptana будет более «отзывчивой» после загрузки посколько больше кода будет скомпилировано чем транслировано. Это значение обозначает количество раз которое должен быть вызван метод перед тем как код будет скомпилирован в инструкции процессора.
• Djava.awt.headless=true – эта строчка находится в .ini файле по-умолчанию
• Djava.awt.nativeDoubleBuffering=true – использовать «железный» двойной буфер. Не уверен что это работает из-за присутствия опции указанной выше которая говорит AWT что станция не имеет дисплея и клавиатуры.

Результатом изменения .ini файла является более шустрая Aptana, хотя конкретный прирост в производительности зависит от многих факторов. Я также использую цветовую схему Port of Ruby Blue – выглядит довольно неплохо!

Aptana Studio с цветовой схемой "Port of Ruby Blue"