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

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

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

«Это не про деньги и не разработку»: 5 заблуждений о работе комьюнити-менеджера

Понедельник, 05 Июня 2017 г. 13:59 + в цитатник


Много раз я пытался объяснить своим знакомым, чем занимаюсь. Обычно я обзываю себя специалистом по связям с общественностью. По крайней мере, это более или менее понятно. Но когда аналогичный вопрос задают люди из игровой индустрии — это настораживает. «Как же так, — подумает комьюнити-менеджер. — Есть же игроки, нужно сделать социальную среду — неужели вам этого недостаточно?». Возможно огорчу кого-то из коллег, но, нет, недостаточно. Когда к вам обращается основатель инди-студии и спрашивает, зачем же нужны КМ, аксиомы вроде «услышанный игрок = счастливый игрок» не убедят его тратить и без того ограниченный бюджет.

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

… и чем он занимается



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

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

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

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

Заблуждение №1: КМ не приносит денег




Котики. Считаются неотъемлемой частью работы КМ.

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

Многие инди-студии берут в штат 1-2 КМ-ов для поддержания официальных ресурсов. Им говорят: «Хотим core-аудиторию в социалках, чтобы была страница на Facebook, а на форумах — видимость присутствия разработчика». Имиджевая задача, казалось бы в наши дни — must have. Но работник, который получит такую установку, не научится в бизнес. Постепенно он выставит себе KPI в лайках и подписках, его конечной целью станет общение и кратковременные задачи, которые перейдут в едва ли полезную рутину.

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

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

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

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

  • Сообщество Reddit способно образовывать спонтанный краудфандинг в поддержку идей и пользователей.
  • Популярные стримеры создают «дефицит ответов» на комментарии подписчиков. Все хотят засветиться в эфире и думают: «Задоначу, и он точно мне ответит».
  • Краудфандинг-платформы как Kickstarter работают по принципу Public-benefit, то есть изначально целятся на ожидания сообщества и им же финансируются.


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

Заблуждение №2: Мнение игроков нельзя измерить



Теперь поделюсь опытом работы на игровом проекте с миллионным активным сообществом — War Robots. Игра издается на весь мир, у нас в отделе КМ сейчас 8 человек +1 аутсорс. На ключевые регионы работают отдельные люди.

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

Мы хотели знать:

  • Что больше всего понравилось и не понравилось игрокам?
  • Чего не хватает новым игрокам?
  • Насколько сложно (читай долго) всё это реализовать?
  • Что мы с этого получим?


Разработка (3) оценивается временем. Успех (4) оценивается прибылью. Но как оценить первые два пункта?



Я не шучу, мы руками собирали каждый отзыв и каждое пожелание игроков. Прочитал отзыв > определил категорию > прибавил единицу. Ну что, во сколько вы оцените работу работника с такой задачей? Вот и мы подумали, что КПД можно и нужно повысить. Автоматизация!

Сначала мы изучили сервисы, занимающиеся Text mining и Social listening. Первое — это сухой анализ текста на предмет ключевых слов. Такой можно найти в админке ревью на Google Play (тогда его еще не было). В связке с самой оценкой получается неплохая статистика, во всяком случае теперь можно выделить конкретную тему по ключу.

Social listening — это анализ текста по содержанию и сентименту. Мы работали на Facebook, Instagram и YouTube, но собирать фидбек оттуда было задачей долговременной и не особо эффективной. Нашли сервис, сделали вывод, что можем получить более подробную выгрузку отзывов не за часы, а за пару минут.



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

Заблуждение №3: КМ не имеет отношения к разработке



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

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

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


Здесь мы преследуем сразу 2 цели: обучить игроков и создать инфлюенсера на YouTube.

При хорошем DAU увеличить охват ивента или турнира тоже можно в два счета. Вы получаете инструмент Call to action. Опишите условия ивента заранее, и игрок начнет к нему готовиться, так как он знает — осведомлен значит вооружен. Как извлечь из этого пользу, зависит от ваших целей.


Разработчики Vainglory отдельно ведут Community, eSports и News, направляя игроков туда, куда им нужно.

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

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

Заблуждение №4: Пока игрок не подписался, КМ с ним не работает



Работает и должен работать.

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

Игра запустилась, добросовестно ведет пользователя пообщаться на Facebook, оценить игру в сторе, записать видео на YouTube.

Далее КМ получает комментарий, оценку и видео. Комментарий говорит, что игра становится скучной, оценка — тройка, в видео — критика. За неделю таких набирается 10/100/1000 пользователей и в отделе формируется отчет «всё плохо, игроки недовольны».

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

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

Пример:

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


На графике процент спавнов с оружием в разных лигах. С такой информацией КМ не поднимет тему «игроки недовольны, оружие плохое». Он скажет, какая точно проблема вызывает недовольство и у кого (в этом случае Weapon 1 в низких-средних лигах, и Weapon 2 — в высоких).

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

Заблуждение №5: КМ выполняет функции техподдержки



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

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

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

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

  • внутриигровые новости и другие социальные фичи;
  • сайт и форум;
  • социальные сети и чаты;
  • лидеры мнений, контент-мейкеры и др.;
  • аналитика проекта;
  • социальная аналитика и опросы.


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



В итоге



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

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

Полезных ссылок н-н-нада?
blog.socious.com/10-most-popular-online-community-tips-2015
yantami.de
www.feverbee.com
www.amazon.com/Buzzing-Communities-Bigger-Better-Active/dp/0988359901
www.amazon.com/Net-Work-Patti-Anklam/dp/0750682973
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330224/


Метки:  

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

Понедельник, 05 Июня 2017 г. 13:47 + в цитатник


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


Введение


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

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

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

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

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

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

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

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

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

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

Простые идеи не работают


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

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



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

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



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



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

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

Когда Микки запускает свою программу, первоначально все идет как надо. Однако, затем происходит следующее:



Такое сравнительное описание искусственного интеллекта является, по моему мнению, весьма реалистичным.

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

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



Вторая проблема заключается в том, что Микки запрограммировал метлу на достижение результата на основе максимальной оценки. Задача «наполнить один котел водой» выглядит достаточно простой и ограниченной, однако если оценивать ее с вероятностной точки зрения, становится ясно, что ее оптимизация приводит к абсурдным результатам. Если котел с 99.9% вероятностью наполнен, но существуют дополнительные ресурсы, программа всегда будет искать способы задействования этих ресурсов для увеличения вероятности.

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

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

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

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

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

Микки пробует такой вариант, однако он не работает:







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

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

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

Одним из очевидных решений является попытка изменения функции оценки с введением кнопки отключения B:



Это означает, что, если кнопка останова активирована, цель системы изменяется с «наполнить котел» на «приостановить работу».

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

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

Что удивительно, современные технологии в этой области не являются намного более продвинутыми, нежели описанная схема. Даная проблема рассмотрена в статье, написанной мной в соавторстве с Фолленштейном, Юдковским и Армстронгом (“Возможность внесения поправок“) и подтверждена соответствующими результатами Орсо и Армстронга (“Средства безопасного прерывания исполнения кода“).

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



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

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





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

Общая картина


Приоритеты настройки
Отступим на шаг назад и поговорим о необходимости настройки продвинутой системы искусственного интеллекта в соответствии с нашими интересами.

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



Публикации в прессе по данной области чаще всего фокусируются на одной из двух проблем: «Что если искусственный интеллект будет разработан «неправильной» группой людей?» и «Что если естественные желания системы искусственного интеллекта U будут отличаться от задачи V?»



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

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

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

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

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



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

Я считаю, что работа по большей части должна заключаться в создании эффективного процесса обучения и в проверке правильности привязки процесса sorta-argmax к результирующей целевой функции U:



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

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

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

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

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

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

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

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

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

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

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

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

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

Пример Стюарта Расселла: если вы построите робота и попросите его сходить в магазин за молоком, робот выберет наиболее безопасный путь, поскольку вероятность возврата с молоком, в данном случае, будет максимальной. Это не означает, что робот боится смерти; это означает, что робот не принесет молоко в случае смерти, чем и объясняется его выбор.

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

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

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

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

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

Фундаментальные трудности


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный проект является очень важным, и я призываю всех заинтересовавшихся принять в нем участие. В интернете имеется большое количество ресурсов по данной тематике, включая информацию об актуальных технических проблемах. Можете начать с изучения исследовательских программ НИИ ИИ и со статьи «Конкретные проблемы безопасности в системах искусственного интеллекта», которую вы можете найти на Google Brain, OpenAI и Stanford.

Примечания


  1. Самолет не может исправлять собственные повреждения или размножаться, но он в состоянии перевозить тяжелые грузы быстрее и дальше, чем птицы. Самолеты во многих отношениях проще птиц, однако они обладают большими возможностями с точки зрения грузоподъемности и скорости (для чего они и были разработаны). Вполне вероятно, что ранние автоматизированные ученые также во многих отношениях будут проще человеческого разума, однако будут превосходить его в определенных задачах. И так же, как конструкция и дизайн самолетов выглядят чуждыми по сравнению с архитектурой биологических существ, мы может ожидать, что конструкция высокопроизводительных систем ИИ будет значительно отличаться от архитектуры и логики человеческого разума.
  2. Попытка формализовать различие конечных и неопределенных целей является насущной исследовательской проблемой. В соответствии с исследовательской статьей “Настройка целей для продвинутых самообучающихся систем”, необходимо применять мягкую оптимизацию («не слишком усердную оптимизации») с консервативным подходом («избегать абсурдных стратегий») и постараться предотвратить крупные непредсказуемые последствия. Более подробная информация по предотвращению негативных последствий можно найти в статье Дарио Амодея, Криса Олаха, Якова Штейнхардта, Пола Криштиано, Джона Шульмана и Дена Мейнза “Конкретные проблемы обеспечения безопасности в системах искусственного интеллекта.”
  3. За последнее десятилетие мы осознали, что компьютеру практически невозможно вручную описать кошку, но его можно научить распознавать кошку. Еще более безнадежна попытка описать человеческие ценности, однако вполне вероятно, что можно разработать обучающую систему, которая могла бы изучить понятие «ценностей».
  4. Ознакомьтесь со статьями «Цели с точки зрения среды», «Малоэффективные агенты» и «Мягкая оптимизация» для определения физических целей, не вызывающих катастрофических побочных эффектов.

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

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

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

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

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

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

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

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

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

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

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

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

    Проблема разделяется на три части:

    1. 1. “Делай, что я имею ввиду” — неопределенная задача, и, даже если бы мы смогли создать систему искусственного интеллекта, мы не знали бы, как перевести подобную задачу в код.
    2. 2. Если выполнение подразумеваемой нами задачи является инструментально обоснованным для достижения определенной цели, достаточно умная система может изучить, каким образом ей выполнять действия, и действовать таким образом до тех пор, пока эти действия будут эффективны для достижения цели. Однако, если система становится еще более умной, она может найти более креативные пути достижения целей, соответственно, задача «делать, что я имею ввиду» может оказаться для системы неоптимальной с инструментальной точки зрения.
    3. 3. Если мы используем обучение для улучшения целей системы на основе полученных данных, которые, как представляется, направляют систему в сторону U (то есть того, что «мы имеем в виду»), вероятно, что система фактически обнулит U, что мы фактически подразумеваем в процессе обучения, но, с другой стороны, может привести к катастрофическим разночтениям в сложных контекстах. Более подробная информация приведена в “Проклятии Гудхарта”.
    4. Примеры проблем, с которыми сталкиваются существующие техники обучения целям и фактам, приведены в статье “Использование машинного обучения для устранения рисков, связанных с ИИ.”
  6. Результат, вероятно, будет не совпадать с человеческой эволюцией, поскольку она связана с множеством исторических событий. Кроме того, результат может оказаться более эффективным вследствие определенных программно-аппаратных преимуществ.
  7. Данная концепция иногда включается в категорию «прозрачность», но стандартное исследование алгоритмической прозрачности на самом деле не решает проблем. Лучшим термином является, по моему мнению, «понимание». Мы хотим получить более глубокое и более широкое представление о том, какую когнитивную работу выполняет система, и как эта работа связана с целями системы или целями оптимизации, то есть мы хотим получить инструмент, дающий представление о практической инженерной работе.
  8. Мы могли бы запрограммировать систему на выполнение действий по кругу, но нам этого не нужно. В принципе, можно запрограммировать метлу, которая только находит и выполняет действия, оптимизирующие понятие полноты котла. Улучшение способности системы эффективно находить действия с высоким коэффициентом (в абсолютном смысле или относительно определенного правила скоринга) само по себе не изменяет правило подсчета, которое оно использует для оценки действий.
  9. Мы можем представить, что последний случай приводит к циклу обратной связи, поскольку усовершенствования конструкции системы позволяют ей придумать дополнительные усовершенствования конструкции, пока все наиболее просто исполнимые варианты не будут исчерпаны.

    Еще одно важное соображение состоит в том, что узким местом для более быстрого развития научных исследований человеком являются время обучения и пропускная коммуникативная способность. Если бы мы могли научить «новый ум» стать передовым ученым за десять минут, и, если бы ученые могли почти мгновенно обмениваться опытом, знаниями, концепциями, идеями и интуицией, научный прогресс мог бы значительно продвинуться. Именно ликвидация этих узких мест дает преимущества автоматизированным изобретателям даже при отсутствии более эффективных аппаратных средств и алгоритмов.
  10. К примеру, ракеты подвержены воздействию более большого диапазона температур и давлений, а также сильнее укомплектованы взрывчатыми веществами.
  11. Рассмотрим разработку Бердом и Лейцеллом очень простого генетического алгоритма, которому было поручено разработать колебательный контур. Берд и Лейцелл были удивлены, обнаружив, что алгоритм не использовал конденсатор на чипе; вместо этого он использовал дорожки схемы на материнской плате в качестве радиоприемника, чтобы передать осциллирующий сигнал с тестового устройства обратно на тестовое устройство.

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

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

