Докеризация веб-служб на R и Python

Автор: admin от 16-08-2018, 14:00, посмотрело: 41

Привет, Хабр! Контейнеризация — это подход к разработке программного обеспечения, при котором приложение или служба, их зависимости и конфигурация (абстрактные файлы манифеста развертывания) упаковываются вместе в образ контейнера. В этой статье рассмотрим создание docker-образа и его использование для запуска оболочки R, Python и много другого. Присоединяйтесь!



Докеризация веб-служб на R и Python

Категория: Microsoft, Linux, Ubuntu

 

Торгово-промышленная палата России предложила не наказывать пользователей «шпионских» устройств

Автор: admin от 16-08-2018, 13:55, посмотрело: 23

Торгово-промышленная палата России предложила не наказывать пользователей «шпионских» устройств
За использование GPS-маячка для коровы можно попасть в поле зрения правоохранительных органов



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



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

Категория: Программирование

 

«Extreme Extended Edge», или коммутация на основе стандарта IEEE 802.1BR

Автор: admin от 16-08-2018, 13:55, посмотрело: 41

Решение «Extreme Extended Edge» (также известное как Virtual Port Extender – VPEX) это новая технология, поддержка которой впервые представлена в операционной системе EXOS, начиная с релиза 22.5. Само решение основано на базе стандарта IEEE 802.1BR (Bridge Port Extension), и в рамках релиза EXOS 22.5 была добавлена поддержка новой аппаратный линейки ExtremeSwitching V400



«Extreme Extended Edge», или коммутация на основе стандарта IEEE 802.1BR

Категория: Программирование

 

Vuex: структурирование больших проектов и работа с модулями

Автор: admin от 16-08-2018, 13:55, посмотрело: 16

Vuex — это официальная, отлично документированная библиотека для управления состоянием приложений, разработанная специально для фреймворка Vue.js. Автор материала, перевод которого мы сегодня публикуем, полагает, что пользоваться этой библиотекой гораздо приятнее, чем Redux, так как, во-первых, для работы с Vuex требуется меньше шаблонного кода, а во-вторых — из-за того, что для работы с асинхронными механизмами здесь не нужно дополнительных библиотек. Более того, так как библиотека Vuex создана той же командой, которая занимается работой над Vue, эта библиотека очень хорошо интегрируется с данным фреймворком. К сожалению, в работе с Vuex всё ещё можно столкнуться с одной сложностью, которая заключается в правильной подготовке структуры проектов, в которых планируется пользоваться этой библиотекой.



Vuex: структурирование больших проектов и работа с модулями



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

Категория: Веб-разработка

 

Настройка squid или как не купить платное решение

Автор: admin от 16-08-2018, 13:55, посмотрело: 21

Настройка squid или как не купить платное решение


Всем привет!



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



Мы пытались внедрить решение от Ideco и ИКС, в итоге остановились на squid. Под катом история пути и техническая информация по настройке старого доброго кальмара.

Категория: Linux

 

Видеонаблюдение с использованием смартфона — плюсы и минусы

Автор: admin от 16-08-2018, 13:00, посмотрело: 18

Видеонаблюдение с использованием смартфона — плюсы и минусы



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



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

Категория: Гаджеты, Сделай Сам

 

Как мы уместили таблицы в экран смартфона и унифицировали в рамках дизайн-системы

Автор: admin от 16-08-2018, 11:40, посмотрело: 14

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



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



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



Для дизайн-проектирования это ставит нам 2 задачи:



1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.



Как мы уместили таблицы в экран смартфона и унифицировали в рамках дизайн-системы


2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.



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

Категория: Системное администрирование

 

33 двухюнитовых сервера на 13 ТБ оперативки и 0,6 ПТ распределённого хранилища — почему это минимум для проактивного UBA

Автор: admin от 16-08-2018, 10:05, посмотрело: 18

Скриншот собираемых данных:



33 двухюнитовых сервера на 13 ТБ оперативки и 0,6 ПТ распределённого хранилища — почему это минимум для проактивного UBA


