Да, просто цвет кодируется 1 байтом (вместо 3х или 4х), что дает 256 цветов.
А палитра получается индивидуальная для каждого png-файла, и хранится в нем вместе с картинкой.
+вроде бы в PNG возможны варианты кодирования цвета меньшим числом бит, соответственно уменьшается и палитра.
Похоже, что автор советов не понимает, как png работает, и советы дает эмпирические какие-то. Ну да, оптимизатор png использовать — это правильно и полезно.
Совет номер 1 — бред. В лучшем случае способ сжатия png (выбранный алгоритм) по умолчанию в какой-то программе. Или вообще какая-то психология, основанная на смутных воспоминаниях о том, что гиф градиенты вертикальные сжимать не умеет. С учетом последующего применения optipng какого-нибудь размеры файлов окажутся примерно одинаковыми. Отличия будут уже из-за особенностей конкретных картинок, удачности (с точки зрения алгоритмов png) цветовых переходов на стыках, и результат может оказаться как в пользу горизонтального изображения, так и в пользу вертикального.
Совет номер 2 — ничего не сказано про то, что это может оказаться сжатием с потерями. Насжимают начинающие верстальщики пнг с несколькими градиентами разных цветов в indexed mode, получат бяку. Догадайтесь почему называется.
Интересовал всегда шрифт Myriad Pro. С одной стороны, в википедии про него написано: Myriad Pro Regular, Bold, Italic, and Bold Italic are bundled with Adobe Reader 7.0 and higher.
А с другой, везде пишут, что его нет ни у кого, и правда он мало у кого есть. Хотя, по идее, Adobe Reader есть у очень многих.
Буду благодарен, если кто-нибудь разъяснит этот вопрос.)
Отсекать у людей с IE возможность закешировать данные не очень хорошо.
Лучше файл переименовывать. А еще лучше, чтобы он автоматически переименовывался. А еще лучше — организовать у себя нормальную системы сборки файлов, чтобы все нужные файлы собирались в 1, сжимались и переименовывались. В django для этого есть django-compress, например.
В том, что при перезапуске memcached (или переполнении отведенной ему памяти — там данные вытесняются) данные о сессии пропадут. Memcache — это кэш, а не постоянное хранилище данных, и сохранность он не гарантирует. Это не минус, это особенность. Ее следует иметь в виду и принимать меры, когда надо. Например такие, как в статье.
Угу, у меня так было с qcodo, потратил много времени зря, идея-то фреймворка вроде интересная, но по исполнению — поделка со всякими ужасами внутри. А в django все нравится, и в код внутри заглядывать не страшно совсем, постоянно заглядываю)
А Вы что думаете, файлы открываются просто так, и поиск по имени там не ведется что-ли?) Да те же самые индексы — хэши, деревья. Чудес не бывает)
БД лучше тем, что решение с БД масштабируется. А вот решение с файловой системой — нет. Скорость же сама по себе штука сложная, много от чего зависит, и говорить о ней абстрактно — бессмысленно, все лучше измерять и не верить своим прикидкам.
Там неясно, с какими параметрами запускалось все в обоих случаях, так что прямое сравнение бессмысленно проводить. Похоже, в mod_wsgi было 15 тредов на сайт, а с fapsw — 1 процесс на сайт, естественно сайт в первом случае занимал раз в 15 больше памяти.
Запустили бы mod_wsgi с одним процессом и 1 тредом, а статику отдавали бы ngnix'ом — было бы сравнение mod_wsgi и fapsw на одних настройках. И неизвестно, что бы оказалось лучше. В любом случае, разница была бы крошечная, думаю.
А что касается производительности — упирается все обычно уж точно не в способ организации wsgi-взаимодействия. Все эти тесты про 10000 запросов в секунду vs 1000 запросов в секунду имеют значение только для статики, в случае приложения, которое что-то делает, коннектится к базе той же, это просто абсолютно незаметная мелочь.
Миф о раздутости апача, думаю, во многом происходит от mod_php. Когда в каждый процесс апача, отдающий статику, встраивается такая бандура и быстро сжирает всю память, а потом запускаешь все на ngnix+fastcgi и радуешься жизни, осадочек-то остается.
Первое «но» — очевидное. На практике в веб-разработке «из ряда вон выходящая возможность» встречается все реже и реже. Может у меня как-то сознание замутилось к вечеру, но сейчас сходу пример выходящей из ряда вон возможности не придумывается.
Препятствие чаще в том, что человек может не знать, как сделать какую-либо вещь простым способом, используя фреймворк, даже когда этот способ существует. Да, фреймворк требуется изучать, и на это нужно время и умственные усилия. Это обычно сложнее, чем изобрести отдельный велосипед и сделать все в «лоб», т.к. требуется часто как-то свои взгляды пересматривать, перенимать стиль мышления чужих людей. Да, и тут такое дело, если фреймворк выбран неудачно — время может быть потрачено почти впустую. Но в случае удачно выбранного фреймворка потраченные усилия окупаются с лихвой.
Второе «но» — идеологическое. Если каждый будет постоянно изобретать велосипед, мы никуда не придем.
В джанге той же есть свои уродства и ограничения, чего уж. Например, невозможность в ORM использовать несколько БД одновременно. Но над этим работают (проект на GSoC), и когда-нибудь этот вопрос будет решен. Как и многие другие вопросы.
И именно благодаря объединению усилий в итоге веб-приложения становится писать легче и приятнее — люди не изобретают свои велосипеды по отдельности, а пробуют проверенное, и стараются сделать это «проверенное» лучше, если их что-то не устраивает, пишут патчи и сторонние приложения. Все это вместе образует инфраструктуру, которая призвана минимизировать написание одного и того же кода по многу раз разными разработчиками. Если в этом «вариться» и представлять, что уже написано и писать не надо, а что еще не написано и будет полезно всем, то первое — жизнь упрощается, т.к. не пишешь велосипеды, и второе — мир становится лучше, т.к. пишешь и выкладываешь во всеобщее достояние то, чего там еще нет.
А палитра получается индивидуальная для каждого png-файла, и хранится в нем вместе с картинкой.
+вроде бы в PNG возможны варианты кодирования цвета меньшим числом бит, соответственно уменьшается и палитра.
Совет номер 1 — бред. В лучшем случае способ сжатия png (выбранный алгоритм) по умолчанию в какой-то программе. Или вообще какая-то психология, основанная на смутных воспоминаниях о том, что гиф градиенты вертикальные сжимать не умеет. С учетом последующего применения optipng какого-нибудь размеры файлов окажутся примерно одинаковыми. Отличия будут уже из-за особенностей конкретных картинок, удачности (с точки зрения алгоритмов png) цветовых переходов на стыках, и результат может оказаться как в пользу горизонтального изображения, так и в пользу вертикального.
Совет номер 2 — ничего не сказано про то, что это может оказаться сжатием с потерями. Насжимают начинающие верстальщики пнг с несколькими градиентами разных цветов в indexed mode, получат бяку. Догадайтесь почему называется.
А с другой, везде пишут, что его нет ни у кого, и правда он мало у кого есть. Хотя, по идее, Adobe Reader есть у очень многих.
Буду благодарен, если кто-нибудь разъяснит этот вопрос.)
А еще фигня в том, что «для себя» математику никто учить не будет)
Поэтому для меня — главный.
А то у яндекса есть, у гугла есть, у рамблера есть, а у мейл.ру нет.
Лучше файл переименовывать. А еще лучше, чтобы он автоматически переименовывался. А еще лучше — организовать у себя нормальную системы сборки файлов, чтобы все нужные файлы собирались в 1, сжимались и переименовывались. В django для этого есть django-compress, например.
БД лучше тем, что решение с БД масштабируется. А вот решение с файловой системой — нет. Скорость же сама по себе штука сложная, много от чего зависит, и говорить о ней абстрактно — бессмысленно, все лучше измерять и не верить своим прикидкам.
раздражают выпадающие-пропадающие менюшки и подсказки.
удачи.
Там неясно, с какими параметрами запускалось все в обоих случаях, так что прямое сравнение бессмысленно проводить. Похоже, в mod_wsgi было 15 тредов на сайт, а с fapsw — 1 процесс на сайт, естественно сайт в первом случае занимал раз в 15 больше памяти.
Запустили бы mod_wsgi с одним процессом и 1 тредом, а статику отдавали бы ngnix'ом — было бы сравнение mod_wsgi и fapsw на одних настройках. И неизвестно, что бы оказалось лучше. В любом случае, разница была бы крошечная, думаю.
А что касается производительности — упирается все обычно уж точно не в способ организации wsgi-взаимодействия. Все эти тесты про 10000 запросов в секунду vs 1000 запросов в секунду имеют значение только для статики, в случае приложения, которое что-то делает, коннектится к базе той же, это просто абсолютно незаметная мелочь.
Миф о раздутости апача, думаю, во многом происходит от mod_php. Когда в каждый процесс апача, отдающий статику, встраивается такая бандура и быстро сжирает всю память, а потом запускаешь все на ngnix+fastcgi и радуешься жизни, осадочек-то остается.
Но у меня есть 2 «но».
Первое «но» — очевидное. На практике в веб-разработке «из ряда вон выходящая возможность» встречается все реже и реже. Может у меня как-то сознание замутилось к вечеру, но сейчас сходу пример выходящей из ряда вон возможности не придумывается.
Препятствие чаще в том, что человек может не знать, как сделать какую-либо вещь простым способом, используя фреймворк, даже когда этот способ существует. Да, фреймворк требуется изучать, и на это нужно время и умственные усилия. Это обычно сложнее, чем изобрести отдельный велосипед и сделать все в «лоб», т.к. требуется часто как-то свои взгляды пересматривать, перенимать стиль мышления чужих людей. Да, и тут такое дело, если фреймворк выбран неудачно — время может быть потрачено почти впустую. Но в случае удачно выбранного фреймворка потраченные усилия окупаются с лихвой.
Второе «но» — идеологическое. Если каждый будет постоянно изобретать велосипед, мы никуда не придем.
В джанге той же есть свои уродства и ограничения, чего уж. Например, невозможность в ORM использовать несколько БД одновременно. Но над этим работают (проект на GSoC), и когда-нибудь этот вопрос будет решен. Как и многие другие вопросы.
И именно благодаря объединению усилий в итоге веб-приложения становится писать легче и приятнее — люди не изобретают свои велосипеды по отдельности, а пробуют проверенное, и стараются сделать это «проверенное» лучше, если их что-то не устраивает, пишут патчи и сторонние приложения. Все это вместе образует инфраструктуру, которая призвана минимизировать написание одного и того же кода по многу раз разными разработчиками. Если в этом «вариться» и представлять, что уже написано и писать не надо, а что еще не написано и будет полезно всем, то первое — жизнь упрощается, т.к. не пишешь велосипеды, и второе — мир становится лучше, т.к. пишешь и выкладываешь во всеобщее достояние то, чего там еще нет.
Тьфу, пафосно вышло, ну и ладно)