О, боже. У вас похоже даже заготовка ответа на критику есть. Хотя речь о совсем другом. Я не высказывал сомнений в результатах, а лишь указал на неактуальность софта и списка антивирусов, не хвалю тот же MSE. Но нельзя делать вид, что его нет ru.wikipedia.org/wiki/Microsoft_Security_Essentials#.D0.A0.D1.8B.D0.BD.D0.BE.D1.87.D0.BD.D0.B0.D1.8F_.D0.B4.D0.BE.D0.BB.D1.8F
Шёл 2015 год, давно уже вышла windows 8, вот-вот появится windows 10, более 6 лет как майкрософт предоставляет в поставке с виндой свой бесплатный антивирус. А в обзоре windows 7 и отсутствие Microsoft Security Essentials.
Понимаю, что Касперский занёс вам денег, но вы думайте на каком ресурсе лапшу вешать.
Как правило это длинные задачи, когда процесс работает больше секунд. Например работа в режиме демона с сокетами, или парсинг, обсчёт большого количества данных, постороение каких нибудь кайнтеров или коэфициентов.
Согласен. В идеале да, например, в .net вполне себе удобно реализовано. А на практике в doctrine модельки такие, что ни одной засранной AR не снилось. Плюс всё разнесено по 100500 слоям из-за чего малейшее изменение влечёт кучу правок.
Довольно хорошо знаю и понимаю теорию, ещё лет пять назад молился на паттерны, увлекался ddd, а последние годы больше увлекаюсь гряным кодом с костылями. На моей личной практике такой подход оказывается более эффективным.
Т.к. это перевод, попытаюсь ответить за автора.
1. Цену себе знать всегда полезно. Многие даже ходят по собеседованиям, хотя не собираются работать, я иногда тоже так делаю, заранее предупреждая о своей незаинтересованности. Не хочется в один прекрасный день обнаружить, что ты тот самый Джон Доу, который загнил сидя на одном месте.
2. Техническое собеседование такое же дырявое решето как и hr-ы работающие по кейвордам. На большинстве собеседований спрашивают джуниорские вопросы, на знание синтаксиса и никак не открывающие твои архитектурные вопросы. Хорошо подготовленный джун может легко отсобеседоваться на сеньёра. И в тоже время сеньёры могут подзабыть основы, когда работают через всякие фреймворки. Очень часто вопросы берут из подготовительных курсов по какой-нибудь сертификации. так что подготовиться не проблема.
>>Причем тут eloquent?
да блин, я и пишу что НИ ПРИ ЧЁМ, это не дело ORM заниматься контролем за количеством Entity. Я же это пишу уже который раз:
>>плясок вокруг сраной модельки из-за того, что ей поручают заниматься не её делами
>>IM при нормальной архитектуре заменяется DI.
>>Именно DI, потому что мы даже напрямую не пляшем не с EM как в случае doctrine
>>Смысл в том, что нужную энтити вытаскивает другой инфраструктурный код
извините, умываю руки, вы всё равно не читаете что я пишу.
God Object — это не про доуступность, а про функциональность, доктрина класичейский его представитель, потому что берёт на себя слишком много функцинала, который может обеспечиваться другими инфраструктурными уровнями. Не зря е компоненты начали жить отдельной жизнью.
UoW прекрасно работает, когда у нас долгоживущее приложение, мы можем хоть год однажды вытащив объект работать с ним не синкая с базой. А когда у нас долисекундный цикл, то оверхед от реализации UoW съедают прибыль от ленивости операций. А хуже всего, что при реализации этой ленивости в доктрине была куча багов, я имел анальное удовольствие пару раз пробираться через слои абстракции в поисках проблемы с ленивой подгрузкой.
>> Вот если бы мы инджектили энтитю в конструктор нашего контроллера — можно было бы говорить про DI.
Laravel умеет инджектить в метод, не только в конструктор. Если хотите, инджектите в конструктор. Смысл в том, что нужную энтити вытаскивает другой инфраструктурный код и пробрасывает её по цепочки и в мидлеваре и в экшен контроллера. Инджект приятнее и читабельнее, удобно тестировать, нежели создание контейнера их которого потом внутри метода тянется $this->get('items_repository')->findItem();
IM в простом виде это и есть конструкция, проверяющая наличие объекта в карте. Это не дело ORM следить за Identity map.
if (!Registry::has('Item:'.$identity)) Registry::set('Item:'.$identity, Item::find($identity))
return !Registry::get('Item:'.$identity);
UoW примерно то же. сразу заботимся чтобы пользователь работал с IM объектами, а затем делаем методы save-delete отложенными. Никакой хайлевел магии нет, чтобы захломлять ей бизнеслогику и клепать жуткие контроллеры пляшущие вокруг EM.
Посмотрите на свой пример и на мой, у вас пляска вокруг EM, хотя это должен быть инфраструктурный слой и он не должен засирать бизнес логику, даже в случае с AR код получается чище. Потому что EM — это типичный God Object, который берёт на себя всё, при этом анемичная кодель представляет собой спагетти из анотаций, репозитории с своим подъязыком DQL, ограниченные IM и UoW, rкоторые всё равно не гарантируют атомарность и целостность данных.
Я был одним из первых поклонников Doctrine 1, нес её в массы, потому что она помогала решать проблемы, а вторая их только добавляет.
Именно DI, потому что мы даже напрямую не пляшем не с EM как в случае doctrine, не с контейнером App в случае Laravel, а именно инджектится нужный объект в нужный метод function(App\Item $item), этакий чёрный ящик.
Про баги БАГИ К сожалению не могу нарыть твит, где авторы сами иронизировали, что приходится по три дня рыться, чтобы выяснить в чём баг.
Ну а что называется ParamConverter, какая разница как нызывается, если он подтверждает удобство инъекций. Какие-то попытки засунуть голову в песок и придраться к названиям.
А в Laravel это решается через DI, мы просто биндим модель к запросу и дальше получаем уже готовые объекты в методах
Route::model('item', 'App\Item');
Route::get('item/{item}', function(App\Item $item) {}); // Вуаля у нас нужный айтем, пустой если не передан id или нужный если он передан, а в случаей отсутствия мы сюда не попадаем, так как генерится ошибка.
Для symfony есть похожий бандл.
Вы понимаете каков машдаб плясок вокруг сраной модельки из-за того, что ей поручают заниматься не её делами, да ещё она и делает это криво.
p.s. Кстати, для Doсtrine 1, были решения в пару строк кода, которые добавляли те же IM и UoW. Не велика беда добавить сей функционал туда где надо, а это малюсенький процент от общего количества проектов. Но во второй версии плясали от горячей печки в итоге и сами обожглись и еду недоготовили, выпустив сырой продукт.
>>По сути правильно на каждый запрос создавать свой IM и свой UoW
А в чём тогда их смысл, если в паралельном запросе мы снесли вообще данную запись, которую потом считаем существуюей ибо на у нас извлекается из DI и даже есть цепочка действий с ней в UoW. И вообще это не дело ORM, это тупо зависимости.
Да, с проблемой мэпинга я столкнулся когда пытались втиснуть в существующий проект не с самой продуманной структурой БД. Но это в любом случае не оправдывает его хилость при наличии большого оверхеда на скорость разработки и производительность.
AR в Laravel — совсем не простой прямой мэппинг строки в таблице на объект. Во первых там есть работа с колекциями как ин мемори, так и при гидрации из базы, в любой момент мы моеж переопределить и получить тот же НЕ прямой мэпинг и мделать это в разы проще чем в Doctrine. Поддержка связей для вытаскивания связанных сущностей. Скоупы, которые являются аналогом DDD-шных критерий. Разные мутаторы и ассесоры, опять же выходящие за рамки прямого мэппинга данных. Обсервинг и т.д.
rambler — nginx
badoo — memcache и много чего для php
sphinx — аксёнова
percona — mysql и его стек
mailru — tarantool
jetbrains — kotlin
yandex — cocaine
vk — kPHP
Энвижен крупно вложился в postgre
…
Там же написано — не Java, потому что запрос живёт мало, один пользователь сделал один запрос, он отработал один раз и умер, почистив всё за собой. Следующий запрос таскает заново все объекты из стороджей. Да, есть демоны, но доктрина там не годится, так как не поддерживает асинхронную работу с базой.
Identity Map действительно антипаттерн, т.к. является обычным Registry и вместо явной передачи объекта по цепочки мы таскаем его из реестра. (Опять же в рамках умирающего php). IM при нормальной архитектуре заменяется DI. Хотя даже DI в таком контексте неоднозначен и является переусложнением :).
Ленивая загрузка бесмыссленно, за исключением подтягивания связей, а в доктрине она превратилось в портал для ошибок и магической логики из-за чего я отказался от Doctrine 2, сейчас, наверное, они почти исправлены, но они были даже спустя 1.5 года после стабильной «версии».
Data mapping тоже отдельная история, он вроде есть, но в результате сводится к прямому биндингу как при AR одна ентити, один аттрибут — одна таблица, одно поле. Сложный биндинг на разные таблицы и разные стороджи нужно делать костылями.
Ну и самое важно это AR которое используется в современных фреймворках это вовсе не классичессичейский фаулеровский AR, а нечто большее. И при нем ничто не мешает использовать IM, UoW, LL, DM и городить DDD.
p.s. Спасибо, что напомнили в очередной раз заняться Pg, раз сейчас в отпуске, а то до сих пор использую его на уровне mysql. Раз уж про обёртки над стороджем, возможно вам будет интересно github.com/sad-spirit/pg-builder github.com/sad-spirit/pg-wrapper
А при чём левый сторонний плагин до wordpress. Я напишу свой с eval($_GET['code']) и будет виноват WP? А ещё такой же бандл создам для symfony и буду на каждом углу заявлять о том, что фреймворк — решето.
У вас очень правильное замечание. Мне кажется следует использовать правило как в других языках — больших анонимок лучше использовать полное function, а для однострочных ~>
В примерах есть usort($array, ($a, $b) ~> $a->val <=> $b->val);
usort($array, function($a, $b) { $a->val <=> $b->val; }); — PSR этот код просит разнести на пару строк из-за {}
Самое важное — понимать, что вас всё равно взломают, а то и сами сломаете. Потому нужно заботиться о безопасности информации хранящейся в электронном виде, шифровать и бэкапить, тем самым миниминизируя потери.
Понимаю, что Касперский занёс вам денег, но вы думайте на каком ресурсе лапшу вешать.
Довольно хорошо знаю и понимаю теорию, ещё лет пять назад молился на паттерны, увлекался ddd, а последние годы больше увлекаюсь гряным кодом с костылями. На моей личной практике такой подход оказывается более эффективным.
1. Цену себе знать всегда полезно. Многие даже ходят по собеседованиям, хотя не собираются работать, я иногда тоже так делаю, заранее предупреждая о своей незаинтересованности. Не хочется в один прекрасный день обнаружить, что ты тот самый Джон Доу, который загнил сидя на одном месте.
2. Техническое собеседование такое же дырявое решето как и hr-ы работающие по кейвордам. На большинстве собеседований спрашивают джуниорские вопросы, на знание синтаксиса и никак не открывающие твои архитектурные вопросы. Хорошо подготовленный джун может легко отсобеседоваться на сеньёра. И в тоже время сеньёры могут подзабыть основы, когда работают через всякие фреймворки. Очень часто вопросы берут из подготовительных курсов по какой-нибудь сертификации. так что подготовиться не проблема.
да блин, я и пишу что НИ ПРИ ЧЁМ, это не дело ORM заниматься контролем за количеством Entity. Я же это пишу уже который раз:
>>плясок вокруг сраной модельки из-за того, что ей поручают заниматься не её делами
>>IM при нормальной архитектуре заменяется DI.
>>Именно DI, потому что мы даже напрямую не пляшем не с EM как в случае doctrine
>>Смысл в том, что нужную энтити вытаскивает другой инфраструктурный код
извините, умываю руки, вы всё равно не читаете что я пишу.
UoW прекрасно работает, когда у нас долгоживущее приложение, мы можем хоть год однажды вытащив объект работать с ним не синкая с базой. А когда у нас долисекундный цикл, то оверхед от реализации UoW съедают прибыль от ленивости операций. А хуже всего, что при реализации этой ленивости в доктрине была куча багов, я имел анальное удовольствие пару раз пробираться через слои абстракции в поисках проблемы с ленивой подгрузкой.
Laravel умеет инджектить в метод, не только в конструктор. Если хотите, инджектите в конструктор. Смысл в том, что нужную энтити вытаскивает другой инфраструктурный код и пробрасывает её по цепочки и в мидлеваре и в экшен контроллера. Инджект приятнее и читабельнее, удобно тестировать, нежели создание контейнера их которого потом внутри метода тянется $this->get('items_repository')->findItem();
IM в простом виде это и есть конструкция, проверяющая наличие объекта в карте. Это не дело ORM следить за Identity map.
if (!Registry::has('Item:'.$identity)) Registry::set('Item:'.$identity, Item::find($identity)) return !Registry::get('Item:'.$identity);
UoW примерно то же. сразу заботимся чтобы пользователь работал с IM объектами, а затем делаем методы save-delete отложенными. Никакой хайлевел магии нет, чтобы захломлять ей бизнеслогику и клепать жуткие контроллеры пляшущие вокруг EM.
Я был одним из первых поклонников Doctrine 1, нес её в массы, потому что она помогала решать проблемы, а вторая их только добавляет.
Про баги БАГИ К сожалению не могу нарыть твит, где авторы сами иронизировали, что приходится по три дня рыться, чтобы выяснить в чём баг.
Ну а что называется ParamConverter, какая разница как нызывается, если он подтверждает удобство инъекций. Какие-то попытки засунуть голову в песок и придраться к названиям.
Route::model('item', 'App\Item');
Route::get('item/{item}', function(App\Item $item) {}); // Вуаля у нас нужный айтем, пустой если не передан id или нужный если он передан, а в случаей отсутствия мы сюда не попадаем, так как генерится ошибка.
Для symfony есть похожий бандл.
Вы понимаете каков машдаб плясок вокруг сраной модельки из-за того, что ей поручают заниматься не её делами, да ещё она и делает это криво.
p.s. Кстати, для Doсtrine 1, были решения в пару строк кода, которые добавляли те же IM и UoW. Не велика беда добавить сей функционал туда где надо, а это малюсенький процент от общего количества проектов. Но во второй версии плясали от горячей печки в итоге и сами обожглись и еду недоготовили, выпустив сырой продукт.
А в чём тогда их смысл, если в паралельном запросе мы снесли вообще данную запись, которую потом считаем существуюей ибо на у нас извлекается из DI и даже есть цепочка действий с ней в UoW. И вообще это не дело ORM, это тупо зависимости.
Да, с проблемой мэпинга я столкнулся когда пытались втиснуть в существующий проект не с самой продуманной структурой БД. Но это в любом случае не оправдывает его хилость при наличии большого оверхеда на скорость разработки и производительность.
AR в Laravel — совсем не простой прямой мэппинг строки в таблице на объект. Во первых там есть работа с колекциями как ин мемори, так и при гидрации из базы, в любой момент мы моеж переопределить и получить тот же НЕ прямой мэпинг и мделать это в разы проще чем в Doctrine. Поддержка связей для вытаскивания связанных сущностей. Скоупы, которые являются аналогом DDD-шных критерий. Разные мутаторы и ассесоры, опять же выходящие за рамки прямого мэппинга данных. Обсервинг и т.д.
badoo — memcache и много чего для php
sphinx — аксёнова
percona — mysql и его стек
mailru — tarantool
jetbrains — kotlin
yandex — cocaine
vk — kPHP
Энвижен крупно вложился в postgre
…
Identity Map действительно антипаттерн, т.к. является обычным Registry и вместо явной передачи объекта по цепочки мы таскаем его из реестра. (Опять же в рамках умирающего php). IM при нормальной архитектуре заменяется DI. Хотя даже DI в таком контексте неоднозначен и является переусложнением :).
Ленивая загрузка бесмыссленно, за исключением подтягивания связей, а в доктрине она превратилось в портал для ошибок и магической логики из-за чего я отказался от Doctrine 2, сейчас, наверное, они почти исправлены, но они были даже спустя 1.5 года после стабильной «версии».
Data mapping тоже отдельная история, он вроде есть, но в результате сводится к прямому биндингу как при AR одна ентити, один аттрибут — одна таблица, одно поле. Сложный биндинг на разные таблицы и разные стороджи нужно делать костылями.
Ну и самое важно это AR которое используется в современных фреймворках это вовсе не классичессичейский фаулеровский AR, а нечто большее. И при нем ничто не мешает использовать IM, UoW, LL, DM и городить DDD.
p.s. Спасибо, что напомнили в очередной раз заняться Pg, раз сейчас в отпуске, а то до сих пор использую его на уровне mysql. Раз уж про обёртки над стороджем, возможно вам будет интересно github.com/sad-spirit/pg-builder github.com/sad-spirit/pg-wrapper
В примерах есть usort($array, ($a, $b) ~> $a->val <=> $b->val);
usort($array, function($a, $b) { $a->val <=> $b->val; }); — PSR этот код просит разнести на пару строк из-за {}