gordi: Всего-то - header и гориз. меню будут загружаться (появляться) после того, как загрузится контент.
а этот как раз не имеет значения
gordi: Время загрузки зависит от инфы и html-кода header'a и гориз. меню.
да хто же Вам такое на рассказывал?
gordi: Есть такие?
Ну ведь ранжирование определяется некой наборов параметров и их соотношениями. Значит есть. Только никто не сможет сказать ни чисел ни процентов. Только умозаключения.
да когда же Вы человеческими понятиями начнете мыслить... Откуда же такое жаление при виде мухи хвататься за артиллерию....
burunduk: а вот если фреймворк используется по максимуму то писать свою библиотеку (практически с теми же функциями) уже не кажется таким разумным
скажите, а разве за время Ваше работе с JS, до появления гквери, у Вас не появилось все необходимо и так?
burunduk, Когда человек знает основы, именно знает и понимает их, и когда задача оправдывает средства, уже не важно, что и как будет использоваться. Если же народ кидается изучать и использовать гквери не понимая что и как на самом деле происходит внутри (хотя-бы на уровне приблизительной модели)- это страшно. Потом появляются вопросы "если нужен AJAX нужно-ли знать JS".
PS Просто от себя, мне не нравится не модели выбранные в прототипе и гквери, ни то как они написаны. Это как машина, в одну садишся - "мое", а к другой и подходить не хочется, независимо от значка на радиаторе...
Такой пинг, по сути, должен указывать на rss/xml страницу. Если это есть, то будет полезно
bearman: зы: подумалось почему то - "при добавлении объявления ддосить яндекс" ))))))))))))
еще интересней можно, яшин бот, при отправке на него кривого XML выпадает по ошибке... У любой системы, обработка ошибок/исключений всегда требует большего ресурса чем штатная работа....
Ayavryk: К тому же известный баг - это не баг. Это фича.
Ну философия, это замечательно, как и чуство юмора. Но исправить свой баг - это дело нескольких часов, самое большее. Исправить гквери - =))) почти смешно.
На счет тестирования - это все от лукавого. Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
Ayavryk: но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
А кто же с этим спорит. Конечно, использовать собственные готовые наработки. Куда же без них. А на возможные собственные баги натягивать еще и баги чужие - зачем?
Ayavryk: которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО.
Ayavryk: Так ведь и php-программисты медленно но верно,......
Может, я пыхом очень стараюсь не пользоваться....
Ayavryk: Я всегда считал, что интерфейс всегда первичен.
Вот именно. Если так, то для Вас, скорее всего, фреймворки и полезны. На мой взгляд, достойный функционал и без сложного GU интерфейса(не путать с юзабельностью) будет и нужным и полезным
Но вот почему так - мне и интересно.
мускулы разные, разные файловые системы и соответственно, представления баз...
То что индекс значительно больше, возможно, зависит от количества переиндексаций или он остается на некотором пиковом значении...
Всетаки софтины разные стоят на виндах и никсах.
malls, он показывает размер или занимаемое место? Если второе, то все правильно
Скрипт работает достаточно долго.
а зачем такие скрипты вешать под WEB. Их лучше пускать асинхронно, а потом возвращать результаты юзеру.
Всего-то - header и гориз. меню будут загружаться (появляться) после того, как загрузится контент.
а этот как раз не имеет значения
Время загрузки зависит от инфы и html-кода header'a и гориз. меню.
да хто же Вам такое на рассказывал?
Есть такие?
Ну ведь ранжирование определяется некой наборов параметров и их соотношениями. Значит есть. Только никто не сможет сказать ни чисел ни процентов. Только умозаключения.
Ведь чем выше контент в конечном итоге и пользователю удобней.
на экране - да. В коде - а какая ему разница?
Пользователю будет удобно, если до загрузки стилей, страницу не будет карячить и все прыгать после их загрузки
T.R.O.N добавил 09.12.2009 в 17:42
В каких цифрах оное может быть выражено?
а яндекс_придуманных единицах
У вас баг на форме сообщения об ошибка
да когда же Вы человеческими понятиями начнете мыслить... Откуда же такое жаление при виде мухи хвататься за артиллерию....
а вот если фреймворк используется по максимуму то писать свою библиотеку (практически с теми же функциями) уже не кажется таким разумным
скажите, а разве за время Ваше работе с JS, до появления гквери, у Вас не появилось все необходимо и так?
burunduk, Когда человек знает основы, именно знает и понимает их, и когда задача оправдывает средства, уже не важно, что и как будет использоваться. Если же народ кидается изучать и использовать гквери не понимая что и как на самом деле происходит внутри (хотя-бы на уровне приблизительной модели)- это страшно. Потом появляются вопросы "если нужен AJAX нужно-ли знать JS".
PS Просто от себя, мне не нравится не модели выбранные в прототипе и гквери, ни то как они написаны. Это как машина, в одну садишся - "мое", а к другой и подходить не хочется, независимо от значка на радиаторе...
К примеру яндекс, http://blogs.yandex.ru/pings
Такой пинг, по сути, должен указывать на rss/xml страницу. Если это есть, то будет полезно
зы: подумалось почему то - "при добавлении объявления ддосить яндекс" ))))))))))))
еще интересней можно, яшин бот, при отправке на него кривого XML выпадает по ошибке... У любой системы, обработка ошибок/исключений всегда требует большего ресурса чем штатная работа....
К тому же известный баг - это не баг. Это фича.
Ну философия, это замечательно, как и чуство юмора. Но исправить свой баг - это дело нескольких часов, самое большее. Исправить гквери - =))) почти смешно.
На счет тестирования - это все от лукавого. Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
А кто же с этим спорит. Конечно, использовать собственные готовые наработки. Куда же без них. А на возможные собственные баги натягивать еще и баги чужие - зачем?
которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО.
Так ведь и php-программисты медленно но верно,......
Я всегда считал, что интерфейс всегда первичен.
Вот именно. Если так, то для Вас, скорее всего, фреймворки и полезны. На мой взгляд, достойный функционал и без сложного GU интерфейса(не путать с юзабельностью) будет и нужным и полезным