В последнее время активную популярность набирает Kotlin. А что если попробовать выбрать более экзотические языки, и применить к ним те же аргументы? Статья написана по мотивам этой, практически повторяя все аргументы за Kotlin. Основная задача: показать, что Ceylon может практически тоже самое, что и Kotlin, применительно к Java. Но кроме этого у Ceylon есть кое-что еще, что будет описано в следующей статье.

Хочу рассказать о новом языке программирования, который называется Ceylon, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я писал на Java (много и долго, более 10 лет, начиная с Java 1.4 и заканчивая Java 8), и Java мне нравилась. Затем на меня большое впечатление произвела Scala, в результате чего Java как язык стал любить несколько меньше. Но судьба свела меня с языком Сeylon, и в последние полтора года мы пишем на Ceylon везде, где только можно. В реальных коммерческих проектах, правда внутренних. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java, я не рассматриваю Java как язык, на котором стоит начинать новые проекты.

Ceylon разработан в Red Hat, автор языка — Gavin King, известный по такому фреймворку как Hibernate. Он создавался людьми, которые хорошо понимают недостатки Java, основная цель заключалась в решении сугубо прикладных задач, обеспечение максимально легкой читаемости кода, избегание любых неоднозначностей и подводных камней, во главу всего стала предсказуемость и структурная красота языка. Также большое внимание уделялось приемлемому времени компиляции. В настоящее время версия языка 1.3.2, непосредственно я познакомился с языком, когда вышла версия 1.2.0.

Хотя Ceylon компилируется в JavaScript, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Ceylon (порядок совпадает с одноименными пунктами соответствующей Kotlin статьи):

0# Совместимость с Java

Также, как и Kotlin, как и Scala, Ceylon на 100 % совместим с Java. Вы можете в буквальном смысле продолжать работать над своим старым Java-проектом, но уже используя Ceylon. Все Java-фреймворки также будут доступны, и, в каком бы фреймворке вы ни писали, Ceylon будет легко принят упрямым любителем Java. Можно без проблем вызывать из Java Ceylon код, также без проблем вызывается Java код.

1# Знакомый синтаксис

Одна из основных особенностей языка Ceylon — максимально удобно читаемый для существующих разработчиков синтаксис. Если взять существующего Java разработчика, то с пониманием Ceylon синтаксиса у него не будет ни малейших проблем. Даже такие языки, как Scala и Kotlin будут менее похожи на Java. Ниже приведен код, показывающий значительное количество конструкций языка, аналогичный примеру на Kotlin:

class Foo(String a) {

    String b= "b";           //  unmodifiable
    variable Integer i = 0;  // variable means modifiable

    void hello() {
        value str = "Hello";
        print("``str`` World");
    }

    Integer sum(Integer x, Integer y) {
        return x + y;
    }

    Float maxOf(Float a, Float b) => if (a > b) then a else b
}

Соответственно можно без проблем продолжать писать в Java стиле на Ceylon.

2# Интерполяция строк

Это как бы более умная и читабельная версия String.format() из Java, встроенная в язык:

value x = 4;
value y = 7;
print("sum of ``x`` and ``y`` is ``x + y``") ; // sum of 4 and 7 is 11

ИМХО синтаксис здесь будет поприятнее, чем в Kotlin, с Java даже не хочется сравнивать.

3# Выведение типа

Ceylon будет выводить ваши типы, если вы посчитаете, что это улучшит читабельность:

value a = "abc";                         // type inferred to String
value b = 4;                             // type inferred to Integer

Float c = 0.7;                   // type declared explicitly
List d = ArrayList();     // type declared explicitly

4# Умные приведения типов (Smart Casts)

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

if (is String obj) {
    print(obj.uppercased)     // obj is now known to be a String
}

5# Интуитивные равенства (Intuitive Equals)

Можно больше не вызывать явно equals(), потому что оператор == теперь проверяет структурное равенство:

value john1 = Person("John"); //we override equals in Person
value john2 = Person("John");
print(john1 == john2);    // true  (structural equality)
print(john1 === john2);    // false  (referential equality)

6# Аргументы по умолчанию

Больше не нужно определять несколько одинаковых методов с разными аргументами:

void build(String title, Integer width = 800, Integer height = 600) {
    return Frame(title, width, height);
}

7# Именованные аргументы

В сочетании с аргументами по умолчанию именованные аргументы избавляют от необходимости использовать Строителей:

build("PacMan", 400, 300)                           // equivalent
build {title = "PacMan"; width = 400; height = 300;}  // equivalent
build {title = "PacMan"; height = 300;}  // equivalent with default width

8# Выражение switch

Оператор ветвления заменён гораздо более читабельным и гибким в применении выражением switch:

switch (obj)
case(1)                              { print("x is 1"); }
case(2)                              { print("x is 2"); }
case(3 | 4)                          { print("x is 3 or 4"); }
case(is String)                      { print ("x is String"); }
case([Integer a, Float b, String c]) {print ("x is tuple with Integer ``a``, Float ``b`` and String ``c``");}
else                                 { print("x is out of range");}

switch может работать как выражение, также результат switch может быть присвоен переменной:

Boolean|IllegalStateException res = 
    switch(obj)
    case(null) false
    case(is String) true
    else IllegalStateException();

Это не полноценный pattern matching, но для большинства случаев хватает и текущего функционала.

В отличие от Kotlin у Ceylon требуется, чтобы к switch все условия были disjoint, то есть не пересекались, что для switch гораздо более логично. Если требуется сопоставление по диапазону или условия могут пересекаться, то нужно использовать обычный if.

9# Свойства

Можно добавить публичным полям кастомное поведение set & get, т. е. перестать набивать код безумными геттерами и сеттерами.

class Frame() {
    variable Integer width = 800;
    variable Integer height = 600;

    Integer pixels => width * height;
}

10# Data Class

К сожалению данного функционала пока нет. Очень хотелось бы иметь иммутабельные классы, у которых автоматом переопределен toString(), equals(), hashCode() и copy(), но, в отличие от Java, не занимали 100 строк кода.

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

class Person(shared String name, 
             shared String email,
             shared Integer age) extends DataObject() {}

value john = Person("John", "john@gmail.com", 112);
value johnAfterBirhstday = john.copy({`Person.age`->113;});
assertEquals(john, john.copy());
assertEquals(john.hash, john.copy().hash);

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

11# Перегрузка оператора (Operator Overloading)

Заранее определённый набор операторов, которые можно перегружать для улучшения читабельности:

class Vec(shared Float x, shared Float y) satisfies Summable {
    shared actual Vec plus(Vec v)  => Vec(x + v.x, y + v.y);
}

value v = Vec(2.0, 3.0) + Vec(4.0, 1.0);

12# Деструктурирующие объявления (Destructuring Declarations)

Некоторые объекты могут быть деструктурированы, что бывает полезно, к примеру, для итерирования map:

for ([key -> [val1, val2, val3]] in map) {
    print("Key: ``key``");
    print("Value: ``val1``, ``val2``, ``val3``");
}

13# Диапазоны (Ranges)

Для улучшения читабельности:

for (i in 1..100) { ... } 
for (i in 0 : 100) { ... }
for (i in (2..10).by(2)) { ... } 
for (i in 10..2) { ... }  
if (x in 1..10) { ... }

В отличие от Kotlin обошлось без ключевого слова downTo.

14# Функции-расширения (Extension Functions)

Их нет. Возможно появится, в ранних спецификациях языка такая возможность рассматривалась. Но вместо функций расширений в принципе работают top level функции. Если мы, допустим, хотим добавить к классу String метод sayHello, то "world".sayHello() выглядит не намного лучше чем sayHello("world"). В будущем они могут появиться.

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

15# Безопасность Null

Java следует называть почти статично типизированным языком. Внутри него переменная типа String не гарантированно ссылается на String — она может ссылаться на null. И хотя мы к этому привыкли, это снижает безопасность проверки на статичное типизирование, и в результате Java-разработчики вынуждены жить в постоянном страхе перед NPE.

В Ceylon эта проблема решена посредством разделения на типы, допускающие и не допускающие значение null. По умолчанию типы не допускают null, но их можно преобразовать в допускающие, если добавить ?:

variable String a = "abc";
a = null;                // compile error

variable String? b = "xyz";
b = null;                // no problem

За счет функционала union types String? это просто синтаксический сахар для String|Null. Соответственно можно написать:

variable String|Null с = "xyz";
с = null;                // no problem

Ceylon заставляет вас бороться с NPE, когда вы обращаетесь к типу, допускающему null:

value x = b.length        // compile error: b might be null

Возможно, выглядит громоздко, но благодаря нескольким своим возможностям действительно полезно. У нас всё ещё есть умные приведения типов, когда типы, допускающие null, преобразуются в не допускающие:

if (!exists b) { return; }
value x = b.length        // no problem

Также можно использовать безопасный вызов ?., он возвращает значение null вместо бросания NPE:

value x = b?.length;       // type of x is nullable Int

