Привет, меня зовут Борис Шабанов, я — руководитель Frontend-разработки в департаменте разработки рекламных технологий Rambler Group. Сегодня я расскажу вам о том, как на нашем приложении возникли проблемы маршрутизации, и про то, как мы их решали.

Продолжим говорить о Elm 0.18.

Elm. Удобный и неловкий
Elm. Удобный и неловкий. Композиция
Elm. Удобный и неловкий. Http, Task

В этой статье рассмотрим вопросы энкодеров/декодеров.

Декодеры/энкодеры используются для:

1. преобразование ответов от сторонних ресурсов (Http, WebSocket и прочее);
2. взаимодействия через порты. Подробнее про порты и нативный код расскажу в следующих статьях.

Вкратце:

• Пруф уже реализован на C++, JS и PHP, подходит для Java.
• Быстрее чем coroutine и Promise, больше фич.
• Не требует выделения отдельного программного стека.
• Дружит со всеми средствами безопасности и отладки.
• Работает на любой архитектуре и не требует особых флагов компилятора.

Продолжим говорить о Elm 0.18.

Elm. Удобный и неловкий
Elm. Удобный и неловкий. Json.Encoder и Json.Decoder
Elm. Удобный и неловкий. Http, Task

В этой статье рассмотрим вопросы архитектуры Elm приложения и возможные варианты реализации компонентного подхода разработки.

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

Несмотря на заявления Google и Яндекс о поддержке поисковыми ботами парсинга сайтов SPA, надеяться на нормальную индексацию не стоит — у поисковых ботов мало ресурсов, ваше приложение должно максимально быстро отрабатывать, иначе, вам либо порежут рейтинг, либо не спарсят страницу, так же бот может не дождаться отработки всех ваших скриптов…
(исследование Google bot)

Мой маленький проект для исследования технологий — изменение посещаемости, после перехода на Server Side Rendering (SSR)

Как настроить Angular и готовые примеры ниже подкатом.

Поговорим о Elm.

Elm — функциональный язык программирования для frontend-разработки. Синтаксис похож на Haskell, но значительно упрощен и специализирован. Исходный код на Elm компилируется в нативный JavaScript. Скомпилированный JavaScript содержит код приложения, которое управляют поддеревом DOM.

Сегодня, в пятой части перевода руководства по Node.js, мы завершим разбор возможностей npm, в частности, коснёмся таких вопросов, как выяснение установленных версий npm-пакетов, установка старых версий пакетов, обновление зависимостей, локальная и глобальная деинсталляция пакетов. Здесь же мы поговорим и об npx.

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

Пару слов о GraphQL

GraphQL это язык запросов для API, который предлагает декларативный подход к получению данных. Он позволяет клиентам запрашивать только нужные данные с веб-сервера и ничего лишнего. Разработанный еще в 2012 году Facebook’ом, которым по-прежнему и поддерживается, GraphQL стал использоваться многими другими крупными и не очень компаниями. Среди прочих Yelp, Shopify и Github.

При использовании REST APIs обычно запросы отправляются по нескольким адресам, для получения всех необходимых данных в приложении. GraphQL API же позволяет тебе отправлять все запрос по адресу с указанием, какие именно данные ты бы хотел получить этим запросом. Поэтому, к слову, GraphQL отлично подходит при использовании в условиях медленного мобильного соединения.

Версии API могут быть головной болью для команд разработчиков. С GraphQL вы можете с этим не беспокоиться. GraphQL позволяет тебе добавить новые поля и типы (это будет обсуждаться позже) в твой GraphQL API, не затрагивая существующие запросы, старые и неиспользуемые же поля могут быть скрытыми от клиентов API. Используя единую эволюционирующую версию, GraphQL API предоставляет вашему приложению постоянный доступ к новым реализациям API и обеспечивают чистую и легко поддерживаемую базу кода.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Привет, Хабр!