https://habrahabr.ru/post/330204/


Метки:  

Универсальная функция создания объектов на примере реализации $injector.instantiate в angularjs

Понедельник, 05 Июня 2017 г. 12:58 + в цитатник
Задумывались ли вы когда-нибудь, как создаются экземпляры используемых вами типов angularJS? Контроллеры, фабрики, сервисы, декораторы, значения- буквально каждый из них в конце концов передаётся на исполнение в функцию instantiate объекта $injector, где их поджидает довольно занимательная конструкция, о которой сегодня и хотелось бы поговорить.



А именно, речь пойдёт о следующей строке:

return new (Function.prototype.bind.apply(ctor, args))();

Очевиден ли для вас сходу принцип её действия? Если ответ положительный, то благодарю за внимание и уделённое вами время :)

Теперь же, когда все съевшие собаку на javascript читатели нас покинули, хотел бы ответить на собственный вопрос: впервые увидев эту строку, я растерялся и абсолютно ничего не понял во всех этих взаимоотношениях и хитросплетениях функций bind, apply, new и (). Давайте разбираться. Начать я предлагаю от обратного, а именно: пускай у нас есть некий параметризованный конструктор, экземпляр которого мы и хотим создать:

function Animal(name, sound) {
  this.name = name;
  this.sound = sound;
}


new


«Что может быть проще»- скажете вы и будете правы: var dog = new Animal('Dog', 'Woof!');. Оператор new — это первое, что нам потребуется, чтобы получить экземпляр вызова конструктора Animal. Небольшое отступление о том, как работает new:

Когда исполняется new Foo(...), происходит следующее:

1. Создается новый объект, наследующий Foo.prototype.
2. Вызывается конструктор — функция Foo с указанными аргументами и this, привязанным к только что созданному объекту. new Foo эквивалентно new Foo(), то есть если аргументы не указаны, Foo вызывается без аргументов.
3. Результатом выражения new становится объект, возвращенный конструктором. Если конструктор не возвращет объект явно, используется объект из п. 1. (Обычно конструкторы не возвращают значение, но они могут делать это, если нужно переопределить обычный процесс создания объектов.)
Подробнее

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

function CreateAnimal(name, sound) {
    return new Animal(name, sound);
}

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

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

И в случае с $injector.instantiate был выбран второй путь:

bind


function Create(ctorFunc, name, sound) {
    return new (ctorFunc.bind(null, name, sound));
}

console.log( Create(Animal, 'Dog', 'Woof') );
console.log( Create(Human, 'Person') );

Небольшое отступление о том, как работает bind:

Метод bind() создаёт новую функцию, которая при вызове устанавливает в качестве контекста выполнения this предоставленное значение. В метод также передаётся набор аргументов, которые будут установлены перед переданными в привязанную функцию аргументами при её вызове.
Подробнее

В нашем случае в качестве контекста мы передаем null, т.к. планируем использовать новую созданную с помощью bind функцию с оператором new, который игнорирует this и создает для него пустой объект. Результатом выполнения функции bind станет новая функция с уже привязанными к ней аргументами (т.е. return new fn;, где fn — результат вызова bind).

Отлично, теперь мы можем использовать нашу функцию, чтобы создавать любых животных и людей, конструкторы которых… принимают параметры name и sound. «Но ведь не все аргументы, которые требуются для животных будут необходимыми и для людей»- скажете вы и будете правы- назревают 2 проблемы:

  1. Аргументы конструкторов могут начать меняться (например порядок или их количество), а значит вносить изменения нам потребуется сразу в нескольких местах: в сигнатуры конструкторов, строки вызова функции Create и строку создания экземпляра return new (ctorFunc.bind(null, name, sound ));
  2. Чем больше у нас появляется конструкторов, тем выше вероятность того, что аргументы для их создания нам потребуются разные, и мы уже не сможем использовать единую функцию (или же нам придётся перечислять все из них, а заполнять лишь необходимые).


apply


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

Небольшое отступление о том, как работает apply:

Метод apply() вызывает функцию с указанным значением this и аргументами, предоставленными в виде массива (либо массивоподобного объекта).
Хотя синтаксис этой функции практически полностью идентичен функции call(), фундаментальное различие между ними заключается в том, что функция call() принимает список (перечень) аргументов, в то время, как функция apply() принимает массив аргументов (единым параметром).
Подробнее

Здесь начинается, пожалуй, самая сложная часть, т.к. нам предстоит используя apply установить контекстом для функции bind наш конструктор (аналогично ctorFunc.bind), а в качестве аргументов для функции bind (не забывая о том, что первым аргументом является устанавливаемый контекст) передать смещенный на одну позицию вправо массив параметров конструктора, используя ctorArgs.unshift(null).



Функция bind недоступна в контексте выполнения Create, т.к. им является объект window, зато доступна посредством прототипа функции Function.prototype.

Итоговым результатом станет следующая универсальная функция:

function Create(ctorFunc, ctorArgs) {
  ctorArgs.unshift(null);
  return new (Function.prototype.bind.apply(ctorFunc, ctorArgs ));
}

console.log( Create(Animal, ['Dog', 'Woof']) );
console.log( Create(Human, ['Person', 'John', 'Engineer', 'Moscow']) );

Возвращаясь к angularJS, мы можем заметить, что в качестве Animal и Human, например, выступают конструкторы фабрик или других типов, а в качестве массива аргументов ['Dog', 'Woof'] — найденные (разрезолвленные) по имени зависимости:

angular
    .module('app')
    .factory(function($scope) {
        // constructor
    });

или

angular
    .module('app')
    .factory(['$scope', function($scope) { 
        // constructor 
    }]);

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

https://habrahabr.ru/post/330214/


Метки:  

«MDM vs CRM» или кто поможет больше продать?

Понедельник, 05 Июня 2017 г. 12:50 + в цитатник
На первый взгляд, может показаться странным, почему противопоставляются такие, казалось бы, несвязанные вещи.
Ведь CRM– это система управления отношениями с клиентами. Широко известно, что она из себя представляет, каким способом она позволяет поднять продажи; чего от неё стоит ждать, а чего –ждать не стоит. Часто CRM-система не является отдельной системой, а входит в ERP-систему предприятия.
MDM – это система управления мастер данными или нормативно-справочной информацией. Принято считать, что она предназначена для централизации управления мастер-данными, обеспечивает функциональные системы (CRM, ERP, WMS, TMS и прочие) непротиворечивыми и полными данными, которые нужны для формирования отчетности, выполнения бизнес-функций и т.п. Другими словами, MDM выполняет сервисную обеспечивающую функцию по сбору, централизованному хранению и распространению информации о мастер-данных. Но, на самом деле, это соответствует истине лишь отчасти.
Чтобы далеко не ходить за примером, приведу случай из жизни компании, совладельцем которой я являюсь. Причем мне кажется, что этот пример является абсолютно типовым, и подобные ситуации встречались и у многих наших партнеров и клиентов.
Так вот, моя компания, занимаясь внедрением CRM и MDM-систем у своих клиентов, очевидно имела потребность как-то этих клиентов находить, заинтересовывать и продавать им свои продукты и услуги.
Исходно в компании была внедрена ERP-система, имеющая встроенную подсистему CRM, в которой и велась информация о контрагентах, их контактных лицах, возможностях продажи, прошедших и запланированных активностях и т.д. Система также имела BI-возможности.
При том, что работа менеджеров по продажам была полностью автоматизирована, тем не менее, имелись проблемы, из-за которых мы не могли сказать, что правильно управляем отношениями с клиентами.
Дело вот в чем. В нашей ERP-системе (равно как и в основной массе известных мне ERP-систем) данные о клиентах компании хранились в справочнике контрагентов, которые являются по сути не клиентами компании, а их юрлицами. Если у клиента имеются несколько юрлиц, то у нас в справочнике контрагентов появляются несколько записей. При этом все взаимодействия, возможности продаж, контактные лица, договорные отношения и все документы привязаны именно к контрагентам (то есть, к юрлицам и договорам). Таким образом, клиент как управленческая бизнес-сущность, которая интегрирует в себя все эти данные, в системе отсутствовала.
Аналогичная ситуация была и с контактными лицами. Один и тот же человек мог быть указан 10 раз как контактное лицо для 10 юрлиц, возможно, даже не относящихся к одному клиенту. В результате не было никакой связи этих 10 контактных лиц между собой, и мы просто не представляли, что на самом деле это один и тот же человек. Надо ли говорить, что контактная информация также была очень противоречива.
Кроме того, отсутствовал большой блок исторической информации, необходимой для понимания клиента, которую невозможно было перенести из старых систем по причине полного несоответствия структуры и контентного состава контрагентов и номенклатуры.
В результате мы зачастую не понимали, КТО НАШ КЛИЕНТ: чем он занимался и чем занимается сейчас, какую он имел и имеет структуру в организации, кто в нем работал раньше и работает сейчас, что ему предлагали, куда его приглашали, что и на какую сумму он у нас купил и т.д.
Без этой информации мы видели только «часть слона» и не могли нормально наладить отношения с клиентом. Таким образом, нам надо было научиться выделять клиента как бизнес-сущность и привязать все данные по клиенту к этой бизнес сущности.
Мы рассматривали разные варианты, но единственно возможным решением всех перечисленных выше задач стал вариант внедрения функциональности MDM-системы в домене CDI (Customer Data Integration).
Читатель спросит, а почему единственным? А почему нельзя было взять внедрить «навороченную» Аналитическую CRM, где есть возможность вести такую «централизованную» информацию по клиенту, и решить все перечисленные проблемы? Отвечу.
Использование MDM-функциональности для решения задачи Знания Своего Клиента имеет некоторые существенные плюсы.
Основной плюс MDM заключается в том, что обычно CRM-системы не имеют нормальных средств работы c данными по клиентам и инструментов нормализации этих данных. Данные собираются из разных систем, являются разрозненными, их надо идентифицировать, стандартизировать, обогащать, дедублицировать, синхронизировать и т.д. В MDM-системах есть механизмы работы с внешними базами данных (база ЕГРЮЛ, СПАРК), механизмы стандартизации адресов, ФИО, телефонов, е-мейлов. Без этих механизмов даже наличие функционала хранения этих данных в CRM-системе абсолютно бесполезно.
Еще существенный плюс MDM – это то, что MDM-системы позволяют довольно гибко настраивать структуру хранения данных о клиентах. В каждой компании данные о клиентах, которые она считает важными, сильно различаются. Например, в нашей компании ведутся данные обо всех программных продуктах клиентов, типах и сроках их поддержки, даже если они были куплены где-то в другом месте. Кроме того, мало хранить эти данные, нужно еще версионировать как сами данные, так и структуру этих данных, т.к. они сильно меняются со временем.
Также несомненным плюсом MDM-систем является то, что MDM-системы могут выявлять явные и неявные соответствия между физическими лицами, между организациями, между физическими лицами и организациями, а также их изменения. Можно прослеживать, кто, где, когда и с кем работал, кто кого знает. Также не секрет, что топ-менеджеры больших организаций у всех на виду и частенько меняют места работы. Эта информация должна выявляться, фиксироваться и создавать дополнительные возможности для продажи.
И четвертым, несомненно важным плюсом, стало наличие в MDM встроенных средств интеграции – ETL и ESB. Эти механизмы просто необходимы для сбора всех сведений о клиентах из разных систем-источников. Особенно в части возможности сопоставления данных из других источников с данными по клиентам.

Соответственно, с помощью MDM для CDI мы решили следующие задачи:
1. В кратчайшие сроки мы смогли преобразовать нашу схему, где центральной сущностью является юрлицо и договор, в схему, где центральной сущностью является клиент. Мы идентифицировали всех клиентов, связали с ними юрлица, договора, контактных лиц, документы и всю другую информацию.
2. Мы смогли выделить «персон», т.е. физических лиц, и связать их с контактными лицами клиентов. Теперь мы отслеживаем передвижения не контактных лиц, а конкретных персон: где они работают, куда переходят и т.д. Можем отслеживать неявные соответствия, кто кого знает, и кто с кем когда-либо работал.
3. Мы смогли создать гибкие и полные хранилища дополнительной информации по клиентам и персонам, которая требуется для продажи. В нашем случае это информация о проектах и их параметрах, информация об используемом программном обеспечении и т.д.
4. Мы смогли агрегировать данные из различных источников (например, из старой системы) и сопоставить их с текущими данными.
5. Мы обеспечили механизм ведения и поддержки данных о клиентах в актуальном состоянии.
Кроме всего вышеперечисленного, внедрение механизмов MDM сподвигло нас взглянуть на проблему более комплексно, чем когда мы внедряли CRM. Фактически под этот проект был инициирован еще один проект по созданию корпоративной политики регулирования данных (Data Governance). Но об этом можно написать еще одну большую статью.
Поэтому в нашем случае MDM – это не сервисная и обеспечивающая функция для других систем, а полноценная система, несущая свою вполне конкретную бизнес-функциональность для многих отделов:
1. Отдел маркетинга использует данные MDM для построения аналитических отчетов. Теперь фактически в едином источнике собраны все данные о клиентах: можно понять, сколько у нас клиентов, какие программные продукты они используют, какие проекты в каких отраслях и регионах были реализованы, какие параметры у этих проектов, все доходные и расходные показатели по клиентам и проектам. Это дает полную информацию для принятия стратегических и тактических маркетинговых решений.
2. Отдел телемаркетинга (кол-центр) использует данные MDM для обзвона и рассылки писем. Когда клиент не был выделен как центральная сущность, было много ошибок, когда звонили одному и тому же клиенту дважды и трижды (по количеству юрлиц). Кроме того, не было полной информации (агрегированной из разных систем), которая требовалась для сегментации клиентов и принятия решения о приглашении их на то или иное мероприятие или о предложении им тех или иных услуг. Теперь можно очень точно и адресно (без повторов и накладок) рассылать письма и обзванивать клиентов, что существенно уменьшает недовольство клиентов и экономит наше время.
3. Отдел продаж. Клиентский менеджер из отдела продаж теперь может получать всю информацию по клиенту в целом, что дает ему больше шансов предложить правильный продукт и грамотно построить стратегию продажи. Кроме того, теперь отдельно ведется мониторинг и поддержание связи с лицами, принимающими решения, когда они переходят в другие компании.
4. Производственные департаменты могут вести информацию о клиентах, их контактах и быть в курсе событий. А также формировать агрегированные данные о проектах для последующего анализа.
Меня многие коллеги-айтишники спрашивают, а как нам обосновать «бизнесу» необходимость внедрения MDM-системы? Ведь это техническая обеспечивающая функция. Так вот – нет, это вполне конкретная функциональная бизнес-система, которая сама по себе может принести колоссальную добавленную стоимость многим подразделениям.

