Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 13.02.06 16:52
Оценка: 201 (26) +7 -1 :)
Здравствуйте, VladD2, Вы писали:

http://www.rsdn.ru/Forum/Message.aspx?mid=1670280&only=1
Автор: VladD2
Дата: 09.02.06

VD>Эффективность такой экстенсиной разработки стримительно стремится к нулю. Не прийми это на свой счет, но ты даже не осознашь насколько не эффективно ты трудишся.

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

Лично я стремлюсь к тому, чтобы быть уникальным специалистом в своей области и стать "широко известным в узких кругах". Например, я сейчас работаю над неким алгоритмом, который всего-то навсего занимает порядка 50K в исходниках (очень размашистым стилем, и с подробными комментариями). Я его уже переделывал почти с нуля три раза и планирую переделать еще как минимум пару раз. Некоторые варианты являются просто тупиковыми, но этого не понять, пока не попробуешь сделать. Таким образом, задача одновременно является решенной и нерешенной. Решенной потому, что уже готово к промышленному применению (и применяется) с некоторыми ограничениями. Нерешенной потому, что надо еще работать и работать чтобы снять эти ограничения — такова сущность задачи. И планирую я это дело примерно на полгода. В сухом остатке — те же 50K исходников и один (один!) класс (конечно же, по ходу работы я надубасю под мегабайт исходников, но они все уйдут в мусорку). Собственно, это может быть даже и не класс, все можно сделать хоть на голом Си — язык вторичен. И что характерно, все эти мои "капризы" очень высоко оплачиваются — и это при том, что результат не гарантирован! Вот это для меня — настоящая задача, я бы даже сказал, битва, а я в ней — доблестный воин

Рассуждать о проектировании и средствах разработки здесь смешно. Хоть в ноутпаде, хоть в студии с кнопочками — разница невелика. А критерий эффективности для меня — работать над интересной нетривиальной задачей за хорошие деньги — так сказать и рыбку съесть и на люстре покачаться. А повышать "эффективность труда" в понимании Влада — это для меня тоска зеленая. Это все равно станок и все равно ты за ним стоишь и прикручивашь "шашечки к вишенкам" — более ничего. Тривиальные задачи мне не интересны, и поэтому работать над ними для меня — не эффективно по определению. И наоборот — в понимании Влада я, наверное, рекордсмен по неэффективности.

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

        Что такое гранфаллон? Хочешь ты узнать,
        Надо с шарика тогда плёнку ободрать!

    В качестве примера гранфаллонов Курт Воннегут приводит всякие партии, 
    в частности: Дочери американской Революции, компанию Дженерал Электрик 
    и Международный орден холостяков — и любая нация в любом месте в любое 
    время.

Стремление к повышению эффективности труда при помощи средств разработки — это тоже гранфаллон. И чем больше автоматизации, тем более тупой работой приходится заниматься. Яркий пример — дизайнер форм в студии. Более рутинной и неблагодарной работы (тяп-ляпать формы, а потом разруливать всякие события), трудно себе представить. И трудно с этим спорить. Это дает средства к существованию бедным голодным индусам (что очень гуманно), но одновременно погружает человечество в пучину профанации. Так что это палка о двух концах. Ну вот будешь ты всю жизнь пахать, изучая все новые и новые языки и технологии и под конец жизни поймешь, что твой разум напоминает комнату, до потолка заваленную бульварными романами для одноразового прочтения. Это что — эффективно? Я бы назвал это бездарным транжирством невосполнимого ресурса — своей жизни. А у нас не так уж и много времени на этой земле. Взять, например, Дейкстру — его именем названы алгоритмы и это будет жить в веках. Вот это я называю эффективностью. Это то, к чему имеет смысл стремиться. Не думаю, что мне удастся что-то в этом роде, но я хотя бы стараюсь.

Я ни в коем случае не пытаюсь навязать свою точку зрения. Нет ничего унизительного в грязной работе по проектированию и дизайну форм в дот-нет студии (ну кто-то же должен — да мне и самому приходится это делать).
Поэтому просьба не принимать на свой счет, это просто лично мне не нравится весь этот лохотрон. Ну вот не нравится и все тут. Мне нравится свой лохотрон.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 23:20
Оценка: +2 -21 :)))
Здравствуйте, McSeem2, Вы писали:

MS>Верю. Но позволь мне угадать. "твердым, тяжолым и хрупким" — это было что-то связанное, например, с COM, или, что-то другое, но обязательно с тяжелым полиморфизмом, множественными наследованиями, фабриками классов и прочими "прелестями".


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

Так что не стоит искать решение в его ограниченности или в том, что он не сталкивался с задачами где С++ способен проявить чудеса программирования.

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

Но именно это ты и твои соратники скорее всего никогда не сделате. Вы удобно устроились в роли эдаких снобов критикавно. Сами пробовать не хотите, но чуть что не применете вылить ушат ехидной критики. При этом еще сделате вид, что мол разновариваете с мальчиками с гряной попой и не забудете провести парочку оскорбительных аналогий, назвать все то что не хотите освоить или просто понять поделками цель которых украсть у вас хлеб и отдать индусами и т.д., и т.п.

Ну, что же. Видимо такова ваша роль. Я же в который раз убеждаюсь, что к общему мнению мы не прийдем. Так что пора кончать эти споры.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 01:13
Оценка: 56 (5) +3 -2 :))) :))) :))
Здравствуйте, McSeem2, Вы писали:

MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?


В том числе, только с противоположным знаком.

MS>Лично я стремлюсь к тому, чтобы быть уникальным специалистом в своей области и стать "широко известным в узких кругах".


Лично мне это всё напоминает известную сказку про блошиного мастера Левшу

MS>Например, я сейчас работаю над неким алгоритмом, который всего-то навсего занимает порядка 50K в исходниках (очень размашистым стилем, и с подробными комментариями). Я его уже переделывал почти с нуля три раза и планирую переделать еще как минимум пару раз.

Кашмар, какая скука

MS>И что характерно, все эти мои "капризы" очень высоко оплачиваются — и это при том, что результат не гарантирован! Вот это для меня — настоящая задача, я бы даже сказал, битва, а я в ней — доблестный воин


А это мне больше напоминает мазахизм, а не доблесть Воин, блин

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

MS>Все эти яростные приверженности к определенным языкам, средствам проектирования и рефакторинга — это ложный карасс, гранфаллон.

Это банальная зависть к людям, которые находятся на острие технологий

MS>Стремление к повышению эффективности труда при помощи средств разработки — это тоже гранфаллон.


А это говорит твоя лень.

MS>И чем больше автоматизации, тем более тупой работой приходится заниматься. Яркий пример — дизайнер форм в студии. Более рутинной и неблагодарной работы (тяп-ляпать формы, а потом разруливать всякие события), трудно себе представить. И трудно с этим спорить. Это дает средства к существованию бедным голодным индусам (что очень гуманно), но одновременно погружает человечество в пучину профанации.


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

MS>Так что это палка о двух концах. Ну вот будешь ты всю жизнь пахать, изучая все новые и новые языки и технологии и под конец жизни поймешь, что твой разум напоминает комнату, до потолка заваленную бульварными романами для одноразового прочтения. Это что — эффективно? Я бы назвал это бездарным транжирством невосполнимого ресурса — своей жизни.


Ну да, гораздо лучше 42 раза переписать одни и теже 50к кода.

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


Он был программист или математик? У меня есть подозрение, что можно быть либо классным программистом, либо отличным математиком. Можно быть и двумя сразу, но средними Ты, кстати, кем себя больше считаешь?

MS>Я ни в коем случае не пытаюсь навязать свою точку зрения. Нет ничего унизительного в грязной работе по проектированию и дизайну форм в дот-нет студии (ну кто-то же должен — да мне и самому приходится это делать).

MS>Поэтому просьба не принимать на свой счет, это просто лично мне не нравится весь этот лохотрон. Ну вот не нравится и все тут. Мне нравится свой лохотрон.

Ну да. Ну ты тоже если что не обижайся Мне вот, например, образно выражаясь, больше нравится строить мосты, небоскрёбы и пирамиды эфиопсов, чем убивать тысячами ни в чём не повинных блох, тщетно пытаться подковать хотя бы одну.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 07:20
Оценка: 28 (7) +8
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>т.е. эффект это результат. А простите меня за неразумность, но какой результат может быть определен, когда *один* класс разрабатывается уже полгода??? Вы продали этот класс или собираетесь продать его за $12000 (это и то по минимуму)???
AAV>Нет, понятие эффективности не подразумевает интересность процесса, и Вам не интересно работать над дизайном формочек в студии, а вот заказчику не интересно платить $12000 за 50 килобайт не пойми чего, того, что, по вашему мнению, должно работать... Поэтому Вы не эффективны, и для заказчика вы слабое звено…

AAV>Эффект это добыча, а какая была стойка у охотника это уже не важно. А добыча это в первую очередь пропитание своему племени, так было, так есть и так будет.


Видишь ли, в чем дело. Нетрудно подсчитать, что возможных ASCII-текстов длиной в 50 килобайт значительно больше, чем элементарных частиц во вселенной.
Поэтому за некоторые последовательности такой длины могут заплатить и $120000. И для заказчика слабое звено — это как раз те, кто не может написать эти 50 килобайт.
Я понимаю твою точку зрения. Но перед тем, как решать за заказчиков Максима, кто будет слабым звеном, неплохо было бы ознакомиться с результатами его труда. Вот например здесь есть прямое свидетельство того, что компания Microsoft фактически выкинула деньги, вложенные в GDI+, на ветер. Вместо того, чтобы платить "сильным звеньям", способным за полгода наколбасить мегабайт исходников, им было бы значительно дешевле нанять одного Максима. А результат оказался бы лучше.

Выводы, справедливые "в среднем", иногда неприложимы к частностям.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:19
Оценка: :))) :))) :))) :))) :)
Здравствуйте, WolfHound, Вы писали:

WH>Я бы не стал делать столь категоричные заявления. У меня в свое время были просто жудкие мигрени. Ничего не помогало. Но гомеопату удалось их свести практически к нулю.


Может это потому что ты как раз в это время перешёл на C#?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 13.02.06 17:45
Оценка: 27 (4) +5 :)
Здравствуйте, McSeem2, Вы писали:

MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?


[... skipped ...]

Знаешь, большое количество кода тоже вовсе не означает, что этот код рутинный, непрофессиональный и включает в себя только лишь кучу формочек и типизированные датасеты, столь услужливо генерируемые студией. Бывает ещё такой зверь, как Enterprise Application. Этот зверь — не узкоспециализированная библиотека и содержит он обычно гораздо больше кода, чем эта библиотека. Ещё этот товарищ всегда другого цвета — не бывает двух одинаковых EA Кому EDI подавай, кому medical insurance, а кому и property management. И используется EA только один раз — не серийный это продукт.

А самое обидное то, что готового каркаса для типового EA никогда нет! И приходится педалить довольно много кода, который и будет этим каркасом. Такого базового, нерутинного кода, который будет составлять основы основ продукта. И работу над которым никак не назовёшь "грязной работой по проектированию и дизайну форм в дот-нет студии". И вот тут рефакторинг будет очень даже к месту — тут без этих шашечек просто не уедешь.

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

PS: В зашиту всех разработчиков Enterprise Application-ов
Re[9]: Философия эффективности труда
От: Павел Кузнецов  
Дата: 14.02.06 22:21
Оценка: :))) :))) :)))
Здравствуйте, WolfHound, Вы писали:

WH> когда я начал работать на C# с решарпером у меня появилось ощущения что я работаю с чемто очень мягким, легким и пластичным.


"Имя, сестра, имя!" Какой оно температуры и цвета?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[8]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 09:00
Оценка: 40 (2) +6
Здравствуйте, Дарней, Вы писали:

Д>Ага. А еще рисует дизайн для кнопок, администрирует систему и отвечает на запросы юзеров. В общем — и чтец, и жнец, и на дуде игрец.

Д>Проектированием, к примеру, должен заниматься отдельный человек. На обычного программиста обычно возлагается только микропроектирование. А то десяток программистов такого напроектируют, что чертям тошно станет.

Это очень примитивный взгляд на программирование. Да, действительно, если у нас есть 10 программистов, то для того, чтобы архитектура изделия не разъехалась нужен кто-то, кто будет координировать. Ты знаешь, тут недавно сравнили понятие "программист" с понятием "врач". Ты наверняка читал. Так оно и есть. И есть микропроектирование. Это твои слова. А это подразумевает уже гораздо более широкую область знаний, чем кодирование.

Потом. Для всех любителей отделять мух от котлет. Технология жесткого разделения труда программистов на архитектуру, проектирование, кодирование, отладку и поддержку не работает. То есть конечно можно в большом коллективе расставить акценты — кто чем больше занимается (даже нужно), но в чистом виде организовать конвейер в принципе невозможно. Потому как процесс неделимый. Я придумал, попробовал написать, потом еще подумал, потом переписал, потом занялся отладкой, поддержкой, потом все снова, но уже не с чистого листа (это здорово экономит время и деньги). И никак иначе.

Потом, просьба не передергивать, а отвечать по существу. То есть я не говорю и не говорил: "А еще рисует дизайн для кнопок, администрирует систему и отвечает на запросы юзеров". Это взято с потолка. Зачем — мне непонятно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Философия эффективности труда
От: mrozov  
Дата: 01.03.06 16:58
Оценка: 5 (1) -3 :))) :)
Это все, конечно, очень благородно, но...

Давайте попробуем себе представить деревню во время посевной. Ежели я в проведении аналогий где-то сильно облажаюсь — просьба сильно ногами не пинать, я парень городской. И вообще — не воспринимайте слишком серьезно.

Значица — посевная. Народ — пашет по-черному. План по валу, вал по плану, все дела.
И посредине всего этого — деятель, а-а-аккура-а-аатненько так сажающий зернышко за зернышком. Перед тем как
посадить — каждому поет колыбельную. Угол и глубину посадки без отвеса и штангенциркуля мерить даже и не берется. Собственно, процентов 30 времени он не сеет, а совершенствует инструментарий.

На каждое зернышко капает из пипетки особым раствором — по его данным, урожайность от него аж на 7.3% выше, чем при использовании стандартных удобрений. Ежели угол посадки его не удовлетворяет, он выкапывает зернышко и сажает его повторно. Вообще, в определении идеальных угла и глубины посадки он — лучший в районе. Есть даже подозрение, что на международном состязании по точечному засеву он вошел бы в десятку. Жаль, что таких соревнований нигде не проводят.

На замечания окружающих, что занимается он х@@@й и другие за то же время засевают в 100 раз больше гордо отвечает, что вышеупомянутым недостойным делом занимаются как раз все остальные. А именно — тупой и монотонной работой, которая ему неинтерестна. Он — Творец и Мастер. На его участке урожай на 30% выше, чем у всех остальных — и это далеко не предел. О позапрошлом сезоне, когда семейство долгоносиков сожрало весь его урожай (4 квадратных метра) он предпочитает не вспоминать. Не ошибается тот, кто ничего не делает.

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

Университет, вкладывающий миллиард долларов ежегодно в разработку удобрений и комбайнов нового поколения их тоже не смущает — куда этим криволапым мелко-очкастым до нашего Василия Пупкина! Всех порвем, не впервой!

И что любопытно — никаких причин жалеть Васю Пупкина нет и быть не может. Он вполне себе счастливый человек. А вот кого можно и нужно пожалеть, так это директора местного совхоза "Назад в коммунизм". За что ему такое счастье?
Re[4]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 13:34
Оценка: 3 (2) +6
Здравствуйте, Oyster, Вы писали:

КДВ>>Решарпер мозгов не отнимает. Кодирование занимает достаточно малый процент времени, а решарпер его просто может несколько сократить (автоматизировать)


O>+1. В автоматизации рутинных операций и заключается его прелесть (речь, конечно, не о формочках ).


Главная прелесть рефакторинга не в автоматизации как таковой, а в возможности больше экспериментировать с кодом, не боясь что это потребует много времени.
Т.е. например ты понимаешь что класс стал слишком большим, но чтобы его разрезать на несколько надо сначала вдумчиво исследовать зависимости внутри него, потом долго переделывать внешний код, а потом еще и отлаживать все что поменял. Подумаешь и решишь — ну его нафик, времени уйдет много, а эффект вобщем то не такой уж и большой, и так сойдет.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[10]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 16.02.06 10:13
Оценка: 3 (3) +1 :))) :)
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, WolfHound, Вы писали:


WH>>Когда я работл с С++ у меня было ощущение что я работаю с чемто очень твердым, тяжолым и хрупким, а когда я начал работать на C# с решарпером у меня появилось ощущения что я работаю с чемто очень мягким, легким и пластичным. Это конечно еще далеко не придел мечтаний но это шаг в правильном направлении.


M>А вот у меня иногда возникает ощущение, что проекты с 1990-х годов сложнее не стали (особенно если учесть большой рост производительности PC), а вот количество людей на них выросло в разы То, что раньше писалось на Clipper и FoxPro одним человеком, сейчас пишется в связке ASP.NET + MS SQL коллективом... Понимаю, что сахар был слаще, но когда пару лет назад я решил немного пописать в RING 0 без всякой OS, то получил много удовальствия


Сложнее они, конечно, стали, но не во столько раз, во сколько увеличилось быстродействие PC и размер RAM. А благодаря последнему появились весьма мягкие, легкие , пластичные, белые и пушистые средства, которые их адепты выдают за последнее слово, не отдавая себе отчета в том, что они просто транжирят бесплатно доставшиеся им ресурсы.

В общем, если у Вас есть 100 рублей, то Вы сто раз подумаете, как их потратить правильно. А если у Вас их 100,000 — первое, что Вы сделаете — пойдете в мебельный магазин и купите себе мягкое, легкое , пластичное и пушистое кресло. За 20,000. Чтобы в нем уютно думать о том, на какие мягкие и т.д потратить все остальное.
With best regards
Pavel Dvorkin
Re: Философия эффективности труда
От: ArhAngelVezel Россия  
Дата: 14.02.06 06:47
Оценка: 60 (3) -1 :)))
Здравствуйте, McSeem2, Вы писали:

MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?


Я никогда не был сторонником отвечать в столь явные флеймы, но сама не состыковка, несоответствие фактам не дает мене полностью и беспрекословно промолчать и одновременно сохранить мою верность "истине"

Давайте подключим google и определимся с понятиями, особенно раз Вы так любите бросаться определениями. Что же такое эффективность:

эффективность — способность производить определенный эффект, действенность; мера производимого эффекта


Откуда следует что эффективность в первую очередь подразумевает получения какой то меры эффекта. Пойдем далее

эффект — процесс, возникающий на Изделии в результате воздействия или изменения какого-либо физического параметра (параметров) самого Изделия и/или Инструмента. (http://karev.narod.ru/terttm.htm)
эффект — результат игры (http://pt.ability.ru/pt02.html)

т.е. эффект это результат. А простите меня за неразумность, но какой результат может быть определен, когда *один* класс разрабатывается уже полгода??? Вы продали этот класс или собираетесь продать его за $12000 (это и то по минимуму)???
Нет, понятие эффективности не подразумевает интересность процесса, и Вам не интересно работать над дизайном формочек в студии, а вот заказчику не интересно платить $12000 за 50 килобайт не пойми чего, того, что, по вашему мнению, должно работать... Поэтому Вы не эффективны, и для заказчика вы слабое звено…

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

Dixi et animam levavi.
Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 13.02.06 23:35
Оценка: 13 (3) +4
Здравствуйте, Mystic, Вы писали:

M>Вопрос в том, что разгребать события так или иначе придется... Да и контролы на форме разгребать... Если, конечно, мы желаем графический интерфейс Альтернатива была еще во времена MS DOS, когда приходилось все писать руками. Было примерно так: запустим программу... Нет, это кнопка слишком вправо уехала. Тут три пикселя будет мало, надо пять. И т. д. Рутина похуже будет. Конечно, можно создать язык разметки вроде TeX, который будет автоматически располагать контролы, но человеческой вмешательство в этот процесс исключать нельзя...


Безусловно придется! Вопрос лишь в том, кому придется? Ты же не ожидаешь, что, скажем, старикан Дональд Кнут тоже должен заниматься этой мышиной мастурбацией в форм-дизайнере? Ему как-то даже не к лицу. Я за разделение труда. В опере пусть поют, Кнут пишет книжки в своем ТеХе, я буду скритеть остатками мозга над алгоритмами. А формы пусть дизайнит кто-нибудь другой.

Так чего я так взъелся-то? А то, что понятие эффективности может быть очень разным. Я охотно верю, что для Влада это — больше ре-шарперов и ре-фактореров (ре-факторов, ре-факеров), хороших и разных. И я ничего против этого не имею, но не надо возводить это в категорию абсолюта. Пусть он расскажет тому же Кнуту, что тот работает жутко неэффективно. Куда он будет послан? Воот. Или, скажем, Андрю Уайлз, который угрохал семь лет жизни на доказательство "какой-то фигни". Зачем ему это надо было? — это же жуть как непроизводительно! А ответ простой — ему было чисто прикольно по жизни. Вот это и есть критерий эффективности. Владу прикольно повышать производительность труда ре-шарперами. Замечательно! Но мне-то это — не прикольно (и некоторым другим — тоже) и, следовательно, ни в коей мере не является для меня эффективным.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[12]: Философия эффективности труда
От: Павел Кузнецов  
Дата: 15.02.06 02:15
Оценка: 8 (3) +4
Здравствуйте, VladD2, Вы писали:

VD>Вот кстати, и ПК нервничает, значит снова в точку.


Меня просто умиляет аргументация подобного уровня:

если сравнить вас с Вольфхаундом как специалистом в области С++, то ты как бы вообще не существущь


Особенно на фоне подобных сообщений
Автор: VladD2
Дата: 14.02.06
в соседнем топике:

Вести разговор с людьми пытающимися сорвать аплодисменты на экстравагантности хамства мне интереса не представляет.

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

Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[6]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:08
Оценка: 1 (1) +1 -3 :))
Здравствуйте, Дарней, Вы писали:

Д>Интересно, а чего это тебя так сильно престиж интересует? У тебя с этим какие-то проблемы?


У меня складывается такое впечатление, что да Видимо судьба прикладного программиста не сложилась и теперь в качестве аргумента нелюбви к профессии приводится рвотный рефлекс.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Философия эффективности труда
От: klapaucius  
Дата: 17.02.06 07:59
Оценка: +5 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Сложнее они, конечно, стали, но не во столько раз, во сколько увеличилось быстродействие PC и размер RAM. А благодаря последнему появились весьма мягкие, легкие , пластичные, белые и пушистые средства, которые их адепты выдают за последнее слово, не отдавая себе отчета в том, что они просто транжирят бесплатно доставшиеся им ресурсы.


Сомнительное утверждение, вообще говоря. Оставим рассуждения о "бесплатных" ресурсах, дело то все в том, что использование легкого и пластичного средства никак нельзя назвать транжирством.

PD>В общем, если у Вас есть 100 рублей, то Вы сто раз подумаете, как их потратить правильно. А если у Вас их 100,000 — первое, что Вы сделаете — пойдете в мебельный магазин и купите себе мягкое, легкое , пластичное и пушистое кресло. За 20,000. Чтобы в нем уютно думать о том, на какие мягкие и т.д потратить все остальное.


Беда в том, что многие люди, привыкшие к бюджетам в 100 рублей, уже просто не в состоянии освоить бюджет в 100 000. А если и освоят, то счастья это им не принесет. Их будут терзать различные фобии. "Как же так? 100 000? Это же шумашетшие деньги! Я всегда укладывался в 100! Это транжирство!". И он попробует, обязательно попробует, если его, конечно, не остановить и не обезвредить, уложить "чуть более сложную" задачу в бюджет 100р воспользовавшись каменным топором и битхаками, и всего через миллион лет, сидя на голом бетонном полу, создаст мегасистему, которую кроме него... кроме? нет, просто никто никогда не сможет поддерживать. Тоесть он ничего не создаст. Тем временем жизнь не будет стоять на месте, люди вокруг будут осваивать бюджеты и объемы памяти измеряемые астрономическими числами, неприменно с использованием передовых мегапушистых средств, а те керенки в количестве 100 000 так никогда и не будут использованы по назначению и превратятся в мукулатуру.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Философия эффективности труда
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 17.02.06 09:29
Оценка: 13 (3) +2 -1
Здравствуйте, klapaucius, Вы писали:

K>Беда в том, что многие люди, привыкшие к бюджетам в 100 рублей, уже просто не в состоянии освоить бюджет в 100 000. А если и освоят, то счастья это им не принесет. Их будут терзать различные фобии. "Как же так? 100 000? Это же шумашетшие деньги! Я всегда укладывался в 100! Это транжирство!". И он попробует, обязательно попробует, если его, конечно, не остановить и не обезвредить, уложить "чуть более сложную" задачу в бюджет 100р воспользовавшись каменным топором и битхаками, и всего через миллион лет, сидя на голом бетонном полу, создаст мегасистему, которую кроме него... кроме? нет, просто никто никогда не сможет поддерживать. Тоесть он ничего не создаст. Тем временем жизнь не будет стоять на месте, люди вокруг будут осваивать бюджеты и объемы памяти измеряемые астрономическими числами, неприменно с использованием передовых мегапушистых средств, а те керенки в количестве 100 000 так никогда и не будут использованы по назначению и превратятся в мукулатуру.


А мне кажется, как раз наоборот. К хорошему быстро привыкаешь. Вот моя з/п со времен студенчества выросла в 30 раз. Думаешь у меня проблема ее потратить??? И никаких фобий А вот если ее урезать раз в десять, то будут большие проблемы. И провокационный вопрос: если человек уже имеет опыт разработки рабочих продуктов с небольшим бюджетом, почему он должен обязательно провалить следующий проект? Если я делал пару-тройку систем за $100, то почему при разработки еще одной подобной системы за $10000 я должен ее провалить?

Раньше как-то проще было... Были процедуры и функции и никаких соблазнов. Зато этим средством я владел профессионально. Надо закодировать обращение матрицы? 30 мин и готово. Надо решить задачу линейного программирования? Пару часов и готово. Надо прикрутить дроби? Полчаса посидел, прикрутил. Нет под рукой программы для игры в русские шашки? Посисел пару вечеров до поздна на ВЦ и написал. С графическим интерфейсом под DOS. Обыграла она меня? Я тебя породил, я тебя и сотру, надо хозяина знать в лицо!

Все это я к чему? Да вот, решил переписать шашечную прорамму. Я точно помню, что реализации ее заняла у меня в студенчестве два дня. Вообруженный новым багажом и новыми знаниями, с учетом того, что я хорошо помнил используемый алгоритм, его я реализовывал пару недель. Постоянно пыхтел, трудился... Вот тут можно рефакторинг сделать, вот тут эту фичу. Нет, надо назад вернуть, ... Создавалось такое (возможно обманчивое) впечатление, что знания о том, что даже возможности IDE, к которым ты привык и без которых ты не можешь, отвлекали от цели... Мысли не о задаче, а о том, какую бы фичу из арсенала средств можно испоьзовать... Конечно, можно сослаться, что шашечная программа не есть реальный сложный проект, но кошки на душе как-то остались и с тех пор я стал очень настороженно относится к новым возможностям...
Re[3]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 03:34
Оценка: 7 (2) +3 -1
Здравствуйте, McSeem2, Вы писали:

MS>Так чего я так взъелся-то? А то, что понятие эффективности может быть очень разным. Я охотно верю, что для Влада это — больше ре-шарперов и ре-фактореров (ре-факторов, ре-факеров), хороших и разных. И я ничего против этого не имею, но не надо возводить это в категорию абсолюта. Пусть он расскажет тому же Кнуту, что тот работает жутко неэффективно. Куда он будет послан? Воот. Или, скажем, Андрю Уайлз, который угрохал семь лет жизни на доказательство "какой-то фигни". Зачем ему это надо было? — это же жуть как непроизводительно! А ответ простой — ему было чисто прикольно по жизни. Вот это и есть критерий эффективности. Владу прикольно повышать производительность труда ре-шарперами. Замечательно! Но мне-то это — не прикольно (и некоторым другим — тоже) и, следовательно, ни в коей мере не является для меня эффективным.


Разработка алгоритмов — это совершенно отдельная задача, и к программированию как таковому имеет довольно-таки опосредствованное отношение. При чем здесь вообще решарпер?
Какой смысл в сравнении мокрого с колючим, которое ты здесь устроил, я не понимаю
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 08:12
Оценка: 1 (1) +5
Здравствуйте, Дарней, Вы писали:


Д>Программированием занимается человек, который бОльшую часть рабочего времени пишет код. Не рисует дизайн, строит диаграммы, общается с заказчиками или занимается исследованиями. А именно пишет код.

Д>Очень просто, правда?

Программированием занимается человек, который бОльшую часть рабочего времени программирует. А это и проектирование и написание кода и отладка и документация и т.д. и т.п. И придумывание алгоритмов для решения соответствующих задач, если шаблонные методы не подходят.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Философия эффективности труда
От: vdimas Россия  
Дата: 07.03.06 18:20
Оценка: 1 (1) +5
Здравствуйте, AndrewVK, Вы писали:

WH>>Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер


AVK>Ты еще не забыл, что мы обсуждаем удобный API. А удобный API хелперов не требует.


Хелперов требуют конкретные повторяющиеся сценарии использования. А удобное АПИ это то, которое позволяет с легкостью создавать произвольные хелперы. Тем более, что на все случаи жизни хелперов не напасешься, они могут загромоздить АПИ и закрыть его суть своей бесполезной массой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:08
Оценка: +5 :)
Здравствуйте, Дарней, Вы писали:

Д>А если "программист" не пишет код, то это или архитектор, или ПМ.


Если архитектор не пишет код, то это не архитектор, а бла-бла-бла архитектор. Прошу не путать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Философия эффективности труда
От: Яшин Евгений Новая Зеландия
Дата: 15.02.06 05:48
Оценка: -3 :)))
Вставлю свои 5 копеек в спор больших дядей.
В своё время я искал графическую библиотечку для 2D графики и натолкнулся на AGG библиотечку. Бесспорно, библиотечка очень хороша, но когда я начал читать просто кучу всяких нелинейный методов гамма коррекции, меня немного это насмешило. Имхо гамма коррекция используется для вытягивания тёмных цветов на севших мониторах. Для всего остального используются цветовые профили, ИМХО. Не представляю заказчика, который за такого рода эффекты выкладывал бы огромные деньги.

А майкрософт может и купит, но явно не за 150000$, потому что нафиг оно ей надо — такое качество за такие деньги. Клиенты не оценят.
Re[13]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 10:13
Оценка: -5 :)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Меня просто умиляет аргументация подобного уровня:

ПК>

ПК>если сравнить вас с Вольфхаундом как специалистом в области С++, то ты как бы вообще не существущь


Хм. А тебя не умиляет то когда человеку севшему не одну собаку в С++ начинают снисходительно говорить "это было что-то связанное, например, с COM..."?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 17.02.06 20:29
Оценка: 33 (4) :)
Здравствуйте, minorlogic, Вы писали:

M>Но при тестировании асимптотики от сложности полигона, обнаруживаем смешную деталь . Оказывается начиная с какогото предела, реализация ведет себя как O(n^2). Эти тесты валились на win2000.


M>И после этого мне кто то расскажет про квалификацию комады Microsoft делающую GDI+ ? увольте.


M>Кстати возможно , что они до сих пор не пофиксили это поведение, для желающих проверьте на GDI+.



Не знаю насчет GDI+, но простой растеризатор ведет себя именно так. Начиная с 3000 точек он тормозит. Вообще-то говоря, не факт что O(N^2) так уж и плохо. Ведь 99% потребностей удовлетворено, разве нет? А кому это надо — красить полигоны из 3000 точек? В visio — точно не надо. Вот простейший тест:
http://antigrain.com/stuff/multifill_timing.zip
TimeMF — это древний код закраски многосвязных полигонов имени Андрея Дмитриева. (C) АО Моринтех 1992 из доблестного Ленинграда (как он тогда назывался).
Pnt=00032 TimeAPI=000141 TimeMF=000875 Rate=0.161143
Pnt=00217 TimeAPI=000156 TimeMF=001000 Rate=0.156
Pnt=00570 TimeAPI=000297 TimeMF=001360 Rate=0.218382
Pnt=01008 TimeAPI=000421 TimeMF=000922 Rate=0.456616
Pnt=01656 TimeAPI=000625 TimeMF=000860 Rate=0.726744
Pnt=03014 TimeAPI=000625 TimeMF=000500 Rate=1.25
Pnt=05105 TimeAPI=001734 TimeMF=000735 Rate=2.35918
Pnt=10235 TimeAPI=002531 TimeMF=000422 Rate=5.99763


Ясно видно, что на простых полигонах WinAPI работает в 6 раз быстрее доморощенного. Но это только лишь потому, что в WinAPI нет функции для быстрого рисования горизонтальных линий. Знаете как в WinAPI быстрее всего нарисовать горизонтальную линию? — надо использовать функции SetBkColor и ExtTextOut, что и сделано в MFC. Большего маразма я в жизни не видал. Ну да ладно. Теперь про GDI+. Фиг с ним, с качеством растеризатора — это мелочь. Он банально не умеет рисовать кривые Безье. Точнее сказать, формально-то умеет, но нет-нет, да и промахнется мимо конечной точки на 1-2 пиксела (очень-очень редко). Как это называется? — халтура это называется. Я не собачатник, но слыхал такую байку, что большие доги не могут сами размножаться — кобелю надо помочь рукой вставить куда надо. Вот именно эту неприличную ассоциацию у меня и вызвают кривые Безье в GDI+.
(включить GIF-анимацию)


И эти люди запрещают мне ковырять пальцем в носу?!!!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Философия эффективности труда
От: WolfHound  
Дата: 14.02.06 19:03
Оценка: 28 (1) +4
Здравствуйте, McSeem2, Вы писали:

MS>Именно так, несмотря на успешность подавляющего большинства моих прикладных проектов. Не моё это. И это ощущение усугубляется нехорошим предчуствием, что мы находимся вначале нового мыльного пузыря типа дот-комов. Ощущение какой-то тщеты, искусственности этого массового рынка, не обеспеченного активами. Жена тут сдвала какие-то MS-сертификаты — ну чисто лохотрон по собиранию денег с населения. И первые, кто обвешиваются эими сертификатами — это индусы. А их много. А каждый экзамен денег стоит. А за дополнительные деньги можно купить ответы на эту угадайку (что они все и делают). И главное — все легально и "цивилизованно". Меркетинг, едрёныть! О каком повышении производительности может идти речь, если она изначально помножена на ноль?! Как там у Пелевина:

Да причем тут чвсе это? Или ты думаешь что ИТ индус которых развелось как...?
Тут ведь дело не только в том что новые технологии дают возможность домохозяйкам писать программа(реально ничего хорошего у них всеравно не получается), а в том что эти технологии поднимают произваодительность проыессионалов.
Причем поднимают очень здорово.
Когда я работл с С++ у меня было ощущение что я работаю с чемто очень твердым, тяжолым и хрупким, а когда я начал работать на C# с решарпером у меня появилось ощущения что я работаю с чемто очень мягким, легким и пластичным. Это конечно еще далеко не придел мечтаний но это шаг в правильном направлении.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 06.03.06 05:06
Оценка: 26 (4) +1
Здравствуйте, mrozov, Вы писали:

M>А еще к ней не имеет никакого отношения твоя уникальность, как специалиста, известность в узких кругах и переделование одного решения по три раза.


M>Так что (имхо) нет у тебя никакой философии эффективности труда. У тебя есть философия оправдания его неэффективности. Вполне адекватная, замечу.


Рекомендуется курить вот это:
http://www.fictionbook.ru/author/nordstrem_kell_a/biznes_v_stile_fank_kapital_plyashet_pod/nordstrem_biznes_v_stile_fank_kapital_plyashet_pod.html
Re[10]: Поштучно говоришь...
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 21:27
Оценка: 18 (1) +1 -3
Здравствуйте, IT, Вы писали:

IT>Кстати, эта самая реклама от MS рассчитана на тот самый манагерский делетантизм и непрофессионализм, который преобладает в нашей индустрии. Нами ведь руководят в основном технически малограмотные прорабы и продавцы, люди знающие об IT технологиях не больше чем твои домохозяйки. Сейчас хорошего программиста найти сложно, а уж профессионального IT менеджера так днём с огнём.


А знаешь почему? Потому что ни грамотные менеджеры, ни грамотные программисты банально не выгодны. Они — как белые вороны. Индустрии выгоден дилетантизм и профанация. Помнится, гуляла такая байка, что один изобретатель придумал неперегорающую электрическую лампочку, но его зарезали по заказу владельцев GE. А сама лампочка до сих пор горит в фонарном столбе где-то на окраине Чикаго. Конечно же это байка, но без криминальной составляющей она вполне правдоподобна — вечные лампочки не выгодны индустрии и именно поэтому их нет в магазинах.

IT>И считают, как землекопов. Кто-то тут говорил про 40 тысяч кубиков в индии. Боюсь, что 8 дней в неделю все эти кубики будут проводить на митингах.


А вот это — выгодно. Под это дело менеджеры среднего звена могут выбить бабки у менеджеров повыше. Те могут найти спонсоров в виде венчурных капиталистов, ну а самих капиталистов воспитывает в нужном русле тот же MS. Круг замкнулся. А на что же все это опирается?! — А вот об этом ты не думай никогда. Вообще никогда!

Ладно, это уже чисто гон — пофлудить захотелось. Но в любой шутке как говорится, только доля шутки.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Философия эффективности труда
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.02.06 13:17
Оценка: 12 (1) +4
Здравствуйте, VladD2, Вы писали:

VD>Так что наличие в команде GDI+ McSeem2 возможно просто ничего бы не дало. Так как ему просто не дали бы убивать месяцы на вылизование чего-то сверх меры.


VD>Пойми, AGG живет на очень узком сегменте рынка. У МС задачи куда более широкие.


Чесно говоря, почитав тут наезды на McSeem2 я только за него порадовался. Если есть люди, которые думают, что AGG лучше GDI+ то, имхо:
-- во-первых, это заслуга McSeem2,
-- во-вторых, это основа благополучия McSeem2.

Так что, пусть МС выпускает ширпотреб, который удовлетворяет 90% потребителей. Главное, чтобы они не удовлетворяли 10% более требовательных (желательно хорошообеспеченных) клиентов, способных оплачивать разработки типа AGG.

2McSeem2: Но пасаран!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 13.02.06 19:05
Оценка: 1 (1) +3 :)
Здравствуйте, Oyster, Вы писали:

O>А самое обидное то, что готового каркаса для типового EA никогда нет! И приходится педалить довольно много кода, который и будет этим каркасом. Такого базового, нерутинного кода, который будет составлять основы основ продукта. И работу над которым никак не назовёшь "грязной работой по проектированию и дизайну форм в дот-нет студии". И вот тут рефакторинг будет очень даже к месту — тут без этих шашечек просто не уедешь.


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


Охотно верю, ибо через все это я проходил. Более того — я даже сподобился спроектировать и написать целый банковский опердень (о! пердень!). И это даже было интересно. Но со временем мне это все надоело и теперь одно слово "Enterprise" навевает на меня необоримую скуку и лень.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 09:02
Оценка: 1 (1) +4
Здравствуйте, Дарней, Вы писали:
Д>А если "программист" не пишет код, то это или архитектор, или ПМ. Опять же, совершенно другая профессия. Это только у нас принято валить всех в одну кучу. Если работает с компьютером — значит, программист.
И, по моему скромному опыту, это хорошо. Я насмотрелся в развитой стране на веб-дизайнеров, падающих в обморок от HTML-разметки, программистов, не понимающих разницу между gif и jpeg... Это ж то же самое, что художник по синему цвету. Нормальный разработчик должен быть достаточно разносторонним.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 02.03.06 10:13
Оценка: 1 (1) +1 :)))
Здравствуйте, mrozov, Вы писали:

M>На лицо — воинствующая безграмотность. Инженеры и ученые — это не совсем одно и то же. Подавляющее большинство инженеров никакой наукой не занимаются, а занимаются применением этой науки на практике. Очень часто — (как правило) их работа имеет разовый характер и повторному использованию не подлежит.


M>Лови заслуженный -1.


Футы нуты, детский сад. Ты не учитель, он не ученик у доски. Ты уверен, что его волнует твоя оценка? Лучше попробуй понять собеседника, чем "двойки" ставить.

P.S. Особенно волнующе выглядит слово "заслуженный" ))) Завуч, не меньше!!!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 02:45
Оценка: +3 :))
Здравствуйте, McSeem2, Вы писали:

IT>>А это мне больше напоминает мазахизм, а не доблесть Воин, блин


MS>Пожалуйста-пожалуйста — можешь считать как угодно. То есть ты твердо убежден в том, что задачи подобного рода — это мазохизм? Это значит, что наши интересы не пересекаются, не более того.


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

MS>Я же говорю о другом, например, перевести задачу (к примеру!) из класса O(N^2) в класс O(N log N), в условиях, когда это сделать нетривиально, но все еще возможно (ну и конечно же, где это актуально), и сделать это наиболее нетупым способом — вот это и есть мегазадача. А "производственный процесс" — это рутина. Смысл в нем для меня отсутствует.


Я правильно понимаю, ускорить твой алгоритм в 2 раза — это хорошо, а ускорить в 80 раз какой-нибудь "производственный процесс" — это бессмысленная рутина?

MS>Инженером.


Хороший ответ

MS>Кстати, придумать алгоритм — это чья работа — программиста или математика?


Хороший вопрос

MS>О чем я и говорю! Пожалуйста, строй небоскребы и мосты, раз ты строитель. А по поводу блохи, мне не нужно ее подковывать — это тоже рутина. Мне интересно придумать как это сделать, понимаешь в чем разница?


Не понимаю Я не понимаю как это сделать не убив при этом стадо этих самых блох. Даже майкросовтовский ресёч этим грешит. Либо ты всё же берешь такой грех на душу, либо ты лукавишь.

MS>Ну или придумать как построить мост (образно говоря). Но не буду же я сам краном рулить! Или тросы тянуть.


Надо и краном порулить и тросы потягать, а как же? По другому не бывает. В нашем деле построить серьёзную систему и не замараться при этом кодированием могут только бла-бла-бла-архитекторы. Понятное дело, что построить они её могут только на словах, а не на деле.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 05:39
Оценка: +2 -3
Здравствуйте, Дарней, Вы писали:

Д>Разработка алгоритмов — это совершенно отдельная задача, и к программированию как таковому имеет довольно-таки опосредствованное отношение.


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

Д>При чем здесь вообще решарпер?


Решарпер приведен лишь в качестве некой фигуры речи.

Д>Какой смысл в сравнении мокрого с колючим, которое ты здесь устроил, я не понимаю


Странно. Вроде бы понятными словами изъясняюсь...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 09:02
Оценка: +5
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант.

КДВ>2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.
Вот от такого подхода и возникают чудовищные приложения. Потому что первую часть либо пропускают вовсе, за отсутствием таланта, либо делает человек уже с таким талантом, что хоть стой хоть падай.
В проектировании UI основную роль играют не пикселы, а процесс взаимодействия. Для создания качественного UI достаточно обладать здравым смыслом и основами знаний по когнитивной психологии. Никакого таланта не надо. Талант нужен для того, чтобы создавать художественные произведения — к примеру, внятный сплэш для визарда ни один программист не изобразит (если он случайно не художник). А вот от UI для приложения художников лучше держать подальше — они имеют очень слабое представление о восприятии динамических структур. Кроме того, художнику очень сложно объяснить суть процесса взаимодействия пользователя с системой, поэтому он связан той структурой UI, которую ему подсунули для раскрашивания. А никакое раскрашивание не спасет UI, в котором нужно звонить абоненту при помощи бросания его иконки на иконку телефона, расположенную на другой закладке.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 00:35
Оценка: :))) :))
Здравствуйте, kedik, Вы писали:

K>Да... ровно на столько, на сколько бухгалтер работающий в софтверной компании — программист.


Не зарикайся.

Бухгалтер,
Программист
и вообще розовый
слоник с БФГ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 15.02.06 02:36
Оценка: +4 :)
Здравствуйте, VladD2, Вы писали:

VD>Знашь, откровенно говоря если сравнить вас с Вольфхаундом как специалистом в области С++, то ты как бы вообще не существущь. Ну, или тянешь на эдакого серяднечка не заметного среди серых масс, а Вольфхаунд пару собак слопал.


Well, it's only your opinion (Big Lebowski)

Влад, не берусь утверждать что твои слова вызывают во мне когнитивный диссонанс, но х...ею я от них конкретно. Ты бы удосужился хотя бы слегка напрячь мозг и подумать, о чем вообще речь идет. Разве я хоть одним словом усомнился в компетентности собеседника? Пацак пацака помоями не обливает, это некрасиво, родной.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 02:20
Оценка: 20 (3) +1
Здравствуйте, IT, Вы писали:

MS>>И что характерно, все эти мои "капризы" очень высоко оплачиваются — и это при том, что результат не гарантирован! Вот это для меня — настоящая задача, я бы даже сказал, битва, а я в ней — доблестный воин


IT>А это мне больше напоминает мазахизм, а не доблесть Воин, блин


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

IT> Ну да, гораздо лучше 42 раза переписать одни и теже 50к кода.


Нее, просто переписать — это мазохизм, несомненно. Или оптимизировать на процентах производительности — пусть этом тоже другие занимаются, я их проконсультирую если что.
Я же говорю о другом, например, перевести задачу (к примеру!) из класса O(N^2) в класс O(N log N), в условиях, когда это сделать нетривиально, но все еще возможно (ну и конечно же, где это актуально), и сделать это наиболее нетупым способом — вот это и есть мегазадача. А "производственный процесс" — это рутина. Смысл в нем для меня отсутствует.

IT>Он был программист или математик? У меня есть подозрение, что можно быть либо классным программистом, либо отличным математиком. Можно быть и двумя сразу, но средними Ты, кстати, кем себя больше считаешь?


Инженером.
Кстати, придумать алгоритм — это чья работа — программиста или математика?

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


О чем я и говорю! Пожалуйста, строй небоскребы и мосты, раз ты строитель. А по поводу блохи, мне не нужно ее подковывать — это тоже рутина. Мне интересно придумать как это сделать, понимаешь в чем разница? Ну или придумать как построить мост (образно говоря). Но не буду же я сам краном рулить! Или тросы тянуть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[13]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 17.02.06 09:42
Оценка: 18 (1) +2 :)
Здравствуйте, Дарней, Вы писали:

Д>Человек — не лошадь, его ослом не заменишь. Пусть даже и дипломированным.


Еще как заменишь! Сколько у нас в мире мест, где сидят дипломированные ослы!
With best regards
Pavel Dvorkin
Re[15]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 17.02.06 20:54
Оценка: 1 (1) +3
Здравствуйте, craft-brother, Вы писали:

CB>Нет, видно, не судьба нам найти общий знаменатель. В разных системах исчисления работаем. Я про промышленное производство ПО, ты — про кустарное.


"Промышленное производство ПО" — это оксиморон (буквально — остроумно-глупое высказывание, типа как "живой труп"). Ну или под термином "промышленное производство ПО" подрузамевается штамповка CD и упаковка в коробки. Но в этом процессе программисты как бы и не учавствуют совсем...

Вопрос такой — а вот работа инженера по проектированию моста через реку (именно что некого конкретного моста через конкретную реку) — это промышленное или кустарное производство?

Или сочинение музыки — это что, тоже производство? Судя по "фабрике звезд" — да, производство. Но является ли это музыкой — вот в чем вопрос.

Кстати, не в тему, но все-таки. Очень хорошую музыку сочинил Игорь Корнелюк для Мастера и Маргариты. Но все-таки, основную тему он спер из Призрака в Опере композитора Андрея Ллойдовича Вебера. Только размер поменял, а мелодический ряд — один в один.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[21]: Философия эффективности труда
От: WolfHound  
Дата: 01.03.06 15:48
Оценка: 1 (1) +3
Здравствуйте, AndrewVK, Вы писали:

AVK>Не будет. Ты же сам тут распинался по поводу stateful/stateless. Так вот — по моей практике удобнее указывать кисти по месту, а не переключать их в контексте.

Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер для этого дела и раблотать както так
GdiPlusLikeConveyor c = new GdiPlusLikeConveyor(graphics);
GdiPlusLikePen pen1 = new GdiPlusLikePen(color1, brush1);
GdiPlusLikePen pen2 = new GdiPlusLikePen(color2, brush2);
c.Line(. . ., pen2);
c.Circle(. . ., pen1);
c.SetPen(pen1);
c.MoveTo(. . .);
c.LineTo(. . .);
c.CurveTo(. . .);
c.SetPen(pen2);
c.MoveTo(. . .);
c.LineTo(. . .);
c.CurveTo(. . .);
c.Flush();

И что это сложнее GDI+?
За то если таки понадобится сделать что-то болие навороченое то...

AVK>Еще раз и медленно. В типовом сценарии применения GDI+ эти возможности и не нужны.

Но они и не мешают.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 15.02.06 08:14
Оценка: :))) :)
Здравствуйте, Шахтер, Вы писали:

Ш>C## ?


Нету оператора ## в C#, поэтому не судьба. Зато во втором есть оператор ??...

C?? — вот наше будущее
Re[12]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 10:13
Оценка: -4
Здравствуйте, McSeem2, Вы писали:

MS>Влад, не берусь утверждать что твои слова вызывают во мне когнитивный диссонанс, но х...ею я от них конкретно. Ты бы удосужился хотя бы слегка напрячь мозг и подумать, о чем вообще речь идет.


Ты лучше сам напрягай моз перед тем как начинашь гадать предпосылках собеседника.

MS> Разве я хоть одним словом усомнился в компетентности собеседника? Пацак пацака помоями не обливает, это некрасиво, родной.


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

Между тем ты прекрасно знашь кто такой Вольфхаунд, и что он знает о области С++.

Извини, может я перегнул палку, но мнея просто возмутило такое пренебрежение. Это очень похоже на так Смактуновский после большого перерыва встретил Миронова, к тому моменту Мировнов уже стал супер-звездой, и спросил у него "А ты еще где нибудь снимался после "Берегись автомобиля"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 15.02.06 20:54
Оценка: +4
Здравствуйте, Дарней, Вы писали:

Д>если начинаешь писать код сам, то очень быстро теряется общая картина.


А если не пишешь его сам, то начинаешь опускать детали и перекладывать принятие важных, но неприятных решений на разработчиков. Никогда не сталкивался с таким подходом к архитектуре — "Ну тут всё просто, вы там сами чего-нибудь придумайте"? Пока архитектор пишет код, пусть небольшую часть, он видит проблемы глазами разработчика. Как только он перестаёт писать код, он очень быстро переходит в противоположный лагерь — лагерь менеджеров и аналитиков, и начинает терять связь с реальностью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 16.02.06 10:15
Оценка: +2 -1 :)
Здравствуйте, Дарней, Вы писали:

Д>Сертификаты — это лохотрон, это и так любому понятно. Ну пусть есть идиоты, которые готовы платить за это свои деньги. Пусть есть другие идиоты, которые нанимают "спецов" с пачками сертификатов. Один раз обожгутся, в другой раз будут думать. Тебя то это каким образом затрагивает? Меня — нет. Чем больше будет идиотов, тем больше будут цениться настоящие специалисты


Чем больше будет дипломированных идиотов, тем труднее будет специалистам доказать, что они не идиоты и тем труднее будет отличить идиота от специалиста.
With best regards
Pavel Dvorkin
Re[14]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 17.02.06 03:25
Оценка: +2 :))
Здравствуйте, Sinclair, Вы писали:

S>Продукт на 1000 пользователей — это практически любая ERP система. Их в мире как грязи. Большинство, насколько мне известно, страдают проблемами с юзабилити.


О, кстати, насчёт юзабилити. Синклер, не мог ты отбивать свои тветы пустыми строчками, а то всё в глазах сливается, не понятно кому плюсы ставить, а кому минусы
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Философия эффективности труда
От: WolfHound  
Дата: 15.02.06 11:29
Оценка: 27 (1) +2
Здравствуйте, McSeem2, Вы писали:

MS>Верю. Но позволь мне угадать. "твердым, тяжолым и хрупким" — это было что-то связанное, например, с COM, или, что-то другое, но обязательно с тяжелым полиморфизмом, множественными наследованиями, фабриками классов и прочими "прелестями". И обязательно — с неочевидным временем жизни объектов, удалением одного раньше другого, утечками памяти и тэ де. Это действительно все очень хрупко и зыбко. И по моим наблюдениям, так называемая "индустрия" тяготеет именно к таким вот кошмарным уродцам (ну так получается почему-то). И C# и прочие Javы действительно здесь помогают, но только лишь как обезболивающее — то есть в качестве лечения симптомов а не болезни.

Влад в соседнем посте был слишком резок и вполне справедливо отхватил кучу минусов но по сути я с ним согласен.
Ты рассуждаешь о том о чем не знаешь. Это выглядит также глупо и нелепо если например я сейчас начну рассуждать о вкусе устриц при том что я их видел пару раз по телевизору.
Твой тон умудренного опытом старца знающего о жизни все и тонкие намеки на то что я не тем занималси по этому не ощютил всю мощь и легкость С++ не способствуют нармальному ведению диалога.
Вобщем если ты не сменишь тон и не примешь то что у твоих собеседников тоже не маленький опыт то я не стану продолжать диалог.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 08:25
Оценка: 4 (1) +1 :)
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, kedik, Вы писали:


K>>Эээ... А что такое программирование тогда?


K>>Если я правильно понял мысль... то программированием непосредственно занимаеться только компилятор


Д>Программированием занимается человек, который бОльшую часть рабочего времени пишет код. Не рисует дизайн, строит диаграммы, общается с заказчиками или занимается исследованиями. А именно пишет код.

Д>Очень просто, правда?

Угу... Теперь понятна причина жаркого спора

А хотите я вас запрограммирую?

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

Но все они являються программистами. Так же как хирург и гомеопат — врачи.

Очень просто, правда?

PS. В данном случае кодеры похоже набросились на архитекторов — рьяно убеждая последних использовать средства кодирования для решения архитектурных задач... Архитекторы искренне недоумевают... Прикольно...

PSS. Нет ничего нового в этом мире... а мины в "новых" технологиях заложены ещё лет 30-40 назад... впрочем это совершенно не мешает на них наступать...
Маркететологи! Вот эти в данное время настоящие программисты!
Re[3]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 08:12
Оценка: 1 (1) +2
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Кстати, пример на виду. РСДН-щики написали мега-приложение для чтения ньюсов, в котором я сейчас эти строки и пишу. Но. Эта задача БАНАЛЬНА по сравнению с разработкой того же Решарпера. И ньюс-ридеров существует масса. На любой вкус и цвет. Так что прекрасно понимаю уважаемого McSeem2.

КДВ>Конечно я не хочу сказать, что написание подобных тулзов — бесполезное занятие. Ни в коей мере. Я говорю о сложности и нетривиальности задачи.

По мне так востребованность тулзы — показатель более весомый, чем сложность и нетривиальность задачи, которую пришлось решить при написании тулзы. Если ты решил пробежать стометровку спиной вперёд, это совсем не означает, что ты герой — это означает, что ты проиграл.

Раньше меня тоже восхищали сложные задачи. Все подряд. Сейчас... меня больше привлекают задачи из реального мира. Что-то востребованное и очень простое... с точки зрения стороннего наблюдателя. Где-то тут проскакивало на РСНДе про complexity, которая скрывается за simplicity

КДВ>На острие технологий маркетинга? ))) Думаю, что речь идет именно об этом.


Знаешь, современный мир, кишащий капиталистическими акулами, устроен таким образом, что за востребованные продукты платят, а за невостребованные — не платят. Так что можно говорить и про "острие технологий маркетинга", можно про интересные задачи, за которые платят — всё равно разговор будет об одном и том же.

КДВ>Решарпер мозгов не отнимает. Кодирование занимает достаточно малый процент времени, а решарпер его просто может несколько сократить (автоматизировать)


+1. В автоматизации рутинных операций и заключается его прелесть (речь, конечно, не о формочках ).

КДВ>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.


Ну если ты так воплощаешь, то да — спору нет. Можно тупо педалить формы, а можно остановиться, подумать и вместо кучи тупого кода, который будет тяжело поддерживать, написать меньше кода, но кода "умного"

КДВ>И добится совершества. Ну или приближения к нему. И за это платят БОЛЬШИЕ бабки.


Да. Можно добиться совершенства в заточке стамески. И со всех концов света будут приходить к тебе люди и просить заточить стамеску. И не будет на свете другого человека, равного тебе в затачивании стамесок!

Тут всё дело только в том, нравится ли тебе изо дня в день затачивать стамеску...
Re[7]: Философия эффективности труда
От: vitaly_spb Россия  
Дата: 14.02.06 10:31
Оценка: :)))
O>Ой... а я рисую дизайн и исследованиями занимаюсь... Я уже не программист?

Ага, ты дизайнер-исследователь
...Ei incumbit probatio, qui dicit, non qui negat...
Re[7]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 11:24
Оценка: +2 :)
Здравствуйте, kedik, Вы писали:

K>Но все они являються программистами. Так же как хирург и гомеопат — врачи.


Гомеопаты не врачи, а шарлотаны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:13
Оценка: +3
Здравствуйте, Дарней, Вы писали:

Д>Вот к примеру, ты можешь представить себе команду корабля, в которой каждый член экипажа и кок, и машинист, да еще и прокладывает курс, если у штурмана не нашлось на это времени?


Проложить путь можно всем вместе. Не проблема. А вот разбивать проект горизонтально по слоям или вертикально по функционалу — это большой вопрос. Если в команде есть люди, которые умеют одинаково хорошо делать всё от источника данных до гуёв, то не использовать такую возможность просто глупо. Дело в том, что в этом случае радикально уменьшается количество коммуникаций со всеми вытекающими последствиями.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 21:04
Оценка: +3
WH>Когда я работл с С++ у меня было ощущение что я работаю с чемто очень твердым, тяжолым и хрупким, а когда я начал работать на C# с решарпером у меня появилось ощущения что я работаю с чемто очень мягким, легким и пластичным. Это конечно еще далеко не придел мечтаний но это шаг в правильном направлении.

Верю. Но позволь мне угадать. "твердым, тяжолым и хрупким" — это было что-то связанное, например, с COM, или, что-то другое, но обязательно с тяжелым полиморфизмом, множественными наследованиями, фабриками классов и прочими "прелестями". И обязательно — с неочевидным временем жизни объектов, удалением одного раньше другого, утечками памяти и тэ де. Это действительно все очень хрупко и зыбко. И по моим наблюдениям, так называемая "индустрия" тяготеет именно к таким вот кошмарным уродцам (ну так получается почему-то). И C# и прочие Javы действительно здесь помогают, но только лишь как обезболивающее — то есть в качестве лечения симптомов а не болезни.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 03:12
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>Что есть то есть, но вот я не уверен, что ты прав в данном случае. GDI+ — это не только библиотека дающая качество выше чем GDI. Это еще API удобный в использовании. И гарантия стабильности этого АПИ.

Это конечно да, согласен.
VD>Спору нет, беблиотека McSeem2 похоже действительно дает несоколько более высокое качество. Вот только ее интерфейс не к черту не годится. Это низкоуровневая бибилотека со сложным интерфейсом. И McSeem2 натурально борется за то чтобы положение вещей не изменялос (как показывают споры о интерфейсе GDI+).
Тут вопрос совсем уже сложный, судить не берусь.
VD>Между тем GDI+ обеспечивает более чем достаточное качество графики.
Да где ж оно достаточное-то? Лично мне оно очень не нравится. Я не понимаю, почему нельзя было позвать нормального специалиста и сделать GDI+ в пятьдесят раз быстрее и в четыре раза качественнее.
VD>В итоге мы имеет целую кучу компонентов и конечных решений на базе этой библиотеки и в упор не замечае решений на столь замечательной библоитеке McSeem2.
Влад, если бы AGG входил в WinXP, а GDI+ c тем же интерфейсом и т.д. был доступен как даунлоад на антигрэйне, то зуб даю — мы бы вообще такой аббревиатуры не знали. Тут вон неподалеку меня убеждают, что невозможно впарить людям классный бесплатный браузер взамен предустановленного IE, даже 3.0. А уж отказаться от предустановленной библиотеки — вообще фантастика.

Ты конечно прав во многом. А что ты скажешь, если МС таки приобретет AGG для следующей винды? Им там как раз остро потребуется векторная графика
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 15.02.06 04:10
Оценка: +3
Здравствуйте, denis_krg, Вы писали:

_>Да, в пользу моей точки зрения. Редко кто из программеров печатает на клаве слепым методом. Но такие есть. Так вот. От скорости печати скорость работы никак не зависит.


Предпосылка правильная.

_>А если это так, то это означает, что само кодирование (сидение в среде разработки) — не самое затратное по времени действие в программировании.


А вывод нет. Дело, конечно же, не в самих 200 знаках в минуту, а в том, что такая фигня получается. Ты когда-нибудь пробовал запомнить все названия используемых библиотечных функций? Я пробовал. Около сотни названий из стандартной сишной библиотеки я таки запомнил. Но вот порядок параметров memset и setmem не мог запомнить никогда А сейчас мне таких функций нужно помнить не сотню, а тысячи. И автокомплит с интеллисенс позволяют мне их набирать помня лишь идею названия. И делаю я это без ошибок в отличии от 10-ти пальцевого метода и нотепада.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 15.02.06 20:56
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

VD>Конструктивная критика хороша, так как из нее можно сделать выводы на будущее. А просто наежды и кичение. Недостойно это.


О! Это значительный прогресс, Влад! Я рад, что ты в конце концов понял это.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Философия эффективности труда
От: kedik  
Дата: 16.02.06 06:59
Оценка: :)))
Здравствуйте, AndrewVK, Вы писали:

AVK> Как их можно сравнивать — что круче, мне непонятно...

Так сравнивают же ... поэтому и прикольно

PS. А тут разве спор? Неее... по моему это не спор...
Оно время у майкрософта в виндах была одна "уязвимость"... И хакеры нашли для неё забавное применение... для DOS атак.
Прикол был в следующем (в вольной интерпретации):
Атака начиналась... а впрочем и заканчивалась... посылкой одного "неправильного" пакета RPC(если мне память не изменяет) хосту A c обратным адресом хоста B (тоже винды с такой же "уязвимостью") с примерно таким содержанием "В ответ на ваш запрос: неверные данные входные данные".

Хост А (хосту B в ответ): — Я конечно извиняюсь, но мой запрос не может содержать неверные данные, поскольку я у вас ничего не спрашивал. Ищите ошибку у себя. С уважением, А.
Хост B: — Конечно спасибо, за заботу, но у меня нет никакой ошибки. Вы видимо послали мне это по ошибке. С уважением, B.
A: — Да, похоже у вас серьезные проблемы — настоятельно рекумендую вам провериться на наличие ошибок. А
B: — Хм... похоже как раз проблемы у вас. Ошибка. B.
A: — What the f..! A.
B: ...
A: ...
B: ...
...


Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 23.02.06 15:40
Оценка: :)))
Здравствуйте, vdimas, Вы писали:

V>Слушай, а в чем проблема с тем алгоритмом-то? Выложи сюда все условия, глядишь — поможем сообща.


Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д. Придумывать обобщенные методы решения, потому что любые ad-hoc приводят к сказке-неотвязке (never ending story). В-третьих — моё! Не дам! Я страшный-ужасный маньяк!


V>А то действительно, банально жаль твоего времени.


Этот вопрос не должен Вас беспокоить.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[2]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 02.03.06 04:33
Оценка: :)))
Здравствуйте, mrozov, Вы писали:

M>Значица — посевная. Народ — пашет по-черному. План по валу, вал по плану, все дела.

M>И посредине всего этого — деятель, а-а-аккура-а-аатненько так сажающий зернышко за зернышком. Перед тем как
M>посадить — каждому поет колыбельную. Угол и глубину посадки без отвеса и штангенциркуля мерить даже и не берется. Собственно, процентов 30 времени он не сеет, а совершенствует инструментарий.

M>На каждое зернышко капает из пипетки особым раствором — по его данным, урожайность от него аж на 7.3% выше, чем при использовании стандартных удобрений. Ежели угол посадки его не удовлетворяет, он выкапывает зернышко и сажает его повторно. Вообще, в определении идеальных угла и глубины посадки он — лучший в районе. Есть даже подозрение, что на международном состязании по точечному засеву он вошел бы в десятку. Жаль, что таких соревнований нигде не проводят.


Фигня. Неправильное сравнение. Некошерное. Правильно было бы так:

А рядом с колхозом есть эспериментальное хозяйство, где некто McSeem2 выращивает новые сорта. Вот туды они перед посевной и бегут. За посевным материалом. И потом ходют консультироваться — как лучше им удобрять, когда сажать, какой цикл должен быть, чтобы значить были максимальные урожаи. Понял?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Философия эффективности труда
От: minorlogic Украина  
Дата: 02.03.06 08:59
Оценка: -3
Налицо "Абсолютное" непонимание сути работы инженера.

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

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

Так вот есть люди добывающие новые знания , а есть которые ... гм . собирают из готовых знаний "продукт".

Короче аналогия неуместна и совершенна непригодна.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Философия эффективности труда
От: mrozov  
Дата: 03.03.06 15:35
Оценка: +1 -2
>Зачем он этого Васю Пупкина содержит?
Коллега, я понятия не имею, кто тебе платит деньги. Я бы не стал. Нет у меня для тебя работы, как и у подавляющего большинства фирм и фирмочек. Даже если ты полубог программирования.

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

>Оставим в покое сравнения, не в них суть. Хотя сажать внучную зернышко к зернышку — это уж точно клиника. Жрать-то надо чего-то

Собственно, да. О том и речь.

>Кстати, найти ту область, где и платили бы хорошо (востребованность) и самому было бы интересно — это и есть самая сложная задача. Но игра стоит свеч.

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

А еще к ней не имеет никакого отношения твоя уникальность, как специалиста, известность в узких кругах и переделование одного решения по три раза.

Так что (имхо) нет у тебя никакой философии эффективности труда. У тебя есть философия оправдания его неэффективности. Вполне адекватная, замечу.

Дикси.
Re[8]: Поштучно говоришь...
От: Kubera Россия  
Дата: 14.02.06 17:49
Оценка: 18 (1) :)
Здравствуйте, IT, Вы писали:

IT>>>А что ты тогда понимал под "производственным процессов", когда об этом говорил?


MS>>Я имел в виду процесс разработки софта по типу конвейера. Тот процесс, где яко бы нужно повышать эффективность и производительность труда.


IT>Нет, я не про то. С этим как раз пока большие проблемы. И пока менеджмент не поймёт, что программистов нельзя считать поштучно как землекопов ситуация не измениться.


Золотые слова!
Но ты бы определился только, что для тебя важнее: либо все дружно на C#, VS2005 и решарпер (там такая феффиктность — одним щелчком мыши восемь классов переименовал!), либо отдельное отношение к каждому программисту (и нужно учитывать то, что кто-то предпочитает работать не в VS и даже (о ужос!) не в другой IDE).

Извини, ещё вопрос.
А почему нельзя? Ну, почему нельзя программистов считать, как землекопов, поштучно? А по-моему можно.
Особливо, когда все (программисты, а не землекопы) начнут использовать самый продвинутый инструментарий для единственно правильной ОС... Тогда сам бог велел. Считать поштучно.