Именно кратким экскурсом в язык запросов GraphQL послужит вам книга Алекса Бэнкса и Евы Порселло, которую мы отдали в перевод пару дней назад. Книга этих же авторов о React и Redux стала настоящим бестселлером (ждем 5-й тираж из типографии). Кстати, спасибо всем, кто указал нам на неточности в коде и терминах ;) книгу по столь быстро устаревающей технологии мы делали излишне быстро.

Автор сегодняшней статьи Робин Вирух также работает над книгой о GraphQL и библиотеках для этого языка, а в сегодняшней статье кратко объясняет достоинства и характерные особенности GraphQL как альтернативы REST

В этой статье рассматриваются сходства и различия двух подходов к решению алгоритмических задач: динамического программирования (dynamic programing) и принципа «разделяй и властвуй» (divide and conquer). Сравнение будем производить на примере, соответственно, двух алгоритмов: бинарного поиска (как быстро найти число в отсортированном массиве) и расстояния Левенштейна (как преобразовать одну строку в другую с минимальным количеством операций).

Хочу сразу заметить, что данное сравнение и объяснение не претендует на исключительную правильность. И возможно даже некоторые преподаватели в университетах захотели бы меня отчислить :) Эта статья является всего-лишь моей персональной попыткой разложить себе же все по полочками и понять что такое динамическое программирование и каким образом в нем участвует принцип «divide and conquer».

Итак, приступим…

Все, кто знаком с Vue, знают, что у Vue-приложения одна точка входа — файл main.js. Там, помимо создания экземпляра Vue, происходит импорт и своего рода Dependency Injection всех ваших глобальных зависимостей (директив, компонентов, плагинов). Чем больше проект, тем больше становится зависимостей, которые, к тому же, имеют каждая свою конфигурацию. В итоге получим один огромный файл со всеми конфигурациями.
В этой статье речь пойдет о том, как организовать глобальные зависимости, чтобы этого избежать.

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

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

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

Сегодня мы представляем вашему вниманию перевод материала, в котором рассмотрены опенсорсные JavaScript-библиотеки для визуализации данных.

Сегодня мы публикуем четвёртую часть перевода руководства по Node.js. В этом материале мы начнём разговор об npm а также рассмотрим особенности файлов package.json и package-lock.json.

Это рассказ про портирование JavaScript на отечественную платформу Эльбрус, выполненное ребятами из компании UniPro. В статье — краткий сравнительный анализ платформ, детали процесса и подводные камни.



В основе статьи — доклад Дмитрия (dbezheckov) Бежецкова и Владимира (volodyabo) Ануфриенко с HolyJS 2018 Piter. Под катом вы найдете видео и текстовую расшифровку доклада.

Перед вами третья часть перевода руководства по Node.js. Сегодня мы поговорим о выборе хостинга для Node.js-проектов, о том, как работать с Node.js в режиме REPL и как запускать скрипты с аргументами, о взаимодействии с консолью и о модулях.

Немного скомкано, записал чтобы не забыть. Должны быть интересны комментарии хабракриптосообщества.

Решил проверить, насколько криптоустойчиа Brainwallet система резервного копирования мультивалютного кошелька Jaxx и что означают секретные слова на уровне кода.

Для начала сделал копию свежеустановленного Google extension кошелька себе в рабочую папку. Подправил файлы для получения возможности редактирования.

Предыстория

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

Для тех, кто все еще не в курсе, плагина webpack.optimize.CommonsChunkPlugin больше нет. Совсем. Вместо этого предлагается в конфиге писать следующее:

module.exports = {
  // ...
  optimization: {
    splitChunks: {
      chunks: "all"
    }
  }
  // ...
}

Это должно работать как магия. Т.е. теперь не мы говорим webpack'у что сделать общим чанком, а он сам все сделает, да еще может даже и лучше нас.

И наступит счастье. Шутка. На самом деле нет...

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

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