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

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

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

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

А что есть база?
Знание спецификации языков программирования?
Знание алгоритмов и теории графов?
Знание наизусть методов разных API?

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

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

DD>>Проверить "знания" можно легко, только корреляции с умением выполнять работу не будет.
M>Если требуются академические знания, то да, смысла нет. Поэтому задание носит исключительно прикладной характер. Или вы считаете что оно не жизненно и слишком надумано?

Это мы уже не задание обсуждаем, а другую тему, ваше желание "проверить знания".

DD>>А умение выполнять работу проверить будет сложно. Единственный способ — тест-драйв.
M>В конечном итоге да, тут согласен, но важно кто туда попадет.

А это уже как вам повезет. Ваша карма, так сказать.

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

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

E>>Здравствуйте, Mazenrab, Вы писали:
E>>Чет у меня сомнение в том, что вам нужно именно это. Вам что, серьезно нужен человек, который раз в день хреначит вот такие примитивнейшие базы с нуля на скорость, причем во внерабочее время?
M>Нет, нам не нужен человек который делает такие базы. У нас база есть. Не такая простая, но суть то не в этом. Десктопное приложение у нас имеется. Нам нужен человек который сделает к нашей системе хорошую, адекватную веб-морду.

Это может сделать любой студент, который хоть раз писал на asp.net и каком-нить jquery. Я думаю для такой задачи проще будет обратиться к фрилансерам, чем нанимать человека.
И вместо "тестовых заданий" просто попросите пример работ показать.

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

M>Угу, идея хорошая, спасибо. А что скажете насчет самого задания? Адекватное? Мне нужен человек который хорошо работает на стыке ASP и JavaScript со всякими приблудами а-ля Ajax.
Это вам видней, удекватное или нет . Удовлетворитесь решением — хорошо . Там ведь на практике у разработчика даже не это важно — важно насколько он будет быстро вникатьв дебри чужого кода, как будет с ним работать, как быстро он умеет гуглить, как хорошо он понимает то, что от него просят, насколько ответственно подходит к работе, насколько самостоятелен, насколько коммуникабелен (не в смысле что анекдоты травить будет, а в смысле насколько не боится спросить то, что сэкономит время всем, и насколько не ленится помогать остальным).
Лично я там ничего сверхсложного не вижу, думаю даже сам бы справился без проблем, не смотря на то, что JavaScript знаю только в общих чертах, с Ajax работал только через очень высокоуровневые фреймворки. Если только юзабилити какое не станете требовать . Соответственно и у тех, кто на этом руку набил более, чем я, проблем вообще быть не должно. Самый геморой — это начальная настройка всего проекта, начальные рисования формочек и тому подобное, начальное создание базы и тому подобное.

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

G>Это может сделать любой студент, который хоть раз писал на asp.net и каком-нить jquery. Я думаю для такой задачи проще будет обратиться к фрилансерам, чем нанимать человека.
G>И вместо "тестовых заданий" просто попросите пример работ показать.

Это как? Вот вам пароль от внутрикорпоративного портала, вот пароль от vpn чтоб на шарепоинт зайти, так вот, форма апрува платежей и спама клиентов — это я делал, можете проверить как оно работает.

M> Нам нужен человек который сделает к нашей системе хорошую, адекватную веб-морду.

Так и пишите — требуем портфолио из адекватных веб-морд.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

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

G>>Это может сделать любой студент, который хоть раз писал на asp.net и каком-нить jquery. Я думаю для такой задачи проще будет обратиться к фрилансерам, чем нанимать человека.
G>>И вместо "тестовых заданий" просто попросите пример работ показать.

YKU>Это как? Вот вам пароль от внутрикорпоративного портала, вот пароль от vpn чтоб на шарепоинт зайти, так вот, форма апрува платежей и спама клиентов — это я делал, можете проверить как оно работает.

А ты сначала тему прочитай. Нужна типичная базоморда, а не "корпоративный портал".

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


M>Ищется человек на з/п 70-80 т.р.
M>Что скажете по поводу тестового задания? Много-немного? Сколько бы вы на него ориентировочно потратили времени?

есть план задач, пусть и делает, справиться, пряники + трудоустройство

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

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

Пишу, как работодатель. Данняя метода работает. Причем работает не только в отношении программистов.

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

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

