Что такое реактивное программирование? Не Rx. И даже не Excel. Это архитектурный паттерн, позволяющий абсолютно иначе писать код. В статье мы устаканим фундаментальные знания, утвердимся в том, что React.js всё же является реактивным, и подумаем о том, как и когда нужно, а когда не нужно применять паттерны реактивного программирования.

Привет! Меня зовут Артём Арутюнян, много где меня можно встретить под ником artalar. 10 лет я разрабатываю крупные веб-сервисы, и вот уже четыре года менеджер состояния, исследуя тему реактивности, консистентности данных и состояния. А началось всё с простого вопроса: почему React, самая популярная современная библиотека для написания UI, по умолчанию полностью рушит приложение и показывает белый экран при появлении ошибки в любом компоненте во время рендера?

В данной статье хотелось бы описать и раскрыть формальную сторону вопроса «что такое состояние» для лучшего понимания фундаментальных основ надёжности любого клиентского приложения. Хочется уже поставить точки в некоторых вопросах терминологии, чтобы чётче отвечать на вопросы «что, когда и зачем брать» при выборе библиотек и технологий для клиентского веб-приложения.

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

Привет, Хабр! Меня зовут Влад, я лид направления Web Performance в Тинькофф.

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

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

Ведущие игроки IT-индустрии продолжают обращать внимание на важность производительности, проводят масштабные исследования и эксперименты, разрабатывают новые концепции, инструменты и API. А в ближайшем будущем Google и вовсе будет учитывать основные показатели производительности в поисковой выдаче.

Пользователям нравятся отзывчивые интерфейсы, а бизнесу — прибыльные проекты. И если производительность играет в этом не последнюю роль, то почему бы не заняться ее оптимизацией?

Наверное, любой разумный человек хоть раз в жизни спрашивает себя о чем-то из списка:

• «Как написать хабростатью?»
• «Что нужно, чтобы записать подкаст?»
• «Как ты пишешь видосики?» (в том числе те, что из хаба Java)

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

Кроме того, я спросил, какое оборудование используют коллеги из подкастов «Разбор Полётов», «devSchacht», «Podlodka Podcast», «Витая пара», и поделился этой информацией между строк. И это причина, по которой этот пост попал в хабы JavaScript и Разработка мобильных приложений — вероятно, кому-то может быть интересно узнать, чем пользуются их любимые подкастеры.

Совсем недавно Руслан (наш Генерал Маркетинг, ARG89) спросил, есть ли у меня список вещей, которые нужно взять с собой в путешествие на конференцию. Такого списка нет — есть только субъективное ощущение того, чем можно пожертвовать вот из этого:

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

Получилось так, что с 2012 года я курирую московский Techstars Startup Digest. Это — email-рассылка мероприятий для IT-специалистов, основателей стартапов и маркетологов.

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

Интересно, что в последнее время большая часть таких мероприятий проходит в коворкингах. Что удивительно, по моим наблюдениям, количество подобных площадок в Москве растет.

Этот тренд заинтересовал меня и стал отправной точкой для новых фотоэкскурсий — вроде тех, что я снимаю для компаний [например, вот самая первая из них и еще одна]. На этот раз мне захотелось рассказать про коворкинги и изучить новый подход к организации рабочих мест.

На Хабре я пока показал только #tceh, SOK и Ключ, а в период новогодних каникул переключился на изучение «мат.части», чтобы посмотреть, какие книги рассказывают об эволюции рабочего пространства: от первых опенспейсов 1900-х годов до коворкингов.

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

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

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

Всем привет, меня зовут Семен Левенсон, я работаю teamlead’ом на проекте «Поток» от Rambler Group и хочу рассказать о нашем опыте использования Apollo.

Объясню, что такое «Поток». Это автоматизированный сервис для предпринимателей, позволяющий привлекать клиентов из Интернета в бизнес, не вовлекаясь в рекламу, и быстро создавать простые сайты, не являясь экспертом в верстке.

Оглавление (на данный момент)

Часть 1. Описание, операции, применения.
Часть 2. Ценная информация в дереве и множественные операции с ней.
Часть 3. Декартово дерево по неявному ключу.
To be continued...

Декартово дерево (cartesian tree, treap) — красивая и легко реализующаяся структура данных, которая с минимальными усилиями позволит вам производить многие скоростные операции над массивами ваших данных. Что характерно, на Хабрахабре единственное его упоминание я нашел в обзорном посте многоуважаемого winger, но тогда продолжение тому циклу так и не последовало. Обидно, кстати.

Я постараюсь покрыть все, что мне известно по теме — несмотря на то, что известно мне сравнительно не так уж много, материала вполне хватит поста на два, а то и на три. Все алгоритмы иллюстрируются исходниками на C# (а так как я любитель функционального программирования, то где-нибудь в послесловии речь зайдет и о F# — но это читать не обязательно :). Итак, приступим.

Введение

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

Следующий пункт нашей обязательной программы — куча (heap). Думаю, также многим известная структура данных, однако краткий обзор я все же приведу.
Представьте себе двоичное дерево с какими-то данными (ключами) в вершинах. И для каждой вершины мы в обязательном порядке требуем следующее: ее ключ строго больше, чем ключи ее непосредственных сыновей. Вот небольшой пример корректной кучи:

На заметку сразу скажу, что совершенно не обязательно думать про кучу исключительно как структуру, у которой родитель больше, чем его потомки. Никто не запрещает взять противоположный вариант и считать, что родитель меньше потомков — главное, выберите что-то одно для всего дерева. Для нужд этой статьи гораздо удобнее будет использовать вариант со знаком «больше».

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