ETL и 1С. Извлечение данных

Первый взгляд

Если вы, как ETL-специалист столкнулись с необходимостью получать данные из 1С, то это первое, что вы можете увидеть, попытавшись разобраться со структурой БД (это из случае MSSQL, для других СУБД картинка аналогичная):



Бизнес-смысл в наименованиях таблиц и полей отсутствует, внешних ключей нет.

Пару ласковых о самой 1С. Реальные таблицы СУБД в ней скрыты за объектами, которые видит разработчик, который часто не догадывается о реальной структуре базы. Да… И весь код на русском языке. Кроме того, есть перечисления, строковые представления которых с помощью SQL получить практически невозможно. Об этом подробнее здесь.

Есть случаи, когда БД нет (и 1С в файловой версии), но это, разумеется ориентирует вас на интеграцию без использования средств СУБД.

Однако, не стоит впадать в отчаяние, поскольку все не так плохо, как кажется.

Внимательный взгляд

Для захвата данных из 1С у вас есть 2 пути:

Реализация «высокоуровневого» интерфейса

Вы можете воспользоваться файловыми выгрузками, web/json сервисами и прочими возможностями 1С, которые окажутся совместимы с вашим ETL.

+

1. Вам не придется лезть в 1С. Все, что на стороне 1С должны сделать 1Сники
2. Вы никак не нарушаете лицензионную политику 1С

—

1. Появляется еще один источник для ошибок в виде дополнительных выгрузок-загрузок,
   расписаний, роботизации
2. Это будет работать существенно медленнее из-за особенностей интерфейсов 1С
3. При любых изменениях в захватываемых данных, вам придется вносить изменения в выгрузки (но это можно обойти настроечной системой)
4. Это вызовет больше ошибок в целостности данных, чем работа напрямую с СУБД

Реализация на СУБД

+

1. Работает быстрее
2. Позволяет гарантировать полноту данных в хранилище при правильном подходе

—

1. Нарушает лицензионное соглашение с 1С

Итак, взвесив за и против, вы решаете строить интеграцию через СУБД, ну или хотя бы
подумать, как вы будете это делать дальше.

Data mapping

Для того, чтобы связать бизнес-данные, как их понимают на стороне 1С с реальными таблицами БД, вам потребуется выполнить немного магии в самой 1С, а именно получить описание метаданных 1С в пригодном для использования виде (в связи бизнес-объектов и таблиц).
Опять же есть, как минимум, целых 3 подхода:

1. Используя com-соединение, web/json сервис получить таблицу соответствия из 1С
2. Сделать то же самое на стороне 1С, сформировав таблицу метаданных
3. Разобрать бинарный файл, который хранится в той же БД

3-й путь мне кажется несколько рискованным в силу того, что 1С имеет привычку вносить изменения в свои внутренности без предупреждения. И, при этом, довольно сложным.
Выбор между 1 и 2 не столь очевиден, но на мой вкус использовать заранее сформированную таблицу гораздо удобнее, и надежнее в ежедневном использовании и нет нужды задействовать что-то, кроме чистого SQL.

Хранить и поддерживать актуальность таблицы удобнее при помощи 1С, обновляя после каждого обновления конфигурации. При этом, ETL может пользоваться View, который покажет данные уже в более удобоваримой форме.

Подготовка таблицы метаданных

Создать в 1С объект, который содержит метаданные конфигурации (к сожалению, скриптом это не сделать, но можно отдать инструкцию 1С-нику)

РегистрСведений.СтруктураКонфигурации
Поля:
ИмяТаблицыХранения
ИмяТаблицы
СинонимТаблицы
Назначение
ИмяПоляХранения
СинонимПоля

Все строки 150 символов



Получается денормализованно, но довольно удобно и просто.

Код 1С для заполнения структуры:

СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных(,истина);
ЗаписиСтруктура = РегистрыСведений.СтруктураКонфигурации.СоздатьНаборЗаписей();
Для каждого СтрокаСтруктуры Из СтруктураБД Цикл
    Для каждого СтрокаПолей Из СтрокаСтруктуры.Поля Цикл
	Запись 					= ЗаписиСтруктура.Добавить();
	Запись.ИмяТаблицыХранения 	= СтрокаСтруктуры.ИмяТаблицыХранения;
	Запись.ИмяТаблицы 		= СтрокаСтруктуры.ИмяТаблицы;
	Запись.СинонимТаблицы 	= Метаданные.НайтиПоПолномуИмени(СтрокаСтруктуры.Метаданные);
	Запись.Назначение 			= СтрокаСтруктуры.Назначение;
	Запись.ИмяПоляХранения  	= СтрокаПолей.ИмяПоляХранения;
	Запись.СинонимПоля 			= Метаданные.НайтиПоПолномуИмени(СтрокаПолей.Метаданные);
	КонецЦикла;
Конеццикла;
ЗаписиСтруктура.Записать(истина);

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

Таблицу можно просматривать как в режиме клиента, так и со стороны SQL, зная их имена.

 SELECT * FROM _InfoReg27083 ORDER BY  _Fld27085

(_InfoReg27083 — имя, которое 1С дала таблице регистра со структурой, _Fld27085 — имя поля с именем таблицы хранения)

Можно сделать View, чтобы было удобнее.

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

А здесь про то, какие есть типы таблиц, и зачем они нужны (нужен доступ к ИТС 1C).

Следующий шаг — составить карту данных и описание трансформации.

Field	Field1C	Transformation	...
_Fld15704	Документ.РеализацияТоваровУслуг.Вес	Check >=0, round(10,2),…	...

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

Захват изменений данных

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

Однако, есть и другие способы:

1. Использовать версии объектов
2. Использовать план обмена

Использовать версии объектов

Для объектов «ссылочного» типа 1С поддерживает версии. Номер версии объекта записывается в бинарное поле _version, аккуратно обновляющееся при каждом обновлении записи. На MSSQL, например, это поле типа timestamp. Версии поддерживаются для объектов типа «Документ»,«Справочник»,«Бизнес-процесс»,«Задача»,«План счетов»,«План видов характеристик», «Константы». Использовать версию довольно просто, сохранив у себя в staging area значение последней версии для объекта, и при следующем обновлении выбрав объекты, большие по значению поля версии. Вместе с «основным» объектом нужно не забыть забрать его табличные части (см. Назначение — «Табличная часть») в структуре (поле вида _DocumentXXX_IDRRef или _ReferenceXXX_IDRRef — ссылка на основную таблицу).

Использовать план обмена

Для не ссылочных типов такой подход не годится, но можно воспользоваться объектом «план обмена». В таблице структуры их назначение = 'РегистрацияИзменений'. Для каждого объекта конфигурации создается отдельная таблица плана обмена.

На уровне БД это таблица, вот такой структуры:

_NodeTRef, — идентификатор типа «узла» плана обмена. Он нам не очень интересен
_NodeRRef, — идентификатор узла плана обмена
_MessageNo, — номер сообщения

Дальше идут поля ключа «основной» таблицы. Они различаются в зависимости от типа таблицы, с которой связана таблица плана обмена:

_IDRRef — в данном случае ID справочника или документа
может быть вот так вот:
_RecorderTRef
_RecorderRRef

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

Для того, чтобы такая таблица регистрации изменений существовала, нужно включить в конфигураторе 1С нужный нам объект в план обмена. Кроме того, нужен быть создан узел плана обмена, идентификатор (_IDRRef) которого наим нужно будет использовать.

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

Как забирать данные через план обмена:

Для начала мы пишем update к плану обмена, где ставим произвольный _MessageNO (лучше всегда 1).

Например

UPDATE _DocumentChangeRec18901 set _MessageNO = 1 WHERE _NodeRRef = @_NodeRRef

Далее выбираем данные из таблицы данных, связав ее по ключу с таблицей плана обмена

SELECT [fieldslist] FROM _Document18891 inner join _DocumentChangeRec18901 ON _Document18891._IDRRef = _DocumentChangeRec18901._IDRRef and _MessageNO = 1 AND _NodeRRef = @_NodeRRef

И подтверждаем забор изменений, удалив записи таблицы изменений

DELETE FROM _DocumentChangeRec18901 WHERE _MessageNO = 1 AND _NodeRRef = @_NodeRRef

Итого: Мы научились читать на стороне ETL метаданные 1С, научились выполнять захват данных. Остальные шаги процесса ETL достаточно хорошо известны. Например, можно почитать здесь.

https://habrahabr.ru/post/334798/

В этой серии статей я расскажу о внутреннем устройстве Android — о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Немного фактов

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

