Эмуляция компьютера: интерпретатор CHIP-8 и формирование изображений

Создавал ранее собственный эмулятор CHIP-8 на coffeescript (js). Было интересно узнать как разработчики игр раньше оптимизировали свои алгоритмы, чтобы уместить игру в лимитированный объем данных. Так например проверка в игре, где необходимо мячиком разбивать стену, на попал ли мячик по стене и требуется ли отскок производится не через дополнительную переменную, а через проверку цвета пикселя в который ударились.

Менеджерам пора проснуться

Вы мне кажется плохо представляете чем заняты PM. Подобные факапы будут разребать ПМ и только потом разработчики, так как ПМ несет ответственность за команду и принятые решения касаемо проекта. Так что какое бы решение не было принято, плохой всегда ПМ, но не команда.

Менеджерам пора проснуться

Согласен с большинством сказанных примеров. Очень часто «идеи» генерируют джуниоры ( хотя бывают и исключения увы), которые соответственно начитались умных примеров со стек оверфлоу и в полностью пхп проект предлагают встроить нод.жс только потому что он вчера о нем прочитал и это же так круто. Может быть, но не здесь и не сейчас. Так же надо отделять «Хорошие идеи» в том проекте где они подойдут от «говнокода», который «генератор идей» считает лучше только потому что никогда не сталкивался с такой проблемой ранее и соответственно нести ответственность за который он не намерен ведь ему «разрешили» его использовать.

А если без JavaScript?

Прям вспомнился язык Hex, который компилируется в 18 ( или сколько там) языков, простое хеллоу ворлд оно превратило в 18 классов.

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

Magento 2: Создание грида в adminhtml

Статья понравилась. Но я заметил что все, включая М2 разработчиков, добавляют в зависимости своего класса редирект или резалт фектори вроде

protected $_resultPageFactory;

public function __construct(
        \Magento\Backend\App\Action\Context $context,
        \Magento\Framework\View\Result\PageFactory $resultPageFactory
) {
        parent::__construct($context);
        $this->_resultPageFactory = $resultPageFactory;
}

Все контроллеры наследуют свойство $this->resultFactory в котором хранится Magento\Framework\Controller\ResultFactory, т.е. достаточно сделать

public function execute()
{
    return $this->resultFactory->create(ResultFactory::TYPE_PAGE);
}

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

Увеличение производительности Magento

Быстрый взгляд на код м2 позволяет сказать, что для доступа к данным product alert stock используются коллекция, для самой важной страницы категории (продукт лист) используется коллекция, страница search модуля в админке использует коллекцию… Поэтому я думаю мы с вами говорим сейчас о разном применении этих вещей.

Я выше просил вас предоставить пример реального использования сервис лаера, но давайте будем более детальными. Предоставьте пожалуйста пример создания кастомного модуля, со своей таблицей в бд и с реализацией сервиса для доступа к моделям для работы с этой бд с учетом различных фильтров (Search criteria). Это поможет нам говорить о более детально примере, а не об абстрактных вещах. Все ссылки выше предоставляют общую информацию и нигде нет примера реального использования этого для чего-то выходящего за рамки нативного функционала, кроме вырванных из контекса примеров и обещаний в будущем все переписать. То что в мадженте есть они и они используются для доступа к данным — это определенно так ( продукты, цмс,… ). Но они не заменяют коллекции повсевместно. По крайней мере на данный момент.

На данный момент коллекции есть и это факт, который признали даже вы, в сторонних модулях и внутри мадженты они используются. Чтобы их правильно использовать надо понимать как же они работают и статья именно об этом. Нельзя просто сказать про новый подход «а вот в мадженте есть… да не везде… да не всегда применимо… да в будущем будет иначе… но есть». Пока что это не «везде» и это надо учитывать.

Увеличение производительности Magento

Проблема, я думаю в том, что сервис лаер «хорошо» описан в документациях и используется в паре мест в самой мадженте, но там в нем есть смысл ибо эти объекты используются в апи. В большинстве ( если не во всех) сторонних экстеншенах, которые сейчас выпускаются для М2 используют коллекции. М2 команда сейчас проверяет все экстеншены перед публикацией. Не в даваясь в вопросы как это они их пропускают, мы возвращаемся к первой проблеме, что люди редко умеют правильно использовать коллекции и грузятся все что не попадя, как в м1 так и в м2.

Увеличение производительности Magento

Я попросил предоставить пример где вы его используете в реальном проекте и как вы его используете в реальном проекте. С учетом всех фильтраций и так далее.

Увеличение производительности Magento

Пожалуйста предоставьте пример того, где вы используете и как вы используете сервис лаер. В м2 точно так же есть коллекции, которые работают апсолютно так же как и в м1. Отличие разве что в получении объекта коллекции.

Увеличение производительности Magento

Если вы собрались копировать код 1 в 1, как делают многие со стек оверфлоу, то конечно ничего не будет работать.

Увеличение производительности Magento

Но почему то и этого не делают :)