jkljkljkl: И какой вид примет клава ? Будут отображаться одни буквы , а как же вид кнопок ?
Во-первых, это не помешает ей пользоваться.
Во-вторых, совет был дан на предмет пойти и покопаться, модифицировав решение для своих нужд. Кто мешает избавиться от картинок и сделать так, как Вы хотите. Вы же не пишете КАК должна выглядеть виртуальная клавиатура в текстовом исполнении.
Очевидно, Вы не хотите этого делать а ждете, пока Вам принесут это в готовом виде. Учитывая, что это не форум разработчиков и что скрипт клавиатуры в ТЕКСТОВОМ исполнении не является типовой задачей, очень уж распространенной в Сети - это Вы зря надеетесь.
Вообще, любое требование должно быть разумным. Лично мне интересно - зачем это может быть нужно вообще? Для сотового телефона или КПК без тачскрина это не нужно, а для тех что с тачскрином - там свое в комплекте с операционкой есть. Для обычных браузеров - нет проблем сделать Flash или предупреждение об отключенных картинках (или еще что-то придумать).
ssin: jkljkljkl, вот сдесь почитай , может что-то интересное найдешь
Это круто, но это флэш (+ javascript). Если javascript еще есть вероятность что будет работать при выключенных картинках, то ActiveX чаще всего - нет. Я так думаю для тех платформ, где картинок нет вообще и javascript будет проблемой, а там где выключены картинки но постоянно - там админы и ActiveX вырезают на корню.
Идешь на http://www.translate.ru/text.asp?lang=ru и смотришь как реализовано там. Если подходит - берешь и переделываешь под свои нужды. Если не подходит - формулируешь задачу точнее и идешь в форум каяться.
Амиро: И кто вам сказал, что мы не продавали на запад?
Хорошо, может быть продавали, я ж не знаю. А имел в виду примерно такое "если бы вы имели 100 продаж какого-либо софта в месяц на запад...". Ну Вы понимаете, между единичными продажами и потоком дистанция огромного размера с позиции саппорта.
Амиро: В том то и дело, что есть поддержка, есть менеджеры, звоним и решаем все вопросы или хотя бы пытаемся их решить, так нет же... вместо этого идем в форум и публично оскорбляем компанию, при этом приукрашивая себя и притаптывая соперника. Без предупреждения.
Мужики, да не нойте вы. Всем тяжело, не одни вы такие. Это вы еще на запад не продавали ничего, вот когда с Тайваня обиженные китайцы не владеющие английским будут на вас бочки катить, вот тогда это будет на что жаловаться. Нужно просто хорошо делать работу.
Правило №1: Служба поддержки не имеет права обижаться на пользователей, пусть они 1000 раз неправы.
Правило №2: Если пользователь неправ, мудак, свинья - смотри п.1.
Stels71, в том то и вся проблема, что Вы по сути может быть даже где-то правы. Сам работаю в поддержке и сталкиваюсь с разными ситуациями, в том числе когда пишут письма не по делу, без описания сути вопроса, с наездами, с ломанием русского языка, чисто из-за лени не хотят прочесть даже то, что написано большими буквами и т.п.
Но поймите, как только Вы встаете из-за рабочего места и идете куда-то в качестве клиента Вы начинаете вести себя точно так же. Самые любимые темы у нас в стране - ругаться по поводу низкой культуры обслуживания ("я же клиент а меня в ж.. не целуют!") и наоборот говорить что все юзеры тупые и вести себя не умеют ("за такие деньги этот к... хочет еще чтобы ему что-то сделали дополнительно!").
Это неправильно. Правильно любить всех юзеров, каждого в отдельности. Тогда у нас будут нормально обслуживать и в ресторанах, и в аэропортах и в саппорте хостинга.
Stels71: И второе - я работаю с этими людьми давно и хамства с их стороны не видел ниразу. Бывает, что спорим, но все в рамках этики ведения бизнеса.
Я думаю, что это довод. Но не слишком сильный в данной ситуации. Из собственного опыта - давно и "конкретно" работаю с саппортом одной очень известной хостинг-компании (как пример, таких примеров можно привести и из другой области несколько). Пока там конкретные люди со мной общались хорошо - все было отлично. Все запросы выполнялись хорошо и вовремя, мне было приятно привозить деньги отдавать, поскольку мне улыбались и все такое. Как только персонал на аккаунтинге сменился - впечатление от компании резко поменялось. При этом как компания работала "хорошо" так и работает. Понимаете? Поэтому я вполне верю, что топикстартер мог отработать по ряду проектов без проблем, ему все нравилось, а потом вот случилась такая незадача.
Так что не нужно никого из клиентов посылать никогда. Мало ли, земля круглая... Вдруг он миллионером станет, а ты у него будешь в тендере участвовать.
Ну хамство не хамство, но в определенном роде некомпетентность проявляется уже в вашем ответе на претензии Топикстартера. Пусть клиент не по правилам, в нерабочее время написал Вам письмо. Пусть он откуда то узнал о Ваших секретных правилах лицензирования и сделал неверные выводы. Но он клиент и имеет право обращаться в службу поддержки тогда когда у него возникает проблема. Вы же понимаете, что у клиента по сути нормальные претензии - он не ожидал что ему выставят такой большой счет, он не ожидал что будут какие-то логотипы внизу его сайта, он недоволен тем, что не смог легко и просто связаться с вами. Почему он должен искать кого-то по ICQ в конце-концов, напрягаться из-за ваших же недоработок?
Поэтому квалифицированная тех.поддержка бы извинилась в топике перед клиентом за то, что ему вообще пришлось терпеть какие-то неудобства. А оправдываться по пунктам всегда приводит только к негативу пользователей, но никак не к укреплению имиджа.
Radionov: Кстати, на конференции Сергей Петренко сказал, что, например, для уменьшения этого влияния Яндекс договорился с Семонитором и тот отдает специальный юзерагент, а они его потом исключают из статистики.
Интересно, гугл тоже со всеми договаривается или они как-то иначе решают проблемы подобного плана? Я понимаю что у них в общемировом масштабе больше трафика и на него сложнее повлиять, но и "бойцов" пробивающих ЭдСенс наверняка тоже немало.
Тьфу ты, это Вы издеваетесь. Кто ж спорит то с этим? Это очевидно.
Вообще-то, я начал с того, что задачу по выяснению что именно тормозит в веб-приложении нужно разбить на части и соответственно все промерить в нужных точках. А Вы мне пишете какие-то очевидные вещи чисто теоретического плана. У ТС же не гигабайтные страницы отдаются, я надеюсь.
Тут вопрос нужно было ставить иначе - что именно показывают счетчики времени по коду и можно ли на них полагаться при нагрузочном тестировании, или по крайней мере какие выводы из них делать нужно, а какие - нет.
Короче надо завязывать с этим базаром, я чувствую. Кому-то помогать всегда себе дороже выходит.
ЗЫ: В любом случае спасибо за оппонирование, кое-чего освежилось в памяти.
Radionov: Насколько я понимаю, автоматические запросы запрещены в значительной степени не из-за нагрузки (посмотрите их статистику - таких хрен нагрузишь), а потому что это портит статистику директа.
Эээ... вообще-то если дополнительная нагрузка, создаваемая такими приложениями мала по отношению к основной, то и данные директа так же будут мало подвержены изменениям в процентном соотношении, насколько я понимаю. Так что это они зря.
А XML запросы как раз вообще никак на директ не влияют. Не должны.
Мишган: На псевдо языке можно?
засечь время
записать в вывод 10 мульенов нулей
вывести время
могу на жабе
long t1 = System.currentTimeMillis();
byte[] data = new byte[10*1024*1024];
response.getOutputStream().write(data);
logger.info("Время: "+(System.currentTimeMillis()-t1));
Да на чем угодно, вы оттестируйте в буферизированном виде и в небуферизированном и приходите с конкретными данными.
Мишган: Все верно только не понял почему вешалка?:-)) поток то обсуживающий данного клиента будет 99% времени своего исполнения ожидать доступности канала (т.е ничего не делать)
Да, идея понятна, но почему Вы считаете, что процесс построения страницы не работает в еще одном отдельном потоке, который просто обрабатывает данные? Он помещает их в определенный межпроцессный буфер, а вот из него уже другой процесс внутри сервера приложения (в нашем примере PHP движок под сервером) будет перегружать данные в сокеты. Именно он уже может ждать пока освободится канал, но он обязан работать независимо от процесса, который формирует данные, поскольку это вообще логически задачи разных слоев архитектуры. Если это не так - это ошибка в архитектуре сервера приложений. Я очень сильно сомневаюсь что найдется такой кривой application сервер, но если Вы можете доказать что он существует экспериментальными данными - давайте, мне самому интересно.
И какой вид примет клава ? Будут отображаться одни буквы , а как же вид кнопок ?
Во-первых, это не помешает ей пользоваться.
Во-вторых, совет был дан на предмет пойти и покопаться, модифицировав решение для своих нужд. Кто мешает избавиться от картинок и сделать так, как Вы хотите. Вы же не пишете КАК должна выглядеть виртуальная клавиатура в текстовом исполнении.
Очевидно, Вы не хотите этого делать а ждете, пока Вам принесут это в готовом виде. Учитывая, что это не форум разработчиков и что скрипт клавиатуры в ТЕКСТОВОМ исполнении не является типовой задачей, очень уж распространенной в Сети - это Вы зря надеетесь.
Вообще, любое требование должно быть разумным. Лично мне интересно - зачем это может быть нужно вообще? Для сотового телефона или КПК без тачскрина это не нужно, а для тех что с тачскрином - там свое в комплекте с операционкой есть. Для обычных браузеров - нет проблем сделать Flash или предупреждение об отключенных картинках (или еще что-то придумать).
jkljkljkl, вот сдесь почитай , может что-то интересное найдешь
Это круто, но это флэш (+ 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
На псевдо языке можно?
засечь время
записать в вывод 10 мульенов нулей
вывести время
могу на жабе
long t1 = System.currentTimeMillis();
byte[] data = new byte[10*1024*1024];
response.getOutputStream().write(data);
logger.info("Время: "+(System.currentTimeMillis()-t1));
Да на чем угодно, вы оттестируйте в буферизированном виде и в небуферизированном и приходите с конкретными данными.
Все верно только не понял почему вешалка?:-)) поток то обсуживающий данного клиента будет 99% времени своего исполнения ожидать доступности канала (т.е ничего не делать)
Да, идея понятна, но почему Вы считаете, что процесс построения страницы не работает в еще одном отдельном потоке, который просто обрабатывает данные? Он помещает их в определенный межпроцессный буфер, а вот из него уже другой процесс внутри сервера приложения (в нашем примере PHP движок под сервером) будет перегружать данные в сокеты. Именно он уже может ждать пока освободится канал, но он обязан работать независимо от процесса, который формирует данные, поскольку это вообще логически задачи разных слоев архитектуры. Если это не так - это ошибка в архитектуре сервера приложений. Я очень сильно сомневаюсь что найдется такой кривой application сервер, но если Вы можете доказать что он существует экспериментальными данными - давайте, мне самому интересно.