Нет. Редиректить с domain.ru на www.domain.ru. Тогда статику можно грузить с img.domain.ru не волнуясь о куках. Хотя, надо признать, что по поводу www - это только мысли. Я не питаю особой любви к ццц, но, повторюсь, в этом контексте префикс приобретает хоть какой-то смысл.
Меня некоторое время уже мучает одна мысль. Заключается она в том, чтобы перестать регистрировать домены второго уровня на каждый чих. Например, пусть существует организация с условным названием futurico (стоп, это же не условное название? ну неважно). Пусть она покупает домен futurico.ru. Затем если организация открывает проект с условным (ну вот, опять) названием habrahabr, то она не заботится о покупке домена второго уровня, а просто делает домен третьего уровня habrahabr.futurico.ru. В таком подходе есть несколько вполне очевидных преимуществ:
1. Появляется namespace. Это поможет пользователям понять, что проект принадлежит компании futurico и, кроме того, снижается вероятность misspelling-а адреса, стоимость решения этой проблемы со стороны организации и у киберсквоттеров остается уже куда меньше поводов скупать похожие домены вроде habrhabr.ru
2. Наконец, это позволяет без дополнительных затрат решить проблему запроса статики с сервера. Одной из проблем, в данном случае, является отправка пользователем cookies на сервер. Если статика расположена на img.habrahabr.ru, а область применения cookies на сайте указывается *.habrahabr.ru, то несчастные байты будут раз за разом отсылаться при каждом обращении к img.habrahabr.ru. Различные тесты доказали, что это способно существенно снизить скорость загрузки сайта у пользователя (материалы по оптимизации фронт-энда, кстати, были на хабре). В то же время, если мы размещаем ресурс на habrahabr.futurico.ru и грузим статику с img.futurico.ru подобных проблем у нас не возникает. Конечно, можно купить для статики отдельный домен (как сделал Яндекс), но мы от этого ничего не выигрываем, а пристижность доменов второго уровня, как было отмечено в статье - сомнительна.
Идея с миллионом пикселов сработала потому, что людям предложили купить то, что раньше никто никогда не предлагал покупать. Это было необычно, это был отличный маркетинг. И опять таки, если бы об этой идее не узнали миллионы пользователей сети, несколько сотен покупателей никогда бы не купили эти несчастные пикселы.
так и вижу заголовки на хабре: автор блога про куннилингус разбогател на читателях.
---
нравится читать мои смешные заметки про куннилингус? please donate.
У этой теории есть один недостаток. Она не говорит, каким образом появляется эта тысяча фанатов. Тысяча фанатов не может взяться из ниоткуда - она появляется из миллионов людей, которым просто нравится то, что вы делаете. Я допускаю, что могут быть исключения, как и везде, но тогда стоило бы упомянуть в посте именно эти исключения, а не Nine Inch Nails-ов, которые стадионы собирают.
Давайте начнем с другого. Назовите хотя бы одну реальную проблему, которая может возникнуть, если в css не указывать кодировку? Договоримся, что по дефолту мы не пишем кириллические комментарии в css.
Все-таки, несмотря на кажущуюся вкусность самой идеи коворкинга, у нее есть минусы. Об организационных минусах упомянул автора поста. Мне же пришло в голову следующее:
1. Эффективность работы, на самом деле, понижается, ведь каждый работает над своими собственными проектами, но при этом еще отвлекается на общение.
2. Чему-то научиться друг у друга можно только, если хотя бы еще один человек в команде занимается тем же, чем и ты (ведь если один программирует на Ruby, а другой пишет на Сидиезе - это прекрасно, но вряд ли будет слишком полезно обоим, просто потому, что направления применения языков разные).
3. Эффективно работать за одним столом - невозможно. У человека должно быть личное пространство. Меня не радует перспектива быть жестоко прерванным чьей-то репликой, когда мой мозг будет обдумывать сложную функцию.
Если бы мне хотелось работать в коллективе, чему-то научиться и при этом сохранять личную свободу, я бы взялся делать стартап: можно было бы договориться еще с кем-нибудь и снимать офис для своей группы например на 2 дня в неделю. Это позволило бы сильно сократить расходы, оптимизировать общение друг с другом до минимально необходимого и оставить время на персональную медитацию над проектом в домашних условиях... и вообще на любые другие дела.
Вы просто обсуждать собираетесь или уже готовы "съехаться"? Надо хотя бы примерно назвать стартовые затраты и ежемесячные, чтобы пришли только те, кто это потянет.
1. Появляется namespace. Это поможет пользователям понять, что проект принадлежит компании futurico и, кроме того, снижается вероятность misspelling-а адреса, стоимость решения этой проблемы со стороны организации и у киберсквоттеров остается уже куда меньше поводов скупать похожие домены вроде habrhabr.ru
2. Наконец, это позволяет без дополнительных затрат решить проблему запроса статики с сервера. Одной из проблем, в данном случае, является отправка пользователем cookies на сервер. Если статика расположена на img.habrahabr.ru, а область применения cookies на сайте указывается *.habrahabr.ru, то несчастные байты будут раз за разом отсылаться при каждом обращении к img.habrahabr.ru. Различные тесты доказали, что это способно существенно снизить скорость загрузки сайта у пользователя (материалы по оптимизации фронт-энда, кстати, были на хабре). В то же время, если мы размещаем ресурс на habrahabr.futurico.ru и грузим статику с img.futurico.ru подобных проблем у нас не возникает. Конечно, можно купить для статики отдельный домен (как сделал Яндекс), но мы от этого ничего не выигрываем, а пристижность доменов второго уровня, как было отмечено в статье - сомнительна.
---
нравится читать мои смешные заметки про куннилингус? please donate.
Трудное сделать привычным,
Привычное сделать легким,
Легкое сделать красивым.
и никак иначе.
1. Эффективность работы, на самом деле, понижается, ведь каждый работает над своими собственными проектами, но при этом еще отвлекается на общение.
2. Чему-то научиться друг у друга можно только, если хотя бы еще один человек в команде занимается тем же, чем и ты (ведь если один программирует на Ruby, а другой пишет на Сидиезе - это прекрасно, но вряд ли будет слишком полезно обоим, просто потому, что направления применения языков разные).
3. Эффективно работать за одним столом - невозможно. У человека должно быть личное пространство. Меня не радует перспектива быть жестоко прерванным чьей-то репликой, когда мой мозг будет обдумывать сложную функцию.
Если бы мне хотелось работать в коллективе, чему-то научиться и при этом сохранять личную свободу, я бы взялся делать стартап: можно было бы договориться еще с кем-нибудь и снимать офис для своей группы например на 2 дня в неделю. Это позволило бы сильно сократить расходы, оптимизировать общение друг с другом до минимально необходимого и оставить время на персональную медитацию над проектом в домашних условиях... и вообще на любые другие дела.