Мне кажется, что это очень хорошее замечание, так как людям не запретишь постить такого рода посты, а их наличие в основной ленте вредит ресурсу.
Отдельное для них место — правильное решения. И тогда, уже при наличие такого места, если такие посты продолжают появляться в основной ленте — минусовать однозначно.
Вопрос, который у меня появился после появления CUDA: возможно ли именно для веб-сервера, при обработке большого количества запросов, организовать множество тредов и пустить их на gpu?
Я знаю, что такая схема имеет некоторые ограничения и неудобства, но если работу с данными, которые нужны для ответа на запросы, возможно запихнуть в рамки быстрой видеопамяти и кешей разного уровня, то даст ли оно ожидаемый рост производительности при высоких нагрузках?
Скорее всего всё будет очень сильно зависеть от характера запросов и логики их обработки. Ну вот для примера, если взять задачу выдачи подсказок (suggests), при наборе в неком поле, — это же множество однотипных запросов, полный индекс данных для которорых можно постоянно держать в быстрой видео-памяти. Поможет ли в такой задаче gpu?
При таком методе, самое главное — где-то в начале не наткнуться на исключение из общей картины.
В данном примере, при первом подсчёте важно было взять именно source='twitter' а не source='the_fresh_twitter_clone' для которого sum(source='the_fresh_twitter_clone') дало бы 27, после чего все последующие расчеты были бы уже ложны.
Среднестатистический запрос ещё нужно уметь построить…
Думаю, что в таком методе, важно делать несколько разных запросов на каждом шагу.
Жаль, что в этом разделе сайта, на страницу выводится только 7(!) элементов (коллекций, аддонов в коллекции), и без возможности задать количество на страницу. Не люблю листать страницы :(
Лёгкое изменение бордеров и бекграунда в инпутах под дизайн в большинстве случаев влияет положительно на впечатление от сайта. Изменение же чекбоксов/радиобаттонов влечёт за собой программирование их стандартного поведения (переходы по Tab, изменение состояния по пробелу и прочую головную боль).
В общем, в этом вопросе главное сохранить узнаваемость компонентов как таковых и их стандартное поведение, в противном случае будет затруднено достижение главной функции формы — её использование.
«Subscribe to see how the collections you admire grow» — здесь, как я понял, полезным моментом есть слежения за появлением новых дополнений в соответствующих коллекциях.
Update Notifier действительно хорош, но он следит только за обновлениями уже установленных.
Ещё один путь группирования, который, действительно, может помочь найти что-то полезное + даёт возможность следить за полезными новинками.
Он хорош тем, что включение дополнения в популярную группу может быть более адекватной оценкой полезности, чем рейтинг (5/5 по оценке только 10 разработчиков) и количество скачиваней (не видно же, сколько из них удалили дополнение после первых 5 секунд ознакомления), но здесь всё зависит от того, кто формирует коллекцию.
Отдельное для них место — правильное решения. И тогда, уже при наличие такого места, если такие посты продолжают появляться в основной ленте — минусовать однозначно.
Я знаю, что такая схема имеет некоторые ограничения и неудобства, но если работу с данными, которые нужны для ответа на запросы, возможно запихнуть в рамки быстрой видеопамяти и кешей разного уровня, то даст ли оно ожидаемый рост производительности при высоких нагрузках?
Скорее всего всё будет очень сильно зависеть от характера запросов и логики их обработки. Ну вот для примера, если взять задачу выдачи подсказок (suggests), при наборе в неком поле, — это же множество однотипных запросов, полный индекс данных для которорых можно постоянно держать в быстрой видео-памяти. Поможет ли в такой задаче gpu?
Ещё бы…
О да, это вершина развития системы укрытий…
офсайт
Это же просто ужс :'(
В данном примере, при первом подсчёте важно было взять именно source='twitter' а не source='the_fresh_twitter_clone' для которого sum(source='the_fresh_twitter_clone') дало бы 27, после чего все последующие расчеты были бы уже ложны.
Среднестатистический запрос ещё нужно уметь построить…
Думаю, что в таком методе, важно делать несколько разных запросов на каждом шагу.
В общем, в этом вопросе главное сохранить узнаваемость компонентов как таковых и их стандартное поведение, в противном случае будет затруднено достижение главной функции формы — её использование.
Update Notifier действительно хорош, но он следит только за обновлениями уже установленных.
Он хорош тем, что включение дополнения в популярную группу может быть более адекватной оценкой полезности, чем рейтинг (5/5 по оценке только 10 разработчиков) и количество скачиваней (не видно же, сколько из них удалили дополнение после первых 5 секунд ознакомления), но здесь всё зависит от того, кто формирует коллекцию.