• Как я писал кодогенератор на PHP и что из этого получилось
    +1
    Сокращенная форма — это <? ?>. Её не рекомендуется юзать чтоб не было потенциальных конфликтов с xml
    В шаблонах юзать <?= ?> очень даже ок, тем более, что эта запись доступна даже при выключенном short_open_tag
  • Как я писал кодогенератор на PHP и что из этого получилось
    0
    Начиная с версии PHP 5.4.0 запись <?= стала доступна всегда.
  • [Symfony 5] Раздельная авторизация для админов и пользователей с двумя разными сущностями и формами входа
    0
    У вас есть массив провайдеров и массив файерволов. 2+2?
  • Задачи с собеседований (front-end) часть 2
    0
    Задача: Уникализация значений в массиве.

    developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Set
  • Как мы разработали сервис, который вошел в топ-5 крупнейших аптечных сайтов мира
    0
    А расскажите поподробней как вы доктрину к битриксу прикрутили?
  • Как я (PhD нейробиологии) стала Data Scientist за 6 месяцев
    +2
    Знакомое такое лицо на заглавной
  • Comet — PHP-фреймворк для быстрых REST API
    +1
    Именно потому фб и напилил HHVM, а ВК KPHP, что просто php уже не подходил. Банально начали делать на том, на чем могли, а переписать уже слишком дорого. На фоне затрат на смену стека, смена фреймворка — копейки.
  • Comet — PHP-фреймворк для быстрых REST API
    +1
    Если важны миллисекунды, то php не берут.
    Если есть возможность ускорить проект практически бесплатно — то почему бы и нет?
  • Comet — PHP-фреймворк для быстрых REST API
    0
    Да, дошло. Спасибо
  • Comet — PHP-фреймворк для быстрых REST API
    0
    он всегда будет возвращать 500 ошибку…

    Я конечно не xDebug, но как вы пришли к такому выводу?
  • Идеальный смартфон
    0
    Здорово, только в обычном Android и всех сторонних прошивках, которые я пробовал


    Это значит только то, что вы обобщаете там, где не следует. Вся прелесть андроида в том, что он бывает разным и каждый может подобрать себе по вкусу. И, если совсем ничего не подходит, можно даже самому напилить оболочку.
  • Идеальный смартфон
    0
    у вас даже на видео видно, что список приложений тоже скролится
  • Идеальный смартфон
    0
    У меня это окно вызывается свайпом от низа экрана на любом экране и с любого приложения.
  • C++/Qt: пора валить?.
    0
    В вебе фреймворков хватает на любой вкус и цвет. И как мне кажется, в описанной автором ситуации лучше бы подошел не PHP, а node с с изоморфным приложением.
  • Идеальный смартфон
    0
    Ну из отличий я только вижу то, что ваш виджет обновляет состояние свое. Не знаю на сколько это важно, потому что для меня объективно работать более чем с двумя приложениями одновременно на экране телефона — неудобно.
  • Идеальный смартфон
    0
    Андроиды список приложений умееют 100 лет же
  • Comet — PHP-фреймворк для быстрых REST API
    +3
    Я думаю, что предзагрузка должна очень сильно оптимизировать существующие фреймворки. Да и RoadRunner сейчас это очень неплохо делает.
  • Идеальный смартфон
    0
    Project Ara, ты ли это?
  • Зачем (не)нужны геттеры?
    0
    Читать рид модель с одной таблицы или с другой бд или вообще хранить в памяти — дело сугубо ваше. В хендлере не нужно дублировать логику. В домене есть бизнес правило, которое определяет срочность заказа. В доменной модели это правило реализовано в методе isUrgent(): bool;

    Хендлер вызывает этот метод и результат сейвит в рид модель.
  • Идеальный смартфон
    0
    У меня была шальная идея в дороге играть в героев, червей и другие игрушки с хот-ситом под виной. На планшете это конечно было бы удобней, но хотя бы на телефоне.
  • Зачем (не)нужны геттеры?
    0
    Вот при изменении в заказе, по доменному событию хендлер считает их вычисляемые значения и зайсевит в рид модель
  • Зачем (не)нужны геттеры?
    0
    Когда несколько частей системы (или, что хуже, несколько систем) используют для совместного доступа к одной и той же информации БД (или другое хранилище).


    Тут есть нюанс, пишут в бд одном месте, а читают в другом (чаще всего еще и с реплики). И как я говорил, читать могут совершенно с другого хранилища, оптимизированного под нужды чтения.

    Теперь касательно апдейта коммента в заказе. Да, если весь ваш апдейт сводится к присваиванию строки, то смысла особо нет что-то придумывать. Смысл появляется, когда есть хоть-какие-то бизнес правила. Например, что коммент не может быть изменен, если заказ в финальном статусе. Вот тут и вылазят всякие isEditable, в которых инкапсулирована бизнес-логика. И находится он в доменной модели. В рид модели ее нет, в рид модели есть только необходимые для отображения данные, без каких-либо проверок.

    Тот же пример с IsUrgent. Да никто не помешает вам забить на разделение отвественности и впилить проверку в рид модель, кроме здравого смысла. Я уже раз десять писал об isEditable и сейчас напишу еще раз про IsUrgent. Вот впилили вы свою проверку if (orderDto.Comment.Contains(«СРОЧНО!!!»)). В одном месте вы цвет поменяли, в другом сортировку подхачили, в третьем вывели в какой-то дополнительный виджет эти заказы. И вот к вам приходит ваш начальник и говорит, что расширяем продажи, будут клиенты иностранцы, будут менеджеры, которые с их заказами работают. Срочно теперь будет не только «СРОЧНО!!!», но и «URGENT!!!». Что вы делаете? Да, вы идете и правите все те места, где вы логику вынесли наружу.

    Еще пару дней спустя вас просят добавить галочку на форму заказа, которая за +100500 денег делает срочный заказ. И вы теперь идете во все те же места и добавляете OR orderDto.UrgentFlag. А потом еще появляется группа пользователей, у которых приоритетная доставка и все их заказы всегда срочные. И при каждом изменении логики работы со срочными заказами нужно пойти и везде поменять. Но можно же один раз описать правило в методе isUrgent в доменной модели. Один раз при измененнии доменной модели считать необходимое состояние и обновить рид модель, и юзать ее там, где это нужно, не дублируя бизнес логику на UI
  • Зачем (не)нужны геттеры?
    0
    Не совсем понимаю, что вы имеете ввиду через интеграцию через бд? В конечном итоге данные все равно хранятся в какой-либо бд, разве не так? Ну кроме случаев, когда все хранится в памяти, да.

    Да, в ДТО вы имеет доступ на чтение к состоянию заказа — это причина существования этого ДТО. Вы можете отобразить это состояние на интерфейсе. Вы не можете совершить никаких бизнес-действий с ним.
    Вы не дублируете бизнес логику на интерфейсе потому, что в ДТО нет бизнес-логики, а есть готовые для отображение значения.
  • Зачем (не)нужны геттеры?
    0
    Хранилище для ДТО апдейтится только по ивенту. Это может быть отдельное хранилище как с точки зрения програмного, так и вообще физически другое, например монга, которая хранит данные в удобном для поиска и чтения виде.

    Но это может быть и просто другой лоадер данных из БД с маппингом на ДТО, а не на бизнес сущности.
  • Зачем (не)нужны геттеры?
    0
    Да, а почему б и нет? Иногда это очень даже оправдано
  • Идеальный смартфон
    0
    вот 72 часа не замечал. Я не то что-бы ребутаю телефон каждый день, делаю это раз в неделю может или при апдейте ОС. Без ребута пин не просит
  • Идеальный смартфон
    0
    Мой Redmi тоже иногда хочет пинкод, вместо отпечатка. Это происходит после ребута. Точно так же, как на рабочем макбуке, после ребута он хочет именно пароль для входа в систему и разблокировки фингерпринта.
  • Идеальный смартфон
    +1
    Так чем вас не устраивают телефоны серий Redmi / Redmi note?
  • Зачем (не)нужны геттеры?
    0
    И попытайтесь понять почему transient reference, а не просто reference
  • Зачем (не)нужны геттеры?
    0
    В идеальном мире рид модель имеет собственное хранилище, оптимизированное под чтение. И рид модель содержит в себе все поля, которые нужны в рид-сценариях.
  • Зачем (не)нужны геттеры?
    0
    Обратите внимание на "Transient references"
  • Зачем (не)нужны геттеры?
    0
    А если внутри IsEditable идет не только сравнение с полем статуса?
    А если IsEditableByUser?

    В моем мире геттер экспоузит внутреннее состояние и по большому счету уместен только в ДТО.
    Метод содержащий бизнес-логику — не является геттером.

    Что из этих утверждений вызывает у вас непонимание?
  • Зачем (не)нужны геттеры?
    0
    Что вы пытаетесь доказать? Вы очевидно усложнили код, просто чтоб показать, что геттер во врайт модели это ок? Ну ради бога, если вам так больше нравится.
  • Зачем (не)нужны геттеры?
    0
    Это интересный вопрос. И простого ответа на него нет. Вообще вопрос разделения обязанностей один из самых сложных в разработке, уступая лидерство лишь вопросу об именовании переменных.

    Я допускаю вот такой вариант у ордера:
    public function shouldBeNotified(DatePeriodCalculatorInterface $calc): bool;


    Но, указанное вами бизнес-правило явно задевает более одного агрегата и тут уже оправдано вынести его в доменный сервис.
  • Зачем (не)нужны геттеры?
    0
    Хендлер спрашивает у врайт модели isEditable и результат пишет в рид модель.
  • Зачем (не)нужны геттеры?
    0
    Нет, потому что он не экспоузит внутреннее состояние. Он инкапсулирует в себе бизнес-логику.

    В случае рид модели тот же isEditable будет геттером, потому, что просто возвращает состояние приватного поля.
  • Зачем (не)нужны геттеры?
    0
    Очевидно, что некий хендлер доменного события
  • Зачем (не)нужны геттеры?
    0
    isEditable ок, потому, что он инкапсулирует логику в себе.
    Вы можете менять эту логику в одном месте, не затрагивая кучу мест, которые пришлось бы затронуть в случае использования getStatus() ==
  • Зачем (не)нужны геттеры?
    0
    в общем случае — это метод возвращающий некое значение. Чаще всего просто внутреннее состояние объекта, иногда содержащий какую-то логику. Чаще всего именуется как getSomething

    В шарпе можно не пилить методы, а сделать проперти, например.
  • Зачем (не)нужны геттеры?
    –1
    э-э-э, я говорю без привязки к языку, как бы