Android — свободный и открытый проект. Большинство исходного кода (который можно найти на https://source.android.com) распространяется под свободной лицензией Apache 2.0.

Компания Android Inc. была основана в 2003 году и в 2005 году куплена Google. Публичная бета Android вышла в 2007 году, а первая стабильная версия — в 2008, с тех пор мажорные релизы выходят примерно раз в год. Последняя на момент написания стабильная версия Android — 7.1.2 Nougat.

Android is Linux

По поводу такой формулировки было много споров, так что сразу поясню, что именно я имею в виду под этой фразой: Android основан на ядре Linux, но значительно отличается от большинства других Linux-систем.

Среди исходной команды разработчиков Android был Robert Love, один из самых известных разработчиков ядра Linux, да и сейчас компания Google остаётся одним из самых активных контрибьюторов в ядро, поэтому неудивительно, что Android построен на основе Linux.

Как и в других Linux-системах, ядро Linux обеспечивает такие низкоуровневые вещи, как управление памятью, защиту данных, поддержку мультипроцессности и многопоточности. Но — за несколькими исключениями — вы не найдёте в Android других привычных компонент GNU/Linux-систем: здесь нет ничего от проекта GNU, не используется X.Org, ни даже systemd. Все эти компоненты заменены аналогами, более приспособленными для использования в условиях ограниченной памяти, низкой скорости процессора и минимального потребления энергии — таким образом, Android больше похож на встраиваемую (embedded) Linux-систему, чем на GNU/Linux.

Другая причина того, что в Android не используется софт от GNU — известная политика «no GPL in userspace»:

We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL 2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.

Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and we don’t believe it’s possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don’t believe it is our place to force them to do so. Using LGPL libraries would often force them to do just that.

Само ядро Linux в Android тоже немного модифицировано: было добавлено несколько небольших компонент, в том числе ashmem (anonymous shared memory), Binder driver (часть большого и важного фреймворка Binder, о котором я расскажу ниже), wakelocks (управление спящим режимом) и low memory killer. Исходно они представляли собой патчи к ядру, но их код был довольно быстро добавлен назад в upstream-ядро. Тем не менее, вы не найдёте их в «обычном линуксе»: большинство других дистрибутивов отключают эти компоненты при сборке.

В качестве libc (стандартной библиотеки языка C) в Android используется не GNU C library (glibc), а собственная минималистичная реализация под названием bionic, оптимизированная для встраиваемых (embedded) систем — она значительно быстрее, меньше и менее требовательна к памяти, чем glibc, которая обросла множеством слоёв совместимости.

В Android есть оболочка командной строки (shell) и множество стандартных для Unix-подобных систем команд/программ. Во встраиваемых системах для этого обычно используется пакет Busybox, реализующий функциональность многих команд в одном исполняемом файле; в Android используется его аналог под названием Toybox. Как и в «обычных» дистрибутивах Linux (и в отличие от встраиваемых систем), основным способом взаимодействия с системой является графический интерфейс, а не командная строка. Тем не менее, «добраться» до командной строки очень просто — достаточно запустить приложение-эмулятор терминала. По умолчанию он обычно не установлен, но его легко, например, скачать из Play Store (Terminal Emulator for Android, Material Terminal, Termux). Во многих «продвинутых» дистрибутивах Android — таких, как LineageOS (бывший CyanogenMod) — эмулятор терминала предустановлен.

Второй вариант — подключиться к Android-устройству с компьютера через Android Debug Bridge (adb). Это очень похоже на подключение через SSH:

user@desktop-linux$ adb shell
android$ uname
Linux

Из других знакомых компонент в Android используются библиотека FreeType (для отображения текста), графические API OpenGL ES, EGL и Vulkan, а также легковесная СУБД SQLite.

Кроме того, раньше для реализации WebView использовался браузерный движок WebKit, но начиная с версии 7.0 вместо этого используется установленное приложение Chrome (или другое; список приложений, которым разрешено выступать в качестве WebView provider, конфигурируется на этапе компиляции системы). Внутри себя Chrome тоже использует основанный на WebKit движок Blink, но в отличие от системной библиотеки, Chrome обновляется через Play Store — таким образом, все приложения, использующие WebView, автоматически получают последние улучшения и исправления уязвимостей.

It’s all about apps

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

Основная единица в Unix-подобных системах — процесс. И низкоуровневые системные сервисы, и отдельные команды в shell’е, и графические приложения — это процессы. В большинстве случаев процесс представляет собой чёрный ящик для остальной системы — другие компоненты системы не знают и не заботятся о его состоянии. Процесс начинает выполняться с вызова функции main() (на самом деле _start), и дальше реализует какую-то свою логику, взаимодействуя с остальной системой через системные вызовы и простейшее межпроцессное общение (IPC).

Поскольку Android тоже Unix-подобен, всё это верно и для него, но в то время как низкоуровневые части — на уровне Unix — оперируют понятием процесса, на более высоком уровне — уровне Android Framework — основной единицей является приложение. Приложение — не чёрный ящик: оно состоит из отдельных компонент, хорошо известных остальной системе.

У приложений Android нет функции main(), нет одной точки входа. Вообще, Android максимально абстрагирует понятие приложение запущено как от пользователя, так и от разработчика. Конечно, процесс приложения нужно запускать и останавливать, но Android делает это автоматически (подробнее я расскажу об этом в следующих статьях). Разработчику предлагается реализовать несколько отдельных компонент, каждая из который обладает своим собственным жизненным циклом.

In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them… so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn’t running.

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

Этот механизм — Binder.

Binder

Binder — это платформа для быстрого, удобного и объектно-ориентированного межпроцессного взаимодействия.

Разработка Binder началась в Be Inc. (для BeOS), затем он был портирован на Linux и открыт. Основной разработчик Binder, Dianne Hackborn, была и остаётся одним из основных разработчиков Android. За время разработки Android Binder был полностью переписан.

Binder работает не поверх System V IPC (которое даже не поддерживается в bionic), а использует свой небольшой модуль ядра, взаимодействие с которым из userspace происходит через через системные вызовы (в основном ioctl) на «виртуальном устройстве» /dev/binder. Со стороны userspace низкоуровневая работа с Binder, в том числе взаимодействие с /dev/binder и marshalling/unmarshalling данных, реализована в библиотеке libbinder.

Низкоуровневые части Binder оперируют в терминах объектов, которые могут пересылаться между процессами. При этом используется подсчёт ссылок (reference-counting) для автоматического освобождения неиспользуемых общих ресурсов и уведомление о завершении удалённого процесса (link-to-death) для освобождения ресурсов внутри процесса.

Высокоуровневые части Binder работают в терминах интерфейсов, сервисов и прокси-объектов. Описание интерфейса, предоставляемого программой другим программам, записывается на специальном языке AIDL (Android Interface Definition Language), внешне очень похожем на объявление интерфейсов в Java. По этому описанию автоматически генерируется настоящий Java-интерфейс, который потом может использоваться и клиентами, и самим сервисом. Кроме того, по .aidl-файлу автоматически генерируются два специальных класса: Proxy (для использования со стороны клиента) и Stub (со стороны сервиса), реализующие этот интерфейс.

Для Java-кода в процессе-клиенте прокси-объект выглядит как обычный Java-объект, который реализует наш интерфейс, и этот код может просто вызывать его методы. При этом сгенерированная реализация прокси-объекта автоматически сериализует переданные аргументы, общается с процессом-сервисом через libbinder, десериализует переданный назад результат вызова и возвращает его из Java-метода.

Stub работает наоборот: он принимает входящие вызовы через libbinder, десериализует аргументы, вызывает абстрактную реализацию метода, сериализует возвращаемое значение и передаёт его процессу-клиенту. Соответственно, для реализации сервиса программисту достаточно реализовать абстрактные методы в унаследованном от Stub классе.

Такая реализация Binder на уровне Java позволяет большинству кода использовать прокси-объект, вообще не задумываясь о том, что его функциональность реализована в другом процессе. Для обеспечения полной прозрачности Binder поддерживает вложенные и рекурсивные межпроцессные вызовы. Более того, использование Binder со стороны клиента выглядит совершенно одинаково, независимо от того, расположена ли реализация используемого сервиса в том же или в отдельном процессе.

Для того, чтобы разные процессы могли «найти» сервисы друг друга, в Android есть специальный сервис ServiceManager, который хранит, регистрирует и выдаёт токены всех остальных сервисов.

Binder широко используется в Android для реализации системных сервисов (например, пакетного менеджера и буфера обмена), но детали этого скрыты от разработчика приложений высокоуровневыми классами в Android Framework, такими как Activity, Intent и Context. Приложения могут также использовать Binder для предоставления друг другу собственных сервисов — например, приложение Google Play Services вообще не имеет собственного графического интерфейса для пользователя, но предоставляет разработчикам других приложений возможность пользоваться сервисами Google Play.

Подробнее про Binder можно узнать по этим ссылкам:

• Android Binder — Embedded Linux Wiki
• Android Interface Definition Language, IBinder
• Deep Dive into Android IPC/Binder Framework
• Android Binder — Android Interprocess Communication
• An Overview of Android Binder Framework
• Binders & Window Tokens

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

https://habrahabr.ru/post/334796/

Заканчивая тему о сети bluetooth mesh (первая заметка, вторая заметка), сегодня мы вкратце рассмотрим её архитектуру и безопасность.

Добро пожаловать.

Архитектура

Архитектура сети похожа на сетевую модель OSI и состоит из 8 уровней. рассмотрим их снизу вверх.

Уровень BLE (Bluetooth Low Energy) – находится в самом низу стека. Это не просто один из слоев архитектуры, а фактически, это полный стек BLE, который необходим для обеспечения сети беспроводной связью. Таким образом, сеть полностью зависит от доступности стека BLE на устройстве.

Канальный уровень (Bearer Layer) – определяет принципы обработки PDU сети. На данный момент определены два канала:

• канал адвертизинга (Advertising Bearer) – использует возможности адвертизинга и сканирования уровня BLE для приема и передачи пакетов PDU;
• канал GATT (GATT Bearer) — позволяет устройству, которое не поддерживает «Advertising Bearer», связываться с узлами сети, использующими протокол «Proxy». «Proxy» протокол инкапсулируется в операции GATT (Generic Attributes Profile) с использованием специально определенных характеристик GATT. Прокси-узел реализует эти характеристики и поддерживает оба канала для того, чтобы иметь возможность конвертировать и передавать сообщения между двумя типами носителя.

Сетевой уровень (Network Layer) – определяет различные типы адресов сообщений и их формат, а так же переносит пакеты PDU из транспортного уровня в канальный. Уровень может поддерживать несколько каналов, каждый из которых может иметь несколько сетевых интерфейсов, включая локальный интерфейс, используемый для связи между элементами, являющимися частью одного и того же узла. Уровень так же определяет, какие сетевые интерфейсы должны передавать сообщения. К сообщениям, поступающим из канального уровня, применяется входной фильтр, для определения того, должны ли эти сообщения доставляться выше. Выходные сообщения обрабатываются выходным фильтром для и делают тоже самое только для доставки ниже. Таким образом, функции узла «Relay» и «Proxy» могут быть реализованы сетевым уровнем.

Нижний транспортный уровень (Lower Transport Layer) — принимает пакеты PDU с верхнего транспортного уровня и отправляет их на нижний транспортный уровень другого устройства. При необходимости выполняется сегментация и сборка пакетов. Для пакетов, длина которых превышает длину одного транспортного PDU, уровень выполняет сегментацию, разделяя пакет на несколько транспортных PDU. Получающая сторона будет собирать эти сегменты в один пакет PDU верхнего транспортного уровня и передавать его выше.

Верхний транспортный уровень (Upper Transport Layer) — отвечает за шифрование, дешифрование и проверку подлинности данных приложения, проходящих через уровень доступа.

Уровень доступа (Access Level) — отвечает за то, как приложения могут использовать верхний транспортный уровень путем:

• определения формата данных приложения;
• управления процессом шифрования и дешифрования, выполняемым на верхнем транспортном уровне;
• проверки перед пересылкой данных вверх того, что данные, полученные с верхнего транспортного уровня, предназначены для текущей сети и конкретного приложения.

Уровень основных моделей (Foundation Models Layer) — отвечает за реализацию тех моделей, которые связаны с конфигурацией и управлением сетью.

Уровень моделей (Models Layer) – реализует модели, тем самым реализуя поведение, сообщения, состояния, привязки состояний и т.д., в соответствие с определениями спецификаций модели.

Безопасность

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

Перечислим фундаментальные составляющие безопасности:

1. Все сообщения сети шифруются и проверяются на подлинность.
2. Безопасность сети, безопасность приложений и безопасность устройств рассматриваются как отдельные составляющие.
3. Ключи безопасности можно изменить в течение срока службы сети с помощью процедуры обновления ключа (Key Refresh).
4. Обфускация сообщений затрудняет их отслеживание, обеспечивая конфиденциальность.
5. Процесс добавления устройства в сеть, сам по себе является процессом в контексте безопасности.
6. Удаление узлов из сети происходит так, что бы исключить атаку типа «trashcan».

Разделение ответственности

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

Для понимания термина «разграничение ответственности», рассмотрим лампу освещения, имеющую функцию ретрансляции (Relay). В качестве ретранслятора она может обрабатывать сообщения, относящиеся к дверной или оконной системе безопасности, являющейся часть данной сети. Лампа не имеет возможности получать доступ и обрабатывать детали таких сообщений, но должна их передавать другим узлам. Для обеспечения запрета доступа к таким сообщениям, сеть использует разные ключи безопасности для защиты сообщений на сетевом уровне от тех, которые используются для защиты данных, относящихся к конкретным приложениям: освещение, охрана, обогрев и т.д.
Все узлы в сети имеют сетевой ключ (NetKey). Но этот ключ делает устройство узлом и членом сети. А вот ключ шифрования и приватный ключ образуются непосредственно из ключа NetKey.
Обладание ключом NetKey позволяет узлу расшифровывать данные и аутентифицироваться до «сетевого уровня» стека сети, чтобы можно было выполнять определенные сетевые функции, такие как ретрансляция. Но обладание им не позволяет расшифровать данные приложения.
Сеть может быть разделена на подсети, и каждая подсеть имеет свой собственный ключ NetKey, принадлежащий только узлам, являющимся членами этой подсети. Такая возможность может быть использована для изоляции конкретных физических областей, например таких, как каждая комната в гостинице.
Данные конкретного приложения могут быть расшифрованы только узлами, имеющими правильный ключ приложения («AppKey»). Через узлы в сети может проходить большое количество ключей такого типа, но, как правило, определенным ключом будет обладать ограниченное множество узлов, имеющих данное приложение. Например, лампы и выключатели света будут обладать ключом AppKey приложения освещения, но не ключом для системы отопления, в которой будут находиться только термостаты, клапаны радиаторов и т.д.
Ключи «AppKey» используются верхним транспортным уровнем стека сети для дешифрования и аутентификации сообщений до того, как передать их уровень доступа.
Ключи «AppKey» ассоциируются только с одним ключом «NetKey». Эта ассоциация называется «привязка ключей» (key binding) и означает, что конкретные приложения, владеющие конкретным ключом «AppKey», могут работать только в одной конкретной сети, тогда как сеть может содержать несколько независимых приложений.
И последний ключ, ключ устройства «DevKey». Это особый тип ключа приложения. Каждый узел имеет уникальный DevKey, известный только устройству с функцией регистратора в сети (Provisioner) и ни кому другому. DevKey используется в процессе подготовки для обеспечения безопасной связи между «Provisioner» и узлом.

Удаление узла, обновление ключа и атаки типа «trashcan»

И так, узлы содержат различные ключи защиты. Если узел сломался и его необходимо утилизировать, или если владелец решает отдать узел другому владельцу, важно чтобы устройство и ключи, которые он содержит, не могли быть использованы для установки атаки на ту сеть, членом которой он прежде был. Для этого была определена процедура удаления узла из сети. Приложение на устройстве «Provisioner» добавляет узел в черный список, после чего инициирует процедуру обновления ключа (Key Refresh Procedure). Эта процедура приводит к тому, что все узлы в сети, за исключением тех, которые являются членами черного списка, получают новые сетевые ключи, ключи приложений и все остальные производные данные. Другими словами, заменяется весь набор ключей безопасности, которые составляют основу безопасности сети и приложений. Таким образом, узел, который был удален из сети и который содержит старый «NetKey» и старый набор ключей «AppKey», больше не является членом сети и не представляет никакой угрозы.

Конфиденциальность

Приватный ключ (privacy key), полученный из «NetKey», используется для обфускации значений заголовков PDU, например таких, как адрес источника. Обфускация гарантирует, что случайный, пассивный перехват сообщений не может использоваться для отслеживания устройств и людей, которые эти устройства используют. Обфускация также затрудняет атаки, основанные на анализе трафика.

Атаки, основанные на повторе сообщения

Данная атака — техника, при котором устройство-перехватчик перехватывает одно или несколько сообщений и просто повторно передает их позже, с целью обмануть получателя, выполняя то, что атакующее устройство не уполномочено делать. Пример: система бесключевого доступа автомобиля всегда имеет риск перехвата данных между владельцем автомобиля и автомобилем.
У bluetooth сети есть защита от подобных атак. Защита основана на использовании двух полей в пакете PDU:

• «номер последовательности» (Sequence Number (SEQ)). Элементы сети каждый раз при отправке сообщения, увеличивают значение SEQ. Узел, получающий сообщение со значением SEQ меньшим или равным предыдущему действительному сообщению, отменит его, так как вполне вероятно, что это сообщение относится к атаке повтора.
• «IV Index» — поле, рассматриваемое вместе с SEQ. Его значение внутри сообщения от данного элемента всегда должны быть равны или больше значению этого поля в последнем действительном сообщении данного элемента.

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

Спасибо за внимание.

https://habrahabr.ru/post/334794/

https://habrahabr.ru/post/334790/

https://habrahabr.ru/post/334788/

В данной статье цикла про Osmocom мы рассмотрим практическую реализацию атак на абонентов GSM сетей. Будут рассмотрены атаки как с помощью голосовых вызовов и СМС так и атаки во время работы абонента с GPRS.

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

Статьи цикла:

Запускаем GSM-сеть у себя дома
Анализ трафика GSM сетей в Wireshark
Добавляем GPRS в домашнюю GSM сеть

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

Подготовка

Для работы нам понадобится еще один компонент, о котором мы упоминали лишь вскользь ранее — osmo-sip-connector.

Мы подключим нашу базовую станцию на основе двух osmocombb-совместимых телефонов к IP АТС Asterisk при помощи этого компонента.



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

Установить osmo-sip-connector на Ubuntu 14.04 мне не удалось из-за зависимостей и я решил пойти другим путем и просто установил все компоненты на Debian 9 (32-бита) через Nightly Builds deb-пакеты. В процессе установки пакетов я не получил никаких ошибок и проблем с зависимостями. Единственное, что я получил некоторые ошибки с texinfo при сборке старого toolchain. Но это легко исправилось правкой в gcc/doc/gcc.texi. Хочу предупредить, что сборку ветки osmocombb jolly/testing нужно проводить при помощи старого toolchain. Даже если вы исправите ошибку компиляции при использовании нового toolchain, вы получите нестабильную работу transceiver/TRX firmware в дальнейшем.

Устанавливаем osmo-sip-connector и asterisk

apt-get install osmo-sip-connector
apt-get install libsofia-sip-ua-glib-dev
apt-get install asterisk

Создаем файл osmo-sip-connector.cfg в вашей директории с другими конфигурационными файлами.

app
mncc
  socket-path /tmp/bsc_mncc
sip
  local 127.0.0.1 5069
  remote 127.0.0.1 5060

Настраиваем asterisk

Очень базовая конфигурация Asterisk может выглядеть так

Добавляем в конец файла /etc/asterisk/sip.conf

[GSM]
type=friend
host=127.0.0.1
dtmfmode=rfc2833
canreinvite=no
allow=all
context=gsmsubscriber
port=5069

Добавляем в конец файла /etc/asterisk/extensions.conf

[gsmsubscriber]
exten=>_XXXXX,1,Dial(SIP/GSM/${EXTEN})
exten=>_XXXXX,n,Playback(vm-nobodyavail)
exten=>_XXXXX,n,HangUp()

Перезапустим asterisk.

Захват абонента в нашу GSM сеть

2G/3G/4G

Сразу рассмотрим два варианта:

1. Целевой абонент использует старый телефон без поддержки 3G/4G.
2. Целевой абонент использует современный смартфон, поддерживающий 4G.

Во втором случае смартфон будет сперва искать 4G сети, затем 3G сети и только потом 2G сети. Таким образом, если вы находитесь в месте, где есть хороший сигнал от базовой станции 3G/4G домашнего оператора абонента, то он не подключится к вашей 2G базовой станции.

Чтобы решить эту проблему нужно либо создать помехи на 3G/4G частотах оператора, либо оказаться вместе с абонентом в локации, где нет покрытия 3G или 4G. Вопреки сомнениям многих людей, таким мест очень много до сих пор.

В первом же случае, когда целевой телефон не поддерживает 3G/4G все становится проще и наша базовая станция должна просто находиться в зоне досягаемости целевого телефона и иметь достаточно мощный сигнал.

MCC/MNC

Чтобы телефон автоматически подключился к нашей GSM сети, она должна являться домашней для SIM-карты, установленном в целевом телефоне.

Домашняя сеть определяется тремя параметрами:

• MNC (Mobile Network Code)
• MCC (Mobile Country Code)
• Networ Name (Имя сети)

Все эти значения не являются тайной и вы можете легко узнать их даже из Википедии.
Эти параметры транслируются базовой станции в SI (System Information) сообщениях на логическом канале BCCH (Таймслот 0).

Сейчас у нас в настройках OpenBSC указано следующее:

network country code 1
mobile network code 1
short name MyNet
long name MyNet

Узнать MCC и MNC абонента можно исходя из номера телефона. Есть множество сайтов с этой информацией, например этот. Узнать имя на латинице сети тоже не составит труда. Обратите внимание, что имя чувствительно к регистру.

В домашних условиях, вам будет так же необходимо изменить auth-policy на closed, чтобы только Ваши телефоны имел право подключаться к сети с реально существующими MCC и MNC.
Для этого добавьте абонентов в HLR с IMSI своих личных SIM-карт, если их еще нет в HLR.

telnet localhost 4242
en
conf t
subscriber create imsi ВАШ_IMSI_1
subscriber imsi ВАШ_IMSI_1 authorized 1
subscriber create imsi ВАШ_IMSI_2
subscriber imsi ВАШ_IMSI_2 authorized 1
...
write file
end

И измените политику аутентификации

telnet localhost 4242
en
conf t
network
auth policy closed
write file
end

Перезапустите OsmoNITB.

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

IMEI

IMEI — International Mobile Equipment Identity.
Когда к вашей сети начнут подключаться абоненты, как узнать, кто именно вам нужен? Вы не видите номера телефонов, вы видите только IMSI и IMEI.
Зная IMEI вы можете однозначно определить модель телефона, в который вставлена SIM-карта. Например при помощи сайта http://www.imei.info/
Модель и происхождение телефона описываются первыми 8 цифрами IMEI. Телефонам, поддерживающим одновременную работу с несколькими SIM-картами, присваивается несколько номеров IMEI.

Таким образом, если вы знаете, что целевой абонент использует Apple iPhone 5, то можете скачать базу данных с TAC кодами и узнать TAC для iPhone 5.
Такая база данных есть у osmocom — http://tacdb.osmocom.org/



Чтобы не захватывать в свою сеть абонентов с неподходящим TAC, хорошо бы отказывать абонентам при регистрации, если их оборудование имеет TAC не для iPhone 5.

На текущий момент я не нашел настроек для EIR в OsmoNITB, но вскоре у нас появятся отдельно стоящие MSC, HLR, возможно и EIR, и там это будет.

На текущий момент будем вручную контролировать подключенных абонентов. Можно просто каждому выставлять «authorized 0», если его IMEI нас не устраивает.

OpenBSC# subscriber imsi 123456789012345 authorized 0

Теперь, все, что остается — это оказаться рядом с абонентом и запустить CalypsoBTS.

MITM во время GPRS-сёрфинга

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

Однако мы можем предоставить ему доступ в интернет при помощи GPRS/EDGE сервисов пакетных данных.
Поскольку машина, предоставляющая доступ в Интерент для абонента находится полностью под нашим контролем, мы можем делать с TCP/IP трафиком все, что угодно.

Проще всего нам будет работать с данным участком



Напоминаю, что скорость передачи данных в GPRS очень низкая, в то же время современные телефоны при получении доступа к сети тут же начинают процесс проверки обновлений, почты, новостей. Все ваши приложения начинают обновлять свои данные. Это может привести к тому, что абоненту будет затруднительно открыть что-то в браузере, так как, помимо низкой пропускной способности, могут происходить потери пакетов, если вы используете такое непроизводительное оборудование как CalypsoBTS.

Поэтому при планировании MITM-атаки нужно иметь это в виду. Можно, например, заблокировать через iptables доступ ко всему, кроме ресурса, взаимодействие жертвы с которым нам интересно.

Далее при помощи фреймворка MITMf можно проводить непосредственно атаки.

Мы перенаправим все HTTP запросы абонента на наш веб-сервер.

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.32:80

Где 192.168.1.32 — IP-адрес машины Kali Linux, которую я буду использовать для атаки.

Дополнительно можно запретить все остальные запросы, на порт 443 и прочие, чтобы увеличить скорость загрузки фишингового сайта.

Воспользуемся SE Toolkit, чтобы скопировать сайт и провести фишинговую атаку.

Запустим SET



Мы хотим получить учетные данные от определенного сайта. Настраиваем SET.







Создаем фишинговую страницу аутентификации defcon.ru



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



В данном случае моя сеть имеет MCC 001 и MNC 01, так что мы видим значок роуминга. В этом случае чтобы получить доступ в Интернет, жертве придется разрешить пакетные данные в роуминге, что неудобно. Поэтому для этой атаки нужно использовать MCC/MNC и имя сети оператора целевого абонента (см. ниже по тексту). В лабораторных условиях можно этого не делать.

После ввода учетных данных SET отображает логин и пароль

СМС-фишинг

Когда делают фишинговые рассылки претворяясь банками или родными, то рассылка происходит с неизвестного абоненту номера, что подозрительно. Когда абонент попадает во враждебную GSM сеть, ему можно отправить СМС с любого номера.

Для отправки СМС нужно лишь сделать следующее:

Подключиться к VTY OsmoNITB и создать абонента от имени которого будет отправлена СМС.

telnet localhost 4242
OpenBSC# en
OpenBSC# subscriber create imsi 123456789012345
OpenBSC# subscriber imsi 123456789012345 extension 89001234567

Где
123456789012345 — IMSI подконтрольно телефона, включенного в сеть атакующего.
89001234567 — Номер телефона, с которого жертва получит СМС.



И отправить СМС можно из того же VTY интерфейса OsmoNITB

OpenBSC# subscriber imsi 987654321987654 sms sender extension 890012345678 send Your bank...

Где 987654321987654 — IMSI телефона жертвы, захваченной в сеть.



Если жертва ответит на СМС, вы получите ответ на подконтрольный телефон.
Ответ вы также сможете легко получить просмотрев Wireshark дамп трафика, при этом не имея подконтрольного телефона в сети.

Обратите внимание, что значка роуминга на снимке экрана в этот раз нет, так как используются MCC, MNC и имя домашней сети SIM-карты целевого абонента, и СМС пришла от абонента, занесенного в телефонную книгу, т.е. обнаружить такую атаку невозможно.

Отправка Binary-SMS — еще один вектор. OsmoNITB позволяет отправлять Siltent SMS, но как отправить binary средствами OsmoNITB, я не нашел. На текущий момент можно попробовать использовать что-то такое. Однако этот вектор еще нужно изучать и реализация конкретных атак в каждом случае будет отличаться.

Перенаправление и запись голосовых вызовов

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

Чтобы использовать Asterisk для маршрутизации звонков, нужно добавить ключ -M в команду osmo-nitb

-M /tmp/bsc_mncc

И запустить osmo-sip-connector

osmo-sip-connector -c путь_до_конфигурационного_файла

Теперь наши вызовы будут маршрутизироваться через Asterisk, мы можем задать любой dialplan и полностью определить, как будет проходить звонок. Атакующий можете, к примеру, направлять все вызовы абонента на автоответчик, где роботизированный женский голос будет спрашивать у абонента конфиденциальную информацию. Никто не же подумает, что робот может навредить человеку?

Запись звонков можно выполнять при помощи стандартных конструкций Asterisk а файле /etc/extensions.conf — Monitor() и MixMonitor().

Radio Resource LCS (Location Service) Protocol

RRLP — GSM протокол, позволяющий сети запросить текущие координаты абонента.
RRLP не требует аутентификации и согласия пользователя на предоставление этих данных.
Мы, через OsmoNITB, тоже можем отправить RRLP запрос захваченному абоненту.
Если используется CalypsoBTS, то вы находитесь рядом с абонентом и это вряд ли может быть полезно, однако при использовании более мощных трансиверов RRLP позволяет выполнять слежку за абонентом.

К сожалению у меня не было достаточно времени это попробовать, но я полагаю, что нужно использовать модуль osmocom-lcs

Существуют и другие атаки, которым подвержены абоненты 2G сетей и большинство сотовых телефонов до сих пор поддерживают GSM. Чтобы не статье жертвой подобного рода атак, будьте внимательны при получении подозрительных звонков, смс или при сёрфинге с мобильного телефона, а так же обращайте внимание на значки 3G/LTE, которые обычно указывают на то, с сетью какого поколения вы в данный момент работаете.

https://habrahabr.ru/post/334708/

Меня зовут Мельник Александр, и я сооснователь сервиса «Дело в мебели»

О чем проект

«Дело в мебели» – это сервис по подбору мебели от проверенных фабрик. Клиент получает персональный подбор 3 проверенных производителей мебели, после чего выбирает самый подходящий вариант.
Основная цель проекта – дать качественный продукт клиенту, и обеспечить добросовестных производителей заявками.

Предыстория

В 2015 году моя подруга купила новую квартиру в Москве. Отдала большие деньги на покупку мебели, но уже через год появились проблемы: диван просел, дверцы кухни начали скрипеть, а направляющие у полок заедали.
Как итог – нужно было все заменить, и он попросил помощи.

Решение проблемы

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

Из уже отобранного списка 38 фабрик, только 4 подходили по нашим критериям цены и качества.

От идеи до старта

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

25 ноября 2016 года я и мой друг создали сервис – «Дело в мебели», в котором отбираем фабрики в базу и берем на себя клиентский сервис.

Принцип работы и бизнес-модель

Основная выгода для клиента – экономия времени и денег при выборе производителя.

Дополнительные выгоды:

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

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

Вопросы и ответы

Как происходит весь процесс?
— Вы проходите тест на нашем сайте, в котором собраны основные вопросы по подбору мебели. Далее мы размещаем вашу заявку среди фабрик. После получения расчетов от них, мы отбираем 3 предложения и передаем их вам. Далее вы взаимодействуете лично с производителем.

Как именно мы выбираем фабрики?
— Каждый производитель чаще всего силен в каком-то одном направлении, кто-то лучше делает кухни из массива, кто-то лучше спальни и т.д. Мы проводим закрытый аукцион среди производителей и подбираем для вас 3 лучших в соотношении цена/качество.

Какое количество фабрик в базе?
— На сегодняшний день их 170. Но мы постоянно расширяем базу.

P.S. Если вы прочитали, пожалуйста уделите еще минуту и напишите ваше мнение или комментарий. Мы ценим это.

https://habrahabr.ru/post/334784/

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

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

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


(картинка для привлечения внимания. Картинка не относится к описываемому мной сервису)


В конце прошлого года я воспользовался сервисом, чьё название я не буду упоминать, не смотря на то, что компания давно исправила уязвимость.

На сайте службы доставки по ссылке вида xxxxxxxx.ru/departure_track/?id=XX00000000123456YYY, которую я получил в письме от интернет-магазина, где делал заказ, была указана довольно детальная информация.

Были доступны следующие данные:
— название интернет-магазина;
— № заказа интернет-магазина;
— вес посылки;
— пункт выдачи, который часто был адресом физ. лица;
— а также контактный телефон отделения, который во многих случаях являлся не телефоном почтового отделения, а был именно личным мобильным телефоном получателя (проверено на себе).





Информация была доступна для просмотра без авторизации и без ограничений по количеству подборов номеров отправлений.

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

В письме, отправленным мной компании, я указал такой пример: звонок может быть на номер +380501234567 со следующими данными:

— Добрый день, меня зовут Андрей, я сотрудник службы доставки XXXXXXXX. Вы ожидаете посылку от %COMPANY_NAME%, весом 1,02 кг, № заказа интернет-магазина 4507XXXX-X?

— Да.

— Ваш адрес Киев, улица Татарская, дом 3, квартира 15 — указано правильно?

— Да.

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

— Хорошо.

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

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

Что приятно, компания приняла моё письмо во внимание и исправила уязвимость (убрала лишние для отображения поля, позже добавила капчу), а также перевела мне 2000 рублей в качестве вознаграждения, пусть и не сразу.

На сегодняшний день проблема исправлена, информация на сайте отображается в усечённом виде

Так что почтовые сервисы бывают разные.

https://habrahabr.ru/post/334782/

9 августа в 11:00 (мск) приглашаем Вас на вебинар «Как надежно и выгодно защитить предприятие от неизвестных угроз и шифровальщиков»

На вебинаре мы расскажем Вам об единственном облачном EPP+EDR решении Panda Adaptive Defense 360, который позволит надежно защитить Ваше предприятие от шифровальщиков, эксплойтов, APT, новых и скрытых угроз, безфайловых атак и атак, не использующих вредоносные программы. Решение позволяет получить полный контроль над происходящим в сети: откуда пришла угроза, где появилась, что пыталась сделать, к каким файлам обращалась, куда что отправляла и пр.

Зарегистрируйтесь на вебинар, узнайте об уникальных возможностях Panda Adaptive Defense 360 и выгодных условиях поставки, протестируйте новое решение.
Мы расскажем, почему пользователи Panda не пострадали от WannaCry, Petya и других новых угроз, и почему они уверены в своей защите от будущих угроз.

Рассматриваемые вопросы:

1. Новые и неизвестные угрозы — серьезная опасность для предприятия
2. Уникальная модель безопасности
3. Возможности решения
4. Лицензирование и преимущества для предприятия

Дата вебинара: 9 августа в 11:00 (московское время)

Ведущий: Паздников Алексей (Panda Security в России)

https://habrahabr.ru/post/334780/

Очень простой способ прикрыть от посторонних сканеров и брутфорсеров важные сетевые порты такие как:

• SSH
• RDP
• ...

Например, я сталкивался с тем, что брутфорсеры постоянно блокировали учетки в домене windows, долбясь по RDP и передавая пары логин/пароль валидных пользователей. Разумеется, DC блокирует такие учетки, пресекая брутфорс.

Можно придумать еще кучу подобных уязвимостей.
И просто неприятно видеть когда на важных портах висят не понятные ESTABLISHED соединения.

Избежать таких ситуаций можно следующим образом:

iptables -A INPUT -p tcp --dport 65432 -m recent --set --name tuktuk
iptables -A INPUT -p tcp --syn --dport 22 -m recent --rcheck --seconds 160 --name tuktuk -j ACCEPT
iptables -A INPUT -p tcp --syn --dport 22 -j DROP

Вот и все!
Кто бы ни попробовал просканировать порт SSH, будет дропнут без разговоров.
Для установки соединения нужно предварительно постучаться на порт 65432.
Например из браузера (http://ваш_адрес:65432)
Или telnet ваш_адрес 65432
Или putty ваш_адрес -p 65432

И потом уже putty ваш_адрес -p 22

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

https://habrahabr.ru/post/334774/

Данная статья предназначена для начинающих веб-разработчиков, а также тех, кто хочет понять, для чего стоит изучить PHP-фреймворк Laravel и какую экосистему он нам предлагает.
Статья написана на момент актуальности Laravel версии 5.4, в августе 2017 выйдет релиз Laravel 5.5, который предоставляет ещё больше возможностей.

Содержание:

• Введение в веб-разработку, что было раньше и что сегодня
• Начало создания веб-проекта
• Этап первый – процесс написания кода
• Этап второй – тестирование кода
• Этап третий – сборка проекта
• Этап четвёртый – развёртывание (deploy) кода
• Итоги
• Основные возможности PHP-фреймворка Laravel
• Полезные ссылки

Введение в веб-разработку: что было раньше и что сегодня

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

Инженер, программист или веб-разработчик?

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

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

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

Буквально любой может взять и тут же вывести строку на экран. Именно поэтому опытные разработчики на любых языках программирования считают PHP-разработчиков «ненастоящими» разработчиками, а PHP – «ненастоящим» языком программирования.

Но возможно ли создать на PHP серьёзный продукт и как доказать другим, что PHP можно доверять? Если Вы из тех людей, которые считают PHP «несерьёзным» языком программирования, то советую дочитать до конца и, скорее всего, Вы измените своё мнение.

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

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

Laravel – это идеальное решение для тех, кто хочет быстро и грамотно создать безопасный и надёжный веб-проект, при этом всегда оставаясь на пике технологий веб-разработки.

Начало создания веб-проекта

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

Сам Laravel хоть и является PHP–фреймворком, но не стоит его недооценивать, ведь это целая экосистема для веб-разработки.

Если Вы скачали фреймворк Laravel в .zip архиве, чтобы оценить его возможности, тогда Ваше рабочее окружение точно настроено неверно, и у Вас существует пробел в знаниях. Вам однозначно стоит внимательно прочитать данную статью до конца.

Этап первый – процесс написания кода

Вы можете работать на любой операционной системе, в том числе и на Windows.
Нам необходима хорошая IDE (Интегрированная среда разработки (англ. Integrated Development Environment)) – рекомендую PhpStorm. Можете использовать текстовый редактор Atom или Sublime Text. Конечно, можно писать код и в обычном блокноте, например, Notepad++, но хорошая IDE – незаменимая вещь.

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

Многие считают, что «крутые» разработчики должны писать код в блокноте, но помнить по памяти названия функций – это одно, а не делать опечатки в коде, упростить и ускорить процесс разработки – это совсем другое. Главная задача – освоить все возможности IDE.

Кроме IDE нам необходимо будет установить Composer (https://getcomposer.org), именно через него мы и будем устанавливать (обновлять) Laravel, добавлять (обновлять) дополнительные пакеты в наш веб-проект.

Обязательно изучите работу с Composer, это очень важный и полезный инструмент.

Подробно изучите инструкцию по установке Laravel по этой ссылке.

Далее мы не будем описывать процесс написания кода, а предположим, что Вы уже установили IDE и Laravel.

После установки Laravel в коде сразу прописано отображение базовой страницы – этого достаточно, чтобы перейти к следующей части статьи.

Этап второй – тестирование кода

Для тестирования веб-проекта Вам не надо загружать файлы на FTP-сервер, устанавливать локальный Apache (тот же Denwer или XAMPP) – так делали много лет назад, а многие новички так делают до сих пор. Это неправильно и не спасёт от ошибок в коде. На сегодняшний день для этих задач есть соответствующие инструменты, которые сэкономят много времени и нервов.

Laravel предлагает нам установить Homestead.
Homestead – это образ операционной системы Ubuntu, в которой уже установлено всё необходимое.

С процессом установки и настройки Homestead Вы можете ознакомиться по ссылке.

Для установки образа нам понадобится Vagrant и VirtualBox.
Благодаря данному образу Вы точно будете знать, какие модули надо установить и как поведёт себя Ваш код на Ubuntu. Вы также можете установить любой дополнительный софт.

Если кратко, то у Вас в системе появятся общие папки с кодом, которые будут доступны внутри образа Ubuntu, и выполняться Ваш код будет именно внутри Ubuntu.

В браузере Вы набираете site.app, и у Вас отображается сайт из Ubuntu.
При этом у Вас также будет доступ к Ubuntu по SSH.

У начинающих установка и настройка Homestead займёт время, но как разработчик Вы просто обязаны это сделать.

Стоит отметить, что Homestead можно установить не только на Linux, но и на Windows.

Далее будем считать, что Homestead установлен, и сайт со свежей версией Laravel открывается у Вас в браузере.

Ваш код запускается в браузере, но действительно ли всё работает?

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

Laravel предлагает нам инструменты для полноценного тестирования веб-проекта со всех сторон. Вы можете тестировать всё: создать временную базу данных, проверить заполнение HTML-форм, проверить загрузку файлов, даже содержание PHP-сессий и отправку писем.

Laravel создан для качественного тестирования всех возможностей Вашего проекта.

Документацию по тестированию можно найти по этой ссылке.

В Laravel тесты находятся в папке tests и выполняются командой phpunit в консоле, либо сразу из IDE.

Тесты бывают нескольких типов:

1. Функциональные – Feature-тесты
2. Модульные – Unit-тесты

Feature-тесты – функциональные тесты.

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

Также Вы можете проводить тестирование с помощью Laravel Dusk, не просто отправляя HTTP-запросы, а используя реальный движок браузера Chromium.

В этом нам поможет Laravel Dusk.

Unit-тесты – модульные тесты.

Другой тип тестирования называется unit-тестированием.
Эти типы тестов проверяют логику нашего приложения, каждую функцию, отлавливают события, определяют отправлено ли письмо, а также сверяют текст письма, проверяют добавлено ли задание в очередь сообщений и всё, что может сломаться, если Вы или кто-то ещё неудачно измените Ваш код.

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

При изменении функционала Вы можете дописать тесты. Это спасёт Вас и Ваших коллег от ошибок и поможет проще диагностировать проблему.

Unit-тестирование позволяет избежать ошибок в логике приложения.

Стоит отметить, что существует методика разработки TDD (test-driven development) – разработка через тестирование. Сначала мы пишем тесты, а затем постепенно реализуем код. Когда все тесты выполнены, то мы можем сказать, что завершили написание кода.

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

Laravel предлагает нам установить Laravel Debugbar.

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

Этап третий – сборка проекта

После создания веб-проекта и прохождения тестов нам необходимо подготовить наш проект к размещению на сервере.

Laravel предоставляет нам Laravel Mix.

Laravel Mix использует Webpack и умеет работать с CSS, JS, Less, Saas, Stylus, PostCSS.

Это замечательный инструмент, который, используя специальный сборщик модулей Webpack, собирает вместе все наши JS и CSS-файлы, а также, самое главное, умеет создавать версии этих файлов.

Таким образом, каждая сборка нашего проекта позволяет иметь разные названия JS и CSS-файлов в HTML-коде, что решает проблему с кешированием при изменении содержимого файла.

В шаблоне нашего проекта пишем:

После сборки он превращается в:

При этом браузер посетителя сразу загрузит новый файл с сайта.

Не правда ли, удобно? Точно также и с JS-файлами.

Стоит отметить, что Laravel замечательно работает с прогрессивным Javascript-фреймворком Vue и позволяет очень удобно создавать веб-приложения на базе этого JS-фреймворка. При этом каждый компонент можно удобно размещать в отдельном файле.

О том, как писать компоненты для Vue используя Laravel можно прочитать по этой ссылке.

Этап четвёртый – развёртывание (deploy) кода

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

Берём папку с файлами и загружаем на FTP-сервер.
Заходим в phpMyAdmin и делаем изменения в БД.

Мы не станем использовать FTP и phpMyAdmin, иначе пока мы вносим изменения, все пользователи, которые зайдут на сайт веб-проекта, увидят множество ошибок об отсутствии каких-то файлов или полей в БД.

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

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

Git — это распределённая система управления версиями файлов.

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

Использовать Git можно через сервис.

Вы можете создать либо общедоступный код, либо приватный (для приватных репозиториев – он платный).

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

Кроме этого, сам Git можно настроить так, чтобы при внесении изменений происходили определённые действия:

1. запуск тестов проекта через Travis CI;
2. форматирование кода по стандарту;
3. анализ качества кода через инструмент.

Таким образом, весь код Вашего веб-проекта будет храниться в Git, он всегда будет качественный и проверенный.

Например, если Вы предложите внести изменения в официальный код PHP-фреймфорка Laravel, то при внесении изменений автоматически запускаются тесты, которые проверяют работу фреймворка, учитывая новый код.

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

Laravel Forge – сервер без хлопот.
Для автоматического развёртывания из Git нам поможет сервис Laravel Forge.

Через Laravel Forge Вы можете создать виртуальный сервер в DigitalOcean, Linode или указать доступ к своему собственному серверу. При этом будет настроено абсолютно всё необходимое ПО для работы PHP-фреймворка Laravel.

Laravel Forge автоматически устанавливает обновления, связанные с безопасностью системы. Также Forge легко установит бесплатный SSL-сертификат от Let's Encrypt.

Вы можете дать сервису Laravel Forge доступ к Вашему Git-репозиторию и при каждом изменении в коде на сервере будет автоматически развёрнута его свежая версия.
Хотите 10 серверов? – Без проблем, Laravel Forge может установить балансировщик нагрузки, создать 10 виртуальных серверов, на каждый сервер копировать код из Git и запустить проект.

Думаете всё?

Нет, совместно с Envoyer Вы можете запускать новый код в работу без остановки сервиса совсем.

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

Ссылка на скрипт.

Итоги

Мы создали комфортное рабочее окружение, установили IDE, Composer, PHP-фреймворк Laravel, написали код проекта, запустили тесты, изучили систему контроля версий Git, отправили туда код, подключили сервис Laravel Forge, при желании подключили также Laravel Envoyer, сделали развёртывание проекта на рабочий сервер из нашего Git-репозитория.

Можно сказать, что Laravel направил нас на грамотный путь в веб-разработке. Впереди ещё многое предстоит изучить, но мы уже проделали большую работу и можем начинать работать в команде с другими разработчиками.

Основные возможности PHP-фреймворка Laravel

А теперь рассмотрим возможности самого PHP-фреймворка Laravel: какие веб-приложения позволяет нам создавать данный PHP-фреймворк, насколько он продвинутый в техническом плане и почему он так популярен во всём мире.

После выхода PHP7 по сравнению с PHP5, скрипты стали быстрее и начали использовать гораздо меньше оперативной памяти, а в связке с Zend OPCache показывают замечательные результаты. В частности сервис Laravel Forge настраивает Zend OPCache для достижения максимальной производительности.

Именно поэтому, когда идёт речь о производительности того или иного PHP-фреймворка, то всегда проводят тестирование без кеширования, работы с БД или файлами, в основном совершая множество вызовов к обычной PHP странице. В этом плане данный PHP-фреймворк существенно ничем не отличается от всех остальных, но когда речь идёт о масштабируемости, гибкости, универсальности встроенных механизмов кеширования и скорости разработки, именно тогда Laravel показывает всю свою гибкость и мощь.

Сам Laravel постоянно совершенствуется и следует современным тенденциям. Изучая его, Вы не отстанете от мира веб-разработки, главное – не зацикливаться на какой-то конкретной версии фреймворка, а развиваться вместе с ним. Для этого необходимо также изучать нововведения Laravel.

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

Постараюсь описать основные возможности Laravel, чтобы можно было оценить масштаб:

• MVC (англ. Model View Controller – модель-представление-контроллер) PHP-фреймворк построен на базе известных и надёжных компонентов Symfony.
  
  
• Необходимые модули для фреймворка подключаются в виде пакетов-провайдеров (service provider). В версии Laravel 5.5 достаточно просто установить пакет через Сomposer, и он сразу будет доступен, без необходимости что-либо писать в коде.
  
  
• Код фреймворка отделён от кода разработчика, каждый компонент легко расширяется.
  
  
• Код веб-проекта, CSS, JS, HTML-код страниц разделены в отдельные директории. Фреймворк использует замечательный шаблонизатор Blade, который позволяет отделить вёрстку от PHP-кода. Сам шаблонизатор настолько прост, что даже начинающий HTML-верстальщик сможет легко его осилить.
  
  
• Удобная маршрутизация, валидация входящих параметров.
  
  
• Кеширование, работа с хранилищами файлов, работа с различными БД.
  
  
• Миграции для базы данных, Вы можете изменять структуру БД и откатывать изменения.
  
  
• Очереди заданий, планировщик задач, консоль, работа с SSH.
  
  
• Огромный функционал Eloquent ORM позволяет полностью обезопасить себя от атак типа SQL Injection, а также загружать данные из нескольких таблиц (решая проблему N+1) или же обрабатывать данные из БД частями.
  
  
• Laravel Collections – можно сказать, что это PHP массивы, но с очень продвинутыми возможностями, которые экономят массу времени.
• Кэширование файлов маршрутизации, файлов конфигурации, шаблонов. Это ускоряет работу фреймворка.
  
  
• Отправка уведомлений различными способами: почта, Slack и т.д., можете дописать сами.
  
  
• Поддержка WebSockets для создания настоящих интерактивных приложений.
  
  
• Поддержка мультиязычности: легко добавляйте любые языки, а пакет Laravel-lang уже содержит множество переводов.
  
  
• Интерфейс командной строки artisan, который позволяет генерировать модели, контроллеры, уведомления, запускать задания из очереди заданий и многое другое.
  
  
• Laravel Tinker – дополнительный пакет, который позволяет работать с кодом проекта из командной строки.
  
  
• Огромные возможности для тестирования веб-проекта, включая заполнение базы данных тестовыми данными.
  
  
• У фреймворка есть даже собственный сайт с библиотекой пакетов.
  
  
• Нужен полнотекстовый поиск? Пожалуйста – Laravel Scout, можно использовать Algolia, Sphinxи другие драйвера.

Впечатляет, не правда ли? А я не описал даже и половины возможностей.

С помощью Laravel можно одной командой сгенерировать систему регистрации и входа на сайт и с лёгкостью подключить сервисы OAuth аутентификации благодаря Laravel Socialite или даже создать свой с помощью Laravel Passport.

Для тех, кто не знает OAuth, – это возможность войти на сайт через социальные сети.

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

На основном сайте PHP-фреймворка Laravel недаром присутствует девиз:

«Любите красивый код? Мы тоже. PHP-фреймворк для веб-мастеров.»

Ведь код PHP-фреймворка Laravel не только красивый, приятно читаемый, но ещё и очень грамотно продуман, а над любым изменением думает множество людей, что позволяет создавать профессиональные веб-приложения на уровне мастера своего дела.

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

Сайт PHP-фреймворка Laravel.

Основные новости PHP-фреймворка и новости о различных пакетах.

Очень рекомендую сайт https://laracasts.com, где Jeffrey Way в своих видео-уроках наглядно и без лишних слов показывает возможности Laravel, также рассказывает много полезных вещей. За 2 минуты человек успевает рассказать больше и доступнее, чем многие за час.

А также рекомендую книгу "Refactoring to Collections", где Adam Wathan подробно рассказывает о возможностях Laravel Collections. Гарантирую, Ваш код изменится в лучшую сторону.

Рекомендую в каждый веб-проект на Laravel устанавливать:

• Laravel Debugbar
• Laravel IDE Helper Generator
• Полезные пакеты от Spatie

P.S.: Данная статья получилась довольно объёмной и без технических подробностей, но её основная задача – дать начинающим разработчикам вводные знания, объяснить что же такое Laravel и какие возможности он даёт, а также показать, что Laravel – это не просто PHP-фреймворк, а целая экосистема, которая постоянно развивается. Это именно тот тренд, на который должны обратить внимание PHP-разработчики.

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

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

https://habrahabr.ru/post/334776/

Ошибки бывают разных форм и размеров. Некоторые ошибки милые и пушистые и их легко исправить, потому что вы можете запустить ваше приложение и пойти прямо к тому месту где происходит ошибка. Если вы счастливчик, Xcode покажет вам какая строка привела к падению вашего приложения.

Другие ошибки более зловещие. Они таятся в фоне и случаются когда вы менее всего этого ожидаете. Они ужасы ночных кошмаров и рекламных роликов Listerine.

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

Это оружие — SwiftyBeaver, основанная на Swift система логирования для iOS и macOS.

В этом руководстве вы узнаете как отлаживать ваше приложения используя SwiftyBeaver и получите следующие полезные умения на этом пути:

• When SwiftyBeaver logging is better than print() and NSLog()
• Как получить доступ к журналам SwiftyBeaver в Crypto Cloud
• Как использовать уровни логирования для различных типов сообщений журнала
• Как фильтровать записи, чтобы облегчить поиск ошибок

Примечание: перед началом урока вы должны быть знакомы с Cocoapods и фреймворком CoreLocation. Сначала ознакомьтесь с этими руководствами чтобы получить необходимые умения.

Начало

Загрузите начальный проект. Этот архив содержит проект и все необходимые файлы для завершения урока.

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

Это приложение названо Ten PM (Вы знаете где ваши дети?).
Откройте TenPM.xcworkspace и посмотрите проект. Теперь откройте Main.storyboard и вы увидете два view controller'а внутри navigation controller'а:



View controller слева — это тот, который родители могут использовать, чтобы сказать приложению где находится «дом» а также задать максимальное расстояние, на которое дети могут отходить. Класс — TrackingSetupViewController, который запрашивает доступ к службам геолокации и сохраняет введенное расстояние для ограничения расстояния.

View controller справа — это тот, который будут использовать дети. Он отображает карту с зеленым кругом представляющим безопасную зону. Он также содержит блок текста ниже, чтобы сообщим им, находятся ли они в настоящее время в безопасной зоне или нет. Класс — TrackingViewController, в котором используется MKMapView отображающий допустимую для детей территорию.

И здесь еще несколько строк на заметку:

• LocationTracker.swift: выступает в роли делегата CLLocationManager. Здесь обрабатываются обновления местоположения и изменения разрешений для служб геолокации.
• ParentProfile.swift: сохраняет важные данные пользователя в NSUserDefaults. Эти данные включают в себя местоположение дома и расстояние, на которое их дети могут отходить от дома.

Используем начальное приложение

Запустите предложение на iOS симуляторе. Вы увидете view controller который представлен классом TrackingSetupViewController:



Перед тем как настроить отслеживание, вы должны быть уверены, что симулятор предоставляет данные о начальном местоположении. Чтобы сделать это выберете симулятор, затем на панели выберите Debug\Location\Apple.



Нажмите на кнопку SETUP TRACKING и приложение запросит разрешение чтобы начать сбор данных о местоположении. Поскольку этот экран для родителей там есть одно лишнее окно для подтверждения, что вы родитель и находитесь дома. Выберите Yes и затем Allow. Один раз приложение определит ваше местоположение и сохранит его как дом, чтобы использовать как центр безопасной для детей зоны.

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



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

Подумайте об этом, это приложение могло бы быть полезным для соттрудников Apple несущих дорогие прототипы iPhone

Теперь когда все настроено, самое время притвориться, что сейчас 2011 год, вы получили прототип iPhone 4 и отправляетесь на прогулку. Давайте симулируем новое местоположение, вне безопасной зоны, в том месте где вы назначили встречу с репортером Gawker.

В меню iOS Simulator снова пройдите в Debug\Location, но в этот раз выберите Custom Location. Введите 37.3393 как широту и -122.0426 как долготу после чего нажмите OK.



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

Это краткое описание функциональности приложения Ten PM. Это довольно простое приложение, которое может быть легко расширено. Вы могли бы начать отправку уведомлений родителям когда их ребенок выходит за пределы безопасной зоны и т.д.

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

Установка SwiftyBeaver

Для начала установим SwiftyBeaver используя Cocoapods. Найдите корневую директорию проекта и найдите там Podfile. Откройте его в редакторе, который для вас наиболее удобен и добавьте следующую строку под строчкой # Pods for TenPM:

pod 'SwiftyBeaver'

Откройте Terminal, перейдите в директорию с эти Podfile и введите следующую команду:
pod install

После минуты или может чуть больше установка SwiftyBeaver в ваш проект будет завершена. Теперь откройте AppDelegate.swift и добавьте следующую строку в подходящем месте в верхней части файла:

import SwiftyBeaver

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

---

Примечание: это руководство по установке работает с Cocoapods и Swift 3. Более подробную инструкцию по установке вы можете найти на странице репозитория проекта SwiftyBeaver на GitHub.

---

Написание ваших первых логов со SwiftyBeaver

Фух. Вы готовы написать немного кода?

Загляните в AppDelegate.swift снова. Это место где вы сейчас настроите логирование для SwiftyBeaver. Вы заметили заготовку метод в стартовом проекте?
setupSwiftyBeaverLogging() вызывается каждый раз когда ваше приложение запускается, и как следует из названия вы будете его использовать для подготовки SwiftyBeaver к использованию. Перейдите к этому методу и добавьте следующее:

let console = ConsoleDestination()
SwiftyBeaver.addDestination(console)

SwiftyBeaver это необычный инструмент логирования. Он имеет несколько входов названых Destinations, которые вы можете конфигурировать в соответствии с вашими нуждами.
Destination определяет где появляются ваши логи.
ConsoleDestination() создает Console Destination, который вы добавили как активный destination для SwiftyBeaver.
В метод application(_:didFinishLaunchingWithOptions:) добавьте следущую строку кода, после вызова метода setupSwiftyBeaverLogging():

SwiftyBeaver.info("Hello SwiftyBeaver Logging!")

Этот код отображает лог уровня info в консоли когда приложение запустится. Вы узнаете больше об уровнях логов чуть позже.
Запустите Ten PM снова. Проверьте консоль когда приложение запустится и вы увидете запись:
12:06:05.402 INFO AppDelegate.application():36 — Hello SwiftyBeaver Logging!

Круто! Вы ведете логирование в консоли с помощью SwiftyBeaver. Изобращение сердца относится к уровню логов, которые разъяснены ниже.

Краткое объяснение уровней логов

Я уверен, что на этом этапе вам интересно почему SwiftyBeaver заставляет использовать метод с именем info() вместо более понятных и логичных имен таких как log() или print().
Это связано с тем, что называется Log Levels.
Не все логи одинаково важны. Некоторые логи полезны для предоставления программисту дополнительной контекстной информации. Другие логи необходимы для более серьезных проблем, таких как ошибки и предупреждения.
При изучении логов достаточно полезно иметь записи, которые классифицированы по уровню угрозы для приложения. Это помогает быстрее фильтровать менее важные сообщения, чтобы быстрее исправлять ошибки.
SwiftyBeaver придерживается договоренностей и использует эти 5 уровней логов:

1. Verbose: наименьший уровень приоритета. Используйте их для контекстной информации.
2. Debug: используйте этот уровень для отображения переменных или иных результатов, которые помогут вам исправить ошибку или решить проблему.
3. Info: обычно используется для информации полезной в более общем контексте поддержки. Другими словами, информация полезная для не-разработчиков ищучающие проблемы.
4. Warning: используйте этот уровень когда достигаете состояния, которое не обязательно станет причиной проблемы, но решительно ведет приложение в этом направлении.
5. Error: самый сериезный и высокий приоритет логов. Используйте его только тогда, когда ваше приложение вызывало серьезную ошибку.

Как записывать разные уровни логов со SwiftyBeaver

Также как вы использовали метод info() для логирования на уровне info, вы можете использовать четыре других метода: verbose(), debug(), warning(), и error() для логирования на остальных четырех уровнях.

Попробуйте. Вернитесь назад к методу application(_:didFinishLaunchingWithOptions:) и замените вызов info() на следующим кодом:

SwiftyBeaver.debug("Look ma! I am logging to the DEBUG level.")

Теперь запустите ваше приложение. Вы должны увидеть другой цвет иконки сердца и другое сообщение на уровне debug.
14:48:14.155 DEBUG AppDelegate.application():36 — Look ma! I am logging to the DEBUG level.

Обратите внимание, что цвет иконки сменился на зеленый, чтобы обозначить debug уровень логов. Это одна из причин, почему SwiftyBeaver лучше, чем print() и NSLog(). Вы можете быстро просмотреть логи и найти сообщения на уровне, который вас интересует.

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

Настройка SwiftyBeaver Crypto Cloud

Одна из крутейших особенностей SwiftyBeaver это возможность ведения логов напрямую в облаке. SwiftyBeaver имеется приложение для macOS, которое позволяет просматривать логи в реальном времени. Если вы когда-нибудь интересовались что же происходит в вашем приложении установленном на тысячи устройств, то теперь вы можете это знать.
Загрузите приложение SwiftyBeaver для Mac. Откройте его и заполните форму, чтобы создать аккаунт.


Далее вы будете перенаправлены напрямую в окно сохранения файла. Это немного странно, потому что они не сообщают для чего этот файл.

Назовите этот файл TenPMLogs, выберите любую локацию по своему усмотрению и нажмите Save.


Файл, которые в создали хранит логи для одного приложения, по этой причине вы и назвали его TenPMLogs. Когда вы открываете этот файл с помощью приложения SwiftyBeaver Mac App вы можете увидеть логи, связанные с приложением Ten PM.
После сохранения файла вам будет предоставлен выбор. Вы можете зарегистрировать новое приложение или просмотреть логи из ранее зарегистрированного приложения. Вы продолжите на вкладке New App.


Кликните по кнопке Generate New App Credentials. Вы должны увидеть следующий экран, показывающий сгенерированные идентификатор и ключи для вашего приложения:

Теперь пора добавить еще один destination для логов используя только что созданные учетные данные безопасности Crypto Cloud. Оставьте это окно открытым и вернитесь к методу setupSwiftyBeaverLogging() в AppDelegate.swift.

Добавьте эти строки в низ этого метода, заменяя строки на соответствующие значение из приложения SwiftyBeaver Mac App:

let platform = SBPlatformDestination(appID: "Enter App ID Here",
                                     appSecret: "Enter App Secret Here",
                                     encryptionKey: "Enter Encryption Key Here")

SwiftyBeaver.addDestination(platform)

Вернитесь в приложение SwiftyBeaver Mac App и кликнките по кнопке Connect. Теперь запустите приложение Ten PM.

Примечание: если вы сглупили как и я и нажали кнопку Connect до того как скопировали учетные данные в ваше приложение, вы можете кликнуть по кнопке настроек (шестеренка) в приложении SwiftyBeaver Mac App, чтобы посмотреть их после подключения.



Теперь проверьте это! Ваши логи появляются в приложении SwiftyBeaver Mac App. Если вы не видите записи сразу же, то не волнуйтесь. Иногда это занимает несколько минут прежде чем записи в журнале попадут в облако. В конечном итоге они все равно появятся.
SwiftyBeaver также автоматически предоставляет одночасовое хранение для ваших логов если вы не перешли на платный аккаунт. Для большинства задач отладки это не будет проблемой. Просто стоит это отметить в случае если вы задумываетесь почему ваши более старые логи больше не видны.

Фильтрация логов по уровню логирования, избранным записям и минимальным уровням логирования

По настоящему классная вещь в SwiftyBeaver Mac App это возможность фильтровать логи по уровню логирования. Это значительно упрощает процесс копания в логах, чтобы найти причину критической ошибки.
Возможно вы уже заметили разные вкладки вверху. Каждая из этих вкладок представляет уровень логирования. Вы можете просматривать несколько уровней за раз или вы можете просматривать только предупреждения и ошибки.
Также вы можете пометить запись как избранную. Вы можете видеть все избранные записи по клику на звезду в левом меню.

Фильтрация по минимальному уровню логирования

Это еще одна особенность, которую вы действительно полюбите. SwiftyBeaver позволяет вам установить минимальный уровень для заданного destination. Если вы хотите использовать ваш Crypto Cloud аккаунт для серьезных предупреждений и ошибок вы можеет это сделать.

Для начала замените текущий код логирования в applicationDidFinishLaunching() на следующий:

SwiftyBeaver.verbose("Watch me bloviate. I'm definitely not important enough for the cloud.")
    
SwiftyBeaver.debug("I am more important, but the cloud still doesn't care.")
    
SwiftyBeaver.info("Why doesn't the crypto cloud love me?")
    
SwiftyBeaver.warning("I am serious enough for you to see!")
    
SwiftyBeaver.error("Of course I'm going to show up in your console. You need to handle this.")

Сейчас вы логируете сообщению на каждом уровне. Запустите приложение и вы должны видеть как все эти записи попадают в Crypto Cloud.



В методе setupSwiftyBeaverLogging() добавьте следующее перед тем как добавляете эту платформу в destination:

platform.minLevel = .warning

Запустите приложение снова. Посмотрите на новый вид вашей консоли Crypto Cloud.


Вы должны видеть только предупреждения и ошибки за последнее время. Никаких других записей не попадет в Crypto Cloud. Вы по прежнему видите все в консоли Xcode!

Примечание: Вы можете задать минимальный уровень для любого типа логирования (destination) в SwiftyBeaver. Вы можете создать несколько Crypto Cloud журналов для различных уровней логирования. SwiftyBeaver имеет большой простор для разных способов логирования.

Исправление труднодоступных ошибок

Было весело поговорить о логировани в Crypto Cloud, но у вас есть некоторые зловещие ошибки, которые вам нужно исправить. Ну или как минимум у вас есть зловещие ошибки, которые вы намерено смоделируете и затем исправите их.
Начните с очистки всех ранних записей. Удалите все логирование из application(_:didFinishLaunchingWithOptions:). Также удалите установку значения для platform.minLevel чтобы по умолчанию отображались все записи.
Для этого теста вам нужно будет видеть все записи в логах.

Моделирование ошибки

Теперь вы готовы к использованию облачного логирования и это самое время чтобы смоделировать неприятный фоновый баг.

Откройте LocationTracker.swift и найдите там метод locationManager(_:didUpdateLocations:). Вставьте туда следующий код после объявления двух guard значений в верхней части метода:

let bug = true
        
if bug == true {
  return
}

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


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

Отслеживание ошибки с помощью SwiftyBeaver

Как теперь мы могли бы отследить эту ошибку с помощью SwiftyBeaver?
Если вы получили отчеты об ошибках в неудавшемся отслеживании местположения, но не имеете никаких хороших предположений об ошибке добавьте логирование везде где только можно, чтобы получить как можно больше информации от пользователей.
Для начала импортируйте SwiftyBeaver в верхней части LocationTracker:

import SwiftyBeaver

Далее добавьте запись вверху метода locationManager(_:didUpdateLocations:):

SwiftyBeaver.info("Got to the didUpdateLocations() method")

Теперь добавьте несколько строк внизу и вставьте эту строку прямо после объявления константы bug:

SwiftyBeaver.debug("The value of bug is: \(bug)")

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

SwiftyBeaver.error("There's definitely a bug... Aborting.")

И наконец, добавьте запись в конце метода locationManager(_:didUpdateLocations:):

SwiftyBeaver.info("Got to the end the didUpdateLocations method")

Этой информации должно быть достаточно, чтобы начать вычислиение что же происходит в вашем коде. Вот как должно выглядеть все содержимое метода locationManager(_:didUpdateLocations:):

SwiftyBeaver.info("Got to the didUpdateLocations() method")

guard let homeLocation = ParentProfile.homeLocation else {
  ParentProfile.homeLocation = locations.first
  return
}

guard let safeDistanceFromHome = ParentProfile.safeDistanceFromHome else {
  return
}

let bug = true
SwiftyBeaver.debug("The value of bug is: \(bug)")

if bug == true {
  SwiftyBeaver.error("There's definitely a bug... Aborting.")
  return
}

for location in locations {
  let distanceFromHome = location.distance(from: homeLocation)
  
  if distanceFromHome > safeDistanceFromHome {
    NotificationCenter.default.post(name: TenPMNotifications.UnsafeDistanceNotification, object: nil)
  } else {
    NotificationCenter.default.post(name: TenPMNotifications.SafeDistanceNotification, object: nil)
  }
}
SwiftyBeaver.info("Got to the end the didUpdateLocations method")

В симуляторе установите местположение в Apple также как делали это ранее. Теперь запустите приложение. Не смотря на то, что сейчас вам доступны логи в консоли Xcode проигнорируйте их и представьте, что вы отслеживаете записи в Crypto Cloud от удаленного пользователя.
Введите безопасное расстояние в 1 километр и нажмите NEXT. После загрузки карты смените ваше местоположение на широту 37.3397 и долготу -122.0426 через особое местоположение.
И снова вы вышли за пределы вашей безопасной зоны без обновления текста.


Вы должны заметить следующие записи, повторяющиеся в SwiftyBeaver Crypto Cloud после того, как установите фильтр в ALL:


Воу, это действительно полезно! Если вы вернетесь к своему коду в классе LocationTracker то сможете сопоставить это с логами и вы увидете как далеко проходит выполнение вашего кода прежде чем оно остановится. Здесь это явно в if bug == true где была запись об ошибке была выведена.
Чтобы «исправить» эту «ошибку» просто установите константу bug в значение false где она объявляется в методе locationManager(_:didUpdateLocations:):

let bug = false

Запустите приложение. Смоделируйте начальную позицию в Apple со смещением за пределы безопасной зоны. В этот раз вы увидите предупреждение о безопасной зоне, которое сработало правильно.
Также вы должны видеть следующие записи в вашей Crypto Cloud консоли.


Это выглядит так как будто приложение миновало ошибку и снова успешно реагирует на изменения местоположения. Вы успешно исправили эту ошибку!

Куда дальше?

Вы можете найти завершенный проект к этому уроку здесь.
Также ознакомьтесь с файловым логированием с помощью SwiftyBeaver. Если у вас есть iPhone и вы хотите быть на 100% увереным, что получите все свои записи (даже если нет Интернет-подключения).
Для более интересных случаев ознакомьтесь с форматированием записей.

https://habrahabr.ru/post/333852/

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

Предыстория

В этот раз для нас всё было довольно просто. Несколько выпускников нашей программы «Специалист по большим данным» в течение, наверное, года просили:

Сделайте для нас еще одну программу, где мы бы могли научиться работать с Kafka, Elasticsearch и разными инструментами экосистемы Hadoop, чтобы собирать пайплайны данных.

Потом со стороны работодателей стали «прилетать» запросы, которые собирательно можно описать так:

Data Engineer'ы – это очень горячие вакансии!
Реально их уже на протяжении полугода никак не можем закрыть.
Очень здорово, что вы обратили внимание именно на эту специальность. Сейчас на рынке очень большой перекос в сторону Data Scientist'ов, а больше половины работы по проектам – это именно инженерия.

С этого момента стало понятно, что спрос есть, и проблема существует. Надо бросаться в разработку программы!

Интересный момент в разработке образовательной программы, что ты её валидируешь не у непосредственного потенциального клиента. Ну представьте, мы подходим к человеку, который хотел бы у нас учиться, и спрашиваем: «Вот это — то, что тебе нужно?» А он вообще без понятия, потому что пока не разбирается в этом.

Поэтому программу нужно валидировать, во-первых, у тех, кто в этом разбирается — реальных data engineer'ов; во-вторых, у работодателей — ведь, это они в конечном счёте потребители нашего продукта.

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

Программа

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

Конкретизируя, получилось, что он должен уметь:

1. Собирать сырые данные
2. Работать с очередями и их конфигурировать
3. Запускать джобы с обработкой данных (в т.ч. ML) по расписанию
4. Конфигурировать BI
5. Работать с реляционными БД
6. Работать с noSQL
7. Работать с инструментами для real-time обработки
8. Пользоваться command-line tools
9. Работать грамотно с окружением

В каждом из этих пунктов можно записать целый ряд различных инструментов. Есть даже прекрасная визуализация на эту тему. Их все охватить в программе не представлялось возможным, да и нужным, поэтому мы решили, что человеку достаточно получить опыт создания одного batch- и одного real-time пайплайна. Остальное, при необходимости, он самостоятельно в будущем освоит.

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

Генератор кликов

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

1. поскольку один из пайплайнов должен быть real-time, то статические готовые датасеты нам не подходят, нам нужно как-то генерировать данные тоже в real-time,
2. поскольку мы решили, что участники должны строить пайплайн «от и до», то это значит, что они должны собирать данные прямо с сайта, как это они бы делали в реальной жизни.

Отлично, осталось придумать как. Часть дата инженеров подсказала, что можно смотреть в сторону инструментов для тестирования сайта — например, Selenium. Часть даже сделала уточнение, что лучше использовать PhantomJS внутри него, поскольку он «headless», а значит, будет быстрее.

Мы воспользовались их советом, и написали свой эмулятор пользователей для сайтов наших участников. Сам не-ахти-какой-код ниже (важно: мы выдадим один и тот же сайт всем, поэтому можем в коде использовать конкретные параметры поиска, зная структуру этого сайта):

from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
from numpy.random import choice
import time
import numpy as np

dcap = dict(DesiredCapabilities.PHANTOMJS)
dcap["phantomjs.page.settings.userAgent"] = ("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 YaBrowser/17.6.1.745 Yowser/2.5 Safari/537.36")
driver = webdriver.PhantomJS(desired_capabilities=dcap)
driver.set_window_size(1024, 768)

hosts = ["35.190.***.***"]
keywords = {"music": "песн", "grammar": "англ"}
conformity = 0.9
condition = 1

def user_journey(host, journey_length, keywords, user_type, conformity):
    driver.get("http://" + host)
    el = driver.find_element_by_link_text("Статьи") # начинаем наш journey со статей
    el.click()
    print driver.current_url
    for i in xrange(journey_length):
        try:
            links = []
            the_links = []
            p = 0
            P = []
            links = driver.find_elements_by_class_name("b-ff-articles-shortlist__a") # собираем список всех url на странице
            if len(links) == 0: 
                links = driver.find_elements_by_class_name("b-ff-mobile-shortlist__a") # если так не удалось, то другим способом
                if len(links) == 0:
                    links = driver.find_elements_by_class_name("b-ff-articles-tags__a") # если и так не удалось, то другим способом
                    links[0].click
                    driver.current_url
            the_links = driver.find_elements_by_partial_link_text(keywords.get(user_type)) # собираем все url, содержащие ключевик
            the_link = choice(the_links, 1)[0] # рандомно выбираем один из нужных url
            links.append(the_link) # добавляем к списку всех ссылок на странице
    
            p = (1-conformity)/float(len(links)-1) # рассчитываем равную вероятность для всех url, но учитывая, что у одной из них будет вероятность conformity
            P = [p]*len(links) # присваиваем всему списку одну и ту же вероятность
            P[-1] = conformity # у последнего элемента 'the link' меняем вероятность на conformity
            l = choice(links, 1, p=P) # делаем рандомный выбор ссылки с заданным списком вероятностей
            time.sleep(np.random.poisson(5)) # случайное время ожидания на странице
            l[0].click()
            print driver.current_url
        except:
            driver.close # закрыть драйвер, если что-то пошло не так

while condition == 1:
    for host in hosts:
        journey_length = np.random.poisson(5)
        user_type = choice(keywords.keys(), 1)[0]
        print user_type
        user_journey(host, journey_length, keywords, user_type, conformity)

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

Внутри типа мы тоже внедрили элемент случайности: пользователь одного типа не будет ходить по одним и тем же ссылками, которые бы мы прямо захардкодили, а ссылка будет выбираться рандомно из подмножества «правильных» ссылок + есть еще элемент случайности, когда пользователь будет попадать на «неправильные» ссылки. Это было сделано, потому что в будущем участники будут анализировать эти данные и пробовать как-то сегментировать этих пользователей.

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



Единственное, что группу в 20-30 человек с такой пушкой быстро не обработаешь, поэтому мы решили запускать этот скрипт через gnu parallel. Такая строчка позволяет запустить наш скрипт параллельно на всех доступных ядрах:

$ parallel -j0 python ::: cannon.py

Итог

1. Каждый участник поднимает у себя выданный нами сайт при помощи nginx.
2. Присылает нам ip-адрес своего сервера.
3. Внедряет на все страницы своего сайта javascript для сбора кликов.
4. Собирирает данные, прилетающие из нашей пушки на его сайт.
5. Передает в Kafka.
6. Ну и дальше по пайплайну...

Так начинается проект, над которым он будет работать в течение 6 недель на программе Data Engineer.

https://habrahabr.ru/post/334756/

С какой из зарубежных бизнес-конференций в ИТ можно сравнить широко известную в узких кругах полуклубную конференцию ISDEF и, вообще, насколько корректны подобные сравнения?

В июне этого года Константин Каплинский, CEO «ГлавСофт» и член правления Ассоциации ISDEF(Independent Software DEvelopers Forum), целенаправленно съездил на Business of Software Europe в Лондоне и делится впечатлениями.

Business of Software Europe

Мне интересны любые аналоги ISDEF. Business of Software Europe – это европейское отделение конференции: первая проходит в Европе, точнее, в Великобритании, а вторая — в США, в Бостоне. Европейскую часть я планировал посетить еще два года назад. Тогда не получилось, тем не менее, я начал следить за этим мероприятием. В итоге в этом году получилось убить сразу двух «зайцев», съездив в Лондон на конференцию и заодно навестив конкурентов в Кембридже, с которыми у нас хорошие отношения и с кем хотелось лично познакомиться.

Business of Software Europe по заявленным целям и тематике похожа на осенние события ISDEF. В первую очередь, это конференция, ориентированная на тех, кто делает бизнес на программном обеспечении. Сервисные компании также представлены на ней, однако их меньше.

Лидеров рынка — больших транснациональных корпораций — на Business of Software Europe нет. Представлены небольшие и среднего размера компании (при том, что выручка в среднем у них гораздо больше). Тем не менее, масштаб компаний вполне сопоставим с масштабами бизнесов членов нашего клуба.

Что касается keynote-выступлений, то на Business of Software Europe стараются приглашать знаменитостей с мировым именем. В этом году выступал Александр Остервальдер, известный своими книгами по построению бизнес-моделей. ISDEF, к тому же, организуется энтузиастами, а Business of Software Europe – коммерческая конференция, у которой есть большой бюджет и, соответственно, возможность приглашать именитых спикеров.

Атмосфера BoS Europe

Так же, как и ISDEF, Business of Software Europe имеет свой постоянный состав участников, которые ездят на конференцию из года в год. Царит рабочая атмосфера, все друг друга хорошо знают, много общаются, свободно знакомятся. Этим она не похожа на многие другие маркетинговые и технические конференции, где люди просто приходят-уходят, слушают, задают вопросы. На Business of Software Europe атмосфера в плане общения очень продуктивная. Мероприятие начинается с приветственной вечеринки, так же как это принято у нас на ISDEF, и все два дня конференция идёт примерно в том же русле.

Возможно, это разница менталитетов, но в России участники более расслабленны. На осенних ISDEF на доклады ходят не все, тогда как на Business of Software Europe, когда выступает спикер, в коридоре никого не поймаешь. Люди заплатили деньги и стремятся не пропустить ни одного доклада. [От редактора: в этом году были доклады от Twitter, Swiftkey (ныне Microsoft), PipeDrive, Balsamiq и другие. В целом спикеров гораздо меньше, чем на ISDEF — меньше 20 против традиционных 40-50 на нашей конференции по осени.]

Много абстракций

На Business of Software Europe обсуждают, как создавать, как продавать, как сделать продукт более полезным для пользователя. Юридические и бухгалтерские тонкости практически полностью отсутствуют. На самом деле это понятно — у них нет специфичного для России валютного контроля, нет проблем с получением денег из-за рубежа.
Чего на Business of Software Europe оказалось много, так это сомнительных абстракций, которые в России скорее бы отпугнули участников, чем заинтересовали. Много рассуждений на тему, как надо правильно думать, как представлять себе пользователя. Спикеры обсуждают ценности, культуру, миссии, способы мышления, которые бы хотелось немного приземлить.
Абстракции нужны, однако мне показалось, что с этим на Business of Software Europe перебор. На мой взгляд, все это не очень хорошо проецируется в практическую плоскость. ISDEF в этом плане – конференция с более практической направленностью.

Что полезного можно получить от участия в Business of Software Europe

Нельзя гарантировать, что участие в BoS Europe будет оправдано с практической точки зрения. Это интересно в плане расширения кругозора, когда ищешь какие-то новые идеи. Но постоянно ездить туда сложно, и будет дороже раза в четыре. На европейскую конференцию полезно съездить, просто потому что это все же другой масштаб, и можно найти для себя что-то полезное. Особенно если необходимо отвлечься от рутины, которая постоянно затягивает, подумать о стратегии, как достичь поставленных целей, как вырасти, масштабироваться и догнать европейские софтверные компании.

Владельцам небольших компаний, которые сосредоточены на развитии своих программных продуктов, стоит попасть сначала на ISDEF. Будет много кейсов, идей, легко применяемых на практике. При этом за совсем небольшие деньги.

https://habrahabr.ru/post/334762/

Когда Wi-Fi только появился на первых линиях метро, мы поняли, что превращаемся в героя Билла Мюррея из «Дня сурка». С той лишь разницей, что он каждый раз просыпался 2 февраля, а мы неделями пытались поймать поезда хотя бы одной ветки и залить на них одну и ту же конфигурацию. Настраивать ее вручную было плохой идеей — поезда уходили в депо и стояли там несколько дней.

Доктор, это лечится?

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

1) дорогие лицензии на такое количество оборудования, как у нас, — более 10 тыс. единиц;
2) не поддерживалось установленное на поездах оборудование RADWIN;
3) стандартные проблемы, связанные со спецификой нашей сети.

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

