Что мы знаем о MODX 3 на данный момент?

Опубликовано 31.05.2015 автором admin

Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?

Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.

Почему нам все равно нужен MODX 3?

Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.

Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.

Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.

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

Синдром «это придумали не мы»

Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.

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

Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:

Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.
Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.
Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.

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

Что такое Slim и зачем его использовать?

Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.

Вот что нам нужно знать о Slim:

Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).
Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.
Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.

Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.

Что насчет Менеджера и ExtJS?

Если вы спросите случайную группу MODX-разработчиков об их самой любимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.

Так что хотя мы пока не знаем, как будет выглядеть Менеджер или на чем он будет построен, мы можем быть вполне уверены, что это не будет ExtJS 3.

Но что же мы знаем?

Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.

При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.

Что дальше?

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

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

ссылка на оригинал статьи http://habrahabr.ru/post/259197/

Водители Uber смогут отслеживать клиентов при их согласии

Опубликовано 31.05.2015 автором admin

Ответить

Uber изменил политику приватности, чтобы внести изменения в работу сервиса. Приложение позволит водителям отслеживать клиентов. Так таксисты смогут быстрее подобрать заказчика по пути или подъехать к нужному подъезду. Кроме того приложение запросит разрешение на доступ к контакт-листу, чтобы таргетировать рекламу на друзей и семью клиента.

В ноябре 2014 года директор нью-йоркского подразделения Uber сообщил журналистке издания Buzzfeed, что может следить за ее передвижениями с помощью God-View — внутренней опции сервиса. Это происшествие вызвало скандал, а Питер Тиль, инвестировавший в американского конкурента Uber — стартап Lyft, назвал Uber самой «этически сомнительной» компанией в Кремниевой долине.

Журналисты и представители власти требовали разъяснить политику приватности. Uber должна составить подробный список данных, которые сервис может получать от клиентов. Сейчас Uber получает и хранит записи транзакций — счета, расстояние, дату и время поездок, и информацию о модели и операционной сети смартфона. Uber также видит звонки и сообщения между клиентом и водителеми IP-адрес клиента.

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

ссылка на оригинал статьи http://geektimes.ru/post/251256/

Теневой DOM (Shady DOM)

Опубликовано 31.05.2015 автором admin

Ответить

На Google I/O нам был представлен Polymer 1.0. Это новый релиз инструмента, который включает ряд особенностей и нововведении. Пожалуй начать стоит именно с Shady DOM.

Зачем нам еще один DOM?

Инкапсуляция является основой веб-компонентов.

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

Браузеры часто используют инкапсуляцию. Например элементы <select> и <video>, отображаются используя не доступный для нас DOM, о котором знает только браузер.

Имеется множество библиотек которые пытаются следовать похожему поведению. Например палагин jQuery, превращающий выбранный вами элемент в слайдер. Как правило, плагин генерирует кучу DOM’а вокруг элемента, пытаясь наделить его типичными для слайдера свойствами и возможностями. Данный подход является отличной практикой, но весь DOM сгенерированный для нужд слайдера не скрыт и находится на странице. Это выглядит далеко не так изящно как использование <select> или <video>.

Shadow DOM нацелен на решение данной проблемы. Браузеры которые поддерживают shadow DOM могут отображать сложные элементы скрывая реализацию (DOM, CSS, JS).

Простая размета — это хорошо!

Давайте представим элемент x-fade, суть которого заключается в красивом появлении изображения при его загрузке.

<x-fade>   <img src="cool.png"> </x-fade>

И допустим мы реализовали плагин для него:

$('x-fade').makeFade();

Автор будет очень доволен, так как он добьется необходимого ему поведения.

По факту, это все, что нам надо от веб-компонентов — простая разметка для достижения необходимого поведения. Но подход основанный на плагине имеет ряд недостатков который решает shadow DOM.

Загрязнение DOM

Допустим после вызова makefade, мы имеем следующий DOM:

<x-fade>   <div>     <img src="cool.png">   </div>   <canvas></canvas> </x-fade>

Плагину x-fade необходим некоторый DOM, для достижения своей цели. Элементы которые он добавил — открыты, что ведет к следующим проблемам:

Детали реализации раскрыты.
Селекторы которые проходят по дереву документа будут включать <canvas> и <div>.
Так как автор не ожидал появление этих элементов, они могут унаследовать ненужные стили.
Элемент <img>, напротив может потерять свои стили, так как он уже не является частью прежнего DOM.
Может ли автор добавить новый элемент? Изменить или удалить? Как поступить если элементы уже не там где были изначально.

Tree Scoping

Область видимости дерева, позволяет нам скрыть часть дерева DOM, от основного документа.
Если мы реализуем x-fade используя shadow DOM, то после вызова makeFade, наше дерево будет выглядеть так:

<x-fade>   <img src="cool.png"> </x-fade>

То есть, абсолютно точно так же как и до инициализации.
Отображение в браузере отличается от того как оно представленно в коде. Для разработчика это по прежнему элемент, в котором всего один <img>.
Благодаря данной возможности мы решили все вышеперечисленные проблемы. А именно:

Детали реализации сокрыты.
Выборки проходящие по документу не будут включать в себя canvas и <div>.
Новые элементы не будут наследовать стили
<img> не потеряет своих стилей, так как он никуда не переместился.
Разработчики с легкостью может добавить новое изображение или изменить текущее.

Инкапсуляция Shadow DOM

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

<x-fade>   <img src="cool.png">   #shadow-root     <div>       <content select="img">     </div>     <canvas></canvas> </x-fade>

Ага, вот и наши <canvas> и <div>. Так же вы могли отметить новый элемент <content>. Это пример композиции shadow DOM с так называемым light DOM — тот, что мы можем передать элементу.
В момент рендеринга эти два DOM’а объединяются и выглядят как результат работы jQuery (для браузера разумеется, мы же этого не видим):

<x-fade>   <div>     <img src="cool.png">   </div>   <canvas></canvas> </x-fade>

Shadow DOM так крут, так зачем нам еще один shady DOM?!

Shadow DOM скрывает дерево DOM, от всего документа. Cелекторы которые мы будем делать по документу (childNodes, children, firstChild итд) не будут включать в результате скрытые элементы.

Сделать полифил для такого поведения ОЧЕНЬ сложно. Нам необходимо добиться такого же композиционного отображения DOM дерева, при этом скрыть его от логического кода.
Это означает, что нам необходимо модифицировать все доступные методы по работе с элементами, что бы возвращать кастомную информацию.

Мы реализовали такой полифил, но цена:

Очень много кода.
Переопределение методов, замедляет работу с элементами.
Такие структуры как NodeList, нам не подвластны.
Аксессоры (например window.document, window.document.body), не могут быть переопределены.
Полифил возвращает проксированнные объекты, что может запутать.

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

Shady DOM

Аля франкенштейн который Гугл всячески пытается похвалить. Жаль, но другого выхода нет

Грубо говоря Shady DOM, предоставляет нам совместимую с shadow DOM модель области видимости дерева. Результат работы мы получим абсолютно точно такой же DOM как и при работе с jQuery плагином.

<x-fade>   <div>     <img src="cool.png">   </div>   <canvas></canvas> </x-fade>

А другими словами господа, все те самые недостатки которые мы якобы побороли — открытая реализация, проблемы со стилями и остальные.

Все, что смог от части сохранить Гугл, так это то, как представлено дерево в коде. Но для этого нам ОБЯЗАТЕЛЬНО, необходимо использовать новое API по работе с DOM и только тогда мы будем работать с элементами будто нечего и не произошло и видеть его так:

<x-fade>   <img src="cool.png"> </x-fade>

На самом деле в пределах элемента, это выглядит вполне себе достойно:

var arrayOfNodes = Polymer.dom(x-fade).children;

Таким образом мы можем работать как и с внутренним DOM так и со светлым DOM.

Из полимера не была вытиснута полностью модель shadow DOM’а. Совместимость shady с shadow позволяет нам писать в одном стиле. Если хотите, вы можете сделать так, что бы полимер решал, где он может использовать shadow DOM нативно, а где включать в работу shady.