Можно объединять безопасные вызовы в цепочки, чтобы избегать вложенных проверок если-не-null, которые иногда мы пишем в других языках. А если нам по умолчанию нужно не null-значение, то воспользуемся elvis-оператором else

value name = ship?.captain?.name else "unknown";

Если всё это вам не подходит и вам совершенно точно нужны NPE, то скажите об этом явно:

value x = b?.length else NullPointerException()  // same as below
assert(!NullPointerException x);

16# Улучшенные лямбды

Это хорошая система лямбд — идеальный баланс между читабельностью и лаконичностью благодаря нескольким толковым решениям. Синтаксис прост:

value sum = (Integer x, Integer y) => x + y;  // type: Integer(Integer, Integer)
value res = sum(4,7)                      // res == 11

Соответственно синтаксис может быть:

numbers.filter( (x) => x.isPrime() );
numbers.filter(isPrime)

Это позволяет нам писать лаконичный функциональный код:

    persons
        .filter ( (it) => it.age >= 18)
        .sort(byIncreasing(Person.name))
        .map ( Person.email )
        .each ( print );

Система лямбд плюс синтаксические особенности языка, делает Ceylon неплохим инструментом для создания DSL. Пример DSL, похожего на Anko, в синтаксисе Ceylon:

 VerticalLayout {
    padding = dip(30);  {
    editText {
        hint = "Name";
        textSize = 24.0;
    },
    editText {
        hint = "Password";
        textSize = 24.0;
    },
    button {
        "Login";
        textSize = 45.0;
    } }
};

17# Поддержка IDE

Между прочим, она достаточно неплохая. Есть eclipse плагин, есть IDEA плагин. Да, по части фич и багов все несколько хуже, чем в Scala или Kotlin. Но в принципе работать можно и достаточно комфортно, проблемы IDE на скорости разработки практически не сказываются.

Итого, если брать сильные стороны Kotlin, Ceylon уступает Kotlin отсутствием функционала DataObject (который можно эмулировать самостоятельно средствами библиотек). В остальном он обеспечивает не меньшие возможности, но с более приятным для чтения синтаксисом.

Ну и так же, как и на Kotlin, на Ceylon можно писать для Android.

Прочитав вышесказанное, может сложиться впечатление — а зачем нам это? Тоже самое есть и в Kotlin, практически 1 в 1.

А то, что в Ceylon есть вещи, которых нет ни в Kotlin, ни в Scala, и за счет этих вещей сам язык во многом гораздо лучше, чем другие языки. Например union types, intersection types, enumerated types, более мощные generics, модульность, herd, аннотации и метамодель, кортежи, for comprehensions. Что реально меняет подход к программированию, позволяет писать гораздо более надежный, понятный и универсальный код. Но об этом в следующей части.

https://habrahabr.ru/post/330412/

1. Генерация BPDU сообщений каждым устройством независимо от корневого коммутатора.
   
   В классическом варианте BPDU «генерит» в сети только корневой коммутатор. Все остальные устройства лишь ретранслируют его. Таким образом, отсутствие BPDU от вышестоящего устройства значит, что проблема может быть в любом месте между данным устройством и корневым коммутатором. Поэтому приходилось ждать достаточно долго (MaxAge=20 сек) прежде чем, смириться с тем, что что-то пошло не так и нужно перестраивать топологию.
   
   В случае RSTP сообщения BPDU стали выполнять роль Hello-пакетов. Теперь потеря трёх таких пакетов (а это 2*3=6 сек) означает, что пора задуматься об изменениях в топологии.
   
   
2. Механизм Proposal/Agreement при активации соединения точка-точка на не Edge-портах для быстрого перехода в состояние передачи (Forwarding).
   
   
   Примечание

   RSTP предусматривает два типа соединения:
   

   • точка-точка (point-to-point) – к такому порту подключен только один RSTP коммутатор;
     
   • общий (shared) — к такому порту подключено несколько RSTP коммутаторов (через хаб, что в наше время является большой экзотикой).
     

   
   Обычно коммутаторы определяют тип соединения автоматически, опираясь на режим передачи full-duplex (точка-точка) или half-duplex (общий). В случае соединения shared «фишечки» RSTP перестают работать.
   
   
   В классическом STP порт, который должен стать корневым, проходит все стадии по переходу в режим передачи (Listening -> Learning -> Forwarding), что занимает более 30 секунд.
   
   Прежде чем коснуться механизма Proposal/Agreement, нужно отметить два разных типа портов в RSTP: пограничный порт (Edge port) и не пограничный (non-Edge port). В Edge порт подключаются оконечные устройства (ПК, серверы, в ряде случаев маршрутизаторы и пр.). В не Edge-порт подключаются другие коммутаторы, участвующие в топологии STP.
   
   
   Примечание

   Тип порта Edge задаётся вручную. Коммутатор не может быстро определить, кто к нему подключен: обычный хост или коммутатор. Конечно, он мог бы ориентироваться на наличие BPDU на этом порту. Но по стандарту коммутатор должен обязательно подождать минимум 15 секунд (Forward delay) прежде, чем решить, что на его порт так и не пришло ни одно сообщение. А это слишком долго. Поэтому право определить, что подключено к порту, доверили человеку.
   
   На коммутаторах Cisco тип порта Edge задаётся командой spanning-tree portfast.
   
   
   RSTP использует механизм Proposal/Agreement для быстрого переходя портов из состояния Discarding в состояние Forwarding. Этот механизм запускается, когда у коммутатора меняется Root Port (как минимум при включении в сеть). В этом случае он выключает все порты, не являющиеся Edge-портами. Об этом оповещает вышестоящий коммутатор (куда как раз смотрит Root port), после чего включает в режим Forwarding только Root port. Остальные порты (не Edge) находятся в заблокированном состоянии, пока не произойдёт одно из двух:
   
   
   • коммутатор обменяется сообщениями Proposal/Agreement с нижестоящим коммутатором,
   • истекут таймеры перехода из стояния Discarding в Learning (15 сек) и из Learning в Forwarding (15 сек), если подключённое оборудование не поддерживает RSTP.
     
   
   Сообщение Proposal отправляется портом, который хочет стать назначенным (Designated) для данного сегмента сети. И фактически запускает механизм Proposal/Agreement. Сообщение Agreement отправляется портом, который становиться корневым (Root). Оно необходимо для оповещения вышестоящего устройства о возможности немедленно перевести порт в состояние Forwarding.
   
   
   
   
3. Механизм альтернативного порта при потере связи через корневой порт.
   
   RSTP отличается от STP тем, что состояние порта отвязали от его роли. Это позволило описать роль порта в топологии сети без оглядки на его состояние. А значить обладать лучшим видение топологии сети и возможностью оперативно реагировать на изменения в ней. Так появились альтернативный (alternative) и резервный (backup) порты. Альтернативный порт – замена корневому. Через него может быть достигнут корневой коммутатор, но при этом данный порт не имеет роли корневого (т.е. получает BPDU c худшей метрикой) и не является назначенным (т.е. не является лучшим в данном сегменте сети для достижимости корневого устройства).
   
   В протоколе RSTP альтернативный порт переходит в состояние передачи сразу же после того, как откажет корневой. Такого же поведения можно добиться в классическом STP, используя проприетарные доработки. Например, Cisco предлагает для этих целей технологию UplinkFast.
   
   
   
   
   
4. Механизм немедленной реакции на получение BPDU с информацией о «худшем» корневом коммутаторе от соседа, имеющего назначенный (designated) порт для данного сегмента сети.
   
   В такой ситуации, если у устройства есть другой маршрут к корневому коммутатору, в классическом STP порт, который ранее был заблокирован, пройдёт все стадии и переключится в режим передачи только через 50 секунд (MaxAge + 2x Forward Delay).
   
   В случае RSTP коммутатор немедленно оценит полученный BPDU (в RSTP нет MaxAge таймера) и начнёт передавать свои, выставив флаг Proposal. Получив такое BPDU, коммутатор, потерявший связь с «рутом», примет участие в механизме Proposal/Agreement, так как у него сменился корневой порт. А дальше достаточно оперативно порты на обоих коммутаторах перейдут в состояние передачи.
   
   
   
   
