«Давайте, наконец, слезем с кресел-каталок, и пойдем с костылями! Да, на кресле конечно больше удобств, зато с костылями больше шансов по настоящему...» — тут подставьте своё
Этот комментарий сделал статью более понятной. Как-то упустил из вида, что информация о промежуточных точках не сохраняется. Видимо да, тогда алгоритмы сжатия не сравнимы с SwingingDoor в общем случае (лишь в конкретных), поскольку алгоритм скорей относится к фильтрации значений, и в меньшей степени — к компрессии. Все равно статья познавательна. Спасибо :)
Это тогда перед их показом надо будет на лету «разжимать».
SwingingDoor тоже требуется декодировать. В зависимости от степени сжатия gzip может оказаться не столь уж и тормозным, по сравнению со SwingingDoor. Хотя думаю, все будет зависеть от самих данных: если меняются скачкообразно и часто, то тут преимущества перед gzip большого не будет. Или как на практике?
Именно «just for fun» :) Интересно ведь, насколько специализированные алгоритмы быстрей алгоритмов сжатия общего назначения. Сравнивая SwingingDoor с gzip можно будет сказать, что «сжатие с потерями более чем в 10 раз эффективнее lossless алгоритма». Если же только в полтора, невольно задумаешься, может быть не стоило терять точность результата, тем более специально для этого переводя цифры в плавающую точку.
Устроим конкурс, кто на предоставленных сырых данных может предоставить лучший алгоритм сжатия? :) Во всяком случае, не смотрели, как жмет gzip/bzip2 алгоритм, к примеру? Насколько они будут менее успешны? Подразумевается, что жать данные нужно порциями, чтобы иметь возможность быстрой перемотки.
мне кажется, что либо нужно четко ограничить рамки решаемых задач, представив систему в виде DSL, либо гибкая модульная система будет стремиться превратиться в еще один язык программирования. У вас нет ни слова о ограничениях, поэтому скорей всего ваш проект последует второму пути развития, часто дублируя существующий функционал над-стоящего языка (к примеру взять Smarty — результат достигается тот же, что можно достигнуть на чистом PHP, но через описание других концептов).
самая модульная система, это язык программирования, поддерживающий модульность :)
Приведенные onBefore/onAfter, кстати, давно составляют основу концепции АОП, или вместо них используются функции-обертки. Так что в верном направлении двигаетесь. Надо лишь развить идею немного больше, чтобы она стала считаться оригинальной.
Похоже на правду. Ведь частота такого CPU близка к частоте работы памяти — тогда зачем ему кеш первого уровня, работающий на частоте процессора. А вот с предсказанием ветвений — получается, что эти блоки архитектурно похожи на работу кеш-памяти? Или цена промаха низка, и поэтому их повыкидывали?
тогда это два с половиной, а не три… А почему нельзя заставить работать высокочастотное ядро на низких частотах? Есть какое-то костылеобразное препятствие?
> Валидация форм на стороне клиента теперь станет намного проще — хоть и, понятное дело, всецело полагаться на нее все равно нельзя; нужно не забывать проверять данные и на стороне клиента сервера.
Как бы ни сказал Киса Воробьянинов: да… уж...! Если не секрет, то каким путеводителем пользовались при переводу в карту машкодов? Не верится, что такой код генерирует не оптимизирующий компилятор :)
На правах конкуренции в рекламе предлагаю посмотреть еще TrackStudio. Это также одна из простых и наиболее мощных систем. Насчет топика: завидую немного, поскольку также ощущаю важность этого вида инструментария. Общение между людьми всегда одна из самых затратных частей любого проекта (не только для гиков ;). А тем более с территориальным разнесением вовсе становится непробиваемой стеной для бизнеса. Молодцы! Только дайте скриншоты полистать. Может что-то пригодится задней части мозга :)
> Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5…
Эта библиотека скорей всего относится к неподдерживаемому более коду. Кстати, покуда работал с множеством функций cryptohash мне тоже нравилось адресоваться к ним с использованием фасетного метода классификации. Но предлагаемая схема не подойдет в качестве универсального приема для любого функционала, даже для того же шаблона Strategy.
В чем действительно безоговорочно согласен, что удобство ООП ярче выражено там, где оно само напрашивается: добавляя к документированному коду интуитивность восприятия.
«мериться» от слова «мера»
SwingingDoor тоже требуется декодировать. В зависимости от степени сжатия gzip может оказаться не столь уж и тормозным, по сравнению со SwingingDoor. Хотя думаю, все будет зависеть от самих данных: если меняются скачкообразно и часто, то тут преимущества перед gzip большого не будет. Или как на практике?
Приведенные onBefore/onAfter, кстати, давно составляют основу концепции АОП, или вместо них используются функции-обертки. Так что в верном направлении двигаетесь. Надо лишь развить идею немного больше, чтобы она стала считаться оригинальной.
клиентасервера.так правильней?
«Ну и кому они нафиг нужны?!» © Ави из Snatch :)
В смысле: уже прекрасно научились обходиться без них. Иногда их не используют сознательно поскольку остается еще много неадминистрируемых серверов со старым php < 5.3.0.
> Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5…
Эта библиотека скорей всего относится к неподдерживаемому более коду. Кстати, покуда работал с множеством функций cryptohash мне тоже нравилось адресоваться к ним с использованием фасетного метода классификации. Но предлагаемая схема не подойдет в качестве универсального приема для любого функционала, даже для того же шаблона Strategy.
В чем действительно безоговорочно согласен, что удобство ООП ярче выражено там, где оно само напрашивается: добавляя к документированному коду интуитивность восприятия.