-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51

Habrahabr/New








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/new/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-new-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

[Перевод] 37 причин, почему ваша нейросеть не работает

Суббота, 05 Августа 2017 г. 11:06 + в цитатник
Сеть обучалась последние 12 часов. Всё выглядело хорошо: градиенты стабильные, функция потерь уменьшалась. Но потом пришёл результат: все нули, один фон, ничего не распознано. «Что я сделал не так?», — спросил я у компьютера, который промолчал в ответ.

Почему нейросеть выдаёт мусор (например, среднее всех результатов или у неё реально слабая точность)? С чего начать проверку?

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

Содержание


0. Как использовать это руководство?
I. Проблемы с набором данных
II. Нормализация данных/Проблемы аугментации
III. Проблемы реализации
IV. Проблемы обучения

0. Как использовать это руководство?


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

  1. Начните с простой модели, которая точно правильно работает для этого типа данных (например, VGG для изображений). Используйте стандартную функцию потерь, если возможно.
  2. Отключите все финтифлюшки, например, регуляризацию и аугментацию данных.
  3. В случае тонкой настройки модели дважды проверьте препроцессинг, чтобы он соответствовал обучению первоначальной модели.
  4. Удостоверьтесь в правильности входных данных.
  5. Начните с действительно маленького набора данных (2-20 образцов). Затем расширяйте его, постепенно добавляя новые данные.
  6. Начните постепенно добавлять обратно все фрагменты, которые были опущены: аугментация/регуляризация, кастомные функции потерь, пробуйте более сложные модели.

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

I. Проблемы с набором данных



Источник: http://dilbert.com/strip/2014-05-07

1. Проверьте входные данные


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

2. Попробуйте случайные входные значения


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

3. Проверьте загрузчик данных


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

4. Убедитесь, что вход соединяется с выходом


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

5. Взаимоотношение между входом и выходом слишком случайно?


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

6. Слишком много шума в наборе данных?


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

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

7. Перемешайте набор данных


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

8. Снизьте несбалансированность классов


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

9. Достаточно ли образцов для обучения?


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

10. Убедитесь в отсутствии партий с единственной меткой


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

11. Уменьшите размер партий


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

Дополнение 1. Используйте стандартный набор данных (например, mnist, cifar10)


Спасибо hengcherkeng за это:

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

II. Нормализация данных/Проблемы аугментации




12. Откалибруйте признаки


Вы откалибровали входные данные на нулевое среднее и единичную дисперсию?

13. Слишком сильная аугментация данных?


Аугментация имеет регуляризующий эффект. Если она слишком сильная, то это вкупе с другими формами регуляризации (L2-регуляризация, dropout и др.) может привести к недообучению нейросети.

14. Проверьте предобработку предварительно обученной модели


Если вы используете уже подготовленную модель, то убедитесь, что используются та же нормализация и предобработка, что и в модели, которую вы обучаете. Например, должен пиксель быть в диапазоне [0, 1], [-1, 1] или [0, 255]?

15. Проверьте предварительную обработку для набора обучение/валидация/тестирование


CS231n указал на типичную ловушку:

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

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

III. Проблемы реализации



Источник: https://xkcd.com/1838/

16. Попробуйте решить более простой вариант задачи


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

17. Поищите правильную функцию потерь «по вероятности»


Снова из бесподобного CS231n: Инициализируйте с небольшими параметрами, без регуляризации. Например, если у нас 10 классов, то «по вероятности» означает, что правильный класс определится в 10% случаев, а функция потерь Softmax — это обратный логарифм к вероятности правильного класса, то есть получается $-ln(0.1) = 2.302$

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

18. Проверьте функцию потерь


Если вы реализовали свою собственную, проверьте её на баги и добавьте юнит-тесты. У меня часто бывало, что слегка неправильная функция потерь тонко вредила производительности сети.

19. Проверьте входные данные функции потерь


Если вы используете функцию потерь из фреймворка, то убедитесь, что передаёте ей то что нужно. Например, в PyTorch я бы смешал NLLLoss и CrossEntropyLoss, потому что первая требует входных данных softmax, а вторая — нет.

20. Отрегулируйте веса функции потерь


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

21. Отслеживайте другие показатели


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

22. Проверьте каждый кастомный слой


Вы самостоятельно реализовали какие-то из слоёв сети? Дважды проверьте, что они работают как полагается.

23. Проверьте отсутствие «зависших» слоёв или переменных


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

24. Увеличьте размер сети


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

25. Поищите скрытые ошибки измерений


Если ваши входные данные выглядят как $(k, H, W) = (64, 64, 64)$, то легко пропустить ошибку, связанную с неправильными измерениями. Используйте необычные числа для измерений входных данных (например, разные простые числа для каждого измерения) и посмотрите, как они распространяются по сети.

26. Исследуйте Gradient Checking


Если вы самостоятельно реализовали Gradient Descent, то с помощью Gradient Checking можно убедиться в корректной обратной связи. Дополнительная информация: 1, 2, 3.

IV. Проблемы обучения



Источник: http://carlvondrick.com/ihog/

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


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

28. Проверьте инициализацию весов


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

29. Измените гиперпараметры


Может вы используете плохой набор гиперпараметров. Если возможно, попробуйте grid search.

30. Уменьшите регуляризацию


Из-за слишком сильной регуляризации сеть может конкретно недообучиться. Уменьшите регуляризацию, такую как dropout, batch norm, L2-регуляризацию weight/bias и др. В отличном курсе «Практическое глубинное обучение для программистов» Джереми Говард рекомендует в первую очередь избавиться от недообучения. То есть нужно достаточно переообучить сеть на исходных данных, и только затем бороться с переобучением.

31. Дайте время


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

32. Переходите от режима обучения в режим тестирования


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

33. Визуализируйте обучение


  • Отслеживайте активации, веса и обновления для каждого слоя. Убедитесь, что отношения их величин совпадают. Например, отношение величины обновлений к параметрам (весам и смещениям) должно равняться 1e-3.
  • Рассмотрите библиотеки визуализации вроде Tensorboard и Crayon. В крайнем случае, можно просто печатать значения весов/сдвигов/активаций.
  • Будьте осторожны с активациями сетей со средним намного больше нуля. Попробуйте Batch Norm или ELU.
  • Deeplearning4j указал, на что смотреть в гистограммах весов и сдвигов:

«Для весов эти гистограммы должны иметь примерно гауссово (нормальное) распределение, спустя какое-то время. Гистограммы сдвигов обычно начинаются с нуля и обычно заканчиваются на уровне примерно гауссова распределения (единственное исключение — LSTM). Следите за параметрами, которые отклоняются на плюс/минус бесконечность. Следите за сдвигами, которые становятся слишком большими. Иногда такое случается в выходном слое для классификации, если распределение классов слишком несбалансировано».

  • Проверяйте обновления слоёв, они должны иметь нормальное распределение.

34. Попробуйте иной оптимизатор


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

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

35. Взрыв/исчезновение градиентов


  • Проверьте обновления слоя, поскольку очень большие значения могут указывать на взрывы градиентов. Может помочь клиппинг градиента.
  • Проверьте активации слоя. Deeplearning4j даёт отличный совет: «Хорошее стандартное отклонение для активаций находится в районе от 0,5 до 2,0. Значительный выход за эти рамки может указывать на взрыв или исчезновение активаций».

36. Ускорьте/замедлите обучение


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

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

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

37. Устранение состояний NaN


Состояния NaN (Non-a-Number) гораздо чаще встречаются при обучении RNN (насколько я слышал). Некоторые способы их устранения:

  • Уменьшите скорость обучения, особенно если NaN появляются в первые 100 итераций.
  • Нечисла могут возникнуть из-за деления на ноль, взятия натурального логарифма нуля или отрицательного числа.
  • Рассел Стюарт предлагает хорошие советы, что делать в случае появления NaN.
  • Попробуйте оценить сеть слой за слоем и посмотреть, где появляются NaN.


Источники:


cs231n.github.io/neural-networks-3
russellsstewart.com/notes/0.html
stackoverflow.com/questions/41488279/neural-network-always-predicts-the-same-class
deeplearning4j.org/visualization
www.reddit.com/r/MachineLearning/comments/46b8dz/what_does_debugging_a_deep_net_look_like
www.researchgate.net/post/why_the_prediction_or_the_output_of_neural_network_does_not_change_during_the_test_phase
book.caltech.edu/bookforum/showthread.php?t=4113
gab41.lab41.org/some-tips-for-debugging-deep-learning-3f69e56ea134
www.quora.com/How-do-I-debug-an-artificial-neural-network-algorithm
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334944/


Android Architecture Components. Часть 4. ViewModel

Суббота, 05 Августа 2017 г. 10:28 + в цитатник
image

Компонент ViewModel — предназначен для хранения и управления данными, связанными с представлением, а заодно, избавить нас от проблемы, связанной с пересозданием активити во время таких операций, как переворот экрана и т.д. Не стоит его воспринимать, как замену onSaveInstanceState, поскольку, после того как система уничтожит нашу активити, к примеру, когда мы перейдем в другое приложение, ViewModel будет также уничтожен и не сохранит свое состояние. В целом же, ViewModel можно охарактеризовать как синглтон, который гарантирует, что не будет уничтожен пока есть активный экземпляр нашей активити и освободит ресурсы после ухода с нее (все немного сложнее, но выглядит как-то так). Стоит также отметить, что мы можем привязать любое количество ViewModel к нашей Activity(Fragment).

Компонент состоит из таких классов: ViewModel, AndroidViewModel, ViewModelProvider, ViewModelProviders, ViewModelStore, ViewModelStores. Разработчик будет работать только с  ViewModel, AndroidViewModel и для получения истанца с ViewModelProviders, но для лучшего понимания компонента, мы поверхностно рассмотрим все классы.


Класс ViewModel, сам по себе представляет абстрактный класс, без абстрактных методов и с одним protected методом onCleared(). Для реализации собственного ViewModel, нам всего лишь необходимо унаследовать свой класс от ViewModel с конструктором без параметров и это все. Если же нам нужно очистить ресурсы, то необходимо переопределить метод onCleared(), который будет вызван когда ViewModel долго не доступна и должна быть уничтожена. Как пример, можно вспомнить предыдущую статью про LiveData, а конкретно о методе observeForever(Observer), который требует явной отписки, и как раз в методе onCleared() уместно ее реализовать. Стоит еще добавить, что во избежания утечки памяти, не нужно ссылаться напрямую на View или Context Activity из ViewModel. В целом, ViewModel должна быть абсолютно изолированная от представления данных. В таком случае появляется вопрос: А каким же образом нам уведомить представление (Activity/Fragment) об изменениях в наших данных? В этом случае на помощь нам приходит LiveData, все изменяемые данные мы должны хранить с помощью LiveData, если же нам необходимо, к примеру, показать и скрыть ProgressBar, мы можем создать MutableLiveData и хранить логику показать\скрыть в компоненте ViewModel. В общем это будет выглядеть так:
public class MyViewModel extends ViewModel {
  private MutableLiveData showProgress = new MutableLiveData<>();

  //new thread
  public void doSomeThing(){
      showProgress.postValue(true);
      ...
      showProgress.postValue(false);
  }
 
  public MutableLiveData getProgressState(){
      return showProgress;
  }
}


Для получения ссылки на наш экземпляр ViewModel мы должны воспользоваться ViewModelProviders:
@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.activity_main);
  final MyViewModel viewModel = ViewModelProviders.of(this).get(MyViewModel.class);
  viewModel.getProgressState().observe(this, new Observer() {
      @Override
      public void onChanged(@Nullable Boolean aBoolean) {
          if (aBoolean) {
              showProgress();
          } else {
              hideProgress();
          }
      }
  });
  viewModel.doSomeThing();
}


Класс AndroidViewModel, являет собой расширение ViewModel, с единственным отличием — в конструкторе должен быть один параметр Application. Является довольно полезным расширением в случаях, когда нам нужно использовать Location Service или другой компонент, требующий Application Context. В работе с ним единственное отличие, это то что мы наследуем наш ViewModel от ApplicationViewModel. В Activity/Fragment инициализируем его точно также, как и обычный ViewModel.

Класс ViewModelProviders, являет собой четыре метода утилиты, которые, называются of и возвращают ViewModelProvider. Адаптированные для работы с Activity и Fragment, а также, с возможностью подставить свою реализацию ViewModelProvider.Factory, по умолчанию используется DefaultFactory, которая является вложенным классом в ViewModelProviders. Пока что других реализаций приведенных в пакете android.arch нет.

Класс ViewModelProvider, собственно говоря класс, который возвращает наш инстанс ViewModel. Не будем особо углубляться здесь, в общих чертах он являет роль посредника с ViewModelStore, который, хранит и поднимает наш интанс ViewModel и возвращает его с помощью метода get, который имеет две сигнатуры get(Class) и get(String key, Class modelClass). Смысл заключается в том, что мы можем привязать несколько ViewModel к нашему Activity/Fragment даже одного типа. Метод get возвращает их по String key, который по умолчанию формируется как: «android.arch.lifecycle.ViewModelProvider.DefaultKey:» + canonicalName

Класс ViewModelStores, являет собой фабричный метод, напомню: Фабричный метод — паттерн, который определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать, по факту, позволяет классу делегировать инстанцирование подклассам. На данный момент, в пакете android.arch присутствует как один интерфейс, так и один подкласс ViewModelStore.

Класс ViewModelStore, класс в котором и находится вся магия, состоит из методов put, get и clear. Про них не стоит беспокоится, поскольку работать напрямую мы с ними не должны, а с get и put и физически не можем, так как они объявлены как default (package-private), соответственно видны только внутри пакета. Но, для общего образования, рассмотрим устройство этого класса. Сам класс хранит в себе HashMap, методы get и put, соответственно, возвращают по ключу (по тому самому, который мы формируем во ViewModelProvider) или добавляют ViewModel. Метод clear(), вызовет метод onCleared() у всех наших ViewModel которые мы добавляли.

Для примера работы с ViewModel давайте реализуем небольшое приложение, позволяющее выбрать пользователю точку на карте, установить радиус и показывающее, находится человек в этом поле или нет. А также дающее возможность указать WiFi network, если пользователь подключен к нему, будем считать что он в радиусе, вне зависимости от физических координат.



Для начала создадим две LiveData для отслеживания локации и имени WiFi сети:
public class LocationLiveData extends LiveData implements
      GoogleApiClient.ConnectionCallbacks,
      GoogleApiClient.OnConnectionFailedListener,
      LocationListener {
  private final static int UPDATE_INTERVAL = 1000;
  private GoogleApiClient googleApiClient;

  public LocationLiveData(Context context) {
      googleApiClient =
              new GoogleApiClient.Builder(context, this, this)
                      .addApi(LocationServices.API)
                      .build();
  }

  @Override
  protected void onActive() {
      googleApiClient.connect();
  }

  @Override
  protected void onInactive() {
      if (googleApiClient.isConnected()) {
          LocationServices.FusedLocationApi.removeLocationUpdates(
                  googleApiClient, this);
      }
      googleApiClient.disconnect();
  }

  @Override
  public void onConnected(Bundle connectionHint) {
          LocationRequest locationRequest = new LocationRequest().setInterval(UPDATE_INTERVAL).setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);
          LocationServices.FusedLocationApi.requestLocationUpdates(
                  googleApiClient, locationRequest, this);
  }

  @Override
  public void onLocationChanged(Location location) {
      setValue(location);
  }

  @Override
  public void onConnectionSuspended(int cause) {
      setValue(null);
  }

  @Override
  public void onConnectionFailed(ConnectionResult connectionResult) {
      setValue(null);
  }
}


public class NetworkLiveData extends LiveData {
  private Context context;
  private BroadcastReceiver broadcastReceiver;

  public NetworkLiveData(Context context) {
      this.context = context;
  }

  private void prepareReceiver(Context context) {
      IntentFilter filter = new IntentFilter();
      filter.addAction("android.net.wifi.supplicant.CONNECTION_CHANGE");
      filter.addAction("android.net.wifi.STATE_CHANGE");
      broadcastReceiver = new BroadcastReceiver() {
          @Override
          public void onReceive(Context context, Intent intent) {
              WifiManager wifiMgr = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
              WifiInfo wifiInfo = wifiMgr.getConnectionInfo();
              String name = wifiInfo.getSSID();
              if (name.isEmpty()) {
                  setValue(null);
              } else {
                  setValue(name);
              }
          }
      };
      context.registerReceiver(broadcastReceiver, filter);
  }

  @Override
  protected void onActive() {
      super.onActive();
      prepareReceiver(context);
  }

  @Override
  protected void onInactive() {
      super.onInactive();
      context.unregisterReceiver(broadcastReceiver);
      broadcastReceiver = null;
  }
}