E>>Здравствуйте, Mazenrab, Вы писали:
E>>Чет у меня сомнение в том, что вам нужно именно это. Вам что, серьезно нужен человек, который раз в день хреначит вот такие примитивнейшие базы с нуля на скорость, причем во внерабочее время?
M>Нет, нам не нужен человек который делает такие базы. У нас база есть. Не такая простая, но суть то не в этом. Десктопное приложение у нас имеется. Нам нужен человек который сделает к нашей системе хорошую, адекватную веб-морду.

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

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

YKU>>Это как? Вот вам пароль от внутрикорпоративного портала, вот пароль от vpn чтоб на шарепоинт зайти, так вот, форма апрува платежей и спама клиентов — это я делал, можете проверить как оно работает.

G>А ты сначала тему прочитай. Нужна типичная базоморда, а не "корпоративный портал".

А ты сначала мой пост прочитай. То, что я написал — это типичная базаморда. Просто зачастую в весьма причудливом месте сидит.

M>Что скажете по поводу тестового задания? Много-немного? Сколько бы вы на него ориентировочно потратили времени?
Примитив. По времени займет пару дней.
Почему так долго? Необходимо обсудить все детали, чтобы понять, что Вы ожидаете получить.
В противном случае это будет еще одно простое решение, которое никак не выделится из списка решений других кандидатов, и я просто зря потрачу пару часов своего времени на кодирование.
Это задание выполнит любой студент, а значит мои шансы уменьшаются.
Стал бы делать, если бы на момент получения задание был без работы.

Я бы не пошел на такую позицию, даже если бы задания не было.
Я против применения веб в карпоративных приложения.
Веб имеет преимущество по сравнению с десктоп (WinForms или WPF): для работы с приложением не нужно устанавливать ПО на компьютер, кроме интернет браузера + неважно какая OC у конечного пользователя, одно и тоже Веб приложение можно гонять на разных OC. Это важно если пользователь за день посещает 20 сайтов. Если при каждом посещении ему нужно будет устанавливать дополнительное ПО, это будет уныло.
В корпоративных приложениях, как правило у всех пользователей стоит одна OC (чаще всего Windows), затраты на установку одного десктоп приложения на фиксированное количество компьютеров минимальны. Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).
То есть преимущество веб технологий в карпоративных приложениях не нужны. Но если вы все-таки будете использовать веб в корпоративном приложении, то Вам придется платить на это ненужное преимущество. Разработка одного и тоже функционала под Web сложнее и дороже, чем под десктоп.

Здравствуйте, igor-booch, Вы писали:

IB>Я бы не пошел на такую позицию, даже если бы задания не было.
IB>Я против применения веб в карпоративных приложения.
IB>Веб имеет преимущество по сравнению с десктоп (WinForms или WPF): для работы с приложением не нужно устанавливать ПО на компьютер, кроме интернет браузера + неважно какая OC у конечного пользователя, одно и тоже Веб приложение можно гонять на разных OC. Это важно если пользователь за день посещает 20 сайтов. Если при каждом посещении ему нужно будет устанавливать дополнительное ПО, это будет уныло.
Ты не поверишь. Пользователь и так будет 20 сайтов посещать. Нафига еще какой-то софт ставить.

IB>В корпоративных приложениях, как правило у всех пользователей стоит одна OC (чаще всего Windows), затраты на установку одного десктоп приложения на фиксированное количество компьютеров минимальны.
"Как прависло" не означает "всегда". Поставили мак кому-то и все. С вебом проблем нет, заработает также. А с десктопом дофига.


IB>Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).

За день? Когда 1000 клиентов? Сомневаюсь.

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

В терхзвенном случае веб не сложнее десктопа. Кроме того у веба есть офигенное преимущество — ссылки. Ссылку можно сохранить и передать кому-нибудь. Покажешь как такое в десктопе сделать?

G>Ты не поверишь. Пользователь и так будет 20 сайтов посещать. Нафига еще какой-то софт ставить.
А нас что планируется использовать одновременно 20 корпоративных веб приложений? Корпоративное приложение одно. Софт поставить надо 1 раз. Посещать каждый день будем один и тот же сайт.



G>"Как прависло" не означает "всегда". Поставили мак кому-то и все.
Согласен, если нужен и Mac OS и Windows и ..., то лучше Web.