Вон, и Влад2 говаривал: "я и миллионы программистов..." Там ещё что-то про прогресс и лентяев было, но увы, не помню... Влад уже всех посчитал, а менеджерам почему нельзя? Да, у них это входит в должностные обязанности!

И потом, посуди сам.
Профессия программист уже потеряла статус инженерной, и если ситуация не переменится, то её статус понизится ещё. (Зато каждая домохозяйка сможет слабать свою ерп систему! Жизнь до Visual Studio 2010 — конфеты, жизнь после Visual Studio 2010 — оргазм!) А низко квалифицированную рабсилу, как тебе должно быть известно, положено считать поштучно.

P.S. Погодь, а может я тебя не правильно понял. Может ты предлагал не мелочится, а считать программистов сразу десятками, сотнями или даже тысячами!
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 03.03.06 15:14
Оценка: 13 (1) +1
Здравствуйте, mrozov, Вы писали:

M>Давайте попробуем себе представить деревню во время посевной. Ежели я в проведении аналогий где-то сильно облажаюсь — просьба сильно ногами не пинать, я парень городской. И вообще — не воспринимайте слишком серьезно.


Оставим в покое сравнения, не в них суть. Хотя сажать внучную зернышко к зернышку — это уж точно клиника. Жрать-то надо чего-то

M>И что любопытно — никаких причин жалеть Васю Пупкина нет и быть не может. Он вполне себе счастливый человек. А вот кого можно и нужно пожалеть, так это директора местного совхоза "Назад в коммунизм". За что ему такое счастье?


Во! Спрашивается, зачем его жалеть? Зачем он этого Васю Пупкина содержит? Это я к тому, что критерий здесь один — востребованность. Пусть я маньяк, пусть даже идиот, каким Вы выставили этого несчастного Васю Пупкина. Но те кто платит мне деньги — они что, тоже идиоты? Как тот директор колхоза?

Кстати, найти ту область, где и платили бы хорошо (востребованность) и самому было бы интересно — это и есть самая сложная задача. Но игра стоит свеч.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[9]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:08
Оценка: 10 (1) -1
Здравствуйте, IT, Вы писали:

IT>Если архитектор не пишет код, то это не архитектор, а бла-бла-бла архитектор. Прошу не путать


архитектор должен писать код, но только не для того проекта, который он в данный момент проектирует. Из совмещения этих двух занятий обычно ничего хорошего не получается. ИМХО
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 12:38
Оценка: 6 (1) +1
Здравствуйте, Sinclair, Вы писали:

VD>>Между тем GDI+ обеспечивает более чем достаточное качество графики.

S>Да где ж оно достаточное-то?

А где же нет? Если не брать субер абсолютные критерии, то GDI+ с лихвой себя окупила.

Возими, например, Visio. Ты работал его последними версиями?
Я вот работал. Меня более чем удовлетворяют его возможности и скорость.
GDI+ — это не асболютный лидер, но это явный шаг вперед. И шаг релаьный. Он рельно доведен до промышленного применения.

На базе GDI+ сделано куча продуктов устраивающая кучу людей. Есть куча библиотек диаграм, генераторы отчетов и т.п.

S> Лично мне оно очень не нравится.


Аргументы? Отрешись при этом от наличич чуть более навороченной библиотеки.
Что именно не нравится в GDI+?

S> Я не понимаю, почему нельзя было позвать нормального специалиста и сделать GDI+ в пятьдесят раз быстрее и в четыре раза качественнее.


Хотя бы потому, что специалисты которые там работают вряд ли сильно уступают McSeem2. Просто перед ними стояла другая задача. Им нужно было создать удобную библиотеку для повседневного применения и они это сделали. А супер-навороты достойные Фотошопов — это просто не была их задачей.

McSeem2, например, гордится невероятным качеством сглаживания которого он добился. Что же? Похвально! Это здорово. Особенно здорово если при этом нет тормозов. Но чер побери качество сглаживания GDI+ меня более чем удовлетворяет.

И вообще надо понимать, что когда GDI+ проектировалась, то рассчитывалось, что все ее функции в конечном итоге будут акселерированны аппоратно. То есть GDI+ выполняла две задачи:
1. Создание интерфейса.
2. Базовоый реализации с которой можно сверяться.

Что касается скорости, то в современных дровах машинах многие функции GDI+ акселерированы и не вызывают нареканий по скорости на современных машинах.

Уж в 50 раз точно GDI+ не ускорить. От силы раза в 2-3.

Так что это больше пиар от McSeem2. Я его понимаю. Это его детище. Он в нем души не чает. Но мы то должны к любому пиару относиться сдержано и выделять только конструктив.

А конструктив таков. McSeem2 профи в оптимизации 2D операций на имеющемся железе и старых API. Но это не являлось главной задачей при проектировании GDI+.

Так что наличие в команде GDI+ McSeem2 возможно просто ничего бы не дало. Так как ему просто не дали бы убивать месяцы на вылизование чего-то сверх меры.

В конце концов 98% пользователей GDI+ не используют и 10% возможностей этой библиотеки. И если бы эта цифра повысилась бы до 99%, то выигрыш был бы вряд ли заметен.

VD>>В итоге мы имеет целую кучу компонентов и конечных решений на базе этой библиотеки и в упор не замечае решений на столь замечательной библоитеке McSeem2.

S>Влад, если бы AGG входил в WinXP, а GDI+ c тем же интерфейсом и т.д.

Погоди... А ты не рассматривашь возможности, что из-за корпления над мелочами в WinXP вообще небыло бы никакой библиотеки? Это по твоем улчеше?

Кто вообще сказал, что в MS не могут сделать нечто такое же крутое как AGG? Может быть тут просто проявляется проблема неуловимого Джо?

Пойми, AGG живет на очень узком сегменте рынка. У МС задачи куда более широкие.

S> был доступен как даунлоад на антигрэйне, то зуб даю — мы бы вообще такой аббревиатуры не знали. Тут вон неподалеку меня убеждают, что невозможно впарить людям классный бесплатный браузер взамен предустановленного IE, даже 3.0. А уж отказаться от предустановленной библиотеки — вообще фантастика.


Это не првда. Просто IE имеет не меньшее качество чем "классный" броузер. Просто те кто считают "классный броузер" классным не чаяно или намерянно умалчивют о некторых недостатках. Или том, что разница не ощутима для большинства потребителей. С теми же броузерами, как только они стали дотягиваться до МС и получили хоть масенькое приемущество в чем-то, то ими тот час же начали пользоваться миллионы.

S>Ты конечно прав во многом. А что ты скажешь, если МС таки приобретет AGG для следующей винды? Им там как раз остро потребуется векторная графика


Я уже не раз сылшал такие вот слова. "А что если это выпустит МС?..."

Все очень просто. Лично для меня не важно кто выпустит. Для меня важны потребительские качества. Я пользуюсь продуктами МС только от того, что потребительские качества их продуктов выше чем у конкурентов.

AGG несомнно хороша по одному из свойств, но это свойство мне в общем-то не так важно. А вот по другим свойствам AGG резко проигрывает. Мне вообще не нужна библиотека которую я самогу использовать из С++. Мне нужна библиотека с удобной объектной моделью которую я смогу использовать из удобного мне средства разработки.

Так вот если МС просто купит AGG и выложит в свободный доступ, то ею воспользуются те 50 человек в мире которые делают разные векторые программы. И не воспользуются миилоны, так как это не удобно.

А вот если МС заменит софтвреный рендериг в GDI+, то конечно я ей воспользуюсь так как это в общем-то ничего не будет стоить. Но это же может сделат и McSeem2 и его контора. Но они этого неделают. И это их личные проблемы.

Между тем в скором времени нас (ну, многих из нас) вооще не будут волновать проблемы 2D библиотека прошлого поколения к которым относятся и GDI+ и AGG. Ведь выйдет Авлаон с аппоратной поддержкой. McSeem2 конечно сразу обругает ее сказав, что сглаживание там хреновое или еще что не так. Но его послушают только ненавистники МС и те кому делать нечго. А знашь почему? Да потому, что МС решает проблемы в глобальном масштабе. Он создает ГУИ нового поколения. И если такие потребительские качества как качество сглаживания будут не удовлетворять основную массу потребителей, то в МС займутся этой проблемой и решат ее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 15.02.06 04:15
Оценка: 5 (1) +1
Здравствуйте, Дарней, Вы писали:

IT>>Если архитектор не пишет код, то это не архитектор, а бла-бла-бла архитектор. Прошу не путать


Д>архитектор должен писать код, но только не для того проекта, который он в данный момент проектирует. Из совмещения этих двух занятий обычно ничего хорошего не получается. ИМХО


Если есть возможность всегда передать свой код другому в случае проблем со временем, и такая необходимость не возникает регулярно и по причине "ну я вот тут показал как, а теперь ты давай, сынок", то можно совмещать без проблем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 15.02.06 03:46
Оценка: 1 (1) +1
Здравствуйте, IT, Вы писали:

КДВ>>Кстати, пример на виду. РСДН-щики написали мега-приложение для чтения ньюсов, в котором я сейчас эти строки и пишу. Но. Эта задача БАНАЛЬНА по сравнению с разработкой того же Решарпера.


IT>Ты бы ещё со студией сравнил или с написанием висты. Ты в курсе, что команда студии — это 500 человек, а число пишущих рсдн-щиков в каждый конкретный момент меньше одного?


Ну так я и не сравниваю. Это ж обычная фривара. Ничего особенного. Море таких продуктов (подобной сложности). Делаются небольшим коллективом (часто из 1-го человека). Если востребованны — потихоньку развиваются. Еще раз — ничего особенного, банальный софт. Тут идея удачна, поэтому пользуются. А технологически — банальность. Мы ж не про маркетинг, а про технологии.

IT>Ну почему же? Сейчас вся передовая общественность увлечённо наблюдают за развитием Nemerle. Некоторые предрекают ему судьбу, аналогичную C++, пришедшему в своё время на замену C.


Я эту передовую общественность только на этом сайте видел. Да и то — не передавая, а фанатичная. Посмотрим. Вон, на жаба-сайтах (www.theserverside.com, www.javalobby.org) уже сколько лет про аспектно-ориентированное программирование народ бодается. Это не язык, это технология, методики и т.д. и т.п. И что? Пока толком не ясно что же от этой фишки хорошего, что плохого. Кто хотел — напробовались. Пока реально тишина. Может лет за 10 что-то сдвинется.

Так что передовая общественность за чем только не наблюдает.

КДВ>>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.


IT>Ты когда-нибудь сам писал гуй сложнее трёх больших зелёных кнопок на форме? С валидацией, с подсветкой изменений, с клавиатурной акселерацией? Я имею ввиду достаточно умный гуй, который сам ведёт пользователя по форме?


Писал, писал ))) Идиотское занятие, если это делать приходится второй раз. Я тут свое мнение выражаю, может кому нравится. Тут на вкус и цвет...

КДВ>>И за это платят БОЛЬШИЕ бабки.


IT>Давай мы лучше не будем в эту сторону, OK? Разговоры про большие зарплаты и размеры головного мозга мне последнее время уже порядком начинают поднадоедать.


А я не про ЗП, я про востребованность. В экономике ее оценивают именно через деньги, которые готовы заплатить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Философия эффективности труда
От: vdimas Россия  
Дата: 20.02.06 22:32
Оценка: 1 (1) +1
Здравствуйте, IT, Вы писали:

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


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

Большинству программистов у нас, к сожалению банально НЕ УДАЕТСЯ найти задачи, сложнее этих шестеренчатых пар. Любая задача интересна лишь в первый раз. В 10-й и 100-й раз — это уже рутина. Ситуацию усугубляет то, что рынок программистского труда в странах СНГ отличается характерным перекосом в сторону тех самых "конвеерных" задач. Это реально существующая неприятность для наших программистов.
Re[19]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.02.06 05:46
Оценка: 1 (1) +1
Здравствуйте, craft-brother, Вы писали:

CB>Не стоит придираться к понятиям. Эти понятия возникли задолго до программирования. И я применяю их по аналогии. Единственная мысль, которую я никак не могу убедительно донести до моих уважаемых оппонентов, это то, что переход в производстве ПО от ремесла и кустарщины к мануфактуре, основанной на специализации и разделении труда, неизбежен и уже идет. Прошу не путать мануфактуру с конвейером. Разработка ПО это не конвейер! Проектирование ПО заканчивается только после запуска компилятора. Более близкая аналогия это конструкторское бюро, в котором над проектом нового космического корабля трудятся тысячи конструкторов и инженеров, при этом каждый разрабатывает свой компонент. Ну, не получится кустарными методами разработать MS Office, при численности команды в 500 человек.

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

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

Пойми, никто не призывает отказаться от разделения труда и заставлять весь коллектив включая бухгалтера рисовать UI, UML-диаграммы, писать код на C# и SQL.
Но я лично глубоко убежден, что в самом-пресамом фабричном производстве софта нельзя стать "специалистом по написанию оператора return". Разделение труда не означает разделения умений. Я пока не видел ни одного толкового разработчика, знакомого с чем-то одним. Все нормальные разработчики умеют дофига всего.
И отказываться от изучения какой-то технологии под предлогом того, что это-де не барское дело — путь в тупик. А usability — это еще одна технология, ничуть не хуже чем ООП или там SQL. За ней тоже стоит здравый смысл; а творчества чуть больше только потому, что результат чуть меньше формализован.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 06:05
Оценка: +2
Здравствуйте, McSeem2, Вы писали:

MS>Эвона как. Ну тогда значит я не хочу быть таким "программистом".


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

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


Интересно, а чего это тебя так сильно престиж интересует? У тебя с этим какие-то проблемы?

MS>Решарпер приведен лишь в качестве некой фигуры речи.


ну конечно. Тем более, что как инструмент для разработки алгоритмов он никогда не позиционировался.

MS>Странно. Вроде бы понятными словами изъясняюсь...


Слова по отдельности все понятные, а вот вместе складываются в какую-то бессмыслицу. Только время от времени из под словесной мишуры проглядывает примитивное бахвальство — эвон я какой крутой да уникальный.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[7]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 08:33
Оценка: -2
Здравствуйте, kedik, Вы писали:

K>Но все они являються программистами. Так же как хирург и гомеопат — врачи.


а бухгалтер, который работает в больнице — это тоже врач?

K>PS. В данном случае кодеры похоже набросились на архитекторов — рьяно убеждая последних использовать средства кодирования для решения архитектурных задач... Архитекторы искренне недоумевают... Прикольно...


Похоже, что кое-кто попал со своими догадками пальцем в ж... тьфу, небо
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 09:01
Оценка: +2
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, kedik, Вы писали:


K>>Да... ровно на столько, на сколько бухгалтер работающий в софтверной компании — программист.


Д>молодец, возьми с полки пирожок А теперь еще посмотри в энциклопедии, с какого века ведет своё происхождение понятие "алгоритм"


Не надо путать жесткое отстаивание своей позиции и элементарное хамство
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 09:02
Оценка: +1 :)
Здравствуйте, Дарней, Вы писали:

Д>молодец, возьми с полки пирожок А теперь еще посмотри в энциклопедии, с какого века ведет своё происхождение понятие "алгоритм"

Да, я молодец. Спасибо, я знаю

С какого века... хм... Я помню когда наш преподаватель в институте сказал: "Нужно изучать программирование с самых основ"... после чего я застал моего соседа по общаге увлеченно читающего книгу с названием на обложке "Основы мироздания"... И он был чертовски прав!

А другой преподаватель однажды сказал другое:
"Я не буду учть вас программировать на IBM PC (тогда это было новое и модное)... или на С++ (тогда это тоже было ново и модно для нас)... я попробую научить вас программировать... а что и на чем, станок с ЧПУ, супер-кпьютер, процесс или коллектив — для вас уже не будет иметь значение..."
Re[5]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:29
Оценка: +2
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.


Его проектируют специалисты по юзабилити, но никак не художники. Кстати, эти специалисты всегда находятся как минимум в тесном контакте с разработчиками и продакт-менеджерами, т.к. при разработке UI приходится учитывать особенности работы и реализации приложения. Например, кое-какие задумки юзабилистов просто нереально заимплементить с точки зрения производительности приложения, а другие из них могут идти вразрез с use cases, разработаными product management department-ом (разработанными не на голом месте, а как результат тесного общения с заказчиком).
Re[10]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 14.02.06 09:43
Оценка: :))
Здравствуйте, Oyster, Вы писали:


O>А я без рефакторинга уже как без рук. Если пересаживаюсь на студию без решарпера — становится неудобно. Так что реальная польза есть. Имхо.


Судя по тому, что ты сказал (если читать как есть) — пользы как от курения ))) Уже без него не можешь
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Философия эффективности труда
От: cvetkov  
Дата: 14.02.06 12:11
Оценка: +2
EXO>Я тоже не считаю, что это было певым приоритетом. И смоти ниже на слова: "если этот выигрышь единственный".
EXO>А ради авторефакторинга (по заявлениям самого микософт) было убрано разделение на cpp и h файлы, например.

разделение на cpp и h для рефакторингов не проблема
оснавная проблема #include и #define

знаю потомучто сам участвовал в написании рефакторингов
Re[3]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:02
Оценка: +1 :)
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Кстати, пример на виду. РСДН-щики написали мега-приложение для чтения ньюсов, в котором я сейчас эти строки и пишу. Но. Эта задача БАНАЛЬНА по сравнению с разработкой того же Решарпера.


Ты бы ещё со студией сравнил или с написанием висты. Ты в курсе, что команда студии — это 500 человек, а число пишущих рсдн-щиков в каждый конкретный момент меньше одного?

MS>>>Все эти яростные приверженности к определенным языкам, средствам проектирования и рефакторинга — это ложный карасс, гранфаллон.

IT>>Это банальная зависть к людям, которые находятся на острие технологий

КДВ>На острие технологий маркетинга? ))) Думаю, что речь идет именно об этом.


Ну почему же? Сейчас вся передовая общественность увлечённо наблюдают за развитием Nemerle. Некоторые предрекают ему судьбу, аналогичную C++, пришедшему в своё время на замену C.

IT>>А это говорит твоя лень.


КДВ>Решарпер мозгов не отнимает. Кодирование занимает достаточно малый процент времени, а решарпер его просто может несколько сократить (автоматизировать)


Кодирование — это ровно такой процент, который позволяет всё закодировать и отладить. Не больше и не меньше.

КДВ>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.


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

IT>> Ну да, гораздо лучше 42 раза переписать одни и теже 50к кода.


КДВ>И добится совершества. Ну или приближения к нему.


Я же не спорю. Подковать блоху действительно не просто.

КДВ>И за это платят БОЛЬШИЕ бабки.


Давай мы лучше не будем в эту сторону, OK? Разговоры про большие зарплаты и размеры головного мозга мне последнее время уже порядком начинают поднадоедать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 21:49
Оценка: +2
Здравствуйте, kedik, Вы писали:

K>Помогает не сахар... помогает гомеопат...

K>... если он понимает что делает... ну и эфективные методы использует конечно

Промывку мозгов?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 23:20
Оценка: :))
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>"Имя, сестра, имя!" Какой оно температуры и цвета?


Он цвета лазурного восхода и тепературы парного молока. В общем, ничего интересного. Можешь не смотреть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 00:08
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

S>Вместо того, чтобы платить "сильным звеньям", способным за полгода наколбасить мегабайт исходников, им было бы значительно дешевле нанять одного Максима. А результат оказался бы лучше.


S>Выводы, справедливые "в среднем", иногда неприложимы к частностям.


Что есть то есть, но вот я не уверен, что ты прав в данном случае. GDI+ — это не только библиотека дающая качество выше чем GDI. Это еще API удобный в использовании. И гарантия стабильности этого АПИ.

Спору нет, беблиотека McSeem2 похоже действительно дает несоколько более высокое качество. Вот только ее интерфейс не к черту не годится. Это низкоуровневая бибилотека со сложным интерфейсом. И McSeem2 натурально борется за то чтобы положение вещей не изменялос (как показывают споры о интерфейсе GDI+).

Между тем GDI+ обеспечивает более чем достаточное качество графики. В итоге мы имеет целую кучу компонентов и конечных решений на базе этой библиотеки и в упор не замечае решений на столь замечательной библоитеке McSeem2.

Откровенно говоря меня устраивать скорость и качество Visio написанного на базе этой библеоткеки. И меня устраивает интерфейс этой библиотеки. Так что я скорее соглашусь ArhAngelVezel. Мне не нравится такая эффективность. Вылизывать все можно до потери пульса. Но одной гордостью сыт не будеь.

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

В общем, я виду к тому, что рулит всегда разумный компромис. Я сам из тех людей что с удовольствием будут заниматься творчеством забив на повседневные банальности, но я сликом хорошо понимаю насколько это порочный путь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 03:12
Оценка: :))
Здравствуйте, Дарней, Вы писали:
Д>А это просто результат плохого управления.
Д>Вот к примеру, ты можешь представить себе команду корабля, в которой каждый член экипажа и кок, и машинист, да еще и прокладывает курс, если у штурмана не нашлось на это времени?
Конечно представляю. А ты, поди, на яхте и не ходил никогда?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 15.02.06 05:34
Оценка: -1 :)
Здравствуйте, Дарней, Вы писали:

Д>если начинаешь писать код сам, то очень быстро теряется общая картина. Я пробовал делать так сам, наблюдал за результатми работы других, и каждый раз результаты были самые неприглядные. Хотя во время работы ты сам это не замечаешь, но стоит отвлечься и пару часов побездельничать — и начинаешь понимать, что до этого порол полную чушь Или пару дней — в зависимости от глубины погружения. И тогда до тебя доходит, что можно было пойти по другому пути и намного упростить работу себе и другим, но ты этого не понимал, потому что залез по уши в детали того пути, которым ты пытался идти.

Д>В общем, ни руководитель проекта, ни архитектор не должны сами писать код для своего текущего проекта. И никто меня не переубедит

А ты побездельничай пару дней...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Философия эффективности труда
От: Шахтер Интернет  
Дата: 15.02.06 07:49
Оценка: :))
Здравствуйте, IT, Вы писали:

IT>Ну почему же? Сейчас вся передовая общественность увлечённо наблюдают за развитием Nemerle. Некоторые предрекают ему судьбу, аналогичную C++, пришедшему в своё время на замену C.


C## ?
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[10]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.02.06 14:02
Оценка: +2
Здравствуйте, Mystic, Вы писали:

M>А вот у меня иногда возникает ощущение, что проекты с 1990-х годов сложнее не стали (особенно если учесть большой рост производительности PC), а вот количество людей на них выросло в разы То, что раньше писалось на Clipper и FoxPro одним человеком, сейчас пишется в связке ASP.NET + MS SQL коллективом...

Очень интересно. Я вот что-то не видел решений на Clipper и фокспро с данными под десяток гигабайт. И опять же, как только количество клиентских мест достигает десятка, клипперные решения почему-то начинают уходить куда-то в сторонку. Так в целом все конечно точно так же. Только компьютеры стоят уже не только у главбуха и директора, да выписка делается не ручкой по бумажке с последующим занесением руками.

Сложность в основном, конечно, в эффекте масштаба. Очень у нас бизнес бурно развился за последние 15 лет. Причем вроде и занимаются-то тем же: купили, продали... Только немножко побольше.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.02.06 15:16
Оценка: -2
Здравствуйте, EXO, Вы писали:

EXO>Влад, пойми, меня твои сомнения не интересуют. То есть совсем. Поскольку мне лично от тебя ничего не надо.


ОК. Но извини, тогда твои слова не стоят ломоного граша.

EXO>И мне достаточно пофигу веришь ты или нет. Я просто рассказал, почему лично я не использую .Net.


А я могу расскзать, что ты это делашь так как тебе приплачивают разные злые дяди из IBM. И что? Это пусословие. Ты тут выкатил обвинений. Тебя попросили оптвердить свои слова. Ты отказался. Все. Разговаривать больше не о чем.

EXO>Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо?


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

Так что уже видно, что ты говоришь не правду. Специально проверил слелав поиск по "97" и по Word. Никаких замечаний не нашел.
Так что заканчивай выдумывать.

EXO> Уличать MS? А опять же нафига? Доказывать что-то тебе? А не слишком ли жирно будет?


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

Дотнет работает на миллионах машин. С некоторого времени — это часть Виндовс. Я лично ставил его н кучу разных машин. Так что не нужно лить грязи.

VD>>Что касается вопроса, то я не раз посылал багрепорты в МС и не разу не видел, чтобы на хорошо оформленный отчет об ошибках не было соотвествующей реакции.


EXO>Кто сказал что небыло? Предложение заменить офис вполне соответсвующая реакция...


Это откровенная не правда. Предложение тебе могли дать только как одно из решений проблемы. В любом случае проблема должна быть подтверждена и тебе должны были указать когда она будет устранена.

Ты же даже не знашь как реально работает фидбэк у МС.

EXO> и достаточно корректная — я бы на их месте сам так ответил. Напомню, что офис 97 русифицировал не MS.


Это тоже не совсем так. Русификация Офиса проводится под присмотром МС и МС за это проверят. В любом случае несовместимость в фрэймворке никакого отношения к Ворду иметь не может. Это баг фрэймворка, так как он нарушает (по твоим словам) работу зарелизенного до этого приложения.

EXO> В евро-версии русского языка тогда еще небыло. Причем я знаю минимум 3 независимые русификации оного.


Ссыкла подтверждающая твои слова будет?


ЗЫ

В общем, ты меня извини, но ты явно пыташся придумать проблему. Фрэймворк без проблем ставится на все версии виндовс заявленные в совместимости и физически не может повредить ранее установленные приложения, так как не модифицирует ничего в ОС. Фрэймворк довольно замкнутое приложение. Он влияет только на приложения на нем созданные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 17.02.06 15:31
Оценка: +2
Здравствуйте, Mystic, Вы писали:

M>Все это я к чему? Да вот, решил переписать шашечную прорамму. Я точно помню, что реализации ее заняла у меня в студенчестве два дня.


Зря ты её стёр. Если бы сейчас на неё посмотрел, то вряд ли бы написал этот пост. Я почти уверен, что там кроме алгоритма ничего и не было, а шаг влево вправо означал попытку к бегству со всеми вытекающими. К той же самой задаче сегодня ты подошёл уже более профессионально, а не тяп-ляп, а как известно, 80% написания приложения занимают 20% времени, а оставшиеся 20% доводки приложения до ума занимают как раз 80% времени.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Философия эффективности труда
От: craft-brother Россия  
Дата: 20.02.06 10:42
Оценка: -2
Здравствуйте, McSeem2, Вы писали:

MS>"Промышленное производство ПО" — это оксиморон (буквально — остроумно-глупое высказывание, типа как "живой труп"). Ну или под термином "промышленное производство ПО" подрузамевается штамповка CD и упаковка в коробки. Но в этом процессе программисты как бы и не учавствуют совсем...



"Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает для пользователя."

Re[3]: Философия эффективности труда
От: mrozov  
Дата: 02.03.06 07:26
Оценка: -2
>Понял?
Я вообще понятливый. Хрен они туда бегут. И хрен они с ним консультируются. Есть в мире хозяйства покрупнее и авторитеты гораздо солиднее. А деятель этот никому не нужен.
Понял?

P.S. Лично с автором незнаком, о его заслугах ничего не знаю и лично против него ровным счетом ничего не имею. Говорю и подходе в целом.
Re[5]: Философия эффективности труда
От: mrozov  
Дата: 02.03.06 08:18
Оценка: +2
Здравствуйте, denis_krg, Вы писали:

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


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

P.S. На самом-то деле я всю жизнь занимался (80% времени) разработкой всяких там библиотек, компонентов и фреймворков. Так что я как раз сам большой спец по точечной засадке с соответствующей репутацией в узких кругах. И в конце концов пришел к выводу, что это вполне себе тупая работа. А интерестная и высокоинтеллектуальная (а также сложная и творческая) это как раз разработка архитектуры конечных решений. Никому эту точку зрения не навязываю, но к людям, категорически заявляющим обратное, отношусь с изрядной долей иронии.
Re[6]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 03.03.06 03:42
Оценка: +1 :)
Здравствуйте, minorlogic, Вы писали:

M>Оценка -1 выражает несогласие с мыслью написанной в посте ? вроде так !

M>1. Предлагаю не переносить на себя (как на личность) оценку , а оставить ее оценивать ПОСТ.
M>2. Если уж оценка переносится на личность , то забить на оценку.

Наверное мы уже слишком отклонились от темы. А вообще, конечно же согласен.
Да, кстати, как ты думаешь, может предложить РСДН-щикам развить как-то еще систему оценок? Чтобы было видно, что за человек на форме. Общие оценки, основные опоненты и основные поддерживающие стороны? Чтобы это быстро было видно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.06 13:13
Оценка: 42 (1)
Здравствуйте, IT, Вы писали:

IT>О, кстати, насчёт юзабилити. Синклер, не мог ты отбивать свои тветы пустыми строчками, а то всё в глазах сливается, не понятно кому плюсы ставить, а кому минусы



Я постараюсь
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Философия эффективности труда
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 16.02.06 09:29
Оценка: 12 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Когда я работл с С++ у меня было ощущение что я работаю с чемто очень твердым, тяжолым и хрупким, а когда я начал работать на C# с решарпером у меня появилось ощущения что я работаю с чемто очень мягким, легким и пластичным. Это конечно еще далеко не придел мечтаний но это шаг в правильном направлении.


А вот у меня иногда возникает ощущение, что проекты с 1990-х годов сложнее не стали (особенно если учесть большой рост производительности PC), а вот количество людей на них выросло в разы То, что раньше писалось на Clipper и FoxPro одним человеком, сейчас пишется в связке ASP.NET + MS SQL коллективом... Понимаю, что сахар был слаще, но когда пару лет назад я решил немного пописать в RING 0 без всякой OS, то получил много удовальствия
Re[9]: Поштучно говоришь...
От: IT Россия linq2db.com
Дата: 14.02.06 18:54
Оценка: 10 (1)
Здравствуйте, Kubera, Вы писали:

K>Но ты бы определился только, что для тебя важнее: либо все дружно на C#, VS2005 и решарпер (там такая феффиктность — одним щелчком мыши восемь классов переименовал!), либо отдельное отношение к каждому программисту (и нужно учитывать то, что кто-то предпочитает работать не в VS и даже (о ужос!) не в другой IDE).


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

K>А почему нельзя? Ну, почему нельзя программистов считать, как землекопов, поштучно? А по-моему можно.


В отличии от землекопов, выполняющих физическую работу, программисты выполняют работу умственную. Кто-то мудрый сказал "Один человек может быть сильнее другого физически в несколько раз, умнее в несколкьо десятков раз, сильнее духом в несколько сотен раз". В результате, один программист запросто может заменить собой пучок псевдо-девелоперов. А если к нему подойти с отдельным отношением и решарпером, то и пару десятков, которым никакой решарпер уже не поможет. В качестве примера в этом топике Синклер уже привёл того же Максима, который воплне мог бы заменить нескольких аболтусов из команды GDI+.

K>Особливо, когда все (программисты, а не землекопы) начнут использовать самый продвинутый инструментарий для единственно правильной ОС... Тогда сам бог велел. Считать поштучно.


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

K>Профессия программист уже потеряла статус инженерной, и если ситуация не переменится, то её статус понизится ещё. (Зато каждая домохозяйка сможет слабать свою ерп систему! Жизнь до Visual Studio 2010 — конфеты, жизнь после Visual Studio 2010 — оргазм!) А низко квалифицированную рабсилу, как тебе должно быть известно, положено считать поштучно.


Эка тебя жизнь поколбасила Программисты уже не инженеры, домохозяйки, ерп

Кстати, эта самая реклама от MS рассчитана на тот самый манагерский делетантизм и непрофессионализм, который преобладает в нашей индустрии. Нами ведь руководят в основном технически малограмотные прорабы и продавцы, люди знающие об IT технологиях не больше чем твои домохозяйки. Сейчас хорошего программиста найти сложно, а уж профессионального IT менеджера так днём с огнём.

K>P.S. Погодь, а может я тебя не правильно понял. Может ты предлагал не мелочится, а считать программистов сразу десятками, сотнями или даже тысячами!


И считают, как землекопов. Кто-то тут говорил про 40 тысяч кубиков в индии. Боюсь, что 8 дней в неделю все эти кубики будут проводить на митингах.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: PS
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:40
Оценка: 9 (1)
Здравствуйте, denis_krg, Вы писали:

_>А я не про иконки. Я просто рассказал о том, что видел сам своими глазами. Да, действительно, художник должен работать в тесном контакте с программистами, спецами по юзабельности и т.д. и т.п. Но все-таки. Без художника никуда. Точнее результат будет не тот. Красоты не будет. Правда не везде она нужна, но это уже другая тема.


А я о том, что без юзабилити-специалиста никуда. Без него художник нарисует что-то красивое, но жутко неудобное и никому не нужное. Потому что эталонный художник умеет только рисовать (зато делает это хорошо), а логика организации UI ему как правило чужда.

PS: Да, бывают лица, которые совмещают в себе и талант художника, и талант юзабилити-специалиста. Но пока что я видел только юридические лица такого типа
Кстати про юзабилити
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.06 08:08
Оценка: 9 (1)
Вот есть такой сетевой персонаж Рома Воронежский.
Вот его сайт.
А вот из него цитата:

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

И я с ней на 100% согласен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Философия эффективности труда
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 14.02.06 10:35
Оценка: 6 (1)
Здравствуйте, McSeem2, Вы писали:

MS>Безусловно придется! Вопрос лишь в том, кому придется? Ты же не ожидаешь, что, скажем, старикан Дональд Кнут тоже должен заниматься этой мышиной мастурбацией в форм-дизайнере? Ему как-то даже не к лицу. Я за разделение труда. В опере пусть поют, Кнут пишет книжки в своем ТеХе, я буду скритеть остатками мозга над алгоритмами. А формы пусть дизайнит кто-нибудь другой.


