• Организация js кода для джуниоров
    0
    Если уж зашла речь про модули и Backbone — то лучше сразу вслед за Backbone смотреть Bacbone.Marionette — это надстройка над Backbone, которая дает в том числе модульность. Т.е. то, о чем написано в статье, только из коробки и с кучей прочих плюшек.
  • Облачная платформа Яндекса. Cocaine
    0
    А мне одному показалось странным наличие агрегирующей ноды? Если она падает, то падает все приложение? Или я чего-то не так понял?
  • Windows Azure Blob-storage: поддержка CORS
    0
    Да, Content-Disposition тоже очень порадовал. Как раз вовремя )
  • Визуальные спецификации
    –1
    Поделюсь реальным примером крутой спецификации от stepahin:
    image
  • Пишем сервер, который не падает под нагрузкой
    +2
    Есть ссылки на эти самые инструменты, которые позволяют «фильтровать» часть запросов в зависимости от нагрузки? Как эти инструменты вообще понимают насколько нагружен бэкэнд? Было бы интересно почитать.
  • Пишем сервер, который не падает под нагрузкой
    +1
    Вы наверное никогда не были в ситуации, когда нагрузка резко возрастает. Понятно, что можно подготовиться, поставить железо, балансеры, расширить каналы и т.д. Но это подготовка. Иногда бывает так, что есть приложение и на него именно сейчас идет в 10 раз больше пользователей, чем обычно. В этом случае могут «помочь» подобные решения — это легко прикрутить уже под нагрузкой. Понятно, что большинство пользователей все равно увидит ошибку, но не все. Обслуживать 20% запросов гораздо лучше, чем обслуживать 0%.
  • Пишем сервер, который не падает под нагрузкой
    +1
    Я не совсем понял, как все-таки работает toobusy(). Все ясно с callstack — замеряется раз в 500 мс. На основе этих данных можно при всех вызовах toobusy возвращать true. Но тогда получается, что в этом случае очередь может за 500мс рассосаться и при этом продолжить всем отвечать ошибкой. Далее предположим нагрузка есть, сделан новый замер длины очереди. Очередь пустая (но нагрузка до сих пор большая, просто всем отвечаем 503). Функция toobusy начинает всем отвечать false. И отвечает так в течение 500мс. В течение этого времени запросы начинают обрабатываться и все равно сервер ложится…

    Я к тому, что по идее надо делать какое-то распределение ответов между замерами. Например, под нагрузкой отвечать toobusy() = false каждому десятому. Но как это сделать?
  • А вы специалист в какой-то одной IT-области или универсал, который занимается всем. Я из второй категории…
    +1
    Вопрос снят — получилось. Лично оплачивал услуги вашего сервиса.
  • А вы специалист в какой-то одной IT-области или универсал, который занимается всем. Я из второй категории…
    0
    И? Получилось?
  • Настоящий многопоточный веб-сервер на ассемблере под Linux
    +1
    Дружище, огорчу тебя — проц 2-х ядерный.
  • Новый Tracks Flow
    0
    Влияет ли проигрывание трека на загрузку CPU?

    Пока нам удалось увидеть загрузку в опере при проигрывании трека. Есть загрузка процессора при переходах / движениях мышью, но это нормально т.к. срабатывают различные события и рендерятся элементы. Если в браузере ничего не играет и не происходит, то загрузка не превышает 4%.
  • Новый Tracks Flow
    0
    Про консоль — хочется понимать, есть ли какие-то процессы, которые происходят в фоне. Операционка — MacOS, верно?
  • Новый Tracks Flow
    0
    Скажите, пожалуйста:
    Загрузка постоянная или только при переходах?
    В консоли браузера что-то происходит (какие-то запросы / действия)?
    Загрузка CPU после обновления страницы исчезает или остается?
    Точно наш сайт тормозит (можно посмотреть в диспетчере задач Chrome Инструменты->Диспетчер задач)
    Это поможет нам в поиске проблемы.
  • Новый Tracks Flow
    +1
    «Форки плейлистов» — это очень круто! Порадовало!
  • Новый Tracks Flow
    0
    Смотрим, думаем… Сейчас, возможно, подключится, но проблема существует.
  • Новый Tracks Flow
    0
    Не совсем понял, откуда вы подключаете VK — из настроек или из сообщения при проигрывании трека?
  • Новый Tracks Flow
    0
    Да, вы правы. В ближайшем билде снимем ограничение.
  • Новый Tracks Flow
    0
    При выборе композиции из VK мы стараемся найти именно тот трек, который хотел услышать пользователь — не кавер, не ремикс, не концертную запись, а именно оригинал. Для этого мы дополнительно фильтруем результаты поисковой выдачи, сравнивая название трека и исполнителя с нашего сайта с выдачей VK. Далее сверяем длительность трека с длительностью, указанной у нас (взятой с last.fm, deezer, ...). Чем больше отличается наша длительность трека от длительности VK, тем менее релевантным считается трек.
    Пока что фильтра / сортировки по качеству звучания нету. Мы планируем внедрить это в будущем.
  • Строки в C# и .NET
    0
    Хабр — такой хабр :)
    Полемика по поводу пары байт скоро перерастет в несколько гигабайт, хранящихся в БД Хабра в виде комментариев )
  • Предельная производительность: C#
    +1
    Вообще глобально любая оптимизация — это повышение скорости работы приложения в ущерб затратам на его дальнейшую поддержку. Чем больше тюнинга, тем хуже код.
    Проблема статьи в том, что автор начал оптимизировать приложение слишком рано и начал использовать приемы низкоуровневой оптимизации, которые на сегодняшний день дают небольшой прирост производительности при больших трудозатратах.
  • Запись к врачу через Интернет — вид изнутри
    +1
    Пользовался подобной системой в Москве. Основных минусов два:
    1. Ограничение на срок записи. Нельзя записаться сильно заранее. Из-за этого начинаются проблемы записи к популярным врачам. В момент открытия записи (ночью) все разбирается за минуты. И получается, что надо напрягаться, а то вообще не попадешь.
    2. Повторный прием. На него надо записываться в общем порядке. При таком раскладе пройти, например, диспансеризацию или подготовить карту ребенку для детского сада — нереальная задача. Приходилось идти без талона.

    Но в целом это прогресс. Немного доработать — и будет все отлично.
  • Предельная производительность: C#
    +2
    Добрая половина приемов — это эдакий привет из 90-х. И главное — совершенно неверный подход к вопросу. Есть несколько простых правил:
    1. Преждевременная оптимизация — зло! Сначала сделай, чтобы работало качественно и правильно, а потом оптимизируй.
    2. Не оптимизируй без профайлера! Сначала собери статистику по скорости работы, а потом оптимизируй то, что действительно тормозит. Пункт 2 делается в цикле до того момента, как скорость работы станет достаточной.
    3. Помни, что на дворе 21 век и компилятор / операционная система / железо умеют оптимизировать выполнение команд. Всякие там кеши жестких дисков, NCQ, оптимизаторы компиляторов и многое многое другое позволяют не делать лишней работы и оставить приложение в понятном виде.
    4. Иногда надо добавить ресурсов на сервер. Например, если докинуть памяти, чтобы ее было с избытком, операционка начнет сама кешировать ввод-вывод.

    Для справки, обычное .NET MVC приложение (RESTful api), работающее с БД при использовании указанных трех правил удалось оптимизировать на 2 порядлка. И при этом никакие foreach, if и прочая муть не трогалась вообще. Достаточно было прекомпилировать запросы, кешировать некоторые данные в Hashtable и отказаться от Newtonsoft JSON сериализатора в сторону стригбилдеров (что, кстати, дало проирост процентов 15, но было самым геморойным). Итого с двух ядер ноутбука приложение стало выдавать около 1000 запросов в секунду вместо 20-35 до оптимизации.
  • Светодиодная лента в качестве освещения комнаты
    0
    А мне одному кажется, что подобные штуки только мешают т.к. изменение света по бокам привлекает внимание, туда автоматически переходит взгляд, а там ничего нет. Т.е. как-бы пытаешься там что-то увидеть, а там — ничего. И приходится наоборот сосредотачивать взгляд на картинке и пытаться не уводить его в сторону на подсветку?
  • Хакатон глазами участника и победителя
    –1
    Объясните мне, зачем надо писать сервис прям там? Можно ведь схитрить и сделать все заранее?
    Как подобные читы отслеживаются? Или это просто «на честность»?
  • Boomfox + Tracks Flow
    0
    Нет.
  • Новое на Tracks Flow
    0
    да
  • Новое на Tracks Flow
    0
    Да, с Chromium на Ubuntu нам пока не удалось подружиться. Рfботаем над этим.
  • Новое на Tracks Flow
    0
    Первая версия сайта была сделана за 4 месяца. Как такового прототипа не было.
  • Новое на Tracks Flow
    0
    Посмотрел — сами файлы идут у нас так же как и с vk.com через userapi.com. По идее домен один и тот же. Если на vk все работает, то и у нас должно.
  • Новое на Tracks Flow
    +1
    Мне кажется, что качество контента в плейлистах, созданных именно пользователями значительно выше, нежели в радио. Поэтому усилия, потраченные на поиск хорошего плейлиста компенсируются тем, что его потом можно будет слушать не один раз.
  • Новое на Tracks Flow
    +2
    О, поправили, спасибо. Пробуйте.
  • Tracks Flow открыт
    0
    Есть в списке неуловимых багов. Будем бороться.
  • Tracks Flow открыт
    +4
    Это неправильный regex шаблон. Поправим. Наши извинения.
  • Tracks Flow открыт
    0
    Исправлено.
  • Tracks Flow открыт
    +1
    Не ожидали если честно. Но сейчас все ок — добавили ресурсов.
  • Tracks Flow открыт
    +3
    Положили нам бэкэнд. Увеличили с 1 ядра до 4. Наши извинения.
  • Tracks Flow + Open Source = Simple File Storage
    0
    Верно, лишняя строчка.
  • Tracks Flow + Open Source = Simple File Storage
    0
    Это наверное взаимовыгодное сотрудничество. Но в целом, учитывая, что мы делимся кодом, наверное мы поддерживаем сообщество.
  • Как, зная только имя и email человека, злоумышленники получили доступ ко всем его аккаунтам и удаленно уничтожили информацию на всех его устройствах
    +1
    Кстати, это очень распространенный косяк — во всех трех ДЦ где я обслуживался можно было так сделать. Иногда чуть сложнее, иногда чуть проще, но в целом несложно, если четко знать что ребутаешь.
  • Tracks Flow изнутри
    0
    Да