5. Улучшенная схема рассылки и обработки сообщений TCN BPDU об изменениях в сети.
   
   Классический STP считает, что топология изменилась, если порт перешёл из состояния заблокированный в состояние передачи или наоборот. Так как изменение топологии может привести к тому, что MAC адреса станут доступны через другие порты (а значит, коммутатор будет слать пакеты не туда), запускается процедура оповещения всех устройств о таком событии. Для этого рассылается сообщение Topology Change Notification (TCN). Получив которое, коммутатор меняет время старения MAC адресов со значения по умолчанию (300 сек) на 15 сек (Forward Delay). Сообщение TCN рассылается в два этапа. Сначала коммутатор, обнаруживший изменения в топологии, отправляет его в сторону корневого коммутатора. Далее корневой коммутатор, получив такое сообщение, узнаёт об изменении в сети и рассылает TCN сообщение (BPDU с соответствующим флагом) уже всем остальным. Двухуровневая схема необходима, так как BPDU в классическом варианте отправляется только корневым коммутатором.
   
   В случае RSTP изменением в топологии считается только переход порта в режим передачи. Причём учитываются порты, которые не являются пограничным (non-edge port). Это и логично, так как переход порта в заблокированное состояние автоматически делает MAC адреса за ним больше не доступными. Как только обнаружено изменение топологии, коммутатор рассылает через все порты (корневой и назначенные) BPDU c флагом TC. Такое сообщение быстро распространяется по сети. Получив его, коммутаторы удаляют из таблицы все MAC адреса доступные через не edge порты, за исключением того, где был получен BPDU c флагом TC.
   
   Edge порт никогда не вызывает изменений в топологии, а также для такого порта не сбрасываются MAC адреса в случае получения BPDU c флагом TC.
   

• К порту подключается устройство, поддерживающее только классический STP. В этом случае порт коммутатора из режима работы RSTP переходит в режим STP. А значит проходит все стандартные для STP стадии: Blocking, Listening, Learning, Forwarding (в зависимости от того, с какими значениями корневого коммутатора и стоимости будет получен BPDU).
  
  
• Коммутатор определил соединение как shared. В этом случае используются стандартные таймеры RSTP. Так как к такому порту подключено два и более коммутатора, задействовать механизм Proposal/Agreement невозможно.
  
  
• Подключено устройство, не участвующее в STP, и на порту не задан тип edge. В этом случае порт пройдёт следующие стадии RSTP: Discarding (15 секунд), Learning (15 секунд), Forwarding. Таким образом, он перейдёт в режим передачи только через 30 секунд.

• Быстрое переключение порта в режим передачи (Forwarding). Порт в этом случае не проходит стандартные стадии на базе таймеров. Это важно, если к такому порту подключено обычное оборудование. Например, сервер или ПК.
• Не происходит уменьшение времени старения MAC адресов за таким портом при получении сообщения TCN. А значит меньше вероятность фладинга пакетов для хостов, которые больше слушают, чем что-то сами отправляют.

• При срабатывании механизма Proposal/Agreement блокируются все не Edge-порты. А это значит, что если мы не настроим обычный порт, куда подключено оконечное оборудование, в режим Edge, коммутатор будет выключать его на 30 секунд (работа RSTP по таймерам) каждый раз, когда меняется root port. В простых сетях это происходит не часто. Но в относительно большой легко. Это как раз тот случай, когда кажется, что перестроения произойдут в сети достаточно быстро, и никто этого даже не заметит. А по факту устройства «отваливаются» от сети на полминуты.

https://habrahabr.ru/post/330358/

Мотивация. Почему Huginn

1. поступила жалоба от клиента
2. зафиксировать факт в журнале
3. отправить сообщение в Telegram

• OpenSource – более 16k звёзд на github.
• Написан на RoR – можно дорабатывать и писать свои компоненты.
• Легко разворачивается и масштабируется.
• Имеет низкий порог вхождения.

Где использовать Huginn

• публикация аукционов во внутренний Telegram-канал,
• триггерные уведомления: жалобы, нарушения, пики и просадки в метриках,
• пуш данных во внешние системы, такие как exponea, expertsender или piwik.

Что такое Huginn

• Webhook Agent – принимает POST запросы от внешних источников.
• Post Agent, Website Agent – отправляет запросы на указанный урл, парсит JSON, HTML или XML.
• DeDuplication Agent – не пропускает дубли событий по уникальному ключу.
• Event Formatting Agent – позволяет перемапить поля в сообщении.
• JavaScript Agent – выполняет произвольный JS код (V8, therubyracer).

• Mysql2Agent – поллим базу на наличие изменений. Для каждой строки выборки будет сгенерировано событие и передано дальше по цепочке.
• EventFormatting – форматируем входящее сообщение с использованием liquid шаблонов.
• JsonAPIAgent – вызвать внешнее или внутреннее API для получения/отправки данных.

Примеры использования

Публикация новых аукционов в Telegram-канал

Персональные рекомендации по sms

Интеграция с маркетинговыми инструментами

Развернуть и попробовать

docker run -it --name huginn \
    -p 3000:3000 \
    -e ADDITIONAL_GEMS="huginn_mysql2_agent(git: https://github.com/yubuylov/huginn_mysql2_agent.git),huginn_jsonapi_agent(git: https://github.com/yubuylov/huginn_jsonapi_agent.git)" \
    huginn/huginn

http://localhost:3000/
Логин: admin, Пароль: password

Полезные ссылки

https://habrahabr.ru/post/330382/

Благодаря Reddit становится популярен формат Ask Me Anything (AMA) — когда команда специалистов, ответственных за какой-то большой, популярный проект, предлагает всем желающим задавать им любые вопросы об их работе и о том, что у сервиса «под капотом», как всё устроено. Первыми формат AMA на Хабре использовали разработчики Badoo. Мы тоже решили попробовать. Надеемся, что другие компании последуют нашему примеру и начнут впускать читателей на свои внутренние кухни.

Стартовать AMA мы решили с командой Облака Mail.Ru. Это молодой, активно развивающийся проект, о котором нам всегда задают много вопросов. К тому же с момента запуска (с августа 2013 года) Облако разрослось в большую семью проектов.

Исторически Облако начиналось как B2C-продукт с веб-, десктопной и мобильными версиями. Однако B2B — это тоже очень перспективный рынок. Поэтому у нас появилась платформа Mail.Ru для бизнеса, объединяющая все B2B-сервисы компании Mail.Ru Group, в том числе Облако для архивов (Icebox), Облако для рабочих групп (Teambox) и Горячее хранилище (Hotbox).

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

Для начала немного истории

Когда мы начинали писать Облако, то взяли за основу единую кодовую базу, которая использовалась и в Почте, и в Моём Мире, и в контентных проектах. Эту кодовую базу мы называем Mpop. Она представляет собой кучу библиотек, написанных на Perl. И несколько лет назад на ней жили все портальные проекты Mail.Ru Group. Когда в каком-то из проектов что-то рефакторили в Mpop, это влияло и на остальные. Постепенно каждый проект переехал на свою версию Mpop, а затем мы начали от неё уходить. Почта, например, частично перешла на Go. Мы тоже изначально жили на Mpop, но потихонечку всё переписали на свой супербыстрый Perl-сервер. У нас полностью асинхронная архитектура, мы используем AnyEvent. И если вы знаете Perl, то приходите к нам, у нас очень весело и интересно!

Как всё устроено

Структурно Облако Mail.Ru состоит из нескольких команд:

• Команда, которая пишет серверную часть и выстраивает её взаимодействие с хранилищами и мобильными клиентами.
• Команда разработки API, прослойки между серверами и вебом. API пользуются и Icebox, и Teambox.
• Команда разработки Hotbox. Она разрабатывает как административный интерфейс для работы с бакетами и ключами в Hotbox, так и само S3 API.
• Команда разработки UI (пользовательского интерфейса) и вёрстки. Отвечает за красоту интерфейса, его стабильность, скорость и функциональность.
• Команда разработки десктопного клиента, которая делает облачный клиент под платформы Windows, Linux, macOS. Также эта команда работает над Скриншотером и разнообразными фичами под него.
• Две команды мобильной разработки, которые пишут клиентские приложения для iOS и Android, напрямую взаимодействующие с серверной частью.
• Команда админов, которая всё это поддерживает, не смыкая глаз днями и ночами.
• Также у нас есть команда тестирования и команда автотестирования, которая пишет автотесты для API.

Под капотом веб- и десктопной версий Облака

Бэкенд Облака Mail.Ru написан на ANSI C, Perl, Lua и немного С++. На Perl решаются задачи, связанные с API. Например, редактирование документов. К слову, мы когда-то рассказывали на Хабре о том, как показываем видео в Облаке, серверная часть там написана на Perl + Lua.

С самого начала, когда ставилась задача создать Облако, одним из главных требований было отсутствие долгих поисков по БД, никаких seek по диску и хранения по принципу append only. На момент старта мы не нашли подходящей БД под древовидные данные, поэтому создали собственную для представления файловой системы.

Приведём немного чисел:

• В день наши юзеры загружают порядка 100 терабайт данных.
• У нас есть более тысячи серверов дисковых хранилищ — это более 100 петабайт данных, в них находится более 9 миллиардов файлов. Нужно оптимально обходить и верифицировать их и быть уверенными в том, что пользовательский контент хранится надёжно и без изменений.
• Число активных пользователей ежемесячно — более 18 миллионов. Каждый день на веб заходит много сотен тысяч уников.
• Мы меняем в среднем десять дисков в неделю, на них заново накатываем данные.
• Пропускная способность сети — до 200 Гбит/c (при необходимости мы можем увеличить её в несколько раз). На закачку к нам сейчас идёт около 25 Гбит/с.

