• превратить нахождение аномального поведения в логах заводских приборов в задачу обычной классификации;
• как за короткое время сгенерировать легкие, но полезные фичи, характеризующие временной ряд целиком;
• как разделить работу внутри команды;
• как «на коленке» смешивать разные модели на одном наборе признаков;
• как поднять AUC с помощью kNN – вишенки на торте Competitive Data Science.

1. ключевом решении на основе подсчета статистик временных рядов в качестве признаков;
2. кодировании подряд идущих разреженных состояний системы вектором признаков;
3. выявлении аномалий с помощью LSTM, идеям по их модификациям.

https://habrahabr.ru/post/330282/

// Почему геймификация — это хорошо?

// А почему это может не работать в ряде случаев?

// Окей, какие кейсы вы приведете как примеры?

// Понятно, что все такие молодцы! А теперь расскажите про стартапы в сфере геймификации рекрутмента.

// К какому выводу мы пришли?

https://habrahabr.ru/post/330280/

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class GenericSingleton : MonoBehaviour {
    static GenericSingleton instance;
    public static GenericSingleton Instance { get { return instance; } }

	void Awake () {
		if (instance && instance != this)
        {
            Destroy(this);
            return;
        }
        instance = this;
	}
}

public class TestSingletoneA : GenericSingleton {

	// Use this for initialization
	void Start () {
        Debug.Log("A");
	}
}

/// 

/// Voloshin Game Framework: basic scripts supposed to be reusable
/// 
namespace VGF
{    
    //[System.Serializable]
    public interface AbstractModel where T : AbstractModel, new()
    {
        /// 

        /// Copy fields from target
        /// 
        /// Source model
        void SetValues(T model);            
    }

    public static class AbstratModelMethods
    {
        /// 

        /// Initialize model with source, even if model is null
        /// 
        /// 
        /// Target model, can be null
        /// Source model
        public static void InitializeWith(this T model, T source) where T: AbstractModel, new ()
        {
            //model = new T();
            if (source == null)
                return;
            model.SetValues(source);
        }
    }
}

using System.Collections.Generic;
using UnityEngine;

namespace VGF
{
    /* Why abstract class instead of interface?
     * 1) Incapsulate all save, load, init, loadinit functions inside class, make them protected, mnot public
     * 2) Create static ALL collection and static ALL methods
     * */
     //TODO: create a similar abstract class for non-mono classes. For example, PlayerController needs not to be a MonoBehaviour
    /// 

    /// Abstract class for all MonoBehaiour classes that support save and load
    /// 
    public abstract class SaveLoadBehaviour : CachedBehaviour
    {
        /// 

        /// Collection that stores all SaveLoad classes in purpose of providing auto registration and collective save and load
        /// 
        static List AllSaveLoadObjects = new List();

        protected override void Awake()
        {
            base.Awake();
            Add(this);
        }

        static void Add(SaveLoadBehaviour item)
        {
            if (AllSaveLoadObjects.Contains(item))
            {
                Debug.LogError(item + "  element is already in All list");
            }
            else
                AllSaveLoadObjects.Add(item);
        }

        public static void LoadAll()
        {
            foreach (var item in AllSaveLoadObjects)
            {
                if (item == null)
                {
                    Debug.LogError("empty element in All list");
                    continue;
                }
                else
                    item.Load();
            }
        }

        public static void SaveAll()
        {
            Debug.Log(AllSaveLoadObjects.Count);
            foreach (var item in AllSaveLoadObjects)
            {
                if (item == null)
                {
                    Debug.LogError("empty element in All list");
                    continue;
                }
                else
                    item.Save();
            }
        }

        public static void LoadInitAll()
        {
            foreach (var item in AllSaveLoadObjects)
            {
                if (item == null)
                {
                    Debug.LogError("empty element in All list");
                    continue;
                }
                else
                    item.LoadInit();
            }
        }

        protected abstract void Save();

        protected abstract void Load();

        protected abstract void Init();

        protected abstract void LoadInit();
    }
}

using UnityEngine;

namespace VGF
{
    /// 

    /// Controller for abstract models, providing save, load, reset model
    /// 
    /// AbstractModel child type
    public class GenericModelBehaviour : SaveLoadBehaviour where T: AbstractModel, new()
    {
        [SerializeField]
        protected T InitModel;
        //[SerializeField]
        protected T CurrentModel, SavedModel;

        protected override void Awake()
        {
            base.Awake();
            //Init();
        }

        void Start()
        {
            Init();
        }

        protected override void Init()
        {
            //Debug.Log(InitModel);
            if (InitModel == null)
                return;
            //Debug.Log(gameObject.name + " : Init current model");
            if (CurrentModel == null)
                CurrentModel = new T();
            CurrentModel.InitializeWith(InitModel);
            //Debug.Log(CurrentModel);
            //Debug.Log("Init saved model");
            SavedModel = new T();
            SavedModel.InitializeWith(InitModel);
        }

        protected override void Load()
        {
            //Debug.Log(gameObject.name + "   saved");
            LoadFrom(SavedModel);
        }

        protected override void LoadInit()
        {
            LoadFrom(InitModel);
        }

        void LoadFrom(T source)
        {
            if (source == null)
                return;
            CurrentModel.SetValues(source);
        }

        protected override void Save()
        {
            //Debug.Log(gameObject.name + "   saved");
            if (CurrentModel == null)
                return;
            if (SavedModel == null)
                SavedModel.InitializeWith(CurrentModel);
            else
                SavedModel.SetValues(CurrentModel);
        }
    }
}

public abstract class AbstractAliveController : GenericModelBehaviour, IAlive
    {
        //TODO: create separate unity implementation where put all the [SerializeField] attributes
        [SerializeField]
        bool Immortal;
        static Dictionary All = new Dictionary();
        public static bool GetAliveControllerForTransform(Transform tr, out AbstractAliveController aliveController)
        {
            return All.TryGetValue(tr, out aliveController);
        }

        DamageableController[] BodyParts;
        
        public bool IsAlive { get { return Immortal || CurrentModel.HealthCurrent > 0; } }
        public bool IsAvailable { get { return IsAlive && myGO.activeSelf; } }
        public virtual Vector3 Position { get { return myTransform.position; } }

        public static event Action OnDead;
        /// 

        /// Sends the current health of this alive controller
        /// 
        public event Action OnDamaged;

        //TODO: create 2 inits
        protected override void Awake()
        {
            base.Awake();
            All.Add(myTransform, this);            
        }

        protected override void Init()
        {
            InitModel.Position = myTransform.position;
            InitModel.Rotation = myTransform.rotation;
            base.Init();
            
            BodyParts = GetComponentsInChildren();
            foreach (var bp in BodyParts)
                bp.OnDamageTaken += TakeDamage;
        }

        protected override void Save()
        {
            CurrentModel.Position = myTransform.position;
            CurrentModel.Rotation = myTransform.rotation;
            base.Save();
        }

        protected override void Load()
        {
            base.Load();
            LoadTransform();
        }

        protected override void LoadInit()
        {
            base.LoadInit();
            LoadTransform();
        }

        void LoadTransform()
        {
            myTransform.position = CurrentModel.Position;
            myTransform.rotation = CurrentModel.Rotation;
            myGO.SetActive(true);
        }

        public void Respawn()
        {
            LoadInit();
        }

        public void TakeDamage(int damage)
        {
            if (Immortal)
                return;
            CurrentModel.HealthCurrent -= damage;
            OnDamaged.CallEventIfNotNull(CurrentModel.HealthCurrent);
            if (CurrentModel.HealthCurrent <= 0)
            {
                OnDead.CallEventIfNotNull(this);
                Die();
            }
        }

        public int CurrentHealth
        {
            get { return CurrentModel == null? InitModel.HealthCurrent: CurrentModel.HealthCurrent; }
        }

        protected abstract void Die();

    }

