Александр Мелеховец

bitbucket.org

По своему опыту выделил для себя следующие правила.
Физика:
1. Питание. Обрати внимание на сахар и быстрые/медленные углеводы. Например, если утром поесть овсяную кашу то энергии хватит на 4-5 часов, если бутерброды, - часа на два. Так по крайне мере у меня.
2. Физические нагрузки, спорт отнимает много времени, хотя очень эффективен. Самый простой способ - побольше ходить, если пользуешься общ. транспортом, то выходить на несколько остановок раньше. Еще можно отжиматься, где-то читал что сто отжиманий в день - тонус для всех мышц тела.
3. Сон. Как и другие рекомендую 7-8 часов, однако нужно обратить внимание на матрас, температуру и влажность в комнате - это намного улучшит качество отдыха.
4. Жидкости. Я пью обычную воду, стараюсь выпивать 2 литра на работе (у меня есть вот такая фляга )
5. Свежий воздух в офисе, яркость света. Стараться работать согласно нормам описаным в охране труда, т.е. должно быть много света, должен быть приток свежего воздуха.
6. Эргономика стола. Обязательно нормальный стул, стол, монитор, клавиатура. Многие пренебрегают этими вопросами, а потом в 30 лет грыжи в позвоночнике, туннельный синдром, линзы/очки и половая дисфункция. (Я понимаю что в 18 лет это звучит как что-то далекое и не про тебя, однако если ты планируешь связать свою жизнь с разработкой, нужно думать о туловище, а не только о мозге)

Психика:
1. Будут дни когда работа не прет, абсолютно. Отпустить и забыть, но не увлекаться.
2. Дисциплина. Так как мозг считай мышца, нужно постоянно тренировать ее; - писать код. В конце концов мозг привыкнет к нагрузке и сможет решать любые задачи и быстро, но будут дни как в первом пункте.
3. Супер важные ежедневные задачи. Для меня это учеба и английский. Я этим занимаюсь не зависимо от дня недели, праздников, событий. Т.е. даже если я узнаю что через три дня конец света, все равно буду оставшиеся дни делать то что и делал раньше. Можно смеяться и крутить пальцем у виска, но нужно объяснить мозгу, что не может быть никаких проволочек, никаких отмазок. Иными словами “сдохни, но сделай”. Этот навык мне позволяет в случае аврала или какой-то мегалажи не паниковать и планомерно решать задачи. (Лучше начинать потихоньку иначе пункт первый на несколько лет)

Через пол года у твоего мозга закончится адаптационный период и в этот момент начинай думать о своем туловище, оно не будет тебя отвлекать от решения любых умственных задач.
Книги:
https://pragprog.com/book/jkthp/the-healthy-programmer
www.ozon.ru/context/detail/id/4320305

1) Что-то мне подсказывает что валится оно на чем-нибудь вроде $product->find() а не на том что вы привели.

2) Лучше делать так

$this->get('doctrine.orm.entity_manager')->getRepository(Organization::class)

3) А еще лучше регистрировать репозитории как сервисы

4) А еще лучше, не наследоваться от доктриновский репозиториев и использовать свои, которым в конструктор передавать entity manager и там уже делать что душе вздумается. Пример (так как это должно быть, в реальных проектах можно упрощать)

class DoctrineOrganizationRepository implements OrganizationRepository 
{
    private $em;
    public function __construct(EntityManagerInterface $em) 
    {
          $this->em = $em;
    }

    public function getOrganization(int $id) : Organization
    {
           $organization = $this->em->find(Organization::class, $id);
           if (!$organization) {
                 throw new OrganizationNotFoundException();
           }
 
           return $organization;
    }
}

По сути наше приложение не должно слишком много знать о доктрине. Ну и еще удобнее регистрировать такие сервисы:

services:
     organization_repository:
         class: MyApp\Service\Doctrine\DoctrineOrganizationRepository
         autowire: true

5) Не дробите приложение на бандлы. Они для того что бы реюзать код. Если вы дробите систему на бандлы с мыслью "может потом реюзаю" - это пример преждевременной оптимизации. Вам нужен только AppBundle и то только ради маленьких шорткатов.

Зависимостей между бандлами быть не должно. Они могут зависеть от библиотек. но не от бандлов.

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).

много потоков это хорошо, но с ростом количества потоков производительность будет падать ну то есть 8 потоков будут работать не в два раза быстрее чем 4.

У вас по сути большая часть времени - это работа с сетью, что медленно. Выход - event loop. В рамках одного потока запускаем много много неблокируемых запроса, и по мере завершения запросов обрабатываем результат.

Комбинация нескольких потоков (по количеству ядер процессора) и event loop даст максимальную утилизацию процессора.

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

Вдобавок, такая "оптимизация" может даже ухудшить дело, потому что не получится реализовать ленивый подсчет данных. Простой пример - если заказ не подтвержден, то не нужно выводить сумму его товаров, а если подтвержден - нужно. Представим, что сумма нигде не хранится и считается на лету из товаров в корзине заказа. При использовании объекта, подсчет суммы не выполнялся бы вообще для неподтвержденных заказов, потому что метод getTotal() не будет вызван в шаблоне. А при конвертации в массив нужно будет высчитывать всё, ведь неизвестно, что пригодится в шаблоне, а что - нет.

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

Так я и подумал, может стоит сразу приучать вьюхи использовать только ассоц. массивы?

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

А так вьюха навязывает логику контроллерам и моделям, что та или другая переменная должна быть именно объектом.

Наоборот, это контроллеры отдают данные и по определению именно они навязывают шаблону логику его работы. И это нормально.

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

Да, можно во все классы запилить поддержку ArrayAccess, но какой в этом смысл? Если вью будет работать с объектом, то это только трата времени. Если вью будет работать с массивом, то ArrayAccess тут ничем не поможет - никакого объекта уже нет. Я не вижу смысла делать такой hot swap.

Это как делать framework-агностик приложение, чтобы в любой момент можно было заменить Симфони на Ларавел - идея прикольная и дизайн в итоге, возможно, будет лучше (но далеко не факт, потому что такое усложнение может сделать всё только хуже), но на практике такие переезды происходят очень редко и даже когда происходят, безболезненно они не проходят.

Гораздо эффективнее сделать минимально необходимый дизайн, а потом, если уж припрет, потратить дополнительное время на перенос. По большому счету, то, что вы предлагаете, это Big Upfront Design и я не сторонник такого подхода. Лучше вносить изменения итеративно, исходя из текущих потребностей бизнеса, оплачивающего работу, и не заглядывать далеко в будущее. Есть ненулевая вероятность, что пока вы будете имплементировать в классах ArrayAccessable Interface, заказчик разорится и ваш красивый, расширяемый, поддерживаемый код окажется никому не нужным.

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

P.S. Я это всё написал как альтернативную точку зрения для всех, кто будет читать этот вопрос впоследствии. Используйте whatever floats your boat, как говорится, в вопросах архитектуры нет серебряной пули.

Если нужно выбирать данные параллельными скриптами, то надёжно работает такой вариант:

UPDATE `emails` SET `status` = 1 WHERE @id := `id` AND `status` = 0 ORDER BY RAND() LIMIT 1;
SELECT * FROM `emails` WHERE `id` = @id;

Вот только сортировка по RAND() очень медленная, по возможности от неё лучше отказаться.