мне кажется, «вехикл» тут не менее понятно, чем «виикл».
(опять же, зависит от целевой аудитории — иностранец может не понять 1-й вариант, большинство наших сограждан — 2-й).
$avtomobil это зло по той же причине — такая же мешанина языков, только письменная.
> Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова
это вполне естественно.
зачем при общении на русском языке использовать американские/английские/какие-то еще нормы произношения?
если коллеги/заказчики зарубежные, то вопросов нет, в этом смысле топик весьма полезен.
но дикая смесь языков вида «пишу на эйч-ти-эм-эл за еду» или «есть багз в некоторых браузэс на тест сёрвэ» ничуть не менее труднопонимаема и безграмотна, чем «уилл код ха-тэ-эм-эл фо фуд».
тогда уж полностью на английский переходить.
речь шла о первоначальном варианте с аякс запросом по загрузке, который не параллелится с загрузкой остальной статики.
в варианте со <script src=«storage.php»> все уже не так плохо.
но от лишних запросов к php все же есть смысл избавляться вовсе, если есть возможность это делать (см. первый коммент), сравните, сколько раз в секунду сервер может отдать статичный файл, а сколько — даже пустую страницу, сгенерированную php.
так у вас «один интернет-магазин» или полноценное full-ajax приложение?
если все приложение можно запихнуть в одну страницу и намертво ее закэшировать на клиенте это одно.
если же это более традиционный сайт с массой статичных страниц с динамическим блоком на каждой — все их в кэш пользователю не засунуть, получаем при переходах по сайту те самые 2 запроса на страницу.
у чисто клиентского хранилища есть большой недостаток — его никак не почистить с сервера, если данные вдруг устареют.
если это не критично, то конечно такой вариант лучше, т.к. вообще никаких запросов не делается.
но раз уж все равно дергать php каждый раз, всегда можно обойтись одним запросом вместо двух — например, взять общий для всех закэшированный код оболочки и подставить туда данные из сессии.
(хотя бы просто в конец дописать через <script>)
до громоздкого приложения запрос в любом случае не долетит, зато клиенту не надо будет делать еще один запрос, который начинает выполняться только после полной загрузки оболочки.
серверу все равно, а скорость загрузки для клиента будет заметно выше.
получение списка ID товаров из cookie;
запрос в БД, из которой возвращалось название товара, его стоимость и прочие необходимые данные;
использование шаблонизатора (Smarty) для генерирование блока корзины на ряду с генерацией остального содержимого.
прекрасно решаются простейшим кэшированием HTML всего блока на стороне сервера по ключу, равному этой самой cookie.
даже сессии не нужны, обычный apc/memcache или что там на его месте.
если хочется оболочку жестко закэшировать — можно в процессе генерации кэша корзины выносить его содержимое в какой-нибудь "cache/" . md5($cart_cookie) . ".js" и его грузить на клиенте (адрес жаваскриптом вычислять по той же куке)
будет замечательный статичный файл вообще без всякого php, только периодически надо убивать старые файлы.
иначе никакого смысла в оптимизации оболочки нет — у вас все равно на каждой странице запрос к php.
можно пойти еще дальше и даже добавление/удаление в корзину делать чисто на клиенте, исправлением куки прямо из js; но тогда надо на cache/*.js еще обработчик 404 повесить, чтобы он перегенерировал кэш для нового значения куки.
по умолчанию bump версии в информации о совместимости происходит автоматически, авторам аддонов никаких телодвижений совершать не надо, если конечно, совместимость действительно есть.
я на это напоролся в ходе использования скрипта fileuploader.js, который по сути делает то же, что в статье написано.
при загрузке мелких файлов все ок, при попытке залить файл на 200M php умирает из-за превышения memory_limit (стоял 512M).
собственно, содержание серверного скрипта роли вообще не играет, можно <?php echo memory_get_usage();?> в качестве upload.php поставить и посмотреть вживую.
при загрузке файла на 100K расход памяти где-то 400K, при загрузке 5.6M — уже 17M.
php5.3.6, apache2+mod_php, ось debian 6.0 / win7.
насколько я понимаю, проблема в том, что скрипт начинает исполняться только после полного получения тела запроса от клиента.
в случае обычного multipart/form-data php на ходу раскладывает все загружаемые файлы в свой upload_tmp_dir, и в $_FILES пишет только пути к ним, при нестандартной же кодировке запроса php не знает, что с ним делать и все тело висит в памяти.
вот зачем ему аж три копии — хз, в $HTTP_RAW_POST_DATA одна точно есть.
уважаемые «юзабилисты»!
выкладывание в pdf текста, верстка которого ничуть не сложнее обычного поста на хабр чем-то напоминает фразу про сапожника без сапог.
а для друзей, у которых нет жаббера, есть вконтактик, который себе можно отдельным жаббер-аккаунтом в миранде подключить и на сам сайт не заходить вообще.
(для меня это выглядит как обычная переписка через жаббер, для них — обычная переписка через интерфейс сайта)
аськой 2.5 года уже не пользуюсь, удивляет, что оно еще шевелится.
что далеко ходить, возьмем тот же хабр, а именно полоску над этим самым комментарием.
если высокое dpi на мониторе, плохое зрение (или зачем там еще размер шрифта менять), то ник, дату, значки # и ↑ увеличивать надо, а иконки-ссылки избранного и голосования пусть так и остаются крошечными, что ли?
кстати, из всех популярных браузеров пункт «размер шрифта» в меню остался разве что в IE.
изобретал свой язык разметки — аналог markdown, более приспособленный для русской раскладки.
по сей день вполне успешно используется на одном форуме, почти полностью вытеснив традиционные бб-коды (оставленные как альтернативный вариант форматирования на выбор пользователя).
флеш и жава — это, все ж таки, плагины.
и разработчики браузеров не шибко много с ними сделать могут.
а тут получилось, они сами еще один вектор атаки создают.
вот и засуетились.
(опять же, зависит от целевой аудитории — иностранец может не понять 1-й вариант, большинство наших сограждан — 2-й).
$avtomobil это зло по той же причине — такая же мешанина языков, только письменная.
это вполне естественно.
зачем при общении на русском языке использовать американские/английские/какие-то еще нормы произношения?
если коллеги/заказчики зарубежные, то вопросов нет, в этом смысле топик весьма полезен.
но дикая смесь языков вида «пишу на эйч-ти-эм-эл за еду» или «есть багз в некоторых браузэс на тест сёрвэ» ничуть не менее труднопонимаема и безграмотна, чем «уилл код ха-тэ-эм-эл фо фуд».
тогда уж полностью на английский переходить.
в варианте со <script src=«storage.php»> все уже не так плохо.
но от лишних запросов к php все же есть смысл избавляться вовсе, если есть возможность это делать (см. первый коммент), сравните, сколько раз в секунду сервер может отдать статичный файл, а сколько — даже пустую страницу, сгенерированную php.
если все приложение можно запихнуть в одну страницу и намертво ее закэшировать на клиенте это одно.
если же это более традиционный сайт с массой статичных страниц с динамическим блоком на каждой — все их в кэш пользователю не засунуть, получаем при переходах по сайту те самые 2 запроса на страницу.
если это не критично, то конечно такой вариант лучше, т.к. вообще никаких запросов не делается.
но раз уж все равно дергать php каждый раз, всегда можно обойтись одним запросом вместо двух — например, взять общий для всех закэшированный код оболочки и подставить туда данные из сессии.
(хотя бы просто в конец дописать через <script>)
до громоздкого приложения запрос в любом случае не долетит, зато клиенту не надо будет делать еще один запрос, который начинает выполняться только после полной загрузки оболочки.
серверу все равно, а скорость загрузки для клиента будет заметно выше.
прекрасно решаются простейшим кэшированием HTML всего блока на стороне сервера по ключу, равному этой самой cookie.
даже сессии не нужны, обычный apc/memcache или что там на его месте.
если хочется оболочку жестко закэшировать — можно в процессе генерации кэша корзины выносить его содержимое в какой-нибудь
"cache/" . md5($cart_cookie) . ".js"и его грузить на клиенте (адрес жаваскриптом вычислять по той же куке)будет замечательный статичный файл вообще без всякого php, только периодически надо убивать старые файлы.
иначе никакого смысла в оптимизации оболочки нет — у вас все равно на каждой странице запрос к php.
можно пойти еще дальше и даже добавление/удаление в корзину делать чисто на клиенте, исправлением куки прямо из js; но тогда надо на cache/*.js еще обработчик 404 повесить, чтобы он перегенерировал кэш для нового значения куки.
при загрузке мелких файлов все ок, при попытке залить файл на 200M php умирает из-за превышения memory_limit (стоял 512M).
собственно, содержание серверного скрипта роли вообще не играет, можно <?php echo memory_get_usage();?> в качестве upload.php поставить и посмотреть вживую.
при загрузке файла на 100K расход памяти где-то 400K, при загрузке 5.6M — уже 17M.
php5.3.6, apache2+mod_php, ось debian 6.0 / win7.
насколько я понимаю, проблема в том, что скрипт начинает исполняться только после полного получения тела запроса от клиента.
в случае обычного multipart/form-data php на ходу раскладывает все загружаемые файлы в свой upload_tmp_dir, и в $_FILES пишет только пути к ним, при нестандартной же кодировке запроса php не знает, что с ним делать и все тело висит в памяти.
вот зачем ему аж три копии — хз, в $HTTP_RAW_POST_DATA одна точно есть.
компаратор можно сделать как a[i], a[j] = min(a[i], a[j]), max(a[i], a[j]), min и max без if-ов вполне реализуются, например так:
выкладывание в pdf текста, верстка которого ничуть не сложнее обычного поста на хабр чем-то напоминает фразу про сапожника без сапог.
(для меня это выглядит как обычная переписка через жаббер, для них — обычная переписка через интерфейс сайта)
аськой 2.5 года уже не пользуюсь, удивляет, что оно еще шевелится.
если высокое dpi на мониторе, плохое зрение (или зачем там еще размер шрифта менять), то ник, дату, значки # и ↑ увеличивать надо, а иконки-ссылки избранного и голосования пусть так и остаются крошечными, что ли?
кстати, из всех популярных браузеров пункт «размер шрифта» в меню остался разве что в IE.
по сей день вполне успешно используется на одном форуме, почти полностью вытеснив традиционные бб-коды (оставленные как альтернативный вариант форматирования на выбор пользователя).
www.mydigitallife.info/2011/03/10/fix-firefox-4-fade-blur-bold-bad-and-ugly-font-rendering/
шрифты все равно рендерятся иначе, чем в фф3, но уже не настолько вырвиглазно.
про последние ("(?<=expr)", "(?<!expr)"), кстати, вообще не упомянуто.
xseksx.ru/x/40/dl/480/otkritka.jar
там все оказалось чуть посложнее, чем один main class, я из-за этих спамеров час убил, чтобы выковырять номерки и тексты ^^
и разработчики браузеров не шибко много с ними сделать могут.
а тут получилось, они сами еще один вектор атаки создают.
вот и засуетились.