И отдельно хочу оговориться, для тех, кто, может быть, не до конца меня понял:
1. Я не хочу сказать, что нужно внедрять MDM вместо CRM, я пишу о роли MDM в построении отношений с клиентами и о том, что эта роль вполне сопоставима с ролью CRM. Понятно же, что и в нашей компании CRM отлично функционирует, выполняя СВОИ функции.
2. Говоря про MDM как бизнес-систему, я не имею в виду, что бизнес-пользователи обязательно должны работать непосредственно внутри MDM (такое, кстати, тоже бывает, но не часто), я имею в виду, что бизнес-пользователи работают с функциями и данными MDM. У нас, например, все пользовательские интерфейсы реализованы внутри ERP, чтобы пользователю было удобно и не требовалось переключаться между системами, но все функции и данные – это забота MDM.
3. Я пишу про свой опыт и опыт многих компаний, которые сталкивались с такой задачей, и не исключаю, что в природе встречаются ситуации, в которых это не работает.

Максим Власов, директор по развитию
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330222/


Метки:  

Сломай голосовалку на РИТ++ за 50 наклеек

Понедельник, 05 Июня 2017 г. 12:14 + в цитатник
Привет, Хабр и особенно участники РИТ++!

Мы сегодня на конференции со стендом (справа от конгресс-холла). У нас есть кола, сникерсы и возможность выиграть:

50 наклеек от РИТ++,
за второе место — пять пицц и ящик колы,
за третье — наш значок Odin.


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

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

Еще можно решить задачки, за каждую решенную задачку мы даем наклейку.

Удачи и ищите наш стенд!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330216/


Метки:  

NeoQUEST-2017: что ждёт гостей на юбилейной «Очной ставке»?

Понедельник, 05 Июня 2017 г. 10:23 + в цитатник
29 июня 2017 года в Санкт-Петербурге состоится юбилейная, пятая «Очная ставка» NeoQUEST! И мы с радостью приглашаем всех, кто интересуется информационной безопасностью: студентов и абитуриентов IT-специальностей, разработчиков, тестировщиков, админов, матёрых специалистов и новичков в инфобезе, хакеров и гиков!

Вход на NeoQUEST-2017 — традиционно свободный, но требует регистрации на сайте мероприятия!

Юбилейная «Очная ставка» готовит сюрпризы, и гостей ждет насыщенная, разнообразная программа, в которой будет много нового и интересного! Итак, на NeoQUEST-2017 будут:

  1. Увлекательные практические доклады о самом актуальном в мире кибербезопасности. Даже в традиционном не обошлось без сюрпризов: впервые за всю историю «Очной ставки» гостей ждет интереснейший доклад из глубин криптографии: про эллиптические кривые и криптосистемы на изогениях. Кроме того, поговорим о безопасности как на уровне «железа» (SMM, системные платы, Embedded-устройства), так и на «высоком» уровне (WSN-сети, пентесты и многое другое)!
  2. ВПЕРВЫЕ: Секция воркшопов! Смело заявляем: без практики стать по-настоящему крутым специалистом по информационной безопасности невозможно. Именно поэтому параллельно с докладами будут проводиться воркшопы, на которых деятельные гости смогут научиться кое-чему новому.
  3. ВПЕРВЫЕ: FastTrack-доклады: быстро, чётко, с огоньком — расскажем о свеженьких новостях в области информационной безопасности!
  4. Конкурсы на «взлом» и не только, викторина «ЕГЭ по ИБ» и космически крутые призы. Напоминаем, что в этом году у NeoQUEST космическая тематика, и это, несомненно, отразится на конкурсах и призах!

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

Заинтриговали? Добро пожаловать под кат: расскажем подробно о докладах и воркшопах!

Для тех, кто впервые слышит о NeoQUEST


NeoQUEST — мероприятие по кибербезопасности, которое проводится компанией «НеоБИТ» совместно с кафедрой «Информационная безопасность компьютерных систем» Санкт-Петербургского политехнического университета с 2012 года. NeoQUEST включает в себя 2 этапа:
1) Hackquest — отборочный online-этап соревнования, представляющего собой индивидуальный CTF;
2) «Очную ставку» — однодневное мероприятие для всех желающих, в рамках которого, помимо прочего, проходит еще и финальный этап hackquest.

Online-этап hackquest


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

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

«Очная ставка»


«Очная ставка» — однодневное мероприятие, проходящее в Санкт-Петербурге, включающее в себя:
— доклады на самые актуальные темы кибербезопасности;
— real-time демонстрации атак;
— конкурсы на «взлом»;
— Twitter-викторину «ЕГЭ по ИБ» — на смекалку и начальные знания в области информационной безопасности;
— финальный этап hackquest для лучших участников online-этапа.

Посетить «очную ставку» может любой желающий – вход свободный! В этом году «Очная ставка» пройдет в Конгрессном Центре «ПетроКонгресс» (кстати, всего 5 минут от метро!), начало докладов — в 11:00 утра.

А теперь — о докладах!


Список еще уточняется, на данный момент гостей ждут следующие доклады:
  1. Вадим Шматов: «Блокчейн на защите авторских прав». Все любят торренты: они быстрые, легкодоступные и совершенно бесплатные. К сожалению, торренты создают уйму проблем информационной безопасности: нарушение авторских прав, распространение вредоносного программного обеспечения и так далее. В докладе будет рассмотрено, как технология блокчейн может быть использована для создания альтернативной торрентам сети. В такой сети файлы скачиваются быстро и легко, авторы получают лицензионные отчисления, а активные пользователи вознаграждаются. Такая сеть позволила бы как крупным компаниям, так и отдельным авторам организовать распространение своих произведений без посредников, а обычным пользователям – получить быстрый и недорогой доступ к авторской музыке, фильмам, играм. Это могло бы снизить масштаб пиратства и сократить ущерб от него как правообладателям, так и обычным пользователям.
  2. Анастасия Ярмак, Анна Штыркина: «Зима близко: постквантовая криптография и закат RSA — реальная угроза или мнимое будущее?».В 2015 году NIST и NSA объявили о необходимости перехода к новым криптографическим алгоритмам, устойчивым к квантовым компьютерам. Готов ли мир к криптографическому апокалипсису, и значит ли это, что близится закат классических асимметричных криптосистем? В докладе будет рассмотрена роль эллиптических кривых в современной криптографии, задача вычисления изогений эллиптических кривых как кандидата для построения постквантовых криптосистем, а также реальные примеры использования библиотеки Microsoft SIDH для создания собственных приложений.
  3. Алексей Никольский: «Кто круче гипервизора? Так себе SMM».Современные x86-компьютеры перенасыщены возможностями и функциями, что объясняет их популярность, в том числе, у хакеров, которые с удовольствием пользуются всеми существующими возможностями, чтобы атаковать компьютеры пользователей и получить от этого выгоду. На предыдущих NeoQUEST мы уже рассказывали про технологии Intel VTx, TXT, TPM, и ME (AMT). В этом году настало время поговорить про System Management Mode — специальный режим процессора, который используется уже давно как разработчиками компьютеров, так и хакерами. В докладе мы разберемся, как защищен самый привилегированный режим на процессоре (круче даже гипервизора). На практике посмотрим, как им могут воспользоваться нарушители.
  4. Андрей Дахнович: «Что может произойти, когда вы набираете google.com в адресной строке браузера и нажимаете Enter?». 2 года назад на сайте github.com была опубликована статья под названием «What happens when you type google.com into your browser's address box and press enter». В течении первых двух месяцев на Хабрахабре было выложено целых 2 перевода этой статьи на русский язык (здесь и тут). В ней подробно описывается все, что происходит с вашим компьютером во время такого запроса, начиная нажатием клавиши «g» и заканчивая рендерингом страницы в браузере. В докладе попробуем резюмировать, а что же может произойти с точки зрения информационной безопасности с вашим компьютером при отправке запроса?
  5. Тигран Овасапян: "(НЕ)безопасность сенсорных сетей".На сегодняшний день область применения технологии беспроводных самоорганизующихся сенсорных сетей довольно широка. Недорогие беспроводные датчики могут использоваться как в военных, так и в гражданских целях (здравоохранение, мониторинг экологических параметров, системы климат контроля и др.). Однако особенности данных сетей предоставляют злоумышленникам широкий спектр возможностей для реализации атак на них. Расскажем о принципах функционирования, особенностях и наиболее перспективных сферах применения данной технологии. Будут рассмотрены актуальные угрозы, способы их реализации и существующие методы защиты от них.
  6. Роман Щербаков: «HARD HACK. Как AliExpress помогает в исследовании оборудования».Одной из важных сторон исследований в области информационной безопасности является изучение аппаратной части устройств и работа с ней. В докладе будут рассмотрены некоторые типы подобных задач на конкретных примерах, рассмотрены типы оборудования, позволяющие решить эти задачи, и произведен их сравнительный анализ. Поговорим о существующих моделях логических анализаторов и их основных преимуществах. Подробно разберем приведённые примеры и возможности логических анализаторов для их решения.
  7. Сергей Сычёв: «Разбираем прошивки Embedded-устройств на болтики и винтики». В последнее время Embedded-устройства получили широкое распространение и, как следствие, представляют реальный интерес для анализа. В докладе рассмотрим общие подходы к анализу встроенного программного обеспечения, существующие механизмы контроля целостности, а также вспомним про реальные случаи встраивания дополнительного функционала в оборудование. В качестве примера будет рассмотрена популярная IP-камера от компании Hikvision.
  8. Алексей Мясников: «RasPiливаем безопасность компьютера». Современные компьютеры становятся меньше, но при этом уверенно догоняют по мощности десктопные решения. В наше время полноценный компьютер можно уместить на одной плате размером чуть больше кредитки. Кто-то использует эти компьютеры для создания умных домов, кто-то — для работы, мы же в данном докладе рассмотрим возможные пути применения «малинки» для автоматизации атак на старших собратьев наших одноплатников.
  9. Виктор Вагисаров: «Связать невидимое». Грамотный пентестер в совершенстве владеет десятками утилит, помогающими ему в анализе безопасности: nmap, burp suite, sqlmap и др. Но огромное их количество и тонны разношёрстного вывода зачастую не позволяют сложить общую картину крупного объекта тестирования. А как было бы хорошо, если бы была система, которая по одной команде автоматически запускает сканеры, анализирует и нормализует их выводы, интеллектуально строит словари для брута паролей, устанавливает и визуализирует (!) связи между обнаруженными компонентами, предлагает вектора атак на них, ищет эксплойты под обнаруженные уязвимости, а также советует (!) пентестеру, какие шаги сделать дальше, чтобы получить максимум профита. А мы такую систему сделали! О ней и будет наш доклад.
  10. Алексей Финагин: «HDMagIc – превращаем HDMI в инструмент обеспечения ИБ». Передача любого файла на соседний компьютер со сверхвысокой скоростью через… интерфейс HDMI? Почему бы и нет? В докладе будет представлен нестандартный подход к применению технологии передачи мультимедийных данных. Мы расскажем о том, как создавался прототип программно-аппаратного комплекса для односторонней передачи данных по HDMI. Разберем основные сложности и ограничения, встреченные в процессе реализации прототипа. В заключение, покажем возможности использования подобных решений в системах обеспечения информационной безопасности.

Секция воркшопов: готовьте очумелые ручки!


1. Bad USB: делаем USB-устройства.


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

Можно ли определить функционал устройства по его внешнему виду? Оказывается, что совсем нет: клавиатуры со встроенными накопителями данных, WiFi-адаптер, похожий на флешку — все это уже немного странно, но еще вполне безобидно… Но вот когда за дело берутся хакеры, тут уже можно ожидать чего угодно!

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

2. Расшифровываем трафик.


Все знают про возможность расшифрования SSL/TLS трафика с помощью закрытого ключа в Wireshark. Но далеко не всем известно, что это не единственный способ расшифрования: Wireshark также поддерживает расшифрование с помощью секретов сессий. А это значит, что любой шифрованный SSL/TLS трафик можно расшифровать, будучи на стороне клиента!

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

Список воркшопов, как и список докладов, на данный момент еще уточняется!

… И многое-многое другое!


Помимо докладов и воркшопов, порадуем гостей секцией FastTrack докладов, демонстрациями атак, отличными конкурсами «на взлом» и не только, крутыми призами и замечательной атмосферой! Не забудем и про ставший уже традиционным конкурс «ЕГЭ по ИБ», проводящийся в Twitter.

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