namespace VGF.Action3d
{
    [System.Serializable]
    public class AliveModelTransform : AliveModelBasic, AbstractModel
    {
        [HideInInspector]
        public Vector3 Position;
        [HideInInspector]
        public Quaternion Rotation;

        public void SetValues(AliveModelTransform model)
        {
            Position = model.Position;
            Rotation = model.Rotation;
            base.SetValues(model);
        }
    }
}

https://habrahabr.ru/post/330278/

У каждого языка есть принципы, на которых он основан. Для Erlang — «Let it crash and let someone else deal with it», для Ruby — «less astonishing» и «programmer happiness», в Python такие принципы как «Explicit is better than implicit», сформулированы в «Zen of Python». В то время, как одни взгляды нам близки, а другие мы не принимаем, они формируют не только дизайн языка и архитектуру библиотек и систем, которые разрабатываются на этом языке, но и сообщество разработчиков вокруг этого языка. В своем докладе я рассмотрю какие принципы заложены в Elixir, чем знание этих принципов полезно разработчику, и как они влияют на код, который мы пишем и используем в своей работе.

У меня сложилось впечатление, что в Elixir-сообществе незаслуженно подзабыли про такую штуку как ETS. Про этот мощный инструмент, который предоставляет платформа. Я расскажу несколько хитростей, которые сделают работу с ETS более удобной и как решить некоторые проблемы, которые возникают при работе с ним. Доклад будет интересен в основном новичкам. Но, возможно, и опытные разработчики смогут узнать что-то новое.

Нейронные сети набирают всё большую популярность в ИТ-индустрии, во многом благодаря применению графических сопроцессоров. Существует множество библиотек для реализации нейронных сетей, большинство из которых написано на Python или C. Вместе с тем платформа Erlang OTP позволяет без лишних усилий реализовать отказоустойчивое приложение с высокой степенью распараллеливания вычислений, и, на наш взгляд, идеально подходит для реализации высоко интегрированного решения для обработки потокового видео с помощью нейронных сетей. Также в библиотеке реализован медиа-сервер для приёма потокового видео. Таким образом пользователь может сосредоточиться на конфигурации нейронной сети, не отвлекаясь на технические детали обработки видео.

https://habrahabr.ru/post/330256/

У каждого языка есть принципы, на которых он основан. Для Erlang — «Let it crash and let someone else deal with it», для Ruby — «less astonishing» и «programmer happiness», в Python такие принципы как «Explicit is better than implicit», сформулированы в «Zen of Python». В то время, как одни взгляды нам близки, а другие мы не принимаем, они формируют не только дизайн языка и архитектуру библиотек и систем, которые разрабатываются на этом языке, но и сообщество разработчиков вокруг этого языка. В своем докладе я рассмотрю какие принципы заложены в Elixir, чем знание этих принципов полезно разработчику, и как они влияют на код, который мы пишем и используем в своей работе.

У меня сложилось впечатление, что в Elixir-сообществе незаслуженно подзабыли про такую штуку как ETS. Про этот мощный инструмент, который предоставляет платформа. Я расскажу несколько хитростей, которые сделают работу с ETS более удобной и как решить некоторые проблемы, которые возникают при работе с ним. Доклад будет интересен в основном новичкам. Но, возможно, и опытные разработчики смогут узнать что-то новое.

Нейронные сети набирают всё большую популярность в ИТ-индустрии, во многом благодаря применению графических сопроцессоров. Существует множество библиотек для реализации нейронных сетей, большинство из которых написано на Python или C. Вместе с тем платформа Erlang OTP позволяет без лишних усилий реализовать отказоустойчивое приложение с высокой степенью распараллеливания вычислений, и, на наш взгляд, идеально подходит для реализации высоко интегрированного решения для обработки потокового видео с помощью нейронных сетей. Также в библиотеке реализован медиа-сервер для приёма потокового видео. Таким образом пользователь может сосредоточиться на конфигурации нейронной сети, не отвлекаясь на технические детали обработки видео.

https://habrahabr.ru/post/330268/

У каждого языка есть принципы, на которых он основан. Для Erlang — «Let it crash and let someone else deal with it», для Ruby — «less astonishing» и «programmer happiness», в Python такие принципы как «Explicit is better than implicit», сформулированы в «Zen of Python». В то время, как одни взгляды нам близки, а другие мы не принимаем, они формируют не только дизайн языка и архитектуру библиотек и систем, которые разрабатываются на этом языке, но и сообщество разработчиков вокруг этого языка. В своем докладе я рассмотрю какие принципы заложены в Elixir, чем знание этих принципов полезно разработчику, и как они влияют на код, который мы пишем и используем в своей работе.

У меня сложилось впечатление, что в Elixir-сообществе незаслуженно подзабыли про такую штуку как ETS. Про этот мощный инструмент, который предоставляет платформа. Я расскажу несколько хитростей, которые сделают работу с ETS более удобной и как решить некоторые проблемы, которые возникают при работе с ним. Доклад будет интересен в основном новичкам. Но, возможно, и опытные разработчики смогут узнать что-то новое.

Нейронные сети набирают всё большую популярность в ИТ-индустрии, во многом благодаря применению графических сопроцессоров. Существует множество библиотек для реализации нейронных сетей, большинство из которых написано на Python или C. Вместе с тем платформа Erlang OTP позволяет без лишних усилий реализовать отказоустойчивое приложение с высокой степенью распараллеливания вычислений, и, на наш взгляд, идеально подходит для реализации высоко интегрированного решения для обработки потокового видео с помощью нейронных сетей. Также в библиотеке реализован медиа-сервер для приёма потокового видео. Таким образом пользователь может сосредоточиться на конфигурации нейронной сети, не отвлекаясь на технические детали обработки видео.

https://habrahabr.ru/post/330264/

У каждого языка есть принципы, на которых он основан. Для Erlang — «Let it crash and let someone else deal with it», для Ruby — «less astonishing» и «programmer happiness», в Python такие принципы как «Explicit is better than implicit», сформулированы в «Zen of Python». В то время, как одни взгляды нам близки, а другие мы не принимаем, они формируют не только дизайн языка и архитектуру библиотек и систем, которые разрабатываются на этом языке, но и сообщество разработчиков вокруг этого языка. В своем докладе я рассмотрю какие принципы заложены в Elixir, чем знание этих принципов полезно разработчику, и как они влияют на код, который мы пишем и используем в своей работе.

У меня сложилось впечатление, что в Elixir-сообществе незаслуженно подзабыли про такую штуку как ETS. Про этот мощный инструмент, который предоставляет платформа. Я расскажу несколько хитростей, которые сделают работу с ETS более удобной и как решить некоторые проблемы, которые возникают при работе с ним. Доклад будет интересен в основном новичкам. Но, возможно, и опытные разработчики смогут узнать что-то новое.