Современные системы безопасности ОЧЕНЬ прожорливы до ресурсов. Почему? Потому что они считают больше, чем многие продакшн-сервера и системы бизнес-аналитики.



Что они считают? Сейчас объясню. Начнём с простого: условно первое поколение защитных устройств было очень простым — на уровне «пускать» и «не пускать». Например, файерволл пускал трафик по определённым правилам и не пускал трафик по другим. Естественно, для этого особая вычислительная мощность не нужна.



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



Сейчас системы UBA (User Behavior Analytics) анализируют поведение пользователей, сравнивая их с другими сотрудниками компании, и оценивают логичность и правильность каждого действия сотрудника. Делается это за счёт Data Lake-методов и довольно ресурсоемкой, но автоматизированной обработки алгоритмами машинного обучения — в первую очередь потому, что прописывать все возможные сценарии руками занимает несколько тысяч человеко-дней.

Категория: Информационная безопасность

 

[DotNetBook] Исключения: события об исключительных ситуациях

Автор: admin от 16-08-2018, 08:00, посмотрело: 20

[DotNetBook] Исключения: события об исключительных ситуациях С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.



События об исключительных ситуациях



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



    try {
        // ...
    } catch {
        // do nothing, just to make code call more safe
    }


В такой ситуации может оказаться что выполнение кода уже не так безопасно как выглядит, но сообщений о том что произошли какие-то проблемы мы не имеем. Второй вариант — когда приложение глушит некоторое, пусть даже легальное, исключение. А результат — следующее исключение в случайном месте вызовет падение приложения в некотором будущем от случайной казалось бы ошибки. Тут хотелось бы иметь представление, какая была предыстория этой ошибки. Каков ход событий привел к такой ситуации. И один из способов сделать это возможным — использовать дополнительные события, которые относятся к исключительным ситуациям: AppDomain.FirstChanceException и AppDomain.UnhandledException.



Данная статья — первая из четырех в цикле статей про исключения. Полный цикл:

— Архитектура системы типов

— Cобытия об исключительных ситуациях (эта статья)

— Виды исключительных ситуаций

— Сериализация и блоки обработки

Категория: Программирование

 

LLTR Часть 1: Первые шаги в OMNeT++ и INET

Автор: admin от 16-08-2018, 07:25, посмотрело: 20

OMNeT++ (Objective Modular Network Testbed in C++) Discrete Event Simulator – это модульная, компонентно-ориентированная C++ библиотека и фреймворк для дискретно-событийного моделирования, используемая прежде всего для создания симуляторов сетей. Попросту говоря это “симулятор дискретных событий”, включающий: IDE для создания моделей, и сам симулятор (GUI).



INET Framework – “библиотека” сетевых моделей для OMNeT++.



Полная версия GIF (15.7 MiB)



В предыдущих частях…



0. Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима? (+ classic Habrahabr UserCSS)



В этой части:




  • создадим “свой первый” протокол (на примере LLTR Basic);

  • выберем подходящий симулятор сити для отладки протокола (и создания его модели);

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

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

  • пройдем весь путь вместе:

    • от счастья, принесенного успешной (наконец!) компиляции первого проекта с пустой сетью,

    • до полного погружения в эксперименты с функционирующей моделью протокола;


  • tutorial, все описано в виде tutorial – мы будем учиться на ошибках – будем совершать их, и будем понимать их (природу), дабы элегантно/эффективно с ними справится;

  • репозиторий (git LLTR Часть 1: Первые шаги в OMNeT++ и INET), в коммитах и тегах которого сохранены все шаги (“Add …”, “Fix …”, “Fix …”, “Modify …”, “Correct …”, …), от начала и до конца.



Note: дополнительная информация для читателей хаба “Mesh-сети”.



{ объем изображений: 2.2+(2.1) MiB; текста: 484 KiB; смайликов: 22 шт. }

Категория: Программирование, Системное администрирование