Server-Driven UI (SDUI) — это подход для динамичного и гибкого пользовательского интерфейса, когда сервер посредством API сообщает приложению, какие компоненты и с каким контентом отображать. Он довольно популярен, и мы его тоже используем на многих экранах — помогает быстро выпускать фичи в продакшн. 

В статье покажу, на каких экранах мы его применяем, и расскажу, как развивались у нас подходы гибкого UI, какие плюсы и минусы мы вывели из его использования. Сначала рассмотрим формы на динамических полях, контракты и ​тонкие моменты создания новых полей. Потом поговорим про динамические флоу, как за ноль калорий на стороне фронта добавлять новых провайдеров для проведения оплаты и закончим зависимыми полями. Всё это с примерами экранов мобильного приложения. 

Публикация очень краткая. Многие думают, что параллельные вычисления в R -- это очень сложно и неприменимо к их текущим задачам.

И да и нет. Если сознательно не вдаваться в теорию, железо и всякие подробности, то можно нарисовать «3 и 1/2» почти универсальных рецепта.

Является продолжением серии предыдущих публикаций.

Тем, кто работает с R, хорошо известно, что изначально язык разрабатывался как инструмент для интерактивной работы. Естественно, что методы удобные для консольного пошагового применения человеком, который глубоко в теме, оказываются малопригодными для создания приложения для конечного пользователя. Возможность получить развернутую диагностику сразу по факту ошибки, проглядеть все переменные и трейсы, выполнить вручную элементы кода (возможно, частично изменив переменные) — все это будет недоступно при автономной работе R приложения в enterprise среде. (говорим R, подразумеваем, в основном, Shiny web приложения).

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

Является продолжением предыдущих публикаций.

Решения на базе R, как классические «отчетные», так и в контуре операционной аналитики, очень хорошо себя зарекомендовали в enterprise окружении. Несомненно, значительную роль в этом играет компания RStudio и ее увлеченный коллектив. В коммерческих продуктах RStudio можно особо не думать об инфраструктурных вопросах, а просто обменять небольшую денежку на готовые решение «из коробки» и сразу заняться самой задачей. В open-source редакциях, а большинство инсталляций в российских компаниях именно такая, приходится думать про инфраструктурные вопросы самостоятельно. Независимо от варианта развертывания, вопрос эксплуатации R приложений остается за разработчиком.

Решения на R хорошо закрывают нишу «средних данных», когда данных «чуть больше» чем влезает в excel или в ненастроенную реляционку и нужны сложные алгоритмы и процессинг, но когда разворачивать пусковой комплекс бигдаты еще более чем рано. Речь идет о десятках-сотнях террабайт в полном объеме, которые легко умещаются в бэкенд на Clcikhouse. Важный момент: все находится во внутреннем контуре, в подавляющем большинстве случаев ПОЛНОСТЬЮ отрезанном от интернета.

Является продолжением серии предыдущих публикаций, уточняет публикацию «Конструктивные элементы надежного enterprise R приложения».

Всем привет! Меня зовут Денис Гирько, я системный архитектор e-commerce платформы в Lamoda. В прошлом году я выступал на конференции DevConf с докладом, которым хочу поделиться с вами.

Это обзорный доклад о том, с какими сложностями в процессе доставки заказа встречается крупный интернет-магазин и какие технические решения могут помочь их преодолеть (на примере решений, которые мы опробовали в Lamoda).

О чем пойдет речь? Расскажу:

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

Приветствую тебя, Хабр! Наверняка вы заметили, что тема стилизации фотографий под различные художественные стили активно обсуждается в этих ваших интернетах. Читая все эти популярные статьи, вы можете подумать, что под капотом этих приложений творится магия, и нейронная сеть действительно фантазирует и перерисовывает изображение с нуля. Так уж получилось, что наша команда столкнулась с подобной задачей: в рамках внутрикорпоративного хакатона мы сделали стилизацию видео, т.к. приложение для фоточек уже было. В этом посте мы с вами разберемся, как это сеть "перерисовывает" изображения, и разберем статьи, благодаря которым это стало возможно. Рекомендую ознакомиться с прошлым постом перед прочтением этого материала и вообще с основами сверточных нейронных сетей. Вас ждет немного формул, немного кода (примеры я буду приводить на Theano и Lasagne), а также много картинок. Этот пост построен в хронологическом порядке появления статей и, соответственно, самих идей. Иногда я буду его разбавлять нашим недавним опытом. Вот вам мальчик из ада для привлечения внимания.

• что такое финансовая математика и как ее учить;
• как устроен софт для финансовой индустрии;
• как в компании Devexperts появилась исследовательская лаборатория по многопоточности;
• куда развивается Concurrency, и что будет в моде в ближайшее время;
• как всемирная олимпиада по программированию пришла в Россию.

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

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в 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).