«Microfomats found at:» - это заголовок. а URL меньше потому что много символом. и акцент на ссылке не нужен. Пользователю и так понятно что за страницу он открыл. Теперь ему главное убедиться что это окно для микроформатов и какие микроформаты есть. по-моему все как раз так, как и должно быть
ух ты! здорово :) я как раз на днях думал о том что было бы неплохо иметь альтернативу google talk. - непривычный он какой-то. и не очень удобный, как по мне
прочитал с интересом. по ходу прочтения с некоторыми вещами был не согласен, только по окончанию понял что Вы говорили о ЦМС системах. Я не любитель таких вещей, в силу того что у меня уже есть достаточно большой опыт в разработке, наборы модулей и достаточно стабильные (многократно обкатанные) версии своих фрэимворков для PHP.
Я согласен в тем, что найти разработчика со знаниями известной ЦМС системы намного проще чем разработчика который сможет доработать кастомную систему. Но тут есть одно "но". в основном с ЦМС системами работают люди с малым опытом, поэтому найти человека который сможет что-то доработать Вам будет проще, но профессионал сможет работать с чем угодно. :) тут и разница - профессионал сделает лучше и подумает наперед.
ЦМС системы безусловно хороши для небольших проектов, при стандартных модулях и скромных аппетитов заказчика :)
Но как только аппетиты начнут расти, не факт что Ваша система будет по-прежнему удовлетворять Вашим потребностям. Например одно дело использовать Smarty в своем фрэимворке. А совсем другое дело использовать готовый движок. Проблема в том, что вы зависите от выранного Вами движка. и если сегодня вы запустите стартап на версии некоего движка 1.1, а завтра выйдет версия 2.0, несовместимая с предыдущими (что бывает достаточно часто), то Вы останитесь не у дел. и придется любыми силами переходить на 2.0 чтобы иметь возможность найти разработчиков знающих Вашу систему. Еще, довольно важный момент всех этих вещей - в любой момент может появиться security bug report на сайте разработчиков Вашего движка. И какие-нибудь недоброжелатели могут им воспользоваться. Имея кастомную систему (пусть намного более несовершенную), все тараканы останутся внутри, и как следствие Вы сможете быть более спокойны в плане безопасности существования Вашего проекта.
Я хочу еще привести несколько причин, почему разработчики предпочитают изобретать велосипеды, вместо использования готовых ЦМС систем. Я согласен, что зачастую на небольших проекта правильнее использовать готовые решения.
1. ЦМС системы, взять тот же eZ (пусть фанаты этого монстра не обижаются), но он жутко тормознутый
2. Для большого проекта, профессионалу лучше использовать хороший enterprise framework
3. банальное - разработчикам легче отвечать за свой код, чем за то что сделали не они (не хочется исправлять чужие баги, угадывать что думал разработчики движка и почему так, а тем более им не хочется разбираться с большой ЦМС, а это нужно, потому как они должны знать что, где, как и почему. для того чтобы в адекватные сроки быть в состоянии оказать поддержку)
4. ЦМС системы очень удобны снаружи и очень сложные и кривые внутри. Из-за большого количества модулей они намного медленнее переходят на более новые версии языков программирования и баз данных.
5. Часто, возможностей модулей недостаточно и их приходится расширять
6. У разработчиков могут быть свои серьезные, похожие наработки
Ну и в заключение, не все заказчики хотят чтобы их проекты делались на известных ЦМС. не знаю почему :) Но как мне кажется, популярные движки и их модули хотят использовать те кто хочет побыстрее и подешевле.
А в целом, статья мне понравилась, Ваш сайт я еще не смотрел, но обязательно загляну. Было бы интересо продолжить дискуссию, ведь в споре рождается истина
можно предложить пользователям специальные кнопки на страницах сайта с контентом типа + и -. вручную ограничить максимальный и минимальный размер. проблему это не решит. но в таком случае вы сможете увеличивать только размер текста который вы можете себе позволить. К примеру контент, а меню пусть остается как есть, чтобы не разъезжался дизайн. Я сам часто увеличиваю шрифт из-за достаточно большого разрешения монитора. Если бы везде были такие кнопки, я бы пользовался ими. я думаю частично это решит проблему.
неудивительно что гугл не прошел :) видимо "экономят трафик". у них даже кавычек нет в таких вещах как font size. да и все в перемешку css, js. я думаю гуглу выгодно так делать. потому как таким образом меньше данных будет передаваться от их самого развитого сервиса. а для него это должно быть достаточно существенно (хотя вопрос спорный), учитывая количество ежедневных запросов. ведь никто не сомневается что гугл мог бы исправить свою главную страницу. возможно, они еще не гоняются за этими стандартами дабы избежать проблем совместимостью с браузерами. а так все просто, и все должны браузеры должны скушать. хоть КПК-шные.
Вы счастливчик, что вам нужно работать только с ИЕ :) однако, у меня есть вопросы. Вы не думали о будущем? ведь, как тут ниже уже написали, Вы изобретаете велосипед. Как я понял опыта у Вас немного с javaScript, поэтому это должно было подтолкнуть к мысли найти готовые решения. я например предпочитаю prototype.js. А о будущем не подумали почему - тратите зря время на то что можно взять готовое и использовать. Вы не получите хоть сколько бы то ни было сравнимого результата с существующими open source наработками. + используя популярный open source вы можете расчитывать что они протестированы достаточно качественно, а это, по крайней мере, придаст Вам уверенности в плане совместимости. Или у Вас один проект на всю жизнь? будет следующий - нужен будет AJAX тот же. захотят эффекты. вы их тоже сами делать будете? захотят кросс-браузерность, хотя бы на Mozilla 2+, IE 6,7 & Opera 9+. сколько времени понадобится на то чтобы переписать все под них?
Теперь по вашим вопросам, по существу:
1. Ошибка 504. Вам не кажется что проблема не в AJAX а в нагрузке на сервер? Если процессор нагружен на 100%, как я понял из-за больших вычислений в БД, то мне кажется сбоит не javascript, а проблема действительно на стороне сервера
2. Неправильный порядок ответов. Вот если бы Вы использовали популярные наработки Open source, то знали бы о сущзествовании синхронных и асинхронных запросов :) и не было бы проблем с потерянными запросами по неизвестной причине и неправильного порядка ответов.
3. Советы: поставьте FireBug, Web Developer плагины для FireFox. Я понимаю что Вы используете IE, но эти вещи возможно помогут Вам выявлении причин неправильно работы
4. По реализации "Connection pool". Я не знаю как в двух словах описать алгоритм всего что Вам нужно. Но могу сказать что Вам придется активно исользовать setTimeOut с маленькими значениями для реализации асинхронных запросов. Стейты и некоторого рода инспекторы, которые будут за всем этим следить. Если есть более конкретные вопросы, я готов помочь чем смогу. Однако настоятельно Вам рекомендую использовать готовые, проверенные решения :) мне кажется Вам будет проще заменить свой велосипед на тот же prototype везде где нужно, чем сейчас и потом бороться со всеми этими проблемами :)
не поймите мой пост неправильно, я просто хочу дать Вам совет, и старался привести доводы, почему так лучше. а пользоваться им или нет - Ваше личное дело.
идея интересная, но мне почему-то кажется что с ее внедрением многие просто не будут пользоваться пунктами 1 и 4.
а еще, перед тем как добавлять фичи, нужно исправить баги (небольшой, но все же в бизнес-логике)
http://habrahabr.ru/blog/habrahabr_ideas/31089.html#comment521471
когда у меня будет "карма", если будет, то один из первых топиков которые я создам - это подборка глюков в крупных проектах. я думаю многим будет интересно :)
тот же куплет только румынская озвучка. вроде больше походит на правду :)
Я согласен в тем, что найти разработчика со знаниями известной ЦМС системы намного проще чем разработчика который сможет доработать кастомную систему. Но тут есть одно "но". в основном с ЦМС системами работают люди с малым опытом, поэтому найти человека который сможет что-то доработать Вам будет проще, но профессионал сможет работать с чем угодно. :) тут и разница - профессионал сделает лучше и подумает наперед.
ЦМС системы безусловно хороши для небольших проектов, при стандартных модулях и скромных аппетитов заказчика :)
Но как только аппетиты начнут расти, не факт что Ваша система будет по-прежнему удовлетворять Вашим потребностям. Например одно дело использовать Smarty в своем фрэимворке. А совсем другое дело использовать готовый движок. Проблема в том, что вы зависите от выранного Вами движка. и если сегодня вы запустите стартап на версии некоего движка 1.1, а завтра выйдет версия 2.0, несовместимая с предыдущими (что бывает достаточно часто), то Вы останитесь не у дел. и придется любыми силами переходить на 2.0 чтобы иметь возможность найти разработчиков знающих Вашу систему. Еще, довольно важный момент всех этих вещей - в любой момент может появиться security bug report на сайте разработчиков Вашего движка. И какие-нибудь недоброжелатели могут им воспользоваться. Имея кастомную систему (пусть намного более несовершенную), все тараканы останутся внутри, и как следствие Вы сможете быть более спокойны в плане безопасности существования Вашего проекта.
Я хочу еще привести несколько причин, почему разработчики предпочитают изобретать велосипеды, вместо использования готовых ЦМС систем. Я согласен, что зачастую на небольших проекта правильнее использовать готовые решения.
1. ЦМС системы, взять тот же eZ (пусть фанаты этого монстра не обижаются), но он жутко тормознутый
2. Для большого проекта, профессионалу лучше использовать хороший enterprise framework
3. банальное - разработчикам легче отвечать за свой код, чем за то что сделали не они (не хочется исправлять чужие баги, угадывать что думал разработчики движка и почему так, а тем более им не хочется разбираться с большой ЦМС, а это нужно, потому как они должны знать что, где, как и почему. для того чтобы в адекватные сроки быть в состоянии оказать поддержку)
4. ЦМС системы очень удобны снаружи и очень сложные и кривые внутри. Из-за большого количества модулей они намного медленнее переходят на более новые версии языков программирования и баз данных.
5. Часто, возможностей модулей недостаточно и их приходится расширять
6. У разработчиков могут быть свои серьезные, похожие наработки
Ну и в заключение, не все заказчики хотят чтобы их проекты делались на известных ЦМС. не знаю почему :) Но как мне кажется, популярные движки и их модули хотят использовать те кто хочет побыстрее и подешевле.
А в целом, статья мне понравилась, Ваш сайт я еще не смотрел, но обязательно загляну. Было бы интересо продолжить дискуссию, ведь в споре рождается истина
Теперь по вашим вопросам, по существу:
1. Ошибка 504. Вам не кажется что проблема не в AJAX а в нагрузке на сервер? Если процессор нагружен на 100%, как я понял из-за больших вычислений в БД, то мне кажется сбоит не javascript, а проблема действительно на стороне сервера
2. Неправильный порядок ответов. Вот если бы Вы использовали популярные наработки Open source, то знали бы о сущзествовании синхронных и асинхронных запросов :) и не было бы проблем с потерянными запросами по неизвестной причине и неправильного порядка ответов.
3. Советы: поставьте FireBug, Web Developer плагины для FireFox. Я понимаю что Вы используете IE, но эти вещи возможно помогут Вам выявлении причин неправильно работы
4. По реализации "Connection pool". Я не знаю как в двух словах описать алгоритм всего что Вам нужно. Но могу сказать что Вам придется активно исользовать setTimeOut с маленькими значениями для реализации асинхронных запросов. Стейты и некоторого рода инспекторы, которые будут за всем этим следить. Если есть более конкретные вопросы, я готов помочь чем смогу. Однако настоятельно Вам рекомендую использовать готовые, проверенные решения :) мне кажется Вам будет проще заменить свой велосипед на тот же prototype везде где нужно, чем сейчас и потом бороться со всеми этими проблемами :)
не поймите мой пост неправильно, я просто хочу дать Вам совет, и старался привести доводы, почему так лучше. а пользоваться им или нет - Ваше личное дело.
а еще, перед тем как добавлять фичи, нужно исправить баги (небольшой, но все же в бизнес-логике)
http://habrahabr.ru/blog/habrahabr_ideas/31089.html#comment521471
когда у меня будет "карма", если будет, то один из первых топиков которые я создам - это подборка глюков в крупных проектах. я думаю многим будет интересно :)