• Задай вопрос эксперту и выиграй билет на Highload!
    0
    1) Согласен, пользователь становится все более нетерпелив, мониторинг UX и его аналитика очень важная вещь.

    2) Большие компании пишут что-то свое — Angular, Flight, React и т.п. Баду не исключение — когда кода много и проекты нужно поддерживать годами — появляется что-то свое. Наше чем-то похоже сейчас на YouTube SPF идеологически (но в таком виде появилось на 2 года раньше). В ближайшее время будем переходить к более толстому клиенту и скорее всего к M,V,VC,C разбиению. Брать готовый фреймворк бессмысленно, адаптация к нашим задачам и ограничениям будет дороже дизайна архитектуры с нуля. А если речь о базовых фреймворках (починка расхождений в браузерах) то на большом проекте все равно должны быть свои обертки вокруг таких операций для большей управляемости и возможности воткнуть измерения (RUM) и перехватчики ошибок — а что внутри — по большей части привычки и вкусовщина.

    3) Важен баланс. С одной стороны полифил querySelectorAll это write-only код — непонятный, дико оптимизированный, загружаешь целиком в мозг, правишь, выгружаешь — тут по-моему по-другому не получится. А какой-нибудь демультиплексор разнотипных реквестов должен быть понятным — возможно много правок потребуется со временем.
    Таким образом низкоуровневое ядро может быть набором адцких черных ящиков, само ядро сбалансированным, но лучше читаемым, а код приложения — максимально понятным и экономия на спичках только вредна.
    Если есть детальный мониторинг UX, то можно понять когда и где сесть вооружившись профайлером, а где накладные расходы в пределах погрешности.
  • Задай вопрос эксперту и выиграй билет на Highload!
    0
    Фиш, ты же вроде уже запустил его?
    www.facebook.com/groups/feedme.ru/
    Или в группу пускают по талонам?
  • offsetHeight или нечаянный спуск лавины reflow
    0
    оригинал — dpp.su/blog/reflow/
    PS. вот за это habrahabr.ru/ppg/ принципиально ничего править не буду. уважаемая редакция, не нужно относиться к пользователям как к скоту.
  • Простой универсальный переключатель на JavaScript
    0
    Капитан! извините не удержался )
    см #comment_4822637
  • Простой универсальный переключатель на JavaScript
    0
    про «неважно» бред, согласен

    про «другой код» — сама функция три строки, нужные куски либы несколько сотен строк. код не open-source. зачем это в статье? статья не про наш фреймворк.

    то, что идея не понятна, я не удивлен. вы не первый.
    «переключения классов» фигня очевидная, а вот чтобы применить когда надо и свести сложную задачу к этой простой, нужно понять о чем статья :)

    dpp@www1.d3 ~/badoo> grep -rwoEh 'js[twe]' _templates|wc -l
    498
    и для всех этих случаев у нас 1 строка жс.
    если писать каждый раз, то будут сотни функций делающие похожую работу
  • Простой универсальный переключатель на JavaScript
    0
    посмотрел delegate в 1.7.2 — принципиально тоже самое: копание в DOM в цикле (строки 3291, 3297). это и называется «классическая реализация live».

    >А найти нужные элементы, это не так уже и долго.
    как говорится it depends. но практика это плохая.
    вот старый, не очень удачный (сохранен во время аварии) график: время инициализации страницы своего профиля my.dpp.su/badoo/cookie-5-js-1m-aggr.png (на графике среднее из миллионов хитов)

    код гмыла не откажусь посмотреть. есть не пожатый?
    все зависит от задачи, если посмотреть главную гугла то там и жс с цсс прям в хтмл засунути и всякие onclick атрибуты, но этоже не значит что так всегда и нужно делать.

    но да, без тестов нет смысла обсуждать дальше
  • Простой универсальный переключатель на JavaScript
    0
    это просто пример. статья демонстрирует подход, а не конкретную реализацию
  • Простой универсальный переключатель на JavaScript
    0
    это просто тестовый пример. а реализация делегирования не кончается одним jQ.live
    в моей реализации скорость не зависит от количества обработчиков и является константой — в худшем случае 5 hash lookup, какое-либо взаимодействие с DOM только в случае если верстальщики не могут сверстать правильно, а это менее 10 случаев из нескольких сотен.
    маштабируется уже 5й год просто отлично ;)

    на счет «лучше все обойду» — не серьезно, хотя на мелких проектах может и допустимо.
  • Простой универсальный переключатель на JavaScript
    0
    dpp в ближайшее время раскажет это тут: toster.ru
  • Простой универсальный переключатель на JavaScript
    0
    > Во время вёрстки верстальщику не нужно знать, что переключение режима выполняется javascript'ом.
    мы работаем в команде, понимать что ты делаешь и как это будет использовано коллегами — обязательное требование к хорошему сотруднику
  • Простой универсальный переключатель на JavaScript
    0
    приставка js есть только у этих классов из сотен использующихся у нас
    это случайность, исторически так сложилось :)
  • Простой универсальный переключатель на JavaScript
    +1
    это код для примера, чтобы небыло зависимостей. в либе код другой
  • Компания Badoo приветствует хаброжителей!
    +3
    Короткое уточнение: я из него выжал 25К одновременных коннектов, а нам надо 500К+.
    сборщик неуправляемый, да. переписывание nodejs/lib/http.js сильно помогло, но не решило проблему полностью
  • Компания Badoo приветствует хаброжителей!
    +1
    ты когда с -o3 соберешь чтоб узнать каков же реальный выигрыш? мож там system один, а внутри то и там и там libev[ent]
    а то с GC в v8 в nodejs у меня все кончилось письмом от одного из комитеров v8 с темой «не верю»
  • Где-же взять VPS/VDS?
    0
    я на firstvds «Разгон» (проблем не было — они уронили всего один раз, правда в самый не подходящий момент). тариф truevds «True20» выглядят превлекательнее.
    есть желание перекинуть пару простеньких проектов с шаред хостинга на тот же вдс и взять, например, «True30».
    каковы ваши причины перехода? что знаете об их QoS?

    зы: спасибо, заинтрегован.
  • Покинутая всеми вкладка
    0
    эх. мне бы выши проблемы…

    только sidebar со списком окон и поиском по нему спасает
  • Никакой «головной боли» — 46% женщин предпочитают интернет сексу
    0
    *только
  • Суперверстальщик и бетон
    0
    это еще что...
    как я уже писал мы ищем сотрудников. после этой статьи как-то так получилось, что читать резюме и собеседовать всех кандидатов "подписали" меня. я намного лучше стал понимать работодателей...

    это было бы очень смешно, если бы не было так грустно... и что самое грустное - большинство (как, возможно, и афтор резюме из сабжа) даже не понимает "что не так"...
  • Кэширование в Django
    0
    тут примерчик явного кэширования запроса. если совсем немного доточить, то можно хранить что угодно.

    на самом деле решение предложенного вами примера не очень корректено. article_list - это основные и единственные данные страницы. если нельзя кэшировать всю страницу, то можно вынести их в тег и кэшировать его (при помощи cache_page). получится неленивая загрузка, но код будет выполняться только если данных нет в кэше.
  • Кэширование в Django
    0
    да. article_list это объект типа QuerySet. запрос в базу отрпавляется при первом обращении к данным (в частности, при итерировании).
  • Кэширование в Django
    0
    угу :) но по-моему шаблоны нагляднее. хотя если версаешь не ты сам...
  • Кэширование в Django
    0
    Говорят можно операторы перегрузить... Сам еще не смотрел, но это решило бы много проблем.
  • Кэширование в Django
    0
    действительно, как подумал что это попадется одному знакомому верстальщику - сразу захотелось спрятать кэширование куда-нить подальше... :))
  • Кэширование в Django
    0
    Я говорю с точки зрения поддержки. Например есть сайт, написанный другим человеком несколько месяцев назад. Моей целью является писать так, чтобы разабраться было как можно проще. Просмотрев шаблоны, благодаря наследованию и тегам джанги понять что откуда растет очень просто.

    Наверное, кешированию не место в шаблонах. но за джанговцами вроде небыло замещено архитектурных просчетов. зачем они тогда его сделали в виде тега? ведь перемешивание MVC они предусмотрительно запретили... надо почитать дискуссии по этой фишке. ее ведь только что добавили в svnку
  • Кэширование в Django
    0
    Согласен. Это просто самое простое решение. В джанге есть сигналы. Можно повесить событие например на сохранение объекта. и в этом событии инвалидировать кэш связанный с сохраненным объектом. вот только если объект встречается во многих местах, то найти и инвалидировать все его кэши не такая тривиальная задача.
  • Кэширование в Django
    0
    да, Вы правы. только прейдется "бегать по всем пакам templatetags и смотреть не закэшировано ли где чего"...
  • Кэширование в Django
    0
    Нда, замороченый пример получился.
    Ключевая строка - {{ block.super }}. Т.к. список статей и список статей имеющих определенный тег по шаблонам не отличаются я понаследовался от списка статей. Шаблон списка статей (из предыдущей статьи, этому будет равен {{ block.super }}):
    {% for article in article_list %}
        «a href="{% url article_view article.id %}"»
        {{ article.title }}
        «/a»
    {% endfor %}
    Тут тега нет т.к. список статей это основные данные отображения. Но по ленивой природе запросов в бд в django запрос в базу не идет.

    Если упростить, то отображения для них будут такими:
    @render_to('blog/index.htm')
    def index(request):
        article_list=Article.objects.filter(public=True)
        return {
            'article_list': article_list,
        }

    @render_to('blog/tag_index.htm')
    def tag(request, tag_slug):
        tag=get_object_or_404(Tag, slug=tag_slug)
        article_list=Article.objects.filter(tags=tag, public=True)
        return {
            'tag': tag,
            'article_list': article_list,
        }
  • Шаблоны Django. Наследование.
    0
    спс, посмотрю.
  • Кэширование в Django
    0
    может быть. но, по-моему, в кэш лучше положить отрендереный кусок нежели дамп объекта который будет каждый раз подыматься, по нему будешь бежать и вставлять куски маркапа... зачем? по мне код и так получается чистый и красивый - не надо бегать по всем пакам templatetags и смотреть не закэшировано ли где чего.
  • Кэширование в Django
    0
    как описать в настройках что хочешь закэшировать кусок шаблона?
    лично у меня никаких идей. ориентироваться на имя блока? а если с параметрами? а если надо хранить несколько версий основываясь на контексте вызова?
  • Кэширование в Django
    0
    на счет таймаута согласен. вот хак - перекрыл стандартный тег cache чтоб он понимал, что если ему не дали таймаута первым параметром его надо взять из settings.py

    кстати, чтобы не "лазить по всем шаблонам где используется данный фрагмент" нужно использовать наследование и определять блок один раз.

    а на счет "засорения всякими cache_" - не согласен. по-моему там им самое место - сразу видишь что и где кэшируется. да и как описать в настройках что хочешь закэшировать кусок шаблона?
  • Кэширование в Django
    0
    про инвалидацию:
    я пока не нашел полностью устраивающего меня универсального решения. как найду - отпишусь.

    на счет site_cfg:
    а мне синковать (sync) удобнее, когда на всех машинах одно и тоже.
  • Кэширование в Django
    0
    очепятался: cachedQuery.py
  • Кэширование в Django
    0
    зы: не забудьте сменить на девелоперской версии строку CACHE_BACKEND = 'dummy:///' на что-нить другое.
    я минут 15 тупил че не работает... ;)
  • Кэширование в Django
    0
    Еще подумал: хорошо бы для кэширования запросов избавиться от явного использования API кэша.
    Вот за пять минут накидал: chachedQuery.py
    Хранит в кеше результаты запроса. Ключем является построенный sql запрос, вытаскиваемый из ихнего sql-построителя.
    Пример там же.
  • Кэширование в Django
    0
    UPD: articles_cached[0].get_absolute_url()
    тоже работает. так что он подымает полноценный объект.
    кодит объекты перед укладкой в кэш он при помощи cPickle/pickle
  • Кэширование в Django
    0
    Про кэширование view-ов я вроде написал вкратце.
    Для кэширования sql запросов можно воспользоваться "кэшированием данных":

    from blog.models import Article
    from django.core.cache import cache
    articles=list(Article.objects.all())
    cache.set('articles',articles)
    articles_cached=cache.get('articles')
    print articles_cached

    проверил только что - вроде все работает.

    На счет обновления кэша по сигналам - действительно я об этом не упомянул. Мне пока хватило инвалидации по таймауту и очистки кэша скриптом генерации public-версии (при изменениях в коде: рестарт апаче, сжатие js и css, пр.).
    Но в перспективе - действительно надо :)
  • Кэширование в Django
    0
    :)
    мне просто интересно когда это может быть надо. разве что если на серваке куча сайтов и один из них совсем не меняется...
  • Шаблоны Django. Наследование.
    0
    как и обещал - написал статью про кэширование. тут.
  • Кэширование в Django
    0
    А если у меня нет регистрации и пользователе-зависимой информации? Но, к примеру, блоки рандомно меняются. Мне все-таки кажется что кешировать все подряд не стоит - лучше кешировать то, что действительно нужно.