Тогда у нас уже был отдел разработки ПО. Почему бы не реализовать необходимую функциональность самим? Нужен сервис, который круглосуточно пытается подключиться к оборудованию до тех пор, пока не «зальет» на него скрипт с конфигурацией. Ни версионности, ни эталонной конфигурации. Только выполнение конкретного маленького скрипта.

Внесите в протокол: telnet/ssh и нюансы в восприятии команд

Оказалось, что курсы CCNA я проходил не зря. Благодаря им я знал, как настраивать оборудование Cisco. Кроме того, у меня был опыт разработки отдельных сервисов, которые «общались» с другими приложениями через консоль.


Времени на поиск идеального решения не было, и мы остановились на самом простом: автоматизировать то, что вручную вводит оператор через консоль.

Это общая схема:



Казалось бы, решение простое, проблем быть не должно, но нет. На его работу повлияла специфика отдельных типов оборудования.

Летим на Базу!

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

1) оборудование находится в вагонах со своим типом и номером;
2) поезда часто пересобирают из разных вагонов, поэтому мета-сущность поезда актуальна, только если он находится на линии, а, значит, на связи;
3) поезда ходят по линиям — в Москве их 13;
4) оборудование бывает разных типов и имеет разные настройки.

Кроме этого, мы придумали «виртуальные» поезда, и привязали к ним стационарное оборудование: базовые станции в тоннеле, оборудование станционных узлов и сетевых ядер.