Изначально Облако писалось с фокусом на десктопные и мобильные клиенты. Затем стало ясно, что веб-то жжот, нужно переделывать. Облако полностью переписали асинхронно (вообще у нас вся кодовая база асинхронная, от ANSI C до AnyEvent в Perl), стало намного лучше и быстрее. Например, сейчас веб-версия Облака живёт на том же десятке серверов, что и три года назад, при том, что число пользователей существенно выросло. Только тогда они лежали в полке по ресурсам без какого-либо запаса. Другие наши новые продукты, например Hotbox, мы тоже пишем на Perl. Такие дела.

Под капотом мобильного Облака

Для написания iOS-приложения Облака мы продолжаем использовать Objective-C. Swift пока не трогаем по ряду причин:

1. Мы всё ещё поддерживаем iOS 7. Да, Swift уже поддерживается на этой версии операционки, но работать со Swift’овыми зависимостями весьма затруднительно.
2. Swift всё ещё нестабилен, и нам не хочется повторять героические подвиги по адаптации новых версий языка, хорошо описанные командой разработчиков Firefox.
3. Использование Swift в данный момент существенно увеличивает размер приложения, а мы гордимся тем, что весим всего около 20 Мб.
4. Мы активно используем динамические свойства языка Objective-C, а в Swift аналогов нет.

В качестве примеров применения динамизма Objective-C приведём следующие:

1. Написание юнит-тестов на утечки памяти. Это возможно благодаря нашей библиотеке POSAllocationTracker. Возможность использования в юнит-тестах выгодно отличает её от фейсбучного аналога в лице FBAllocationTracker.
2. Автоматическое обнаружение доступа к объекту из неправильного потока. Имплементировано в объекте POSSchedulableObject из библиотеки POSRx. Кстати, в ней вы можете посмотреть на боевые примеры юнит-тестов на утечки памяти.

Другие архитектурные особенности iOS-приложения:

• Использование POSInputStreamLibrary для загрузки видеофайлов в Облако. На графике ниже отображаются два вида загрузок видеофайлов. Оранжевые столбы — загрузки, содержимое которых получено с помощью API Photos.framework. Синие столбы — содержимое получено с помощью ALAssetsLibrary и завёрнуто в POSInputStreamLibrary. Это делает загрузку тяжёлых видеофайлов экстремально быстрой, как было описано в нашей давней статье.

• Использование disaster recovery тестов. В нашу сетевую библиотеку встроен механизм генерации случайных сетевых ошибок. Таким образом, в отладочной сборке приложению обязательно прилетят от сервиса пятисотки и четырёхсотки. Благодаря этому практически невозможно не протестировать каждую новую фичу на данные краевые случаи. Имплементация доступна в наглядном виде в объекте POSHTTPGateway из библиотеки POSRx.

Главная архитектурная задача для iOS приложения на сегодняшний день — избавление от подвисаний приложения при работе с большими облаками. В качестве инструмента для решения данной проблемы мы видим паттерн Schedulable Architecture, о котором мы не так давно писали на Хабре. Чтобы по мере его внедрения немедленно видеть результаты и быть уверенными, что движемся в правильном направлении, мы сделали мониторинг подвисаний. Сейчас у нас уже есть график самых проблемных мест в виде списка классов, в которых чаще всего происходят зависания. Выглядит он так:

Благодаря плагину для HockeyApp у нас есть полная информация о каждом зависании — стек вызовов и логи.

Android-клиент Облака полностью разработан на Java (мы пока не нашли для себя выгоды в Kotlin’e). В принципе, в архитектуре нет ничего супермодного: MVP, весь сетевой слой в сервисе, для сети используем okhttp, данные храним в SQLite, за исключением галереи. Там может быть очень много данных, и их надо быстро поднимать из кеша. Поэтому для галереи мы применяем самописную сериализацию. Для коммуникации внутри приложения есть eventbus от green robot. Для эффективной работы в фоне на новых версиях андроида используем JobScheduler’ы, а для не очень новых — GcmNetworkManager.

Для выкатки фич на процент, A/B тестирования и части аналитики используем Firebase. Для отладки взаимодействия с сервером юзаем в дебажных сборках Stetho от Facebook. В последней версии почти перешли на векторную графику в приложении. Думаю, через пару версий полностью перейдём на неё. Тесты пишем на junit, uiautomator и espresso.

Под капотом B2B-Облака

B2B-Облако — это три разных продукта:

• Teambox — облако для рабочих групп, аналог B2C-Облака, в котором можно выделить личное пространство для каждого аккаунта в домене, создавать общие папки для отделов и групп сотрудников и настраивать доступ к файлам.
• Hotbox — хранилище с быстрым доступом для распространения медиа- и любого другого часто скачиваемого контента с S3-совместимым протоколом доступа, распределённым хранением с множественным копированием и гарантированным SLA 99,99 %.
• Icebox — объектное облачное хранилище для архивации и длительного хранения данных и простым веб-интерфейсом. Оно создано для хранения и доступа к редко используемым данным с поддержкой протокола S3, к которым при необходимости можно получить быстрый доступ.

B2B-Облако состоит из двух частей — фронтенда, который мы встроили в нашу Платформу для бизнеса, и бэкенда, который обеспечивает управление Облаком и его работу. Та часть бэкенда, которая отвечает за функционирование Облака, написана на Perl, поддержка управления — на Python.

Платформа для бизнеса biz.mail.ru обеспечивает доступ к управлению всех B2B-Облаков. Сама платформа — это общая административная панель для B2B-сервисов Mail.Ru: Почты для сайта, корпоративного Календаря, Агента, службы DNS и B2B-Облаков. Платформа предоставляет личный кабинет администраторов и реализована по принципу плагинов — есть общие элементы (авторизация, управление проектами и доменами, списком пользователей), есть отдельные разделы для подключаемых сервисов — Почты, Teambox, Hotbox, Icebox и других. У Платформы есть своё API и механизм проксирования запросов из бэкенда Платформы в бэкенды подключенных сервисов. Таким образом, у нас имеется общая инфраструктура, функционал которой разрабатывают разные команды программистов, а для пользователей всё управление собрано в одной административной панели.

Итак, спрашивайте!

По традиции надо обозначить время, когда мы будем отвечать на вопросы. И пусть это будут два дня, а не один: сегодня и завтра с 12.00 до 19.00 (по московскому времени). Но в случае особо ожесточённых дискуссий мы, конечно, не ограничимся этим интервалом. Задавайте вопросы про наш софт, про наши серверы, про наши команды, про наше API и так далее. Погнали!

https://habrahabr.ru/post/330348/

А что делать остальным?

1. Display: box работает только с префиксами, в данном случае с -webkit- (display: -webk2) it-box;).
2. Странно работает с float.
3. Аналогов некоторым современным свойствам нет.

Как же решить уже найденные проблемы?

@media all and (-webkit-min-device-pixel-ratio:0) {
/*Всё, что вы сюда напишете, будет работать только с -webkit-*/
}

https://habrahabr.ru/post/330410/

Наборы для игр

Разное

https://habrahabr.ru/post/330252/

Создатели сервиса

https://habrahabr.ru/post/330404/

В этой статье я бы хотел рассказать о том, как работают списки инициализации (braced initializer lists) в C++, какие проблемы они были призваны решать, какие проблемы, в свою очередь, вызвали и как не попасть в просак.

Первым делом предлагаю почувствовать себя компилятором (или language lawyer-ом) и понять, компилируются ли следующие примеры, почему, и что они делают:

Классика:

std::vector v1{5};
std::vector v2(5);
std::vector v3({5});
std::vector v4{5};
std::vector v5 = 5;

Современный C++ — безопасный язык, я никогда не выстрелю себе в ногу:

std::vector x( {"a", "b"} );
std::vector y{ {"a", "b"} };

Больше скобочек богу скобочек!

// Почему их тут пять, скомпилируется ли программа и почему?
std::vector> v1{{{{{}}}}}; 

Если один конструктор не подходит, мы берем второй, правильно?

struct T{};
struct S {
    S(std::initializer_list);
    S(double, double);
    S(T, T);
};

int main() {
    S{T{}, T{}}; // Работает ли вот так?
    S{1., 2.}; // а так?
}

Almost Always Auto, говорили они. Это повышает читабельность, говорили они:

auto x = {0}; // какой тут тип у x?
auto y{0}; // а у y?
// вы уверены? попробуйте другую версию вашего компилятора

Привет из древних времен:

struct S {
    std::vector a, b;
};

struct T {
    std::array a, b;
};

int main() {
    T t1{{1, 2}, {3, 4}};
    T t2{1, 2, 3, 4};
    T t3{1, 2};
    S s1{{1, 2}, {3, 4}};
    S s2{1, 2, 3, 4};
    S s3{1, 2};
}

Все понятно? Или ничего не ясно? Добро пожаловать под кат.

Disclaimers