Юбилейная «Очная ставка» будет просто космос, поэтому регистрируйтесь на сайте NeoQUEST, берите друзей и коллег (не забывайте про ноутбуки или устройства, их заменяющие!) и приходите (приезжайте, прилетайте и приплывайте, если вы не из Питера) 29 июня на NeoQUEST-2017!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330014/


Метки:  

Динамическое подключение внешних собственных модулей в Gradle

Понедельник, 05 Июня 2017 г. 09:52 + в цитатник

Преамбула


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

Казалось бы, собери библиотеку и выложи её в локальный maven-репозитарий, а потом уже собирай приложение. Но хочется, чтобы можно было поправив код в библиотеке сразу попробовать изменения в приложении и при этом сохранить раздельное хранение кода библиотеки и приложения, включая настройки IDE и прочее.

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


Библиотека


Для начала приведу пример содержимого build.gradle в библиотеке:
import java.text.SimpleDateFormat

apply plugin: 'java'
apply plugin: 'maven-publish'

sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8

jar.baseName = 'library'

publishing {
    publications {
        mavenJava(MavenPublication) {
            groupId='name.alenkov.habr.gradle-dynamic-dependency'
            
            version = new SimpleDateFormat('yyyyMMddHHmm').format(new Date())

            from components.java
        }
    }
}


Здесь ключевым является строка «version = new SimpleDateFormat('yyyyMMddHHmm').format(new Date())», которая задаёт версию сборки на основе текущего времени в момент её публикации в репозитарий — в остальное время версия для библиотеки нам не требуется.

Disclaimer: В нашем демонстрационном приложении мы не поддерживаем более одной ветки библиотек в продуктовой среде и потому нет потребности в поддержке версионности вида X.Y.Z

Note: в примерах я использую локальный Maven и не привожу примеры с использованием Artifactory, т.к. это не влияет на подход.

Приложение


Теперь перейдём к настройке нашего build.gradle в приложении.

Исходное состояние build.gradle:
apply plugin: 'java'

sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8

repositories {
    mavenLocal()
    jcenter()
}

dependencies {
    compile 'name.alenkov.habr.gradle-dynamic-dependency:library:+'
}




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

Первый шагом, слинкуем нашу библиотеку в проект приложения в подкаталог ext:
cd ./app/ext
ln -s ../../library/ ./


Вторым шагом добавим небольшой код в settings.gradle, который сканирует каталог "/ext" на наличие gradle-проектов и будет подключать их к нам в проект:

final extDir = new File(rootDir, 'ext')
if (extDir.exists()) {
    extDir.eachDir { dir ->
        if (new File(dir, 'build.gradle').exists()) {
            logger.trace('found ext module: ' + dir.name)

            final String prjName = ':' + dir.name
            logger.lifecycle('include ext project: ' + prjName)
            include prjName
            project(prjName).projectDir = dir
            project(prjName).name = 'ext-' + dir.name
        }
    }
}


И третий, заключительный штрих — модифицируем секцию dependencies в build.gradle:
dependencies {
    compile subprojects.find({ it.name == 'ext-library' }) ? project(':ext-library')
            : 'name.alenkov.habr.gradle-dynamic-dependency:library:+'
}



и пример, когда в library есть дополнительные gradle-задачи:


Из текущего неудобства — в IDEA динамический модуль подключается не совсем корректно — не подключаются source-каталоги как надо. Завёл баг. Как временное решение — открываю оба проекта в IDEA и в одном окне вношу правки (когда автоподсказки надо), а в другом запускаю

Исходный код обоих модулей можно посмотреть на github

UPD: аналогичным способом можно подключать и плагины gradle, только монтируя их в buildSrc. Если будут желающие, могу написать пример…
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330162/


Метки:  

Новый старший брат в семье 3PAR

Понедельник, 05 Июня 2017 г. 09:50 + в цитатник
24 мая компания Hewlett Packard Enterprise объявила о предстоящем начале продаж HPE 3PAR StoreServ 9450. Это полностью построенная на flash-технологиях старшая модель в сегменте массивов среднего класса HPE, обладающая производительностью около 2 миллионов операций ввода-вывода в секунду со временем отклика менее одной миллисекунды, с пропускной способностью до 34 ГБ/c и масштабируемостью до 18 петабайт полезной емкости (с учетом дедупликации и компрессии).

Рассказываем подробнее о новинке, а также о том, какую оценку получили массивы 3PAR в исследовании Gartner критически важных характеристик систем хранения.

Новые массивы дополняют (а не заменяют) семейство HPE 3PAR StoreServ 8000, которое предназначено для организаций меньшего размера и обеспечивает лучшие в индустрии показатели общей стоимости владения.

До этого объявления в среднем сегменте самой мощной моделью у 3PAR была StoreServ 8450. Если сравнить максимальные характеристики массивов, получается такая таблица:

8450


9450


Изменение


Число контроллеров


2 — 4


2 — 4


-


Число процессоров (ядер)


2 – 4 (40)


4 – 8 (80)


100%


Число ASIC


2 – 4


4 – 8


-


Порты 16Gb Fiber Channel


4 – 24


0 – 80


230%


Порты 10Gb iSCSI Ports


0 – 8


0 – 40


400%


Порты 1Gb Ethernet IP Ports


0 – 16


0


-


Порты 10Gb Ethernet IP Ports


0 – 8


0 – 24


300%


Встроенные порты для репликации по IP


2 – 4 (1GbE)


2 – 4 (10GbE)


-


Объем кэша на контроллер/систему


192 / 384


448 / 896


130%


Число SSD в массиве


6 – 480


6 – 576


20%


Число SSD в базовой стойке


480 SFF


384 SFF


-20%


Сырая емкость


3351 ТБ


6000 ТБ


79%



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

Система HPE 3PAR StoreServ 9000 полностью готова к использованию новых типов памяти и протоколов. В декабре 2016 года на конференции Discover компания Hewlett Packard Enterprise продемонстрировала рабочий прототип 3PAR, использовавший SSD Intel Optane с подключением по протоколу NVMe. Результаты тестов показывают снижение времени доступа на 50% и увеличение количества операций ввода-вывода на 80% по сравнению с базовой моделью. Модернизация HPE 3PAR StoreServ 9000 накопителями Storage Class Memory не потребует каких-либо изменений в базовой конфигурации.

В архитектуре HPE 3PAR StoreServ реализованы все известные в индустрии способы оптимизации хранения, позволяющие снижать стоимость полезной емкости на флеш-накопителях. Технология HPE 3PAR Adaptive Data Reduction включает Zero Detect, дедупликацию в режиме онлайн, компрессию и упаковку сжатых данных. Радикальное снижение расходов на флеш-память возможно без каких-либо компромиссов по производительности или надежности, благодаря аппаратной реализации большинства алгоритмов в специализированных микросхемах 3PAR ASIC.

Gartner: не только квадранты


В связи с выходом новых массивов имеет смысл напомнить об исследовании критически важных характеристик систем хранения, проведенном Gartner. Когда речь заходит о Gartner, все обычно вспоминают «магические квадранты». Квадранты просты и наглядны. Отчет «Critical Capabilities for General-Purpose, Midrange Storage Arrays» в какой-то мере более интересен, потому что подробнее раскрывает, что именно независимые консультанты думают о системах хранения разных производителей. В отчете «препарируются» 8 характеристик массивов:
  • Manageability (управляемость, автоматизация, мониторинг, отчеты, консоль управления);
  • RAS (надежность, доступность, сервисное обслуживание);
  • Performance (производительность, число операций ввода-вывода в секунду, пропускная способность, время отклика);
  • Scalability (масштабируемость);
  • Ecosystem (интеграция с бизнес-приложениями, ПО резервного копирования, поддержка гипервизоров);
  • Multitenancy & Security (поддержка разнородных рабочих нагрузок, их изоляция, контроль уровня доступа и аудит);
  • Storage Efficiency (соотношение сырой и полезной емкости, TCO).

Эти характеристики оцениваются для каждого массива с разными весами в разных сценариях использования:
  • Consolidation (как массив поведет себя при консолидации различных приложений на одной платформе);
  • OLTP (работа массива в наиболее критичных бизнес-приложениях как ERP и СУБД);
  • Server Virtualization & VDI (для серверной и виртуализации рабочих мест);
  • Analytics (аналитика и Big Data)
  • Cloud (частные, публичные гибридные облака).

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

Материалы:
1. The Storage Industry’s First Triple-Double: HPE 3PAR StoreServ 9450 (блог Мэтта Моррисси, HPE Storage)
2. 3PAR Receives Highest Product Scores in 5 Use Cases in Gartner Critical Capabilities Report. Again. (блог Хорхе Маэстре, HPE Storage)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330010/


Метки:  

Текстовый онлайн с фестиваля РИТ++ 2017. День первый

Понедельник, 05 Июня 2017 г. 09:44 + в цитатник
Сегодня в этом посте весь день будет вестись текстовая трансляция фестиваля РИТ++ 2017, проходящей в Сколково 5 и 6 июня. РИТ++ — это целый ряд профессиональных узкотематических конференций: системное администрирование и эксплуатация, высоконагруженные системы и базы данных, серверное программирование, управление проектами и предпринимательство, enterprise-конференция, а также фронтенд и мобильная разработка.

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



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

  • Вика Гонгина — vika_viki
  • Александр Якубович — ragequit

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

https://habrahabr.ru/post/330098/


Метки:  

[Перевод] Полезные утилиты для администраторов, обслуживающих Kubernetes

Понедельник, 05 Июня 2017 г. 09:09 + в цитатник


В статье кратко рассмотрены сторонние Open Source-утилиты для Kubernetes, реализующие разные возможности, призванные помочь в повседневной работе. 4 из них взяты из англоязычного материала и помогают в: автоматическом обновлении конфигураций, отслеживании нагрузки по контейнерам/подам/нодам, переключении контекстов, создании кластеров DIND (Docker in Docker). Остальные — найдены на GitHub и представлены коротким списком.

Kube-applier



Сервис онлайн-хранилища Box открывает исходный код некоторых инструментов, используемых у себя для деплоя с помощью Kubernetes. В апреле был представлен один из таких проектов — kube-applier.

Kube-applier запускается как сервис в Kubernetes, берёт из Git-репозитория набор конфигурационных файлов для кластера Kubernetes и последовательно применяет их к подам в кластере. Когда бы эти изменения ни появились в файлах, они автоматически забираются из репозитория и применяются к соответствующим подам. (Пример конфигурации для kube-applier см. здесь.)

Изменения могут также применяться по расписанию или по запросу. Kube-applier логирует свои действия при каждом запуске и предлагает метрики для мониторинга с Prometheus.



Kubetop


  • GitHub.
  • Лицензия: MIT License.
  • Требования: Python, Pip / Pipsi.

Kubetop — консольная утилита для вывода списка всех запущенных нод, всех подов на этих нодах и всех контейнеров в этих подах, а также потребление ресурсов процессора и оперативной памяти для каждого из них — аналогично классической Unix-утилите top. Этот инструмент нельзя рекомендовать как полноценную замену детальному журналированию/отчётности, т.к. предоставляемая им информация весьма ограничена, но иногда именно такая краткость и быстрый взгляд на статус кластера Kubernetes могут оказаться очень полезны.

В действительности у kubectl в составе Kubernetes есть похожая функция, но у Kubetop более наглядный вывод:

kubetop - 13:02:57
Node 0 CPU%   9.80 MEM% 57.97 (   2 GiB/   4 GiB)  POD%  7.27 (  8/110) Ready
Node 1 CPU%  21.20 MEM% 59.36 (   2 GiB/   4 GiB)  POD%  3.64 (  4/110) Ready
Node 2 CPU%  99.90 MEM% 58.11 (   2 GiB/   4 GiB)  POD%  7.27 (  8/110) Ready
Pods:       20 total        0 running        0 terminating        0 pending
                 POD               (CONTAINER)        %CPU         MEM   %MEM
s4-infrastructure-3073578190-2k2vw                    75.5  782.05 MiB  20.76
                      (subscription-converger)        72.7  459.11 MiB
                                 (grid-router)         2.7   98.07 MiB
                                         (web)         0.1   67.61 MiB
                        (subscription-manager)         0.0   91.62 MiB
                       (foolscap-log-gatherer)         0.0   21.98 MiB
                                       (flapp)         0.0   21.46 MiB
                              (wormhole-relay)         0.0   22.19 MiB

Kubectx и K8senv


  • Kubectx: анонс в блоге; GitHub; лицензия: Apache License v2.
  • K8senv: GitHub; лицензия: MIT License; требует Python (ставится через Pip).

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

Kubectx — Bash-скрипт, позволяющий назначать короткие имена контекстам Kubernetes и переключаться между ними. А если передать в качестве аргумента дефис, то происходит переключение на предыдущий контекст. Скрипт также поддерживает автоматическое дополнение имён по нажатию на .

$ kubectx minikube
Switched to context "minikube".
$ kubectx -
Switched to context "oregon".
$ kubectx -
Switched to context "minikube".
$ kubectx dublin=gke_ahmetb_europe-west1-b_dublin
Context "dublin" set.
Aliased "gke_ahmetb_europe-west1-b_dublin" as "dublin".

Другая утилита для переключения контекстов — k8senv — чуть менее функциональна.

kubeadm-dind-cluster


  • GitHub.
  • Лицензия: Apache License 2.0.
  • Требования: Docker 1.12+, Kubernetes 1.4.x, 1.5.x, 1.6.x.

Как известно, для тестового запуска локальной инсталляции Kubernetes с одной нодой есть хорошее готовое решение от самого проекта — Minikube. А для тех, кто хочет развернуть для экспериментов или разработки самого Kubernetes кластеры из многих узлов, есть продукт от Mirantis — kubeadm-dind-cluster (KDC).

