Паттерны ООП в примерах для iOS

А есть более конструктивные предложения? :)

Да, есть толпа, которая называет чёрное белым MVP — MVC. И Stanford University туда же. На Stackoverflow есть заплюсованный ответ, что MVP — это разновидность MVC. Смотря что считать контроллером.

Вопрос в том: мы с вами что можем сделать? Ну, я дополню пост инфой из данного обсуждения. И всё? Если да, то куда мы против Стэнфорда.

Паттерны ООП в примерах для iOS

Дополнил пост разделом «Что почитать?»

Одним выстрелом не получится! У каждого своя голова. Сам Страуструп говорил, что он знает ООП «на троечку» (цитату сейчас не могу найти, но смысл такой).

Паттерны ООП в примерах для iOS

Вот и переводи после этого статьи. :) Значит, Cocoa MVC — вовсе не MVC…

Про детей, боюсь, поздно думать, потому что в Стэнфорде уже 4 года учат именно так (и без приставок типа «Cocoa MVC»).

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

P.S. Просьба не кидать тапками, но вот читаю Фаулера, не вижу ничего криминального в MVP.

Задумка-то хорошая

To approach MVP I find it helpful to think about a significant mismatch between two strands of UI thinking. On the one hand is the Forms and Controller architecture which was mainstream approach to UI design, on the other is MVC and its derivatives. The Forms and Controls model provides a design that is easy to understand and makes a good separation between reusable widgets and application specific code. What it lacks, and MVC has so strongly, is Separated Presentation and indeed the context of programming using a Domain Model. I see MVP as a step towards uniting these streams, trying to take the best from each.

Паттерны ООП в примерах для iOS

О! Вещь. :)

Эт я понимаю

Паттерны ООП в примерах для iOS

Ну вот я сейчас в роли ПМа затягиваю сроки сдачи проекта исключительно из-за качества кода.
// Не реклама, все вакансии заняты. :)

Паттерны ООП в примерах для iOS

этот ужас писали как раз инженеры Apple

Или специально нанятая команда индусов. :) Я больше склоняюсь к такому варианту.

Инженеров Apple NeXT, плодами которых пользуются инженеры Apple, я только хвалю:

а почему не проверили (albumIndex >= 0)? Автор туториала об этом не подумал, а создатели класса NSArray подумали

Математический фокус для MP3, JPEG и Гомера Симпсона

Можете папку расшарить? :)

Путь от идеи до макета. Размышляя о концепции продукта

=)

Ну, то, что я Жене перед выступлением объяснял. Из тестового задания:
© Макс Ткачук paz0r, ладно уж. :)

— Результаты первой итерации тестирования. Какие мы сделали выводы?
— Результаты второй итерации тестирования. Какие мы сделали выводы?
…
— Конечный интерфейс.

Первые два пункта не менее важны, чем последний. Эта мысль очень согласуется с моим некоторым опытом тимлида/ПМ: когда представляешь решение, ключевую роль имеет обоснование данного решения, в данном случае исследование и выводы из него. Тем самым включается голова у заказчика, он начинает думать, анализировать (а не просто прикидывать, крут ли UI). Вот об этом human-centred design.

Есть ощущение, что ты слишком подстраиваешься под заказчика, чего ему, может быть, не надо. «Как — не надо?!!» Что я имею в виду: вот разница между двумя вопросами заказчику:
— Вам какие нравятся шары, красные или зелёные?
— Мы провели исследование, юзеры при виде зелёных шаров чаще испытывали чувство удовлетворения. Оставляем зелёные? Или исследуем дальше по подгруппам, имеет ли смысл показывать одним красные, а другим зелёные?

P.S. Кроме «чувства удовлетворения», могут быть любые другие UX-метрики, о которых на WUD много говорили, ждём материалы докладов, media_magnit обещала, что выложат.

Путь от идеи до макета. Размышляя о концепции продукта

Отличная аналогия с искусством!