1. Эта статья ознакомительная, не претендует на полноту и часто будет жертвовать корректностью в угоду понятности. С другой стороны, у читателя предполагается базовое знание C++.
2. Я пытался придумывать разумные переводы на русский для англоязычных терминов, но с некоторыми я потерпел полное фиаско. Синтаксические конструкции вида {...} я буду называть braced-init-lists, тип из стандартной библиотеки — std::initializer_list, а вид инициализации, когда мы пишем как-то так: int x{5} — это list-init, также известная как uniform initialization syntax, или универсальный синтаксис инициализации.

Attention!

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

Итак, braced-init-lists (штуки с фигурными скобками, {1, 2, 3}, uniform initialization syntax) и std::initializer_list — разные вещи! Они сильно связаны, между ними происходят всякие тонкие взаимодействия, но любое из них вполне может существовать без другого.

Но сначала — немного предыстории.

Unicorn initialization syntax

В C++98 (и его bugfix-update, C++03) существовало достаточно проблем и непоследовательностей, связанных с инициализацией. Вот некоторые из них:

• Из C пришел синтаксис инициализации переменных (в том числе, массивов и структур) с использованием фигурных скобок, но он не очень хорошо взаимодействовал с возможностями C++ (например, инициализация структур не была доступна для C++-классов)
• Часто хочется соорудить какой-нибудь контейнер (например, std::vector) из заранее известных элементов — в языке не было встроенной возможности для этого, а библиотечные решения (Boost.Assign) не отличались изящностью синтаксиса, были не бесплатны с точки зрения скорости работы и не слишком хорошо влияли на время компиляции
• При инициализации примитивных типов легко случайно потерять информацию при сужающем преобразовании (narrowing conversion) — например, случайно присвоить double в int
• Most vexing parse, которым любят пугать начинающих C++-ников.

Поэтому во время разработки C++11 родилась такая идея: давайте мы дадим возможность проинициализировать что угодно с помощью фигурных скобок:

• Для случаев, где это применимо в C, новый синтаксис будет работать так же, только лучше
• Сужающие преобразования при этом мы запретим
• А если мы пытаемся проинициализировать класс с конструкторами, то мы и конструктор сможем вызывать, с переданными параметрами

Pitfalls

Казалось бы, на этом можно и закончить: инициализация контейнеров должна получиться сама собой, ведь в C++11 появились еще и шаблоны с переменным числом параметров, так что если мы напишем variadic-конструктор… на самом деле, нет, так не получится:

• Такой конструктор должен быть шаблоном, что часто нежелательно
• Придется инстанцировать конструкторы со всевозможным числом параметров, что приведет к раздуванию кода и замедлению компиляции
• Эффективность инициализации, например, для std::vector-а будет все равно не идеальная

Для решения этих проблем придумали std::initializer_list — "магический класс", который представляет собой очень легкую обертку для массива элементов известного размера, а так же умеет конструироваться от braced-init-list-а.

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

Зачем же он нужен? Главным образом, чтобы пользовательские классы могли сказать: "я хочу конструироваться от braced-init-list-а элементов такого-то типа", и им не требовался бы для этого шаблонный конструктор.

(Кстати, к этому моменту должно стать понятно, что std::initializer_list и braced-init-list это разные понятия)

Теперь-то все хорошо? Мы просто добавим в наш контейнер конструктор вида vector(std::initializer_list) и все заработает? Почти.

Рассмотрим такую запись:

std::vector v{5};

Что имелось в виду, v(5) или v({5})? Другими словами, хотим ли мы сконструировать вектор из 5 элементов, или из одного элемента со значением 5?

Для решения этого конфликта разрешение перегрузок (overload resolution, выбор нужной функции по переданным аргументам) в случае list-initialization происходит в два этапа:

1. Сначала рассматриваются только конструкторы с единственным параметром типа std::initializer_list (это один из главных моментов, когда компилятор таки генерирует std::initializer_list по содержимому фигурных скобочек). Разрешение перегрузок происходит между ними.
2. Если ни один конструктор не подходит, то дальше все как обычно — разворачиваем braced-init-list в список аргументов и проводим разрешение перегрузок среди всех доступных конструкторов.

Отметим, что конструктор, который проиграл на первом этапе, вполне может подойти на втором. Это объясняет пример с избытком скобочек для инициализации вектора из начала статьи. Для понятности удалим один из вложенных шаблонов, а также заменим std::vector на свой класс:

template struct vec {
    vec(std::initializer_list);
};

int main() {
    vec v1{{{}}};
}

Под пункт 1 наш конструктор не подходит — {{{}}} не похож на std::initializer_list, потому что int нельзя проинициализировать с помощью {{}}. Однако {} — вполне себе zero-initialization, поэтому конструктор принимается на втором шаге.

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

struct S {
    S(std::initializer_list);
    S(double, double);
};

int main() {
    S{1., 2.};
}

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

Классы-агрегаты

Ну теперь-то все? Не совсем. Старый синтаксис инициализации структур, доставшийся нам от C, никуда не делся, и можно делать так:

struct A { int i, j; };
struct B { A a1, a2; };
int main() {
    B b1 = {{1, 2}, {3, 4}};
    B b2 = {1, 2, 3, 4}; // brace elision
    B b3 = {{1, 2}}; // clause omission
}

Как видим, при иницализации агрегатов (грубо говоря, C-подобных структур, не путать с POD, POD — это про другое) можно и пропускать вложенные скобочки, и выкидывать часть инициализаторов. Все это поведение было аккуратно перенесено в C++.

Казалось бы, какой бред, зачем это в современном языке? Давайте хотя бы предупреждения компилятора будем на это выводить, подумали разработчики GCC и clang, и были бы правы, не будь std::array классом-агрегатом, содержащим внутри себя массив. Таким образом, предупреждение про выкидывание вложенных скобок по понятным причинам срабатывает на вот таком невинном коде:

int main() {
    std::array a = {1,2,3};
}

Проблему эту GCC "решил" выключением соответствующего предупреждения в режиме -Wall, в clang-е же уже три года все по-прежнему.

Кстати, тот факт, что std::array — агрегат, не прихоть безумных авторов стандарта или ленивых разработчиков стандартных библиотек: достичь требуемой семантики этого класса просто невозможно средствами языка, не теряя в эффективности. Еще один привет от C и его странных массивов.

Возможно, большая проблема с классами-агрегатами — это не самое удачное взаимодействие с обобщенными функциями (в том числе) из стандартной библиотеки. На данный момент функции, которые конструируют объект из переданных параметров (например, vector::emplace_back или make_unique), вызывают обычную инициализацию, не "универсальную". Вызвано это тем, что использование list-initialization не позволяет никаким нормальным способом вызвать "обычный" контруктор вместо принимающего std::initializer_list (примерно та же проблема, что и с инициализацией в не-шаблонном коде, только тут пользователь не может обойти ее вызовом другого конструктора). Работа в этом направлении ведется, но пока мы имеем то, что имеем.

Almost Always Auto

Как же braced-init-list-ы ведут себя в сочетании с выводом типов? Что будет, если я напишу auto x = {0}; auto y = {1, 2};? Можно придумать несколько разумных стратегий:

1. Запретить такую инициализацию вообще (в самом деле, что программист хочет этим сказать?)
2. Вывести тип первой переменной как int, а второй вариант запретить
3. Сделать так, чтобы и x, и y имели тип std::initializer_lits

Последний вариант нравится мне меньше всего (мало кому в реальной жизни заводить локальные переменные типа std::initializer_list), но в стандарт С++11 попал именно он. Постепенно стало выясняться, что это вызывает проблемы у программистов (кто бы мог подумать), поэтому в стандарт добавили патч http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html, который реализует поведение №2… только в случае copy-list-initialization (auto x = {5}), а в случае direct-list-initialization (auto x{5}) оставляет все по-старому.

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

Промежуточные итоги

Хотя универсальный синтаксис инициализации и std::initializer_list — возможности языка, добавленные из благих и правильных побуждений, мне кажется, что из-за извечной необходимости в обратной совместимости и не всегда дальновидных решениях на ранних этапах вся ситуация вокруг них на данный момент излишне сложная, вымученная и не самая приятная для всех вовлеченных сторон — авторов стандарта, компиляторов, библиотек и прикладных разработчиков. Хотели как лучше, а получилось, как в известном комиксе:

В качестве примера возьмем, например, историю с [over.best.ics]/4.5, который сначала добавили в стандарт, потом, не подумав, удалили, как избыточный, а потом добавили обратно в измененном виде — как описание крайнего случая с пятью (!) условиями.

Тем не менее, возможность полезная и облегчающая жизнь, поэтому здесь я приведу небольшой и не претендующий на объективность список того, как не выстрелить себе в ногу:

