Задать вопрос
  • Есть ли объективные причины отказаться от аннотации?

    wittyrider: а никак, они не для того что бы их сериализовывали/десериализовывали. Вообще как, и jms и symfony сериализаторы поддерживают аксесоры через рефлексию, так же как это делает доктрина при гидрации данных. Но вообще сериализирую я не сами сущности а DTO, ибо сущностям не место в контроллере, а сериализации не место где-то еще кроме контроллера (или фронт контроллера).
  • Как получить модель в директиве?

    vasIvas: что до js-data, я не могу сказать вам что знаю как оно надо делать, есть разные варианты. Я обычно запихиваю это дело в сервисы-репозитории, которые инкапсулируют логику сохранения данных. Так я делаю свой код более изолированным, можно скажем в рамках одного репозитория хранить данные в webstorage а в другом через js-data данные сохранять/доставать. А вот нужно ли репозитории выносить в отдельный модуль я пока не решил. Мне нравится эта идея но с ней есть свою нюансы. В TS есть интерфейсы и можно в отдельном модулей хранить реализацию только. Я же большую часть времени работаю с ES2015 и как-то... там с этим сложнее. Пока я не замарачиваюсь, мне достаточно изоляции на уровне репозитория.

    По поводу копирования структуры ORM на сервере - нет конечно, вы же работаете с API, а ресурсы в контексте HTTP это далеко не всегда сущности в базе или проекция таблиц. Чем меньше ваш клиент будет знать о реализации сервера тем лучше.

    А вот shema + валидация - тут как бы как, валидация тут нужна если вы сущности на клиенте создаете, а не только загружаете. Я лично ею не пользуюсь. Как альтернатива схемам можно вместо json использовать protocol buffer, тогда и трафик будет экономиться и проблема с валидацией схемы отпадет.

    По поводу загрузки в store.defineResource - чисто теоритически вы можете через import json загрузить. Я думал об этом, правда в контексте кодогенерации. Но пока руки не дошли. Если у меня этот json не будет генерироваться из apiblueprint например то смысла в нем мало для меня лично.
  • Как получить модель в директиве?

    vasIvas: я так и не понимаю как по вашему это должно работать. В гемдеве обычно применяют ECS, и там все действительно на ивентах и так как вы хотите. Никто в зравом уме не пихает MVC в игрушки, там совершенно другие принципы. MVC же нужно для приложений, где не нужно реагировать на изменение состояния по 60 раз в секунду.
  • Как получить модель в директиве?

    vasIvas:

    1) сервер не модель, это поставщик данных, ваш persistence layer.
    2) тип того, я обычно не рассматриваю контроллер директивы как отдельную сущность. Это просто контроллер директивы, я даже по разным файлам их не раскидываю ибо не вижу смысла - и не экспортирую его нигде.
    3, 4, 5, 6) - тут как хотите, можете вручную, можете заюзать какую-нибудь директиву для отображения деревьев и т.д. Причем в этом случае link не нужен вовсе, данные подготовить можно в контроллере, он для этого и нужен. А потом передать во view.

    Да, старый добрый MVC. Только меня трактовка смущает. view говорит контроллеру что что-то случилось, контроллер просит модель дать ему данных и конвертит его в формат который понимает view и собственно скармливает ему. То есть controller это переводчик, посредник, как и положено.
  • Как спроектировать JavaScript приложение?

    Иван Антонов: UML не нужен, все это дело заменили BDD-шные сценарии с примерами поведения, сторимэппинги и т.д. Модель теперь проектируется как можно ближе к языку предметной области, единственное что осталось - введение акторов разве что и юз кейсы.
  • Как спроектировать JavaScript приложение?

    Иван Антонов: мне всегда казалось что кодеры это и есть люди которые используют готовое... ну или реализуют то что на UML описал архитектор (что уже давно вымирает).

    И не вымрут они. Джуниоры нужны всегда.
  • Как спроектировать JavaScript приложение?

    Макс Минимус: да и ковыряние в популярных решениях на определенном этапе будет давать намного больше опыта чем написание своих велосипедов.
  • Как спроектировать JavaScript приложение?

    Макс Минимус: я не понимаю одного, в контексте вопроса небыло ровным счетом ничего о студентах.

    Студенты и школьники должны снова и снова имплементить известные алгоритмы что бы разбираться в их сути, да они должны написать хотя бы пару велосипедов. Но, это только для себя. Потом все эти велосипеды надо сжечь и использовать готовое. А использовать самопис в коммерческой разработке (на себя или кого-то другого) - это в итоге выльется в большие расходы на поддержку.

    Все программисты умеют писать сами и все программисты могут использовать свой код. Другое дело что далеко не все понимают когда нужно одно а когда другое. И еще большая проблема - отсутствие культуры разработки.
  • Как спроектировать JavaScript приложение?

    Макс Минимус: а в прочем забейте, глянул ваш вопрос, и понял что переубедить вас не выйдет. Продолжайте жить в своем выдуманном мире, где все что писали не вы - плохо.
  • Как спроектировать JavaScript приложение?

    Макс Минимус: например программируя на Си мы загоняем себя в рамки процедурного программирования.

    Что до "ооп это лишь определенный стиль" - нет, это намного больше. Это идея построенная на 4 довольно простых и одновременно сложных для осознания принципов. ООП проще чем функциональная парадигма, и дает довольно мощный инструмент для построения абстракций.

    Да и в целом, не использовать ООП в js не выйдет, так как там все есть объект и так или иначе у вас будет взаимодействие объектов.

    Если нормально зачетно грызть гранит науки то может быть и чужих фоеймворков не захочется

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

    Сейчас фреймворки примерно сравнялись по возможностями и движение идет в сторону модульности. Хотите - используйте компоненты одного вместе с компонентами другого. Не использовать готовые решение это признак не дальновидности. Если вам нравится поддерживать свой код, который выступает лишь инфраструктурой для функциональности вашего приложения, это ваше дело, но с точки зрения бизнеса это не круто. А мы ведь пишем код не потехи ради, а что бы делать наших кастомеров хэппи (будь то клиенты заказавшие нам программу или пользователи нашего собственного продукта).
  • С чего начать изучение написания TDD - тестов?

    abcd0x00:
    Вот тесты:

    Ну круто, да, конкретно в этом лучае выходит много тест кейсов, но это не потому что TDD плохой а потому что ваша функция умеет сразу много всего. Попробуйте покрыть такое тестами, и тестов станет сразу меньше:

    func add(a int, b int) int {
       return a + b; 
    }


    Для библиотек такое покрытие кода тестами необходимость, у меня так же есть примеры где для одного метода библиотеки появляются десятки сценариев.

    Но опять же, как было бы если бы вы практиковали TDD:

    - написали тест
    func(1, 2) == 3
    - написали код, потому что тест зафэйлен, нет такой функции
    func([1], [2]) == [1, 2]
    - тесты зеленые, ничего не надо писать

    Далее ваши тест кейсы по сути покрывают функционал оператора + языка на котором вы пишите, в этом не особо много смысла. Дополнительные тесты вы можете написать только ради покрытия различных пограничных случаев, но это не то для чего нужен TDD. Если вы не уверены в каком-то случае вы записываете его в виде теста, но не более. Если вы сходу записываете все пограничные случае - это здорово, но TDD приследует не эту цель.

    А теперь представьте себе такой тест
    describe('comments', () => {
        // ...
         if('allows to make abuse on comment only once for user', () => {
            commentAlreadyHasAbuses(1);
            expect(this.comment.isVisible()).to.equal(true);
            this.comment.abuse(this.createUser());
            this.comment.abuse(this.createUser());
            expect(this.comment.isVisible()).to.equal(true);
        });
    
        it('hides after abuse from author of the post', () => {
            this.comment.abuse(this.postAuthor);
            expect(this.comment.isVisible()).to.equal(false);
        });
    
        if('hides after 3 abuses from different users', () => {
            commentAlreadyHasAbuses(2);
            expect(this.comment.isVisible()).to.equal(true);
            this.comment.abuse(this.createUser());
            expect(this.comment.isVisible()).to.equal(false);
        });
    
        function commentAlreadyHasAbuses(amount) {
           for(let i = 0;i<amount;i++ {
               this.comment.abuse(this.createUser());
           }
        }
    })


    это более-менее реальный пример. Да, кода выходит раза в полтора больше чем в реализации метода abuse моей сущности, но это довольно тупой код. + я думаю его можно сократить. Но это реальные кейсы. Причем добавлялись они не сразу сходу. Скажем сначала была возможность абьюзить комментарии. Потом добавили правило что после определенного количество жалоб комменты должны прятаться. Потом правило для автора. Релизы раз в неделю и все такое. Инкрементая разработка. Ну и да, тест не копипаста, выдуманный. В оригинале он на phpspec.

    потому что кое-кто не знает про предпросмотр. ;)

    У комментариев есть предпросмотр? Предпросмотр есть только у ответов и вопросов. Да и почему нельзя было добавить markdown я не понимаю.
  • С чего начать изучение написания TDD - тестов?

    abcd0x00: короче почитайте Кента Бэка, либо переведем дискуссию в личку. Мне уже немного надоело цитаты расставлять)
  • Зачем нужны события в yii2?

    HaruAtari: я не говорю о тестировании диспетчера событий, я про то что приходится мокать диспетчер что бы отследить какие ивенты были сгенерированы системой. Это нормальная практика, особенно когда ивенты генерятся сервисами. Я же использую domain events, разница в этом подходе лишь в том что мне не надо мокать диспетчер, так как он дергается только по postFlush доктрины, тогда из всех сущностей учавствовавших в транзакции (а точнее все что лежит в UoW) забираются все события которые произошли с моделью. А значит в тестах я могу получить список этих ивентов как обычный массив просто вызвав метод модели.
  • С чего начать изучение написания TDD - тестов?

    abcd0x00:
    Так а где тут разработка через тестирование?

    Это конкретно фаза рефакторинга. Разработка через тестирование в том что вы не должны писать код пока у вас нет красных тестов. Фаза рефакторинга же является одной из основной, так как именно тут мы добиваемся какой-то чистоты код. А все что до этой фазы это та самая PoC реализация.

    Первый признак того, что привести нечего особо.
    Про NDA слышал? К сожалению я не могу предоставлять исходники своих проектов. А что-то на гитхабах посмотреть можно.

    Программа должна быть надёжной сама по себе, а не по критерию "клиент принял - значит, всё правильно".

    важность каждой фичи вашего приложения не равноценна. Некоторые важнее, некоторые второстепенны. Скажем если вы пишите бизнес систему и у вас отваливается загрузка аватарок никто особо грустить не будет, но если сломается бизнес логика обработки платежей и т.д. - то тут будет беда.

    Да и без этого тестов навалом, потому нюансов бывает дофига и больше.

    Опять же у вас есть пример?

    Ну, у тебя-то, походу, этим тестировщики занимаются

    написанием юнит тестов? Юнит тесты исключительно задача разработчика, QA могут разве что E2E тесты писать. К сожалению у меня есть только пара проектов где QA пишут E2E, в остальных случаях этим занимаюсь я.
  • Зачем нужны события в yii2?

    HaruAtari: ну я правильно понимаю что вы мокаете диспатчер или что-то в этом духе, так?
  • Как писать код для библиотек у которых нет деклараций?

    vasIvas: в es5 нет модулей, вы видимо имеете в виду CommonJS.

    трансляторы обычно делают пустой объект с пропертей $default или что-то в этом духе. Ну во всяком случае когда-то так было, еще во времена когда вроме es6-module-transpiler ничего толкового небыло.
  • Зачем нужны события в yii2?

    HaruAtari: в Yii2 вроде ж запилили нормальный IoC аля Laravel... мне кажется кастыли идут от AR а не от Yii.
  • Зачем нужны события в yii2?

    проблема не в слишком слабой связанности а в недостаточном зацеплении (coheashing) и сложностях в дебаге и покрытии тестами. По сути логику на ивентах невозможно нормально замокать, потому только функциональные тесты.
  • Зачем нужны события в yii2?

    Как фанат DDD вставлю свои 3 копейки, событие "пользователь создан" должно зафаириться только после того как пользователь действительно был создан, транзакция в базу пошла успешно и т.д. То есть либо из сервисного слоя либо domain events но это не про Yii2