Нейронные сети набирают всё большую популярность в ИТ-индустрии, во многом благодаря применению графических сопроцессоров. Существует множество библиотек для реализации нейронных сетей, большинство из которых написано на Python или C. Вместе с тем платформа Erlang OTP позволяет без лишних усилий реализовать отказоустойчивое приложение с высокой степенью распараллеливания вычислений, и, на наш взгляд, идеально подходит для реализации высоко интегрированного решения для обработки потокового видео с помощью нейронных сетей. Также в библиотеке реализован медиа-сервер для приёма потокового видео. Таким образом пользователь может сосредоточиться на конфигурации нейронной сети, не отвлекаясь на технические детали обработки видео.

https://habrahabr.ru/post/330272/

https://habrahabr.ru/post/330250/

https://habrahabr.ru/post/330248/

https://habrahabr.ru/post/330244/

Введение в обработку естественных языков

Введение

• Формирование ответов на вопросы (Question Answering) (то, что делают Siri, Alexa и Cortana)
• Анализ эмоциональной окраски высказываний (Sentiment Analysis) (определение, имеет ли высказывание положительную или отрицательную коннотацию)
• Нахождение текста, соответствующего изображению (Image to Text Mappings) (генерация подписи к входному изображению)
• Машинный перевод (Machine Translation) (перевод абзаца текста с одного языка на другой)
• Распознавание речи (Speech Recognition)
• Морфологическая разметка (Part of Speech Tagging) (определение частей речи в предложении и их аннотирование)
• Извлечение сущностей (Name Entity Recognition)

Как использовать глубокое обучение

Структура статьи

Векторы слов

Word2Vec

Рекуррентные нейронные сети (Recurrent Neural Networks, RNN)

Управляемые рекуррентные нейроны (Gated recurrent units, GRU)

• Фильтр обновления
  
  • Если $$ ~ 1, то $$ не принимает во внимание текущий вектор слова и просто копирует предыдущее скрытое состояние.
  • Если $$ ~ 0, то $$ не учитывает предыдущее скрытое состояние и зависит только от контейнера памяти.
  • Этот фильтр позволяет модели контролировать, как много информации от предыдущего скрытого состояния должно влиять на текущее скрытое состояние.
• Фильтр сброса состояния
  
  • Если $$ ~ 1, то контейнер памяти сохраняет информацию с предыдущего скрытого состояния.
  • Если $$ ~ 0, то контейнер памяти не учитывает предыдущее скрытое состояние.
  • Этот фильтр позволяет отбросить часть информации, если в будущем она не будет нас интересовать.
• Контейнер памяти: зависит от фильтра сброса состояния.

Нейроны с длительной кратковременной памятью (Long short-term memory, LSTM)

Сравнение LSTM и GRU

Перед тем, как углубиться в статьи

Нейронные сети с памятью (Memory Networks)

Введение

Архитектура сети

• End to End Memory Networks
• Dynamic Memory Networks
• Dynamic Coattention Networks (реализованы в ноябре 2016 и получили лучший за все времена результат на наборе данных Stanford’s Question Answering)

Tree-LSTM для анализа эмоциональной окраски высказываний

Введение

Архитектура сети

Нейронный машинный перевод (Neural Machine Translation, NMT)

Введение

Архитектура сети

Заключение

О, а приходите к нам работать? :)

wunderfund.io — молодой фонд, который занимается высокочастотной алготорговлей. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.

Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.

Присоединяйтесь к нашей команде: wunderfund.io

https://habrahabr.ru/post/330194/

Принцип работы лазерных рулеток

В фазовом методе, в отличие от импульсного, лазер работает постоянно, но его излучение амплитудно модулируется сигналом определенной частоты (обычно это частоты меньше 500МГц). Отмечу, что длина волны лазера при этом остается неизменной (она находится в пределах 500 — 1100 нм).
Отраженное от объекта излучение принимается фотоприемником, и его фаза сравнивается с фазой опорного сигнала — от лазера. Наличие задержки при распространении волны создает сдвиг фаз, который и измеряется дальномером.
Расстояние определяется по формуле:

$$

Где с — скорость света, f — частота модуляции лазера, фи — фазовый сдвиг.
Эта формула справедлива только в том случае, если расстояние до объекта меньше половины длины волны модулирующего сигнала, которая равна с / 2f.
Если частота модуляции равна 10 МГц, то измеряемое расстояние может доходить до 15 метров, и при изменении расстояния от 0 до 15 метров разность фаз будет меняться от 0 до 360 градусов. Изменение сдвига фаз на 1 градус в таком случае соответствует перемещению объекта примерно на 4 см.
При превышении этого расстояния возникает неоднозначность— невозможно определить, сколько периодов волны укладывается в измеряемом расстоянии. Для разрешения неоднозначности частоту модуляции лазера переключают, после чего решают получившуюся систему уравнений.
Самый простой случай — использование двух частот, на низкой приблизительно определяют расстояние до объекта (но максимальное расстояние все равно ограничено), на высокой определяют расстояние с нужной точностью — при одинаковой точности измерения фазового сдвига, при использовании высокой частоты точность измерения расстояния будет заметно выше.

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

• Напряжение питания должно быть достаточно высоким — сотня вольт и выше.
• Сильная зависимость параметров от температуры.
• Достаточно высокая стоимость (по сравнению с другими фотодиодами).

Реверс-инжиниринг лазерной рулетки

• TP3, TP4 — низкочастотный сигнал с усилителя фотодиода. Именно этот сигнал несет информацию о расстоянии до объекта. При помощи осциллографа можно увидеть, что сигнал имеет частоту 5 кГц, и содержит постоянную составляющую.
• TP1 — опорный сигнал. Также имеет частоту 5 кГц и содержит постоянную составляющую. Амплитуда этого сигнала довольно мала — около 100 мВ.
• TP5 — высокое напряжение питания лавинного фотодиода.

Программирование

• 162.0 MHz
• 189.0 MHz
• 192.75 MHz
• 193.5 MHz

Алгоритм Гёрцеля (англ. Goertzel algorithm) — это специальная реализация дискретного преобразования Фурье (ДПФ) в форме рекурсивного фильтра.… В отличие от быстрого преобразования Фурье, вычисляющего все частотные компоненты ДПФ, алгоритм Гёрцеля позволяет эффективно вычислить значение одного частотного компонента.

• При увеличении Uapd (то есть с ростом усиления) заметно возрастает чувствительность APD к изменениям температуры и изменению уровня сигнала.
• При уменьшении амплитуды светового сигнала появляется небольшой сдвиг фазы — примерно +2 градуса при изменении амплитуды от максимальной до минимальной.
• При охлаждении APD появляется положительный сдвиг фазы.