G>С вебом проблем нет, заработает также. А с десктопом дофига.
G>В терхзвенном случае веб не сложнее десктопа.
Каких проблем дофига?
Я имел ввиду, что в случае Web
1) javascript слаботипизированный, динамический, его сложнее отлаживать, чем статическую логику
2) UI логика разделяется между javascript и северной страницей, в десктоп единый ЯП и единое место для логики: классы
3) web по природе stateless, это накладывает дополнительные сложности
4) web выполняется в ограниченном контексте безопасности, это может усложнить разработку. Ограниченный контекст безопасности нужен если опять же если вы посещаете 20 сайтов за день, которые могут быть и вредоносными. Но нет смысла не доверять корпоративному приложению, так как оно одно и его разрабатывают и поддерживают доверенные люди.
Подробней здесь http://ru.wikipedia.org/wiki/Rich_Internet_Application#.D0.9D.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D1.82.D0.BA.D0.B8


IB>>Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).
G>За день? Когда 1000 клиентов? Сомневаюсь.
Да хоть 1000000. ClickOnce располагает бинарники десктоп приложения на веб сервере. Можно разместить приложения в шаренной папке. Написать приложение которой при добавлении в шаренную папку новой версии приложения, копирует его на комп пользователя, 1-2 дня

G>Кроме того у веба есть офигенное преимущество — ссылки. Ссылку можно сохранить и передать кому-нибудь. Покажешь как такое в десктопе сделать?
Покажу XBAP. Ну если позарез нужны нужны ссылки и XBAP не катит, то без веб не обойтись.



Короче у каждой технологии (Web и десктоп) есть своя область применения, свои достоинства и недостатки. Какой Вы видите область применения, достоинства и недостатки Web? По Вашим словам можно подумать что Web — серебряная пуля и всегда хуже чем десктоп.

Здравствуйте, igor-booch, Вы писали:

G>>Ты не поверишь. Пользователь и так будет 20 сайтов посещать. Нафига еще какой-то софт ставить.
IB>А нас что планируется использовать одновременно 20 корпоративных веб приложений?
Причем тут корпоративное приложение? Гугл, сайты партнеров, поставщиков итп. Даже если пользователь не будет сидеть в одноклассниках, то все равно будет много сайтов открывать.

IB>Корпоративное приложение одно. Софт поставить надо 1 раз. Посещать каждый день будем один и тот же сайт.
Да ну? Как минимум 2: почта и erp. А может быть еще и портал, так что точно больше одного



G>>"Как прависло" не означает "всегда". Поставили мак кому-то и все.
IB>Согласен, если нужен и Mac OS и Windows и ..., то лучше Web.
А как ты заранее узнаешь? Приедт завтра начальник и захочет чтобы на его новом iPad работало приложение. Причем это очень частый кейс.
Даже поэтому стоит уже сейчас по-максимуму отказаться от десктопной разработки.


G>>С вебом проблем нет, заработает также. А с десктопом дофига.
G>>В терхзвенном случае веб не сложнее десктопа.
IB>Каких проблем дофига?
IB>Я имел ввиду, что в случае Web
IB>1) javascript слаботипизированный, динамический, его сложнее отлаживать, чем статическую логику
Клиентского кода, по сравнению с серверным будет совсем мизер. JS кстати отлаживать проще, это делается прямо в брузере, без дополнительных инструментов.
Если совсем не можешь JS осилить, то есть Script# или GWT.

IB>2) UI логика разделяется между javascript и северной страницей, в десктоп единый ЯП и единое место для логики: классы
В трехзвенном то случае? Обычный клиент-сервер не рассматриваем, так как при том же уровне безопасности и разграничения доступа он сложнее, чем трехзвенка.


IB>3) web по природе stateless, это накладывает дополнительные сложности
Любой stateless легко превращается в stateful, а наоборот — нет.

IB>4) web выполняется в ограниченном контексте безопасности, это может усложнить разработку. Ограниченный контекст безопасности нужен если опять же если вы посещаете 20 сайтов за день, которые могут быть и вредоносными. Но нет смысла не доверять корпоративному приложению, так как оно одно и его разрабатывают и поддерживают доверенные люди.
Ты серьезно? Я сколько видел серьезных корпоративных сетей, там пользователи не работают с правами локального админа. Как раз ограниченный контекст безопасности позволяет заставить приложение всегда работать в таких условиях и не будет эффекта "work on my machine". А на сервере делай что хочешь, там хоть fulltrust.