KDC использует kubeadm для запуска кластера, созданного из Docker-контейнеров вместо виртуальных машин (для этого применяется DIND, Docker in Docker — прим. перев.). Выбранная реализация позволяет быстрее перезапускать кластер, что особенно ценно, если необходимо быстро видеть результат изменений в коде при разработке самого Kubernetes. Также можно использовать KDC в окружениях непрерывной интеграции. Работает в GNU/Linux, Mac OS и Windows, не требует инсталляции Go, т.к. использует докеризированные сборки Kubernetes.

Пример работы с KDC на базе Kubernetes 1.6:
$ wget https://cdn.rawgit.com/Mirantis/kubeadm-dind-cluster/master/fixed/dind-cluster-v1.6.sh
$ chmod +x dind-cluster-v1.6.sh

$ # запуск кластера
$ ./dind-cluster-v1.6.sh up

$ # добавление директории с kubectl в PATH
$ export PATH="$HOME/.kubeadm-dind-cluster:$PATH"

$ kubectl get nodes
NAME          STATUS         AGE
kube-master   Ready,master   1m
kube-node-1   Ready          34s
kube-node-2   Ready          34s

$ # Kubernetes dashboard доступен на http://localhost:8080/ui

$ # перезапуск кластера, который произойдет намного быстрее первого старта
$ ./dind-cluster-v1.6.sh up

$ # остановка кластера
$ ./dind-cluster-v1.6.sh down

$ # удаление контейнеров и томов DIND
$ ./dind-cluster-v1.6.sh clean

Другие утилиты


Список прочих вспомогательных утилит для Kubernetes, доступных на GitHub и не упомянутых в оригинальной статье:
  • kube-monkey — убивает поды случайным образом по аналогии с Chaos Monkey от Netflix (есть альтернатива chaoskube);
  • Kubediff — показывает разницу между конфигурациями Kubernetes: текущей запущенной и описанной в конфиге (может как работать как служба, периодически скачивающая последнюю конфигурацию из Git и сравнивающая её с текущей, поддерживает отправку уведомлений в Slack-чат, имеет веб-интерфейс);
  • ktmpl — обрабатывает параметризированные шаблоны манифестов Kubernetes;
  • kube-lint — валидирует конфигурации и ресурсы Kubernetes на соответствие правилам, определённым вами;
  • kenv — вставляет переменные окружения в описание ресурсов;
  • konfd — управляет конфигурациями приложений с помощью секретов Kubernetes, configmaps и шаблонов на Go;
  • kubernetes-secret-manager — управляет секретами с помощью Vault от Hashicorp;
  • k8sec — тоже помогает управлять секретами Kubernetes в консоли;
  • kube-ops-view — наглядно показывает текущий статус всех подов и нод кластера с помощью dashboard, написанного на JavaScript;



  • kubewatch — мониторит все события в кластере Kubernetes и сообщает о них в Slack-чат;
  • kube-slack — сообщает в Slack об ошибках в работе подов;
  • k8stail — реализует вывод логов как tail -f для всех подов кластера.



Делитесь своими находками в комментариях и подписывайтесь, чтобы не пропускать наши новые статьи! ;-)
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330198/


Метки:  

Понятия: множество, тип, атрибут

Понедельник, 05 Июня 2017 г. 07:43 + в цитатник
Математикам лень объяснять на языке обывателя, что такое действительное число. Обывателю трудно читать значки, написанные математиком, потому что их смысл для него не понятен. В итоге есть разрыв между теорией и практикой. В теории математики прекрасно знают, что такое типы объектов и что такое атрибуты, но, спускаясь к практике, мы видим, что мало, кто из практиков понимает, что это такое. Существует множество интуитивных понятий, но каждое из них скорее похоже на религиозную догму, нежели на знание. В данной статье я попытался ликвидировать пробел между математиками и прикладниками, объясняя основы теории множеств простым языком, без сложных значков.

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


Множества в математике и физике


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

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

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

Определение состава множества


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

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

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

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

Первый способ определения состава – это перечисление
Второй способ – задание условия идентификации.

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

Первый способ основан на серии высказываний:

Тарелка входит в состав множества А
Маркер входит в состав множества А
Больше никто не входит в состав множества А


Второй способ – это высказывание в предикатах:

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

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

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

В состав множества А входят те и только те объекты, которые входят в состав множества А и

Объект входит в состав множества А тогда и только тогда, когда он входит в состав множества А.

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

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

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

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

Определение состава подмножества


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

  1. Можно определить их путем перечисления.
  2. Можно приклеить стикер к слонам, и сказать, что те слоны, у которых есть приклеенный стикер, считаются африканскими. Это определение состава множества через атрибут. Атрибутом будет считаться наличие или отсутствие стикера.
  3. Можно определить состав через пересечение двух множеств: множества слонов и множества животных, обитающих в Африке.
  4. Можно ввести понятие типа «африканские слоны».

Используя в нашей работе OWL, мы имеем возможность реализовать три описанных выше способа задания подмножества:

  1. Явно перечислить входящие в подмножество объекты,
  2. Определить правило идентификации через любые условия на любые атрибуты, с разными операциями: от самого факта обладания значением какого-либо атрибута до попадания этого значения в определенный диапазон
  3. Задать операции над другими множествами: например, в класс A входят только те объекты, которые входят в класс B и не входят при этом в класс.

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

Моделирование подмножества при помощи типа


Для определения типа «африканский слон» нам понадобятся:

  1. Группа объектов, из которой мы выбираем объекты для под-типа. В данном случае эта группы имеет название – это группа слонов.
  2. Уникальное свойство, котором объекты типа отличаются от остальных объектов группы: проживают в Африке.
  3. Уникальное название для объектов данного типа

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

Итого, чтобы дать определение типа, надо:

  1. Указать группу объектов.
  2. Указать отличительные особенности (дифференциальные свойства) объектов данного типа от объектов группы.
  3. Указать название объектов данного типа

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

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

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

Понятие тип


Итак, с точки зрения теории множеств:

Тип – это способ выделения подмножества из над-множества и присвоение нового имени объектам этого подмножества

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

Разница между типом объектов и множеством объектов


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

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

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

Мне кажется, что из всего сказанного ясно, чем понятие «тип объектов» отличается от понятия «множество объектов».

Моделирование однотипных объектов


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

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

Жизненный цикл объекта


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

  1. Классификация (отнесение объекта к определенному классу, или типу объектов) всегда субъективна. Один и тот же объект с разной точки зрения может выглядеть по-разному. Если мы строим расширяемую модель предметной области, использование которой предполагает наличие разных стейкхолдеров, то должна быть возможность моделирования контекста и различных точек зрения. При этом с разных точек зрения один и тот же объект может быть отнесен к разным типам.
  2. Учет жизненного цикла объекта предполагает не только учет изменений объекта, но и учет изменения нашего восприятия этого объекта, поскольку наравне с процессом синтеза и анализа идет процесс объективации и деобъективации.

Процесс объективации и деобъективации выглядит так:

Объективация

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

Деобъективация

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

Примеры из практики:


Объективация:

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

Деобъективация:

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

Требования к моделлеру, моделирующего типы


Сформулируем требования к моделлеру, который предназначен для моделирования типов:
  1. Необходимо уметь моделировать однотипные объекты, состав атрибутов которых не совпадает
  2. Необходимо уметь моделировать правила, которые выделяют объекты в один тип
  3. Необходимость моделировать другие атрибуты типа: название объектов данного типа, историю этого названия и проч.
  4. Необходимо уметь моделировать разные точки зрения на один и тот же объект
  5. Необходимо уметь моделировать жизненный цикл объекта
  6. Необходимо уметь моделировать изменение нашего представления об объекте с течением времени .

Как в ИТ отрасли реализовать эти требования без обращения к структуре БД? Как, не обращаясь к структуре данных, учитывать разные точки зрения, добавлять новые типы объектов, уточнять тип объектов, переклассифицировать объекты в случае необходимости?

Моделирование объектов при помощи OWL


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

  • Добавление нового множества объектов в OWL ничем не отличается от добавления нового объекта.
  • Можно потребовать, что, если тип объекта известен, то модель объекта создается с заданными, наперед известными атрибутами. При этом после создания атрибуты могут как добавляться, так и удаляться. Пример: создавая модель заявки, мы можем потребовать указать значения атрибутов (номер заявки, дата заявки, заявитель, адресат). Надо только помнить, что эти атрибуты в OWL существуют отдельно от типов объектов. И один атрибут может быть использован при моделировании объектов разных множеств. Это принципиальное отличие от распространенных языков программирования, где атрибут существует только в рамках одного типа объектов. Другой атрибут в другом типе, пусть и называемый так же, будет другим атрибутом.
  • Можно потребовать наоборот: определять подмножество моделируемого объекта на основе атрибутов модели объекта и его принадлежности к над-множеству. Для этого в правиле будет записано, что если модель объекта, относящегося к определенному над-множеству, содержит такие-то атрибуты и их значения удовлетворяют определенным правилам, то объект автоматически будет отнесен к определенному подмножеству. Так при помощи правил будет реализована, так называемая, «утиная классификация». Например, если в модели заявки есть значение атрибута «Телефонный номер», а «Подключение» — это значение атрибута «Тип выполняемых работ», то заявка автоматически будет классифицирована как заявка на подключение телефонного номера.


Разделения множества на подмножества


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

Разделение множества на подмножества можно провести разными способами.

  1. Можно разделить множество на непересекающиеся подмножества, распределив объекты по подмножествам путем их перечисления. Создать семь подмножеств и перечислить объекты, которые принадлежат каждому из подмножеств.
  2. Для каждого подмножества можно придумать свой подтип. Тогда все множество можно разделить на семь подмножеств, введя семь подтипов: «Тип красных объектов», «Тип желтых объектов» и т. д. Каждый объект можно отнести к одному из перечисленных типов и сказать, например, так: объект относится к типу красных объектов.
  3. Можно разделить надмножество при помощи атрибута и его значений. Например, можно ввести атрибут «Цвет» и семь его значений: «Красный», «Желтый» и тд. Тогда название цвета станет прилагательным для объекта и будет звучать так: красный объект, желтый объект и тд.

Первый способ в OWL реализован при помощи создания семи разных классов и указания объектов, которые к ним относятся.

Второй способ может быть реализован тремя разными способами:

  1. При помощи создания отдельных классов, объединенных одним типом, но сами типы, как я говорил ранее, не моделируются. Этот способ ничем не отличается от способа разделения перечислением.
  2. При помощи справочника «Типы цветных объектов», значениями которого будут объекты, моделирующие типы: «Красные объекты», «желтые объекты» и тд
  3. При помощи атрибута с названием «тип объекта», значения которого будут иметь текстовую форму: «Тип красных объектов», «Тип желтых объектов» и тд

Третий способ разделения множества на подмножества в ИС моделируется двумя способами:

  1. При помощи справочника «Цвета», значениями которого будут объекты, моделирующие значения атрибутов: красный, желтый и т. д.
  2. При помощи атрибута с названием «Цвет», значения которого будут иметь текстовую форму: «красный», «желтый» и тд.

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

#объект #атрибут #значение

Принадлежность классу — таким:

#объект rdf:type #класс

То есть можно сказать, что принадлежность классу просто выражается при помощи специального служебного атрибута, определенного в стандарте — rdf:type.

Понятие атрибут


Сформулируем утверждение:

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

Моделирование подмножеств при помощи атрибута


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

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

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

  1. третий способ моделирования типа и
  2. второй способ моделирования атрибута.

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

О том, как вводится функция на множестве подмножеств и не только про это, можно почитать тут: akuklev.livejournal.com/1261552.html

Третий способ реализации атрибута хорош тем, что при помощи него можно моделировать огромное количество подклассов (вариантов написания строки – очень много), но плох тем, что не понятно, как узнать, что объекты относятся к одному классу: «Красный», красный», «»кра)сный_» — это обозначение одного и того же класса, или разных?

О том, как лучше моделировать подклассы написано море литературы, и я не буду здесь повторяться. Просто запомним, что атрибут – это модель подклассов, а значение – это указание на подкласс.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330196/


Метки:  

Pygest #10. Релизы, статьи, интересные проекты из мира Python [23 мая 2017 — 5 июня 2017]

Понедельник, 05 Июня 2017 г. 07:43 + в цитатник
image Всем привет! Это уже десятый выпуск дайджеста на Хабрахабр о новостях из мира Python.

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

А теперь к делу!


Статьи


Да, Python медленный, но меня это не волнует
О том, что действительно важнее — продуктивность или производительность?

Python 3 Patterns, Recipes and Idioms
Очень крутая подборка паттернов и рецептов для Python 3

The Meaning of Underscores in Python
О назначении символа нижнего подчёркивания в Python

Exposing Python 3.6's Private Dict Version
Немного о внутреннем устройстве словарей в Python 3.6

Python Functions Aren't What You Think
Небольшая заметка о том, что, на самом деле, представляют из себя функции в Python

Python: the thing good Objects come in
Заметка о внутреннем устройстве объектов в Python

Debugging an inactive python process
Отличная статья о том, как можно осуществлять отладку неактивного процесса в Python

Modern Django — Part 0: Introduction and Initial Setup
Modern Django — Part 1: Project Refactor and Meeting the Django Settings API
Modern Django — Part 2: REST APIs, Apps, and Django REST Framework
Серия статей, рассказывающих о том, как начать работать с Django

Интересные проекты


Chaos Bot
Интересный эксперимент, в котором всю разработку отдали в open-source сообщество.

Gitsuggest
Инструмент, который подсказывает github-репозитории на основе тех, которые вам понравились.

News Audit
Инструмент для определения «фейковых» новостей

Предыдущий выпуск дайджеста ищете здесь:

Pygest #9. Релизы, статьи, интересные проекты из мира Python [8 мая 2017 — 22 мая 2017]

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