1. Проверка, не попали ли разности фаз в зону «нулевого» расстояния. В области, близкой к нулю калибровки, из-за ошибок измерения значение разности фаз может «прыгать» — от 0 градусов до 359 градусов, что приводит к большим ошибками при измерении расстояния. Поэтому, при обнаружении, что все три разности фаз одновременно получились близкими к нулю, можно считать, что измеряемое расстояние близко к нулевому значению, и за счет этого отказаться от вычисления величин N.
2. Предварительное вычисление расстояния по биениям сигналов с частотами 191.5 МГц и 193.5 МГц. Эти частоты выбраны близкими, за счет чего зона определенности получается достаточно большой: $$, но и результат вычислений сильно подвержен влиянию ошибок измерений. При низком уровне принимаемого сигнала ошибка может составлять несколько метров (несколько длин волн).
3. Вычисление расстояния методом перебора по разностям фаз сигналов с частотами 162.5 МГц и 191.5 МГц.
   Поскольку на предыдущем этапе уже определено приблизительное расстояние, то диапазон перебираемых значений N можно ограничить. За счет этого уменьшается сложность перебора и отбрасываются возможные ошибочные результаты.

Результаты

Напоследок: какие рулетки еще можно встретить?

• В первую очередь стоит отменить проект реверс-инжиниринга лазерной рулетки BOSCH DLE50.
  Особенность этой рулетки — в ней в качестве PLL генератора используется заказная микросхема CF325, на которую в интернете нет никакой документации, что заметно усложняет процесс реверс-инжиниринга. Эта ситуация (заказные микросхемы без документации) очень часто встречается в лазерных рулетках, но, похоже, сейчас ситуация начинает меняться — заказные микросхемы начинают заменятся «универсальными».
  Используемый в этой рулетке микроконтроллер — ATmega169P.
  Еще одна особенность этой рулетки — использование механического узла, управляемого электромагнитом, который позволяет создавать «оптическое короткое замыкание», то есть перенаправляет свет от лазера к фотодиоду по известному пути. За счет того, что длина пути света и коэффициент отражения при этом известны, микроконтроллер может производить различные калибровки (по амплитуде и фазе). Во время работы этого узла лазерная рулетка достаточно громко щелкает.
  Вот здесь можно посмотреть фотографии электроники этой рулетки.
• Достаточно много что известно про лазерную рулетку UT390B.
  Некий энтузиаст смог произвести реверс-инжиниринг протокола отладочного UART интерфейса этой рулетки, и научился управлять ее работой. Есть даже библиотека для Arduino.
  На русском про устройство этой рулетки можно почитать здесь.
  Как видно из фотографий, электроника этой рулетки достаточно проста, и похожа на ту, что описана в этой статье.
  Используемый в этой рулетке микроконтроллер — STM32F103C8. Микросхема PLL: CKEL925 (на нее есть документация).
• А вот протокол новой версии рулетки UT390B+ никто пока выяснить не смог.
  Схемотехника этой рулетки отличается от ее старой версии.
  Она еще ближе к схемотехнике моей рулетки — здесь используется микроконтроллер STM32F030CBT6 и PLL Si5351.
  Если приглядеться к фотографиям, можно заметить, что в рулетке установлены два лазера.
  Судя по всему, два лазера в рулетке сейчас — не редкость. Вот в этом описании устройства еще одной рулетки упоминается, что один из лазеров имеет видимое излучение, и служит только для «целеуказания», а второй лазер — инфракрасный, и используется для измерения расстояния. Интересно, что при этом и лазер, и фотодиод используют одну линзу.
• Еще одна рулетка с неизвестным протоколом — BOSCH PLR 15.
  Энтузиасты уже пытались разобраться с ее протоколом, но пока в этом никто не преуспел.
  Раньше я тоже пробовал выяснить, как работает эта рулетка, и даже частично восстановил схему этой рулетки.
  Используемый в этой рулетке микроконтроллер — STM32F051R6. А вот других микросхем высокой степени интеграции в ней просто нет!
  Зато фотоприемник здесь использован очень необычный, я никогда не встречал даже упоминаний таких устройств:
  
  Судя по всему, он представляет собой систему на кристалле, и содержит два фотодиода (измерительный и опорный каналы), усилители фотодиодов, цифровую управляющую электронику и АЦП. Сигнал модуляции лазера идет тоже с него. Сам фотоприемник соединен с микроконтроллером через SPI.
  Я пробовал перехватывать данные, которые идут по SPI — там присутствуют команды от контроллера датчику и пакеты информации от датчика контроллеру.
  Если обработать эти пакеты в Excel — то явно видны синусоиды (то есть используется фазовый способ измерения расстояния). Это значит, что обработкой сигнала в этой рулетке занимается микроконтроллер.
  Однако информации по SPI идет очень много, частоты, на которых идут измерения, установить не удалось, так что даже считать с рулетки расстояние — достаточно проблематичная задача.
• Различные китайские модули.
  В последнее время в китайских интернет-магазинах появилось большое количество модулей лазерных дальномеров (из можно найти по запросу «laser ranging module» и аналогичных ему).
  Среди них можно найти и модули, которые выглядят абсолютно так же, как и мой, но продаются они в два раза дороже (40$). Похоже, что это все те же внутренности лазерных рулеток, но с модифицированной прошивкой. Интересно, что среди различных конструкций мне несколько раз попадались дальномеры с двумя одинаковыми микросхемами PLL (судя по всему, эти микросхемы — не заказные).
  

https://habrahabr.ru/post/327642/

https://habrahabr.ru/post/330242/

Когда нужна экосистема. Наш опыт

• Если меняется фирменный стиль, то нужно бежать и менять дизайн всего. Но более реалистично – у вас будет зоопарк. (Приоритеты, ресурсы, бюджеты – вам его обязательно обеспечат).
• Дизайнерам нужно будет постоянно контролировать фронтендеров. А им придется писать много повторяемого кода (но это отдельная большая история, и о ней мы вам расскажем отдельно)

• Пользователи испытывают неудобство в работе. Когда одному и тому же человеку приходится использовать несколько систем с неоднородным UX и в каждой из них элементы управления ведут себя немного по-разному, неизбежно возникают “трения” (frictions), количество которых и характеризует UX как хороший или плохой. Такого рода “трения” воспринимаются пользователем очень болезненно, потому что не дают работать “в потоке”.
  Так как у нас бизнес-системы, пользователи вынужденно их используют. Тем не менее “производительность” труда явно не на максимуме.
  

• Качество коммуникаций, в том числе маркетинговых, у компании далеко от идеала.
  Компании тщательно следят за соответствием всех своих носителей фирменному стилю. В толстом бренд-буке в деталях описывают нецифровые носители — от визиток до сувенирных кружек в фирменном стиле. А цифровые коммуникации компании зачастую не в состоянии регламентировать и привести к единому виду. И так цифровые носители “помогают” размывать бренд.
  

Язык дизайна. Этапы создания

Этап 1. Определяем основные принципы

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

• Избавляем интерфейсы от всех нефункциональных “красивостей”, которые не несут полезной функции.
• Используем минимум иконок. Как правило они не облегчают пользователю жизнь, а заставляют играть в «угадайку».

• Используем интуитивно-понятные ассоциации.
  Не каждый сразу вспомнит, что такое CVC-код, но всем понятно, что такое «три цифры на обороте карты», поэтому на страничках онлайн-оплаты размещают изображение банковской карты.
  В нашем случае, для сотрудников авиакомпании, которые занимаются анализом проданных перевозок, отображение данных было сверстано по стандартам составления маршрутных квитанций (по-простому – билета).
  

• Учитываем восприятие цветов человеком при выборе цветовых решений в интерфейсах.
  К примеру, в финансах принято красным обозначать расходы. Поэтому, когда мы делаем финансовую систему, в которой будут работать бухгалтера, мы будем «раскрашивать» для них деньги так, как им привычно. И так нужно действовать с каждой аудиторией.
  