IB>>>Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).
G>>За день? Когда 1000 клиентов? Сомневаюсь.
IB>Да хоть 1000000. ClickOnce располагает бинарники десктоп приложения на веб сервере. Можно разместить приложения в шаренной папке. Написать приложение которой при добавлении в шаренную папку новой версии приложения, копирует его на комп пользователя, 1-2 дня
Я вообще-то про ручное размещение. ClickOnce ничем не лучше веба. Fulltrust требует админских привелегий, которые пользователям никто не даст, а в остальном какие преимущества? А никаких.
Только привязка к ОС, что во время развития мобильных устройств губительно.

G>>Кроме того у веба есть офигенное преимущество — ссылки. Ссылку можно сохранить и передать кому-нибудь. Покажешь как такое в десктопе сделать?
IB>Покажу XBAP. Ну если позарез нужны нужны ссылки и XBAP не катит, то без веб не обойтись.
Так XBAP это недовеб. Тот же браузер, тот же ограниченный контекст безопасности. Уж лучше SL последний, он OOB умеет.



IB>Короче у каждой технологии (Web и десктоп) есть своя область применения, свои достоинства и недостатки. Какой Вы видите область применения, достоинства и недостатки Web? По Вашим словам можно подумать что Web — серебряная пуля и всегда хуже чем десктоп.
Не серебрянная пуля, но для корпоративного софта всегда лучше, чем десктоп.

1) Кроссплатформенность
2) Ссылки
3) Stateless (это дает возможность обновлять софт без отключения клиентов)
4) Динамичность — добавить страницу с мешапом на сайт ниче не стоит, добавить форму в клиентское приложение стоит дофига.

G>Причем тут корпоративное приложение?
При том что обсуждается корпоративное приложение по распределению водителей по заявкам. Если нужно зайти на сайт партнера, в инет магазин, на форум, никто не запрещает делать это через браузер, так так это все не относится к данному корпоративному приложению.



G>>>"Как прависло" не означает "всегда". Поставили мак кому-то и все.
IB>>Согласен, если нужен и Mac OS и Windows и ..., то лучше Web.
G>А как ты заранее узнаешь? Приедт завтра начальник и захочет чтобы на его новом iPad работало приложение. Причем это очень частый кейс.
G>Даже поэтому стоит уже сейчас по-максимуму отказаться от десктопной разработки.
Ну если начальник далек от IT, он может еще и не такое придумать, тут и веб может не спасти. У компании должна быть долгосрочная IT стратегия, направленная на минимизацию расходов и максимизацию выгод от IT.


IB>>1) javascript слаботипизированный, динамический, его сложнее отлаживать, чем статическую логику
G>Клиентского кода, по сравнению с серверным будет совсем мизер.
Незнаю может у тебя другой опыт. По моему опыту чем богаче web приложение, чем более отзывчивое (меньше перезагрузок страниц), чем больше требования к производительности, тем больше нужно использовать технологий типа AJAX и всяческих ухищрений, чем больше клиентский код. Может для не RIA приложений клиентского кода будет мало.

G>JS кстати отлаживать проще, это делается прямо в брузере, без дополнительных инструментов.
JS сложнее отлаживать потому-что те ошибки, которые в статических ЯП ловятся при компиляции, в JS можно поймать только в runtime.

G>Если совсем не можешь JS осилить, то есть Script# или GWT.
Script# или GWT не юзал, но не думаю, что будет проще чем с JS.

IB>>2) UI логика разделяется между javascript и северной страницей, в десктоп единый ЯП и единое место для логики: классы
G>В трехзвенном то случае? Обычный клиент-сервер не рассматриваем, так как при том же уровне безопасности и разграничения доступа он сложнее, чем трехзвенка.
В десктоп логика уровня представления (Presentation layer) записана на одном ЯП и в одном месте в классах. На web логика уровня представления разделяется между javascript и северной страницей. Чтобы сократить количество уровней, конечно можно запихнуть в северную страницу бизнес логику (Logic (Business) layer), но тогда мы скорей всего смешаем Presentation layer и Logic (Business) layer. Можно использовать что-то типа ASP.NET MVC, но (по моему опыту) он больше усложняет, чем упрощает. Использовал ASP.NET MVC 3 года назад, может сейчас что-то изменилось.


IB>>3) web по природе stateless, это накладывает дополнительные сложности
G>Любой stateless легко превращается в stateful, а наоборот — нет.
Превращается, но это превращение стоит денег и времени разработчиков. Десктоп по природе statefull, ему превращения-извращения не нужны.

