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

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

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

Всем привет!

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

Да, в этой статье я предлагаю выложить все парсеры на стол и измерить!

Предлагаю вашему вниманию перевод статьи Automatic Firefox Extension Updates.

Статья старенькая, но вся информация актуальна и по сей день.

Разработчики расширений Firefox конечно знают, что при распространении расширений через официальный store вы бесплатно получаете возможность автоматически обновлять свои расширения. Но что делать, если мы хотим сами хостить свое расширение на своем сайте? Как нам самим реализовать поддержку автоматических обновлений?

Данная статья содержит в себе описание основных возможностей шаблонизатора Handlebars и является свободным переводом его официальной документации. Итак, поехали…

С поддержкой asyncio и вдохновленный Scrapy.

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

В первую очередь как инструмент для сбора данных, применяемый в моем хобби проекте, который не давил бы своей мощью, сложностью и наследием. И да, кто же будет сознательно начинать что-то новое на python2.x?

В итоге появилось идея сделать простой фреймворк для современной экосистемы python3.x, но такой же элегантный как Scrapy.

Под катом обзорная статья о Pomp в стиле FAQ.

Регулярно появляется какая-нибудь JS-библиотека, которую начинают шумно обсуждать на всевозможных форумах. Сначала постепенно нарастает энтузиазм, а затем сообщество быстро делится на противоборствующие лагери, по-разному относящиеся к новинке. Было бы просто невероятным подвигом рассмотреть все распространённые JS-фреймворки и библиотеки, поэтому хотим предложить вам список самых популярных и оказавших наибольшее влияние инструментов для фронтенд-разработки. А заодно дадим некоторые рекомендации по их использованию.

Но прежде чем перейти к делу, хотим уточнить:

• Не нужно ломать копий, если в этот список не попали какие-то из ваших любимых фреймворков или библиотек.
• Следите за обновлениями используемых вами инструментов. В последнее время начала активно внедряться кроссбраузерная и кроссаппаратная (cross-device) поддержка. Например, можно воспользоваться сканером, который подскажет, совместимы ли более старые версии с большинством устройств.

Как известно, в следующем январе сервис Parse будет закрыт. Большинство разработчиков ищут альтернативу для этого сервиса. В одном из проектов guthub собралось достаточно много альтернатив, со ссылками и описанием. Перед вами — перевод этой страницы.

Часть 1: универсальные сервисы

Провайдеры, предоставляющие информацию в реальном времени, помечены (*).

AnyPresence MBaaS (Mobile backend as a service). Упрощает процесс создания мобильных приложений предприятия, работающих на разных устройствах, не ущемляя гибкость средств, доступных разработчику. Легок в использовании даже для неопытных пользователей. Опытные разработчики получают доступ к исходникам всех компонентов.

ApiOmat позволяет процессам предприятия работать как мобильным приложениям. Мобилизует сложные бизнес-структуры и процессы путём объединения существующих IT-систем с мобильными приложениями и устройствами. Его можно устанавливать прямо в дата-центре компании, что позволит работникам выполнять свою работу через приложения вне зависимости от их местонахождения.

Appcelerator Arrow (*) Состоит из двух основных компонентов, Builder и Cloud. Arrow Builder позволяет быстро создавать API, модели данных и соединители данных как через мастер настройки, так и через написание кода. Arrow Cloud – это эластичный облачный сервис, где выполняются API и происходит анализ их использования, плюс обеспечивается работа двух десятков смежных сервисов (гео, хранение фотографий и т.п.) с использованием ArrowDB

Appery.io Интегрированные сервисы MBaaS – чтобы разработчики могли сконцентрироваться на приложениях, не отвлекаясь на инфраструктуру.

Здравствуйте, меня зовут Дмитрий Карловский, и я… архитектор множества широко известных в узких кругах фреймворков. Меня никогда не устраивала необходимость из раза в раз решать одни и те же проблемы, поэтому я всегда стараюсь решать их в корне. Но прежде, чем их решить, нужно их обнаружить и осознать, что довольно сложно находясь в плену привычек, паттернов, стереотипов и "готовых" решений. Каждый раз сталкиваясь с проблемами в реализации задачи, я задумываюсь "что, блин, не так с этим инструментом?" и, конечно же, иду пилить свой инструмент: функцию, модуль, библиотеку, фреймворк, язык программирования, архитектуру ЭВМ… стоп, до последнего я ещё не докатился.

Речь сегодня пойдёт о JS-фреймворках. Нет, я не буду рассказывать про очередное готовое решение, не в том цель поста. Я лишь хочу посеять в ваших головах несколько простых идей, которые вы не встретите в документации ни к одному популярному фреймворку. А в конце мы постараемся сформировать видение идеальной архитектуры построения пользовательского интерфейса.