• Поддерживает развитие функционала.
• Поддерживает разные платформы — веб, мобильность.
• Оставляет пространство для “творчества”.
  Можно сделать специальное оформление к праздникам, или маркетинговой акции.

Этап 2. Собираем UI Kit

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

Этап 3. Технологично упаковываем

Этап 4. Создаем «документацию»

Этап 5. Обеспечиваем версионность

Итого в результате дизайн-части проекта:

• Мы научились создавать собственный «язык» дизайна, адаптированный под специфику экосистемы ИТ-сервисов заказчика.
• На опыте ИТ-сервисов конкретного заказчика превратили зоопарк в единую экосистему. Разработали единую концепцию UX, что позволит минимизировать “трение” при работе с нашими системами.
• Создали UI Kit, который позволяет заказчику поддерживать и развивать все свои системы в едином стиле, а для наших дизайнеров сокращает временные затраты при работе над дизайном.
• Реализовали распространение обновлений библиотеки в виде npm-пакета, что в сочетании с грамотным версионированием помогает исправлять огрехи и актуализировать дизайн безболезненно и изолированно на каждом проекте.
• Исчерпывающе проиллюстрировали работу библиотеки через демо-приложение, что позволяет разработчикам нередко обходиться не только без дизайнеров, но даже без верстальщиков.

https://habrahabr.ru/post/330206/

Первое впечатление

• Google действительно сделали хорошую библиотеку с удобным API;
• Google не стал закрываться, а учел все современные наработки в области архитектуры Android-приложений, взяв лучшее из всего;
• У новичков наконец-то есть хорошая документация, которая поможет им начать разрабатывать приложения уже с неплохой архитектурой, без необходимости детально вникать в смысл MVP/MVVM и т.д.

Хорошая архитектура

• Позволяет декомпозировать логику (получение данных/обработка/взаимодействие с пользователем и т.д.);
• Масштабируемость. Слово, которое должно быть в любой статье про архитектуру. В Android с этим все достаточно просто, так как любое приложение можно разбить на экраны, между которыми будут весьма прозрачные связи, а архитектуру отдельного экрана сделать масштабируемой не представляется сложным;
• Позволяет писать тесты для бизнес-логики приложения.

1. Обработка пересоздания Activity. Вероятно, самая многострадальная тема при построении архитектуры приложения, которая не нуждается в комментариях;
2. Выполнение HTTP запросов (как на получение данных, так и на отправку);
3. Поддержка потоков данных, например, при работе с сокетами/сенсорами;
4. Кэширование данных;
5. Обработка ошибок.

Архитектура от Google

public class LocationLiveData extends LiveData {
 
   private LocationManager locationManager;
 
   private LocationListener listener = new LocationListener();
 
   private LocationLiveData(@NonNull Context context) {
       locationManager = (LocationManager) context.getSystemService(Context.LOCATION_SERVICE);
   }
 
   @Override
   protected void onActive() {
       locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);
   }
 
   @Override
   protected void onInactive() {
       locationManager.removeUpdates(listener);
   }
}

public class LocationActivity extends LifecycleActivity {
 
   private LocationLiveData locationLiveData;
  
   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_movies);
      
       //...
 
       locationLiveData = new LocationLiveData(this);
       locationLiveData.observe(this, location -> {
           // update your UI
       });
   }
 
   //...
}

public class BaseLifecycleActivity extends AppCompatActivity implements LifecycleRegistryOwner {
 
   @NonNull
   private final LifecycleRegistry lifecycleRegistry = new LifecycleRegistry(this);
 
   @MainThread
   @NonNull
   @Override
   public LifecycleRegistry getLifecycle() {
       return lifecycleRegistry;
   }
}

1. Все экземпляры ViewModel хранятся в retain Fragment (HolderFragment). Это весьма стандартное решение, которым также пользовались многие разработчики.
2. Класс ViewModel должен хранить все экземпляры LiveData, чтобы они переживали пересоздание Activity.
3. Связь ViewModel с View осуществляется через LiveData, то есть ViewModel не управляет View явным образом, и это можно считать некоторой вариацией паттерна MVVM.

public class MoviesViewModel extends ViewModel {
  
   @NonNull
   private final MoviesRepository moviesRepository;
 
   @Nullable
   private MutableLiveData> moviesLiveData;
 
   public MoviesViewModel(@NonNull MoviesRepository moviesRepository) {
       this.moviesRepository = moviesRepository;
   }
 
   @MainThread
   @NonNull
   LiveData> getMoviesList() {
       if (moviesLiveData == null) {
           moviesLiveData = new MutableLiveData<>();
           moviesRepository.popularMovies()
                   .subscribeOn(Schedulers.io())
                   .observeOn(AndroidSchedulers.mainThread())
                   .subscribe(moviesLiveData::setValue);
       }
       return moviesLiveData;
   }
}

viewModel.getMoviesList().observe(this, movies -> {
   if (movies != null) {
       adapter.setNewValues(movies);
   }
});

MoviesViewModel viewModel = ViewModelProviders.of(this).get(MoviesViewModel.class);

class MoviesViewModelProviderFactory extends BaseViewModelFactory {
 
   @NonNull
   private final MoviesRepository repository;
 
   MoviesViewModelProviderFactory(@NonNull MoviesService moviesService) {
       this.repository = new MoviesRepository(moviesService);
   }
 
   @NonNull
   @Override
   public  T create(@NonNull Class modelClass) {
       if (modelClass.equals(MoviesViewModel.class)) {
           //noinspection unchecked
           return (T) new MoviesViewModel(repository);
       }
       return super.create(modelClass);
   }
}

ViewModelProvider.Factory factory = new MoviesViewModelProviderFactory(service);
return ViewModelProviders.of(this, factory).get(MoviesViewModel.class);

Показ прогресса и обработка ошибок

public class Response {
 
   @Nullable
   private final T data;
 
   @Nullable
   private final Throwable error;
 
   private Response(@Nullable T data, @Nullable Throwable error) {
       this.data = data;
       this.error = error;
   }
 
   @NonNull
   public static  Response success(@NonNull T data) {
       return new Response(data, null);
   }
 
   @NonNull
   public static  Response error(@NonNull Throwable error) {
       return new Response(null, error);
   }
 
   @Nullable
   public T getData() {
       return data;
   }
 
   @Nullable
   public Throwable getError() {
       return error;
   }
}

public class MoviesViewModel extends ViewModel {
 
   @Nullable
   private MutableLiveData>> moviesLiveData;
 
   //...
 
   @MainThread
   @NonNull
   LiveData>> getMoviesList() {
       if (moviesLiveData == null) {
           moviesLiveData = new MutableLiveData<>();
           moviesRepository.popularMovies()
                   //...
                   .subscribe(
                           movies -> moviesLiveData.setValue(Response.success(movies)),
                           throwable -> moviesLiveData.setValue(Response.error(throwable))
                   );
       }
       return moviesLiveData;
   }
}

viewModel.getMoviesList().observe(this, moviesResponse -> {
   if (moviesResponse != null && moviesResponse.getData() != null) {
       adapter.setNewValues(moviesResponse.getData());
   } else if (moviesResponse != null && moviesResponse.getError() != null) {
       // show error
   }
});

