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

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

Ну и "вишенкой на торте" можно считать удобство и простоту используемого инструмента, что тоже немаловажно.

Для решения этих задач и была разработана кросс-платформенная open-source .NET библиотека Unchase.FluentPerformanceMeter.

Так вышло, что в данный момент я принимаю участие в разработке фронт-энд приложения (React + Redux), делающего множество запросов к REST API каждую минуту, если не секунду.

Мне надоело на каждый запрос писать REQUEST/FAILURE/SUCCESS (далее RFS) экшны, к ним кейсы для редьюсера, всё это обильно поливать тестами (ведь качество превыше всего).

Я написал очередной велосипед.

И в чем же проблема?

Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.

Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.

Ну, я и решил — если такого решения нет, напишу-ка я его сам.

Постановка задачи

Убирая всю лирику из первого абзаца, получаю задачу — нам нужно создать инструмент, который будет:

1. Делать асинхронный GET-запрос к REST API.
2. Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
3. Складывать полученные данные в store и следить за актуальностью хранящихся данных.

По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.

Этот пост является вольным переводом статьи Xcode: A Better Way to Deal with Storyboards by Stan Ostrovskiy

Некоторые примеры кода в оригинальной статье устарели (ввиду выхода Swift 3) и в переводе были изменены.

Советы и рекомендации по работе с Interface Builder.

Apple серьезно улучшили Interface Builder в новом Xcode 8. Использование size classes стало более интуитивным, возможность масштабирования сториборда — очень удобной, а полное превью прям в Interface Builder — просто великолепным. Для тех у кого были сомнения насчет использования Interface Builder, это может стать хорошими плюсами.

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

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

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

В вашем проекте есть один файл main.storyboard, который выглядит вот так?

С точки зрения дизайнера, все хорошо: полностью видно UI и навигацию. И это именно то, для чего Interface Builder и был создан.

Но для разработчика это несет множество проблем:

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

Строим свой full-stack на JavaScript: Основы

В мире JavaScript очень легко набрать свой стек технологий, используя набор небольших пакетов, каждый из которых решают свою конкретную проблему. И это хорошо, c одной стороны, а с другой стороны, у вас особо нет выбора — фреймворки которые выполняют широкий спектр задач в JavaScript не популярны.

В этом цикле статей я хочу поделиться своим практическим опытом построения JS стека.

В этой статье мы рассмотрим, как создавать всплывающие и перекрывающие элементы на React, Angular 1.5 и Angular 2. Реализуем создание и показ модального окна на каждом из фреймворков. Весь код написан на typescript. Исходный код примеров доступен на github.