Выводы

Веб-компонентам необходима инкапсуляция, ага…
Shadow DOM имплементирует инкапсуляцию, но нативно его только Гугл и поддерживает.
Пытаться сделать полифил для shadow DOM затея сложная и медленная в перспективе.
Shady DOM представляет нам супер-быстрый аналог полифила shadow DOM’а, но с ~~некоторыми~~ самой большой кучей недостатков, но у нас есть новое API для вас 😉
Shady DOM дает нам возможность расширить аудиторию приложений которые мы может разрабатывать используя данную модель.
Все эти неудобства доказывают, что все платформы должны поддерживать shadow DOM нативно.

На самом деле я очень доволен самим полимером. Я планирую написать ряд статей по его использованию. Как было сказано на конференции, компоненты реакта работают только в реакте, компоненты ангуляра только с ангуляром, а компоненты написанные с использование полимера — работают везде. Они занимают уровень между веб-платформой и фреймворками. Вы можете использовать их с любым фреймворком или же написать приложение используя только компоненты.
У меня был опыт скрещивания Backbone с React компонентами, но это не так круто как может показаться. А вот компоненты полимера + Backbone прям конфетка.

ссылка на оригинал статьи http://habrahabr.ru/post/259187/

Эстетический пост выходного дня или Когда 3D-печать — искусство

Опубликовано 31.05.2015 автором admin

Ответить

3D-печать уже используется для того, чтобы делать вкусные закуски и десерты, но в 2015 году 3D-печатную еду действительно попробует большинство людей, считает старший интерактивный дизайнер компании Frog Эрик Боам. И это – только начало!

«То, как мы едим, станет чем-то похожим на мультфильм «Джетсоны», – говорит Боам, ставя в пример разные кулинарные технологии – 3D-принтер ChefJet для печати из сахара и кухонного робота для низкотемпературной готовки Mellow, которые вскоре появятся на рынке.

Как минимум в 2015 году Вы попробуете свой первый 3D-печатный десерт: конфетку, приготовленную роботом, или шоколадку, распечатанную из CAD-файла. «Я думаю, в 2015 году мы будем чаще создавать еду на 3D-принтере сами, чем покупать 3D-печатные кулинарные изделия», – считает специалист.

ссылка на оригинал статьи http://geektimes.ru/post/251254/

Дайджест интересных материалов для мобильного разработчика #105 (25-21 мая)

Опубликовано 31.05.2015 автором admin

Ответить

Самое интересное на этой неделе, безусловно, это конференция Google I/O 2015. Android M, Android Pay, операционная система Brillo для интернета вещей, Google Play Services 7.5, Android Studio и Polymer, Cloud Messaging, Cloud Test Lab – это только малая часть их и множества нужных и интересных премьер! О них и других новинках мобильной разработки в новом дайджесте.

Android M и инструменты для разработчиков

Android L принёс с собой абсолютно новый пользовательский интерфейс, новую среду исполнения программ ART, увеличил скорость работы и отзывчивость интерфейса. В Android M мы сосредоточились на улучшении базового пользовательского опыта: устранили различные ошибки и внесли крупные изменения в основные элементы платформы.

Читаем переписку клиентов Ubank с саппортом

Я уже писал об уязвимости в мобильном приложении Альфа-Банка, которая позволяла получать выписки по любому клиенту банка. В этот раз я решил проверить мобильное приложение сервиса по приёму платежей Ubank.

Конкурс для дизайнеров от Почты Mail.Ru

Почта Mail.Ru запускает конкурс на дизайн концепции мобильного интерфейса. Задача конкурса — предложить подход для удобной и эффективной работы с информацией, накопившейся в электронной почте.

Почему айфон перезагружается от арабской смс

Конечно же, это не перезагрузка, а крэш графической подсистемы, который вызывает перезагрузку всей системы. Т.к. окно с текстом пуш-сообщения напрямую входит в графическую оболочку iOS, а не является отдельным виджетом (как, например, в Android), логично, что любая ошибка на столь высоком уровне выведет систему из строя.

iOS