Теперь перейдем к ViewModel, поскольку у нас есть условие, которое зависит от полученных данных с двух LifeData, нам идеально подойдет MediatorLiveData как холдер самого значения, но поскольку перезапускать сервисы нам невыгодно, поэтому подпишемся к MediatorLiveData без привязки к жизненному циклу с помощью observeForever.  В методе onCleared() реализуем отписку от него с помощью removeObserver. В свою же очередь LiveData будет уведомлять об изменении MutableLiveData, на которую и будет подписано наше представление.    

public class DetectorViewModel extends AndroidViewModel {
//для хранения вводимых данных, решил создать Repository, листинг его можно посмотреть на GitHub по линке в конце материала
  private IRepository repository;
  private LatLng point;
  private int radius;
  private LocationLiveData locationLiveData;
  private NetworkLiveData networkLiveData;
  private MediatorLiveData statusMediatorLiveData = new MediatorLiveData<>();
  private MutableLiveData statusLiveData = new MutableLiveData<>();
  private String networkName;
  private float[] distance = new float[1];
  private Observer locationObserver = new Observer() {
      @Override
      public void onChanged(@Nullable Location location) {
          checkZone();
      }
  };
  private Observer networkObserver = new Observer() {
      @Override
      public void onChanged(@Nullable String s) {
          checkZone();
      }
  };
  private Observer mediatorStatusObserver = new Observer() {
      @Override
      public void onChanged(@Nullable Status status) {
          statusLiveData.setValue(status.toString());
      }
  };

  public DetectorViewModel(final Application application) {
      super(application);
      repository = Repository.getInstance(application.getApplicationContext());
      initVariables();
      locationLiveData = new LocationLiveData(application.getApplicationContext());
      networkLiveData = new NetworkLiveData(application.getApplicationContext());
      statusMediatorLiveData.addSource(locationLiveData, locationObserver);
      statusMediatorLiveData.addSource(networkLiveData, networkObserver);
      statusMediatorLiveData.observeForever(mediatorStatusObserver);
  }

//Для того чтобы зря не держать LocationService в работе, мы от него отписываемся если WiFi network подходит.
  private void updateLocationService() {
      if (isRequestedWiFi()) {
          statusMediatorLiveData.removeSource(locationLiveData);
      } else if (!isRequestedWiFi() && !locationLiveData.hasActiveObservers()) {
          statusMediatorLiveData.addSource(locationLiveData, locationObserver);
      }
  }

//считываем данные с репозитория
  private void initVariables() {
      point = repository.getPoint();
      if (point.latitude == 0 && point.longitude == 0)
          point = null;
      radius = repository.getRadius();
      networkName = repository.getNetworkName();
  }

//метод, который отвечает за проверку того находимся мы в нужной зоне или нет
  private void checkZone() {
      updateLocationService();
      if (isRequestedWiFi() || isInRadius()) {
          statusMediatorLiveData.setValue(Status.INSIDE);
      } else {
          statusMediatorLiveData.setValue(Status.OUTSIDE);
      }
  }

  public LiveData getStatus() {
      return statusLiveData;
  }
// методы которые отвечают за запись данных в репозиторий
  public void savePoint(LatLng latLng) {
      repository.savePoint(latLng);
      point = latLng;
      checkZone();
  }

  public void saveRadius(int radius) {
      this.radius = radius;
      repository.saveRadius(radius);
      checkZone();
  }

  public void saveNetworkName(String networkName) {
      this.networkName = networkName;
      repository.saveNetworkName(networkName);
      checkZone();
  }

  public int getRadius() {
      return radius;
  }

  public LatLng getPoint() {
      return point;
  }

  public String getNetworkName() {
      return networkName;
  }

  public boolean isInRadius() {
      if (locationLiveData.getValue() != null && point != null) {
          Location.distanceBetween(locationLiveData.getValue().getLatitude(), locationLiveData.getValue().getLongitude(), point.latitude, point.longitude, distance);
          if (distance[0] <= radius)
              return true;
      }
      return false;
  }

  public boolean isRequestedWiFi() {
      if (networkLiveData.getValue() == null)
          return false;
      if (networkName.isEmpty())
          return false;
      String network = networkName.replace("\"", "").toLowerCase();
      String currentNetwork = networkLiveData.getValue().replace("\"", "").toLowerCase();
      return network.equals(currentNetwork);
  }

  @Override
  protected void onCleared() {
      super.onCleared();
      statusMediatorLiveData.removeSource(locationLiveData);
      statusMediatorLiveData.removeSource(networkLiveData);
      statusMediatorLiveData.removeObserver(mediatorStatusObserver);
  }
}


И наше представление:

public class MainActivity extends LifecycleActivity {
  private static final int PERMISSION_LOCATION_REQUEST = 0001;
  private static final int PLACE_PICKER_REQUEST = 1;
  private static final int GPS_ENABLE_REQUEST = 2;
  @BindView(R.id.status)
  TextView statusView;
  @BindView(R.id.radius)
  EditText radiusEditText;
  @BindView(R.id.point)
  EditText pointEditText;
  @BindView(R.id.network_name)
  EditText networkEditText;
  @BindView(R.id.warning_container)
  ViewGroup warningContainer;
  @BindView(R.id.main_content)
  ViewGroup contentContainer;
  @BindView(R.id.permission)
  Button permissionButton;
  @BindView(R.id.gps)
  Button gpsButton;
  private DetectorViewModel viewModel;
  private LatLng latLng;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      ButterKnife.bind(this);
      checkPermission();
  }

  @Override
  public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
      super.onRequestPermissionsResult(requestCode, permissions, grantResults);
      if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
          init();
      } else {
          showWarningPage(Warning.PERMISSION);
      }
  }

  private void checkPermission() {
      if (PackageManager.PERMISSION_GRANTED == checkSelfPermission(
              Manifest.permission.ACCESS_FINE_LOCATION)) {
          init();
      } else {
          requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, PERMISSION_LOCATION_REQUEST);
      }
  }


  private void init() {
      viewModel = ViewModelProviders.of(this).get(DetectorViewModel.class);
      if (Utils.isGpsEnabled(this)) {
          hideWarningPage();
          checkingPosition();
          initInput();
      } else {
          showWarningPage(Warning.GPS_DISABLED);
      }
  }

  private void initInput() {
      radiusEditText.setText(String.valueOf(viewModel.getRadius()));
      latLng = viewModel.getPoint();
      if (latLng == null) {
          pointEditText.setText(getString(R.string.chose_point));
      } else {
          pointEditText.setText(latLng.toString());
      }
      networkEditText.setText(viewModel.getNetworkName());
  }

  @OnClick(R.id.get_point)
  void getPointClick(View view) {
      PlacePicker.IntentBuilder builder = new PlacePicker.IntentBuilder();
      try {
          startActivityForResult(builder.build(MainActivity.this), PLACE_PICKER_REQUEST);
      } catch (GooglePlayServicesRepairableException e) {
          e.printStackTrace();
      } catch (GooglePlayServicesNotAvailableException e) {
          e.printStackTrace();
      }
  }

  @OnClick(R.id.save)
  void saveOnClick(View view) {
      if (!TextUtils.isEmpty(radiusEditText.getText())) {
          viewModel.saveRadius(Integer.parseInt(radiusEditText.getText().toString()));
      }
      viewModel.saveNetworkName(networkEditText.getText().toString());
  }

  @OnClick(R.id.permission)
  void permissionOnClick(View view) {
      checkPermission();
  }

  @OnClick(R.id.gps)
  void gpsOnClick(View view) {
      startActivityForResult(new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS), GPS_ENABLE_REQUEST);
  }


  private void checkingPosition() {
      viewModel.getStatus().observe(this, new Observer() {
          @Override
          public void onChanged(@Nullable String status) {
              updateUI(status);
          }
      });
  }

  private void updateUI(String status) {
      statusView.setText(status);
  }

  protected void onActivityResult(int requestCode, int resultCode, Intent data) {
      if (requestCode == PLACE_PICKER_REQUEST) {
          if (resultCode == RESULT_OK) {
              Place place = PlacePicker.getPlace(data, this);
              updatePlace(place.getLatLng());
          }
      }
      if (requestCode == GPS_ENABLE_REQUEST) {
          init();
      }
  }

  private void updatePlace(LatLng latLng) {
      viewModel.savePoint(latLng);
      pointEditText.setText(latLng.toString());
  }

  private void showWarningPage(Warning warning) {
      warningContainer.setVisibility(View.VISIBLE);
      contentContainer.setVisibility(View.INVISIBLE);
      switch (warning) {
          case PERMISSION:
              gpsButton.setVisibility(View.INVISIBLE);
              permissionButton.setVisibility(View.VISIBLE);
              break;
          case GPS_DISABLED:
              gpsButton.setVisibility(View.VISIBLE);
              permissionButton.setVisibility(View.INVISIBLE);
              break;
      }
  }

  private void hideWarningPage() {
      warningContainer.setVisibility(View.GONE);
      contentContainer.setVisibility(View.VISIBLE);
  }
}


В общих чертах мы подписываемся на MutableLiveData, с помощью меnода getStatus() из нашего ViewModel. А также работаем с ним для инициализации и сохранения наших данных.
Здесь также добавлено несколько проверок, таких как RuntimePermission и проверка на состояние GPS. Как можно заметить, код в Activity получился довольно обширный, в случае сложного UI, гугл рекомендует посмотреть в сторону создания презентера(но это может быть излишество).

В примере также использовались такие библиотеки как:
compile 'com.jakewharton:butterknife:8.6.0'
compile 'com.google.android.gms:play-services-maps:11.0.2'
compile 'com.google.android.gms:play-services-location:11.0.2'
compile 'com.google.android.gms:play-services-places:11.0.2'
annotationProcessor 'com.jakewharton:butterknife-compiler:8.6.0'


Полный листинг: here

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

Android Architecture Components. Часть 1. Введение
Android Architecture Components. Часть 2. Lifecycle
Android Architecture Components. Часть 3. LiveData
Android Architecture Components. Часть 4. ViewModel
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334942/


Колебания цен на нефть: виноват ли алгоритмический трейдинг?

Суббота, 05 Августа 2017 г. 10:21 + в цитатник


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

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

По словам нефтяных инвесторов, добыча сырья и спрос на него больше не являются движущими силами ценообразования на рынке. Они утверждают, что программный трейдинг искажает ситуацию и провоцирует ценовые перепады. Взять к примеру ситуацию от 25 мая: даже после того, как страны-члены ОПЕК решили продолжить сокращение добычи сырья, цены на нефть упали практически на 5%.

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

Премьер-министр Саудовской Аравии Халид аль-Фалих был одним из тех, кто связал события 25 мая с действиями технических трейдеров. «Тогда многие люди хотели продать акции», — сказал он после встречи ОПЕК 25 мая. «Но падение цен усилилось после того, как цена преодолела определенные технические барьеры».

По данным Комиссии по торговле товарными фьючерсами, автоматизированная торговля «энергетическими» контрактами (акциями) с конца 2014 по конец 2016 года составила 58 процентов, тогда как в предыдущем двухлетнем периоде её уровень составлял 47 процентов.

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

8 и 9 марта запасы США продемонстрировали рекордный уровень. Однако после того, как в игру вступили алгоритмы, цена на нефть упала ниже 50 долларов за баррель – впервые за год.



«Всё больше трейдеров ведутся на кричащие заголовки, а не считают реальные объемы нефти, — сказал Майкл Тран, директор по энергетическим стратегиям RBC Capital Markets. — Многие из них — это алготрейдеры или кванты».

У каждого из фондов – свои стратегии, из-за этого влияние на них алгоритмов и автоматизации бывает крайне сложно определить. Как говорит Майкл Помада, исполнительный директор Crabel Capital Management, «люди склонны винить в происходящем те вещи, которые они не понимают».

Да, действительно, в основе алгоритмов часто лежит непростая методология. Время покупки и продажи акций определяется с помощью следующих индикаторов – скользящих средних (MA) и волатильности.

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

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

Автоматизированная торговля захватывает и другие сферы: например, согласно отчету CFTC, в сельском хозяйстве её уровень возрос до 49% в течение последних двух лет (до конца 2016 года) относительно 38% в прошлом периоде. То же самое можно сказать и о рынке металла, где процент алгоритмического трейдинга составил 54% в сравнении с 47% с 2012 по 2014 годы.

Однако цены на нефть всё-таки более подвержены колебаниям, нежели цены в других отраслях, в том числе, и из-за последних действий ОПЕК. Моментум-трейдеры, использующие алгоритмы, чувствуют тенденции на рынке, утверждает Питер Хан из Bridgeton Research Group. Он также сказал о том, что рынок нефти сейчас находится в переходном состоянии. «На таком рынке торговые системы на базе импульсных алгоритмом будут «выбиваться» из длинных и коротких позиций».

Некоторые алгоритмические стратегии неплохо финансируются: например, в прошлом году 25,5 млрд долларов было инвестировано в деятельность биржевых консультантов по товарным опционам (CTA, commodity trading adviser), многие из которых, по данным Preqin, используют алгоритмы для отслеживания трендов на рынке фьючерсов. В первом квартале этого года CTA привлекли еще 7,2 млрд долларов, после чего общий объём их средств составил 256 млрд долларов.

По мнению Goldman Sachs, биржевые консультанты могут создавать новые торговые возможности на рынке. «Фундаментальным инвесторам не стоит опасаться CTA-фондов. Их деятельность следует рассматривать как источник новых возможностей для заработка, поскольку они уводят рынок в сторону от жесткого следования фундаментальным показателям», пишет инвестиционный банк в своем отчете по сырьевым продуктам от 29 июня.

Другие материалы по теме финансов и фондового рынка от ITinvest:


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

https://habrahabr.ru/post/334940/


Метки:  

Охота на рыжего демона или пеленгатор помех спутниковой навигации

Суббота, 05 Августа 2017 г. 05:47 + в цитатник


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

К чему это привело читайте дальше.


Эпиграф
У нас потерялся робот. Работы прекратились и должны стоять, пока мы его
не обнаружим.
А. Азимов, «Как потерялся робот»

Ко дню рождения одного товарища
И. Царик, «Пользуясь случаем»



Зачем нужны GPS-глушилки и GPS-спуферы особо рассказывать не нужно. Сегодня все знают, что даже «новая аристократия» их использует для пущей безопасности. Особенно это знают жители Москвы. Что уж тогда говорить о простых людях. Ну когда у нас кому было какое дело до мелких неудобств соседа? «Если „Им“ наплевать, то мне тем более. Если мне нужно — врубил и поехал».

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

А теперь представьте себе робо-водителя будущего…

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

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

Самый дешевый способ вырубить навигацию стоил мне 2500 рублей.

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

А какой богатый у него спектр (видео)!


Далее эта зараза во мне прогрессировала в деструктивные действия и я разобрал его:

Все очень просто и со вкусом, почти по-деревенски)
И теперь вы все понимаете, почему демон рыжый.
(Хотя и «История рыжего демона» мне тоже нравится)

Но каково оно в действии!

Разящий огонь инквизиции! Теперь каждый пацан, сэкономив на пиве 30 раз, может «сжечь» всю навигацию на районе. Здесь хочу заметить, что запускал я эту штуку за городом. Ни один автолюбитель не пострадал.

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

NT1065 содержит четыре радио-тракта, которые можно настроить на использование одного гетеродина. Это видно по структурной схеме:

Тогда все четыре канала будут синфазны с точностью до неидентичностей радио-трактов. На рисунке ниже показан спектр разностей фаз.

Видно, что разности фаз стабильны, таким образом, возможно создание на базе NT1065 четырехканального фазового пеленгатора.

Берем плату из предыдущей статьи, добавляем к ней четыре антенны с малошумящими усилителями (МШУ). Можно было и без МШУ, но хотелось немного поднять сигнал в диапазонах, где антенна согласована плохо.

ВЧ-фильтры, рекомендуемые к установке на входе NT1065, для простоты и для гибкости пеленгатора, опускаем. Антенны настроены только на верхний навигационный диапазон (L1), но, закрыв глаза на чувствительность, можно будет попробовать использовать пеленгатор и на нижних диапазонах (L2, L3, L5 и т.д.). Позже посмотрим, что получится.

Вот такая получилась железяка:

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

А сейчас — софт (видео).


Исходники — здесь.

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

Здесь все сделано по-простому: алгоритм можно назвать «формирование диаграммы направленности», по-английски наверное будет beamformer — находим направление основного лепестка диаграммы направленности, наиболее соответствующее принятому антенной решеткой сигналу. Формула будет такая:

Конкретный код смотрите в GitHub'е, кому интересно.

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


И работает так: (видео).

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

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

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

Вот на это я и хочу направить дальше свои усилия.

P.S.

На нижнем диапазоне, в навигационной формулировке L2, L3, L5 и т.д., пока работает не очень. Надо курить калибровку)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332746/


Security Week 31: Борец с WannaCry арестован в США, Svpeng получил новую фишку, Cisco патчит 15 дыр