Все по плану

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

Однако при настройке поезда целиком появляется зависимость между разными типами оборудования: так, чтобы не потерять доступность контроллеров при смене адресации, сначала нужно было настраивать поездные роутеры и только потом – контроллеры. У скриптов мы добавили признак активности и критерий “применять, только если оборудование на связи”. Здесь же решили на уровне логики сервиса обновлять параметр доступности оборудования при соединении с заданным IP-адресом.

Далее мы ввели таблицу задач, которые ссылались на скрипты и также имели признак активности и поле параметров. Ключевой из них – текст SQL-запроса на выборку идентификаторов устройств, на которые надо отправить конфигурацию. Использование именно такой схемы позволяло по любым признакам выбирать устройства из базы для конфигурирования выбранным скриптом.

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

Крючок для поездов

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


Главным недостатком конфигурации была скорость работы: большая часть оборудования была не на связи. Кроме того, из-за особенностей строения подсети управления, связь с оборудованием занимала несколько секунд. Мы задавали тайм-аут подключения от 30 секунд до 2 минут, и за сутки удавалось поймать максимум 20 поездов.

Очевидно, что ключ к повышению производительности – многопоточность. Опустим все сложности, с которыми я столкнулся при разработке многопоточного решения (кто пробовал делать нечто подобное под Windows, знают об этом не понаслышке). Желаемого результата мы достигли, и на виртуальной машине в 6 ядер сервис мог одновременно обрабатывать более 500 единиц оборудования.