Вот как раз от Д. Кнута я как раз такого и ожидаю Он производит впечатлдение страшно педантичного человека. Что его подтолкнуло к созданию TeX? То, что ACP выглядело в гранках с эстетической точки зрения ужасно (в типографии литейный набор был заменен фотонабором, что ухудшило качество). Или, например, его история про дельту, когда он начал избегать использвоание этой буквы, а потом занялся вопросом: почему? Ну и немного утяжелил ей хвостик. Да и в самом TeX-е много средст именно ручной доводки тех же формул. Если читать TeX-book, то можно встретить: если скобки окружают сумму, то TeX несколько неправильно выбирает размер скобочек, желательно проставить размер вручную и т. д. Вообще, этот человек очень много придает внимание не только содержанию, но и форме. Если вы у него на HTML странице найдете хоть один незакрытый тег, то это приравнивается к опечатке и вы получаете $2.95. Поэтому, имхо, Д. Кнут как раз очень много внимания уделил бы именно интерфейсу.

BTW, у Д. Кнута я зато обнаружил одно интересно замечание. Когда он проектировал TeX, то старался сделать так, чтобы его программа удолетворила 99% всех требований. И расчитывал на то, что те, кто попадает в этот 1% просто изменят соответсвующим образом исходники TeX. Поэтому TeX не содерэит средств для сочетания двунаправленых языков, автоматического расположения иллюстраций... Д. Кнут на последний вопрос заметил: "Расположение иллюстраций я выполняю в самом конце работы над книгами, это занимает совсем немного времени и даже доставляет удовольствие. Конечно, если бы я работал в типографии и расположение иллюстраций было бы моей каждодневной обязаностью, я бы искал путь это оптимизировать. А так я решил, что те, кто будут заниматься этим, внесут изменения в исходники TeX, ..." (своими словами, смысл примерно тот же).

Я тоже много занимался и занимаюсь алгоритмами. Примерно как ты описал. Но мне также и нравиться заниматься "мышиной возней" и разрабатывать интерфейс. Мне это тоже интересно. В общем-то проектирование удобного интерфейса тоже увлекательное дело, особенно когда интерфейс нетривиален и надо сочетать противоречивые требования.
Re[7]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 12:52
Оценка: 6 (1)
Здравствуйте, McSeem2, Вы писали:

IT>>А что ты тогда понимал под "производственным процессов", когда об этом говорил?


MS>Я имел в виду процесс разработки софта по типу конвейера. Тот процесс, где яко бы нужно повышать эффективность и производительность труда.


Нет, я не про то. С этим как раз пока большие проблемы. И пока менеджмент не поймёт, что программистов нельзя считать поштучно как землекопов ситуация не измениться.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 14:09
Оценка: 4 (1)
Здравствуйте, Дарней, Вы писали:

AVK>>Более того — мне куда проще потом самому реализовать то что я спроектировал, меньше работы по формализации, объяснению и контролю. Вот только я не резиновый, все и сразу сделать не могу.


Д>Вот-вот-вот. У меня всё именно так и происходило. Проще самому написать, чем объяснить другому программисту и потом стоять у него над душой, чтобы не накосячил. И всё, понеслось


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

AVK>>ИМХО всего лишь (не обижайся) недостаток опыта. Если будешь тренироваться, то все у тебя получится. У меня, к примеру, получается и код писать и проектированием заниматься.


Д>Количество сущностей, которые человек может одновременно держать в воображении и работать с ними, ограничено. Тренировками можно повысить эту величину, но принципиально картину это не изменит.


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

Д> Поскольку после этого ты начнешь заниматься более сложными проектами, и вернешься к тому же, с чего начинал — голова пухнет


Это с непривычки.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[11]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 27.02.06 14:55
Оценка: 1 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>Чем это отличается от Graphics.BeginContainer/EndContainer?


Так он же только аффинный трансформер сохраняет. Кстати, почему они назвали его "Container"? Почему не "Transformer"?

MS>>Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.


AVK>Это следствие текущих возможностей железок. Теоретически в ускорителях последнего поколения можно делать гибкие конвееры на шейдерах, но результат такого решения и его востребованность я представляю с трудом.


Не совсем. Растровые конвейеры — безусловно должны работать в HW (это то, что GPU умеет делать хорошо — молотить цвета в параллель), но возможности вертексных шейдеров сильно ограничены (фактически они сильно связаны с растровыми — посчитать нормаль, цвет в вершине и т.д.). Но при помощи их все равно невозможно, например, вычислить stroke. И невозможно триангулировать полигон. То есть, все равно это надо считать на CPU. А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.

MS>>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.


AVK>А что ты скажешь о System.Windows.Media?


Да то же самое — все намешано в одну кучу. Догадались выделить в отдельный класс геометрию, да и то криво. Например, PathGeometry звучит как масло-масляное — Path это собственно и есть Geometry. Или FillRule — это фундаментальное свойство растеризатора, а не геометрии. Можно, например, попросить растеризатор нарисовать два или больше путей как единое целое? — это тривиальная операция и очень полезная. Но если можно, то у разных путей могут быть разные FillRule, у одного NonZero, а у другого — EvenOdd. И что делать растеризатору? — он не может работать одновременно с двумя. Это я к тому, что даже при беглом взгляде обнаруживаются внутренние противоречия.

Ну почему надо упираться рогом в свои ущербные и противоречивые концепции, а не посмотреть, например, на тот же OpenVG?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 03.03.06 19:01
Оценка: 1 (1)
Здравствуйте, mrozov, Вы писали:

M>Если твоя квалификация несмотря на это позволяет тебе не заботиться ни о месте работы ни о зарплате — я за тебя очень рад (без подколок). Но в целом твоя философия этому (по моим представлениям) способствовать не должна. Т.е. ты (имхо) обеспечен и уважаем несмотря на нее, а не благодаря ей.


То есть, другими словами, ты хочешь сказать, что если бы я не придерживался своей философии, я был бы столь же успешен или даже больше? Теоретически я этого не исключаю, но вот какое совпадение — пока я моя так называемая успешность резко повысилась как раз после того, как я пришел к этой своей философии и предпринял попытку разорвать порочный круг рутины. Поэтому я имею право сравнивать.
Я не призываю никого "все бросать и делать только то, что лично тебе интересно" — это ни к чему хорошему не приведет. Нужно сначала морально созреть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Философия эффективности труда
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 13.02.06 19:23
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

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


Вопрос в том, что разгребать события так или иначе придется... Да и контролы на форме разгребать... Если, конечно, мы желаем графический интерфейс Альтернатива была еще во времена MS DOS, когда приходилось все писать руками. Было примерно так: запустим программу... Нет, это кнопка слишком вправо уехала. Тут три пикселя будет мало, надо пять. И т. д. Рутина похуже будет. Конечно, можно создать язык разметки вроде TeX, который будет автоматически располагать контролы, но человеческой вмешательство в этот процесс исключать нельзя...
Re[3]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 07:17
Оценка: -1
Здравствуйте, McSeem2, Вы писали:

MS>Охотно верю, ибо через все это я проходил. Более того — я даже сподобился спроектировать и написать целый банковский опердень (о! пердень!). И это даже было интересно. Но со временем мне это все надоело и теперь одно слово "Enterprise" навевает на меня необоримую скуку и лень.


Банк — это немножко не то, как и бухгалтерия. Немного знаю и о том и о том, так что могу заявить, что имхо под термин "корпоративное приложение" банковские и 1С-овские штучки не попадают. Да и многое зависит от роли на проекте, конечно, — черновую работу делать невесело даже на самых интересных проектах.

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

А что касательно оффтопа, то на вкус и цвет товарищей нет, конечно. Может, это у меня возрастное — любовь к решению разнообразных задач
Re[4]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 07:56
Оценка: :)
Здравствуйте, Дарней, Вы писали:

Д>Разработка алгоритмов — это совершенно отдельная задача, и к программированию как таковому имеет довольно-таки опосредствованное отношение...

Эээ... А что такое программирование тогда?

Если я правильно понял мысль... то программированием непосредственно занимаеться только компилятор
Re[5]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 08:07
Оценка: -1
Здравствуйте, kedik, Вы писали:

K>Эээ... А что такое программирование тогда?


K>Если я правильно понял мысль... то программированием непосредственно занимаеться только компилятор


Программированием занимается человек, который бОльшую часть рабочего времени пишет код. Не рисует дизайн, строит диаграммы, общается с заказчиками или занимается исследованиями. А именно пишет код.
Очень просто, правда?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Философия эффективности труда
От: ArhAngelVezel Россия  
Дата: 14.02.06 08:08
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, kedik, Вы писали:


K>>Эээ... А что такое программирование тогда?


K>>Если я правильно понял мысль... то программированием непосредственно занимаеться только компилятор


Д>Программированием занимается человек, который бОльшую часть рабочего времени пишет код. Не рисует дизайн, строит диаграммы, общается с заказчиками или занимается исследованиями. А именно пишет код.

Д>Очень просто, правда?

это не программист это кодер
Re[6]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 08:14
Оценка: :)
Здравствуйте, Дарней, Вы писали:

Д>Программированием занимается человек, который бОльшую часть рабочего времени пишет код. Не рисует дизайн, строит диаграммы, общается с заказчиками или занимается исследованиями. А именно пишет код.

Д>Очень просто, правда?

Ой... а я рисую дизайн и исследованиями занимаюсь... Я уже не программист?
Re[5]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 08:41
Оценка: :)
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

[... прочитано и поскипано ...]

КДВ>Только вот не принципиально это. Много времени кодирования да, экономит. А программирования в целом — нет.


Кодирование — уже не часть программирования?

КДВ>Ага, мастер-класс показать ))) Вот тут то и начинается интерес. Когда начинаешь обобщать. Причем сделать свой движек, который кодерам сэкономит время в 2 раза — круто. Не так ли?


Именно так. Написать библиотеку, которой будут пользоваться другие

КДВ>Не надо сравнивать программирование с заточкой стамесок, строительством и другими темами. Это все натяжки. Большие натяжки. К примеру в твоем примере ты забыл, что не надо делать 2-ю версию алгоритма. Копирование бесплатно.


Это была метафора... но ладно — скажу иначе:

Да. Можно добиться совершенства в создании библиотеки Икс, которая делает Игрек. И со всех концов света люди будут качать твою библиотеку Икс, потому что она делает Игрек лучше всех. И не будет на свете другой библиотеке, равной Икс в деланьи Игрек!

Тут всё дело только в том, нравится ли тебе изо дня в день биться над проблемой Игрек, когда вокруг ещё есть проблемы Альфа, Бета и Каппа...


Разъяснение касательно "в твоем примере ты забыл": Конечно, собственно затачивать стамески всем желающим будут подмастерья. Мастер в это время будет изобретать новый способ косой фигурной заточки, который должен сэкономить до 20% времени рабочему
Re[9]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 08:45
Оценка: -1
Здравствуйте, kedik, Вы писали:

K>Да... ровно на столько, на сколько бухгалтер работающий в софтверной компании — программист.


молодец, возьми с полки пирожок А теперь еще посмотри в энциклопедии, с какого века ведет своё происхождение понятие "алгоритм"

K>PS. Будем тыкать дальше?

K>Если да... то давайте уж как нибудь поэффективней... что бы не отклоняться от темы

ну если тебе так нравится сам процесс... не буду тебе мешать
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 09:15
Оценка: :)
Здравствуйте, Oyster, Вы писали:

O>Жаль, что нет хороших инструментов рефакторинга для C++. Тогда, я думаю, ты бы оценил ту на самом деле небольшую помощь, которую они оказывают простому программисту. А со временем, возможно, не смог бы и жить без рефакторинга, как и все мы, закабалённые решарпером


O>Ведь неужели тебе никогда не приходилось выделять метод? Или переименовывать переменную? Или, скажем, менять название класса? Пусть эти операции составляют 1% твоей работы — почему бы не автоматизировать этот процент и не освободить свой мозг и свои руки для более благородных дел?


С этим то никто и не спорит.
Просто "хороших инструментов рефакторинга для C++" нет далеко не случайно.
В C# для авторефакторинга пришлось специально кое в чем ограничить язык. Стоило оно того или нет — уже вопрос.
Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет.
Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.
Re[12]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 14.02.06 09:30
Оценка: :)
Здравствуйте, Дарней, Вы писали:

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


По-моему ты конкретно преувеличиваешь. Тут Влада нет пока, все корректно. Хотя, уходим в сторону. А про "кодер — программист" я сказал в другой ветке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 09:40
Оценка: :)
Здравствуйте, Oyster, Вы писали:
O>Вот тут не соглашусь с утверждением — не вижу, откуда оно следует. Да и не чувствую я ущербности языка C#. Они боролись за строгую типизацию — это да — но хорошая поддержка рефакторинга вряд ли была приоритетом №1.

Я тоже не считаю, что это было певым приоритетом. И смоти ниже на слова: "если этот выигрышь единственный".
А ради авторефакторинга (по заявлениям самого микософт) было убрано разделение на cpp и h файлы, например.

EXO>>Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет.

EXO>>Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.

O>Никто именно о нём не кричит. Просто именно у этого топика именно такая тема.


ну тогда нет возражений.
По моему никто не спорит, что наличие авторефакторинга лучше, чем его отсутсвие. Разногласия лишь в том, на сколько это существенно.
Re[5]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 10:12
Оценка: :)
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Кстати, про художников. Мой очень хороший знакомый занимался одно время тем, что писал на Вижуал Васике написанием софта для обучения (металлургический комбинат). Причем не надо придираться к средству, разработчкик он прекрасный. Ну так про художников. Там одна тетка была, которая рисовала. Только рисовала. На фотошопе. Другая — программист на вспоможении, и он — всю анимацию анимировал. Так вот, без художника получалось просто на порядок хуже. Я сам видел, что ТАК не художник не сделает.
Ты меня конечно извини, но ты берешь мультимедиа-приложение в качестве примера. А еще есть флеш-ролики, которые конечно тоже программа, но только Масяня без Куваева ни у одного программиста не выйдет.
КДВ>Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.
Я тебя уверяю, художников там привлекают только для того, чтобы картинки рисовать. Я не спорю с этим — я уже написал, что картинки должен рисовать художник. Но ни один художник тебе не изобретет reading pane layout в аутлуке. Потому что это не картинка, а организация UI. Этим занимаются отдельные люди, специализирующиеся на юзабилити. И вот для этой задачи никакой талант не нужен. Только ленивые разработчики оправдывают кошмарные UI отсутствием художественных способностей. Читайте книги — все гуру пишут, что художественные способности нужны исключительно для художественных задач. Остальное вполне по плечу произвольному человеку, оборудованному здравым смыслом.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 11:37
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kedik, Вы писали:


K>>Но все они являються программистами. Так же как хирург и гомеопат — врачи.


VD>Гомеопаты не врачи, а шарлотаны.

Ровно в той же степени, что и хирурги
Re[2]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 13:21
Оценка: +1
Здравствуйте, last_hardcoder, Вы писали:
_>Интересно, а найти такую творческую работу можно только случайно или существует какой-то метод целенаправленного поиска?

Существует: сделать себе имя. Например, на фриварных проектах.

_> Обычно постановка выглядит так: сделай тото и тото, GUI, базу, хм..., а можешь ещё чтобы программа сама... (искуственный интеллект, в общем)


А чем тебе "искуственный интеллект" плохая задача?
Re[9]: Поштучно говоришь...
От: WolfHound  
Дата: 14.02.06 18:08
Оценка: +1
Здравствуйте, Kubera, Вы писали:

K>Но ты бы определился только, что для тебя важнее: либо все дружно на C#, VS2005 и решарпер (там такая феффиктность — одним щелчком мыши восемь классов переименовал!), либо отдельное отношение к каждому программисту (и нужно учитывать то, что кто-то предпочитает работать не в VS и даже (о ужос!) не в другой IDE).

А почему противопоставление? Не понимаю.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 19:21
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

MS>Именно так, несмотря на успешность подавляющего большинства моих прикладных проектов. Не моё это.


Понимаю. Только не понятно зачем ты себя любимого обобщаешь на всю индустрию

MS>И это ощущение усугубляется нехорошим предчуствием, что мы находимся вначале нового мыльного пузыря типа дот-комов.

MS>Но это лишь ощущение, хорошо бы оно было ложным.

Думаю, что это лишь твои ощущения. Из-за огромного количества праздношатающихся малограмотных индусов найти человека стало труднее, это факт. Но их берут в основном те, кто как Kubera ищет землекопов. Тебе это не грозит, не переживай
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 15.02.06 03:38
Оценка: -1
Здравствуйте, IT, Вы писали:

_>>А где ты видал, чтобы большую часть времени писали код? То есть непосредственно шмякали на кнопки на клаве????? Может быть ты хотел сказать, что писать код, это значит и продумывать его структуру, и на бумажке что-то рисовать и... многое другое?


IT>Мы тут последние пару дней как раз ломаем копья доказывая друг другу, что рисование на бумажке можно заменить непосредственно рисованием кода


Ну да, программирование — это мысленный процесс, а не механический (пальцами). Опять же, если хорошо подумать, то получается, что строк кода надо нашлепать немного.
Да, в пользу моей точки зрения. Редко кто из программеров печатает на клаве слепым методом. Но такие есть. Так вот. От скорости печати скорость работы никак не зависит. А если это так, то это означает, что само кодирование (сидение в среде разработки) — не самое затратное по времени действие в программировании.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:48
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Дело в том, что в этом случае радикально уменьшается количество коммуникаций со всеми вытекающими последствиями.


да-да, наблюдал я такие случаи, когда количество коммуникаций радикально уменьшается и действительно, со всеми вытекающими последствиями
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[8]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:48
Оценка: -1
Здравствуйте, McSeem2, Вы писали:

MS>Именно так, несмотря на успешность подавляющего большинства моих прикладных проектов. Не моё это. И это ощущение усугубляется нехорошим предчуствием, что мы находимся вначале нового мыльного пузыря типа дот-комов. Ощущение какой-то тщеты, искусственности этого массового рынка, не обеспеченного активами. Жена тут сдвала какие-то MS-сертификаты — ну чисто лохотрон по собиранию денег с населения. И первые, кто обвешиваются эими сертификатами — это индусы. А их много. А каждый экзамен денег стоит. А за дополнительные деньги можно купить ответы на эту угадайку (что они все и делают). И главное — все легально и "цивилизованно". Меркетинг, едрёныть! О каком повышении производительности может идти речь, если она изначально помножена на ноль?! Как там у Пелевина:

MS>Но это лишь ощущение, хорошо бы оно было ложным.

Сертификаты — это лохотрон, это и так любому понятно. Ну пусть есть идиоты, которые готовы платить за это свои деньги. Пусть есть другие идиоты, которые нанимают "спецов" с пачками сертификатов. Один раз обожгутся, в другой раз будут думать. Тебя то это каким образом затрагивает? Меня — нет. Чем больше будет идиотов, тем больше будут цениться настоящие специалисты
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:57
Оценка: -1
Здравствуйте, IT, Вы писали:

IT>Если есть возможность всегда передать свой код другому в случае проблем со временем, и такая необходимость не возникает регулярно и по причине "ну я вот тут показал как, а теперь ты давай, сынок", то можно совмещать без проблем.


если начинаешь писать код сам, то очень быстро теряется общая картина. Я пробовал делать так сам, наблюдал за результатми работы других, и каждый раз результаты были самые неприглядные. Хотя во время работы ты сам это не замечаешь, но стоит отвлечься и пару часов побездельничать — и начинаешь понимать, что до этого порол полную чушь Или пару дней — в зависимости от глубины погружения. И тогда до тебя доходит, что можно было пойти по другому пути и намного упростить работу себе и другим, но ты этого не понимал, потому что залез по уши в детали того пути, которым ты пытался идти.
В общем, ни руководитель проекта, ни архитектор не должны сами писать код для своего текущего проекта. И никто меня не переубедит
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[14]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 05:18
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>не ходил, но могу представить. Получается, что количество членов экипажа ограничивается десятком человек, максимум двумя десятками.

Совершенно верно. Смею напомнить, что в нашей работе команды большего размера — экзотика. Численность компаний попрошу в пример не приводить — у нас вон тоже под полтыщи человек под ружьем. А в нашей команде — десять. В твоей команде сколько народу?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Философия эффективности труда
От: Шахтер Интернет  
Дата: 15.02.06 09:19
Оценка: :)
Здравствуйте, Oyster, Вы писали:

O>Здравствуйте, Шахтер, Вы писали:


Ш>>C## ?


O>Нету оператора ## в C#, поэтому не судьба. Зато во втором есть оператор ??...


В С++ есть. Так что будет С##++. Влад удавится.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[7]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 12:09
Оценка: +1
Здравствуйте, kedik, Вы писали:

K>PS. В данном случае кодеры похоже набросились на архитекторов — рьяно убеждая последних использовать средства кодирования для решения архитектурных задач... Архитекторы искренне недоумевают... Прикольно...


Как общественно признанный архитектор , семю тебя заверить, что то, о чем пишет McSeem, к архитектуре имеет весьма слабое отношение.
Вобще, как тут справедливо заметили, спор идет ни о чем. Есть структурная сложность, есть сложность поведенческая. Как их можно сравнивать — что круче, мне непонятно. Считать что за счет поведенческой сложности можно устранить сложность структурную — наивность, вызванная скорее всего узостью опыта.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[12]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 13:34
Оценка: +1
Здравствуйте, Дарней, Вы писали:

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


ИМХО всего лишь (не обижайся) недостаток опыта. Если будешь тренироваться, то все у тебя получится. У меня, к примеру, получается и код писать и проектированием заниматься. Более того — мне куда проще потом самому реализовать то что я спроектировал, меньше работы по формализации, объяснению и контролю. Вот только я не резиновый, все и сразу сделать не могу.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[6]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 13:34
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Некоторые нюхали. Сами закладывают мины и сами потом их нюхают.


Ты про котов что ли? Так они вроде софт и не пишут.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[11]: Поштучно говоришь...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 13:34
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

MS>Конечно же это байка, но без криминальной составляющей она вполне правдоподобна — вечные лампочки не выгодны индустрии и именно поэтому их нет в магазинах.


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

IT>>И считают, как землекопов. Кто-то тут говорил про 40 тысяч кубиков в индии. Боюсь, что 8 дней в неделю все эти кубики будут проводить на митингах.


MS>А вот это — выгодно. Под это дело менеджеры среднего звена могут выбить бабки у менеджеров повыше. Те могут найти спонсоров в виде венчурных капиталистов, ну а самих капиталистов воспитывает в нужном русле тот же MS. Круг замкнулся. А на что же все это опирается?! — А вот об этом ты не думай никогда. Вообще никогда!


Если бы ты был прав, то аутсорсинг в России умер. Потому как зарплаты у нас в Москве, Питере и Новосибе уже вполне европейские, а организационного гемороя с русскими пока еще существенно больше, чем с индусами. Тем не менее не умирает, а наоборот растет.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[16]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 15.02.06 20:46
Оценка: :)
Здравствуйте, Дарней, Вы писали:

IT>>Ну так поделись с нами своими наблюдениями


Д>басню про рака, лебедя и щуку слышал?


Это проблема менеджера, а не архитектора.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Философия эффективности труда
От: Яшин Евгений Новая Зеландия
Дата: 16.02.06 10:55
Оценка: :)
Упс, господа, за что стоко минусов то. В чём вы несогласны?
Кому нужна жутко нелинейная гамма коррекция антиальязинга? Кто может это оценить? В каких задачах реально требуются такие приложения?

По поводу 150тыщ, я с Владом уже согласен.

P.S.: чтоб я ещё раз ввязывался в священную войну..
Re[12]: Философия эффективности труда
От: craft-brother Россия  
Дата: 16.02.06 11:09
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Ты вообще с кем споришь?

Я не спорю, я возражаю и пытаюсь делать это аргументированно.
Видимо я недостаточно убедителен.

S>Я также против того, чтобы как-то мистифицировать юзабилити. Да, есть такая профессия — специалист по юзабилити. Но она не требует никаких специальных талантов, кроме здравого смысла и желания улучшить интерфейс. Ну есть у боинга толпа этих специалистов, и что? Это не Пикассы никакие, и даже не Валентины Юдашкины.


Я возражаю против того, что каждая кухарка (или архитектор, есле тебе больше это нравится) может создать эффективный UI, отвечающийт современным требованиям бизнеса.Повторюсь, речь идет не о простеньких и мало распространенных программных поделках.Речь об эффективности автоматизации профессиональной деятельности большого числа (1000 — 1000000) пользователей.

Для иллюстрации нетривиальности возможных решений еще один пример. В двух словах (погугли — найдешь). Танком Т-90 водитель управляет, в бою лежа, а на марше — высунув голову из люка и вдыхая выхлоп впереди идущей машины. Где здесь здравый смысл? Все это сделано для того, чтобы на 0,5 м уменьшить высоту танка и повысить его боевую эффективность.

Давай не спорить, а попытаемся придти к общему знаменателю.

1. Согласен, что промышленное производство эффективнее кустарного при массовости продукта?
2. Согласен, что основа этой эффективности лежит в разделении труда и специализации?
3. Согласен что художник, специалист по промышленному дизайну лучше и быстрее, чем программист, подберет цветовую гамму, шрифты и компоновку элементов экранной формы?
4. Согласен, что специалист по юзабилите лучше и быстрее, чем программист (архитектор), спроектирует человеко-машинное взаимодействие?
Re[5]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.02.06 12:25
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот этот принцип очень хорошо было бы сделать обязательным правилом. Поддерживаю на 100%


Это нереально. Подобное может себе позволить IT, потому что он не много пишет. Основные же модераторы по определению пишут в тот форум, который они модерируют (потому что никто не будет модерировать форум, который ему не интересен). В результате имеем два варианта — либо объем модерирования резко упадет, либо модераторы этого форума станут резко меньше писать. Ты что выбираешь?
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[12]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 16.02.06 13:09
Оценка: :)
Здравствуйте, VladD2, Вы писали:
VD>Пока что все это смахивает на выдумку.

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

Особенно забавно, подобное слышать потенциальному пользователю программы. Пусть даже бесплатной.
Не думаю, что твои "официальные" клиенты получают лучший сервис...
Re[14]: Философия эффективности труда
От: craft-brother Россия  
Дата: 16.02.06 15:11
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>В жизни в 90% проектов даже один архитектор — это уже роскошь. И именно он отвечает за все, включая HCI. Архитектор имеет право отказаться от рисования иконок. А вот отказываться от проектирования взаимодействия — нет. Потому что иначе он не архитектор, а обманщик, который не делает свою работу. Взаимодействие пользователя с софтом есть важнейшая часть архитектуры.


Нет, видно, не судьба нам найти общий знаменатель. В разных системах исчисления работаем. Я про промышленное производство ПО, ты — про кустарное. Я про то «как лучше», а ты про то «как всегда».
Спасибо за дискуссию.
Успехов.
Re[15]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.02.06 03:06
Оценка: +1
Здравствуйте, craft-brother, Вы писали:
CB>Нет, видно, не судьба нам найти общий знаменатель.
Наверное.
CB>В разных системах исчисления работаем. Я про промышленное производство ПО, ты — про кустарное.
А ты не мог бы рассказать, где именно живет это промышленное производство? Я вот своими глазами пока что его не видел. Где эти легендарные конвейеры стоят? Или, может быть, я неправильно понимаю значение слова "промышленный"?
CB>Я про то «как лучше», а ты про то «как всегда».
Да просто я совершенно не уверен, что так, как ты предлагаешь — лучше. Если бы ты высказывал меньше тезисов, и больше аргументов, тогда мне было бы проще хотя бы понять, о чем идет речь.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 17.02.06 04:26
Оценка: -1
Здравствуйте, VladD2, Вы писали:

_>>Вон, на жаба-сайтах (www.theserverside.com, www.javalobby.org) уже сколько лет про аспектно-ориентированное программирование народ бодается. Это не язык, это технология, методики и т.д. и т.п. И что? Пока толком не ясно что же от этой фишки хорошего, что плохого.


VD>АОП пока что в стадии иследований. И его губит совершенно бредовая терминалогия. С такой терминалогией ему выжить нереально.


Это ты так думаешь. А многие думают по-другому. Я про тех, кто занимается исследованиями в этой сфере.

VD>К тому же АОП всего лишь один небольшой узкий подход в том время как метапрограммирование (МП) технология куда как более универсальная и гибкая. АОП реализуем на МП, но МП не реализуемо на АОП.


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

_>>Так что передовая общественность за чем только не наблюдает.


VD>А не передовая исходится сомнениями и сарказмом.


Передавая занимается серьезными исследованиями. И ее отличают от фанатичной толерантность, критичный взгляд к собственной персоне. Иначе ничего не добьешься. В лучшем случае станешь евангелистом какой-нибудь технологии или корпорации. Понял, на что я намекаю? )))) (без обид)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 17.02.06 07:52
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Вот этот принцип очень хорошо было бы сделать обязательным правилом. Поддерживаю на 100%


AVK>Это нереально. Подобное может себе позволить IT, потому что он не много пишет. Основные же модераторы по определению пишут в тот форум, который они модерируют (потому что никто не будет модерировать форум, который ему не интересен). В результате имеем два варианта — либо объем модерирования резко упадет, либо модераторы этого форума станут резко меньше писать. Ты что выбираешь?


Я сам являюсь модератором fido7.ru.visualcpp. Был несколько лет назад выбран, правда, практически сейчас никакого участия в эхе не принимаю и не модерирую. Впрочем, там модератор почти и не нужен, а выбрали меня из-за того, что координатор эхи поставил условие — либо выберете модератора, либо эху удалим.

А ответ на вопрос, что я выбираю — предельно прост в вашем случае. Если модератор в данном топике принимает участие, он передает свои права на его модерирование (этого топика, не более) своему коллеге. А тот, наоборот, ему в аналогичном случае.
With best regards
Pavel Dvorkin
Re[13]: Философия эффективности труда
От: klapaucius  
Дата: 17.02.06 13:40
Оценка: +1
Здравствуйте, Mystic, Вы писали:

M>А мне кажется, как раз наоборот. К хорошему быстро привыкаешь. Вот моя з/п со времен студенчества выросла в 30 раз. Думаешь у меня проблема ее потратить??? И никаких фобий А вот если ее урезать раз в десять, то будут большие проблемы. И провокационный вопрос: если человек уже имеет опыт разработки рабочих продуктов с небольшим бюджетом, почему он должен обязательно провалить следующий проект? Если я делал пару-тройку систем за $100, то почему при разработки еще одной подобной системы за $10000 я должен ее провалить?


Так не должен и не обязан. В норме, как раз все должно быть впорядке. Лично я тоже очень быстро привыкаю к хорошему. Но самое смешное как раз в том, что есть люди, которые не могут смирится с увиличением ресурсов. Они уверены, что даже если у тебя есть 1024 мегабайта памяти, нужно писать так, как будто их 64 и жертвовать для этой цели всем: универсальностью, гибкостью, собственной производительностью и комфортом. Их можно понять, они выросли в голодные времена дорогой памяти. Но мы ведь все в те времена выросли? Если ресурсов становится больше — разве не логичным будет их осваивать? Для некоторых людей это означает сдаться. Но! Ресурсы ведь для использования существуют, а не для экономии в тех условиях, когда их достаточно. Прогресс железа хорош в том числе и тем, что позволяет использование пушистых средств.
Зачем вечно жить в каменном веке?
В большинстве случаев можно выделить несколько узких мест и потом их оптимизировать. А вот сделать из суперпроизводительного кода поддерживаемый и универсальный — невозможно. Во всяком случае я просто не знаю как. Память можно купить за деньги. Кому заплатить деньги, чтобы все эти гигабайты программ написанных, понятное дело, не нами (кривые руки вегда у кого-то другого) наконец заработали? Бедные пользователи...

M>Вот тут можно рефакторинг сделать, вот тут эту фичу.


По моему, то, что человек хочет сделать рефакторинг, а не думает о его необходимости с ужасом, это лучше, чем просто хорошо. Это великое достижение нашего века.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[8]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 19.02.06 02:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Кстати, на макросах Нэмерла авторы языка с успехом эмулируют АОП.


Почему эмулируют? Точно так же можно сказать, они эмулируют и ООП
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 20.02.06 15:40
Оценка: +1
Здравствуйте, craft-brother, Вы писали:

CB>

CB>"Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает для пользователя."


Термины "кустарное", "мануфактурное", "мелкосерийное", "промышленное" вообще не применимы к данному роду деятельности. Они имеют смысл при производстве товаров, то есть в процессе копирования продукта. Например, в производстве процессоров. Но ни к коем случае не при рабработке процессоров. Для процессов разработки нужна какая-то другая терминология.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[18]: Философия эффективности труда
От: craft-brother Россия  
Дата: 21.02.06 07:39
Оценка: -1
Здравствуйте, McSeem2, Вы писали:

MS>Термины "кустарное", "мануфактурное", "мелкосерийное", "промышленное" вообще не применимы к данному роду деятельности. Они имеют смысл при производстве товаров, то есть в процессе копирования продукта. Например, в производстве процессоров. Но ни к коем случае не при рабработке процессоров. Для процессов разработки нужна какая-то другая терминология.


РЕМЕСЛО, мелкое ручное производство промышленных изделий, господствовавшее до появления крупной машинной индустрии (а затем частично сохранившееся наряду с нею). Для Р. характерны: применение простых орудий труда; решающее значение в производственной деятельности ремесленника его личного мастерства, которое позволяет производить высококачественные, а часто и высокохудожественные изделия; мелкий характер производства (ремесленник работает один или с крайне ограниченным числом помощников).
КУСТАРНОЕ ПРОИЗВОДСТВО, начальная, ранняя стадия развития и низшая форма капитализма в промышленности; преимущественно мелкое домашнее товарное производство на рынок или децентрализованная (раздаточная) мануфактура, основанная на эксплуатации непосредственного товаропроизводителя — кустаря торговым и промышленным капиталом.
МАНУФАКТУРА, форма крупного промышленного производства, соединение многих ремесленников и рабочих в одном помещении для производства, с широким применением разделения труда, но без паровых двигателей; представляет переход от ремесленного к фабрично-заводскому производству.