https://habrahabr.ru/post/330182/


Метки:  

[Перевод] Развертывание и сопровождение Redmine, правильный путь

Понедельник, 05 Июня 2017 г. 07:18 + в цитатник


Дисклеймер: это не обычное руководство вида «Как установить Redmine». В нем я не буду погружаться в настройку базы данных или установку веб-сервера. Я также не буду рассказывать о настройке Redmine. Документация по Redmine в этом плане является достаточно полной. А для того, что не упоминается в официальной документации, есть общая процедура запуска Rails-приложений, которую можно легко найти в Интернете.


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


Готовы? Тогда начнём.


Отложите сборки типа «все-в-одном» и готовые к запуску виртуальные машины


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


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


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




Установка — это только верхушка айсберга. Обновление — вот что придется делать регулярно.




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


Ниже я расскажу, как просто поддерживать Redmine в актуальном состоянии.


Используйте Git


Даже если вы намереваетесь запустить стоковый Redmine без каких-либо настроек или плагинов, всё равно используйте репозиторий Git для хранения копии Redmine. По крайней мере, наличие специализированного репозитория даст вам место хранения всего необходимого для развертывания (позже это будет рассмотрено подробнее). Рано или поздно вы (или ваши пользователи) захотите установить какой-нибудь плагин или настраиваемую тему, и для этого уже будет готова инфраструктура. Эксперименты с изменениями и тестирование плагинов и тем в локальных ветвях без нарушений в производственном коде становятся очень простыми при наличии собственного репозитория git c Redmine. Так что сейчас мы начнем с настройки репозитория.


Хотя основной репозиторий Redmine является экземпляром Subversion, на Github есть полуофициальный репозиторий, который поддерживается основным коммиттером и постоянно обновляется. Используйте его для настройки собственного репозитория:


Настройка локального клона Redmine


$ git clone git@github.com:redmine/redmine.git
$ cd redmine
$ git remote rename origin upstream
$ git remote add origin git@yourserver.com:redmine.git
$ git checkout -b redmine/3.2-stable upstream/3.2-stable
$ git checkout -b local/3.2-stable
$ git push --set-upstream origin local/3.2-stable

Измените номер версии 3.2-stable на номер последней стабильной версии Redmine.


Удаленный репозиторий git@yourserver.com должен быть частным, так как в нем будет храниться конфигурация развертывания (а возможно, и прочая информация, публиковать которую не стоит). Поскольку описанный ниже процесс развертывания будет извлекать из этого репозитория код, то репозиторий должен быть доступен во время развертываний, поэтому не размещайте его на настольных компьютерах. Идеальной будет ситуация, когда репозиторий также будет доступен с веб-сервера, на котором происходит развертывание. Но это при необходимости можно обойти.


Теперь у вас есть две локальные ветви:
redmine/3.2-stable, который отслеживает Redmine 3.2 без дополнительного функционала из репозитория github/redmine, представленная вышеуказанным удаленным восходящим репозиторием,
local/3.2-stable, куда будут помещены все настройки развертывания, кастомизации, темы и плагины.


Пропатчите обновления версий


Redmine использует следующую схему нумерации версий: xyz Major/Minor/Patch. Каждая младшая версия имеет собственную стабильную ветку, в которой исправления и патчи безопасности будут применяться с течением времени (до тех пор, пока эта версия все еще поддерживается). В нашем случае это ветвь 3.2-stable.


Время от времени эта восходящая ветвь будет получать некоторые новые коммиты. Ваша задача — включить новые коммиты в локальную ветвь local/3.2-stable для развертывания.


Хотя возможно и просто регулярно дополнять восходящую ветвь, я предлагаю использовать git rebase для поддержки собственного набора изменений поверх стокового кода Redmine:


Перебазирование локальных изменений поверх «голого» Redmine:


$ git checkout redmine/3.2-stable
$ git pull                          # new upstream commits coming in
$ git checkout local/3.2-stable
$ git rebase redmine/3.2-stable

Команда rebase:


  • Отменит все локальные изменения в local/3.2-stable.
  • Обновит local/3.2-stable, чтобы отразить изменения, произошедшие в redmine/3.2-stable.
  • Повторно применит все локальные изменения поверх «голой» версии.

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


Младшие и старшие обновления


Теперь, когда есть новая стабильная ветвь (скажем, 3.3-stable), делайте то же самое — перебазируйте ваши изменения поверх неё. Команды git будут немного отличаться из-за изменения восходящей ветви:


Перенос локальных изменений в новую стабильную ветвь


$ git fetch upstream
$ git checkout -b redmine/3.3-stable upstream/3.3-stable
$ git checkout -b local/3.3-stable local/3.2-stable
$ git rebase --onto redmine/3.3-stable redmine/3.2-stable local/3.3-stable

Эти команды вначале создают две новые локальные ветви для версии 3.3: одну из восходящей, а другую — из локальной ветви 3.2. Затем они перебазируют локальные изменения поверх redmine/3.3-stable. Локальные изменения здесь — это разность между redmine/3.2-stable и local/3.3-stable (что по-прежнему является redmine/3.2-stable). Теперь local/3.3-stable содержит Redmine 3.3 плюс любые локальные изменения.


Для новой старшей версии требуется сделать то же самое.


Бог ты мой, у меня конфликты!


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


Проверьте, какой из коммитов дал сбой, узнайте, для чего он предназначался (хорошо помогут осмысленные сообщения коммитов), исправьте файлы, командой git add добавьте каждый исправленный файл, когда закончите. Если конфликты были устранены, можно просмотреть изменения, которые будут зафиксированы, с помощью команды git diff --cached. Как только вы сочтете результат удовлетворительным, можно продолжить ребазирование с помощью команды git rebase --continue.


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


Что дальше?


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


Ссылки


  1. Deploy and maintain Redmine the right way
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/329872/


Метки:  

Однолинейные схемы в Revit

Понедельник, 05 Июня 2017 г. 05:26 + в цитатник
image
Revit — программный комплекс, реализующий принцип информационного моделирования зданий. Изначально программа предназначалась для архитекторов. Теперь все больше компаний при устройстве на работу требуют от инженеров умения работы в Revit. Autodesk Revit предоставляет мощный .NET API, позволяющий разрабатывать собственные приложения для решения различных задач. В данной статье хочу поделиться опытом создания однолинейных схем в Revit.


Главными преимуществами Revit для инженера являются:
— работа с актуальными планировками;
— совместная работа нескольких инженеров в одном файле;
— контроль пересечения инженерных коммуникаций;
— обмен заданиями;
— создание автоматически обновляемых спецификаций.
Revit также позволяет проектировать системы электроснабжения и вести расчет нагрузок в табличном виде. Недостатком является то, что нельзя вести расчеты, производить выбор оборудования и оформлять схемы в соответствии с нормативными документами, действующими на территории РФ. Создание однолинейных схем довольно трудозатратная процедура, отнимающая массу времени.
Когда я работал в Autocad, я использовал для расчета таблицу Excel: заносил мощность подключенного оборудования, названия, место расположения, тип, длины и еще множество параметров, производил расчет, а затем чертил схемы с помощью плагина для Autocad.
Теперь, при работе с Revit, все эти данные можно получить из BIM модели. Например данный плагин получает следующую информацию:
— Номер выключателя;
— Электрические нагрузки;
— Напряжение;
— Количество полюсов;
— Коэффициент мощности;
— Тип кабеля;
— Классификацию электрических нагрузок;
— Сечение нейтрального проводника;
— Длину кабельной линии.
Остальная информация рассчитываются на основе полученных и введенных пользователем параметров.
Работа плагина состоит из трех этапов:
1) Получение необходимых данных из BIM-модели и загрузки в форму для редактирования;
2) Редактирование пользователем параметров;
3) Создание схемы.
Плагин можно загрузить по ссылке.



Чтобы извлечь параметры электрических систем, получаем доступ к активному документу:
UIApplication uiapp = commandData.Application;
UIDocument uidoc = uiapp.ActiveUIDocument;
Application app = uiapp.Application;
Document doc = doc.Document;

Далее извлекаем необходимые параметры из BIM-модели. В данном примере рассмотрим как получить параметры цепи (номер, коэффициент мощности, тип кабеля), а также материал жилы кабеля из настроек кабельных линий. Поиск нужных параметров ведется по ID с помощью списка BuiltInParameters. Такой способ поиска параметра не будет зависеть от локализации Revit.
//Выбираем электрические цепи, относящиеся к щиту "ЩС"
ParameterValueProvider provider 
= new ParameterValueProvider(new ElementId((int)BuiltInParameter.RBS_ELEC_CIRCUIT_PANEL_PARAM));
FilterStringRule rule = new FilterStringRule(provider, new FilterStringEquals(), "ЩС", true);
ElementParameterFilter filter = new ElementParameterFilter(rule);
ICollection docCircuits =         
                (new FilteredElementCollector(doc))
                .OfCategory(BuiltInCategory.OST_ElectricalCircuit)
                .WherePasses(filter)
                .ToArray();
 foreach (Element docCircuit in docCircuits)
{
  //Номер цепи
  num = docCircuit.get_Parameter(BuiltInParameter.RBS_ELEC_CIRCUIT_NUMBER)?
  .Element.Name;
  //Коэффициент мощности
  powerFactor = 
  docCircuit.get_Parameter(BuiltInParameter.RBS_ELEC_POWER_FACTOR)?
  .AsValueString();
   //Тип кабеля
  cableType = 
  docCircuit.get_Parameter(BuiltInParameter.RBS_ELEC_CIRCUIT_WIRE_TYPE_PARAM)?
  .AsValueString(); 
  //Материал жилы  
  Element wireType = new FilteredElementCollector(doc)
                .OfClass(typeof(WireType))
                .FirstOrDefault(
                e => e.Name.Equals(cableType));
  string coreMaterial = wireType.get_Parameter(BuiltInParameter.RBS_WIRE_MATERIAL_PARAM)
  .AsValueString();   
}                          

После получения необходимых параметров можно приступать к созданию схемы. Создаем транзакцию и вставляем элементы схемы в файл. Кстати, единицы измерения — футы, поэтому при вставке элементов нужно не забывать про это.
using (Transaction tx = new Transaction(doc))
 {
   tx.Start("Создание однолинейной схемы");
   double xCoord = 0;
   // Вставляем отходящие линии
   foreach (Circuit circuit in panel.circuits)
   {              
     //Получаем семейство из активного документа по имени.
     FamilySymbol lineSymbol = FilteredElementCollector(doc)
                         .OfClass(typeof(FamilySymbol))
                         .Where(q => q.Name == "SLD_АВ")
                         .First() as FamilySymbol;
     //Переводим координаты точки вставки из миллиметров в футы
     XYZ coords = new XYZ(xCoord, 0, 0).ToFeets();
     //Вставляем семейство с именем SLD_АВ
     FamilyInstance line = doc.Create.NewFamilyInstance(coords, lineSymbol, uidoc.ActiveView);
     //Получаем все параметры семейства
     ParameterSet parametersLineOut = line.Parameters;
     //Записываем значение в параметр семейства
     foreach (Parameter param in parametersLineOut)
     {
      switch (param.Definition.Name)
       {
          case "Номер группы": param.Set(circuit.number); break;
          case "Тип кабеля": param.Set(circuit.cableType); break;
          case "Коэффициент мощности": param.Set(circuit.powerFactor); break;
       }
     }
     xCoord = xCoord + 25;
    }
      tx.Commit();
 }     

Все, схема готова!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330128/


Метки:  

ЧПУ (SEF URLs) в Symfony 3 — автогенерация slug, настройка и маршрутизация

Понедельник, 05 Июня 2017 г. 00:38 + в цитатник
Всем доброго времени суток!

Третьего дня мне понадобилось провести блиц вебинар на тему ЧПУ в Symfony. Вообще время вебинара у меня ограничено двумя часами, при этом я должен был рассказать еще и про автогенерацию CRUD функционала (scaffolding) в той же Symfony, и про простейший способ создать постраничность. Это создало проблему, так как я знаю как сделать ЧПУ «ручками», не прибегая к автоматизированным под эту задачу инструментам, но рассказ получился бы долгий и оказались бы затянутыми в обсуждение лишние темы. Поэтому я пошел спрашивать у Интернета как сделать все проще. И вот я оказался в той редкой ситуации, когда такая популярная платформа как Symfony не имеет банального обучающего материала на тему «ЧПУ в три клика». Смотрел так же и на английском языке, но там тоже пусто (может плохо искал — время было ограничено). В общем я справился с поиском разрозненного материала по данной теме, а так же со сбором его в единое повествование, так что почему бы не поделиться со всеми?



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

ЧПУ — аббревиатура от «Человекопонятные URL». На английский переводится как Friendly URL или Semantic URL. Однако чаще используется как аналогичная аббревиатура: SEF URLs — Search Engine Friendly URLs.

Что дает вам ЧПУ?

Самое очевидное — это то, что URL-ы вашего сайта будут понятны пользователю. Зачем, только, ему их читать? Большинство клиентов моих заказчиков даже не подозревают о наличии адресной строки браузера. Если есть сомнения, то посмотрите сколько результатов выведет запрос в Гугл «Где находится адресная строка браузера».

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

ЧПУ, не ЧПУ

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

Обычно можно найти шаблоны пути подобные таким:
http(s)://Домен/slug-категории/slug-подкатегории/slug-товара-или-статьи
http(s)://Домен/Профайл/slug-владельца-профайла

Тут появляется еще один термин — Slug, который важен для дальнейшего понимания статьи:

Slug — (из Викисловаря) альтернативная дружественная к восприятию человеком — буквенно-цифровая часть универсального адреса интернет-ссылки (URL) к рубрицируемому содержимому. То есть, если по простому, то slug заменяет всяческие признаки и id-шники ресурсов нашего сайта в URL-е на человекопонятный текст.

