Здравствуйте, yumi, Вы писали:
Y>Кстати, параллельно веду как раз таки веб-проект, среду документооборота на ASP.NET WebForms, я устал говорить заказчикам, что, то что они хотят невозможно в принципе из-за специфики веба
Знакомая картина. Сначала впарят заказчику не нужный ему веб, а потом объясняют, почему то что он хочет "невозможно в принципе".
... << RSDN@Home 1.2.0 alpha 4 rev. 1205 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
GZ>>Ты строил интуитивный интерфейс на вебе?(для справки, коренным отличием интуитивного, является возможность удобных для пользователя быстрых, часто повторяемых действий с некоторыми ответвлениями, которые чаще всего сопровождаются диалогами(которые в свою очередь реализованы на уровне HTML из рук вон плохо), быстрыми клавишами, и вообще плотным взаимодействием пользователя и программы). G>Строил. Ничего сверхъестественного нету. jquery в зубы и вперед.
G>>>Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight.
GZ>>Это то, с чем пришлось столкнуться на практике. А по факту можно придумать еще кучу. G>Чтобы не возникало разногласий объясняю: я говорию про бизнес приложения, где работает больше одного пользователя одновременно.
Вы как-то слишком ограниченно и узко смотрите сквозь призму только своего опыта. Вот тебе GlebZ говорит, что веб-приложения чисто технологически проигрывают тольстым клиентам, а ты совершенно про другое поешь, о чем-то о своем. Вот я щас тоже занимаюсь бизнес приложениеми, клиент у нас толстый, был бы веб, мы бы повесились сразу, точнее не прошли бы стадию внедрения. Т.к. запросы там такие, что веб точно не покатит, операционистам, нужно очень быстро вбивать разные данные, искать, редактировать. И это без трогания мыши, т.к. это отвлекает очень сильно.
Надо же четко видеть грань, где подходит веб-приложение, где RIA, где толстый клиент и мне кажется, что одно не вытеснит все остальное, никогда.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, shrecher, Вы писали:
S>А зачем desktop C#? Чем C++ и QT не подходит?
Я сорву покровы — C++ подходит даже для Web!
CGI наше фсио!
И даже более! Для CGI не нужен даже С++, подходит plain old C!
(На самом деле, веб-проекты можно писать даже на ассемблере, но до этих кругов посвящения очень далеко.)
Здравствуйте, Odi$$ey, Вы писали:
OE>основная проблема толстого клиента не в ноотбуке, а в необходимости обновления/отката обновлений строго синхронно с серверной частью
Основная проблема не в синхронности обновлений (оно решено в Click Once и еже с ними, да и кастом пишется за предельно короткое время). Основная проблема в наличии самого деплоинга в различное окружение. Особенно для пользователя, который живет в тундре, в чуме, и до него ехать три дня и три ночи. Любая ошибка деплоинга из-за кривой операционки и т.д. — выливается в проблему. А если количество пользователей тысячи!!! Зачастую и Framework ставится криво. Видоизменение деплоинга толстяка, в деплоинг SL или JavaFX — IMHO всего лишь видоизменение проблемы.
Здравствуйте, BulatZiganshin, Вы писали:
G>>Вообще создание приложения сложнее, чем создание компонент.
BZ>ага. давай архитектора с кодером сравнивать
На мой взгляд, кодер в чистом виде — уже некая сферическая абстракция.
Как правило, ситуации таковы — архитектор составляет ТЗ по функционалу и приблизительному дизайну.
Затем выбор конкретной платформы и технологий идет на совместном брейн-ринге.
И последующая реализация этой функциональности полностью up to u.
Как построишь, так и будет.
Разве что где-нибудь уткнешься в что-нибудь технологическое, тогда вновь беспокоится архитектор и итерация повторяется.
Как-то так.
Здравствуйте, gandjustas, Вы писали:
E>>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее*
Проблема в том, что WinForms использует горазда меньше нативных технологий. Уверен, что вам в каждой форме не приходиться писать на WinAPI. Тогда как разработчику Asp.Net приходиться использовать и понимать всю технологию разработки: html, javascript, css, кроссбраузерность, http-протокол. Средний asp.net'чик уже должен знать LifeCycle страницы, разбираться в вопросах безопастности не только sql-inject, но и в уникальных только для веб словах wrong-params, xss и т.д. А умение концентрировать все знания в одном месте — стоит денег...
Здравствуйте, cattle.coder, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
E>>>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее*
CC>Проблема в том, что WinForms использует горазда меньше нативных технологий. Уверен, что вам в каждой форме не приходиться писать на WinAPI. Тогда как разработчику Asp.Net приходиться использовать и понимать всю технологию разработки: html, javascript, css, кроссбраузерность, http-протокол. Средний asp.net'чик уже должен знать LifeCycle страницы, разбираться в вопросах безопастности не только sql-inject, но и в уникальных только для веб словах wrong-params, xss и т.д. А умение концентрировать все знания в одном месте — стоит денег...
На самом деле, это разделение WinForms vs. ASP.NET developers выглядит, как разделение плотников на тех, кто работает молотком и тех, кто топором..
Здравствуйте, gandjustas, Вы писали:
GZ>>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться. G>Для длительных бизнес-транзакций лучше не хранить стостояние в памяти приложения, а использовать какой-либо явный процесс (WF например) с сохранением состояния в БД или другом внешнем носителе.
Чаще проще и дешевле — хранить именно в приложении. G>К интерфейсу это мало отношения имеет.
Ты строил интуитивный интерфейс на вебе?(для справки, коренным отличием интуитивного, является возможность удобных для пользователя быстрых, часто повторяемых действий с некоторыми ответвлениями, которые чаще всего сопровождаются диалогами(которые в свою очередь реализованы на уровне HTML из рук вон плохо), быстрыми клавишами, и вообще плотным взаимодействием пользователя и программы).
G>Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight.
Добавлю. А также:
Ресурсоемких операций.
Операций связанных с безопасностью.
Операций связанных с графикой(как то сканирование, и разл. граф редакторы).
Операций связанных с окружением пользователя (меня умиляет что Microsoft для шарепоинта, поддержку оного вделали в офис, но это отнюдь не все редакторы)
Это то, с чем пришлось столкнуться на практике. А по факту можно придумать еще кучу.
Здравствуйте, cattle.coder, Вы писали:
GZ>>Идеологии совершенно разные. CC>Да одинаковая в общем то идеология — срубить бабла на том, что хочет клиент.
А ты думал что смысл в том чтобы бабки тебе отвалить?
CC>Подходы разные, конечные библиотечки немного другие... Все мы пользуемся и молотками и пилами и другими программерскими инструментами. Если сравнивать со столярами, то скажем так: Win.Form это те кто делает мебель из пластика, Asp.Net это те кто делает из дерева и камня. Все те же шпингалеты и саморезы. Но с деревом горазда проще накосячить, знать для этого нужно больше, руки иметь прямее.
Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу.
Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы)
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, gandjustas, Вы писали:
G>>Подумал G>>1)Непостоянное соединение — огромная проблема G>>2)Использование ресурсов компа — редко возникает, реально один пример — неудобно использовать сканер.
Y>Плохо подумали, ключевые моменты упускаете. Основное, это возможность делать почти любое GUI без каких-либо ограничений и специфики веба в виде request-response.
Это как раз не является ограничением. Ajax и DHTML позволяют сделать с интерфейсом все. Если нужны совсем красивости, то есть SL\Flash.
Y>Да и просто банально программировать гораздо приятнее, нежели на аццкой смеси HTML/CSS/JS/jQuery...
Это сильно субъективное мнение.
G>>А чего такого они хотят? Y>Грубо говоря, толстого клиента хотят, либо RIA.
Ну так сделайте им RIA и навсегда похороните проблемы с деплоем клиентских мест.
G>>Да ну? И чего же не хватает? Y>Да я разве вспомню щас, старый уже, память совсем не та Помню, не хватало, простых элементарных контролов и даже сторонних платных нормальных не было. Из рассмотрения выпал очень быстро, а я больше возлагал надежды на qooxdoo, но производительность у него
Ну конкретнее. Контрол могли бы и сами написать, благо делается это элементарно.
G>>Моежет уже SL 3 начинать обкатывать. Y>
Не надо так скептически относится, зарелизят SL 3 через год-полтора, как раз к выходу N+2 версии вашего продукта. Вы к тому времени уже будете иметь немалый опыт в этой технологии.
Здравствуйте, AndrewVK, Вы писали:
Y>>2. Веб им как раз таки нужен был, т.к. они работают в системе из разных точек мира. AVK>Ну и что? TCP/IP не только браузер можетиспользовать.
Ух ты! А я и не знал!
Y>> Офисы по всей России. Куча народу могут быть в командировках AVK>Без ноутбуков?
Представьте себе, представьте себе, зелене... тьфу, всмысле могут. В конце концов, в ТЗ они сами хотели веб, и получили веб
Вообще, забавная история с этими заказчиками, впервые у меня такое, хотя это и оффтопик Добавил я им в табличку колонку дополнительную, а она у них, с их разрешением экрана перестала влезать по горизонтали, скроллинг появлялся. Так вот, как думаете, что они сделали? Нет, они меня не попросили, чтобы я ширину колонок меньше сделал, все бы влезло. Они тупо в головном офисе всем поставили широкоэкранные мониторы
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, gandjustas, Вы писали:
S>>>Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень. G>>Не очень понимаю к чему ты клонишь. Каждый раз капчу писать с нуля? G>>Если "мерить в капчах", то пока CGI\C программист делает капчу, ASP.NET программист сдает уже второй проект.
BZ>просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам
Те кто используют капчи не занимаются только использованием капчей.
Вообще создание приложения сложнее, чем создание компонент.
Здравствуйте, gandjustas, Вы писали:
GZ>>Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу. G>Это как раз гораздо лучше ложится на концепцию бизнес-операций.
Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
GZ>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF)
Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически. Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
GZ>>>Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу. G>>Это как раз гораздо лучше ложится на концепцию бизнес-операций. GZ>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
Для длительных бизнес-транзакций лучше не хранить стостояние в памяти приложения, а использовать какой-либо явный процесс (WF например) с сохранением состояния в БД или другом внешнем носителе.
К интерфейсу это мало отношения имеет.
GZ>>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF) GZ>Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически.
Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight.
GZ>Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Не дам, я ссылки не храню.
Здравствуйте, AndrewVK, Вы писали:
Y>>Кстати, параллельно веду как раз таки веб-проект, среду документооборота на ASP.NET WebForms, я устал говорить заказчикам, что, то что они хотят невозможно в принципе из-за специфики веба
AVK>Знакомая картина. Сначала впарят заказчику не нужный ему веб, а потом объясняют, почему то что он хочет "невозможно в принципе".
1. Впаривал не я, проект мне достался по наследству.
2. Веб им как раз таки нужен был, т.к. они работают в системе из разных точек мира. Офисы по всей России. Куча народу могут быть в командировках и доступ к системе нужен обязательно.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну и что? TCP/IP не только браузер можетиспользовать. Y>> Офисы по всей России. Куча народу могут быть в командировках AVK>Без ноутбуков?
основная проблема толстого клиента не в ноотбуке, а в необходимости обновления/отката обновлений строго синхронно с серверной частью
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ну и что? TCP/IP не только браузер можетиспользовать. Y>>> Офисы по всей России. Куча народу могут быть в командировках AVK>>Без ноутбуков?
OE>основная проблема толстого клиента не в ноотбуке, а в необходимости обновления/отката обновлений строго синхронно с серверной частью
а в чем тут проблема ?
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, Ellin, Вы писали:
E>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее*
Веб сейчас гораздо больше востребован, чем десктоп.
Вообще говоря сейчас на вебе (HTML+CSS+JS) можно сделать все, что не требует навороченной графики.
А с помощью SL 3 можно в вебе и графику сделать.
Кроме того для десктопа давно существует WPF. WinForms реально востребован только там, где без него не обойтись — MMC, OBA и под Mono.
Полноценный Win интерфейс лучше делать на WPF.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Ellin, Вы писали: E>>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее* G>Веб сейчас гораздо больше востребован, чем десктоп.
именно зп выше? И долго такое еще продержится? Мне кажется, что у тех кто занимается вебом перспектив меньше... ну... как у тех кто делфи занимается за это и доплачивают. Или я не прав?
С точки зрения нервотрепки в вебе или десктопе сложнее?
Здравствуйте, Ellin, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Ellin, Вы писали: E>>>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее* G>>Веб сейчас гораздо больше востребован, чем десктоп. E>именно зп выше?
Уровень ЗП зависит в первую очередь от конторы. В среднем да, для ASP.NET зп повыше будет, но совсем немного.
E>И долго такое еще продержится? Мне кажется, что у тех кто занимается вебом перспектив меньше... ну... как у тех кто делфи занимается за это и доплачивают. Или я не прав?
Наверное неправ, учитывая сколько сейчас MS делает для развития веба на .NET (ASP.NET, Silverlight, Azure итп)
E>С точки зрения нервотрепки в вебе или десктопе сложнее?
Это уже зависит от менеджера и заказчиков.
Самый хреновый вариант когда от ASP.NET программиста требуют еще версткой и дизайном заниматься.
Здравствуйте, Ellin, Вы писали:
E>Сам C# WinForms разработчик. Так смотрю, что ASP.NET больше получают... из-за чего? В чем парадокс? Или это у соседей трава всегда зеленее*
Здравствуйте, gandjustas, Вы писали:
E>>И долго такое еще продержится? Мне кажется, что у тех кто занимается вебом перспектив меньше... ну... как у тех кто делфи занимается за это и доплачивают. Или я не прав? G>Наверное неправ, учитывая сколько сейчас MS делает для развития веба на .NET (ASP.NET, Silverlight, Azure итп)
Мне кажется, что все совсем наоборот — все десктопные приложения и Shell операционных систем унифицируется с веб.
E>>С точки зрения нервотрепки в вебе или десктопе сложнее? G>Это уже зависит от менеджера и заказчиков. G>Самый хреновый вариант когда от ASP.NET программиста требуют еще версткой и дизайном заниматься.
Ну, таковы симптомы времени.
Know Your HTML
The more you explore the depths of jQuery, the more you understand the importance of knowing in detail the HTML you're working with. ASP.NET server controls tend to hide the structure of the HTML they output. On the other hand, server controls were just introduced to let developers focus on declarative attributes rather than HTML details. Years of experience proved this was not always the right approach.
Today, you do need to keep your HTML under total control for accessibility, styling, and conformance to XHTML. Incidentally, this fact establishes a subtle link between jQuery and the ASP.NET MVC framework. And it is no coincidence that the ASP.NET MVC framework includes the latest version of jQuery in the package.
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, shrecher, Вы писали:
S>>А зачем desktop C#? Чем C++ и QT не подходит?
SA>Я сорву покровы — C++ подходит даже для Web! SA>CGI наше фсио! SA>И даже более! Для CGI не нужен даже С++, подходит plain old C! SA>(На самом деле, веб-проекты можно писать даже на ассемблере, но до этих кругов посвящения очень далеко.)
Не надо ерничать. Не все в мире Web и C#. Как раз это mainstream, тут поток и полно уже готовых решений, программистов, дешевых офшорных консалтеров из ЮВА, Индии и Китая. Эти направления превращаются в дешёвый товар массового потребления, соответственно, и удешевление труда программиста.
Нужно искать уникальные или редкие направления. Как раз "plain old C" или asm частенько очень нужен, и те компании готовы платить очень неплохо, т.к. нет переизбытка кандидатов.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, StandAlone, Вы писали:
SA>>Здравствуйте, shrecher, Вы писали:
S>>>А зачем desktop C#? Чем C++ и QT не подходит?
SA>>Я сорву покровы — C++ подходит даже для Web! SA>>CGI наше фсио! SA>>И даже более! Для CGI не нужен даже С++, подходит plain old C! SA>>(На самом деле, веб-проекты можно писать даже на ассемблере, но до этих кругов посвящения очень далеко.)
S>Не надо ерничать. Не все в мире Web и C#. Как раз это mainstream, тут поток и полно уже готовых решений, программистов, дешевых офшорных консалтеров из ЮВА, Индии и Китая. Эти направления превращаются в дешёвый товар массового потребления, соответственно, и удешевление труда программиста.
Разве? С увеличением спроса растет цена — закон рынка.
Другое дело что для здач где требуется выскоая квалификация на низкоуровневых языках, на высокоуровневом языке достаточно скопипастить одну строчку и из какого-нибудь примера.
Поэтому для задач одного уровня программисту на высокоуровневом языке платят меньше.
S>Нужно искать уникальные или редкие направления. Как раз "plain old C" или asm частенько очень нужен, и те компании готовы платить очень неплохо, т.к. нет переизбытка кандидатов.
"Частенько" это в 0.001% случаев?
С трудом могу представить реальную задачу где необходим асм, кроме писания сильно системного софта.
Даже шейдеры пишутся на HLSL, а не на ассемблере.
Вот в C потребность повыше, там где нужен нативный код или интероп без С не обойтись.
Здравствуйте, StandAlone, Вы писали:
SA>На самом деле, это разделение WinForms vs. ASP.NET developers выглядит, как разделение плотников на тех, кто работает молотком и тех, кто топором..
Идеологии совершенно разные.
Здравствуйте, GlebZ, Вы писали:
GZ>Идеологии совершенно разные.
Да одинаковая в общем то идеология — срубить бабла на том, что хочет клиент. Подходы разные, конечные библиотечки немного другие... Все мы пользуемся и молотками и пилами и другими программерскими инструментами. Если сравнивать со столярами, то скажем так: Win.Form это те кто делает мебель из пластика, Asp.Net это те кто делает из дерева и камня. Все те же шпингалеты и саморезы. Но с деревом горазда проще накосячить, знать для этого нужно больше, руки иметь прямее.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, StandAlone, Вы писали:
SA>>На самом деле, это разделение WinForms vs. ASP.NET developers выглядит, как разделение плотников на тех, кто работает молотком и тех, кто топором.. GZ>Идеологии совершенно разные.
Таки несомненно правильная мысль высказана выше! Действительно, идеология молотка — забивать, скажем даже — заколачивать! А идеология топора — стругать, рубить. В таком вот аксепте.
С ужасом жду того момента, когда понадобится идеология дрели или лучковой пилы...
Хотя, впрочем, строили же великолепные строения без единого гвоздя!
Писали же как-то сайты на CGI ( гугл, блин, со своей пикасой — upload.cgi)
Здравствуйте, gandjustas, Вы писали:
G>Разве? С увеличением спроса растет цена — закон рынка. G>Другое дело что для здач где требуется выскоая квалификация на низкоуровневых языках, на высокоуровневом языке достаточно скопипастить одну строчку и из какого-нибудь примера. G>Поэтому для задач одного уровня программисту на высокоуровневом языке платят меньше.
Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень. Нет, возможно $1200 это круто в среднем по России, но как-то для малова-то для потенциально хорошего спеца.
G>С трудом могу представить реальную задачу где необходим асм, кроме писания сильно системного софта.
К примеру IT-безопасность: дезасемблирование, анализ протоколов. Тут надо мозги. Кстати, одна из самых востребованных областей.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Разве? С увеличением спроса растет цена — закон рынка. G>>Другое дело что для здач где требуется выскоая квалификация на низкоуровневых языках, на высокоуровневом языке достаточно скопипастить одну строчку и из какого-нибудь примера. G>>Поэтому для задач одного уровня программисту на высокоуровневом языке платят меньше.
S>Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень.
Не очень понимаю к чему ты клонишь. Каждый раз капчу писать с нуля?
Если "мерить в капчах", то пока CGI\C программист делает капчу, ASP.NET программист сдает уже второй проект.
G>>С трудом могу представить реальную задачу где необходим асм, кроме писания сильно системного софта. S>К примеру IT-безопасность: дезасемблирование, анализ протоколов. Тут надо мозги. Кстати, одна из самых востребованных областей.
Для анализа протоколов асм не нужен. Насчет востребованности дизассемблирования у меня есть сомнения. Покажите вакансии где требуется дизасемблирование.
Здравствуйте, GlebZ, Вы писали:
GZ>Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу.
Это как раз гораздо лучше ложится на концепцию бизнес-операций.
GZ>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы)
Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF)
Здравствуйте, gandjustas, Вы писали:
S>>Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень. G>Не очень понимаю к чему ты клонишь. Каждый раз капчу писать с нуля? G>Если "мерить в капчах", то пока CGI\C программист делает капчу, ASP.NET программист сдает уже второй проект.
просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам
Здравствуйте, senglory, Вы писали:
S>Здравствуйте, shrecher, Вы писали:
S>>К примеру IT-безопасность: дезасемблирование, анализ протоколов. Тут надо мозги. Кстати, одна из самых востребованных областей.
S>Где востребованных?
Because of the worldwide financial crisis, the firm expects spending on technology by enterprise companies to grow by just 2.6 percent next year compared with 2008.
G>Для анализа протоколов асм не нужен. Насчет востребованности дизассемблирования у меня есть сомнения. Покажите вакансии где требуется дизасемблирование.
Здравствуйте, StandAlone, Вы писали:
SA>Писали же как-то сайты на CGI ( гугл, блин, со своей пикасой — upload.cgi)
Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php.
Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется.
CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
Это безотносительно наличия/отсутствия фреймворка и реально из чего этот cgi испечён (пёрл, си/си с крестиками или ассемблер). Это совершенно другой вопрос.
Прогресс ушел в сторону более простых средств (с точки зрения функционал/затраты на производство).
Примерно так.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Ну это только лаборатория касперского.
S>Да, но ты посмотри как они развиваются и расширяются ...
G>>А еще парочку контор, не AV направленности?
S>http://www.agnitum.ru/about/job/profile.php S>http://www.infowatch.ru/Vedrazr
S>Можешь еще поискать "intrusion prevention system", "firewall".
Там активно используется asm? Сильно сомневаюсь.
Всяческие анализаторы (как и любой алгоритмически сложный код) гораздо выгоднее писать на явзяках высокого уровня и переходить на более низкий уровень только из соображений быстродействия.
Ограничение сильные действуют для кода в режиме ядра, так только С, даже с++ с трудом работает.
А прогресс тем временем движется в направлении выноса некоторых ядерных функций в user-mode (в семерке что-тотакое придумали), таким образом все больший простор открывается для использования высокоуровневых средств в системном программировании.
"Вирусный аналитик". Совершенно гиблая профессия, чисто для восторженных вчерашних и нынешних студентов, фанатиков кода с горящими красным глазами.
Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
Здравствуйте, WPooh, Вы писали:
WP>Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php. WP>Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется. WP>CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Меры против взлома?
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, WPooh, Вы писали:
WP>>Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php. WP>>Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется. WP>>CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
SA>Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Вряд ли там php, вероятнее всего fastcgi + python\c++ с самописным фреймворком
SA>Меры против взлома?
Здравствуйте, StandAlone, Вы писали:
SA>Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Это большая военная тайна. У них NDA, разве они расскажут.
Подозреваю, что там фарма на самом деле. Урлу, как обычно, для совместимости оставляют неизменной.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, shrecher, Вы писали:
G>>>Для анализа протоколов асм не нужен. Насчет востребованности дизассемблирования у меня есть сомнения. Покажите вакансии где требуется дизасемблирование.
S>>http://www.kaspersky.ru/vacancies?dept=151517973
S>>http://www.kaspersky.ru/vacancies?vacid=156056584
SA>"Вирусный аналитик". Совершенно гиблая профессия, чисто для восторженных вчерашних и нынешних студентов, фанатиков кода с горящими красным глазами.
Какая разница для фанатиков или уровновешенных кодеров? Главное, что платят и востребованы и этому нет конца-края.
SA>Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
С/С++ аппаратно зависимый язык поэтому всегда неплохо знать какой код он генерит. Кстати, на мобильных платформах, которые в стадии еще разработки, копиляторы генерят код с ошибками, поэтому порой приходится читать сам асм и разбирать почему не пашет.
Здравствуйте, gandjustas, Вы писали:
BZ>>просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам G>Те кто используют капчи не занимаются только использованием капчей.
но большинство-то из них занимаются достаточно простыми вещами.
G>Вообще создание приложения сложнее, чем создание компонент.
Здравствуйте, shrecher, Вы писали:
S>Какая разница для фанатиков или уровновешенных кодеров? Главное, что платят и востребованы и этому нет конца-края.
Платят? Килобакс в зубы и будь доволен. Никуда ты с подводной лодки не денешься.
Востребованы? Дай бог, если в десятке мест по всей России.
А разница огромная. Создавая что-то новое, ты постоянно развиваешь системное мышление, интеллект, обучаешься приемам и подходам.
Ковыряясь в дебрях бинарей, всего этого не получить.
SA>>Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
S>С/С++ аппаратно зависимый язык поэтому всегда неплохо знать какой код он генерит. Кстати, на мобильных платформах, которые в стадии еще разработки, копиляторы генерят код с ошибками, поэтому порой приходится читать сам асм и разбирать почему не пашет.
Когда приходится разбираться с тем, какой код куда генерится, это верный признак того, что парой уровней абстракции выше допущена серьезнейшая ошибка.
Занятие это, возможно, и нужное. Но серьезным его назвать нельзя.
Здравствуйте, GlebZ, Вы писали:
G>>Это как раз гораздо лучше ложится на концепцию бизнес-операций. GZ>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
Для этого придумано масса всего, включая сохранение состояния в БД.
GZ>>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF) GZ>Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически. Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Покане могут. Но технологии движутся вперед стремительно, и это можно только приветствовать.
Дабы не быть голословным : ribbon-like UI веб-приложения, уже давно реальность.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, gandjustas, Вы писали:
BZ>>>просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам G>>Те кто используют капчи не занимаются только использованием капчей. BZ>но большинство-то из них занимаются достаточно простыми вещами.
Давно хочу спросить о статистических показателях по этому вопросу
G>>Вообще создание приложения сложнее, чем создание компонент. BZ>ага. давай архитектора с кодером сравнивать
Нет, здесь дело не в этом. Дело в том, что требования разные. Писателям компонент нужно предоставить определенный список фич — свойств/методов/событий для людей, разбирающихся в программировании. Поэтому требования к юзабилити здесь гораздо слабже, нежели в конечных приложениях. У меня вот так оказывалось, что в итоге приходилось писать собственные контролы/библиотеки/хелперы. Потому что конкретному заказчику нужен свой бизнесс, такой, какой удобен ему и его работникам, считающим, что системный блок — это процессор. Нередко требования этого бизнесса таковы, что просто собрать прогу как конструктор ну соооовсем не получается. Так что все эти сравнения некорректны по-любому. Сложность везде есть, но везде она своя.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
GZ>>>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться. G>>Для длительных бизнес-транзакций лучше не хранить стостояние в памяти приложения, а использовать какой-либо явный процесс (WF например) с сохранением состояния в БД или другом внешнем носителе. GZ>Чаще проще и дешевле — хранить именно в приложении.
Если надо проще и дешеве, то это отлично и вебе решается. (клиентсвое состояние — viewstate, серверное состояние — session state).
Явное сохранение состояния кстати хорошо влияет на структурирование логики.
G>>К интерфейсу это мало отношения имеет. GZ>Ты строил интуитивный интерфейс на вебе?(для справки, коренным отличием интуитивного, является возможность удобных для пользователя быстрых, часто повторяемых действий с некоторыми ответвлениями, которые чаще всего сопровождаются диалогами(которые в свою очередь реализованы на уровне HTML из рук вон плохо), быстрыми клавишами, и вообще плотным взаимодействием пользователя и программы).
Строил. Ничего сверхъестественного нету. jquery в зубы и вперед.
G>>Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight. GZ>Добавлю. А также: GZ>Ресурсоемких операций.
Ресурсоемкие операции на клиенте в бизнес-приложениях — моветон.
GZ>Операций связанных с безопасностью.
Тем более лучше на сервере.
GZ>Операций связанных с графикой(как то сканирование, и разл. граф редакторы).
Flash\Silverlight, со сканированием действительно траблы.
GZ>Это то, с чем пришлось столкнуться на практике. А по факту можно придумать еще кучу.
Чтобы не возникало разногласий объясняю: я говорию про бизнес приложения, где работает больше одного пользователя одновременно.
Здравствуйте, yumi, Вы писали:
Y>Вы как-то слишком ограниченно и узко смотрите сквозь призму только своего опыта. Вот тебе GlebZ говорит, что веб-приложения чисто технологически проигрывают тольстым клиентам, а ты совершенно про другое поешь, о чем-то о своем.
И что за "чисто-технологические" ограничения есть для веба при разработке бизнес-приложений?
Y>Вот я щас тоже занимаюсь бизнес приложениеми, клиент у нас толстый, был бы веб, мы бы повесились сразу, точнее не прошли бы стадию внедрения. Т.к. запросы там такие, что веб точно не покатит, операционистам, нужно очень быстро вбивать разные данные, искать, редактировать. И это без трогания мыши, т.к. это отвлекает очень сильно.
Вы не можете табордер настроить на странице?
Если не хотите или не можете сами писать интерфейс, то вполне можете взять один из кучи фреймворков, которые делают то что надо.
Если вам уж совсем навороченный интрфейс надо, то берите Silverlight.
Y>Надо же четко видеть грань, где подходит веб-приложение, где RIA, где толстый клиент и мне кажется, что одно не вытеснит все остальное, никогда.
Чтобы эту грань видеть надо хотябы немного позаниматься созданием сложных интерфейсов под web. окажется что эта грань гораздо дальше чем вы предполагаете.
Здравствуйте, gandjustas, Вы писали:
G>И что за "чисто-технологические" ограничения есть для веба при разработке бизнес-приложений?
А самому подумать?
Y>>Вот я щас тоже занимаюсь бизнес приложениеми, клиент у нас толстый, был бы веб, мы бы повесились сразу, точнее не прошли бы стадию внедрения. Т.к. запросы там такие, что веб точно не покатит, операционистам, нужно очень быстро вбивать разные данные, искать, редактировать. И это без трогания мыши, т.к. это отвлекает очень сильно. G>Вы не можете табордер настроить на странице?
представь себе, можем ну хотя бы на простой вопрос можешь ответить? как мне в вебе пользоваться хот-кеями? ась?
Кстати, параллельно веду как раз таки веб-проект, среду документооборота на ASP.NET WebForms, я устал говорить заказчикам, что, то что они хотят невозможно в принципе из-за специфики веба
G>Если не хотите или не можете сами писать интерфейс, то вполне можете взять один из кучи фреймворков, которые делают то что надо.
Ой, много чего перепробовали, всякие там, dojo, qooxdoo, ... ну не помогают костыли, никак...
G>Если вам уж совсем навороченный интрфейс надо, то берите Silverlight.
Тоже, по ряду причин не подошел, технология в целом сырая и отсутствие нужных компонентов/контролов, тоже напрягает.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, gandjustas, Вы писали:
G>>И что за "чисто-технологические" ограничения есть для веба при разработке бизнес-приложений?
Y>А самому подумать?
Подумал
1)Непостоянное соединение — огромная проблема
2)Использование ресурсов компа — редко возникает, реально один пример — неудобно использовать сканер.
Y>>>Вот я щас тоже занимаюсь бизнес приложениеми, клиент у нас толстый, был бы веб, мы бы повесились сразу, точнее не прошли бы стадию внедрения. Т.к. запросы там такие, что веб точно не покатит, операционистам, нужно очень быстро вбивать разные данные, искать, редактировать. И это без трогания мыши, т.к. это отвлекает очень сильно. G>>Вы не можете табордер настроить на странице?
Y> представь себе, можем ну хотя бы на простой вопрос можешь ответить? как мне в вебе пользоваться хот-кеями? ась?
Не в курсе, сам созданием keyboard-only UI даже на десктопе не занимался.
Минута гугления дала такие результаты: http://code.google.com/p/js-hotkeys/ http://www.openjs.com/scripts/events/keyboard_shortcuts/
Y>Кстати, параллельно веду как раз таки веб-проект, среду документооборота на ASP.NET WebForms, я устал говорить заказчикам, что, то что они хотят невозможно в принципе из-за специфики веба
А чего такого они хотят?
G>>Если не хотите или не можете сами писать интерфейс, то вполне можете взять один из кучи фреймворков, которые делают то что надо. Y>Ой, много чего перепробовали, всякие там, dojo, qooxdoo, ... ну не помогают костыли, никак...
Наверное вы не умеете их готовить
G>>Если вам уж совсем навороченный интрфейс надо, то берите Silverlight. Y>Тоже, по ряду причин не подошел, технология в целом сырая и отсутствие нужных компонентов/контролов, тоже напрягает.
Да ну? И чего же не хватает?
Моежет уже SL 3 начинать обкатывать.
Здравствуйте, gandjustas, Вы писали:
G>Подумал G>1)Непостоянное соединение — огромная проблема G>2)Использование ресурсов компа — редко возникает, реально один пример — неудобно использовать сканер.
Плохо подумали, ключевые моменты упускаете. Основное, это возможность делать почти любое GUI без каких-либо ограничений и специфики веба в виде request-response. Да и просто банально программировать гораздо приятнее, нежели на аццкой смеси HTML/CSS/JS/jQuery...
G>А чего такого они хотят?
Грубо говоря, толстого клиента хотят, либо RIA.
G>Да ну? И чего же не хватает?
Да я разве вспомню щас, старый уже, память совсем не та Помню, не хватало, простых элементарных контролов и даже сторонних платных нормальных не было. Из рассмотрения выпал очень быстро, а я больше возлагал надежды на qooxdoo, но производительность у него
G>Моежет уже SL 3 начинать обкатывать.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
G>Кроме того для десктопа давно существует WPF. WinForms реально востребован только там, где без него не обойтись — MMC, OBA и под Mono. G>Полноценный Win интерфейс лучше делать на WPF.
А по скорости на старом железе оно не будет уступать WinForms ?
Здравствуйте, Dog, Вы писали:
G>>Кроме того для десктопа давно существует WPF. WinForms реально востребован только там, где без него не обойтись — MMC, OBA и под Mono. G>>Полноценный Win интерфейс лучше делать на WPF. Dog>А по скорости на старом железе оно не будет уступать WinForms ?
Смотря насколько старом.
Без графического ускорителя точно уступать будет.
G>>>Полноценный Win интерфейс лучше делать на WPF. Dog>>А по скорости на старом железе оно не будет уступать WinForms ? G>Смотря насколько старом. G>Без графического ускорителя точно уступать будет.
Хорошо, а с каким минимум графическим ускорителем уступать не будет ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, yumi, Вы писали:
Y>>Кстати, параллельно веду как раз таки веб-проект, среду документооборота на ASP.NET WebForms, я устал говорить заказчикам, что, то что они хотят невозможно в принципе из-за специфики веба
AVK>Знакомая картина. Сначала впарят заказчику не нужный ему веб, а потом объясняют, почему то что он хочет "невозможно в принципе".
"невозможно в принципе" чаще всего означает нежелание разработчиков разбиратся с проблемой и способами её решения.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
G>>Ну так сделайте им RIA и навсегда похороните проблемы с деплоем клиентских мест. GZ>RIA — это панацея?
Смотря для чего. Для многих случаев очень даже панацея.
Здравствуйте, Odi$$ey, Вы писали:
OE>основная проблема толстого клиента не в ноотбуке, а в необходимости обновления/отката обновлений строго синхронно с серверной частью
Это совсем не проблема, если моск включать, особенно в корпоративных решениях.
... << RSDN@Home 1.2.0 alpha 4 rev. 1207 on Windows Vista 6.1.7100.0>>
Здравствуйте, yumi, Вы писали:
Y>Вообще, забавная история с этими заказчиками, впервые у меня такое, хотя это и оффтопик Добавил я им в табличку колонку дополнительную, а она у них, с их разрешением экрана перестала влезать по горизонтали, скроллинг появлялся. Так вот, как думаете, что они сделали? Нет, они меня не попросили, чтобы я ширину колонок меньше сделал, все бы влезло. Они тупо в головном офисе всем поставили широкоэкранные мониторы
Вот ты смеёшься, а у нас заказчики требуют работы backend'ов проектов на кластере, несмотря на то, что ставят на один сервер. На мой вопрос, а нафига, они отвечают "чтобы можно было масштабировать систему без вашего участия". Дело в том, что труд программистов тут дорог, а железо дёшево. Вывод напрашивается сам собой...