1. Потратьте некоторое время на то, чтобы ознакомиться с тем, что на самом деле происходит (я рекомендую прочитать параграф стандарта — на удивление понятный и не слишком зависимый от остальных)
2. Не используйте std::initializer_list, кроме как в параметре конструктора
3. Да и в параметре конструктора используйте, только если вы понимаете, что происходит (если не уверены — сконструируйтесь лучше от вектора, пары итераторов или range-а)
4. Не используйте классы-агрегаты без крайней необходимости, напишите лучше конструктор, инициализирующий все поля
5. Не используйте braced-init-list в сочетании с auto
6. Прочитайте эту статью про то, что делать с пустыми списками инициализации (у меня руки чешутся ее перевести и запостить, может быть, вскоре займусь)
7. И, как я уже писал в самом начале, имейте в виду, что braced-init-list и std::initializer_list — это разные концепции, весьма хитро взаимодействующие друг с другом

Давайте помечтаем

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

Мне кажется, что переиспользовать фигурные скобки для создания std::initializer_list во время инициализации — ошибка дизайна языка. Я был бы очень рад, если бы вместо этого мы получили бы более явный и отдельный синтаксис (пусть и более уродливый, например, какие-нибудь странные скобки типа <$...$> или встроенный интринзик вроде std::of(...)). То есть инициализируем вектор как-то так: std::vector> x = std::of(std::of(1, 2), std::of(3, 4));

Что бы это дало? Новый способ инициализации (с защитой от most vexing parse и сужающих преобразований) оказался бы отвязан от std::initializer_list, не потребовалось бы вводить отдельный шаг для разрешения перегрузок, ушла бы проблема с конструктором vector или vector, новый синтаксис инициализации можно было бы использовать в обобщенном коде безо всяких проблем.

Конечно, недостатки у такого подхода довольно серьезные: более уродливый синтаксис в простейших случаях и уход от цели сделать синтаксис более унифицированным с инициализацией в стиле C (к такой унификации я отношусь довольно скептически, но это тема для отдельного разговора).

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

struct S {
   int a, b;
   S(...) = aggregate;
};

Заключение

Напоследок повторюсь еще раз, что я не претендую на 100% корректность или на истину в последней инстанции. Добро пожаловать в комментарии, если что-то осталось непонятным, или если есть что сказать по этой довольно специфической теме.

https://habrahabr.ru/post/330402/

• Типизацию для JS сейчас хотят почти на всех, крупных и не очень, проектах;
• Webpack — крайне простое, в использовании, и популярное, средство сборки
  проектов (да еще и import/export может)

{
  "name": "vuejs-webpack-ts",
  "version": "1.0.0",
  "description": "Sample project of Webpack+TS+Vue.js ",
  "main": "webpack.config.js",
  "scripts": {
    "start": "webpack-dev-server --hot --inline --history-api-fallback"
  },
  "repository": "https://github.com/StepanZharychev/vue-ts-webpack.git",
  "author": "Stepan Zharychev",
  "license": "ISC",
  "dependencies": {
    "babel-core": "^6.24.0",
    "babel-loader": "^6.4.1",
    "css-loader": "^0.27.3",
    "style-loader": "^0.16.0",
    "ts-loader": "^2.0.3",
    "typescript": "^2.2.1",
    "webpack": "^2.3.2",
    "vue": "^2.3.3",
    "vue-class-component": "^5.0.1",
    "vue-loader": "^12.1.0",
    "vue-property-decorator": "^5.0.1",
    "vue-template-compiler": "^2.3.3",
    "webpack-dev-server": "^2.4.2"
  }
}

module.exports = {
    entry: './app/init.ts',
    output: {
        filename: 'dist/bundle.js',
        path: __dirname,
        publicPath: '/static/'
    },
    module: {
        loaders: [
            {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                options: {
                    configFileName: 'tsconfig.json',
                    appendTsSuffixTo: [/\.vue$/]
                }
            },
            {
                test: /\.js/,
                loaders: ['babel-loader']
            },
            {
                test: /\.vue$/,
                loader: 'vue-loader',
                options: {
                    loaders: {
                        ts: 'ts-loader'
                    },
                    esModule: true
                }
            },
            {
                test: /\.css/,
                loaders: ['style-loader', 'css-loader']
            }
        ]
    },
    devServer: {
        compress: true,
        port: 8001
    },
    resolve: {
        extensions: ['.tsx', '.ts', '.js']
    },
    devtool: 'source-map'
}

import Vue from 'vue'
import Component from 'vue-class-component'
import HelloComponent from '../hello/hello.vue'

@Component({
    components: {
        hello: HelloComponent
    }
})
export default class MainComponent extends Vue {
    public message = 'Hello there, Vue works!'
}

import MainComponent from './components/main/main.vue'

declare module '*.vue' {
    import Vue from 'vue'
    export default Vue
}

import Vue from 'vue'
import MainComponent from './components/main/main.vue'

class AppCore {
    private instance: Vue;

    private init() {
        this.instance = new Vue({
            el: '#appContainer',
            render: h => h(MainComponent),
        })
    }

    constructor() {
        this.init();
    }
}

new AppCore();

https://habrahabr.ru/post/330400/

Возможности

• EC2;
• IAM;
• S3;
• RDS;
• Auto Scaling;
• SNS;
• SQS;
• Route53;
• CloudWatch;
• CloudFormation;
• Lambda.

$ awless create instance subnet=subnet-356d517f image=ami-70edb016 type=t2.micro

• фильтрация списков ресурсов по их свойствам и тегам;
• возможность использования произвольных алиасов для названий ресурсов;
• поддержка AWS userdata для provisioning (исполнения произвольных удалённых или локальных скриптов) на новых создаваемых экземплярах;
• логирование выполняемых операций (awless log);
• отмена ресурсов, созданных с помощью шаблонов (awless revert с идентификатором операции из журнала);
• простой SSH-доступ к экземплярам (awless ssh);
• просмотр данных о ресурсах в offline (требует предварительного запуска awless sync для локального хранения данных).

Установка

$ curl https://raw.githubusercontent.com/wallix/awless/master/getawless.sh | bash

$ go get -u github.com/wallix/awless

Примеры использования awless

• Список экземпляров с сортировкой по времени их работы:
  $ awless list instances --sort uptime
• Вывод пользователя по его имени или ID:
  $ awless show jsmith
• Создание экземпляра и provision в него из Gist:
  $ awless create instance name=my_machine image=ami-3f1bd150 keypair={keypair.name} \
subnet={main.subnet} securitygroup={securitygroup} \
userdata=https://gist.github.com/simcap/360dffae4c6d76ab0e89621dd824a244
• Определение политики для пользователя:
  $ awless attach policy user=jsmith arn=arn:aws:iam::aws:policy/AmazonEC2FullAccess
• Загрузка локального файла в S3:
  $ awless create s3object bucket=my-existing-bucket file=./todolist.txt
• Создание экземпляра и вход в него по SSH (по локальному ключу):
  $ awless run repo:instance_ssh
Please specify (Ctrl+C to quit):
instance.name ? my-new-instance-name
instance.subnet ? @my-existing-subnet
instance.vpc ? @my-existing-vpc
keypair.name ? my-new-keyname
$ awless ssh my-new-instance-name

Заключение

https://habrahabr.ru/post/330398/

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

Сейчас мы основательно обновляем более масштабный блок API — по управлению данными (Data API). Типовой кейс c его использованием — это, например, самостоятельная интеграция телефонии с CRM с расширенными возможностями контроля передаваемых между системами данных.

1. Покажу, как мы сами реализовали готовую интеграцию виртуальной АТС с retailCRM на основе новой версии API. Эта же логика может быть легко перенесена в любую нужную интеграцию с вашей системой (оговорюсь, что это не инструкция, а именно фундамент для реализации интеграций других АТС с retailCRM или других CRM с телефонией UIS).
2. Расскажу о ключевых функциях по управлению данными, которые мы зашиваем в обновленный API и на которые вы можете опираться.

Пример базовой интеграции телефонии с CRM

Давайте посмотрим, как сделать интеграцию телефонии с CRM с поддержкой базового функционала на примере retailCRM. При этом оговоримся, что под базовым функционалом мы понимаем:

• Всплывающую карточку контакта
• Фиксацию потерянных звонков в CRM
• Исходящие звонки из CRM
• Прослушивание записей разговора в CRM-системе

Конкретно в схеме интеграции UIS с retailCRM мы реализовали еще несколько полезных функций (например, синхронизацию статусов сотрудников в сервисах и т.п.). Однако, думается, что они все-таки выходят за рамки базового функционала подобных интеграций, так что подробно на них в этом материале я останавливаться не буду.

Используемые инструменты

• Инструменты UIS: Data API; Call API; блок уведомлений
• API retailCRM

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

Общая схема работы интеграции

Кликайте на схему, чтобы посмотреть в полном размере.

Активация телефонии в retailCRM

Телефония в retailCRM активируется запросом к /api/v4/telephony/setting/{code}/edit. Cреди прочих, в запросе указываются следующие параметры:

• makeCallUrl — URL, на который retailCRM будет отправлять запросы для генерации исходящих звонков.
• changeUserStatusUrl — URL, на который retailCRM будет отправлять оповещения об изменении статуса сотрудника.

Обработка звонка

Всплывающая карточка контакта

Всплывающая карточка контакта в retailCRM осуществляется простым запросом к API /api/v4/telephony/call/event, триггером будет сработавшее уведомление на событие «Ожидание ответа», когда у сотрудника уже звонит телефон.

