для небольших нагрузок, около 10-50 К грамотная файловая архитектура в разы лучше/легче/быстрее чем с использованием мускула. Правда как сие будет на фреймворке (ведь пых это всетаки фреймворк) - затрудняюсь. Для Perl/tcl - однозначно.
PS качественно написать рабуту файлового движка, безусловно, сложнее за очень-очень оправдано.
- Если небольшие фирмы поличили блок IP для себя, то они будут привязаны к Юридическому адресу. (основные изменения - это новые владельцы и/или новы преобретатели адресов)
- мелкие доморощенные провайдеры поглащаются крупными (возможны изменения географии и т.д.)
- припаркованные IP для физ-хостинга, меняют адрес вместе со сменой площадки.
- мобильные операторы (3G,WIFI и т.д.) пожераю все новые адреса в самых загадочных местах..
Вобщем получается что актуальность базы должна быть не страше 6 месяцев.
Директом последний раз пользовался очень-очень давно, посему и пропустил.
понимаете, я не спрашивал о технологии получения. Это как 2 пальца об асфальт
спасибо, пошел читать
можно простым
Встроенные фбиблиотеки PHP которые он наследовал от Perl имееют небольшую производительность. Да и с качеством у них проблемы. Очень рекомендую использовать ImageMagick
http://www.imagemagick.org/script/api.php
имхо конечно, но я все время и пытаюсь сказать, что смысл в стандарте будет только тогда, когда валидность (соотвествие стандарту) будет, пусть просто логическим, синонимом кросброузерности, как и наоборот. А пока эти 2 критерия кода между собой связаны не очень сильно.
это да, хотя, надеюсь согласитесь, не так много сайтов где есть такая необходимость.
вам часто это надо? тольок серьезно, не ради словца.
на мой взляд, это единственная причина, но гарантий того, что так не поступят с любым тегом так-же (вот уже ifarme стал мешать) - нет никаких.
к сожелению не смог найти аргументов. я тоже не нашел.
Вернее так - изголится можно в любом варианте, вот тольок причин это делать не могу найти. Зачем вместо самого простого и логичного варианта придумывать хитро...ные решения.
в помойку, очень надеюсь.
PS Такое ощущение что самые обычнве вещи теперь стало модно решать сугубо с использование CSS (конечно 3-го) и какого-нибудь фреймворка. Т.е. выполнить стандартную проверку силами самого JS - это уже не понтово.
где Вы такое увидели? Я какраз говорю о том, что каждый должен заниматься своим делом. Именно своим. Именно поэтому я противник готовых цмсок, которые позволяют людям, очень далеким от сайтостроения , делать сайты.
Не как ему нравится, а как нравится броузерам, которые его отображают. Стандарт который помагает, всячиски привествиую. От души. Просто на мой взгляд, тот набор рекомендаций, который сейчас ходит по свету:
HTML5
XHTML 1.0 Strict
XHTML 1.0 Transitional
HTML 4.01 Strict
HTML 4.01 Transitional
HTML 3.2
XHTML 1.1
XHTML Basic 1.0
XHTML Basic 1.1
XHTML 1.1 plus MathML 2.0
И это не полный список, при этом, в большинстве совем, просто набор воды, котору налили туда доля солидности. "Чем больше в книге воды, тем она глубже".
T.R.O.N добавил 06.07.2009 в 17:01
сделать могу и я. Я хотел именно готовые решения увидить. Те что видел, они уступают по компактности и красивости обычным, т.е. без излишего терзания стилей.
пока прав. Включите жесткое требование.
ну покажите тогда как многослойные рисуки делаются через CSS. Вы же бредите. Т.е. Вы предлагаете, просто ради валидности, создавать гемор к стилях и коде???
Вы еще упомените, что стили лучше иметь во внешнем файле. Безусловно, это красивее, пока не посмотрите на такое творение на небыстрых линях. Благо, и гугл и яша, изначально, о людях думаю, посему делат код своих страниц так, чтобы его было нормально видно...
пипец. Ну тогда объясните чем <font color="red">*</font> хуже чем <span class="...">*</span> для выделения единичного символа?
Знаеете, тут уж кто-то писал что делает все на дивах, так он даже вывод прайса так наваял. конечно, это жудко продвинутый способ, и не нужно было использовать эти "позорные таблицы".
Все должно использоваться там, где это удобно, а не там где модно.
Все просто. Варианта есть их 4.
1. То что вы называете стандартом (хотя это просто соглашение о взаимодействии) становится именно стандартом, т.е. имеет жеские требования.
2. броузеры отказываются от собственных парсеров, и все начинают использовать единый, который и стандартизируется (это же касается объектной модели, обработчиков объектов и т.д.)
3. Стандарт/соглашение убирает из своих недр все то, что было придуманно для солидности, но не влияет на основные критерии отображения.
4. Каждый, кому не лень, прекращает плодить свое (тот же FF, яша с его добавками как к HTML так и к роботсу и дале-дале).