Следующим шагом оптимизации стало выделение «легкой» задачи проверки доступности оборудования. Я написал отдельный запрос для всех типов “поездного” оборудования и задал периодичность раз в 30 минут. За это время либо один поезд уходит с линии, либо приходит новый. Включив соответствующий критерий в других задачах, я добился того, что опрашивались только единицы оборудования, которые находились на связи за последние полчаса. И в таком режиме мы продержались достаточно долго, пока не столкнулись с нюансами уже на уровне эксплуатации.

Эксплуатация, бессердечная ты… мука

За несколько лет существования сети мы создали и применили более 160 скриптов: у многих из них были сложные зависимости и необходимость последовательного применения на одном и том же оборудовании. В основном настраивали Access-List-ы и меняли правила QoS, но были и критические изменения, связанные с авторизацией и DHCP.

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

Другие проблемы были связаны с заменой физически неисправного оборудования. Эксплуатация меняла оборудование на новое с настройками “по умолчанию”, которые могли быть уже несовместимы с актуальной системой предоставления сервиса. Автоконфигуратор не исправлял подобные ошибки, т.к. считал, что оборудование настроено корректно. Со временем это стало существенной проблемой: пользователи могли ехать в поездах без Wi-Fi только по этой причине. Решением стала передача множества скриптов и правил в эксплуатацию, но человеческий фактор никто не отменял, и ошибки хоть и стали возникать реже, выявлялись все так же мучительно и долго.

