Кирилл Арутюнов

debounce

Один из вариантов:

route(
  'route.name',
  array_merge(
      request()->query(),
      [
          'sortBy' => 'relevance_score',
          'sortOrder' => ($currentSortBy === 'relevance_score' && $currentSortOrder === 'asc') ? 'desc' : 'asc',
      ]
   )
)

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

Статья старая и не актуальная. Есть новые инструменты и при чем весьма удобные.

1. Перейти на версию 8.3.6
2. Открыть доступ по OData
3. Профит.

Никаких битриксов. Драйвер есть готовый тут https://packagist.org/packages/falseclock/dbd-php

Позавчера опубликовал статью infostart.ru/public/605427

при выполнении запроса в модели, происходит:
1. Запрос для получения структуры таблицы
2. Запрос для получения кол-ва записей таблицы
3. Запрос для получения данных по указанной выборке

что бы избежать этого (на продакшене) стоит использовать кеширование схемы БД, для этого в конфиге подключение к БД достаточно прописать, например:
enableSchemaCache' => true,
'schemaCacheDuration' => 180000,
'schemaCache' => 'cache'

установить sendmail, указать в php.ini php.net/manual/ru/mail.configuration.php#ini.sendm... , прописать spf для домена (откуда идёт отправка), сгенерировать ключи и подключить DKIM(установив open-dkim) чтоб письма подписывались.

1. Изучить рекомендации по рассылкам у крупных почтовых сервисов (Google, Yandex, Mail.ru). При подготовке писем для рассылки строго следовать их рекомендациям.
2. Зарегистрироваться в postmaster.yandex.ru, postmaster.mail.ru, чтобы следить за ходом рассылки писем.
3. Отлавливать недоставленные письма, убирать их из листов рассылки, дабы не мусорить.
4. Сделать механизм отписки от рассылки (это один из критериев пункта 1), причем 100% работающий в один клик.
5. Мониторить нажатие кнопки "Спам" в вышеуказанных почтовых сервисах, также сразу исключать их из будущих рассылок.

1к подписчиков - это мелочь. Можешь пробовать отсылать сразу все письма на свой почтовый релей (для 1к хватит и одного релея), даже почти дефолтно настроенный MTA будет рассылать с нужными интервалами.

Обязательное условие - соблюдать все почтовые правила и не пренебрегать цифровыми подписями - SPF, DKIM, DMARC, правильные записи в DNS (A, MX, PTR).

Думаю, если вы технарь, то именно детальный просчет всех вариантов, куда нужно вложить деньги - хостинг, реклама, офис ... - вы должны уже уметь составлять

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

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

А вот что нужно для стартапа, это маркетинг, наверное даже больше, чем техническая часть.

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

А вот из современного и, как сегодня говорят, мотивирующего, вот что неплохо:
Библия "Бутстрапера" (Сет Годин)
Фиолетовая корова (Сет Годин)
Метод Тыквы (Майкл Микаловиц)
Стартап без бюджета (туалетно-бумажный бизнесмен) (Майкл Микаловиц)
Маркетинговые войны (Джек Траут)

1) Идем сюда https://postmaster.mail.ru/
2) Регаем там себя как отправителя (определение по домену)
3) После этого появится всякая статистика по отправляемым письмам
4) Там же есть возможность настроить FBL - это то что Вам нужно
5) Profit

Подробнее тут habrahabr.ru/company/mailru/blog/147713

Как бонус, у mail.ru есть офигенная штука - можно письма снабдить специальным заголовком, и мэил начнет по ним (в отдельности) давать статистику (кол-во писем, жалобы, %% доставки и т.п.)

Текущее положение дел:

1. Нет адаптивности.
   
2. Большинство размеров задано в пикселах - это ухудшает положение дел для первого пункта.
   
3. Нет единого стиля написания кода.
   
4. Ужасный вариант применения универсального селектора.
   
5. Нет normalize.css.
   

Советы:

1. Определите свой стиль, которому вы будете следовать, ибо сейчас в коде помесь двойных и одинарных кавычек.
   
2. Не используйте идентификаторы для стилизации элементов. Сейчас это считается дурным тоном.
   
3. Не используйте селектор по тегу для вложенных в body header, footer, main и т.д.
   
4. Советую ознакомиться с различными методиками организации стилей и вообще кода. Для начала пойдет Code Guide by @mdo.
   
5. Используйте CSS-препроцессоры (можно ещё и HTML).
   

А так, начало неплохое, даже в IE8 более-менее нормально все.

1. Vagrant, или docker с системой максимально похожей на production сервер. Разработку ведем там.
2. Если никакая vcs не используется - пи"№;ц конечно, но быстро подключайте, иначе бида обеспечена. Рекомендую git + git-flow.
3. Правки в БД ТОЛЬКО на основе миграций, при этом создавайте как up, так и down.
4. Возьмите готовую систему для диплоя, либо напишите свой скрипт для этого. Цель в том, что бы минимизировать человеческий фактор при обновлении продакшна на столько, на сколько это возможно.
5. Все, что находится в /vendor - обязательно должно быть заигнорировано в vcs, composer.json И composer.lock (спс OnYourLips) должен ссылаться на фиксированные версии пакетов.
6. Код ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ желательно покрыть тестами. Самый кульный вариант - запуск тестов после push изменений в главный репозиторий. Для этого можно использовать связку gitlab + gitlab-ci.
7. На счет доменов - в чем проблема то? Вынесите домен в конфигурацию, и создайте конфиги для локального, тестового и боевого окружений.
8. На счет записей в БД: да, они обязаны отличаться. По хорошему на проде руками в принципе можно только смотреть, а записывать нельзя. Для тестовой БД - пишите фикстуры.
9. сразу подумайте на счет логов: если их over-дофига, имеет смысл использовать системы типа logstash, или sentry.

Можно через системный cron, можно через планировщик (events самого mysql), через крон банальность и инфы в гугле море, через планировщик - интересней:
По умолчанию в большинстве версий MySQL планировщик отключен. Чтобы его включить добавьте event_scheduler = 1; в файл конфигурации MySQL. Для избежания перезапуска MySQL следует выполнить далее команду SET GLOBAL event_scheduler = ON;
Затем создаем событие типа:

DELIMITER $$
 
CREATE EVENT IF NOT EXISTS `e_part_manage`
       ON SCHEDULE EVERY 30 DAY
       STARTS '2014-10-10 04:00:00'
       ON COMPLETION PRESERVE
       ENABLE
       COMMENT 'Управление удалением записей'
       DO BEGIN
Тут можно как напрямую вставить команду удаления, так и использовать процедуру
       END$$
 
DELIMITER ;

Как-то так.