IB>>4) web выполняется в ограниченном контексте безопасности, это может усложнить разработку. Ограниченный контекст безопасности нужен если опять же если вы посещаете 20 сайтов за день, которые могут быть и вредоносными. Но нет смысла не доверять корпоративному приложению, так как оно одно и его разрабатывают и поддерживают доверенные люди.
G>Ты серьезно? Я сколько видел серьезных корпоративных сетей, там пользователи не работают с правами локального админа. Как раз ограниченный контекст безопасности позволяет заставить приложение всегда работать в таких условиях и не будет эффекта "work on my machine". А на сервере делай что хочешь, там хоть fulltrust.
Приложение корпоративное, его создают и поддерживаю доверенные люди. От кого защищаться? Могу предположить: web более подвержен хакерским атакам. А если дать десктопному приложению fulltrust, то не надо "заставлять приложение всегда работать в таких условиях", оно и так будет работать. Эффект "work on my machine" наблюдал в веб. У пользователей разные версии браузеров, разные настройки (той же безопасности).



IB>>>>Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).
G>>>За день? Когда 1000 клиентов? Сомневаюсь.
IB>>Да хоть 1000000. ClickOnce располагает бинарники десктоп приложения на веб сервере. Можно разместить приложения в шаренной папке. Написать приложение которой при добавлении в шаренную папку новой версии приложения, копирует его на комп пользователя, 1-2 дня
G>Я вообще-то про ручное размещение. ClickOnce ничем не лучше веба.
Не лучше, но и не хуже. Также залил в одном месте и все клиентские машины при следующей перезагрузке приложения получили новую версию.


G>>>Кроме того у веба есть офигенное преимущество — ссылки. Ссылку можно сохранить и передать кому-нибудь. Покажешь как такое в десктопе сделать?
IB>>Покажу XBAP. Ну если позарез нужны нужны ссылки и XBAP не катит, то без веб не обойтись.
G>Так XBAP это недовеб. Тот же браузер, тот же ограниченный контекст безопасности. Уж лучше SL последний, он OOB умеет.
Да, XBAP это недовеб, точнее это десктопное приложение исполняющееся в браузере в partial trust. Ты спросил как на десктопе сделать ссылки. Я тебе показал.



G>Не серебрянная пуля, но для корпоративного софта всегда лучше, чем десктоп.

G>1) Кроссплатформенность
Для корпоративного софта в этом отношении web будет "всегда лучше", если никто никогда не принимает долгосрочной корпоративной IT политики по использованию единой ОС, то есть всегда нужна поддержка всех ОС.


G>2) Ссылки
Для корпоративного софта в этом отношении web будет "всегда лучше", если для корпоративного софта всегда нужны ссылки.

G>3) Stateless (это дает возможность обновлять софт без отключения клиентов)
Для корпоративного софта в этом отношении web будет "всегда лучше", если для корпоративного софта никогда не нужен statefull. Если используется Stateless превращенный в statefull, то не всегда есть "возможность обновлять софт без отключения клиентов". Может измениться формат и семантика данных состояния.

G>4) Динамичность — добавить страницу с мешапом на сайт ниче не стоит, добавить форму в клиентское приложение стоит дофига.
Добавил форму в десктоп приложение, задеплоил на ClickOnce или скопировал в шареную папку, вот и все. Стоимость в web и десктоп одинакова.

Здравствуйте, igor-booch, Вы писали:

G>>>>"Как прависло" не означает "всегда". Поставили мак кому-то и все.
IB>>>Согласен, если нужен и Mac OS и Windows и ..., то лучше Web.
G>>А как ты заранее узнаешь? Приедт завтра начальник и захочет чтобы на его новом iPad работало приложение. Причем это очень частый кейс.
G>>Даже поэтому стоит уже сейчас по-максимуму отказаться от десктопной разработки.
IB>Ну если начальник далек от IT, он может еще и не такое придумать, тут и веб может не спасти. У компании должна быть долгосрочная IT стратегия, направленная на минимизацию расходов и максимизацию выгод от IT.

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


