Отправляется не строка а Buffer, который по сути является низкоуровневой областью памяти (V8 heap).
Он точно не копируется и, как мне кажется, не маршалится. Т.е. потерь нет никаких, в теории.
А если если даже маршалится то это делается через одно memcpy().
Т.е. вне зависимости от числа обращений к файлу в памяти будет хранится только зипованный и обычный буферы, каждый в единственном экземпляре. Который передается по ссылке.
Я не могу представить себе нагрузку, которая может убить ноду на примерно таком коде
var buffer=new Buffer(«bla bla bla… 50K»);
app.get('/',function(req,res){
res.send(buffer);
});
Узкое место у вебсервисов почти всегда — диск. Будет ли работать ngnix быстрее зависит от нагрузки на диск. ngnix, как мне кажется, полюбому mtime проверяет. Т.е. диск грузит.
Ой я тоже несу. При env=development он ничего не кеширует при production — он кеширует и не смотрит на время.
Сверять время не нужно на production. При обновлении ведь его рестартят.
Да и невозможно поскольку в haml, jade, less, sass есть подключаемые файлы и большинство компиляторов не возвращают их список. Даже если бы возвращали, то для показа одного файла могло бы потребоваться получение статистики по 10-20 файлам, что могло тормозить при сильных нагрузках.
Однако, я бы не разбивал адрес и квартиру. Это может сбить с толку людей живущих в частном доме. Хотя нужно пробовать: если при отсутствии этого поля многие забывают ввести квартиру.
З.Ы. Ввел тел +38 063 111 22 33. Поле просветилось красным, но причину ошибки не выдало. Лучше ее вывести в поповере.
Запутано сильно. Метод со свободной формой плох.
0. Сложно. Для далеких от компа людей.
1. Лишнее поле.
2. Дублирование данных.
3. У пользователя появляется дилемма
В общем для продвинутой аудитории, для формы которую пользователь набирает постоянно это терпимо. Для обычных случаев — нет.
Адрес можно сократить до двух полей. Город и Адрес. По дефолту, город определяется автоматически по ip и идет до адреса. ФИО тоже одно поле. Регион нафиг не нужен. Индекс никто не помнит, а если помнят то не вводят.
У вас 14 полей. Вариант без танцев с бубнами это 2 поля на адрес и по одному на фио, тел, мыло и сообщение. Т.е. всего 6 полей.
По скрину видно, что он находит фильтр. Как будто знает, что он есть и где он. Он не ищет его слева.
Единственная причина, которая на ум приходит, это то что он знаком с этим интерфейсом или аналогичным ему.
Вас я ни в чем не обвинял. Причины по которым респондент ранее был знаком с интерфейсом различны. Но своим глазам я верю больше, чем вам.
В вашем примере, человек уже был знаком с интерфейсом. Так что слово «знакомится» не подходит. Это видно из того, что после изначальной фокусировки он сразу ищет боковое меню, хотя в нем нет цветовых раздражителей.
Также видно что он заголовки просматривает.
То что движение зрачка довольно сложное это я лет с 10 знаю, но большинство данных обрабатывает подсознанием.
Я практик. Я не рассуждаю абстракциями типа локуса, когнитивной психологии. Есть несколько решений у каждого решения есть свои плюсы и минусы. Каждое решение нужно проверять хотя бы сценарием (User Story). А то натеотиризировать можно много, например, коммунизм.
Чтобы читать только заголовки, пользователь должен заранее определить точно чего он хочет. Однако, в реальности, пользователь до того как зашел на сайт крайне редко в точности знает какие параметры ему нужны. У пользователей, обычно, до захода на сайт нет плана, в стиле: я буду искать 3-4 звездочный отель с парковкой. Он просматривает большинство пунктов и выбирает подходящий. А не просматривает заголовки только.
Здесь вертикальный с Ajax работает лучше, поскольку пользователь видет большую часть выдачи. И в случае скрола независимого может и искать и просматривать без необходимости скролить.
У вертикального есть преимущества.
1. Он не занимает дополнительного места. Т.е. меньше скролить нужно.
2. Снизу вверх привычнее. Заметьте что все формы сейчас одноколочные. Даже ввод логина и пароля.
3. Если существуют поля ввода строки, то обычно используется только малая их часть (их начало). Поэтому при вертикальном расположении меньше движений мыши и глаза. Сравните
[XXXX_____________________________]
[XXXX_____________________________]
и
[XXXX_____________________________] [XXXX_______________________]
В первом случае глаз не двигаясь и не меняя фокус может прочитать данные в нескольких полях сразу.
4. Человек привык читать вправо-вниз. Сначала строку читает, потом спускается на следующую. При вертикальной от так и делает. При горизонтальной он читает по схеме вправо-вниз-вправо.
Титульная страница ЯМ имхо перегружена. Фокус внимания распылен. Но они выруливают за счет того, что это Яндекс и есть соотв. кредит доверия. У них все правильно, но использовать их решения нельзя.
Представьте что вы чайник и ищите, скажем электрочайник, и в первый раз заходите на сайт Маркета (где-то услышали). В двух ситуациях:
1. Сервис называется «Яндекс.Маркет»
2. Сервис называется «Яша.Маркет»
В обоих случаях возникает напряжение, поскольку вы не знаете, что делать. Но в первом случае вы знаете, что это Яндекс и не закрываете сразу. Затем видите поле поиска и вспоминаете, что Яндекс поисковик и преодолеваете свою лень и одним пальцем набираете «электрочайник» и нажимаете поиск.
Во втором случае вам скорее лень было разбираться или вводить.
В любом случае ЯМ это не проходной сайт, на который большинство пользователей заходят только однажды, а сервис с более или менее стабильной аудиторией, поэтому не так велики требования к скорости обучения.
Да и титульную станицу новые пользователи не видят. Основной траф на маркет идет из веб-поиска, на соотв. категорию или товар.
Примером может служить ЯМаркет, где на одной странице расположено сразу 5 способов начать искать товар. И это прекрасно.
Что дозволено Юпитеру, не дозволено быку. Изначально у ЯМ есть «кредит доверия», поскольку он Яндекс. Пользователь первый раз перейдя на ЯМ и испугавшись многообразия не закроет сайт, а сделает над собой усилие и разберется.
Контрол звездочки не стандартный лучше вместо него использовать не от и до. А от галочки от 1 до 5. Ну либо селекты. Сейчас много народу в интернете с компом не дружит.
При раскрытии у вас элементы прыгают, лучше их оставить на своих местах просто увеличить высоту
Валюта не указана
Кнопка должна быть слева, а не справа. В крайнем случае справа, но на одном уровне с формой, а не под ней. Там кнопку найти сложно. Гляньте где у Яши и гугла кнопки.
У заголовка большее отклонение чем содержимого
Также есть проблемы с многословностью
«по» лишнее. «По цене» => «Цена»
Количество звезд => число звезд
«Выбор отелей по дополнительным критериям» — вообще жесть.
Горизонтальный контрол фильтра (поиска) применим, когда фильтр/поиск основная функция и без него разобраться сложно. В товарах однозначно вертикальный, в гостиницах спорный вопрос. Но имхо лучше использовать комбинацию изначальный поиск горизонтальный, потом вертикальный.
у Украины нереальный ППС. Раза в 2 выше чем в Тае. Однако, в Тае жизнь дешевле. Это вам любой кто там был скажет. Скорее всего Украина мухлюет с данными ППС. Пару цифр поправить, это не газ стырить.
Помню читал официальную брошурку по статистике безработицы. Год не помню, но давно было.
Ни у одной области Украины не было уровня ниже 15%. Зато в среднем 7.5% получилось :)
Почти все используют в основном минус-слова. Поспрашивайте у коллег.
1, 2, вебинар или те же несколько статей Drizzly.
Не вижу в этих статьях и вебинарах выкладок и реальных экспериментов. Источники не авторитетны.
Дризли писал о совсем другом. Про статегию `кавычки`:
Она не пригодна для кампаний, цель которых собирать максимально дешевый теплый трафик и для кампаний в низкоконкурентных тематиках (трудозатраты несопоставимы с получаемым профитом). В этих случаях достаточно использовать длинную портянку очевидных минус-слов на уровне кампании. А вот в случаях, когда вам не дают покоя зубастые конкуренты, а цена за клик зашкаливает за 5-10 у.е – она будет незаменима. Речь пойдет о правильном применении кавычек.
Т.е. кавычки нужны когда ставки просто огромные. Существенно больше 5-10 у.е.
Я никогда не говорил с фанатизмом, что кавычки никогда нельзя применять. В отличии от вас.
В некоторых случаях кавычки могут быть полезны. Но таких случаев меньшинство.
Дескриптор по любому юзает диск при считывании.
Он точно не копируется и, как мне кажется, не маршалится. Т.е. потерь нет никаких, в теории.
А если если даже маршалится то это делается через одно memcpy().
Т.е. вне зависимости от числа обращений к файлу в памяти будет хранится только зипованный и обычный буферы, каждый в единственном экземпляре. Который передается по ссылке.
Я не могу представить себе нагрузку, которая может убить ноду на примерно таком коде
var buffer=new Buffer(«bla bla bla… 50K»);
app.get('/',function(req,res){
res.send(buffer);
});
Узкое место у вебсервисов почти всегда — диск. Будет ли работать ngnix быстрее зависит от нагрузки на диск. ngnix, как мне кажется, полюбому mtime проверяет. Т.е. диск грузит.
Сверять время не нужно на production. При обновлении ведь его рестартят.
Да и невозможно поскольку в haml, jade, less, sass есть подключаемые файлы и большинство компиляторов не возвращают их список. Даже если бы возвращали, то для показа одного файла могло бы потребоваться получение статистики по 10-20 файлам, что могло тормозить при сильных нагрузках.
Сделаю, как опцию, если с регулярками кто поможет. (это не моя сильная сторона).
Но, имхо, use удобнее.
Однако, я бы не разбивал адрес и квартиру. Это может сбить с толку людей живущих в частном доме. Хотя нужно пробовать: если при отсутствии этого поля многие забывают ввести квартиру.
З.Ы. Ввел тел +38 063 111 22 33. Поле просветилось красным, но причину ошибки не выдало. Лучше ее вывести в поповере.
0. Сложно. Для далеких от компа людей.
1. Лишнее поле.
2. Дублирование данных.
3. У пользователя появляется дилемма
В общем для продвинутой аудитории, для формы которую пользователь набирает постоянно это терпимо. Для обычных случаев — нет.
Адрес можно сократить до двух полей. Город и Адрес. По дефолту, город определяется автоматически по ip и идет до адреса. ФИО тоже одно поле. Регион нафиг не нужен. Индекс никто не помнит, а если помнят то не вводят.
У вас 14 полей. Вариант без танцев с бубнами это 2 поля на адрес и по одному на фио, тел, мыло и сообщение. Т.е. всего 6 полей.
Единственная причина, которая на ум приходит, это то что он знаком с этим интерфейсом или аналогичным ему.
Вас я ни в чем не обвинял. Причины по которым респондент ранее был знаком с интерфейсом различны. Но своим глазам я верю больше, чем вам.
Также видно что он заголовки просматривает.
То что движение зрачка довольно сложное это я лет с 10 знаю, но большинство данных обрабатывает подсознанием.
Чтобы читать только заголовки, пользователь должен заранее определить точно чего он хочет. Однако, в реальности, пользователь до того как зашел на сайт крайне редко в точности знает какие параметры ему нужны. У пользователей, обычно, до захода на сайт нет плана, в стиле: я буду искать 3-4 звездочный отель с парковкой. Он просматривает большинство пунктов и выбирает подходящий. А не просматривает заголовки только.
Здесь вертикальный с Ajax работает лучше, поскольку пользователь видет большую часть выдачи. И в случае скрола независимого может и искать и просматривать без необходимости скролить.
1. Он не занимает дополнительного места. Т.е. меньше скролить нужно.
2. Снизу вверх привычнее. Заметьте что все формы сейчас одноколочные. Даже ввод логина и пароля.
3. Если существуют поля ввода строки, то обычно используется только малая их часть (их начало). Поэтому при вертикальном расположении меньше движений мыши и глаза. Сравните
[XXXX_____________________________]
[XXXX_____________________________]
и
[XXXX_____________________________] [XXXX_______________________]
В первом случае глаз не двигаясь и не меняя фокус может прочитать данные в нескольких полях сразу.
4. Человек привык читать вправо-вниз. Сначала строку читает, потом спускается на следующую. При вертикальной от так и делает. При горизонтальной он читает по схеме вправо-вниз-вправо.
Представьте что вы чайник и ищите, скажем электрочайник, и в первый раз заходите на сайт Маркета (где-то услышали). В двух ситуациях:
1. Сервис называется «Яндекс.Маркет»
2. Сервис называется «Яша.Маркет»
В обоих случаях возникает напряжение, поскольку вы не знаете, что делать. Но в первом случае вы знаете, что это Яндекс и не закрываете сразу. Затем видите поле поиска и вспоминаете, что Яндекс поисковик и преодолеваете свою лень и одним пальцем набираете «электрочайник» и нажимаете поиск.
Во втором случае вам скорее лень было разбираться или вводить.
В любом случае ЯМ это не проходной сайт, на который большинство пользователей заходят только однажды, а сервис с более или менее стабильной аудиторией, поэтому не так велики требования к скорости обучения.
Да и титульную станицу новые пользователи не видят. Основной траф на маркет идет из веб-поиска, на соотв. категорию или товар.
Что дозволено Юпитеру, не дозволено быку. Изначально у ЯМ есть «кредит доверия», поскольку он Яндекс. Пользователь первый раз перейдя на ЯМ и испугавшись многообразия не закроет сайт, а сделает над собой усилие и разберется.
Также есть проблемы с многословностью
Горизонтальный контрол фильтра (поиска) применим, когда фильтр/поиск основная функция и без него разобраться сложно. В товарах однозначно вертикальный, в гостиницах спорный вопрос. Но имхо лучше использовать комбинацию изначальный поиск горизонтальный, потом вертикальный.
Помню читал официальную брошурку по статистике безработицы. Год не помню, но давно было.
Ни у одной области Украины не было уровня ниже 15%. Зато в среднем 7.5% получилось :)
Регион Москва.
кондиционеры 43 объявы.
кондиционеры вольдемар 39 объявы.
В итоге только 10% по топовому запросу использует кавычки. Не думаю что по таком запросу 90% новичков сидят в Москве.
Я вас не тролю. Я отвечаю в вашем же духе
.
Почти все используют в основном минус-слова. Поспрашивайте у коллег.
Не вижу в этих статьях и вебинарах выкладок и реальных экспериментов. Источники не авторитетны.
Дризли писал о совсем другом. Про статегию `кавычки`:
Т.е. кавычки нужны когда ставки просто огромные. Существенно больше 5-10 у.е.
Я никогда не говорил с фанатизмом, что кавычки никогда нельзя применять. В отличии от вас.
В некоторых случаях кавычки могут быть полезны. Но таких случаев меньшинство.