Я боюсь, что мультитач работал в убунте еще пару лет назад. :)
Надо всего-лишь иметь тачпад, который на уровне железа поддерживает мультитач и «достаточно» (точной версии не скажу) свежию версию драйвера xorg-synaptics.
ну и в /etc/hal/fdi/policy/shmconfig.fdi описать настройки. Примерно так:
То, что он играл одни из самых сложных произведений, не означает, что они из самых красивых.
Сложные оценит профессионал, критик или просто знающий человек, но обыватель пройдет мимо, потому что произведение ему не понравится, и будет абсолютно прав.
Играй бы он, к примеру, известные произведения Вивальди — получил бы намного больше за «узнаваемость».
Для 8.04 возможно вы правы. Но я посмотрел по зависимостям — он вытягивает добрую половину kde4, он точно помогает для kde3.5, который в hardy используется?
из-за того, что разница невелика, я возьму то, что удобнее положить в кошелек :)
или в случае програмимрования легче читается, понимается и поддерживается.
микрооптимизация, к сожалению, не приносит желаемых результатов. Конечно, не стоит совсем о ней забывать, и ваша статья хороша для понимания правильных конструкций. Но, как я уже говорил, в первую очередь надо искать узкие места в алгоритмах.
В общем случае у вас не будет милионов и даже тысяч вызовов этих конструкций, получается что оптимизация конструкций — экономия на спичках.
В подавляющем большинстве случаев приложение тормозит из-за неправильных или неэффективных алгоритмов.
Поэтому под оптимизацией стоит понимать не поиск наиболее быстрого способа пробижаться по массиву из миллиона элементов, а поиска алгоритма, позволяющего избежать этого действия.
Вы не знаете куда он будет вставлен, может быть колонка будет 100 пикселей шириной, а может 200.
Вы не знаете какое придет объявление - большое и маленькое и сколько в нем строк текста.
Вы знаете только, что заголовок максимум 33 символа, текст - 75, а урл - 255.
Примерные расчеты все равно ни к чему не приведут, контент будет продолжать прыгать. А любой владелец сайта лучше согласится на пол-секундную задержку, чем на прыгающие блоки.
У Яндекса есть вертикальный, горизонтальный, плоский и фиксированный форматы. Все их них, кроме последнего, занимают столько места, сколько надо для конкретного рекламного блока, т.е. зависят от количества объявлений и их размера. Размеры таких блоков заранее узнать никак нельзя, соответственно, загружать и отрисовывать рекламу надо непосредственно во время загрузки страницы.
Вся проблема в том, что если не использовать document.write, то контент страницы будет прыгать, потом что он загрузится быстрее, чем реклама. Соответственно, когда подгрузится реклама, она отодвинет контент, что совсем некрасиво.
Если использовать фиксированные форматы, то проблемы нет, но для резиновых блоков, как у Яндекс, ничего, кроме document.write использовать нельзя.
Более того, правильно настроенные и быстроотвечающие сервера не создают больших задержек при загрузке страниц.
Надо всего-лишь иметь тачпад, который на уровне железа поддерживает мультитач и «достаточно» (точной версии не скажу) свежию версию драйвера xorg-synaptics.
ну и в /etc/hal/fdi/policy/shmconfig.fdi описать настройки. Примерно так:
Я им отписал туда подробненько что-да-как :)
Сложные оценит профессионал, критик или просто знающий человек, но обыватель пройдет мимо, потому что произведение ему не понравится, и будет абсолютно прав.
Играй бы он, к примеру, известные произведения Вивальди — получил бы намного больше за «узнаваемость».
Для 8.04 возможно вы правы. Но я посмотрел по зависимостям — он вытягивает добрую половину kde4, он точно помогает для kde3.5, который в hardy используется?
Его заменили в KDE 4.1 на Dragon Player.
если не трудно, можете сделать тест для переменного числа ветвей (от 1 до 10, например)?
или в случае програмимрования легче читается, понимается и поддерживается.
микрооптимизация, к сожалению, не приносит желаемых результатов. Конечно, не стоит совсем о ней забывать, и ваша статья хороша для понимания правильных конструкций. Но, как я уже говорил, в первую очередь надо искать узкие места в алгоритмах.
Прирост в несколько миллисекунд — это и есть экономия на спичках.
В общем случае у вас не будет милионов и даже тысяч вызовов этих конструкций, получается что оптимизация конструкций — экономия на спичках.
В подавляющем большинстве случаев приложение тормозит из-за неправильных или неэффективных алгоритмов.
Поэтому под оптимизацией стоит понимать не поиск наиболее быстрого способа пробижаться по массиву из миллиона элементов, а поиска алгоритма, позволяющего избежать этого действия.
Тем более, что она хоть и бесплатная, но закрытая.
Вы не знаете какое придет объявление - большое и маленькое и сколько в нем строк текста.
Вы знаете только, что заголовок максимум 33 символа, текст - 75, а урл - 255.
Примерные расчеты все равно ни к чему не приведут, контент будет продолжать прыгать. А любой владелец сайта лучше согласится на пол-секундную задержку, чем на прыгающие блоки.
Если использовать фиксированные форматы, то проблемы нет, но для резиновых блоков, как у Яндекс, ничего, кроме document.write использовать нельзя.
Более того, правильно настроенные и быстроотвечающие сервера не создают больших задержек при загрузке страниц.