Разберем пример

Кому и так ясно что-такое ЧПУ — мотаем дальше.

Разбор примера как могли бы выглядеть URL-ы сайта, если их доработать до ЧПУ
На примере сайта магазина rozetka.com.ua (первый сайт, который попался под руку). ЧПУ тут в зачаточном состоянии. Давайте попробуем их ссылки довести до ума вручную:

Я зашел на страницу «Мячи для настольного тенниса» и адрес в ее оказался:
rozetka.com.ua/t_balls/c81265

Явно, что «c81265» первым символом указывает на то, что запрашиваемый объект — категория товаров, а число после него — id категории в базе данных.

Переделав под ЧПУ у на получилось бы просто:
rozetka.com.ua/t_balls

Просто удалили id-шник? Как же так? А как же контентные страницы (http://rozetka.com.ua/contacts/)?
Да никаких проблем. Просто поставьте все контентные страницы, так чтобы текущий путь в запросе сверялся в первую очередь с ними. В Symfony это делается всего лишь тем, что маршруты для этих путей объявлены первыми.

Если и так не получается или у вас на сайте есть еще что-то важное кроме контентных страниц и категорий товаров, то делаем более однозначный путь:
rozetka.com.ua/category/t_balls

Далее я перешел на сам продукт «Мячи для настольного тенниса Donic Elit 1* 6 шт белый (618016): rozetka.com.ua/198578/p198578

Вот тут просто беда. ЧПУ даже перестало пахнуть.

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


Здесь:

t_balls — slug категории
donic-elit-1-6-beliy — slug продукта

Думаю с наглядностью мы закончили.

Как получить ЧПУ в Symfony

Объяснять буду на примере свежей установки Symfony. На момент написания была взята версия Symfony 3.3.0. Предполагается, что вы установили Symfony и сконфигурировали доступ к базе данных.

Прежде чем начнется суть да дело нужно подружить нашу Symfony 3.3.0 с phpunit, чтобы она не валилась после автогенерации контроллеров. Дополните composer.json проекта двумя строчками:

composer.json
...
    "require-dev": {
        ...
        "phpunit/phpunit": "^6.2.1"
        ...
    },
...
    "config": {
        "platform": {
            "php": "7.0.15"
        },
        ...
    },
...

И произведите обновление зависимостей:

composer update

Или так, если у вас композер архивом лежит в проекте:

php composer.phar update

Генерируем внутри бандла AppBundle сущность продукта консольной командой:

php bin/console doctrine:generate:entity --entity=AppBundle:Product --fields="name:string description:text seller:string publishDate:datetime slug:string(length=128 nullable=false unique=true)" -q

Наверняка вы заметили, что помимо остальных полей имеется интересное поле slug. Я сделал его уникальным, и без возможности быть равным null. Дело в том, что в нашем новом проекте мы должны будем иметь возможность выбирать товары из базы данных как по id-шникам, так и по slug-ам. Slug теперь — наш второй после id уникальный идентификатор записи.

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

php bin/console doctrine:database:create #создаем базу данных
php bin/console doctrine:schema:create #создаем структуру данных в базе данных

php bin/console doctrine:generate:crud --entity="AppBundle:Product" --route-prefix=products --with-write -n #генерируем CRUD контроллер

Теперь после запуска сервера

php bin/console server:run localhost:2020

Мы можем посетить страницу http://localhost:2020/products/ и увидеть пустой список продуктов да ссылку на страницу создания нового продукта:



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

Подключение поведенческих расширений Doctrine

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

-> How to use Doctrine Extensions

Тут нам советуют использовать бандл StofDoctrineExtensionsBundle, который обеспечит корректное подключение расширений Doctrine. Читаем документацию по нему:

-> StofDoctrineExtensionsBundle

Устанавливаем бандл StofDoctrineExtensionsBundle:

composer require stof/doctrine-extensions-bundle

Подключаем скачанный бандл:

app/AppKernel.php
class AppKernel extends Kernel
{
    public function registerBundles()
    {
        $bundles = array(
            // ...
            new Stof\DoctrineExtensionsBundle\StofDoctrineExtensionsBundle(),
        );
        // ...
    }
    // ...
}

Из всего богатства вовлеченных нами в проект расширений Doctrine нам нужно всего одно — Sluggable behavior extension. Так что сконфигурируем StofDoctrineExtensionsBundle таким образом, чтобы это расширение было включено:

app/config/config.yml
...
stof_doctrine_extensions:
    default_locale: en_US
    orm:
        default:
            sluggable : true
...

Расширение Sluggable behavior extension подключено. Надо теперь указать ему, что именно от него требуется. Для этого почитаем по нему документацию:

-> Sluggable behavior extension for Doctrine 2

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

src/AppBundle/Entity/Product.php
...
use Gedmo\Mapping\Annotation as Gedmo;
...

/**
 * Product
 *
 * @ORM\Table(name="product")
 * @ORM\Entity(repositoryClass="AppBundle\Repository\ProductRepository")
 */
class Product
{
...
     /**
     * @var string
     *
     * @Gedmo\Slug(fields={"name"})
     * @ORM\Column(name="slug", type="string", length=128, nullable=false, unique=true)
     */
    private $slug;
...
}

Здесь я указал аннотацией @Gedmo\Slug(fields={"name"}), что я хочу, чтобы slug генерировался на основании поля name. Можно указать несколько полей, чтобы они конкантинировались при генерации. Например, часто вместо с именем сущности указывают дату создания: @Gedmo\Slug(fields={"publishDate", "name"}).

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

src/AppBundle/Form/ProductType.php
...
class ProductType extends AbstractType
{
    /**
     * {@inheritdoc}
     */
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->add('name')->add('description')->add('seller')->add('publishDate'); //Удалили ->add('slug')
    }
    ...
}