Пятница, 04 Августа 2017 г. 23:35 + в цитатник
Что мы знаем о Маркусе Хатчинсе? На удивление мало. До истории с WannaCry о нем вообще ничего не было слышно, но тут его прославил блестящий ход со стоп-доменом. Парень порылся в коде троянца, нашел механизм самоуничтожения при получении ответа с захардкоденного домена, зарегал домен (затраты составили $10) и сумел существенно затормозить эпидемию Воннакрая.

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

Юное дарование приехало в Лас-Вегас – там как раз проходят конференции Black Hat и Defcon. И тут выяснилось, что парня заждались в окружном суде восточного Висконсина, причем с достаточно серьезными обвинениями на руках. Обвинительный акт содержит шесть пунктов, вменяемых Маркусу. Все они сводятся к тому, что Маркус Хатчинс, на пару с неназванным лицом ответственен за создание и распространение банковского троянца Kronos.

Кроноса заметили в даркнете в 2014 году, когда его авторы открыли предзаказ за $7000. Цена, видимо, оказалась завышена, так как после релиза его начали продавать по $3000, а уже в 2015 году он шел по $2000. На Youtube, кстати, есть ролик, рекламирующий Кроноса, предположительно снятый подельником Хатчинса.

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

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

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

Svpeng обзавелся кейлогером

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

Что интересно, для перехвата клавиатурного ввода используются так называемые специальные возможности Android – функции облегчения работы со смартфоном для инвалидов. При этом Svpeng отказывается работать, если в списке клавиатурных раскладок обнаруживается русская. Роман Унучек, который у нас тут собаку съел на андроидной малвари, утверждает, что это обычная тактика для российских киберпреступников, чтобы избежать уголовного преследования. Мол, если в России ничего плохого их детище не делает, то и преступления как бы нет.

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

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

Cisco выпустила патчи к 15 уязвимостям

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

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

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

Еще один, трудноэксплуатируемый, но потенциально вкусный баг, позволяет менять некоторые параметры в базе данных локального состояния соединений (LSA) роутера Cisco. Злоумышленник отправляет специально сконструированные пакеты OSPF LSA type 1, меняет таким образом таблицу маршрутизации, и потенциально перехватывает или блекхолит трафик по некоторым соединениям. Все это работает для устройств с поддержкой протокола OSPF и не работает с протоколом FSPF.

Древности


«Softpanorama»

Очень опасный резидентный вирус. Стандартно поражает COM- и EXE-файлы при обращении к ним. EXE-файлы переводятся в COM-формат (см. вирус «VACSINA»). Проявляется следующим образом: стирает сектора со случайными номерами, вызывает int 5 (печать экрана). Содержит текстовые строки: «comexe», «Enola Gay is now flying to SoftPanorama!», «command». Перехватывает int 8, 21h

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 83.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334934/


Метки:  

Второй Hackfest в истории ReactOS

Пятница, 04 Августа 2017 г. 21:51 + в цитатник
Спешим поделиться важной информацией.

Мы решили продолжить традицию, поэтому второму в истории ReactOS хакфесту быть! Мероприятие пройдет с 14 по 18 августа 2017 года в Кёльне (Германия). Приглашаются желающие, для участия требуется предварительная регистрация

Всю информацию о событии можно получить на специальной вики-страничке.

image
Фотография с хакфеста, прошедшего в 2015 году.

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

Свое участие уже подтвердили такие разработчики, как Colin Finck, Eric Kohl, Giannis Adamopoulos, Mark Jansen, Thomas Faber, Victor Martinez, Timo Kreuzer.

Список участников и идей для хакфеста постоянно обновляется на второй вики-страничке.

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

Если потенциальный участник обратится заблаговременно, то есть прямо сейчас, Фонд может оказать справочно-информационную поддержку, организовать совместный трансфер из аэропорта и проживание в хостеле вместе со всеми участниками, что существенно сократит расходы. Администратор мероприятия — Colin Finck

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

Что в проекте произошло за 60 дней лета?




Хлеба и зрелищ


На следующем видео есть ответ на популярный вопрос — «работает ли у вас 1С: Предприятие?»




Видео прислал волонтер проекта, Андрей Шаталов.

А вот и ответ на второй по популярности вопрос — "а Кризис у вас хоть запускается?"



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

https://habrahabr.ru/post/334932/


Метки:  

[Перевод] XBRL: просто о сложном - Глава 6. Погружение в XBRL - Часть 1. Приступаем

Пятница, 04 Августа 2017 г. 21:31 + в цитатник

6. Погружение в XBRL


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


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


Примечание: Мы не будем создавать базы ссылок определений (definition linkbase) и базы ссылок на реcурсы (reference linkbase). В реальной жизни вы могли бы создать по крайней мере одну из них, чтобы более подробно описать свои концепты, но для целей данной главы они не нужны. После того, как вы освоите базы ссылок ярлыков (label linkbase) и презентаций (presentation linkbase), с пониманием баз ссылок определений и ресурсов не должно возникнуть никаких проблем.


6.1. Приступаем


Начнем с простой таксономии для нашего примера.


6.1.1. Схема таксономии


Прежде всего нам нужен документ, содержащий схему таксономии.


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


Давайте считать, что мы начинаем наш маленький проект в первый день года, сразу после боя курантов, тогда назовем документ с таксономией следующим образом – ‘sample-2017-01-01.xsd’. Будем обсуждать наш документ небольшими частями, создавая таксономию шаг за шагом.


6.1.1.1. Корень схемы

Как и в любой XML-схеме, мы начинаем с корневого элемента schema:



 ...

Обратите внимание на атрибуты внутри корневого элемента:


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

Остальные атрибуты определяют префиксы элементов схемы. Префикс указывает, каким пространством имен определяется элемент:


  • xmlns
    Пространство имен XML Schema – является значением по умолчанию для всех элементов без префикса;
  • xmlns:xbrli
    Пространство имен отчета XBRL (instance);
  • xmlns:link
    Пространство имен XBRL Link;
  • xmlns:xlink
    Пространство имен XML Schema XLink;
  • xmlns:sample
    Наконец, любые определенные нами элементы, которые находятся в целевом пространстве имен, будут иметь префикс sample.

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


Спецификация XBRL включает в себя ряд схем:
  • XBRL Instance
    Содержит определения (типы, атрибуты, элементы), необходимые для объявления фактов и концептов;
  • XBRL Linkbase
    Содержит определения, необходимые для объявления ссылок от одной части таксономии (или базы ссылок) к другой;
  • XBRL XLink
    Используется для объявления самих баз ссылок, это пространство имен понадобится вам при создании собственного расширения спецификации XBRL;
  • W3C XLink
    Пространство имен для XML Link; обратите внимание, что схема для этой части спецификации находится на сайте xbrl.org, поскольку W3C не предоставляет эту схему, а для спецификации XBRL она необходима.


6.1.1.2. Импорт схемы отчета

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



Элемент import должен точно определить схему, идентифицированную пространством имен. Документ схемы, на который указывает URI в атрибуте schemaLocation, должен реально существовать.

Схема отчета XBRL импортирует схему XBRL Linkbase, а она, в свою очередь, импортирует схемы XBRL XLink и W3C XLink. Это означает, что нам не нужно самостоятельно импортировать эти схемы.

Пространство имен W3C XML Schema стандартизировано и автоматически распознается поддерживающим нашу схему программным обеспечением.

6.1.1.3. Концепты

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


Имя Тип
nr_employees_total non-negative integer item
nr_employees_male non-negative integer item
nr_employees_female non-negative integer item
nr_employees_age_up_to_20 non-negative integer item
nr_employees_age_21_to_40 non-negative integer item
nr_employees_age_41_and_up non-negative integer item

Концепт, отражающий общее количество сотрудников, определяется следующим образом:



Разберем атрибуты концепта:


  • id
    Этот идентификатор используется для обозначения концепта в других документах, таких как базы ссылок. Он должен быть уникальным в пределах схемы. Для id концепта мы использовали префикс ‘sample_’, чтобы сделать его глобально уникальным.
  • name
    Указанное в этом атрибуте наименование идентифицирует концепт внутри таксономии и отчета. Оно должно быть уникальным в пределах таксономии.
  • xbrli:periodType
    Каждый концепт должен иметь связанный с ним тип периода. В нашем примере количество сотрудников указывается на начало и на конец периода, то есть на дату. Для таких концептов используется значение instant.
  • type
    Количество сотрудников является целым числом; сотрудник, работающий неполный день, также считается как единица, а не дробь. Поскольку отрицательного количества сотрудников быть не может, мы используем тип nonNegativeIntegerItemType, определенный в схеме отчета XBRL.
  • substitutionGroup
    Это простой концепт, не являющийся кортежем, поэтому здесь указываем значение item, определенное в схеме отчета XBRL.
  • nillable
    Рекомендуется всегда указывать концепты как nillable, это позволяет передавать по ним пустые факты.

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


Нам также понадобится абстрактный концепт, который будет служить корнем иерархии представления нашего отчета. Ему (произвольно) присвоим тип xbrli:stringItemType. Для передачи фактов абстрактные концепты не используются, поэтому можно указать любой тип для удовлетворения требований спецификации XBRL по его наличию.



Абстрактный концепт должен иметь атрибут abstract со значением true.


6.1.1.4. Связи с базами ссылок

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


Связь с базами ссылок указывается в элементе appinfo, который размещается внутри элемента annotation:



  
    
    
  

У связи с базой ссылок есть следующие атрибуты:


  • xlink:type
    Здесь всегда указывается simple.
  • xlink:href
    В этом атрибуте указывается сама ссылка на базу. В нашем примере мы ссылаемся на базы ярлыков и презентаций, о которых поговорим позже.
  • xlink:role
    Атрибут ‘роль’ определяет тип базы ссылок. Мы используем значения labelLinkbaseRef и presentationLinkbaseRef, определенные схемой XBRL Linking.
  • xlink:arcrole
    Ролью дуги к базе ссылок всегда указывается определенное в XLink значение linkbase.

6.1.2. База ссылок ярлыков


База ярлыков содержит три типа элементов:


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

Эти элементы размещаются внутри элемента labelLink:




  
  ...
  

У элемента labelLink есть следующие атрибуты:


  • xlink:type
    Здесь всегда указывается extended.
  • xlink:role
    Для ссылок по умолчанию используется роль link.

6.1.2.1. Локтаторы (locator)

Локаторы размещаются в элементы loc. Они указывают на концепты связанной с ними таксономии.



  • xlink:type
    Типом элемента loc всегда указывается locator, означающий, что он используется как локатор (концептов).
  • xlink:href
    Указывает на фактическое местоположение концепта. Обратите внимание, что тут мы используем его id.
  • xlink:label
    Локатору присваивается ярлык для обращения к нему внутри базы ссылок. В качестве значения ярлыка мы будем использовать id концепта с префиксом ‘concept_’.

6.1.2.2. Ярлыки

Для определения ярлыков используется элемент label.





  • xlink:type
    Типом всегда является значение ‘resource’, указывающее, что ярлык является локальным ресурсом базы ссылок.
  • xlink:label
    Как и в случае с локаторами, значение атрибута label обеспечивает возможность обращаться к ярлыку внутри базы ссылок. Обратите внимание, что каждая из приведенных меток связана с одним и тем же концептом, и во всех из них используется одно и то же значение атрибута. Это позволяет использовать связь один-ко-многим от концепта к его ярлыкам. В нашем примере это три разных вида ярлыков для концепта ‘nr_employees_total’.
  • xlink:role
    Роль определяет вид используемого ярлыка. Спецификация XBRL предоставляет большое количество предопределенных ролей. В примере мы используем три вида – нормальный, краткий и развернутый ярлыки. Приложение для работы с таксономией или отчетом XBRL позволяет выбрать наиболее подходящий вид ярлыков. Базы ссылок презентаций также могут указывать предпочтительный вид ярлыка.
  • xml:lang
    В этом атрибуте указывается язык метки. В примере мы используем только английский язык, но в базу ссылок можно включать ярлыки на любых языках.

6.1.2.3. Дуги ярлыков

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



  • xlink:type
    Типом всегда указываем ‘arc’, дуга (кто бы мог подумать).
  • xlink:arcrole
    Роль дуги определяет вид связи. Для ярлыков указывается ‘concept-label’, дуга между концептом и ярлыком.
  • xlink:from
    Указывает на одну из сторон дуги, в нашем случае на концепт. Мы используем label локатора в качестве значения этого атрибута.
  • xlink:to
    Указывает на вторую сторону дуги, на ресурсы ярлыка, также с использованием label ресурса.

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


6.1.3. База ссылок презентаций


Презентации содержат два типа элементов:


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

Все они располагаются внутри элемента presentationLink:




  
    ...
  

6.1.3.1. Локаторы


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


6.1.3.2. Дуги презентаций


Дуги презентаций связывают концепты в parent-child иерархию (дерево):





...

  • xlink:type
    Как и ранее, ‘arc’.
  • xlink:arcrole
    Роль дуги презентации – ‘parent-child’, она указывает на то, что база ссылок презентаций представляет собой иерархическую структуру.
  • xlink:from
    Указывает на родительский концепт иерархии через его локатор. В нашем примере не было подходящего концепта, поэтому для корня иерархии мы используем абстрактный концепт ‘presentation_root’.
  • xlink:to
    Указывает на дочерний концепт иерархии через его локатор. В нашем примере все концепты располагаются под корневым концептом ‘presentation_root’.
  • order
    Этот атрибут задает порядок следования дочерних элементов, расположенных под общим родительским элементом.
  • priority
    Используется для переопределения баз ссылок. В нашем примере мы этого не делаем (пока что).
  • use
    Указывая значение optional, мы обозначаем, что концепт может быть частью сети презентаций. Общепринятой практикой является указание этого значения, хотя оно же используется по умолчанию в случае отсутствия атрибута.
  • preferredLabel
    Ранее мы создали несколько видов ярлыков в нашей базе ссылок ярлыков. Здесь мы видим, как в базе ссылок презентаций указывается предпочтительный вид ярлыка для дочернего (to) концепта дуги.

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


6.1.4. Отчет XBRL


Создав таксономию, мы можем использовать ее для создания отчета.


Документ с отчетом XBRL содержит следующие виды элементов:


  • Ссылки на схему таксономии;
  • Контексты для фактов;
  • Единицы измерения для числовых фактов;
  • Сами значения фактов.

Все эти элементы размещаются внутри элемента xbrl:




  ...

6.1.4.1. Ссылка на схему таксономии

Ссылка на схему указывается в элементе schemaRef:




  • xlink:type
    Указываем тип связи ‘simple’.
  • xlink:href
    Ссылка задается как href-атрибут. Он указывает расположение схемы таксономии на сайте ее создателя.

6.1.4.2. Контекст

У нас в примере есть два контекста – начало отчетного периода и конец отчетного периода:



  
    12-34567
  
  
    2016-01-01
  


  
    12-34567
  
  
    2016-12-31
  

  • id
    Используется для связи факта с контекстом. Это значение должно быть уникально в пределах отчета.
  • entity
    Здесь указывается организация, по данным которой составляется отчет.
    • identifier
      Этот элемент использует схему (scheme) для определения того, по какой организации составляется отчет. В нашем примере мы используем несуществующую схему на вымышленном сайте.
  • period
    Здесь указывается период или дата контекста.
    • instant
      В нашем примере у нас два instant-контекста, для дат начала и окончания отчетного периода соответственно.

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

6.1.4.3. Единицы измерения

Для всех числовых фактов должны быть указаны единицы измерения:



  Person

  • id
    Используется для связи факта с единицей измерения. Это значение должно быть уникально в пределах отчета.
  • measure
    Идентифицирует единицу измерения. В нашем примере мы определили собственную единицу измерения – ‘Person’.

6.1.4.4. Факты

Теперь мы наконец достигли финальной цели всего нашего упражнения – передачи фактов:


35
41


23
27
12
15


5
9
23
21
7
11

Каждый факт – это отдельный связанный с концептом элемент. Значение элемента является значением факта.


  • contextRef
    Каждый факт ссылается на свой контекст через id контекста. Наш пример содержит факты для каждого концепта в каждом из контекстов.
  • unitRef
    Поскольку для всех числовых фактов должны быть указаны единицы измерения, в нашем примере заполняем здесь ‘u_person’.
  • decimals
    Для числовых фактов должен быть задан один из атрибутов – decimals (десятичные знаки) или precision (точность). В нашем примере все факты целочисленные, поэтому указываем decimals со значением ‘0’.

6.1.5. С гордостью представляем вам – наш отчет XBRL


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


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


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


image


В общем, мы неплохо потрудились!

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

https://habrahabr.ru/post/334356/


Метки:  

Подготовка к проекту внедрения SAP HCM

Пятница, 04 Августа 2017 г. 20:37 + в цитатник
Данная заметка адресуется бизнесу, заказчикам, которые начинают думать о внедрении новой системы, будь то SAP или не SAP. Мне удалось поработать со стороны заказчика, со стороны консалтинга (не только SAP), что дает чуть более широкое понимание проблем с обеих сторон. Хочу также отметить, что проблемы, или, давайте назовем это задачами, одинаковые для любой страны. Я могу судить по работе на проектах в США, Норвегии, Венгрии, России. Исключительно мой опыт.

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

