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

[metaclass]

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

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

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

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

Comments

[orleanz.livejournal.com]

" как только про удобный интерфейс гита узнают.

если рассматривать гит исключительно в связке с гитлерхабом, то там всё уже почти нормально

[tiendil.livejournal.com]

Качественный софт выгоден, его просто готовить не умеют :-)

[serge-ivanov.livejournal.com]

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

[eternal-leave.livejournal.com]

Ровно до тех пор, пока не надо слить десять веток, которые друг с другом конфликтуют.

[vit-r.livejournal.com]

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

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

Грубо говоря, как только в фирме появляется менеджер по софтостроению, делать хорошо, быстро и надёжно становится не выгодно.

[metaclass.livejournal.com]

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

[falcrum.livejournal.com]

Ну, индустрия-то вряд ли помрёт вот так - но да: будет кисло...

[max630.livejournal.com]

> Нормальных средств разработки UI как не было, так и нет

Ну вот, опять. Вы вобще что имеете ввиду, мне казалось за последние, я не знаю, 25 лет было вообще всё, и tk, и мышкой на формы кидать, и fudgets, и html5, и так никто и не нашёл То Что Надо чтоли?

[orleanz.livejournal.com]

ну если вот так СРАЗУ десять веток слить, то да. Но это обычно свидетельствует о неправильной организации работы. Не надо ЗАПУСКАТЬ.

[tiendil.livejournal.com]

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

[orleanz.livejournal.com]

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

[metaclass.livejournal.com]

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

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

[max630.livejournal.com]

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

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

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

[insanegigolo.livejournal.com]

менеджер это часто бывший программист.

[justy-tylor.livejournal.com]

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

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

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

[develop7]

ну то есть как нормально
шаг в сторону от workflow (git-flow, github-flow etc) — и за чтением «документации» к гиту незаметно пролетают одни сутки за другими

[max630.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[juan-gandhi.livejournal.com]

Согласен по всем пунктам.

[nicka-startcev.livejournal.com]

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

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

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

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

[tretiy3.livejournal.com]

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

[justy-tylor.livejournal.com]

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

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

[stdray.livejournal.com]

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

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

[stdray.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

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