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

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

Сервисы

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

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

Клиент-серверная архитектура для разработчиков веб-приложений — это примерно как одна из черепах, на которой стоял мир в воззрениях наших предков. Трудно себе представить иное положение вещей. Однако бесчисленное количество веб-приложений сформировало новую потребность — управление данными на фронтенде. Пока нет единого подхода и реализации, есть только отдельные технологии, позволяющие работать с данными на клиенте. Да и с ними никто особо не заморачивается. А между прочим, пора. О том, что уже есть в плане работы с данными на фронтенде и что будет дальше, мы поговорили с Никитой Прокоповым aka tonsky.

Сегодня в кругах программистов почти каждый знает о библиотеке Facebook – React.

В основе React лежат компоненты. Они схожи с DOM элементами браузера, только написаны не на HTML, а при помощи JavaScript. Использование компонентов, по словам Facebook, позволяет один раз написать интерфейс и отображать его на всех устройствах. В браузере все понятно (данные компоненты преобразуются в DOM элементы), а что же с мобильными приложениями? Тут тоже предсказуемо: React компоненты преобразовываются в нативные компоненты.

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

Итак, начнем.

На DevConf-2016 как и в прошлом году будут не только доклады, но и мастер-классы. Что такое мастер-класс? Чем он отличается от доклада или сессии на флипчартах.

Я очень люблю Leaflet. С его помощью можно очень быстро строить свои интерактивные карты. Однако, практически все доступные поставщики тайлов (слоёв для карт) предоставляют свои услуги за весьма внушительные деньги. Существуют такие OpenSource-проекты, как OSM, но не всегда их тайлы удовлетворяют своим внешним видом.

Цель

Цель заключалась в том, чтобы слепить своего полностью бесплатного кентавра. Мне всегда нравились Yandex-карты, но не их API. Поэтому я заинтересовался вопросом внедрения Яндекс-карты, как слоя для Leaflet.

Мы создадим простой, но реалистичный модуль комментариев для блога, упрощенный аналог модуля комментариев реального времени, предлагаемый такими ресурсами как Disqus, LiveFyre и Facebook.

Мы обеспечим:

• Представление для отображения всех комментариев
• Форму для ввода и отправки комментариев
• Задел на будущее, для подключения настоящего бэк-енда

Также будут реализованы:

• Optimistic commenting: комментарии появляются на странице раньше чем они сохраняются на сервере, что визуально ускорит наш модуль
• Live updates: комментарии других пользователей появляются на странице в реальном времени
• Markdown formatting: пользователи могут использовать Markdown-разметку для форматирования текста

Финальная версия

Ссылка на GitHub

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

Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:

JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.

Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.

Введение

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

• Использование React предполагает, что View нашего Web-приложения разбито на компоненты, и каждый из них, так или иначе, отвечает за собственное отображение и функциональность.

  
  

• Подразумевается, что будут использованы современные инструменты разработки вроде babel, webpack, browserify, gulp, post- pre- css-процессоры.

Использование точек с запятой в JavaScript – один из самых горячо обсуждаемых топиков (сразу после пробелов и табов… два пробела, пожалуйста). Вот с ходу три ссылки, почему точки с запятой не нужны. Но так ли это на самом деле?

Начну с того, что использую vim в качестве редактора файлов. Все удобно и быстро, но есть некоторые проблемы которые выделил при длительном пользовании:

• Нет асинхронности. Знаю что есть nvim — но он работает не так быстро и не так гладко
• Сложность написания плагинов. Спорный конечно вопрос для разных гуру — но честно говоря так много «каши», не хватает модульности и какой то структурности из уже реализованных «велосипедов»
• Когда слишком много плагинов vim стартует — нужно быть честным, довольно долго и это напрягает

Пользуюсь так же по основному своему хобби — Android Studio. Очень прожорлив этот IDE к ресурсам системы, процессор иногда сходит с ума обрабатывая очередной цикл gradle assembleDebug.

Visual Studio Code испытывал скептически. Первое что удивило скорость запуска вместе с большой структурой проекта. Моментальный поиск по файлам и множество плагинов, отличный менеджер плагинов похожий на Sublime. Минимальная загрузка процессора.

Давно в Android Studio не хватало одной полезной штуки — перевод ресурсов strings.xml под другие языки. Делать раньше это было весьма неудобно:

• Выделить текст
• Скопировать
• Перейти в любой онлайн переводчик
• Вставить текст
• Выбрать текущий язык перевода
• Выбрать в какой язык перевести
• Скопировать перевод
• Открыть результирующий strings.xml
• Вставить перевод

Чего хотелось — одной комбинацией клавиш получить моментальный результат.

Мы немного переименовались и предлагаем вашему вниманию очередную подборку с ссылками на полезные ресурсы и материалы из области фронтенда и дизайна

Тут мелькнула статья, как чувак, выбирая инструментарий, ничего не мог написать. Это про меня! Под Новый год нашёл ViewModel.org. А внутри прекрасный Two-Way Binding. Но не проходит ощущение ящика в гараже, заваленного гаечными ключами вперемешку с "лишними" деталями. Наглядный пример, как в собственной же демке пришлось ввернуть костыль, гы-гы. И я застрял на четыре месяца — хобби по вечерам после работы. Перебрал все пакеты, хоть как-то полезные для Blaze. Приставал к авторам с мольбами… Собрал в итоге новый велосипед с громким именем Template2.