(Курсив мой. CB)

Не стоит придираться к понятиям. Эти понятия возникли задолго до программирования. И я применяю их по аналогии. Единственная мысль, которую я никак не могу убедительно донести до моих уважаемых оппонентов, это то, что переход в производстве ПО от ремесла и кустарщины к мануфактуре, основанной на специализации и разделении труда, неизбежен и уже идет. Прошу не путать мануфактуру с конвейером. Разработка ПО это не конвейер! Проектирование ПО заканчивается только после запуска компилятора. Более близкая аналогия это конструкторское бюро, в котором над проектом нового космического корабля трудятся тысячи конструкторов и инженеров, при этом каждый разрабатывает свой компонент. Ну, не получится кустарными методами разработать MS Office, при численности команды в 500 человек.
Re[6]: Философия эффективности труда
От: ArtemGorikov Австралия жж
Дата: 25.02.06 14:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>Все очень просто. Лично для меня не важно кто выпустит. Для меня важны потребительские качества. Я пользуюсь продуктами МС только от того, что потребительские качества их продуктов выше чем у конкурентов.


VD>AGG несомнно хороша по одному из свойств, но это свойство мне в общем-то не так важно. А вот по другим свойствам AGG резко проигрывает. Мне вообще не нужна библиотека которую я самогу использовать из С++. Мне нужна библиотека с удобной объектной моделью которую я смогу использовать из удобного мне средства разработки.


Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.

P.S. Качество картинки у AGG действительно лучше, чем у GDI+, и еще одно достоинство — ее можно залинковать в модуль, тогда как gdiplus.dll придется тащить с собой в инсталлянте.
Re[3]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 25.02.06 17:46
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

MS>Для специалиста по юзабилити — штука совершенно бесполезная, а у домохозяек в любом случае получаются "кошмарные домашние странички".


Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол по пикселям в коде с постоянной перекомпиляций для проверки попадания — дело не для слабонервных. Даже в досе в своё время я на турбовижине наваял визуальный редактор форм, после чего дело пошло асолютно на другом уровне.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 25.02.06 18:12
Оценка: +1
Здравствуйте, McSeem2, Вы писали:

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


MS>И это верно. А чем же они тогда пользуются, если сразу отключают? Есть какая-то альтернатива?


Переключаются в html код. Проще и эффективней. Работают подсветка синтаксиса и автокомплит.

MS>Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера.


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

MS>Все эти рукоблудства с генерированием кода — не более чем маркетинговый тотал-булшит.


Сохранение в ресурсах выглядело бы короче. Но сгенерированный код можно править самому, что есть гуд. Я к этому прибегаю довольно часто, особенно для всяких поисков замен и удаления лишнего. К тому же он довольно оптимален. Жирный сгенерированный код — это кривые ручки писателя контрола, но никак не писателей редактора форм.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 28.02.06 16:24
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?


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

MS>>Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.


AVK>Попробуй привести простейшие примеры на псевдокоде.


Типа так — типовой конвейер для рисования линий на основе полигонов, самый примитив:

Path path = new Path();
CurveFlattener curve = new CurveFlattener(path);         // Дробит кривые на прямые отрезки
Stroker stroker = new Stroker(curve);                    // Вычисляет эквидистанту к ломаной
AffineTransformer trans = new AffineTransformer(stroker);// Поворот, маштабирование, etc
PolygonClipper clipper = new PolygonClipper(trans);      // Отсечение полигона по прямоугольнику

// Далее мы выполняем:
path.MoveTo(. . .);
path.LineTo(. . .);
path.CurveTo(. . .);
. . .
// Геометрические параметры элементов конвейера
stroker.width(3.5);
stroker.LineJoin(Round);
trans.Rotate(35.0);
clipper.ClipBox(0,0,100,100);
. . .
// Рисуем
graphics.Render(clipper);


Это на самом низком уровне и только одна из возможных форм. Может быть что-то типа graphics.AddPipelineElement(new Stroker()) вместо того, чтобы "коннектить" их вручную). И понятно, что типовые конвейеры должны быть заранее определены, чтобы не возиться каждый раз с их созданием. Но надо обязательнео иметь возможность создавать конвейеры самому. Более того — создавать элементы конвейера самому. Как, например, мне "завернуть" декартово пространство в полярное? — чтобы на входе я пользовался обычными координатами, а рисовалось в виде круговой диаграммы (это не прихоть, это реальная задача для схематического отображения кольцевых ДНК). Такая схема создает принципиальную возможность расширения функциональности, в отличие от набора тривиальных ad-hoc решений. Можешь поверить на слово, в любой более-менее сложной задаче, где надо что-то рисовать, очень быстро упираешься в ограничения. И работа превращается в постоянный поиск обходных путей — меня от этого тошнит.

AVK>Понимаешь — в большинстве случаев мне по барабану.


Вот именно. И подавляющему большинству — тоже по барабану. Это и есть политика преднамеренной профанации. Зачем вообще изучать типографику, знать, какие бывают линии и что делают те или иные преобразования? Зачем вообще знать, что 2*2=4? — можно взять калькулятор и посчитать. Я конечно понимаю мотивы такой политики, но мне она не по душе.

MS>>Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии.


AVK>А он для этого и не делался. Нужно просто понять для чего он создавался — только для того чтобы заменить GDI, который, прежде всего, предназначен для отрисовки пользовательского интерфейса. И задача эта не менее серьезная, нежели картография, просто акценты в ней другие.


Неправда. Называется — GDI, Graphics Device Interface, то есть, штука, претендующая на универсальность. А потом выясняется, что ей только UI и можно рисовать. Ну что за дела?

Но это есть хорошо! Ибо пока у MS-архитекторов отключен думатель и включен круиз-контроль, у меня будет незанудная и высокооплачиваемая работа.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[17]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 28.02.06 19:01
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Погоди. Я могу последовательно вызывать методы Graphics, меняющие его состояние и от этой последовательности, по идее, должен зависеть результат.


Это все очень ограниченно, так сказать, капля в море. Я подозреваю, что под "методы Graphics, меняющие его состояние" ты подразумеваешь аффинный трансформер внутри него. Я уже приводил пример с широкой линией. В одних случаях надо так, в других — сяк. В GDI+ нет возможности этим управлять. А то что тебе "пофиг", не является сколько-нибудь значимым аргументом.

AVK>Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.


Подобные утверждения принято обосновывать. Ну и потом, удобство/неудобство — это понятия субъективные, в то время как наличие той или иной возможности — это фундаментальное свойство. Я уже приводил пример с "выпучиванием" a-la MacOS-X http://antigrain.com/stuff/sketcher.zip
Я просто подменяю конвейер (точнее, модифинцирую его), а сами кнопки (или что там еще рисуется) знать не знают, насколько там прямо или криво будет нарисовано. Вот весь код трансформера (на C++, но не суть):
        void transform(double* x, double* y) const
        {
            double dx = *x - m_xc;
            double dy = *y - m_yc;
            double r = sqrt(dx * dx + dy * dy);
            double rm = m_radius / m_magn;
            if(r < rm)
            {
                *x = m_xc + dx * m_magn;
                *y = m_yc + dy * m_magn;
                return;
            }
            double m = (r + rm * (m_magn - 1.0)) / r;
            *x = m_xc + dx * m;
            *y = m_yc + dy * m;
        }


Тривиально! Но поди встрой его в конвейер GDI+ — и съешь конфетку обломиську. Надо приделывать что-то снаружи и модифицировать сам код, который рисует контролы (во всех контролах!). И ты при этом намекаешь на удобство GDI+ для рисования UI? В общем, душит-смех-низачот.

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


Ну чего тогда споришь?
Это так, шутка. Спорь конечно же — мне приятно с тобой беседовать.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[18]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.06 08:58
Оценка: -1
Здравствуйте, McSeem2, Вы писали:

MS>Это все очень ограниченно, так сказать, капля в море. Я подозреваю, что под "методы Graphics, меняющие его состояние" ты подразумеваешь аффинный трансформер внутри него. Я уже приводил пример с широкой линией. В одних случаях надо так, в других — сяк. В GDI+ нет возможности этим управлять. А то что тебе "пофиг", не является сколько-нибудь значимым аргументом.


То есть ты считаешь, что в любых ситуациях единственно верное решение — максимально навороченное?

AVK>>Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.


MS>Подобные утверждения принято обосновывать.


Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.

MS> Ну и потом, удобство/неудобство — это понятия субъективные, в то время как наличие той или иной возможности — это фундаментальное свойство. Я уже приводил пример с "выпучиванием" a-la MacOS-X http://antigrain.com/stuff/sketcher.zip


А я тебе уже ответил на это — лишние возможности тоже далеко не всегда благо.

MS>Тривиально! Но поди встрой его в конвейер GDI+ — и съешь конфетку обломиську. Надо приделывать что-то снаружи и модифицировать сам код, который рисует контролы (во всех контролах!).


Все очень просто — не нужно контролам никаких трансформеров, а тем паче тонкости по настройке конвеера трансформера.

MS>В общем, душит-смех-низачот.


Поглядывай на правила.

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


MS>Ну чего тогда споришь?


Я просто намекаю на то, что критерии для оценки GDI+ выбраны несколько не те. Это примерно как оценивать Камаз на предмет наличия в нем CD-changer.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[19]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 01.03.06 14:44
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>То есть ты считаешь, что в любых ситуациях единственно верное решение — максимально навороченное?


Ты так ничего и не понял. Тот псевдо-код не нужно повторять каждый раз, когда тебе надо нарисовать линию. Это свсего лишь некий setup, конфигуратор. Какая такая "навороченость"? Вот в GDI+ — уж действительно, наворотили так наворотили. А толку — чуть.

AVK>Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.


Сюрприз — будет примерно то же самое, что и на GDI+. Разница же в другом. Еще раз и медленно. При моем подходе я могу так сконфигурировать конвейеры, чтобы контролы рисовались совершенно по другому. При этом их код не будет затронут. С GDI+ такой возможности нет в принципе — там внутри все приколочено шиферными гвоздями.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[22]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.06 16:01
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер


Ты еще не забыл, что мы обсуждаем удобный API. А удобный API хелперов не требует.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[4]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 02.03.06 08:06
Оценка: +1
Здравствуйте, mrozov, Вы писали:

M>Я вообще понятливый. Хрен они туда бегут. И хрен они с ним консультируются. Есть в мире хозяйства покрупнее и авторитеты гораздо солиднее. А деятель этот никому не нужен.

M>Понял?

M>P.S. Лично с автором незнаком, о его заслугах ничего не знаю и лично против него ровным счетом ничего не имею. Говорю и подходе в целом.


Я тож понятливый. К афторитерам не пробиться, им не до мелких хозяйств. Народу нужен кто-то, кто будет поближе к ним. Я тоже о подходе в целом. Поэтому таким буйным цветом цветут всякие консультанты. Причем есть такие, которые помогают решать серьезные проблемы. А ведь обычно консультанты — это не какие-то фирмы, а просто отдельные личности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 03.03.06 03:40
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Интересно, а психиаторы лечат клиническое отсутствие чувства юмора? Если нет, то будем лечить народными методами... баней.




А если бы я дописал — "шутка"? )))) Думаю — не лечат.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Философия эффективности труда
От: mrozov  
Дата: 09.03.06 14:49
Оценка: :)
Здравствуйте, EXO, Вы писали:


EXO>Рекомендуется курить вот это:

EXO>http://www.fictionbook.ru/author/nordstrem_kell_a/biznes_v_stile_fank_kapital_plyashet_pod/nordstrem_biznes_v_stile_fank_kapital_plyashet_pod.html

Не, друг, ты лучше такой фигни больше не кури...

Да здравствует трезвое восприятие действительности!
Re[2]: Философия эффективности труда
От: Topknot Украина  
Дата: 14.02.06 02:05
Оценка:
Здравствуйте, IT.

Сэр IT, ваша категоричность умиляет (по крайней мере для админа Философского раздела).
ИМХО.Наезжать как бы неуместно, более уместно видимо поразмыслить.
Максим толково изложил (без наездов особых) ситуацию в нашем ремесле (АйТи).
У него есть на то полное право, ввиду его опыта и самостоятельности мышления, стремящейся, оторваться от стереотипности нашего бытия. Конечно, можно обижаться на "индусов"(тут уже каста професиональная, не нация), так как многим приходится делать рутинную работу. Рутина она везде есть, это и есть то, за что труд получил свой корень от слова "трудный"(непростой, утомительный). Левша занимается рутиной тоже (это не белоручка по определению), когда не успевая за мыслью "хавает" тонны своего же кода, стремясь к совершенству (для стороннего человека это скука, как для меня смотреть на вбивание гвоздей сапожником по контуру подошвы). НеЛевша — "хавает" тонны документации и прочей айтишной муры ("бульварные романы" — точно подмечено Максимом). Каждый по-своему живёт. Если кто-то думает что вот так вот будет эффективнее — то навереное это его право. За то и любят многие программирование — за свободу. Впрочем, Максим поднял корневой вопрос любой профессиональной деятельности, и даже более того — вопрос Смысла Жизни. Как в Библии написано про закапывание талантов — лучше не скажешь. Прийдет Время и спросит: "как ты использовал то что тебе дано было?". Думаю что Максим хотел на самом деле больше не о банальных вещах поговорить (он так и и написал, что языки и прочее — это второстепенно). Важнее — суть, что ты вкладываешь в свою работу, и какой это мерой мерять чтобы оценить эффективность работы. Я не Левша, не дорос еще, но скоро буду им тоже. И таких нас тут много. ИМХО, эффективность работы программиста сложно оценить, так как мы не просто инженерим мосты, дома и так далее. Мы в них душу вкладываем, без этого они работать толком не будут. Тут все честно: сколько отдал — столько и вернулось. А мерить такой процесс простой линейкой (скоростью печати, кол-вом строк, брендом и версией SDK) — не честно. Поносить друг друга тут — совсем нехорошо.

Сорри за длинный ответ. Щекотливость обязывает.

"Что такое хорошо и что такое плохо?" (С) Поэт один...
«Украина – это та Русь, которая осталась дома».
В. Новодворская.
Re[3]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 02:55
Оценка:
Здравствуйте, Topknot, Вы писали:

T>Сэр IT, ваша категоричность умиляет (по крайней мере для админа Философского раздела).


Если я вступил в полемику, то вряд ли уже буду заниматься модерированием данного топика. Но могу попросить сделать это кого-нибудь другого

T>ИМХО.Наезжать как бы неуместно, более уместно видимо поразмыслить.


[skip]

Я очень рад, что у Максима есть поклонники. Правда
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 04:07
Оценка:
Здравствуйте, IT, Вы писали:

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


Сколько можно талдычить — не "выжимать из одного алгоритма все соки" а придумывать алгоритмы. Это больше напоминает процесс построения математических доказательств. И далеко не "всю жизнь". Всю жизнь — это уже фанатизм какой-то. Навязчивая идея.

MS>>Я же говорю о другом, например, перевести задачу (к примеру!) из класса O(N^2) в класс O(N log N), в условиях, когда это сделать нетривиально, но все еще возможно (ну и конечно же, где это актуально), и сделать это наиболее нетупым способом — вот это и есть мегазадача. А "производственный процесс" — это рутина. Смысл в нем для меня отсутствует.


IT>Я правильно понимаю, ускорить твой алгоритм в 2 раза — это хорошо, а ускорить в 80 раз какой-нибудь "производственный процесс" — это бессмысленная рутина?


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

Во-вторых. Что такое задача O(N^2)? А это вот что. Дали 10 чисел — работат 1 секунду, дали 1000 чисел — уже почти три часа. Для миллиона чисел — больше 300 лет. То есть, при определенном пределе метод просто перестает быть работоспособным. В то же время, до некоторого предела O(N^2) может работать и быстрее, чем O(N log N). И вот задача заключается не столько в том, чтобы ускорить (хотя и это тоже), а в том, чтобы сделать хотя бы работоспособным в принципе. Для одних типов задач — это тривиально, для других — невозможно в силу устойства нашего мира. Для третьих — неизвестно, получится или нет, надо пробовать, крутить-вертеть. Вот это мне и интересно. Хотя и "ускорить вдвое", когда уже казалось бы все выжато — тоже бывает интересно. И если удается, то происходит это как правило не за счет тупой кодовой оптимизации (там уже как правило все соптимизировано), а за счет использования других методов.

А что значит "ускорить в 80 раз какой-нибудь "производственный процесс" — я без понятия. Какой именно процесс? Добычи нефти? Обработки банковских платежей? Устроить разгон автомобильного конвейера в 80 раз? Или производственный процесс разработки софта? Если последнее — то не верю я в это. Причина проста — для кардинального ускорения надо "разгонять" вербальные каналы общения людей. И к сожалению, это не исправить никакими студиями. На костылях все равно далеко не убежишь.

IT>Надо и краном порулить и тросы потягать, а как же? По другому не бывает. В нашем деле построить серьёзную систему и не замараться при этом кодированием могут только бла-бла-бла-архитекторы. Понятное дело, что построить они её могут только на словах, а не на деле.


Дык. Порулили уже. Просто всему свое время. А к "архитекторам" ни разу не стоявшим у станка я тоже отношусь с некоторым снисхождением. Пороху не нюхали.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[5]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 04:56
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Сколько можно талдычить — не "выжимать из одного алгоритма все соки" а придумывать алгоритмы. Это больше напоминает процесс построения математических доказательств.


Т.е. ты себя всё же больше относишь к математикам

MS>Во-вторых. Что такое задача O(N^2)? А это вот что. Дали 10 чисел — работат 1 секунду, дали 1000 чисел — уже почти три часа. Для миллиона чисел — больше 300 лет. То есть, при определенном пределе метод просто перестает быть работоспособным. В то же время, до некоторого предела O(N^2) может работать и быстрее, чем O(N log N). И вот задача заключается не столько в том, чтобы ускорить (хотя и это тоже), а в том, чтобы сделать хотя бы работоспособным в принципе. Для одних типов задач — это тривиально, для других — невозможно в силу устойства нашего мира. Для третьих — неизвестно, получится или нет, надо пробовать, крутить-вертеть. Вот это мне и интересно. Хотя и "ускорить вдвое", когда уже казалось бы все выжато — тоже бывает интересно. И если удается, то происходит это как правило не за счет тупой кодовой оптимизации (там уже как правило все соптимизировано), а за счет использования других методов.


Я в курсе что такое O(N^2). И в курсе что с лучшими алгоритмами не сравнится никакая оптимизация. Но ты не поверишь, мне интересно заниматься как алгоритмами, так и выжиманием из них соков. Разбираться в новых технологиях и уметь эффективно их использовать. Последнему, кстати, нужно учиться очень и очень долго. И ни в каких книжках об этом не пишут. Я учился, довольно долго, и смею утверждать, что могу улучшить практически любой код, сделать его проще, понятнее и надёжнее. Иногда получается 2к строк ужать в 15, а от навороченной UI формы с сотней полей оставить рукописного кода один конструктор на две строчки. И тоже не знаешь получится или нет, с чем придётся больше бороться, со сложностью задачи или с костностью мышления, глупостью, безответственностью. Но мне этим нравится заниматься. И ещё мне нравится делать это быстро в чём мне последнее время помогают современные средства IDE, но никак не нотепад. Хорошо бы ещё научиться рефакторить некоторым мозги и всё совсем было бы хорошо.

MS>А что значит "ускорить в 80 раз какой-нибудь "производственный процесс" — я без понятия.


А что ты тогда понимал под "производственным процессов", когда об этом говорил?

MS>Дык. Порулили уже. Просто всему свое время. А к "архитекторам" ни разу не стоявшим у станка я тоже отношусь с некоторым снисхождением. Пороху не нюхали.


Некоторые нюхали. Сами закладывают мины и сами потом их нюхают.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 05:24
Оценка:
Здравствуйте, IT, Вы писали:

MS>>А что значит "ускорить в 80 раз какой-нибудь "производственный процесс" — я без понятия.


IT>А что ты тогда понимал под "производственным процессов", когда об этом говорил?


Я имел в виду процесс разработки софта по типу конвейера. Тот процесс, где яко бы нужно повышать эффективность и производительность труда.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 07:31
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Так чего я так взъелся-то? А то, что понятие эффективности может быть очень разным. Я охотно верю, что для Влада это — больше ре-шарперов и ре-фактореров (ре-факторов, ре-факеров), хороших и разных. И я ничего против этого не имею, но не надо возводить это в категорию абсолюта.


Жаль, что нет хороших инструментов рефакторинга для C++. Тогда, я думаю, ты бы оценил ту на самом деле небольшую помощь, которую они оказывают простому программисту. А со временем, возможно, не смог бы и жить без рефакторинга, как и все мы, закабалённые решарпером

Ведь неужели тебе никогда не приходилось выделять метод? Или переименовывать переменную? Или, скажем, менять название класса? Пусть эти операции составляют 1% твоей работы — почему бы не автоматизировать этот процент и не освободить свой мозг и свои руки для более благородных дел?

Да, пожжержка рефакторинга — не серебрянная пуля (думаю, Влад это и не имел в виду). Ре-допиши_свой_язык — это лишь подспорье, лишь инструмент, который может сделать жизнь краше — стоит только научиться им пользоваться.

MS>Пусть он расскажет тому же Кнуту, что тот работает жутко неэффективно. Куда он будет послан? Воот. Или, скажем, Андрю Уайлз, который угрохал семь лет жизни на доказательство "какой-то фигни". Зачем ему это надо было? — это же жуть как непроизводительно! А ответ простой — ему было чисто прикольно по жизни. Вот это и есть критерий эффективности.


Ну тебе уже говорили, что примеры не совсем корректны ввиду того, что эти товарищи грязной работой почти не занимаются. А вот возьми ты, скажем, Дона Бокса, и спроси: "- Дон, а вот что бы ты делал, если б в студии не было рефакторинга?" Дон, я думаю, ответил бы, что фигня вопрос и не нужен ему никакой рефакторинг, а сам бы закрылся в своей многокомнатной каморке и горько заплакал...

В общем, я предполагаю (читай — большое жирное ИМХО), что если бы Кнут писал достаточно много кода, он бы, скорее всего, тоже ратовал за поддержку рефакторинга студией. Потому что любой нормальный программист хочет писать как можно меньше кода и как можно меньше думать (читай — автоматизировать свою работу там, где это возможно).

MS>Владу прикольно повышать производительность труда ре-шарперами. Замечательно! Но мне-то это — не прикольно (и некоторым другим — тоже) и, следовательно, ни в коей мере не является для меня эффективным.


См. выше
Re[2]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 07:43
Оценка:
Здравствуйте, IT, Вы писали:


IT>Лично мне это всё напоминает известную сказку про блошиного мастера Левшу


MS>>Например, я сейчас работаю над неким алгоритмом, который всего-то навсего занимает порядка 50K в исходниках (очень размашистым стилем, и с подробными комментариями). Я его уже переделывал почти с нуля три раза и планирую переделать еще как минимум пару раз.

IT>Кашмар, какая скука

Кстати, пример на виду. РСДН-щики написали мега-приложение для чтения ньюсов, в котором я сейчас эти строки и пишу. Но. Эта задача БАНАЛЬНА по сравнению с разработкой того же Решарпера. И ньюс-ридеров существует масса. На любой вкус и цвет. Так что прекрасно понимаю уважаемого McSeem2.
Конечно я не хочу сказать, что написание подобных тулзов — бесполезное занятие. Ни в коей мере. Я говорю о сложности и нетривиальности задачи.

MS>>И что характерно, все эти мои "капризы" очень высоко оплачиваются — и это при том, что результат не гарантирован! Вот это для меня — настоящая задача, я бы даже сказал, битва, а я в ней — доблестный воин


IT>А это мне больше напоминает мазахизм, а не доблесть Воин, блин


IT>Кстати, по поводу "очень высокой оплаты". Зарплаты относятся к трём категориям по возрастанию: о которых не удобно говорить, о которых говорят с гордостью и о которых не удобно говорить. Поздравляю, похоже ты уже на втором уровне



MS>>Все эти яростные приверженности к определенным языкам, средствам проектирования и рефакторинга — это ложный карасс, гранфаллон.

IT>Это банальная зависть к людям, которые находятся на острие технологий

На острие технологий маркетинга? ))) Думаю, что речь идет именно об этом.


MS>>Стремление к повышению эффективности труда при помощи средств разработки — это тоже гранфаллон.


IT>А это говорит твоя лень.



Решарпер мозгов не отнимает. Кодирование занимает достаточно малый процент времени, а решарпер его просто может несколько сократить (автоматизировать)


MS>>И чем больше автоматизации, тем более тупой работой приходится заниматься. Яркий пример — дизайнер форм в студии. Более рутинной и неблагодарной работы (тяп-ляпать формы, а потом разруливать всякие события), трудно себе представить. И трудно с этим спорить. Это дает средства к существованию бедным голодным индусам (что очень гуманно), но одновременно погружает человечество в пучину профанации.


IT>Здесь можно было бы рассказать тебе о том, что качественный UI, в сравнении со всем остальным, является наиболее трудоёмкой задачей, требующей высокой квалификации и усидчивости, которая у большинства программистов отсутствует напрочь. Но так как это моё сообщение будем считать несерьёзным, то замечу, что ты просто не в состоянии это делать и в тебе говорит твоя зависть



Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.


MS>>Так что это палка о двух концах. Ну вот будешь ты всю жизнь пахать, изучая все новые и новые языки и технологии и под конец жизни поймешь, что твой разум напоминает комнату, до потолка заваленную бульварными романами для одноразового прочтения. Это что — эффективно? Я бы назвал это бездарным транжирством невосполнимого ресурса — своей жизни.


IT> Ну да, гораздо лучше 42 раза переписать одни и теже 50к кода.


И добится совершества. Ну или приближения к нему. И за это платят БОЛЬШИЕ бабки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 08:22
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>это не программист это кодер


А если "программист" не пишет код, то это или архитектор, или ПМ. Опять же, совершенно другая профессия. Это только у нас принято валить всех в одну кучу. Если работает с компьютером — значит, программист.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 08:25
Оценка:
Здравствуйте, Oyster, Вы писали:

O>По мне так востребованность тулзы — показатель более весомый, чем сложность и нетривиальность задачи, которую пришлось решить при написании тулзы. Если ты решил пробежать стометровку спиной вперёд, это совсем не означает, что ты герой — это означает, что ты проиграл.


O>Раньше меня тоже восхищали сложные задачи. Все подряд. Сейчас... меня больше привлекают задачи из реального мира. Что-то востребованное и очень простое... с точки зрения стороннего наблюдателя. Где-то тут проскакивало на РСНДе про complexity, которая скрывается за simplicity



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

А вообще — это конечно просто разница восприятия жизни. Так что тут спорить бесполезно. И так бывает и так.



КДВ>>На острие технологий маркетинга? ))) Думаю, что речь идет именно об этом.


O>Знаешь, современный мир, кишащий капиталистическими акулами, устроен таким образом, что за востребованные продукты платят, а за невостребованные — не платят. Так что можно говорить и про "острие технологий маркетинга", можно про интересные задачи, за которые платят — всё равно разговор будет об одном и том же.



Я хотел сказать, что в случае "острия технологий" очень часто (а в случае Майкрософта повсеместно) выступает блестящий ум маркетолога. То есть не надо путать востребованные технологии и острие технологий. Это даже разный мир с разным подходом к решению проблем, к самой разработке софта. И большая часть людей занимается именно востребованными технологиями.


КДВ>>Решарпер мозгов не отнимает. Кодирование занимает достаточно малый процент времени, а решарпер его просто может несколько сократить (автоматизировать)


O>+1. В автоматизации рутинных операций и заключается его прелесть (речь, конечно, не о формочках ).


Только вот не принципиально это. Много времени кодирования да, экономит. А программирования в целом — нет.


КДВ>>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.


O>Ну если ты так воплощаешь, то да — спору нет. Можно тупо педалить формы, а можно остановиться, подумать и вместо кучи тупого кода, который будет тяжело поддерживать, написать меньше кода, но кода "умного"


Ага, мастер-класс показать ))) Вот тут то и начинается интерес. Когда начинаешь обобщать. Причем сделать свой движек, который кодерам сэкономит время в 2 раза — круто. Не так ли?


КДВ>>И добится совершества. Ну или приближения к нему. И за это платят БОЛЬШИЕ бабки.


O>Да. Можно добиться совершенства в заточке стамески. И со всех концов света будут приходить к тебе люди и просить заточить стамеску. И не будет на свете другого человека, равного тебе в затачивании стамесок!


O>Тут всё дело только в том, нравится ли тебе изо дня в день затачивать стамеску...


Не надо сравнивать программирование с заточкой стамесок, строительством и другими темами. Это все натяжки. Большие натяжки. К примеру в твоем примере ты забыл, что не надо делать 2-ю версию алгоритма. Копирование бесплатно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 08:27
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Программированием занимается человек, который бОльшую часть рабочего времени программирует. А это и проектирование и написание кода и отладка и документация и т.д. и т.п. И придумывание алгоритмов для решения соответствующих задач, если шаблонные методы не подходят.


Ага. А еще рисует дизайн для кнопок, администрирует систему и отвечает на запросы юзеров. В общем — и чтец, и жнец, и на дуде игрец.
Проектированием, к примеру, должен заниматься отдельный человек. На обычного программиста обычно возлагается только микропроектирование. А то десяток программистов такого напроектируют, что чертям тошно станет.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[8]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 08:37
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, kedik, Вы писали:


Д>а бухгалтер, который работает в больнице — это тоже врач?

Да... ровно на столько, на сколько бухгалтер работающий в софтверной компании — программист.

PS. Будем тыкать дальше?
Если да... то давайте уж как нибудь поэффективней... что бы не отклоняться от темы
Re[6]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 08:49
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Здравствуйте, Кузнецов Денис Викторович, Вы писали:


O>Тут всё дело только в том, нравится ли тебе изо дня в день биться над проблемой Игрек, когда вокруг ещё есть проблемы Альфа, Бета и Каппа...

O>[/q]

Неверная постановка задачи... тфу вопроса...
Те которые решают проблемму Игрек только ради решения самой проблеммы — это хобби. Если это работа то решением проблеммы Игрек можно заниматься до тех пор пока это приносит доход. Ибо корневая проблема — это получение дохода, но никак не проблемма Игрек
А если это хобби и это приносит доход — этим можно заниматься вечно
Re[7]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 08:53
Оценка:
Здравствуйте, kedik, Вы писали:

K>Неверная постановка задачи... тфу вопроса...

K>Те которые решают проблемму Игрек только ради решения самой проблеммы — это хобби. Если это работа то решением проблеммы Игрек можно заниматься до тех пор пока это приносит доход. Ибо корневая проблема — это получение дохода, но никак не проблемма Игрек
K>А если это хобби и это приносит доход — этим можно заниматься вечно

Это вообще был риторический вопрос А идея была в том, что каждому нравится своё. Как итог — простые программисты, не занимающиеся разработкой мегабиблиотек, тоже делают хорошие и интересные вещи. А им страх как нужен рефакторинг. Это возвращаясь к топику...
Re[6]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 09:00
Оценка:
Здравствуйте, Oyster, Вы писали:

КДВ>>Только вот не принципиально это. Много времени кодирования да, экономит. А программирования в целом — нет.


O>Кодирование — уже не часть программирования?


Не придирайся к фразе. Ясно сказано, что кодирования часть процесса разработки (программирования). Если брать только кодирование, то да, можно ожидать существенной экономии времени. Но кодирование занимает небольшой процент времени от разработки в целом. Так что если ты ускоришь кодирование в 2 раза, то это не значит, что ты сможешь ускорить разработку в целом хотя бы на 10%. Вот так вот.

O>Именно так. Написать библиотеку, которой будут пользоваться другие


+1


O>Разъяснение касательно "в твоем примере ты забыл": Конечно, собственно затачивать стамески всем желающим будут подмастерья. Мастер в это время будет изобретать новый способ косой фигурной заточки, который должен сэкономить до 20% времени рабочему


А это уже НИОКР. Кстати. Интереснейшее занятие.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Философия эффективности труда
От: Кузнецов Денис Викторович Казахстан  
Дата: 14.02.06 09:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

КДВ>>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант.

КДВ>>2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.

S>Вот от такого подхода и возникают чудовищные приложения. Потому что первую часть либо пропускают вовсе, за отсутствием таланта, либо делает человек уже с таким талантом, что хоть стой хоть падай.

S>В проектировании UI основную роль играют не пикселы, а процесс взаимодействия. Для создания качественного UI достаточно обладать здравым смыслом и основами знаний по когнитивной психологии. Никакого таланта не надо. Талант нужен для того, чтобы создавать художественные произведения — к примеру, внятный сплэш для визарда ни один программист не изобразит (если он случайно не художник). А вот от UI для приложения художников лучше держать подальше — они имеют очень слабое представление о восприятии динамических структур. Кроме того, художнику очень сложно объяснить суть процесса взаимодействия пользователя с системой, поэтому он связан той структурой UI, которую ему подсунули для раскрашивания. А никакое раскрашивание не спасет UI, в котором нужно звонить абоненту при помощи бросания его иконки на иконку телефона, расположенную на другой закладке.

Наверное мы говорим про разные вещи. Есть ведь разные проекты. Есть и бизнес-приложения, где форм многие сотни (100), есть и что-то вроде РСДН-хоме, где форм конечно количество, а времени для разработки очень много (сколько лет уже эту штуку полируют?). И есть еще много разных сегментов рынка. Ты про какой? Я лично про бизнес-приклады говорил. И я за свои слова отвечаю. Чесс слово. Наверное мы просто не все договариваем, поэтому и не понимаем друг друга.

