Автоматически — это только значит, что это уже написано и вам не нужно это реализовывать самому, а всё равно это будет выполняться и проблемы с браузерами решать вам и выполнять при этом финты ушами тоже вам.
Могу привести пример из жизни:
Был у нас заказчик. Попросил он работу с данными в гриде, а так же попросил оставить настройку в конфиге приложения — сколько можно максимально выводить строк в грид. Сказано — сделано… ничего сложного в этом нет.
Мы конечно дали рекомендацию, что максимальное значение не стоит задавать больше двухсот-трёхсот строчек.
Заказчик же (точнее бизнес — заказчик) решил что 200-300 строчек — это не круто, давайте-ка будем выводить несколько тысяч, хоть в этом и не было практической пользы. В хроме и лисе всё продолжало нормально работать при групповых операциях (максимум четыре — пять секунд на типовом PC). А вот IE 6-7 выполнял теже скрипты за 16 минут (8 — около 10 минут). Технический персонал со стороны заказчика понимал, что такое требование — это бред, но бизнес упёрся всё тут.
Мы неделю потратили на различные эксперименты на взаимодействия сервера и браузера, чтобы разделить функционал так чтобы вывести работу на оптилные пять секунд.
Возможно, пессимист и вижу всегда самое плохое и только проблемы, которые возможны теоретически… но так меня научила жизнь.
Я достаточно чётко себе представляю для чего нужна данная библиотека (иначе не юзал бы её), да и статью перечитал уже несколько раз.
Скорее всего я просто гоняюсь за призраками прошлого. Когда идёт борьба за каждый переданный с/на клиента килобайт. Когда неосторожное движение скриптом может загнать браузер в стопур из-за того, что он полностью интерпритирует js, а не делает предкомпиляцию… Когда особенность работа js в IE зависит не только от его версии… но и от того как он попал в систему, как это было с IE7 (шел в комплекте с ОС или был поставлен в качестве обновления IE 6).
Ага… а данные откуда берутся по вашему?
К тому же я, если честно, не вижу смысла просто гонять какие-то данные просто по странице, внутри дума и между js-объектами, без сохранения их на сервере.
Да дело не в размере jQuery, хотя он тоже важен.
Дело в передаваемых данных, которые будут постоянно гоняться для поддержания синхронизации, точнее для опроса клиентом сервера.
Связывание — это конечно хорошо, но только на достаточно толстом канале от сервера до пользователя, а если каналчик плохенький GPRS или ещё лучше Dial-Up, то по производительности — это будет издевательством над конечным потребителем.
Не знаю насчет «кошмара для программиста» — я не разработчик под андройд и даже не жаба, но как пользователь могу решительно сказать, что среди приложений под андройд я нашел и использую такие приложения, которые с такой силой интегрируют телефон с сервисами гугл, что аж дух захватывает и насколько я знаю, что такой не возможность на «нехламном» аймобилко и симбиан.
Вообще платежи работаю в три этапа: Сначала чекинг — потом подтверждение — выгрузка реестра в банк, для того чтобы он перевёл деньги.
Мы работаем так:
Ресерв (запрос на возможность проведения и получение дополнительной информации)
Обратно получаем ресервенд (где получаем подтверждение на возможность проведения плюс информацию о том во сколько это обойдётся конкретному пользователю, плюс какие-нибудь комментарии, которые нужно показать пользователю)
Далее спрашиваем пользователя хочет ли он при таких условия, такой платёж. Если он согласен, то мы продолжаем.
Списываем у пользователя средства и отправляем запрос Пурчайс.
И ждём ответа — ПурчайсЭнд, по которому мы закрываем транзакцию у нас.
Далее при накоплении определённой массы платежей мы выгружаем реестр в банк по которому банк уже перечисляет средства по счетам.
Это конечно идеальный вариант есть ещё всякие примочки по борьбе с критическими ситуациями и пропадающими запросами и ответами, но общая схема такая.
Вообще-то два эти два понятия всегда ходят вместе… не будет PR — не будет и маркетинга. Если не пиариться, то и продажи, в случае Apple, вряд ли будут.
Вообще-то зависимость есть :)
Например, Бизнес Apple сильно завязан на фигуре Джобса (я, конечно, считаю, что это не совсем обосновано, так как многое из достижений компании он просто присвоил себе)… далее немного сарказма:
Стив чихает и плохо выглядит — он болен, возможно уйдёт на пеньсию, возможно упадут прибыли компании, следовательно выплат на одну акцию будет меньше, следовательно и стоить она будет меньше.
Стив хитро улыбается, скорее всего Apple что-то замышляет — возможно что-то новенькое… а когда это новенькое выйдет, то миллионы поклонников ринуться покупать, следовательно будут прибыли, скорее всего и выплаты поднимутся… значит акция растёт.
Конечно, приметивненько, но суть я думаю вы уловили.
ну да, это веб-морда eCare-ра тупарылая, в смысле не удобная для использования и сильно тормозит временами, временами в дауне… а временами не хочет пускать с пометкой: «Неверный логин или пароль».
В общем-то статей по .NET от Microsoft на русском достаточно много в сети, а вот о наиболее популярной альтернативе — Mono, достаточно мало. Может кто посоветует ресурс? А то как — то не комфортно иногда делать проект как opensource на препроитарной платформе :)
Вообще платформа, через которую работают вышеописанные сервисы, берет для оператора совсем небольшой процент, просто бы если бы вымпелком брал бы 50 со всех платежей, которые проходят через платформу — данные платежи были бы невыгодны данным сервисам :)
То что вы пишите в статье про печать фотографий и брать за это деньги за счет смс, то, если мне не изменяет память, такая задумка была у Кавказского Мегафона (они хотели поставить специальные аппараты для печать фотографий в курортных городах и загружать на них фотографии с карточек памяти или по блютуз и потом абонент бы вводил свой телефонный номер и ему приходила бы цена и вопрос хочет ли он оплатить, если абонент отвечал положительно, то аппарат распечатывал фотографии и оператор снимать необходимую сумму со счета абонента) несколько лет назад, но они провели исследование и оно показало, что такой вариант не принесёт прибыли, либо средства будут слишком «длинными» для инвестирования.
А на андройд не будет?
А то народ вроде заморочился по поводу портирования Qt (http://code.google.com/p/android-lighthouse/) но не понятно что у них в итоге получится.
Могу привести пример из жизни:
Был у нас заказчик. Попросил он работу с данными в гриде, а так же попросил оставить настройку в конфиге приложения — сколько можно максимально выводить строк в грид. Сказано — сделано… ничего сложного в этом нет.
Мы конечно дали рекомендацию, что максимальное значение не стоит задавать больше двухсот-трёхсот строчек.
Заказчик же (точнее бизнес — заказчик) решил что 200-300 строчек — это не круто, давайте-ка будем выводить несколько тысяч, хоть в этом и не было практической пользы. В хроме и лисе всё продолжало нормально работать при групповых операциях (максимум четыре — пять секунд на типовом PC). А вот IE 6-7 выполнял теже скрипты за 16 минут (8 — около 10 минут). Технический персонал со стороны заказчика понимал, что такое требование — это бред, но бизнес упёрся всё тут.
Мы неделю потратили на различные эксперименты на взаимодействия сервера и браузера, чтобы разделить функционал так чтобы вывести работу на оптилные пять секунд.
Возможно, пессимист и вижу всегда самое плохое и только проблемы, которые возможны теоретически… но так меня научила жизнь.
Скорее всего я просто гоняюсь за призраками прошлого. Когда идёт борьба за каждый переданный с/на клиента килобайт. Когда неосторожное движение скриптом может загнать браузер в стопур из-за того, что он полностью интерпритирует js, а не делает предкомпиляцию… Когда особенность работа js в IE зависит не только от его версии… но и от того как он попал в систему, как это было с IE7 (шел в комплекте с ОС или был поставлен в качестве обновления IE 6).
К тому же я, если честно, не вижу смысла просто гонять какие-то данные просто по странице, внутри дума и между js-объектами, без сохранения их на сервере.
Дело в передаваемых данных, которые будут постоянно гоняться для поддержания синхронизации, точнее для опроса клиентом сервера.
Мы работаем так:
Ресерв (запрос на возможность проведения и получение дополнительной информации)
Обратно получаем ресервенд (где получаем подтверждение на возможность проведения плюс информацию о том во сколько это обойдётся конкретному пользователю, плюс какие-нибудь комментарии, которые нужно показать пользователю)
Далее спрашиваем пользователя хочет ли он при таких условия, такой платёж. Если он согласен, то мы продолжаем.
Списываем у пользователя средства и отправляем запрос Пурчайс.
И ждём ответа — ПурчайсЭнд, по которому мы закрываем транзакцию у нас.
Далее при накоплении определённой массы платежей мы выгружаем реестр в банк по которому банк уже перечисляет средства по счетам.
Это конечно идеальный вариант есть ещё всякие примочки по борьбе с критическими ситуациями и пропадающими запросами и ответами, но общая схема такая.
Например, Бизнес Apple сильно завязан на фигуре Джобса (я, конечно, считаю, что это не совсем обосновано, так как многое из достижений компании он просто присвоил себе)… далее немного сарказма:
Стив чихает и плохо выглядит — он болен, возможно уйдёт на пеньсию, возможно упадут прибыли компании, следовательно выплат на одну акцию будет меньше, следовательно и стоить она будет меньше.
Стив хитро улыбается, скорее всего Apple что-то замышляет — возможно что-то новенькое… а когда это новенькое выйдет, то миллионы поклонников ринуться покупать, следовательно будут прибыли, скорее всего и выплаты поднимутся… значит акция растёт.
Конечно, приметивненько, но суть я думаю вы уловили.
То что вы пишите в статье про печать фотографий и брать за это деньги за счет смс, то, если мне не изменяет память, такая задумка была у Кавказского Мегафона (они хотели поставить специальные аппараты для печать фотографий в курортных городах и загружать на них фотографии с карточек памяти или по блютуз и потом абонент бы вводил свой телефонный номер и ему приходила бы цена и вопрос хочет ли он оплатить, если абонент отвечал положительно, то аппарат распечатывал фотографии и оператор снимать необходимую сумму со счета абонента) несколько лет назад, но они провели исследование и оно показало, что такой вариант не принесёт прибыли, либо средства будут слишком «длинными» для инвестирования.
А то народ вроде заморочился по поводу портирования Qt (http://code.google.com/p/android-lighthouse/) но не понятно что у них в итоге получится.