@NonNull
private final MutableLiveData loadingLiveData = new MutableLiveData<>();
 
@NonNull
LiveData isLoading() {
   return loadingLiveData;
}
 
@MainThread
@NonNull
LiveData>> getMoviesList() {
   if (moviesLiveData == null) {
       moviesLiveData = new MutableLiveData<>();
       moviesRepository.popularMovies()
               //...
               .doOnSubscribe(disposable -> loadingLiveData.setValue(true))
               .doAfterTerminate(() -> loadingLiveData.setValue(false))
               .subscribe();
   }
   return moviesLiveData;
}

viewModel.isLoading().observe(this, isLoading -> {
   if (isLoading != null && isLoading) {
       progressDialog.show(getSupportFragmentManager());
   } else {
       progressDialog.cancel();
   }
});

Тестирование

@RunWith(JUnit4.class)
public class MoviesViewModelTest {
 
   private MoviesViewModel viewModel;
 
   private MoviesRepository repository;
 
   @Before
   public void setUp() throws Exception {
       repository = Mockito.mock(MoviesRepository.class);
       Mockito.when(repository.popularMovies()).thenReturn(Observable.just(new ArrayList<>()));
 
       viewModel = new MoviesViewModel(repository);
   }
}

@Test
public void testLoadingMovies() throws Exception {
   Observer observer = Mockito.mock(Observer.class);
   viewModel.getMoviesList().observeForever(observer);
 
   Mockito.verify(repository).popularMovies();
   Mockito.verify(observer).onChanged(any(Response.class));
}

@MainThread
protected void setValue(T value) {
   assertMainThread("setValue");
   mVersion++;
   mData = value;
   dispatchingValue(null);
}

testCompile ("android.arch.core:core-testing:$architectureVersion", {
   exclude group: 'com.android.support', module: 'support-compat'
   exclude group: 'com.android.support', module: 'support-annotations'
   exclude group: 'com.android.support', module: 'support-core-utils'
})
 
@Rule
public InstantTaskExecutorRule instantExecutorRule = new InstantTaskExecutorRule();

@Test
public void testProgressUpdated() throws Exception {
   Observer observer = Mockito.mock(Observer.class);
   viewModel.isLoading().observeForever(observer);
   viewModel.getMoviesList();
 
   Mockito.verify(observer).onChanged(true);
   Mockito.verify(observer).onChanged(false);
}

Кэширование данных

Заключение

https://habrahabr.ru/post/330208/

Simple XML

$xml = simplexml_load_file("price.xml");
echo "\n";