Кстати, про художников. Мой очень хороший знакомый занимался одно время тем, что писал на Вижуал Васике написанием софта для обучения (металлургический комбинат). Причем не надо придираться к средству, разработчкик он прекрасный. Ну так про художников. Там одна тетка была, которая рисовала. Только рисовала. На фотошопе. Другая — программист на вспоможении, и он — всю анимацию анимировал. Так вот, без художника получалось просто на порядок хуже. Я сам видел, что ТАК не художник не сделает.

Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:24
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>С этим то никто и не спорит.

EXO>Просто "хороших инструментов рефакторинга для C++" нет далеко не случайно.
EXO>В C# для авторефакторинга пришлось специально кое в чем ограничить язык. Стоило оно того или нет — уже вопрос.

Вот тут не соглашусь с утверждением — не вижу, откуда оно следует. Да и не чувствую я ущербности языка C#. Они боролись за строгую типизацию — это да — но хорошая поддержка рефакторинга вряд ли была приоритетом №1.

EXO>Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет.


Да не ограничивали C# ради рефакторинга!

EXO>Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.


Никто именно о нём не кричит. Просто именно у этого топика именно такая тема.
Re[7]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:24
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Не придирайся к фразе.




КДВ>Ясно сказано, что кодирования часть процесса разработки (программирования). Если брать только кодирование, то да, можно ожидать существенной экономии времени. Но кодирование занимает небольшой процент времени от разработки в целом. Так что если ты ускоришь кодирование в 2 раза, то это не значит, что ты сможешь ускорить разработку в целом хотя бы на 10%. Вот так вот.


Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?

КДВ>А это уже НИОКР. Кстати. Интереснейшее занятие.


Тут не понял. Это некий синоним слова "флейм", надо полагать?
Re[11]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 09:24
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Не надо путать жесткое отстаивание своей позиции и элементарное хамство


мне конечно дико жаль. Но когда меня вдруг начинают априори называть низкоквалифицированным работником, то я от этого слегка зверею.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 09:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>И, по моему скромному опыту, это хорошо. Я насмотрелся в развитой стране на веб-дизайнеров, падающих в обморок от HTML-разметки, программистов, не понимающих разницу между gif и jpeg... Это ж то же самое, что художник по синему цвету. Нормальный разработчик должен быть достаточно разносторонним.


специализация все равно должна быть. Потому что если за какую-то часть задачи отвечают "все" — это значит, что за нее не отвечает никто. И окажется потом, что предположения одного проектировщика не совпадают с предположениями другого, и программа в целом ковыляет на костылях вместо того, чтобы бегать.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 09:30
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Это очень примитивный взгляд на программирование. Да, действительно, если у нас есть 10 программистов, то для того, чтобы архитектура изделия не разъехалась нужен кто-то, кто будет координировать. Ты знаешь, тут недавно сравнили понятие "программист" с понятием "врач". Ты наверняка читал. Так оно и есть. И есть микропроектирование. Это твои слова. А это подразумевает уже гораздо более широкую область знаний, чем кодирование.


а я и не говорил, что "только пишет код". Я сказал "бОльшую часть времени пишет код"
А если человек бОльшую часть времени код не пишет, а (к примеру) руководит другими, то это явно уже другая профессия
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: PS
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:31
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

Ещё не надо путать разработку UI с рисованием иконок. Вторым занимаются таки художники, а вот первым — товарищи, описанные мной в предыдущем посте.
Re[8]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 14.02.06 09:33
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?


Тут скорее психология. Уж больно приятно, когда среда умная (умнее, чем предыдушие). Но это на мой взгляд. Да, кстати, сам пользуюсь, балдею, но отдаю себе отчет, что реально пользы помимо моих эмоций немного.

КДВ>>А это уже НИОКР. Кстати. Интереснейшее занятие.


O>Тут не понял. Это некий синоним слова "флейм", надо полагать?


Шутник. Погугли ))))
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: PS
От: denis_krg Казахстан  
Дата: 14.02.06 09:35
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Ещё не надо путать разработку UI с рисованием иконок. Вторым занимаются таки художники, а вот первым — товарищи, описанные мной в предыдущем посте.


А я не про иконки. Я просто рассказал о том, что видел сам своими глазами. Да, действительно, художник должен работать в тесном контакте с программистами, спецами по юзабельности и т.д. и т.п. Но все-таки. Без художника никуда. Точнее результат будет не тот. Красоты не будет. Правда не везде она нужна, но это уже другая тема.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 14.02.06 09:37
Оценка:
Здравствуйте, Дарней, Вы писали:

КДВ>>Это очень примитивный взгляд на программирование. Да, действительно, если у нас есть 10 программистов, то для того, чтобы архитектура изделия не разъехалась нужен кто-то, кто будет координировать. Ты знаешь, тут недавно сравнили понятие "программист" с понятием "врач". Ты наверняка читал. Так оно и есть. И есть микропроектирование. Это твои слова. А это подразумевает уже гораздо более широкую область знаний, чем кодирование.


Д>а я и не говорил, что "только пишет код". Я сказал "бОльшую часть времени пишет код"

Д>А если человек бОльшую часть времени код не пишет, а (к примеру) руководит другими, то это явно уже другая профессия

А где ты видал, чтобы большую часть времени писали код? То есть непосредственно шмякали на кнопки на клаве????? Может быть ты хотел сказать, что писать код, это значит и продумывать его структуру, и на бумажке что-то рисовать и... многое другое? Я все-таки не про руководство писал, а про разработку непосредственно (т.е. программирование).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:37
Оценка:
Здравствуйте, denis_krg, Вы писали:

O>>Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?


_>Тут скорее психология. Уж больно приятно, когда среда умная (умнее, чем предыдушие). Но это на мой взгляд. Да, кстати, сам пользуюсь, балдею, но отдаю себе отчет, что реально пользы помимо моих эмоций немного.


А я без рефакторинга уже как без рук. Если пересаживаюсь на студию без решарпера — становится неудобно. Так что реальная польза есть. Имхо.

КДВ>>>А это уже НИОКР. Кстати. Интереснейшее занятие.


O>>Тут не понял. Это некий синоним слова "флейм", надо полагать?


_>Шутник. Погугли ))))


Ой...
Re[8]: PS
От: denis_krg Казахстан  
Дата: 14.02.06 09:43
Оценка:
Здравствуйте, Oyster, Вы писали:


O>PS: Да, бывают лица, которые совмещают в себе и талант художника, и талант юзабилити-специалиста. Но пока что я видел только юридические лица такого типа


Крылатая фраза однако ))))
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:44
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Я тоже не считаю, что это было певым приоритетом. И смоти ниже на слова: "если этот выигрышь единственный".

EXO>А ради авторефакторинга (по заявлениям самого микософт) было убрано разделение на cpp и h файлы, например.

Заявления в студию. Я не уверен, что это не так, просто не слышал об этом никогда.

EXO> ну тогда нет возражений.

EXO>По моему никто не спорит, что наличие авторефакторинга лучше, чем его отсутсвие. Разногласия лишь в том, на сколько это существенно.

Ой ли никто не спорит? Смотрим на рутовое сообщение топика:

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


Это ли не попытка опровержения утверждения о полезности поддержки рефакторинга, встроенной в среду?
Re[11]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 14.02.06 09:46
Оценка:
Здравствуйте, denis_krg, Вы писали:

O>>А я без рефакторинга уже как без рук. Если пересаживаюсь на студию без решарпера — становится неудобно. Так что реальная польза есть. Имхо.


_>Судя по тому, что ты сказал (если читать как есть) — пользы как от курения ))) Уже без него не можешь


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

Кстати, курение вредно не потому, что ты к нему привыкаешь, а потому, что оно садит организм.
Re[8]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 10:14
Оценка:
Здравствуйте, Oyster, Вы писали:

O>Заявления в студию. Я не уверен, что это не так, просто не слышал об этом никогда.


Сходу не нагуглилось. Если найду — вышлю.
Но сразу замечу, что сами разработчики C# люди явно более вменяемые, чем некоторые из их "последователей"
(или это общая проблема "последователей"). Так что я не утверждаю, что их решения были плохи.
И кстати говоря сам я (прописав лет 15 на C++) сейчас предпочел бы C# для большинства задачь, разумеется если нет других особых условий.

Пример "особого услвия": я не могу пользоваться янусом, поскольку .Net-фреймворк, который он хочет при установке конфликтует с той версией MS Offoce, котрая стоит на машине. (При установке фреймворка перестает работать офис, при переустановки офиса — фреймворк.) Офис купленный и использование именно этой версии является обязательным, так что...

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


O>Ой ли никто не спорит? Смотрим на рутовое сообщение топика:

O>

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

O>Это ли не попытка опровержения утверждения о полезности поддержки рефакторинга, встроенной в среду?

IMHO, это просто эмоции.
Средства авторефакторинга действительно в массе ухудьшают стиль программироания. Но не потому, что авторефакторинг плох, а потому что он создает предпосыки для формирования другой "массы".
Иными словами — C# меньше бъет по рукам за кривую архитектуру, и на более поздних этапах.
Re[6]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 14.02.06 10:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ты меня конечно извини, но ты берешь мультимедиа-приложение в качестве примера. А еще есть флеш-ролики, которые конечно тоже программа, но только Масяня без Куваева ни у одного программиста не выйдет.

КДВ>>Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.
S>Я тебя уверяю, художников там привлекают только для того, чтобы картинки рисовать. Я не спорю с этим — я уже написал, что картинки должен рисовать художник. Но ни один художник тебе не изобретет reading pane layout в аутлуке. Потому что это не картинка, а организация UI. Этим занимаются отдельные люди, специализирующиеся на юзабилити. И вот для этой задачи никакой талант не нужен. Только ленивые разработчики оправдывают кошмарные UI отсутствием художественных способностей. Читайте книги — все гуру пишут, что художественные способности нужны исключительно для художественных задач. Остальное вполне по плечу произвольному человеку, оборудованному здравым смыслом.

Может разойдемся? ))
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.02.06 10:51
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>специализация все равно должна быть. Потому что если за какую-то часть задачи отвечают "все" — это значит, что за нее не отвечает никто.

Че-то ты перепутал. Широкая специализация — это не когда много людей отвечают за часть задачи, а наоборот — когда один человек отвечает за много задач.
Вот как раз при специализации и наблюдается такой бардак, как ты описываешь — к кому ни пойди, никто не виноват. Верстальщик кивает на художника, художник на программера, программер на архитектора. А почему кнопка уехала — никто не знает.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 10:59
Оценка:
Здравствуйте, Дарней, Вы писали:

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

Дарней,
не флейма ради, а люпопытства для... А кто ставил под сомнение твою квалификацию?
Re[8]: Философия эффективности труда
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.02.06 12:15
Оценка:
Здравствуйте, cvetkov, Вы писали:

C>разделение на cpp и h для рефакторингов не проблема

C>оснавная проблема #include и #define

C>знаю потомучто сам участвовал в написании рефакторингов


А шаблоны разве не проблема?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 12:19
Оценка:
Здравствуйте, cvetkov, Вы писали:
C>разделение на cpp и h для рефакторингов не проблема
C>оснавная проблема #include и #define

Да, об этом забыл. Согласен, что дело именно в #include, а исчезновение h-файлов уже следствие.
Спасибо.
Re[13]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 12:19
Оценка:
Здравствуйте, kedik, Вы писали:

K>Дарней,

K>не флейма ради, а люпопытства для... А кто ставил под сомнение твою квалификацию?

Re[6]: Философия эффективности труда
Автор: kedik
Дата: 14.02.06

только не говори, что "на самом деле совсем другое имел в виду"
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Философия эффективности труда
От: Дарней Россия  
Дата: 14.02.06 12:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Че-то ты перепутал. Широкая специализация — это не когда много людей отвечают за часть задачи, а наоборот — когда один человек отвечает за много задач.

S>Вот как раз при специализации и наблюдается такой бардак, как ты описываешь — к кому ни пойди, никто не виноват. Верстальщик кивает на художника, художник на программера, программер на архитектора. А почему кнопка уехала — никто не знает.

А это просто результат плохого управления.
Вот к примеру, ты можешь представить себе команду корабля, в которой каждый член экипажа и кок, и машинист, да еще и прокладывает курс, если у штурмана не нашлось на это времени?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[8]: Философия эффективности труда
От: WolfHound  
Дата: 14.02.06 13:12
Оценка:
Здравствуйте, VladD2, Вы писали:

[offtopic]
VD>Гомеопаты не врачи, а шарлотаны.
Я бы не стал делать столь категоричные заявления. У меня в свое время были просто жудкие мигрени. Ничего не помогало. Но гомеопату удалось их свести практически к нулю. Раз в 3 месяца приступы случались но по сравнению с почти каждый день это очень большой прогресс.
А другой врачь с виду еще болие шерлотанский чем гомеопат избавил меня от мигрений вобще.
Короче тут на кого нарвешься. Если человек не понимает что делает то в лучшем случае ничего не изменится... в худшем... В любом случае идти по объявлению в газете это безумие. В таких вопросах нужно очень тщательно собрать и проверить сведенья о враче.
[/offtopic]
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Философия эффективности труда
От: last_hardcoder  
Дата: 14.02.06 13:16
Оценка:
Здравствуйте, McSeem2,

Интересно, а найти такую творческую работу можно только случайно или существует какой-то метод целенаправленного поиска? Нельзя сказать, чтобы передо мной никогда не ставилось сложных задач. Однако, если они и ставились, то речь никак не могла идти о том, чтобы заниматься пол года каким-то там алгоритмом. Обычно постановка выглядит так: сделай тото и тото, GUI, базу, хм..., а можешь ещё чтобы программа сама... (искуственный интеллект, в общем)

При этом, ощущение определённого потенциала для решения серьёзных задач у меня было всегда. Но время течёт. Меняются работодатели. А уровень остаётся прежним. Другой раз сунешься на собеседование в какую-нибудь крутую контору. Ну там, ессно, изучают предыдущий опыт и желают удачи.
Re[4]: Философия эффективности труда
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.02.06 13:16
Оценка:
Здравствуйте, IT, Вы писали:


IT> число пишущих рсдн-щиков в каждый конкретный момент меньше одного?


Интересно, догонит ли Аххилес черепаху?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:19
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>А где ты видал, чтобы большую часть времени писали код? То есть непосредственно шмякали на кнопки на клаве????? Может быть ты хотел сказать, что писать код, это значит и продумывать его структуру, и на бумажке что-то рисовать и... многое другое?


Мы тут последние пару дней как раз ломаем копья доказывая друг другу, что рисование на бумажке можно заменить непосредственно рисованием кода
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 13:29
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, kedik, Вы писали:


K>>Дарней,

K>>не флейма ради, а люпопытства для... А кто ставил под сомнение твою квалификацию?

Д>Re[6]: Философия эффективности труда
Автор: kedik
Дата: 14.02.06

Д>только не говори, что "на самом деле совсем другое имел в виду"

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

Я лишь попытался совместить "протоколы общения" путем введение общих используемых терминов... но не более

PS. В любом случае я приношу извинения и сожалею о том что недостаточно точно выразился ... ты эта, заходи если чего (с) Волк
Re[3]: Философия эффективности труда
От: last_hardcoder  
Дата: 14.02.06 13:32
Оценка:
Здравствуйте, EXO, Вы писали:

_>> Обычно постановка выглядит так: сделай тото и тото, GUI, базу, хм..., а можешь ещё чтобы программа сама... (искуственный интеллект, в общем)


EXO>А чем тебе "искуственный интеллект" плохая задача?


К сожалению, заниматься серьёзной задачей в фоновом режиме я не могу. Посвятить отпуск программированию — это пожалуйста. Но двух недель на ИИ, увы, не достаточно.
Re[7]: Философия эффективности труда
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.02.06 13:34
Оценка:
Здравствуйте, IT, Вы писали:

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


И он не одинок


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:40
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>И он не одинок


Я в этом не сомневаюсь. Мне даже приходилось видеть таких людей и мне их всегда было жалко. Максиму ещё повезло, что он себя хоть в чём-то нашёл.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 14.02.06 13:40
Оценка:
Здравствуйте, last_hardcoder, Вы писали:
_>>> Обычно постановка выглядит так: сделай тото и тото, GUI, базу, хм..., а можешь ещё чтобы программа сама... (искуственный интеллект, в общем)
EXO>>А чем тебе "искуственный интеллект" плохая задача?
_>К сожалению, заниматься серьёзной задачей в фоновом режиме я не могу. Посвятить отпуск программированию — это пожалуйста. Но двух недель на ИИ, увы, не достаточно.

Не понял.
Ты ж выше пишешь, что это работодател заказывает тебе написать ИИ? Так в чем проблема? Каккой же это фоновый режим?
Re[9]: Философия эффективности труда
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.02.06 13:48
Оценка:
Здравствуйте, IT, Вы писали:

IT>Я в этом не сомневаюсь. Мне даже приходилось видеть таких людей и мне их всегда было жалко.


Интересно, а альпинистов, которые в обычной жизни работают промышленными альпинистами тебе так же жалко?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 14.02.06 13:56
Оценка:
Здравствуйте, eao197, Вы писали:

IT>>Я в этом не сомневаюсь. Мне даже приходилось видеть таких людей и мне их всегда было жалко.


E>Интересно, а альпинистов, которые в обычной жизни работают промышленными альпинистами тебе так же жалко?


Если у них тоже рвотный рефлекс к своей профессии, то жалко.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Философия эффективности труда
От: last_hardcoder  
Дата: 14.02.06 13:59
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Не понял.

EXO>Ты ж выше пишешь, что это работодател заказывает тебе написать ИИ? Так в чем проблема? Каккой же это фоновый режим?

Для работодателя — это незначительная деталь. Основное, как я уже сказал, база, GUI, бизнес-логика. А извлечение нужной информации из Excel файлов в произвольном формате, это желательная фича. Только времени на неё ни пол года, ни год, а вообще 0, поскольку система развивается и остальные задачи съедают всё время.
Re[6]: Философия эффективности труда
От: craft-brother Россия  
Дата: 14.02.06 15:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


То-то народ уж лет 30 проблемами HCI занимается. Предлагаю при помощи здравого смысла попробовать спроектировать интерфейс взаимодействия пилота с самолетом или оператора с АЭС. А что в коммерческих приложениях с юзибилити особо не заморачиваются, то эта халява очень скоро кончится.ИМХО, конечно.
Re[9]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.06 15:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Гомеопаты не врачи, а шарлотаны.

WH>Я бы не стал делать столь категоричные заявления. У меня в свое время были просто жудкие мигрени.

Внушение мощьная психотерапевтическая штука. Вот только микродозы сахара вряд ли могут помощь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Философия эффективности труда
От: kedik  
Дата: 14.02.06 18:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:


VD>>>Гомеопаты не врачи, а шарлотаны.

WH>>Я бы не стал делать столь категоричные заявления. У меня в свое время были просто жудкие мигрени.

VD>Внушение мощьная психотерапевтическая штука. Вот только микродозы сахара вряд ли могут помощь.

Помогает не сахар... помогает гомеопат...
... если он понимает что делает... ну и эфективные методы использует конечно
Re[7]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 14.02.06 18:42
Оценка:
Здравствуйте, IT, Вы писали:

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


Именно так, несмотря на успешность подавляющего большинства моих прикладных проектов. Не моё это. И это ощущение усугубляется нехорошим предчуствием, что мы находимся вначале нового мыльного пузыря типа дот-комов. Ощущение какой-то тщеты, искусственности этого массового рынка, не обеспеченного активами. Жена тут сдвала какие-то MS-сертификаты — ну чисто лохотрон по собиранию денег с населения. И первые, кто обвешиваются эими сертификатами — это индусы. А их много. А каждый экзамен денег стоит. А за дополнительные деньги можно купить ответы на эту угадайку (что они все и делают). И главное — все легально и "цивилизованно". Меркетинг, едрёныть! О каком повышении производительности может идти речь, если она изначально помножена на ноль?! Как там у Пелевина:
...Комитет-то мы межбанковский, это да, только все банки эти - 
межкомитетские. А комитет - это мы. Во как.
   - Понял, - сказал Татарский.  -  Кажется,  понял...  То  есть  как,
подожди... Выходит, что те определяют этих, а  эти...  Эти  определяют
тех. Но как же тогда... Подожди... А на что тогда все опирается?
   Не договорив, он взвыл от боли - Морковин изо всех сил ущипнул  его
за кисть руки - так сильно, что даже оторвал маленький лоскуток кожи.
   - А вот про это, - сказал он, перегибаясь через стол и заглядывая в
глаза Татарскому почерневшим взглядом, - ты не думай никогда.  Никогда
вообще, понял?


Но это лишь ощущение, хорошо бы оно было ложным.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[11]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 00:37
Оценка:
Вот кстати, и ПК нервничает, значит снова в точку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 03:12
Оценка:
Здравствуйте, craft-brother, Вы писали:

CB>То-то народ уж лет 30 проблемами HCI занимается. Предлагаю при помощи здравого смысла попробовать спроектировать интерфейс взаимодействия пилота с самолетом или оператора с АЭС.

Ничего сверхъестественного. Немножко больше когнитивной психологии, намного больше юзабилити-тестов. Или ты вправду полагаешь, что управление боингами какие-то люди со спецталантами придумывали? В жизни не поверю. И в первую очередь потому, что на месте менеджмента боинга я бы никакому таланту не поверил. А поверил бы результатам тестирования прототипов на большом количестве пилотов.

Тем более, что мы все же говорим не об АЭС (ты лично, кстати, насколько часто пишешь софт для АЭС?), а о нормальном коммерческом софте. Где ошибка во взаимодействии не стоит четыреста жизней и полмиллиарда долларов.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 15.02.06 03:56
Оценка:
Здравствуйте, VladD2, Вы писали:

MS>>Верю. Но позволь мне угадать. "твердым, тяжолым и хрупким" — это было что-то связанное, например, с COM, или, что-то другое, но обязательно с тяжелым полиморфизмом, множественными наследованиями, фабриками классов и прочими "прелестями".


VD>Знашь, откровенно говоря если сравнить вас с Вольфхаундом как специалистом в области С++, то ты как бы вообще не существущь. Ну, или тянешь на эдакого серяднечка не заметного среди серых масс, а Вольфхаунд пару собак слопал. Достаточно поглядеть на его посты одно-двух-летней давности и все становится ясным.


Ясно что????? То, что человек пришел к определенному мнению? Ну и что? Это мнение этого человека. Не значит, что к тому же придут другие люди. Жизнь то разнообразна. Тут не математика и не физика. Программирование (если не касается опять же математики) — вообще не наука, где можно что-то формально доказать. Ну написал. Ну ты проникся. Ну и что? Что всем теперь в это тыкать? Лучше б ссылку дал. Вон Вирт как что напишет, так тебя тошнит. А кто-то выдает написанное Виртом за истину в последней инстанции.


VD>Так что не стоит искать решение в его ограниченности или в том, что он не сталкивался с задачами где С++ способен проявить чудеса программирования.


VD>Все дело в том, что Вольфхаунд волею судемб был вынужден сероезно поработать на этой альтернативе. И произошло то, что происходит с более менее разумными людьми. Он проникся. Не думаю, что он сможет объяснить тебе как это выглядит или каково оно на вкус. Это можно прочувствовать только самому попоробовав.



Твоя логика: я проникся. Я разумный (почти гений). Он проникся. Значит он тоже разумный. Вы, батенька, уж больно себя любите. До безобразия.


VD>Но именно это ты и твои соратники скорее всего никогда не сделате. Вы удобно устроились в роли эдаких снобов критикавно. Сами пробовать не хотите, но чуть что не применете вылить ушат ехидной критики. При этом еще сделате вид, что мол разновариваете с мальчиками с гряной попой и не забудете провести парочку оскорбительных аналогий, назвать все то что не хотите освоить или просто понять поделками цель которых украсть у вас хлеб и отдать индусами и т.д., и т.п.



Критика у тебя слабовата. На грани просто словестного поноса. Без агрументов.

VD>Ну, что же. Видимо такова ваша роль. Я же в который раз убеждаюсь, что к общему мнению мы не прийдем. Так что пора кончать эти споры.


Вот вот.


P.S. а ссылку на статью(тьи) все-таки дай
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

Д>>Вот к примеру, ты можешь представить себе команду корабля, в которой каждый член экипажа и кок, и машинист, да еще и прокладывает курс, если у штурмана не нашлось на это времени?

S>Конечно представляю. А ты, поди, на яхте и не ходил никогда?

не ходил, но могу представить. Получается, что количество членов экипажа ограничивается десятком человек, максимум двумя десятками.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:48
Оценка:
Здравствуйте, kedik, Вы писали:

K>Клянусь своим копилятором я имел в виду все что угодно, но только не твою квалификацию — о ней я ничего не знаю, по сему это было бы по крайней мере ... эээ... глупо как минимум с моей стороны


K>Я лишь попытался совместить "протоколы общения" путем введение общих используемых терминов... но не более


ну а кто там все-таки подразумевался под "кодерами" из числа здесь присутствующих?

K>PS. В любом случае я приношу извинения и сожалею о том что недостаточно точно выразился ... ты эта, заходи если чего (с) Волк


... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[14]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 15.02.06 04:52
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Дело в том, что в этом случае радикально уменьшается количество коммуникаций со всеми вытекающими последствиями.


Д>да-да, наблюдал я такие случаи, когда количество коммуникаций радикально уменьшается и действительно, со всеми вытекающими последствиями


Ну так поделись с нами своими наблюдениями
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 04:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ну так поделись с нами своими наблюдениями


басню про рака, лебедя и щуку слышал?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[12]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 15.02.06 06:11
Оценка:
Здравствуйте, Дарней, Вы писали:
Д>если начинаешь писать код сам, то очень быстро теряется общая картина. Я пробовал делать так сам, наблюдал за результатми работы других, и каждый раз результаты были самые неприглядные. Хотя во время работы ты сам это не замечаешь


Ты прав... но с одним "но": навык "переключения уровней восприятия" — это навык. А потому, в принципе тренеруемый.

Хотя оговорка "в принципе" существенная — поскольку он имеет тенденцию распространяться на обычную жизнь... что оказывается порой не полезно. После чего включаются защитные механизмы психики и навык удаляется нафиг — как сорняк.
Примирить одно и другое не слишком просто, хоть и возможно.
Re[12]: Философия эффективности труда
От: kedik  
Дата: 15.02.06 06:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kedik, Вы писали:


K>>Помогает не сахар... помогает гомеопат...

K>>... если он понимает что делает... ну и эфективные методы использует конечно

VD>Промывку мозгов?


И это тоже... настоящий врач лечит не симтомы, а причину "Ибо все болензни от нервов... только сифилис — от удовольствия" (с) не моё

Хирурги нужны не меньше... но у них другая специализация... там где проще вырезать, чем промыть...
ну или наоборот пришить чего обратно...

PS. Хотя я лично видел гомеопата, который ставил на ноги тех кому хирург выписал направление к паталогоанатому
Re[8]: Философия эффективности труда
От: craft-brother Россия  
Дата: 15.02.06 07:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

Есть определенные тенденции.
Авиакосмический концерн Boeing меняет подход к приобретению ПО: главным критерием для него становится критерий применимости (usability), то есть простота освоения и использования программного продукта конечными пользователями.здесь

В настоящее время Usability Engineering Center состоит из 14 специалистов, работающих в штаб-квартире компании SAP, которые взаимодействуют с более чем 120 специалистами по эргономике, работающими в проектах SAP по всему миру.здесь

ЗЫ. Если создание интерфейса будет выполняться только программистами без привлечения специалиста по эргономике и профессионального графического дизайнера, то в следствие непрофеесионализма прогаммера:
ИМХО, переход от кустарного производства к промышленному требует разделения труда и профессиональной специализации.
Re[8]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 15.02.06 07:26
Оценка:
Здравствуйте, McSeem2, Вы писали:

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


Нет, тут ты неправ. Корпоративные приложения нельзя сравнивать с теми продуктами, которые делались в эпоху доткомов. Люди за это время стали умнее, научились считать и заказывают продукты, которые приносят реальную прибыль компании. Сейчас мне уже не встречаются ситуации, когда компания приходит в консалтинговую контору и заказывает себе "сайт абы шото было". Сейчас компания исследует свою работу, подсчитывает возможную прибыль и идёт в консалтинговую контору, чтобы та написала ей приложение с вполне конкретным функционалом за вполне конкретные сроки, и делает она это не из непонятной тяги к вебу (например), а из вполне прагматичной любви к прибыли.

Так что как раз этот рынок (а я всё пою песню о корпоративных приложениях) активами очень даже подкреплён. Поэтому лопнуть ему не суждено (я не финансовый аналитик, но всё же).

MS>Жена тут сдвала какие-то MS-сертификаты — ну чисто лохотрон по собиранию денег с населения. И первые, кто обвешиваются эими сертификатами — это индусы. А их много. А каждый экзамен денег стоит. А за дополнительные деньги можно купить ответы на эту угадайку (что они все и делают). И главное — все легально и "цивилизованно". Меркетинг, едрёныть! О каком повышении производительности может идти речь, если она изначально помножена на ноль?!


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

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

[... П поскипан ...]

MS>Но это лишь ощущение, хорошо бы оно было ложным.


На рынке на ощущения полагаться нельзя — съедят и не поморщатся. И вот этот отрывок из Пелевина имхо показывает, что ситуация на этом самом рынке тебе не вполне понятно. Что, впрочем, неудивительно, поскольку ты на этом рынке и не вертишься сейчас.
Re[14]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 15.02.06 07:31
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>да-да, наблюдал я такие случаи, когда количество коммуникаций радикально уменьшается и действительно, со всеми вытекающими последствиями


В общем случае "многопрофильный специалист" != "толковый многопрофильный специалист". К сожалению, именно так. К счастью, при наличии вменяемого руководства такие рецидивы удаляются хирургическим путём. К сожалению, этот подход не работает, если "специалист" и есть руководство...
Re[12]: Философия эффективности труда
От: Шахтер Интернет  
Дата: 15.02.06 07:41
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>Твоя логика: я проникся. Я разумный (почти гений). Он проникся. Значит он тоже разумный. Вы, батенька, уж больно себя любите. До безобразия.


Это явление очень хорошо известно из истории религий: Савл обратился в Павла.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[11]: Поштучно говоришь...
От: Oyster Украина https://github.com/devoyster
Дата: 15.02.06 07:48
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А вот это — выгодно. Под это дело менеджеры среднего звена могут выбить бабки у менеджеров повыше. Те могут найти спонсоров в виде венчурных капиталистов, ну а самих капиталистов воспитывает в нужном русле тот же MS. Круг замкнулся. А на что же все это опирается?! — А вот об этом ты не думай никогда. Вообще никогда!


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

Всё написанное ещё более верно в случае, если у такой компании есть свой IT department.

И ещё насчёт индусов — ходят слухи, что спрос на дешёвую рабсилу на рынке падает. Заказчикам всё больше импонирует качество, пусть даже за него прийдётся переплатить вдвое. Хотелось бы верить, что это не просто слухи... потому как появление большого количества высококвалифицированных спецов невозможно в силу действия закона сохранения IQ

MS>Ладно, это уже чисто гон — пофлудить захотелось. Но в любой шутке как говорится, только доля шутки.


+1
Re[9]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 08:48
Оценка:
Здравствуйте, craft-brother, Вы писали:
CB>Есть определенные тенденции.
С ними никто не спорит.

CB>ЗЫ. Если создание интерфейса будет выполняться только программистами без привлечения специалиста по эргономике и профессионального графического дизайнера, то в следствие непрофеесионализма прогаммера:

CB> CB>ИМХО, переход от кустарного производства к промышленному требует разделения труда и профессиональной специализации.
Можно, я Стругацких процитирую?

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

Это я к тому, что не надо из численности Usability Engineering Center в Боинге делать вывод типа "куда уж мне, убогому, соваться. Как накидал UI, так пусть и живет".
Подавляющее большинство проектов делается командами численностью до 10 человек. И для этих проектов не нужно привлекать цельные институты изучения HCI. Нужно просто пользоваться здравым смыслом.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Философия эффективности труда
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 15.02.06 09:40
Оценка:
Здравствуйте, Oyster, Вы писали:

Ш>>C## ?


O>Нету оператора ## в C#, поэтому не судьба. Зато во втором есть оператор ??...


O>C?? — вот наше будущее


Nullable C
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[10]: Философия эффективности труда
От: craft-brother Россия  
Дата: 15.02.06 09:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Подавляющее большинство проектов делается командами численностью до 10 человек. И для этих проектов не нужно привлекать цельные институты изучения HCI. Нужно просто пользоваться здравым смыслом.


В Австралии, например, аборигены жилье строят из тростника. Что же, давай теперь всем будем советовать так строить?
Предлагаю не смешивать то "как лучше" с тем "как всегда"? ((с) Черномырдин)
Многое зависит от того, для кого делается программный продукт. Для собственных нужд — делай как хочешь. Для ежедневной интенсивной работы 1000 корпоративных пользователей с окладом $60K в год — будь добр обоснуй заказчику необходимую эффективность твоего интерфейса. Не все заказчики поведутся на "здравый смысл", который будет свой у каждого из 10 программистов.
Re[12]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 10:13
Оценка:
Здравствуйте, denis_krg, Вы писали:

VD>>Знашь, откровенно говоря если сравнить вас с Вольфхаундом как специалистом в области С++, то ты как бы вообще не существущь. Ну, или тянешь на эдакого серяднечка не заметного среди серых масс, а Вольфхаунд пару собак слопал. Достаточно поглядеть на его посты одно-двух-летней давности и все становится ясным.


_>Ясно что????? То, что человек пришел к определенному мнению? Ну и что? Это мнение этого человека. Не значит, что к тому же придут другие люди.


Ясным становится его настрой на то время и круг его интересов в области программирования.

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

Я, ИТ, Вольфхаунд раньше являлись теми самыми С++-программистами не видившими ему серьезной атльтернативы. Теперь же все резко изменилось.

