• Кэширование в Django
    +1
    Как и обещал - статья про кэширование в Django.
    Странно у меня получается - делал блог чтоб писать о JavaScript, а пишу, в основном, о Django. Наверное потому, что блог делал на нем и нахожусь под впечатлением. Вот что значит грамотная архитектура!
  • vkontakte.ru планирует предоставить пользователям возможность более точно указывать свое семейное положение
    0
    пля... 42й сервак мего прова лежит. если до утра не подымут я либо их убью либо сам убьюсь...
    Вам - огромное спасибо что заметили!
  • vkontakte.ru планирует предоставить пользователям возможность более точно указывать свое семейное положение
    0
    Life is short...
    Life's too short! Stand and watch. Or get involved. Your choice...

    Кликабельно. меня не пинать, я слева :))
  • Шаблоны Django. Наследование.
    0
    Картинки уже нарисовал 8) но статью писать пока нет времени. Думаю займусь в выходные.
  • Шаблоны Django. Наследование.
    0
    Спс, попробую.
  • Шаблоны Django. Наследование.
    0
    Извиняюсь, Вы правы. Как я уже заметил тут я увлекся и не описал кеширование совсем. Обещаю вскоре написать статью о кешировании в джанге. Сейчас, к сожалению, совсем пропало время. Может в выходные?
  • Шаблоны Django. Наследование.
    0
    Одной из мотивационных причин написанию статьи для меня стало то, что в свое время мне пытались объяснить самописанную систему наследования шаблонов. Вещи действительно простые, но это зависит от того как объяснять... Тогда я несколько дней не мог всасать чего он там наворотил...
  • Шаблоны Django. Наследование.
    0
    Оффтопик:
    Хабралюди! Чем вы кормите мои комментарии? Никак не могу понять почему джанга срыгивает некоторые из них.

    Если у Вас не получилось отправить какой-то комментарий прошу написать мне об этом по хабропочте или на dpp at dpp.su. Спасибо.
  • Шаблоны Django. Наследование.
    0
    спасибо что обратили внимание, а то бы так и не заметил )) я так увлекся описанием того как это устроено что забыл написать что "это".

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

    сейчас попробую исправиться =)
  • Шаблоны Django. Наследование.
    0
    мне тоже казалось что наибольшие зарплаты у жавы. наверное потому что основно потребитель - банки.

    на счет зарплат тоже согласен. имхо, пока молодой и есть силы я лучше буду заниматься тем, что нравится. хороший специалист в любой области будет получать хорошую з/п. понятно, что в некоторых областях прийдется приложить намного больше усилий чтобы доказать что ты "хороший".
  • Шаблоны Django. Наследование.
    +1
    Да, нравится =) последний раз я этим занимался тут. Считаю, что велосипедостроение помогает понять структуру и архитектуру велосипедов "от производителя" лучше всего остального.

    >Блин есть массив данных
    По-моему один из нас чего-то недопонимает. Дело в том, что массива-то нету 8-(

    Если из базы в xml доставать весть каталог товаров... сами понимаете что будет. Идея этих двух статей была именно в том, чтобы избавиться от выборки данных (которая может быть очень ресурсоемкой), но при этом не порушить целостность архитектуры.
  • Шаблоны Django. Наследование.
    +1
    ничего не могу сказать. я не пересекался с миром .NET и не интересовался ситуацией с зарплатами.

    У меня есть только один знакомый дотнетовец. Да, он умеет рубить бабло. Но больше всего меня убило (прости, чувак, если эты это читаешь, но я запомнил это на всю жизнь) когда он не смог нарисовать блок-схему цикла. По-моему понимание основ это очень важно. То, что микрософт позволяет нам не думать о том как это устроено это конечно хорошо, но имхо это очень сильно отражается на качестве кода.

    Оффтопик: а-а-а-а! ты предал свою аватарку! :)))
  • Шаблоны Django. Наследование.
    +1
    На самом деле - смысл есть. Точнее он может быть и надо оценивать в каждом конкретном случае.

    Когда я работал в веб-студии "на потоке" я понял, что до какой-то степени в жертву скорости разработки можно принести очень многое. Пусть оно кривое, противное и тормозное, но если оно позволяет быстро сшибать деньги с неопытных клиентов - его надо использовать. Конечно халтура возможна только во время становления рынка (либо при монополии). А сколько и чего ты согласен принести в жертву - каждый решает сам. Мне, например, просто противно производить неликвид. И надо быть готовым, что Ваши клиенты могут очень быстро из Вас вырости (как из ползунков).
  • Шаблоны Django. Наследование.
    +2
    эээ... мне очень стыдно, но у меня есть против него предубеждение. если честно, то все, что я о нем знаю это то, что он существует.

    С учетом этого приведу свои доводы:
    * платный. у меня нет тысяч долларов на покупку windows server, mssql server, visual sudio, msdn и прочих продуктов микрософта. использовать ворованый софт и пытаться продать то что ты при помощи него сделал - получается как-то не очень.
    * дорогой хостинг - менее распространен, выше требования.
    * допустим я захотел его изучать. единственный верный путь - сделать на нем что-либо. что делать? сколько будет стоить хостинг и софт? а ведь первый блин наверняка будет комом...
    * комьюнити. сама идеология opensource строится на бескорыстии и взаимопомощи. по-моему шанс получить бесплатную, но *квалифицированную* консультацию в случае opensource намного выше. да, размер комьюнити может быть больше - выучить проще, микрософт позаботился о комфорте разработчика - но каков средний уровень членов?
    * уровень контроля. в opensource ты всегда можешь дойти до сути того как что-либо работает или почему что-то работает медленно. в случае с продуктами от мс - максимум до чего ты можешь "докопаться" - это до авторитетного высказывания, что "это лучше не использовать".

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

    Вот и получается что ты пользуешся средствами разработки, а не разрабатываешь программы :)

    это все мое имхо и я нарочно утрирую. не воспринимайте слишком серьезно.
  • Шаблоны Django. Наследование.
    +1
    На самом деле я делал сайты на Питоне (http://dpp.su/portfolio/tag/acesite3/) около полугода перед тем как начал изучать Django. Кроме этого делал сайты и на ПХП (http://dpp.su/portfolio/tag/php/), но при этом никакой фреймворк не использовал.
    Когда я решил посмотреть какие фреймворки для ПХП и для Питона существуют я перепробовал наверное с десяток. По-моему секрет успеха джанги в следующем:
    * хорошая скорость out-of-box (т.е. если при программировании придерживаться идеологии джанги то не придется танцевать с бубном вокруг своего детища после прихода десяти посетителей одновременно).
    * хороший quick start tutorial дающий представление обо всех частях системы.
    * хорошая документация - это по-моему самое главное (имхо, документация джанги намного лучше документации самого питона).
    * продуманная архитектура - практически ничего из написанного в документации не вызывает отторжения.
    * продуманная структура - как и архитектура достигается при помощи правильного использования общепринятых паттернов проектирования.
    Как я уже писал чуть выше:
    Главное приемущество Django - это стройная, логичная и стандартная сруктура решения проблем.

    Я допускаю, что для ПХП тоже есть грамотные фреймворки. Наверное, я их просто не нашел. Но с другой стороны - питон позволяет намного больше. Когда я только сел на питон - мне многое не нравилось - казалось, что на пхп аналогичные проблемы я бы решал намного эффективнее. Но со временем пришло понимание, что если простые вещи действительно проще сделать на пхп, то сложные сделать на нем красиво уже практически не реально. Простой пример - для удобного ORM нужна перегрузка операторов сравнения, а в пхп ее просто нет. (Кстати, в джанге ORM не очень удобный - многовато "магии".)
  • глюк
    +1
    Странная дата у статьи получилась - опубликовал-то я ее сегодня...
    Кроме того, не смог победить автозамену </> на угловые скобки. пришлось заменить кавычками.
  • Фрагментарное кэширование в MVC веб-фреймворках
    0
    Написал подробную статью о том как устроены шаблоны Django и как в Django решается сабж.
  • Каким словом лучше заменять слово «Друг» в социальных сетях и пр.?
    0
    американский "френд" это совсем не то, что русский "друг". но, к сожалению, Россия переняла от Америки не только джинсы...

    Нагуглилось вот: друг - это ... - оцените уровень культуры анонимов...
  • offsetHeight или нечаянный спуск лавины reflow
    0
    хм. понял что вы имеете ввиду.

    Можно изменить функцию на:
    function doesElementInheritCSSClass(el, cls)
    {
        var p=el;
        var re=new RegExp('(^|\\s)'+cls+'($|\\s)');
        while(p && !re.test(p.className))
            p=p.parentNode;
        return !!p;
    }
  • offsetHeight или нечаянный спуск лавины reflow
    0
    >поразмышляйте (когда будет время) о том, для чего это может понадобится и как это может изменить скрипты:

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

    однако в данном случае body.hide определяет общее состояние, а сам .hide - состояние конкретного виджета. а нам надо найти именно состояние виджета. и как состояние приложения называтся не суть важно. тем более, что в таком случае мы получим не то что хотели:

    <body class="hide">
    <widget class="hide"></widget>
    <p id="p1">test</p>
    </body>
    isHidden($('p1')); // ==true

    поэтому состояние приложения лучше назвать по другому.

    или я что-то упускаю?
  • offsetHeight или нечаянный спуск лавины reflow
    0
    > Было бы разумно проверять в условии наличие тех свойств и методов, которые необходимо использовать:
    > if (document.defaultView && …
    там дело немного в другом document.defaultView есть и в Safari, но в Safari быстрее работает isHidden

    >>Т.о. "универсальным решением" будет функция isHidden. ;)
    > Обе isHidden жестко привязаны к имени класса, и, следовательно, не
    > могут называться универсальными.
    если они не привязаны к классу, то это должны быть не isHidden, а doParentshaveTheFollowingClassName ;) но если это принципиально, то исправить, чтобы имя класса передавалось параметром - не проблема.

    > К тому же та, что внутри
    > isHiddenFast будет работать некорректно (проблема: return !!p &&
    > p!=b; => нет проверки класса элемента, если элемент - это body).
    а какой смысл скрывать body? это сделано нарочно.

    Таки собрался дать более четкое определение reflow. Думаю теперь все четко написано.

    PS. спасибо большое за комментарии!
  • offsetHeight или нечаянный спуск лавины reflow
    0
    >>Коммитятся все отложенные reflow, а не только те...
    Я думаю эта фраза некорректна. Я так написал чтоб было понятнее. reflow не связан с каким либо элементом, у reflow есть только точка старта, от которой распространяются изменения. И будет ли затронут тот или иной элемент зарание не известно.

    >Вы ведь только теперь написали: "не только те" (об этом и речь).
    Теперь понял, что Вы имели ввиду. Четкого определения reflow я не нашел ни на русском ни на английском. Если можете поправить определение reflow чтобы это было понятно - внесите свой вклад :)

    >>Понятно почему? Если нет...
    >А вот так не надо.
    да ладно Вам, я ж по-доброму ;)

    >>Мы получили универсальное решение...
    >Проверьте свое "универсальное решение" на этом примере:
    О! спасибо Вам большое за обнаружение этой ошибки.
    В цитируемой статье явно указано, что вызов getComputedStyle также вызывает reflow, и причины отсутствия этого в IE и FF непонятны, хотя и радуют.

    Теперь понятны "причины отсутствия" - по тому что не работает :)) Странно, что я не заподозрил подставу сразу.

    Т.о. "универсальным решением" будет функция isHidden. ;)
  • offsetHeight или нечаянный спуск лавины reflow
    +1
    да нет, просто прожки работающие без доса, юзая тока функции биоса. на сколько помню написал простейший файловый менеджер и текстовый редактор. потом забил...
  • offsetHeight или нечаянный спуск лавины reflow
    0
    Вы это имели ввиду:
    function test_offset()
    {
        var c=init();
        var o = document.getElementsByTagName('meta').item(0);
        profile('offsetHeight');
            for(var i=0; i<1000; i++){
                fnOffset(o);
                c.appendChild(t.cloneNode(true));
            }
        profileEnd();
        clean(c);
    }

    У меня цифры остаются прежними во всех браузерах.

    Коммитятся все отложенные reflow, а не только те, которые связаны с каким-то элементом. Понятно почему? Если нет постараюсь объяснить еще раз.
  • offsetHeight или нечаянный спуск лавины reflow
    0
    почему этот процесс становится причиной повторного вывода (laying out) элемента?

    Это не так. Этот процесс коммитит отложеные reflow. Если их небыло, то reflow не происходит - смотрите самый первый тест.

    Что же произойдет в случае если они были.
    Представьте, что в DOM есть таблица с двумя ячейками. Ширина таблицы - 100px, ширина ячейки - 50%.

    examples

    Мы меняем содержимое первой ячейки и хотим узнать какова ее ширина. Казалось бы - 50px. Сравним таблицы 1 и 2.
    Как браузер должен отличить первый случай от второго? Для этого требуется сделать layout не только для самого элемента, но и для его детей. Теперь рассмотрим третий случай. Как мы видим от содержимого могут измениться параметры родительского элемента, что потребует его пересчета. Примеры 4 и 5.
    Таким образом от изменившегося элемента распространяется лавина reflow.

    Efficient JavaScript:
    As stated earlier, the browser may cache several changes for you, and reflow only once when those changes have all been made. However, note that taking measurements of the element will force it to reflow, so that the measurements will be correct. The changes may or may not not be visibly repainted, but the reflow itself still has to happen behind the scenes.

    This effect is created when measurements are taken using properties like offsetWidth, or using methods like getComputedStyle. Even if the numbers are not used, simply using either of these while the browser is still caching changes, will be enough to trigger the hidden reflow.
  • offsetHeight или нечаянный спуск лавины reflow
    0
    За сам пример - спасибо. Но если заменить top: -9999px на display:none то все по-прежнему работает. Какой тогда смысл использовать top: -9999px ?
  • offsetHeight или нечаянный спуск лавины reflow
    0
    за сам пример спасибо. Но если заменить top: -9999px на display:none, то все по прежнему работает. Какой смысл тогда использовать top: -9999px ?
  • offsetHeight или нечаянный спуск лавины reflow
    0
    хм, мне очень любопытно чем руководствовался человек поставивший минус комментарию. в статье ведь объясняется теория, объясняющая замедление. и это имеет отношние к любой библиотеке.
  • offsetHeight или нечаянный спуск лавины reflow
    0
    добавил еще одну страницу в статью с описанием этого решения.
  • offsetHeight или нечаянный спуск лавины reflow
    0
    Пожалуйста. :)
    Если честно, прочитав заметку Владимира Токмакова, я сразу же подумал, что предлагаемый им подход не оптимален из-за reflow. Но это наложилось на очередное заявление одного знакомого, который ссылается на Кодоводство, как на библию, и на Лебедева, как пророка ее. Вот я и решил аргументировано объяснить, что прислушиваться к советам великих нужно, но также нужно понимать разницу между безоговорочным доверием и осознанным согласием. Это было поводом. А что получилось в результате – Вы видите. ;) Отсюда такой странный заголовок. Всю остальную мораль я убрал, чтобы не портить статью, а заголовок забыл.

    На счет "оптимизаторства". Я учился программировать с ассемблера. Добивался, чтоб программки не тормозили на двойке с двумя метрами памяти и влезали в загрузочный сектор дискетки. Это наложило свой отпечаток на мое профессиональное развитие. Потом я изучил Си, затем Си++, но понимание того, как все устроено у компилятора внутри, было всегда. Затем я не мог принять интерпретируемые языки из-за того, что практически ни на что нельзя повлиять. Однако постепенно осознал, что скорость кода, в какой-то мере, допустимо приносить в жертву скорости разработки. Однако неоптимальный код я не могу писать до сих пор. Наверное, это стало чертой профессионального характера. А накопив багаж знаний по какому-либо языку или технологии, рефракторинг с целью оптимизации приходится проводить все реже.
  • offsetHeight или нечаянный спуск лавины reflow
    0
    да, спасибо, опечатка
  • offsetHeight или нечаянный спуск лавины reflow
    0
    а пример необходимости top: -9999px можно? я как-то никогда с таким не сталкивался. С visibility косяки у IE знаю, а с display не встречал
  • offsetHeight или нечаянный спуск лавины reflow
    0
    спасибо, опечатка.
  • offsetHeight или нечаянный спуск лавины reflow
    +1
    А если необходимо узнать виден ли вложеный элемент? Такое бывает в сложных приложениях (н-р контрол в соседнем табе). И если есть десятка два контролов, это становится очень неудобно.
    То, что я предложил в конце - это самое простое и правильное решение:
    если мы договоримся, что скрытые элементы должны иметь класс hide, то все сведется к определению наличия этого класса у элемента или его родителей.
  • Передача параметров в обработчики событий JavaScript
    0
    ну это я упоминал в первы строках моего коментария. Вопрос не в том, что замыкания неявно присутствуют везде, а в том, когда правильнее решать проблемы именно используя замыкания.
  • Передача параметров в обработчики событий JavaScript
    0
    Еще стоит отметить следующие применения: псевдо-private члены класса, функции-генераторы.
    что я еще забыл?
  • Передача параметров в обработчики событий JavaScript
    0
    http://www.terrainformatica.com/?p=9
    http://www.terrainformatica.com/?p=13

    любопытно, что оттуда убрали мои замечания в коментариях. написано "2 Comments", а нет ни одного.
  • Передача параметров в обработчики событий JavaScript
    0
    Замыкания (closures, delegates) – это одна из основных фишек JavaScript. Без нее реализация часто возможна только с использованием глобальных переменных, что на самом деле будет тем же самым замыканием, только не вокруг одной переменной, а вокруг всех переменных window. ;)

    Для чего применяется:
    - создать ссылку на вызов функции с параметрами (переданными при создании замыкания)
    - создать ссылку на вызов функции в контексте объекта

    Я использую вот такую функцию для создания замыканий:
    /**
    * Bind function to context
    * @param {Object|HTMLElement} context
    * @param {Function} fn
    * @return {Function} function bound to context
    */
    $.bind=function(context, fn /*args...*/)
    {
        if(typeof(context)=='function'){
            var args=Array.prototype.slice.call(arguments,0)
            args.unshift(null);
            return $.bind.apply(this, args);
        }

        if(arguments.length==2){    // params on call
            return function(){
                fn.apply(context||null, arguments);
            };
        }else{    // params on create
            var args=Array.prototype.slice.call(arguments,2);
            return function(){
                fn.apply(context||null, args.concat(Array.prototype.slice.call(arguments,0)));
            };
        }
    };

    Столько всего наворочено только для удобства использования и оптимизации.

    Самым простым вариантом будет такой:
    /// delegate bound params on create, if none params on call
    function delegate(that, thatMethod /*args...*/)
    {
        if(arguments.length==2)
            /// params on call
            return function(){ return thatMethod.apply(that,arguments); };

        /// params on create
        var args=Array.prototype.slice.call(arguments,2);
        return function(){ return thatMethod.apply(that,args); };
    }


    На счет расточительства: как асемблерщик – асемблерщика я вас понимаю. Говорят, что из-за ООП программы на C++ медленнее программ на C в 10000 раз. Но ведь давно уже никто не говорит, что использовать ООП – расточительно. JavaScript сам по себе быстрый. Узкие места обычно кроются в его связке с DOM.
  • Текст в перспективе
    0
    спасибо за карму. сегодня опубликую статью для публикации которой она мне была нужна.
  • Текст в перспективе
    0
    спасибо, понятно.
    т.е. тему для обсуждения сообществу я предложить не могу, а могу только участвовать в чужих дискуссиях. проблема в том, что активная дискуссия чаще всего длится меньше дня, а время для участия удается выбрать не всегда. на форумах, где активная тема всплывает вверх в этом смысле проще...