IB>>>1) javascript слаботипизированный, динамический, его сложнее отлаживать, чем статическую логику
G>>Клиентского кода, по сравнению с серверным будет совсем мизер.
IB>Незнаю может у тебя другой опыт. По моему опыту чем богаче web приложение, чем более отзывчивое (меньше перезагрузок страниц), чем больше требования к производительности, тем больше нужно использовать технологий типа AJAX и всяческих ухищрений, чем больше клиентский код. Может для не RIA приложений клиентского кода будет мало.
Все равно это мизер по сравнению с серверным кодом. Например сколько нужно JS написать чтобы сделать AJAX базоморду на ASP.NET если у тебя есть SQL Server? Ноль.
Даже на чистом JS выводить гриды можно с помощью 5 строк.

G>>JS кстати отлаживать проще, это делается прямо в брузере, без дополнительных инструментов.
IB>JS сложнее отлаживать потому-что те ошибки, которые в статических ЯП ловятся при компиляции, в JS можно поймать только в runtime.
Ну вообще-то большинство опечаток можно ловить в JS не запуская. Есть вполне компиляторы для JS, такие штуки как JSLint.

G>>Если совсем не можешь JS осилить, то есть Script# или GWT.
IB>Script# или GWT не юзал, но не думаю, что будет проще чем с JS.
Зря так думаешь.

IB>>>2) UI логика разделяется между javascript и северной страницей, в десктоп единый ЯП и единое место для логики: классы
G>>В трехзвенном то случае? Обычный клиент-сервер не рассматриваем, так как при том же уровне безопасности и разграничения доступа он сложнее, чем трехзвенка.
IB>В десктоп логика уровня представления (Presentation layer) записана на одном ЯП и в одном месте в классах. На web логика уровня представления разделяется между javascript и северной страницей. Чтобы сократить количество уровней, конечно можно запихнуть в северную страницу бизнес логику (Logic (Business) layer), но тогда мы скорей всего смешаем Presentation layer и Logic (Business) layer. Можно использовать что-то типа ASP.NET MVC, но (по моему опыту) он больше усложняет, чем упрощает. Использовал ASP.NET MVC 3 года назад, может сейчас что-то изменилось.
Не понял о чем ты. В вебе MVС, на десктопе MVVM или на худой конец MVP, все это PL, меняется только view. Бизнес-логика в любом случае на сервере.

В mvc 3 легко сделать так чтобы отдавался HTML в случае если вызывается <url> и JSON если вызывается <url>.json. Логика контроллера при этом не поменяется. А на клиенте можно хоть Ajax, хоть сайт без ajax вообще, хоть десктопный клиент. Но в последнем толку мало.

IB>>>3) web по природе stateless, это накладывает дополнительные сложности
G>>Любой stateless легко превращается в stateful, а наоборот — нет.
IB>Превращается, но это превращение стоит денег и времени разработчиков. Десктоп по природе statefull, ему превращения-извращения не нужны.
А с чего ты взял что statefull это хорошо? Это как раз плохо, state нужен только там где он нужен и не более того. На сервере не нужен точно.

IB>>>4) web выполняется в ограниченном контексте безопасности, это может усложнить разработку. Ограниченный контекст безопасности нужен если опять же если вы посещаете 20 сайтов за день, которые могут быть и вредоносными. Но нет смысла не доверять корпоративному приложению, так как оно одно и его разрабатывают и поддерживают доверенные люди.
G>>Ты серьезно? Я сколько видел серьезных корпоративных сетей, там пользователи не работают с правами локального админа. Как раз ограниченный контекст безопасности позволяет заставить приложение всегда работать в таких условиях и не будет эффекта "work on my machine". А на сервере делай что хочешь, там хоть fulltrust.
IB>Приложение корпоративное, его создают и поддерживаю доверенные люди. От кого защищаться?

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

IB>Могу предположить: web более подвержен хакерским атакам.
Веб, который смотрит наружу — да. Двузвенка никогда наружу не смотрит, потому что сразу пароль от базы уплывет.

IB>А если дать десктопному приложению fulltrust, то не надо "заставлять приложение всегда работать в таких условиях", оно и так будет работать.
А если не дать?

IB>Эффект "work on my machine" наблюдал в веб. У пользователей разные версии браузеров, разные настройки (той же безопасности).
Знал бы ты сколько я видел приложений, которые внезапно перестали работать не под админом, тупо потому что в HKLM писать пытались или Program Files. По сравнению с ними проблемы с настройками браузера в вебе не видно в микроскоп.