Очень сложно сделать просто, как известно. Зацените:

В статье рассказывается про модуль, позволяющий создавать подмножество javascript с любыми ключевыми словами. Строго для безудержного веселья.
На волне статьи про rucckuu.js я обзавидовался и решил обнародовать своё творение: небольшую экосистему для создания произвольных подмножеств javascript. Если к вам давно закрадывалась мысль о том, что некоторые ключевые слова плохо подходят к контексту их применения или мысль о том, что javascript слишком многословен (всякое бывает). Если вы хотите добродушно подшутить над коллегами или просто объяснить вашей маме, чем вы всё-таки занимаетесь на работе, добро пожаловать под кат.

С выходом Node.js 6.0 мы из коробки получили готовый набор компонентов для организации честного ленивого загрузчика. В данном случае я имею в виду lazyload, который пытается найти и загрузить нужный модуль только в момент запроса его по имени и находится в глобальной области видимости для текущего модуля, при этом не вмешиваясь в работу сторонних модулей. Написано по мотивам статей Node.JS Избавься от require() навсегда и Загрузчик модулей для node js с поддержкой локальных модулей и загрузки модулей по требованию.

Данная статья носит больше исследовательский характер, а ее целью является показать особенности работы Node.js, показать реальную пользу от нововведений ES 2015 и по новому взглянуть на уже имеющиеся возможности JS. Замечу, что этот подход опробован в продакшене, но все же имеет несколько ловушек и требует вдумчивого применения, в конце статьи я опишу это подробнее. Данный DI может легко использоваться в прикладных программах.

Вы никогда не задумывались, как выглядит код на JavaScript для программиста, у которого родной язык — английский? Представьте, насколько удобнее им читать и писать код на своем «нативном» языке, насколько ускоряется время разработки и уменьшается количество багов. А ведь использование английского языка как основы для языков программирования не обусловлено ничем, кроме того, что «так исторически сложилось».

В то время, как ребята из команд, работающих над Angular, React, мягко, но уверенно пересаживают разработчиков на ES2015, я хотел бы немного рассказать о возможностях использования нового стандарта спецификации с библиотекой Backbone.js. На сегодня основной подход к использованию ES2016 в браузерах один и не зависит от используемого фреймворка/библиотеки. И заключается он в следующем: пишем код на ES2015 и с помощью транспайлера (напр., Babel) получаем код (который и выполняется в браузере) на предыдущем стандарте ES5.

Но как модули, классы и прочие "фишки" из ES2015 использовать в рамках сущностей библиотеки Backbone.js? Об этом речь пойдет под катом.

Введение: Зачем нужен RESTful сервис на Meteor

Meteor привлекает простотой использования и возможностью очень быстро создать работающее приложение с минимальным набором функций. У Meteor — хорошо развитое сообщество. Есть множество полезных дополнительных модулей, которые не требуют сложной настройки, и могут быть использованы сразу после установки. Есть хорошая документация, примеры и большое количество постов на форумах, вроде StackOverflow. Meteor — это full-stack фреймворк, который предлагает удобную и многофункциональную интеграцию сервера с клиентом. Так зачем же выходить за рамки этого взаимодействия, и создавать RESTful сервис?

Клиент-серверное приложение, по-сути, состоит из 2 независимых частей, которые взаимодействуют посредством определенного интерфейса. При этом каждая из частей клиент-серверного приложения может создаваться разными людьми или командами. Разработчики клиенсткой части вовсе не ограничены использованием Meteor, они могут использовать любой другой JS фреймворк, клиент даже не обязательно должен быть написан на JS, это может быть к примеру приложение Android, написанное на Java, или iOS, написанное на Objective C.

Именно эти причины заставили меня выбрать Meteor для построения back end в моем проекте, и искать пути для создания RESTful сервиса на Meteor.

Введение

В данной статье рассматривается вопрос о том, как реализовать обмен типизированными сообщениями между Back-End на основе ASP.NET Web API и Front-End, созданного с использованием TypeScript. Это приобретает особенное значение при работе над объёмными проектами, и тем-более важно, если команда является распределенной. Например, когда Back-End и Front-End разработчики работают из разных мест, в разных часовых поясах, и не всегда имеют возможность проконтактировать и обсудить что-либо. В этом случае отслеживание изменений представляет кропотливую работу, которая может быть чревата множеством трудноуловимых ошибок.

Для автора статьи, как для человека, который пришел к разработке Front-End со стороны WPF и Silverlight, большой проблемой, стало отсутствие статической типизации. Сколько раз вместо того чтобы сложить “2” и “2” складывал “2” и “Функцию возвращающую 2”, или передавал DOM объект вместо его jQuery обертки. Появление статических анализаторов кода, таких как JSLint, несколько облегчило проблему, но настоящим прорывом, особенно в командной разработке, для нас стал TypeScript.