Задать вопрос
  • Чем обычная разработка клиента отличается от разработки на AngularJS?

    vasIvas: хз, сижу на IDEA год, до этого сидел на PHPStorm. Никогда никаких проблем.
  • На чем писать программы под Linux?

    sim3x: насколько я знаю все пока только в планах... под mono они только часть своих продуктов тестить собираются но не более.
  • Чем обычная разработка клиента отличается от разработки на AngularJS?

    vasIvas: вот 3 года являюсь пользователем продукции jetbrains и никогда таких проблем небыло. Хотя я встроенными ватчерами не пользовался никогда. Думаю если полазить по настройкам проблема решится, ибо не должно быть такой проблемы.
  • На чем писать программы под Linux?

    sim3x: и go и rust компилируемые языки, так что я бы поставил их выше Си или C++ в списке, аккурат после python.
  • Почему постоянно лезет undefined?

    Александр Прозоров: я не о конкретной реализации а о подходе - все это можно спокойно организовать на промисах, они дают более примитивные элементы flow control. Важна не реализация а идея.

    p.s. корутины всеравно поудобнее будут, хоть и сложнее.
  • Надо ли добавлять в кеш роутинг?

    Владимир Грабко: читаем еще внимательнее, он не нужен, кешировать между запусками нет смысла, а построенное дерево маршрутов хранится в память на все время жизни процесса.
  • Scrum: Кто пишет ТЗ? На сколько детально?

    OnYourLips: противоречия нет ровно так же как и ценности. Есть намного более удобные способы описывать требования и делать декомпозицию чем проектирование модели предметной области через UML. Конечно, есть проекты где это полезно, проекты с очень сложной бизнес логикой и т.д. Но как по мне фичаспеки с примерами (в контексте BDD) и тесты тут справляются лучше. Да и я уж не помню когда видел в последний раз как бизнес аналитики делают что-то сложнее из того что связано с UML кроме как определение акторов и запись юз кейсов.
  • Почему постоянно лезет undefined?

    Александр Прозоров: ну это всего-лишь своего рода надстройка над промисами и хороший пример как они помогают жить лучше...
  • Почему постоянно лезет undefined?

    nepster09: ну люди ж как-то живут. Хотя промисы вам бы думаю пригодились, с ними код хоть немного более читабельнее.
  • Почему Angular не видит модуль?

    Vasyl Pylypiv: давайте уточним, это ангуляр модуль не видит или что-то не так при сборке commonjs?
  • Для чего и как применять директивы в AngularJS?

    vasIvas: SPA это single page application, по сути это эдакое название для обычного (ну или толстого) клиента в контексте клиент-серверной архитектуры, то что оно single page означает только то что есть одна точка входа и все.

    Скажем в контексте того, чем занимаюсь я, это всякого-рода бизнес приложения. Например... вконтактики можно рассматривать как SPA, или gmail. Да даже тостер может быть реализован как SPA, для конечного пользователя разницы не будет, SPA это или просто сайт. Функционировать он будет схожим образом, просто сервер будет только данные предоставлять и ничего не будет знать о клиенте.

    Теперь канвасы и SVG - это маленький кусочек того, что нам предлагают DOM API и браузеры. Скажем на SVG удобно графики строить, на canvas можно игрушки делать (хотя лучше на webgl), или с картинками баловаться... или еще чего. По сути это очень узко специализированные вещи. Одно для работы с растром, другое для работы с вектором. Для работы с этими вещами существуют отдельные библиотеки.

    Давайте возьмем игрушку, у нас есть какое-то прилоежение-игрушка, на canvas/webgl. Это один элемент и куча логики поверх него + обработка DOM ивентов и т.д. То есть наше приложение-игрушка это лишь один компонент в контексте SPA, а не все SPA. Ангуляр вам тут поможет только в одном - изолирует это в директиву, а внутри делайте уже что хотите. Все что будет происходит с канвасами выходит за рамки того, для чего делался ангуляр. Он может вам предоставить сервисный слой для логирования, для работы с сетью... и все. UI - уже ваша забота в контексте этой задачи. Возможно у вас будут еще какие-то странички или отдельные состояния - тут ангуляр тоже может помочь, но с самой игрушкой - нет, не для того ангуляр делался.

    3D сайт - хороший пример. Что именно у вас будет 3D? Переходы по страницам в стиле "куб"? Так не вопрос, у вас есть директива изолирующая вьюпорт состояний, и вы можете довешивать на него дополнительную логику, которая скажем запускает анимацию по переходу на другое состояние. А еще мы можем дописать директиву которая сохраняет текущее состояние в кеш (примерно так сделали чуваки из ionic-а для оптимизаци перехода по скринам). Причем canvas/svg тут не нужны - все это можно делать через css. Если же вы хотите выйти за пределы DOM и отрисовывать все на canvas (как если бы мы работали с flash/flex) - то это опять же выходит за пределы ответственности ангуляра. Тут вам кое как может помочь ReactJS, так как он как раз таки предоставляет абстракцию над UI, и вы можете под копотом юзать хоть стандартный DOM, хоть свой движек на canvas/webgl. И опять же, вы можете использовать reactjs внутри ваших директив на ангуляре - это не запрещается.

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

    В вашем случае, помниться, вы пытались организовать общение контроллера плеера и контроллера элементов управления этого плеера. При том что в этом случае нам нужно общение только вверх (от элементов управления к плееру), я не вижу причин вводить тут ивенты. Единственно что, плеер может уведомлять скоуп об изменении своего состояния (например пользователь нажал паузу, но другим способом а не нажатием на кнопку). Это удобно, да. Но в целом все зависит от ситуации. Конкретно ангуляр вам никак не регламентирует как должны общаться директивы между собой. Я лично стараюсь избегать ивентов если могу, ибо их намного сложнее тестировать чем простой вызов метода мок-объекта.

    Ну и по поводу моделей. backbone позволяет организовать мэппинг данных на клиенте на api по типу active record, ну и в теории можно организовать на его основе трехсторонний дата биндинг но я по такому не угараю, js-data - что-то типа data-mapper, более универсальное решение для организации persistence layer ваших моделей. Модель в этом случае будет представлена совокупностью POJO (Plain Old Javascript Object), сервисов и т.д. Но это в контексте именно приложений. Это бизнес логика этих приложений. Для меня модель это именно это, и ее не может быть много, это просто слой.

    Ну и да, я не считаю что флеш это детское недоразумение, работал с ним лет 6-7 назад так как альтернативы что-то забавное делать небыло. По поводу TypeScript жалкое подобие AS3 - это уже лучше чем было ранее, согласитесь, JS так себе язык. AS3 клевая штука но флэш/флекс как платформа уже не нужны (почти).

    Короче я не хочу продолжать этот спор ибо я не понимаю вашу позицию. Если хотите - можем продолжить в рамках личной переписки, ибо мне интересно, но как-то лениво разбираться тут)
  • Почему Angular не видит модуль?

    Vasyl Pylypiv: тогда проверять второй пункт. В любом случае либо модуль на момент запуска приложения еще не загружен, либо такого модуля на самом деле нет.
  • Почему Angular не видит модуль?

    Vasyl Pylypiv: проверять в таком порядке:
    - точно ли загрузились все скрипты
    - правильно ли прописаны имена модулей, может опечатка где
  • Для чего и как применять директивы в AngularJS?

    vasIvas: сори, не привык с мобильника печатать... там в первой половине много опечаток аля "прообрас -> проброс"
  • Для чего и как применять директивы в AngularJS?

    vasIvas: Вы видимо никогда не писали ничего более-менее больного на каком-нибудь backbone в былые времена…


    Все что он делает, это берет с dom элемент и предоставляет на него ссылку , которою нужно получить написав тысячу строк вместо одной dom.getElement. Все.


    Ну вот не надо утрировать, ссылка на элемент это самый минимум того что он делает. По факту:

    предоставляет структуру для инкапсуляцию поведения элемента (контроллер для поведения, link для инфраструктуры и работы с dom)
    изоляция от внешнего мира (изолированный scope, прообраз данных через атрибуты)
    шаблоны
    иерархия и выполнение директив согласно приоритетам (хотя это сомнительно, обычно соль именно в иерархии и ngTransclude).
    И это только в контексте того, что дают нам директивы. Не забываем про внедрение зависимостей, добротный низкоуровневый сервис для работы с сетью… и все все все все можно покрывать юнит тестами. Вы когда-нибудь пробовали покрывать тестами приложение на голом jquery с этими вот getElement и т.д.? Это боль и унижение, потому так мало пишут тестов под это дело, только E2E спасает а их поддерживать сложнее.


    применить знания полученные в gamedev в "мегасайтах",


    И вот вопрос, вы говорите о мегасайтах, SPA и т.д. а потом сразу спрыгиваете обратно в gamedev. SVG, canvas и т.д. - это все части отдельных элементов UI, к SPA это вообще никак не относится. SPA это сайты аля google music или... да вот тот же тостер можно вполне себе сделать как SPA. А то о чем вы говорите - это игрушки, для этого есть свои фреймворки. Каждой задаче свой инструмент.


    И ещё он не нравится тем, что в нем отсутствует модель.


    Из коробки ничего для организации этого слоя нет, согласен, это минус. С другой стороны - есть все что нужно для организации сервисного слоя, а далее уже пляшите как хотите. Мне вот нравится js-data, кому-то нравится backbone для моделек, кто-то берет restangular или что-то в этом духе... Как по мне дать возможность разработчику самому решить как у него будет организована модель - это есть хорошо. Для меня ангуляр решает огромную проблему в плане организации конкретно UI layer + предоставляет неплохой слой инфраструктуры (если рассматривать вместе с готовыми решениями а не только то что идет из коробки).


    а то и того хуже, фабрикам


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


    А hmvc это нечто! Зачем вводить слой для связи контроллеров, когда они и так прекрасно общаются через mainController при помощи событий.


    Вы о чем вообще? Причидите пример, о каких событиях вы тут толкуете, нет там ничего такого. События аля $destroy у скоупа это системные события, да и вообще общение через события дурная идея. Мне кажется вы просто не знаете о чем говорите либо я вас не понимаю. Привидите пример того что вас напрягает в этом контексте и я на 99% скажу что либо вы не верно поняли (я подозреваю что вы про ngModelController?) либо просто сами так сделали.


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

    Я воспринимаю модель исключительно как слой приложения, а он может быть только один. Откуда могут взяться две модели?


    Скоро забудем о ооп


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

    Ведь отсылать запросы из фабрики

    Повторюсь, фабрики в ангуляре нужны только что бы пораждать сервисы, а запросы отправляются из сервисов, так что ничего не нарушено и все хорошо. То что так можно делать - это плохо, да, и люди иногда так делают. В ангуляре вообще много чего что позволяет сделать очень плохие вещи, именно поэтому я очень жду выхода angular2 где большая часть этих проблем устранена.
  • Для чего и как применять директивы в AngularJS?

    copal: писал с утра, не проспавшись. Так это, что у вас там за истерия по поводу гугла и его провальности?

    1) webassembly это стандартизированный ASM.js. И только. Заменить DOM пока не выйдет.
    2) никто н гугл не ставит, гугл имеет непосредственное отношение к полимеру и ангуляру, но там много уже и от комьюнити, для меня это просто удобные инсртументы. Если в один прекрасный день перестану поддерживать ангуляр (маловероятный сценарий, уж слишком много людей его тыкало), то я лично просто перейду на что-то другое. В контексте модульного angular2 это сделать очень легко и просто.
  • Для чего и как применять директивы в AngularJS?

    copal: почему же не MVC фреймворк? Очень даже MVC, но помимо MVC он еще HMVC и MVVM предоставляет.