Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
Я вообще удивляюсь такому разделению, это все равно как в автомобильной отрасли механик презирал бы водителеля и наоборот. в принципе, в той сфере тоже такое имеет место быть, вспомним стеб про "прокладки между рулем и сиденьем" = водитель, но с другой стороны "тот не водитель, кто под машиной не лежал", и в нашей стране это особо актуально. Малореально быть механиком и не быть водителем (я лично ни одного автослесаря не знаю не умеющего водить машину), точно так же малореально быть водителем и совсем ничего не знать об устройстве двигателя — хотя бы принципиальную схему, для чего нужен стартер, для чего генератор, а для чего двигатель, все мы представляем, и хотя бы воду залить в бачок омывателя один фиг каждому ездоку придется.
Так к чему это я ? Что профессии эти взаимосвязаны, и профессиональные водилы чаще всего сами ремонтируют свои тачки (за искл. крупного ремонта).
Так почему же столь непонятное разделение на "программистов простеньких сайтов на пхп" и великих гуру, для которых гуй — это западло.
По-моему, без какой-никакой серверной логики не состряпаешь даже "простенькую страничку", если она не статична.
может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот. Во всех местах, где я работал, приходилось от начала и до конца всю разработку осуществлять самому — и странички рисовать, и логику веб-сервера писать, и контролы, и запросы — хранимые процедуры на сервере БД (ах да простите, большинство здесь это тоже называют "простенькими селектами", пусть они иногда на 80 строчек получались .
И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
29.08.05 20:41: Перенесено модератором из 'О работе' — IT
E>может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот.
E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
E>Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
многоуровневая структура это вам видимо пустой звук?
Потому, что многими считается, что разработка GUI это примитивная работа.
С моей точки зрения — это работа весьма сложная — зачастую гораздо более сложная, чем разработка серверного кода.
Кроме того, за подобным отношением многие скрывают банальное неумение разрабатывать этот самый GUI. Легко выглядить профессионалом в глазах заказчика, когда ты делаешь то, в чём он не разбирается. И очень сложно — когда рисуешь формы и экраны, смысл которых ему хорошо виден
E>может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот.
СУБД. Нет там гуя и быть не может (ибо нафиг не нужен). Серверу вообще побарабану, есть где-то гуй, али нет его.
А не любят его — потому-что это скучно. Локализацией заниматься — тоже занятие малоприятное.
Народ все больше творчество любит, относится к професии как к призванию.
P>многоуровневая структура это вам видимо пустой звук?
вот именно что звук — ибо как ПОЛНОСТЬЮ изолировать все уровни, я реально плохо представляю...
Дело в том, что реализация каждого уровня абстракции всегда порождает нагромождение интерфейсов их взаимодействия — и что это целесообразно в большинстве реальных проектов — я сильно сомневаюсь. Как собственно и показывает практика.
Здравствуйте, egaron, Вы писали:
P>>многоуровневая структура это вам видимо пустой звук?
E>вот именно что звук — ибо как ПОЛНОСТЬЮ изолировать все уровни, я реально плохо представляю...
E>Дело в том, что реализация каждого уровня абстракции всегда порождает нагромождение интерфейсов их взаимодействия — и что это целесообразно в большинстве реальных проектов — я сильно сомневаюсь. Как собственно и показывает практика.
для функционирования и кодирования это действительно минус, но он более чем окупается при одновременной работе нескольких человек над разными уровнямии,при поддержке проекта и дальнейших апдейтах. Естественно что если проект на одного и дальнейшей поддержки не планируется, то делать многоуровневость и абстрагировать уровни=зря тратить время.
g_i>СУБД. Нет там гуя и быть не может (ибо нафиг не нужен). Серверу вообще побарабану, есть где-то гуй, али нет его.
Это безусловно так, если в рамках одного проекта, если логику БД разрабатывают абсолютно изолировано от остальных частей приложения.
Но тогда усложняется взаимодействие в команде — в случае полного цикла разработки я взял да написал запрос к БД или процедурку, если она мне понадобилась, а в случае изолированного должен точно и формализованно изложить программисту БД, что должно быть на вх. и что на выходе. что безусловно приводит к дополнительному уровню абстракции. В некоторых проектах это безусловно целесообразно и используется, тут все индивидуально для каждого конкретного случая.
Другое дело — кидайте в меня камнями и помидорами, но я все равно не понимаю, как можно отделить рисование от обработки этого самого рисования !
Здравствуйте, g_i, Вы писали:
g_i>А не любят его — потому-что это скучно. Локализацией заниматься — тоже занятие малоприятное. g_i>Народ все больше творчество любит, относится к професии как к призванию.
Не согласен с Вами. Очень многое зависит от уровня сложности разрабатываемой системы.
GUI позволяет проявить максимум творчества в реализации системы.
Тут и достаточно сложные вопросы проектирования(взять хотя бы стандартные паттерны проектирования — многие из них заточены под UI), также интересные вопросы связаны с реализацией Custom Control'ов.
Не важно какую часть системы Вы разрабатываете — UI или ядро системы. Обе эти задачи достаточно сложны и интересны.
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
1. Профессионалы от остальных отличаются прежде всего умеренностью суждений и уважением собеседника.
2. Зачастую под программистами гуя подразумевают людей которые только и способны что кнопки на форме расставлять. Виной тому обилие псевдопрограммистов которые подвигав эти самые кнопки на формах в дельфи/vb6 считают себя гуру.
3. Проектирование GUI с учетом требований по usability весьма непростая работа, специалистов по которой у нас в стране крайне мало, они неплохо оплачиваются, и на то что их обзывают программистами гуя только улыбаются в ответ (имхо).
Помимо этого:
1. как раз таки хорошо разделять GUI и логику. См. например классический паттерн MVC.
2. server-side программисты как правило не умеют проектировать GUI. К слову большинство desktop разработчиков — тоже. Для этих целей как я уже говорил должен быть или специальный человек или этот навык должен отдельно тренироваться чтением соответствующих книжек и форумов.
3. Программировать для некоторых GUI "западло", потому что сама по себе задача раскидать контролы по форме тривиальна и поэтому неинтересна. Впрочем в лексиконе профессионала слово "западло" не должно встречаться. К таким задачам следует относится следующим образом: Если менеджер хочет стрелять из пушки по воробьям — это его право.
Здравствуйте, egaron, Вы писали:
... E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку.
Зато, скажем, облегчит перевод на другой гуй. Взаимодействие с пользователем нужно отделять от логики — ибо пользователем может быть не только живой юзер, а скажем другая система (например, генерации отчетов).
> В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Это практикуется в основном в небольших по численности проектах, ввиду недостатка узких специалистов .
В этом есть преимущество — в том, что человек представляет проект в целом — в этом-же и недостаток: сложную систему в одиночку трудно поднять. К тому-же быть специалистом во всем — не просто. К тому-же, есть шанс получить в рамках одной системы разный по стилю гуй.
E>Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
Это ты лучше приведи пример, как гуй может жестко зацепить логику. Наверное, для специальных систем, оптимизируемых под какую-то программно-аппаратную платформу (включая АРМ пользователя) это логично.
Даже если гуй где-то завязывается на логику — эту логику надо как-то отделять.
Здравствуйте, egaron, Вы писали:
.. E>Другое дело — кидайте в меня камнями и помидорами, но я все равно не понимаю, как можно отделить рисование от обработки этого самого рисования !
Ивенты от презентационного слоя преобразуются в ивенты и сущности логической модели, обрабатываются, результат возвращается контроллеру приложения который дергает гуй. Чаще всего это происходит на клиенте.
Сервер про гуй не знает.
Здравствуйте, Rand1, Вы писали:
.. R>Не согласен с Вами. Очень многое зависит от уровня сложности разрабатываемой системы. R>GUI позволяет проявить максимум творчества в реализации системы. R>Тут и достаточно сложные вопросы проектирования(взять хотя бы стандартные паттерны проектирования — многие из них заточены под UI), также интересные вопросы связаны с реализацией Custom Control'ов. R>Не важно какую часть системы Вы разрабатываете — UI или ядро системы. Обе эти задачи достаточно сложны и интересны.
Согласен. Но большинству разработчиков гуй все-же неинтересен. Тут нужны некоторые навыки дизайнера что-ли (а еще лучше — задатки, потому-как у нас этому практически не учат). Так-что статистически гуй все-же не любят, народ все больше рвется абстракциями повелевать.
Здравствуйте, egaron, Вы писали:
E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Усложнение разработки — не аргумент. Главное — чтобы пользователю было просто. К сожалению, мы очень часто встречамся с программами, интерфейс которых написан по принципу "Для того, чтобы понять интерфейс, надо понять, как программа устроена". А пользователю надо понимать не то, как программа устроена, а то, как она облегчит выполнение его каждодневных рутинных задач.
Есть отличная фраза: "Идеальный GUI — это одна кнопка во весь экран, на которой написано "Сделать за меня мою работу"." Более яркой иллюстрации принципа отделения GUI от логики не придумать.
Теперь по сути. GUI писать сложно. Порой очень сложно. А красивый и в то же самое время функциональный и удобный GUI — еще сложнее. К сожалению, устойчивое мнение о том, что GUI — это "простенькое клепание страничек, достойное ПТУшников", складывается именно потому, что делать это хорошо (и проектировать, и реализовывать) умеют очень и очень немногие. Интерфейс подавляющего большинства программ не выдерживает никакой критики. Отсюда и выводы, что "такое можно сделать на коленке за один день".
Повышайте уровень производимого вами GUI до такой степени, чтобы им можно было гордиться, тогда не будет мучительно больно...
Здравствуйте, g_i, Вы писали:
g_i>Это ты лучше приведи пример, как гуй может жестко зацепить логику. Наверное, для специальных систем, оптимизируемых под какую-то программно-аппаратную платформу (включая АРМ пользователя) это логично. g_i>Даже если гуй где-то завязывается на логику — эту логику надо как-то отделять.
Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ? Я никогда не видел специалистов, которые бы только "кидали кнопки на форму", не имея понятия о связи с их обработкой.
Или та же страничка .aspx Во всех ее контролах — неразрывная связь с серверной разработкой .... Если изолировать а клепании приложений на ASP.Net серверную логику то что получится ? Рисует тот же дизайнер DataGrid (по начальным условиям не имея представлении о его функционировании). И что он нарисует ? Только HeaderText колонок ? и то он должэен предусмотреть, будет это BoundColumn, TemplateColumn и связь с данными, которые он будет туда биндить ....
А затем приходит программер и дописывает в эти колонки имена столбцов, которые будут биндиться из базы, и саму процедуру ? так что ли ? смешно....
А классический ASP или пхп? когда там между тэгами <% %> — сервер, а остальное — чистый хтмл и переплетаются они буквально по несколько раз за строчку ? Да запутаются просто-напросто дизайнер и программер, отдельно это написавши. А клиентский скрипт ?
в общем , никак не представляю себе дизайнера, ВООБЩЕ НИКАК не связанного с программированием. Разве что картинки или иконки нарисовать .... Отделение логики БД от логики приложения все же представить много проще....
Здравствуйте, dingo, Вы писали:
D>Теперь по сути. GUI писать сложно. Порой очень сложно. А красивый и в то же самое время функциональный и удобный GUI — еще сложнее. К сожалению, устойчивое мнение о том, что GUI — это "простенькое клепание страничек, достойное ПТУшников", складывается именно потому, что делать это хорошо (и проектировать, и реализовывать) умеют очень и очень немногие. Интерфейс подавляющего большинства программ не выдерживает никакой критики. Отсюда и выводы, что "такое можно сделать на коленке за один день".
В крупных конторах, есть такая должность как дизайнер GUI. Теперь представьте что он не программист, а художник. Мне пришлось в одном проекте воплощать в жизнь полёт фантазии такого художника (точнее часть полёта). Так вот, я вам вот что скажу, после этого очень уважаю людей которые кодят интерфейс, такого количества проблем я ни в одном проекте не видел и решать их было очень интересно, хотя и трудно.
PS Многие скажут: "Какие проблемы раскидал контролы и свободен!". Но поскольку разум дизайнера не затуманен знаниями библиотек и внешним видом контролов , мне пришлось все контролы кастомными делать да ещё и динамически меняющими свое поведение в ответ на реакции юзера. Я считаю, что программер GUI уважаемая и весьма сложная работа в проекте(нормальном проекте).
Здравствуйте, egaron, Вы писали:
.. E>Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ?
Это не серверная логика. Это клиентская логика.
E>Или та же страничка .aspx Во всех ее контролах — неразрывная связь с серверной разработкой .... Если изолировать а клепании приложений на ASP.Net серверную логику то что получится ?
"неразрывная связь" — ключевая фраза. Клиент "потребляет" серверную логику, не связанную вообще-то с гуем.
E>А классический ASP или пхп? когда там между тэгами <% %> — сервер, а остальное — чистый хтмл и переплетаются они буквально по несколько раз за строчку ? Да запутаются просто-напросто дизайнер и программер, отдельно это написавши. А клиентский скрипт ?
Не запутаются, если будут следовать четко обозначенному контракту.
E>в общем , никак не представляю себе дизайнера, ВООБЩЕ НИКАК не связанного с программированием. Разве что картинки или иконки нарисовать ....
Я тоже не представляю.
>Отделение логики БД от логики приложения все же представить много проще....
GUI входит в логику клиентской части чаще всего все-таки.
Здравствуйте, g_i, Вы писали:
g_i>Согласен. Но большинству разработчиков гуй все-же неинтересен. Тут нужны некоторые навыки дизайнера что-ли (а еще лучше — задатки, потому-как у нас этому практически не учат). Так-что статистически гуй все-же не любят, народ все больше рвется абстракциями повелевать.
Я лет 6 занимаюсь в основном gui, не сказал бы, что там нет абстракций и всего остального, ну может бизнес-логики нет .
из последних приколов, понадобилось нашим манагерам, не стандартно отображать данные, наваяли: почти дерево
Здравствуйте, egaron, Вы писали:
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
Есть ГУЙ, а есть Гуйня. Просто потому что куча программистов которые научились в RAD средствах кнопки на формы ставить и показывать в Grid-е содержимое БД, называют свою Гуйню ГУЕм это слово тоже приобрело негативную окраску. Хотя хороший ГУЙ сделать это сложная работа, а придумать еще сложнее(последним впрочем больше стоит заниматься дизайнерам и usability expert-ам)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, merlin.fs, Вы писали:
MF>Я лет 6 занимаюсь в основном gui, не сказал бы, что там нет абстракций и всего остального
С этим я не спорю. Я в общем-то о том, что:
1. гуй — все-таки не серверная часть и бизнес-логика на него не должна быть завязана
Это по вопросу "ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ?"
2. гуем не так интересно заниматься — поэтому его чаще и ругают (ибо заниматься им часто заставляют)
Это по вопросу "Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное."
Вообще, зря я в этот тред полез. Крик души — штука монологическая.
У нас небольшая контора, уровени очень грамотно изолированы
0. ПМ, он же ТЗ-шник.
1. Назовем, урове Framework — тот человек (или команда) которые далают компоненты, связанные в единую систему, "кочующий" из прокта в проект код. Нужен не в каждом проекте.
2. Сборщики. (Судя по твоему контексту, именно их ты назвал ГУРУ). Отвечают за реализацию логики конкретного приложения. Обязаны на выходе отдавать рабочую логику с накиданными (хотябы как попало) элементами интерфейса.
3. Дизайнер. Отвечает за иконки и т.д. — на выходе .psd.
4. Верстальщик (ГУЙ-щик?). Задача — причесать вывод от уровня 2 к 3 (правда в 40% уровень 2 появляется до 3).
Так вот. Человек, который способен сделать качественный layout и натянуть его на код (по сути, объединить уровни 2 и 3) — достоин респекта.
Челочек, именно ГУЙ-цик (верстальщик) — нет. ИМХО.
-----------
У нас над проектом ВСЕГДА работают как минимум 4 человека. Все четко распределяет П.М.. Тот, кто отвечает за ГУЙ еще должен набивать базы. Респекта к ним нет.
Здравствуйте, egaron, Вы писали:
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
<>
Потому что серверное программирование — худо-бедно защищено от потока халтуры.
Здравствуйте, egaron, Вы писали:
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
Я не буду здесь обсуждать web-интерфейсы и распределенные приложения, т.к. ими не занимался. Но в среде десктопных приложений так много программ с просто отвратительным интерфейсом .
Я не дизайнер и не верстальщик, при этом задачи "накидать кнопок на формы да побольше" у меня не стоит. Я все делаю — бизнес-логика, GUI, сокеты, инет, обсчеты, все что там может быть.
При этом качественный GUI может занимать 30-60% всего времени на разработку. Написать custom контролы, графики (50% от всего), репорт или редактор, грид, страницы настроек с propertygrid — это бывает гораздо больше, чем логика, все зависит от ситуации. При этом я горжусь результатами труда, своего и коллег.
А рассуждать про "накидать кнопкок на форму" могут только люди, которые просто не видели, как пишется настоящий GUI. Очнитесь, посмотрите вокруг — на MS Office, Winamp, IE, FF, Opera. Поливать их грязью все могут. А много ли могут реализовать интерфейс, хотя бы на 10% такой же удобный и приятный, как в этих программах?
Мне просто жаль людей, которые вынуждены пользоваться убожествами таких вот горе-программистов, считающих себя гуру и обсерающих профессионалов просто потому, что "им это не интересно, это не творческая работа".
ArtemGorikov wrote:
> А рассуждать про "накидать кнопкок на форму" могут только люди, > которые просто не видели, как пишется /настоящий/ GUI. Очнитесь, > посмотрите вокруг — на MS Office, Winamp, IE, FF, Opera. Поливать их > грязью все могут.
Так дело в том, что чаще всего программисты на Delphi кричат, что у них
круто, быстро и удобно делается интерфейс. На поверку он как раз и
оказывается (обычно) "формой с кнопками".
> А много ли могут реализовать интерфейс, хотя бы на 10% такой же > удобный и приятный, как в этих программах?
Сложная задача, по себе знаю
> Мне просто жаль людей, которые вынуждены пользоваться убожествами > таких вот горе-программистов, считающих себя гуру и обсерающих > профессионалов просто потому, что "им это не интересно, это не > творческая работа".
Опять же, все зависит от типа GUI. Если это просто тупая мордочка к БД —
то это действительно неинтересно и скучно. А вот если что-то типа
Word/Visio — уже совсем другое дело, так как фокус смещается c рисования
форм, на создание "логики" для GUI.
Здравствуйте, Cyberax, Вы писали:
>> Потому что серверное программирование — худо-бедно защищено от потока халтуры.
C>Толпы php-шников доказывают обратное
php-программы — это по большей части всё-таки гуй — т.е. клиентский код для презентации чего-то-там на сервере.
(Ну не GUI, а HTML-UI, какая разница?)
E>Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
Файловые системы с одной стороны и файловые менеджеры с другой.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, egaron, Вы писали:
E>>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
К><>
К>Потому что серверное программирование — худо-бедно защищено от потока халтуры.
Как раз наоборот. Халтурщику в нём гораздо легче. Результаты его работы визуально не видны, ну а то, что система тормозит, повисает или падает в результате его работы то это сложно понять, особенно людям не сведущим. Для них тормозит как раз GUI приложение. Ну а что там внутри творится — так это кто их разберёт
Многие хорошие системные программисты убеждены, что халтурщикам в системном программировании делать нечего. С чем я в принципе согласен Однако, в результате, многие из них не подозревают о том, что существует достаточно много фирм, где халтуршики прекрасно занимаются серверным кодом Особенно много таких во внутренних проектах, хотя и в некоторых компаниях они умудряются работать и на внешних клиентов.
Здравствуйте, Cyberax, Вы писали:
C>Опять же, все зависит от типа GUI. Если это просто тупая мордочка к БД — C>то это действительно неинтересно и скучно. А вот если что-то типа C>Word/Visio — уже совсем другое дело, так как фокус смещается c рисования C>форм, на создание "логики" для GUI.
Delpi/Builder это вообще отдельная тема. Эти инструменты возникли на беду в эпоху дикого бизнеса в России, когда у большинства людей даже в столицах представления не было о том, что такое софт и как он должен выглядеть. В результате они породили огромную прослойку псевдоразработчиков, которые с одной стороны достаточно быстро могли накидать бизнес-приложение — БД + клиент с кучей форм, а с другой — в большинстве своём оказывались не способны сделать что-либо ещё.
Большинство из них восновном и занималось рисованием форм с кнопочками, а не разработкой. Хотя бы потому, что разработка включает дизайн, синтез — архитектуры, иерархии классов или хотя бы отдельных классов, что в половине Builder/Delphi/MFC приложений просто отсутствовало к какой-либо форме (за исключением каркса, поддерживаемого посредством визрадов). Притом парадоксально, но занимались они не разработкой GUI, а как раз бизнес-логикой (которая и нужна была заказчику). Интерфейсы подобных приложений редко когда можно было назвать хорошими или удобными, чаще всего они вызывали дрожь в коленках.
Основная работа подобного "девелопера" заключалась в прописывании обработчиков событий от элементов управления, конструировании простеньких (часто однотипных) БД и написании запросов к ним. Большинство из них не видело и даже не слышало не то что о многопоточности, но даже толком не представляло себе и половины возможностей языка связанных с банальными классами. (Для большинства Builder-разработчиков вопрос о различии виртуального и не виртуального методов в C++ явно относился к области высшей математики )
В результате, когда лавочка стала закрываться (времена мелкой островковой автоматизации восновном канули в лету) и спрос стал падать — вся эта банда понеслась устраиваться на работу в другие места. Но поскольку с разработкой они знакомы по сути не были и учить их на серверных программистов было сложнее, чем новичков (у тех хоть мозги свежие, быстрее соображают и учатся — а главное — хотят учиться и не строят из себя "разработчика-со-стажем"), их как правило и сажали на разработку GUI — с которой они были ну хоть как то знакомы. Ну а поскольку их художественные достоинства так же оствляли желать лучшего, всё это очень поспособствовало возникновению мифа о том что разработка GUI дело плёвое и им может заниматься каждый. Ведь в тех командах, где были подобные GUI разработчики — и правда, их мог заменить почти любой. Программировал он лучше (тем более, что о каких-либо спец-контролах речь и не шла), а что до вкуса или дизайнерских способностях — то тут они были примерно равны (а часто даже лучше)
Здравствуйте, g_i, Вы писали:
g_i>Ивенты от презентационного слоя преобразуются в ивенты и сущности логической модели, обрабатываются, результат возвращается контроллеру приложения который дергает гуй.
Ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания...
E>>Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ? g_i>Это не серверная логика. Это клиентская логика.
Под "серверной логикой" вы понимаете логику сервера БД ? Если речь идет о веб-приложении, то серверные обработчики событий кнопок вполне можно назвать серверной логикой. впрочем, это дело терминологии....
Здравствуйте, egaron, Вы писали:
E>>>Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ? g_i>>Это не серверная логика. Это клиентская логика.
E>Под "серверной логикой" вы понимаете логику сервера БД ? Если речь идет о веб-приложении, то серверные обработчики событий кнопок вполне можно назвать серверной логикой. впрочем, это дело терминологии....
Скажем так — бизнес-логика (если она реализована аппсервером) и ниже.
И все-таки так и не понятно — что же есть почетный программерский труд ? Почему большинство проектов большинством здешних обитателей зовется "простеньким клепанием однотипных формочек" ? Что является по мнению обитателей данного форума занятием, достойным настоящего программера ? на этот вопрос так ответа и не дадено господами, не жалеющих эпитетов в стиле "крик души пэтэушника"
И где они, плоды труда "настоящих программеров" ? Когда до сих пор по России даже единой паспортной БД просто НЕ СУЩЕСТВУЕТ (только ВЕДУТСЯ ПЕРЕГОВОРЫ ПО СОЗДАНИЮ.... и это в век информационных технологий. А когда я получал свидетельство о рождении ребенка, то обратил внимание, что программа учета написана на ФоксПро под ДОС)... ужели "простенькую формочку" не наклепать ? не понимаю я чего-то ....
Здравствуйте, egaron, Вы писали:
E>И где они, плоды труда "настоящих программеров" ? Когда до сих пор по России даже единой паспортной БД просто НЕ СУЩЕСТВУЕТ (только ВЕДУТСЯ ПЕРЕГОВОРЫ ПО СОЗДАНИЮ.... и это в век информационных технологий.
Мил человек, ты хотя бы примерно представляешь себе стоимость внедрения единой паспортной базы?
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Кодт wrote:
>>> Потому что серверное программирование — худо-бедно защищено от > потока халтуры. > C>Толпы php-шников доказывают обратное > php-программы — это по большей части всё-таки гуй — т.е. клиентский > код для презентации чего-то-там на сервере. > (Ну не GUI, а HTML-UI, какая разница?)
Если бы Сейчас php-шники уже и логику пытаются писать — натыкался на
проект с самописным сервером приложений на php.
egaron wrote:
> И все-таки так и не понятно — что же есть почетный программерский труд > ? Почему большинство проектов большинством здешних обитателей зовется > "простеньким клепанием однотипных формочек" ? Что является по мнению > обитателей данного форума занятием, достойным настоящего программера ? > на этот вопрос так ответа и не дадено господами, не жалеющих эпитетов > в стиле "крик души пэтэушника" > И где они, плоды труда "настоящих программеров" ? Когда до сих пор по > России даже единой паспортной БД просто НЕ СУЩЕСТВУЕТ (только ВЕДУТСЯ > ПЕРЕГОВОРЫ ПО СОЗДАНИЮ.... и это в век информационных технологий.
Это называется "российский бизнес" (для тех кто не знает). В результате
переговоров проект выиграет та контора, которая предложит больший откат.
Причем итоговый результат работы зачастую вообще не важен, так как
использоваться не будет и нужен просто "для галочки". В итоге, будет
использоваться система на кривом FoxPro/Delphi, которую напишет сисадмин
в самой гос. учреждении.
AndreyFedotov wrote:
> C>Опять же, все зависит от типа GUI. Если это просто тупая мордочка к > БД — > C>то это действительно неинтересно и скучно. А вот если что-то типа > C>Word/Visio — уже совсем другое дело, так как фокус смещается c > рисования > C>форм, на создание "логики" для GUI.
[skip]
> Интерфейсы подобных приложений редко когда можно было назвать хорошими > или удобными, чаще всего они вызывали дрожь в коленках.
Вот такие приложения я как раз и называю ГУЙовыми
> (Для большинства Builder-разработчиков вопрос о различии виртуального > и не виртуального методов в C++ явно относился к области высшей > математики )
Угу, надо было срочно проект как-то на Дельфи сделать. Так как Дельфи я
не знал, то спросил у знакомого Дельфиста: "Как в Дельфе передать объект
по значению?" Ответ был: "Э.... А что это такое?"
> Ну а поскольку их художественные достоинства так же оствляли желать > лучшего, всё это очень поспособствовало возникновению мифа о том что > разработка GUI дело плёвое и им может заниматься каждый. Ведь в тех > командах, где были подобные GUI разработчики — и правда, их мог > заменить почти любой. Программировал он лучше (тем более, что о > каких-либо спец-контролах речь и не шла)
Абсолютно согласен.
> а что до вкуса или дизайнерских способностях — то тут они были > примерно равны (а часто даже лучше)
Вообще нужны отдельные дизайнеры. Например, мои иконки один раз назвали "абстрактным искусством" Да и вообще, лучше программистов не пускать рисовать (хотя исключения бывают).
Абсолютно согласен. Тот кто вообще выдумал термин "гуевый программист" был ламером и байта не нюхал. Начитаются книжек, и высокопроффесионально начинают выпендриваться. Поработает за деньги, начнет понимать почем это стоит.
Разделение все таки есть. И это разделение на системного программиста, и прикладного. Что они делают, серверную логику или клиента это уже неважно.
Слишком системный программист:
Пытается запрограммировать все что горит и плавится. Причем ему не очень важен конечный результат. Ему значительно важней сам процесс. Дай ему волю, может месяцами программировать то, что никому на фиг не нужно. Конечный результат ему практически не виден, и отношение такое-же. Способен нагенерить много багов на строку кода, при этом считает это нормальным явлением. Главное чтобы работало(баги сошлись в нужную функцию). Смотрит на прикладников свысока. Считает что сможет делать их работу в 10 раз лучше и быстрее. Наклепать форму для него как нечего делать. Только форма кривая получается. Но на такие мелочи не обращает внимание. Зачастую даже не знает как работает конечный продукт и по этому поводу отсылает к прикладникам, дескать, не царское это дело. Эго дело обеспечить прикладника инструментами и связь с внешними системами.
Слишком прикладной программист:
Выполняет свою работу. Знает цену своей ошибки, за что и получает по репе. Знает что нужно клиенту. Видит результат и свои ошибки. Хреновый прикладной программист достаточно быстро выявляется и выпроваживается из комманды. Хороший прикладник зарабатывает деньги и кормит системщика. Вот о ком надо песни слагать.
Естественно — хороший программист есть смесь этих слишком.
X>Мил человек, ты хотя бы примерно представляешь себе стоимость внедрения единой паспортной базы?
а ты примерно представляешь себе ее важность ? конечно удобнее взятки давать за ускоренное прохождение запросов по бумажной почте (хорошо хоть не на почтовых голубях), которые из дальних регионов идут порой больше года, а чел не может загранпаспорт получить ... А стоимость маразма под названием "преепись населения" ? А остальные убытки ? так что сомневаюсь что затраты на этот проект не оправданы
Здравствуйте, egaron, Вы писали:
E>а ты примерно представляешь себе ее важность ? конечно удобнее взятки давать за ускоренное прохождение запросов по бумажной почте (хорошо хоть не на почтовых голубях), которые из дальних регионов идут порой больше года, а чел не может загранпаспорт получить ...
Это — проблемы конкретного индивидуума, а не государства
E>А стоимость маразма под названием "преепись населения" ?
А этот т.н. "маразм" по любому придется проводить и при наличии единой базы — для синхронизации с реальны состоянием дел и убиранием систематических ошибок.
E>А остальные убытки ?
Какие убытки?
E> так что сомневаюсь что затраты на этот проект не оправданы
Прикинь:
1) Надо поставить компьютеры во _ВСЕ_ паспортные столы страны. В т.ч. в дальнем Мухосранске
2) Надо обучить персонал для работы с ними
3) Надо заключить договора по всей стране на обслуживание этой компьютерной техники
4) Далеко не факт что в Дальнем Мухосранске будет телефонная линия, способная держать модемный коннект до пресловутого "Единого Сервера". Так что апдейты базы из регионов будут точно так же идти годами голубиной почтой
5) После всего этого в помещении "Единой Базы" возникнет пожар/наводнение/что-то еще, и все бэкапы единой базы в одночасье помрут. И придется ее опять годами восстанавливать. А нормальный администратор, способный предотвратить такой форс-мажор, в здравом уме не пойдет работать по единой такрифной сетке
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, xvost, Вы писали:
X>Здравствуйте, egaron, Вы писали:
E>>а ты примерно представляешь себе ее важность ? конечно удобнее взятки давать за ускоренное прохождение запросов по бумажной почте (хорошо хоть не на почтовых голубях), которые из дальних регионов идут порой больше года, а чел не может загранпаспорт получить ...
X>Это — проблемы конкретного индивидуума, а не государства
Как ни парадоксально, но гос-во для того и нужно чтоб их решать.
Понимаешь, дело даже не в неудобствах каких-то операций. Дело в том, что НЕТ по даже в масштабах страны идентификатора человека, его primary key. Единственным документом, идентифицирующим личность, является паспорт (который даже толком не проверишь настоящий или фальшивый).
Это с точки зрения обработки данных ужасно — почва для создания двойников итд. И вместо "первичного ключа" мы пишет во всех документах "Пупкин Василий Дмитрич, 19лохматого года рождения, паспорт серии такой-то, номер такой, то выдан 1-ым ОМ Мухосранского района Урюпинской губернии, 31 февраля прошлого года" и далее в том же роде.
Проблемы регионов где нет компьютеризации можно путем поднятия данных "наверх" и цетнтрализации в более-менее развитые административные центры в виде первичных документов. что тут изобретать велосипед ?
то что эту проблему решать надо обязательно, перед здравомыслящими людьми вопроса даже не стоит.....
ГУЙ для меня — ругательное слово. Но не потому, что я отношусь к кому-то с презрением, а потому что просто не люблю. Не люблю по очень простой причине — я стараюсь все делать на высшем уровне качества (не всегда успешно, конечно же). Так вот, ГУИ высшего качества — задача огромной сложности. Под сложностью я понимаю трудно обрабатываемую задачу — это термин из теории сложности. Практически для меня это означает, что результат неадекватен потраченным усилиям. Ну скукотааа... Еще раз повторю — это только для меня, с моим субъективным восприятием и моими личными тараканами в голове. То есть, это сугубое ИМХО, которое, как известно всегда побеждает.
Приведу пример, раз уж на то пошло. Дизайнер форм .Net — совершенно отвратительный ГУИ. Предназначен для для создания других ГУЙев, но лучше бы его не было, чесслово. Кажущаяся простота тяп-ляпа приводит к еще большей сложности — даже не сложности — рутинности работы. Получается непомерно много лишних телодвижений (кликнуть сюда, ввести строку, перейти туда, поставить событие... и так 30 раз), так что для нормальной повседневной работы лучше просто редактировать текст. И проблема здесь не столько в халтурности программистов форм-дизайнера (хотя и это тоже), сколько в сложности задачи самой по себе. Это является типичной попыткой решить неуместную задачу. То есть такую, которая заведомо не может быть решена с хорошим качеством.
Другой пример — диалоги vs конфиг-файлы. Главное предназначение диалогов — это профанация, то есть, чтобы любая кухарка... (далее по тексту). Я ничего не имею против этого. Точнее имею, но в несколько другом аспекте. Вот у нас есть диалог опций проекта в VC 7.1 — навороченный, с кучей закладок и списков. Чтобы найти нужную опцию в нем — надо в общем случае вручную тыкать на все эти пипки. То есть, способ тупого линейного поиска, никак не автоматизируемый. Группировка в иерархические структуры при этом никак не помогает, а только больше запутывает. Что мы имеем в конфиг-файле — открываем в редакторе и находим автоматизированным поиском. То есть, глазами нам ничего выискивать не надо, есть кнопка search. Спрашивается, нафига тогда они вообще нужны — эти компьютеры, если в ихних ГУЙах приходится искать нужные опции вручную, как на бумаге?! Да на бумаге как правило даже лучше, поскольку в конце каждой технической книжки содержится алфавиный индекс.
Я ни в коем случае не призываю к "возврату на деревья", то есть, к командной строке или конфиг-файлам. Я призываю относиться к работе отвественно — если уж назвался ГУЙем, предоставь возможности, не меньшие, чем у конфиг-файлов, хотя бы поиск. Кто-нибудь видел хоть раз диалог с закладками и поиском? Вот поэтому, все сегодняшние ГУИ — это просто халтура. А делать "нехалтуру" — это в десятки раз сложнее и дороже, чем лучшие из существующих ГУЙев.
Можно привести множество других примеров — "прозрачный" (яко-бы) copy/paste. Попробуйте скопировать текст из браузера в MS Word (просто Ctrl-C, Ctrl-V) и при этом воздержаться от слов "микрософт выпей йаду". Надо так — Select, Copy. Затем в MS Word: Edit — Copy Special — Unformatted text. Эта операция никак не автоматизируется одной кнопкой! — другой типичный пример халтуры.
Подводя итог. ГУИ — задача гигантсткой сложности, при кажущейся простоте реализации. Именно отсюда растут ноги легиона халтурщиков и дурной репутации ГУИ среди программистов (вполне заслуженной). ГУИ — это прежде всего эргономика, отдельная большая наука. А решать ее пытаются какие-то там программисты (читай — кухарки).
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, IT, Вы писали:
MS>>ГУЙ для меня — ругательное слово.
IT>После прочтения у меня сложилось впечатление, что твои претензии не к разработчикам гуёв, а к Computer-Human Interaction вообще
Здравствуйте, IT, Вы писали:
IT>После прочтения у меня сложилось впечатление, что твои претензии не к разработчикам гуёв, а к Computer-Human Interaction вообще
Филосовский вопрос. Возможно, так оно и есть. Интерфейс водитель-автомобиль в тысячи раз менее объемный, чем интерфес MS Word. Но он требует определенных механических навыков и значительной самодисциплины (так же, как и умение писать карандашом на бумаге). Проблема разработчиков ГУИ в том, что они обещают "щасте всем даром". Мотив понятен — заработать как можно больше денег на кухарках, типа "смотрите как все просто". А на самом деле это очень непросто, поскольку для людей профессиональных этот ГУИ очень быстро становится обузой. А другого — нету, поскольку основная ставка делается именно на кухарок. Ничего не имею против кухарок (и сам такой, во многих аспектах). Я против того, что нет ни малейшей заботы о профессионалах — когда достигаешь определенных навыков, работа с любым существующим ГУИ становится тошнотворной рутиной. ГУИ не дает развития, не дает стимула. В искусстве манипуляций тремя педалями и рулем можно совершенствоваться до бесконечности. В любом ГУИ — наступает потолок, причем очень быстро.
А вот сделать "и вашим и нашим" — и есть задача гигантской сложности, пока что никем не решенная. Трагедия же в том, что большинство программистов ГУИ даже и не подозревают о существовании такой задачи. У свиньи так устроена шея, что она не может посмотреть на небо, поэтому неба для нее и не существует вовсе.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, IT, Вы писали:
IT>>После прочтения у меня сложилось впечатление, что твои претензии не к разработчикам гуёв, а к Computer-Human Interaction вообще
MS>Филосовский вопрос. Возможно, так оно и есть. Интерфейс водитель-автомобиль в тысячи раз менее объемный, чем интерфес MS Word. Но он требует определенных механических навыков и значительной самодисциплины (так же, как и умение писать карандашом на бумаге). Проблема разработчиков ГУИ в том, что они обещают "щасте всем даром". Мотив понятен — заработать как можно больше денег на кухарках, типа "смотрите как все просто". А на самом деле это очень непросто, поскольку для людей профессиональных этот ГУИ очень быстро становится обузой. А другого — нету, поскольку основная ставка делается именно на кухарок. Ничего не имею против кухарок (и сам такой, во многих аспектах). Я против того, что нет ни малейшей заботы о профессионалах — когда достигаешь определенных навыков, работа с любым существующим ГУИ становится тошнотворной рутиной. ГУИ не дает развития, не дает стимула. В искусстве манипуляций тремя педалями и рулем можно совершенствоваться до бесконечности. В любом ГУИ — наступает потолок, причем очень быстро.
С моей точки зрения взгляд интересные, есть разумные, здравые наблюдения и идеи. А вот что я люблю, так это черезмерные обобщения. Что бы утверждать про любой GUI нужно было видеть их все. На что, подозреваю, врядли претендуют присутствующие. Как мне кажется сия концепция родилась на сопоставлении GUI от Microsoft и текстовых файлов а-ля UNIX/Linux Но во-первых — у Микрософта шаблонный GUI — то есть интерфейс уровня "так себе", даже в лучших из их приложений. Потому сравнение уже не корректно. А во-вторых сравнение GUI и текстовых файлов с настройками это всё равно что сравнение яркого с мягким.
Даже когда GUI используется для конфигурирования, он часто не только отображает настройки, но так же используется для учёта множества взаимосвязей, что в сделать в конфигурационных файлах вручную может быть трудоёмко и черевато ошибками. Да и потом, если кто-то забыл — дизайн конфигурационного файла тоже задача интересная — умеючи так можно его сделать, что взвоешь хуже чем от любого GUI В общем в обоих случаях это вопрос дизайна, мастерства того, кто этот дизайн делает и желания вкладывать энергию в этот дизайн.
Ведь те же текстовые файлы ценны не сами по себе — а благодаря наличию GUI — редакторов с функцией поиска. Убери её — и что от концепции останется? А добавь её в GUI?
MS>А вот сделать "и вашим и нашим" — и есть задача гигантской сложности, пока что никем не решенная. Трагедия же в том, что большинство программистов ГУИ даже и не подозревают о существовании такой задачи. У свиньи так устроена шея, что она не может посмотреть на небо, поэтому неба для нее и не существует вовсе.
А если быть чуть проще — цель, достижение которой требует творческого подхода, который явно выходит за рамки тиражирования существующиз решений, особенно — типовых решений от Microsoft
Ошибаетесь !
Есть primary key ! Это номер паспорта , который уникален и который легко проверить , фальшивый или нет (запросом в месный паспортный стол).
Вот кстати опять война на пустом месте разгорелась в топике.
Опять мы забываем что GUI бывают совсем разные.
1. GUI для десктоп приложения , расчитанного на массы. (требование — удобство пользования , простота)
2. GUI одноразовой системы (для внутр. пользования). (требование — дешевизна, скорость разработки)
3. GUI промышленной системы. (требование — стандартизация (соответствие жестко фиксированным нормам ))
....
И спорить о Гуевых программистах, в отрыве от конкретики — неумесно.
Думаю мнение о квалификации Гуистов сформировалось по 2 классу задач. А вот первый класс задач , решают специалисты по эргономике , дизайнеры , и программисты совмесными усилиями . И смею вас заверить это одни из самых квалифицированных и оплачиваемых специалистов.
В общем замечу , что все таки , GUI не самая сложная в алгоритмическом плане задача, но действительно ОЧЕНЬ творческая.
McSeem2 wrote:
> Можно привести множество других примеров — "прозрачный" (яко-бы) > copy/paste. Попробуйте скопировать текст из браузера в MS Word (просто > Ctrl-C, Ctrl-V) и при этом воздержаться от слов "микрософт выпей > йаду". Надо так — Select, Copy. Затем в MS Word: Edit — Copy Special — > Unformatted text. Эта операция никак не автоматизируется одной > кнопкой! — другой типичный пример халтуры.
Вообще говоря, автоматизируется, но надо написать макрос. Кстати, лично
МНЕ нравится, что Ворд сохраняет форматирование при вставках из IE/FireFox.
IT wrote:
> MS>>ГУЙ для меня — ругательное слово. > IT>После прочтения у меня сложилось впечатление, что твои претензии не > к разработчикам гуёв, а к Computer-Human Interaction вообще > Ксати. Насчёт "MS Word: Edit — Copy Special — Unformatted text"... > повбывавбы
Эээ... А что, собственно говоря, не нравится? Ворд по умолчанию копирует
форматированый текст, который может по требованию целевой программы
превращаться в rtf, обычный текст или вставлятсья как Word'овский документ.
minorlogic wrote:
> Есть primary key ! Это номер паспорта , который уникален и который > легко проверить , фальшивый или нет (запросом в месный паспортный стол).
minorlogic wrote: > Ошибаетесь ! > Есть primary key ! Это номер паспорта , который уникален и который легко > проверить , фальшивый или нет (запросом в месный паспортный стол).
В нынешней системе — нет. Паспорт несколько раз меняют (при желании
поменять лишний раз — цена вопроса — меньше 500 рублей в любом раскладе,
плюс не больше трёх месяцев — которые можно проходить с "потерянным и
позже найденным"). Даже свидетельство о рождении не годится — у меня
есть два своих.
Кажется как primary key сделан ИНН, но он технологически есть не у всех,
а при попытке добиться 100-процентного покрытия населения ИНН столкнёмся
(с учётом первичного назначения ИНН) со слишком хорошим совпадением с
пророчествами конца света, что может оказаться социальной проблемой.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Ну и ещё, раз уж пошла такая пьянка, веб-интерфейс RSDN тоже один из лучших LM>Че? Юзабилити на НУЛЕ
Lazy Cjow Rhrr wrote: > McSeem2, > MS>... работа с *любым* существующим ГУИ становится тошнотворной рутиной ... > > Не согласен. Контрпримеры, которые на мой взгляд (естественно всё > субъективно, потому что здесь нет объективных критериев) опровергают > твоё суждение: > > * Vim
Как определить опытного пользователя GViM? Он захотел и научился
отключать toolbar..
А вообще-то там весь toolbar нужен, чтобы пользователь спокойно жил,
пока не выучит двадцать кнопок (:wq, :sp, :e, :w, :f, :q, yy, p, x, d,
b, e, w, :.! ... — всё?) А в консоли я там вообще GUI не наблюдаю.
Командная строка — и удобно. > * FAR
В принципе, да. Впрочем, что-то я уже всё меньше пользуюсь (если свои
настройки под рукой) mc/tc . Командная строка/vim...
Здравствуйте, Cyberax, Вы писали:
C>Вообще говоря, автоматизируется, но надо написать макрос. Кстати, лично C>МНЕ нравится, что Ворд сохраняет форматирование при вставках из IE/FireFox.
Ключевые слова — написать макрос. За всю историю я втретил только одну секретаршу, которая действительно хорошо владела Word' ом. Она заготовила себе шаблоны на все случаи жизни и перестроила Word так, как ей было удобно. Проблема Word'а, imho, в том, что весь процесс создания нормальных макросов скрыт от пользователя. Сложно научиться этому в процессе работы.
В эпоху расцвета настольных СУБД был широко распространен пакет ForPro. Вот он как раз позволял обучаться во время работы. Вот если бы у Word'а было какое-нибудь окошко, в котором бы отображались результаты пользовательских топтаний мышью по кнопкам, возможно, многим жилось бы полегче. Хотя бы потому, что не пришлось бы прыгать от клавиатуры к мыши и обратно. В то же время после нескольких таких прыжков команды, появляющиеся в таком окошке, запоминаются пользователями с гораздо меньшим напряжением сил, чем в результате заучивания их наизусть с помощью всякого рода книжек "для чайников". Вместе с тем, использование команд более эффективно.
Проблему разных категорий пользователей в той или иной мере решает комбинированный интерфейс, включающий как традиционный GUI, так и не менее традиционный интерфейс командной строки. Точнее, разумное их совмещение.
Privalov wrote:
> C>Вообще говоря, автоматизируется, но надо написать макрос. Кстати, лично > C>МНЕ нравится, что Ворд сохраняет форматирование при вставках из > IE/FireFox. > Ключевые слова — написать макрос. За всю историю я втретил только одну > секретаршу, которая действительно хорошо владела Word' ом. Она > заготовила себе шаблоны на все случаи жизни и перестроила Word так, > как ей было удобно. Проблема Word'а, imho, в том, что весь процесс > создания нормальных макросов скрыт от пользователя. Сложно научиться > этому в процессе работы.
Процесс создания макросов ОЧЕНЬ прост — жмем alt-f11, и пишем процедуру
без параметров. Это и будет макрос — его можно забиндить на клавиши,
добавить в любой тулбар или меню, повесить на событие и т.п. Более того,
почти все команды в Ворде имеют интерфейс макросов.
Есть интерактивная запись макросов — менюшка Tools -> Macro. При этом
записаный макрос будет так же виден в VB как обычная процедура.
> Вот если бы у Word'а было какое-нибудь окошко, в котором бы > отображались результаты пользовательских топтаний мышью по кнопкам, > возможно, многим жилось бы полегче.
Именно это и происходит при записи макроса — действия пользователя
отображаются в виде скрипта на VBA.
> Проблему разных категорий пользователей в той или иной мере решает > комбинированный интерфейс, включающий как традиционный GUI, так и не > менее традиционный интерфейс командной строки. Точнее, разумное их > совмещение.
Ну так чем тогда Ворд не нравится? Он замечательно управляется из
внешних скриптов на Perl/VBS/JS/...
Кодт wrote:
> LCR>>Ну и ещё, раз уж пошла такая пьянка, веб-интерфейс RSDN тоже один > из лучших > LM>Че? Юзабилити на НУЛЕ > Дык у других-то вообще ОТРИЦАТЕЛЬНОЕ.
А если в квадрат возвести?
ЗЫ: интерфейс у RSDN очень даже неплохой, но вот система форумов (ИМХО)
как-то подкачала.
LuciferMoscow,
LCR>>Веб интерфейс RSDN... LM>Че? Юзабилити на НУЛЕ
Хорошо, вот тебе аргументы:
1. Лёгкость поиска нужной информации (мягкий поиск, структура в виде дерева).
2. Лёгкость добавления туда своей информации (редактор и т.п.).
3. Лёгкость доступа к нужному форуму, статьям, голосованиям и т.д. (всё та же структура в виде дерева).
4. Функциональная насыщенность. (много чего, просто лень перечислять).
5. Приятный голубой цвет
Это при том, что этот гуи является фронтэндом для большой кучи разнородной информации.
raskin,
R>Как определить опытного пользователя GViM? Он захотел и научился R>отключать toolbar..
Интересный критерий
R>А вообще-то там весь toolbar нужен, чтобы пользователь спокойно жил, R>пока не выучит двадцать кнопок (:wq, :sp, :e, :w, :f, :q, yy, p, x, d, R>b, e, w, :.! ... — всё?) А в консоли я там вообще GUI не наблюдаю. R>Командная строка — и удобно.
Я не спорю, что кривая обучения в виме имеет очень крутую "крутизну". Короче, согласен с тем, что ты пишешь
Но здесь товарищи говорят о том, что для опытного пользователя гуй — это тормоз.
Так вот — Вим — пример гуя, который не является тормозом для опытного пользователя. Более того, как раз для опытного пользователя как раз он и является усилителем продуктивности поэтому и представляет существенную ценность в первую очередь для него (те опытного пользователя).
>> * FAR R>В принципе, да. Впрочем, что-то я уже всё меньше пользуюсь (если свои R>настройки под рукой) mc/tc . Командная строка/vim...
Правильно заточенный ФАР экономит целые месяцы жизни...
Lazy Cjow Rhrr wrote: > raskin, > R>А вообще-то там весь toolbar нужен, чтобы пользователь спокойно жил, > R>пока не выучит двадцать кнопок (:wq, :sp, :e, :w, :f, :q, yy, p, x, d, > R>b, e, w, :.! ... — всё?) А в консоли я там вообще GUI не наблюдаю. > R>Командная строка — и удобно. > > Я не спорю, что кривая обучения в виме имеет очень крутую "крутизну". > Короче, согласен с тем, что ты пишешь
Там на старте пичок. GUI его сглаживает. Дальше очень мягко идёт. И —
всё в процессе, случаёно натыкаясь в help (а также пытаясь понять, что
сделал, положив кирпич на клавиатуру) > > Но здесь товарищи говорят о том, что для опытного пользователя гуй — это > /тормоз/. > > Так вот — Вим — пример гуя, который не является тормозом для опытного > пользователя. Более того, как раз для опытного пользователя как раз он и > является усилителем продуктивности поэтому и представляет существенную > ценность в первую очередь для него (те опытного пользователя).
Смотрим историю — сначала всё было в командной строке, а потом GUI
прикрутили на всякий случай и ограниченный. Естественно он не мешает —
дёрни за верёаочку, верёвочка и отвалится. > >> > * FAR > R>В принципе, да. Впрочем, что-то я уже всё меньше пользуюсь (если свои > R>настройки под рукой) mc/tc . Командная строка/vim... > > Правильно заточенный ФАР экономит целые месяцы жизни...
Правильный *украденный* .vimrc — годы, в течении которых обкатывался
предыдущим хозяином... .bash_profile, опять же.
Чего на старте?
R>GUI его сглаживает. Дальше очень мягко идёт. И — R>всё в процессе, случаёно натыкаясь в help (а также пытаясь понять, что R>сделал, положив кирпич на клавиатуру)
Прям идилия . Сколько килограмм бумаги перевёл на то, чтобы прочитать всякие мануалы?
>> Правильно заточенный ФАР экономит целые месяцы жизни... R>Правильный *украденный* .vimrc — годы, в течении которых обкатывался R>предыдущим хозяином... .bash_profile, опять же.
Здравствуйте, Cyberax, Вы писали:
C>А как, например, мне _удобно_ посмотреть ответы на мои посты?
Поставить RSDN@Home. А что касается веба то такое вобще где либо реализовано?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Lazy Cjow Rhrr wrote: > raskin, > > R>Там на старте пичок. > > Чего на старте?
learning curve. Но я его как-то сам прошёл по F1.. > > R>GUI его сглаживает. Дальше очень мягко идёт. И — > R>всё в процессе, случаёно натыкаясь в help (а также пытаясь понять, что > R>сделал, положив кирпич на клавиатуру) > > Прям идилия . Сколько килограмм бумаги перевёл на то, чтобы прочитать > всякие мануалы?
0, не поверите. vimtutor дочитал недавно. :help много читал.
Много подсмотрено через плечо. И даже linux документации печатно читал
10*A4,
наверное. Справка с экрана — губите поля и реки, а не леса и озёра.
>> > Правильно заточенный ФАР экономит целые месяцы жизни... > R>Правильный *украденный* .vimrc — годы, в течении которых обкатывался > R>предыдущим хозяином... .bash_profile, опять же. > > Ох, не люблю скрипты из чужих рук...
Ясно, что пойдут под переписывание, а только грабли видно. И к сложным
вещам показан подход. Если хотите ходить по воде, не забывайте про
подводные грабли.
Здравствуйте, Cyberax, Вы писали:
>> C>Эээ... А что, собственно говоря, не нравится? >> Мне не надо форматированный.
C>Вы в меньшинстве. Поэтому copy special/paste special и не стоят в C>дефолтных настройках.
Мы вдвоём по сравнению с тобой одним уже в большинстве
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Я вкратце отвечу. Построение идеального ГУИ задача решаемая, но почти не решаемая.
В том смысле, что решение существует, но практически никто не считает нужным его искать.
Но в то, что оно существует — я верю твердо.
К слову, маленькая шпилька.
MS>...Я призываю относиться к работе отвественно — если уж назвался ГУЙем, предоставь возможности, не меньшие, чем у конфиг-файлов, хотя бы поиск. Кто-нибудь видел хоть раз диалог с закладками и поиском?
C C>Процесс создания макросов ОЧЕНЬ прост — жмем alt-f11, и пишем процедуру C>без параметров. Это и будет макрос — его можно забиндить на клавиши, C>добавить в любой тулбар или меню, повесить на событие и т.п. Более того, C>почти все команды в Ворде имеют интерфейс макросов.
Разумеется. Однако после нажатия Alt-F11 у пользователя меняется среда. Документ исчезает, а вместо него появляется среда разработки, похожая на Visual Basic. Это довольно здорово сбивает с толку.
C>Есть интерактивная запись макросов — менюшка Tools -> Macro. При этом C>записаный макрос будет так же виден в VB как обычная процедура.
Но опять-таки на него как-то надо переключиться. А в том же командном окне FoxPro все происходит на глазах у пользователя. Imho, так удобнее.
C>Ну так чем тогда Ворд не нравится? Он замечательно управляется из C>внешних скриптов на Perl/VBS/JS/...
Я разве где-нибудь говорил, что он мне не нравится? Я тоже управлал им из внешних программ. Но это, кажется, уже не GUI. Впрочем, одна вещь мне всегда не нравилась в Word — его редактор уравнений. Вот ему бы строку ввода и какой-нибудь язык описаний формул. В свое время замучился я совсем отчеты готовить. Правда, последние несколько лет я этим не занимаюсь.
Здравствуйте, Cyberax, Вы писали:
C>Эээ... А что, собственно говоря, не нравится? Ворд по умолчанию копирует C>форматированый текст, который может по требованию целевой программы C>превращаться в rtf, обычный текст или вставлятсья как Word'овский документ.
Вот я выставил шрифт, кеглю, наклон и прочие параметры и печатаю. Потом мне потребовалось процитировать фразу из Интернета. Я ее копирую (очевидная автоматизация — не печатать же вручную). И у меня все отъехало. Все параметры становятся какими-то левыми. Здесь мне выгоднее Unformatted text. Это случай 1.
Случай 2 — я копирую таблицу из браузера. Здесь мне выгоднее копировать с максимальным сохранением стилей. Я потом все стили чохом поправлю.
Рискну утверждать, что случай 1 — гораздо более частый.
Далее, предположим, что мы задались целью сделать Paste интеллектуальным, чтобы он автоматически определял, надо сохранять форматирование или же вставлять просто текст. Но у нас нет и не может быть формальных критериев этого в общем случае. Есть лишь некоторые "вторичные половые признаки". И чтобы работало более-менее адекватно, требуется нехилый объем кода. А 100% адекватности не достичь никогда.
Если экстраполировать это наблюдение на ГУИ вообще, то получается, что имплементация хорошего универсального ГУИ требует квадратичного объема работы в зависимости от его функциональности. 100 условных функций — 10000 строк кода. 200 функций — 40000 строк. Ну ладно, может не квадратичного, но всяко круче линейного. То есть, в терминах теории сложности, является трудно обрабатываемой задачей.
На то они и компьютеры (вычислители), чтобы перемалывать задачи класса O(N^2). А когда это приходится делать человеку, это уже перебор. Филосовская сущность программирования переворачивается с ног на голову — не компьютер для человека, а человек для компьютера. Нафига они тогда вообще нужны эти компьютеры?
Если же мы проанализируем ситуацию глубже, то придем к неизбежному выводу, что большую часть индустрии (массовой, конечно же!) составляет именно ГУИ. И эти ГУИ развиваются по пути усложнения для разработчиков, без существенного улучшения функциональности. Фнкциональность растет линейно, а сложность разработки — квадратично. Кому и зачем это надо? Я скажу. Это надо, чтобы накормить армию голодных индусов-халтурщиков. И устроено это по классическим принципам финансовой пирамиды — чем выше к вершине, тем больше денег. А вверху пирамиды — сами-знаете-кто.
Но это же и чревато тем же, чем чревата любая пирамида — рано или поздно рухнет. Вот поэтому ГУИ для меня и является ругательным словом. Эх, куда занесло! Чесслово, хотел ответить кратко.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>К слову, маленькая шпилька. ЗХ>
MS>>...Я призываю относиться к работе отвественно — если уж назвался ГУЙем, предоставь возможности, не меньшие, чем у конфиг-файлов, хотя бы поиск. Кто-нибудь видел хоть раз диалог с закладками и поиском?
Здравствуйте, McSeem2, Вы писали:
ЗХ>>К слову, маленькая шпилька. ЗХ>>
MS>>>...Я призываю относиться к работе отвественно — если уж назвался ГУЙем, предоставь возможности, не меньшие, чем у конфиг-файлов, хотя бы поиск. Кто-нибудь видел хоть раз диалог с закладками и поиском?
.
MS>Я помню об этом. Сколько лет понадобилось, чтобы осознать такую необходимость?
Вопрос "сколько лет?" я отметаю как неконструктивный
Надо просто принимать лучшее, отбрасывать худшее и двигаться вперед. (какой я сегодня оптимистический... может быть оттого, что отпуск обламывается?..)
Здравствуйте, Cyberax, Вы писали:
C>Эээ... А что, собственно говоря, не нравится? Ворд по умолчанию копирует C>форматированый текст, который может по требованию целевой программы C>превращаться в rtf, обычный текст или вставлятсья как Word'овский документ.
Просто обычный результат такого копирования это нередактируемая и нечитаемая раскоряка. С таким же успехом можно выкопировать текст из PDF.
Здравствуйте, minorlogic, Вы писали:
M>А вот в постах выше , речь шла как зар о клиентах к базам данных, что скорее всего ко 2 му классу относится .
M>2. GUI одноразовой системы (для внутр. пользования). (требование — дешевизна, скорость разработки)
Я бы не сказал, что "требование — дешевизна, скорость разработки" здесь однозначно главное. Плавали — знаем. Все зависит от интенсивности использования. Если интенсивность высокая (например, банковские барышни, вбивающие тонны платёжек), то эргономика и удобство навигации выходят на первый план. Например, как минимум кнопки вверх-вниз должны однозначно выполнять функцию навигации по полям ввода, поскольку они находятся рядом с num-pad (это как минимум). В стандартной виндовой схеме событий это реализуется через ж... А мышей в таких интерфесах надо вообще давить.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndreyFedotov, Вы писали:
AF> С моей точки зрения взгляд интересные, есть разумные, здравые наблюдения и идеи. А вот что я люблю, так это черезмерные обобщения. Что бы утверждать про любой GUI нужно было видеть их все.
Признаю, это я конечно загнул. Ну можно отнестись к высказыванию, как к литературному приему — гиперболе.
На самом деле, конечно же имелся в виду коробочный коммерческий mainstream, предназначенный для широкого распространения. А еще точнее — подавляющая масса этого майнстрима.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, korum, Вы писали:
K>У нас небольшая контора, уровени очень грамотно изолированы K> [ skipped ]
K>Так вот. Человек, который способен сделать качественный layout и натянуть его на код (по сути, объединить уровни 2 и 3) — достоин респекта. K>Челочек, именно ГУЙ-цик (верстальщик) — нет. ИМХО. K>----------- K>У нас над проектом ВСЕГДА работают как минимум 4 человека. Все четко распределяет П.М.. Тот, кто отвечает за ГУЙ еще должен набивать базы. Респекта к ним нет.
Прямо дедовщина какая-то получается, честное слово . "Еще должен набивать базы". Бр-р...
У вас там как с текучкой кадров — не слишком большая?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>LuciferMoscow,
LCR>>>Веб интерфейс RSDN... LM>>Че? Юзабилити на НУЛЕ
LCR>Хорошо, вот тебе аргументы: LCR>1. Лёгкость поиска нужной информации (мягкий поиск, структура в виде дерева). LCR>2. Лёгкость добавления туда своей информации (редактор и т.п.). LCR>3. Лёгкость доступа к нужному форуму, статьям, голосованиям и т.д. (всё та же структура в виде дерева). LCR>4. Функциональная насыщенность. (много чего, просто лень перечислять). LCR>5. Приятный голубой цвет
LCR>Это при том, что этот гуи является фронтэндом для большой кучи разнородной информации.
LCR>Ну и где твоё "на нуле"
Для форума инвидиновский движок мне больше нравится
McSeem2 wrote:
> ГУЙ для меня — ругательное слово. Но не потому, что я отношусь к > кому-то с презрением, а потому что просто не люблю. Не люблю по очень > простой причине — я стараюсь все делать на высшем уровне качества (не > всегда успешно, конечно же). Так вот, ГУИ высшего качества — задача > огромной сложности.
Мое ИМХО: GUI должен помогать делать 99% стандартных задач.
Нестандартные задачи можно делать и из скриптов/командной строки.
То есть требовать, чтобы GUI умел _ВСЕ_ — совершенно не надо. Надо
просто требовать, чтобы GUI помогал в большинстве задач.
Пример: FAR — в нем можно делать почти все с помощью встроеных средств,
ну а для чего-нибудь нестандартного — есть командная строка. Word —
через интерфейс можно делать почти все, что угодно, но для расширения
есть Automation-интерфейс и VBA.
Andrei N.Sobchuck wrote
> C>Эээ... А что, собственно говоря, не нравится? Ворд по умолчанию > копирует > C>форматированый текст, который может по требованию целевой программы > C>превращаться в rtf, обычный текст или вставлятсья как Word'овский > документ. > Просто обычный результат такого копирования это нередактируемая и > нечитаемая раскоряка. С таким же успехом можно выкопировать текст из PDF.
Я постоянно копирую текст из PDF в Ворд. Никаких проблем не замечал.
Здравствуйте, IT, Вы писали:
C>>Вы в меньшинстве. Поэтому copy special/paste special и не стоят в C>>дефолтных настройках.
IT>Мы вдвоём по сравнению с тобой одним уже в большинстве
Ну специально для меньшинств в M$ позаботились о макросах... Menu Tools->Macro->Record New Macro. В диалоге Record New Macro вводишь Macro Name (к примеру — PasteSpecialUnformated). Жмешь конпку Keyboard. В появившемся диалоге Customize Keyboard находясь в поле Press new shortcut key жмякаешь комбинацию батонов — можно тот же Ctrl-V или как у меня CtrlShiftV. Жмешь Assign, затем Close. После этого появляется тулбар с кнопками Stop Recording, Pause Recording. Далее жмешь Menu Edit->Paste Special в диалоге Paste Special выбираешь Unformatted Text и жмешь Ок. Затем на тулбаре жмешь Stop Recording и вуаля — теперь у тебя есть Paste Sepecial Unformatted доступный одним нажатием твоей любимой кнопки.
Только не говори мне что тебе влом один раз записать макрос... Хотя если влом то можно и через VB Edition (Alt-F11):
Sub PasteSpecialUnformatted()
Selection.PasteAndFormat (wdPasteDefault)
End Sub
и потом назначаешь этому макросу клавишу через Tools->Customize->Keyboard.
Здравствуйте, minorlogic, Вы писали:
MS>>В контексте обсуждения (начиная с исходного сообщения) было именно это (то есть, майнстрим) и ничто другое.
M>А вот в постах выше , речь шла как зар о клиентах к базам данных, что скорее всего ко 2 му классу относится .
Ну так во втором случае и БЛ (бизнес логика) такая же как и GUI. DataAccess — таже рутина — datareader, dataset (только не надо про фреймворки, давайте обсуждать то что .NET дает, бо фреймворки для UI не менее интересная и сложная, может даже более сложная задача иногда чем фреймворки для бл), Process/Service Layer — ну тоже — по правилам преобразовать и запроцессить данные — тоже в большинстве случаем рутина. Что еще — спроки (stored procedures) — ну что сказать — геморой еще тот.
Понятно что если начать вращать вселенными (извините — абстракциями) то там большое пространство для написания фреймворков, причем зачастую мы или изобретаем в таком случае велосипед или как говорит уважаемый мной IT — фабрику по производству гвоздя, ну так и в UI можно занятся тем же самым. На одном из пред. проектов был сделан такой фреймворк — интересная задача была, только не особо она была нужна (в том контексте), просто так получилось что времени лишнего много оказалось в перерыве (пока архитекторы бодались) вот и разрешил занятся фреймворком человеку.
А люди которые в целом говорят что что-то — не важно BL или UI это фигня и не серьезно — скорее всего относятся к непрофессионалам, или скажем по другому — узкоспециализированным профессионалам считающим все что находится вне их компетенции или неинтересным или недостойным их внимания.
Здравствуйте, BorisKV, Вы писали:
BKV>Ну специально для меньшинств в M$ позаботились о макросах...
Во-во. Навевает анекдот про "доработайте напильником". То есть, не что иное, как перекладывание ответственности с себя на пользователя. "Мы вот вам конструктор LEGO, а вы уж там сами себе дом постройте". А мне не нужен конструктор, мне нужен дом. То же самое относится к мракобесию с dockable windows.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Во-во. Навевает анекдот про "доработайте напильником". То есть, не что иное, как перекладывание ответственности с себя на пользователя. "Мы вот вам конструктор LEGO, а вы уж там сами себе дом постройте". А мне не нужен конструктор, мне нужен дом. То же самое относится к мракобесию с dockable windows.
На самом деле ничего они не перекладывают — большинству пользователей нужна именно отформатированная вставка — я почти на 100% уверен, что у M$ есть соответствующие результаты опросов которые показывают что надо усредненному пользователю. Можно привести много примеров из реальной жизни в которой производители делали вещи с учетом мнения/желания/потребности усредненного пользователя/покупателя.
А про Лего — это скорее относится к .NET + нечто от Infragistics — вот вам кубики — собирите что хотите — при желании можно и ворд сделать. Но я не думаю что вы всерьез считаете что Word это набор кубиков. Это как раз дом, но живущий в нем может кастомизировать его по своему усмотрению, но дом останется домом. А уровень кастомизации как раз зависит от опыта. Чайник — постелит коврик, шторы, венок на дверь и будет счастлив, а профессионал — переделает лестницу, ковровое покрытие заменит, установит датчики чтобы свет автоматом включался и т.д.
А чем вам так Dockable Windows не угодили — хорошая вещь для оптимизации используемого места на экране. Я не очень люблю floating windows — но пристыкованные — они очень даже ничего. Хотя наверное тот ужас что вытворили в VS 2005 — это действительно мракобессие — хотя может я чего-то не знаю и надо просто побольше порабоать...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>А как, например, мне _удобно_ посмотреть ответы на мои посты? WH>Поставить RSDN@Home. А что касается веба то такое вобще где либо реализовано?
Вежливости ради было бы неплохо хотя бы просматривать ответы на свои посты. Ввиду популярности RSDN форумов, если не просмотрел ответы в течении 2-3-х дней, то ветки, в которых участвовал, могут оказаться весьма далеко, и до них порой просто не доходишь. (у меня нет на сканирование вообще всего даже в интересующих темах, я читаю и ввязываюсь в обсуждения выборочно). Т.е. вполне реально порадовала бы возможность, типа GoToNextNonReadedReply как вебе, так и в RSDN@Home.
E>А классический ASP или пхп? когда там между тэгами <% %> — сервер, а остальное — чистый хтмл и переплетаются они буквально по несколько раз за строчку ? Да запутаются просто-напросто дизайнер и программер, отдельно это написавши. А клиентский скрипт ?
Так это считается плохо, а не хорошо. По ряду причин.
Года с 99го в этой области активно продвигают XML, именно для решения этой задачи.
Даже системы, не основанные на XML — типа форумного движка vBulletin — и те имеют понятие "темплейтов" и "стайлшитов".
Госсподи... всесоюзные системы продажи билетов на поезд и самолет были еще при Горбаче. На IBM 360.
X>1) Надо поставить компьютеры во _ВСЕ_ паспортные столы страны. В т.ч. в дальнем Мухосранске
Где-то года с 99-00 компьютеры перестали быть экзотикой даже в Мухосранске.
X>2) Надо обучить персонал для работы с ними
Несложно, если приложение правильно сделано в плане юзабилити. Не сложнее, чем софтина у кассирши в обменнике.
X>4) Далеко не факт что в Дальнем Мухосранске будет телефонная линия, способная держать модемный коннект до пресловутого "Единого Сервера".
Состояние дел со связью в России много лучше, чем кажется некоторым. Особенно везде, где есть железные дороги. И уж телефон во всех госструктурах точно есть.
X>5) После всего этого в помещении "Единой Базы" возникнет пожар/наводнение/что-то еще, и все бэкапы единой базы в одночасье помрут.
Не надо считать разрабочиков систем такого уровня за дебилов. Не может быть в такой системе одного единого сервера. Всегда размазанность по куче серверов.
>А нормальный администратор, способный предотвратить такой форс-мажор, в здравом уме не пойдет работать по единой такрифной сетке
Нормальный администратор (точнее, целая компания солюшн-провайдер) нанимается один раз и пишет инструкцию для дешевого администратора. Дешевые администраторы работают по единой тарифной сетке.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, minorlogic, Вы писали:
M>>1. GUI для десктоп приложения , расчитанного на массы. (требование — удобство пользования , простота)
MS>В контексте обсуждения (начиная с исходного сообщения) было именно это (то есть, майнстрим) и ничто другое.
Вообще у меня сложилось впечатление, что в форуме RSDN разработчики БД и мордочек к ним если и не mainstream, то много.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IT, Вы писали:
IT>Ксати. Насчёт "MS Word: Edit — Copy Special — Unformatted text"... повбывавбы
Та же петрушка в MSVS.
Пришлось редиректить хоткеи с Paste на HTML Paste.
Вот на кой мне левые теги при вставке одного слова в файл *.cs/*.js/*.htm/*.aspx ?
Ибо браузер ложит HTML-код как простой текст. Мож это надо разруливать в браузерах?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>А как, например, мне _удобно_ посмотреть ответы на мои посты? WH>Поставить RSDN@Home. А что касается веба то такое вобще где либо реализовано?
Один программист был прикреплен ко двору военачальника из Ву. Военачальник спросил программиста: ''Что легче спроектировать: бухгалтерский пакет или операционную систему?''.
''Операционную систему',' ответил программист.
Военачальник недоверчиво воскликнул: ''Но ведь бухгалтерский пакет намного проще, чем сложная операционная система!''.
''Это не так'', сказал программист, ''Когда проектируется бухгалтерский пакет, программист выступает посредником между людьми с разными взглядами на продукт: как он должен работать, как должны выглядеть отчеты, каким образом он должен соответствовать налоговому законодательству. Проектируя же операционную систему, программист ищет самую простую гармонию между машиной и идеями. Вот почему операционную систему легче проектировать''.
Военачальник Ву кивнул и улыбнулся. ''Это все хорошо, но что легче отлаживать?''.
Программист не нашелся что ответить.
Мне лень лазить по треду и искать, есть ли уже тут цитаты
Посему извините, если кого-то здесь повторяю...
.
.
Перекуём баги на фичи!
Если нам не помогут, то мы тоже никого не пощадим.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