Пропущенные звонки

Пропущен звонок или успешен, можно определить по параметру is_lost в уведомлении о завершении звонка. И если звонок пропущен, то статус звонка будет загружен запросом API /api/v4/telephony/calls/upload, поля которого можно заполнить параметрами из уведомления.

Успешные звонки и сохранение их записей в CRM

Чтобы загрузить успешный звонок в retailCRM, предварительно нужно получить дополнительную информацию по этому вызову, с чем и поможет справиться Data API.

Немного о компоновке запроса:

• В поле params можно указать интересующие параметры, чтобы в ответе пришли только они
• В поле filter можно указать наименование тех полей, которые вас интересуют

{
  "jsonrpc": "2.0",
  "id": 1122,
  "method": "get.call_legs_report",
  "date_from": "2017-06-01 14:34:00",
  "date_till": "2017-06-01 14:36:52",
  "params": {
    "access_token": "N2dw2Rf33fn23fknkmdfeJmcP",
    "filter": {
        "filters": [
            {
                "field": "call_session_id",
                "operator": "=",
                "value": 31451224
            },
{
                "field": "is_talked",
                "operator": "=",
                "value": true
            }
        ],
        "condition": "and"
    },
    "fields": [
      "id",
    "call_seesion_id",
    "call_records",
    "release_cause_code",
    "direction",
    "start_time",
    "employee_id",
    "called_phone_number",
    "contact_phone_number",
    "total_duration",
    "duration"
    ]
  }
}

Полученную информацию необходимо загрузить в retailCRM запросом API /api/v4/telephony/calls/upload. Если требуется расширить набор загружаемых параметров, их можно взять из параметров уведомления «Завершение звонка».

Исходящий звонок из retailCRM по клику

При попытке сотрудника позвонить по клику на номер контакта из интерфейса CRM, retailCRM будет присылать вам запрос на URL, указанный при активации телефонии. Теперь необходимо этот запрос перенаправить в сервис телефонии для совершения звонка. Для этого можно использовать наш Call API.

{
  "jsonrpc": "2.0",
  "method": "start.employee_call",
  "id": "number",
  "params": {
    "access_token": "N2dw2Rf33fn23fknkmdfeJmcP",
    "first_call": "employee",
    "early_switching": true,
    "switch_at_once": true,
    "show_virtual_phone_number": false,
    "virtual_phone_number": "88002000600",
    "direction": "out",
    "contact": "72131231111",
    "employee": {
      "id": 13421
    }
  }
}

Cинхронизация статусов сотрудников в retailCRM и UIS

При получении уведомления о смене статуса сотрудника от retailCRM, необходимо сгенерировать запрос к Data API, чтобы изменить настройки этого сотрудника в соответствии с новым статусом.

{
  "jsonrpc": "2.0",
  "id": "number",
  "method": "update.employees",
  "params": {
    "access_token": "N2dw2Rf33fn23fknkmdfeJmcP",
    "id": 13421,
    "calls_available": false
  }
}

Нюансы управления данными через API UIS

А сейчас, как обещал, расскажу о ключевых функциях по контролю передаваемых между телефонией и CRM данных, которые мы предусмотрели в обновленном API UIS.

• Контролируемая защита данных. Запросы к API осуществляются по ключам с разграниченными правами доступа. Ключи API создаются под конкретного пользователя и обладают набором прав, аналогичным полномочиям пользователя в Личном кабинете UIS. Например, если у него есть только доступ на просмотр сотрудников, и редактировать их профили в интерфейсе UIS он не может, то не сможет сделать это и через API.
• Журнал-лог запросов в личном кабинете. Еще один важный шаг к повышению прозрачности всего процесса по работе с API.
• Гибкие условия фильтрации для получения данных. Задавать условия можно самостоятельно.
• Передача массивов в запросах для получения списка конкретных сущностей (сотрудников, звонков и пр.). Раньше, чтобы получить, например, профили сотрудников Коли, Васи и Пети, нужно было делать три запроса к API, а теперь это один запрос, в котором указаны ID нужных сотрудников.
• Частичное обновление данных. Отправлять всю простыню свойств обновляемой сущности в запросе на обновление не нужно — достаточно отправить только те поля, которые реально изменились.
• Индивидуальное определение получаемых полей. В запросе на получение данных задаются только интересующие вас параметры. Профит — фильтрация хлама в виде ненужной информации.
• Продуманная система ошибок. Это для того, чтобы упростить диагностику проблем.

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

P.S. Кстати говоря, если вы представитель CRM-системы, которой не хватает интеграции с телефонией, то тоже буду рад сотрудничать. Вы поможете нам проработать схему готовых партнерских интеграций в один клик из Личного кабинета UIS, а мы вам — сделать интеграцию наших сервисов для ваших пользователей.

https://habrahabr.ru/post/330396/

В предыдущей статье Нативные ECMAScript модули — первый обзор я рассказал историю JavaScript модулей и текущее состояние дел реализации нативных EcmaScript модулей.

Сейчас доступны две реализации, которые мы попробуем сравнить с бандлерами модулей.

Основные мысли:

1. выполнять скрипт или загружать внешний файл и выполнять как модуль, используя

https://habrahabr.ru/post/329918/

Введение

Проблемы наследования

class FunctionParser
{
friend class FunctionParsersManager;
public:
  FunctionParser(....): ....{};

  virtual void parse(....) = 0;
  void funcParse(....);
  bool isInZones(....);
protected:
  generic_string _id;
  generic_string _displayName;
  generic_string _commentExpr;
  generic_string _functionExpr;
  std::vector _functionNameExprArray;
  std::vector _classNameExprArray;
  void getCommentZones(....);
  void getInvertZones(....);
  generic_string parseSubLevel(....);
};

std::vector _parsers;

FunctionParsersManager::~FunctionParsersManager()
{
  for (size_t i = 0, len = _parsers.size(); i < len; ++i)
  {
    delete _parsers[i]; // <=
  }

  if (_pXmlFuncListDoc)
    delete _pXmlFuncListDoc;
}

class FunctionZoneParser : public FunctionParser
{
public:
  FunctionZoneParser(....): FunctionParser(....) {};

  void parse(....);
  
protected:
  void classParse(....);

private:
  generic_string _rangeExpr;
  generic_string _openSymbole;
  generic_string _closeSymbole;

  size_t getBodyClosePos(....);
};

class FunctionUnitParser : public FunctionParser
{
public:
  FunctionUnitParser(....): FunctionParser(....) {}

  void parse(....);
};

class FunctionMixParser : public FunctionZoneParser
{
public:
  FunctionMixParser(....): FunctionZoneParser(....), ....{};

  ~FunctionMixParser()
  {
    delete _funcUnitPaser;
  }

  void parse(....);

private:
  FunctionUnitParser* _funcUnitPaser = nullptr;
};

class Window
{
  ....
  virtual void display(bool toShow = true) const
  {
    ::ShowWindow(_hSelf, toShow ? SW_SHOW : SW_HIDE);
  }

  virtual void redraw(bool forceUpdate = false) const
  {
    ::InvalidateRect(_hSelf, nullptr, TRUE);
    if (forceUpdate)
      ::UpdateWindow(_hSelf);
  }
  ....
}

class SplitterContainer : public Window
{
  ....
  virtual void display(bool toShow = true) const; // <= good

  virtual void redraw() const;                    // <= error
  ....
}

• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'UserDefineDialog' and base class 'StaticDialog'. userdefinedialog.h 332
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'FindReplaceDlg' and base class 'StaticDialog'. findreplacedlg.h 245
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'GoToLineDlg' and base class 'StaticDialog'. gotolinedlg.h 45
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'FindCharsInRangeDlg' and base class 'StaticDialog'. findcharsinrange.h 52
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'ColumnEditorDlg' and base class 'StaticDialog'. columneditor.h 45
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'WordStyleDlg' and base class 'StaticDialog'. wordstyledlg.h 77
• V762 It is possible a virtual function was overridden incorrectly. See first argument of function 'redraw' in derived class 'WordStyleDlg' and base class 'Window'. wordstyledlg.h 99
• V762 It is possible a virtual function was overridden incorrectly. See third argument of function 'create' in derived class 'PluginsAdminDlg' and base class 'StaticDialog'. pluginsadmin.h 107

Утечки памяти

bool ProjectPanel::openWorkSpace(const TCHAR *projectFileName)
{
  TiXmlDocument *pXmlDocProject = new TiXmlDocument(....);
  bool loadOkay = pXmlDocProject->LoadFile();
  if (!loadOkay)
    return false;        // <=

  TiXmlNode *root = pXmlDocProject->FirstChild(TEXT("Note...."));
  if (!root) 
    return false;        // <=

  TiXmlNode *childNode = root->FirstChildElement(TEXT("Pr...."));
  if (!childNode)
    return false;        // <=

  if (!::PathFileExists(projectFileName))
    return false;        // <=

  ....

  delete pXmlDocProject; // <= free pointer
  return loadOkay;
}

