В бытность PHP разработчиком работал в одной из компаний из списка. Это худшее место в котором я когда либо работал. Конечно я не про какой то неадекват. Но с точки зрения технологий, бюрократии, саморазвития - худшее.
сам sbrk ничего не выделяет, а сдвигает границу адресного пространства кучи, доступной процессусам sbrk ничего не выделяет, а сдвигает границу адресного пространства кучи, доступной процессу
... что впринципе и является выделением памяти, ведь мы получаем больше виртуальных адресов для использования.
В линуксе вниз граница не двигается, в этом смысле предпочтительнее ммап- выделенную им память можно отдать обратно ос.
Давайте не переводить разговор в русло: "почему комментатор комментирует". Because i can.
По поводу темы - я не считаю что не об этом. Вы обозначили преимущества поразрядной сортировки в общем случае (да в частных случаях она может быть хороша - но в статье я не вижу об этом), я с этим не согласен и привожу свои аргументы.
1 А поиск в хеш таблице с бакетами О(n) в худшем случае, только думается на собеседовании в озон ожидают другого ответа на вопрос о сложности поиска в хэш таблице ;)
Возвращаясь к квиксорту- зависит от выбора опорного элемента, применяя простые техники вероятность получить квадрат очень низкая. Так что обычно говорят об ожидаемом времени работы - nlog n. Загляните в сорцы стандартной сортировки, там должно быть что то про сложность.
2 Вы видимо не понимаете в чем претензия. Дело в том что в текущем go производительность обобщенного алгоритма будет ниже производительности того же алгоритма написанного с конкретным типом данных. Это происходит из-за того что go не выведет тип на этапе компиляции - соответсвенно будут накладные расходы в рантайме.
Двоякое отношение к Yii. Yii2 в свое время помог "войти в профессию" и форум фреймворка был классный, но вот Yii3... Со стороны выглядит несколько противоречиво - топка за различные PSR'ы (роутинг, di, реквесты и тд) и при этом собственная реализация. Есть ли обоснование - зачем пилить свои имплементации шаблонных вещей когда вокруг куча готовых, протестированных, оптимизированных? Не является ли это бутылочным горлышком в процессе реализации фреймворка?
рамках go сервисов мы пробовали в домен добавлять специальный метод "восстановления" с набором параметров, мапающихся на состояние агрегата.
В свое время пилил ормку для автомаппинга больших графов сущностей, но как оказалось это не особо кому нужно. В микросервисах развесистая бизнес логика (а за ней и развесистые агрегаты) не частое явление.
ORM как раз ничего не создает, а восстанавливает из хранилища в соответствии с persistance ignorance. Если вы в коллекцию сущностей в оперативке добавите а потом запросите сущность, вы же не ожидаете что вызовется конструктор при запросе?
Другими словами корень агрегата создается ровно 1 раз, что как раз по DDDшному ибо отражает язык бизнеса.
Если угождать всем и каждому - получится свалка из конструкций и концепций. В итоге php придет к тому с чего начинал - str_rot13 и вот это вот все.
Может, конечно, три года в go так влияют, но релизы чуть ли не полностью состоящие из syntax sugar воспринимаются как то искусственно что ли. Как будто: "мы не знали что делать с языком (но делать что то надо) поэтому вот вам гора сахара - будете экономить минуту в день при написании кода". И как то люди забывают, что код надо не только писать, но и читать, и увеличение когнитивной нагрузки при чтении это не то чтобы плюс.
Мы же можем сортировать не поразрядно а побайтого, тоесть int64 будем сортировать по 8 байтам, в этом случае получим O(N). Другое дело, что на практике там слишком большой постоянный множитель + нужна доп память, сортировки сравнением оказываются быстрее по итогу.
При выделении отдельного бизнес слоя, не зашитого в объекты-агрегаторы, можно добавлять функциональность добавляя сервисы (не изменяя при этом старые сервисы и, в некоторых случаях, сами доменные объекты).
Думаю в тех кейсах где Вы добавите новый сервис, я смогу добавить новый агрегат. Но, что если речь идет о каком нибудь OrderService и вам нужно имплементировать фичу, ну например отмены заказа. Будете ли вы создавать отдельный сервис для этого? Ведь сейчас к модулю Order у вас есть четкий API находящийся в OrderService, какой смысл разделять его? Я считаю, что в данном случае никакого, ровно та же аналогия и с агрегатами которые также предоставляют API к доменному слою.
что работу с данными и сами данные лучше разделять
В случае ООП это противоречит инкапсуляции.
В статья говорится
Используя агрегаты мы пишем бизнес-логику в одном месте
Согласен, это странно, не могу говорить за автора, но возможно имелось в виду — используя агрегаты мы получаем одну точку доступа к нашей бизнес логике.
Из прочитанного выходит что данные надо хранить вместе с их обработчиками, слой бизнес логики «зашит» в объекты-агрегаты. А ведь одни и те же данные могут использоваться/обрабатываться в разных ситуациях. Получается при разрастании функционала нужно добавлять новые публичные методы в объекты-агрегаты (нарушение принципа открытости/закрытости)? Или не правильно понял.
Тоесть в случае анемичной архитектуры — при добавлении публичных методов в сервисы, open/close нарушен не будет?
Тот момент, что бизнес логика «зашита» в агрегаты, так же не совсем верен. Агрегат гарантирует сохранение некоторых бизнес инвариантов, но при этом бизнес логика может делегироваться как корню агрегата, так и другим сущностям, доменным сервисам и тд.
Нет, не рассматривал, да и не уверен что Haskell удобен в контексте системного программирования.
В бытность PHP разработчиком работал в одной из компаний из списка. Это худшее место в котором я когда либо работал. Конечно я не про какой то неадекват. Но с точки зрения технологий, бюрократии, саморазвития - худшее.
alloca есть как минимум
... что впринципе и является выделением памяти, ведь мы получаем больше виртуальных адресов для использования.
В линуксе вниз граница не двигается, в этом смысле предпочтительнее ммап- выделенную им память можно отдать обратно ос.
Давайте не переводить разговор в русло: "почему комментатор комментирует". Because i can.
По поводу темы - я не считаю что не об этом. Вы обозначили преимущества поразрядной сортировки в общем случае (да в частных случаях она может быть хороша - но в статье я не вижу об этом), я с этим не согласен и привожу свои аргументы.
Извините но ваши выводы о сортировках - это без комментариев, информация вроде в открытом доступе есть, уж по квиксорт vs mergesort точно.
Спор по производительности тоже банальный, вот бенчмарк (из вашей статьи), можете запустить и убедиться:
https://play.golang.org/p/OChn_R2qe_s
Ну так почему в оппоненты своей реализации вы берёте generic реализацию?
Напишите квиксорт для слайса интов- тогда будет честное сравнение (и думается radix не выйдет из него победителем).
1 А поиск в хеш таблице с бакетами О(n) в худшем случае, только думается на собеседовании в озон ожидают другого ответа на вопрос о сложности поиска в хэш таблице ;)
Возвращаясь к квиксорту- зависит от выбора опорного элемента, применяя простые техники вероятность получить квадрат очень низкая. Так что обычно говорят об ожидаемом времени работы - nlog n. Загляните в сорцы стандартной сортировки, там должно быть что то про сложность.
2 Вы видимо не понимаете в чем претензия. Дело в том что в текущем go производительность обобщенного алгоритма будет ниже производительности того же алгоритма написанного с конкретным типом данных. Это происходит из-за того что go не выведет тип на этапе компиляции - соответсвенно будут накладные расходы в рантайме.
1 В том числе о нем и речь, откуда n^2?
2 Так в том и дело что вы написали алгоритм для интов а в стандартной библиотеке generic алгоритм, откуда тут равные условия
1) Встроенная сортировка имеет n*log(n) сложность.
2) Сравниваете generic реализацию сортировки из стандартной библиотеки со своими реализациями в которых зашит int.
3) Radix сорт в отличие от например q-sort имеет еще и накладные расходы по памяти.
Вообщем сравнение некорректное как по мне.
Двоякое отношение к Yii. Yii2 в свое время помог "войти в профессию" и форум фреймворка был классный, но вот Yii3... Со стороны выглядит несколько противоречиво - топка за различные PSR'ы (роутинг, di, реквесты и тд) и при этом собственная реализация. Есть ли обоснование - зачем пилить свои имплементации шаблонных вещей когда вокруг куча готовых, протестированных, оптимизированных? Не является ли это бутылочным горлышком в процессе реализации фреймворка?
Пожалуйста! по поводу 1.17 - есть такое, рассчитывал дописать статью несколько позднее.
В свое время пилил ормку для автомаппинга больших графов сущностей, но как оказалось это не особо кому нужно. В микросервисах развесистая бизнес логика (а за ней и развесистые агрегаты) не частое явление.
e = new entity(id: 1)
eCollection.add(e)
alsoE = eCollection.byID(1) <- создается ли тут новый инстанс entity? Если нет почему он должен создаваться когда eCollection это база данных?
ORM как раз ничего не создает, а восстанавливает из хранилища в соответствии с persistance ignorance. Если вы в коллекцию сущностей в оперативке добавите а потом запросите сущность, вы же не ожидаете что вызовется конструктор при запросе?
Другими словами корень агрегата создается ровно 1 раз, что как раз по DDDшному ибо отражает язык бизнеса.
Если угождать всем и каждому - получится свалка из конструкций и концепций. В итоге php придет к тому с чего начинал - str_rot13 и вот это вот все.
Может, конечно, три года в go так влияют, но релизы чуть ли не полностью состоящие из syntax sugar воспринимаются как то искусственно что ли. Как будто: "мы не знали что делать с языком (но делать что то надо) поэтому вот вам гора сахара - будете экономить минуту в день при написании кода". И как то люди забывают, что код надо не только писать, но и читать, и увеличение когнитивной нагрузки при чтении это не то чтобы плюс.
(печальный взгляд из гошного лагеря)
Думаю в тех кейсах где Вы добавите новый сервис, я смогу добавить новый агрегат. Но, что если речь идет о каком нибудь OrderService и вам нужно имплементировать фичу, ну например отмены заказа. Будете ли вы создавать отдельный сервис для этого? Ведь сейчас к модулю Order у вас есть четкий API находящийся в OrderService, какой смысл разделять его? Я считаю, что в данном случае никакого, ровно та же аналогия и с агрегатами которые также предоставляют API к доменному слою.
В случае ООП это противоречит инкапсуляции.
Согласен, это странно, не могу говорить за автора, но возможно имелось в виду — используя агрегаты мы получаем одну точку доступа к нашей бизнес логике.
Тоесть в случае анемичной архитектуры — при добавлении публичных методов в сервисы, open/close нарушен не будет?
Тот момент, что бизнес логика «зашита» в агрегаты, так же не совсем верен. Агрегат гарантирует сохранение некоторых бизнес инвариантов, но при этом бизнес логика может делегироваться как корню агрегата, так и другим сущностям, доменным сервисам и тд.