Angular *

Хотелось бы поделиться с вами историей разработки моей игры.

Итак, всё началось около 4 лет назад, когда я решил попробовать свои силы в программировании игр. Собравшись в кучку из трёх человек, мы решили галопом освоить Unreal Engine 3. По своей неопытности, мы бросились делать MMO с крутым графоном. Чтобы там и звуки, и пушки, и лазеры, и открытый мир и т.д. Естественно, всё это не принесло результатов: запал угас, проект почил в бездне игродева.

Однако, страсть к программированию у меня осталась, идеи копились, а полученный опыт подтолкнул к правильному (на тот момент) решению.

Хочешь сделать игру — делай всё сам.

Автор: Сергей Матвеенко

Однажды ко мне пришел инвестор одного проекта и сказал: «Давай сделаем планировщик путешествий по картам Google!» Я согласился. Тогда инвестор стал рассказывать, как техдиректор представлял себе архитектуру этого планировщика: он говорил что-то про связь с сервером, про ключ API, про запросы в Google, про деньги за запросы, которых будет много и т. д. Все выглядело сложно и красиво. Однако затем мы стали внимательно читать документацию Google API и вдруг поняли, что на самом деле нам сервер не нужен. Вообще! Весь планировщик можно сделать на клиенте. А самое интересное — мы можем обойтись даже без API-ключа (при условии, что мы будем использовать JS API). В итоге я за два дня смог написать такой планировщик, с логикой на стороне клиента, на основе Google API, без использования сервера. Все оказалось очень просто.

Я расскажу, как можно сделать простейший планировщик такого рода буквально за пару часов. Конечно, за это время можно собрать только прототип, но главное — он будет работать! Его главной функцией будет прокладка оптимального маршрута между достопримечательностями в интересующем нас городе; может присутствовать разбивка плана поездки по дням. Все будет сделано на AngularJS с использованием Google Maps/Places API. Я расскажу об особенностях работы с этим API и о некоторых его возможностях, которые не указаны в документации. Также мы поговорим о выделении логики в клиентские приложения.

Привет всем.

Мы классический web 2.0 сайт сделаный на Drupal. Можно сказать, что мы медиа сайт, т.к. у нас очень много всевозможных статей, и постоянно выходят новые. Мы уделяем много внимания SEO. У нас для этого даже есть специально обученные люди, которые работают полный рабочий день.

К нам заходит более 400k уникальных пользователей в месяц. Из них 90% приходит из поиска Google.

И вот уже почти полгода мы разрабатывали Single Page Application версию нашего сайта.

Как вы уже наверное знаете, JS это вечная боль сеошников. И нельзя просто так взять и сделать сайт на JS.

Перед тем как начать разработку мы начали исследовать этот вопрос.
И выяснили, что общепринятым способом является отдача google боту уже отрисованой версии страницы.
Making AJAX applications crawlable

Также выяснилось, что этот способ более не рекомендуется Google и они уверяют, что их бот умеет открывать js сайты, не хуже современных браузеров.

We are generally able to render and understand your web pages like modern browsers.

Т.к. на момент принятия нашего решения Google только-только отказались от подобного метода, и еще никто не успел проверить как Google Crawler на самом деле индексирует сайты сделаные на JS. Мы решили рискнуть и сделать SPA сайт без дополнительной отрисовки страниц для ботов.

Не так давно я рассказывал о геме Oxymoron, позволяющем очень просто и быстро строить современные Single Page Application на AngularJS и Ruby on Rails. Статья была встречена весьма позитивно, поэтому пришло время написать более-менее сложное приложение, чтобы показать все возможности гема.

Часть 1 Часть 2 Часть 3 Часть 4

Сервисы

Тур героев развивается, и мы ожидаем добавление новых компонентов в ближайшем будущем.

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

Заинтересовавшись методологией построения SPA-приложений на Ruby on Rails, я пришел к некоторым идеям, которые реализуются теперь в каждом моем приложении и впоследствии даже были выделены в отдельный гем Oxymoron. На данный момент на Oxymoron написано более 20 достаточно крупных коммерческих рельсовых приложений. Хочу вынести гем на общественный суд. Поэтому дальнейшее свое повествование буду вести уже на его основе.

Пример готового приложения.

Вы уже знаете, что мы запустили новый проект, посвященный проектам с открытым исходным кодом — linuxloves.ms. Подробности про проект вы можете найти в нашей публикации на Хабре, которая уже вызвала ожесточенный флейм :-).

Разработчики, которые создают решения в стеке MEAN могут легко размещать свои решения в облачной платформе Microsoft Azure. Проще всего это сделать с помощью виртуальных машин.

Для упрощения работы с виртуальными машинами в облаке Azure предлагается площадка Azure Marketplace, в которой находятся сотни заранее настроенных виртуальных машин с разным окружением и установленными инструментами, включая операционные системы, базы данных, среды, фреймворки, CMS и так далее.

Рассмотрим, как любой пользователь Azure может развернуть стек MEAN за несколько минут.

Часть 1 Часть 2 Часть 3 Часть 4

Наше приложение растет. В этой части сосредоточимся на компонентах, пригодных для повторного использования, а также на передаче данных компонентам. Давайте отделим список героев в отдельный компонент и сделаем этот компонент пригодным для повторного использования.

Чуть переведя дыхание после прошедшего события, а именно 2 недели, мы готовы в красках рассказать, как же прошла традиционная конференция Frontend Dev Conf.