Но в конце я не понял: где тут про юзабилити? Мы типа провели коридорное тестирование — что будем делать с его результатами? Что если они сломали нам мозг? Что если юзер совсем не такой, как мы представляли? Да, согласен, можно так провести «тестирование», что оно точно не сломает наши изначальные шаблоны. Так его и проводят очень многие, что неправильно.

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

— Результаты первой итерации тестирования. Какие мы сделали выводы?
— Результаты второй итерации тестирования. Какие мы сделали выводы?
…
— Конечный интерфейс.

Тогда это будет серьёзный разговор, а не «о вкусах не спорят».

P.S. Копирайты ставить не буду, они есть у меня в профиле, в предыдущих постах.

«Мы вам обязательно перезвоним»

Отдельное спасибо тем соискателям, которые на отказ отвечают: «Спасибо, не проблема.»
Вы делаете HR'ов лучше. :)

«Мы вам обязательно перезвоним»

А если серъезно, то людям просто неприятно сообщать плохие новости.

Скажу ещё серьёзнее: нужно хорошо работать над собой, чтобы регулярно сообщать отказы.

Мне пришлось за полгода сообщить примерно 50 отказов (хотя я не HR). У нас очень высокие требования к тесту, поэтому каждый второй спрашивает: «почему?» и иногда в довольно резкой форме, т.к. он потратил несколько часов на тест. Нужны хорошие нервы, чтобы после десятков таких «почемучек» продолжать сообщать отказы.

ГОСТ по юзабилити

О, Дмитрий, спасибо за выступление на WUD, пост написан по Вашей наводке. :) Ну и не только пост, а вообще как-то мозги повернулись.

ГОСТ по юзабилити

ГОСТ — просто перевод аналогичного ISO

Заявлено так. Очень хотел сравнить, но не нашёл полного IS'ходника дешевле, чем 4.5 килорублей.

ГОСТ по юзабилити

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

Нет процедуры => невозможно сказать, ГОСТ выполнен или нет.

ГОСТ по юзабилити

Не любой. Вот этот нормативный акт — просто набор советов, best practices.

Как я сходил на World Usability Day

Там главное две вещи:

1. Сам процесс: тимбилдинг, мозговой штурм, непредсказуемые юзеры, сжатые сроки.

2. Почти постоянное наблюдение со стороны профессионала. Из поста:

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

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

Проблемы перехода в менеджеры среднего звена — это проблемы?

Да ладно, в песочнице обычное весенне-осеннее обострение.

Ломаем iOS-приложение! Часть 2

Вы дочитали до этого коммента? Сюрприз! #include <sys/ptrace.h> не работает на реальном устройстве. Решение:

#import <dlfcn.h>
#import <sys/types.h>

typedef int (* ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#if !defined(PT_DENY_ATTACH)
#define PT_DENY_ATTACH 31
#endif  // !defined(PT_DENY_ATTACH)

void disable_gdb() {
  void * handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
  ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");
  ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
  dlclose(handle);
}

Далее в функцию main() добавить:

#ifndef DEBUG
    disable_gdb();
#endif

И, наконец, обфусцировать константу "ptrace" (домашнее задание). Всю эту инфу прислал автор одной статьи, которая лежит в песочнице и очень ждёт инвайта.

Как я сходил на World Usability Day

Подход один: слушай юзеров.

Задавай вопросы. Именно чтобы почувствовать, «в какую сторону» ему будет удобнее… ведь «в лоб» не спросишь.

Как я сходил на World Usability Day

Надеюсь, paz0r не против. :) Остальные участники, кто не с хабра, если есть что добавить, пишите на почту [e-mail].

Задание на пол-листа A4. Вкратце:

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

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

Ожидаемый результат:
1. Какие сделаны выводы из 1-го тестирования?
2. Какие сделаны выводы из 2-го тестирования?
3. Само приложение на больших листах — см. последнее фото в посте.

На всё полтора часа, примерно три brainstorm-итерации по полчаса: проектируем, рисуем, тестируем.

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

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

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