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

[metaclass]

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

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

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

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

Comments

[nicka-startcev.livejournal.com]

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

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

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

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

[stdray.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

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

[stdray.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

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

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

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

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

[stdray.livejournal.com]

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

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

Просто пересчитываейте все.

>число таких зависимостей растет как минимум как квадрат числа полей.
Число зависимостей прописано в ТЗ (или выводится из бизнес-логики). Программисту остается реализовать лишь одну ф-цю вида
User State -> (Business Logic )-> Business Result -> User State
где User State - это поля, чекбоксы и все остальное, что видет и трогает пользователь.

>примерно на 8 параметрах эта простая задача превратится в примерно непосильную.
Нет такой зависимости. Если у вас калбак_через_калбак (и мир не синхронный), то да. А в общем случае - нет. И это не общие, а конкретно ваши проблемы.

>автосдизайнить гуй
Это миф.

[tonsky.livejournal.com]

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

> Это (судя по всему) какие-то оптимизации.

Не оптимизация, это подгон под ожидаемое поведение. Эвристика. Если я фиксирую сумму, потом двигаю первое слагаемое, а потом второе, то ожидается что прыгать-скакать должно третье. Тут поведение далеко за уровнем «onClick» и автогенераторов.

[mechanician.livejournal.com]

Почему нельзя разрешить пользователю самому закреплять значения, которые не надо пересчитывать?

[metaclass.livejournal.com]

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

[mechanician.livejournal.com]

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

[berezovsky.livejournal.com]

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

Можно проверять всю форму сразу и потом рассказывать про ошибки. Но тогда заебёшься придумывать, как это внятно объяснить пользователю. Именно по-человечески, что вот это вот не подходит потому что то-то и то-то. Например, тут в одном популярном клиент-банке формочка полминуты обрабатывается, потом падает с несодержательным сообщением.

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

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

[mechanician.livejournal.com]

Можно дать ввести некорректное и подсветить это поле красным. А рядом с полем кнопку с вопросом, по которой открыть окно с комментарием, почему оно красное. В общем, вариантов масса.

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

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

[metaclass.livejournal.com]

У меня такое работает на 20 полях вычисления земельного налога :)

[serge-ivanov.livejournal.com]

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

[metaclass.livejournal.com]

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

[max630.livejournal.com]

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

[metaclass.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[nicka-startcev.livejournal.com]

нет.

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

[justy-tylor.livejournal.com]

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

[victorgr.livejournal.com]

Это Constraint programming?