Однако есть те кто не пробовал и постоянно кричит, что им что-то нужно доказать или показать. Это самовнушение в стиле "это все для индусов, и нам не гоже..." уже даже улыбку не вызвают.

_>Твоя логика: я проникся. Я разумный (почти гений). Он проникся. Значит он тоже разумный. Вы, батенька, уж больно себя любите. До безобразия.


Моя логика в другм. Моя логика в неприятии мнения людей отрицающих что-то не попробовав.

_>P.S. а ссылку на статью(тьи) все-таки дай


Про что?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 12:09
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Пример "особого услвия": я не могу пользоваться янусом, поскольку .Net-фреймворк, который он хочет при установке конфликтует с той версией MS Offoce, котрая стоит на машине. (При установке фреймворка перестает работать офис, при переустановки офиса — фреймворк.) Офис купленный и использование именно этой версии является обязательным, так что...


Что за офис и как он может с фреймворком конфликтовать? В любом случае — пиши в техподдержку, тебе помогут.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[7]: Философия эффективности труда
От: Oyster Украина https://github.com/devoyster
Дата: 15.02.06 12:20
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Nullable C


Тогда бы был C?. А это вообще непонятно что (что и подразумевалось, когда я это писал )
Re[10]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 15.02.06 12:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Что за офис и как он может с фреймворком конфликтовать?

Русский 97-й (ну вот такой куплен и никто не видит причин для производства его менять).

AVK>В любом случае — пиши в техподдержку, тебе помогут.


Ага, говорят "замените версию офиса".
Re[5]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 12:38
Оценка:
Здравствуйте, Яшин Евгений, Вы писали:

ЯЕ>А майкрософт может и купит, но явно не за 150000$, потому что нафиг оно ей надо — такое качество за такие деньги. Клиенты не оценят.


$150 000 — для МС — это не деньги. Это зарплата высококласного программиста за год.
А купят или не купят они это дело не по этому. Они будут думать проще. Нужно им это или нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Философия эффективности труда
От: Дарней Россия  
Дата: 15.02.06 13:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Более того — мне куда проще потом самому реализовать то что я спроектировал, меньше работы по формализации, объяснению и контролю. Вот только я не резиновый, все и сразу сделать не могу.


Вот-вот-вот. У меня всё именно так и происходило. Проще самому написать, чем объяснить другому программисту и потом стоять у него над душой, чтобы не накосячил. И всё, понеслось

AVK>ИМХО всего лишь (не обижайся) недостаток опыта. Если будешь тренироваться, то все у тебя получится. У меня, к примеру, получается и код писать и проектированием заниматься.


Количество сущностей, которые человек может одновременно держать в воображении и работать с ними, ограничено. Тренировками можно повысить эту величину, но принципиально картину это не изменит. Поскольку после этого ты начнешь заниматься более сложными проектами, и вернешься к тому же, с чего начинал — голова пухнет
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 15.02.06 14:20
Оценка:
В кои-то веки мне хочется согласться с рассуждениями Влада.
Потому не ограничиваюсь только кнопочкой оценки...
Re[11]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.02.06 14:33
Оценка:
Здравствуйте, craft-brother, Вы писали:
CB>В Австралии, например, аборигены жилье строят из тростника. Что же, давай теперь всем будем советовать так строить?
Не надо передергивать.
CB>Многое зависит от того, для кого делается программный продукт. Для собственных нужд — делай как хочешь. Для ежедневной интенсивной работы 1000 корпоративных пользователей с окладом $60K в год — будь добр обоснуй заказчику необходимую эффективность твоего интерфейса.
CB>Не все заказчики поведутся на "здравый смысл", который будет свой у каждого из 10 программистов.
Ты вообще с кем споришь? Перечитай тред с начала и покажи мне то место, где я предлагаю уволить юзабилистов.
Вот тезис, который я хочу опровергнуть:

Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. 2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.

Этот тезис отражает отношение к проектированию ГУИ как к раскладке по окну картинок, нарисованных кем-то с художественным талантом, с пиксельной точностью.
Я не могу согласиться с таким отношением. Ни к картинкам ни к пиксельному позиционированию проектирование ГУИ не сводится. Я не против привлечения отдельных юзабилистов, если бюджет проекта позволяет и требует того. Я против того, чтобы сваливать проблемы GUI на художника, который уже рвет на себе волосы от того, что манагеры требуют "нарисуй еще понятнее", и на клик-клик кодера, который только и умеет, что выравнивать контролы и расставлять таб-ордер.
Я за то, чтобы при проектировании ГУИ люди сначала думали о юзабилити, потом — о выравнивании, и только потом — о художественных ценностях.

Я также против того, чтобы как-то мистифицировать юзабилити. Да, есть такая профессия — специалист по юзабилити. Но она не требует никаких специальных талантов, кроме здравого смысла и желания улучшить интерфейс. Ну есть у боинга толпа этих специалистов, и что? Это не Пикассы никакие, и даже не Валентины Юдашкины.

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

Но я уверен, что архитектор, который занимается проектированием самолетного софта, просто обязан со временем начать разбираться в юзабилити сам. А не отмазываться тем, что это де каких-то сверхъестественных способностей требует, которые при рождении раздаются.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.06 17:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>Чесно говоря, почитав тут наезды на McSeem2 я только за него порадовался.


Я не него и не наезжал. Речь шала о продуктивности. Синклер и ArhAngelVezel правы и не правы одновременно.

Да, ценным может быть и ювелирная работа, и порождение кучи кода решающей проблему. Вопрос как всегда в балансе. Критика GDI+ со стороны McSeem2 явно натянута, хотя и местами справидлива.

E>Так что, пусть МС выпускает ширпотреб, который удовлетворяет 90% потребителей. Главное, чтобы они не удовлетворяли 10% более требовательных (желательно хорошообеспеченных) клиентов, способных оплачивать разработки типа AGG.


И я о том же. Я бы даже сказал так. Если AGG удовлетворит потребности 0.1% и это окажется достаточно для процвитания конторы McSeem2, то замечательно и он не зря ест свой хлеб. Вот только не нужно бросать понты и уничижать чужой труд.

Конструктивная критика хороша, так как из нее можно сделать выводы на будущее. А просто наежды и кичение. Недостойно это.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 22:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ничего сверхъестественного. Немножко больше когнитивной психологии, намного больше юзабилити-тестов. Или ты вправду полагаешь, что управление боингами какие-то люди со спецталантами придумывали?


О, кстати, прекрасный пример. Классическое управление самолетом — РУД (рукоятка управления двигателем, обычно внизу широкий рычах), РУС (рукоятка управления самолетом, в просторечии штурвал) и педали. С первой все понятно, вторая завязана на элероны (влево-вправо) и горизонтальное оперение (вперед-назад). Наконец педали связаны трапециедальным механизмом и управляют вертикальным оперением.
Так вот — юзабилити у этого решения никакое. Оно весьма неинтуитивно и приходится долго обучаться. Когда всерьез занялись юзабилити, то сначала вместо РУС появился джойстик, а потом HOTAS(Hands on throttle-and-stick), который сделал ненужным РУД.
Но вот что удивительно — на боингах все осталось по прежнему
Точно так же давно известно, что текущая схема управления автомобилем тоже не самый лучший вариант, и что бы придумать лучше не нужно иметь семь пядей во лбу. Однако вот ...
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[5]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.02.06 22:55
Оценка:
Здравствуйте, denis_krg, Вы писали:

IT>>Ну почему же? Сейчас вся передовая общественность увлечённо наблюдают за развитием Nemerle. Некоторые предрекают ему судьбу, аналогичную C++, пришедшему в своё время на замену C.


_>Я эту передовую общественность только на этом сайте видел. Да и то — не передавая, а фанатичная.


Я бы рекомендовал тебе больше таких обобщений не делать.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[9]: Философия эффективности труда
От: kedik  
Дата: 16.02.06 06:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Так вот — юзабилити у этого решения никакое. Оно весьма неинтуитивно и приходится долго обучаться. Когда всерьез занялись юзабилити, то сначала вместо РУС появился джойстик, а потом HOTAS(Hands on throttle-and-stick), который сделал ненужным РУД.

AVK>Но вот что удивительно — на боингах все осталось по прежнему

На счет юзабилити не совсем верно...

Это решение становиться интуитивным примерно после 10 часов налета... И в основном это тратиться не на изучение "интерфейса" а для привыкания к "обратной связи" — для современного человека несвойственно свободное перемещени в трех измерениях без опоры на твердую поверхность — вестибулярный апарат не натренирован... Это на основе моего личного опыта... правда не на Боинге, конечно ...

Но по сути джойстик и есть РУС, а в HOTAS левая рука лежит таки на РУДе — принципиально ничего не меняеться — для небольших самолетов там на РУДе особо и размещять нечего — все что нужно и так там, а для больших — все равно места не хватит

Что касательно авиации, то все придумано (по крайней мере интерфейс РУС/РУД) как раз особыми людьми и называються они — пилоты, а реализовано конструкторами — по началу это были одни и те же люди... именно поэтому для первого самостоятельного вылета достаточно порой и 5-7 часов... а не годы... годы уходят на то что бы изучить остальные кнопки и нафига они нужны

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

PS. Есть такая байка, по преданию вроде сказанная как раз пилотом Боинга:
"Для управления современным самолётом нужны двое — пилот и сабака... Обязанность пилота — кормить сабаку... а собака должна следить за тем что бы пилот ничего не трогал"
Re[11]: Поштучно говоришь...
От: Дарней Россия  
Дата: 16.02.06 07:21
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Конечно же это байка, но без криминальной составляющей она вполне правдоподобна — вечные лампочки не выгодны индустрии и именно поэтому их нет в магазинах.


А ты проверял? "Вечные" лампочки продаются практически в любом хозяйственном магазине. Они конечно не совсем вечные, но живут на пару порядков дольше обычных — это точно. А обычные лампочки не заменили потому, что стоят они тоже на порядок больше. Соображение "жаба душит" действует железно и в этой области
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: Философия эффективности труда
От: Дарней Россия  
Дата: 16.02.06 07:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Совершенно верно. Смею напомнить, что в нашей работе команды большего размера — экзотика. Численность компаний попрошу в пример не приводить — у нас вон тоже под полтыщи человек под ружьем. А в нашей команде — десять. В твоей команде сколько народу?


Аналогично. Но это характерно только для проектов среднего размера, да и то по большей части в начале жизни проекта. Потом все равно начинается жесткое разделение обязанностей по проектированию и кодированию. Ну или проект просто погибает под своим весом.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[13]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 16.02.06 10:22
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>По-моему ты конкретно преувеличиваешь. Тут Влада нет пока, все корректно.



:
With best regards
Pavel Dvorkin
Re[4]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 16.02.06 10:27
Оценка:
Здравствуйте, IT, Вы писали:

IT>Если я вступил в полемику, то вряд ли уже буду заниматься модерированием данного топика. Но могу попросить сделать это кого-нибудь другого


Вот этот принцип очень хорошо было бы сделать обязательным правилом. Поддерживаю на 100%
With best regards
Pavel Dvorkin
Re[10]: Философия эффективности труда
От: Дарней Россия  
Дата: 16.02.06 10:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Чем больше будет дипломированных идиотов, тем труднее будет специалистам доказать, что они не идиоты и тем труднее будет отличить идиота от специалиста.


Если они специалисты, то докажут. А если не могут доказать — значит, грош цена таким "специалистам"
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Философия эффективности труда
От: Privalov  
Дата: 16.02.06 10:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Чем больше будет дипломированных идиотов, тем труднее будет специалистам доказать, что они не идиоты и тем труднее будет отличить идиота от специалиста.


Из наблюдений: чем выше квалификация специалиста, тем меньше обращает внимания окружающих он обращает на свои дипломы, сертификаты и пр. Так что отличить будет не скажу, что просто, но и совсем не так сложно, как кажется.
Re[11]: Философия эффективности труда
От: Pavel Dvorkin Россия  
Дата: 16.02.06 11:03
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Если они специалисты, то докажут. А если не могут доказать — значит, грош цена таким "специалистам"


Уж не помню откуда. Про лошадь.

"научилась спать стоя и работать как лошадь. Несмотря на это, всегда можеть быть заменена ослом, если осел дипломированный".
With best regards
Pavel Dvorkin
Re[12]: Философия эффективности труда
От: Дарней Россия  
Дата: 16.02.06 11:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>"научилась спать стоя и работать как лошадь. Несмотря на это, всегда можеть быть заменена ослом, если осел дипломированный".


Человек — не лошадь, его ослом не заменишь. Пусть даже и дипломированным.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.02.06 11:35
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>О! Это значительный прогресс, Влад! Я рад, что ты в конце концов понял это.


Можешь поясничать дальше, если тебе это доставляет удоволствие. Конструктива это не прибавит.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.02.06 11:35
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Русский 97-й (ну вот такой куплен и никто не видит причин для производства его менять).


И как 97-ой Офис может конфликтовать с дотнетом? У них ни ожного общего компонента.

AVK>>В любом случае — пиши в техподдержку, тебе помогут.


EXO>Ага, говорят "замените версию офиса".


Привиди, плиз, ссылку на отписку, или цитату с мылом того кто отбрехался.

Пока что все это смахивает на выдумку.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.02.06 11:35
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>Вон, на жаба-сайтах (www.theserverside.com, www.javalobby.org) уже сколько лет про аспектно-ориентированное программирование народ бодается. Это не язык, это технология, методики и т.д. и т.п. И что? Пока толком не ясно что же от этой фишки хорошего, что плохого.


АОП пока что в стадии иследований. И его губит совершенно бредовая терминалогия. С такой терминалогией ему выжить нереально.

К тому же АОП всего лишь один небольшой узкий подход в том время как метапрограммирование (МП) технология куда как более универсальная и гибкая. АОП реализуем на МП, но МП не реализуемо на АОП.

_>Так что передовая общественность за чем только не наблюдает.


А не передовая исходится сомнениями и сарказмом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Философия эффективности труда
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.02.06 14:02
Оценка:
Здравствуйте, craft-brother, Вы писали:
CB>Повторюсь, речь идет не о простеньких и мало распространенных программных поделках.Речь об эффективности автоматизации профессиональной деятельности большого числа (1000 — 1000000) пользователей.
Продукт на 1000 пользователей — это практически любая ERP система. Их в мире как грязи. Большинство, насколько мне известно, страдают проблемами с юзабилити.
CB>Для иллюстрации нетривиальности возможных решений еще один пример. В двух словах (погугли — найдешь). Танком Т-90 водитель управляет, в бою лежа, а на марше — высунув голову из люка и вдыхая выхлоп впереди идущей машины. Где здесь здравый смысл? Все это сделано для того, чтобы на 0,5 м уменьшить высоту танка и повысить его боевую эффективность.
Я все равно не понимаю, как Т90 относится к тому, что программисты малораспространенных программ отмазываются от проектирования UI под предлогом отсутствия художественных способностей. Это не программный продукт, а разработкой танков я не занимаюсь.
CB>Давай не спорить, а попытаемся придти к общему знаменателю.
Давай.
CB>1. Согласен, что промышленное производство эффективнее кустарного при массовости продукта?
Не в курсе. Пока что хороших примеров промышленного производства я не видел. Имеется, я надеюсь, программный продукт? Мало опыта, наверное. Все, что я видел — кустарные поделки. Вот сейчас участвую в разработке массового продукта. Кустарным, конечно, способом. И совершенно не вижу пути внедрить к нам промышленное производство.
CB>2. Согласен, что основа этой эффективности лежит в разделении труда и специализации?

CB>3. Согласен что художник, специалист по промышленному дизайну лучше и быстрее, чем программист, подберет цветовую гамму, шрифты и компоновку элементов экранной формы?

Нет, не согласен. Гамму и шрифты — запросто. Компоновку — не уверен. Я специалистов по промышленному дизайну пока вживую не встречал, а насчет художника — 100% уверен что ничего он не сделает. И из личного опыта, и из банальных соображений здравого смысла. Откуда художнику знать, сколько элементов на самом деле будет в комбобоксе? Как он догадается, что комбобокс можно заменить списком с чекбоксами? Художник оперирует не теми понятиями. Даже если он рисует элемент управления, он никогда не задумывается о его поведении. Максимум, что может придумать художник — это look. А нужно еще и feel.
CB>4. Согласен, что специалист по юзабилите лучше и быстрее, чем программист (архитектор), спроектирует человеко-машинное взаимодействие?
Лучше — может быть. Быстрее — не факт. С учетом того, что сначала кто-то должен потратить очень много времени на то, чтобы объяснить этому специалисту суть решаемой задачи.
Архитектор по определению знаком со всеми требованиями. Кроме того, этот специалист должен хорошо себе представлять возможности используемой платформы, потому как они диктуют жесткие ограничения. В итоге мы получаем дубликат архитектора с уклоном во взаимодействие между человеком и машиной. А архитектор, получается, ограничивается взаимодействием внутренних частей софта между собой.
Если у вас очень большой проект (независимо от количества пользователей) с резиновым бюджетом, то можно позволить себе нанять по архитектору для каждого стыка в системе — архитектор по интеграции, архитектор по персистенсу, архитектор по HCI, архитектор по хардвару, архитектор по миграции с предыдущих версий и конкурирующих продуктов...

В жизни в 90% проектов даже один архитектор — это уже роскошь. И именно он отвечает за все, включая HCI. Архитектор имеет право отказаться от рисования иконок. А вот отказываться от проектирования взаимодействия — нет. Потому что иначе он не архитектор, а обманщик, который не делает свою работу. Взаимодействие пользователя с софтом есть важнейшая часть архитектуры.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.02.06 16:26
Оценка:
Здравствуйте, EXO, Вы писали:

VD>>Пока что все это смахивает на выдумку.


EXO>Влад, я не считаю нужным продолжать разговор в таком тоне.


В каком тоне?

Скажу более прямо. Привиди, плиз, подтверждение своим словам, так как они вывзват сильные сомнения. Так понятно? И не нужно делать вид, что тебя это оскорбляет. Делаешь заявления, трудись их обосновывать. А то мы тут может долго обсуждать то чего нет на самом деле.

Что касается вопроса, то я не раз посылал багрепорты в МС и не разу не видел, чтобы на хорошо оформленный отчет об ошибках не было соотвествующей реакции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 17.02.06 06:32
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Скажу более прямо. Привиди, плиз, подтверждение своим словам, так как они вывзват сильные сомнения. Так понятно?

Влад, пойми, меня твои сомнения не интересуют. То есть совсем. Поскольку мне лично от тебя ничего не надо.
И мне достаточно пофигу веришь ты или нет. Я просто рассказал, почему лично я не использую .Net. И отчасти почему избегаю делать на нем продукты для своих клиентов (поскольку не хочу рисковать наступанием на подобные проблемы у них).
Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо? Уличать MS? А опять же нафига? Доказывать что-то тебе? А не слишком ли жирно будет?

VD>Что касается вопроса, то я не раз посылал багрепорты в МС и не разу не видел, чтобы на хорошо оформленный отчет об ошибках не было соотвествующей реакции.


Кто сказал что небыло? Предложение заменить офис вполне соответсвующая реакция... и достаточно корректная — я бы на их месте сам так ответил. Напомню, что офис 97 русифицировал не MS. В евро-версии русского языка тогда еще небыло. Причем я знаю минимум 3 независимые русификации оного. А потому предложение перейти на единуюя мультиязычную версию вполне разумно в общем случае. Дугое дело, что это ситуация показала мне, что .Net не полностью палелен старому коду — какие-то пересечения есть. Какие — не знаю, но есть. А значит, он может пересечься и с чем-то еще.
И кто-то еще так же как я может просто не стать ставить .Net программу, если она не встанет "с пол пинка", или подерется с чем-то имеющимся на компе. Так же как я не стал ставить янус, зная, что с наскоку он не встанет.
Да, можно было исследовать вопрос и найти решение. Наверняка можно. Но это надо делать для каждого частного случая. И проблемы с установкой .Net не только у меня. Я знаю в своем окужении еще как минимум двоих людей, которые такие проблемы имели. В каждом случае разные. Правда, во всех случаях на компах был "старый софт".
Re[6]: Философия эффективности труда
От: minorlogic Украина  
Дата: 17.02.06 09:36
Оценка:
А давайте поговорим более детально ?
По факту, алгоритм растеризации сложных многоугольников в GDI работал вроде бы приемлемо для большинства.

Но при тестировании асимптотики от сложности полигона, обнаруживаем смешную деталь . Оказывается начиная с какогото предела, реализация ведет себя как O(n^2). Эти тесты валились на win2000.

И после этого мне кто то расскажет про квалификацию комады Microsoft делающую GDI+ ? увольте.

Кстати возможно , что они до сих пор не пофиксили это поведение, для желающих проверьте на GDI+.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[14]: Философия эффективности труда
От: Дарней Россия  
Дата: 17.02.06 09:57
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Еще как заменишь! Сколько у нас в мире мест, где сидят дипломированные ослы!


Я такие места тоже видел. Разнообразные шарашки на государственном финансировании, по большей части. Но мне там делать все равно нечего. Так что пусть себе разлекаются
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[13]: Философия эффективности труда
От: WolfHound  
Дата: 17.02.06 10:25
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Все это я к чему? Да вот, решил переписать шашечную прорамму. Я точно помню, что реализации ее заняла у меня в студенчестве два дня. Вообруженный новым багажом и новыми знаниями, с учетом того, что я хорошо помнил используемый алгоритм, его я реализовывал пару недель. Постоянно пыхтел, трудился... Вот тут можно рефакторинг сделать, вот тут эту фичу. Нет, надо назад вернуть, ... Создавалось такое (возможно обманчивое) впечатление, что знания о том, что даже возможности IDE, к которым ты привык и без которых ты не можешь, отвлекали от цели... Мысли не о задаче, а о том, какую бы фичу из арсенала средств можно испоьзовать... Конечно, можно сослаться, что шашечная программа не есть реальный сложный проект, но кошки на душе как-то остались и с тех пор я стал очень настороженно относится к новым возможностям...

Дело в том что ты пытался применять эти технологии на сознательном уровне. А надо такие вещи выносить на подсознательный уровень. Туда вобще надо выносить все что можешь.
Вот вочему у меня в программах на С++ ни память не портится и ни чего не утекает. А по тому что все грабли С++ у меня на уровне рефлексов. Автопилот работает.
В C#'е есть свои тонкости. IDE у него сложная и навороченая и помнить о всех ее фишках просто не реально. Да и памяти на задачу не хватит. А вот если выработать рефлексы то никаких проблем со всеми этими наворотами не будет. Это будет также просто как дышать. Ты вобще отвлекаешься на дыхание? А ведь это процесс гораздо сложнее чем автокомплит.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Философия эффективности труда
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 17.02.06 11:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот вочему у меня в программах на С++ ни память не портится и ни чего не утекает. А по тому что все грабли С++ у меня на уровне рефлексов. Автопилот работает.

Против возможнотей C++ я ничего не имею.

WH>В C#'е есть свои тонкости. IDE у него сложная и навороченая и помнить о всех ее фишках просто не реально. Да и памяти на задачу не хватит. А вот если выработать рефлексы то никаких проблем со всеми этими наворотами не будет. Это будет также просто как дышать. Ты вобще отвлекаешься на дыхание? А ведь это процесс гораздо сложнее чем автокомплит.

У меня в Delphi все тоже на уровне автопилота. Но проблема немного не в том. Подход к решению задач что-ли изменился...
Re[13]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.02.06 12:24
Оценка:
Здравствуйте, Mystic, Вы писали:

M>А мне кажется, как раз наоборот. К хорошему быстро привыкаешь. Вот моя з/п со времен студенчества выросла в 30 раз. Думаешь у меня проблема ее потратить??? И никаких фобий А вот если ее урезать раз в десять, то будут большие проблемы. И провокационный вопрос: если человек уже имеет опыт разработки рабочих продуктов с небольшим бюджетом, почему он должен обязательно провалить следующий проект?


Ну вот опять. Ты не заметил что предыдущий оратор использовал аналогию в качестве примера, а ты только на ее основании сделал вывод. Так нельзя. Теперь по делу — здесь
Автор: AndrewVK
Дата: 10.01.05
я ответил на твой вопрос.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[7]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.02.06 12:34
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А ответ на вопрос, что я выбираю — предельно прост в вашем случае. Если модератор в данном топике принимает участие, он передает свои права на его модерирование (этого топика, не более) своему коллеге. А тот, наоборот, ему в аналогичном случае.


Проблема только в том, что таких коллег недофига. Например в этом топике отметились все местные модераторы. Кому его модерить?
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[7]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.02.06 21:19
Оценка:
Здравствуйте, denis_krg, Вы писали:


VD>>АОП пока что в стадии иследований. И его губит совершенно бредовая терминалогия. С такой терминалогией ему выжить нереально.


_>Это ты так думаешь. А многие думают по-другому. Я про тех, кто занимается исследованиями в этой сфере.


Я думаю, что этих многих по пальцам одной руки можно пересчитать. Я как редактор принимал участе в попытке подготовить материал по АОП. И видел тот тихий ужас который творился при попытке перевести термины. Они ведь на английсоком непонятны. А на русском они вообще в кашу превращаются.

VD>>К тому же АОП всего лишь один небольшой узкий подход в том время как метапрограммирование (МП) технология куда как более универсальная и гибкая. АОП реализуем на МП, но МП не реализуемо на АОП.


_>Опять же, метапрограммирование уже проходили.


Похоже что проходили мимо.

_> Пока ничем хорошим вроде не кончилось.


Да вроде как многие используют. Причем даже при том, что удобных средств почти небыло.

_> Не получила эта технология распространения.


Про построители парсеров к примеру слышал?

_> Может быть кто-нибудь удачную реализацию предложит, но ответить на этот вопрос ни 1 человек ни 1 группа людей не может. Тут нужно ВРЕМЯ.


Да уже предложили. Макросы Лиспа оказались очень неплохим решением. В Нэмерле это решение было доведено до очень внушительного уровня.

Кстати, на макросах Нэмерла авторы языка с успехом эмулируют АОП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 19.02.06 07:43
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Ссыкла подтверждающая твои слова будет?

Я уже сказал, что нет. Причем принципиально "нет".


VD>В общем, ты меня извини, но ты явно пыташся придумать проблему. Фрэймворк без проблем ставится на все версии виндовс заявленные в совместимости и физически не может повредить ранее установленные приложения, так как не модифицирует ничего в ОС. Фрэймворк довольно замкнутое приложение. Он влияет только на приложения на нем созданные.


Да ради бога, верь в это если хочешь.
Re[9]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.02.06 13:21
Оценка:
Здравствуйте, IT, Вы писали:

IT>Почему эмулируют? Точно так же можно сказать, они эмулируют и ООП


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

А вот АОП — это синтаксический сахар который реализуется на макросах. Но тут ничего страшного нет, так как в языке почти все синтаксический сахар. Даже операторы && и || и то синтаксический сахар.

Так что можно смело сказать, что императивное программирование в Нэмерле тоже эмулирвется. Для его поддержки сделаны только изменяемые переменные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Философия эффективности труда
От: Adopt  
Дата: 19.02.06 22:18
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?


Допустим
Эффективность — мощность (работа за промежуток времени)
Всем известно что,

[Мощность] — Вт
Вт = 1 Дж / 1 сек.
1 Дж = Н * м
Н = кг * м / (сек * сек)

Итого

[Эффективность] = (кг * м ^ 2)/(сек ^ 3)

кг — количество кода
м — "правильность" кода
сек — более большая единица времени чем секунда (в зависимости от сроков и времени проекта, часов в рабочем дне и прочее)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Философия эффективности труда
От: Павел Кузнецов  
Дата: 20.02.06 22:23
Оценка:
Здравствуйте, VladD2, Вы писали:

EXO>>Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо?


VD>Извини, но ты в МС никто не ведет личную переписку по багам.


Ведет. Более того, иногда даже hotfixes предоставляет, которые иным способом недоступны. См., например, http://support.microsoft.com/kb/839582/en-us

VD>Для этого есть багтрекеры в которых любой баг отмечается и может быть найден.


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

VD>Так что уже видно, что ты говоришь не правду.


Или же ты просто торопишься с выводами...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re: Философия эффективности труда
От: vdimas Россия  
Дата: 20.02.06 22:47
Оценка:
Здравствуйте, McSeem2, Вы писали:

Слушай, а в чем проблема с тем алгоритмом-то? Выложи сюда все условия, глядишь — поможем сообща.

А то действительно, банально жаль твоего времени.
Re[8]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 20.02.06 22:57
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>Большинству программистов у нас, к сожалению банально НЕ УДАЕТСЯ найти задачи, сложнее этих шестеренчатых пар.


Выделенным ты фактически подтверждаешь мою мысль.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философия эффективности труда
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 21.02.06 10:35
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

EXO>>>Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо?


VD>>Извини, но ты в МС никто не ведет личную переписку по багам.


ПК>Ведет.


Подтверждаю.

ПК>Более того, иногда даже hotfixes предоставляет, которые иным способом недоступны. См., например, http://support.microsoft.com/kb/839582/en-us


Нам предоставляли хотфикс к ворду 2000, хотя я и уверен, что он не уникален.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: Философия эффективности труда
От: vdimas Россия  
Дата: 24.02.06 08:23
Оценка:
Здравствуйте, McSeem2, Вы писали:


V>>Слушай, а в чем проблема с тем алгоритмом-то? Выложи сюда все условия, глядишь — поможем сообща.


MS>Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д.


Звучит как минимум подозрительно... Ты с голым алгоритмом экспериментируешь или с какой-нить железкой/технологией? Если первое, то оччень подзрительно звучит, наверняка догадываешься — почему...


MS>Придумывать обобщенные методы решения, потому что любые ad-hoc приводят к сказке-неотвязке (never ending story). В-третьих — моё! Не дам! Я страшный-ужасный маньяк!


Нет, обычный жадина


V>>А то действительно, банально жаль твоего времени.


MS>Этот вопрос не должен Вас беспокоить.


Более того, меня даже не обеспокоила такая постановка вопроса, и еще более того... Вас совершенно не должен беспокоить вопрос относительно того, что же именно может беспокоить меня.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 24.02.06 20:09
Оценка:
Здравствуйте, vdimas, Вы писали:

MS>>Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д.


V>Звучит как минимум подозрительно... Ты с голым алгоритмом экспериментируешь или с какой-нить железкой/технологией? Если первое, то оччень подзрительно звучит, наверняка догадываешься — почему...


Я не знаю, что такое "голый алгоритм", но подрузамеваю, что под ним понимается что-то типа quick sort. А моя задача — триангулировать Flash, всего-навсего. Но надо это сделать так, чтобы не было стыдно встраивать в железяки типа мобильников. Если есть желание — надо взять GameSWF и переписать в нем тесселятор. А вот в чем там заключается "подстава" — это действительно долго объяснять.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re: Философия эффективности труда
От: Chipsеt Россия http://merlinko.com
Дата: 25.02.06 05:25
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, VladD2, Вы писали:


MS>http://www.rsdn.ru/Forum/Message.aspx?mid=1670280&amp;only=1
Автор: VladD2
Дата: 09.02.06

VD>>Эффективность такой экстенсиной разработки стримительно стремится к нулю. Не прийми это на свой счет, но ты даже не осознашь насколько не эффективно ты трудишся.

MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?

MS>Подозреваю, что ты скажешь, что-то типа "в количестве успешно решенных задач". Но и это тоже не критерий, поскольку все зависит от того, что считать "решенной задачей".

MS>Я ни в коем случае не пытаюсь навязать свою точку зрения. Нет ничего унизительного в грязной работе по проектированию и дизайну форм в дот-нет студии (ну кто-то же должен — да мне и самому приходится это делать).

MS>Поэтому просьба не принимать на свой счет, это просто лично мне не нравится весь этот лохотрон. Ну вот не нравится и все тут. Мне нравится свой лохотрон.

Я с тобой согласен на 100%.
Однако хочу защитить "бросание на форму контролов". Есть такое слово (и даже форум) -- искусство юзабилити. И это искусство не хуже и не лучше создания алгоритмов. "Бедных индусов" туда пускать нельзя что-бы не появлялись такие темы как Руки от ушей
Автор: crackoff
Дата: 14.04.05
.
Напоследок скажу что сам я не в коем случае не гениальный дизайнер ГУЯ, я сам то в основном клавиатурой пользуюсь . Просто хотел тебе указать что пример который ты привел малость некорректный
"Всё что не убивает нас, делает нас сильнее..."
Re[7]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.06 15:28
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.


Ага. Но судя по моим ощущениям от McSeem2 этого никогда не будет.

ЗЫ

Я буду рад если ошибусь!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 25.02.06 17:25
Оценка:
Здравствуйте, Chipsеt, Вы писали:

C>Однако хочу защитить "бросание на форму контролов". Есть такое слово (и даже форум) -- искусство юзабилити. И это искусство не хуже и не лучше создания алгоритмов. "Бедных индусов" туда пускать нельзя что-бы не появлялись такие темы как Руки от ушей
Автор: crackoff
Дата: 14.04.05
.


Это верно и я уже упоминал, что задача проектирования ГУИ — это сложное дело. Вот простейший пример — диалог супротив конфиг файла. Диалог — это конечно хорошо, но где в нем функция поиска нужного элемента? А когда в диалоге с два десятка закладок, без поиска становится плохо (Apple что-то сделали в этом направлении, но в общем и целом — конь не валялся). Налицо яростная профанация с оголтелым ущемлением функциональности.

C>Напоследок скажу что сам я не в коем случае не гениальный дизайнер ГУЯ, я сам то в основном клавиатурой пользуюсь . Просто хотел тебе указать что пример который ты привел малость некорректный


