Во-первых, это не помешает ей пользоваться.
Во-вторых, совет был дан на предмет пойти и покопаться, модифицировав решение для своих нужд. Кто мешает избавиться от картинок и сделать так, как Вы хотите. Вы же не пишете КАК должна выглядеть виртуальная клавиатура в текстовом исполнении.
Очевидно, Вы не хотите этого делать а ждете, пока Вам принесут это в готовом виде. Учитывая, что это не форум разработчиков и что скрипт клавиатуры в ТЕКСТОВОМ исполнении не является типовой задачей, очень уж распространенной в Сети - это Вы зря надеетесь.
Вообще, любое требование должно быть разумным. Лично мне интересно - зачем это может быть нужно вообще? Для сотового телефона или КПК без тачскрина это не нужно, а для тех что с тачскрином - там свое в комплекте с операционкой есть. Для обычных браузеров - нет проблем сделать Flash или предупреждение об отключенных картинках (или еще что-то придумать).
Это круто, но это флэш (+ javascript). Если javascript еще есть вероятность что будет работать при выключенных картинках, то ActiveX чаще всего - нет. Я так думаю для тех платформ, где картинок нет вообще и javascript будет проблемой, а там где выключены картинки но постоянно - там админы и ActiveX вырезают на корню.
Идешь на http://www.translate.ru/text.asp?lang=ru и смотришь как реализовано там. Если подходит - берешь и переделываешь под свои нужды. Если не подходит - формулируешь задачу точнее и идешь в форум каяться.
Хорошо, может быть продавали, я ж не знаю. А имел в виду примерно такое "если бы вы имели 100 продаж какого-либо софта в месяц на запад...". Ну Вы понимаете, между единичными продажами и потоком дистанция огромного размера с позиции саппорта.
Мужики, да не нойте вы. Всем тяжело, не одни вы такие. Это вы еще на запад не продавали ничего, вот когда с Тайваня обиженные китайцы не владеющие английским будут на вас бочки катить, вот тогда это будет на что жаловаться. Нужно просто хорошо делать работу.
Правило №1: Служба поддержки не имеет права обижаться на пользователей, пусть они 1000 раз неправы.
Правило №2: Если пользователь неправ, мудак, свинья - смотри п.1.
Stels71, в том то и вся проблема, что Вы по сути может быть даже где-то правы. Сам работаю в поддержке и сталкиваюсь с разными ситуациями, в том числе когда пишут письма не по делу, без описания сути вопроса, с наездами, с ломанием русского языка, чисто из-за лени не хотят прочесть даже то, что написано большими буквами и т.п.
Но поймите, как только Вы встаете из-за рабочего места и идете куда-то в качестве клиента Вы начинаете вести себя точно так же. Самые любимые темы у нас в стране - ругаться по поводу низкой культуры обслуживания ("я же клиент а меня в ж.. не целуют!") и наоборот говорить что все юзеры тупые и вести себя не умеют ("за такие деньги этот к... хочет еще чтобы ему что-то сделали дополнительно!").
Это неправильно. Правильно любить всех юзеров, каждого в отдельности. Тогда у нас будут нормально обслуживать и в ресторанах, и в аэропортах и в саппорте хостинга.
Я думаю, что это довод. Но не слишком сильный в данной ситуации. Из собственного опыта - давно и "конкретно" работаю с саппортом одной очень известной хостинг-компании (как пример, таких примеров можно привести и из другой области несколько). Пока там конкретные люди со мной общались хорошо - все было отлично. Все запросы выполнялись хорошо и вовремя, мне было приятно привозить деньги отдавать, поскольку мне улыбались и все такое. Как только персонал на аккаунтинге сменился - впечатление от компании резко поменялось. При этом как компания работала "хорошо" так и работает. Понимаете? Поэтому я вполне верю, что топикстартер мог отработать по ряду проектов без проблем, ему все нравилось, а потом вот случилась такая незадача.
Так что не нужно никого из клиентов посылать никогда. Мало ли, земля круглая... Вдруг он миллионером станет, а ты у него будешь в тендере участвовать.
Ну хамство не хамство, но в определенном роде некомпетентность проявляется уже в вашем ответе на претензии Топикстартера. Пусть клиент не по правилам, в нерабочее время написал Вам письмо. Пусть он откуда то узнал о Ваших секретных правилах лицензирования и сделал неверные выводы. Но он клиент и имеет право обращаться в службу поддержки тогда когда у него возникает проблема. Вы же понимаете, что у клиента по сути нормальные претензии - он не ожидал что ему выставят такой большой счет, он не ожидал что будут какие-то логотипы внизу его сайта, он недоволен тем, что не смог легко и просто связаться с вами. Почему он должен искать кого-то по ICQ в конце-концов, напрягаться из-за ваших же недоработок?
Поэтому квалифицированная тех.поддержка бы извинилась в топике перед клиентом за то, что ему вообще пришлось терпеть какие-то неудобства. А оправдываться по пунктам всегда приводит только к негативу пользователей, но никак не к укреплению имиджа.
Интересно, гугл тоже со всеми договаривается или они как-то иначе решают проблемы подобного плана? Я понимаю что у них в общемировом масштабе больше трафика и на него сложнее повлиять, но и "бойцов" пробивающих ЭдСенс наверняка тоже немало.
Тьфу ты, это Вы издеваетесь. Кто ж спорит то с этим? Это очевидно.
Вообще-то, я начал с того, что задачу по выяснению что именно тормозит в веб-приложении нужно разбить на части и соответственно все промерить в нужных точках. А Вы мне пишете какие-то очевидные вещи чисто теоретического плана. У ТС же не гигабайтные страницы отдаются, я надеюсь.
Тут вопрос нужно было ставить иначе - что именно показывают счетчики времени по коду и можно ли на них полагаться при нагрузочном тестировании, или по крайней мере какие выводы из них делать нужно, а какие - нет.
Короче надо завязывать с этим базаром, я чувствую. Кому-то помогать всегда себе дороже выходит.
ЗЫ: В любом случае спасибо за оппонирование, кое-чего освежилось в памяти.
Эээ... вообще-то если дополнительная нагрузка, создаваемая такими приложениями мала по отношению к основной, то и данные директа так же будут мало подвержены изменениям в процентном соотношении, насколько я понимаю. Так что это они зря.
А XML запросы как раз вообще никак на директ не влияют. Не должны.
Что подробнее то? Про архитектуру проекта рассказывать не буду. Назывался AdWatch (и сейчас так называется), кто в теме - знает что это за зверь.
2 ТопикСтартер: вот вам ссылка - может пригодится. http://php.russofile.ru/ru/translate/unsort/chachig_in_php
Да на чем угодно, вы оттестируйте в буферизированном виде и в небуферизированном и приходите с конкретными данными.
Да, идея понятна, но почему Вы считаете, что процесс построения страницы не работает в еще одном отдельном потоке, который просто обрабатывает данные? Он помещает их в определенный межпроцессный буфер, а вот из него уже другой процесс внутри сервера приложения (в нашем примере PHP движок под сервером) будет перегружать данные в сокеты. Именно он уже может ждать пока освободится канал, но он обязан работать независимо от процесса, который формирует данные, поскольку это вообще логически задачи разных слоев архитектуры. Если это не так - это ошибка в архитектуре сервера приложений. Я очень сильно сомневаюсь что найдется такой кривой application сервер, но если Вы можете доказать что он существует экспериментальными данными - давайте, мне самому интересно.