bool FindReplaceDlg::processReplace(....)
{
  ....
  TCHAR *pTextFind = new TCHAR[stringSizeFind + 1];
  TCHAR *pTextReplace = new TCHAR[stringSizeReplace + 1];
  lstrcpy(pTextFind, txt2find);
  lstrcpy(pTextReplace, txt2replace);
  ....
}

1. Буфер pTextFind не очищается и вообще не используется в функции. Для замены используется исходный буфер txt2find.
2. Буфер pTextReplace в дальнейшем используется, но память тоже не освобождается.

Ошибки с указателями

LRESULT CALLBACK ScintillaEditView::scintillaStatic_Proc(....)
{
  ScintillaEditView *pScint = (ScintillaEditView *)(....);

  if (Message == WM_MOUSEWHEEL || Message == WM_MOUSEHWHEEL)
  {
    ....
    if (isSynpnatic || makeTouchPadCompetible)
      return (pScint->scintillaNew_Proc(....); // <=
    ....
  }
  if (pScint)
    return (pScint->scintillaNew_Proc(....));
  else
    return ::DefWindowProc(hwnd, Message, wParam, lParam);
}

Lang * getLangFromID(LangType langID) const
{
  for (int i = 0 ; i < _nbLang ; ++i)
  {
    if ((_langList[i]->_langID == langID) || (!_langList[i]))
      return _langList[i];
  }
  return nullptr;
}

Lang * getLangFromID(LangType langID) const
{
  for (int i = 0 ; i < _nbLang ; ++i)
  {
    if ( !_langList[i] && _langList[i]->_langID == langID )
      return _langList[i];
  }
  return nullptr;
}

Разные ошибки

bool VerifySignedLibrary(...., const wstring& cert_subject, ....)
{
  wstring subject;
  ....
  if ( status && !cert_subject.empty() && subject != subject)
  {
    status = false;
    OutputDebugString(
      TEXT("VerifyLibrary: Invalid certificate subject\n"));
  }
  ....
}

subject != subject

if ( status && !cert_subject.empty() && cert_subject != subject)
{
  ....
}

TCHAR GetASCII(WPARAM wParam, LPARAM lParam)
{
  int returnvalue;
  TCHAR mbuffer[100];
  int result;
  BYTE keys[256];
  WORD dwReturnedValue;
  GetKeyboardState(keys);
  result = ToAscii(static_cast(wParam),
    (lParam >> 16) && 0xff, keys, &dwReturnedValue, 0); // <=
  returnvalue = (TCHAR) dwReturnedValue;
  if(returnvalue < 0){returnvalue = 0;}
  wsprintf(mbuffer, TEXT("return value = %d"), returnvalue);
  if(result!=1){returnvalue = 0;}
  return (TCHAR)returnvalue;
}

(lParam >> 16) & 0xff

TCHAR* FileDialog::doOpenSingleFileDlg()
{
  ....
  try {
    fn = ::GetOpenFileName(&_ofn)?_fileName:NULL;
    
    if (params->getNppGUI()._openSaveDir == dir_last)
    {
      ::GetCurrentDirectory(MAX_PATH, dir);
      params->setWorkingDir(dir);
    }
  } catch(std::exception e) {                             // <=
    ::MessageBoxA(NULL, e.what(), "Exception", MB_OK);
  } catch(...) {
    ::MessageBox(NULL, TEXT("....!!!"), TEXT(""), MB_OK);
  }

  ::SetCurrentDirectory(dir); 

  return (fn);
}

LRESULT CALLBACK GridProc(HWND hWnd, UINT message,
                          WPARAM wParam, LPARAM lParam)
{
  ....
  case WM_CREATE:
    lpcs = &cs;
    lpcs = (LPCREATESTRUCT)lParam;
  ....
}

typedef std::basic_string generic_string;

generic_string TreeView::getItemDisplayName(....) const
{
  if (not Item2Set)
    return false;                     // <=
  TCHAR textBuffer[MAX_PATH];
  TVITEM tvItem;
  tvItem.hItem = Item2Set;
  tvItem.mask = TVIF_TEXT;
  tvItem.pszText = textBuffer;
  tvItem.cchTextMax = MAX_PATH;
  SendMessage(...., reinterpret_cast(&tvItem));
  return tvItem.pszText;
}

Чистка кода

void Notepad_plus::wsTabConvert(spaceTab whichWay)
{
  ....
  char * source = new char[docLength];
  if (source == NULL)
    return;
  ....
}

bool Notepad_plus::doBlockComment(comment_mode currCommentMode)
{
  ....
  if ((!commentLineSymbol) ||       // <=
      (!commentLineSymbol[0]) ||
       (commentLineSymbol == NULL)) // <= WTF?
  { .... }
  ....
}

• V713 The pointer commentLineSymbol was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 3928
• V713 The pointer commentStart was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 3931
• V713 The pointer commentEnd was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 3931
• V713 The pointer commentStart was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 4228
• V713 The pointer commentEnd was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 4228
• V713 The pointer commentLineSymbol was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 4229
• V713 The pointer commentStart was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 6554
• V713 The pointer commentEnd was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 6554
• V713 The pointer commentLineSymbol was utilized in the logical expression before it was verified against nullptr in the same logical expression. notepad_plus.cpp 6555

INT_PTR CALLBACK PluginsAdminDlg::run_dlgProc(UINT message, ....)
{
  switch (message)
  {
    case WM_INITDIALOG :
    {
      return TRUE;
    }
    ....
    case IDC_PLUGINADM_RESEARCH_NEXT:
      searchInPlugins(true);
      return true;

    case IDC_PLUGINADM_INSTALL:
      installPlugins();
      return true;
    ....
  }
  ....
}

void Notepad_plus::notifyBufferChanged(Buffer * buffer, int mask)
{
  // To avoid to crash while MS-DOS style is set as default 
  // language,
  // Checking the validity of current instance is necessary.
  if (!this) return;
  ....
}

• V704 'this && type == DOCUMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 505
• V704 'this && type == ELEMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 506
• V704 'this && type == COMMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 507
• V704 'this && type == UNKNOWN' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 508
• V704 'this && type == TEXT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 509
• V704 'this && type == DECLARATION' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxmla.h 510
• V704 'this && type == DOCUMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 505
• V704 'this && type == ELEMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 506
• V704 'this && type == COMMENT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 507
• V704 'this && type == UNKNOWN' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 508
• V704 'this && type == TEXT' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 509
• V704 'this && type == DECLARATION' expression should be avoided: 'this' pointer can never be NULL on newer compilers. tinyxml.h 510
• V704 'this' expression in conditional statements should be avoided — this expression is always true on newer compilers, because 'this' pointer can never be NULL. nppbigswitch.cpp 119

Заключение

https://habrahabr.ru/post/330394/

Создание эффекта погружения

Креативная подача и взаимодействие с пользователями

Переосмысление и доработка

https://habrahabr.ru/post/330388/

• На что обратить внимание при выборе услуги облачного PCI DSS хостинга
• Знакомство с vCloud Director 8.10: обзор функциональных изменений
• vCloud Director 8.10: для чего нужны Virtual Machine Affinity Rules
• Тонкости импорта vApp в vCloud Director
• vCloud Director: как создать безопасное подключение между двумя организациями
• vCloud Availability: глубокое погружение в репликацию трафика

https://habrahabr.ru/post/330336/

• Аутентификация, авторизация и учет (AAA) — RADIUS или TACACS+
• Интервью с Максимом Хижинским — C++ разработчиком системы DPI
• Зачем интернет-провайдеру аналитика и статистика
• Нулевой рейтинг (Zero-rating) и как его правильно применить
• Профессор Гильермо Франсия о кибербезопасности национальной инфраструктуры
• Преимущества использования расширенной функциональности СКАТ DPI

https://habrahabr.ru/post/330306/

Какая ваша любимая база данных?

	PostgreSQL
	MySQL
	Tarantool
	CockroachDB
	ClickHouse
	MongoDB

Проголосовало 64 человека. Воздержалось 13 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330386/

Корявая документация.

Невозможность редактировать исходный код прошивки для отладочной платы.

Бардак в заголовочных файлах.

Среда, компилятор и их, кхм… особенности

Напоследок

По существу ли замечания автора?

	Автор нуб, ничего из описанного вообще не является проблемой
	Согласен с автором, могли бы и получше сделать
	Я вообще мимо проходил, но тема интересная
	Не пиши больше, пожалуйста

Проголосовало 39 человек. Воздержалось 13 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330384/

https://habrahabr.ru/post/330378/

HP Smart Array P212

Давайте посмотрим на то как настройки кэширования влияют на скорость.

Про SAS диски

HP Smart Array P212 + SSD

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

HP Smart Array B110i

1 — SATA Legacy

2 — SATA AHCI

3 — SATA RAID

Про надежность и сохранность данных

ИТОГО

П.С.

https://habrahabr.ru/post/330286/