В том-то и трагедия, что корректный. Набор инструментов, что поставляется с той же студией — он яко бы позволяет "любой домохозяйке сделать ГУИ". И если там один чек-бокс и две кнопки, то это действительно так. Но изготовление чего-нибудь чуть более сложного в том же форм-дизайнере превращается в кошмарную рутину. Для специалиста по юзабилити — штука совершенно бесполезная, а у домохозяек в любом случае получаются "кошмарные домашние странички". Эта профанация безусловно выгодна с точки зрения мгновенных прибылей, но она создает лишь иллюзию работоспособности — некая поделка сделанная индусами для индусов рангом пониже. Да это же всемирный заговор!!!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 25.02.06 17:57
Оценка:
Здравствуйте, IT, Вы писали:

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


И это верно. А чем же они тогда пользуются, если сразу отключают? Есть какая-то альтернатива? Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера. Все эти рукоблудства с генерированием кода — не более чем маркетинговый тотал-булшит.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Философия эффективности труда
От: Cyberax Марс  
Дата: 25.02.06 18:03
Оценка:
IT wrote:
> Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не
> было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер
> сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол
> по пикселям в коде с постоянной перекомпиляций для проверки попадания —
> дело не для слабонервных.
Эээ... А про "layout managers" вы слышали?

У меня в Java через некоторое время использования layout'ов в Swing (и
SWT) пропало желание использовать GUI-дизайнеры вообще.

Хотя что-то типа wxGlade'а — тоже вполне нормально (так как позволяет
визуально смотреть иерархию лэйаутов).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 25.02.06 18:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Эээ... А про "layout managers" вы слышали?


Слышали и видели и даже в руках держали. Частично это помогает, но от покрытия нужных мне 100% случаев layout manager'у как без языка до Киева. К тому же размеры контролов, цвет, шрифт и прочую мелочовку он не менеджит. Т.е. удобное средство, решающее свои конкретные задачи, на универсальный подход не претендующее.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Философия эффективности труда
От: Cyberax Марс  
Дата: 25.02.06 18:39
Оценка:
IT wrote:
> C>Эээ... А про "layout managers" вы слышали?
> Слышали и видели и даже в руках держали. Частично это помогает, но от
> покрытия нужных мне 100% случаев layout manager'у как без языка до
> Киева.
Не знаю, вот в Eclipse их для всего хватает. AbsoluteLayout там вообще
не используется нигде в стандартной поставке.

> К тому же размеры контролов, цвет, шрифт и прочую мелочовку он не

> менеджит.
Как раз размеры менеджаться спокойно (в соответствующих layout'ах).
Шрифтов обычно используются один-два на форму, так что с ними проблем
обыно нет. Для подбора цветов есть плугины к IDE.

> Т.е. удобное средство, решающее свои конкретные задачи, на

> универсальный подход не претендующее.
Эти задачи покрывают фактически 99% всего.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[7]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 25.02.06 18:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Эти задачи покрывают фактически 99% всего.


Т.е. к layout manager'ом дело не заканчивается, ты ещё используешь ещё кучу всяких приблуд
Правильно? А то я уж подумал, что в джаве всего лишь одна кнопка, которая называется "layout manager".
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Философия эффективности труда
От: Cyberax Марс  
Дата: 25.02.06 19:04
Оценка:
IT wrote:
> C>Эти задачи покрывают фактически 99% всего.
> Т.е. к layout manager'ом дело не заканчивается, ты ещё используешь ещё
> кучу всяких приблуд
> Правильно?
Ну еще и контролы нужны, естественно. Но 99% задач с построением
формочек (то есть то что делает form-designer) решаются layout'ами,
причем обычно красивее и удобнее.

Например, с помощью layout'ов обычно очень легко сделать масштабируемые
формы. Или формы, которые будут работать с настройками шрифта "Очень
крупный". А вот в дизайнерах форм типа MSовского это обычно не делается
нормально (я прошу, только не надо вспоминать anchor'ы).

> А то я уж подумал, что в джаве всего лишь одна кнопка,

> которая называется "layout manager".
Ага, одна большая красная кнопка
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Философия эффективности труда
От: IT Россия linq2db.com
Дата: 25.02.06 19:21
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну еще и контролы нужны, естественно. Но 99% задач с построением формочек (то есть то что делает form-designer) решаются layout'ами, причем обычно красивее и удобнее.


Никогда не забывай добавлять в таких случаях — ИМХО или для моих задач

C>А вот в дизайнерах форм типа MSовского это обычно не делается нормально (я прошу, только не надо вспоминать anchor'ы).


Для большого проекта лучше сразу покупать какую-нибудь библиотеку контролов. Один тоже в большинстве своём не идеал, но то, что предлагает MS вообще ниже всякого плинтуса.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 25.02.06 20:57
Оценка:
Здравствуйте, IT, Вы писали:

MS>>Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера.


IT>Не совсем так. Кроме пикселей есть ещё куча свойств, который нужно контролировать. Тот же TabOrder, например, шрифты, цвет, баиндинг.


Ну так это же все чисто визуальные свойства, которые должны быть отделены от кода. Да я даже был бы не против того, чтобы этот дизайнер подковыривал что-то в моем коде, при условии 100% соблюдения первой медицинской заповеди "не навреди". И то, что работоспособность среды разработки напрямую зависит от устойчивости контролов — за такие "архитектурные решения" надо вообще отвинчивать яйца с особым цинизмом. Запусти внутри OnPaint своего контрола бесконечный цикл — студии кирдык.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[17]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.02.06 21:12
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ведет. Более того, иногда даже hotfixes предоставляет, которые иным способом недоступны. См., например, http://support.microsoft.com/kb/839582/en-us


Это ни о чем не говорит. Вот к этому багу тоже нет публичного хотфикса, но это не означает, что какая то важная информация о самом баге скрыта от глаз наблюдателей, все ответы MS касательно его судьбы в описании бага присутствуют.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[17]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.02.06 21:12
Оценка:
Здравствуйте, craft-brother, Вы писали:

CB>

CB>"Программисты любят и умеют программировать...


Я так понимаю что это цитата. Имя ученого мужа не огласишь? Или ты самого себя цитируешь?
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[20]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.02.06 21:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Точно так же и совет "для создания удобного пользовательского интерфейса пригласите специалиста по юзабилити" на практике бесполезен. Более того, я считаю его вредным как минимум для архитекторов, потому что он подразумевает отсутствие необходимости думать самому, и поощряет мысли типа "у нас нет на это денег, а значит хрен с ней с юзабилити". В самом-самом большом проекте, даже типа офиса, уверяю тебя, главный архитектор вовсе не отдает все на откуп "спецам". Архитектор должен сам понимать, что такое юзабилити, иначе его надо гнать в шею, ибо он не сможет внятно поставить задачу юзабилисту.


Главное — именно архитектор принимает решение о балансе юзабилити и затратах труда на него.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[7]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 25.02.06 22:41
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.


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

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

В-третьих, есть нечто такое, причем не одно:
1. http://www.rsdn.ru/Forum/Message.aspx?mid=1582093&amp;only=1
Автор: McSeem2
Дата: 11.01.06

2. AGGPlus, http://www.point.com.mk/aggplus/
3. http://antigrain.com/stuff/Agg2D.zip. Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.

Ну а уж сделать враппер для .Net на MC++ — не сложно.

McSeem
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Философия эффективности труда
От: Cyberax Марс  
Дата: 26.02.06 03:56
Оценка:
IT wrote:
> C>Ну еще и контролы нужны, естественно. Но 99% задач с построением
> формочек (то есть то что делает form-designer) решаются layout'ами,
> причем обычно красивее и удобнее.
> Никогда не забывай добавлять в таких случаях — ИМХО или для моих задач
ОК, буду соблюдать политкорректность

> C>А вот в дизайнерах форм типа MSовского это обычно не делается

> нормально (я прошу, только не надо вспоминать anchor'ы).
> Для большого проекта лучше сразу покупать какую-нибудь библиотеку
> контролов. Один тоже в большинстве своём не идеал, но то, что предлагает
> MS вообще ниже всякого плинтуса.
Так проблема не во внешнем виде контролов, а в способе их расположения.
Хотя, если в сторонней библиотеке есть layout'ы...
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[18]: Философия эффективности труда
От: Павел Кузнецов  
Дата: 26.02.06 04:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Это ни о чем не говорит. Вот к этому багу тоже нет публичного хотфикса, но это не означает, что какая то важная информация о самом баге скрыта от глаз наблюдателей, все ответы MS касательно его судьбы в описании бага присутствуют.


Суть в том, что не все баги есть в этой базе. Соответственно, отсутствие информации об ошибке в данной базе не позволяет Владу утверждать о том, что его оппонент нечестен.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[18]: Философия эффективности труда
От: craft-brother Россия  
Дата: 26.02.06 09:25
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Я так понимаю что это цитата. Имя ученого мужа не огласишь? Или ты самого себя цитируешь?


здесь
Re[19]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.06 09:54
Оценка:
Здравствуйте, craft-brother, Вы писали:

AVK>>Я так понимаю что это цитата. Имя ученого мужа не огласишь? Или ты самого себя цитируешь?


CB>здесь


Ну так я и знал, никому не известный "авторитет".
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[8]: Философия эффективности труда
От: ArtemGorikov Австралия жж
Дата: 26.02.06 10:43
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, ArtemGorikov, Вы писали:


AG>>... Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.


MS>Ну во-первых, как бы это цинично ни звучало, я не так уж и уверен, что оно надо. Все-таки, чисто софтварный рендеринг, причем даже не оптимизированный под SIMD, лучше рассматривать как академические эксперименты. Просто оказалось, что можно не так уж и плохо использовать в практических приложениях (и уж точно — в областях типа растеризации карт на сервере).

Не надо скромничать. Штука действительно полезная, по качеству картинки лучше чем GDI+ а по скорости сравнимая — в чем-то быстрее, в чем-то медленнее. Чтобы эта либа пошла в массы, она должна иметь нормальный интерфейс, лучше всего — похожий на GDI+, под C++ и .NET. Только не надо пытаться повторить FlatAPI GDI+ — это INHO никому не надо.

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

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

MS>В-третьих, есть нечто такое, причем не одно:

MS>1. http://www.rsdn.ru/Forum/Message.aspx?mid=1582093&amp;only=1
Автор: McSeem2
Дата: 11.01.06

MS>2. AGGPlus, http://www.point.com.mk/aggplus/
MS>3. http://antigrain.com/stuff/Agg2D.zip. Чтобы скомпилировать, надо скачать http://antigrain.com/agg23.zip и положить файлы Agg2D* в что-то типа agg23/research/win32/Agg2D/*.* — просто чтобы не перенестраивать пути в проекте.
И все мимо цели: AGGPlus начато, но не доделано, и обертки нетовской там нет. А если есть обертка нетовская, как в здесь , то это вообще не совместимый с GDI+ интерфейс.

MS>Ну а уж сделать враппер для .Net на MC++ — не сложно.

Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.
Re[9]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 26.02.06 23:49
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

AG>Не надо скромничать. Штука действительно полезная, по качеству картинки лучше чем GDI+ а по скорости сравнимая — в чем-то быстрее, в чем-то медленнее. Чтобы эта либа пошла в массы, она должна иметь нормальный интерфейс, лучше всего — похожий на GDI+, под C++ и .NET. Только не надо пытаться повторить FlatAPI GDI+ — это INHO никому не надо.


Как раз, если воспроизвести FlatAPI, то можно просто-напрсто взять .h файлы GDI+. Но дело даже не в этом. Сама концепция GDI+ является на мой взгляд ужасно непрактичной, неудобной и ограниченной. Не надо его повторять — это неблагодарная работа. "Карандаши" и "кисти" это какой-то неестественный изврат, намешаны в одну кучу фундаментально разные понятия. И я не вижу особого смысла в совместимости. Если проект состоит из 20 мег исходников и по всему коду натыканы вызовы GDI+, то это плохой проект и ему ни какие эмуляции не помогут. Для таких случаев надо не просто эмулировать GDI+, а в точности воспроизводить все его поведение, включая глюки. Иначе где-нибудь, чего-нибудь да отъедет. Это очень неблагодарная работа и я ей заниматься не хочу. Ну а если вся графическая часть сосредоточена в небольшом файле-обертке, кил на 40, то портировать ее на другую библиотеку (хоть на OpenGL) не составляет труда.

Концепция API (или GDI) нового поколения мне представляется несколько иначе.
1. Надо вернуться к традиционной stateful модели (SetFillColor()/DrawPolygon()/etc) взамен неудачной концепции кистей и прочего. Фактически, в GDI+ хотели сделать класс Graphics как stateless, но получилась машанина — трансформации у нас stateful (Rotate, Scale, etc), а использование кистей и карандашей — stateless.
2. Приделать механизм автоматического восстановления состояния. Типа BeginSessoin() добавляет некий entry в стек, EndSession() восстанавливает все изменившиеся после BeginSessoin() параметры. Эти вызовы могут быть вложенными. Для автоматизации вызовов делается простейший scope guard (в C# — using) — очень похоже на SVG или XAML.
3. Возможность формировать собственные векторные конвейеры. Например, Path->AffineTransformer->CurveFlattener->Stroker->PerspectiveTransformer->Clipper->Renderer. Все это должно быть доступно динамически, в run-time.
4. Аналогично — растровые конвейеры, например, Rasterizer->Gradient->AlphaMask->FrameBuffer.

Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.

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


Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.

AG>Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.


Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Философия эффективности труда
От: ArtemGorikov Австралия жж
Дата: 27.02.06 10:51
Оценка:
Здравствуйте, McSeem2, Вы писали:


MS>Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.

Это интересно. Но тут уже вопрос: а зачем сообществу программистов растеризация Flash? Если говорить о популярности библиотеки, то IMHO на ее популярность это никак не повлияет.

AG>>Не сложно. Но гораздо лучше, когда он уже есть и совместим со стандартом de-facto — чтобы осталось только переключить графику с GDI+ на AGG.


MS>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.

Странно... мне совсем не показалось, что GDI+ ограничен в интерфейсе. Довольно-таки простая в использовании либа, правда с кучей нареканий по поводу качества картинки и вообще контроля за процессом рисования — к примеру, у меня она рисовала довольно странного вида линии со стилем PS_DOT — как она масштабировала их толщину и расстояние м/д точками, я не понял. Ну и ее еще нельзя залинковать в модуль, а в моем случае было очень желательно ограничить конечное число модулей до 1, т.е. никаких дополнительных dll-к нести с собой нельзя. Зато GDI+ прекрасно совместима с GDI, т.е. принимает ее настройки масштабирования и все делает сама, не обременяя пользователя деталями реализации.
Re[10]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.06 13:04
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>2. Приделать механизм автоматического восстановления состояния. Типа BeginSessoin() добавляет некий entry в стек, EndSession() восстанавливает все изменившиеся после BeginSessoin() параметры. Эти вызовы могут быть вложенными. Для автоматизации вызовов делается простейший scope guard (в C# — using) — очень похоже на SVG или XAML.


Чем это отличается от Graphics.BeginContainer/EndContainer?

MS>Фактически, все конвейеры в GDI+, Java2D и прочих, жестко закодированы, за счет чего получается огромный объем кода типа switch/case с изначально ограниченной функциональностью. Например, если взять некие анизотропные преобразования (scale(0.5,2.0)), то результат рисования линии будет сильно зависеть от того, когда эти преобразования используются — до строкера или после. А управлять этим в GDI+ нельзя.


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

MS>Плохая это идея, в силу ограниченности самого GDI+. Еще раз, не хочу я эмулировать GDI+, поскольку не считаю что игра стоит свеч.


А что ты скажешь о System.Windows.Media?
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[11]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 27.02.06 15:32
Оценка:
Здравствуйте, ArtemGorikov, Вы писали:

MS>>Было, теперь стало меньше. Рост — это вполне естественный процесс. Сейчас я работаю над версией 2.4, которая будет включать растеризацию Flash. Мне представляется это более перспективным.


AG>Это интересно. Но тут уже вопрос: а зачем сообществу программистов растеризация Flash? Если говорить о популярности библиотеки, то IMHO на ее популярность это никак не повлияет.


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

AG>Странно... мне совсем не показалось, что GDI+ ограничен в интерфейсе. Довольно-таки простая в использовании либа,


Ограничен. Где, например, встроенные перспективные преобразования? Да там все тупо сделано. Фишки нет.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[12]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.06 16:40
Оценка:
Здравствуйте, McSeem2, Вы писали:

AVK>>Чем это отличается от Graphics.BeginContainer/EndContainer?


MS>Так он же только аффинный трансформер сохраняет.


А там есть что еще сохранять?

MS> Кстати, почему они назвали его "Container"? Почему не "Transformer"?


Наверное все же он сохраняет что то еще . Например Clipping.

MS>Не совсем. Растровые конвейеры — безусловно должны работать в HW (это то, что GPU умеет делать хорошо — молотить цвета в параллель), но возможности вертексных шейдеров сильно ограничены (фактически они сильно связаны с растровыми — посчитать нормаль, цвет в вершине и т.д.). Но при помощи их все равно невозможно, например, вычислить stroke. И невозможно триангулировать полигон. То есть, все равно это надо считать на CPU.


Это не страшно. Как показывает практика с векторными операциями CPU справляется, благо их обычно не так много. Главное растровые вещи акселерировать.

MS> А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.


Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.

MS>Ну почему надо упираться рогом в свои ущербные и противоречивые концепции, а не посмотреть, например, на тот же OpenVG?


Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[13]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 27.02.06 22:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

MS>>Так он же только аффинный трансформер сохраняет.

AVK>А там есть что еще сохранять?
MS>> Кстати, почему они назвали его "Container"? Почему не "Transformer"?

AVK>Наверное все же он сохраняет что то еще . Например Clipping.


Ну вот. Значит, парадигма stateless Graphics является утопией. Кстати, такие вещи, как Clipper, Transformer, Stroker являются по сути равноправными элементами конвейера. На входе точки и на выходе точки. А вот в какой последовательности их использовать — этим надо уметь управлять. Например, может быть так:
Path->Transformer->Clipper->Stroker->Transformer2->Clipper2

MS>> А это значит, что как минимум, геометрический конвейер вполне можно кастомизировать — в какой последовательности выполнять операции.


AVK>Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.


Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.



Вот скажи пожалуйста, при scale(0.5, 1), как должна выглядеть толстая линия в 99% случаев? Как на нижнем рисунке или как на предпоследнем? Имей в виду, что любое предпочтение я тут же аргументированно оспорю. Потому что нет его, этого предпочтения — в одних ситуациях требуется одно поведение, в других — другое.

AVK>Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.


Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии. Кружочки в Visio рисовать можно, но чуть более heavy duty — и кирдык.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[14]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.02.06 08:41
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ну вот. Значит, парадигма stateless Graphics является утопией.


Там вобще то чистый stateless и не заявлен. А отказ от выбора ручки или кисти скорее всего связан с большим количеством ошибок, когда забывают переключить кисть, и с тем, что этот выбор стимулирует группировать отрисовку не по семантике, а по стилю.

MS> Кстати, такие вещи, как Clipper, Transformer, Stroker являются по сути равноправными элементами конвейера. На входе точки и на выходе точки. А вот в какой последовательности их использовать — этим надо уметь управлять. Например, может быть так:

Path->>Transformer->Clipper->Stroker->Transformer2->Clipper2

Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?

AVK>>Можно. Но в 99% случаев это просто не нужно. Поэтому такая возможность не должна усложнять API.


MS>Здесь есть два подхода. Можно тупо закодировать конвейер и сказать, что это подходит для 99% случаев, а остальные дружными рядами идут в лес. Так сделано в GDI+. А можно сделать возможность составлять конвейеры самому и предоставить некий готовый конвейер по умолчанию, который и будет использоваться чаще всего (или даже несколько типовых конвейеров). Так по моему скромному разумению следует поступать.


Попробуй привести простейшие примеры на псевдокоде.

MS>Вот скажи пожалуйста, при scale(0.5, 1), как должна выглядеть толстая линия в 99% случаев? Как на нижнем рисунке или как на предпоследнем? Имей в виду, что любое предпочтение я тут же аргументированно оспорю. Потому что нет его, этого предпочтения — в одних ситуациях требуется одно поведение, в других — другое.


Понимаешь — в большинстве случаев мне по барабану.

AVK>>Ну очевидно, что у МСных архитекторов чуство прекрасного отличается от твоего.


MS>Не только моего. Как показывает практика, GDI+ непригоден для хоть сколько нибудь серьезных вещей, хоть той же картографии.


А он для этого и не делался. Нужно просто понять для чего он создавался — только для того чтобы заменить GDI, который, прежде всего, предназначен для отрисовки пользовательского интерфейса. И задача эта не менее серьезная, нежели картография, просто акценты в ней другие.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[16]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.02.06 16:35
Оценка:
Здравствуйте, McSeem2, Вы писали:

AVK>>Ты хочешь сказать, что от последовательности применения трансформов в GDI+ ничего не зависит?


MS>Я хочу сказать, что эта последовательность жестко, раз и навсегда приколочена гвоздями внутри.


Погоди. Я могу последовательно вызывать методы Graphics, меняющие его состояние и от этой последовательности, по идее, должен зависеть результат.

AVK>>Попробуй привести простейшие примеры на псевдокоде.


MS>Типа так — типовой конвейер для рисования линий на основе полигонов, самый примитив:


MS>
MS>Path path = new Path();
MS>CurveFlattener curve = new CurveFlattener(path);         // Дробит кривые на прямые отрезки
MS>Stroker stroker = new Stroker(curve);                    // Вычисляет эквидистанту к ломаной
MS>AffineTransformer trans = new AffineTransformer(stroker);// Поворот, маштабирование, etc
MS>PolygonClipper clipper = new PolygonClipper(trans);      // Отсечение полигона по прямоугольнику

MS>// Далее мы выполняем:
MS>path.MoveTo(. . .);
MS>path.LineTo(. . .);
MS>path.CurveTo(. . .);
MS>. . .
MS>// Геометрические параметры элементов конвейера
MS>stroker.width(3.5);
MS>stroker.LineJoin(Round);
MS>trans.Rotate(35.0);
MS>clipper.ClipBox(0,0,100,100);
MS>. . .
MS>// Рисуем
MS>graphics.Render(clipper);
MS>


Ну о чем я и подозревал — код весьма неудобный при отрисовке GUI.

MS>Вот именно. И подавляющему большинству — тоже по барабану. Это и есть политика преднамеренной профанации.


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

MS> Зачем вообще изучать типографику, знать, какие бывают линии и что делают те или иные преобразования? Зачем вообще знать, что 2*2=4? — можно взять калькулятор и посчитать. Я конечно понимаю мотивы такой политики, но мне она не по душе.


Все это здорово, но надо помнить, что GDI+ не для твоей души создавался.

MS>Неправда. Называется — GDI, Graphics Device Interface, то есть, штука, претендующая на универсальность.


По факту он используется для GUI и иногда для вывода на принтер. Все.

MS>Но это есть хорошо! Ибо пока у MS-архитекторов отключен думатель и включен круиз-контроль, у меня будет незанудная и высокооплачиваемая работа.


МС никогда на этот рынок и не претендовал.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[11]: Философия эффективности труда
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.03.06 15:10
Оценка:
Здравствуйте, VladD2, Вы писали:

ПК>>"Имя, сестра, имя!" Какой оно температуры и цвета?


VD>Он цвета лазурного восхода и тепературы парного молока.


...только зелёного!!!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.06 15:10
Оценка:
Здравствуйте, McSeem2, Вы писали:

AVK>>Ну напиши отрисовку кнопки с текстом и картинкой в своем стиле и на GDI+, и, думаю, все будет понятно.


MS>Сюрприз — будет примерно то же самое, что и на GDI+.


Не будет. Ты же сам тут распинался по поводу stateful/stateless. Так вот — по моей практике удобнее указывать кисти по месту, а не переключать их в контексте.

MS> Разница же в другом. Еще раз и медленно. При моем подходе я могу так сконфигурировать конвейеры, чтобы контролы рисовались совершенно по другому. При этом их код не будет затронут. С GDI+ такой возможности нет в принципе — там внутри все приколочено шиферными гвоздями.


Еще раз и медленно. В типовом сценарии применения GDI+ эти возможности и не нужны.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[23]: Философия эффективности труда
От: WolfHound  
Дата: 01.03.06 16:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

WH>>Дело в том что в варианте McSeem2 вполне можно написать небольшой хелпер

AVK>Ты еще не забыл, что мы обсуждаем удобный API. А удобный API хелперов не требует.
Меня в принципе и предложеный API вполне устраивает.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 02.03.06 04:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Он цвета лазурного восхода и тепературы парного молока. В общем, ничего интересного. Можешь не смотреть.


Батенька, Вам надо срочно обратиться к психиатору. Я абсолютно серьезно говорю. Нельзя затягивать. Такие вещи хорошо не кончаются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Философия эффективности труда
От: mrozov  
Дата: 02.03.06 09:12
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Налицо "Абсолютное" непонимание сути работы инженера.


На лицо — воинствующая безграмотность. Инженеры и ученые — это не совсем одно и то же. Подавляющее большинство инженеров никакой наукой не занимаются, а занимаются применением этой науки на практике. Очень часто — (как правило) их работа имеет разовый характер и повторному использованию не подлежит.

Лови заслуженный -1.
Re[4]: Философия эффективности труда
От: denis_krg Казахстан  
Дата: 02.03.06 10:24
Оценка:
Здравствуйте, mrozov, Вы писали:

M>На лицо — воинствующая безграмотность. Инженеры и ученые — это не совсем одно и то же. Подавляющее большинство инженеров никакой наукой не занимаются, а занимаются применением этой науки на практике. Очень часто — (как правило) их работа имеет разовый характер и повторному использованию не подлежит.


Да, кстати, господин директор школы, как быть с инженерами, которые занимаются НИОКР? Ведь инженера занимаются проектированием тех же самолетов, придумывают в том числе и новые решения, которые есть ЗНАНИЯ, которые потом используются много где.

То есть инженера, конечно, разные бывают. Но крутые — это уже практически прикладная наука. Боюсь, что тут четкой черты провести нельзя. Если что — поправь. Так что уважаемый minorlogic в чем-то прав, как ты считаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Философия эффективности труда
От: mrozov  
Дата: 02.03.06 10:59
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>Да, кстати, господин директор школы, как быть с инженерами, которые занимаются НИОКР? Ведь инженера занимаются проектированием тех же самолетов, придумывают в том числе и новые решения, которые есть ЗНАНИЯ, которые потом используются много где.


_>То есть инженера, конечно, разные бывают. Но крутые — это уже практически прикладная наука. Боюсь, что тут четкой черты провести нельзя. Если что — поправь. Так что уважаемый minorlogic в чем-то прав, как ты считаешь?


Во-первых — минусы раздавать начал не я. А раздавать два минуса на одну мысль — дурной тон, не находишь? Я вернул должок.
Во-вторых, возможность ставить минусы — не случайно тут прописана. Я ей воспользовался. А вот хто ты такой, чтобы мне этим тыкать, да еще и в оскорбительной форме? -1

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

И от этих изобретателей велосипедов и вечных двигателей спасу просто нет. Зато профессионалов, умеющих делать свою работу эффективно — всегда не хватает. Катастрофически.

И еще раз повторю — никаких переходов на личности, не знаю я ничего о MacSeem-е и охотно верю, что он — профессинал высокого класса. Однако тенденция мне не нравится. И пафос коллег-инструментальщиков считаю неуместным.
Re[12]: Философия эффективности труда
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.03.06 11:02
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>Батенька, Вам надо срочно обратиться к психиатору. Я абсолютно серьезно говорю. Нельзя затягивать. Такие вещи хорошо не кончаются.


Батенька, вам нужно срочно умерить пыл и начать уважительнее относится к собеседникам.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[2]: Философия эффективности труда
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.03.06 11:07
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Давайте попробуем себе представить деревню во время посевной. Ежели я в проведении аналогий где-то сильно облажаюсь — просьба сильно ногами не пинать, я парень городской. И вообще — не воспринимайте слишком серьезно.


M>Значица — посевная. Народ — пашет по-черному. План по валу, вал по плану, все дела.

M>И посредине всего этого — деятель, а-а-аккура-а-аатненько так сажающий зернышко за зернышком. Перед тем как
M>посадить — каждому поет колыбельную. Угол и глубину посадки без отвеса и штангенциркуля мерить даже и не берется. Собственно, процентов 30 времени он не сеет, а совершенствует инструментарий.

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Философия эффективности труда
От: minorlogic Украина  
Дата: 02.03.06 12:50
Оценка:
Оценка -1 выражает несогласие с мыслью написанной в посте ? вроде так !
1. Предлагаю не переносить на себя (как на личность) оценку , а оставить ее оценивать ПОСТ.
2. Если уж оценка переносится на личность , то забить на оценку.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[12]: Философия эффективности труда
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.06 22:24
Оценка:
Здравствуйте, denis_krg, Вы писали:

_>Батенька, Вам надо срочно обратиться к психиатору. Я абсолютно серьезно говорю. Нельзя затягивать. Такие вещи хорошо не кончаются.


Интересно, а психиаторы лечат клиническое отсутствие чувства юмора? Если нет, то будем лечить народными методами... баней.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Философия эффективности труда
От: vdimas Россия  
Дата: 07.03.06 18:20
Оценка:
Здравствуйте, klapaucius, Вы писали:

K>Беда в том, что многие люди, привыкшие к бюджетам в 100 рублей, уже просто не в состоянии освоить бюджет в 100 000. А если и освоят, то счастья это им не принесет. Их будут терзать различные фобии. "Как же так? 100 000? Это же шумашетшие деньги! Я всегда укладывался в 100! Это транжирство!".


Сейчас все наобоорот, ИМХО. Проекты, разработка которых ранее стоила бы миллионы, сейчас стоят десятки тысяч.

K> И он попробует, обязательно попробует, если его, конечно, не остановить и не обезвредить, уложить "чуть более сложную" задачу в бюджет 100р воспользовавшись каменным топором и битхаками, и всего через миллион лет, сидя на голом бетонном полу, создаст мегасистему, которую кроме него... кроме? нет, просто никто никогда не сможет поддерживать. Тоесть он ничего не создаст.


С какой это стати? Почему ты считаешь, что на новых инструментах нельзя эффективно и быстро писать эффективные и быстрые программы? Даже тот же C#, если использовать бездумно, может дать как сильный проигрышь в производительности, так и наоборот. Если кто-то интересуется эффективностью, то он как минимум прочитает рекомендации самой MS о программировании под .Net и как минимум не будет создавать необоснованных тормозов на абсолютно ровном месте только лишь по причине своего невежества и не желании понимать суть вещей, которыми оперирует (нафига типа мне эти байты/биты... а вот фиг, хорошие программисты на .Net — это все поголовно бывшие плюсовики, и они прекрасно разбираются в поднаготной).

K> Тем временем жизнь не будет стоять на месте, люди вокруг будут осваивать бюджеты и объемы памяти измеряемые астрономическими числами, неприменно с использованием передовых мегапушистых средств, а те керенки в количестве 100 000 так никогда и не будут использованы по назначению и превратятся в мукулатуру.


Повторяю медленно. Бюджеты аналогичных проектов сейчас на порядки меньше. Через десяток лет разработать "сложную" систему будет еще на порядок дешевле. Ты все извратил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Философия эффективности труда
От: Яшин Евгений Новая Зеландия
Дата: 09.03.06 14:32
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Я не призываю никого "все бросать и делать только то, что лично тебе интересно" — это ни к чему хорошему не приведет. Нужно сначала морально созреть.


Хм, интересно, вот что в вас такого созрело что вам помогло найти такого работодателя? Вообще как можно найти такого работодателя (по шагам желательно) и о чём он вообще думает.
А созревших тут, имхо, навалом. Кому неохото спокойно, сидя, ковыряясь в носу и с сурьёзным видом ходя по офису писать программку, читать, неторопясь, умные форумы, книжки, и потом приходить домой с чуством совершенно удовлетворённой самооценки. Кому неохото избавиться от понятия deadline и перестать двигать "кнопку на два пикселя" с последующей пересборкой проекта и оформлением патча. Это сложно хотя бы от того, потому что жутко занудно, и чтобы совсем не потухнуть в рутине, приходиться придумывать задачу "поабстрактнее", часто не от того, что это удобнее или быстрее, а просто потому что.
Re[6]: Философия эффективности труда
От: EXO Россия http://www.az.inural.ru
Дата: 10.03.06 05:56
Оценка:
Здравствуйте, Яшин Евгений, Вы писали:
ЯЕ>А созревших тут, имхо, навалом.

Это иллюзия.

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


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

Но тольоко маленькое НО!
Мы переборчивы, и далеко не всех возьмем "сурьёзным видом ходя по офису писать программку, читать, неторопясь, умные форумы". Специалистов по "движению кнопок" на эту вакансию не рассматривали...
Re[6]: Философия эффективности труда
От: McSeem2 США http://www.antigrain.com
Дата: 13.03.06 04:50
Оценка:
Здравствуйте, Яшин Евгений, Вы писали:

ЯЕ>Хм, интересно, вот что в вас такого созрело что вам помогло найти такого работодателя? Вообще как можно найти такого работодателя (по шагам желательно) и о чём он вообще думает.


Не знаю, что созрело, возможно некая потребность в реализации своего эго. А работодателя я не искал — они сами (и надеюсь, что не придется больше искать). Что же касается конкретных "рецептов", то вряд ли они существуют. Кое-что я весьма пафосно изложил здесь
Автор: McSeem2
Дата: 13.04.05
. Подобный опыт, однако, не может ничего гарантировать, единственное, в чем я убежден — надо активнее участвовать в некой "общественной жизни". Тратить время на общение (много времени) — без этого никуда. Работодателей искать не надо. Если все идет как задумано, они сами проявятся. Если не проявляются, значит либо пока рано, либо что-то идет не так. И вообще это не должно являться первичной целью (как ни странно звучит). Если задаваться целью именно найти работодателя, то для этого есть гораздо более прямой путь — резюме в зубы и ковровым бомбометанием.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.