Система СИ: общие требования к конфигурации, маркер версии на оборудовании

Тогда мы придумали “эталонный скрипт”, который приводит конфигурацию оборудования в нужное нам состояние. И для полного счастья нужно было придумать способ, сохраняющий метку конфигурации прямо на оборудовании. Для контроллеров мы стали использовать пустые ACL-и. Например, для версии от 1 января 2015 года мы создали ACL с именем «v2015010101» – этот параметр легко считать, а реализованное хранение логов применения скриптов прямо в базе позволило строить запросы на основании информации, собранной с оборудования сервисными скриптами. Итоговая схема конфигурирования стала такой:





Введение “эталонного скрипта” совпало с формированием доступных до авторизации сервисов, поэтому конфигурации могли меняться несколько раз в неделю. Разработанная система могла за пару минут изменить конфигурацию всего доступного оборудования в поездах. В этот момент у пользователей полностью пропадал Wi-Fi на несколько минут, в том числе переставал “светить” SSID Wi-Fi сети.

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

В результате мы поменяли схему еще раз. Сейчас эталонный скрипт запускается каждый день рано утром с открытием метро и “ловит” оборудование в поездах, которые только выходят на линии и оказываются в сети. Количество доступных попыток настроено так, чтобы к закрытию метро скрипт прекращал работу. Таким образом, поезда проверяются и настраиваются по мере выхода на линию без существенного влияния на пользователей сети. Такое решение позволило отказаться от второстепенного опроса доступности оборудования и снизило ресурсоемкость автоконфигуратора примерно в 5 раз.

Лучше, чем швейцарский нож

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

https://habrahabr.ru/post/334734/