Заходим на форму создания продукта (http://localhost:2020/products/new)


Сохраняем и видим, что slug сгенерирован. Он годен для использования в маршрутах вашего приложения:



Остается проверить ЧПУ на деле.

Первый ЧПУ маршрут

Сделаем все по простому. А именно — переделаем маршруты products_show и products_edit:



таким образом, чтобы они показывали нам продукт не по id-нику, а по slug-у. Маршрут products_delete менять не будем, так как он не виден ни пользователю, ни поисковику.

src/AppBundle/Controller/ProductController.php
...
class ProductController extends Controller
{
     ...
     /**
     * Finds and displays a product entity.
     *
     * @Route("/{slug}", name="products_show")
     * @Method("GET")
     * @param string $slug
     * @return \Symfony\Component\HttpFoundation\Response
     */
    public function showAction(string $slug)
    {
        $product = $this->getDoctrine()
            ->getRepository('AppBundle:Product')
            ->findOneBySlug($slug);
        $deleteForm = $this->createDeleteForm($product);

        return $this->render('product/show.html.twig', array(
            'product' => $product,
            'delete_form' => $deleteForm->createView(),
        ));
    }

    /**
     * Displays a form to edit an existing product entity.
     *
     * @Route("/{slug}/edit", name="products_edit")
     * @Method({"GET", "POST"})
     * @param Request $request
     * @param string $slug
     * @return \Symfony\Component\HttpFoundation\RedirectResponse|\Symfony\Component\HttpFoundation\Response
     */
    public function editAction(Request $request, string $slug)
    {
        $product = $this->getDoctrine()
            ->getRepository('AppBundle:Product')
            ->findOneBySlug($slug);

        $deleteForm = $this->createDeleteForm($product);
        $editForm = $this->createForm('AppBundle\Form\ProductType', $product);
        $editForm->handleRequest($request);

        if ($editForm->isSubmitted() && $editForm->isValid()) {
            $this->getDoctrine()->getManager()->flush();

            return $this->redirectToRoute('products_edit', array('slug' => $product->getSlug()));
        }

        return $this->render('product/edit.html.twig', array(
            'product' => $product,
            'edit_form' => $editForm->createView(),
            'delete_form' => $deleteForm->createView(),
        ));
    }
    ...
}

app/Resources/views/product/index.html.twig
{% extends 'base.html.twig' %}

{% block body %}
    

Products list

{% for product in products %} {% endfor %}
Id Name Description Seller Publishdate Actions
{{ product.id }} {{ product.name }} {{ product.description }} {{ product.seller }} {% if product.publishDate %}{{ product.publishDate|date('Y-m-d H:i:s') }}{% endif %}
{% endblock %}


app/Resources/views/product/show.html.twig
{% extends 'base.html.twig' %}

{% block body %}
    

Product

Id {{ product.id }}
Name {{ product.name }}
Description {{ product.description }}
Seller {{ product.seller }}
Publishdate {% if product.publishDate %}{{ product.publishDate|date('Y-m-d H:i:s') }}{% endif %}
Slug {{ product.slug }}
{% endblock %}

Получилось так:



Теперь маршрут на детальный просмотр продукта выглядит так: @Route("/{slug}", name="products_show")

Маршрут на редактирование продукта: @Route("/{slug}/edit", name="products_edit")

Напоследок

Мы добились нашей цели:

  • slug генерируется автоматически при сохранении сущности
  • маршруты работают с учетом slug вместо id-шника
  • Поле slug в базе данных обладает уникальным ключом, что позволяет нивелировать тормоза при выборке продуктов по этому полю

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

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

Кстати, 3d картинку рендерил сам специально для этой статьи. Мне она понравилась, да и сил много не отняла.

Всем хороших маршрутов!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330170/


Метки:  

Дайджест свежих материалов из мира фронтенда за последнюю неделю №265 (29 мая — 4 июня 2017)

Воскресенье, 04 Июня 2017 г. 23:56 + в цитатник
Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.


Веб-разработка
CSS
Javascript
Браузеры
Занимательное

Веб-разработка



CSS



JavaScript



Браузеры




Занимательное



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



Дайджест за прошлую неделю.
Материал подготовили dersmoll и alekskorovin.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330190/


«Прикорнуть немножечко»: чек-лист для короткого перерыва на сон

Воскресенье, 04 Июня 2017 г. 20:14 + в цитатник
Здоровый сон — понятие субъективное. Работать над улучшением качества сна сложно или практически невозможно в силу индивидуальных жизненных обстоятельств. Мы решили подготовить краткий чек-лист, который поможет быстро погрузиться в эту тему и найти подходящие тематические источники, которые подойдут именно вам.

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


/ Flickr / Ricardo Velasquez / CC

Факты:


  • Бифазный паттерн сна очень распространен
  • Короткий сон в середине дня вреден для здоровья — это миф
  • Гейтс, Черчилль, Клинтон, Кеннеди и Эдисон делали перерыв на сон
  • Эффект от короткого сна нельзя сравнивать с воздействием кофеина
  • Многие американские компании заменили кофе-брейк на сон

Плюсы:


  • Napping в большей степени «выгоден» людям творческих профессий
  • Короткий сон улучшает работу памяти во второй половине дня
  • И благоприятно влияет на работу сердечно-сосудистой системы

Минусы:


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

Советы:


  • Откажитесь от будильника в пользу планирования времени на сон
  • Планируйте короткий сон через 7-8 часов после пробуждения утром
  • Пейте кофе и другие бодрящие напитки уже после короткого сна
  • Избегайте эмоциональных перепадов за пару часов до начала сна
  • Физические упражнения лучше завершить за 45 минут до сна
  • Прием пищи благоприятно влияет на качество короткого сна
  • Одного захода на короткий дневной сон вполне достаточно
  • Полностью откажитесь от napping’а, если не можете привыкнуть к нему

Мифы:


  • Короткий сон нужен только ленивым людям
  • Правильный выбор времени не отражается на качестве сна
  • Циркадный цикл «бодрствование-сон» можно игнорировать


/ Изображение Boston.com


Что нужно для перехода на «free-running sleep»:


  1. «Free-running sleep» — это сон без привязки к 24-часовой системе
  2. Журнал времени пробуждения утром и перехода ко сну вечером
  3. Лог должен учитывать короткий (и очень короткий) дневной сон
  4. Быстрый переход ко сну за 5-10 минут (иначе лучше просто не спать)
  5. Эмоциональные перепады — враг эффективного дневного сна
  6. Знание циркадного цикла (поможет планировать время для сна)
  7. Помещение без посторонних звуков и яркого света

Что почитать по теме:




Наши материалы по теме продуктивной работы:



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

https://habrahabr.ru/post/330178/


Метки:  

Inperfo – минималистичный мониторинг сети

Воскресенье, 04 Июня 2017 г. 19:10 + в цитатник

image


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


Сервис предназначен для мониторинга именно физических Ethernet-интерфейсов. Что, кстати, позволяет видеть перекосы трафика в Port Channel'ах при неверной настройке или каких-то других проблемах. Если у вас другие задачи, и нужно мониторить и другие типы интерфейсов, то посмотрите в сторону Observium'a и собратья (LibreNMS, NetXMS, etc) или на SolarWind NPM.


Основной целью создания сервиса было желание видеть топы по загрузке интерфейсов, ошибкам, чтобы все проблемные или потенциально проблемные места были как на ладони. В zabbix'e или cacti сделать такой динамический скрин мягко говоря проблематично. К тому же хотелось иметь топ по истории за неделю, а не в текущий момент – неделя, оптимальный вариант для многих сетей, когда нагрузка растёт после выходных и снижается к концу недели, или же наоборот – в выходные пики, а будние дни нагрузка ниже.
И вторая не менее важная цель — минималистичный интерфейс без излишних наворотов, сложностей и финтиплюшек. Подойдёт и понравится не всем, да.


Сервис решает 3 задачи


  1. Показывает "узкие" места сети. Это может быть перегруженный в час пик аплинк access-свитча в distribution level. Или же перегруженный порт до backup или memcached-сервера. Можно отдельно назначить интерфейсы как внутренние или внешние аплинки, чтобы видеть их в отдельном топе. Все графики строятся по максимумам – недельные, месячные и годовые графики не усредняются.
  2. Показывает ошибки на интерфейсах, для удобства группируя данные по хостам и датацентрам, отображая топ ошибок со всех устройств. Ошбики в таблице хостов и интерфейсов – сумма за неделю, на графиках – ошибок в секунду.
  3. Отслеживает кол-во свободных и занятых портов на свитчах, что помогает вовремя решать задачи по расширению сети.

И само собой, автоматически отслеживает изменения – переименование интерфейсов, описаний (ifDescr), изменение статуса интерфейса и так далее. Единственная ручная работа – добавление новых устройств или серверов в конфиг агента. Со временем добавится возможность auto discovery, но пока её нет.


Вам точно не подойдёт Inperfo, если вам нужны:
– Мониторинг CPU/Memory
– Мониторинг hdd, temperature и другие не Ethernet-вещи
– Возможность рисовать карты и схемы сети


Компоненты системы


Сервис состоит из двух компонентов: сервера и агента. Агент собирает snmp-данные об интерфейсах и отправляет их на сервер. Сервер обрабатывает (сортирует, обновляет rrd-файлы и прочая) полученные данные и отображает через web-интерфейс.


Как работает сервер


Сервер — это docker-контейнер со "стандартным" набором софта: nginx/php-fpm/memcached/mysql/rrdtool. Сервер ожидает, что агенты будут присылать данные каждые 5 минут. Данные сохраняются в базе – по нагрузке интерфейсов и ошибкам ведётся недельная history, по которой рассчитываются 95-й перцентиль и топ по max/avg. Сделано это для того, что "видеть" сеть в разных "разрезах" – без редких всплесков или наоборот, когда нужно посмотреть только всплески.
Данные контейнера хранятся на хостовой системе для удобства обновления, бекапа и переноса сервера на другие хосты. Обновиться можно буквально одной командой (идея взята у докера, см. https://get.docker.com)


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


Агент – это тоже docker-контейнер, в котором по крону раз в 5 минут запускается агент, собирающий snmp-данные об интерфейсах с сетевых устройств или серверов. Пока что интервал обновления (опроса) устройств изменить нельзя.
Клиент поддерживает две версии SNMP – v2 и v3.
Конфигурация агента, логи, и отправляемые данные хранится на хостовой системе. Это позволяет легко редактировать конфиги, переносить агента на другие хосты при необходимости.


Сценарии использования


Мониторим сетевое оборудование


В идеале нам нужно установить и настроить по одному агенту на каждый из дата центров или удалённых офисов, чтобы агент мог локально опрашивать устройства внутри дата центра по snmp и отправлять собранные данные на центральный сервер, который может находится в одном из датацентров или где-нибудь в облаке (Amazon, DigitalOcean, Azure, etc).
Если же у вас один дата центр или есть "быстрые" линки до остальных ДЦ, то достаточно установить сервер и агента на одной и той же linux-машине, с которой и будут опрашиваться все устройства сети. Или, например, на той же машине, где у вас уже стоит cacti – не нужно будет настраивать snmp-доступ на сетевом оборудовании (если он у вас есть :)
Основной "минус" этой схемы: нужен snmp-доступ к сетевому оборудованию.


Мониторим сетевые интерфейсы на серверах


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


Плюсы:


  • Можно обойтись без доступа к сетевому оборудованию
  • Можем довольно просто автоматизировать установку и настройку мониторинга
    Минусы:
  • Нет capacity по портам (если оно нужно)
  • Потребуется ручное добавление новых серверов в конфиг агента

Смешаный режим


Тут всё ясно, можно мониторить и свитчи/роутеры и серверы вместе – агент не различает тип устройства, а информацию по интерфейсам берёт из MIBv2-базы. Кстати, это ещё один минус – если у вас есть девайс, у которого информация по интерфейсам отдаётся с "нестандартных" MIB'ов (например, BTI 7000), то Inperfo, на данный момент, вам не подойдёт.


Производительность


Хорошо себя чувтсвует на "среднем" железе (16CPU/16GB) до 100 устройств (6000+ портов), на большем кол-ве запускать и наблюдать работу пока что не приходилось. Но посколько агент для опроса каждого устройства создаёт отдельный процесс (fork), то golang с go-рутинами просто изнывает и просится в этот кусок кода. Аналогично работает и сервер при получении данных.


Что добавится в следующих версиях


– Указание максимальной скорости для интерфейса. Нужно в ситуациях, когда к провайдеру вы подключены по 1Гб-линку, но оплаченный канал по факту меньше, аля ограничен до 500Мб.
– Еженедельные отчёты по топам на почту.
– Уведомления на почту.
– Отдельная сборка docker-контейнера с сервером и агентом. Для небольших сетей это идеальный вариант. Плюс появится возможность добавлять хосты через web-интерфейс.
– Топы/графики по пакетам
– Поиск по имени устройства, по интерфейсу, по описанию и по алиасу
– Переписать агента и часть сервера на golang.


На данных момент сервис не шлёт никаких алертов и прочего, но по URI /export/ можно импортировать данные в тот же заббикс, и получать уведомления. Сервис ещё немного сыроват, но поставленные задачи решает.


Install & enjoy.

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

https://habrahabr.ru/post/330188/


Метки:  

Блокчейн + распределённое хранилище = Sia

Воскресенье, 04 Июня 2017 г. 18:59 + в цитатник

Всем привет!


У всех нас есть данные, которые хочется держать под контролем. Мы не хотим потерять к ним доступ и не хотим, чтобы доступ был у кого-то ещё. Где хранить такие данные? Я считаю, что Sia может стать идеальным местом для этого и расскажу, почему.


Sia

Disclaimer: Sia активно развивается и, по словам разработчиков, всё ещё не подходит для того, чтобы быть единственным местом для бекапа.


Sia (произносится "Сая") — это распределённая система на основе блокчейна, участники которой хранят информацию на жестких дисках друг друга за плату. Участник системы может решить быть только пользователем, загружающим данные (в терминологии Sia — renter), или же сервером, принимающим данные (в терминологии Sia — host), или совмещать эти две роли. Хосты заинтересованы в хранении данных, так как они уходят в убыток, если теряют данные. Это обеспечивается следующим образом: при заключении контракта на хранение данных хост вносит депозит и ежедневно подтверждает факт хранения загруженных данных; если он этого не делает, то лишается части депозита. Подробности процесса оставим на десерт :-)


Вычисление кодов Рида — Соломона


Чтобы данные уцелели даже в случае отказа нескольких хостов, используются коды Рида — Соломона. Данные загружаются на 40 хостов и остаются доступными, если хотя бы 10 из этих хостов доступны. Избыточность хранения составляет 3x. В будущем ожидается рост uptime хостов, после чего избыточность можно будет снизить.


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


Страница Siacoin на бирже Poloniex
Страница Siacoin на бирже Poloniex.


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


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


Когда я осознал это, я решил было сделать систему, лишённую этих недостатков: децентрализованную, анонимную и надёжную. Сначала я решил проверить, нет ли чего готового на гитхабе. И нашёл Sia — именно то, что нужно! С точки зрения пользователя, Sia — это готовый аналог покупки кучи серверов для ручной загрузки данных. И аналог более эффективный, так как один сервер хранит данные тысяч пользователей. Калькулятор стоимости хранения на сайте Sia показывает, что хранение 5Тб в течение месяца обойдётся в 10 долларов. (Disclaimer: реальная цена будет выше из-за комиссий на создание контрактов и тройной избыточности хранения, но всё равно остаётся очень и очень привлекательной.)


Как загрузить файлы в Sia


Sia-UI


См. также руководство на официальном сайте.


  1. Скачать и запустить Sia-UI.
  2. Купить сиакоины.
  3. Загрузить файлы, используя интерфейс Sia-UI.

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


Если честно, Sia-UI я ни разу не запускал, так как я живу в командной строке, а Sia предоставляет отличные инструменты для этого: siad и siac. (Кстати, весь код Sia написан на Go, что не может не радовать.) Основы работы с siad и siac можно почерпнуть из статьи про запуск хоста и из хеплов этих программ. Программу siad обычно достаточно просто запустить, а взаимодействовать с ним уже через siac.


Примеры команд:


  • siac wallet unlock — разблокировать кошелёк (требуется ввод seed),
  • siac wallet balance — показать текущий баланс кошелька,
  • siac renter setallowance money time_period — заключить контракты с хостами,
  • siac renter upload /path/to/source/file path/in/sia — загрузить файл в Sia,
  • siac renter contracts — вывести все заключённые контракты с хостами.

siac взаимодействует с siad через HTTP API. С помощью него можно строить свои системы, использующие Sia в качестве хранилища. Команда Sia делает ставку на то, что в будущем компании будут хранить свои данные в Sia.


Для хранения данных необходима информация, находящаяся в папке renter/. Есть планы о восстановлении данных исключительно из seed (см. в разделе "планы").


По желанию можно сохранить информацию об объёме загруженного с помощью siac renter export и загрузить её в "пузомерку": rankings.sia.tech.


rankings


Как запустить свой хост Sia


siad


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


Про запуск своего сервера есть целая статья. Я тут опять пробегусь по верхам.


  1. Нужны программы siad и siac. Программа siad запускается, а все действия осуществляются через siac. Надо подождать, пока siad скачает блокчейн. Это занимает несколько часов, есть планы по значительному ускорению.
  2. Завести адрес (siac wallet address), закинуть на него сиакоинов, купленных любым способом.
  3. Добавить папку: siac host folder add /path/to/dir size
  4. Назначить цену за хранение, загрузку и выгрузку данных: siac config.
  5. Опубликовать информацию о хосте: siac host announce.

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


Доходы хостеров можно посмотреть на сайте siahub.info. Пример графика доходов хоста, на который загружено 585 из доступных 999 Гб:


siahub


Данный хост получает 57 сиакоинов каждый день. 1 сиакоин сегодня стоит примерно 1.5 цента, а значит этот хост ежедневно получает примерно 50 рублей. Пусть есть NAS на 4Тб за 20к рублей. При аналогичном проценте заполнения он выдавал бы примерно 200 рублей в день, то есть 6к рублей в месяц — неплохая окупаемость.


Доказательство хранения


image


В Sia хосты регулярно доказывают, что хранят загруженные данные. Это важный момент, так как иначе недобросовестные хосты могли бы сбрасывать все данные в /dev/null, продолжая получать плату. Выше я обещал рассказать, как устроено доказательство хранения. Это подробно описано в статье от создателя Sia. Ниже моё объяснение на пальцах.


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


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


У внимательного читателя мог возникнуть вопрос — а что, если зловредный хост будет хранить данные, но не будет давать их скачивать пользователю? Или просто иметь низкий uptime, из-за чего пользоваться им будет невозможно. Для борьбы с этим в Sia придумали систему рейтинга хостов. Каждый запущенный клиент вычисляет этот рейтинг независимо, в том числе измеряет uptime, поэтому лучше дать программе поработать вхолостую перед заключением контрактов, чтобы набралась статистика по хостам. Все факторы, влияющие на рейтинг, разбираются в статье про рейтинг. Рейтинги хостов можно смотреть командой siac hostdb -v и на сайте siahub.info.


Siafund


В Siacoin есть одна особенность, которую я не встречал раньше в альткоинах. Siafund — это особый вид ресурсов, который может храниться в том же блокчейне и на таких же адресах, как и Siacoin. Адреса, на которых хранится Siafund, получают часть доходов хостов. Отчисления в размере 3.9% от выплат по успешным контрактам распределяются пропорционально между держателями Siafund. В природе существует ровно 10к Siafund. Большая их часть находится у разработчиков (Nebulous Inc.), но немногим больше 1000 были в своё время распроданы. Siafund продаются на бирже bitsquare.io и на канале #siafunds Slack-чата. В настоящее время цена одного Siafund составлет примерно 2 биткоина. Siafund'ы неделимы.


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


Обозреватели сети


На siapulse.com и siahub.info есть красивые карты хостов.


map


Хосты уже есть на всех материках, кроме Африки. Общее количество активных — 275. В том числе хосты есть в нескольких городах России и Украины. Приглашаю всех, кому нужна помощь с запуском хоста и вообще с Sia, на каналы Slack-чата, включая #help, #russian и #farming.


Планы


Некоторые планы из официального roadmap:


  • возможность поделиться загруженным файлом с другим пользователем Sia (в следующем релизе) и с кем угодно (через 2 года).
  • Загрузка частей файла.
  • Эффективное хранение маленьких файлов.
  • Стримминг видео.
  • Автоматическое назначение цены хостом.
  • Восстановление файлов из seed.
  • Поддержка мобильных и других легковесных клиентов.

Сообщество



Жду всех в Slack-чате. Спасибо всем, кто дочитал до конца!

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

https://habrahabr.ru/post/330140/


Дайджест интересных материалов для мобильного разработчика #205 (29 мая-04 июня)

Воскресенье, 04 Июня 2017 г. 17:25 + в цитатник
Уже завтра открывается новая WWDC, а пока мы обсуждаем новый смартфон Энди Рубина, успехи инди-игр, архитектуру Android-приложений, искусственный интеллект и распознавание изображений, работу с отзывами и бесконечное ASO.



Как инди-игре обогнать Angry Birds?

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

Реалистичный Realm. 1 год опыта

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

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

iOS


Android


Разработка


Аналитика, маркетинг и монетизация


Устройства и IoT



< Предыдущий дайджест. Если у вас есть другие интересные материалы или вы нашли ошибку — пришлите, пожалуйста, в почту.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/330186/



Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 992 991 [990] 989 988 ..
.. 1 Календарь