{development}{python?}Ангелы и бесыРазработчики и Заказчики

Навеяно перепиской в ЛС.
Некоторые лица могут узнать себя. Но это исключительно следствие типичности и характерности описываемых ниже сущностей.
Речь пойдет об часто встречающихся заблуждениях, царящих в умах Заказчиков (далее просто З.) программного обеспечения (ПО) и Разработчиков (Р.) этого самого ПО. Естественно, ПО это заказывается на Python for Series60, PyS60. Я не пишу о том чего не знаю по причинам описанным, кстати, ниже. Ну хорошо, почти не пишу.
Я осознаю некоторую пафосность использованных определений в отношении "заказчиков", обращающихся с просьбой "сбацать прожку" на каком-то там Python, и "разработчиков", бацающих эти прожки в свободное от остальных дел время просто just for fun, забавы ради, но хотите верьте, хотите нет, в "большом мире" отличий не так уж много.
Основные ошибки, которые характерны Заказчикам ПО:
.* Никто никогда не скажет про какое-либо блюдо в присутствии профессионального повара, что оно легко готовится, пускай даже это до боли знакомый салат-оливье.
Никто не будет учить стоматолога как лечить свои зубы, хотя вы знакомы с ними всю жизнь и знаете все трещинки на их поверхности, а этот(а) первый раз их видит.
И так далее, и так далее...
Одним словом ни один дилетант не будет выставлять себя знатоком в присутствии профессионала.
Тем не менее З. часто просит "накатать легкую прожку".
Пардон, кто вам сказал, что она легкая.
Запомните, в Python "легкой" может считаться только программа со стандартным Avkon-интерфейсом, которая не дергает ни какое телефонное API. Ещё бы хорошо, чтобы программе не нужно было никаким образом общаться с пользователем. Но это уже из категории разнузданных мечтаний.
То есть калькулятор какой-нибудь написать - легко, записную книжку - пожалуйста, а вот самый простой конвертер текстовых файлов из одной кодировки в другую - уже нисколько не "легкая" задача.
Потому как только программа становится приложением - а эта волшебная метаморфоза происходит как только Р. пробует первый раз запустить её на исполнение в своей среде разработке (под этим определением может скрываться как специализированный текстовый редактор, так и весь инструментарий Р., типа редактора и консоли для тестирования скриптов) - так вот если при этом Python может оставаться в своей уютной песочнице, то никаких проблем нет, кроме разве чисто "как запрограммировать задачу". В противном случае жестокая реальность запросто может сделать Р. беспомощным.
Взять тот же конвертер. Мало ли. Вдруг несколько файлов окажутся в совершенно другой кодировке - это надо предусмотреть, пользователь вздумается выйти из диалога выбора файлов, не выбрав ни одного - это надо предусмотреть (хотя какого черта ты тогда заказывал приложение, чтобы им НЕ пользоваться, что ли?), файлы окажутся размером в несколько мегабайт - это тоже надо предусмотреть. Хотя, если перечитать перечисленные возможные проблемы, можно заметить, что их должен контролировать юзер, но куда там. Вы же не забыли, что он твердо уверен, что ему требуется "легкая прожка", а таковая по определению не способна доставлять какие-либо неудобства.
.* Зачастую из предыдущего пункта вытекает следующая черта З.: отсутствие четкого технического задания (ТЗ).
Для неР. поясню. Приложение в идеале должно делать то, что хочет З. Совокупность всех "хотелок" называется ТЗ. Причём чём оно подробнее, тем проще Р. разрабатывать приложение, а порой и просто сразу прояснить, что в принципе возможно, а что выходит за рамки возможностей того же Python, чтобы впоследствии не оказалось, что разрабатываемый велосипед предусматривается запускать в космос.
Многие ТЗ выглядят так, как будто З. желает, чтобы приложение при запуске уходило в фон и общалось с ним исключительно через астрал-ментал-логос-универсум-и ещё черт-те что, настолько неконкретные требования и пожелания предъявляемые им. К сожалению "libastral" пока далек от реализации даже для куда более популярных серверных и десктопных операционных систем чем Symbian.
Итак, пока программисты улыбаются предыдущей шутке, а простые смертные недоумевают повторим тезис:
Каждое своё пожелание З. обязан высказывать на этапе заказа, а не на этапе "приложение уже готово". Уважайте чужой труд.
========================
Поскольку З. получили уже на орехи ради справедливости рассмотрим то, в чём можно упрекнуть Р.
Основные ошибки, которые характерны Разработчикам ПО:
.* "Один и тот же у всех лишь Python. Всё остальное разное."
Да, это звучит именно так.
И то на настоящий момент это утверждение ложно.
В общем случае у З. Python может быть установлен либо в память телефона, либо на карту памяти (причём карта памяти тоже не всегда диск E, вполне возможно что это диск F), модули - особенно си-расширения - могут иметь разную версию с модулями Р. и иметь несовместимое API, смартфон может быть "взломанным" или нет, а таинственный демон Ктулху может сделать так, что приложение будет молча аварийно закрываться у З., хотя у Р. демонстрировала отменную работоспособность.
И ни о чём этом З.-ку знать не нужно. А вот Р. нужно знать и помнить, а поэтому быть готовым: показать З., где взять нужный модуль; выуживать из З. с настойчивостью и терпением матери, кормящей с ложки ребенка, информацию необходимую, чтобы составить представление о Python-окружении на телефоне З. Одним словом делать всё, чтобы приложение заработало, если станет понятно, что проблемы не в ошибках в программном коде.
Да, к сожалению Р. приходится как и любому продвинутому юзеру развлекаться сисадминством на Symbian, а куда деваться? Не забывайте, мы пишем "легкую прожку".
.* Python как и любое приложение выполняется операционной системой.
Программы, выполняемые интерпретатором Python, как следствие, тоже выполняются ОС.
Поскольку всё "железо" смартфона используется ОС и мы имеем к нему доступ тоже посредством ОС, то по логической цепочке приходим к очевидному выводу, что Python скрипты могут управлять смартфоном. Ваш КО.
Соответственно, если программа имеет пользовательский интерфейс, значит этот самый интерфейс можно рассматривать как набор рычагов, педалей и кнопок для управления смартфоном.
Лучшие автомобили имеют прекрасное продуманное управление, удобное рабочее место, уютный климат-контроль.
Тогда какого чёрта многие приложения выглядят как запорожец, а то и вообще как самавто?
Вы скажете, что это работа дизайнера (Д.), а Р., как мы выяснили чуть раньше, дополнительной нагрузки сисадмина хватает. Постойте, постойте. Работа дизайнера - сделать пользователю красиво. Сделать пользователю удобно - это всё-таки работа программиста.
=======================
Итак, счёт 2:2 говорит нам о том, что игра была зрелищной, а я скажу, что пора закругляться.
Материал был подготовлен в Dedit от Jbak с помощью клавиатуры моего N82 под аккомпанемент тишины. Потому как вся музыка уже давно спета, а тишина - она всякий раз особенная, наполненная мыслями.