В апреле совместно с МФТИ и компанией Contented мы запустили вводный курс по дизайну интерфейсов на образовательной онлайн-платформе Coursera. На нее зарегистрировалось более 8000 студентов. И это вдохновило нас на создание полноценной специализации «Дизайнер интерфейсов», состоящей из пяти курсов и защиты дипломного проекта. Программа подойдет как новичкам, так и квалифицированным UI- и UX-специалистам. За время обучения студент может практически с нуля достигнуть middle-уровня в области дизайна интерфейсов.

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

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

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

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

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

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

Выпускники, которые успешно прошли все курсы, сделали дипломную работу и получили сертификат, получат доступ к программе трудоустройства от Contented.

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

Зарегистрироваться на специализацию можно здесь.

https://habrahabr.ru/post/334718/

Многие дети российских 90-х с теплотой вспоминают часы, проведённые за приставками, — как с друзьями играли в «танчики», Батлтодс, Рокэнролл рэйсинг и кучу других игр. Уверен, что есть среди вас и такие, кто и до сих пор играет и коллекционирует классические приставки и игры для них. Что-то в них есть такое, что связывает с беззаботным детством.

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

Среди интересующихся ретрогеймингом есть мнение, что играть надо на оригинальном железе, а эмуляция — это не тру. Это означает, что если вы решили вспомнить былые деньки и погонять с друзьями в «Чипа и Дэйла», то будьте добры достать себе приставку (желательно оригинальную NES или Famicom) и пару картриджей к ней. В современном мире это не проблема — можно купить всё это на интернет-аукционах. Вопрос только в том, с какой суммой вы готовы расстаться.

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

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

Выход — собрать аркадный автомат самому

Из чего будет собран наш аркадный автомат

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

Какой джойстик использовать — не принципиально. На AliExpress уйма предложений разнообразных DIY-наборов. Мой выбор пал на этот.



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

• Я выбрал полноформатный вариант автомата. Его высота — около двух метров. Значит, можно не экономить на месте внутри автомата.
• С полноценным ПК проще в плане модификаций и подключения периферии.
• Так как для автомата нужен монитор 4:3, то не хочется создавать себе проблему подключения старого монитора по HDMI.
• Мне системный блок достался дешевле, чем одноплатный компьютер.

Мощность в этом случае не сильно-то и важна. Скажу лишь, что я использовал ПК на Core 2 Duo, 1GB RAM, 120GB HDD.

Что касается монитора: пробежавшись по комиссионкам, максимум, что я смог найти подходящего — это 20-ти дюймовый монитор HP L2035. Главным критерием было соотношение сторон 4:3. Ну а бонусом оказалась удобная конструкция, которая крайне удачно поддается модификации.

Последняя крупная часть автомата — его корпус. Без него это просто ПК. Собрать его я решил из ЛДСП — чтобы надежно.

Сборка корпуса

Кажется, самая сложная задача, которая предстоит решившему сделать игровой автомат, это сборка корпуса для автомата. Звучит несложно — фактически надо просто построить шкаф, в который будет установлен ПК и встроен монитор. На деле всё чуть сложнее — готовые чертежи с размерами найти сложно (или я плохо искал). То, что нашёл, позволило набросать кривую 3D-модельку.



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

Чтобы это сделать, нужен конкретный список деталей с точными размерами. Поэтому вспоминаем студенчество и «Компас» и рисуем чертёж боковой панели. Отмечаем на ней все внутренние детали. Вот уже с этими артефактами можно идти в любую компанию, которая продаёт ЛДСП режет такие плиты.

Вот что получилось конкретно у меня: раскрой и чертёж



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

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

Я выбрал последний вариант, так как он самый каноничный и у меня был доступ к инструменту.

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



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

Резюмирую алгоритм:

• Заказываем раскрой ЛДСП по списку деталей.
• Покупаем кант (врезной, накладной или ленту).
• Покупаем расходники (евровинт, мебельные петли, замки на дверцы если надо, решетки вентиляции и прочее).
• Заказываем оргстекло по размерам.
• Вооружаемся дрелью, шуруповертом, электролобзиком, фрезером (опционально).
• Тратим непрогнозируемое количество времени на сборку корпуса.
• Profit!

Софт

Так как внутри автомата в моей версии — ПК, то встаёт вопрос выбора операционной системы. Поставленную задачу можно решить как на Windows, так и на Linux. Последний вариант мне как-то ближе (и покупать систему не надо), поэтому расскажу немного о том, как развернуть всё на Linux. Наиболее подходящий, на мой взгляд, для этой цели дистрибутив — Lubuntu 16.04 LTS.

Важный вопрос — это удобство выбора и запуска игр, хочется управлять автоматом исключительно с помощью установленного джойстика. Для этого нужна своеобразная frontend-оболочка, в удобном виде показывающая список игр и по требованию запускающая эмулятор с выбранной игрой. Благо Open source-сообщество уже давно решило эту задачу. Как говорится: «всё уже написано до нас». Например, у проекта Attract-mode есть версии под все популярные платформы, в том числе интересующую Ubuntu. Оболочка поддерживает темы оформления, которые, кстати говоря, написаны на Squirrel, так что любителям модификаций будет, где развернуться. Ну или можно посетить форум проекта и найти что-нибудь по душе.

Работа с оболочкой предельна проста: после запуска нажимаем tab и попадаем в меню. В первую очередь настраиваем эмуляторы — пути к играм и всяческим красивостям: логотипам, видео-превью, обложкам, постерам. В зависимости от темы могут использоваться разные красивости. Их, кстати, можно попробовать стянуть с помощью встроенной функции scrape artwork. Не надо думать, что найдется всё, но для большинства популярных игр всё приедет автоматом. Для поиска видео-превью игр можно ещё воспользоваться проектом Progettosnaps.net — ребята собрали очень большую коллекцию видео и распространяют её абсолютно бесплатно.

После настройки путей надо обязательно прожать пункт generate romlist — после того как, счётчик дойдет до 100%, автоматически будет добавлен экран (display) данного эмулятора. Выйдя из меню, на этом экране уже можно полистать список игр и попробовать что-нибудь запустить.

Основным эмулятором станет известный MAME — благо, его сборка существует и под Linux. Для меня стало открытием, что ромы для этого эмулятора так же версионированы, как и сам эмулятор, так что не получится на новом эмуляторе запустить ром со старой версии. Но так как версию рома узнать не получится, придётся качать много апдейт-паков и обновлять ромы, которые вы выберете для своего аркадного автомата. Много ромов и апдейтов к ним можно найти на проекте Emuparadise.me.

Для разнообразия можно поставить ещё несколько эмуляторов: nestopia, gens, zsnes и настроить их в attract-mode.

Есть небольшой нюанс — не во всех эмуляторах есть возможность замапить выход из эмулятора на кнопку джойстика. Он решается установкой пакета antimicro, который висит в процессах и мапит кнопки джойстика на кнопки клавиатуры: просто выбираем кнопку на джойстике и мапим её на Esc.

Остается только сделать так чтобы attract-mode и antimicro запускались сразу при логине и всё!

Провода и прочее

Итак, у нас уже есть корпус и настроенный ПК, Всё, что нам осталось, это встроить джойстик, колонки, свет и развести провода внутри корпуса.
Встроить джойстик в автомат, вернее, в панель управления, не составит труда. Фактически надо просто насверлить отверстий необходимого размера. А вот расположить их — процесс творческий и поле для экспериментов. У меня получилось вот так:




Чертежик можно посмотреть тут

Для подсветки лого я использовал метра два LED-ленты 12V (потому как проще всего запитаться от блока питания ПК).

Колонки проще взять с питанием от USB — как-то комфортнее работать с 12V вместо 220V.

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

Выносим на панель:

• кнопку включения из системника;
• регулятор уровня громкости;
• выключатель звука (просто впаиваем тумблер в цепь питания колонки);
• выключатель подсветки.

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

Вместо заключения

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

В итоге аркадный автомат переехал в офис «2ГИС» на 20 этаж и в данный момент причиняет добро и наносит радость всем желающим. По ощущениям очень много людей пробует играть в автомат. После работы стабильно можно застать кого либо, пытающегося найти именно ту игру из своего детства, даже были заказы что-то добавить. Вечером в пятницу небольшая толпа людей создает ощущение маленького аркадного зала. Мне кажется именно таким оно и было — когда ты ждешь своей очереди поиграть автомат — с интересом наблюдаешь как играют твои друзья и искренне переживаешь с ними особо сложные моменты.

Ну всё, с обязательной программой закончил, теперь произвольная часть.

https://habrahabr.ru/post/334752/

Мы, дети 90-х, любим добавить в задания NeoQUEST что-нибудь олдскульное. В этом году нам вспомнились гремлины, и мы добавили их в легенду одного из заданий соревнования «Очной ставки» NeoQUEST-2017.

Однако, под внешне забавной легендой скрывается вполне себе реальная практическая задача: а что, если привычные ELF-файлы — не просто исполняемые файлы, а контейнеры, открыть которые нам предстоит? Для этого придется испытать довольно-таки обширные возможности objcopy и освежить в памяти организацию ELF-файла.

Чтобы вычислить подозрительные секции, необходимо представлять секционный и сегментный состав типичного ELF. Помимо этого, конечно, пригодится и опыт — например, общение с firmware embedded-систем вполне может подсказать подходящие идеи!

Думаете, готовы на 100%? Уверены, что гремлинам удастся вас удивить спрятанными архивами, попорченными таблицами символов, а также аудиофайлами, которые зазвучат только в руках умелого мастера! Под катом — исходники к заданию и прохождение, чтобы каждый читатель Хабра мог собственноручно попробовать пройти задание!

Исходные данные к заданию

Легенда к заданию выглядела так:
Прибыв на место, мы обнаружили, что на базе полнейший хаос и разруха. Все это устроила парочка местных аборигенов, очень похожих на гремлинов из известного земного фильма. Один из них явно был главным в этой небольшой банде, более крупный, наглый и разговорчивый:
— Hehehehehehe, we had ate your message! Had ate this stupid gremlin! And will eat you!
Второй, мельче и скромнее, держался позади своего товарища и периодически выкрикивал:
— The Gremlins Are Coming!

Похоже, эти паршивцы не только устроили хаос и разруху, повредили оставленное нам сообщение, но еще и товарища своего слопали…

Исходные данные — три файла: greik, straip и message.

Исходя из легенды, понимаем, что самый важный файл — message, и нужно его прослушать. Но, само собой, он не работает (иначе в чем смысл задания?). Если запустить его, получим следующую информацию:

Sorry, but i'm lost my prepare section...

Чтобы починить наше сообщение, надо «распотрошить» двух гремлинов, которые всё
«погрызли», в том числе, и своего товарища. Запустим каждый файл. После ./greik увидим:

The Gremlins Are Coming! (оригинальная цитата из фильма, между прочим!)

После ./straip:

Hehehehehehe, we had ate your message! Had ate this stupid gremlin! And will eat you!

То есть, всё то, что описано в легенде. Раз эти гремлины съели всё необходимое для прохождения задания, нужно посмотреть, что у них внутри! Применим утилиту readelf на оба файла. Нас будут интересовать только секции файла и информация о них, поэтому
необходимо использовать флаги -SW. В результате получим для straip:



Обратим внимание на секцию 28, stomach (желудок!). Сдампим ее. Для этого можно
воспользоваться либо утилитой dd, высчитав все необходимые смещения, либо утилитой objcopy следующим образом:

 objcopy -O binary --only-section=.stomach --set-section-flags .stomach=alloc straip stomach

Аналогичные действия произведем для файла greik. Выдача readelf -SW:



Дампим секции 28 и 29 (.first_stuff и .second_stuff):

objcopy -O binary --only-section=.first_stuff --set-section-flags .first_stuff=alloc greik first_stuff
objcopy -O binary --only-section=.second_stuff --set-section-flags  .second_stuff=alloc greik second_stuff

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

stomach: Zip archive data, at least v2.0 to extract
first_stuff: data
second_stuff: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Разархивируем stomach и, используя утилиту file, посмотрим, что за файлы мы получили:

sec1: data
piece2: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
key1: ASCII text

Ура, получили промежуточный ключ key1 («ISCJcPhB33cAvq9F9YkaZyU91SfwSObn»)! Остальные файлы необходимы для дальнейшего решения задачи. Исходный файл message сообщал, что у него потеряны секции, и из архива мы извлекли файл с именем sec1.

Применим утилиту readelf на message:



Видим, что имеется секция .extract (16) размером 0x50 (80). Также у нас есть один из извлеченных из гремлинов файлов размером 0x50 — first_stuff. Восстановим эту секцию:

objcopy --update-section .prepare=first_stuff message

Снова запустим message:

Preparing data for extract…
Preparing data successful
Sorry, but i'm lost my extract section...

Ему не хватает еще одной секции. По аналогии с предыдущей секцией восстанавливаем и эту:

objcopy --update-section .extract=sec1 message

Снова запускаем message:

Preparing data for extract…
Preparing data successful
Extracting key data…
Extracting complete successful

Все выполнилось. В результате получили аудио-файл message.mp3. Однако, если попытаться его прослушать, мы услышим лишь тишину, потому что данные нулевые. Вспомним, что straip
говорил нам, что они сожрали еще одного гремлина, и у нас осталось два неиспользованных файла в формате ELF.

Запуск их не даст ничего, кроме ошибки:

Failed to execute process './second_stuff'. Reason:
exec: Exec format error
The file './second_stuff' is marked as an executable but could not be run by the operating system.

Это все потому, что эти объектники необходимо слинковать друг с другом:

gcc second_stuff piece2 -o gremlin

В результате получим:

