Перевел свой проект в production mode — да, класс \Magento\Sales\Api\Data\OrderStatusHistory\Repository имплементирующий интерфейс \Magento\Sales\Api\OrderStatusHistoryRepositoryInterface появился в файле .../var/generation/Magento/Sales/Api/Data/OrderStatusHistory/Repository.php.
Будем надеяться, что положительные изменения в багфиксах станут скорее правилом, а не исключением. Могут ведь иногда и за 2 минуты смержиться:
Данные говорят, как минимум, о том, что миграция в Woo несколько проще, чем в Magento, а не о том, что Magento удерживает сегменты. Magento 2 может и "начала ориентироваться на мерчанта с годовым оборотом 20+ млн. $", но ориентируются ли эти мерчанты на Magento 2?
выбор продиктован тем что не во всех СУБД возможно ...
IMHO, несколько в противоречии с
есть такая нотация и она в PostgreSql продвигается
Я не совсем понял, мы привязываемся к Postgres'у или пытаемся быть универсалами? Я, кстати, также ожидал увидеть "parent_id" в "element_tree".
Исходя из моего опыта работы с EAV структурой в Magento я несколько опасаюсь увидеть ваш SQL для постраничной выборки данных с фильтрацией и сортировкой (типовой use case). Но тем интереснее будет взглянуть на в следующей статье. Удачи.
имеет смысл эту команду обучать, а не топор точить
И. Не "а", а "и". Имеет смысл и инструментарий содержать в порядке, и навыки его использования нарабатывать. Вы, дружище, бросаетесь в крайности, пролетая мимо золотой середины.
Полностью согласен, программирование — это craft, а не art. Воспроизводимость, дополняемость, инженерность, если хотите, здесь важнее уникальности или самобытности. Понимание этого приходит со временем и не ко всем.
Весьма категоричное заявление, коллега. Причем в нем не охвачены средние программисты, к коим я и себя отношу и коих по моему мнению — большинство. Мне, например, типизация (если она есть) весьма помогает ориентироваться не только в чужом коде, но и в собственном тоже (разумеется, при поддержке IDE). Не спасает, но и не мешает.
У меня очень положительные впечатления от использования java packages & PHP namespaces, а вот в JS я подобного механизма не вижу. Когда PHPStorm пытается предложить мне автодополнение к началу какой-нибудь JS-функции, то он сперва долго "шуршит мозгами", а потом выдает сразу список всего, что нашел, причем одноименных функций из разных источников там столько, что автодополнением для JS'а я, например, пользоваться не могу. Возможно дело в том, что я работаю с Magento, а там куча не только своего кода, но и и кода из сторонних модулей, со своими JS-зависимостями. Иногда приходится из 5 JQuery-библиотек, которые тянутся модулями, оставлять одну посвежее, а остальные глушить (правда это для М1 было, с двойкой пока такого опыта не было).
Надо будет попробовать ваш вариант на небольшом, отдельном проекте и понаблюдать за. Боюсь, правда, разбор всего содержимого каталога vendor вызовет примерно такой же эффект — куча одноименных функций без возможности идентификации источника кроме как по имени файла (даже без пути). Но если давать "кучерявые" имена для своих структур (VendorProjectModuleClass — чтобы у IDE даже сомнений не было, что я имею в виду), то такой вариант, я думаю, вполне даже хорош.
Судя по примеру на JS — вас не волнует, что там реально предается в opts
Не совсем так. Я бы с радостью задал ожидаемую структуру входного объекта и для JS, вот только пока не знаю, как это сделать. Лучшее, что я пока нашел:
/**
* ..
*
* @param {Object} opts
* @param {string} opts.currency
* @param {Object} opts.screen
* @param {boolean} opts.screen.save
* @param {string} opts.screen.prefix
* @param {Object} opts.suite
* @param {string} opts.suite.pack
* @param {string} opts.suite.scenario
*/
function doGood(opts) {
var opts = opts || {}
var suite = opts.suite || {pack: "undef", scenario: "undef"}
var optsScreen = opts.screen || {} // screenshots related opts
var saveScreens = optsScreen.save || false // don't save screenshots by
var savePrefix = optsScreen.prefix || "default" // default prefix for screenshots
var currency = opts.currency || "EUR"
]1
Получается "масляное масло" — задавать структуру входного аргумента в док-блоке и парсить его же в теле функции в первых строках. Структура входных аргументов на PHP удобна всплывающими подсказками и autocomplet'ом (поддержка IDE).
Виной всему — моя лень. Мне было лениво расписывать "нездоровый" вариант на десять аргументов, и я остановился на более коротком, надеясь, что идея будет понятной. В результате запорол пример. Ну что ж, буду работать над собой.
Да, так и есть. Если очень сильно применять SRP, то начинают попадаться классы, мокать которые при тестировании — полная ерунда. Коллега Dimitar Ginev как раз и рекомендует не заниматься ерундой и не тестировать подобные классы (orchestrators).
Я имел в виду, что если просто делать копии рабочих исходников (например, с расширением .orig), то по ним точно так же можно отслеживать изменения кода в рабочих исходниках, как и при использовании мокирования для тестирования кода содержащего линейную последовательность действий. Вот только можно не писать юнит-тест для такого класса, а просто брать эталонный исходник, подписывать его "сениорской" пописью и проверять, что "джуниор" не запорол код при рефакторинге. Абсурд, в общем, тут имелся в виду.
ну тогда не все так безнадежно, как мне казалось :)
Коллега maghamed, может у Вас есть идея, как бы злосчастный PR-5145 протолкнуть в ближайший релиз?
Перевел свой проект в production mode — да, класс
\Magento\Sales\Api\Data\OrderStatusHistory\Repositoryимплементирующий интерфейс\Magento\Sales\Api\OrderStatusHistoryRepositoryInterfaceпоявился в файле.../var/generation/Magento/Sales/Api/Data/OrderStatusHistory/Repository.php.Будем надеяться, что положительные изменения в багфиксах станут скорее правилом, а не исключением. Могут ведь иногда и за 2 минуты смержиться:
Alexa Top 1K:
Может все-таки на "не очень маленького продавца"? Очень маленькие в "топ 1000" не попадают.
Миграция клиентов в феврале 2017:
Данные говорят, как минимум, о том, что миграция в Woo несколько проще, чем в Magento, а не о том, что Magento удерживает сегменты. Magento 2 может и "начала ориентироваться на мерчанта с годовым оборотом 20+ млн. $", но ориентируются ли эти мерчанты на Magento 2?
Fixed.
Несколько не ожидал увидеть мой SQL именно в таком, не совсем классическом виде, но мое любопытство удовлетворено в полной мере. Спасибо.
У меня легкий когнитивный диссонанс:
IMHO, несколько в противоречии с
Я не совсем понял, мы привязываемся к Postgres'у или пытаемся быть универсалами? Я, кстати, также ожидал увидеть "parent_id" в "element_tree".
Исходя из моего опыта работы с EAV структурой в Magento я несколько опасаюсь увидеть ваш SQL для постраничной выборки данных с фильтрацией и сортировкой (типовой use case). Но тем интереснее будет взглянуть на в следующей статье. Удачи.
И. Не "а", а "и". Имеет смысл и инструментарий содержать в порядке, и навыки его использования нарабатывать. Вы, дружище, бросаетесь в крайности, пролетая мимо золотой середины.
Получается, что самому языку типизация не нужна, но чтобы IDE могло в типах разбираться все-таки в каком-то виде (аннотации) эти типы указывать нужно.
Вы полностью подверждаете свою собственную характеристику. Причем во всех частях. Похвальная самокритичность.
Полностью согласен, программирование — это craft, а не art. Воспроизводимость, дополняемость, инженерность, если хотите, здесь важнее уникальности или самобытности. Понимание этого приходит со временем и не ко всем.
Объяснитесь, пожалуйста. Если досуг, разумеется.
Весьма категоричное заявление, коллега. Причем в нем не охвачены средние программисты, к коим я и себя отношу и коих по моему мнению — большинство. Мне, например, типизация (если она есть) весьма помогает ориентироваться не только в чужом коде, но и в собственном тоже (разумеется, при поддержке IDE). Не спасает, но и не мешает.
У меня очень положительные впечатления от использования java packages & PHP namespaces, а вот в JS я подобного механизма не вижу. Когда PHPStorm пытается предложить мне автодополнение к началу какой-нибудь JS-функции, то он сперва долго "шуршит мозгами", а потом выдает сразу список всего, что нашел, причем одноименных функций из разных источников там столько, что автодополнением для JS'а я, например, пользоваться не могу. Возможно дело в том, что я работаю с Magento, а там куча не только своего кода, но и и кода из сторонних модулей, со своими JS-зависимостями. Иногда приходится из 5 JQuery-библиотек, которые тянутся модулями, оставлять одну посвежее, а остальные глушить (правда это для М1 было, с двойкой пока такого опыта не было).
Надо будет попробовать ваш вариант на небольшом, отдельном проекте и понаблюдать за. Боюсь, правда, разбор всего содержимого каталога vendor вызовет примерно такой же эффект — куча одноименных функций без возможности идентификации источника кроме как по имени файла (даже без пути). Но если давать "кучерявые" имена для своих структур (VendorProjectModuleClass — чтобы у IDE даже сомнений не было, что я имею в виду), то такой вариант, я думаю, вполне даже хорош.
Если бы можно было ставить ссылку на структуру в док-блоке, хватило бы примерно такого:
Не совсем так. Я бы с радостью задал ожидаемую структуру входного объекта и для JS, вот только пока не знаю, как это сделать. Лучшее, что я пока нашел:
Получается "масляное масло" — задавать структуру входного аргумента в док-блоке и парсить его же в теле функции в первых строках. Структура входных аргументов на PHP удобна всплывающими подсказками и autocomplet'ом (поддержка IDE).
Виной всему — моя лень. Мне было лениво расписывать "нездоровый" вариант на десять аргументов, и я остановился на более коротком, надеясь, что идея будет понятной. В результате запорол пример. Ну что ж, буду работать над собой.
У вас тоже? Вы с коллегой lair'ом там что, на скорость чтения соревнуетесь? В таком случае примите от меня респекты и в свой адрес, коллега.
Поражаюсь вашей скорости чтения, коллега.
Да, так и есть. Если очень сильно применять SRP, то начинают попадаться классы, мокать которые при тестировании — полная ерунда. Коллега Dimitar Ginev как раз и рекомендует не заниматься ерундой и не тестировать подобные классы (orchestrators).
Я имел в виду, что если просто делать копии рабочих исходников (например, с расширением .orig), то по ним точно так же можно отслеживать изменения кода в рабочих исходниках, как и при использовании мокирования для тестирования кода содержащего линейную последовательность действий. Вот только можно не писать юнит-тест для такого класса, а просто брать эталонный исходник, подписывать его "сениорской" пописью и проверять, что "джуниор" не запорол код при рефакторинге. Абсурд, в общем, тут имелся в виду.