В рамках проекта консультанты опираются на задачи проекта и требуют бизнес унифицироваться. Получается такая ситуация, когда бизнес самого себя просят самостоятельно устаканиться и отдать за это деньги чужим людям. Я также в свое время мотивировал себя ходить в спортзал — раз заплатил, то «нуна ходить». Сама по себе унификация тоже не очень понятный процесс. Представьте большой бизнес, где множество компаний, разные функции, разная иерархия управления. Простой пример: крупный завод на десятки тысяч персонала и малюсенькая компания с продавцами продукции на экспорт. И это все в рамках одного объема проекта, где должны быть унифицированные процессы, документы и методики. Для одних мельчайшее изменение аукнется численностью, фондами, эффективностью закрытия периода, другие вовсе не заметят. А упразднение одной из премий для первых пройдет просто другим видом начисления, а вторым может похоронить мотивацию продавцов. Потому что унификация.

Отчетность, особенно внутренняя, является еще одним камнем в огород обеих сторон. Бизнес говорит, что нужны отчеты, обычно в установленных формах, а консультанты предлагают «какие-то странные выгрузки из системы в кривом формате». Возникает конфликт устоев и прогресса, в котором обычно побеждает сложившаяся практика на предприятии по документообороту. Если справка по физобъемам должна лежать каждое утро у начальника цеха на столе, то никакая система не поможет пока начальник не начнет открывать систему по утрам. На западе такая практика встречается реже, когда заказчик требует формирование бумажных отчетов. Люди работают с современными технологиями дольше и больше, поэтому безбумажный документооборот развит и проекты запускаются проще. Разумеется, что это не касается законодательной отчетности.

Методология это самый большой объем работы на проекте. Скажу по секрету, что часто говорят о необходимости унифицировать процессы, а на практике процессы занимают процентов 10 от реальной работы по унификации. Основное это бумажки и расчеты, и зачастую это связано с требованиями законодательства, в то время как процессы практически не регламентируются законами. Под методологией я понимаю алгоритмы расчета тех или иных величин, правила заполнения отчетов и выходных форм. На входе в проект заказчик любит оперировать цифрами 80/20, 70/30 или иными конкретными величинами измеряющими результат унификации. С одной стороны какая разница сколько будет видов оплаты, ведь это всего лишь справочник? А с другой стороны необходимо на всех уровнях понимать что такое фонд оплаты труда, что такое затраты на персонал (это понятие обычно шире, чем фонд оплаты труда). В моем понимании идеальная унификация стремится к нулю, к упрощению до максимального уровня, не противоречащего закону и целям бизнеса.

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

В западной практике я встречал такой подход. Есть основная часть заработной платы — оклад или тариф. Его формирование устанавливается по единому алгоритму для всех категорий сотрудников независимо от способа учета и характера работы. Эту базовую часть все подразделения понимают одинаково. Мотивационная часть (премии, надбавки, доплаты) формируется из нескольких основных видов начислений, которые называются общими словами (например, «Премия за результат», «Премия за качество», «Надбавка за условия труда» и пр.), а что внутри этих начислений отдается на откуп каждому подразделению. Так «Премия за результат» у продавцов содержит один смысл, у рабочих другой, у ТОПов третий. И неважно как считается эта величина. С точки зрения управления персоналом это одна сумма, которая должна быть рассчитана и предоставлена ответственным подразделением. Как это подразделение рассчитает и управляет этим начислением никого не волнует, так как это прямая ответственность руководителя этого же подразделения. Такое решение идеально вписывается в концепцию унификации: количество алгоритмов в зоне внимания HR минимально, мотивация каждой группы персонала определена в зоне соответствующего предприятия или подразделения, понимание фонда единое у всех, головная боль HR стремится к нулю, так как функция децентрализована. Отсутствие автоматизации? Отнюдь. Так как каждое подразделение или предприятие живет в своем темпе (своя система мотивации, свои показатели, свои скорости работы и оценки результатов), то каждое подразделение самостоятельно озабочено инструментарием для эффективного выполнения этой функции. Кому-то достаточно Excel раз в год, а другим нужна онлайн интеграция с производственными системами. Но эти задачи переходят в зону ответственности этого подразделения, и оно лучше HR знает как выполнить эту задачу эффективно.

План мероприятий по подготовке к проекту внедрения SAP HCM

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

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

Процессы. Пожалуй это самое популярное слово при внедрении. Все хотят упростить, унифицировать процессы. Если посмотреть на процессы после внедрения SAP и до, то отличий будет не так много, сколько было шума вокруг этого. Унифицировать процессы без привязки к системе очень просто. Берем самый простой вариант процесса и самый сложный (как выше в примере с заводом и продавцами). Смотрим чем они отличаются (с большой степенью вероятности отличия будут в количестве коммуникаций и выходных формах), приводим процессы к наисложнейшему по всем предприятиям. А потом откусываем шаги согласно первому принципу «сломайте, чтобы построить». Не нужно строить красивых диаграм и поэм — в реальной повседневной жизни никто не заглядывает в эти многотомники. Простая табличка в Excel поможет.

Бумажки. Вторая после методологии больная тема. Бумажки это все то, что не нужно закону. В одной компании был проведен эксперимент с изъятием принтеров. Люди физически не могли напечатать документы. Через полгода количество документов по электронной почте сократилось в разы. Вместо «где отчет?» стал возникать вопрос «где посмотреть?». Я верю, что есть документы, которые нельзя унифицировать. Например, дополнительные соглашения к трудовым договорам. Достаточно переработать документы по наиболее массовым случаям и их унифицировать и автоматизировать. Все остальное вынести за рамки проекта и унификации как в ситуации с премией за результат. При массовом подборе и найме в розничном бизнесе документы легко унифицируются и автоматизируются, но зачем это делать для промышленных гигантов?

Люди и проект. Это самая щепетильная тема. Любой управленец знает, что люди болезненно воспринимают изменения. Даже перестановку стола в кабинете можно считать за объявление войны, неуважение к отданным предприятию лучшим годам жизни. Начиная проект по внедрению такой системы, а это большой проект, каждый его участник со стороны бизнеса морально чувствует, что это временно и против него. Даже руководитель проекта имеет опасения, что после проекта его роль завершится, и он станет не нужным предприятию. Перед стартом проекта у людей должно быть четкое понимание, что с ними случится после завершения проекта. Любой проект это стресс, это дополнительная работа, которая отличается от привычной. Многие участники проекта рассматривают это как допнагрузку, которая никак не компенсируется. Стоит заранее подумать о мотивации людей работать в проекте эффективно, а не из под палки «иначе уволим».

Коммуникации или «а поговорить». Многие руководители стали руководителями потому, что они начали или умели разговаривать. Правильно формулировать и доносить свои мысли до собеседника. Когда начинается проект, то об этом забывают. Проект подразумевает вовлечение большего количества людей, чем мы привыкли видеть ежедневно. Появляется новый барьер, который нужно преодолеть, чтобы достичь результата. Но вот незадача — нет мотивации. Зачем идти и разговаривать с кем-то, если лично мне это ничего не даст. Со своим руководителем или подчиненными — всегда пожалуйста, так как стимулы понятны. А тут совершенно другие люди (как в бизнесе, так и внешние консультанты), результаты общения с которыми не предвидят никакой мотивации. В итоге мы видим постоянный недостаток информации у всех участников проекта на всех уровнях. Чтобы снизить потенциальные риски из-за коммуникаций еще до проекта нужно выстраивать правила общения. Не формальные регламенты кто, куда, зачем и когда, а нечто иное. На практике это может быть организация проектных инициатив, которые в стратегическом плане приведут самих участников к пониманию необходимости внедрения новой системы. Раньше на предприятиях были такие штуки как «рацухи» — рационализаторские предложения, реализация которых сделает предприятие или процесс в чем-то лучше. Это и есть проектная инициатива, которая может вовлечь большое количество людей без объявления проекта, подготовив тем самым и команду, и бизнес к изменениям.

Самое главное, с моей точки зрения, как и многократно ранее было замечено в других статьях, это максимально точно донести цель внедрения до наибольшего количества людей в компании.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334928/


Метки:  

Как перенести сервер Zimbra на другой сервер

Пятница, 04 Августа 2017 г. 19:57 + в цитатник
Очень много вопросов у системных администраторов вызывает миграция Zimbra Collaboration Suite с одного сервера на другой или миграция с версии на версию. Самый простой и эффективный способ это сделать — воспользоваться бесплатным инструментом Zextras Migration Tool.

image

Zextras Migration Tool — бесплатный инструмент Zextras Suite, который позволяет переносить данные и настройки почтовых доменов из любой версии Zimbra Collaboration Suite в другую. Для переноса также потребуется модуль Zextras Backup, который входит состав Zextras Suite и у которого есть 30-дневный пробный период с полной функциональностью.

Основные особенности Zextras Migration Tool:

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

Установка


Для установки Zextras Migration Tool не требуется дополнительного программного обеспечения. Скачайте модуль с официального сайта и распакуйте его в любом каталоге:

$ tar xfz Zextras_migration_tool-X.X.X.tgz
$ ls
Zextras_migration_tool-X.X.X.tgz Zextras_migration_tool-X.X.X/


Внутри каталога Zextras_migration_tool-X.X.X находится файл install.sh. Если запустить его с параметром -h, то можно увидеть пояснения по установке.

$ cd Zextras_migration_tool-X.X.X
$ ./install.sh -h

./install.sh -h | ./install.sh [ -u ] all|zimlet|core

-h This very message
-u Uninstall the target

The targets available for (un)installation are:
core -- Zextras Migration Tool Core
zimlet -- Zextras Migration Tool Zimlet
all -- Zextras Migration Tool Core followed by Zextras Migration Tool Zimlet

* In order to use Zextras Migration Tool both
* core and zimlet need to be installed.


Чтобы успешно выполнить установку, нужно либо стать пользователем root, либо выполнить скрипт с привилегиями root.

$ su -
# ./install.sh all


Или:

$ sudo ./install.sh all

Переходим к экспорту данных

Экспорт данных с помощью Zextras Migration Tool


На левой панели Консоли администрирования Zimbra Collaboration Suite выберите ZxMig.

image

image

Нажмите «Start Migration».

image

Введите путь для сохранения данных и нажмите «Next». Zextras Migration Tool проверяет пуста ли папка назначения и имеет ли пользователь разрешения для записи файлов.

image

Выберите домены, которые вы хотите экспортировать, и нажмите «Next».

image

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

image

Импорт данных с помощью Zextras Backup


