metaclass | Пикейное жилетство от ИТ

Пикейное жилетство от ИТ

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

* Качественный софт на самом деле никому не выгоден, про что упоминает

vit_r

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

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

Flat | Top-Level Comments Only

Ну, вот например, я могу в класс сунуть два поля с типом других классов и таскать это вместе по всему софту. Для этого почти ничего не нужно делать, вплоть до наличия генерик-классов типа Tuple[T1,T2] или, при наличии метапрограммирования, вообще смержить два класса в один новый с объединением множеств полей

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

Ну когда как, я думаю что видел массу фрейворков где это можно сделать.

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

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

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

Правильный Visual UI design это тема (шрифты, цвета, отступы, рамочки, ...), создаваемая на весь UI приложения или набора приложений. Это много высококвалифицированной работы и малый видимый объём на выходе (таблицы и гайдлайны). Далее, имея Logical UI design document приложения, большую часть UI можно сгенерировать.

С другой стороны, наштамповать фотошопом 100500 экранов со "стилем фирмы" может и обезьяна. И обезьянам очень выгодна существующая ситуация, позволяющая получать деньги за такой творческий высер.

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

Именно в мобильных приложениях (до перехода на "одинаковый андроид") под разные модели телефонов писались разные Visual UI design документы. В то же время, Logical UI design приложений (Voice Call, Contacts, Calendar, ...) мог быть общим для всех моделей телефонов одного поколения.

нет не миф, к сожалению. даже если учитывать что абсолютно все стандартизовано. я пилю сейчас приложение в гугловом дизайне (https://www.google.com/design/spec/material-design/introduction.html). Все по полочкам разложено у них. Вот тулбар: кнопка меню, потом заголовок, который у них в примерах "Application", потом еще кнопка справа. Но у меня, в силу непреодолимых обстоятельств, заголовок должен быть не "Application", почему-то, а "Чехол откидной Apple iPhone 5c Ferrari Scuderia Book Type Rubber Red FESCRUFLHPMRE". И все. пездетс. Можно закрывать все эти гайдлайны. Велкам то май ворлд.
А это все от того, что UI - это галимая прикладуха, на самом деле. И выдумывать средства разработки для нее - это бред. Только ручками.
Мы не выдумываем же средства разработки для вновь издаваемых законодательных актов, правильно? Хер знает что они там навыдумывают. Вот и с UI также. Чисто прикладная отрасль.

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

А так - не ручками надо, а инструментами. И не начинать сборку мебели с "выковал топор, пошёл в лес за древесиной".

А что это за причины такие? И кто всю эту чушь в заголовке будет читать?

А что там еще писать? Просто "Чехол"? Тогда на каждом экране будет написано чехол, а в этом нет никакого смысла уже. Этот тулбар на телефоне существунную долю экрана занимает, а значит что-то полезное туд нужно засунуть. Выкинуть тулбар? А как же гайд?
Читает чувак, который выбирает чехол для телефона. Их там сотни и они все и apple и iphone и 5c. Приходится писать этот треш.
Ну и получается, что нельзя просто взять и сгенерить уи. Обязтельно нужно потрхаться.

У товара не может быть столь длинного названия. Что это за ~~стектрейс явовский~~ "Личный Его Императорского Величества Принца Кирну четырех Золотых Знамен именной бомбовоз 'Горный Орел'"? Как это читать, как от других товаров отличать при таком длинном названии? Ну не пишут так для покупателей, в отдельном описании - да, но не на этикетке.

(no subject)

tretiy3.livejournal.com - 2014-09-12 20:36 (UTC) - Expand

а вот соседняя проблема, хехе.

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

нет, никаких трёх кнопок "посчитать" нету. хоткеев тоже не надо. всё должно само.

ps: а теперь аналогичная программа "подгонка катушки индуктивности" с этак десятком взаимоувязанных параметров (диаметр/длина сердечника, диаметр провода, внешний диаметр и длина намотки, индуктивность, собственная емкость. с этими 7 параметрами всё уже веселее, да?)

Проблема в чём? На двунаправленных биндингах оно не делается?

а если полей пять и нужно чтоб было удобно подгонять?

(длина, ширина, высота, плотность, масса параллелепипеда)

Я не знаю, что такое "удобно подгонять", но "длина, ширина, высота, плотность, масса параллелепипеда" пересчитываются за условные 0мс + латенси клиент-сервер. Где проблема?

если поменяли вот это поле и введено вон то поле, то (не) нужно пересчитывать вон те поля.

если в прошлый раз меняли вон то, а в этот раз меняют вот это, то (не) нужно пересчитывать вон те поля.

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

да. проблема тут не в 0мс на сервере на расчет, а в лютом бешеном росте и объёма кода, и числа нужных тестов. и примерно на 8 параметрах эта простая задача превратится в примерно непосильную.

плюс, автосдизайнить гуй под такую задачу - тоже становится крайне муторно

(no subject)

stdray.livejournal.com - 2014-09-12 01:07 (UTC) - Expand

(no subject)

tonsky.livejournal.com - 2014-09-12 08:53 (UTC) - Expand

(no subject)

mechanician.livejournal.com - 2014-09-12 03:48 (UTC) - Expand

(no subject)

metaclass.livejournal.com - 2014-09-12 08:27 (UTC) - Expand

(no subject)

mechanician.livejournal.com - 2014-09-12 10:24 (UTC) - Expand

(no subject)

berezovsky.livejournal.com - 2014-09-12 10:44 (UTC) - Expand

(no subject)

mechanician.livejournal.com - 2014-09-12 12:10 (UTC) - Expand

(no subject)

metaclass.livejournal.com - 2014-09-12 08:22 (UTC) - Expand

Пользователь должен увидеть на экране эти пять полей. И как вы это будете реализовывать - это будет чисто ваша проблема, как разработчика.
Главное, что это должно работать в интуитивно-понятном виде, и не тормозить.

Да сколько угодно.
Проблема в не в GUI, проблема в "вывести из одной формулы все обратные для всех переменных" :)

Как минимум в Qt событие изнутри и изменение пользователем отличаются, так что можно наследовать модель из QAbstractItemMode или как её там, описываете это изменение там (это просто, но мне сейчас лень) и цепляете хоть к таблице хоть к отдельным виджетам; всё должно работать. подозреваю в других тоже так же.

В этом проблема - записать 1 функцию, чтобы оно вывело обратные само.
С гуем проблемы нет - событие, его источник считается первичным и не изменяющимся, по его переменной выбирается одна из формул расчета, в которой эта переменная результат.

Это как обычный диалог выбора цвета, когда одновременно показываются движки RGB, HSV и различные "выбери на кубике". Надо хорошо знать используемый фреймворк, чтобы пресекать зацикливание, но не рокет сайенс.

нет.

у "выбери цвет" всё определяется однозначно, а у параллелепипеда уже не очень.

У параллелепипеда - как захардкодишь распределение изменений, так и будет. Либо нужную теорию, которая будет "стабилизировать систему". Это уже не UI вопросы.

Это Constraint programming?

Требования к галимой прикладухе (UI) по объему строго больше, чем ее реализация. Если брать WPF (где уже возможно разделение обязанностей) или тем более комфортные веб-технологии (Ember), то даже на примитивных кейсах выйдет, что узким местом является аналитик, но никак не технология или ее пользователи (программист и верстальщик).

UI - это почти полностью задача аналитиков и дизайнеров, и только потом верстальщиков и программистов.

Вот, плюс много.

Flat | Top-Level Comments Only