К концу 2015 года в распоряжении JavaScript разработчиков образовалось огромное количество инструментов. В этой экосистеме легко потеряться, поэтому успешные команды следуют выработанным правилам, которые позволяют не терять время и сохранять здоровье проектов. Под катом перевод статьи 2016 года от команды Heroku, в которой они рассказывают о десяти привычках веб разработчиков, у которых все работает и ничего не болит. Скорее всего 80% написанного вы уже знаете – тем интереснее вам будет прочитать об оставшихся двух приемах!

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

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

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

Есть такой динозавр — ICQ. Вспомнили тот самый звук входящего сообщения? О да! Еще мне сразу вспомнилась учеба в универе: именно тогда я застал расцвет этого мессенджера. Правда, самим клиентом я пользовался другим, кажется, это был QIP. Сейчас уже точно и не вспомню. У Аськи был слишком навороченный интерфейс, мой молодой мозг не мог с ним справиться. А еще были крутые номера, которыми все хвастались. Точнее хвастались количеством цифр в нем. У моего соседа по общаге был 5-значный. И это было круто.



А теперь к делу. Недавно Mail.ru решили организовать конкурс на дизайн мобильного приложения этого клиента. Я решил поучаствовать. Что из этого вышло, смотрите дальше.

Предлагаю вашему вниманию перевод статьи How To Pick a Frontend Web Framework c сайта top.fse.guru.

Привет, приятель!

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

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

_{Фото: ivan dupont}

Всем привет! Меня зовут Дмитрий Исайкин, и с недавних пор я занимаюсь мобильной разработкой. Почему с недавних? Еще три месяца назад я был руководителем группы C/C++-разработки Почты Mail.Ru. Но однажды я в очередной раз задумался о том, что мне всё меньше и меньше нравится то, чем я занимаюсь. Больше времени стали отнимать обязанности тимлида: мотивация, стимуляция, отчётность, административные заботы. И тогда я решил: пора что-то менять. Разместил резюме, сходил на несколько собеседований. Всё это время я размышлял о том, чего же я хочу. Мне предложили возглавить направление разработки в одной достаточно крупной фирме, и я практически согласился. Но, «переспав» с этим решением бессонную ночь, я понял, что такая работа будет мне не в радость. Ещё был вариант пойти старшим разработчиком в другую хорошую фирму. Но там пришлось бы заниматься примерно той же работой, что и в предыдущие годы.

Эта статья — вторая часть серии:

• Часть 1: Декораторы методов
• Часть 2: Декораторы свойств и классов
• Часть 3: Декораторы параметров и фабрика декораторов
• Часть 4: Сериализация типов и metadata reflection API

В предыдущей статье мы выяснили, какие типы декораторов мы можем использовать в TypeScript.

Мы также узнали, как реализовать декоратор метода и ответили на основные вопросы про то, как декораторы работают в TypeScript:

• Как они вызываются?
• Кто передает в них аргументы?
• Где объявлена функция __decorate?

В этой статье мы познакомимся с двумя новыми типами декораторов: декоратором свойства (PropertyDecorator) и декоратором класса (ClassDecorator).

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Многие впервые увидев синтаксис шаблонов Angular2 начинают причитать, мол ужас какой сделали, неужто нельзя было как в Angular1 хотя-бы. Зачем нужно было вводить это разнообразие скобочек, звездочек и прочей ерунды! Однако при ближайшем рассмотрении все становится куда проще, главное не пугаться.

Так как шаблоны в AngularJS являются неотъемлемой его частью, важно разобраться с ними в самом начале знакомства с новой версии этого фреймворка. Заодно обсудим, какие преимущества дает нам данный синтаксис по сравнению с angular 1.x. Причем лучше всего будет рассматривать это на небольших примерах.

Данная статья во многом основана на материалах этих двух статей:

• Angular2: синтаксис шаблонов
• Angular2: Синтаксис биндинга данных

Для того, что бы упростить подачу материала, давайте разберемся. Под AngularJS я буду подразумевать всю ветку Angular 1.x, в то время как под Angular2 — ветку 2.x.

Так же спасибо господину Bronx за ценное дополнение, которое я включил в текст статьи.

Примечание: вечер выходного дня, потому о опечатках и т.д. сообщайте в личку. Премного благодарен и приятного чтения.

Хочу поделиться своим небольшом положительном опытом об проекте основанном на Angular + Typescript по прошествии года. Это далеко не новая связка, и я уверен, что уже многие её успешно используют. Конечно, уже многие ждут больше статей об React или Angular 2.0, но мне кажется, и этот опыт будет кому-то полезен.