На сервере, куда планируется перенос данных, необходимо установить пробную версию Zextras Suite. Или же приобрести лицензию. Скачайте пакеты с официального сайта (http://www.Zextras.com/Zextras-download-for-zimbra.html) или командой:

Wget http://www.Zextras.com/download/Zextras_suite-latest.tgz

Распакуйте архив:

$ tar xfz Zextras_suite-X.X.X.tgz
$ ls
Zextras_suite-X.X.X.tgz Zextras_suite-X.X.X/


И запустите установку:

./install.sh all

После установки зимлетов Zextras Suite в Панели Администратора перейдите на вкладку «Резервное копирование».

image

Нажмите кнопку «Import Backup» в разделе «Import/Export», чтобы открыть мастер импорта резервных копий.

image

Перенесите сохраненную копию на сервер и пропишите к ней путь. Затем нажмите «Next». Zextras проверит, содержит ли целевая папка действительную резервную копию Zextras и имеет ли пользователь разрешения на ее чтение и редактирование.

image

Выберите домены, которые вы хотите импортировать, и нажмите «Next».

image

Выберите учетные записи, которые хотите импортировать, и нажмите «Next». Учетную запись System Resource импортировать не нужно!

image

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

image

Готово!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334926/


[Перевод - recovery mode ] 10 типов структур данных, которые нужно знать + видео и упражнения

Пятница, 04 Августа 2017 г. 19:41 + в цитатник

[Из песочницы] Как мы оптимизировали Ragdoll анимацию смерти в Unity

Пятница, 04 Августа 2017 г. 19:06 + в цитатник
Или как легко превратить Ragdoll в AnimationClip.



Всем привет, мы маленькая инди-студия Drunken Monday. На днях выпустили игру, где нужно бегать по арене и крутить вокруг себя здоровенным топором, стараясь попасть по другим игрокам. Хорошо попал — убил.

Чтобы смерть от топора была эффектной, мы использовали обычную ragdoll анимацию, построенную на физике. И всё было хорошо. Поначалу.

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

Можно было озадачить аниматоров. Мы даже почти отдали эту задачу в работу, как пришла мысль: почему бы не записать несколько ragdoll смертей прямо в Unity, и потом просто показывать нужную анимацию?

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

Что получилось.gif
image

Реализация


Клип анимации в Unity представлен классом AnimationClip, который содержит множество AnimationCurve, определяющего кривую изменений одного конкретного свойства конкретного объекта, например, свойства localPosition.x. Изменения значений свойства относительно времени описываются множеством структур Keyframe.



Идея простая, для каждого свойства каждого объекта персонажа создать кривую анимации AnimationCurve, и каждый кадр сохранять значения этого свойства на кривой. В конце экспортировать созданный AnimationClip через AssetDatabase.CreateAsset.

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

Properties = new Dictionary ();
 
Properties.Add ( "localPosition.x", new AnimationCurve () );
Properties.Add ( "localPosition.y", new AnimationCurve () );
Properties.Add ( "localPosition.z", new AnimationCurve () );
 
Properties.Add ( "localRotation.x", new AnimationCurve () );
Properties.Add ( "localRotation.y", new AnimationCurve () );
Properties.Add ( "localRotation.z", new AnimationCurve () );
Properties.Add ( "localRotation.w", new AnimationCurve () );
 
Properties.Add ( "localScale.x", new AnimationCurve () );
Properties.Add ( "localScale.y", new AnimationCurve () );
Properties.Add ( "localScale.z", new AnimationCurve () );

Каждый кадр для всех свойств будут проставляться текущие значения:

Properties["localPosition.x"].AddKey (new Keyframe (time, _animObj.localPosition.x, 0.0f, 0.0f));
Properties["localPosition.y"].AddKey (new Keyframe (time, _animObj.localPosition.y, 0.0f, 0.0f));
Properties["localPosition.z"].AddKey (new Keyframe (time, _animObj.localPosition.z, 0.0f, 0.0f));
 
Properties["localRotation.x"].AddKey (new Keyframe (time, _animObj.localRotation.x, 0.0f, 0.0f));
Properties["localRotation.y"].AddKey (new Keyframe (time, _animObj.localRotation.y, 0.0f, 0.0f));
Properties["localRotation.z"].AddKey (new Keyframe (time, _animObj.localRotation.z, 0.0f, 0.0f));
Properties["localRotation.w"].AddKey (new Keyframe (time, _animObj.localRotation.w, 0.0f, 0.0f));
 
Properties["localScale.x"].AddKey (new Keyframe (time, _animObj.localScale.x, 0.0f, 0.0f));
Properties["localScale.y"].AddKey (new Keyframe (time, _animObj.localScale.y, 0.0f, 0.0f));
Properties["localScale.z"].AddKey (new Keyframe (time, _animObj.localScale.z, 0.0f, 0.0f));

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

Готовый класс AnimationRecorderItem.cs

Также создадим управляющий класс AnimationRecorder.
При начале работы этот скрипт должен пробежаться по всем детям анимируемого объекта и создать для каждого из них экземпляр AnimationRecorder, а также сразу сформировать и запомнить relativePath под которым он будет записан в AnimationClip.

Согласно документации relativePath формируется так:
Path to the game object this curve applies to. The relativePath is formatted similar to a pathname, e.g. «root/spine/leftArm». If relativePath is empty it refers to the game object the animation clip is attached to.

Код будет выглядеть так:

private List _recorders;
 
void Start ()
{
	Configurate ();
}
 
void Configurate ()
{
	_recorders = new List ();
 
	var allTransforms = gameObject.GetComponentsInChildren< Transform > ();
	for ( int i = 0; i < allTransforms.Length; ++i )
	{
		string path = CreateRelativePathForObject ( transform, allTransforms [ i ] );
		_recorders.Add( new AnimationRecorderItem ( path, allTransforms [ i ] ) );
	}
}
 
private string CreateRelativePathForObject ( Transform root, Transform target )
{
	if ( target == root )
	{
		return string.Empty;
	}
 
	string name = target.name;
	Transform bufferTransform = target;
 
	while ( bufferTransform.parent != root )
	{
		name = string.Format ( "{0}/{1}", bufferTransform.parent.name, name );
		bufferTransform = bufferTransform.parent;
	}
	return name;
}

Далее каждый кадр считаем текущее время анимации и записывает текущие значения свойств:

private float _recordingTimer;
private bool _recording = false;
 
void Update ()
{
 
	if ( _recording )
	{
		for ( int i = 0; i < _recorders.Count; ++i )
		{
			_recorders [ i ].AddFrame ( _recordingTimer );
		}
		_recordingTimer += Time.deltaTime;
	}
}

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

30 фпс должно быть достаточно для каждого.

Запись будем начинать по нажатию на Пробел.

private const float CAPTURING_INTERVAL = 1.0f / 30.0f;
 
private float _lastCapturedTime;
private float _recordingTimer;
private bool _recording = false;
 
void Update ()
{
	if ( Input.GetKeyDown ( KeyCode.Space ) && !_recording )
	{
		StartRecording ();
		return;
	}
 
	if ( _recording )
	{
		if (_recordingTimer==0.0f||_recordingTimer-_lastCapturedTime>=CAPTURING_INTERVAL)
		{
			for ( int i = 0; i < _recorders.Count; ++i )
			{
				_recorders [ i ].AddFrame ( _recordingTimer );
			}
			_lastCapturedTime = _recordingTimer;
		}
		_recordingTimer += Time.deltaTime;
	}
}
 
public void StartRecording ()
{
	Debug.Log ( "AnimationRecorder recording started" );
	_recording = true;
}

Реализуем экспорт анимации. Создадим объект AnimationClip и заполним собранными значениями.

private void ExportAnimationClip ()
{
	AnimationClip clip = new AnimationClip ();
	for ( int i = 0; i < _recorders.Count; ++i )
	{
		Dictionary propertiles = _recorders [ i ].Properties;
		for ( int j = 0; j < propertiles.Count; ++j )
		{
			string name = _recorders [ i ].PropertyName;
			string propery = propertiles.ElementAt ( j ).Key;
			var curve = propertiles.ElementAt ( j ).Value;
			clip.SetCurve ( name, typeof(Transform), propery, curve );
		}
	}
	clip.EnsureQuaternionContinuity ();
 
	string path = "Assets/" + gameObject.name + ".anim";
	AssetDatabase.CreateAsset ( clip, path );
	Debug.Log ( "AnimationRecorder saved to = " + path );
}

Готовый класс AnimationRecorder.cs

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

Готовый класс AnimationRecorderRagdollHelper.cs

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

Как только холодный труп застынет на земле — жмем Пробел.



Скрипт экспортирует нашу анимацию в корень проекта.



Записываем таким образом по 4-5 анимации для каждого персонажа и включаем их рандомно при смерти.

P. S. Или не совсем рандомно.
Игра мультиплеерная, физика крутится на сервере и оттуда к нам приходит вектор удара. Выбираем анимацию, вектор которой ближе всего к полученному, доворачиваем персонажа в нужную сторону… полетели!

Ссылки


Проект на GitHub

Ролик игры на YouTube с подборкой смертей

Для тех кого заинтересовала игра, ее можно найти в Steam, Google Play, AppStore, Facebook и ВКонтакте.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334922/


Метки:  

[Перевод] Laracon 2017 — краткий обзор и куча полезных ссылок

Пятница, 04 Августа 2017 г. 19:03 + в цитатник

laracon-2017


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


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


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


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


День 1


Freek Van der Herten, Spatie


Тема: Создаем панель управления с помощью Laravel, Vue.js и Pusher


Мне уже был знаком материал, который Фрик осветил в своем выступлении, поскольку я уже читал запись в его блоге на эту тему. И всё же я узнал много нового, поскольку он кодил в прямом эфире, чтобы показать, как сделаны компоненты времени/погоды, статистики packagist и лента Твиттера.


Он также представил впечатляющие в статистику по опенсорс-пакетам Spatie.


Ссылки:



Tom Schlick


Тема: Как строить многопользовательские приложения


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


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


Ссылки:



Adam Wathan


Тема: CRUDово по дизайну


Адам в своем выступлении сфокусировался на том, что контроллеры надо делать как можно более RESTful. Вначале он показал скриншот Basecamp 3, который упоминал в своем твите David Heinemeier Hansson (DHH):


basecamp-3
https://twitter.com/dhh/status/647163196839739392


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


Адам писал код прямо на сцене для демо-приложения — Casthacker. В его файле маршрутов было два контроллера — PodcastsController с 13-ю методами и EpisodesController с 5-ю.


Он переработал их в дополнительные контроллеры при помощи следующих принципов:


  • Если это вложенный ресурс, создавайте новый контроллер
  • Если ресурс можно редактировать независимо, создавайте новый контроллер
  • Если вы затрагиваете pivot-записи, создавайте новый контроллер и, возможно новую модель (см. последнюю ссылку внизу)
  • Если вы изменяете состояние ресурса, создавайте новый контроллер

Главная мысль демо была в том, что никогда не надо писать кастомные действия. Ограничьте методы контролера до 7 CRUD-действий: index, create, store, show, edit, update и destroy.


// Примеры:
// До
PodcastsController@publish
PodcastsController@unpublish
// После
PublishedPodcastsController@store
PublishedPodcastsController@destroy
// До
PodcastsController@subscribe
// После
SubscriptionsController@store

Его презентацию и демо-приложение еще нельзя посмотреть онлайн, но он написал в Твиттере, что скоро всё выложит. Но если вы уже подписаны на его курс Test-Driven Laravel, то вы найдете эту тему в секции “Publishing Concert Drafts”.


Ссылки:



Maxime Locqueville, Algolia


Тема: Laravel Scout + Algolia + Vue


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


  • Установил Laravel Scout и импортировал модели в Algolia при помощи команды artisan scout:import.
  • Настроил выдачу поисковых результатов в панели Algolia, в частности, назначил веса определенным атрибутам, так чтобы они оказывались выше в поисковой таблице.
  • Создал поисковый интерфейс при помощи компонента Vue — vue-instantsearch. Компоненты в React и чистом JavaScript также доступны на github-аккаунте Algolia.

Если вы не знали, у Algolia Есть опция поиска в документации Laravel.


Ссылки:



Evan You, Vue


Тема: Состояние Vue на 2017 год


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


Первая конференция VueConf проходила в Польше в июне.


Эван в основном говорил о росте Vue: показывал впечатляющую статистику из Github (61.2k+ звезд), NPM (622k+ загрузок в месяц) и Chrome Devtools (228k+ активных пользователей в неделю). Он также приводил примеры роста экосистемы Vue. Самое примечательное из — Weex, мобильный UI-фреймворк.


Также я отметил ряд моментов:


  • Теперь я могу более четко объяснить, почему я предпочитаю Vue. Это самый прогрессивный фреймворк: вы можете пользоваться его функционалом по минимуму, полностью или же оставаться где-то посередине. С Vue это намного удобнее, чем с React.
  • У Vue, как и у Laravel, будут утилиты, которые облегчают процесс тестирования frontend-кода. Эван упомянул что они все еще над ними работают.
  • По мнению Эвана цель Vue — более счастливые и работоспособные разработчики.

Ссылки:



Nils Adermann, Composer/Packagist


Тема: Управление зависимостями


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


Во второй половине доклада дали хорошие подсказки для композера:


  • Мейнтейнеры пакетов — последовательно используйте SemVer, чтобы сообщать пользователям об изменениях
  • Документируйте все изменения.
  • Пользователи — используйте консервативное ограничение версий для зависимостей.
  • Используйте composer update [--dry-run] вместо полного composer update. Метка dry-run позволяет просматривать изменения без какого-либо влияния на файлы.
  • Отправьте composer.lock в систему контроля версий. Используйте git checkout composer.lock, чтобы разрешать конфликты слияния в lock-файле.

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


  • Только один человек в команде отвечает за composer.lock для обновления пакетов.
  • Другие члены команды могут запустить composer update , если надо проапгрейдить конкретную зависимость при работе над какой-то функцией или при исправлении баги. Этот момент также надо обговаривать со всей командой, чтобы несколько человек ненароком не обновили один и тот же пакет, пока они работают над чем-то еще.

Ссылки:



Taylor Otwell


Тема: Laravel Horizon (возможно, там было что-то другое, но именно эта тема была у всех в голове)


Наконец, пришло время главного доклада. Тейлор прошелся по всему списку новых функций Laravel 5.5. Я включил в список ссылки на Laravel News и Laracasts, где можно изучить в деталях все функции. Меня особенно порадовали классы кастомных правил валидации. Я писал о них раньше в другой статье.


Но все взоры были прикованы к Horizon. Когда его наконец показали публике, я очень обрадовался, потому что это именно то, что мне нужно для моей текущей работы. Horizon — это пакет Laravel, который помогает управлять очередями через конфигурационный файл. И у него отличный интерфейс. Если вы часто страдаете от того, что приходится управлять несколькими проваленными задачами одновременно через командную строку, то Horizon вам понравится. Одно предостережение: он поддерживает только драйвер Redis, но это опенсорс, так что в сообществе, возможно, скоро добавят поддержку и других драйверов.


Сайт Horizon запустили на 2ой день конференции: https://horizon.laravel.com


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


Ссылки:



День 2


Matt Stauffer


Тема: Настройка Laravel


Мэтт так тараторил, что шутка про повторный просмотр его выступления на Youtube на скорости 0.5 и шуткой-то не является.


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


Что меня особенно зацепило в его выступлении, так это его мысли о читабельности кода:


  • Когда работаешь с новым приложением, самое сложное — разобраться, “где и как это происходит?”
  • Пишите свои приложения так, чтобы любой, кто читал документацию Laravel, смог бы в них разобраться.

Мне вспомнилась иллюстрация, которую я видел в книге “Чистый код” за авторством Роберта Мартина (Дядя Боб):


clean-code


Источник:
http://www.osnews.com/story/19266/WTFs_m


Полагаю, плохая читабельность кода будет означать, что показатель “что это за хрень?!” в минуту будет довольно высоким.


Ссылки:



Sean T. Larkin, webpack


Тема: webpack — основные идеи и не только


Шон очень круто объяснил, чем является webpack для backend-разработчиков, которые в основном используют его вместе с Laravel Mix.


webpack — это компоновщик модулей. Он объединяет модули JavaScript (ES6, CommonJS и AMD) для запуска в браузере. У енго модульная архитектура, основанная на плагинах. 80% webpack-а построено на плагинах.


В остальной части доклада обсуждали компоненты плагинов и “tapable” элементы.


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


Вы можете помочь разработчикам webpack, если вы поддержите их на сайте Open Collective.


Ссылки:



Mathias Hansen и Michele Hansen, Geocod.io


Тема: Запуск и масштабирование стороннего проекта


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


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


Ссылки:



Laura Elizabeth


Тема: Отладка дизайна


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


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


Ссылки:



Justin Jackson


Тема: Как создавать приложения, которые люди будут покупать


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


Ключевые мысли его доклада:


  • Создавайте то, что люди хотят, а не то, в чём они нуждаются.
  • Четыре действия, которые должен совершить потенциальный клиент: заметить, захотеть, сделать, и полюбить.
  • Мы должны захотеть ваш продукт, а не нуждаться в нём (что-то похожее я слышал в курсе Economics 101).
  • Люди будут платить деньги, если ваш продукт решает их проблемы и делает их жизнь лучше прямо сейчас.
  • Сфокусируйтесь на людях, а не на идеях. Решайте проблемы специфической группы людей — в идеале вы должны знать этих людей. Посмотрите, в чём у них сложности, и предоставьте им решение.

Он также порекомендовал пару книг. Ссылки на них вы увидите ниже.


Ссылки:



Jeffrey Way, Laracasts


Тема: Убить чудовище


Большинству людей, возможно, было бы интересно послушать выступление Джеффри “Глубинный анализ цветовой темы, которую я использую”. Если судить по комментариям к его видеозаписям на Laracasts, людям интересны IDE-темы так же, как и сам код.


Джеффри озвучил 9 причин, почему нужно “Убить чудовище”. В этот момент я перестал делать записи, и поэтому у меня нет детального изложения его материала. Основная мысль, которую я запомнил (потому что он возвращался к ней много раз) — это то, что все переделки кода должны быть грубыми. Это значит, что если какая-то часть кода перестала вас устраивать, то переделайте ее самым простым из возможных способов. Если после этого ваш код не стал лучше, не бойтесь вернуться к предыдущей версии.


В основном он затрагивал те темы, которые в той или иной степени освещались на Laracasts: очистка внутреннего api, использование одиночных traits, уменьшение количества условий в views, событий/слушателей и объектов запросов.


Под конец он выдал пару интересных цитат. Мне особенно понравилась цитата про убийство кода. Я нашел ее источник и добавил к ссылкам ниже.


Если вам нужно доказательство будущего, то вам не нужен Терминатор T-1000. Вам нужен Кенни из Южного Парка. Нам нужен код, который можно убить легко и весело.


Ссылки:



Jack McDade


Тема: Глубокое влияние


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


В зависимости от того, с какой точки зрения на это посмотреть, его высказывание было либо полностью неуместным, либо как раз-таки попало в точку, поскольку зал был полон людей, которые сидели, уткнувшись в свои ноутбуки или телефоны. Он также говорил о модели обучения, которую он назвал “Заплати вперед”. При такой модели вы обучаете троих людей, и каждый из них в свою очередь обучает еще троих, и так далее. Доклад прозвучал вполне уместно для конца конференции: он не освещал никаких технических вопросов, и всё же заставляла задуматься о некоторых вещах.


Ссылки:


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

https://habrahabr.ru/post/334918/


Метки:  

[recovery mode] ГДЕ ЛОГИКА? Учимся мыслить системно. Часть 2

Пятница, 04 Августа 2017 г. 18:40 + в цитатник
С частью 1 можно ознакомиться, перейдя по ссылке habrahabr.ru/post/334892

III ЧЕРЕЗ ВЗАИМОПОНИМАНИЕ К ЭФЕКТИВНЫМ ВЗАИМООТНОШЕНИЯМ


Для успеха в жизни — умение общаться с людьми гораздо важнее обладания талантом
Джон Лаббок

Итак продолжим…
Оттолкнувшись от вопроса взаимопонимания в отношениях, давайте разовьем тему общения и расширим рамки исследования.
Для того, чтобы четко понимать основы эффективного взаимодействия с людьми, рассмотрим под разными углами принципы Коммуницирования. Для этого можно вспомнить какие-то известные вам события из жизни или обратиться к источникам информации. Например, интернету. Лично я выбрал для себя следующие темы:

1. ДОЗНАЕМСЯ ОБ ЭФФЕКТАХ КОММУНИКАЦИИ


Одним из важнейших аспектов общения, заслуживающим пристального внимания, являет собой его воздействие, оказываемое на участников. Витиевато получилось, но необычно… Другими словами нужно понять, какие факторы общения, вызывают значимую реакцию у общающихся и к каким это приводит последствиям.
Давайте для начала вслушаемся в первые ощущения, открывающиеся при общении. Тут уместно вспомнить слова Коко Шанель: «У вас не будет второго шанса, произвести первое впечатление». Итак, для построения качественной коммуникации с нужными людьми, важно с первых минут правильно организовать общение. Говорят, что сделать это проще в неформальной обстановке. Помните трюк с курилкой из фильма «Москва слезам не верит»:
-А я вот в научный зал Ленинской библиотеки пропуск достала.
-Зачем?
-Представляешь, какой там контингент? Академики, докторы, философы.
-Ну и что, будешь смотреть, как они читают?
-Много ты понимаешь. Там еще курилка есть…
Поменять в лучшую сторону впечатление о себе, конечно со временем возможно, но на это придётся потратить силы и время. Поэтому всё-таки гораздо правильнее позаботиться об этом заблаговременно.

Следующая мысль, на которую я хотел бы обратить внимание, заключается в том, что в любом общении необходимо осознавать то, насколько в нем заинтересованы остальные собеседники. Еще в Ветхом завете подмечено: «Не будь навязчив, чтобы не оттолкнули тебя, и не слишком удаляйся, чтобы не забыли о тебе». В моей практике был случай, когда для отдела продаж компании пригласили психолога, с целью повышения уровня коммуникативных навыков сотрудников. И все шло очень хорошо и даже замечательно, и народ рос над собой, но возник побочный эффект. После нескольких уроков и бесед, сотрудницы вереницей потянулись к этому психологу, ставшему постепенно мессией, для того, чтобы излить ему душу (уж очень душевно он умел слушать) и получить квалифицированные советы (уж очень грамотно он умел разложить все по полочкам). В итоге взвыл психолог, не готов он был к таким нагрузкам. И как только руководство не пыталось его оградить от навязчивых домогательств, но разве можно отказать страждущим людям, которые тебе доверились. В результате он переехал в другой город. Человек он умный и думаю, что подобных ошибок больше не совершал. Если Вы нуждаетесь в общении с кем-то, то попытайтесь вызвать у собеседника взаимный интерес. Старайтесь говорить людям то, что они ждут от Вас услышать, то что им приятно слышать и то что их волнует и занимает. Также эквивалентен и обратный постулат – старайтесь чаще доносить до людей, то что Вы хотите слышать от них. Какая самая употребляемая фраза у мужчин при общении со своими половинками по телефону? «Я тоже…И я тебя…Угу…» — все просто и не требует излишних усилий.
Еще один заслуживавший внимания эффект от общения, я недавно наблюдал в троллейбусе. Пожилая женщина, примостившись напротив дамы интеллигентного вида, стала ей рассказывать свои перипетии с оформлением квартиры и о притязаниях родственников на ее имущество. Интеллигентная дама при этом, осталась безучастной и не проронила ни слова. Но рассказчица осталась очень довольна “общением” и, когда она выходила на своей остановке из транспорта, казалось, что гора свалилась с ее плеч. Почему люди хотят поведать кому-то события из свой жизни, которые существенны только для них самих и абсолютно безразличны для собеседника? При чем человеку не важно, чтобы ему отвечали или как-то еще реагировали на его монолог, ему необходимо просто, чтобы его кто-то слушал. Схожий эффект, Вы наверняка наблюдали, когда человек, придя к кому-то за советом, в ходе своего изложения проблемы, собственнолично и отыскивает ее решение. Остается только поблагодарить безмолвного собеседника за помощь и, не услышав ни слова, уйти. При всем при том, испрашиватель наверняка сам размышлял над решением, но найти разгадку смог, только поведав свои суждения кому-то вслух. Возможно это просто проблемы в общении человека Самого с Собой. А как-никак — это самый надежный слушатель и рассказчик, он всегда под рукой, он никогда не отвернется и не бросит Вас.
А теперь про то что беспокоит. Одной из самых скверных, на мой взгляд, черт для общения является раздражительность. Иногда человек прекрасно осознавая, что со стороны это выглядит отвратительно и дурно влияет на его имидж в целом, но не способен справиться со своими чувствами. Обычно негодование вызывают нелицеприятные оценки действиям и поступкам, раздаваемые собеседниками. Причем несправедливость может выражаться не только сутью информации, но и просто тоном ее донесения. Подобной слабостью могут пользоваться оппоненты, для проявления нервозности у противной стороны и получения психологического преимущества в беседе. И наоборот, если Вам дороги отношения с человеком, старайтесь избегать инициатив, которые его явно раздражают и вызывают напряжение. Например, герой сказки Евгения Шварца «Обыкновенное чудо» говорил по этому поводу: «Если хочешь указать на ошибки, то сначала похвали, мерзавец».
Подметив волнующие нас статические проблемы давайте взглянем на их динамику. Поднимемся над монументальным и окинем взглядом изменчивое и непостоянное.

2. ПРОЩУПАЕМ ВЛИЯНИЕ РАЗВИТИЯ СРЕДСТВ КОММУНИКАЦИИ НА КАЧЕСТВО ОБЩЕНИЯ


В ходе эволюции рода человеческого, эволюционировали и способы его коммуницирования. По мере того как появляются все новые легкодоступные средства связи, увеличивается интенсивность и качество самого общения. А с повышением оперативности доставки сообщений еще и стало оставаться все меньше времени для маневра в формулировании мыслей. В результате в социальных сетях появился свой сленг, чаще всего сводящийся к замене слов и целых выражений более ёмкими фразеологическим оборотами — клише. Например, то что еще в прошлом веке звучало как: «Предоставленная вами информация, кажется мне недостоверной», сейчас можно выпалить изречением: «Аффтар жжет». Возможна даже имитация невербального общения, при помощи смайликов, подмигиваний, значков и т.п. Использование такого жаргона, чаще всего претит людям консервативного воспитания. Но необходимость прикинуться своим в определенном сообществе заставляет даже их подражать этой “дурновкусице”.
Употребление подобного сленга продиктовано все-таки не только желанием выпендриться, но и эффективностью с точки зрения скорости передачи информации. Я где-то читал, что проводились исследования в области военного искусства, по выявлению наиболее эффективного языка — управления людьми во время венных операций. По предположению исследователей, команды на английском языке, звучат короче, чем на русском и при их использовании должно тратиться меньше времени. Но в реальных условиях оказалось, что русскоговорящие военнослужащие управляются с командами более оперативно. При изучении этого феномена выяснили, что команды подаются в основном в виде идиоматических выражений (мата) ограниченного набора, но расширенного вариациями, за счет использования интонаций.
Второй момент, который хотелось бы отметить в этом разделе, это изменение пропорций читателей и писателей. Раньше, в далекой доинтернетовской эпохе, было гораздо больше людей, которые с удовольствием читали и мало писали. Естественно, в те времена, если кто-то уже собрался и записал, какие-то свои мысли и размышления, то донести их до широкого круга читателей было очень сложно, даже для профессионала. Сейчас же интернет в общем и соц.сети в частности позволяют выкладывать свои мысли на всеобщее суждение практически в реальном режиме времени. Люди чаще стали писать, приобрели опыт, у них снизилась боязнь быть непонятыми и они вошли во вкус. В связи с этим: во-первых, у большинства стало меньше времени для чтения, а во-вторых, появилась возможность сразу отвечать и обсуждать прочитанное. Поэтому формат публикаций стал меняться. Статьи более 3 листов теперь не востребованы, люди не могут подарить столько своего драгоценного время автору, если только это не специфические знания, которые в данный момент им нужны “до зарезу”. Хотя если Вы уже дочитали до этого места, видимо есть исключения.

3. ПОДОБЬЕМ ИТОГИ


По традиции, гранулируем информацию в краткие тезисы, для удобства дальнейшего использования:
Вывод 7: Для налаживания долгосрочных эффективных взаимоотношений с людьми, планируйте их построение и развитие заблаговременно и возводите основательно с первого момента общения.
Вывод 8: Если в процессе общения Вы преследуете какие-то интересы, управляйте им. Для этого необходимо уметь четко формулировать для себя, цели которых вы хотите добиться и определять оптимальные способы их достижения.
Вывод 9: Полезно уметь общаться с Самим Собой. Рассуждать, предлагать решения и оппонировать себе, в выборе вариантов. Так же это может быть нелишне для получения опыта риторики вообще и умения импровизировать при общении с оппонентами.
Вывод 10: Если есть необходимость установить доверительные отношения в определенном сообществе людей и не «флудить как лузер, съезжая с темы», необходимо приспосабливаться к стилю общения, присущему данной публике, «разруливая» порог недоверия.
Вывод 11: Если вы хотите общаться с занятыми людьми, старайтесь формулировать свои мысли сжато, но так, чтобы сознание человека могло легко разбавить этот “концентрат” до удобоваримой консистенции.
Вывод 12: Необходимо научиться управлять своими чувствами при общении, не позволяя проявляться спонтанным эмоциям.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334916/


Метки:  

«Советы инженерам»: обзор Huawei S5720-52X-PWR-SI V2R9SPC500

Пятница, 04 Августа 2017 г. 18:35 + в цитатник


Привет, Хабр! Блог Huawei снова на связи!

В эфире очередной выпуск рубрики «Советы инженерам».
И сегодня у нас в гостях заслуженный коммутатор Китая, обладатель почетного звания «Достойная замена модели Cisco 2960S-24-PWR», лидер линейки Huawei по соотношению «функционал/цена» — коммутатор Huawei S5720-52X-PWR-SI V2R9SPC500.


Краткое досье на нашего героя:
48GE PoE+, 4*10GE портов.
SI версия поддерживает L3 маршрутизацию, включая RIP и OSPF.
Версия ПО V200R009C00SPC500.
Мощность блока питания 500Вт, для PoE доступно 370.
Стекирование возможно через 1/10GE Uplinks.
Интерфейсы 10GE поддерживают практически любые трансиверы, в том числе SNR.
Поддерживается управление через web интерфейс и CLI (telnet, ssh v2), SNMP v2c/v3, централизованное через eSight.

А речь сегодня пойдет о нашем опыте использования S5720 в качестве коммутатора доступа для подключения рабочих мест и IP-телефонов.

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

Но, давайте ближе к делу — что удалось выяснить о S5720 и проверить на практике?

Опыт первый. VLAN


Созданы VLAN для офисной сети и для телефонов. Настроены «транки» и пользовательские порты. Включен LLDP.

Для работы Voice VLAN порты настраиваются в режиме «hybrid». IP-телефоны Yealink имеют возможность получения настроек по LLDP, чем мы успешно и воспользовались.

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

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

Вопросов при настройке маршрутизации не возникло — всё работает. Базовые настройки маршрутизации:

router id 192.168.30.4
#
ospf 1
area 0.0.0.0
network 10.0.50.0 0.0.0.255
#
interface Vlanif50
mtu 9198
ospf timer hello 1
ospf timer dead 3


Аутентификация peer не проверялась. В целях ускорения сходимости были настроены нестандартные тайминги (так называемый «LAN-based design»). В качестве «neighbor» успешно использована ASA5512 — работает.

Не обошлось и без нюансов: несмотря на то, что серия SI поддерживает динамический роутинг, он возможен только между интерфейсами Vlan (Vlanif). Т.е. порт нельзя перевести в режим L3 и назначить ему IP-адрес. Это возможно только для серий EI, HI.



Опыт второй. Безопасность


В качестве защиты от наиболее распространённых типов угроз мы настроили DHCP snooping, IP Source Guard, ARP security — все вместе это позволяет избежать некоторых типов атак, наиболее распространённых в офисной сети, в том числе и непреднамеренных.

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

На базе DHCP snooping работают функуции IP Source Guard и ARP security, защищающие от подделки IP и MAC адресов. Здесь суть в том, что работа возможна только с адресом полученным по DHCP, а связка «порт—IP—MAC» создается и проверяется автоматически.

Данная настройка убережет нас, если кто-то захочет использовать чужие IP-MAC, или организовать атаку типа MITM-атаку («Man-in-the-Middle»).

Третий тип возможных угроз — это атаки на STP. Здесь в качестве защиты на пользовательских портах включена фильтрация BPDU (то есть никакие STP-фреймы не отправляются пользователю и не принимаются от него).

Кроме того, ведёртся контроль появления посторонних BPDU stp bpdu-protection, что возможно при подключении другого коммутатора или атаки на stp root.

Активированная опция «stp edge-port enable» исключает порт из расчёта STP, уменьшая время сходимости и нагрузку на коммутатор.

Комбинация stp bpdu-protection и stp edge-port enable, аналогична Cisco spanning-tree portfast.

Собственно, примеры конфигурации:

dhcp enable
#
dhcp snooping enable
dhcp snooping alarm dhcp-rate enable
dhcp snooping user-bind autosave flash:/dhcp-bind.tbl write-delay 6000
arp dhcp-snooping-detect enable
dhcp server detect

vlan 2
name office
dhcp snooping enable
dhcp snooping check dhcp-request enable
dhcp snooping check dhcp-rate enable
arp anti-attack check user-bind enable
ip source check user-bind enable

vlan 3
name guest
dhcp snooping enable
dhcp snooping check dhcp-request enable
dhcp snooping check dhcp-rate enable
arp anti-attack check user-bind enable
ip source check user-bind enable

vlan 4
name voice
dhcp snooping enable
dhcp snooping check dhcp-request enable
dhcp snooping check dhcp-rate enable
arp anti-attack check user-bind enable
ip source check user-bind enable

interface GigabitEthernet0/0/1
port link-type hybrid
voice-vlan 4 enable
port hybrid pvid vlan 2
port hybrid tagged vlan 4
port hybrid untagged vlan 2
stp root-protection
stp bpdu-filter enable
stp edged-port enable
trust dscp

stp instance 0 root primary
stp bpdu-protection


Опыт третий. Администрирование


Выполнена настройка административной части, к которой относятся NTP, SNMP, AAA, Radius.

Выяснилось, что можно активировать до 16 линий VTY, тогда как по умолчанию только 5.

И, собственно, некоторые удобства администрирования.

user-interface maximum-vty 15
user-interface con 0
authentication-mode aaa
history-command max-size 20
screen-length 40
user-interface vty 0 14
authentication-mode aaa
history-command max-size 20
idle-timeout 30 0
screen-length 40


Что важно отметить ещё?

Для доступа по SSH необходимо добавление именно пользователей SSH, кроме пользователя в разделе ААА.

Ключи RSA уже сгенерированы, но если меняли имя и домен на коммутаторе, то рекомендуем сгенерировать ключи заново.

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

stelnet server enable
[HUAWEI] aaa
[HUAWEI-aaa] local-user admin123 password irreversible-cipher Huawei@123
[HUAWEI-aaa] local-user admin123 service-type ssh
[HUAWEI-aaa] local-user admin123 privilege level 15
[HUAWEI-aaa] quit
[HUAWEI] ssh user admin123 authentication-type password


Также нам удалось настроить аутентификацию администраторов через Radius.

Необходимо отметить, что для администраторов используется схема под названием domain default_admin!

domain default_admin
authentication-scheme default
accounting-scheme Radius
service-scheme Admin
radius-server Radius


Опыт четвертый. Замена сертификата устройства на действительный


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

Импорт сертификата возможен только из CLI.

Столкнулись с тем, что ключи и сертификат должны быть отдельно, несмотря на то, что формат «pfx» позволяет экспортировать закрытый ключ в составе сертификата.

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

При стандартном экспорте в pem, сначала в файле идут сертификаты CA и только в конце сертификат устройства.

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

Представляем вашему вниманию пошаговый алгоритм:

1. Сгенерировать сертификат на внешнем CA.
2. Экспортировать отдельно сертификат или цепочку и закрытый ключ.
3. Если это цепочка — открыть файл сертификата блокнотом и перенести последний блок (сертификат устройства) в начало файла, сохранить.
4. На коммутаторе создать папку mkdir flash:/security
5.Поместить в папку файл сертификата и ключ tftp 192.168.0.1 chain-servercert.pem /security/chain-servercert.pem
После этого, согласно инструкции, создать политику и выполнить импорт.

system-view
[HUAWEI] ssl policy http_server
[HUAWEI-ssl-policy-http_server] certificate load pfx-cert servercert.pfx key-pair rsa key-file serverkey.pfx auth-code cipher 123456
# Load a PEM certificate chain for the SSL policy.

system-view
[HUAWEI] ssl policy http_server
[HUAWEI-ssl-policy-http_server] certificate load pem-chain chain-servercert.pem key-pair rsa key-file chain-servercertkey.pem auth-code cipher 123456

Для применения политики необходимо перезапустить https сервер, но отдельно он не перезапускается. Поэтому необходимо перезапустить весь web сервис.

http server disable
http server enable

В итоге экспорт прошёл успешно, и web-интерфейс использует достоверный сертификат.

Подводим итоги


В качестве итогов — несколько цифр и выводов:

  • Загрузка CPU коммутатора даже на холостом ходу порядка 20%, и периодами возрастает до 30%. Влияния на трафик не замечено.
    CPU utilization for five seconds: 25%: one minute: 25%: five minutes: 24%
    TaskName CPU Runtime(CPU Tick High/Tick Low) Task Explanation
    VIDL 75% 2/187119ff DOPRA IDLE
    OS 12% 0/55d4a7fe Operation System
    POE 4% 0/204e4380 POE Power Over Ethernet

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

    Input peak rate 804556024 bits/sec, Record time: 2016-08-15 15:09:17
    Output peak rate 999957528 bits/sec, Record time: 2016-08-12 12:20:09

  • Один из телефонов наотрез отказался подключаться на скорсти 1000Мбит/с, только на 100Мбит/с. Настройки AUTO, с обоих сторон. Прямое подключение к коммутатору 1м патч-кордом, смена порта коммутатора не помогли. При этом к Cisco 2960 телефон подключался на 1G стабильно. Это один из 20 аналогичных телефонов. Вопрос так и не был решен.

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

P.S. До встречи в следующих выпусках, господа Инженеры!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334910/


Метки:  

«Ржавая» IP-камера: прошивка на Rust

Пятница, 04 Августа 2017 г. 18:01 + в цитатник
До появления ботнета Mirai только особо интересующиеся знали о том, что находится внутри обычных IP камер. В большинстве случаев там стоит обычный линукс, причем частенько с дефолтным рутовым паролем, а то и вообще без него: у нас в офисе стоит такая камера, с прошивкой от декабря 2016 года и беспарольным рутовым телнетом.

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

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

Мы решили исправить эту ситуацию своей прошивкой, причем сделав ставку на Rust.



Условия работы



Нужно сделать пару пустяков: разобраться с SDK, написать код, который настраивает железо, принимает H264 кадры и отправляет их в сеть. Пара пустяков, особенно учитывая насколько легко и просто деплоиться на IP камеры и отлаживать это всё. Ну и оставшая мелочь: мы решили писать этот код на Rust.

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

Почему не подойдет Go, Erlang или какая-нибудь Java/C#? Потому что на IP камере флешка на 8 мегабайт и 128 мегабайт памяти из которых половина отнята у ядра под нужды видео. Понятно, что камеры есть разные, но всегда стараются делать по минимуму, чтобы не поднимать стоимость без нужды. На одной камере мы видели флешку на 64 мегабайта, там конечно можно развернуться, но хватает и совсем крохотных флешек.

Так, обычная картина на дешевой камере за 3000 рублей мы видим:

# free
             total       used       free     shared    buffers     cached
Mem:         60128      17376      42752          0       2708       4416
-/+ buffers/cache:      10252      49876
Swap:            0          0          0
# cat /proc/cpuinfo 
Processor	: ARM926EJ-S rev 5 (v5l)
BogoMIPS	: 218.72
Features	: swp half thumb fastmult edsp java 
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 5

Hardware	: hi3518
Revision	: 0000
Serial		: 0000000000000000


В таких условиях паршиво написанный софт начинает очень сильно страдать уже от 3-4 подключений. Золотое правило при работе с IP камерами: вообще стараться больше одного подключения (или два, по одному на каждое качество) не делать и это связано не только с узким каналом до камеры, но ещё с тем, что четвертый клиент к IP камере зачастую делает невозможным просмотр у первых трех. Забегая вперед, скажу что у нас и на 50 клиентах проблем не возникло.

Как устроена камера



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

На камеру напаяна SPI флешка. Это такая же флешка, как та, на которую прошивает себя в биос какой-нибудь локер. Содержимое этой SPI флешки можно прочитать, подцепившись клещами, можно записать (если повезет), с неё же считывает данные в память процессор и выполняет их. Бывает, что флешка не SPI, а NAND, тогда всё сложнее: просто так клещами не подцепишься — приходится быть ответственнее.

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

У uboot открытые исходники, но в нём хранятся данные, специфичные для конкретной железки. Если скопировать флешку с камеры, сделанной фирмой XM на камеру, сделанную фирмой Hikvision, то есть большой шанс, что даже uboot не загрузится.

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

Но ничего страшного, всё это решаемый вопрос, двигаемся дальше.

А дальше находится ядро линукса. Было бы слишком просто, если бы можно было одно ядро собрать для всех возможных камер и потом просто модули перетыкать. Нет, так нельзя, поэтому для разных версий чипсета нужны разные ядра: где-то 2.x.y, где-то 3.x.y. Почему так? Потому что к ядру идут закрытые модули. Где-то можно исхитриться, но всё равно унифицировать всё не получится.

После этого идет обычный хозбытовой buildroot. Здесь всё как у людей.

Дальше надо запустить хитрые скрипты, настраивающие железо через i2c (и возможно как-то ещё), загрузить правильные модули и стартовать специально написанный софт.

Захват видео



В захвате видео очень много подготовки железа. Если почитать спецификацию onvif и мануал по SDK IP камеры, то можно увидеть много общего — софтверный интерфейс отражает общую структуру большинства железяк и она следующая: видео снимается с сенсора, немножко обрабатывается, потом засовывается в энкодеры (аппаратные конечно) и потом в софтине можно забрать из определенного места в памяти готовые H264 NAL юниты. Для базового сценария осталось только приделать управление пользователями, настройки и какой-нибудь сетевой протокол. Для полноценной камеры ещё нужна поддержка всяких механизмов массовой настройки (discovery, onvif, psia, etc..) и аналитика.

А чего там про Rust



Вот как раз стример у нас ржавый. Целая пачка unsafe кода, автогенеренного из сишного кода SDK с помощью bindgen, подпатченый биндинг к libc (постараемся залить патч в апстрим) и дальше реализация RTSP на tokio. Даже уже есть возможность посмотреть видео с камеры в обычном браузере — это недостижимая роскошь для китайских камер, которые поголовно требуют установку ActiveX.

Структура очень непривычна после эрланга: ведь тут нет процессов и сообщений, есть каналы, а с ними всё становится немножко по-другому. Как я уже выше писал, современно написанный код с правильной организацией дает возможность раздавать видео не 2-3 клиентам, а более 50 без какой-либо просадки производительности.

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

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

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

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

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

https://habrahabr.ru/post/334912/


Метки:  

Пятничная дискуссия

Пятница, 04 Августа 2017 г. 17:22 + в цитатник

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


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

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

https://habrahabr.ru/post/334906/


Метки:  

RADIUS аутентификация пользователей доверенного домена

Пятница, 04 Августа 2017 г. 17:11 + в цитатник

Зачем и почему это?


Так сложились обстоятельства, что мне пришлось администрировать уже настроенную RADIUS аутентификацию пользователей одного доверенного домена на узле Mikrotik, который либо пропускал в интернет пользователей, либо нет. Раньше такого настраивать не приходилось, был в распоряжении просто уже готовый настроенный «черный ящик». Задача была добавить пользователей еще одного домена в эту схему аутентификации.
Чтобы я помнил эту историю вечно, сюда и описываю процесс.

Как оно работает?


Итак, начал смотреть как это все работает в текущей схеме. На первый (да и не первый тоже) взгляд все по учебнику:
  • На неком компьютере домена AUTHSRV.DOM1.LOCAL (win2003), поднята «Служба проверки подлинности в интернете».
  • В ней прописан клиент — Mikrotik, с общим секретом.
  • Домен DOM1.LOCAL (win2008) имеет двустороннее доверие с DOM2.LOCAL (win2003).
  • В DOM2.LOCAL создана глобальная группа allow_internet, в которую добавлены пользователи, которые должны успешно проходит аутентификацию на Mikrotik.
  • На компьютере AUTHSRV.DOM1.LOCAL создана локальная группа allow_internet, в которую включена глобальная группа доверенного домена DOM2.LOCAL\allow_internet.
  • Соответственно в настройках службы проверки подлинности создана политика удаленного доступа, разрешающая доступ, если пользователь входит в группу AUTHSRV\allow_internet.

Все выглядит логично и действительно работает как ожидается.

Как сделать чтобы заработало?


Вижу цель — не вижу препятствий. Создаю двустороннее доверие DOM1.LOCAL с DOM3.LOCAL (win2003). Создаю в DOM3.LOCAL глобальную группу allow_internet, включаю туда пользователей. Добавляю эту глобальную группу в AUTHSRV\allow_internet и радостно пытаюсь авторизоваться.

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

И т.к. недостаток моих знаний не позволил мне понять, что собственно тут-то и кроется ответ, начались изыскания. Никаких следов в логах на контроллерах доменов DOM3.LOCAL или DOM1.LOCAL от этого события не было. Гугл по такой ошибке выдает вообще что-то к делу не относящееся (сплошной RDP). Поиск в групповых политиках на «рабочем» DOM2.LOCAL ничего не дал.
Я даже попробовал проксирование RADIUS запросов, подняв на DC.DOM3.LOCAL также службу проверки подлинности в интернете и трансляцию туда запросов с именем пользователя вида «DOM3*». Тем не менее в логе прокси-RADIUS сервера была точно такая же ошибка и отказ в доступе.

Причина всех бед


А причина всегда одна — безблагодатность. Оказывается, потому что DOM3.LOCAL работал в mixed-режиме, то на всех пользователях по-умолчанию на вкладке «Входящие звонки»/«Dial-in» атрибут «Разрешение на удаленный доступ (VPN или модем)» имеет значение «Запретить доступ», в отличие от DOM2.LOCAL.
Сменил режим работы домена DOM3.LOCAL на «native» и изменил на всех пользователях атрибут атрибут «Разрешение на удаленный доступ (VPN или модем)» на значение «Управление на основе политики удаленного доступа» (которое до смены режима работы домена было недоступно) следующим скриптом:
Set objOU = GetObject("LDAP://dc=DOM3,dc=local")
objOU.Filter = Array("user")
For Each objUser In objOU
objUser.PutEx 1,"msNPAllowDialin", vbnull
objUser.SetInfo
Next

После этого все заработало так как должно было.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334904/


Метки:  

Может ли дрон купить пиво? (Вопрос к размышлению)

Пятница, 04 Августа 2017 г. 17:04 + в цитатник
С Днём пива! Как сказали бы древние шумеры: «Не знать пива — не знать радости». В честь этого события мы хотим поделиться историей нашего друга о том, как один он решил стать пивоваром, а также рассказать всякие факты по теме.



Наверно сейчас вы задумались над вопросом, который указан в заголовке статьи, так же как и мы с kichik. В итоге мы пришли к выводу, что всё же дрон не может купить пиво, потому что становится невозможным идентифицировать хозяина, а значит и законность продажи алкоголя.
UPD Так как этот вопрос вызвал спор, присоединяйтесь к голосованию во ВК и делитесь своим мнением в комментариях. Давайте докопаемся до истины вместе.

Заметки дилетанта


Решил поделиться с общественностью результатами прошлогоднего железно -ИТ-шного приключения по созданию домашней облачной пивоварни.

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

В принципе в мире существует два основных типа автоматизированных домашних пивоварен – трёхкотловая HERMS (Heat Exchange Recirculating Mash System) и двухкотловая RIMS(Recirculating Infusion Mash Systems). Решили сделать HERMS. За основу взяли вот такую схему:



Использовано у нас тут 12 шаровых кранов (некоторые пришлось менять, так как латунные на температурах близких к 100 замечательно клинит), два насоса (Н1, H2), пара тенов (T1, T2) на 3.5 Kw и медные трубки на обжимах, которые мы прокляли после пары пересборок системы и заменили на прозрачные шланги.

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

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



Пивные технологии


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

Для начала познакомимся с автоматизируемым процессом. Само по себе пивоварение достаточно простое и хорошо автоматизируется. Оперируя тремя исходными материалами – хмелем, солодом и водой, а также температурой и перемещением нашего продукта между ёмкостями, можно получить практически всё для пенного напитка. Для составления рецептов есть хорошие готовые приложения, например, BeerSmith и BeerTools, которые высчитывают даже цвет итогового напитка по используемому сырью, в них же указаны все важные промежуточные значения на этапах варки, чтобы процесс можно было корректировать.
При этом при простоте основного техпроцесса в производстве есть огромное количество нюансов, фишечек и интуиции, которые дают огромные возможности для творчества и бесконечного «улучшайзинга».

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



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

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

На этом этапе есть несколько способов автоматизации процесса. Можно нагревать непосредственно заторник: греть нужно снаружи плиткой, чтобы не получить жжёный солод. Для наиболее частых схем домашних пивоварен (HERMS и RIMS) сусло прокачивается через фильтр на дне чана и нагревается через теплообменник либо горячей водой из другого чана, либо прокачивается через проточный нагреватель.

На картинке виден теплообменник в левом баке. А в правом «лейка», через которую будущее сусло сливается обратно в заторник.



Ещё одним способом нагрева является «Infusion», когда мы подливаем нагретую воду из других ёмкостей, высчитывая при этом разницу объёмов и температур, чтобы получить итоговый результат. Это удобно использовать в простом домашнем пивоварении, без автоматизации.
После производим «Мэш-аут» – поднимаем температуру до 77 чтобы ферменты прекратили работу. Здесь можно провести первичное охмеление, если нужно по рецепту, но главное теперь очистить наше сусло от «дробины» – того что не растворилось на входе.

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

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

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

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

К процессу решили добавить красоту и визуализацию, поэтому на Raspbery PI была поставлена Win 10 Core и написано WPF-приложение, которое при подключении к HDMI рисовало весь техпроцесс:



Конечная схема слегка отличается от изначальной, но это же инженерия! Приложение позволяет в ручную управлять клапанами, тенами и насосами, а также запускать вручную и автоматически по рецептам все циклы процесса. Ну и конечно, подключили всё к IoT Hub чтобы собирать статистику температур и времени работы системы.

Об авторе



Алексей Любко — более 15 лет занимается разработкой прикладных информационных систем на базе технологий Microsoft для государственных органов и коммерческих организаций. Технический руководитель первого в РФ центра инноваций Microsoft в МИФИ. В настоящее время руководитель разработки и сооснователь продукта Pryaniky.com. На протяжении 9 лет обладатель статуса Microsoft Most Valuable Professional (Microsoft MVP).



10 фактов о пиве


Во время подготовки статьи мы с ahriman (Сашей Белоцерковским) читали разные статьи, и нашли несколько интересных фактов, которые решили «не убирать в стол» и поделиться с вами.

Факт 1. Существует мнение, что выращивание зерновых культур началось не для того, чтобы кормить народ хлебом, а для того, чтобы поить пивом. Оно, конечно, выглядит радикальным, но имеет место быть. В 2013 году об этом написали Вести: Получается, что движущей силой развития человеческой цивилизации была страсть к алкогольным напиткам.

Факт 2. Считается, что пиву почти столько же тысячелетий, сколько нашей цивилизации. Самые древние «следы» пива были обнаружены на западном Иране и датируются 3500—3100 годами до н. э.

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

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

Факт 5. В Хьюстоне существует дом полностью украшенный пивными банками. В 1968 году его придумал и украшал на протяжении 18 лет Джон Милкович.

Факт 6. В 1814 году в Лондоне произошёл настоящий пивной потоп, который в итоге привёл к нескольким жертвам. По описаниям это было жуткое зрелище.

Факт 7. Приятный фруктовый вкус ламбиков достигается засчёт того, что их настаивают в винных бочках.

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

Факт 9. В США есть крафтовая пивоварня, которая использует HoloLens для определения качества своего пива.

Факт 10. В Великобритании вы можете выпить пиво, которое сварено с помощью технологий искусственного интеллекта.

А ещё мы нашли пошаговый туториал от нашего MVP о том, как заниматься пивоварением с Raspberry PI и Windows 10 IoT. Поэтому у нас вопрос.
Перевести ли для вас туториал о пивоварении на русский язык?

Проголосовало 24 человека. Воздержался 1 человек.

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

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

https://habrahabr.ru/post/334902/


Метки:  

Что отставной генерал НАТО преподаёт студентам Университета Иннополис

Пятница, 04 Августа 2017 г. 16:39 + в цитатник
image

В Университете Иннополис студентов обучают профессора и научные сотрудники с опытом работы в ведущих ИТ-компаниях и университетах мира. Также вуз приглашает на гостевые лекции весьма необычных ИТ-специалистов. Мы уже писали о том, как своим опытом со студентами делился хакер Ares, знакомый с Эдвардом Сноуденом. На этот раз мы расскажем о профессоре Анджело Мессине, который работает профессором-практиком Института информационных систем и возглавляет магистерскую программу «Управление разработкой программного обеспечения» в нашем вузе. В интервью он делится воспоминаниями о службе в составе групп войск НАТО, объясняет, почему решил переехать в Иннополис обучать российских студентов и как в Европе армия взаимодействует с наукой.

— Анджело, кем вы работали последние 10 лет?
— До апреля 2008 года я был полковником, заместителем директора по исследованиям и технологиям в Европейском оборонном агентстве (Брюссель, Бельгия). До 2012 — директор подразделения в Секретариате по оборонительному вооружению (Рим, Италия). До 2013 — бригадный генерал, директор департамента логистики в силовом подразделении (Рим). До февраля 2016 — заместитель главы отдела логистики штаба генерала армии (Рим). С 2012 года до января 2017 года — бригадный генерал Итальянской армии.

— С чего началась ваша служба в армии, вы заканчивали военное училище?
— Я учился в одном из лучших университетов Италии — в Туринском политехническом университете, где получил степень по инженерным наукам. Там же я защитил кандидатскую (PhD) и прошел курсы профессиональной военной подготовки для общего и объединенного состава штаба.

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

С третьего курса в течение года студент изучает только военные дисциплины. Затем можно вернуться в университет и завершить учёбу по выбранной специальности. На это даётся всего 3 года. И с этим строго. Если студент не сдаёт экзамен или переносит сроки сдачи, это влечёт за собой дисциплинарные наказания. В этом отличие между обычным студентом и студентом в «военной форме» — последние должны строго соблюдать установленный график обучения. Например, если я заявляю, что через три года получу специализацию, я обязан сделать это. Это не значит, что на этом подготовка завершается — заканчивается только 5-летний срок обучения.

Моя карьера в армии началась со звания лейтенанта, затем я стал лейтенант-капитаном, майором, подполковником, полковником и дослужился до генерала.

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

Исключением была моя преподавательская практика в сфере высоких технологий. Курс, который я читал, относился к сфере безопасности и не предназначался для офицеров гражданской службы. 
Название курса я не могу раскрыть, поскольку эта информация принадлежит итальянской армии. Я не вправе разглашать названия курсов, связанных с военной сферой, но могу рассказать, какие курсы читал в военной академии. Я преподавал компьютерные науки (Computer Science), в частности, совместный курс от Министерства обороны и Министерства связи и телекоммуникаций Италии по персональным компьютерам (Personal Computers) в течение 7 лет. Также в конце 90-х я 2 года преподавал в военном университете в Риме и читал 2 курса: «Введение в компьютерные науки» (Introduction to Computer Science) и «Общая электротехника» (General Electronics).

— Как вы взаимодействовали с НАТО и чем занимались в США?
— Я сотрудничал с агентством НАТО по связи и информации (NCIA) в качестве независимого консультанта по разработке гибкого ПО (agile software), но это агентство находится не в США.
Я входил в состав многих рабочих групп и групп военных специалистов, связанных с НАТО и ЕС. В США я работал в агентстве Nomisma, которого уже не существует, а также сотрудничал с Агентством НАТО по связи и информации. В Италии я входил в состав множества рабочих групп под руководством НАТО. Одна из них — группа NSIT. Я занимал разные посты: председатель, национальный представитель, секретарь рабочей группы и т.д.

С 2005 по 2008 годы я работал на Европейское оборонное агентство (EDA) заместителем директора по исследованиям и технологиям. Мне повезло быть в числе сотрудников первой группы и работать практически над всеми европейскими научно-исследовательскими программами в составе рамочной программы FP7. Моей задачей было предоставлять результаты исследований, обеспечивать сотрудничество между группами и продвигать исследования в области науки и технологии.

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

Было много интересных поездок. В 2004 году я летал в Сан-Франциско в роли члена рабочей группы НАТО по обмену данными. Ничего секретного, проект был связан с библиотеками и хранением информации, поэтому я могу говорить об этом. Находясь в Сан-Франциско, я параллельно готовился к другой встрече в Швеции, а затем полетел в Рим. Это был интересный опыт: 4 дня и множество перелётов — Рим, Сан-Франциско, Швеция, и снова Рим. В таком режиме я жил 2 года.

Поэтому Россия хорошо вписалась в мою «сеть контактов», в которую уже входили Греция, Испания, Франция, Великобритания, Германия, Швеция. Работа в международной среде научила меня многому — организации, управлению и опыту международного взаимодействия.

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

— Как Итальянская армия взаимодействует с учёными? 
— Сам я исследования не проводил, а занимался их поддержкой и развитием. В ходе научно-исследовательского сотрудничества между Италией и США я был главой делегации, состоящей, в основном, из учёных-преподавателей университетов. Как это было тогда: 70 учёных-преподавателей из разных университетов Италии занимались базовыми научными исследованиями, например, в области фотоники. Делегация встретилась с нашими коллегами из Вашингтона, и мы обменялись результатами. Сам я не занимался исследованиями уже более 20 лет — у меня уже не тот возраст. Научные исследования — удел молодых учёных 25—30 лет, по крайней мере, в мире компьютерной инженерии.

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

— Что интересного происходило с вами в области международного сотрудничества?
— Однажды я давал интервью для европейской газеты, в котором сказал, что Франция (в то время, не сейчас) являлась препятствием для ЕС — её политика была слишком акцентирована на интересах страны. 

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

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

image

— Расскажите, чем вы занимаетесь в Университете Иннополис?
— Я читаю курс по инновационной методологии гибкой разработки ПО. Он по выбору и доступен для всех, но на него чаще приходят студенты магистратуры. В основе курса — программа профессиональной подготовки инженеров Италии. Если вы хотите изучить конкретные виды гибкой разработки ПО для критически важных приложений (mission critical applications) — этот курс для вас. 

Если вы хотите создать безопасный продукт, проверить качество и этапы разработки, не используя каскадный метод разработки, то используйте конкретный вид гибкой разработки. Это как раз то, чем занимался я с моими коллегами при Министерстве обороны Италии, разрабатывая программный комплекс LC2EVO. 

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

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

Студенты здесь очень умные. И я знаю, о чём говорю, так как видел разных студентов в Европе и США. В России они целеустремлённые, всегда готовы преодолевать трудности. Впереди у меня ещё два года, в течение которых я могу передавать им свои знания, мотивировать и убеждать раз и навсегда перейти на гибкие методы разработки. 

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

Но с конца 60-х и начала 70-х годов инженерная мысль стала рациональнее. Инженеры рассуждали так: давайте пропишем все этапы разработки и будем придерживаться процедуры. Так появился метод каскадной разработки, который стал общепринятым до сегодняшнего времени. Оборонная промышленность продвигала эту процедуру и экспортировала программную инженерию в авиацию, космическую и промышленную области. В критических условиях промышленность просто принимала необходимый стандарт, разработанный министерством обороны. 

В начале 90-х внезапно появилось новое поколение устройств. Процедура разработки ПО изменилась: фабричная разработка ушла на второй план — теперь всё можно было делать на одном компьютере. 

Используя платформу Eclipse или средства Microsoft Development Tools, можно было разработать своё собственное ПО, и я не говорю о каких-то сложных программах. Появились персональные «фабрики» по разработке ПО. Конечно, это послужило началом создания технических норм, в мире начался бум разработки ПО. 

Чётких требований к безопасности ПО не было, и разработка шла по лёгкому пути без учёта каких-то норм. Появился огромный рынок — приложения для Android, iOS, стандартное программное обеспечение. Это приносит огромные деньги, а также стимулирует и ускоряет процесс доставки данных. Срок доставки у некоторых приложений, например, Android — каждые несколько часов, у других — пара дней или недель. Разумеется, это совершенно несовместимо с каскадным методом. 

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

— Есть ли разница между руководством военными и работой со студентами? Приходилось ли вам командовать российской молодёжью?
— Я работал с инженерами, которые уже получили специализацию или учились на последнем курсе университета. Так что мой опыт ограничен — ранее я обучал студентов 4—5 курса. А в России я работаю с первокурсниками и для меня это новый опыт.

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

Инженеры-специалисты уже с опытом. Это люди, которым учёба нужна для карьерного роста, поэтому моя основная задача — вызвать их интерес. При этом заставить их заинтересоваться чем-то нельзя. Со студентами всё иначе: они молоды и им интересен предмет, который я преподаю. Здесь только один момент: важно правильно выбирать материал — не давать им то, что они пока не в силах освоить. Иногда приходится упрощать материал, чтобы не уходить «в высокие материи». Студенты полны энтузиазма и храбро идут на экзамен, в то время как инженеры-специалисты на лекциях часто просто ждут, когда занятие закончится.

Я никогда не командую студентами. Я просто вежливо прошу выполнять задания. Российские студенты дисциплинированнее, по сравнению с итальянскими студентами. Разумеется, я имею в виду студентов Университета Иннополис, так как у меня нет опыта преподавания в других российских вузах. Итальянские студенты платят за обучение, поэтому они могут не выполнить задание преподавателя, если оно им не нравится. Здесь иначе: студенты учатся по грантам и слушают преподавателя, старательно выполняют задания, независимо от желаний. 

Конечно, можно наказать студентов плохими оценками, но это зависит от случая. Некоторые студенты очень мотивированы, и их не нужно ни о чём просить — они сами делают, занимаются, изучают. Есть студенты, которые стараются, но не всегда понимают, что они делают. В Италии, если студентам дать общее задание и попросить поработать в группах, часть студентов покинет лекцию. В Университете Иннополис студенты с удовольствием работают в группах. Они достаточно самостоятельны, поэтому иногда я кого-то даже оставляю «за старшего». Почти как в армии! (Смеется).

— Тяжело ли было переехать в Россию? 
— Я знал немного о вашей стране. Мои познания в истории России заканчивались периодом Второй мировой войны — то, что прочитал в книгах. Что-то я узнал из СМИ или на школьных уроках много лет назад. Ну, а мы знаем, что СМИ долгое время находилось под контролем.

После приезда мы с женой обнаружили в России черты, близкие нашей культуре. И, как ни удивительно, это зима. У себя на родине я живу в той части страны, где всегда холодно. Это центральная часть Италии, ближе к горам. Там много снега, но для нас холодно это когда на улице -5 или -7. А здесь -27! Но это не так уж и плохо. Здесь другой холод — он сухой, так что -27 здесь это не то же самое, что -27 в итальянских горах.

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

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

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

Я жил в Брюсселе, в США, в других странах, и мне везде нравилось, но, живя в США, я замечал множество различий с моей страной. Прошло уже несколько месяцев в России, и я чувствую себя здесь как дома. Иннополис прекрасен, Казань великолепна. Моё реальное впечатление от столицы Татарстана сильно отличалось от ожиданий.

— Как ваша семья отреагировала на переезд в холодную Россию?
— Мое решение в семье одобрили. Я не убеждал жену переехать в Россию. За меня это сделала Татьяна Станко, проректор Университета Иннополис. После моего визита, она сказала: «В следующий раз приезжайте с супругой». Когда мы приехали, Татьяна пригласила нас на ужин и показала город.

Правда, первый же комментарий моей жены после новости о переезде был таким: «Это здорово, но там же холодно!» А затем был вопрос: «А что там в России интересного»? Почему-то многие думают, что Россия — какое-то странное место, где все пьют водку и распевают песни. А когда я показываю фотографии, вижу, что люди сильно удивляются. 

— Когда вы получили предложение поработать в России, не было ли конфликта интересов, учитывая отношения России и НАТО?
— Я по-прежнему консультант НАТО. До приезда в Россию я подписал с ними соглашение. Они могут вызвать меня по вопросам, связанным с методологией гибкой разработкой ПО, и я обязан на них реагировать. Я сообщил агентству НАТО по связи и информации (NCIA) о том, что переезжаю в Россию, в Татарстан, для работы в Университете Иннополис. Никаких возражений с их стороны не было. 

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

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

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

Думаю, что многие россияне отдыхают и работают в США, а некоторые мои коллеги в университете имеют двойной диплом, выданный американским университетом Карнеги-Меллон. Это культурный и академический обмен. В чём же здесь проблема? А секретная информация остаётся секретной.
Когда я поделился с бывшим коллегой из генерального штаба о том, почему я уезжаю работать в Университет Иннополис, он ответил, что моё решение вызывает уважение, потому что это ещё один способ рассказать о профессии военного инженера. Мой коллега был рад, что в России ценят эту профессию.

— Какие у вас гаджеты?
— Я до сих пор пользуюсь устройствами на базе процессора Intel. У меня есть планшет Surface Pro Tablet с операционной системой Windows 10. Иногда я подумываю перейти на Apple, но пока не решился: я старомоден, так сказать, из поколения Windows, часто работаю с продуктами этой системы — это удобно, и я привык.

— А что насчёт мессенджеров?
— Сейчас я пользуюсь Whatsapp. Мессенджер распространён в Италии и в Европе. С его помощью я общаюсь с семьёй: моя дочь живёт в Брюсселе, а сын — в северной части Италии. Полгода назад я завёл аккаунт в Телеграме — можно сказать, все «козыри» на руках! Все коллеги в Университете Иннополис пользуются этим мессендежером.

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

Но какова цель взломщика, который нарушает конфиденциальность общения в сети? Выгода от шпионской деятельности в социальной сети стремится к нулю. У меня сотни электронных адресов, и если кто-то взломает мой почтовый ящик, то никакой важной информации там не найдут, кроме личных переписок в стиле: «Привет, как дела? Я купил новый мотоцикл!». 

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

Конечно, в сети можно найти шпионский софт, установить его на устройство того, за кем следите, и все сообщения с его мессенджеров будут дублироваться на ваш телефон. Кстати, не обязательно устанавливать вредоносное ПО на телефон. Можно просто отправить вирусное письмо на электронную почту. В Италии это запрещено законом. Полагаю, что и в России тоже. Нарушение прав на неприкосновенность частной жизни — уголовно наказуемое деяние.

Для защиты от кибератак я использую пароли, дополнительные учётные записи и другие данные. Основное правило, которого я придерживаюсь, — не сохранять используемые пароли. Пусть я и бывший военный, но скажу, что в глобальном мире секретов больше нет. Раньше было много тайн, которые на самом деле таковыми не были. Информация считалась секретной, потому что долго и тщательно разрабатывалась и поэтому находилась под грифом «совершенно секретно». Но когда такой секрет раскрывали, внутри ничего особенного не было. Например, раньше информация о траекториях 155 мм артиллерийского снаряда считалась секретной. Сейчас эти данные можно найти в интернете. В нашем мире сложнее скрыть то, что действительно секретно. Самая секретная информация сегодня — банковские данные.

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

Я уверен, что технологии невозможно остановить и бороться с ними бесполезно. Вопрос в человеческой природе — изменится ли она. За свою скромную жизнь я не заметил каких-либо перемен. Развитие военных технологий не сделало общество «плохим». Однако культура стала мельчать из поколения в поколение. Когда я учился в школе, мы сами писали сочинения, устраивали обсуждения и обменивались мнениями. Сейчас выпускники школы, в которой я учился, неграмотно пишут, плохо знают географию, историю, но хорошо разбираются в современных технологиях. Конечно, возможность найти в интернете любую необходимую информацию — это просто мечта. Но молодое поколение неразумно использует эти огромные возможности.

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

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

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

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

Простое правило: если вы не хотите стать жертвой атаки, не выкладывайте личные данные в сеть. Например, в нашей семье есть правило: не выкладывать в социальные сети фото детей. Это строгий запрет. Если мы хотим обменяться фото — отправляем личным сообщение через мессенджер: WhatsApp или Телеграм. Итак, средства и технологии обеспечения безопасности не дают 100% защиту. Чтобы обезопасить себя, каждый, помимо технологий, создает свои правила.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334900/


Метки:  

Как пережить хардфорк и не слечь в больницу

Пятница, 04 Августа 2017 г. 16:33 + в цитатник
Вечером 1 августа произошел хардфорк биткоина. Наш знакомый (назовем его Дмитрий) обратился в DTI с проблемой: с кошелька пропали все BTC + не были начислены BCH. Всю гамму чувств, которую испытал Дмитрий и его близкие, мы опустим. Опишем только факты и действия, которые привели к позитивному результату. Об этом ниже.



Дисклеймер: все совпадения имен и другой личной информации случайны.


Суть проблемы


В преддверии хардфорка биткоина Дмитрий решил обезопасить свои накопления и перевел их в аппаратный кошелек Ledger.

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

К вечеру вторника, уже после хардфорка, Дмитрий решил открыть Ledger, чтобы проверить, появился ли доступ к его кошельку в блокчейне Bitcoin Cash.

Однако он столкнулся с двумя важными проблемами:
  • После разделения кошелька на BTC и BCH-части (об этом в нашем алгоритме ниже) на кошельке Bitcoin Cash количество начисленных BCH равнялось нулю.
  • При переходе назад в Bitcoin-кошелек количество BTC также обнулилось, + была удалена история транзакций и сброшены настройки интерфейса.

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

Комментарий технической части DTI:
Согласно идее форка, дублируется весь блокчейн — соответственно, и все кошельки. Ledger предоставляет доступ к дублированному кошельку в блокчейне Bitcoin Cash, он называется Main-кошельком. Однако в целях безопасности рекомендуется перевести все средства на новый кошелек — Split. Дмитрий зашел в кошелек Ledger и увидел ноль на балансе BTC и BCH-Split. Ноль на балансе BTC был вызван багом приложения, а ноль на BCH-Split нормален, потому что коины на него еще нужно перевести с кошелька BCH-Main.

Восстановление Bitcoin


Опыт Дмитрия показал, что «глюк», при котором пропадают BTC, устраняется двумя способами:
  • восстановлением кошелька по ключевым словам,
  • через меню в приложении: «Настройки» (где их искать, показано в алгоритме ниже) — «Инструменты» — «Reset»

В результате ему удалось вернуть BTC, однако BCH так и не появились в кошельке.

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

Получение Bitcoin Cash


Как подчеркивает Ledger, все обладатели BTC на своем кошельке автоматически получили BCH. Однако, как выяснилось, проблема может возникнуть при попытке их найти. Для этого нужно обновить устройство (в случае с аппаратным кошельком) и следовать следующему алгоритму — он работает с Ledger-кошельками:

1) Скачать из Ledger Manager и установить кошелек Bitcoin Cash.