IB>>>>>Современные технологии позволяют делать это централизовано (ClickOnce или можно самому сделать за день).
G>>>>За день? Когда 1000 клиентов? Сомневаюсь.
IB>>>Да хоть 1000000. ClickOnce располагает бинарники десктоп приложения на веб сервере. Можно разместить приложения в шаренной папке. Написать приложение которой при добавлении в шаренную папку новой версии приложения, копирует его на комп пользователя, 1-2 дня
G>>Я вообще-то про ручное размещение. ClickOnce ничем не лучше веба.
IB>Не лучше, но и не хуже. Также залил в одном месте и все клиентские машины при следующей перезагрузке приложения получили новую версию.
Хуже потому что ссылок нет.


G>>>>Кроме того у веба есть офигенное преимущество — ссылки. Ссылку можно сохранить и передать кому-нибудь. Покажешь как такое в десктопе сделать?
IB>>>Покажу XBAP. Ну если позарез нужны нужны ссылки и XBAP не катит, то без веб не обойтись.
G>>Так XBAP это недовеб. Тот же браузер, тот же ограниченный контекст безопасности. Уж лучше SL последний, он OOB умеет.
IB>Да, XBAP это недовеб, точнее это десктопное приложение исполняющееся в браузере в partial trust. Ты спросил как на десктопе сделать ссылки. Я тебе показал.
А чем оно тогда отличается от веба с точки зрения пользователя? Тем что .NET FW требует? Я же говорю — недовеб, уж лучше веб делать.



G>>Не серебрянная пуля, но для корпоративного софта всегда лучше, чем десктоп.

G>>1) Кроссплатформенность
IB>Для корпоративного софта в этом отношении web будет "всегда лучше", если никто никогда не принимает долгосрочной корпоративной IT политики по использованию единой ОС, то есть всегда нужна поддержка всех ОС.
Даже если кто-то примет, что с того? Если ты хочешь ориентироваться на широкий класс заказчиков — используй веб.


G>>2) Ссылки
IB>Для корпоративного софта в этом отношении web будет "всегда лучше", если для корпоративного софта всегда нужны ссылки.
Ссылки вообще всегда нужны. Они взаимодействие улучшают. Как например пользователь может сказать коллеге чтобы он ознакомился к некоторым документом или посмотрел назначение конкретного водителя? Ссылки могут ничего не улучшать только в очень простых приложениях.

G>>3) Stateless (это дает возможность обновлять софт без отключения клиентов)
IB>Для корпоративного софта в этом отношении web будет "всегда лучше", если для корпоративного софта никогда не нужен statefull. Если используется Stateless превращенный в statefull, то не всегда есть "возможность обновлять софт без отключения клиентов". Может измениться формат и семантика данных состояния.
Неправильно формулируешь вопрос. Вопрос в том что statefull это только представление (даже не обязательно логика представления). Больше нигде он не нужен. Вот ты открыл клиент и работаешь с ним, тут на сервере приложение обновилось и тебе надо перезапустить. Ты в браузере тупо жмешь F5 и работает, а с десктопом нужно полный цикл остановка-запуск пройти. Кроме того, так как нет ссылок, ты теряешь контекст работы.

G>>4) Динамичность — добавить страницу с мешапом на сайт ниче не стоит, добавить форму в клиентское приложение стоит дофига.
IB>Добавил форму в десктоп приложение, задеплоил на ClickOnce или скопировал в шареную папку, вот и все.
Ниифга, надо еще чтобы все перезапустили клиент и чтобы перешли на новую форму, а как ты о ней скажешь если у тебя ссылок нет?

IB>Стоимость в web и десктоп одинакова.
Создание страницы не обязательно ведет к редеплою приложения, а в десктопе обязательно. Я именно об этом и говорил.

Здравствуйте, igor-booch, Вы писали:

IB>Можно использовать что-то типа ASP.NET MVC, но (по моему опыту) он больше усложняет, чем упрощает. Использовал ASP.NET MVC 3 года назад, может сейчас что-то изменилось.

Наверное, стоит воздержаться от советования, если в технологии не разбираешься.

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

M>Ищется человек на з/п 70-80 т.р.
M>Что скажете по поводу тестового задания? Много-немного? Сколько бы вы на него ориентировочно потратили времени?

Задание нормальное, давать для человека, который хочет 70-80 тыс — вполне адекватно. Отсеятся ненужные категории людей — джуниоров, т.к. по стилю все будет понятно, и продвинутых чуваков, которые стоят больше 80 тыр, т.к. такие пройдут мимо.
Потратил бы час-два.