Wott

Такое было в рамках развития концепции адаптивной верстки — в зависимости от размеров экрана показывать разный layout и, соответственно, разный размер картинок

Но перекидывать на лету умеет большинство сайтов и в этом нет ничего для нового проекта :)

Есть хорошая обертка — MultiCurl от Vadym Timofeyev <tvad@mail333.com>

слепая печать, приходиться набирать ОЧЕНЬ много текста, стирать и снова набирать
арифметика, часто приходиться считать +1-1+1-1, редко больше
хорошая память — переменные, вызовы — все что написал надо помнить
тренированная задница и мочевой пузырь — часа два-три сидеть на одном месте, полностью отвлекаясь от материального, чревато

а если серьезно то различные теории помогают либо при обдумывании архитектуры либо при анализе багов.
При написании кода важнее простые ( перечисленные выше ) навыки

Если дизайнером не уточнено, я показываю сообщение поверх поля чуть выше ( иногда ниже ) и правее, что бы можно было в поле мышкой ткнуть. Как только поле в фокусе его сообщение исчезает.

добавлю от себя — если это авторский блог или комменты суть вопрос-ответ, то двухуровневая структура рулит
иначе 1 2 1

не понятно зачем иметь 4 таблицы для похожих сущностей — post,news,special, special_page. Если ихъ обьеденить, то сразу вопрос с комментами отвалится.

имхо очень плохая практика иметь безликие id, name — лучше иметь blog_id, post_name и сразу все понятно без разглядывания схем или ключей

какие тут работы? сверстать 3 страницы. Я беру 50$ за страницу, кто-то сделает и дешевле.

все остальное на самом деле опционально. какой CMS или какой язык тут не важно, потому что если верстается под какое-то конкретное окружение, то на выходе уже готовый шаблон для страницы и разница в цене тут только понты в конкретном комьюнити.
А поскольку динамики нет ( ну конечно ее можно приделать, например каталог не рисовать вручную ) то что там после верстки вообще не важно. Если не планируется потом это расширять, то стоит смотреть в сторону удобной админки, а не языка.

Я считаю что REST APi должен очень простым и понятным, но действительно сложными представлениями я пока не рулил.

В качестве доки я обычно даю минимальный пример взаимодействия в котором комментирую необходимые действия и привожу должные ответы от сервиса. В принципе наверно можно найти тулзу которая приведет код примера к красивому html, но это скорее вопрос генерирования док вообще а не для api.

Смотря для чего:
На ранних стадиях разработки — генератор данных или рыба.
На стадии саппорта — обезличенные реальные данные, потому что юзеры придумывают такое что нормальные люди предусмотреть могут не всегда.

Да и не стоит пытаться пресечь доступ к реальным данным. Программист держит в руках код и может вставить туда все что угодно и получить соответствующий доступ. Это вопрос доверия, который надо решать сразу. В крайнем случае настройте слежение за работой сайта так что бы выявить несанкционированный доступ.

Само по себе это ничего не дает ни во времени загрузки ( online event даже позже случается ) ни в скорости загрузки.
Но в комплексе это очень хороший метод оптимизации количества запросов и кеша.

wott.info/wordpress/optimization-in-numbers/

Как только он надоедает тому, кто его спонсирует.

Если это заказной проект — то рулит этим заказчик
Если это свой — то до тех пор пока не надоест
Если это групповой, то пока есть группа или хотя бы один, кому не безразлично.

Забавно, но свой собственный сервер данный сервис нифига не оптимизирует :)

Панельки на VPS тоже работают.

Мой совет — закажите установку установку и настройку VPS и панельки. Включите ежедневный backup. И начните работать с ним через панельки. А дальше читать по администрированию unix-ов и когда потребуется что-то посмотреть — делаем привычные движения в панельках и смотрим конфиги. Если хочется что-то осмысленное попробовать — пробуем, если что откатываем VPS на вчерашний backup.

В принципе через пару месяцев активного шевеления можно получить level-up до админа-середнячка.

Не совсем понятно что именно хочется видеть.

Есть официальные ленты с анонсами релизов и прочее.

Можно вытащить новые плагины и темы или найти сайт, который это уже сделал с какими-то ревью, но таковые все больше туповатые агрегаторы недалеких SEO-шников. Да и зачем? 90% не стоят потраченного времени.

Если ленту интересного для WP девелопера, то с этим проблемы — есть кучка мелких блогов, которые выдают по статье в месяц дай Бог. Можно конечно собрать, но они то потухнут то погаснут, так что искать придется чаще чем читать :) Как вариант — ищем нужно в гугле, находим — подписываемся.

В общем правильно написали что поиск рулит.

1. самая распространенная проблема — плохой код.
нарушение стандартов, отсутствие необходимых параметров и прочие баги воспринимаются браузером нормально, но результат не всегда соответствует ожиданиям. И когда такой багнутый код доводят до нужного вида в одном браузере — в других конечно же все по-другому.

хороший код как правило одинаков или почти одинаков во всех брузерах.
IE хороший показатель — он практически ничего из ошибок не прощает и корежит кривую верстку.

2. мелкие несоответствия — отступы, иногда отсутствие или разное поведение для значений.

решается хорошим reset.css, но все равно доставляет в случае непростой верстки

3. тупо баги.
IE со своим margin, bold/background и ненаследованием размерностей тут лидирует, но и остальные доставляют постоянно.
решается хаками.

Я лично пишу $_REQUEST вместо $_POST и вставляю проверку на POST, которую по DEBUG флагу обхожу.
Ну а в целом есть много http снифферов, которые позволяют повторять запрос. Наверно их и под MAC пишут.

Вы неправильно ставите вопрос. как хранить — без разницы, данные от этого не испортятся. Вопрос в том что вы будете с ними делать. И тут есть варианты:

Если планируется делать выборки по юзерам по свойствам, например принадлежность к группе, то такие свойства должны быть в явном виде. Нормализовать или нет — решайте сами.

Если же опции используются скопом, например при рендере страницы для него и больше никак, то есть смысл упаковать массив в виде json/xml.

Мне лично нравиться вариант Wordpress, где есть отдельная таблица для именованных опций ( юзера, поста и что там еще ) и в ней храниться либо отдельное значение или массив в виде отдельных строк, но с одним именем, по которым можно делать выборку или сериализованный массив — по желанию. Точнее как удобно их использовать. И при желании все варианты можно миксовать.

Я бы сделал возможности равноправными, а уж потом как-то бы использовал.
В том вконтакте вроде как в монетизации поучаствовал домен.

С точки зрения SEO поддомен выгоднее, вроде как.

А еще куки разные, то есть site.name/user1 и site.name/user2 вместе уживутся с трудом, а user1.site.name и user2.site.name — даже и напрягаться не надо.

Также возможно иметь разные DNS зависимые параметры для поддоменов.

В общем я бы мапил поддомен на директорию — а там видно будет :)