• Имеет ли данная схема организации БД право на существование?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Право существовать имеет но.... а смысл?

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

    Соответственно у нас появляется разделение - все операции на запись работают исключительно с реляционкой, все операции на чтение - с nosql (ну или часть с nosql и часть с реляционкой, тут смотря что вы хотите ускорять и есть ли смысл в организации агрегации данных).
    Ответ написан
    2 комментария
  • AngularJS $scope и array - баг или фича?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    без моего ведома фильтровать этот array?

    нет, но массив может быть изменен из другой части системы, например если он пробрасывается в директиву.
    Ответ написан
  • Как подружить backend (java) и front Angular?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    я не экстрасенс но...

    CORS
    Ответ написан
    Комментировать
  • Книги vs оф. документация vs статьи vs видеокурсы: как лучше всего изучать новую технологию, или фрейворк?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в случае библиотек - смотрю примеры что бы понять что эта штука делает и зачем она, потом лезу в код и документацию
    в случае фреймворков - смотрю какой-нибудь шорт гайд или геттинг стартед - лезу в код и документацию.

    Скажем где-то год назад я разбирался с новой для меня штукой - webgl, википедия, статьи в интернетах, примеры, и вроде как основы разобрал. Далее начал писать примитивную игрушку просто что бы разобраться, на этом и остановился. Далее скорее всего пошли бы книги, более углубленное изучение архитектуры GPU и организация графического конвеера, книги по opengl и т.д. К счастью часть из этого я уже знал да и необходимость в webgl у меня была только для ускорения обсчета картинок на клиенте.
    Ответ написан
    Комментировать
  • Почему до сих пор нет автоматической HTML - верстки страницы?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Почему нельзя обучить нейросеть верстать страницы

    Потому что нельзя нейросеть обучить верстать, она может только классифицировать. Тут вон люди не умеют и учатся годами....
    Ответ написан
    1 комментарий
  • Частое нарушение идеологии, в частности в Laravel или так и должно быть?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    CleanArchitecture-81565aba46f035911a5018
    Использовать модель B в контроллере A, это норма?или 1m=1c?тогда как болтать меж собой контроллерам?


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

    Давайте попробуем упростить эту картинку до MVC в самом простом его виде (я про ту шту. В этом случае слой Use Cases (Application layer или операционный уровень у Эванса) сольется с контроллерами. У нас будет по экшену контроллера на каждый юз кейс который выполняет приложение. Это как бы плохо, так как контроллеры перестают выполнять обязанность быть адаптерами к интерфейсу, но если интерфейс у нас один и только один - проблемы нет.

    Далее, разбираемся что есть модель - модель это совокупность всех бизнес правил и бизнес объектов, где бизнес правила это сервисы уровня модели, а бизнес объекты это наши сущности или... модели в контексте AR. Согласитесь, это нормальное явление когда в рамках какого-то юз кейса мы оперируем несколькими моделями. То что у вас половина сущностей названа как контроллеры - это только потому что того требуют ваши кейсы, они так и называются - зарегистрировать пользователя, авторизовать пользователя, добавить друзей.... Юз кейсы определяют флоу работы системы.

    Так что да, это более чем нормально в рамках серверной интерпритации MVC работать с бизнес сущностями A и B в контроллере C.

    А теперь попробуем наладить дела. Про Application layer мы уже говорили, давайте все юз кейсы вернем туда. То есть наш контроллер будет забирать данные из реквеста, преобразовывать в тот формат который кушают наши сервисы из application layer и дергать их. Ну и затем контроллеру так же придется сформировать результат работы этих сервисов в тот формат, которого требует интерфейс. И вот у нас уже с бизнес сущностями A и B работает сервис C, а контроллер всего лишь просит что-то делать и занимается переводом. Так когда мы захотим к WEB добавить REST то нам просто надо будет дописать контроллеры и не трогать логику.

    Теперь задумаемся о том что есть бизнес объекты и что они должны знать и уметь. Эти штуки хранят данные и знания о том как с этими данными работать. Обычно там содержится самая высокоуровневая логика. Ну то есть у вас есть очень простые бизнес правила которые распространяются на один объект - типа пользователь должен иметь всегда валидный email и не пустой пароль, или там.... вы не можете создать пост не указав категорию. Такие правила реализуются за счет того что данные передаются в конструктор и вы не можете создать объект нарушив это правило. Ограничение ответственности тут простое - все эти правила должны касаться только самой сущности, если у вас есть правила затрагивающие несколько сущностей, и между ними нет очевидной связи, то такие правила лучше выносить в маленькие сервисы, которые выполняют такого рода проверки. Их можно в сущности потом передавать через дабл диспатч при вызове методов и т.д.

    Далее что есть юзкейс - это некий сервис (просто какой-то класс), который делает работу в рамках какого-то юз кейса. Причем давайте условимся что у нас на каждый кейс по сервису, так чуть проще. В итоге у нас будет класс с одним публичным методом который принимает на вход какие-то штуки и дергает другие сервисы декларирующию бизнес правила. То есть сам сервис нужен только для того что бы сказать другим сервисам что сделать и в какой последовательности, он дирижер и его задача только управление оркестром, управление моделью.
    Ответ написан
    8 комментариев
  • Как правильно работать с Асинхронностью в Node.js?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Разберитесь с event loop для начала

    - колбэки
    - промисы
    - корутины

    Выбирайте, самое сложное и красивое внизу.
    Ответ написан
    Комментировать
  • Как лучше создавать класс в javascript?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в чём же разница в new 'класс' и object.create 'класс',


    Object.create не вызывает конструктор, именно по этой причине так удобно при помощи оного выставлять в качестве прототипа другие объекты.

    создавать классы, в прототипном или функциональном стиле ?

    в js нет классов. В любом случае - лучше методы объявлять в прототипе.

    https://babeljs.io/docs/learn-es2015/#classes
    Ответ написан
    Комментировать
  • Как реализовать параллельные вычисления?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    нода хоть и быстра но она однопоточна. лучше возьмите erlang или go.
    Ответ написан
    Комментировать
  • Как в директиве получить контроллер в который она обернута?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    или если его и не нужно получать по идеологии, то почему?

    потому что это создает зависимость директивы от контекста, в котором она используется. Проследите логику

    1) работа директивы требует того что бы она была обернута в SomeControeller на уровень выше.
    2) директива становится частью SomeControeller, или если быть точным, куска view которым управляет SomeControeller.
    3) нет смысла в директиве, так как мы не можем более реюзать ее в другом месте
    4) если директива зависит от контроллера SomeControeller, почему бы не вынести из SomeControeller то что нужно директиве в ее собственный контроллер?

    как-то так. Все взаимодействие с директивой должно происходить либо через контроллеры директив (параметр require директивы), либо через атрибуты (изолированный scope, bindToController в angular 1.4). И уж тем более странно желание подменять методы контроллера из link.

    updated

    короче суть в непонимании того что есть директива как я понимаю. Директива - самодостаточная единица (самостоятельное маленькое MVC приложение). По хорошему она может зависеть только от других директив, но ей глубоко должно быть плевать где именно и как ее используют. Она выполняет свой маленький кусочек логики. Некоторые директивы выступают в роли фасадов, инкапсулируя в себе и упрощая работу с множеством директив.

    Далее, по поводу обработчиков - яркий пример директива ng-click. Эта директива выглядит как-то так:

    function myNgClick() {
        return {
            restrict: 'A',
            scope: {
                callback: "&myNgClick"
            },
            link: function (scope, el) {
                el.bind('click', function (e) {
                    scope.$apply(function () {
                         scope.callback({$event: e});
                    });
                });
            }
        }
    }


    Как мы видим на этом примере, у нас есть директива, чья основная задача - вызвать что-то по клику на элемент. И все. Через эту директиву мы скажем можем дернуть метод контроллера другой директивы. В этом проявляется сила ангуляра, мы можем проводить декомпозицию элементов интерфейса настолько глубоко насколько мы вообще хотим. делать крайне изолированные, маленькие и простые директивы, которые очень легко покрыть тестами и легко использовать.

    link директивы нужен ТОЛЬКО для того что бы связать DOM и логику. То есть в 99% случаев в директиве будет только link или только контроллер. Оба - это уже стремно, в этом случае лучше вынести ту логику которую хочется запихнуть в link в отдельную директиву.

    контроллер (мы сейчас отойдем чуть чуть от MVC только ради того что бы упростить все) реализует всю логику (или делегирует модели). Вся логика не относящаяся к DOM а например относящаяся к обработке данных должна быть вынесена в контроллер.

    Пара слов по поводу ng-controller. Это так же директива, которая позволяет привязать к элементу какой-то контроллер. Эта штука по сути (как и ng-include в принципе) нужна только для ускорения разработки и упрощения. В целом же приложение на angular стоит воспринимать как HMVC приложение, состоящее исключительно из деревьев директив. Первый шаг на пути к web-components (по сути ангуляровские директивы послужили неплохим глотком вдохновения).

    Как-то так.
    Ответ написан
  • Как сократить повторяющийся код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    у вас там три колонки, по сути зная индекс чекбокса на который мы кликнули, мы можем сделать все что нужно в рамках нужной нам колонки, это уже избавляет нас от необходимости дублировать все три раза.
    Ответ написан
    Комментировать
  • Проблема с фильтром в Angular.js, что делать?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    var phones = []; // наша исходная коллекция
    $scope.updateList = updateList;
    updateList();
    
    function updateList(name, status) {
        // логика упрощенная, должно быть явно не так но передает суть.
        $scope.phones = phones.filter(function (phone) {
            return -1 !== phone.name.indexOf(name) && phone.status === status;
        });
    }


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

    p.s. проверьте темплейт на опечатки. У вас там затесался лишний знак доллара.
    Ответ написан
    Комментировать
  • Как вы постигали жестокое ооп в javascript?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    жестокое ооп в javascript

    для начала - ООП в JS не жесткое, оно как раз таки упрощенное до нельзя.

    классической модели ооп

    Берем классическую модель ООП и...
    - инкапсуляция происходит не за счет модификаторов доступа а за счет сокрытия всего приватного в модулях/замыканиях.
    - Классов нет, но у каждого объекта есть конструктор и прототип (которые в свою очередь так же явлюятся объектами), что по сути то же самое но отличается тем, что у каждого экземпляра объекта, порожденного конструктором, своя копия прототипа, а значит если мы поменяли прототип то все рожденные ранее объекты не будут иметь изменений.
    - контекст вызова в js определяется по владельцу метода, который мы вызвали (ну или его можно подменить руками через call/bind/apply)
    - конструкция new Foo создаст объект с типом Foo, скопирует прототип и затем вызовет конструктор, который по умолчанию не явно возвращает контекст вызова, но вы можете там явно вернуть что угодно, что показывает что это обычная функция.
    - наседование с прототипом работает так же просто, проверяем есть ли что-то у объекта, если нет - идем по цепочке прототипов ниже и ниже. Если мы хотим обратиться к методу прототипа (как бы вызвать parent метод) то нам надо сохранить на него ссылку.
    - Что бы упростить работу со всем этим делом - вооружайтесь babel.js и используйте "классы", суть остается той же но меньше кода да и выглядит логичнее и привычнее.

    Вот как-то собственно и все.
    Ответ написан
    3 комментария
  • Как работает MVC controller?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) контроллер - это медиатор (посредник) между view и model, кроме как связывать эти два компонента он ничего не должен делать, все делегируется в эти два слоя
    2) все контроллеры должны быть stateless - то есть никаких сохранений параметров и прочего.
    3) каждый "экшен" контроллера должен быть независимым.
    Ответ написан
  • Почему не работает UI - ROUTER в Angular?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    $rootScope.$on(
        '$stateChangeError',
        function (event, toState, toParams, fromState, fromParams, error) {
          if (!angular.isString(error)) {
            error = JSON.stringify(error);
          }
          $log.error('$stateChangeError: ' + error);
        }
      );


    приятного дебага, и поправьте опечатку с темплейтом в contacts.list
    Ответ написан
    Комментировать
  • Как лучше организовать работу с сервисами в контроллере $this->get('service') vs controller as service?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    или внедрят по тайп хинтингу

    На самом деле тут есть варианты:
    - написать compile pass который будет агрегировать всю эту инфу + param converter который будет инджектить сервисы в контроллер (можно взять за основу готовые штуки, типа как тут и тут
    - использовать PHP-DI

    Остается вариант контроллеры как сервисы.

    Этот вариант хорош только в случае если у нас контроллеры толстые, что само по себе плохо.

    Как у вас организованно контроллеры?

    экшен контроллера собирает данные из запроса (можно просто кастомные запросы делать и через парам конвертеры разруливать) и передает в сервис уровня приложения, потом выводит результат его работы. Использую get метод и не парюсь, контроллеры это вообще не то о чем надо париться (кроме того что они должны быть тонкими).
    Ответ написан
    5 комментариев
  • Порядок объявления свойств в селекторе?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    договоренности такие есть только в командах. В целом есть рекомендации и подходы. Есть подходы согласно которым селектору не желательно иметь позиционирование и оформление (BEM), тип так:

    .block-a {
       // оформление
    }
    .block-a__child {
         // позиционирование дочернего блока
    }
    
    .block-child {
         // оформление дочернего блока
    }
    Ответ написан
    Комментировать
  • Какова ниша js фреймворков?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    ну например google music написан на polymer

    что до builtwith - там как бы да, слегка разачаровываешься обычно когда просматриваешь это дело, там только парочка интересных проектов а все остальное - что-то простое.

    Веб-сервисы. Все понятно, туда сюда гонять XML/JSNON, JS вообще не нужен

    что для вас web сервисы и откуда там "гонять json"? Я правильно понимаю что вы сейчас о микросервисах на бэкэнде? Причем тут тогда фронтэнд?

    веб-приложения. Как правило, наборы гридов

    Хватит думать десктопными интерфейсами начала двухтысячных. Лично я считаю гриды дурным тоном (за очень редкими исключениями списки намного лучше справляются с выводом информации).

    Вот сижу и думаю, что за типы проектов должны быть, в которых применение фреймворков действительно было бы оправдано,


    Да на самом деле любой single page application, ибо фреймворк (например тот же angular) дает вам готовую инфраструктуру, позволяющую изолировать все по слоям, делать изолированные и легко покрываемые тестами (вы же не будете спрашивать зачем нужны тесты?) элементы интерфейса. А бизнес логика на клиенте в подавляющем большинстве простая, обычно все упирается именно в UI и как все это дело организовать. Фреймворки существенно упрощают разработку.

    Ну и еще на angular (а точнее на ionic) сделано приличное количество гибридных приложений (cordova/phonegap)
    Ответ написан
    Комментировать