foreach ($xml->xpath('/DocumentElement/price') as $producs) { ?> 
    

https://habrahabr.ru/post/330240/

Кто трясет деревья?

Webpack, Rollup и Uglify

Что делать?

https://habrahabr.ru/post/330148/

Диалоговые системы давно и прочно вошли в нашу жизнь. В заглавии упомянута и на картинке представлена ELIZA — диалоговая система-психоаналитик (сейчас, ее назвали бы чат-бот), родом из 60-ых годов. Если вам интересно, как человек дошел до общения с ботами-психоаналитиками и что еще есть интересного в диалоговых системах, добро пожаловать под кат.

В самом деле сейчас диалоговые системы можно встретить где угодно: если вы звоните в банк, вы общаетесь (по крайней мере сначала) с диалоговой системой, когда вы делаете заказ или пытаетесь задать маршрут в навигаторе — тоже, может быть, вы пользуетесь Siri от Apple или Cortana от Microsoft, и это тоже они.

Чем привлекательны диалоговые интерфейсы? Тем, что это естественный для человека способ получения информации. (Собственно, поэтому робот, с которым вы разговариваете, когда куда-то звоните, называет “автоинформатор”.)

Классификация

Диалоговые системы можно охарактеризовать по следующим признакам: General — Task-oriented (общего назначения — задачеориентированный) и Open Domain — Closed Domain (способный говорить на любую тему или только на строго определенную). В каждой из пар первый компонент существенно сложнее второго. Давайте рассмотрим несколько примеров:

Начнем с самого простого — с автоинформаторов, они совершенно точно task-oriented и closed domain.
Вышеупомянутая ELIZA — closed domain (она умеет говорить только на тему психоанализа), но при этом general — у нее нет четко поставленной задачи, с ней можно “поболтать”.
Еще один пример бота, c которым можно поболтать, — CharRNN от Андрея Карпаты (Andrej Karpathy). Сама CharRNN — это просто нейросетевая модель, которая умеет продолжать данную ей строку, если натренировать ее, например, на субтитрах к фильмам и сериалам, то она научится “отвечать” на ваши реплики. В этом смысле она является general — у нее нет четко выраженной цели — и open domain — потенциально может говорить на любую тему. Проблема заключается только в том, что эта модель исключительно простая, она просто продолжает данную ей строку, не имея никакого понятия о диалоге, фразах и даже отдельных словах.

Из примеров остались два: ConvAI — это наше соревнование, о котором ниже, и true AI. Почему я отдельно выделил, что AI здесь “настоящий”? Потому что сейчас пошла мода называть AI все, что угодно, вплоть до автоинформаторов. Я же хотел подчеркнуть, что это полноценный искусственный интеллект, способный говорить на любую тему. И — самое важное — он способен вести беседу, то есть имеет представление о диалоге.

ConvAI

Теперь пришло время рассказать о нашем соревновании, чем оно отличается от приведенного выше и зачем мы решили его делать.
ConvAI — это Conversational Intelligence Challenge, соревнование разговорного искусственного интеллекта. А раз это соревнование, то нужно как-то участников сравнивать. И тут оказывается, что стандартные метрики сравнения текстов, известные по машинному переводу BLEU, ROUGE, etc. здесь не работают.

Получается, что машинные метрики, которые мы знаем, не коррелируют с человеческими суждениями (в то время как человеческие оценки между собой прекрасно коррелируют — верхняя правая картинка). Источник [1].

Из этого следует, что сравнивать системы общего назначения между собой пока не представляется возможным — мы просто не знаем, как это делать. Но зато мы совершенно точно можем сравнивать задачеориентированные системы с помощью простейшей метрики Task Completion Rate (TCR).

То есть мы можем их сравнить по количеству диалогов, которые достигли цели. В качестве цели для нашего соревнования мы выбрали обсуждение небольшого куска текста, например, короткой новостной статьи или отрывка из Википедии. Человек, пообщавшись на тему представленного текста с другим человеком/ботом, ставит свою оценку. При этом мы не даем пользователю информации о “естественности” или “искусственности” интеллекта собеседника. Базируясь на собранных оценках мы сможем отранжировать ботов наших участников так, чтобы построить цепочку от самого простого CharRNN до человека. (По крайней мере, мы на это надеемся.)

Стоит еще упомянуть, что наш challenge прошел жесткий отбор и был выбран, как NIPS Live Competition этого года. А также то, что соорганизаторами соревнования являются Йошуа Бенжио (Yoshua Bengio), который не нуждается в представлении, а также Александр Рудницкий (Alexander Rudnicky) и Алан Блэк (Alan W. Black) из университета Карнеги-Мэллон (Carnegie-Mellon University).
Всю информацию про соревнование, включая правила, API нашего сервера и другое, можно найти на его сайте convai.io.

Датасеты

Отдельно стоит сказать про доступные датасеты для исследований в области разговорного интеллекта. Существует несколько общедоступных датасетов для диалоговых систем [2]. Прежде всего, стоит выделить Dialog State Tracking Challenge, в этом году он, кстати, будет проводиться уже в шестой раз. Он рассчитан на системы, которые могут вести диалог, отслеживая его состояние (state), то есть является, пожалуй, самым близким к цели нашего соревнования. Но у этого датасета есть важная особенность — он является closed domain, то есть исключительно рассматривает одну конкретную тему. Open domain и task-oriented общедоступного датасета не существует, и мы рассчитываем, что после нашего соревнования будет сформирован новый датасет, состоящий из разговоров добровольцев и участников команд с ботами, который будет выложен в общий доступ для всех исследователей.

Заключение

Надеемся, что у вас сформировалось некоторое представление о диалоговых системах. Более того, если вы хотите попробовать себя в их создании, то мы будем рады вас видеть в качестве участника или добровольца (нам нужны люди, которые будут разговаривать с ботами наших участников). Если вы не представляете, с чего начать, то мы специально для вас сделали базовое решение. Оно требует немного пререквизитов для запуска — по факту, один только Docker. Так что — дерзайте!

P.S. Если вам интересно поучаствовать в создании искусственного интеллекта не только во время соревнования, но и на постоянной основе, у нас есть открытые позиции. Информацию можно почерпнуть на сайте ipavlov.ai.

Литература

1. Chia-Wei Liu et al. How NOT To Evaluate Your Dialogue System: An Empirical Study of Unsupervised Evaluation Metrics for Dialogue Response Generation. arxiv:1603.08023
2. Iulian Vlad Serban et al. A Survey of Available Corpora for Building Data-Driven Dialogue Systems. arxiv:1512.05742

https://habrahabr.ru/post/330228/

void irq_handler(pt_regs_t *regs) {
        ...
    int irq = get_irq_number(regs);
    {
        ipl_enable();
        irq_dispatch(irq);
        ipl_disable();
    }
    irqctrl_eoi(irq);
        ...
    critical_dispatch_pending();
}

Обработка прерываний на Cortex-M

FreeRTOS

void xPortSysTickHandler( void )
{
    /* The SysTick runs at the lowest interrupt priority, so when this interrupt
    executes all interrupts must be unmasked.  There is therefore no need to
    save and then restore the interrupt mask value as its value is already
    known. */
    portDISABLE_INTERRUPTS();
    {
        /* Increment the RTOS tick. */
        if( xTaskIncrementTick() != pdFALSE )
        {
            /* A context switch is required.  Context switching is performed in
            the PendSV interrupt.  Pend the PendSV interrupt. */
            portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
        }
    }
    portENABLE_INTERRUPTS();
}

void xPortPendSVHandler( void )
{
    /* This is a naked function. */
 
    __asm volatile
    (
    "   mrs r0, psp                         \n"
    "   isb                                 \n"
    "                                       \n"
    "   ldr r3, pxCurrentTCBConst           \n" /* Get the location of the current TCB. */
    "   ldr r2, [r3]                        \n"
    "                                       \n"
    "   tst r14, #0x10                      \n" /* Is the task using the FPU context?  If so, push high vfp registers. */
    "   it eq                               \n"
    "   vstmdbeq r0!, {s16-s31}             \n"
    "                                       \n"
    "   stmdb r0!, {r4-r11, r14}            \n" /* Save the core registers. */
    "                                       \n"
    "   str r0, [r2]                        \n" /* Save the new top of stack into the first member of the TCB. */
    "                                       \n"
    "   stmdb sp!, {r3}                     \n"
    "   mov r0, %0                          \n"
    "   msr basepri, r0                     \n"
    "   dsb                                 \n"
    "   isb                                 \n"
    "   bl vTaskSwitchContext               \n"
    "   mov r0, #0                          \n"
    "   msr basepri, r0                     \n"
    "   ldmia sp!, {r3}                     \n"
    "                                       \n"
    "   ldr r1, [r3]                        \n" /* The first item in pxCurrentTCB is the task top of stack. */
    "   ldr r0, [r1]                        \n"
    "                                       \n"
    "   ldmia r0!, {r4-r11, r14}            \n" /* Pop the core registers. */
    "                                       \n"
    "   tst r14, #0x10                      \n" /* Is the task using the FPU context?  If so, pop the high vfp registers too. */
 
    "   it eq                               \n"
    "   vstmdbeq r0!, {s16-s31}             \n"
    "                                       \n"
    "   stmdb r0!, {r4-r11, r14}            \n" /* Save the core registers. */
    "                                       \n"
    "   str r0, [r2]                        \n" /* Save the new top of stack into the first member of the TCB. */
    "                                       \n"
    "   stmdb sp!, {r3}                     \n"
    "   mov r0, %0                          \n"
    "   msr basepri, r0                     \n"
    "   dsb                                 \n"
    "   isb                                 \n"
    "   bl vTaskSwitchContext               \n"
    "   mov r0, #0                          \n"
    "   msr basepri, r0                     \n"
    "   ldmia sp!, {r3}                     \n"
    "                                       \n"
    "   ldr r1, [r3]                        \n" /* The first item in pxCurrentTCB is the task top of stack. */
    "   ldr r0, [r1]                        \n"
    "                                       \n"
    "   ldmia r0!, {r4-r11, r14}            \n" /* Pop the core registers. */
    "                                       \n"
    "   tst r14, #0x10                      \n" /* Is the task using the FPU context?  If so, pop the high vfp registers too. */
    "   it eq                               \n"
    "   vldmiaeq r0!, {s16-s31}             \n"
    "                                       \n"
    "   msr psp, r0                         \n"
    "   isb                                 \n"
    "                                       \n"
    #ifdef WORKAROUND_PMU_CM001 /* XMC4000 specific errata workaround. */
        #if WORKAROUND_PMU_CM001 == 1
    "           push { r14 }                \n"
    "           pop { pc }                  \n"
        #endif
    #endif
    "                                       \n"
    "   bx r14                              \n"
    "                                       \n"
    "   .align 4                            \n"
    "pxCurrentTCBConst: .word pxCurrentTCB  \n"
    ::"i"(configMAX_SYSCALL_INTERRUPT_PRIORITY)
    );
}

StackType_t *pxPortInitialiseStack( StackType_t *pxTopOfStack, TaskFunction_t pxCode, void *pvParameters )
{
    /* Simulate the stack frame as it would be created by a context switch
    interrupt. */
 
    /* Offset added to account for the way the MCU uses the stack on entry/exit
    of interrupts, and to ensure alignment. */
    pxTopOfStack--;
 
    *pxTopOfStack = portINITIAL_XPSR;   /* xPSR */
    pxTopOfStack--;
    *pxTopOfStack = ( ( StackType_t ) pxCode ) & portSTART_ADDRESS_MASK;    /* PC */
    pxTopOfStack--;
    *pxTopOfStack = ( StackType_t ) portTASK_RETURN_ADDRESS;    /* LR */
 
    /* Save code space by skipping register initialisation. */
    pxTopOfStack -= 5;  /* R12, R3, R2 and R1. */
    *pxTopOfStack = ( StackType_t ) pvParameters;   /* R0 */
 
    /* A save method is being used that requires each task to maintain its
    own exec return value. */
    pxTopOfStack--;
    *pxTopOfStack = portINITIAL_EXEC_RETURN;
 
    pxTopOfStack -= 8;  /* R11, R10, R9, R8, R7, R6, R5 and R4. */
 
    return pxTopOfStack;
}

NuttX

uint32_t *up_doirq(int irq, uint32_t *regs)
{
  board_autoled_on(LED_INIRQ);
#ifdef CONFIG_SUPPRESS_INTERRUPTS
  PANIC();
#else
  uint32_t *savestate;
 
  /* Nested interrupts are not supported in this implementation.  If you want
   * to implement nested interrupts, you would have to (1) change the way that
   * CURRENT_REGS is handled and (2) the design associated with
   * CONFIG_ARCH_INTERRUPTSTACK.  The savestate variable will not work for
   * that purpose as implemented here because only the outermost nested
   * interrupt can result in a context switch.
   */
 
  /* Current regs non-zero indicates that we are processing an interrupt;
   * CURRENT_REGS is also used to manage interrupt level context switches.
   */
 
  savestate    = (uint32_t *)CURRENT_REGS;
  CURRENT_REGS = regs;
 
  /* Acknowledge the interrupt */
 
  up_ack_irq(irq);
 
  /* Deliver the IRQ */
 
  irq_dispatch(irq, regs);
 
  /* If a context switch occurred while processing the interrupt then
   * CURRENT_REGS may have change value.  If we return any value different
   * from the input regs, then the lower level will know that a context
   * switch occurred during interrupt processing.
   */
 
  regs = (uint32_t *)CURRENT_REGS;
 
  /* Restore the previous value of CURRENT_REGS.  NULL would indicate that
   * we are no longer in an interrupt handler.  It will be non-NULL if we
   * are returning from a nested interrupt.
   */
 
  CURRENT_REGS = savestate;
#endif
  board_autoled_off(LED_INIRQ);
  return regs;
}

    bl      up_doirq                /* R0=IRQ, R1=register save (msp) */
    mov     r1, r4                  /* Recover R1=main stack pointer */
 
    /* On return from up_doirq, R0 will hold a pointer to register context
     * array to use for the interrupt return.  If that return value is the same
     * as current stack pointer, then things are relatively easy.
     */
 
    cmp     r0, r1                  /* Context switch? */
    beq     l2                      /* Branch if no context switch */
	//Далее копируем регистры
…
    /* We are returning with a pending context switch.  This case is different
     * because in this case, the register save structure does not lie in the
     * stack but, rather, within a TCB structure.  We'll have to copy some
     * values to the stack.
     */
 
    add     r1, r0, #SW_XCPT_SIZE   /* R1=Address of HW save area in reg array */
    ldmia   r1, {r4-r11}            /* Fetch eight registers in HW save area */
    ldr     r1, [r0, #(4*REG_SP)]   /* R1=Value of SP before interrupt */
    stmdb   r1!, {r4-r11}           /* Store eight registers in HW save area */
#ifdef CONFIG_BUILD_PROTECTED
    ldmia   r0, {r2-r11,r14}        /* Recover R4-R11, r14 + 2 temp values */
#else
    ldmia   r0, {r2-r11}            /* Recover R4-R11 + 2 temp values */
#endif
	…

Embox

void irq_handler(pt_regs_t *regs) {
          ...
    int irq = get_irq_number(regs);
    {
          ipl_enable();
          irq_dispatch(irq);
          ipl_disable();
    }
    irqctrl_eoi(irq); // Только тут теперь будет небольшая хитрость, а не прямой вызов
          ...
}

// Регистры сохраняемые процессором при входе в прерывание
struct cpu_saved_ctx {
    uint32_t r[5];
    uint32_t lr;
    uint32_t pc;
    uint32_t psr;
};
 
void interrupt_handle(struct context *regs) {
    uint32_t source;
    struct irq_saved_state state;
    struct cpu_saved_ctx *ctx;
 
    ... // Тут обычная обработка прерывания, пропустим
 
    state.sp = regs->sp;
    state.lr = regs->lr;
    assert(!interrupted_from_fpu_mode(state.lr));
    ctx = (struct cpu_saved_ctx*) state.sp;
    memcpy(&state.ctx, ctx, sizeof *ctx);
 
    // Ниже показано то как мы модифицируем стек
    /* It does not matter what value of psr is, just set up sime correct value.
     * This value is only used to go further, after return from interrupt_handle.
     * 0x01000000 is a default value of psr and (ctx->psr & 0xFF) is irq number if any. */
    ctx->psr = 0x01000000 | (ctx->psr & 0xFF);
    ctx->r[0] = (uint32_t) &state; // we want pass the state to __pending_handle()
    ctx->r[1] = (uint32_t) regs; // we want pass the registers to __pending_handle()
    ctx->lr = (uint32_t) __pending_handle;
    ctx->pc = ctx->lr;
 
    /* Now return from interrupt context into __pending_handle */
    __irq_trampoline(state.sp, state.lr);
}

.global __irq_trampoline
__irq_trampoline:
 
    cpsid  i
    # r0 contains SP stored on interrupt handler entry. So we keep some data
    # behind SP for a while, but interrupts are disabled by 'cpsid i'
    mov    sp,  r0
    # Return from interrupt handling to usual mode
    bx     r1

.global __pending_handle
__pending_handle:
    // Тут выгружаем на стек “старый” контекст, чтобы выйти из прерывания
    // уже по-честному, то есть туда где нас изначально прервали.
    # Push initial saved context (state.ctx) on top of the stack
    add    r0, #32
    ldmdb  r0, {r4 - r11}
    push   {r4 - r11}
 
    // Тут восстанавливаем некоторые регистры. Но это не очень значимая деталь,
    // Для понимания эта деталь не важна, пропустим.
    ...
 
    cpsie  i
    // Вот тут переключаем контексты, если требуется
    bl     critical_dispatch_pending
    cpsid  i
    # Generate PendSV interrupt
    // Тут инициируем прерывание PendSV, обработчик приведен ниже
    bl     nvic_set_pendsv
    cpsie  i
    # DO NOT RETURN
1: b       1
 
.global __pendsv_handle
__pendsv_handle:
 
    # 32 == sizeof (struct cpu_saved_ctx)
    add    sp, #32
    # Return to the place we were interrupted at,
    # i.e. before interrupt_handle_enter
    bx     r14

https://habrahabr.ru/post/330236/

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

Шаг 1: Установка расширения

Шаг 2: Создание нового проекта

Шаг 3: Выбор сценария

Шаг 4: Настройка очереди

Общие настройки

Агенты

Почтовые настройки

Фильтры

• {client_name} – имя клиента
• {client_email} – e-mail клиента
• {ticket_id} – id созданного тикета (если создался тикет)

Шаг 5: Работа с тикетами

• Для ручного создания тикета необходимо открыть письмо от клиента, нажать на иконку Deskun и выбрать пункт «Создать тикет в...». Далее выбирается очередь, к которой относится задача.
• Если в настройках очереди вы указали ответственного сотрудника, то все тикеты будут автоматически адресоваться ему.

1. Сводная информация.
2. Последние действия.
3. Информация по открытым и закрытым тикетам.

Заключение

https://habrahabr.ru/post/330232/