16 апреля в Минске состоялась международная конференция Frontend Dev Conf! Уже в четвертый раз нам удалось объединить под ее началом более 300 участников и сделать FDConf громким событием во frontend-тусовке.

Желание разработать собственный Angular.js webApi модуль возникло при работе с большим количеством http-запросов в проекте.

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

Задачи, которые должен решать будущий webApi модуль:

1. Предотвратить дублирование http-запросов в проекте.
2. Группировать существующий список запросов по функциональным категориям, чтобы проще вносить правки в конкретные методы.
3. Быть полностью независимой функциональной единицей приложения, которая подключается к любому другому Angular.js проекту простым Dependency Injection'ом.
4. Инкапсулировать внутреннюю реализацию, чтобы избежать проблем при работе с внешними источниками.

Демо

Посмотреть исходный код модуля: github.

Дальше поговорим о каждом из этих пунктов подробнее.

Всем привет.

5 июня мы вместе с SPb Frontend проведем в Питере большую конференцию по JavaScript во всех его проявлениях: клиентский и серверный, библиотечный и сам-по-себе, олдскульный и авангардный.

Конференция называется HolyJS (неплохо, правда?).

Сайт конференции: http://holyjs.ru

Докладов будет около 20, параллельных залов — 3.

Среди подтвержденных докладов:

• Известный технический блогер, фанат Clojure и автор DataScript Никита tonsky Прокопов сделает доклад о том, как организовать работу с состоянием и данными приложения в условиях распределенности, плохой связи и сложной структуры;
• Легенда ASP.NET Дино Эспозито объяснит о том, как аккуратно (умнее, чем через user agent) определять клиентские устройства, чтобы адаптировать под них UI/UX;
• Руководитель фронтенд-разработки в Avito и автор basis.js Роман Дворнов сделает доклад о CSSO — инструменте для минификации CSS;
• Виктор Грищенко расскажет про Swarm — инструмент для синхронизации данных между разными устройствами;
• Денис Мишунов расскажет о психологических и технических приемах и примерах, позволяющих управлять восприятием пользователя и помогают сделать ваш сайт «быстрым» в юзерском понимании.

Часть 1 Часть 2 Часть 3 Часть 4

Нужно больше героев

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

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

Как говорилось ранее, главной причиной перехода может служить существенное увеличение в скорости работы приложения: в 4.3 раза более быстрые манипуляции с DOM и в 3.5 раза более быстрые циклы $digest (по сравнению с 1.2), как заявили Джеф Кросс и Бриан Форд на конференции ngEurope.

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

Давайте же рассмотрим эти инструменты!

Вторая версия ангуляра всё ближе к релизу и всё больше людей начинают интересоваться им. Пока что информации по фреймворку не так много, особенно на русском языке, и всё чаще начинают возникать вопросы по некоторым темам.

Одна из тем, вызывающая много вопросов — внедрение зависимостей. Некоторые люди не сталкивались с подобной технологией. Другие не до конца понимают, как она работает в рамках Angular 2, так как привыкли к другим реализациям, которые бывают в других фреймворках.

А разгадка кроется в том, что DI во втором ангуляре действительно несколько отличается от других, и связано это в первую очередь с общим подходом и философией 2-й версии. Заключается она в том, что сущностями из которых строится всё приложение, являются компоненты. Сервисный слой, роутер, система внедрения зависимостей — вторичны и они имеют смысл только в рамках компонента. Это очень важный момент, который лежит в основе понимания архитектуры нового фреймворка.

Часть 1 Часть 2 Часть 3 Часть 4

Вступление

Эта статья основана на документации Angular 2 и представляет собой перевод двух статей — Вступление и Редактор героя.

Используется Angular 2 release is beta.12.

Тур героев: обзор

Наш великий план — построить приложение для кадрового агентства героев. Даже героям нужна работа!

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

Со стремительным приближением Angular 2.0, параллельно существующим с большим количеством других frontend-фреймворков, в воздухе витает множество волнений по поводу предстоящих затрат (как временных, так и денежных), связанных с переводом своих проектов на новую версию. Как вы думаете, есть ли у разработчиков желание изучить еще один новый фреймворк?

Давайте разбираться. Прошу под кат.

Angular Attack это 48-ти часовой online hackathon с использованием Angularjs

Здравствуйте, уважаемые читатели.

Сегодня вашему вниманию предлагается статья о стеке MEAN (Mongo, Express, Angular, Node) который кажется нам перспективной (при этом достаточно модной) темой. Просим высказаться, хотите ли вы увидеть на русском языке книгу об этом стеке. Добро пожаловать под кат.

Вдохновившись статьей «Порог вхождения в Angular 2 — теория и практика», решил тоже написать статью про свои муки творчества.

У меня есть большой проект, написанный на ASP.NET WebForms. В нем намешано много всякого, и постепенно мне это всё перестало нравиться. Решил я попробовать переписать всё на чем-нибудь современном. Angular 2 мне приглянулся сразу, и я решил пробовать его. Задача определилась такая: написать новый frontend, прикрутив его к существующему backend, с минимальными переделками последнего. Новый frontend должен быть UI-совместимым со старым, чтобы конечный пользователь ничего не заметил.

Итого имеем такой стэк: backend — ASP.NET Web API, Entity Framework, MS SQL; frontend — Angular 2; тема Bootstrap 3.

Сразу покажу результат TreeView:

EDA – event driven architecture или событийно-ориентированная архитектура. Довольно известный подход к проектированию веб-приложений, который сильно облегчает разработку, когда связанные компоненты находятся на разных ветвях иерархии, делая их связь более прозрачной.