2) Открыть кошелек Bitcoin Cash и в приложении Bitcoin Chrome App выбрать «Настройки» — «Blockchains».




3) Выбрать Bitcoin Cash, а затем нажать на «Split».



4) Нажать на стрелку вниз и скопировать адрес.





5) Выбрать «Настройки» — «Blockchain» — «Bitcoin Cash» — «Main» по аналогии с пунктами 2 и 3.

6) Отправить нужную сумму BCH на свой Bitcoin Cash «Split» кошелек (адрес, который был скопирован в пункте 4).





 
Важно: BCH появятся в кошельке не сразу — нужно подождать время до добавления транзакции в блок, в сети Bitcoin обычно около 10 минут.


В дальнейшем для пользования BCH всегда используйте кошелек Bitcoin Cash «Split».

Если данный алгоритм не привел к желаемому результату, можно воспользоваться дополнительными советами на сайте Ledger:

Суммируя: что делать, если после хардфорка лишился всего


  • Успокоиться. Это правда важно!
  • Восстановить кошелек одним из указанных способов и найти свои BTC
  • Воспользоваться алгоритмом по установке и настройке кошелька и найти свои BCH
  • Выдохнуть — ваши средства снова с вами!:)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334896/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1081 1080 [1079] 1078 1077 ..
.. 1 Календарь