• Лучшие способы использования Angular.js

    • Translation

    От переводчика:


    Привет, Хабр! Мы мы продолжаем делится с сообществом полезными материалами о разработке и дизайне. В этот раз команда TrackDuck подготовили перевод статьи Jeff Dickey о Angular, которая нам очень понравилась и в свое время заставила пристальней присмотреться к Gulp. Эта статья будет полезна разработчиками, которые хотят сэкономить время на рутинных операциях и построить качественные процессы при разработке веб-приложений. Мы активно используем Angular для разработки собственного продукта для визуального комментирования веб-сайтов, поэтому готовы ответить в комментариях на интересующие вас вопросы!




    Я использовал Angular в довольно большом количестве приложений и видел много способов структурирования приложений с использованием этого фрэймворка. Сейчас я пишу книгу о проектировании Angular приложений c использованием MEAN стека, и больше всего исследований я провел в этом направлении. В итоге я остановился на довольно оригинальной структуре приложения. Я считаю, что мой подход более простой чем тот, что предложил Burke Holland.
    Прежде чем начать, я хотел бы рассказать о существующем подходе к реализации модульности в Angular.
    Если вы разрабатываете продакшн решение на Angular - добро пожловать под кат!
  • AngularJS для привыкших к jQuery

    • Translation
    • Tutorial
    AngularJS — прекрасный фреймворк для построения веб-приложений. У него замечательная документация, снабженная примерами. В обучающих «пробных» приложениях (вроде TodoMVC Project) он очень достойно показывает себя среди остальных прочих фреймворков. По нему есть отличные презентации и скринкасты.

    Однако если разработчик никогда ранее не сталкивался с фреймворками, подобными Angular, и пользовался в работе в основном библиотеками вроде jQuery, то ему может быть трудно изменить свой образ мышления. Как минимум, так было со мной, и я бы хотел поделиться некоторыми заметками на эту тему. Может быть, кому-то это будет полезно.
    Читать дальше →
  • Учебник AngularJS: Всеобъемлющее руководство, часть 2

    • Translation
    • Tutorial
    Часть 1

    4.1 $rootScope


    $rootScope не сильно отличается от $scope, просто это объект $scope самого верхнего уровня, от которого происходят все остальные области видимости. Когда Angular начинает создание вашего приложение, он создаёт объект $rootScope, и все привязки и логика приложения создают объекты $scope, являющиеся наследниками $rootScope.

    Обычно мы не используем $rootScope, но с его помощью можно обеспечить передачу данных между разными областями видимости.
    Читать дальше →
  • Учебник AngularJS: Всеобъемлющее руководство, часть 1

    • Translation
    • Tutorial

    Содержание


    1 Введение в AngularJS
    2 Engineering concepts in JavaScript frameworks
    3 Modules
    4 Understanding $scope
    5 Controllers
    6 Services and Factories
    7 Templating with the Angular core
    8 Directives (Core)
    9 Directives (Custom)
    10 Filters (Core)
    11 Filters (Custom)
    12 Dynamic routing with $routeProvider
    13 Form Validation
    14 Server communication with $http and $resource

    1 Введение в AngularJS


    Angular – MVW-фреймворк для разработки качественных клиентских веб-приложений на JavaScript. Он создан и поддерживается в Google и предлагает взглянуть на будущее веба, на то, какие новые возможности и стандарты он готовит для нас.

    MVW означает Model-View-Whatever (модель – вид – что угодно), то есть гибкость в выборе шаблонов проектирования при разработке приложений. Мы можем выбрать модели MVC (Model-View-Controller) или MVVM (Model-View-ViewModel).

    Этот обучающий материал задумывался как отправная точка для изучения AngularJS, его концепций и API, чтобы помочь вам создавать великолепные веб-приложения современным способом.
    Читать дальше →
  • Fork в приложениях использующих event loop

      Существуют разные способы реализовать одновременную обработку данных: fork, threads, event loop… и, насколько я понимаю, вместе они уживаются довольно паршиво.

      Давайте возьмём event loop и fork. Есть ли смысл использовать их в одном приложении? На первый взгляд — конечно, есть! Event loop будет нормально работать только при условии, что обработчики событий отрабатывают достаточно быстро. И как только какой-то обработчик начинает требовать много времени для работы, первое что приходит в голову — отforkнуть его в отдельный процесс (в принципе есть ещё и нити, но в perl с ними туго, так что этот вариант даже не рассматриваем).

      Но это на первый взгляд. А если копнуть глубже…
      Читать дальше →
    • Документация Mojolicious: Потерянные Главы

      • Tutorial
      Update: статья обновлена для соответствия Mojolicious 6.0.

      Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

      Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

      Содержание


      1. Недостатки
      2. Роутинг: внутреннее устройство
      3. Роутинг: настройка
      4. Параметры HTTP-запроса
      5. Парсинг
      6. Tips & Tricks
        1. Поддержка неблокирующих приложений в режиме CGI
        2. Как работает Mojo::UserAgent при тестировании своего приложения
        3. ojo и Mojolicious::Lite
        4. Переменные окружения


      Другие статьи в этой серии



      Недостатки


      В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код
      sub secret { shift->secrets([shift]) }
      
      либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

      Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

      С проблемой обратной совместимости мы мало что можем сделать (хотя, наверное, можно сделать плагин к Mojolicious, который будет её эмулировать по мере возможности). Зато вторую проблему решить не сложно — недостающую документацию можно написать самостоятельно. По мере изучения Mojolicious я планирую описывать некоторые вещи, которые, по-хорошему, должны быть в официальной документации, отсюда и название этой статьи.
      Читать дальше →
      • +20
      • 13.9k
      • 7
    • Документация Mojolicious: Потерянные Главы

      • Tutorial
      Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

      Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

      Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay


      Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

      • описание последовательно выполняющихся операций без «лапши» callback-ов
      • передачу результатов из callback-а(ов) текущего шага на следующий
      • общие данные для callback-ов, объединённых в одну задачу
      • синхронизацию групп callback-ов
      • перехват и обработку исключений в callback-ах

      Используемые термины:

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

      Альтернатива Promises

      Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+
      Читать дальше →
    • Полезное и приятное для разработчика в Mojolicious

      Про Mojolicious на Хабре уже несколько раз писали. Фреймворк успешно развивается и, на мой взгляд, становится удобнее для быстрой разработки с каждым днем.

      Под катом я собрал несколько приемов работы с фреймворком, которые серьезно упрощают жизнь мне и, быть может, будут полезны для кого-то еще.
      Читать дальше →
      • +11
      • 6.1k
      • 5
    • Asterisk, или домашняя телефония для (про)двинутых пользователей

        Эта история началась два долгих года назад, когда во время командировки в США я ВДРУГ остался без мобильной связи: с дуру перед поездкой поменял телефон, а он оказался «двух-диапазонником»… Да и роуминг не дешёвый…
        Итогом стало открытие для себя SIP-телефонии.

        И вот несколько месяцев назад, из статей на Хабре, выясняю, что чужим дядям можно и не платить за межгород, если надо позвонить откуда-то в родной город через Интернет! Достаточно поставить VoIP сервер и настроить его так, как надо именно тебе!

        И вот, взяв в руки Asterisk, я приступил к операции по борьбе с излишней жадностью ОпСоСов…

        Читать дальше →