piece2: In function `main':
gizmo.c:(.text+0x5b): warning: the `gets' function is dangerous and should not be used.
gizmo.c:(.text+0x86): undefined reference to `get_back_function'
collect2: error: ld returned 1 exit status

И снова все не так, как должно быть! Используем утилиту readelf на наши «куски» гремлина, но на этот раз посмотрим таблицу символов (ключ -s). Для second_stuff:



Для piece2:



Видим, что в одном из них есть наша функция get_back_function, на которую ругался компилятор, а во втором есть некая функция с именем «a4f922hjd9843jd». Переименуем ее в get_back_function:

objcopy --redefine-sym a4f922hjd9843jd=get_back_function second_stuff

Попробуем повторить сборку файла:

gcc second_stuff piece2 -o gremlin

piece2: In function `main':
gizmo.c:(.text+0x5b): warning: the `gets' function is dangerous and should not be used.

Как видим, теперь все хорошо. Запускаем gremlin:

Hello… I tried saved your message, but forgot my name… Remember my name, plese and I can get back part of your
>>

Парниша вроде неплохой: пытался спасти наше сообщение, за что и пострадал. Готов все нам вернуть, да вот только своё имя забыл. Имя его Gizmo (оригинальное имя хорошего гремлина из фильма). Это можно увидеть как еще в процессе сборки, так и в любом HEX-редакторе в самом начале как исходных объектников, так и самого файла gremlin.

Введем его имя (с большой буквы, конечно!), ииии…

Hello… I tried saved your message, but forgot my name… Remember my name, please and I can get back part of your
>> Gizmo
Yes, yes! It's my name! Get back your part of file!

В результате получим еще один файл data_section. Легко догадаться, что и его мы запихиваем в исходный файл message:

objcopy --update-section .key=data_section message

Эту секцию .key можно было заметить еще когда мы исследовали утилитой readelf файл message. Во-первых, имя у нее говорящее, во-вторых, размер совпадает с тем, что вернул нам Gizmo.

Запустив файл message еще раз, мы уже получим нормальное сообщение, которое можно
прослушать. Там сказано, что нам необходимо взять md5-хэш от этого файла и это будет ключом. Берём md5 и получаем ключ: 65935b0ae91b566c14c8b584ee8cf85d.

Happy End!

Оказывается, ELF-файл может быть далеко не просто исполняемым файлом, а контейнером для чего-либо. Это задание можно было пройти, выполнив реверс бинарников, но не реверсом единым сильны специалисты по инфобезу!

В данном варианте прохождения достаточно нескольких нехитрых манипуляций — и ELF-ский пазл успешно сложен, секции и таблицы символов восстановлены, архивы распакованы, а нашим гремлинам не остается ничего, кроме как сменить внушительное «The Gremlins Are Coming!» на белый флаг и выдать долгожданные ключи!

https://habrahabr.ru/post/332918/

^{Для понимания статьи стоит знать правила игры «Мафия». Пример правил можно прочесть тут.}

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

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

Тогда я предложил вожатым как-нибудь видоизменить игру Мафия, чтобы добавить ей жизни. «Но как мы можем изменить игру Мафия?» — спросили меня вожатые. Я задумался…

Ранняя попытка изменить игру Мафия

Какое-то время назад я проводил видоизменённую Мафию на команду из 14-ти человек. Тогда, чтобы закрепить информацию про одну преступную организацию 19-ого века^EN, я внёс в игру довольно маленькое изменение: Я повесил на стену самодельный календарь и перед началом игры объявил, что Мафия не сможет убивать в один определённый день недели, как и некоторые члены той преступной организации.

Сразу скажу, что игра прошла так себе — я зачёркивал на календаре каждый ход по одному дню. Учитывая то, что каждую ночь мафия убивала одного мирного жителя, и каждый день мирные жители убивали одного подозреваемого, то на всю игру уходило меньше недели. А значит день, когда нельзя было убивать, наступал всего один раз за игру. Фишечка не выстрелила, но ребята с удовольствием поиграли в Мафию. Как обычно.

Мафия на 100 человек

^{Да, это не опечатка, игра действительно изначально планировалась на 100+ человек. Но удалось её провести только на 52, поэтому я пишу в заголовке о том, о чём точно могу говорить.}

Придумывание изменений

Первое, от чего я хотел избавиться — вылет из игры. Я считаю, что нелюбовь к играм на вылет, это не моя личная прихоть, а это объективная и важная часть придумывания любой игры, которую должен понимать каждый создатель игр. Как-никак, основная цель любой игры — развлечь людей. А когда человек вылетает из игры, то мы лишаем возможности получать удовольствие человека, который хотел его получить. Он оказывается наравне с человеком, который изначально вообще не хотел играть, и тупо сидел в углу и смотрел, как играют другие.

Вылет из игры

В игре Мафия это особо заметно — в первый же день выбывают 1-2 человека, которые потом вынуждены ждать, пока игра окончится и начнётся занова, чтобы наконец-то поиграть.


Но чем можно заменить смерть? Тем более, когда она является основной механикой игры.
Я подумал о депортации. Это как раз подходит к сеттингу, что группа людей является географической локацией — городом. Дальше нужно просто придумать, чем занять депортированных людей на этой локации, чтобы для них игра продолжалась.

Я собирался проводить игру на pre-camp'е (несколько дней до лагеря, когда идёт подготовка) для вожатых; и посчитал, что вожатых со всем остальным стаффом будет около 100 людей _{(я ошибся, но об этом ниже)}
Так почему бы не провести игру для всех сразу? Я разделю людей на группы, в которых они будут играть в обычную мафию, с обычным числом людей, но вместо того, чтобы убивать людей, они будут депортировать людей в другую группу. Отличный способ избавиться от мафии на своей локации, и в то же самое время усложнить игру другой группе, если в игре будет соревновательный элемент.

Соревновательный элемент

Если никто в Мафии не умирает, то нужно какое-то другое условие победы. Но, чтобы с локации всё ещё нужно было стараться изгнать мафию, а ошибочная депортация мирных жителей ухудшала ситуацию для остальных мирных жителей. Пусть они соревнуются, какая локация соберёт больше денег. Каждый игрок будет проносить в казну локации 100 условных единиц денег каждый день. А мафия, значит, будет их воровать.

Что делать мафии

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

Загадки

Не хотелось бы, чтобы получилась игра с полной информацией, ибо всегда есть игроки, которым нравятся скрытые элементы игры, в которых нужно разбираться. По-этому я решил, что мирные жители не будут точно знать, сколько на их локации находится мафий. Но они будут знать, что это можно высчитать по какой-то формуле.
Благодаря этому в игре могут появиться негласные роли. Такие, как человек, следящий за приростом денег, и старающиеся по этой цифре вычислить количество мафий _{(так и вышло)}

Сеттинг

Итак, у нас есть основные механики игры. Нужна сеттинг — окраска, в которой всё будет происходить. Темой лагеря была «Америка 20-ого века», и я подумал, что к нашей механике неплохо подойдут колонии Британии. Америка, Ямайка, Нигерия, ЮАР, Индия, Австралия. Темы лагеря вообще не обязательно было придерживаться, ведь игра для вожатых, так что несоответствие временного промежутка не критично. И так, каждая локация — одна из колоний Британии. Ведущие (я и напарница) — сама Британия. Так же, в каждой колонии будет по наместнику Британии — локальному ведущему, который будет вести игру в конкретной колонии — следить за тем, кого и куда депортирует мафия ночью, и кого — мирные жители днём. Так же, эти люди смогут ведущим сообщать важную информацию для подсчёта денег — количество мирных жителей и мафии за конкретный день.

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

$$

^{Формула работает, и её не так уж сложно вычислить игрокам при помощи реверс-инжинеринга.}

Эта формула была известна только мафии. Мирным же жителям нужно было дойти до неё логически-математическими рассуждениями.

Чтобы избавиться от этой проблемы, я решил сделать одной из колоний аутентичную колониальную Австралию. Она изначально будет пустой, и прибывая в ней мафия будет обычными мирными жителями. Так колонии, высылая заключённых в Австралию, будут сильно уменьшать прирост денег в общаг мафии. Более подробные правила Австралии будут лежать в самой Австралии, и о них будут знать только люди, побывавшие в ней.

Подготовка

На подготовку не хотелось тратить слишком много времени. Как-никак игра проводится один раз, и для вожатых.

Карты

Нужен способ распределить роли. Играя в маленькой группе, подходят и простые похлопывания игроков, пока у них закрыты глаза… Но это не честно, и нельзя проверить, если кто-то жульничает. По-этому лучше иметь карты с ролями. Конечно можно раздавать и не карты, а просто бумажки… Но согласитесь, что карту держать в руках приятнее. А ещё её можно утащить с игры как сувенир.

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

^{По законам жанра — вся полезная информация на карте.}

Ролей было всего две — мафия и мирный житель. Большее количество ролей бы сильно тормозило такую большую игру. Но для окраски я решил добавить ничего не значащие профессии мирным жителям. Согласитесь, что приятнее быть хоть немного уникальным «Лавочником», чем серой массой «Мирных Жителей».

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

Деньги

Было решено, что каждая колония будет зарабатывать свои отдельные деньги, и мафии всех колоний вместе будут воровать деньги в один общаг. Но как это отобразить, чтобы игроки видели состояние игры? У меня в распоряжении для игры был проектор, так что тут дело переходит к вопросу программирования.

Microsoft Excel

Разумеется, первое что приходит в голову: Сделать всё в Microsoft Excel. Он уже умеет делать различные вычисления, и можно сделать так, чтобы их результат красиво отображался на экране. Но так как вычисления происходят раз в день, должны храниться промежуточные результаты вычислений (чтобы показывать сумму за все дни), и входная информация постоянно меняется (количество мирных и мафии), то всё равно придётся использовать VBA.
Конечно это вариант, который даже будет работать. Но есть вариант получше.

Unity3D

У меня уже был опыт в использовании Unity3D для отображения состояния игры на проекторе. И хоть с Юнити придётся писать большее количество математики вручную, у Юнити есть одна килер-фича, из-за которой я буду всегда использовать именно Unity3D для подобных проектов: Поддержка двух мониторов, с отображением разной информации на каждом мониторе. Это значит, что пока игроки будут видеть только общее число денег каждой колонии, и общее количество игроков каждой колонии, я на своём ноутбуке смогу видеть информацию, которая им не должна быть известна — количество мафий в колонии, и количество украденных денег. А так же, кнопки управления, которые бы только ухудшали внешний вид игрового экрана.

Так это выглядит в редакторе:

<sup>Слева — экран ноутбука. Справа — проектор.


Отдельно экран ноутбука</sup>

Правила Австралии

Как я писал выше, в Австралии лежит листик, с более подробными правилами. Игрокам же в начале игры объясняется минимум, и обращается их внимание на то, что Австралия в начале игры пустая.

Проведение

В целом игра прошла хорошо. Не считая того, что, как я писал выше, я рассчитывал на 100 человек, а их было чуть больше 50-ти. А это значит, что почти в каждой колонии было изначально всего 10 человек (не считая пустой Австралии) из которых было две мафии. Для более интересной игры, нужно было бы иметь хотя бы по три мафии в колонии, но на 10 человек, это бы нарушило всю математику.

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

Итог

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

https://habrahabr.ru/post/334450/

Подозреваю, что довольно значимая часть читателей поста младше, чем эти операционные системы. Но на них в закромах Родины ещё бегает наш российский (и не только) софт. Да и вы наверняка нет-нет, да видели DOS-приклад на рабочих местах Сбербанка или в больницах.

Есть такие Power-машины, которые предназначены для расчётов больших и тяжёлых штук. На них работает приклад, который не может быть запущен в обычном кластере, как правило — банковские системы и всякие биржевые штуки. Проблема в том, что современные гипервизоры создают виртуальную машину не больше, чем физический сервер, где они стоят. А один физический x86-сервер для таких задач мелковат. Поэтому и используется архитектура x64 (RISC).

Одинаковые по суммарной производительности системы на x86 и x64 отличаются по цене в десятки и сотни раз. Казалось бы, никаких проблем: надо переписать софт так, чтобы он мог работать в сотни потоков и встать в кластер или облако, да?

Ага, сейчас! Программистов, кто это писал, уже нет. Исходники обычно утеряны или же написаны на языках времён мезозоя. Даже документации обычно нет. Поэтому знаете, что мы делаем? Мы заворачиваем гипервизор в гипервизор. О, это отдельная песня. Сейчас расскажу.

Куски мамонта

Да, чёрт побери, заворачиваем гипервизор в гипервизор. Типичная задача — нужно отмигрировать что-то на тот же Huawei х86. Вообще, коммерческих архитектур, которые позволяют получать реально очень большие кластеры, хорошо подходящие для таких задач, всего три — это Супердом, кластер Фуджитсу и кластер Huawei. Отдельно есть ещё решения, но у этих трёх архитектуры похожи и близки к оптимальным по масштабированию. В нашем случае Huawei оказался выбран под проект по двум причинам:
— Цена при заданной стабильности.
— Совместимость со старыми ОС на уровне драйверов и т. п., то есть возможность миграции.



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

На очереди на тестовые внедрения Huawei стоят два крупных заказчика, поэтому тема очень горячая.

Теперь диспозиция. У заказчиков инфраструктура устоялась, баги пойманы, совместимость достигнута, поэтому действует главное правило разработчика: «работает — не трогай». В банках оно ох как важно. Взять и проапдейтиться на новую версию — это квест длиной в миллион страданий.

При этом обратите внимание это не значит, что они не переносят ничего. Те же базы с AIX’а P-серии на Linux x86 они очень быстро переделывают и накатывают — это уже отработанная процедура во многих банках.

Боль в прикладе и СУБД. Не всегда внешние NIX’ы могут работать с СУБД из-за отличия хранимых процедур и кучи других проблем совместимости. Как следствие, начинается допиливание до консистентного состояния. Если RISC-машины уже давно в этом плане устоялись, то разработчики кластеров х86 в сфере новички, и наступили ещё не на все грабли. Главное — не поддерживают фичи глубоко старого NIX, а в банках или промышленности иногда стоят совсем старые версии.

И именно в этот момент мы начинаем заворачивать гипервизор в гипервизор, Джонни! Не всегда, конечно, а только тогда, когда принимается решение, что конкретно этот приклад лучше не трогать, а то все помрут. Выглядит это так:

1. Находим последнюю стабильную версию ОС, где работает приклад. Чтобы вы понимали всю боль — иногда это Novell Netware 4.x. Это где основной сетевой протокол — IPX/SPX, а TCP/IP рассматривается как фантазия из будущего, но на всякий случай поддерживается. В одном банке это чудо до сих пор работает с данными архивов. И иногда она реально нужна для глубокого поиска по финансовым данным.
2. Находим гипервизор, который поддерживает эту стабильную версию ОС и приклад. Запускаем в нём. Получается, например, некий старый Linux.
3. Находим гипервизор (скорее всего, уже свежую Вмвару), который поддерживает этот старый Linux. Запускаем ВМ с ВМ на нём.

Получается дом, который построил Джек.

Понятное дело, приклад от этого страдает по производительности, но деваться особо некуда. Знаю одну историю о попытке ухода с Нетвары. Лет 10 как разработчиков просто нет. Все хваленые виртуализаторы не поддерживают никак и никогда. В итоге кое-как умудрились подняться с 4 на 6,5 потом её уже в гипервизоре.

Кстати, если вы думаете, что это всё очень редкие случаи, присмотритесь к принтерам в отделениях банков, где вы бываете. Есть шанс встретить матричные принтеры на подключении к LTP-портам. Это даже не универсальные COM-порты, нет, которые можно встретить сегодня в мутированном виде клавиатурных гнёзд. Старый добрый LTP! В этих же банках отчёты сдают на 3,5-дюймовых дискетах. Даже у нас есть пара дисководов на случай горячей замены на складе. Там же ещё лежат суперсовременные ZIP-дисководы. Хорошо хоть 5,25 и 8 дюймов не встречали пока в практике. Хотя саму «грампластинку» — гибкий магнитный диск формата 8 дюймов в конверте — я ещё встречал в хранилищах ЗИП. Дисководы — нет.

Из современной истории в регионах можно часто повсеместно встретить старые компаковские сервера. Которые лет 10 назад поставлялись. Это ещё 2004-й, до слияния с HP.

А что Huawei?

А их разработка допиливает драйвера и прочее. Производитель железа должен поддерживать целевую ось аппаратно. Старые х86 были на интеловых чипсетах — это небольшие машины. У хьюллета — 16 ядер и выше. И железо у них для разруливания нестандартное. Поэтому не всё так просто, как может показаться. Те же менеджеры памяти очень нетривиальны для старых систем.

В итоге на выпуске нового сервера в начале список совместимости из одной ОС. Позже допиливают. Сейчас хотят больше глубоких NIX. Выбор-то простой: либо ПО системное переделывать, либо работать с операционной. Поэтому второе проще, потому что в банках распространён тот же Центос бесплатный (и даже не Редхат), и если дать совместимость — клиентов на х86 сразу станет больше.

Естественно, миграция может привести к переписыванию всей системы. И этого никто не хочет особо. Чаще всего разрабы потерялись, потому что системе 11 лет, нет актуальной документации или она не ведется. Найти хотя бы точки интеграции — стандартная проблема. Хранимые процедуры тоже добавляют радости. Ну и напоследок, 90% диалогов:
— У вас процедура принятия в эксплуатацию есть?
— Конечно!
— А документация по ней нужна?
— Абсолютно.
— Так, а эта процедура соблюдается?
— Нет, конечно, вы чего, с ума сошли?

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

Так что только переход на суперкластеры с совместимостью со старыми ОС.

Тесты

За 2 месяца мы протестировали для заказчиков 5 платформ. Обследовать по сути нечего, вопросы только по стабильности и возможности миграции. Никаких синтетических тестов, потому что результаты каждый раз разительно отличаются от реальных. Причём в обе стороны.

Будущее

В далёком будущем, возможно, таких танцев с бубном не будет. Самая главная беда, когда нам нужна вертикальная масштабируемость (увеличение количества процессоров и памяти в рамках одной машины), так как единую базу Оракл просто так нельзя разбить на несколько частей, она должна быть единой. А это хотят сделать все, чтобы перейти в облака и просто втыкать блейды в своё удовольствие. Сейчас большие СУБД на AIX единые и очень жирные. Поэтому вертикальный масштаб — для х86 сейчас это 32 процессора, по 16 ядер.

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

https://habrahabr.ru/post/334598/