Подтверждаю, переход на SSD значимо влияет на скорость работы.
Сам перешёл на SSD года 2 или 3 назад (когда окончательно отказался от W7) - был очень приятно удивлён.
p.s. Главное, чтобы материнка поддерживала SATA-III до 6Gb/s.
Я сначала подключил не в том слот и был разочарован заявленным приростом скорость, а потом вставил в правильный и рабочий процесс сразу заиграл новыми красками.
Здесь согласен, когда нет точки опоры, все эти умозрительные изыскания ни к чему не приведут.
Изначально разные оценочные координаты.
Не пришли. Я четко ответил - на момент написания вами кода - это самопис. Всё что было изначально в базовой комплектации - штатное. Определяющим является контекст, время и отношение разработчика к проекту.
Если вы разработчик ПО и работаете над штатными функциями, которых пока нет, но они планируются как штатные - они будут представлены как штатные. Если вы костылите и дорабатываете чужой код под свои нужды - это самопис, неважно в какой форме: будет ли это плагин, которым мы СамиНапиСали, или просто куски дополняющего кода, предоставляющие вам необходимую функциональность.
Приведу умозрительный пример для прояснения моей позиции.
Допустим (гипотетически представим) по случаю вас и меня пригласили работать над сайтом. Это оказался WP, но для решения SEO задач мне нужно значимо расширить функциональность, который в базовой версии нет - я пишу вам техническое задание, чтобы вы реализовали [такую-то] и [такую-то] возможность. Вы смотрите задание и сообщаете заказчику, что реализация данного ТЗ будет стоить столько-столько. Заказчик удовлетворяет и вы работаете. По результату для меня и для заказчика это будет самопис, потому что мы (я как автор ТЗ, и заказчик как бенефициар проекта) привлекли программиста и он выполнил свою часть работы.
При этом вы со своей стороны, могли и сами написать необходимый код, и найти готовое решение, если оно укладывается в ТЗ, да хоть получили код от AI. Путь и форма достижения результата не играет роли, ключевая роль в том, что для заказчика штатными возможностями это было сделать нельзя, а благодаря участию программиста стало возможно.
Теперь вам понятна моя логика?
Да, по субботам могу :)
О! Мы теперь введем новую переменную - форма приобретения кода. Т.е. если кто-то сторонний заказывает написанный код, то он уже не является авторским т.е. "само написанным программистом", а обретает какое-то новое качество и свойство.
В связи с этим вопрос - а заказанная с нуля CMS по требования заказчика - это самопис, CMS или заказанный скрипт?
А вот этот написанный вами комментарий? Он сапопис или невамипис?
До абсурда можно довести любую идею. Стоит только выдернуть из контекста и начать жонглировать уточняющими вопросами 😉
На момент когда вы это личном писали, это был самопис.
И раз вы его писали, вы скорее всего это делали потому, что в нужной вам мере не было необходимой штатной функциональной возможности.
Да будем вам. Все предельно прозрачно. Либо в админке в пользовательском режиме можно это сделать, либо нельзя.
Это и есть штатные возможности.
Всё что дополнительно костылится - внештатные. Вот и вся принципиальная разница.
Зависит от бизнеса его условий, его фактической локации и прочих обстоятельств, которые в том числе касаются разработки, бюджетов и руководства.
Как выше отметил Владимир - для Яндекса приоритетны поддомены, если есть фактическая возможность закрепить региональность. В этом смысле возможность регионального ранжирования через поддомены это ключевая точка роста для прогнозируемого трафика.
Безусловно есть и конечно все их длинным списком и подробными объяснениями излагать вряд ли будут.
Ключевые моменты в аффилированности (хотя Яндекс сейчас на это закрывает глаза), в дублированности контента (потому что как чаще всего товарный набор один и тот же во всех регионах), в региональной структуре, если она имеет необходимость.
Здесь много нюансов на стыке офферов и товарных элементов, но разбирать всё это имеет смысл только применительно к конкретике бизнеса.
Обсуждать особенности у некой умозрительной бизнес конструкции - это всё равно, что натягивать невидимые штаны на сферического коня в вакууме - спора и дискурсов c какой стороны это делать - масса, а полезности - ноль.
Владимир правильно вам намекнул - желаете сделать всё правильно, наймите опытного специалиста. Желаете разобраться самостоятельно - пробуйте, делайте и в конкретике рабочих данных задайте более конкретные вопросы.
Так более вероятно получить более точные и предметные советы.
Главной вопрос - для чего?
Оказать психотропное воздействие на потенциального противника НАТО?
Ну мы то точно знаем, что земля не плоская, поэтому этот абсурдный тезис рассматривать не стоит, а вот то, что у ряда программистов есть свои суждения в отношении того, что PHP не в полной мере является языком программирования и на это есть веские основания - это любопытно.
Но сейчас эту тему я обсуждать не хочу, это просто как дополнение к неочевидным особенностям.
Хорошо :) Тогда на всякий случай я обозначил свою, раз уж я себя им назвал :)
Пожалуйста.
Штатная функциональность это явные рабочие решения, определённые возможностями движка на уровне доступных пользовательских изменений через административную часть, либо дополняющие административные элементы.
Например, в штатной функциональности заявлено, что в административной части можно производить заполнение мета данных OpenGraph и при этом есть соответствующие поля, где в пользовательском режиме можно их активировать и заполнить.
При этом заполнение может быть уникальным, а может быть рекурсивным.
Вот это штатная функциональность.
Когда я вижу, что в административной части CMS не поддерживается работа с OpenGraph данными, я вижу, что нет у движка такой штатной (т.е. заранее определённой) возможности. И тогда я формирую ТЗ программисту, чтобы он это реализовал, если в этом есть рабочая необходимость.
Здесь могут быть варианты. Это штатная возможность может быть реализована в базовой версии, а может быть предусмотрена через установку доп. плагинов и компонентов.
Если вы просто переключаете плагины и темы, то их общую совокупность можно назвать штатными функциональными возможности. Но если мы рассматриваем какую-то базовую часть движка вне функциональных дополнений, то штатными функциями будут только те, что обеспечивает базовый движок.
